Record run 21: F66 proven, and why round one did not count

The first fix wrote the projection and lost it at the rotation the reopen
causes, so the planner still got nothing. Both rounds passed their unit
tests; what separated them was where the assertion sat in the sequence.

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

BURNIN.md

@@ -2947,3 +2947,72 @@ The implement session kept working after the reopen. It verified phase-2
 against the old plan 40 seconds after the task had moved to `plan`. Harmless,
 because supersession discards it, but the reopen does not end the session that
 reported the contradiction. That session rotates at its own next boundary.
+
+## Run 21, 2026-08-29: F66 proven, in two rounds
+
+Tasks `06G4WW6TND26M16CZA6WE5T458` (issue 32, on `edf0076`) and
+`06G4XAFH1MBPC35VSJN7V3NS14` (issue 34, on `7539696`).
+
+### Round one failed, and the failure was in the fix
+
+`edf0076` projected the contradiction onto the task and rendered it into the
+plan-phase context. The projection appeared at the reopen and was gone before
+the planning session launched:
+
+```text
+16:58:01  PlanMismatchRecorded phase-2 replan, plan reopened
+          projection carries the contradiction
+16:58:20  TaskReleased          the rotation the reopen causes
+          projection empty
+16:59:29  replacement sealed, planner never told anything
+```
+
+The clearing rule added with F67 sits **below** the reducer switch, so it runs
+for every event rather than for the correction it was written for. A release
+found the task unblocked and erased the contradiction. Two mistakes made it:
+the rule was written as if it were inside `case "TaskCorrected"`, which is
+merely the nearest case above it, and the unit test read the projection at the
+moment it was written rather than at the moment the planner reads it.
+
+`7539696` scopes the clear to `TaskCorrected`, and the store test now walks the
+real sequence: mismatch, reopen, release, lease, then assert.
+
+### Round two: the planner is told what it was convened to fix
+
+```text
+18:00:17  PlanMismatchRecorded phase-2 replan, plan reopened
+          projection survives the rotation
+18:01:02  planning session launches
+```
+
+From that session's `.orchestra/launch.md`:
+
+```text
+## Why this phase reopened
+
+A plan was already accepted and the code contradicted it. Orchestra reopened
+this phase to settle that, and the session that found it is gone.
+
+- phase: phase-2
+- observed: The summary lines are printed from the recorded results after
+  every check has run, ...
+- the plan says: The plan states that phase 2 prints the header from a helper
+  that returns the number of checks about to run.
+- evidence: scripts/orchestra_e2e_healthcheck.sh:1
+
+The accepted plan stays accepted until you seal a replacement, and sealing one
+supersedes it along with every phase it had verified. Address the
+contradiction above: a replacement that repeats it will be contradicted again.
+```
+
+It renders above the sealed research and plan, because it changes how they
+should be read. The first planning session of a task carries no such section,
+and neither does implement. Sealing the replacement (`2edcbe9e`) cleared the
+projection, which is the other end of its lifetime.
+
+### The lesson worth keeping
+
+Both rounds of this fix passed their unit tests. What separated them was where
+the assertion sat in the sequence. A projection written correctly and read one
+rotation later is not the same claim, and only the live run put the read where
+the agent does.