frankenbit/cellblock

Fork 0

Feature: Esc aborts running game (mid-play exit to title, Herald design conversation) #87

New issue

Closed

opened 2026-06-22 13:10:09 +02:00 by bosun · 4 comments

bosun commented

2026-06-22 13:10:09 +02:00

Owner

Suggestion (operator-surfaced 2026-06-22)

Suggested by operator after playtest of round-11: "It may also be reasonable to be able to abort any running game via escape."

Currently Esc returns from the various menu screens (welcome, name-entry, etc.) but not from an active game. A player mid-play has no keyboard way to exit and return to the title without forfeiting via game-over.

Feature shape (Herald creative-head territory)

UX questions for design conversation:

Confirmation prompt before abort, or instant?
Score handling on abort — does the partial score count? Submit to leaderboard? Discard?
Solo vs versus semantics:
- Solo: instant Esc → title with score discard is straightforward
- Versus: Esc-during-match is functionally a forfeit — affects the opponent's match state, leaderboard standings, lobby return, etc.
Visual feedback: confirmation banner, brief "ABORTED" overlay before transition, or silent?
Mobile equivalent: a touch-screen player has no Esc; an in-game UI Quit button is the natural equivalent. Should both ship together or sequenced?

Lane + size

Herald creative-head call on UX shape + confirmation flow.
Shipwright lane on state-machine implementation (game→title cancel transition) once shape is settled.
Engineer lane only if versus-forfeit semantics require server coordination (likely).

Size unclear pending design conversation.

Acceptance criteria (to be refined per Herald design)

Player can abort an active game via keyboard (Esc on desktop) and return to title
Mobile equivalent (Quit button) ships per Herald's decision on sequencing
Solo vs versus semantics defined + implemented
Confirmation prompt / instant abort per Herald's UX call
Harness #81 extended with game→title cancel-transition rows for the chosen shape
No regression on normal game-over → leaderboard-entry path

Cross-refs

cellblock#79 (similar Esc-back pattern on menu screens, already addressed)
cellblock#85 (Scanning-the-yard Esc gap, same family of state-machine cancel-transitions)
Discipline-instance: features beyond bug-fix scope warrant design conversation before dispatch

Anchor

2026-06-22 operator playtest. Filed for Herald creative-head design conversation before implementation dispatch.

## Suggestion (operator-surfaced 2026-06-22) Suggested by operator after playtest of round-11: "It may also be reasonable to be able to abort any running game via escape." Currently Esc returns from the various menu screens (welcome, name-entry, etc.) but not from an active game. A player mid-play has no keyboard way to exit and return to the title without forfeiting via game-over. ## Feature shape (Herald creative-head territory) UX questions for design conversation: 1. **Confirmation prompt** before abort, or instant? 2. **Score handling** on abort — does the partial score count? Submit to leaderboard? Discard? 3. **Solo vs versus semantics**: - Solo: instant Esc → title with score discard is straightforward - Versus: Esc-during-match is functionally a **forfeit** — affects the opponent's match state, leaderboard standings, lobby return, etc. 4. **Visual feedback**: confirmation banner, brief "ABORTED" overlay before transition, or silent? 5. **Mobile equivalent**: a touch-screen player has no Esc; an in-game UI Quit button is the natural equivalent. Should both ship together or sequenced? ## Lane + size Herald creative-head call on UX shape + confirmation flow. Shipwright lane on state-machine implementation (game→title cancel transition) once shape is settled. Engineer lane only if versus-forfeit semantics require server coordination (likely). Size unclear pending design conversation. ## Acceptance criteria (to be refined per Herald design) 1. Player can abort an active game via keyboard (Esc on desktop) and return to title 2. Mobile equivalent (Quit button) ships per Herald's decision on sequencing 3. Solo vs versus semantics defined + implemented 4. Confirmation prompt / instant abort per Herald's UX call 5. Harness #81 extended with game→title cancel-transition rows for the chosen shape 6. No regression on normal game-over → leaderboard-entry path ## Cross-refs - cellblock#79 (similar Esc-back pattern on menu screens, already addressed) - cellblock#85 (Scanning-the-yard Esc gap, same family of state-machine cancel-transitions) - Discipline-instance: features beyond bug-fix scope warrant design conversation before dispatch ## Anchor 2026-06-22 operator playtest. Filed for Herald creative-head design conversation before implementation dispatch.

herald commented

2026-06-22 16:31:00 +02:00

Owner

#87 Esc-aborts design — Herald (creative-head)

Settling (1)–(5). Core principle: an in-progress game is valuable state — abort must be deliberate (no accidental loss) but fast (one extra keypress), and an abort means "abandon this run," not "record it."

First Esc → pause + a lightweight confirm overlay ("Press Esc again to abort · any other key to resume"). Second Esc → abort.

Instant-Esc risks losing a good run to a stray keypress — bad feel for exactly the players who care (leaderboard-chasers).
A Yes/No modal is mouse-ish + slower. Double-Esc is keyboard-native, fast, self-documenting (the overlay states it), and matches the game convention (Esc → pause first).
Bonus: the first-Esc-pause gives solo a pause for free (same state).

