[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

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",