The ship parent's run page is not useful: rounds do not link their child runs, bare 'U1 · started' rows carry no state, and the hand-off is rendered as the answer while the run is live

[justinhelmer]

Observed 2026-09-21 18:44Z on the run page of the hosted ship parent 1dab1ba0-d87d-403d-9f01-050cfa775e6d (#2134's runner), 41 minutes into the run, by the maintainer.

1. No child is visible or linked. The maintainer expected the coding run to be visible and linked from the parent. runs children 1dab1ba0 answers []: the review child 0f1eb8a2-318e-4efd-a323-c352263400e5 that ran round 1 (18:03–18:07Z) is not associated with its parent in the ledger, and the fix-round child was never admitted (starved by the A plain-words reply into a ship thread re-emits itself as a steer command every 3 s (runaway), and a reply into a thread whose runner ended is bound as a new ship #2144 loop, then refused by the drain since 18:31Z) — so the page shows neither the child that existed nor the child that is missing.
2. The timeline rows say nothing. U1 · started (with the unit's title), U1 · started again, U1 · request_changes — no link to the review run, the pull request, the verdict, the findings, or the head reviewed; no state after the last row. The maintainer: "all this is useless; it needs to actually be useful or go away."
3. The hand-off is rendered as the answer. The bottom block reads REPLY answer — Handed to the plan runner. • plan … • the unit adopts … while the run is still live 41 minutes later. The maintainer: "reply/answer is misleading because it's still running." The hand-off acknowledgement is not the run's answer; the page's last block must be the live state while the run is live and the final report when it ends.
4. The live label lies. Pondering… 38m / Ruminating… over Switchboard overhead 41m 09s with zero model time: the parent was waiting for a child admission that the drain refused. (Record 0072's one live state: "waiting for the deploy to finish", not a model-turn word.)

Requirements (record 0065: the hosted pipeline run is an orchestrator and every surface reads its standing from its own record; record 0072: one live state):

• Every round on the parent page is one row that links the child run (coding / review / fix) by id and label, the pull request and head it acted on, and the verdict with its findings count; a round whose child is not admitted yet reads the live state and its cause (fix round 1 — waiting for admission since 18:07Z: the bot is draining for a deploy).
• runs children <parent> lists every child the parent spawned, in order, with its stage and round; the parent's page is rendered from that list, so the two can never disagree.
• No row without state or evidence: U1 · started twice is a bug in the emitter, not a rendering choice.
• The hand-off message is labelled as the hand-off (Handed to the plan runner is a step, shown in the timeline), never as REPLY answer; while the run is live the page ends with the live state; at the end it ends with the unit's report.
• The live label comes from the one server-owned state (record 0072), never from a model-turn word when no model turn is in progress.

Related: #2144 (the incident that exposed it), #2116 (parents and children under one rule), record 0072 plan (#2140).