coulomb/clay-borg
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

CB-WP-0018: record the card report and what it actually is

Browse source 
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 <noreply@anthropic.com>
This commit is contained in:
tegwick 2026-08-03 02:00:21 +02:00
parent e8bb7263f2
commit 78e82497ee
1 changed files with 49 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

49
workplans/CB-WP-0018-the-browser-is-a-client.md
View file

@ -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