docs: reconcile the lane's records with its final state

Four stale claims, all in durable documentation that would have shipped
as written.

The framing still said "AWAITING APPROVAL. Nothing implemented" while
the ledger and the PR both said otherwise.

R7's status line said SIXTH OCCURRENCE while the body below it recorded
the seventh. Its tree-exclusion bullet said the observing lane's diff is
two docs; the lane carries three. And its cumulative figure said in-gate
is 2 failures in 3 runs, which omitted this lane's final head-exact
verification gate --- a fourth in-gate run, green. The figure is 2 in 4,
and the fourth is named so a reader can tell which run it was.

Active-work carried the same stale docs count and the same 2-in-3, and
recorded neither PR #244, nor the final head 2d76984, nor the gate log
20260829T152824Z-673477. It now carries all three, with the gate's
result read from its eight stage logs rather than inferred from stage
exits.

The sweep that found the last 2-in-3 also printed "(none = consistent)"
unconditionally, which is the read-success-from-absence shape this
project keeps catching. It now prints the hit count and only claims
CLEAN when that count is zero.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai

docs/active-work.md

@@ -316,11 +316,11 @@ from #171 and #215.
   were green and stage 6 (`gpu`) genuinely failed — that one completed
   and reported — but the run as a whole proves nothing and must not be
   read as a gate outcome.
-- **That `gpu` failure is R7's SIXTH occurrence**, recorded in
+- **Those `gpu` failures are R7's SIXTH and SEVENTH occurrences**, in
   `docs/ci-red-signatures.md`. All three required fragments, isolated
   selector green three times, and **this lane touches no `pmacs-gpu`
   file at all** — its whole diff is two `assert!` message strings and
-  two docs.
+  three docs.
 - **GATE RUN 2: 7/8, `gpu` red on R7 again** (head `45d438c`, log
   `20260829T150011Z-429115`). `sweep` ran fully green this time.
   **Two consecutive in-gate R7 failures prompted a narrowing**: 17 green
@@ -329,9 +329,17 @@ from #171 and #215.
   false and the registry's first write-up — which called those runs
   *exclusions* — is corrected there: nothing outside the gate has ever
   reproduced this, so matching one gate condition at a time outside it
-  cannot isolate an in-gate cause. In-gate is 2 failures in 3;
-  out-of-gate is 0 in 17. Recorded in the registry; **not this lane's
-  to solve**.
+  cannot isolate an in-gate cause. In-gate is 2 failures in 4;
+  out-of-gate is 0 in 17 — **and a fourth in-gate run, this lane's
+  final verification gate, was also green, so the cumulative figure is
+  2 in 4**. Recorded in the registry; **not this lane's to solve**.
+- **PR #244** — https://github.com/levineuwirth/pmacs/pull/244, opened
+  at head **`2d76984`**, which is exactly the head the gate ran on.
+- **GATE GREEN, head-exact**: all 8 stages, log
+  `20260829T152824Z-673477`, with `HEAD` and a clean worktree captured
+  before and after. Zero `FAILED` lines and zero non-zero-failure
+  result lines across all eight stage logs, read from them rather than
+  inferred from stage exits.
 - **Still owed, separately:** `workflow_dispatch` on `ci.yml`, and U9's
   discriminating control — pin test-binary concurrency to 1, then load
   a lone `--lib` binary — which has been named since 2026-08-09 and

docs/ci-red-signatures.md

@@ -496,7 +496,7 @@ Stage 4; the lane touches no `pmacs-gpu` code at all.
 | **selector** | `-p pmacs-gpu attach::tests::managed_retry_survives_transients_and_uses_the_successful_stream` |
 | **job / flavor** | local (Linux), `cargo test --workspace --features crdt --no-fail-fast`, i.e. under full-sweep load |
 | **required fragments** | `transient sequence must attach` + `Handshake(Io(` + `BrokenPipe` (or `code: 32`) |
-| **status** | **SIXTH OCCURRENCE 2026-08-29 — causal status still UNRESOLVED.** The fifth carries the strongest tree exclusion this row has had: a **documentation-only diff** |
+| **status** | **SEVENTH OCCURRENCE 2026-08-29 — causal status still UNRESOLVED.** The sixth and seventh came back to back on one lane and are written up together below; the fifth carries the strongest tree exclusion this row has had, a **documentation-only diff** |
 | **what IS established** | **three** occurrences at `pmacs-gpu/src/attach.rs:1680`, the second and third with all three fragments **verified** rather than inferred; the test drives a scripted transient-then-success sequence over a real socket pair. **The added GPU test is not the mechanism** — see the third-occurrence control below |
 | **what is NOT** | whether the broken pipe is the *fixture's* writer closing early or a real retry-path defect. **This row is not a claim that it is harmless** |
 | **rerun evidence** | occurrence 1: 6 isolated runs green, plus a full `--workspace --features crdt` sweep green (113 targets). Occurrence 2: **30 green on the observing branch** (15 isolated selector, 15 full `-p pmacs-gpu`) **plus a 15-run merge-base control, also green**. Occurrence 3: 5 isolated selector runs green, 10 full `-p pmacs-gpu` runs green **with** the added test, and **1 failure in 10 with the added test `#[ignore]`d** — the first rerun in this row's history that reproduced anything. Per the rerun rule the green runs establish intermittence only; the red control run is what carries the exclusion |
@@ -516,7 +516,7 @@ at `pmacs-gpu/src/attach.rs:1889`, `283 passed; 1 failed`.
 
 * **The tree exclusion is as strong as the fifth's.** The observing
   lane's entire diff is `src/async_runtime.rs`,
-  `tests/m4_acceptance.rs` and two docs — **no `pmacs-gpu` file, and no
+  `tests/m4_acceptance.rs` and three docs — **no `pmacs-gpu` file, and no
   file `pmacs-gpu` links against beyond the workspace it always did.**
   The change is two `assert!` message strings.
 * **Rerun: isolated selector green three times** (`1 passed`, 0.01 s
@@ -562,8 +562,11 @@ four conditions **by itself** reproduces the failure. They do not show
 that any of them is uninvolved when the gate supplies the rest.
 
 **What the observations actually support**, stated at the strength they
-carry: in-gate is **2 failures in 3 runs**; out-of-gate is **0 failures
-in 17**. That asymmetry is suggestive and it is not a clean split,
+carry: in-gate is **2 failures in 4 runs** — the failing pair, then two
+greens, the second of which is this lane's final head-exact
+verification gate (`20260829T152824Z-673477`) — while out-of-gate is
+**0 failures in 17**. That asymmetry is suggestive and it is not a
+clean split,
 because the third in-gate run passed.
 
 **The method for the next occurrence follows from that.** Varying

docs/parse-budget-diagnosability-framing.md

@@ -1,6 +1,6 @@
 # Parse-budget diagnosability — reporting the measurement that failed
 
-**Status: revision 2 — AWAITING APPROVAL. Nothing implemented.**
+**Status: revision 2 — APPROVED 2026-08-29, IMPLEMENTED, PR #244.**
 
 Revision 2 answers review of 1. Three of its four changes are
 corrections, and one is a scope reduction: