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

---
id: CB-WP-0026
kind: product
title: "Collect the rulings: ten answers that arrived and were never applied"
status: done
state_hub_workstream_id: "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

```task
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

```task
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

```task
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

```task
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

```task
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](../evidence/CB-EV-0022-collect-the-rulings.md).

- **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.