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.
2026-07-26 12:35:26 +04:00
# Product Backlog
Items that need a client/business decision before any code is written — not blockers, not bugs, not backend work. Verified against current repo state 2026-07-26.
## Dark mode / Theme selector
`theme-section` 's light/dark/system dropdown saves correctly and `theme-engine.service.ts` sets a `data-theme-mode` attribute on `<html>` , but no CSS anywhere in the app reads that attribute — picking Dark or System changes nothing visually today. Theme palette colors themselves are unaffected (real CSS custom properties, genuinely live).
**Decision needed:** does the client want a real dark mode? If yes, this is a real feature project (dark palette + `[data-theme-mode]` /`prefers-color-scheme` strategy + a `matchMedia` listener for "system"), not a wiring fix.
## Brand color contrast (WCAG AA)
`--border-color` fails 3:1 UI-component contrast in every theme (1.24– `--success` /`--warning` /`--error` /`--info-color` fail 4.5:1 when used as plain text-on-white in a handful of places. These are real palette colors, not a token bug — fixing means visibly changing the brand.
**Decision needed:** theme-owner sign-off on adjusted brand colors before any change ships.
## Design-token gap: `stars.component` rating glyph color
`src/app/features/website/product/engagement/components/stars/stars.component.scss:10` uses a literal hex (`#cdd6d5` ) with no matching design token.
**Decision needed:** add a token for this exact shade, or intentionally reuse an existing token (visual shift either way) — needs a design-system owner's call, not an engineering guess.
feat: dead-config sweep, test suite foundation, widget settingsSchema validation
Sprint G: audited every BootstrapConfig field for a real runtime consumer
(docs/DEAD-CONFIG-AUDIT.md). Wired 3 previously-dead editable fields:
footer.logoUrl, company.address.street/contacts.phone, catalog.suggestionsEnabled.
Remaining dead fields needing a business/design decision tracked in
PRODUCT_BACKLOG.md/KNOWN-ISSUES.md, not silently left.
Sprint H: 6 new spec files (test count 57 -> 83), covering ProjectEditorFacade
(undo/redo, draft persistence, publish gating), AdminAnalyticsFacade
(never-fabricate-a-number contract), and regression coverage for this
session's carousel/hero/profile-toggle fixes.
Sprint I: widget settingsSchema (declared in widget-manifest.json, never
validated) now enforced via a new lightweight schema check in
ProjectValidator, surfaced through the existing issuesByField pipeline.
Same check reused in diagnostics so editor and diagnostics can't disagree.
Verification: tsc clean, ng build clean, 83/83 tests pass, barry-cache
validate clean (2 pre-existing unrelated warnings only).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-05 20:47:13 +04:00
## `layout.type` ("Site Layout" selector) — dead editable field
The Theme section's "Site Layout" dropdown edits top-level `BootstrapConfig.layout.type` ,
but page rendering (`SectionEngineService.resolveLayoutType` ) only ever reads each
individual `PageConfig.layout` , never the top-level `bootstrap.layout` — so the
selector has no visible effect regardless of what's chosen.
**Decision needed:** which page(s) should this selector actually drive — only the
homepage, or every page that doesn't set its own `layout` ? That decision determines
the wiring, not an engineering guess. Found: Sprint G dead-config sweep, `docs/DEAD-CONFIG-AUDIT.md` .
## `company.companyName` — dead editable field, needs a copyright-fallback decision
The Footer section's "Company Name" field has no runtime consumer. The footer
already has a copyright fallback (`© {year} {brandName}` ) using `branding.brandName`
when `footer.copyrightText` is empty — reusing `company.companyName` there instead
(or in addition) is a content/legal-wording decision (brand name vs. legal entity
name are intentionally different fields), not a safe mechanical fix.
**Decision needed:** should the copyright fallback use the legal company name
instead of (or alongside) the brand name? Found: Sprint G dead-config sweep,
`docs/DEAD-CONFIG-AUDIT.md` .
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.
2026-07-26 12:35:26 +04:00
## Footer "Contacts" page content
The footer's "Contacts" link (`footer-contacts` / `nav.contacts` ) has no static-page content in the bootstrap mock data at all — unlike "About" (which was a route-name mismatch, already fixed), there's simply nothing written for Contacts.
**Decision needed:** what should the Contacts page actually say (address, phone, hours, map?) — a content question, not a code fix.
## Advanced analytics (traffic, funnels, heatmaps)
No data source exists for site traffic, conversion funnels, or heatmaps anywhere in the frontend or backend plan — this is a from-scratch analytics pipeline, not a missing endpoint.
**Decision needed:** does the client want this for launch or later, and which analytics vendor/build to use (build vs. buy).
## Payment providers
Current checkout supports QR and card via the existing custom payment flow (`bank-payment-modal` , `payViaCard` ). No alternative payment providers are wired or planned.
**Decision needed:** if additional payment providers (e.g. wallets, buy-now-pay-later) are wanted, needs a business decision on which providers before any integration work starts.
