CB-WP-0034: who you are bonding with

Reported three times across three sessions, two days apart, and it
survived a whole UI rebuild: "i cant see whos support i accept".

It was not styling. The move button's label was format!("{c:?}"), so the
player read `RespondToSupport { response: AcceptBond }` — Rust struct
syntax with no name in it. And the command does not carry the
counterparty, so nothing rendering it alone could have said who; it comes
off the view, as whoever played Support at this seat.

Four more seat-panel fields had the same defect, including `support
AcceptBond` — the one the report names. CB-WP-0020 fixed exactly this for
selections and left its four neighbours as they were.

command_label has no catch-all arm, and that earned its keep before any
test ran: GroundChoice::RejectReverse and SupportResponse::BreakRivalry
both failed to compile — two moves that would have shipped as struct
dumps. An offer the view cannot see is said to be unseen rather than given
an invented name.

The finding underneath: the coverage probe that exists to prove every view
field reaches the PLAYER was matching "player: Some(PlayerId(1))" and
"members: [PlayerId(1)". It was certifying the defect as coverage and
would have gone red had anyone fixed it. Second confirmation of
CB-WP-0024's finding, from the sharper side: a probe naming Debug output
does not merely fail to protect, it pins the defect in place.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

workplans/CB-WP-0033-a-game-is-the-unit.md

@@ -3,6 +3,7 @@ id: CB-WP-0033
 kind: product
 title: "A game is the unit"
 status: done
+state_hub_workstream_id: "66c54551-38cd-465e-bb2f-9e1d83e14438"
 ---
 
 # Purpose
@@ -51,6 +52,7 @@ session still destroyed its own evidence.** [ADR-0019](../decisions/ADR-0019-a-g
 id: CB-WP-0033-T01
 status: done
 priority: high
+state_hub_task_id: "b0b4b9f3-f99f-4b4d-8eed-ba2fa4f9ea98"
 ```
 
 **Controls:**

workplans/CB-WP-0034-who-you-are-bonding-with.md

@@ -0,0 +1,109 @@
+---
+id: CB-WP-0034
+kind: product
+title: "Who you are bonding with"
+status: done
+---
+
+# Purpose
+
+```
+structural tier  S   (rendering only -- no rule, no dependency, no budget,
+                      no artifact contract moved)
+chaos            d8 = 4  → no override
+declared tier    S
+```
+
+**Declaration 5 of chaos window 3.**
+
+## The report, three times
+
+> *"RespondToSupport is unclear as i cant see whos support i accept."*
+> — 2026-08-06
+>
+> *"i can not [see] the player i bond or not-bond with. We should change
+> that."* — 2026-08-07 15:58
+>
+> *"But i **still** cant see the player i am bonding with."* — 2026-08-07 16:12
+
+Three sessions, two days, and it **survived a whole UI rebuild**.
+
+## It was not styling
+
+The move button's label was `format!("{c:?}")`. The player was reading
+
+```
+RespondToSupport { response: AcceptBond }
+```
+
+— Rust struct syntax, with **no name anywhere in it**. And
+`GroundCommand::RespondToSupport { response }` **does not carry the
+counterparty**, so nothing rendering the command alone could have named
+them. It comes off the view: whoever played `Support` targeting this seat.
+
+**Four more fields on the seat panel had the same defect**, including the
+one the report names — `support AcceptBond`, an answer with nobody
+attached. CB-WP-0020 fixed exactly this for `selections` and left its four
+neighbours as they were.
+
+## Task: name who
+
+```task
+id: CB-WP-0034-T01
+status: done
+priority: high
+```
+
+**Controls:**
+- **the seat is named**, and the raw command name never reaches the page;
+- **an unseen offer is not given an invented name** — a confidently wrong
+  seat is worse than an honest gap (ADR-0018);
+- **no catch-all arm**, so a new command cannot silently fall back to
+  `Debug`;
+- mutation-proven both ways.
+
+**Done 2026-08-07.**
+
+**The exhaustiveness control paid for itself immediately**, before any
+test ran: `GroundChoice::RejectReverse` and
+`SupportResponse::BreakRivalry` both failed to compile. Two moves that
+would have shipped as struct dumps, caught by the absence of a `_ =>`.
+
+**These are clay-borg's words, not the edition's.** The Action cards carry
+the game's own `rules_text` (ADR-0015); nothing vendored names these
+control moves, and `Glossary` is unvendored (F18). If it lands, this is a
+caller to revisit.
+
+## The finding underneath: a gate that pinned the defect
+
+`every_view_field_is_classified_in_the_emitted_document` — the probe that
+exists to prove **every view field reaches the player** — was matching
+
+```
+"problem: 7 }"   "player: Some(PlayerId(1))"   "members: [PlayerId(1)"
+```
+
+**It was proving the field reached the page by matching Rust struct
+syntax.** A gate written to protect the player's view of the game had
+been certifying the defect as coverage, and would have gone red if
+anyone had fixed it.
+
+**Second confirmation of CB-WP-0024's finding, from the other side.** That
+pass found a probe naming a *presentation* does not survive a rendering
+change. This is the sharper case: a probe naming *Debug output* actively
+holds the defect in place.
+
+Probes now name facts — `Ground & Restate`, `P2 + P3`, `accepted P3's
+Support`. The fixture gained a visible Support offer so the probe can name
+a seat rather than a response with nobody attached.
+
+## Not done here
+
+- **The unknown-supporter path is untested against a real game.** It is
+  reachable only if `RespondToSupport` is offered while the Support is not
+  visible in the responder's view; whether the rules permit that is a
+  question for `ground-game`, and the page currently says it cannot see
+  rather than guessing.
+- **Other Debug output may remain outside the two surfaces audited here**
+  (the move buttons and the seat panel). The exhaustive match guards
+  commands only.