Summary

Fixes a stall-watchdog blindspot where the orchestrator's heartbeat tracker treated stateLastUpdatedAt as a forward-progress signal. That timestamp gets touched on every state rewrite — including no-op rewrites that auto-resume performs each time the loop re-enters — so during any prolonged hang where the orchestrator keeps auto-resuming (e.g. a subagent that returns without progress and gets retried), the stall clock reset every tick and the no-progress watchdog never fired its USER_ACTION_REQUIRED escalation.

Observed in the field as a 30+ minute hang with only heartbeat output, build_stall_threshold_ms set to 30 min, and the user-action prompt never triggered.

Fix

build/orchestrator/monitor.ts — drop stateLastUpdatedAt from the moved predicate. Keep drainProcessedCount (real progress signal) and add phase (sidecar's phase index, only advances on real forward progress) as the new positive signal. Pre-fix tracker files without lastSeenPhase parse fine; the moved-check is gated on tracker.lastSeenPhase !== undefined so the old-tracker case falls through correctly to "no positive signal observed" on the next tick.

lastSeenStateLastUpdatedAt is retained in the tracker schema for backwards-compat with pre-fix on-disk state (read but ignored; written preserved for forward-compat readers).

Test Coverage

build/orchestrator/__tests__/monitor.test.ts — 3 new regression tests:

1. STALL ARM: stateLastUpdatedAt advance is NOT progress (spawnResume tracker-reset regression) — pre-seeds tracker with stale state, advances only stateLastUpdatedAt on subsequent ticks, asserts USER_ACTION_REQUIRED fires (the bug repro).
2. STALL ARM: phase advance IS progress (resets stall clock) — asserts MONITOR_REENTER + RUN_RUNNING when phase advances, and tracker upgrade to lastSeenPhase: 2.
3. STALL ARM: pre-fix tracker without lastSeenPhase still works (backwards-compat) — old tracker schema (no lastSeenPhase field) still escalates correctly because the comparison gate defaults to "no positive signal."

Result: 36 pass / 0 fail / 101 expect() calls (~480ms).

Investigation note: plan-review-loop STALEMATE (false-alarm Bug #2)

A second hypothesis from the field investigation — "plan-review-loop missing STALEMATE emission on round-cap with synth returned ok:false" — was investigated and ruled out. The STALEMATE path already exists in plan-review-loop.ts at two sites:

• plan-review-loop.ts:1424 — continue path on synth ok:false
• plan-review-loop.ts:1468 — round-cap path on synth ok:false

Both return finalResult("synth_failure", round, 1, verdict). The caller in cli.ts:11710-11722 properly throws ExitError(1) on loopResult.exitCode === 1. End-to-end wiring is correct. The observed 30-min hang was entirely attributable to the tracker regression fixed in this PR.

Adversarial review summary

Reviewed for: backwards-compat with old trackers, phase wrap/backwards, brand-new-run signals at 0, test tautology, schema break for pre-fix readers, sidecar/tracker race. All clean. One minor theoretical concern (phase going backwards would count as progress) is a non-issue in normal flow — phase shouldn't go backwards in healthy operation, and if it does the run is already in a degraded state where a one-tick stall-clock reset is acceptable.

Test plan

• bun test build/orchestrator/__tests__/monitor.test.ts — 36/36 pass
• Smoke test: launch a real gstack-build run, simulate a synth hang, confirm watchdog fires within build_stall_threshold_ms (manual verification, recommended before merge)