milestone bridge: distinguish a settled-then-cancelled run, fix the leader-facing worker model

[nikolasd]

What

A completed protocol turn (real work done, a real answer produced, but nothing ever called run/finish to render a verdict on it) lands in the same cancelled run state as a run that never got that far, and the milestone digest told the leader the same thing either way: "was cancelled. Any partial output it produced is readable ..., though there may be none." For a run that genuinely finished its turn, that reads as if the run failed and might have produced nothing, when in fact the result is complete and just sitting unread.

The run state itself does not change — cancelled is the correct terminal state for both cases, and stays that way (the maintainer's own 2026-09-09 ruling, shared with the leader-disconnect case: ADR-0027 reserves succeeded for an explicit run/finish). Only the digest text now distinguishes them.

Four commits, in order:

1. The digest branch. MilestoneTracker gets a new public hasSettledTurn(runId): boolean, reading the same #sawSettled bookkeeping isMilestone's own runFlagsEvent arm already keeps (no new state). formatDigest takes a required 3rd argument (tracker: MilestoneTracker) and branches on it inside the cancelled case only: settled → "finished its turn and ended without a verdict; the result is complete. Read it via crew_run { op: "result", runId }." (reusing the existing READ_THE_REPORT constant, same tone as succeeded's digest); not settled → unchanged wording.

   Read-first: formatDigest/MilestoneTracker have exactly two consumers in the whole extension — milestones.ts itself (the one production call site inside attachMilestoneBridge) and milestones.test.ts (all 11 existing call sites, updated to pass a tracker). Nothing else imports either export.

   Reproduce-first: two new tests pin both branches. Confirmed RED by temporarily stashing just milestones.ts (keeping the new tests) and running against the unpatched source — the settled-turn case failed with the old wording. Restored the fix, confirmed GREEN.

   This branch deliberately covers two populations that land in cancelled for different reasons but get the identical next action: a leader that never called run/finish on a real, completed turn, and the daemon's own recovery sweep ending a waitingUser/waitingPeer/paused run at restart (traced against crates/runtime/src/recovery.rs's target_state_for) — if that run's turn had genuinely settled before the restart, the new sentence is still true and the leader's next move is identical. No third branch needed. One bound is named in the same comment: hasSettledTurn only knows what this bridge instance observed — a connection opened strictly between a run's settle and its terminal event, with the settle already behind the replay cursor, falls back to the unchanged wording (not a regression this branch introduces; that run got the same wording before it existed).

2. The leader-facing worker-model premise. crew_run's own tool description and crew-orchestration/SKILL.md both stated "a TUI vendor's process outlives its turn" / "a TUI vendor process never exits between turns" as the reason a settled turn is readable before a run goes terminal — only true for a TUI worker. Replaced with the model that covers both adapter shapes: a TUI worker persists between turns, a protocol worker exits when its turn ends, and in both cases a settled turn is when the answer is readable.

   Confirmed correct and left untouched: crew-orchestration/SKILL.md:29-30 (the crew_send/crew_finish framing predating this list, since superseded — see commit 3), crew-approvals/SKILL.md:35, docs/user-guide.md:187 — each already gates its own advice on an observed state.

3. The terminal/parked split. Commit 2's own fix re-committed a version of the premise error four lines below the fix: it told the leader "once the run is terminal or settled, read via result and close via finish" — joining two outcomes that need opposite handling. Measured end to end: a protocol worker's clean exit with a settled turn lands as RunState::unrendered_verdict() (crates/protocol/src/run.rs), i.e. "cancelled", a terminal state; run_finish rejects any terminal run outright (invalid_params, "already finished", crates/runtime/src/service/orchestration.rs:1449-1456). So the joined instruction told the leader to call finish on an already-terminal run and get refused. Split: settled-but-non-terminal (waitingUser) → result then finish, as before; already terminal (including cancelled after a settled turn) → result is the whole of it, finish will refuse (names the exact error). crew-orchestration/SKILL.md's own numbered list split the same way in all three spots that carried the same joined claim (the park's transience, result's readability, the crew_send/finish bullets).

4. Drop an unmeasured timing claim introduced while writing commit 3 ("exits ... within milliseconds") — nothing in the proof-run artifacts times that specific interval. Replaced with the structural reason (a protocol worker runs one turn and exits), which is both true and can't rot, using the repo's own established phrasing for this shape.

Tests

• packages/extension/src/milestones.test.ts: 31/31 pass (29 existing, updated for the new required tracker argument, + 2 new: cancelled after a settled turn says the result is complete, not 'may be none', cancelled with no settled turn keeps the existing partial-output wording).
• Commits 2-4 are doc/description-only, no behavior change — verified with the marker guard (clean) and a full read of every changed sentence, not just a diff skim.

Gate

bun run check full pass on the four-commit tip: marker guard (446 files, clean), generate --check clean, format/typecheck/extension-build clean, bun test 639/639, cargo test --workspace all green.

Note: this branch's runs.ts edit changes the extension bundle's embedded text; the committed dist/ is expected to go stale against it until CI's bundle-check/auto-commit-dist rebuilds it (not hand-built here — a macOS/arm64 build wouldn't byte-match CI's linux-x64 one).