Some checks failed
ci / check (push) Failing after 4s
Five remarks from the maintainer's test games, checked against the code before being written down — two had already reached ground-game on wrong premises, so a claim now names the line that makes it true. Three of the five turned out to be data the projection already carries, drawn as text: solution_deck_len, solution_discard, and OutcomeView's personal/mastery/winners. One control (`close — I have read this`) is labelled as a reading but shuts the server down, and leaves a live-looking page pointing at a dead port. One number does not exist at all: table.rs loops run_game and keeps only the last summary. CB-WP-0024 (S, chaos d8=6, declaration 7 of window 2) — the piles and the other seats' plays as objects on the table, the ending control saying what it does, and a tally that survives "play again". CB-WP-0025 (L, chaos d8=6, declaration 8) — "could we have won" and "how hard is this" are the same search asked twice. Tier L because the information boundary is the whole design problem: a solver reading GroundState sees the deck the rules hide, and would tell the maintainer he could have won by playing a card he had no way to know was there. Also unblocks GROUND-WP-0005, active with both tasks waiting on a measured difficulty baseline. Also: CB-WP-0022 T07's evidence file moves to CB-EV-0021 — CB-WP-0023 shipped CB-EV-0020 first. loop-lint: no findings. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
306 lines
12 KiB
Markdown
306 lines
12 KiB
Markdown
---
|
||
id: CB-WP-0022
|
||
kind: product
|
||
title: "The design instrument: findings about the game, with their reproductions"
|
||
status: active
|
||
state_hub_workstream_id: "fda16340-0049-4acf-884b-a5cfdbde47c0"
|
||
---
|
||
|
||
# Purpose
|
||
|
||
```
|
||
structural tier L (named a high-leverage pass by the maintainer, and it
|
||
amends INTENT — clay-borg gains a stated aspect)
|
||
chaos d8 = 6 → no override
|
||
declared tier L
|
||
```
|
||
|
||
Declaration 5 of chaos window 2. Tier L: separate survey, **adversarial
|
||
review**, ADR, then spec, then code.
|
||
|
||
## The insight, in the maintainer's words
|
||
|
||
> *"We should consider ourselves testing the game and document
|
||
> inconsistencies to report them back to the ground-game repo, so that the
|
||
> game designer can improve the rules accordingly… We should have the
|
||
> rigorous game simulation engine and a meta scope to capture notes about
|
||
> game design flaws, questions, results and protocols about trial games…
|
||
> This will provide clay-borg an additional aspect as a valuable game
|
||
> design tool."*
|
||
|
||
**This is already happening and has no home.** In five passes the engine
|
||
has produced, as a by-product of being rigorous:
|
||
|
||
| finding | how it surfaced |
|
||
|---|---|
|
||
| ten underdetermined rules points (U1–U10) | formalizing the dataset into testable rules |
|
||
| SOLVE offered on a face-down Problem, always inert | a human dragging it three rounds running |
|
||
| GR-A13 "wasted SOLVE" on a claimed Problem | a scenario that had to pick a default |
|
||
| GR-E01 unreachable below 5 seats | arithmetic over the deal count |
|
||
| six provisional scenario defaults | scenarios that could not be written without deciding something |
|
||
| GR-E03 / GR-E04 never played to the end | nobody noticed for nineteen passes |
|
||
|
||
Every one was found by *building the simulator*, not by playing. That is
|
||
the thing worth naming: **a simulator rigorous enough to refuse ambiguity
|
||
is a design instrument, because it cannot proceed past a rule that does
|
||
not decide.**
|
||
|
||
And every one of them has been carried in prose, in six different places,
|
||
and one sat unread in an inbox for four days.
|
||
|
||
## The load-bearing rule this must have
|
||
|
||
The project's standing failure is *unexecuted verification*. A design
|
||
register that collects opinions would reproduce it in a new medium.
|
||
|
||
> **A design finding is not admissible without its reproduction.**
|
||
|
||
Concretely: a scenario that fails, an arithmetic check that prints the
|
||
contradiction, a recorded game the reader can replay, or a named test.
|
||
*"This feels unbalanced"* is a note, not a finding. **GR-E01 is admissible
|
||
because 4/6/9 against 5/7/9 is a computation anyone can rerun; the SOLVE
|
||
inertness is admissible because a recorded session shows three no-ops.**
|
||
|
||
This is what would make clay-borg a design tool rather than a suggestion
|
||
box, and it is the one part of this proposal that must not be traded away
|
||
for convenience.
|
||
|
||
## The judgment I want reviewed, not assumed
|
||
|
||
The maintainer asked whether this should extend to *"a meta about the
|
||
clay-borg engine evolution itself."*
|
||
|
||
**My answer is no, and it should be argued rather than accepted.** That
|
||
register already exists and is load-bearing: `evidence/CB-EV-*` records
|
||
what each pass found, `decisions/ADR-*` records what was decided and what
|
||
was rejected, `gates.toml` records what every control has caught and what
|
||
would retire it, and workplans record what was attempted. Nineteen passes
|
||
of engine evolution are already captured, with dates, costs and
|
||
falsifiers.
|
||
|
||
**Building a second register for the same subject would be ceremony**, and
|
||
this project has a standing rule that a gate must cash out. The asymmetry
|
||
is the point: engine evolution has a home and game design does not.
|
||
|
||
If the adversarial review disagrees, that is exactly the kind of thing
|
||
tier L exists to surface.
|
||
|
||
## Task: survey how this is done elsewhere, and what we already have
|
||
|
||
```task
|
||
id: CB-WP-0022-T01
|
||
status: done
|
||
priority: high
|
||
state_hub_task_id: "6b8663b8-4143-4361-ad9e-7df0c4f4a19d"
|
||
```
|
||
|
||
`research/CB-RES-0007-*.md`.
|
||
|
||
**Do not survey issue trackers.** The question is narrower and more
|
||
interesting: how do rigorous rule systems record *the ambiguity they
|
||
found*? Candidates worth a benchmark-to-beat:
|
||
|
||
- **Errata and rulings practice** in published games (Magic's
|
||
comprehensive-rules + rulings split, Netrunner's NAPD card rulings) —
|
||
what makes a ruling *findable* years later.
|
||
- **Formal-methods counterexample traces** — a model checker's output is
|
||
precisely a reproduction attached to a claim, which is the shape wanted
|
||
here.
|
||
- **Conformance-suite provisional behaviour** — how W3C/WHATWG mark
|
||
"implementation-defined" and how a spec later absorbs it.
|
||
- **What this repo already has**: `provisional: true` scenarios,
|
||
`§Underdetermined`, `gates.toml`'s `caught`/`retire_if` shape, and the
|
||
hub message that went unread. **The register must reuse the provisional
|
||
machinery rather than compete with it.**
|
||
|
||
Name, per dimension, the property to beat — findability, reproducibility,
|
||
and whether a ruling can *close* a finding mechanically.
|
||
|
||
**Done 2026-08-03.**
|
||
[CB-RES-0007](../research/CB-RES-0007-design-instrument.md), with a
|
||
runnable baseline (`tools/design-baseline.py`).
|
||
|
||
**The baseline is us, and it is measured**: 6 findings across **11 files**
|
||
with no index, **2 of 6 (33%) with a runnable reproduction**, and U1–U10
|
||
raised 2026-07-30, first *read* 2026-08-03 — **4 days**, 0 of 10 ruled.
|
||
|
||
**The uncomfortable number is stated up front rather than left for the
|
||
review to find: the reproduction rule would reject four of our six
|
||
existing findings.** The survey answers it — none of the four is
|
||
expensive to reproduce, so the 33% is evidence that nobody was ever asked
|
||
for one, not that the rule is unaffordable.
|
||
|
||
**Magic corrected an assumption this pass was about to build on.** I
|
||
expected a ruling to be the authoritative resolution. It is not: rulings
|
||
are *"reminder information with no actual weight or rules meaning"*, and
|
||
the authoritative fix folds into the **Oracle** card text. **A finding
|
||
closes when the source changes, not when an annotation is added** — so
|
||
the register must be a queue that empties, not an archive that grows.
|
||
That is now a constraint on T03's lifecycle.
|
||
|
||
Model checkers supplied the reproduction rule independently (a
|
||
counterexample trace *is* the finding), and W3C's *implementation-defined*
|
||
mark is the one piece of machinery we already have and must reuse rather
|
||
than duplicate.
|
||
|
||
## Task: adversarial review
|
||
|
||
```task
|
||
id: CB-WP-0022-T02
|
||
status: todo
|
||
priority: high
|
||
state_hub_task_id: "d2597895-fe2e-4f1e-a3db-a5fb8833434c"
|
||
```
|
||
|
||
Tier L requires it. Give the reviewer the survey **and** the §judgment
|
||
above, and require an attempt at:
|
||
|
||
- **that the engine-evolution register is redundant** — the strongest
|
||
counter is that ADRs record *decisions* and evidence records *findings*,
|
||
but nothing records *what we learned about building engines*, which is a
|
||
third thing;
|
||
- **that "carries its reproduction" is affordable** — if half the real
|
||
findings cannot be reproduced cheaply, the rule will be quietly dropped
|
||
and the register becomes a suggestion box anyway. *(Since this task was
|
||
written the answer has hardened: two findings reached ground-game on
|
||
wrong premises, and ground-game has itself ruled that reproductions are
|
||
required. The reviewer should now press the opposite way — whether the
|
||
rule is **sufficient**, given both bad premises would have shipped a
|
||
passing test alongside a wrong description.)*
|
||
- **that a register is needed at all**, rather than one more section in
|
||
`GroundRules.md §Underdetermined`, which already exists and already
|
||
works.
|
||
|
||
Record the trail in `history/`, unpolished.
|
||
|
||
## Task: decide
|
||
|
||
```task
|
||
id: CB-WP-0022-T03
|
||
status: todo
|
||
priority: high
|
||
state_hub_task_id: "a2e85810-e949-4ea0-81fc-36b912af326c"
|
||
```
|
||
|
||
`decisions/ADR-0012-*.md`. At minimum:
|
||
|
||
- whether clay-borg's **INTENT gains a stated aspect** as a design
|
||
instrument, and in what words — this is the change with the longest
|
||
half-life in the pass;
|
||
- the finding **taxonomy**, and it should be grounded in the six findings
|
||
above rather than invented: *underdetermined* (rules do not say),
|
||
*inconsistent* (rules disagree with each other or the data), *inert* (a
|
||
rule that cannot fire), *degenerate* (fires, but collapses play),
|
||
*unplayed* (implemented, never played);
|
||
- the **lifecycle** and who owns each state: raised → reported → ruled →
|
||
applied, or withdrawn;
|
||
- whether a finding without a reproduction is **rejected** or **admitted
|
||
as a note** — and if admitted, how it is prevented from aging into an
|
||
apparent finding.
|
||
|
||
## Task: specify
|
||
|
||
```task
|
||
id: CB-WP-0022-T04
|
||
status: todo
|
||
priority: high
|
||
state_hub_task_id: "60ddfeab-81b1-45e4-9ec9-91cc8ea7fb72"
|
||
```
|
||
|
||
`specs/GameDesign.md`, with metrics, because a spec without them is prose.
|
||
|
||
Candidate measures, to be argued not adopted:
|
||
|
||
- **findings with a runnable reproduction** — target 100%, and the
|
||
denominator includes withdrawn ones;
|
||
- **time from raised to reported** — the U-items took four days to be
|
||
*read*; that is the number this exists to fix;
|
||
- **findings closed by a ruling** vs **findings still open**, with age.
|
||
|
||
**ground-game has ruled on what a finding must carry** (GROUND-WP-0004
|
||
T02, 2026-08-04), and it is stricter than this pass proposed. Adopt it:
|
||
|
||
> 1. Arithmetic findings must ship a **runnable reproduction** *and* a
|
||
> **row-level deal table** listing Surface and each hidden priority
|
||
> separately — **never only "sum of file" or "deal depth N"**.
|
||
> 2. ground-game rulings that depend on arithmetic **should cite** that
|
||
> reproduction id or path, so a later reader can re-run it.
|
||
|
||
The second half is theirs to keep. The first is ours, and it is a direct
|
||
consequence of both premises we got wrong: *"12 in the file"* was a sum
|
||
without a deal table, and *"offered on a face-down Problem"* was a
|
||
condition named without checking which one actually fired.
|
||
|
||
**So the reproduction rule gains a shape requirement, not just an
|
||
existence one.** A finding that ships a passing test but describes the
|
||
wrong quantity is still a bad finding — which is exactly what happened
|
||
twice. The spec must say what a reproduction has to *show*, not only that
|
||
one exists.
|
||
|
||
Also specify the **trial protocol**, which is the part with no precedent
|
||
here: a trial game is a `--record`ed session plus an observation log, so
|
||
*"we played it and X happened"* is replayable rather than remembered. The
|
||
engine already records sessions as scenarios; a trial is that plus notes,
|
||
and it must cost almost nothing or it will not be done.
|
||
|
||
## Task: build it, and backfill what is already known
|
||
|
||
```task
|
||
id: CB-WP-0022-T05
|
||
status: todo
|
||
priority: high
|
||
state_hub_task_id: "469413ba-ed47-4840-a60e-ee7f95dc06ff"
|
||
```
|
||
|
||
The register, the tool, and then **the six findings above entered into
|
||
it** — backfilling is the test. A register that cannot express findings
|
||
the project already has is the wrong register, and discovering that after
|
||
designing it is the point of doing it in this order.
|
||
|
||
`make design` (or equivalent) must report: open findings by kind, those
|
||
without a reproduction, and those never reported to their owner.
|
||
|
||
## Task: report to ground-game, mechanically
|
||
|
||
```task
|
||
id: CB-WP-0022-T06
|
||
status: todo
|
||
priority: high
|
||
state_hub_task_id: "c6a659bd-c495-4754-9332-baadad51012a"
|
||
```
|
||
|
||
Generate the report and send it. **The message that sat unread for four
|
||
days is the baseline to beat**, and the failure was not the message — it
|
||
was that nothing pointed at it and nothing tracked whether it was
|
||
answered.
|
||
|
||
So the report must land somewhere that persists: a file in `ground-game`
|
||
under its own workplan, not only an inbox entry. GROUND-WP-0002 already
|
||
holds the ten U-items; this should extend it rather than duplicate it.
|
||
|
||
Include the two sharpened findings this pass has already produced:
|
||
|
||
- **GR-E01 vs GR-S01** — the deal count puts 4/6/9 points in play against
|
||
thresholds of 5/7/9, so either the count or the thresholds are wrong and
|
||
no dataset reconciles them;
|
||
- **SOLVE's legality** against a face-down Problem or an unmatchable suit.
|
||
|
||
## Task: evidence
|
||
|
||
```task
|
||
id: CB-WP-0022-T07
|
||
status: todo
|
||
priority: high
|
||
state_hub_task_id: "4fb77911-486d-4d9e-a53d-c4e486c74ce2"
|
||
```
|
||
|
||
`evidence/CB-EV-0021-*.md`. *(Was CB-EV-0020 when written; CB-WP-0023
|
||
shipped that number first — `evidence/CB-EV-0020-solve-legality.md` — so
|
||
this one moves rather than collides.)*
|
||
|
||
- **Whether backfilling changed the design** — if all six findings fit the
|
||
first taxonomy, say so and be suspicious of it.
|
||
- **What tier L cost against what it caught**, since this is the second
|
||
full-weight L pass and CB-WP-0012's deleted its own structural trigger.
|
||
- **The engine-evolution question**, as the review left it.
|
||
- **Quote CB-WP-0021's cost by re-running the instrument.**
|