§1 — Why this exists

Dispatches are silent by design: a headless worker opens with one short message and then works through tool calls for twenty minutes. Without a live view the lead cannot tell a deep worker from a stalled one, and a second orchestrator session cannot tell that a node is already being worked.

The upstream skillset solved this with a separate daemon on its own port. Reckon already runs one systemd-managed server on 127.0.0.1:8765 serving every mounted project, so a second daemon would be a regression. This plan folds the watcher into that server as a native surface and — more importantly — exposes in-flight state through the read tools agents already call.

§2 — Deliverables

Server routes. GET /crew across all mounted projects and GET /crew/<project> for one. Each response joins the live pointers with the owning repository's ledger: member identity and role from the ledger, phase and last activity derived by tailing the run's machine-readable log. Phase derivation is per-backend and reuses the terminal-event recognition already built for dispatch — done on a terminal event, working when the log was written recently, idle otherwise. Rows carry direct plan_href and sprint_href links so the view is navigable rather than merely informative. Tailing is bounded — read the tail of the log, never the whole file.

The watcher surface. A fifth glyph tab in the SPA shell beside Overview, Plans, Sprints and Graph, hash-routed consistently with the existing four, polling /crew. One row per run: member, role, plan and section with links, resolved model and effort, elapsed time, phase, last activity, and the gate the run is working toward. Follow the repository's minimal-ink figure discipline — this is a table of labels and values, so it is a semantic HTML table, never cards or tiles.

In-flight bands on plans and sprints. A plan page shows a band when any live run targets it; a sprint view badges each item that is in flight. This is what makes the live state answer the question the lead actually asks — not "what is the crew doing" but "is this being worked".

In-flight through the existing read tools. read_plan gains an in_flight block and roadmap rows gain an in_flight field carrying run id, member, section and start time. This is the cheapest available guard against double-dispatch: a second orchestrator, or a worker reading its own plan, sees a node is taken without needing to know the crew tool exists. For a node holding write scope a duplicate dispatch risks a conflicting second commit.

Repair the measured MCP and installation defects. Each was found while exercising the tools during design:

§3 — Evidence gates

§4 — Constraints

The server derives phase on read and stores nothing. Adding a background poller inside the server would create a second writer of run state and reintroduce the coupling the three-tier ownership split exists to avoid.

Server, parse and render changes are not hot. A restart is required and must be coordinated, since a running server and every connected MCP stdio process hold the old code in memory.

§5 — Recovery classification must read what the worker delivered

Run-state legibility is this plan's subject, and the classifier that a fresh orchestrator session depends on most is currently able to recommend promoting a run that delivered nothing. classify_pointer decides delivery from manifest_present or phase in ("complete", "failed"), and each half of that expression fails differently.

A terminal turn is not a terminal node. The stored phase reaches complete when the backend emits its end-of-turn event, which fires whenever the worker's turn ends — including a turn that ended in a NEEDS-HELP: surrender having produced nothing at all. Measured on this project: a run whose launch was rejected before its command started stored phase=complete with no manifest on disk, and recover classified it completed_unpromoted with the next action reckon crew complete --gate <verdict> --commit <sha> — a commit that does not exist, for work that never ran. Following that advice writes a fabricated success into the committed ledger, which is the one record later calibration treats as ground truth.

A failed run is advised to be promoted as a success. The same expression puts "failed" inside the terminal set, so the classification and the next action are identical for a run that failed and a run that succeeded.

Manifest presence is not manifest content. A blocked manifest exists exactly like a complete one, so a worker that correctly reported status: blocked is also classified as promotable. Delivery is a claim the manifest makes about itself, so the classifier must read the claim rather than infer it from the file existing.

The repair is to make the manifest's own status the authority on delivery, keep liveness where it already is in the process table, and let a run whose evidence disagrees with its phase report that disagreement rather than resolving it silently in favour of promotion.

§6 — Cleanup must consult live run state before removing a worktree

Worktree cleanup preflights for tracked and untracked changes and for reachability from the integrated branch, and refuses on either. Both checks protect committed or uncommitted work. Neither asks whether a worker is still running there.

So a node that has produced no commit yet — a read-only analysis, a verification run, anything early in its turn — presents as a clean worktree whose HEAD is already an ancestor of the primary branch, and cleanup removes it out from under a live process. Measured here: a session-wide cleanup removed five worktrees, one of which belonged to a run still in flight. The worker had read its ledger, was partway through its analysis, found its own working directory gone, and correctly refused to continue elsewhere rather than silently completing outside its fence. Its manifest reported the anomaly precisely; nothing was corrupted, and the node was redispatched. But the failure mode is a lost node with no signal beyond the worker noticing, and a worker that had not noticed would have written results from an unfenced location.

The live pointers already hold everything needed to prevent this: each names its worktree, and this plan's own work made that set readable in one call. Cleanup should consult it and refuse a path that a live run still claims, in the same visible-blocker style it already uses for a dirty tree. That is strictly better than asking the caller to remember, because the caller who forgets is an orchestrator mid-wave with several sessions of state in flight.

/reckon-ship inflight-visibility

/reckon-ship inflight-visibility