From 78e82497ee0549bb4d91f07f88b55b6d17110376 Mon Sep 17 00:00:00 2001 From: tegwick Date: Mon, 3 Aug 2026 02:00:21 +0200 Subject: [PATCH] CB-WP-0018: record the card report and what it actually is A discard pile already exists -- solution_discard on GroundState, SolutionDiscarded removes from hand, and the page renders it. Building one would have been building a thing that is there. What was dragged are ACTION cards, which are not cards and are correctly never consumed; solution cards leave the hand at Resolve because a selection is a face-down commit. But the report points at something real. Measured live: Investigate draws correctly (2 -> 3 -> 4 cards), and Solve was then played three times on problem-1 with the hand unchanged at 4 and discard empty -- because problem-1 was face down and GR-A02's resolver silently continues. legal_commands offers Solve on every face-up problem without consulting the hand. Whether SOLVE should be selectable against a face-down problem or an unmatchable suit is a game-semantics question and INTENT defers those to ground-game. What is ours is that a provably-inert move is offered, accepted and never accounted for. Folded into T02 as the case the log must handle: a command that produced NO events is the one the player needs to see. Co-Authored-By: Claude Opus 5 --- .../CB-WP-0018-the-browser-is-a-client.md | 49 +++++++++++++++++++ 1 file changed, 49 insertions(+) diff --git a/workplans/CB-WP-0018-the-browser-is-a-client.md b/workplans/CB-WP-0018-the-browser-is-a-client.md index abe0ae9..65aaa27 100644 --- a/workplans/CB-WP-0018-the-browser-is-a-client.md +++ b/workplans/CB-WP-0018-the-browser-is-a-client.md @@ -80,6 +80,49 @@ asserts the final GET returns a page naming the outcome, **not** a refused connection. And the error path, driven by a game that fails, asserting the reason reaches the page. +## The second report, and what it actually is + +Reported: *"the cards I play by pulling them on a target will not be +removed, that is wrong i guess we will need a discard pile."* + +**A discard pile already exists** — `solution_discard` on `GroundState`, +`SolutionDiscarded` removes the card from the hand and pushes it there, +and the page already renders `deck N remaining / discard …`. Building one +would have been building a thing that is there. + +What the maintainer dragged were **action** cards. The five GROUND actions +are not cards and are correctly never consumed. Solution cards leave the +hand at **Resolve**, not at Select, because a selection is a face-down +commit. + +But the report is pointing at something real. Measured over a live game: + +| move | hand | discard | +|---|---|---| +| 1 · Investigate → problem-2 | 2 cards | none | +| 2 · Investigate → problem-3 | **3 cards** | none | +| 3 · Solve → problem-1 | 4 cards | none | +| 4 · Solve → problem-1 | **4 cards** | none | +| 5 · Solve → problem-1 | **4 cards** | none | + +Investigate draws, correctly. **Solve was played three times and did +nothing, three times, in silence.** GR-A02's resolver `continue`s when the +problem is face-down, already claimed, denied, or when the seat holds no +card of the matching suit — and `legal_commands` offers Solve on every +face-up problem without consulting the hand, while the page offers it on +problem-1 which was still face-down. + +**Whether that is a rule gap or intended is not this repo's call.** A +face-down commit you cannot fulfil is a plausible bluff in a commit/reveal +game with DARVO, and INTENT defers game semantics to `ground-game`. What +*is* this repo's call is that a move which provably does nothing is +offered, accepted, and never accounted for. That is the log's job (T02) +and the explanation's job (T03), and it is now the concrete case both are +measured against. + +Raised for `ground-game`, not decided here: **should SOLVE be selectable +against a face-down problem, or against a suit the seat cannot match?** + ## Task: a game log, and what to do next ```task @@ -109,6 +152,12 @@ player sees state change with no account of why. produced, not re-narrated from the state. A log that describes the state after the fact is a second implementation of the rules and will drift. +**The case it must handle**, from the measurement above: three SOLVEs that +produced no events at all. A log built only from events would show nothing +for them and reproduce the silence. So the log must distinguish *"this +command produced these events"* from *"this command produced none"* — +the second is the one the player needs and the harder one to render. + ## Task: say where a drop goes, and what it means ```task