CB-WP-0044: the page says which rules it plays
Some checks failed
ci / check (push) Failing after 4s
Some checks failed
ci / check (push) Failing after 4s
Reported as "I did a session and noted no changes" — correct, and the fault was ours twice. make ground passes no --variant, so the session was baseline, and CB-WP-0043 deliberately leaves the baseline layout untouched because a variant that redraws the baseline invalidates every prior look at it. But the deeper defect is that nothing said so. The page named the round, the step, the Lead, the scoring mode and the viewer, and never which rules it was playing — GroundView did not even carry the variant. There was no way from the screen to tell baseline from H1 from H2. A session that cannot say which rules it is playing cannot report a rules change; the player did the right thing and the instrument had nothing to tell them. Now: variant on GroundView, `rules <id>` in the page header beside the scoring mode, `rules <id>` in the inspector because a replay that cannot say which rules produced it is the same defect in the other tool, and make ground VARIANT=h2 so the capability is reachable. Both coverage probes caught the new field independently — the render crate's and cb-play's — the second time in two passes that they have turned an addition into a legibility requirement instead of letting it be silent state. Verified by fetching the served page rather than by reading the code: make ground VARIANT=h2 prints "rules: h2" and the page carries "rules h2-scoped-problem-stress" with the scope labels; the baseline says "rules ground-darvo-r0" and keeps its row. Still open: nothing explains what a scope DOES, and the trial log header does not record the variant either — the same defect one artifact along. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
parent
471de44632
commit
25b18bddf7
9 changed files with 271 additions and 2 deletions
75
workplans/CB-WP-0044-the-page-says-which-rules-it-plays.md
Normal file
75
workplans/CB-WP-0044-the-page-says-which-rules-it-plays.md
Normal file
|
|
@ -0,0 +1,75 @@
|
|||
---
|
||||
id: CB-WP-0044
|
||||
kind: product
|
||||
title: "The page says which rules it plays"
|
||||
status: done
|
||||
---
|
||||
|
||||
# Purpose
|
||||
|
||||
```
|
||||
structural tier M (adds a field to the projection, a canonical
|
||||
interface, and a driver knob)
|
||||
declared tier M
|
||||
```
|
||||
|
||||
## The report
|
||||
|
||||
> *"I did a session and noted no changes."*
|
||||
|
||||
**Correct, and the fault was ours twice over.**
|
||||
|
||||
`make ground` passes no `--variant`, so the session was **baseline** — and
|
||||
CB-WP-0043 deliberately leaves the baseline layout untouched, because a
|
||||
variant that redraws the baseline invalidates every prior look at it.
|
||||
|
||||
**But the deeper defect is that nothing said so.** The page named the
|
||||
round, the step, the Lead, the scoring mode and the viewer — **and never
|
||||
which rules it was playing.** `GroundView` did not even carry the variant.
|
||||
There was no way, from the screen, to tell baseline from H1 from H2.
|
||||
|
||||
> **A session that cannot say which rules it is playing cannot report a
|
||||
> rules change.** The player did the right thing and the instrument had
|
||||
> nothing to tell them.
|
||||
|
||||
## Task: say it, and make it reachable
|
||||
|
||||
```task
|
||||
id: CB-WP-0044-T01
|
||||
status: done
|
||||
priority: high
|
||||
```
|
||||
|
||||
**Controls:**
|
||||
- **the page names the variant**, beside the scoring mode where a player
|
||||
already looks for what game this is;
|
||||
- **the inspector names it too** — a replay that cannot say which rules
|
||||
produced it is the same defect in the other tool;
|
||||
- **`make ground` can select it**, or the capability exists and nobody
|
||||
can reach it;
|
||||
- **verified end to end against a served page**, not by reading the code.
|
||||
|
||||
**Done 2026-08-08.**
|
||||
|
||||
`variant` on `GroundView`, `rules <id>` in the header, `rules <id>` in the
|
||||
inspector, and `make ground VARIANT=h2`.
|
||||
|
||||
**Both coverage probes caught the new field independently** — the render
|
||||
crate's and `cb-play`'s — which is the second time in two passes that the
|
||||
probes have turned an addition into a legibility requirement rather than
|
||||
letting it be silent state.
|
||||
|
||||
**Verified by fetching the served page**: `make ground VARIANT=h2` prints
|
||||
`rules: h2`, and the page carries `rules h2-scoped-problem-stress` plus
|
||||
the scope labels. The baseline page says `rules ground-darvo-r0` and keeps
|
||||
its row, which is the behaviour CB-WP-0043 intended and could not
|
||||
previously be told apart from a bug.
|
||||
|
||||
## What this does not fix
|
||||
|
||||
- **Nothing on the page explains what a scope does.** It says *whose* a
|
||||
Problem is; it does not say that an unclaimed personal card ticks only
|
||||
its owner at Round End. H2's `Rules_Text.csv` is vendored and unread.
|
||||
- **The variant is not in the trial log's header**, so a note written
|
||||
during an H2 session does not record which rules it was about. That is
|
||||
the same class of defect as this one, one artifact along.
|
||||
Loading…
Add table
Add a link
Reference in a new issue