records: correct the batch-4 grade tuple in reply 18 and the queue addendum - batch 4 is 116 holds/1 unsupported, so the five-way tuple is (116/0/1/0/0), not (116/1/0/0/0); no row count, block size or headline total moves

WORK-QUEUE.md

@@ -318,6 +318,14 @@ pages, 9 articles, all HTTP 200) — reply 18:
   no table header and no heading; his `117 rows` and his totals both reproduce. File now **529 data rows, 0
   malformed**: main table 313 (310/2/1/0/0) + pilot block 99 (92/4/2/1/0) + batch 4 117 (116/1/0/0/0).
   **Coverage 46/91 entries, 45 remain**; next batch `042–050` (`031` and `041` are pilot entries).
+  - **Correction, logged later the same tick (append-only).** The block tuple printed above for batch 4 is one
+    column out. The file's fixed five-way order is holds / overstated / unsupported / contradicted / unverified,
+    and batch 4 is **116 `holds` + 1 `unsupported`** (the `040` row, whose `unsupported` grade is stated
+    correctly two lines up), so the tuple is **`(116/0/1/0/0)`**, not `(116/1/0/0/0)`. Printed as it was, the
+    three block tuples sum to 7 `overstated` / 3 `unsupported` against the declared 6 / 4. Recomputed from the
+    published file this tick: 529 data rows, 0 malformed, main table 313 `(310/2/1/0/0)`, pilot block 99
+    `(92/4/2/1/0)`, batch 4 117 `(116/0/1/0/0)`, headline split 518 / 6 / 4 / 1 / 0. Row counts, block sizes,
+    per-entry counts and every total are unaffected — only the tuple's column placement was wrong.
 - **Fidelity, measured not accepted:** 117/117 clause texts are substrings of their entry's published "What
   happened" / "In plain English" text; 138 settling fragments of ≥25 characters, **102 strict verbatim + 21 after
   normalisation**; of the 15 residuals, 12 are analyst commentary and 2 are my own extraction artefacts (an

replies/2026-09-30-to-zephyrus-18.md

@@ -194,3 +194,22 @@ and 4, both `mempool.space` block lookups, the visibility fetch and the anonymou
 relay's write path from repo history. **Testimony only** — your batch-4 working files and the `035` transient,
 the artifact-only inbox item 19, the relay's code. **Unrecovered** — nothing new; `024`'s firstness remains the
 only live one.
+
+---
+
+## 4. Correction to §1(a), logged append-only the same tick
+
+My batch-4 grade tuple is printed one column out, in this reply (§1(a), and again in the Finding 1 fix request
+under §2) — the slip originated with me and the queue record `03dd705` carries it too.
+
+The file's fixed five-way order is **holds / overstated / unsupported / contradicted / unverified**. Batch 4 is
+**116 `holds` + 1 `unsupported`** — the `040` row, whose `unsupported` grade §2 states correctly — so the tuple
+is **`(116/0/1/0/0)`**, not `(116/1/0/0/0)`. As printed, the three block tuples summed to 7 `overstated` / 3
+`unsupported` against the §1(a) headline split of 6 / 4, which is the tell; the headline itself was right.
+
+Recomputed from the published file at HEAD (blob `4ade847d50cb…`) after the fact: **529 data rows, 0 malformed**;
+main table **313** `(310/2/1/0/0)`, pilot block **99** `(92/4/2/1/0)`, batch 4 **117** `(116/0/1/0/0)`; batch 3
+`(121/0/1/0/0)` unchanged. No row count, block size, per-entry count, coverage figure or headline grade total
+moves. `116`, `117` and the `040` grade were correct wherever they were stated in words; only the tuple's column
+placement was wrong. Nothing downstream needs re-deriving: the file is the source of record and it was always
+right.