Production is reached by promotion

A deploy target declares where it deploys, which environment that is, and which staging target it is promoted from. Before it will queue anything, the coordinator compares the WHOLE workspace — the container commit and every sub-repo commit — against the last successful build of that staging target. Not just the top-level commit: a sub-repo moving underneath you is exactly the change nobody notices.

A sub-repo the staging build recorded no commit for is treated as MOVED rather than matching. The reassuring reading of an absent value is the one that gets believed, so it has to be the safe one.

It refuses by naming the staging build that would satisfy it, so the message is actionable rather than merely negative.

Promotion promotes BYTES. Staging packs its distribution only after verifying the site it deployed, and the production job installs that archive rather than rebuilding.

Rebuilding from the same commit was the simpler option and was rejected: npm is not reproducible byte-for-byte, so "the same commit" is not "the same site", and production would ship bytes nobody looked at.

That makes a second check necessary — the artifact being installed must ITSELF be a build of the staging target for this workspace. Without it, a CI build's artifact or a superseded staging artifact promotes cleanly whenever some staging build exists at the right commit.