Wave 5 of thressgame-100 epic complete \u2014 paradigm-break wave per oracle.
User-authorized despite the cost. Coverage: 47/51 \u2192 50/51 = 98 %.
PARADIGM-BREAK CONTEXT (oracle pre-flagged):
Oracle classified Wave 5 as 'paradigm break \u2014 game-level mutable state'. User
explicitly authorized via 'no time/cost limit, no backward-compat constraint,
just fucking get it all done'. Design choice: scores live alongside RngStream
on GAME_ENTITY \u2014 same pattern as existing global state (RngStream,
ChoiceTimeoutPolicy, BoardTopology, BlockAllExceptKing), not new architecture.
ENGINE WORK (W5.0\u2013W5.4):
Score subsystem (locked decision F):
- WhiteScore + BlackScore attrs on GAME_ENTITY \u2014 type 'number', default 0
- Initialized at engine construction (engine.ts:632\u2013634) so fact-log inclusion
is mechanical \u2014 state-hash auto-includes scores via existing infrastructure
- N=100 byte-identical replay determinism verified
3 NEW PRIMITIVES:
- add-resource(player, amount) imperative; synchronous fire of
on-resource-changed hooks
- spend-resource(player, amount, imperative; selfRecurse:true \u2014 only the
then, else) chosen arm runs (walker doesn't auto-recurse
into both); cascade-depth-limited (8)
- on-resource-changed(player, trigger; fires on threshold crossing in
threshold, direction up/down/any; snapshot-before-iterate
direction, so hook arm registering more hooks doesn't
primitives) fire on the same crossing
WS PROTOCOL (W5.5) \u2014 Scenario A chosen: ZERO protocol changes:
- broadcast.ts uses session.allFacts() which iterates ALL facts on ALL entities
including GAME_ENTITY
- WhiteScore/BlackScore mutations land in game.state and game.delta frames
automatically; client PredictionManager receives them out-of-the-box
- Zod FactSchema has untyped .unknown() value field on the wire \u2014 number values
serialize implicitly
UI WORK (W5.6) \u2014 GameView.tsx score chips:
- Two chips: data-testid='score-white' (\u26aa W) and data-testid='score-black'
(\u26ab B), bordered chip styling matching ActionMenu sibling vocabulary
- HIDE-WHEN-ZERO rule: chips hidden unless either score !== 0 OR
OnResourceChangedHooks contains entries (pure-chess games visually unchanged)
- Real-time updates via existing useMultiplayerGame hook \u2014 broadcasts trigger
re-render, scores update without page reload
3 NEW RECIPES (W5.7):
Batch M \u2014 economy:
- tpl-treasure-chest \u2014 capture spawns treasure marker; entering treasure
awards white +5 score and consumes marker
(SIMPLIFIED: arm 2 hardcodes player='white' \u2014
no chooser-color resolver; LastModifierChooser
semantics = rule applier not current mover)
- tpl-cash-grab \u2014 every turn-end, white+1 + black+1 (passive income)
(SIMPLIFIED: V3 has no eq shape \u2014 random-pick result
can't be compared against piece Position; ship the
dual-add-resource pattern instead of canonical
random-square-rewards-piece-owner semantics)
- tpl-summoning-ritual \u2014 spend 5 score to summon white knight at e4
(SIMPLIFIED: single-shot at activation; repeatable
summoning needs request-choice loop \u2014 W6+ scope)
TEST SURFACE:
- add-resource.test.ts: ~10 unit tests
- spend-resource.test.ts: ~12 unit tests
- on-resource-changed.test.ts: ~15 unit tests
- economy-integration.test.ts: 8 integration tests
(incl. N=100 determinism)
- wave5-recipes-real.test.ts: 14 runtime tests
- recipes.test.ts: 5 \u00d7 62 = 513 expect calls
- wave5-economy.spec.ts (Playwright): 5 e2e tests
(3 load + summoning-ritual
success-path runtime +
cash-grab turn-end driven)
bun run check: 3270 tests pass (was 3192, +78). 0 regressions.
e2e: 5/5 green via .sisyphus/scripts/run-pw.sh against docker compose dev stack.
KEY FINDINGS (recorded in learnings.md):
- spend-resource selfRecurse:true correctly gates walker auto-recursion \u2014
place-piece inside 'then' only runs when spend succeeds
- ctx-attr.entity:'self' resolves cleanly to ctx.pieceId in resolver
- fireOnTurnEndHooks (and other per-piece dispatchers) iterate pieces \u2014 hooks
on GAME_ENTITY are dead-seeded; apply-descriptor needs targetSquare for any
recipe rooted at a per-piece trigger
- Snapshot-before-iterate in fireOnResourceChangedHooks prevents reentrant
cascade fires on the same crossing
BACKWARD-INCOMPAT TESTS UPDATED (per locked decision J):
- registry-count.test.ts: 56 \u2192 59 (3 new primitives)
- ParamField.snapshot.test.tsx: SAMPLE_PARAMS exhaustiveness for 3 new kinds
- GameView snapshot: regenerated for new score-chip section
Plan: .sisyphus/plans/thressgame-100.md
Notepads: .sisyphus/notepads/thressgame-100/
Evidence: .sisyphus/evidence/thressgame-100-wave5.txt (gitignored, 1074 lines)
Wave 4 of thressgame-100 epic complete \u2014 highest-risk wave (move-gen
topology) survived with 0 regression. Coverage: 44/51 \u2192 47/51 = 92 %.
ENGINE WORK (W4.0\u2013W4.7):
Topology subsystem (locked decision G \u2014 opt-in via BoardTopology attr):
- New attr: BoardTopology on GAME_ENTITY \u2014 'standard' | 'wrap-files' | 'wrap-all'
- New helper: util/topology.ts \u2014 wrapSquare(rawCol, rawRow, topology) +
readBoardTopology(session)
- coord.ts threads optional topology through slidingSquares / knightSquares /
kingSquares (default 'standard' preserves all pre-W4 output bit-identical)
- rules/primitives.ts threads topology through rookCandidates, bishopCandidates,
queenCandidates, knightCandidates, kingCandidates, pawn{Single,Double}Advance,
pawnCaptureSqares
- rules/{sliding,knight,king,pawn}.ts read topology via readBoardTopology and
thread through candidate generators
- presets/core-piece-types.ts pawn attackProbe reads topology
- New imperative: set-board-topology(value) \u2014 modifies the GAME_ENTITY attr
Pairing subsystem (locked decision E):
- New attrs: PieceLink (per-piece, EntityId[]), OnPiecePairLinkBrokenHooks
(game-level)
- New imperative: link-pieces(a, b) \u2014 symmetric (adds B to A's links AND
A to B's links); self-link no-op
- New imperative: unlink-pieces(a, b) \u2014 symmetric removal
- New trigger: on-piece-pair-link-broken(target, primitives) \u2014 fires when
a linked partner is destroyed; introduces 'linkedPieceId' binding
- Cascade integration: engine.ts:dealDamage and destroy-piece.ts both fire
the on-piece-pair-link-broken cascade when a linked piece is destroyed.
PieceLink + the partner's link entry are auto-unlinked BEFORE the trigger
fires (prevents reentrant infinite loop \u2014 the cascade-loop fix).
Two critical bugs found and fixed (full walkthrough in evidence file):
1. CASCADE LOOP: original draft fired hooks BEFORE auto-unlinking; reentrant
destroy-piece(survivor) re-fired the hook on original \u2192 infinite loop.
Fix: clear dying piece's PieceLink AND prune partners' lists FIRST, then
fire hooks. Pinned by cascade test in on-piece-pair-link-broken.test.ts.
2. TOROIDAL CYCLE: wrap-all sliding rays cycle every 8 squares (queen on a1
loops back to a1 going horizontally). Added 7-cell cycle guard in
slidingSquares matching BASE_RANGE; king's extended-reach mode uses a
Set<Square> per ray to detect re-visits.
5 NEW RECIPES (W4.8\u2013W4.9):
Batch K \u2014 topology:
- tpl-pacman-style-cross-ref \u2014 modifier-shaped equivalent of wrap-board preset;
cross-references RULES.md#wrap-board in summary
- tpl-bouncing-ricochet \u2014 first multi-armed recipe in codebase: activation
seeds wrap-files, expire arm reverts to standard
Batch L \u2014 pairing:
- tpl-down-with-the-ship \u2014 white king linked to all white rooks; killing
the king cascade-destroys both rooks
- tpl-soul-link \u2014 cross-color knight linking; either dies, both
die (SIMPLIFIED: link ALL white knights to ALL
black knights since recipe library has no
per-piece pick mechanism in activation arms)
- tpl-hot-drop \u2014 spawn 2 white queens at e4+d4, link them;
killing one cascade-destroys the other
(SIMPLIFIED: hardcoded queens at d4/e4 \u2014
place-piece pieceType/color/square strict)
TEST SURFACE:
- util/topology.test.ts: 14 unit tests
- rules/topology.test.ts: 30 boundary tests across 6 piece
types \u00d7 3 topologies
- set-board-topology.test.ts: 9 unit tests
- link-pieces.test.ts: 9 unit tests
- unlink-pieces.test.ts: 8 unit tests
- on-piece-pair-link-broken.test.ts: 11 unit tests
- wave4-recipes-real.test.ts: 22 runtime tests
- wave4-topology-pairing.spec.ts e2e: 7 tests (5 load + 2 runtime,
including PredictionManager attr
probe + DOM piece visibility for
the linked-queens spawn)
bun run check: 3192 tests pass (was 3081, +111). 0 regressions.
e2e: 7/7 green via .sisyphus/scripts/run-pw.sh against docker compose dev stack.
BACKWARD-INCOMPAT TESTS UPDATED (per locked decision J):
- registry-count.test.ts: 52 \u2192 56 (4 new primitives)
- ParamField.snapshot.test.tsx: SAMPLE_PARAMS exhaustiveness for 4 new kinds
- wave3-recipes-real.test.ts: count assertion widened toBe \u2192 toBeGreaterThanOrEqual
Plan: .sisyphus/plans/thressgame-100.md
Notepads: .sisyphus/notepads/thressgame-100/
Evidence: .sisyphus/evidence/thressgame-100-wave4.txt (gitignored, 1076 lines)
Wave 3 of thressgame-100 epic complete. 85 % MILESTONE HIT.
Coverage: 37/51 \u2192 44-45/51 = 86-88 % (depending on overlap accounting; both
clear the 85 % gate).
W3.0 AUDIT \u2014 request-choice capabilities verified:
- 6 supported kinds (Zod schema): rps | piece | square | column | row | coin-flip
- (NOT yes-no, NOT number \u2014 plan brief was inaccurate; updated learnings.md)
- All 6 wired through schema \u2192 apply() \u2192 RequestChoiceModal.tsx \u2192 unit tests
- No gaps to fix.
8 NEW RECIPES (W3.2\u2013W3.5):
Batch G \u2014 choice-driven spawn (kind: square):
- tpl-bottomless-pit \u2014 pick a square; permanent pit there
- tpl-call-down-lightning \u2014 pick a square; death-square spawns there
(SIMPLIFIED: lethality moved to consumer arm
\u2014 destroy-piece needs entity-id not square)
- tpl-portal-storm \u2014 pick 2 squares; spawn a linked portal pair
Batch H \u2014 choice-driven swap:
- tpl-anti-camping-choice \u2014 pick victim + swapper; swap them
(SIMPLIFIED: random swap not expressible \u2014
with-probability gates per iteration not
picks one)
- tpl-two-kids-trenchcoat \u2014 sacrifice 2 pieces; bishop@e4
(SIMPLIFIED: place-piece pieceType/color/square
hardcoded \u2014 strict literal enums)
Batch I \u2014 choice-driven self-modification:
- tpl-blood-sacrifice \u2014 sacrifice one piece; +5 Hp to another
(uses W1.6's add-to-attribute.target redirect)
- tpl-summoning-ritual-light \u2014 sacrifice + 50/50 knight-or-bishop@e4
(SIMPLIFIED: hardcoded type/color/square +
no resource cost \u2014 W5 territory)
Batch J \u2014 sophie's-choice:
- tpl-sophies-choice \u2014 both players pick own piece; both die
(forPlayer:'both' verified working as in
tpl-mr-freeze)
FOUR DOCUMENTED SIMPLIFICATIONS (full rationale in evidence file Section 4):
- tpl-call-down-lightning: lethality dropped (no Position-comparison primitive)
- tpl-anti-camping-choice: random-swap dropped (with-probability per-iteration
semantics)
- tpl-two-kids-trenchcoat: place-piece hardcoded (strict literal enums)
- tpl-summoning-ritual-light: hardcoded place + RNG branch (no resource yet)
KEY RUNTIME DISCOVERY (documented in learnings.md):
- runPrimitives catches SuspendedExecution INTERNALLY and returns; does NOT
re-throw. Test pattern is to read PendingChoices off GAME_ENTITY after the
call rather than asserting throw.
- For multi-step request-choice e2e: poll on data-choice-id flip rather than
visibility (modal close+reopen is sub-frame). Canonical idiom for future waves.
TEST SURFACE:
- wave3-recipes-real.test.ts: 26 unit tests (60 expect calls)
- recipes.test.ts: 5 \u00d7 54 = 444 expect calls
- wave3-choices.spec.ts (Playwright): 11 e2e tests (8 load + 3 runtime,
including FIRST multi-step request-choice
runtime test \u2014 portal-storm 2-step
square picker with poll-on-data-choice-id
assertion idiom)
bun run check: 3081 tests pass (was 3055, +26). 0 regressions.
e2e: 11/11 green via .sisyphus/scripts/run-pw.sh against docker compose dev stack.
ANTI-CAMPING OVERLAP NOTE:
Both tpl-anti-camping (W2 dormant variant) and tpl-anti-camping-choice (W3
choice variant) map to the single upstream ThressGame rule `anti_camping`.
This is intentional \u2014 two different mechanical interpretations of the same
rule name. Documented in evidence file with dual coverage accounting:
- 45/51 = 88 % (recipe-vs-denominator convention, matches plan target)
- 44/51 = 86 % (strict unique-rule convention)
Both clear the 85 % milestone.
Plan: .sisyphus/plans/thressgame-100.md
Notepads: .sisyphus/notepads/thressgame-100/
Evidence: .sisyphus/evidence/thressgame-100-wave3.txt (gitignored, 832 lines)
T85: Wired Wave 12 move-gen attrs into engine.ts:getAllLegalMoves (the path the drag UI actually uses):
- BlockAllExceptKing (game-level early-return)
- BlockedPieceTypes (game-level early-return)
- MovesAs (per-piece substitution via lookupMoveGenerator)
- MovesAlsoAs (additive; deduped via dedupeMoves helper)
- MoveClassRestriction (post-filter on the entire move set)
Previously these attrs only filtered rules/turn.ts:getLegalMovesForPiece, but the production drag path goes through engine.ts. Now both paths apply identical filters.
T86: engine.ts:applyMove now honors isPawnPush:
- pushedPieceId moved to pushedTo (defender shoved forward)
- pawn moves to diagonal target square (no capture retract)
- HasMoved set on pawn
- Hook firing + turn advancement preserved
5 fixmes lifted in move-gen-attrs.spec.ts (MovesAs, MovesAlsoAs, BlockedPieceTypes, MoveClassRestriction, PawnPushesPiecesEnabled).
1 fixme lifted in orphan-primitives.spec.ts (must-class consumer now active).
E2E status: 30/30 thressgame-coverage tests PASS. 0 fixmes. 0 skips.
Unit tests: 2866 -> 2868 (+2 from new applyMove unit tests). bun run check exit 0.
Final Verification Wave found two real blockers:
1. T58 RequestChoiceModal.tsx was marked complete but did NOT exist on disk.
2. request-choice locked 6-kind enum was shipped as 5 (missing 'coin-flip').
Remediation:
- Build RequestChoiceModal.tsx with role=dialog, aria-modal=true, ESC/backdrop close, kind-specific input UI for all 6 kinds (rps / coin-flip / piece / square / column / row); 4 tests
- Add 'coin-flip' to:
- request-choice primitive paramsSchema enum
- PendingChoice.kind union (schema.ts + util/pending-choices.ts)
- WS protocol ChoiceKindSchema (server/protocol.ts)
- choice-timeout.firstDefaultForKind (defaults to 'heads')
- broadcast.isValidChoiceValue (accepts 'heads' | 'tails')
- AutoChoiceResolver: deterministic alternating heads/tails for coin-flip
T68 e2e tests remain .skip()'d pending UI integration (modal-into-GameView wiring + activate-descriptor UI) — a follow-up task. The sentinel test asserts the gap exists so when integration lands, skips lift in the documented order.
Tests: 2740 -> 2744 (+4). bun run check exit 0.
Replaces the original single-flow stub with a comprehensive suite
that exercises every user-facing behaviour of the visual authoring
surface against a live Vite dev server. 11 tests run in 23s.
Scenarios:
1. Mode toggle persists across reload
Opens editor, toggles to Visual, verifies aria-pressed state +
localStorage key, reloads, confirms Visual is still active on
the next mount.
2. Palette click adds top-level primitive to block list
Clicks palette-btn-on-turn-end, verifies block-card-on-turn-end
appears with matching aria-label and the narrative preview
mentions "turn end". Asserts via aria-label rather than visible
text so the open inspector docs do not cause strict-mode matches.
3. Clicking × removes the block without triggering a drag
Adds three blocks, clicks the × button on the middle one,
verifies it is gone AND that dnd-kits assertive announcer never
reported "Picked up sortable item" — direct regression for the
drag-handle isolation fix.
4. Clicking expand toggles the block without triggering a drag
Asserts aria-expanded flips from false to true on click without
the card being removed or reordered.
5. Selecting a trigger makes palette clicks add children
Adds on-turn-end, selects it, verifies palette-add-target-banner
appears with the parent label, then clicks add-to-attribute and
asserts there is exactly one add-to-attribute block AND it is
a descendant of block-card-on-turn-end.
6. "Add at top level instead" resets the nested-target selection
After entering nested-add mode, clicks the escape button and
verifies subsequent palette adds are top-level siblings.
7. × on a nested child removes only that child
Verifies nested removal leaves the parent intact.
8. Preview narrative reflects tree mutations immediately
Adds primitive and checks narrative; removes and checks narrative
no longer mentions the seeded attribute.
9. Save → reload → load preserves the composed descriptor
Fills inspector fields (attr=Hp, delta=1), saves, reloads,
confirms Visual mode is remembered, loads from library, verifies
inspector value survived the round-trip.
10. Depth-4 descriptor surfaces validation banner + disables save
Pre-seeds localStorage with a depth-4 descriptor (conditional
→ on-capture → on-damaged → conditional → add-to-attribute),
loads it, verifies the validation banner renders and the Save
button becomes disabled.
11. Toggling Form ↔ Visual preserves the composed descriptor
Composes a tree, captures the JSON preview, toggles to Form and
back to Visual, verifies JSON preview is byte-identical.
The spec uses data-testid selectors exclusively where possible,
falls back to aria-label for the block card outer <article>, and
uses click({ position }) to land on the card header (avoiding the
× / expand / grip / inspector overlays).
Tiny preview-pane data-testid added for Playwright targeting (T25
setup), plus an initial e2e spec file covering the visual-mode
authoring flow — to be expanded in T25.
Spec covers happy path: open editor, toggle to Visual, add on-move
from palette, configure nested add-to-attribute, verify preview
narrative renders. Real runtime execution against the chess dev
server is Wave 4 work.
Profiles can now carry a list of PresetActivation entries alongside
their per-type / per-instance modifiers. When such a profile is
picked in the Lobby, its bundled presets are unioned with any
layout suggestedPresets (profile config wins on id-collision).
Changes:
- ModifierProfile.presetActivations added (optional readonly array).
Zod schema + server wire schema mirror the field; drift guard
picks up forgotten updates on either side.
- ModifierProfileEditor grows a Presets tab in the right column
sharing space with the Library tab. Each preset row carries a
checkbox, scope radio (both/white/black), and a turns counter
(blank = permanent). Inline diagnostics warn on redundant layout
overlap and on loose-scope incompatibility; hard errors under
overlapping scope disable Save.
- Lobby merges profile.presetActivations into its active preset
set on profile select, on editor close, and on URL deep-link.
- LayoutPicker suggested-preset chips now expose aria-pressed so
the active state is readable by assistive tech + e2e tests.
Tests: library round-trip preserves presetActivations (unit); two
new e2e scenarios (pre-seeded bundled profile auto-activates; full
editor-author loop persists + reflects in the lobby). 1752 unit +
105 playwright all green.
Clicking a square with the palette's currently-selected piece now
deletes that piece instead of re-placing it. Makes tap-to-delete a
natural single-gesture operation without switching to the Erase
brush. A different brush-piece still replaces (unchanged behaviour).
Previously the ModifierProfileEditor's layout picker was editor-only
UI state — it drove per-instance board preview and live validation,
but was dropped on save. This meant per-instance modifiers (square-
bound to their authoring layout) silently became orphans in the Lobby
if the user picked a different layout at apply time, with no signal
about the mismatch.
Changes:
- ModifierProfileEditor now writes the bound layout through to
profile.layoutId (schema already supported the optional field) and
rehydrates boundLayout from profile.layoutId on open / load /
undo / redo.
- Lobby rearranged so the Modifier Profile picker sits ABOVE the
Layout Picker. Picking a profile with a layoutId binding snaps
selectedLayout to match. Same behavior on URL ?modifierProfile
deep-links and after the editor closes with a new save.
- Mismatch banner (amber) surfaces when the user overrides the
layout after picking a bound profile, with a one-click "Switch
to <LayoutName>" restore.
Unit test added for library round-trip of layoutId; new
profile-layout-binding.spec.ts covers the four scenarios: snap,
manual override + mismatch banner, unbound profile leaves layout
alone, and editor-save persists layoutId.
Attr-string fields in the Custom Modifier Editor now differentiate
between declare-sites (seed-attribute.attr) and consume-sites
(add-to-attribute.attr, multiply-attribute.attr, add-aura.targetAttr,
absorb-damage-with-attribute.attr):
- Consume-sites hide the illustrative 'User-defined examples' group
(ArmorPlates/BloodStacks/ManaPool) because those names are fiction
unless something seeds them.
- Consume-sites surface a new 'Seeded in this descriptor' group
populated from seed-attribute primitives elsewhere in the current
tree (including inside trigger children via childPrimitives).
- Badge states: emerald 'seeded' when the typed value matches an
in-tree seed; red 'not seeded' when it's a non-schema name with no
backing seed; amber 'user-defined' only in declare-mode for
off-catalog names.
Declare-mode behaviour is unchanged — inventing ShieldCharges there
still works without warnings.
Surfaces the contents of docs/user/custom-modifiers.md directly inside
the Custom Modifier Editor so authors can compose descriptors without
cross-referencing the guide:
- Per-primitive docs panel in the Parameter Inspector with a longer
behaviour explanation + one or more worked examples (collapsible).
- Palette hover tooltips now show the full long description plus the
first example's headline.
- New 'Templates' header button opens a picker with 5 built-in recipes
(Boosted Pawn, 3-Charge Shield, Aura King, Vampire, Low-HP Fortress).
- AttrCombobox replaces plain text inputs for attr / targetAttr fields.
Grouped, free-form autocomplete over 17 curated suggestions with a
'user-defined' badge for out-of-catalog typed names so ShieldCharges-
style recipes still work.
Primitives gain optional longDescription + examples fields on their
EffectPrimitive descriptor; 15 registrations annotated. Recipe
descriptors pass the existing validator, and new unit tests enforce
doc coverage going forward.
Feature 2 of post-epic-deferrals. Exposes extinction-chess's
configurable targetType through the in-game rules drawer so players
don't need to open devtools or call engine.presetState themselves.
UI:
- RulesDrawer.tsx renders a 'Target: <PieceType>' chip inside the
extinction-chess detail card when the preset is active.
Clicking advances through pawn -> knight -> bishop -> rook ->
queen -> king -> pawn (wraps). Plural labels ('Pawns', 'Knights',
...) for prose.
- data-testid='extinction-target-cycler' on the chip for e2e.
- New optional RulesDrawer props extinctionTarget +
onExtinctionTargetChange; omitted props hide the cycler (no
hard dependency on the engine).
Wiring (GameView.tsx):
- Solo-only per plan decision 2a. Multiplayer games use the
target set at room-creation time; the cycler doesn't render in
MP to avoid desync (a future preset-config.update WS message
could lift this; out of v1 scope).
- Local useState syncs with engine.presetState via a useEffect;
setExtinctionTarget writes back through the same state API and
calls refresh() so legal highlights + terminal-state panels
pick up the target flip.
Docs:
- extinction-chess.ts docblock updated to reference the shipped
UI surface + the MP deferral.
- PRESET-API.md post-landing backlog: remove the 'UI cycling'
deferral (now shipped), add the MP-target-sync deferral.
Tests:
- 2 new rule-variants.spec.ts cases: (a) cycler cycles through
all 6 labels when preset active, (b) cycler hidden when preset
inactive.
Verification: 1663 unit + 89/89 e2e (87 + 2 new). Typecheck + lint
clean.
Plan: .sisyphus/plans/post-epic-deferrals.md Feature 2 complete.
Feature 1 of post-epic-deferrals. Lets the room creator pick which
color they play: white, black, or random. Joiner always takes the
remaining color (no joiner-side preference in v1 per plan decision
1b).
Protocol:
- RoomCreatePayloadSchema gains an optional preferredColor field
with the three-value enum. Omitting the field defaults to
'white' on the server — byte-identical to pre-F1 behaviour so
legacy clients are untouched.
- Client type mirror (packages/chess/src/net/types.ts) kept in
sync; exports PreferredColor type alias.
Server:
- RoomRegistry.createRoom gains a preferredColor parameter.
'random' is resolved at room creation via Math.random() and
never leaks beyond this function — the concrete color is stored
on room.creatorColor + room.joinerColor so reconnects surface
the same assignment.
- Room interface adds creatorColor + joinerColor fields.
- JoinResult success variant widens from 'color: "black"' to
'color: Color' to accept either assignment.
- broadcast.ts threads payload.preferredColor through to
createRoom.
UI:
- Lobby.tsx adds a 3-button radiogroup ('Play as: White / Black /
Random') between LayoutPicker and the modifier-profile picker.
Active button is filled (bg-neutral-900), inactive is ghost.
Omits the field from the room.create payload when left at the
default so old servers keep working.
- data-testid='color-preference-{white,black,random}' for e2e.
Tests:
- 7 new protocol.test.ts cases: each enum value accepted,
omitted valid, invalid strings rejected, composition with
existing fields.
- 5 new rooms.test.ts cases: back-compat default, explicit
white, explicit black, random distribution across 40 samples,
random-resolved color stored idempotently.
- 4 new multiplayer.spec.ts cases: host=black flow, host=random
disjoint-color assertion, back-compat no-field flow, UI
buttons render + toggle with correct aria-checked state.
Verification: 1663 unit tests (+12) + 87/87 Playwright (+4).
Typecheck + lint clean across chess + server.
Plan: .sisyphus/plans/post-epic-deferrals.md Feature 1 complete.
Phase F.4 of the rule-variants epic.
Three end-to-end scenarios covering the full lobby -> game flow:
1. knightmate: selecting the knightmate layout surfaces a
'Suggested rules' chip for knightmate-rules in LayoutPicker;
tapping activates the preset; Play Solo loads the game with
no console errors; a pawn push resolves normally.
2. double-move: in-game rules drawer shows a 'Multi-move'
category section (Phase F.3 grouping); toggling double-move
ON makes white play two consecutive half-moves before the
turn flips to black, verified by successful drags of two
white pieces followed by a black piece drag.
3. suicide-chess: after establishing a capture opportunity
(1. e4 d5), toggling suicide-chess on via the in-game rules
drawer. White's next move: a non-capture (a2-a3) is
rejected by filterLegalMoves; the compulsory capture
(e4xd5) succeeds.
Scenarios 2 and 3 toggle the preset via the IN-GAME drawer
(lives in GameView.tsx) rather than the lobby — Lobby.tsx has
no rules drawer; only the layout-picker chip path is available
pre-game. Scenario 1 exercises the chip path. Deferred:
lobby-side drawer is a follow-up if richer pre-game preset
activation UX is desired.
Tests: 1651 unit + 3 new e2e = 4-test file added to e2e suite.
All 3 pass.
T3 audit gap 2 (CRITICAL). The server's Room kept registered custom
modifier descriptors in a per-room Map but the game.state snapshot
carried no field for them. Impact:
- Client A registers 'custom:shield' → server broadcasts
custom-modifier.registered → A + any currently-connected B see it.
- Client C joins AFTER the registration → receives game.state →
has no knowledge of 'custom:shield'.
- Client C's engine applies a profile with kind='custom:shield' →
registry-dispatch fallback silently no-ops → apparent cosmetic
modifier mismatch between A/B and C.
Symmetric fix across the wire:
- GameStatePayloadSchema (server + client types) gains an optional
customModifiers: CustomModifierDescriptorWire[] field.
- Both emit sites in broadcast.ts (late-joiner path +
reconnect-with-buffered-deltas path) include the room's registered
descriptors.
- PredictionManager.applyFullState mirrors received descriptors
onto the fresh engine's customModifiers registry before handing
control to the UI. Unknown descriptor shapes are accepted as-is
(the wire-shape cast at the single boundary bridges the Zod v3/v4
type split same as the custom-modifier.registered subscriber).
E2E regression guard (Oracle Q4.1 recommendation): new scenario
'late-joiner + reconnect receive registered custom modifiers in
game.state'. Host creates + registers, opponent joins AFTER
registration, asserts opponent's game.state carries the descriptor.
Would have caught the pre-fix behaviour as a test failure instead of
a manual audit find.
1393 unit + 19/19 custom-modifiers e2e green.
Threads the multiplayer publisher all the way from useMultiplayerGame
down through GameView → RulesDrawer → ModifierProfileEditor →
CustomModifierEditor, surfacing a Share with Room button in the
custom modifier editor when (and only when) the editor was opened
from a multiplayer game.
Wiring summary (top-down):
- useMultiplayerGame.ts: returns sendRegisterCustomModifier(descriptor),
a thin wrapper around the GameClient.sendRegisterCustomModifier
helper added in the previous commit.
- useMultiplayerGame.ts: onError handler surfaces CUSTOM_MODIFIER_INVALID
and CUSTOM_MODIFIER_LIMIT as toasts on top of the existing in-game
error banner so the user notices the rejection immediately.
- GameView.tsx: GameEngineState gains an optional
sendRegisterCustomModifier field; the multiplayer destructure
pulls it out and passes it to RulesDrawer as
onShareCustomModifierWithRoom (omitted in solo, where the prop is
undefined and Share UI doesn't render).
- RulesDrawer.tsx: optional onShareCustomModifierWithRoom prop;
conditionally forwards to ModifierProfileEditor.
- ModifierProfileEditor.tsx: optional onShareCustomModifierWithRoom
prop; conditionally forwards to CustomModifierEditor as onShareWithRoom.
- CustomModifierEditor.tsx: when onShareWithRoom is provided, renders
a green Share with Room button in the header alongside Save. Click
invokes the publisher with the current descriptor; toast confirms
the share landed (server broadcast is the actual proof, observed
by the local PredictionManager subscriber registering the descriptor
on the engine's customModifiers registry).
E2E coverage (both formerly-fixme tests now PASS):
- multiplayer custom modifier sharing — both clients see the
registered descriptor: opens two browser contexts via raw WS
(matches modifier-profiles.spec.ts MP pattern), host registers a
descriptor after both reconnect-by-token complete, both sides
observe custom-modifier.registered.
- server rejects custom modifier with > 50 primitives — error event
observed: host registers a 51-primitive descriptor, asserts an
INVALID_MESSAGE / CUSTOM_MODIFIER_INVALID error is observed and
no broadcast fires.
Final state: 79/79 e2e + 1386 unit tests, zero fixmes, zero skipped.
T3 Wave 5 (T29). New Playwright suite at e2e/custom-modifiers.spec.ts
covering 16 scenarios across the user-facing flows:
- Editor opens from the Modifier Profile editor header
- Palette click adds primitive to tree
- Save button reflects validator state (disabled when name empty)
- Custom modifier appears in PerType kind dropdown
- Selecting a custom kind shows the summary card
- Library survives page reload
- Solo game with custom-kind profile renders modifier indicators
- Multi-profile stack: stack two profiles, remove an entry, reorder
- Aura primitive: page survives onAfterMove recompute
- Library cap holds at 20 entries
Plus 4 trigger primitive scenarios (formerly fixme, unblocked by the
trigger evaluator wiring committed alongside):
- on-turn-start nested primitives fire at turn boundary
- on-capture nested primitives fire on capture
- conditional evaluates and runs matching branch
- absorb-damage-with-attribute integrates with damage pipeline
2 fixmes remain — both blocked on the editor-side multiplayer send UI
(server + client wire-side is fully implemented in this commit).
Integration fixes uncovered while writing the suite:
1. ModifierKindIdSchema widened from z.enum([built-ins]) to z.string().min(1).
The pre-T3 enum silently rejected every profile that referenced a
custom modifier id (e.g. 'custom:my-shield'), causing library load
to drop the entry and the picker to have no option. Validity is
now enforced at apply time via the registry-dispatch fallback
(MODIFIER_REGISTRY → engine.customModifiers → warn-and-skip).
2. Lobby.resetToFreshGame now passes loadCustomModifierLibrary()
results to ChessEngine.opts.customModifiers so a profile that
references a custom kind can resolve at apply time. Without this
the apply silently no-opped the custom-kind entries and indicators
never rendered.
Schema tests updated: the 'rejects unknown modifier kind' test flipped
to 'accepts arbitrary kind strings (T3 widening)' with explanatory
JSDoc; an empty-string-rejection test added to preserve the min(1)
guard.
77 e2e + 1386 unit tests green; 2 honest fixmes documented.
If the user played multiplayer earlier in the tab session, room-code,
room-token, and player-color persisted in sessionStorage. Clicking Play
Solo then:
1. navigate('/game') — no code param
2. GameRoute reads sessionStorage, finds stale creds → Case 1
canonicalises the URL to /game/<stale-code>
3. MultiplayerGameView mounts, opens a WS to a dead room, handshake
fails silently → blank white screen with a live URL like
/game/OSJBJY in the address bar.
Fix: handlePlaySolo explicitly wipes room-code, room-token, player-color,
layout-name, and modifier-profile-name before navigating. The solo path
then goes through GameRoute's Case 2 (no code, no creds) and mounts
GameView cleanly.
Regression test in solo-smoke.spec.ts seeds sessionStorage with stale
MP creds, clicks Play Solo, and asserts:
- URL settles on /game (not /game/<stale>)
- No 'mp-joining' placeholder
- Board renders (e2 pawn visible)
- All stale keys are wiped from sessionStorage
- No console errors
Verified the test fails without the fix (Playwright hits the blank
screen / Joining placeholder) and passes with it.
The hover tooltip previously rendered on every piece regardless of
whether it had any modifier facts, showing just a piece-type header and
'No active modifiers' — noise with zero information the user can't
already see on the board.
Now returns null when there are no modifier rows. The pinned panel
(click-to-pin) keeps its empty-state copy because an explicit pin is a
deliberate inspect action where confirming 'nothing here' is valid.
Tests:
- Inverted the two T24 hover tests to assert the tooltip does NOT render
on unmodified pieces (b1 knight, e2 pawn on a vanilla solo game).
- Added a positive test: hover a modified pawn (HP +1 from a seeded
profile) and assert the tooltip + at least one row are visible.
P6 (source chain in pinned panel):
Required two server-side changes to make the badge actually meaningful:
- Add `profile` field to GameStatePayload schema (server emits it,
client receives it) so multiplayer clients see the room's active
profile metadata, not just the modifier facts.
- Make `ChessEngine.activeProfile` mutable via `setActiveProfile()`
so PredictionManager can sync it from `game.state` snapshots.
Also wire `modifier-profile.updated` through GameClient + Prediction-
Manager so hot-swap broadcasts update the engine's profile field
reactively.
Fix Lobby.handlePlaySolo's resetToFreshGame to forward the selected
profile to the new ChessEngine — otherwise the local engine had
modifier facts (via server reconcile) but no profile metadata,
breaking source-chain attribution and any other profile-aware UI.
P7 (multiplayer propose → approve → both observe updated):
P8 (multiplayer propose → reject → no updated broadcast):
Implemented at the WS-protocol level using two parallel raw sockets
per test (mirrors multiplayer.spec.ts pattern). Critical sequencing:
- Both sockets opened concurrently via Promise.all so opponent is
listening BEFORE host's propose arrives at the server (otherwise
proposal-pending broadcasts to nobody and the test deadlocks).
- Token must travel at the envelope level, not in payload, for the
server's reconnect-by-token path to fire (otherwise hits ROOM_FULL
on the second connection from each player).
- game.move payload uses algebraic notation strings ('a2', 'a3'), not
square indices — the protocol schema only accepts strings.
- Host re-uses original room.create token, opponent re-uses their
join token. Server's reconnectManager treats both as grace-window
reconnects since the original WS closed cleanly.
Verification:
- 1231 unit tests pass (96 files)
- 58/58 Playwright tests pass in 1.9 min (was 55 + 3 fixme)
- Total Playwright surface coverage: solo-smoke (7) + multiplayer (2) +
full-flow (1) + layouts (24) + modifier-profiles (24 — including all
8 T2-polish tests, 0 fixme).
Adds 8 Playwright scenarios to modifier-profiles.spec.ts under a new
'T2 polish' describe block:
P1 editor undo/redo across 3 distinct type-modifier adds
P2 copy / paste wire: Copy lights the Paste button with a count
P3 paste-type-modifier disabled when clipboard empty (baseline)
P4 conflict panel: seed an invuln-king profile via localStorage,
bind layout=classic, Load, observe error + Fix clears it
P5 modifier-indicator rendered without hover (create-room path,
with the same no-WS-server test.skip fallback T26 uses)
P6 source-chain in pinned panel — test.fixme; ModifierPinnedPanel
computes row.source but does not render it yet
P7 multiplayer propose->approve e2e — test.fixme; needs a
two-context harness this spec doesn't have today. Protocol
coverage lives at packages/server/src/ws.modifier-profile-
consent.test.ts.
P8 multiplayer propose->reject e2e — same harness gap as P7.
Adds 2 regression tests to solo-smoke.spec.ts:
- Rules drawer: clicking the backdrop (far-left of viewport)
closes the drawer and leaves the board interactive. Regression
guard for the stuck-overlay pointer-events bug.
- Modifier editor: Esc closes the editor but leaves the drawer
open (capture-phase stopImmediatePropagation); a second Esc
then closes the drawer. Documents the nested-Esc ordering
contract and guards against a future change that would cascade
both closes on one keystroke.
Result: 55 Playwright passing, 3 skipped (all documented fixme).
bun run check green.
The T1 ModifierProfileEditor installed a window-level Esc handler that
closed the modal but the RulesDrawer had no Esc handler of its own.
Users hitting Esc with the drawer open (no modal) saw nothing happen;
worse, with both open+modal, closing the modal left the drawer's
pointer-events-blocking backdrop in place, silently breaking all
board drag-interaction afterward.
Fix:
- Add useEffect-based Esc handler to RulesDrawer that closes it when
no nested modal is active.
- ModifierProfileEditor now uses capture-phase + stopImmediatePropagation
so the drawer's Esc handler does NOT also fire on the same keystroke,
preventing double-close.
Add packages/chess/e2e/solo-smoke.spec.ts — 5 regression scenarios
that would have caught this at T1 CI time. Test 4 specifically
reproduces the original bug (drawer open → Esc → drag board pieces).
Also queue 2 additional scenarios in the T2 plan since T2 work extends
both drawer + editor further.
All tests green: 1217 unit tests (94 files), 48 Playwright e2e in 1.3m.
- Create ModifierPinnedPanel.tsx: fixed-position side panel with piece
header, modifier list (label + describe() value), and close button
- Board.tsx: add onPieceClick prop, fire on piece click (distinct from drag)
- GameView.tsx: add pinnedPieceId state; clicking a piece toggles pin;
clicking same piece again or × closes panel; panel renders fixed right-4
- 2 new e2e tests: click b1 pins panel with 'knight' text; × dismisses it
Adds ModifierTooltip component that reads MODIFIER_REGISTRY attrs from
engine.session for the hovered piece and renders them as labelled rows.
The tooltip always appears on piece hover (piece type + color header) and
shows modifier rows only when modifier facts are set on the entity.
Board.tsx gains an optional onPieceHover callback; GameView.tsx tracks
hoveredPieceId and renders the tooltip absolutely in the board wrapper.
A 120ms hide-delay prevents flicker when cursor briefly leaves a piece.
Two Playwright tests added: hover shows tooltip with piece name; hover
over unmodified piece shows zero modifier-tooltip-row elements.
Adds a modifier profile picker next to the layout picker in the Lobby, and a header badge in GameView that surfaces the active profile's name.
Lobby:
- New <select data-testid="profile-picker"> loads entries from loadLibrary() on mount and refreshes when the ModifierProfileEditor closes (auto-selecting the most recently updated entry).
- Selecting a saved profile sets the active ModifierProfile; selecting 'Custom…' opens the existing editor modal.
- URL param ?modifierProfile=<b64> decodes + pre-selects even when the profile isn't in the local library, via a synthetic '<name> (from link)' option so the <select> can reflect the choice without collapsing it.
- handleCreate now sends payload.profile when a profile is selected and stashes modifier-profile-name in sessionStorage.
- handleJoin reads profile from the server's room.joined echo so late joiners see the badge on first paint.
GameView:
- New ModifierProfileBadge component mirrors LayoutBadge but reads modifier-profile-name from sessionStorage and uses fuchsia tones so it's visually distinct when both badges are present.
lobby-request.ts:
- OneShotRoomResult exposes the optional profile field the server now echoes (T19).
E2E:
- 2 new Playwright tests: 'create room with profile — badge shows in game' seeds the library via localStorage, selects the profile, creates the room, and asserts the badge text. 'URL pre-select loads profile in picker' base64-encodes a profile into ?modifierProfile= and verifies the picker shows the correct value + 'from link' synthetic label.
All 8 modifier-profiles e2e tests pass; bun run check green (1213/1213 unit tests).
Adds ModifierProfileEditor modal shell with 3 placeholder panels
(T21 catalog / T22 board preview / T23 profile list). Esc closes
the modal via a window keydown listener active only while isOpen.
Wires a 'Modifier Profiles' button into the RulesDrawer footer that
opens the editor. Adds e2e/modifier-profiles.spec.ts with 2 tests:
open-from-drawer and esc-to-close.
Previously the FEN textarea held an independent draft that only
synced to the board when the user clicked Reset. Placing a piece
left the FEN showing stale content, which was confusing — the
field looked like a proxy for the board but wasn't.
Now the textarea mirrors the live board FEN by default:
- Placing, erasing, or clearing pieces updates the textarea
immediately.
- Starting to type into the textarea marks it 'dirty' (via a ref
so we don't rerender), pausing the auto-sync until the user
Loads (accept the draft) or Discards (restore the live FEN).
- The 'Unsaved edit' indicator appears while dirty.
- Load / Discard buttons disable when draft equals live FEN —
nothing to apply.
- Library load also resets the dirty flag, as that's a clean
state reset.
- Removed the redundant 'Current: <fen>' helper line below the
textarea; the textarea itself is the live FEN now.
E2E: 2 new tests
- FEN field updates live as pieces are placed.
- Typing into FEN field pauses live sync until Load or Discard.
25/25 Playwright tests passing. 1025 unit tests green.
The Empty layout had no real user need:
- Can't Play Solo (board with no pieces, nothing to click).
- Server rejects it for Create Room (validator requires >=1 king
per side).
- The 'blank canvas' use case is already handled by the
LayoutEditor's Custom... flow, which opens with an empty piece
list and lets the user compose.
It was UI clutter in the picker dropdown — users would see
'Empty Board' alongside real layouts and have no way to actually
use it.
EMPTY_LAYOUT stays exported for unit tests that need a zero-piece
starting state, but it no longer registers in LAYOUT_REGISTRY, is
not imported by the layouts barrel side-effects, and no longer
appears in the picker. Source flipped to 'custom' to signal it's
not a user-selectable premade.
Tests updated:
- premades.test.ts asserts 'empty' is NOT in the registry.
- e2e/layouts.spec.ts removes the Empty-solo test and asserts the
'empty' option is absent from the picker dropdown.
1025 unit tests + 23 e2e tests green.
Covers gaps in the original Phase E spec:
- Solo play reaches the engine: picking Pawns-Only and Classic and
asserting the rendered board matches the layout's piece placement
(not just that the UI dropdown says so).
- Empty layout solo: documents current behavior (solo lets users
poke at any layout, validator only gates multiplayer).
- Chess960 re-randomizes: takes 8 consecutive snapshots of the
back rank and asserts they're not all identical (p(collision)^7
is effectively zero).
- Valid ?fen query pre-selects Custom (inverse of the existing
malformed-FEN test).
- Library operations: full save → star → unstar → delete round
trip via the library drawer's aria-labeled buttons.
- Layout badge hidden for classic solo games.
- Multiplayer with Dunsany: full pipeline proof — picker →
Create Room UI → server resolves + validates → room.created
echo → joiner renders same Dunsany setup via room.joined echo.
Compares rank-1 and rank-8 snapshots between two browser
contexts to verify bit-identical rendering.
- Server-side rejection: sends a kingless custom layout via raw
WebSocket and asserts LAYOUT_INVALID error with a human-readable
king-related message.
New server-spawn block mirrors multiplayer.spec.ts so the layouts
tests can run in isolation or against an existing dev server.
24/24 Playwright tests passing (21 layouts + 2 multiplayer +
1 full-flow) in ~40s.
- LayoutEditor: move Esc handling to a window keydown listener so
the modal closes regardless of where focus currently sits (the
prior onKeyDown on the modal div only fired when the root div
itself held focus).
- LayoutPicker: add data-testid on the description <p> so e2e
assertions can target it unambiguously instead of relying on
free-text matches that also select the hidden <option> labels.
- e2e: use the new testid.
All 12 layouts e2e tests pass; existing multiplayer + full-flow
e2e suites still green.
Adds a full in-browser editor for authoring custom starting
layouts and a persistent library to save them across sessions.
persist/layout-library.ts:
- SavedLayout shape with id/name/pieces/starred/updatedAt.
- saveToLibrary / loadLibrary / deleteFromLibrary / setStarred /
duplicateEntry / makeId helpers.
- Capacity cap at 20 entries; oldest non-starred is evicted on
overflow; all-starred + full returns { ok: false, reason }
so the UI can surface an actionable message.
- Localstorage key is versioned (houserules:layouts:v1) for a
future migration path.
- 14 unit tests cover eviction, shape validation, star toggles,
duplicate flow, and the crypto.randomUUID fallback.
ui/LayoutEditor.tsx:
- Modal overlay with three panels — palette (white/black pieces +
Erase + Clear), interactive 8x8 board with click-to-place
brushes, and an actions panel.
- Live FEN textarea (toFen/fromFen round-trips) with a Load
button that replaces the board and a Reset-to-board sync.
- Live validation panel shows errors (block CTA) and warnings
(inform but don't block). The 'Use This Layout' CTA is disabled
until errors clear.
- Save to Library writes a SavedLayout; the integrated Library
drawer lists saved layouts sorted by starred-first + most-recent,
with Load / Star / Duplicate / Delete actions.
- Copy Share Link writes a \${origin}/?fen=...&name=... URL to the
clipboard — pastes straight into the lobby's existing query-param
pre-select flow from Phase D.
- Esc closes the modal.
ui/Lobby.tsx:
- Custom... entry in the layout picker opens the editor.
- onApply(layout) commits the custom layout as the lobby's
current selection so Create Room ships it to the server.
e2e/layouts.spec.ts:
- Picker renders every premade + Custom entry.
- Selecting Dunsany updates description; ?layoutId=dunsany and
malformed ?fen behave correctly.
- Editor opens on Custom, validates king count, erases pieces,
loads FEN, commits via 'Use This Layout', saves to library
with cross-reload persistence, closes on Esc.
1025 unit tests passing; bun run check clean. Playwright suite
requires dev server — run with \`bun run --filter @paratype/chess e2e\`
when needed.
Board now renders three visual states during a drag: faint dot for
legal quiet-move targets, ring for legal capture targets, and a bright
emerald fill when the cursor is actually over a valid drop square so
the user sees exactly where the piece will land. Hovering an invalid
square shows a subtle red tint telling the player the drag will snap
back on release.
Turn indicator shows "Your turn" (with a pulsing emerald dot and
green card treatment) when it`s the local player`s turn in
multiplayer, and "Opponent`s turn" otherwise. Solo play falls back
to the neutral "White`s turn" / "Black`s turn" phrasing.
Presets previously lived on a process-global singleton with only a
binary on/off toggle. Two bugs followed:
1. Multiplayer illegal-move errors — the client-side toggle didn`t
reach the server, so optimistic moves legal under client rules got
rejected by the server`s unmodified ChessEngine.
2. No way to apply a rule to just white or just black, or to time-box
it for N turns.
Replaces the shared `PRESET_REGISTRY.active: Set<string>` with
instance-owned `ChessEngine.activePresets: ActivePresetSet`. Each
activation carries:
- scope: `both` | `white` | `black`
- turnsRemaining: positive int or null (permanent)
Engine reads `getForColor(color)` per piece, so scope=white never
contributes moves during black`s turn. `applyMove` calls
`tickAfterMove(moverColor)` which implements player-local counting:
white-only durations tick only when white moves.
Compatibility is the LOOSE rule — `incompatibleWith` blocks only when
the two activations have overlapping scopes. `scope=white` + `scope=black`
pair of otherwise-incompatible presets is allowed because the engine
never evaluates both for the same side.
Server changes: GameSession owns an ActivePresetSet. New protocol
messages:
- client → server: `room.setPresets` with full activation list
- server → client: `game.presets` broadcast on every set change
(post-setPresets + post-move-with-expiry)
`game.state` snapshots now include `activations` so reconnects pick
up the current rule set without extra round-trips.
Client changes: PredictionManager applies `game.presets` to the base
engine`s ActivePresetSet and re-renders via onStateChange; cloneEngine
carries activations onto the predicted clone. New hook surface:
- activations: readonly PresetActivation[]
- setPresets(next): replace the active set
useMultiplayerGame dispatches setPresets through the socket
(server-authoritative); useChessEngine mutates in-place (local mode).
UI: RulesDrawer + RulesView render scope radios (Both/White/Black)
and a duration input per active preset. Empty duration means
permanent, positive integers last N player-local turns.
Tests:
- 15 new ActivePresetSet unit tests (scope, tick, loose compat,
atomicity, clone)
- 4 new engine-presets integration tests (per-color, duration,
white-only vs black-only)
- Migrated older preset tests from `PRESET_REGISTRY.activate` to
the instance API
- New E2E regression test: enable knights-leap-twice scope=white in
multiplayer; verify the double-leap is accepted by the server,
verify black`s knight cannot use it
Previously, GameView used a local ChessEngine regardless of whether the
user was in a multiplayer room. Moves were never sent to the server and
the opponent only saw updates on full page reload.
Introduce useMultiplayerGame, a React hook that wraps GameClient and
PredictionManager and exposes the same shape as useChessEngine. App
reads sessionStorage once at mount of /game and dispatches to either
MultiplayerGameView (server-backed) or GameView (local) accordingly.
Board now accepts myColor to gate drag by piece ownership in addition
to turn, so black pieces never become draggable on white`s board and
vice versa.
Rewrites the multiplayer E2E to actually validate live sync: each drag
on one page is asserted to appear on the opposite page before the next
move. The previous test drove both colors from one page because the
GameClient wiring was missing; that workaround is no longer needed.
