Refactor Client to use RTK Query, improve error handling, and add test coverage
Description
The Client app currently uses a data-fetching and scheduling layer that has grown hard to reason about. Error handling is inconsistent across fetches, state propagation relies on events that are easy to miss, and there is very little automated test coverage. We should align the Client with the Admin by moving it onto RTK Query, harden error handling, and introduce a real test suite.
Problems
- Data fetching is ad-hoc. The Client does not use RTK Query (which Admin already does), so caching, retries, and request deduplication are reinvented per call.
- Error handling is inconsistent. Failed fetches and timeouts are handled differently in different code paths, making client error codes (ER101–ER201) harder to surface and diagnose.
- State is propagated via events. This makes flow hard to follow and causes subtle bugs when listeners are missing or ordering is wrong.
- No meaningful test coverage exists for Client logic — neither unit nor E2E.
Proposed approach
- Migrate Client data access to RTK Query, reusing the generated API where possible and adding Client-specific endpoints via enhanced-api.
- Replace the event-based state propagation with a context-based model so component state flows are explicit and traceable.
- Parallelize fetches that are independent, and standardize timeout/error handling across all calls.
- Add a Vitest unit-test setup for the Client and write tests covering the new data layer, error handling, and progression logic.
- Add Playwright E2E tests for the Client's main flows.
Scope
- Client entry (assets/client/) and Client-specific Redux slices.
- API spec regeneration (task generate:api-spec → task generate:redux-toolkit-api) after the operation-id change.
- assets/shared/redux/enhanced-api.ts cache invalidation updates for any new Client endpoints.
- New Vitest config and test files; new Playwright specs under assets/tests/.
Acceptance criteria
- Client fetches all data through RTK Query; no remaining ad-hoc fetch wrappers.
- All fetches share a single error-handling and timeout path; ER1xx codes are emitted consistently.
- State flows through context, not custom events.
- Vitest suite runs via task test:unit and covers the new Client data layer.
- Playwright E2E suite covers Client startup, screen binding, and content progression.
- All existing tests pass.
Refactor Client to use RTK Query, improve error handling, and add test coverage
Description
The Client app currently uses a data-fetching and scheduling layer that has grown hard to reason about. Error handling is inconsistent across fetches, state propagation relies on events that are easy to miss, and there is very little automated test coverage. We should align the Client with the Admin by moving it onto RTK Query, harden error handling, and introduce a real test suite.
Problems
Proposed approach
Scope
Acceptance criteria