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:**