In-flight board mutations can repopulate cleared state after logout

[Chris0Jeky]

Summary

resetForLogout() generation-gates and aborts board-list/detail reads, then clears all board state. It does not own or invalidate card, column, label, comment, or board mutation requests that were already in flight.

Several mutation paths deliberately treat currentBoard === null as permission to commit into the selected-board collections (the pre-load/test convention). After logout, that same null value means the store was intentionally cleared. A late response can therefore repopulate the previous account's cards, labels, comments, columns, or boards and can emit a toast/error on the login screen or into a later session.

Confirmed shape

1. A board mutation begins under authenticated session A.
2. Authentication transitions true→false and resetForLogout() clears the store.
3. The mutation settles after reset.
4. Its post-await patch/finally runs without a session-generation guard. Paths that accept a null board write old-session data back into the cleared refs; every path can still write shared loading/error/toast state.

Read cancellation does not cover this because most mutation API calls are not issued with a store-owned abort signal.

Expected design

Introduce one board-store session/mutation epoch owned by resetForLogout():

• each mutation captures the current epoch before issuing its request;
• post-await state, toast, error, and loading commits occur only while that epoch is still current;
• reset synchronously advances the epoch before clearing refs;
• a stale response may resolve/reject to its original caller, but cannot repopulate or message the logged-out/new session;
• normal same-session currentBoard === null behavior, if genuinely required, is made explicit rather than doubling as logout authority;
• server-side effects already accepted before logout are not falsely presented as cancelled or rolled back.

Coordinate with #3305 so a stale mutation cannot clear a newer session's operation-owned loading state.

Acceptance

• Deferred-promise regressions for create/update/delete across representative board, card, label, and comment paths followed by resetForLogout().
• Rejection-after-logout produces no stale error/toast in the cleared/new session.
• Login as a second account before the old response settles cannot receive account-A client state.
• Existing board list/detail generation, demo-mode, mutation-epoch, and navigation tests remain green.
• Frontend lint, typecheck, build, full tests, and exact-head hosted CI pass.

Audit provenance

Found during the selected-board async-integrity pass behind #3299, #3301, #3303 and the loading-ownership follow-up #3305. Kept separate from those focused PRs to avoid cross-branch conflicts and to make the session boundary explicit.

[Chris0Jeky]

Audit disposition: keep Priority I. This is the highest-severity unimplemented finding from this pass because it crosses an authenticated-session boundary, not merely a selected-board route. Recommended next implementation order is one shared session epoch in boardState/helpers, reset advancement first, then representative board/card/column/label/comment regressions before migrating every mutation. Coordinate the final loading settlement with #3305; do not patch individual null-board branches independently. No active branch currently owns this cross-store slice.

[Chris0Jeky]

Current dependency map from main and PR heads 8f89bfc (#3312) / a1264ab (#3315): their local visit generations watch currentBoard.id, but BoardView unmount retains that payload. Route departure therefore needs its own synchronous invalidation, separate from fetch generations and from Paper/legacy skin changes.

The smallest shared seam is a board mutation/visit epoch in boardState, advanced first by resetForLogout and by the actual BoardView unmount. Mutation lanes must capture it and check before queued transport and after settlement before state, loading, error or toast writes. PaperBoardView is only a child skin and must not retire the route; a cancellable navigation guard is also too early. Existing BoardView unmount fixtures can prove the real lifecycle call, and deferred store tests should retain currentBoard through leave/reopen.

This is a dependency note, not an implementation claim or merge approval. #3312 and #3315 remain blocked on their existing route-lifetime findings; #3312 also needs exact DateTimeOffset freshness comparison beyond milliseconds. Existing writer scope and the review ceiling must be reconciled before a shared implementation touches those stores. Read fetch generations must not be repurposed as mutation identity ownership.

[Chris0Jeky]

[Codex lane claim v2]
Lane: alpha-product-trust continuation, coordinated by the active Taskdeck high-impact goal.
Base: main 308434f plus the already reviewed PR #3315 dependency at 7ed5732, which introduces the shared mutation session generation.
Owned paths: frontend/taskdeck-web/src/store/board/{boardStoreHelpers,boardCrudStore,cardStore,labelStore,cardCommentStore}.ts, focused regression fixtures, and coordinator-owned STATUS entry.
Shared-path reconciliation: current Codex task inventory shows no other active Taskdeck writer; the previous drafter task is wrapped. Bounded local lease/worktree inventory found no active owner for the historical #3303/#3307 claims. Their remote source PRs #3304/#3312 remain preserved and unchanged; this is a distinct main-based logout/session fix, not another review/fix round on either parked source. Their later integrations must reconcile these guards.
Parallel-safe work: read-only mapping/review; unrelated modules. Root is the sole writer for this checkout.
Status: implementing #3306 fully across board/card/label/comment settlements using resetForLogout's shared generation. Capture before transport; suppress stale cache/list/count/error/toast/loading writes, mutation invalidation and recovery transport; preserve same-session null-board behavior and original caller results/errors. No server rollback/cancellation claim. #3305 global same-session loading arbitration remains separate.
Verification: deferred success/rejection and second-login regressions, queued-label transport and recovery coverage, existing column/session/navigation/demo checks, full frontend/static checks, fresh independent review and exact-head required CI before merge.