clay-borg/specs/FindingRegister-closed.md
tegwick 704b99975b
Some checks failed
ci / check (push) Failing after 4s
Apply ground-game's rulings: mastery in points, four boards, and a
vendor tool that covers what the gate checks

They ruled on all seven items the same day. Two were actionable here.

F28 RULED: points. Modes.csv MODE_COOP clarified upstream to say
"penalties apply to points, not card count"; mastery is now
total - blame - denied. A recorded scenario went red on it --
gr-e02-shared-ground pinned 0 (2 claimed CARDS - 1 - 1) and now expects
2 (4 POINTS - 1 - 1). The number moved because the rule was decided, not
because the engine drifted, and the scenario records both rulings; its
schema has no field for a second one, so both live in ruled_note with
`ruled` carrying the LATEST date.

F29 RULED not-intended and APPLIED upstream: SCN_02's suits re-tuned the
same day. The characterisation test is how we found out -- it pinned the
duplication, went red on the re-tune, and that red WAS the notification.
It now asserts every pair distinct, the stronger statement the
duplication had made unavailable. SCN_02 re-measures at 73 at 2p, not
67: its own board now.

F26/F30 ruled and recorded. F30's ruling incidentally confirms our
reading -- they name priority-2's suit as the first lever, which is the
difference we identified without having measured causation.

vendor-editions grew twice, both times because it covered less than the
gate it exists to satisfy:

  - It refused to touch ground-darvo-r0/ on the reasoning that the
    baseline is "a separate record". That was wrong within the hour:
    ground-game clarified Modes.csv and `make vendor` reported a clean
    sync while edition-check went red. A sync tool that covers less than
    its check reports success into a red gate.
  - Its two-block rewrite DETECTED which fence held which set and
    preserved the arrangement -- faithfully preserving a swap an earlier
    write had introduced, leaving each fence under a heading describing
    the other. edition-check reads every sha256 line flat and passed
    throughout: a document can be self-consistently wrong and green.
    Order is now asserted, with a control that goes red on a swap.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-09 00:15:14 +02:00

14 KiB
Raw Blame History

Finding register — closed findings

The prose for findings that are withdrawn or applied. Split out of FindingRegister.md when it crossed the ~400-line loadability limit (CB-WP-0049).

The register itself is unchanged. Every row still lives in the machine-readable block there, and make design still reads exactly one file. What moved is the history — ADR-0012 D5's reasoning applies: a default view that mixes open and closed loses the queue property, and the same is true of a file.

