CB-WP-0026: collect the rulings -- ten answers that arrived and were never applied
Some checks failed
ci / check (push) Failing after 3s

ground-game ruled all ten U-items on 2026-08-03, every one CONFIRMED as
the default clay-borg simulates, and confirmed five of six provisional
scenarios. clay-borg never collected the answers: CB-RES-0007 reported "0
of 10 ruled" the same day, and CB-WP-0022 built the finding register two
days later still recording them as `reported`. make design's first run is
what noticed -- not a human, not the adversarial review that found four
other things.

That is the unread-inbox failure running in the opposite direction, and it
appears nowhere in the declaration, survey, ADR or spec of the pass that
was built entirely around the forward version. It is arguably worse: an
unread message is visible as silence, while a collected-but-unapplied
ruling looks exactly like work in progress.

Ten rulings quoted into §Underdetermined (the three conditional ones
verbatim -- U1's designer note, U2's End-only trigger, U8's
consume-only-if-it-cancels). Five provisional flags lifted, replaced by
ruled/ruled_by/ruled_note so the flag went and the provenance stayed.
Register queue 9 -> 0.

T02's control came back clean: make sim is 26 passed, 59 rules covered,
nothing red. Had a scenario gone red it would have meant we described our
own behaviour incorrectly to ground-game.

I wrote two U-item mappings and both were wrong. gr-a04 -> U1 (it asserts
consent is REQUIRED; U1 asks WHEN the target accepts) and gr-d05 -> U5 (it
exercises the UNREJECTED Reverse; U5 is the rejected one). Both plausible
from covers:, neither survived reading the description. Third and fourth
instance of this defect; the first two reached ground-game. So encodes_u_item
is now a declaration and design.py asserts the file names what it claims --
and that check's own first version grepped for mentions and went red when
two files recorded why they do NOT encode U1 and U5. A mention is not a
claim, which is exactly the looseness that let "six of the ten have
provisional scenarios" stand.

Two positive controls went red for the best possible reason, both broken
the same way -- asserting against live repo data instead of constructing
their condition. rule-coverage.py required at least one provisional item
to EXIST; it now builds a fixture and reports the live count as a
diagnostic, because there is no number of provisional items this project
should have. design-baseline.py pinned "2 of 6" while recomputing one row
from a live glob, so the dated snapshot was never a snapshot; frozen to
its 2026-08-03 list and unwired from self-tests, since per ADR-0012 D8 it
is no longer a reporting tool.

ScenarioFile is deny_unknown_fields and refused the four new fields until
declared -- correct: a corpus accepting unknown metadata would let a typo'd
encodes_u_iem sit there claiming nothing.

DEVIATION: ADR-0012 D2 said "no new file". GroundRules.md crossed the
loadability limit, so the register moved to specs/FindingRegister.md. D2's
substance holds -- one register, same machinery, nothing competing -- but
the literal instruction did not, and it resolves an awkwardness D2 named
itself.

make all: exit 0. loop-lint clean.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
tegwick 2026-08-05 16:13:37 +02:00
parent b1f4a85a4a
commit 6be9fbc9af
15 changed files with 797 additions and 138 deletions

View file

@ -154,11 +154,39 @@ def self_test():
check("code-id matcher finds none in unmarked source",
parse_code_ids("fn f() { let x = 1; }") == set())
# T08: every provisional scenario must carry an owner and a date.
import glob as _g
prov = provisional_items(sorted(_g.glob("scenarios/ground/*.yaml")))
check("every provisional item has an owner and a raised date",
bool(prov) and all(o and r for _, o, r in prov),
f"{len(prov)} provisional item(s)")
#
# **Tested against a fixture, not against the repo.** This control used
# to read `scenarios/ground/*.yaml` and require `bool(prov)` — a guard
# against a vacuous pass, which is the right instinct, but it made the
# control depend on the repo *having* provisional items. CB-WP-0026
# lifted the last five (ground-game ruled them all on 2026-08-03) and
# the control went red for the best possible reason: nothing is
# provisional any more.
#
# A positive control must construct the condition it tests. The live
# count is a diagnostic below, not a pass criterion — there is no
# number of provisional items this project *should* have.
import glob as _g, tempfile as _tf, os as _os
with _tf.TemporaryDirectory() as _d:
good = _os.path.join(_d, "good.yaml")
bad = _os.path.join(_d, "bad.yaml")
open(good, "w").write("scenario: x\nprovisional: true\n"
"provisional_owner: ground-game\n"
"provisional_raised: 2026-07-31\n")
open(bad, "w").write("scenario: y\nprovisional: true\n")
g = provisional_items([good])
b = provisional_items([bad])
check("a provisional item with an owner and a date passes",
len(g) == 1 and all(o and r for _, o, r in g))
check("a provisional item MISSING its owner/date is caught",
len(b) == 1 and not all(o and r for _, o, r in b),
"without this the check passes on anything it can parse")
live = provisional_items(sorted(_g.glob("scenarios/ground/*.yaml")))
check("every LIVE provisional item has an owner and a raised date",
all(o and r for _, o, r in live),
f"{len(live)} provisional item(s)"
+ (" — none; all ruled 2026-08-03 (CB-WP-0026)" if not live else ""))
# --- CB-WP-0005 T01: the kernel denominator ---
# The control the old arm was fixed for, replicated. A pattern that