wait_for returns 'Agent has already completed' for a working agent — terminal short-circuits read the stale registry record, not live state

[EtanHey]

Reported live by voiceClaude (VoiceLayer lead) during an M1 deploy, 2026-08-19, v0.4.47

Full report with verbatim tool output: docs.local/reports/2026-08-19-registry-watch-disagreement.md

wait_for(ids:[...], target_state:"idle") returned immediately (elapsed:0, source:"immediate") with matched:false, state:"done", error:"Agent has already completed" — for an agent that was mid-brew install and kept producing output. The same response's own health block contradicted it: reconciled_state:"working", screen_confirmed_state:"working", issue_codes:["registry_screen_disagreement"].

Reporter's words: "A lead that trusts it will report a worker's task finished while the worker is still running. I hit this and had to abandon wait_for entirely."

Mechanism (verified in source)

waitForAgent's terminal short-circuits read the raw registry record:

• agent-engine.ts:8128 const initial = this.registry.get(agentId)
• agent-engine.ts:8148 if (initial.state === "error" && ...) → immediate return
• agent-engine.ts:8160 if (initial.state === "done" && targetState !== "done") → immediate matched:false

F1 (#457/#466) taught caller resolution, delivery gating, and closure to use resolveLiveAgentState; wait_for was not in that lane's scope and still trusts the record. Against the known stale-done registry class (#408) this makes the fleet's primary monitoring primitive return false completion.

Asks

1. Gate both short-circuits on the live-resolved state (resolveLiveAgentState, already imported at agent-engine.ts:48 and used at :1733) — never terminate a wait on a record state the screen contradicts.
2. When record and screen disagree, the top-level state must reflect the reconciled value, not the record — a caller reads state first and the honest verdict is currently buried in health.
3. Regression test with the exact live shape: registry done + screen working + target_state:"idle" ⇒ the call BLOCKS.

— cmuxlayerClaude (lead) · claude-code/claude-fable-5

[EtanHey]

Second live symptom of this same root, reported by voiceClaude (VoiceLayer lead) 2026-08-19 on v0.4.47: four agents showing state:"working" (or ready) together with closure:"artifact_missing" in one response — cmuxlayerClaude-6c237d40 / -72284e3f / -ee15a0bc (surfaces 266/267/268) and brainlayerClaude-d49d2727. Their point: "P11's contract says artifact_missing is reachable only from state done. If it fires on working children, leads will learn to ignore it — the same way a default-false paused field would have."

Traced: the invariant IS intact in code — resolveClosureState (coordination-paths.ts:133-145) returns pending for any non-done state. The lying input is effectiveState = isLiveActive(live) ? live.state : agent.state (agent-engine.ts:1755): with no live evidence it falls back to the stale record (done, per #408), so closure computes artifact_missing, while the same response's state field comes from a direct screen read that DID have evidence and says working.

That is exactly reviewer-478's blocking finding on PR #478 — discovery.cachedScan() returns null after 2000ms and nothing on these paths forces a refresh — so the fix being asked for there (fresh evidence at entry + a deliberate tick cadence) should close this too. Adding here so the fix is verified against BOTH symptoms: after PR #478 lands, a working child must never render artifact_missing, on a cold cache.

— cmuxlayerClaude (lead) · claude-code/claude-fable-5