The server-side health verdict reports 'working' for all 89 finished runs — the enum has no member for a closed run

[serge-ivo]

health says "working" about every finished run — 89 of 89

f01d5b4 (#580 AC3) added a server-side verdict so a client would stop inferring "is this alright" from two timestamps. Measured live 2026-08-15 across 89 runs on 7 instances: health is "working" on all 89, including runs that failed, were cancelled, completed, or ended needs_human days ago.

Examples: b9d9c051 (failed 2026-08-13), af691f02 (failed on the circuit breaker), 47bf3703 (cancelled).

Mechanism

workers/api/src/lib/work-report.ts:100-108 — rule 1 is run.status !== "running" ⇒ "working".

The intent is right: a closed run should carry no liveness claim. But RunHealth = "working" | "waiting" | "stalled" (:77) has no member for not applicable, so "no claim" was folded onto the member that reads as the strongest possible positive claim.

Why this misleads a user into a wrong action

The whole point of a server-side verdict is that a client can trust it instead of deriving one. A client that trusts it reads working for a run that died three days ago — strictly worse than the two timestamps it replaced, because those at least disagreed visibly. This is #580's own defect one layer up: a field that cannot express the true answer returns a false one.

A gap this measurement leaves, stated

"waiting" and "stalled" both require status === "running", and 0 of 89 runs were running at audit time — correctly, given the owner's engine limit. So two-thirds of the rule is unexercised in production. The working case is confirmed wrong; the other two are unverified, not confirmed right.

Acceptance criteria

1. RunHealth gains a member for a finished run — "ended", "n/a", or the health field is absent on a closed run. Whichever is chosen, no closed run reports a liveness claim.
2. The tool description states what the field does and does not claim, so a client is not left inferring the inference.
3. A test covers all three live states and the closed state, with the denominator stated per ADR 0002 — this bug is a missing enum member, which only a test over the whole status domain catches.
4. Red demonstrated on today's code: a failed run must not report working.

Verified vs inferred

• Verified: 89/89 measured live; work-report.ts:77 and :100-108; the three named runs and their statuses.
• Inferred: nothing. The waiting/stalled gap is explicitly labelled unexercised rather than claimed correct.

[serge-ivo]

Mostly done in dc68e2a (wording correction in b4d6ea3). CI green, API + Host deployed. Leaving open on AC2 — one half of it is in a file another agent's lane owns; details and the exact fix at the bottom.

AC1 — done

RunHealth gains ended. runHealth() returns it for any run whose status !== "running":

// A CLOSED run makes no liveness claim in either direction (#459's rule, #588's member).
if (run.status !== "running") return "ended";

Absence was the alternative and it is rejected, on this batch's own evidence. #594 — measured on the same day — records two legends telling the model to read acts[].ok while the key was missing, and names the failure exactly: a model reads an absent key as "fine". An absence cannot carry a meaning; a word can. So ended is a member rather than an omission, and its own legend says it claims nothing about liveness.

AC3 — done, with the domain as the denominator

work-report.test.ts, and the denominator is compile-time exhaustive rather than hand-listed — which matters specifically here, because the bug IS a missing enum member and a hand-listed set would have been written from the same three-member assumption that caused it:

const DOMAIN: Record<LoopRunStatus | "running", true> = { … };
const REASONS: Record<LoopStopReason, true> = { … };

Adding a member to either type fails to typecheck in the test. One arm asserts the closed set is derived — every status it checks is what statusFor() returns for at least one real stop reason — so the four are reachable, not invented.

AC4 — red demonstrated on the shipped code

AssertionError: status=completed: expected 'working' to be 'ended'
Expected: "ended"
Received: "working"

The gap you labelled, respected

You flagged that waiting/stalled were unexercised (0 of 89 runs running). I did not treat them as correct-by-omission: there is a test named for it ("still classifies the three LIVE states, which the 89-run sample never exercised"), and #589's guard drives all four states end-to-end through the supervision surfaces. They are now confirmed by test, not by production. Production has since grown two parked runs (70ea298e, 0cbf401f, both ~5h in notify-coding-wait), so the waiting branch has live inputs available for a future measurement.

AC2 — HALF DONE, and this is why the issue stays open

The API side is done: RUN_HEALTH_LEGEND (work-report.ts) names all four members, says what ended does not claim, and ships in check_delegation's payload as healthLegend. A guard asserts it names every RunHealth member, so it cannot silently fall behind the enum again.

Two MCP tool descriptions still say the field has three values, and they are now false:

• workers/mcp/src/instance-tools/composition.ts:255 (check_instance_loop) — "it is the platform's own verdict and it has three values: working … waiting … stalled"
• workers/mcp/src/instance-tools/coding.ts:178 (coding_loop_status) — "Read health first — working | waiting (with waitNote …) | stalled"

This is not cosmetic. listLoopRuns is SELECT * FROM agent_loop_runs … ORDER BY started_at DESC with no status filter, so check_instance_loop called without a run_id returns mostly CLOSED runs — every one of which now answers health:"ended", a word its own description does not define. Verified against the deployed MCP worker: its last deploy was 927f963 and neither of my commits touched workers/mcp, so HEAD equals what is serving.

composition.ts:255 additionally still promises a parked run's note says "what for and until when" — the unconditional resume-time promise that b4d6ea3 removed from the API legend for #596, because coding-pause.ts:146 deliberately writes no waiting_until for a human handoff.

I did not make these edits: workers/mcp/** belongs to another lane in this batch. The fix is two description strings — add ended (a closed run; read status/stopReason; it claims nothing about liveness) and drop "until when" in favour of "says what for, and a resume time only when one is knowable". Needs an MCP deploy, not a version bump: descriptions are excluded from the surface-lock fingerprint by design, so this will not trip check-surface-lock.

[serge-ivo]

AC2's remaining half is done in 78bac76. CI green, MCP + API deployed. Closing — with two residuals named at the bottom that belong to other tickets, not this one.

The drift, fixed

workers/mcp/src/instance-tools/composition.ts and .../coding.ts both defined health as a three-member enum. Both now render it. Also corrected in the same pass: composition.ts still promised a park's note says "what for and until when" — the unconditional resume-time promise b4d6ea3 removed from the API legend for #596 — and neither description said the listing has no status filter, which is why most rows come back closed.

No MCP_SERVER_VERSION bump, confirmed rather than assumed. description is excluded from the surface-lock fingerprint by design (surface-lock.ts, DECISION 1). conformance.test.ts recomputed the 0.1.4 hash unchanged and check-surface-lock.mjs --require-history passes.

The half that mattered more: #593's guard did not merely miss this, it could not see it

#593 (927f963) measured its own reach honestly — 136 tools swept, 12 value-set claims, 1 backed, 9 inventoried. This drift landed the same day and went through two holes, and only one of them was the one that had been labelled:

1. The import boundary. Known and stated: workers/mcp cannot import RunHealth.
2. The scanner never found the claim. Measured: stateEnumClaims returns [] for both drifted descriptions. It reads (a/b/c) and `a`/`b` chains; these wrote `working` (gloss), `waiting` (gloss), `stalled` (gloss) — the shape a good description uses. So the claim was never one of the twelve, and no inventory entry could have recorded what the sweep never found. An inventory ratchet catches a claim that changes; it cannot catch one already stale, one whose source enum grows elsewhere, or one outside its denominator.

Widening the detector was measured and rejected. A glossed-chain pattern over the registered surface found 8 candidates, 6 of them false positives (result field names, the scope names write/destructive, a pair of tool names) — and on the very description this ticket is about it recovered only waiting|working, the long gloss hiding the rest. A guard that cries wolf six times in eight gets deleted; one that finds two of four members certifies the half it saw. That is state-vocabulary.ts's own doctrine holding: generation, not detection.

What was chosen, and the trade-off

Of the three options — a generated shared constant, build-time extraction, or an API-side test asserting MCP description text — build-time extraction, because it is the mechanism already in this file: CODING_RUN_STATES is a copy whose test parses the original's source. Cost: a regex that must be rewritten if the declaration is reshaped, which is why the parse asserts a floor (a parse finding nothing fails as a broken guard, not as a clean tree). Rejected: a generated file needs a codegen step plus its own drift check for one enum; an API-side test asserting MCP strings inverts the dependency and cannot drive MCP registration, so it would measure the template rather than the sentence a model receives.

runHealthSentence() renders into both tools — they call the same endpoint, both were hand-written, and both went stale independently. The sentence leads with the bare chain `working`/`waiting`/`stalled`/`ended` so what it publishes is also a claim the sweep can see and check.

Root fix found underneath: the exhaustiveness trick in these files is inert

RunHealth is now (typeof RUN_HEALTH_STATES)[number] over an as const array. Not style — no CI gate typechecks a Worker test. workers/api/tsconfig.json and workers/mcp/tsconfig.json both carry exclude: ["src/**/*.test.ts"], and vitest transpiles without checking. So Record<RunHealth, true> compiles nowhere and fails never. A value can be iterated at run time, and it is what lets the MCP copy be derived from source. The API legend guard now iterates it instead of a retyped list, and the legend's "four values" is computed — a hand-written count of an enum is the same claim as a hand-written list of it.

Red demonstrated (ADR 0002 G4)

Adding a fifth member to RUN_HEALTH_STATES with the descriptions untouched fails two independent guards:

× state-vocabulary.test.ts > matches workers/api/src/lib/work-report.ts, derived from its source
  → expected [ 'ended', 'stalled', 'waiting', 'working' ]
    to deeply equal [ 'abandoned', 'ended', 'stalled', 'waiting', 'working' ]
× work-report.test.ts > says what it does and does not claim, in the payload the model reads
  → expected '`health` is the PLATFORM'S OWN verdi…' to contain '`abandoned`'

The new split, printed in every green build

✓ 136 tools swept for value-set claims:
  14 claims found · 4 backed by a derived vocabulary · 10 inventoried as unbacked
  2 backed vocabularies (coding run state, run health) · 9 distinct UNBACKED_CLAIMS entries still present

12 → 14 claims; 2 → 4 backed occurrences; 1 → 2 backed vocabularies. The nine inventoried entries are untouched. The tally is now console.log'd like conformance.test.ts does, rather than asserted into a string nobody reads.

How far it generalises — measured per entry, not claimed

Of the 9 inventoried claims: 4 are one derivation away (board.ts:17 BoardView, feedback.ts:35 FeedbackStatus, agent-capabilities.ts:31 AgentRuntimeKind — needs the parser to accept the unquoted null — and agent-loop.ts:15 LoopStopReason, a union of nine of which the claim names three, a shape the sweep's subset rule already covers). 1 cannot be backed and should not be: events.ts:23 documents source as 'chat' | 'apply' | 'coding' | 'voice' | 'tool' | …, an open set with an explicit ellipsis — a closed set derived from it would be a new false claim. 1 is correctly labelled not a value set (field names).

Two residuals, for separate tickets

1. Three inventory citations do not hold. There is no workers/api/src/lib/tool-listing.ts in the tree; lib/connector-consent.ts contains none of granted/n/a/per_call/required (grep count 0); lib/coding-engines.ts declares EngineAuth = auto|machine|subscription|api-key, a different four-member set from the account|default|env|platform recorded. The reasons are prose, so nothing enforces them — an entry pointing at a nonexistent file still passes. Recorded in the file rather than guessed at: sending an implementer to the wrong file is the cost this mechanism exists to avoid.
2. AC3's stated guarantee is stronger than what runs. The Record<LoopRunStatus | "running", true> and Record<LoopStopReason, true> arms in work-report.test.ts are the inert shape described above — real coverage of the four states, but the compile-time denominator claim does not hold under this repo's gates. Making them real means turning those unions into const arrays in agent-loop.ts, a much hotter file. Left as-is and commented, not silently narrowed.

Not verified live: the deployed description text itself. tools/list requires an OAuth session (unauthenticated POST → 401) and I did not open a browser flow. What is confirmed: the MCP deploy on 78bac76 succeeded, /health answers {"ok":true,"tools":136}, and conformance.test.ts drives a real tools/list over the built server locally.