Audited every *.md in docs/ and root. Merged five overlapping backend docs (BACKEND_INTEGRATION.md + AUTHENTICATION.md + ERROR_CONTRACT.md + MAINTENANCE_MODE.md + the already-archived BACKEND_API.md/ BACKEND_API_REMAINING_WORK.md) into one canonical docs/BACKEND.md (4775 lines, 10 numbered sections) - deleted the four standalone files outright now that their content is fully inlined. Archived (not deleted - real historical value): ADMIN.md (Sprint 19-28 build log, sprint-report-shaped, not a living reference) and FRONTEND-ROADMAP.md (despite its name, a shipped-history changelog with detail no other doc has - not a forward roadmap, so keeping it in root alongside NEXT_PHASE.md was exactly the "10 roadmaps" confusion being cleaned up). Deleted outright (zero value): SPRINTS.md - a leftover copy-pasted sprint-kickoff prompt saved as a file, not documentation. Rewrote docs/PROJECT_STATUS.md with completion-percentage estimates per area (frontend/backend/UI/admin/storefront) and an explicit first-customer-readiness call. Rewrote docs/NEXT_PHASE.md to the strict 5-phase structure (backend integration -> production testing -> performance -> monitoring -> v2 ideas), pointing to PRODUCT_BACKLOG .md/FUTURE_FEATURES.md for phase 5 detail instead of duplicating it. Rewrote root README.md - was stale (referenced deleted pages/info, pages/legal folders from a prior RC pass), now covers architecture, frontend/backend status, how to run, mock<->API switch mechanism (useMockData in environment.ts), current folder structure, and a documentation map. Updated docs/PROJECT_INDEX.md (the stated entry point) to link only the surviving doc set - every remaining document is reachable from it. Fixed every broken/stale cross-reference to the deleted/renamed backend docs across ARCHITECTURE.md, EDITOR.md, FRONTEND.md, PROJECT-STRUCTURE.md, StaticPages.md, KNOWN-ISSUES.md (10 individual link fixes, verified by repo-wide grep before and after). Left CHANGELOG.md's two historical entries untouched - changelogs are append-only history, not live navigation, editing past entries would misrepresent what was true at the time. Not touched (explicitly out of scope): docs/architecture/foundation/** (enforced ADRs/governance, permanent not sprint-shaped), docs/context/** (Barry Cache infrastructure, "do not edit by hand" per CLAUDE.md), .claude/worktrees/** (separate git worktrees containing an unrelated project's docs, not this repo's documentation). docs/ root: 22 files -> 16. Plus 5 in docs/archive/ (was 3).
7.3 KiB
Static Pages (Project Editor module)
Sprint X+2. Full-featured CRUD editor for tenant static content (About, Privacy, Terms, Contacts, custom pages, etc.), living inside the Project Editor at /edit/static-pages. Edits bootstrap.staticPages directly — the same model the storefront renders from (docs/BACKEND.md §3 CRUD Contracts, CMS), no parallel content store.
/backoffice/static-pages (Admin dashboard) redirects here rather than hosting a second CRUD UI over the same data.
Where it lives
src/app/features/content-management/
models/content-page.model.ts ContentPage — the CRUD-facing shape
services/content-page.service.ts normalize / resolve / validate / serialize <-> StaticPageConfig
facade/content-management.facade.ts
components/
static-pages-editor.component.* the editor UI (list + per-page card)
static-page-preview/ device preview (desktop/tablet/mobile)
src/app/shared/models/config/static-page.model.ts StaticPageConfig — the bootstrap wire format
src/app/features/project-editor/components/html-editor/ MarketplaceHtmlEditorComponent (rich text)
src/app/core/config/static-page-resolver.service.ts storefront resolver
ContentPageService is the single translation layer between the editor's ContentPage[] and the bootstrap's Record<string, StaticPageConfig> (or the legacy array format) — normalize/resolve/validate/serialize all live there. Nothing else should hand-roll that mapping.
Field reference
General
id— stable key, also the bootstrap record key.slug— used for duplicate-slug detection and as theroutedefault.route— independently editable fromslug(defaults from it, but can diverge — e.g. a legacy redirect path). Validated for duplicates against every other page's route.enabled— master on/off switch. A disabled page never resolves on the storefront, regardless ofstatus.- Navigation visibility —
showInHeader,showInFooter,showInSitemap(independent per-surface flags, unrelated toenabled). order— sort position in the editor list and (for footer pages) the auto-generated footer nav group.icon— optional icon identifier.
Localization
title(per locale, intranslations[locale].title) and a top-leveltitlefallback.translations[locale].html— the rich-text/HTML body, one per supported locale.customTemplate— optional template identifier; consumed by nothing yet (data-only field, forward-compatible with a future template-selection feature).
SEO
Per top-level seo and per-translation translations[locale].seo (locale-specific overrides win when resolving): title, description, keywords, canonical, robots, ogTitle, ogDescription, ogImage.
Media
heroImage,thumbnail— wired through the sharedMediaPickerComponent(same picker used by Branding/Footer logos).gallery: string[]— a lightweight comma-separated URL list ("future ready" per the brief; no dedicated multi-upload UI yet).
Publishing
status: 'draft' | 'published'— per-page publish lifecycle, independent of the whole-bootstrap draft/publish cycle (see below).- Modified indicator — an "unsaved changes" badge per page, diffed against the originally loaded/published snapshot (
ProjectEditorFacade.originalStaticPages).
The enabled + status gating story
A static page resolves on the storefront (ContentPageService.resolvePage, used by both StaticPageResolverService for the page route and FooterResolverService for the auto-generated footer nav group) only when enabled === true AND status === 'published'. This is independent of whether the surrounding bootstrap itself has been published — a page marked draft stays invisible even after the tenant hits "Publish" on the whole config, and only becomes visible once its own status flips to published.
Compatibility default: normalizing existing bootstrap data (loaded from the backend, imported, or read from a legacy array-format staticPages) defaults missing enabled/status to enabled: true, status: 'published' — pre-existing pages never get silently un-published by this feature landing. Only the editor's create-page action opts a brand-new page into status: 'draft' by default, so newly authored content doesn't go live until an author explicitly publishes it.
The Static Pages editor's own Live Preview (desktop/tablet/mobile, StaticPagePreviewComponent) intentionally bypasses this gate — it renders straight from the page's current in-memory HTML, so a draft page can still be previewed before publishing.
CRUD, search, filter, bulk actions
- Create, duplicate (clones a page as a new
draft), delete (confirm dialog), reorder (up/down — not drag-and-drop; see below). - Search across id/slug/route/title (all locales); filter by status (draft/published) or by locale (hides pages missing a translation for the selected locale).
- Bulk actions (multi-select checkboxes): delete, enable, disable, publish, unpublish.
- Important implementation detail: every mutation (create/duplicate/delete/move/bulk) operates on the full, unfiltered page list, never the search/filter-narrowed view — reading from the filtered view before writing back would silently delete whatever the active filter was hiding. See the
persist()comment instatic-pages-editor.component.ts. - Reorder is up/down (
move()), not literal drag handles — a deliberate, lower-complexity scope call; swapping in drag-and-drop later is additive.
Validation
ContentPageService.validatePages() returns: duplicateSlugs, duplicateRoutes (checked independently — a route can diverge from its slug), emptyTitles, invalidHtml (via schema/validators/primitives.validateHtml), invalidSeo (canonical/OG-image URL shape, and robots against a known-token set: index, noindex, follow, nofollow, and their comma-joined combinations). Surfaced as per-page badges in the editor.
This is layered under (not a replacement for) ProjectValidator's existing platform-wide checks (docs/EDITOR.md's "Configuration schema..." section), which already cover duplicate slugs and cross-surface duplicate routes (pages vs. static pages) at the whole-bootstrap level.
Rich text editor
MarketplaceHtmlEditorComponent — see docs/EDITOR.md's "HTML editor (Static Pages)" section for the full toolbar list, the Sprint X+2 additions (horizontal rule, code block, embed), and the HTML-mode validation contract.
Navigation integration
The Navigation section (navigation-section.component) has an "Insert page link" control (page picker + button) next to both header and footer "Add link." It creates a NavigationItemConfig { type: 'staticPage', key: <pageId> } — a shape the resolvers (StaticPageResolverService, FooterResolverService) already understood before this sprint; only the editor-side create path was missing. A static-page-linked nav row shows a "Linked to page" indicator instead of editable label/URL fields, since both are derived dynamically from the linked page.
Export / import / draft / publish
No changes to ProjectEditorIoService or ProjectEditorDraftStorageService — static pages flow through bootstrap.staticPages exactly as before, so JSON export/import and the draft-autosave/publish cycle work unmodified. All Sprint X+2 fields are additive and optional at the wire level.