40 lines
3.1 KiB
Markdown
40 lines
3.1 KiB
Markdown
|
# Next Phase — Post-Backend-Integration Work
|
||
|
|
|
||
|
|
Everything here assumes a real backend implementing `docs/BACKEND_INTEGRATION.md` exists. None of this can start before that. Not a re-statement of the backend checklist itself (`BACKEND_INTEGRATION.md` §9 owns that) — this is what the frontend needs to do once a real API is reachable.
|
||
|
|
|
||
|
|
## Connect gateways
|
||
|
|
|
||
|
|
Swap every mock gateway for a real one behind its existing (or newly-added) DI token, per the migration checklist in `BACKEND_INTEGRATION.md` §8. Order matters — follow §8's dependency-ordered sequence (auth/tenant/bootstrap first, then read-heavy catalog domains, then write-heavy customer domains, then admin domains, then builder/CMS).
|
||
|
|
|
||
|
|
## Remove mocks
|
||
|
|
|
||
|
|
Once every domain has a real gateway bound and verified, retire the `*LocalGateway`/mock repository implementations (or gate them behind an explicit dev-only flag if they're still useful for offline frontend development). Remove `useMockData`/mock-interceptor paths that are no longer reachable.
|
||
|
|
|
||
|
|
## Wire dormant auth
|
||
|
|
|
||
|
|
Register the Ed25519 `authInterceptor` in `app.config.ts` and attach `ed25519AuthGuard` to admin routes once a real backend can issue/verify challenges — currently fully built but not activated. Fix the `toAuthErrorShape()` gap noted in `KNOWN-ISSUES.md` so `session-expired`/`invalid-signature` screens become reachable once the backend returns a body-level error code.
|
||
|
|
|
||
|
|
## Enforce the role model
|
||
|
|
|
||
|
|
Wire the existing (currently unenforced) `AdminRole` model into route guards and UI gates — right now anyone who passes admin auth has full access regardless of role.
|
||
|
|
|
||
|
|
## Integration testing
|
||
|
|
|
||
|
|
No automated test suite exists yet for any of the touched areas. Once real endpoints exist, this is the point to add integration tests against them (not against mocks) — facade-level tests verifying real request/response shapes match `BACKEND_INTEGRATION.md`.
|
||
|
|
|
||
|
|
## E2E tests
|
||
|
|
|
||
|
|
Critical flows worth covering first: storefront checkout (cart → order → payment), admin product/category CRUD, builder draft → publish → live storefront reflects the change, admin auth (once Ed25519 is live).
|
||
|
|
|
||
|
|
## Performance profiling
|
||
|
|
|
||
|
|
Real backend latency will differ from the instant mock responses today — re-profile loading states, skeleton timing, and the two known large lazy chunks (`project-editor`, `catalog-container`) under real network conditions before committing to a bundle-splitting approach.
|
||
|
|
|
||
|
|
## Production monitoring
|
||
|
|
|
||
|
|
Wire real error tracking/APM once real endpoints exist — the current admin Monitoring page is mock activity data with no real event source. Decide on the actual monitoring/observability stack as part of backend infra (out of frontend scope, but the frontend's Monitoring UI is ready to display real events once real events exist — see `BACKEND_INTEGRATION.md` §3 Monitoring).
|
||
|
|
|
||
|
|
## Maintenance mode
|
||
|
|
|
||
|
|
Build the frontend UI gaps explicitly flagged as not existing yet in `docs/MAINTENANCE_MODE.md` (full-page maintenance takeover, per-module inline banners, scheduled-maintenance countdown) once the backend maintenance-mode contract (also in that doc) is decided and implemented.
|