# Finding register — closed findings

The prose for findings that are **withdrawn** or **applied**. Split out of
[`FindingRegister.md`](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 5–6 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**, 2–6 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-game** — *does 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

**U1–U10 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 U1–U10**, 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.

**U1–U10 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 1–4 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.