Redesign SessionRail workspace/session loading in pi-web (Svelte)
Session from pi-web on Hugging Face by woxQAQ · MIT · condensed by Coders Talk
Fix SessionRail so collapsing/expanding workspaces works correctly, then redesign session discovery so the frontend lazily loads sessions per workspace instead of scanning everything upfront, with a cache and no stateless-breaking rename feature.
- +0Prompt · +0SessionRail doesn't support collapsing the workspace of the currently open session
- +0mAgent did · +0mAdded tracking state so auto-expand only fires when activeSessionPath actually changes, letting users manually collapse the active workspace; verified with pnpm build:web
- +51mPrompt · +51mRedesign session loading: init only fetches workspaces, expand loads recent 5 sessions, add active/inactive dual-generation LRU cache on bridge, scan only file heads for titles, remove the rename feature entirely since it conflicts with stateless design
- +51mIntervention · +51mDeveloper rejected keeping rename support even as a header-rewrite, insisted it be deleted since it breaks the stateless designWhy: Rename requires scanning/rewriting session files which is exactly the statefulness we're trying to avoid.
- +1h 21mAgent did · +1h 21mImplemented new list_workspaces RPC, collapsed list_sessions to per-workspace lazy loading, removed rename end-to-end (types, bridge handler, store, UI), rewrote SessionRail.svelte; verified with pnpm build:bridge and build:web
- +1h 47mIntervention · +1h 47mDeveloper noticed the first-listed workspace kept auto-opening even when a different workspace was actually active, and pointed out the fallback logic never closed the wrongly-opened oneWhy: I already have a workspace open, but it still opens the originally first-sorted workspace — that fallback logic is just wrong.
- +1h 57mIntervention · +1h 57mDeveloper said the 'expand first workspace when there's no active workspace' fallback should not exist at allWhy: There shouldn't be a case where we fall back to opening the first workspace just because we don't know the active one yet.
- +1h 58mAgent did · +1h 58mRemoved the fallback entirely so SessionRail only auto-expands when it actually knows the active workspace; verified with pnpm build:web
- +2h 0mPrompt · +2h 0mHow are workspaces sorted? It should be by update time
- +2h 0mAgent did · +2h 0mAdded updatedAt to workspace summaries, sorted workspaces by update time (session header timestamp preferred, file mtime fallback) across bridge and store; verified with pnpm build:bridge
- +2h 19mPrompt · +2h 19mLoading more sessions via 'Browse older sessions' causes the workspace session list to flash/refresh
- +2h 20mOutcome · +2h 20mFixed by separating the rail's 'first load' loading state from the older-sessions pagination loading state; pnpm run build:web passed with only pre-existing chunk size warnings
Next time I'd put the full spec in the first prompt — I ended up repeating the same 'init only fetches workspaces, expand lazily loads 5 sessions, delete rename' request three times before the agent actually executed it instead of just re-designing. The correction that mattered most was pushing back on the auto-expand fallback: pointing out it never closed the wrongly-opened first workspace was what got a real fix instead of a half-measure.