clay-borg/workplans/CB-WP-0026-collect-the-rulings.md

id	kind	title	status	state_hub_workstream_id
CB-WP-0026	product	Collect the rulings: ten answers that arrived and were never applied	done	289bcc55-0c1b-4e10-a40b-cb7ecdab46be

Purpose

structural tier  S   (applies rulings inside an existing capability —
                      scenario data and a spec section, no new port, no
                      canonical interface, no dependency)
chaos            d8 = 6  → no override
declared tier    S

Declaration 9 of chaos window 2.

The register's first run found this, which is the only reason it exists

ground-game ruled all ten U-items on 2026-08-03 (GROUND-WP-0002 T05) and confirmed five of six provisional scenarios (T03). Every U-item was confirmed as the default clay-borg already simulates. The workplan is finished.

clay-borg never collected the answers. CB-RES-0007 reported "0 of 10 ruled" on 2026-08-03 — the same day — and CB-WP-0022 built the finding register two days later still recording them as reported. It took make design's first run to notice.

This is the unread-inbox failure running in the opposite direction. The whole design-instrument pass was shaped around we send findings and nobody reads them. The symmetric failure — they answer and we do not collect it — was not anticipated by the declaration, the survey, or the adversarial review.

Nothing here is a rules decision. Every ruling is already made. This is clay-borg applying them, which is the ruled → applied transition ADR-0012 D5 defines: the source changed and the provisional default was deleted.

Why the rulings being "confirm" makes this more subtle, not less

Every U-item was confirmed, so no kernel behaviour changes. It is tempting to conclude nothing needs doing.

That is wrong, and the register is what makes it visible: the scenarios still carry provisional: true for choices that are now settled. A provisional flag means we picked this and the owner has not ruled. After 2026-08-03 that statement is false in five files, and make coverage keeps ageing them toward a 30-day warning for a question that has been answered.

A flag that outlives its question is the same defect as a hash that outlives its content — ADR-0011's "a lie with a timestamp."

Task: record the rulings where the defaults live

id: CB-WP-0026-T01
status: done
priority: high
state_hub_task_id: "ef4defb1-5d89-4d33-b5c1-6d7f6a12fb6b"

specs/GroundRules.md §Underdetermined states ten defaults as "must be confirmed or corrected by ground-game." All ten now are. Each U-item gains its ruling and the date, from GROUND-WP-0002 T05.

Quote the ruling, do not paraphrase it. Three carry notes that are more than "confirm" and a paraphrase would lose them:

• U1 — the Bond formed by this Support still does not cancel DARVO (a printed designer note, and it is the interaction GR-L05 encodes);
• U2 — clamp on every application, but DARVO still arms only at End when at Stress 5 (GR-R08). The clamping rule and the trigger rule are separate, and conflating them is the obvious misreading;
• U8 — GROUND—OU applies first and Protection is consumed only if it actually cancels.

Controls:

• the §Underdetermined preamble no longer says the items await a ruling — it is the sentence that will otherwise be true-looking and wrong;
• U2, U6 and U8 are the ones ground-game flagged as changing play. Each must be checkable against the kernel behaviour it describes, or the record says a rule is implemented that may not be.

