docs: final project closeout - classify TODO, backend spec, status
Classified every TODO.md item into one of DONE/BACKEND/PRODUCT DECISION/FUTURE VERSION/BUG, verified against source, not against prior docs: - BACKEND items (bootstrap content, builder draft/publish, 6 admin CRUD domains, media pipeline) confirmed already covered by BACKEND_INTEGRATION.md; appended a mapping appendix rather than duplicating raw bullets. Fixed 22 stale internal BACKEND_API.md cross-references left over from before that file was archived. - PRODUCT DECISION items (dark mode, brand-color WCAG contrast, stars.component token gap, footer Contacts content, advanced analytics, payment providers) moved to new docs/PRODUCT_BACKLOG.md. - FUTURE VERSION items (Angular 22, bundle splitting, cart-modal composition cleanup, hero-spacing investigation) moved to new docs/FUTURE_FEATURES.md. - BUG: rewrote docs/KNOWN-ISSUES.md down to the one real, verified, currently-reproducible frontend bug (Ed25519 admin-auth error codes session-expired/invalid-signature are unreachable - toAuthErrorShape() never reads a body error code, only maps HTTP status, and no status ever produces those two codes - confirmed by reading auth.service.ts + auth-error.model.ts). Condensed the "Fixed" history instead of carrying full verbose repro text forward. - DONE items removed outright (dead-code deletion, dashboard false positive, RC-02 fixes, stale "dynamic-renderer unwired"/"178 missing keys" claims already disproven by source). docs/TODO.md rewritten to the exact "no blockers" template - nothing left qualifies as a release blocker. New docs/PROJECT_STATUS.md: honest per-area status (frontend/backend/ docs/auth/builder/storefront/admin), known limitations, and explicit production/backend/demo readiness calls - including correcting an initial draft's unpushed-commit count (53, not 10, per git log origin/B2B..HEAD). New docs/NEXT_PHASE.md: work that can only start once a real backend exists (gateway swap-in, mock removal, dormant-auth activation, role enforcement, integration/E2E tests, perf profiling, monitoring, maintenance-mode UI). docs/PROJECT_INDEX.md (the stated entry point) updated to link the new doc set and stop pointing at the now-archived BACKEND_API.md/AUTH.md. docs/FRONTEND-ROADMAP.md's "Known open items" replaced with pointers to the new category-split docs instead of a duplicated mixed list. Not swept: a handful of low-traffic docs (architecture ADRs, FRONTEND.md, EDITOR.md, ARCHITECTURE.md, PROJECT-STRUCTURE.md, StaticPages.md, ADMIN.md) still reference the old BACKEND_API.md/ AUTH.md filenames - noted as a known gap in PROJECT_STATUS.md rather than touched blindly, since they're historical-context docs, not the navigation entry point.
This commit is contained in:
39
docs/NEXT_PHASE.md
Normal file
39
docs/NEXT_PHASE.md
Normal file
@@ -0,0 +1,39 @@
|
||||
# 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.
|
||||
Reference in New Issue
Block a user