tegwick
51efe55d14
Some checks failed
ci / check (push) Failing after 4s
Tier S (fixes inside a boundary; chaos d8=3, no override). Two observations from play, both about what the page says has happened. The controls moved BELOW the log: you read what happened, then decide what to do next. They were above it, which asks for the decision first. And sealing now marks the WHOLE PAGE inert, not just the controls. A greyed-out button beside a full-colour table still reads as a live game with one broken control; the session has ended and everything on screen is a record of it. The status line stays legible on purpose -- it is the one thing still worth reading. THE STUB NEEDED A BODY classList TO MAKE THAT TESTABLE. Without it "the session visibly ended" would have been a claim about CSS with nothing checking it, which is precisely CB-WP-0016's finding: a stub too thin to express a failure is how the failure survives. The harness reports the sealed page through the status channel with a NUL-separated marker -- ugly, deliberate, and documented, because widening the return type would touch every caller for one boolean. Both directions asserted: a `closed` reply seals the page, an `ok: dealing` reply does NOT -- otherwise the seal test would pass for a page that greys itself whenever it is touched, breaking `play again`. 63 render tests, 26 cb-play, check and loop-lint clean. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
627 B
627 B
Trial log
What the player said while playing, bound to the position they said it at
(CB-WP-0027, ADR-0014). The recording beside this file is the position;
state_hash is what reaches it.
These are raw notes and they stay here. Nothing in this file travels to
ground-game (ADR-0014 D4) — a note reaches them only by being promoted to a
register finding, by a human, with the wording chosen then.
| n | round | step | state_hash | comment |
|---|---|---|---|---|
| 1 | 5 | Reveal | bb9de8f0bfe5 | RespondToSupport is unclear as i cant see whos support i accept. |