code-be-01
8080661557
ci/woodpecker/pr/ci Pipeline was successful
The next publish step bumped each package's own version but left @mosaicstack/* dependency ranges as published caret ranges (^0.0.3-next.2636). A caret range leaves the resolver free to pick any later build in the tuple — and on a host with a stale cache, an installer-side scaffold pinned at stable, or a registry proxy hiccup, that freedom is how a gateway@next install ends up executing stable-era dependency code (web1 evidence in #1389: old tier validator, missing migrations, stable versions in the dependency tree despite matching -next builds existing). Pipeline fix (not a per-package symptom patch): pass 2 of the publish script rewrites every published manifest's @mosaicstack/* entries (dependencies, devDependencies, peerDependencies, optionalDependencies) to the EXACT same-pipeline build recorded in pass 1 — exact pins make the stable-fallback class unrepresentable regardless of resolver path. A dep outside the publish set fails the publish loudly (cannot pin). New post-publish guard (same step, after the existing version check): npm-views every freshly published manifest and fails the pipeline when any @mosaicstack/* entry is not an exact -next.<pipeline> pin — stable-range leaks and cross-pipeline pins both red. Hermetic evidence (scripts extracted from the YAML, mock registry): bump+pin rewrites a 3-package sandbox to exact next.9999 pins; guard green on exact pins; red on ^0.0.3 stable range; red on 0.0.4-next.8888 cross-pipeline pin. No registry access needed to re-verify (mock-npm pattern).