Record run 18: an implement successor inherits verified phase progress

The rung the last two runs missed. A five-phase task with ten named checks
kept the implement phase open long enough to rotate inside it. The successor
picked up in implement and its launch context carried the whole sealed plan,
phase-1 and phase-2 as verified, phase-3 as the first unfinished phase, and
the current human authority.

Unasked-for bonus: the progress block renders SHA staleness itself, naming
the tree each phase was verified against and the tree it is now.

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

BURNIN.md

@@ -2691,3 +2691,72 @@ the fix.
 because `omitempty` does not omit a zero `time.Time`. The worker parses it back
 to a zero value and `watchHandoff` starts the clock, so behaviour is correct.
 It is the same marshalling trap the operator console hit.
+
+## Run 18, 2026-08-29: the implement-successor rung, proven
+
+Task `06G4VF5HZW7Q4JBM3TTY7W1Y64` on `c587f2c`, a five-phase plan whose phases
+are ten named checks rather than one refactor. Volume of mechanical work is
+what keeps the implement phase open; phase count does not.
+
+### The rotation
+
+```text
+13:43:10  implement session launched
+13:43:44  phase-1 verified
+13:44:04  phase-2 verified
+13:44:35  handoff requested, reason=milestone, delivered by watchHandoff's resend
+13:45:25  TaskLeaseRenewed
+13:46:51  TaskReleased   handoff_ref 0b4fae6f705a  anchor 8ea3c7d1ae8f
+13:46:51  TaskLeased     successor, same harness
+13:46:55  TaskPickupValidated
+13:47:06  TaskLaunchAcknowledged, still in implement
+```
+
+The lever was the worker state file, backdated past `handoffRetryAfter` so the
+request went out on the next tick. Under `c587f2c` that lever now produces a
+real prompt: the flag alone used to sit there unasked, which is how run 16
+ended in a silent expiry.
+
+### What the successor was given
+
+From `.orchestra/launch.md`, written at 13:47:05:
+
+```text
+## Current phase
+implement: Implement the accepted plan below. Verify as you go.
+
+## Verified git state
+- head: 8ea3c7d1ae8fd960897344694645117adbd8ee82
+- uncommitted changes: false
+
+## Current human decisions
+None recorded. Work from the goal and acceptance above.
+
+## Plan progress
+Orchestra established this by running the plan's own verification. You cannot
+write it.
+- phase-1 (...): automated checks passed at d3acd4989a20, stale because the
+  tree is now at 8ea3c7d1ae8f, waiting for the human to confirm the manual steps
+- phase-2 (...): automated checks passed at d3acd4989a20, stale because the
+  tree is now at 8ea3c7d1ae8f, waiting for the human to confirm the manual steps
+- phase-3 (Checks 7 to 8): not started
+- phase-4 (...): not started
+- phase-5 (...): not started
+```
+
+Everything the rung asked for is there: the complete accepted plan with all
+five phases, their files, changes and verification; the phases already
+verified; the first unfinished phase; and the current human authority. The
+launch context also carries the accepted research and its dead ends.
+
+**SHA staleness renders itself.** Neither phase is reported as simply passed.
+Each says the checks passed at `d3acd4989a20` and are stale because the tree
+has moved to `8ea3c7d1ae8f`. That is half of the manual-verification rung
+observed without being asked for.
+
+### The lever still loses a race, sometimes
+
+`systemctl restart` alone leaves a five-second window in which the running
+worker's tick save can clobber the edit. It clobbered run 17's attempt and
+survived run 18's. Stop, edit, start is the reliable sequence, and it needs
+`systemctl stop` and `start` in the unattended sudo rule.