A closed finding is not deleted, because the account of why something was withdrawn is often the more useful half.

  • F11 — SOLVE offered where it cannot act. Offered on a face-down Problem, or with no matching suit in hand; inert every time. Ruled GROUND-WP-0002 T02, implemented CB-WP-0023 as GR-P05. applied — the rule changed, not just the annotation. The case we reported was not the case that fired: validate already rejected face-down, and the maintainer's three inert SOLVEs were the hand case.

  • F12 — GR-A13 "wasted SOLVE" on an already-claimed Problem. A scenario had to pick a default and did. note: no artifact isolates the degenerate line, so under GameDesign §3.1 it may not be reported until one exists.

  • F13 — GR-E01 vs GR-S01, withdrawn 2026-08-05. Raised as "4/6/9 against 5/7/9, no dataset reconciles them." 2da19a4 measured 6/9/12 against 5/7/9 and the scenario was renamed -unreachable--reachable-. Its reproduction is green, which under GameDesign §1.3 is the alarm that forced the resolution. Withdrawn rather than deleted, and the withdrawal is reported (ADR-0012 D5).

  • F16 — "the game is too easy at 56 seats", withdrawn the day it was raised. Claimed from GreedyPolicy winning 200/200 at those seat counts. A FirstLegal policy scores 0% on the identical deals, and at two seats it beats greedy — two unsophisticated agents span the whole range, so the measurement was about the policy. Caught by the CB-WP-0025 adversarial review (C4) before transmission; it would have been the fifth wrong premise sent to ground-game and the worst, since GROUND-WP-0005 is blocked on exactly this number. The withdrawal was reported (ADR-0012 D5). Its reproduction is difficulty.rs, whose policy panel is plural because of this finding.

  • F23 — a false claim propagated five times by citation instead of measurement. CB-EV-0024 §6 stated that chaos window 2 produced zero overrides and that its retirement condition was untestable. CB-EV-0025, CB-EV-0026, CB-EV-0027 and CB-WP-0029 each repeated it, citing the one before.

    It was false. Declaration 3 (CB-WP-0020) rolled d8 = 8 and overrode — and CB-WP-0020 recorded it correctly at the time, in those words: "the first override at d8… It changed nothing… One." Counting the workplans takes one command.

    The subject makes it worse. Three of those four files were arguing that this project's defect is claims asserted without their reproduction — while carrying one. facts-check catches a copied number that disagrees with its source; nothing catches a number with no source, asserted once and cited thereafter.

    applied — ADR-0017 corrects it, and each of the four files carries an in-place correction rather than a silent edit (ADR-0012 D5). The general defect is not fixed: it is the same family as the five wrong-subject instances, and still has no control.

  • F22 — does the component supply bind the game? Asked, measured, and withdrawn. Tokens.csv gives every component a quantity — 6 Protection, 5 Denied, 12 relation links — and no numbered rule mentions a supply, so the engine could in principle mint a seventh Protection token (saturating_add, no bound, lib.rs:986). Measured over 750 games, 26 seats, greedy and random: Protection reaches 1 per seat and 2 on the table; Denied 3 of 5; links exactly 12 of 12, never over, because GR-L01's two-slot rule is the twelve-token supply written twice. Focus/Blame: 0 conflicts. Withdrawn — nothing to report. Registered as a stated negative because a survey that finds nothing and leaves no trace cannot be told from one that was never run. The check ships as a standing control (ADR-0016 D3): if play ever does exceed a quantity, that is a finding for ground-gamedoes the box bound the game, or do the rules? — and not a bound for the engine to invent.

  • F21 — dragging did not work until after the first note was saved. Reported 2026-08-06: "I could not drag and drop at the beginning but after I added the first comment it worked." note, and I could not reproduce it. The gesture logic is correct against the served page (the JS harness posts properly), the ghost carries pointer-events:none so it cannot intercept the drop, and the markup is identical before and after the note — the 303 re-renders the same page from the same state. Candidates, none confirmed: a <details> toggle inside an action card shifting the layout mid-drag; a first-load timing difference; or a browser-level pointer capture. Reproducing it needs a browser, which no test here has — the same gap F19 named. Recorded rather than guessed at.

  • F20 — a click target wearing a drag affordance made the ending controls look dead. play again, end session, pass and the move buttons carried .pick, which is cursor:grab. A grab cursor invites a drag, and a drag released over nothing posts nothing — so the button did nothing and appeared broken. Reported as two separate observations ("the button shows a hand to pick up that it probably shouldn't" and "I can't start another game or stop the server") which are one defect. applied: click targets now carry .tap. This extends CB-WP-0017's rule — interactive and inert must not look identical — to click and drag must not look identical either.

  • F19 — the engine shipped a table nobody could play on, and every gate was green. CB-WP-0028's overhead view was 620px tall, so the action cards sat a screen below the Problems; dragging between them was physically impossible. Seats were drawn inside the table, and the table drop target was a card among the buttons rather than the drawn surface. make all passed throughout, because every test asserted the DOM was correct — which it was. The JS harness even posts a correct gesture against a page a human cannot drag on. degenerate: the feature fires and collapses play. applied — fixed 2026-08-06, with height, seat-position and single-drop-zone proxies added. They are proxies. Nothing here lays out a browser, and the gap CB-EV-0026 named — that no gate measures whether a player can play — is unclosed.

  • F14 — GR-E03/GR-E04 never played to the end. Closed 2026-08-07, and the reason they were unplayed was ours. cb-play built every game with ScoringMode::SharedGround and passed an empty patch, so two of the three shipped modes were unreachable from the only way anyone plays. The mode was patchable in scenarios and not from the driver. --mode added; all three now play to the end and give different winners from identical play: shared → all four seats, common → P3 alone, coalitions → P1+P2. applied — 800 games per mode in the reproduction.

The register's first run found ten answers nobody had collected

U1U10 are ruled, not reported. GROUND-WP-0002 T05 answered all ten on 2026-08-03 — every one confirmed as the default clay-borg already simulates — and GROUND-WP-0002 T03 confirmed five of the six provisional scenarios, voiding gr-e01 as a rules gap. The workplan is finished.

CB-RES-0007 reported "0 of 10 ruled" and this register was built saying reported. Both were two days stale on the day they were written. The answers had arrived and nothing propagated them — the same failure as the unread inbox, in the opposite direction.

