[james3014-nexus-agent]

Closes #517

Summary

• Root cause. The P0: cutover restart can relaunch stale deployment instead of approved target #377 activation-binding fence (src/cutover-orchestration.ts, added in cb20d84b and c069e406) refuses an orchestrated restart that has no activationBinding with RECONCILIATION_REQUIRED. This happens before the build-ready probe and the actuator. That refusal is intended. The cutover-progression.test.ts fixture was never updated (cutover-orchestration.test.ts already has a bindActivation helper). So three tests failed on main: the G4 canary, BUILD_NOT_READY, and actuator failure.
• Fix (test-only, expectations unchanged). A bindActivation() helper records an exact activation binding after the restart decision. The G4 successor reports the bound release and activationCutoverId, as the real replacement does. The original gates are reached again: BUILD_NOT_READY with 0 actuator calls, and CUTOVER_ACTUATOR_UNAVAILABLE then AWAITING_RECONNECT with no second schedule. The identity-mismatch case passed before only because the fence refused it first; it now reaches the real mismatch check.
• Chain. Removed the DS-1-F2 exclusion. npm test now also runs node --import tsx --test src/cutover-progression.test.ts and node --test scripts/ops/m5-cutover/m5-cutover.test.mjs. The m5-cutover tests were also not in CI before. Nexus Core verify runs npm test in a clean container, so both are now checked on every PR.
• No production code changes.

Evidence

• cutover-progression.test.ts: 3 failed on main; 8/8 pass after the fix. m5-cutover.test.mjs: 11/11 pass.
• check-test-chain: 131 chained, 6 excluded. typecheck clean. Merged with main 67907f2 and re-run.

🤖 Generated with Claude Code

[james3014-nexus-agent]

Review record — head f8c5a8310b2f71cc37c755e425b0eb29aae8a9c8

Independent Claude review (Claude Opus 5.5, bundle-M2-cutover lead; the implementation was done by a separate Sonnet agent): ACCEPT at f8c5a83.

• Test-only change, no production code. Root cause confirmed: the P0: cutover restart can relaunch stale deployment instead of approved target #377 activation-binding fence in src/cutover-orchestration.ts (cb20d84b, c069e406) refuses before the build-ready and actuator gates, as intended.
• The fixture now records an exact activation binding (same shape as cutover-orchestration.test.ts). Expectations are unchanged. BUILD_NOT_READY (0 actuator calls), CUTOVER_ACTUATOR_UNAVAILABLE (no blind retry) and the identity-mismatch check are reached for real again. Before this, identity-mismatch passed only because the fence refused it first.
• Chain: the DS-1-F2 exclusion is removed. npm test now runs cutover-progression.test.ts and scripts/ops/m5-cutover/m5-cutover.test.mjs.
• Found by the first Core run (isolated container): the no-env sidecar test crashed before printing its JSON when the container had no HOME. Fixed in cbd5bce by passing HOME and surfacing raw stderr on failure. Core is green since then, so both files now run in the container.

Cross-model review: not run. This is a low-risk, test-only PR, and the high-risk cross-model rule does not apply.

• Verdict: ACCEPT at f8c5a83

Delta since the first READY (cbd5bce): merges of origin/main after #522, #375 and #525 landed. The only conflict was the package.json test line, resolved by keeping both #522's tool-projection-recovery entry and this PR's two entries. After the merge, the PR diff is still the same 4 files. Re-verified: cutover-progression 8/8, m5-cutover 12/12 (includes #525's case), tool-projection-recovery 5/5, check-test-chain 132 chained / 6 excluded, typecheck clean, Core green on this head. The macOS smoke is red for the same pre-existing Node 24 OpenSSL sandbox error as on main.