From bb426b3e9b688b8e05954da0528d796978b96f84 Mon Sep 17 00:00:00 2001 From: tegwick Date: Mon, 3 Aug 2026 20:48:08 +0200 Subject: [PATCH] Declare CB-WP-0022: the design instrument, tier L The maintainer named a new aspect: clay-borg as a game design tool, with a register for design flaws, questions, results and trial protocols. Structural L on the maintainer-named-high-leverage trigger, and it amends INTENT. Chaos d8=6, no override. The insight is that this is already happening with no home. Five passes have produced ten underdetermined rules points, SOLVE offered on a face-down problem and always inert, GR-A13's wasted SOLVE, GR-E01 unreachable below 5 seats, six provisional scenario defaults, and two scoring modes never played to the end -- every one found by BUILDING the simulator rather than by playing it. A simulator rigorous enough to refuse ambiguity is a design instrument, because it cannot proceed past a rule that does not decide. All of it has been carried in prose in six places and one sat unread in an inbox for four days. The load-bearing rule: a design finding is not admissible without its reproduction. A register that collects opinions would reproduce this project's standing failure -- unexecuted verification -- in a new medium. Recorded as a judgment for the adversarial review rather than assumed: the engine-evolution meta the maintainer also asked about should NOT be built, because evidence/, decisions/, gates.toml and workplans already carry nineteen passes of it with dates, costs and falsifiers. A second register for the same subject is ceremony. The asymmetry is the point -- engine evolution has a home and game design does not. T05 backfills the six known findings as the TEST of the register: one that cannot express findings the project already has is the wrong register, and discovering that after designing it is why the order is survey, review, decide, specify, build. Co-Authored-By: Claude Opus 5 --- workplans/CB-WP-0022-the-design-instrument.md | 244 ++++++++++++++++++ 1 file changed, 244 insertions(+) create mode 100644 workplans/CB-WP-0022-the-design-instrument.md diff --git a/workplans/CB-WP-0022-the-design-instrument.md b/workplans/CB-WP-0022-the-design-instrument.md new file mode 100644 index 0000000..5462d63 --- /dev/null +++ b/workplans/CB-WP-0022-the-design-instrument.md @@ -0,0 +1,244 @@ +--- +id: CB-WP-0022 +kind: product +title: "The design instrument: findings about the game, with their reproductions" +status: ready +--- + +# 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: todo +priority: high +``` + +`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. + +## Task: adversarial review + +```task +id: CB-WP-0022-T02 +status: todo +priority: high +``` + +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; +- **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 +``` + +`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 +``` + +`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. + +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 +``` + +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 +``` + +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-T06B +status: todo +priority: high +``` + +`evidence/CB-EV-0020-*.md`. + +- **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.**