They are ruled, not applied, and the difference is work we owe. Per ADR-0012 D5, applied means the source changed and the provisional default was deleted. The rulings confirmed our defaults, so the rules did not move — but the scenarios still carry provisional: true for choices that are now settled. Lifting those flags and recording each ruling is what closes U1U10, and it is not done. make design shows them open until it is.

The U-item ↔ scenario mapping, measured twice

One U-item has a scenario that names it: U2. CB-RES-0007 asserted six of ten did.

CB-WP-0026 T03 tried to write the other mappings and produced two wrong ones before checking them:

claimed why it was withdrawn
gr-a04-bond-support → U1 it asserts consent is required; U1 asks when the target accepts. Different question.
gr-d05-darvo-reverse → U5 it exercises the unrejected REVERSE; U5 is the rejected one (GROUND—ND). Different stage.

Both were plausible from the covers: list and both were wrong on reading the description. That is the third and fourth instance of this exact defect — a link that looks right, asserted without checking what the artifact actually exercises — and the first two reached ground-game.

So a scenario now declares encodes_u_item explicitly or claims nothing. Nine U-items have no reproduction and are recorded as having none. They are applied because the ruling landed and the provisional flag came off, not because anything demonstrates them.

What the backfill measured, and what it contradicted

Only U2 names its U-item in a scenario. Measured, not estimated:

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." Five provisional scenarios exist and one cites the item it stands for. The other four may well encode U-item defaults — the mapping is simply not written down, so it is not checkable, and an uncheckable link is the defect this register exists to fix. The register records what is citable; the rest is debt, visible in make design.

No sixth kind was needed — the five kinds absorbed all four non-U findings. And the survey's "six provisional defaults" was not entered as a finding: C3 showed it double-counted GR-E01, and the provisional scenarios are reproductions for underdetermined items, not a finding of their own.

U1U10 are reported while lacking reproductions, which GameDesign §3.1 would now forbid. They were reported on 2026-07-30, before the rule existed. They are grandfathered rather than rewritten, and the debt is a reported metric with a target of zero.

  • F28 — SHARED GROUND's mastery rating counts cards where the mode card counts points. "All claimed Problem cards form one shared score. … For a mastery rating, subtract 1 for each Blame token still in play and 1 for each Denied Problem." The shared score is claimed value (total); mastery subtracts the same penalties from the claimed count. Both readings fit the sentence and they differ on every game where a 3-point Problem is claimed. Ours to report, theirs to rule.

    Sensitivity: vary only the point value of the claimed Problems and the gap moves with sum(value) - count. The two readings agree exactly when every claimed Problem is worth 1 — no Problem in the edition is — or when nothing is claimed, which is a loss. Everything else is held fixed: same board, same penalties, same threshold.

    RULED and APPLIED 2026-08-08. ground-game: "points." Modes.csv MODE_COOP clarified upstream to read "start from that shared point total and subtract 1 point for each Blame token still in play and 1 point for each Denied Problem (penalties apply to points, not card count)." The engine now computes total blame denied.

    A recorded scenario went red on it, which is the gate working: gr-e02-shared-ground pinned mastery 0 (2 claimed cards 1 1) and now expects 2 (4 points 1 1). The number moved because the rule was decided, not because the engine drifted, and the scenario says so.

  • F29 — SCN_01 and SCN_02 are the same board. Identical suit and value at every priority; every measured cell matches exactly at every seat band under both policies. Not called a defect — a reskin is a legitimate design choice — but "four scenarios" is three boards, and a study treating them as four independent samples double-counts one. inconsistent because two artifacts that present as distinct are not; the register does not have a kind for "intended duplication", and inventing one before ground-game rules would be answering for them.

    Sensitivity: none — this is an identity, not a measurement. It holds for every seed and every seat band by construction, and the test is a characterisation so a future divergence is a decision.

    RULED 2026-08-08: not an intended reskin. ground-game will re-tune SCN_02's suits and/or values under a content workplan. The characterisation test stays as-is until they do — when the decks diverge it goes red, which is exactly the notification we want.

    APPLIED 2026-08-08, upstream. SCN_02's suits were re-tuned the same day: priorities 14 are now Change / Clarify / Boundary / Repair against SCN_01's Clarify / Boundary / Repair / Change. Re-measured, it is its own board — 2p group success 73 where it read 67 as SCN_01's twin.

    The characterisation test is how we found out. It pinned the duplication, went red on the re-tune, and that red was the notification. It now asserts every pair distinct — the stronger statement the duplication had made unavailable.