Files
dotfiles/claude/governance/record-keeping-cluster-JURIST-PACKAGE-2026-08-27.md
T
David F GliddenandClaude Opus 5 aec342f385 session 2026-08-27: the block ruled NOT PASSED; the answer key finally exists
The jurist design-gated the six-item record-keeping block and returned it not
passed, on three counts, all now discharged:

  1. The package's frontmatter asserted the jurist has NO repository access.
     False — PENDING-161 (open, [ESCALATE]) had said so two days earlier, and
     the false premise generated the package's whole relay architecture.
  2. Cluster membership was set by relay; the root was never run back across
     the register. PENDING-143 states 145's mechanism in the same words.
  3. Part V's argument for not drafting the answer key does not survive: a
     hand-read key cannot pass by construction, and a block-keyed key collapses
     safely into an id-keyed one under the opposite ruling.

Ruling filed verbatim BEFORE any act under it — PENDING-108 (c)'s ordering,
first adoption. Its own 10-package clock now starts on that package.

Filed: PENDING-166 (mumble legibility), -167 (seam cap 12, provenance stated so
it is not laundered), -168 (condition 3's structural remedy + the fourth-instance
doctrine, explicitly NOT added to the frozen ladder), -169 (the steward's standing
Tarbuckle dispositions, recorded because they existed nowhere else), -170 (the
built-vs-ruled tags cannot be armed while REVIEWED-128's header names no PENDING).
Amended PENDING-162 (the fortnight is compromised for the seam limit only),
PENDING-89 (the fool is not a fourth checker, by ruling as well as construction),
PENDING-104 ADDENDUM 1, PENDING-165 (option (c)'s blocker discharged),
PENDING-142 (the key's hash), PENDING-131 ADDENDUM 4 (Move 2 dispositioned).

PENDING-104 ADDENDUM 1 resolves an anomaly the jurist reported and declined to
explain: two of its tools disagreed on line numbers by exactly 23, because the
executor inserted a 23-line note while it was reading. The executor's filing
silently corrupted the checker's view of the executor's filing.

Two of the steward's eight asks were already discharged (PENDING-160, the §9
strike) and were reported rather than duplicated.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RmFYCUeAaPqbpJMj6uGokk
2026-08-27 22:32:17 +02:00

33 KiB
Raw Blame History


title: The record-keeping cluster — six items, one block date: 2026-08-27 type: PROPOSAL — block design gate. Authorization chain: executor drafts → jurist design-gates → steward authorizes. audience: the jurist, who has BOUNDED READ ACCESS to the governance register via governance-mcp.py (governance_item, governance_state, repo_activity) and NO filesystem read. ⚠ CORRECTED 2026-08-27 under the ruling's condition 1: this line first read "who has NO repository access", which is false and is the third placement of a premise PENDING-161 filed two days earlier. The Grounding section below is therefore a CONVENIENCE, not a necessity — the jurist can read those items directly, and did. What remains genuinely unreachable from the jurist's side, and is therefore executor testimony throughout: the contents of wake-digest.py, governance-drift-check.py, the skill files, and the absence of the answer key. status: DRAFT for the design gate. Nothing in this document is built, run, or landed. The one measurement it reports was run read-only and is reproduced in full.

The record-keeping cluster — PENDING-110 · 145 · 146 · 108 · 144 · 139

How to read this

Part I measures the live state of the two registers using the digest's own parser, with pre-specified positive controls, and reports what the measurement cannot settle. Part II gives each of the six items its substrate status — every ask checked against code read today. Part III demonstrates the rework the block ordering exists to prevent: it is not hypothetical, and one instance is already in the record. Part IV proposes that five of the six are one defect and names it; it also argues the sixth is not, against the grain of grouping them. Part V identifies the single artifact this entire block gates, which is unbuilt and was ordered built "first" ten days ago. Part VI traces consequences, Part VII gives change-class and landing, Part VIII the scope boundary, Part IX the gate questions.

The one-sentence claim to test:

These six items cannot be correctly ruled one at a time, because five of them are the same defect — a status inferred from narrative prose that was never constrained to carry one — and the remedies each proposes presuppose an answer to a unit question none of them is authorized to settle alone; the sixth belongs in the sitting for a different reason, stated rather than smoothed over.


Grounding — the ratified text this builds on (quoted verbatim)

This section exists because the recurring failure is composing a claim about the constitution from memory when the constitution already settles it. These are the actual words, read 2026-08-27.

§ ~/CLAUDE.md — Steward-Jurist Interface, the REVIEWED.md template (line 179):

## REVIEWED-[N] — [Matches PENDING-N title]

§ ~/CLAUDE.md — Authorization Taxonomy:

| [HARDENING] | Addresses the class of failure, not just the instance | Propose in PENDING.md; await steward annotation | | [PROPOSAL] | New architectural direction or contract | Explicit steward authorization via REVIEWED.md |

§ ~/CLAUDE.md — Constitutional Constraint #4:

Honest degradation — The system must report its own limits. Silent failures are architectural violations

§ REVIEWED-105 §4 — the sequencing precedent the jurist cites (2026-08-08):

  1. SEQUENCING across the four open items: land 123 before 119(i) and 120(a). Both add lines to .precommit-triggers; a validator that catches a malformed line should exist before the file grows. In the other order, the first thing to test the new declarations is the declarations themselves.

§ REVIEWED-122 condition 1 (2026-08-17) — the pre-registered key:

  1. CONDITION — the acceptance check is a pre-registration, and its ordering is load-bearing. […] the per-item disposition answer key over all 69 filtered items is hand-read and committed before the implementation exists, with the commit hash recorded. A key written after the fix inherits the fix's reading of what closure means, and would pass by construction. […] If the key and the implementation disagree on any item, the disagreement is the finding and is reported — never reconciled by amending the key.

§ REVIEWED-122 condition 5 — placed records are not edited to please the parser:

  1. CONDITION — the reader is fixed; the placed records are not silently amended. REVIEWED-78, -81 and -82 are placed rulings and are not to be edited to satisfy the current parser. Fixing the record to please the instrument inverts which of the two is authoritative. Should the steward decide the headers are worth normalizing, each amendment carries a dated note stating what was changed and why, per no-silent-revision — but that is a separate steward act and is not authorized here.

§ REVIEWED-122 condition 10 — the scope of what a ruling can verify:

  1. Scope of this ruling, stated rather than assumed. I read PENDING-142 verbatim via governance_item, and independently observed governance_state() reporting PENDING-81 open against an AUTHORIZED REVIEWED-81 […] Everything else […] is executor testimony from a script I cannot run. That is precisely why condition 1 requires a hand-read key: the ruling cannot verify the census, and the acceptance check is the only instrument that can.

§ REVIEWED-122 condition 11 — the severance that produced PENDING-144:

  1. A follow-on item is owed and is not folded in. The drift-check covers ~/CLAUDE.md and reads no script. […] Whether script-resident claims warrant coverage is a [HARDENING] question larger than this item and is to be filed separately rather than absorbed here.

§ REVIEWED-122 If AUTHORIZED: — the build order in force:

If AUTHORIZED: Draft and commit the hand-read answer key first, with its hash recorded. Submit the (b) decision-verb enumeration for ruling before wiring. Then implement (d) with (a) and (b) inside it, per conditions 2–5.

§ The two mechanisms under discussion, quoted from source (read 2026-08-27).

~/dotfiles/scripts/wake-digest.py:438 — the whole of what decides "ruled":

return set(re.findall(r"^## REVIEWED-\S+\s*—\s*PENDING-(\S+?)\s*—", reviewed_text, re.M))

~/dotfiles/scripts/wake-digest.py:449-453 — the whole of what decides "open":

for h, ln in open_items(t):
    m = re.match(r"PENDING-(\S+?)\s*—", h)
    if m and m.group(1) in ruled:
        continue
    items.append((h, ln, tag_of(t, h)))

~/dotfiles/scripts/governance-drift-check.py:217 and :645:

RE_HEAD = re.compile(r"^##\s+REVIEWED-(\d+)\s*[—-]\s*(.*)$", re.M)
RE_BUILT = re.compile(r"\bBUILT\b")

Part I — Terrain: what the registers actually contain, measured today

A read-only script reproducing the digest's parser exactly (the two quoted blocks above) was run against the live PENDING.md and REVIEWED.md on 2026-08-27. Four positive controls were specified before it was run, because a clean zero from a governance instrument is the most dangerous output it can produce; three false zeroes were caught in this corpus on 2026-08-26 alone, and only one of the three was caught before it was believed — by a control the jurist pre-specified. All four controls passed.

Dated observation, 2026-08-27 Value
## blocks in PENDING.md 114
Distinct ids the parser resolves those blocks to 101
Ids the parser considers "ruled" 80
Blocks shown open that have a like-numbered ruling naming no PENDING 23 candidates
Blocks suppressed as ruled that still carry a live **Awaiting:** line 52 candidates
Rulings whose captured id matches no live item 34

⚠ The two candidate columns are candidate columns, and this is the finding, not a hedge.

  • The 23 cannot be reported as 23 false opens. Some are numeric coincidences that name the same item harmlessly; some are rulings genuinely on that item; telling them apart requires reading each. Verified subset: PENDING-78, -81, -82 — three items shown OPEN in this morning's wake digest against three rulings recorded AUTHORIZED on 2026-07-28, whose deliberate like-numbering REVIEWED-122 condition 6 already establishes from REVIEWED-78's own Notes.
  • The 52 cannot be reported as 52 live asks. Many carry self-cancelling text — Awaiting: Nothing. RULED 2026-08-06, ~~Steward authorization.~~ → BUILT — which is the stale-Awaiting: population REVIEWED-122 condition 10 already names. Verified subset: PENDING-131 shows four blocks carrying live awaits (parent, ADDENDUM 1, ADDENDUM 2, ADDENDUM 4) — an independent reproduction of the hand-read table in PENDING-146, arrived at by a different route.
  • Of the 34, most are items long since moved to PENDING-archive.md, which is correct behaviour. The one defect in the column is 131/132/133/134 — REVIEWED-116's header, captured as a single token equal to no id, so a four-item design-gate ruling suppresses nothing at all.

⚠ THE MEASUREMENT DEMONSTRATES THE BLOCK'S THESIS AT ITS OWN EXPENSE. An instrument built specifically to size this problem returns two columns it is not entitled to total. It can establish the class and bound the candidate pool; it cannot settle a single item's disposition, because disposition is a judgement about a record and no aggregate reaches it. That is precisely why REVIEWED-122 condition 1 requires a hand-read key — and it is why the numbers above are offered as terrain, never as an acceptance check. Reporting them as totals is the column-manufacturing error this corpus has now avoided twice; declaring the limit is the banked practice, and it fires here.


Part II — The six items, each ask checked against the substrate

Read today: wake-digest.py, governance-drift-check.py, ~/REVIEWED.md, ~/PENDING.md, ~/.claude/skills/jurist-package/SKILL.md. Every ask in all six items is unbuilt. Nothing in this cluster has been quietly satisfied since filing, and the items' descriptions of the mechanisms match the code as it stands.

Item Ask Substrate status, verified 2026-08-27
110 (2026-08-06) (b) never write a bare register number convention; unadopted in doctrine
(c) backfill REVIEWED headings NOT done — REVIEWED-78/-81/-82 headers still carry no — PENDING-N —. ⚠ And see Part III.
(d) read the body, not only the heading NOT built — ruled_pendings matches the header only
145 (2026-08-17) (i)–(iv) record-level disposition NOT built — ruled is a set of id strings; nothing compares dates; nothing distinguishes parent from addenda
146 (2026-08-17) (i)–(iii) convention + block detection NOT built — unit is the id parsed from the header. Retroactive split NOT done: PENDING-147…165 contain no item carrying ADDENDUM 4's Move 1/Move 2, whose Awaiting: line is still live and still invisible
108 (2026-08-06) (b) package-without-ruling detector NOT built — no package/ruling pairing check exists in the drift-check
(c) file-before-act ordering NOT built — the skill prescribes file-ruling-then-Addendum, not ruling-before-authorized-act
144 (2026-08-17) (iii) disclose the gap in the clean line NOT built — the printed line reads CLAUDE.md clean (N/N controls passed, M paths verified) with no scope disclosure
(ii) checkable claims carry their check authoring practice; unadopted
139 (2026-08-14) (a)/(b) widen RE_HEAD, guard RE_BUILT NOT built — both regexes verbatim as filed

One correction to the record, made here rather than left standing. PENDING-144's "confirmed occupant" — the ruled_pendings docstring asserting the opposite of the substrate — was corrected on 2026-08-17 and the docstring now carries the dated correction in place. The item already states this in the past tense and needs no amendment; it is noted so the jurist does not rule on a live defect that is in fact a discharged one. 144's class remains entirely open; only its one exhibit is historical.


Part III — The rework is not hypothetical: one instance is already in the record

The jurist's reason for the block — "ruling them in filing order guarantees rework" — can be demonstrated rather than argued, and the demonstration is the strongest single item in this package.

PENDING-110 (2026-08-06) recommends (b) + (c) + (d). Its option (c) reads:

(c) Backfill the headings. Bounded to those where the number names a different item, plus the three the digest miscounts

REVIEWED-122 condition 5 (2026-08-17) — eleven days later — rules on those exact three:

REVIEWED-78, -81 and -82 are placed rulings and are not to be edited to satisfy the current parser. Fixing the record to please the instrument inverts which of the two is authoritative. […] that is a separate steward act and is not authorized here.

⚠ So ruling PENDING-110 as filed would authorize an act a later placed ruling has already declined, and declined on a stated principle rather than on cost. Nothing marks this in PENDING-110; the item predates the ruling and has no way to know. A reader taking the items in filing order — which is the order the open list presents them in, and the order the digest printed them in this morning — walks into it.

This is also the second-order form of the defect the cluster is about. The conflict is invisible because there is no mechanism that relates an option in an open item to a condition in a placed ruling; both are prose. The block ordering the jurist proposes is a human remedy for exactly the gap the items propose mechanical remedies for, and it worked — which is one datum in favour of the differently-positioned-readers doctrine and none at all in favour of relying on it.


Part IV — The root, and the one item it does not reach

Five of the six are one defect. PENDING-139 states it in its own body, and it is the clearest statement in the cluster:

⚠ THE COMMON CAUSE IS THE TECHNIQUE, NOT THE TWO REGEXES. Both defects are substring-matching over prose used as a status signal […] The class is that a status is being inferred from narrative text that was never constrained to carry one, and it will keep producing defects of this shape in either direction — false clean lines and false alarms — for as long as the status has no declared field of its own. Whether that is worth fixing properly (a declared status key per item, matched exactly) or whether marker-matching is good enough for a detection-only instrument is the real question, and it is the steward's.

Mapped across the cluster, each site is the same technique failing on a different field:

Item The prose read as a status The failure it produces
110 a bare integer, read as an identifier the number names two items; ~140 code citations inherit it
145 a ruling's header id, read as a disposition one ruling claims the number for all time; later addenda suppressed on arrival
146 a header id, read as the unit of decision five blocks collapse to one row; four live asks invisible while the verdict is correct
139 ### read as not-a-heading; NOT BUILT read as built a clean line over a halved population; a negation read as an assertion
144 a docstring's prose, read as provenance a false claim about the register, inside the instrument that reports the register

⚠ PENDING-108 IS NOT THIS DEFECT, AND SAYING SO IS THE POINT. 108 is about an artifact that was never created — a ruling document nobody wrote. No parser failure produces that, and no declared field prevents it. Grouping it under the root would be the tidier package and the falser one. It belongs in this sitting for a narrower and weaker reason, stated plainly so the jurist can reject it: its proposed remedy (b) is filename-stem matching — the same technique the root question is about, one directory along. If the steward rules for declared fields, 108(b) should be built as a declared pairing rather than a stem match; if the steward rules that marker-matching is adequate for detection-only instruments, 108(b) is unaffected. That is a real dependency, but it is a dependency of 108's implementation shape, not of its merits, and 108 could be ruled separately without rework. It is offered as a convenience of the sitting, and the jurist should feel free to sever it.


Part V — The artifact this whole block gates, and it is unbuilt

REVIEWED-122's If AUTHORIZED: opens: "Draft and commit the hand-read answer key first, with its hash recorded."

Verified 2026-08-27: the key does not exist. No file matching *answer-key* or *disposition-key* anywhere in ~/dotfiles; no commit touching such a path since 2026-08-17. PENDING-146 recorded it as "not yet drafted" on 2026-08-17; that is still true ten days later.

Both 145 and 146 say, independently, that the key cannot be correctly written until they are ruled. PENDING-146:

If "item" resolves to id, the key reproduces the exact unit that caused this defect and grades green. The key MUST be keyed on ## blocks, and must record, per block, whether it carries a live **Awaiting:** and at what tag. Condition 1 as ruled was one word away from certifying this defect as correct.

And PENDING-145: "This must be inside PENDING-142's pre-registered key, not bolted on after."

So the dependency chain is closed and it runs one way only:

  the unit question  (145 + 146, and 110's identifier question beneath them)
        ↓  must be settled before
  the hand-read answer key  (REVIEWED-122 condition 1 — unbuilt, ordered "first")
        ↓  which must exist before
  the PENDING-142 implementation  (REVIEWED-122's authorized build — blocked)

This is REVIEWED-105 §4's precedent exactly, and the jurist's citation of it is apt: "a validator that catches a malformed line should exist before the file grows. In the other order, the first thing to test the new declarations is the declarations themselves." Here the file has already grown — 114 blocks — and the key written today against the wrong unit would certify the defect and pass by construction, which is the one outcome condition 1 was written to prevent.


Part VI — Consequence-trace

Ratified clause End-state if the block is ruled together Verdict
## REVIEWED-[N] — [Matches PENDING-N title] The template still says title, not number. A declared-field ruling would supersede it; a marker-matching ruling leaves it intact and 110(b) becomes doctrine. Either outcome is consistent; the template must be amended under a declared-field ruling or it will re-teach the collision. [ESCALATE] — steward's hand.
REVIEWED-122 cond. 1 (key before implementation) Unaffected in force; satisfiable for the first time, because the unit it must be keyed on becomes decided. Preserved and unblocked
REVIEWED-122 cond. 5 (placed records not edited) 110(c) is withdrawn or re-posed rather than authorized. Conflict resolved rather than inherited
REVIEWED-122 cond. 10 (ruling cannot verify the census) Holds. This package's Part I is executor testimony from a script the jurist cannot run — and it declares the two columns it cannot total. Preserved; the disclosure is the compliance
REVIEWED-122 cond. 11 (script claims filed separately) PENDING-144 is that filing, ruled in the same sitting as its parent's siblings. Satisfied
Constraint #4 (report own limits) 144(iii) makes the drift-check's clean line state its subject; 139(b) makes the register check report forms it cannot classify. Both strengthen it

One level deeper — which way does the inference run. Under a declared-field ruling, the inference inverts: today the absence of a marker means "no status found, assume open"; with a declared field the absence of the field means "malformed, report cannot-assess". That is a strictly better failure mode but it re-grades every existing block as malformed on day one — 114 of them. Any declared-field ruling must therefore say what happens to the existing corpus: bulk-annotate, or treat absence as a legacy default. Neither 145 nor 146 addresses this, and it is surfaced here rather than discovered during the build (Gate question Q4).

And is any class named here actually two kinds? Yes — one. "Suppressed block carrying a live Awaiting:" (Part I, 52 candidates) is two kinds with opposite dispositions: blocks whose ask is genuinely live, and blocks whose Awaiting: line is stale prose left after the ask was discharged. They require opposite remedies — the first needs unhiding, the second needs the line retired. A single "unhide the suppressed" fix would surface both and mistake the second for recovered work.


Part VII — Change-class and landing

  • 110(b), 146's convention — a change to authoring doctrine in ~/CLAUDE.md §Steward-Jurist Interface. [ESCALATE], steward's hand. The executor does not touch that file.
  • 110(c) — an edit to placed rulings. Steward's act only, and per REVIEWED-122 cond. 5 not authorized today; re-posed here as Q2 rather than assumed withdrawn.
  • 110(d), 139(a)/(b), 144(iii), 145, 146's detection — executor builds against wake-digest.py and governance-drift-check.py. Both are governance instruments, so none proceeds without authorization; detection-only measurement already ran and needed none.
  • 108(b)/(c) — a new drift-check detector plus an ordering clause in a skill. Executor, on authorization.
  • The answer key — hand-read, executor-authored, committed with its hash recorded before any implementation, per REVIEWED-122 cond. 1 which is already in force and needs no new authorization. It needs only the unit ruled.

No re-verify storm. Nothing here changes what any chamber or engine gate accepts; the subject is the governance registers and the two scripts that read them.


Part VIII — What this package does NOT do

  • Runs no code that mutates anything. The Part I measurement is read-only and its source is reproduced above; it wrote nothing.
  • Does not rule. Every disposition below is a lean, not a decision.
  • Does not correct any item. The one item whose exhibit is historical (144) is annotated in Part II, not edited.
  • Does not draft the answer key. The key must not be written before the unit is ruled — that is Part V's entire argument, and drafting it here would commit the error the package reports.
  • Does not touch ~/CLAUDE.md, ~/REVIEWED.md, or any placed ruling.
  • Does not total the two candidate columns in Part I, and declines to.
  • Does not address the 270 uncounted census candidates of PENDING-164. That backlog is untouched by this block and is not advanced by ruling it.

Part IX — Gate questions

Q1 — The root question, and it is the block's hinge. Declared status fields per item (rules:, status:, unit: — matched exactly), or better marker-matching over prose? Executor's lean: declared fields, for the closure signal only — not a general schema. The evidence is that marker-matching has now failed in both directions at five sites, and each fix widened a pattern that the next unanticipated form escaped. But the lean is weak on cost: a declared field re-grades 114 existing blocks (Part VI), and 139 itself asks whether marker-matching is "good enough for a detection-only instrument" — which the digest arguably is.

Q2 — 110(c) against REVIEWED-122 condition 5. Is (c) withdrawn, or re-posed as the "separate steward act" condition 5 contemplates? Executor's lean: withdrawn as filed. Under Q1-as- declared-fields it becomes unnecessary; under Q1-as-marker-matching it remains the record-edit condition 5 warns against. It has no reading on which it is the right move.

Q3 — Is PENDING-108 severed? Executor's lean: rule it in the sitting, but on its own merits, and sever it if that is cleaner. Part IV states the case against grouping it.

Q4 — The corpus transition, which no item addresses. Under declared fields, what is the disposition of the 114 existing blocks that carry no field? Executor's lean: absence means cannot-assess, never open and never closed — Constraint #4 and REVIEWED-106's three-valued precedent. Bulk-annotation is a second, separately-ruled act.

Q5 — Ordering within the block. The relayed order is 110 → 145 → 146 → 108 → 144 → 139. Executor's lean, offered against the grain: read 139 first. It is last in the relayed order and it is the only item that states the root question the other four turn on; taking it last means four rulings are made before the question they presuppose is put. The relayed order is right about dependency among the unit items; 139 is not one of them, it is their diagnosis. This is a lean about reading order, not about ruling order, and the jurist may well have meant exactly that.

Q6 — The key's own falsifier. REVIEWED-122 cond. 1 requires that key-vs-implementation disagreements be reported as findings, never reconciled. Should the key additionally be required to record, per block, which of the two kinds a live Awaiting: is (Part VI's split — genuinely live vs. stale prose)? Executor's lean: yes. Without it the acceptance check cannot distinguish recovered work from resurfaced noise, and 52 candidates is too many to eyeball twice.


Filed by the executor 2026-08-27. Companion entries: ~/PENDING.md PENDING-108, -110, -139, -144, -145, -146. No code changed, no register mutated, no ruling drafted. The Part I measurement script is preserved beside this package as record-keeping-cluster-measurement-2026-08-27.py — read-only, controls pre-specified in source, exits non-zero and refuses its own numbers if any control fails.


Addendum — design-gate ruling received and applied (2026-08-27)

Parts I–IX above are preserved as the text the jurist ruled on. This Addendum layers disposition; it does not rewrite history. The one exception is the frontmatter audience: line, corrected in place because condition 1 required it before the sitting and a false premise left standing in a document written for quotation is the defect itself. The correction is marked and records what it replaced.

Verdict received: NOT PASSED AS FILED. The ruling is filed verbatim and separately at record-keeping-cluster-JURIST-RULING-2026-08-27.md, before any act taken under it — the ordering PENDING-108 (c) proposes and the executor had not previously adopted.

The ruling in force

  • The block is real; the sitting should happen. Ruling order 139 → 145 → 146 → 110 → 144, with 108 severed and 143 in the picture as evidence, not as an item to rule.
  • Q1 reframed and answered: the two scripts are not one instrument. Declared closure field for the wake digest (a primary governance surface, the last place to infer status from prose); 139(b) for the drift-check, marker-matching included, because it is a detector. This dissolves most of the 114-block transition cost that made the executor's lean weak.
  • Q4 was already largely ruled by REVIEWED-122 condition 4 (the third value is enumerated, never counted).
  • Q6 yes, and partly already in force.

Corrections that supersede the drafted design

  1. The premise was false, and it was load-bearing. The jurist has bounded read access and used it, reading eight items verbatim. The package's relay architecture was chosen on a stated ground that does not hold. Corrected in the frontmatter; the Grounding section stays, relabelled a convenience.
  2. Membership was set by relay, not by the root. The package argued a root and never ran it back across the register. PENDING-143 belongs in the picture — it states 145's mechanism in the same words on a different item, and is the evidence that the defect has already forced a workaround into the register rather than being prospective. PENDING-124 and -128 are steward reads owed since 2026-08-17 and were absent.
  3. Part V's blocking argument does not survive, and Part VIII's refusal to draft inverted the doctrine the census was run under. A hand-read key cannot pass by construction; the risk is to its scope, and 146 already supplies the remedy as a requirement. A block-keyed key is strictly finer and collapses to an id-keyed one under the opposite ruling; the reverse is false. The key is therefore safe to draft under every outcome of Q1 and Q4 and is being drafted now.
  4. Part V buried the ungated work. The answer key is the gated artifact; the citation-safety fence is the ungated one and has been ungated for seventeen days. Move 2 is bounded, closable in one sitting, and needs no ruling from either party.
  5. Q2's lean over-read condition 5. 110(c) has two legs; condition 5 reaches only the 78/81/82 leg. The REVIEWED-86 / PENDING-86 collision is untouched by it and is re-posed rather than withdrawn.
  6. Q3's severance stands on better grounds than the package gave. A filename stem is a structured token, not narrative prose; its failure mode is mismatch, not misreading. 108(b) is closer to the declared-field answer applied to another substrate, which argues for Q1's lean rather than for grouping.
  7. The If AUTHORIZED: quotation was truncated mid-clause without an ellipsis. The dropped remainder carries two obligations bearing on this package, and the dependency chain is one link short: unit → key → verb-enumeration ruling → implementation.
  8. The 78/81/82 "verified subset" is three items of two kinds — PENDING-161 separates 82 out as the one confirmed self-declared-closure case. The package committed, on its own verified subset, the two-kinds-under-one-label error it correctly flagged for the 52.
  9. 144's exhibit is not only historical. A live instance exists: the drift-check's clean line is correct and silent about a false substrate claim in placed ruling REVIEWED-129, because that claim is outside its one file.

Part I's instrument — three defects conceded, and they are not cosmetic

  • The docstring overclaimed. It said the script reproduces the digest's parser exactly; the ruled regex is reproduced, but open_items() was substituted with "every line beginning with ## ". That substitution produces 114 — the figure Part VI then used to size the transition cost. The half that was reproduced is not the half that carried the load.
  • All four controls are must-detect. PENDING-139 — an item inside this very package — requires controls in both directions, and there is no must-not-flag control. Control 4 is a positive control on the parser's own definition of its unit and passes trivially.
  • Consequently 114 and 80 are floors, not counts, and the package did not say so. Both are blind to ### forms that 139(A) has measured to exist.
  • decision_of can borrow a neighbour's verdict under re.S when an entry has no **Decision:** line, and the printed column inherits it uncontrolled.
  • One interpretive claim was layered onto a script number without separation — "most of the 34 are in PENDING-archive.md". The script never reads that file, and the claim was checkable.

What proceeds now

  1. ✅ DONE — the answer key, at block granularity, drafted and committed BEFORE any implementation. claude/governance/PENDING-142-answer-key-2026-08-27.md, pre-registration commit 3a33666 (3a33666730380e5b51c694e83ebfbc723b35c407), committed alone so the hash is unambiguous. REVIEWED-122 condition 1's "hash recorded" is satisfied by this line and by the PENDING-142 note. 120 blocks over 106 distinct ids — 14 invisible as units. ⚠ Its declared limit: 5 of 120 rows are hand-read in the full sense; the rest are hand-assigned from a dispositive field, and the remainder is recorded as owed.
  2. Move 2 — dispose the 25 line-addressable blockquote runs. Ungated, one sitting.
  3. The frontmatter correction: done.
  4. PENDING-143, -124, -128 entered into the picture: done, in this Addendum.
  5. Part I's instrument: defects recorded here rather than the script quietly amended, so the ruled text and its rebuttal stand together.

⚠ The loose end the jurist reported and declined to explain is resolved, and it was resolvable only from the executor's side. See PENDING-104 — ADDENDUM 1. It is not a defect in either governance tool. The register was being written by the executor while the jurist read it, and the 23-line delta is exactly the length of a note inserted into PENDING.md at line ~763 earlier that day. The jurist's "agreeing" trio (3421 / 3732 / 3764) is 23 lower than the live file; the "disagreeing" pairs straddle the write. The executor's own filing activity silently corrupted the jurist's read of the cluster about filing, and the corruption presented as authoritative line numbers.