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).
code-be-01