ci / check (push) Failing after 4s

Details

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>

2026-08-07 17:49:06 +02:00

3.7 KiB

Raw Blame History

id	kind	title	status
CB-WP-0034	product	Who you are bonding with	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

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.

3.7 KiB Raw Blame History