Paging cursor is a singleton in a store whose convention is slot-keyed Records

[rnoack1]

What

The older-history paging cursor is a singleton in ChatState, while almost everything else that
varies per chat is a slot-keyed Record. That mismatch is the root cause behind a run of races in
chatSlice.ts, and it forces an ownership protocol to exist at all.

Today the cursor is five scalar fields (website/src/store/chatSlice.ts:535-545):

Field	Purpose
slotHasMore	is there more history to page
slotOldestIndex	the offset the next page is fetched at
slotCursorKey	which chat the two values above belong to
slotSwitchRequestId	a switch is in flight and owns the cursor
slotSwitchTarget	which chat that switch is going to install a cursor for

The last three exist only to answer "is this cursor mine?" and "is someone about to replace it?".
Meanwhile the same state holds 9 slot-keyed maps that never need to ask those questions, because
the map key already answers them: slotMessages, slotActivity, slotRun, slotHydrated,
slotSide, slotSideClosed, slotStatusDetail, slotContextPct, slotContextTokens.

Why it matters

Because the cursor is global, every reducer that installs messages has to re-coordinate it, and the
failure mode is silent — paging quietly does nothing, or pages at an offset belonging to a different
chat. Recent review of #4001 turned up several instances of that one shape in a row, each needing its
own guard:

• a superseded older-history fetch landing after a chat switch, prepending another chat's page
• a background refresh landing inside a switch window and re-validating a cursor the switch was
  about to replace
• the clear reducers leaving the cursor in a state a waiting pinned-message jump could not resolve

Each was fixed, and all 8 cursor writers now go through one setPagingCursor helper that carries the
ownership check internally, so a writer cannot update one field and forget another. But the invariant
is still enforced by a helper rather than made impossible, and the two claim fields are pure
bookkeeping that exists only because the cursor is shared.

Proposal

Replace the singleton with a per-chat record, so the map key is the cursor key:

slotCursor: Record<string, { hasMore: boolean; oldestIndex: number }>

That change:

• deletes slotCursorKey outright — a cursor read for chat X can only ever be chat X's
• deletes slotSwitchRequestId / slotSwitchTarget as cursor-ownership state, because a switch
  writing chat X's entry cannot corrupt chat Y's
• reduces the remaining ownership question to the single genuine case: a chat being reloaded in
  place, where the new cursor should replace the old one
• brings the cursor in line with the 9 sibling maps, so the next person adding a message-installing
  reducer has nothing to remember

Scope / why not in #4001

It touches every reader of the cursor, not just the writers, so folding it into a focused race fix
would have turned that fix into a refactor. Filing it separately as the structural follow-up both
reviewers of #4001 independently identified as the real fix.

Suggested sequencing: land the per-chat record and migrate readers first, then delete the three
now-unused scalars in a second change, so the two diffs stay reviewable.

[github-actions]

Automated triage summary — generated from the issue text alone, before any maintainer has read it. Treat every line as a starting point, not a verdict.

A refactor proposal for the dashboard chat store: the older-history paging cursor is held as global scalar fields while all sibling per-chat state is slot-keyed, which required ownership/claim bookkeeping and produced a series of silent paging races recently patched in #4001. Reporter proposes replacing it with a per-chat cursor record and deleting the claim fields, sequenced as two diffs.

_{Posted by issue-summary.yml. The model had no access to the repository — it read only this issue and the titles of recent ones.}

[bolichen97]

🤖 Kiro Crew Auto-Pipeline [operator: bolichen97]: Routed to needs-investigation. Replacing the singleton paging cursor (slotHasMore/slotOldestIndex/slotCursorKey/slotSwitchRequestId/slotSwitchTarget) with a slot-keyed slotCursor: Record<string,{hasMore,oldestIndex}> is a Redux state-machine refactor, not a mechanical edit: it rewrites all 8 cursor writers plus setPagingCursor, and touches the switch/clear/refresh reducers whose interaction is the source of the races the issue catalogs (superseded fetch landing after a switch, background refresh inside a switch window, clear leaving an unresolvable cursor for a pinned-message jump). Correctness hinges on preserving the one genuine ownership case — a chat reloaded in place — while proving the map key subsumes the other ownership checks. A human should validate the reducer-interaction model before implementation.

[rnoack1]

Two more fields belong to this family, and one of them is new.

loadingOlder is the third scalar that varies per chat and is not slot-keyed — it gates
the paging predicate and drives the in-flight indicator, so a switch mid-fetch leaves it
describing the outgoing chat.

slotOlderError was added by #2822 (the red "retry" state on the load-earlier control).
It is the same shape as the five fields above: one global describing whichever chat is
active. Making it safe in that PR took nine reset sites, seven of which were folded into
the cursor helper so that "a cursor re-base clears the flag" holds by construction; the
two that remain are an ownership transfer and a retry, neither of which re-bases the
cursor. That fold removed the maintenance cost but not the underlying shape — the flag is
still global, and the render site still has to compare a cursor key against the active
chat to know whether it may be trusted.

So the per-chat keying this issue describes now covers seven fields rather than five. The
argument for doing them together is unchanged and, if anything, stronger: keying only some
of them leaves the family split across two conventions, which is a worse intermediate
state than either end.

[pepmach]

Pod-required pipeline stand-down (pepmach): not drivable as a live defect, and the issue itself is a refactor ask. Measured on an unmodified pod at cbdd4a569 seeded sessions-a-few: the dashboard initial load requests the full corpus with no cursor, and the backend hardcodes has_more=False unless the session has size-rotated archive/ segments — the fixture sessions (~2 messages each) can never paginate, so the two-slot cursor-contamination trace cannot be performed through real routes (that needs hundreds of turns per slot to trigger size rotation). Independently, every cursor writer already routes through setPagingCursor with slot-guarded creator/fulfilled/rejected paths, as the issue text itself concedes ("the invariant is enforced by a helper rather than made impossible"). Residual global loadingOlder produces at most a transient dead click, cleared unconditionally. The 7-field slot-keying refactor remains structurally defensible but needs a maintainer-validated reducer-interaction model, a seed that can actually paginate (a long-history fixture), and sequencing after open PR #9130, which is live in exactly these files. No code changed, no PR; zero residue.