Files
marketplaces/docs/PRODUCT_BACKLOG.md
sdarbinyan ce63931bc2
Some checks failed
Architecture Governance / architecture (push) Has been cancelled
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

4.0 KiB
Raw Blame History

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.241.42:1 measured); --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.

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.

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.

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.