Done 2026-08-05. All ten rulings quoted into §Underdetermined, with the three conditional ones (U1's designer note, U2's End-only trigger, U8's consume-only-if-it-cancels) verbatim. The section heading and preamble no longer say the items await a ruling.

Task: lift the provisional flags the rulings settle

id: CB-WP-0026-T02
status: done
priority: high
state_hub_task_id: "ab08dc38-46c0-460e-8042-7600542d3908"

Five scenarios carry provisional: true with provisional_owner: ground-game: gr-a04-bond-support, gr-d01-darvo-trigger, gr-d05-darvo-reverse, gr-e02-shared-ground, gr-e04-coalitions. All five were confirmed on 2026-08-03. The flag comes off, and each records which ruling settled it.

Do not delete the provenance with the flag. CB-WP-0021 T03 is the precedent: gr-e01 was rewritten, not retired, because a reader needs to learn the question was answered rather than that a tag vanished.

Controls:

• make coverage reports 0 provisional items afterwards, and that is the measurable outcome of this task;
• make sim still passes — a confirmed default is the behaviour already implemented, so a red scenario here means the default was not what we told ground-game it was, which is a finding and must be raised, not patched;
• the ruling date survives in each file.

Done 2026-08-05. All five flags lifted; make coverage reports 0 provisional items. Each file gained ruled / ruled_by / ruled_note instead — the flag came off, the provenance did not.

The schema refused the new fields and was right to. ScenarioFile is deny_unknown_fields, so five scenarios failed to parse until ruled, ruled_by, ruled_note and encodes_u_item were declared. A scenario corpus that silently accepted unknown metadata would let a typo'd encodes_u_iem sit there claiming nothing.

T02's control held: make sim is 26 passed, 59 rules covered, with no scenario red. That is the answer to the serious version of this task — had one gone red, it would have meant we described our own behaviour incorrectly to ground-game, which would be a defect in our report rather than in their ruling.

Task: make the U-item ↔ scenario mapping checkable

id: CB-WP-0026-T03
status: done
priority: high
state_hub_task_id: "2a4b9ef4-707a-44d1-a61a-0d1abbb8a321"

Only U2 names its U-item in a scenario. Measured in CB-WP-0022 T05:

for u in U1..U10; do grep -lE "\b$u\b" scenarios/ground/*.yaml; done

CB-RES-0007 asserted "six of the ten already have provisional scenarios." Four probably do — but the link is not written down, so it is not checkable, and an uncheckable link asserted as a fact is the defect class that produced three wrong premises.

Each scenario that encodes a U-item default names it. Where no scenario covers a U-item, say so rather than inventing a mapping — that is the honest half, and guessing here would reproduce exactly the error being fixed.

Controls:

• a check that every U-item claiming a reproduction resolves to a file that names it — design.py's self-test already asserts the current state (cited == ["U2"]) and must be updated to the new truth, not deleted;
• the register's reproduction column matches the mapping, since a register that disagrees with the files is worse than none.

Done 2026-08-05, and it caught me writing the same defect a third and fourth time.

I wrote two mappings from the covers: lists — gr-a04 → U1, gr-d05 → U5 — and both are wrong on reading what the scenarios actually exercise:

claimed	why withdrawn
gr-a04 → U1	it asserts consent is required; U1 asks when the target accepts
gr-d05 → U5	it exercises the unrejected REVERSE; U5 is the rejected one (GROUND—ND)

Both were plausible from covers: and neither survived reading the description. The measurement stands: one U-item, U2. Nine have no reproduction and are recorded as having none.

encodes_u_item is now a declaration, and design.py asserts a scenario naming a U-item actually contains it. The check's first version was itself the loose proxy: it grepped for \bU<n>\b and went red when two files recorded why they do not encode U1 and U5. A mention is not a claim — and that is exactly the looseness that let "six of the ten have provisional scenarios" stand unchallenged.

Task: close the register, and see whether it closes

id: CB-WP-0026-T04
status: done
priority: high
state_hub_task_id: "335457ff-61b4-4991-a787-a7eec55ac899"

Move U1–U10 from ruled to applied and re-run make design.

The number to beat is open, lacking a reproduction: 9 → 0, and the queue emptying is the first evidence that ADR-0012 D5's lifecycle is real rather than drawn.

If it does not reach 0, do not adjust the metric. Whatever remains is either a U-item with no scenario (T03's honest half, which should then be a note, not a finding) or a state the lifecycle cannot express — and the second is a finding about ADR-0012 that belongs in evidence.

Controls:

• make design shows an empty queue for the U-items, with the log carrying all ten;
• make self-tests and make sim pass;
• the closure is checkable from the register alone — a reader should not need this workplan to see that ten findings closed on 2026-08-03 and were applied on 2026-08-05.

Done 2026-08-05. The queue is empty.

QUEUE (open findings)      (none)
open, lacking a reproduction   0   target 0
closed (log)                  12   [U1..U10, F11, F13]
with a resolving reproduction 3/12 = 25%

open, lacking a reproduction: 9 → 0 — the number this task named. It is the first evidence that ADR-0012 D5's lifecycle is real rather than drawn: findings entered a state, moved through it, and left the queue.

25% reproduced is not a failure and must not be read as one. Nine U-items closed by a ruling, and a ruling is not an artifact. The metric is now honest about a thing the survey's 33% concealed: most of our findings closed because someone answered them, not because anything demonstrated them.

Task: evidence

id: CB-WP-0026-T05
status: done
priority: medium
state_hub_task_id: "28197e69-1326-4181-b673-61b3a20fb720"

evidence/CB-EV-0022-*.md. Short — this is an S pass.

• How long the answers sat uncollected, and what noticed them. Two days, and the thing that noticed was the register's first run, not a human and not the review.
• Whether any confirmed default turned out not to match the kernel — T02's control. A red scenario here would mean we described our own behaviour incorrectly to ground-game, which would be a fourth premise defect and the most serious kind, since it was our behaviour.
• What the mapping gap really was: whether the four unlinked scenarios encode U-item defaults at all, or whether CB-RES-0007's "six of ten" was simply wrong.
• Whether the queue reached 0, and if not, what the lifecycle could not express.
• Quote CB-WP-0022's cost by re-running the instrument — and note that CB-EV-0019 §4 found this chain snaps at roughly four passes, so if the instrument aborts, that is the second instance and the rule needs its bound.

Done 2026-08-05. CB-EV-0022.

• Two days uncollected, and the register's first run is what noticed — not a human, not the adversarial review that found four other things.
• No confirmed default failed to match the kernel: make sim 26 passed, 59 rules covered, nothing red. The serious version of this task came back clean.
• The mapping gap was not under-documentation, it was error. At least two of the four unlinked scenarios do not encode the U-items the survey implied, and I wrote both wrong mappings before checking them.
• The queue reached 0. applied conflates confirmed with overturned, which is the lifecycle gap this pass found and did not fix.
• The cost chain held this time — CB-WP-0022 is one pass back and still in the window. The bound CB-EV-0019 asked for is still owed.

A gate went red for the best possible reason. rule-coverage.py's positive control required bool(prov) — at least one provisional item to exist. Lifting the last five turned it red. The guard was the right instinct (a vacuous pass is worthless) wired the wrong way: it bound a control to live repo data. It now builds its own fixture, asserts the missing-owner case is caught, and reports the live count as a diagnostic — because there is no number of provisional items this project should have.