Record run 16: the rotation rung, half proven

A successor inherits the whole sealed plan. Phase progress is withheld
from a review successor on purpose, so the rung still needs an
implement-phase successor. F62: a requested handoff nobody answers is
invisible, and its only consequence is an expiry indistinguishable from
an idle one.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CVbaKucEYBjMqVeUgJUsc1

BURNIN.md

@@ -2527,3 +2527,63 @@ transaction and no session behind, on either worker.
 
 Both workers hold no sessions and no release transactions. Deployed pair is
 still `3c7cf95` on both halves.
+
+## Run 16, 2026-08-29: the rotation rung, half proven
+
+Task `06G4SWEVP71FYYKAV5FV0ZK5ZG` on `34f3c28`, a three-phase plan
+(`78d25730140c`) with automated checks inside policy.
+
+### Proven: a successor inherits the whole sealed plan
+
+The launch context of the session that picked the task up after its rotation
+carries the complete plan: overview, current state, desired end state,
+non-goals, approach, all three phases with their files, changes and
+verification, testing strategy, risks, migration, and ten research citations.
+
+### Not a defect: that successor was not given phase progress
+
+`renderPlanProgress` runs only for `WorkPhaseImplement`
+(`internal/agentctx/agentctx.go:321`). This successor picked up in review, and
+the code says why: an independent review must reconstruct the change from the
+diff rather than inherit the implementer's account. Progress is withheld there
+deliberately.
+
+So the rung still needs an **implement-phase** successor. The records exist and
+are durable, projected by `Task.PlanPhases()`.
+
+### Why the mid-implement rotation missed
+
+A trivial task spends about four minutes in implement, and all three phases
+verified inside two and a half of them, every one against the same tree
+`3da86dbf8ad5`. The implementer does the whole change first, then verifies each
+phase. The suspend, edit and restart that sets `handoff_requested` takes about
+a minute, and it landed after the implementer had already asked for review.
+
+Two mechanics worth keeping:
+
+- **The web handoff action cannot drive this.** `RequestHandoff` needs a local
+  coordinator and every session here is worker-owned, so it answers 503. That
+  is the Design A guardrail working, and a fourth UI-exposed gap.
+- **A state-file edit does not survive a running worker.** It holds sessions in
+  memory and writes them back. Suspend, edit, then restart; resuming lets the
+  old copy win. This cost one attempt to learn.
+
+### F62: a requested handoff that is never answered is invisible
+
+The rotation is agent-driven: the worker asks, and the agent must write
+`HANDOFF.md` at a turn boundary. The review agent never did. Renewals stopped,
+the lease expired at 10:12:05, and the task requeued having lost an attempt.
+
+Worker health recorded exactly one thing, 34 times:
+
+```text
+x34  lease 06G4SWEVP71FYYKAV5FV0ZK5ZG not renewed: agent status idle and pane unchanged
+```
+
+Nothing says a handoff was requested and left unanswered. There is no timeout,
+no retry, and no observation. The only visible consequence is an expiry that
+looks identical to an ordinary idle one. Diagnosing it needed the worker state
+file.
+
+The ring earned its keep again: one distinct message with a count of 34, rather
+than 34 overwrites of one slot.