[FIX] REVIEWED-122 conditions 6, 7, 11 — and a fifth defect class found by the ruling's own placement (REVIEWED-122)

Executes the three legs REVIEWED-122 severed from the gated mechanism.

COND. 6 (second requirement, which the earlier docstring commit did NOT
discharge): checked what else relies on the discarded reading. Two sites.
(1) The selftest asserts `ruled_pendings ignores a ruling that names no PENDING`
using REVIEWED-82 as its fixture — a real AUTHORIZED ruling on PENDING-82,
presented as an example of correct ignoring. The assertion is mechanically true
and stays true; what is wrong is the fixture and what the name implies.
Annotated, NOT repaired: the repair sits inside the gated mechanism.
(2) governance-mcp.py asserts `governance_state item count == sec_pending()` —
a count-based agreement check, the exact shape finding 9 names, which passes
regardless of whether the classification is right. Reported, not changed.

COND. 7: PENDING-121 restored to the open list by hand as PENDING-143, a
disclosed CARRIER. Direct restoration was impossible without one of three acts
the executor may not take — editing REVIEWED.md (Constraint #1, and cond. 5),
inducing a Class-A header (trading hidden for unclosable), or changing the gated
parser. The carrier is labelled as a proxy, not as the item. -124 and -128
deliberately not carried: cond. 7 preserves their UNDETERMINED status.

COND. 11: filed separately as PENDING-144 rather than folded — script-resident
substrate claims are checked by nothing, including the drift-check. One confirmed
occupant; population explicitly unmeasured.

AND A FIFTH DEFECT CLASS, found by watching this ruling land. A ruling claims a
NUMBER, not a record. REVIEWED-122 named PENDING-142 and hid all four of its
records at once — fine here, since its conditions do dispose of them, but the
mechanism never checked that.

Where it is not fine: REVIEWED-115 (2026-08-10) claimed `131`, so all five
PENDING-131 records are hidden — including ADDENDUM 4, dated 2026-08-13 and
therefore SUPPRESSED ON ARRIVAL, three days after the ruling that silenced it,
while awaiting steward direction. PENDING-131 (c) is the unbuilt fence: the
pulling thread of every session since 08-10, made a CONDITION by REVIEWED-121,
and it has never once appeared in the list of items awaiting authorization.
The work was not lost only because MEMORY.md and the session records were
carrying it by hand.

The same item fails the other way too: REVIEWED-116's header
`PENDING-131/132/133/134` parses to one token matching no id, so a four-item
design-gate ruling suppresses nothing.

Filed as PENDING-145 — a new item, not a PENDING-142 addendum, because an
addendum would have been hidden on arrival, which is the defect. None of
PENDING-142's options (a)/(b)/(d) covers this: all three still resolve
id -> ruled. Flagged as something the pre-registered answer key must encode
BEFORE implementation, or the key will certify this behaviour as correct.

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

PENDING.md

@@ -3281,3 +3281,76 @@ The third is the sharpest: **both halves are in the same document**, so this is
 **Awaiting:** Steward. The jurist ruling above needs placement in `~/REVIEWED.md` by the steward's hand.
 
 ---
+## PENDING-143 — CARRIER: PENDING-121 is held open by its own ruling and cannot be shown by the instrument that lists open items
+**Date:** 2026-08-17
+**Tag:** [FIX]
+**Summary:** Executes REVIEWED-122 condition 7 — restore PENDING-121 to the open list by hand, at once, rather than when the mechanism lands. This entry is the carrier; it retires when PENDING-142 is built.
+
+**The item being carried.** `PENDING-121 — engine_source_binding: prose → declared surfaces, and the fingerprint specified but never recorded`. Its ruling, `REVIEWED-110`, reads verbatim: **`DESIGN GATE PASSED WITH CONDITIONS (1-4), then HELD OPEN for a redraft of Part IV.2 after substrate`**. Held open by the ruling itself, and invisible in `governance_state()` since that ruling was placed, because the suppression rule asks only whether a REVIEWED header names the id — never what the ruling decided.
+
+**Why a carrier rather than a direct restoration.** Restoring PENDING-121 itself requires one of three acts, and the executor may do none of them: editing `~/REVIEWED.md` so `REVIEWED-110` stops naming the id (forbidden — Constitutional Constraint #1, and forbidden again by REVIEWED-122 condition 5, which rules that placed records are not to be amended to satisfy the parser); renaming PENDING-121's own header to evade the regex (a Class-A defect deliberately induced — the item would then become permanently unclosable, trading a hidden item for an unclosable one); or changing the parser, which is the gated work that conditions 1–2 place behind a pre-registered answer key. **A carrier item is the only honest lever left**, and it is disclosed as a proxy: what appears in the open list is this entry, not PENDING-121.
+
+⚠ **Stated as a limit rather than glossed:** this does not restore PENDING-121. It makes the *fact of its being held open* visible in the surface where a reader looks for open work — which is the parent item's whole finding applied to itself. The steward may prefer a different lever; this one is reversible by deleting this entry.
+
+**What is actually owed on PENDING-121:** the Part IV.2 redraft that REVIEWED-110 held it open for. Not carried here; read REVIEWED-110 and PENDING-121 directly.
+
+**Not asserted:** PENDING-124 (REVIEWED-106) and PENDING-128 (REVIEWED-111) are the other two design-gate items in the same class. REVIEWED-122 condition 7 preserves the parent item's refusal to claim their status. They are **UNDETERMINED pending a steward read** and are deliberately NOT carried here — carrying them would assert what the ruling declined to resolve.
+**Files affected:** none — this entry is the mechanism.
+**Awaiting:** Retires when PENDING-142 lands and PENDING-121 becomes visible on its own. Until then, this is the record that it is open.
+
+---
+## PENDING-144 — Substrate claims inside the governance scripts are checked by nothing, including the script that checks for substrate claims
+**Date:** 2026-08-17
+**Tag:** [HARDENING]
+**Summary:** Filed separately per REVIEWED-122 condition 11, which ruled this out of PENDING-142 rather than folded into it. `governance-drift-check.py`'s subject is exactly one file; the scripts implementing the governance checks make substrate claims of their own, and nothing reads them.
+
+**Verified:** `governance-drift-check.py` reads `CLAUDE_MD = HOME / "dotfiles" / "CLAUDE.md"` and nothing else. Its own summary line — *"governance drift-check: CLAUDE.md clean (29/29 controls passed, 4 paths verified)"* — is accurate about its subject and is read, at every wake, as a verdict on governance state.
+
+**The confirmed occupant.** `ruled_pendings`'s docstring asserted that REVIEWED-78/-81/-82 were *"like-numbered rulings … concerning other matters"* which had *"falsely hidden"* three items. The substrate says the opposite in its own words, and the false claim sat inside the instrument that reports governance state, for weeks, until a jurist relay asked the parser why it disagreed with itself. **That is the exact class `governance-drift-check.py` exists to catch, one layer in, where it cannot see.**
+
+⚠ **Not asserted: the size of the population.** No census of factual claims in `scripts/` has been run, and its cost is unknown. The claim here is that the coverage gap is real and has one confirmed occupant — not that there are many, and not that there are few. Anyone acting on this should size it first; the temptation to infer a population from one vivid instance is the same error the parent item is about.
+
+**Why this is not simply "extend the drift-check."** The drift-check works because `~/CLAUDE.md`'s claims are *structured enough to be checkable* — paths that resolve or don't, tools configured or not, dates past or future. A docstring's claim that three rulings "concern other matters" is prose about the meaning of governance records. Building a parser to infer truth from prose that was never constrained to carry it is the trap PENDING-142 is about, one level up.
+
+**Options:**
+- **(i) Extend the drift-check's subject to script docstrings.** Rejected on the reasoning above unless someone can name the checkable sub-class.
+- **(ii) Require a checkable claim to carry its check.** Where a docstring asserts something about the substrate that *could* be verified, the assertion moves into the selftest, where it is executed rather than narrated. The selftest already does this for behaviour; this extends the same practice to provenance. Bounded, incremental, no new machinery.
+- **(iii) Disclose the gap and stop there.** The drift-check's clean line states what it does **not** cover, so a clean result is never read as "no false claims in governance tooling."
+
+**Recommendation: (iii) immediately, (ii) as standing practice, (i) only if a checkable sub-class is named.** (iii) costs one line and removes the overstatement at the surface where it is read; (ii) converts the class from narrated to executed wherever it can be, at the moment a claim is written rather than in a sweep afterwards. ⚠ Note that (ii) is the same shape as REVIEWED-122 condition 1 — a claim is worth more when the check precedes it than when it is composed alongside.
+**Files affected:** `~/dotfiles/scripts/governance-drift-check.py` (output line for (iii)); authoring practice for (ii).
+**Awaiting:** Steward authorization.
+
+---
+## PENDING-145 — A ruling claims a NUMBER, not an item: every addendum filed after it is suppressed on arrival, and the pulling thread has been invisible since 2026-08-10
+**Date:** 2026-08-17
+**Tag:** [HARDENING]
+**Summary:** Filed as a new item rather than as PENDING-142 ADDENDUM 4 **because that addendum would have been hidden the moment it was written** — which is the defect being reported. Found by watching REVIEWED-122's own placement.
+
+**The mechanism.** `ruled_pendings` builds a set of id *strings*; `sec_pending` skips any item whose header parses to an id in that set. Nothing compares dates, and nothing distinguishes a parent from its addenda. So **one ruling claims the number for all time**, and every record later filed under that number is suppressed on arrival, whatever it says and whoever it awaits.
+
+**Demonstrated on this session's own ruling.** REVIEWED-122 names PENDING-142. All four PENDING-142 records — the parent and ADDENDA 1, 2 and 3 — went hidden in one act. Here that is roughly right, since REVIEWED-122's conditions 2, 6, 9 and 11 do dispose of the addenda's contents. **But the mechanism did not check that, and would have hidden them identically had the ruling not touched them.**
+
+⚠ **Where it is not roughly right, and this is the finding.** `REVIEWED-115` (2026-08-10) rules on PENDING-131 — *"AUTHORIZED in part; one authorization VOIDED the same day; one conditional authorization LAPSED on its own condition."* It puts `131` in the ruled set. **All five PENDING-131 records are consequently hidden**, including:
+- **ADDENDUM 2** — `**Awaiting:** Steward authorization on (b), **(c)-as-PROPOSAL**, and §6.`
+- **ADDENDUM 4**, dated **2026-08-13 — filed three days AFTER the ruling that suppresses it.** `**Awaiting:** Steward direction on Move 1 … and Move 2 …`
+
+**PENDING-131 (c) is the unbuilt fence.** It is the pulling thread of every session since 2026-08-10, and `REVIEWED-121` made seeking it a **condition of the doctrine it ratified** — not a wish. **It has never once appeared in the list of items awaiting authorization.** A ruling placed before it existed had already claimed its number.
+
+⚠ **What this does NOT mean.** The work was not lost. The steward has been tracking it through `MEMORY.md`, the session records and the trackers, which is why it is the live thread rather than a forgotten one. **The harm is not that the fence was forgotten; it is that the parallel human system is the only reason it wasn't** — and the instrument whose stated job is to report what awaits authorization has been silent about the most load-bearing open item in the corpus for a week. A backstop that only works because someone is also holding it by hand is not a backstop.
+
+**And it fails in the other direction in the same place.** `REVIEWED-116`'s header reads `## REVIEWED-116 — PENDING-131/132/133/134 — …`. The regex captures the single token `131/132/133/134`, which equals no real id, so **that ruling suppresses nothing at all** — a four-item design-gate ruling with no effect on the open list. Over-suppression and under-suppression, in the two rulings covering one item.
+
+**Relation to PENDING-142.** This is a *fifth* class, not covered by that item's options: (a) title-matching, (b) decision-reading and (d) three-valued reporting all still resolve **id → ruled**, so all three inherit this. Any of them, built as specified, would keep every PENDING-131 record hidden.
+
+**Options:**
+- **(i) Match records, not numbers.** A ruling disposes of the specific record it names; an addendum filed later is a new record and starts open. Requires ruling headers to name what they rule more precisely than a bare number — which REVIEWED-116 shows they already sometimes try to do, and the parser already fails to read.
+- **(ii) Date-bound suppression.** A ruling suppresses only records existing at its date; anything filed later stays open until separately ruled. Cheap, needs no change to how rulings are written, and directly fixes the ADDENDUM-4 case. ⚠ But `**Date:**` is self-reported prose in both files, so this makes an unchecked field load-bearing — the *rank-on-fields-you-actually-write* hazard.
+- **(iii) Addenda are their own items.** Number them independently (`PENDING-146` rather than `PENDING-131 ADDENDUM 4`) and let the existing mechanism work. Costs the visible parent-child relation, which is real information.
+- **(iv) Explicit disposition.** A ruling lists the records it disposes of; anything unlisted stays open. Most honest, most burden on the jurist and steward at ruling time.
+
+**Recommendation: (ii) as the immediate stop-gap, (iv) as the durable answer, and neither before PENDING-142's answer key exists.** (ii) unhides the addenda now and its weakness is disclosed; (iv) is where this should land, because the underlying error is that closure is inferred from a number when it is a *judgment about a record*. ⚠ **This must be inside PENDING-142's pre-registered key, not bolted on after** — the key is a hand-read disposition for all filtered items, and if it is written against the id→ruled model it will encode this defect as correct and pass by construction. REVIEWED-122 condition 1 exists precisely to stop that, and this item is the reason it will be tested.
+**Files affected:** `~/dotfiles/scripts/wake-digest.py` (`ruled_pendings`, `sec_pending`).
+**Awaiting:** Steward authorization. ⚠ **Independently of the mechanism: PENDING-131 ADDENDA 2 and 4 await steward action now** and have been unable to say so since they were filed.
+
+---

scripts/wake-digest.py

@@ -862,6 +862,16 @@ def selftest():
         ruled_pendings("## REVIEWED-84 — PENDING-87 — Order attestation") == {"87"})
     chk("ruled_pendings does NOT suppress the like-numbered item  [the 2026-08-01 bug]",
         "84" not in ruled_pendings("## REVIEWED-84 — PENDING-87 — Order attestation"))
+    # ⚠ RELIANCE ON THE DISCARDED READING — reported under REVIEWED-122 cond. 6,
+    # NOT repaired here (the repair is inside the gated mechanism; see PENDING-142
+    # ADDENDUM 1). The assertion is mechanically TRUE and will stay true. What is
+    # wrong is the fixture and what the name implies: `REVIEWED-82` is not a
+    # ruling-about-something-else, it is the AUTHORIZED ruling on PENDING-82, and
+    # this line therefore presents the false-open class as intended behaviour.
+    # Whoever builds PENDING-142 will see this check fail, or be tempted to keep it
+    # passing. Failing is the fix working. Re-derive the fixture from the property
+    # ("does this ruling dispose of that item?") using two genuinely unrelated
+    # documents, per REVIEWED-122 cond. 2.
     chk("ruled_pendings ignores a ruling that names no PENDING",
         ruled_pendings("## REVIEWED-82 — Read-only MCP server: eyes on the substrate") == set())
     chk("ruled_pendings handles non-numeric families",