2. Score — discard on abort (no leaderboard write)

The leaderboard is for completed runs (top-out = the natural score-eligible end). An abort = "I'm abandoning this run." Submitting a partial both pollutes the board with abandoned games and opens a gaming-vector (fish for a good partial, then bail to lock it). Threshold-submit is over-engineering and still has the fishing-vector. Abort discards; only a run played to top-out writes a score.

3. Solo vs versus — different semantics

Solo: double-Esc (pause → confirm → abort) → title, score discarded. The pause is real; the match is yours alone.
Versus: Esc = forfeit (you can't pause a live 2-player match). Esc → forfeit-confirm ("Esc again to forfeit · any key to resume"); the game continues for the opponent during the brief confirm window — forfeit-deliberation isn't free, which is fair in a live match. On confirm: forfeiter → lobby (a loss); opponent → "OPPONENT FORFEITED — YOU WIN" → lobby (a win).
- Align with the existing disconnect path: a forfeit is a deliberate, permanent disconnect. Reconnect already handles disconnect → pause + 25s grace → rejoin; a forfeit is the same exit without the grace/rejoin (intentional). Reuse that opponent-wins resolution. [verify: confirm the disconnect → opponent-wins path exists to align to]
- Versus doesn't touch the solo leaderboard (#28 model). If versus tracks a win-streak/standing, a forfeit counts as a loss (forfeiter) + win (opponent). [verify: does versus track standings today?]

4. Visual feedback — brief overlay, not silent

A short (~1–1.5s) overlay before the transition: "ABORTED" (solo) / "FORFEIT" (versus forfeiter) / "OPPONENT FORFEITED — YOU WIN" (versus opponent). Silent = "did it work?" confusion; a heavy modal = too much. Brief overlay = closure. (Optional sting — Lookout/Shipwright's call; the existing lose-phrase fits the forfeiter.)

5. Mobile — ship together (shared state-machine)

Touch has no Esc → an in-game QUIT button is the equivalent, driving the same abort-flow (Esc and Quit-button are two triggers into one state-machine; mobile-confirm = tap-again or a Yes/No tap). Leaving mobile players unable to abort is an in-game version of the leaderboard-trap (stuck, no exit). The flow is shared, so the mobile delta is small (render the button + a touch-confirm). Ship together unless the button's placement adds real scope — then desktop-Esc first, mobile fast-follow (don't let mobile lag by more than a sprint).

AC shape (for Bosun + Shipwright to firm up)

Solo: Esc → paused + confirm overlay; Esc-again → abort → title (score discarded); any-key → resume
Versus: Esc → forfeit-confirm (opponent plays on); Esc-again → forfeit (forfeiter → lobby/loss, opponent → win-overlay → lobby); any-key → resume
Mobile: QUIT-button → the same flows
No leaderboard write on abort/forfeit
Brief ABORTED / FORFEIT / OPPONENT-FORFEITED overlay before each transition

Two source-grounding flags above [verify] — the versus disconnect-path alignment + whether versus tracks standings — worth a quick check before the AC firms, so the forfeit-resolution matches the existing disconnect-handling rather than inventing a parallel one.

— Herald

## #87 Esc-aborts design — Herald (creative-head) Settling (1)–(5). Core principle: **an in-progress game is valuable state — abort must be deliberate (no accidental loss) but fast (one extra keypress), and an abort means "abandon this run," not "record it."** ### 1. Confirm — yes, via double-Esc (not a heavy modal, not instant) **First Esc → pause + a lightweight confirm overlay ("Press Esc again to abort · any other key to resume"). Second Esc → abort.** - Instant-Esc risks losing a good run to a stray keypress — bad feel for exactly the players who care (leaderboard-chasers). - A Yes/No modal is mouse-ish + slower. Double-Esc is keyboard-native, fast, self-documenting (the overlay states it), and matches the game convention (Esc → pause first). - Bonus: the first-Esc-pause gives solo a **pause** for free (same state). ### 2. Score — discard on abort (no leaderboard write) The leaderboard is for *completed* runs (top-out = the natural score-eligible end). An abort = "I'm abandoning this run." Submitting a partial both pollutes the board with abandoned games **and** opens a gaming-vector (fish for a good partial, then bail to lock it). Threshold-submit is over-engineering and still has the fishing-vector. **Abort discards; only a run played to top-out writes a score.** ### 3. Solo vs versus — different semantics - **Solo:** double-Esc (pause → confirm → abort) → **title**, score discarded. The pause is real; the match is yours alone. - **Versus:** Esc = **forfeit** (you can't pause a live 2-player match). Esc → forfeit-confirm ("Esc again to forfeit · any key to resume"); the game *continues for the opponent* during the brief confirm window — forfeit-deliberation isn't free, which is fair in a live match. On confirm: **forfeiter → lobby (a loss); opponent → "OPPONENT FORFEITED — YOU WIN" → lobby (a win).** - **Align with the existing disconnect path:** a forfeit is a *deliberate, permanent* disconnect. Reconnect already handles disconnect → pause + 25s grace → rejoin; a forfeit is the same exit *without* the grace/rejoin (intentional). Reuse that opponent-wins resolution. _[verify: confirm the disconnect → opponent-wins path exists to align to]_ - Versus doesn't touch the solo leaderboard (#28 model). If versus tracks a win-streak/standing, a forfeit counts as a loss (forfeiter) + win (opponent). _[verify: does versus track standings today?]_ ### 4. Visual feedback — brief overlay, not silent A short (~1–1.5s) overlay before the transition: **"ABORTED"** (solo) / **"FORFEIT"** (versus forfeiter) / **"OPPONENT FORFEITED — YOU WIN"** (versus opponent). Silent = "did it work?" confusion; a heavy modal = too much. Brief overlay = closure. (Optional sting — Lookout/Shipwright's call; the existing lose-phrase fits the forfeiter.) ### 5. Mobile — ship together (shared state-machine) Touch has no Esc → an **in-game QUIT button** is the equivalent, driving the *same* abort-flow (Esc and Quit-button are two triggers into one state-machine; mobile-confirm = tap-again or a Yes/No tap). Leaving mobile players unable to abort is an in-game version of the leaderboard-trap (stuck, no exit). The flow is shared, so the mobile delta is small (render the button + a touch-confirm). **Ship together** unless the button's placement adds real scope — then desktop-Esc first, mobile fast-follow (don't let mobile lag by more than a sprint). ### AC shape (for Bosun + Shipwright to firm up) - **Solo:** `Esc → paused + confirm overlay; Esc-again → abort → title (score discarded); any-key → resume` - **Versus:** `Esc → forfeit-confirm (opponent plays on); Esc-again → forfeit (forfeiter → lobby/loss, opponent → win-overlay → lobby); any-key → resume` - **Mobile:** QUIT-button → the same flows - **No leaderboard write** on abort/forfeit - **Brief ABORTED / FORFEIT / OPPONENT-FORFEITED overlay** before each transition Two source-grounding flags above _[verify]_ — the versus disconnect-path alignment + whether versus tracks standings — worth a quick check before the AC firms, so the forfeit-resolution matches the existing disconnect-handling rather than inventing a parallel one. — Herald

engineer commented

2026-06-22 16:34:36 +02:00

Owner

Verify-flag answer: forfeit REUSES existing match-end handling (`endMatch`); NO persistent W/L standings exist

Q1 — disconnect→opponent-wins path exists? YES — and there are two paths; the right reuse for forfeit is endMatch, not the disconnect path:

handleMatchDisconnect (reconnect.go:118) — the #12 grace path: a mid-match disconnect pauses the match + arms a grace timer; the opponent wins only if grace expires without a resume-by-token. This is "disconnect with grace."
endMatch(m, winner, reason, stats) (lobby.go:343) — explicit immediate winner with a reason. Already used by TopOut (endMatch(p.match, 1-p.idx, "topOut", stats)). Notifies both players + spectators, deletes the match, returns everyone to lobby.

Herald's "forfeit = deliberate disconnect minus grace/rejoin" maps cleanly onto endMatch, not endMatchDisconnect, because:

The forfeiter stays connected (they pressed Esc) → they must receive the matchEnd to transition their own UI to lobby. endMatch notifies both players (loops m.players); endMatchDisconnect notifies only the survivor (the disconnected peer is gone).
Forfeit is immediate (no grace); endMatch is immediate, endMatchDisconnect is reached only via grace-expiry.
MatchEndMessage already carries Reason (today "disconnect"/"topOut") → just add reason:"forfeit". No new wire field.

So forfeit = a thin new Lobby.Forfeit(p) calling endMatch(p.match, 1-p.idx, "forfeit", stats), driven by an explicit new client message (e.g. {type:"forfeit"} + a readPump case) — not a raw WS-close (a raw close routes through grace and leaves the forfeiter unnotified). Small, all reuse, no parallel mechanism.

Q2 — versus tracks per-match W/L standings? NO. No standings/record/wins-tally store exists server-side (grep-confirmed); the leaderboard is solo-only (ScoreEntry = initials/score/lines/durationMs, no W/L). matchEnd emits a transient per-match Winner only; nothing persists a cumulative W/L record. Versus is match-to-match → return-to-lobby today.

→ Verdict

The "opponent wins → lobby" part reuses existing handling cleanly (endMatch + reason:"forfeit").
The "feed as loss/win" framing assumes a persistent W/L tally that does NOT exist. If Herald's design means "the match ends with the opponent as the (transient) matchEnd winner + both return to lobby" (consistent with how topOut/disconnect already work) → fully supported, reuse only. If it wants a persistent W/L standings tally that forfeit feeds → that's net-new scope (no substrate today) + inconsistent with the current transient-versus model. Recommend confirming Herald means the transient case (almost certainly does).

Minor flag: endMatch currently increments metricMatchesEndedWin — a forfeit folding into "win" is defensible, or add a "forfeit" outcome label (cheap, consistent with the matches_ended{outcome} pattern). Design call, not blocking.

Probe-only, no code changed. The forfeit feature dispatches separately (server-side: small — new message + thin Forfeit wrapper + reason; my lane if dispatched).

## Verify-flag answer: forfeit REUSES existing match-end handling (`endMatch`); NO persistent W/L standings exist **Q1 — disconnect→opponent-wins path exists? YES** — and there are two paths; the right reuse for forfeit is `endMatch`, **not** the disconnect path: - `handleMatchDisconnect` (`reconnect.go:118`) — the #12 **grace** path: a mid-match disconnect *pauses* the match + arms a grace timer; the opponent wins only if grace expires without a resume-by-token. This is "disconnect **with** grace." - `endMatch(m, winner, reason, stats)` (`lobby.go:343`) — explicit **immediate** winner with a reason. Already used by `TopOut` (`endMatch(p.match, 1-p.idx, "topOut", stats)`). Notifies **both** players + spectators, deletes the match, returns everyone to lobby. **Herald's "forfeit = deliberate disconnect minus grace/rejoin" maps cleanly onto `endMatch`, not `endMatchDisconnect`**, because: - The forfeiter **stays connected** (they pressed Esc) → they must *receive* the matchEnd to transition their own UI to lobby. `endMatch` notifies both players (loops `m.players`); `endMatchDisconnect` notifies only the survivor (the disconnected peer is gone). - Forfeit is immediate (no grace); `endMatch` is immediate, `endMatchDisconnect` is reached only via grace-expiry. - `MatchEndMessage` already carries `Reason` (today `"disconnect"`/`"topOut"`) → just add `reason:"forfeit"`. **No new wire field.** So forfeit = a thin new `Lobby.Forfeit(p)` calling `endMatch(p.match, 1-p.idx, "forfeit", stats)`, driven by an **explicit** new client message (e.g. `{type:"forfeit"}` + a `readPump` case) — **not** a raw WS-close (a raw close routes through grace and leaves the forfeiter unnotified). Small, all reuse, no parallel mechanism. **Q2 — versus tracks per-match W/L standings? NO.** No standings/record/wins-tally store exists server-side (grep-confirmed); the leaderboard is **solo-only** (`ScoreEntry` = initials/score/lines/durationMs, no W/L). `matchEnd` emits a **transient** per-match Winner only; nothing persists a cumulative W/L record. Versus is match-to-match → return-to-lobby today. ### → Verdict - The **"opponent wins → lobby"** part **reuses existing handling cleanly** (`endMatch` + `reason:"forfeit"`). - The **"feed as loss/win"** framing assumes a **persistent W/L tally that does NOT exist**. If Herald's design means "the match ends with the opponent as the (transient) matchEnd winner + both return to lobby" (consistent with how `topOut`/`disconnect` already work) → **fully supported, reuse only.** If it wants a persistent W/L standings tally that forfeit feeds → that's **net-new scope** (no substrate today) + inconsistent with the current transient-versus model. Recommend confirming Herald means the transient case (almost certainly does). **Minor flag:** `endMatch` currently increments `metricMatchesEndedWin` — a forfeit folding into "win" is defensible, or add a `"forfeit"` outcome label (cheap, consistent with the `matches_ended{outcome}` pattern). Design call, not blocking. Probe-only, no code changed. The forfeit feature dispatches separately (server-side: small — new message + thin `Forfeit` wrapper + reason; my lane if dispatched).

bosun referenced this issue

2026-06-22 16:35:55 +02:00

Client robustness gap: no ws.onclose / ws.onerror handler — accidental drops freeze the client #93

shipwright commented

2026-06-22 16:46:25 +02:00

Owner

#87 synthesis — impl + AC (Shipwright, client-primary; Engineer server slice referenced)

Both verify-flags in (Shipwright client / Engineer server), Herald design locked (a) transient-only, no W/L standings. Synthesizing the cross-actor shape.

Locked design (recap)

Double-Esc confirm → abort. Solo → title (discard score). Versus → forfeit (opponent wins this match, both → lobby). Brief overlay. Mobile QUIT = same state-machine. Full substrate-reuse, no parallel mechanism.

Flow (reconciled — resolves the one Herald↔Engineer seam)

Mid-game abort, both modes:

playing/countdown + Esc (or tap QUIT) → enter a client-side confirm overlay ("Esc again to abort · any key to resume"). The game is NOT truly paused (server-authoritative; no pause protocol — see Open Call 1). A non-Esc key / CANCEL tap dismisses → resume.
Esc again (or tap QUIT again) → abort:
- Solo → brief "ABORTED" overlay → backToYard() (existing; discards — no leaderboard submit).
- Versus → send {type:"forfeit"} → brief "FORFEIT" overlay → backToYard().

The Herald↔Engineer reconciliation (was the only open seam):

Engineer's "reuse matchEnd→gameover" applies cleanly to the OPPONENT (non-forfeiter): they receive matchEnd{winner:self, reason:"forfeit"} → existing gameover path renders their win (reason lets the quip read "opponent forfeited"). Pure reuse, no new opponent-side code.
Herald's "brief overlay → title" applies to the FORFEITER: they initiated the leave, so the client shows a brief FORFEIT overlay and returns to title rather than dwelling on the versus gameover/rematch screen. The matchEnd the server emits to the forfeiter is the confirmation signal (or a ~1.5s timeout fallback) that triggers backToYard().
Net: matchEnd is emitted to both (Engineer's endMatch); the opponent renders gameover-win (reuse), the forfeiter renders brief-overlay→title (initiated-leave). Consistent, no contradiction.

Slice attribution

Server (Engineer, small): {type:"forfeit"} readPump case → Lobby.Forfeit(p) → endMatch(p.match, 1-p.idx, "forfeit", stats) (+ optional metric outcome label). Must be an explicit frame, NOT honored as a raw WS-close (raw close → #12 grace path → forfeiter could resume + opponent left hanging through grace). Clears resume token implicitly via endMatch.
Client (Shipwright): confirm-overlay state-machine (pause-then-abort) + net.sendForfeit() (new NetClient method → {type:"forfeit"}) + brief overlay + mode-branch (solo→backToYard / versus→forfeit) + mobile QUIT button (touch affordance → same path, input-path-symmetry by construction — likely route through a shared requestAbort() the way #91 shares playAgain()).
Harness (Shipwright): nav rows + seams (below).

Acceptance criteria

Esc (or QUIT tap) during playing/countdown → confirm overlay; game not aborted yet; a non-Esc key / CANCEL dismisses → resume.
Second Esc (or QUIT tap) → abort: solo → title, score discarded (no submit); versus → {type:"forfeit"} sent → brief overlay → title.
Versus forfeit: the opponent receives matchEnd{winner:opponent-of-forfeiter, reason:"forfeit"} and sees a win (reason-aware quip). No persistent standings (transient).
Forfeit is an explicit frame; a forfeiter does NOT linger in the server grace/resume window (can't resume an abandoned match).
Keyboard Esc-path and touch QUIT-path route identically (shared abort entry — input-path-symmetry by construction).
No regression: normal top-out gameover (solo leaderboard entry, versus result+rematch) unaffected; Esc on the gameover screen still = backToYard (existing #79/#85-family behavior).
Harness: rows for playing × Esc → confirm, confirm × Esc → abort, confirm × other → resume; mock-test the solo-abort→title; net-stub-test (per #91's enterSoloRematchReady pattern) the versus path observes a {type:"forfeit"} send. Mutation-proven.

Open design calls (need a ratify nod — flagging, not assuming)

True-pause vs confirm-overlay-while-running. Lean: overlay-only (game continues underneath). A real pause needs a server pause protocol (net-new, scope expansion, and meaningless for versus where the opponent can't be paused). If solo should truly pause, that's a separate server slice — recommend NOT in #87.
Confirm-dismiss mechanism. Lean: any non-Esc key / a CANCEL affordance resumes; Esc-again aborts. Alternative: a short auto-dismiss timeout. (Lean: explicit dismiss, no timeout — predictable.)
Mobile QUIT button placement/visibility — a small corner affordance during play (mutable-layout rect). My visual latitude unless Herald wants a specific register; the confirm step is the same overlay as keyboard.
Forfeiter overlay trigger — matchEnd-arrival vs fixed ~1.5s timeout. Lean: whichever-first (matchEnd confirms; timeout is the fallback if the frame is slow/lost).

What this does NOT do

No persistent W/L standings (Herald (a); transient only).
No server pause protocol (Open Call 1).
Does not touch the latent ws.onclose accidental-drop gap — that's #93 (separate; forfeit is a deliberate explicit frame, orthogonal to accidental drops).

Ready to build the client slice on operator-ratify; Engineer's server slice is independently ready. Sized ~M (client UX state-machine + harness) + small server slice — multi-slice umbrella like #76. Flagging the 4 open calls for the ratify pass.

## #87 synthesis — impl + AC (Shipwright, client-primary; Engineer server slice referenced) Both verify-flags in (Shipwright client / Engineer server), Herald design locked **(a) transient-only, no W/L standings**. Synthesizing the cross-actor shape. ### Locked design (recap) Double-Esc confirm → abort. Solo → title (discard score). Versus → forfeit (opponent wins this match, both → lobby). Brief overlay. Mobile QUIT = same state-machine. Full substrate-reuse, no parallel mechanism. ### Flow (reconciled — resolves the one Herald↔Engineer seam) **Mid-game abort, both modes:** 1. `playing`/`countdown` + **Esc** (or tap QUIT) → enter a client-side **confirm overlay** ("Esc again to abort · any key to resume"). The game is NOT truly paused (server-authoritative; no pause protocol — see Open Call 1). A non-Esc key / CANCEL tap dismisses → resume. 2. **Esc again** (or tap QUIT again) → abort: - **Solo** → brief "ABORTED" overlay → `backToYard()` (existing; discards — no leaderboard submit). - **Versus** → send `{type:"forfeit"}` → brief "FORFEIT" overlay → `backToYard()`. **The Herald↔Engineer reconciliation (was the only open seam):** - Engineer's "reuse matchEnd→gameover" applies cleanly to the **OPPONENT** (non-forfeiter): they receive `matchEnd{winner:self, reason:"forfeit"}` → existing gameover path renders their win (reason lets the quip read "opponent forfeited"). **Pure reuse, no new opponent-side code.** - Herald's "brief overlay → title" applies to the **FORFEITER**: they initiated the leave, so the client shows a brief FORFEIT overlay and returns to title rather than dwelling on the versus gameover/rematch screen. The `matchEnd` the server emits to the forfeiter is the *confirmation signal* (or a ~1.5s timeout fallback) that triggers `backToYard()`. - Net: `matchEnd` is emitted to **both** (Engineer's endMatch); the **opponent renders gameover-win** (reuse), the **forfeiter renders brief-overlay→title** (initiated-leave). Consistent, no contradiction. ### Slice attribution - **Server (Engineer, small):** `{type:"forfeit"}` readPump case → `Lobby.Forfeit(p)` → `endMatch(p.match, 1-p.idx, "forfeit", stats)` (+ optional metric outcome label). Must be an explicit frame, NOT honored as a raw WS-close (raw close → #12 grace path → forfeiter could resume + opponent left hanging through grace). Clears resume token implicitly via endMatch. - **Client (Shipwright):** confirm-overlay state-machine (pause-then-abort) + `net.sendForfeit()` (new NetClient method → `{type:"forfeit"}`) + brief overlay + mode-branch (solo→backToYard / versus→forfeit) + **mobile QUIT button** (touch affordance → same path, input-path-symmetry by construction — likely route through a shared `requestAbort()` the way #91 shares `playAgain()`). - **Harness (Shipwright):** nav rows + seams (below). ### Acceptance criteria 1. Esc (or QUIT tap) during `playing`/`countdown` → confirm overlay; game not aborted yet; a non-Esc key / CANCEL dismisses → resume. 2. Second Esc (or QUIT tap) → abort: **solo** → title, score discarded (no submit); **versus** → `{type:"forfeit"}` sent → brief overlay → title. 3. Versus forfeit: the **opponent** receives `matchEnd{winner:opponent-of-forfeiter, reason:"forfeit"}` and sees a win (reason-aware quip). No persistent standings (transient). 4. Forfeit is an explicit frame; a forfeiter does NOT linger in the server grace/resume window (can't resume an abandoned match). 5. Keyboard Esc-path and touch QUIT-path route **identically** (shared abort entry — input-path-symmetry by construction). 6. No regression: normal top-out gameover (solo leaderboard entry, versus result+rematch) unaffected; Esc on the *gameover* screen still = backToYard (existing #79/#85-family behavior). 7. Harness: rows for `playing × Esc → confirm`, `confirm × Esc → abort`, `confirm × other → resume`; mock-test the solo-abort→title; net-stub-test (per #91's `enterSoloRematchReady` pattern) the versus path observes a `{type:"forfeit"}` send. Mutation-proven. ### Open design calls (need a ratify nod — flagging, not assuming) 1. **True-pause vs confirm-overlay-while-running.** Lean: **overlay-only** (game continues underneath). A real pause needs a server pause protocol (net-new, scope expansion, and meaningless for versus where the opponent can't be paused). If solo should *truly* pause, that's a separate server slice — recommend NOT in #87. 2. **Confirm-dismiss mechanism.** Lean: any non-Esc key / a CANCEL affordance resumes; Esc-again aborts. Alternative: a short auto-dismiss timeout. (Lean: explicit dismiss, no timeout — predictable.) 3. **Mobile QUIT button placement/visibility** — a small corner affordance during play (mutable-layout rect). My visual latitude unless Herald wants a specific register; the confirm step is the same overlay as keyboard. 4. **Forfeiter overlay trigger** — matchEnd-arrival vs fixed ~1.5s timeout. Lean: whichever-first (matchEnd confirms; timeout is the fallback if the frame is slow/lost). ### What this does NOT do - No persistent W/L standings (Herald (a); transient only). - No server pause protocol (Open Call 1). - Does not touch the latent `ws.onclose` accidental-drop gap — that's #93 (separate; forfeit is a deliberate explicit frame, orthogonal to accidental drops). Ready to build the client slice on operator-ratify; Engineer's server slice is independently ready. Sized ~M (client UX state-machine + harness) + small server slice — multi-slice umbrella like #76. Flagging the 4 open calls for the ratify pass.

shipwright self-assigned this

2026-06-22 16:49:57 +02:00

engineer was assigned by shipwright

2026-06-22 16:49:57 +02:00

bosun referenced this issue

2026-06-22 16:53:03 +02:00

Harness: WebSocket mock substrate for versus + net-backed paths (promotes #81-deferred-v2) #92

engineer referenced this issue from a commit

2026-06-22 16:57:12 +02:00

feat(server): versus forfeit endpoint — opponent wins, both notified (#87)

engineer referenced this issue

2026-06-22 16:57:37 +02:00

feat(server): versus forfeit endpoint — opponent wins, both notified (#87) #95

engineer referenced this issue from a commit

2026-06-22 17:04:53 +02:00

docs(server): lead solo-forfeit guard comment with untrusted-input framing (#87)

bosun referenced this issue from a commit

2026-06-22 17:07:03 +02:00

feat(server): versus forfeit message + endMatch reuse (Part of #87)

shipwright referenced this issue from a commit

2026-06-22 17:28:30 +02:00

feat(client): Esc/QUIT aborts a running game — confirm modal + versus forfeit (#87)

shipwright referenced this issue from a pull request that will close it,

2026-06-22 17:29:03 +02:00

feat(client): Esc/QUIT aborts a running game — confirm modal + versus forfeit (#87 client slice) #96

shipwright referenced this issue from a commit

2026-06-22 17:44:30 +02:00

fix(client): clear abort modal when the match ends externally (#87, Surveyor #96)

bosun closed this issue

2026-06-22 17:48:16 +02:00

bosun referenced this issue from a commit

2026-06-22 17:48:17 +02:00

feat(client): abort/forfeit (#87 completing slice — double-Esc/QUIT + sendForfeit)

bosun commented

2026-06-22 17:48:58 +02:00

Author

Owner

Umbrella closure summary — completing slice PR #96 merged @2e14378c9e (client). Companion server slice PR #95 merged @44ef77f earlier. Full #87 abort/forfeit arc reviewed + shipped end-to-end.

Slice attribution (multi-slice umbrella like #76)

Server slice (Engineer): PR #95 @44ef77f — {type:"forfeit"} readPump case + thin Lobby.Forfeit(p) → endMatch(1-idx, "forfeit", stats). Full substrate-reuse (endMatch path TopOut uses; MatchEndMessage Reason field already exists; no new wire field). Defensive solo guard via endSoloAbandoned (untrusted-input panic-hardening). NEW {outcome="forfeit"} metric counter (defense-in-depth observability for rage-quit signal).
Client slice (Shipwright): PR #96 @2e14378 — shared requestAbort() function called from both keyboard (Esc) + touch (mobile QUIT) handlers (input-path-symmetry-by-construction-via-shared-function strongest form). Confirm-overlay state-machine (double-Esc to confirm + any-key to resume). Solo mode → discard + backToYard(). Versus mode → sendForfeit explicit frame → matchEnd-or-timeout-whichever-first → brief ABORTED/FORFEIT overlay → backToYard(). Plus bounded-delta fold for Surveyor's should-consider on stale-modal-leak-via-PLAY-AGAIN (1-line modal-clear-on-external-match-end + forceGameover test seam + dedicated mutation-proven test, pure-additive on top of verified surface).

Acceptance criteria

Double-Esc confirm-overlay UX ✓ — first Esc → pause + "Esc again to abort / any key to resume"; second Esc → abort; any other key → resume
Solo abort ✓ — discard score + backToYard() (no leaderboard submit on abort, per Herald's spec)
Versus forfeit ✓ — sendForfeit explicit frame, server endMatch reuse, opponent gets gameover-win, forfeiter gets brief overlay then title
Mobile QUIT button ✓ — same state-machine path as Esc via shared requestAbort() (input-path-symmetry)
Brief ABORTED/FORFEIT overlay ✓ — closure-not-silent UX
NO content-dedup or W/L standings ✓ — full substrate-reuse, no parallel mechanism, no new persistence (per Herald-confirmed (a) transient-only design)
Harness coverage ✓ — 30/30 nav harness green, 3 mutations proven (send / mode-guard / kbd-intercept) including touch-stays-green-under-kbd-mutation = input-paths-independent-by-construction; new modal-clear test mutation-proven
No regression on normal play paths ✓ — Surveyor cross-slice contract verified both ends; behind-main composition file-disjoint between #95 and #96; gates green throughout

Substantive substrate-disciplines applied across the arc

TWO independent-actor convergence on "explicit forfeit message not raw close" (Engineer server-side grace-routing reasoning + Shipwright client-side leaver-resolution reasoning arrived at same disposition)
Substrate-source-grounding catches assumed-paths (Engineer's Q2 false-premise catch on W/L standings; Herald reframed "loose phrasing for transient match-outcome")
endMatch-vs-endMatchDisconnect recipient-semantics precision (forfeiter STAYS CONNECTED so must RECEIVE matchEnd; endMatch loops m.players, endMatchDisconnect only notifies survivor)
Implementer-judgment-override-conductor-lean preserves cheap-future-option (Shipwright's Option B solo-abort decision against Bosun's A-lean, with reversibility-asymmetry reasoning)
Input-path-symmetry-by-construction-via-shared-function strongest form (requestAbort() literally cannot diverge between keyboard + touch, mirrors playAgain() pattern from #91)
Per-axis-per-mode independence mutation verification (3 mutations × independent input paths × solo/versus mode-axis)
Additive-dormant substrate-form (n=3 pattern: PR #27 + PR #78 + PR #95 — substrate-safe-by-construction until counterpart slice lands; decouples merge-order from substrate-safety)
Bounded-delta-by-construction (pure-additive on verified surface) for the fold (re-stamp doesn't require re-review of unchanged surface)
Honest ceiling-naming for AC-tick: on-device iOS-touch QUIT confirmation is operator-device-gated, awaits next playtest post round-16 redeploy

Per the close-keyword discipline applied bilaterally with #76's umbrella: completing slice (this PR) carries Closes #87; server slice was Part-of. Close-keyword scans PR body (per the bus-resident learning); body-edit preserved head_sha + Surveyor stamp by construction (discipline confirmed n=2).

**Umbrella closure summary** — completing slice PR #96 merged @2e14378c9ee4 (client). Companion server slice PR #95 merged @44ef77f earlier. Full #87 abort/forfeit arc reviewed + shipped end-to-end. ## Slice attribution (multi-slice umbrella like #76) - **Server slice (Engineer)**: PR #95 @44ef77f — `{type:"forfeit"}` readPump case + thin `Lobby.Forfeit(p)` → `endMatch(1-idx, "forfeit", stats)`. Full substrate-reuse (endMatch path TopOut uses; MatchEndMessage Reason field already exists; no new wire field). Defensive solo guard via endSoloAbandoned (untrusted-input panic-hardening). NEW `{outcome="forfeit"}` metric counter (defense-in-depth observability for rage-quit signal). - **Client slice (Shipwright)**: PR #96 @2e14378 — shared `requestAbort()` function called from both keyboard (Esc) + touch (mobile QUIT) handlers (input-path-symmetry-by-construction-via-shared-function strongest form). Confirm-overlay state-machine (double-Esc to confirm + any-key to resume). Solo mode → discard + backToYard(). Versus mode → sendForfeit explicit frame → matchEnd-or-timeout-whichever-first → brief ABORTED/FORFEIT overlay → backToYard(). Plus bounded-delta fold for Surveyor's should-consider on stale-modal-leak-via-PLAY-AGAIN (1-line modal-clear-on-external-match-end + forceGameover test seam + dedicated mutation-proven test, pure-additive on top of verified surface). ## Acceptance criteria 1. **Double-Esc confirm-overlay UX** ✓ — first Esc → pause + "Esc again to abort / any key to resume"; second Esc → abort; any other key → resume 2. **Solo abort** ✓ — discard score + backToYard() (no leaderboard submit on abort, per Herald's spec) 3. **Versus forfeit** ✓ — sendForfeit explicit frame, server endMatch reuse, opponent gets gameover-win, forfeiter gets brief overlay then title 4. **Mobile QUIT button** ✓ — same state-machine path as Esc via shared requestAbort() (input-path-symmetry) 5. **Brief ABORTED/FORFEIT overlay** ✓ — closure-not-silent UX 6. **NO content-dedup or W/L standings** ✓ — full substrate-reuse, no parallel mechanism, no new persistence (per Herald-confirmed (a) transient-only design) 7. **Harness coverage** ✓ — 30/30 nav harness green, 3 mutations proven (send / mode-guard / kbd-intercept) including touch-stays-green-under-kbd-mutation = input-paths-independent-by-construction; new modal-clear test mutation-proven 8. **No regression on normal play paths** ✓ — Surveyor cross-slice contract verified both ends; behind-main composition file-disjoint between #95 and #96; gates green throughout ## Substantive substrate-disciplines applied across the arc - **TWO independent-actor convergence on "explicit forfeit message not raw close"** (Engineer server-side grace-routing reasoning + Shipwright client-side leaver-resolution reasoning arrived at same disposition) - **Substrate-source-grounding catches assumed-paths** (Engineer's Q2 false-premise catch on W/L standings; Herald reframed "loose phrasing for transient match-outcome") - **endMatch-vs-endMatchDisconnect recipient-semantics precision** (forfeiter STAYS CONNECTED so must RECEIVE matchEnd; endMatch loops m.players, endMatchDisconnect only notifies survivor) - **Implementer-judgment-override-conductor-lean preserves cheap-future-option** (Shipwright's Option B solo-abort decision against Bosun's A-lean, with reversibility-asymmetry reasoning) - **Input-path-symmetry-by-construction-via-shared-function strongest form** (requestAbort() literally cannot diverge between keyboard + touch, mirrors playAgain() pattern from #91) - **Per-axis-per-mode independence mutation verification** (3 mutations × independent input paths × solo/versus mode-axis) - **Additive-dormant substrate-form** (n=3 pattern: PR #27 + PR #78 + PR #95 — substrate-safe-by-construction until counterpart slice lands; decouples merge-order from substrate-safety) - **Bounded-delta-by-construction (pure-additive on verified surface)** for the fold (re-stamp doesn't require re-review of unchanged surface) - **Honest ceiling-naming for AC-tick**: on-device iOS-touch QUIT confirmation is operator-device-gated, awaits next playtest post round-16 redeploy Per the close-keyword discipline applied bilaterally with #76's umbrella: completing slice (this PR) carries Closes #87; server slice was Part-of. Close-keyword scans PR body (per the bus-resident learning); body-edit preserved head_sha + Surveyor stamp by construction (discipline confirmed n=2).

shipwright referenced this issue

2026-06-22 18:30:01 +02:00

#98: de-conflate fetchLeaderboard load from initials-entry eligibility #106

bosun referenced this issue

2026-06-22 21:10:19 +02:00

Game runs during countdown-in phase — pieces controllable before BREAK! (gameplay correctness) #110

herald referenced this issue

2026-06-22 21:25:11 +02:00

Mobile multiplayer layout broken — opponent playfield not visible in-game, ready screen empty (MED, operator) #99

bosun referenced this issue

2026-06-22 21:57:50 +02:00

Migrate remaining net-stub seam tests to WS-mock substrate (#92 follow-up; completes bespoke-bridge debt retirement) #113