Context

Frontend stores are tested with mocked API modules, and API modules are tested with mocked HTTP. But the boundary between stores and API modules — especially error mapping, response transformation, and state reconciliation — is not tested as a unit. Additionally, several stores lack tests entirely.

Untested or Under-Tested Stores

Stores With No Tests

• captureStore — the core capture workflow store; manages capture creation, queue status, triage state
• workspaceStore — workspace mode management, active board selection, mode persistence
• archiveStore — archive listing, restore operations, restore status tracking
• chatStore (if it exists separately from chatApi) — message accumulation, session management, tool-call streaming

Store + API Integration Scenarios

captureStore

1. Create capture → API succeeds → store reflects new capture in list
2. Create capture → API returns 400 (validation error) → store shows error, no phantom capture
3. Create capture → API returns 500 → store shows network error, capture not lost
4. Fetch capture list → includes proper pagination/sorting
5. Capture triage status polling → store reflects Processing → Completed transition

boardStore

6. Create board → optimistic update → API confirms → final state matches
7. Create board → API fails → optimistic update rolled back
8. Card drag-drop → optimistic move → API confirms → position stable after re-render
9. Card drag-drop → API 409 Conflict → card snaps back to original position
10. Board data refresh while user is editing a card → edit not lost
11. Column reorder → optimistic → API confirms → all cards maintain correct column association
12. Delete board → confirmation → API succeeds → board removed from list, redirect to another board
13. Board auto-switching bug regression (BUG: Board auto-switches between boards every few seconds without user input #509): creating a second board does not auto-switch away from current board

queueStore

14. Queue polling → items transition through Pending → Processing → Completed states
15. Queue item disappears (deleted server-side) → store handles gracefully (no phantom entry)
16. Data isolation regression (BUG: Fresh user sees other users' automation queue data (data isolation failure) #508): queue data only shows authenticated user's items

notificationStore

17. Real-time notification arrival (via SignalR or polling) → store increments unread count
18. Mark all read → all notifications show as read, unread count drops to 0
19. Board-scoped notification filtering → only shows notifications for selected board

sessionStore

20. Token expiry → store detects 401 → redirects to login
21. OAuth code exchange → store receives token → stores in local storage → redirects to intended page
22. Logout → store clears token, clears all other stores' user-specific state

Implementation Notes

• Use Vitest with Pinia test utils (`setActivePinia(createPinia())`)
• For store + API integration: don't mock the API module, mock the HTTP layer (msw or vi.fn on fetch)
• This allows testing the actual store → API → HTTP chain, catching mismatches in response shapes
• For optimistic update tests: verify intermediate state (before API response) and final state (after response)

Edge Cases to Stress

• Stale state reconciliation: Store has cached data, API returns newer data → store updates correctly
• Concurrent mutations: Two users editing the same board → SignalR event triggers store refresh
• Network offline then online: API calls fail with network error → retry when online → state recovers
• Large datasets: Board with 500 cards → store pagination/virtualization doesn't lose cards
• Error message mapping: API returns `errorCode` + `message` → store maps to user-friendly error string