docs: consolidate documentation and archive temporary reports

Step 1-2 (audit + plan): classified 35 project markdown files into Core/Architecture/ADR/Temporary-audit/Sprint-report/Generated-review/ Duplicate/Obsolete/Historical. Agent-tooling files (.agents/skills/**, .superpowers/**, docs/context/**, CLAUDE.md/GEMINI.md/AGENTS.md/ .github/copilot-instructions.md) explicitly out of scope — intentional per-tool duplication, not documentation debt. Step 3 (merge, no information lost): - docs/PROJECT.md -> docs/PROJECT_INDEX.md, rewritten as the single entry point: system overview, living-doc index, archive pointer, current status, and a critical-finding callout up top. - docs/backend/BACKEND-INTEGRATION.md -> docs/BACKEND_API.md, docs/backend/REMAINING-BACKEND-WORK.md -> docs/BACKEND_API_REMAINING_WORK.md (also folded in a legitimate uncommitted status update that had been sitting unstaged all session: categories marked DONE, order-creation endpoint noted done). - RELEASE-NOTES.md merged into CHANGELOG.md (was a near-duplicate of the same release content in friendlier prose), then deleted. - KNOWN-ISSUES.md: added item 13 (see below) and item 14 (missing canDeactivate on admin/products edit, from the archived PROJECT-STATE audit, re-verified still true); added a correction note to Fixed item 7. - All cross-references to renamed/moved files fixed across every kept doc (grep+sed pass, then verified with a link-existence check across all 58 in-scope markdown files -> 0 broken links). Step 4 (archive, nothing deleted without merging first): created docs/archive/, moved 19 files there (3 root sprint reports, 1 platform report, SPRINT-PLAN.md, and 14 one-off audit/review/report docs). Added correction headers to the 3 archived docs whose conclusions were affected by the finding below, rather than silently leaving them misleading. Step 5: docs/PROJECT_INDEX.md rewritten per the mission brief - someone opening the repo should understand the whole system from it. IMPORTANT FINDING (surfaced during this audit, not the mission's primary goal but too significant to bury): pages/category/*, pages/search/*, pages/item-detail/*, pages/info/**, pages/legal/** (40+ files) are entirely unrouted dead code - app.routes.ts's cmsContentRoutes is a literal empty array, and category/search/product routes redirect to CatalogContainerComponent/ ProductDetailsContainerComponent, not these files. Confirmed against app.routes.ts directly and cross-checked against FRONTEND.md's own routing description. This means several fixes from earlier this cycle (RC-Premium-01, RC STORE-01) and the dead-code cleanup sprint's conclusion that these files were live were all wrong - documented as KNOWN-ISSUES.md item 13, flagged at the top of PROJECT_INDEX.md, and noted on the 3 archived docs whose conclusions it affects. No application code was changed to fix this (out of scope per this session's 'documentation only' constraint) - it needs a wire-it-up-or- delete-it decision first. Verification: tsc --noEmit clean, npm run build green, all markdown links across 58 in-scope files resolve (checked programmatically). No application/Angular/backend code modified. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-25 19:10:49 +04:00
parent 5707755576
commit 5374401257
38 changed files with 281 additions and 222 deletions
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -19,6 +19,16 @@ Format loosely follows [Keep a Changelog](https://keepachangelog.com/). Dates ar
 - `refactor: marketplace release polish` — accessibility pass (explicit `aria-label` on every previously-unlabeled filter `<select>` across the new admin modules), loading-skeleton consistency across admin list pages that previously rendered blank during the initial fetch, and consolidation of the admin dashboard card's custom loading shimmer onto the shared skeleton component.
 - **Storefront premium UX polish** (RC-Visual-02, RC-Premium-01, RC STORE-01) — composition fixes (shared skeleton/empty-state components, undefined theme vars), visual/interaction polish (hover/focus states, color-only-signal fixes), and cleanup across Home/Catalog/Search/Product/Compare/Wishlist/Cart/Static Pages. Full history: `docs/archive/`.
 - **Performance audit** (RC PERF-01) — initial bundle 1.47 MB → 1.12 MB (−24%), biggest win from lazy-loading en/hy i18n packs; dead `items-carousel`/primeng-only component removed.
 - **WCAG 2.1 AA accessibility audit** (RC A11Y-01) — first skip link added app-wide, dialog focus-trap fixes, keyboard-operable drag-and-drop fallbacks, contrast fixes.
 - **Release-candidate walkthrough** — 2 P0s fixed: an app-wide query-param routing bug, and Backoffice Categories CRUD being completely broken end-to-end.
 - **Dead-code cleanup** — removed unregistered auth guards/interceptor, unused search-analytics service, empty backoffice scaffold directories, orphaned shared barrels/models.
 ### Please note
 Orders, transactions, users/roles, monitoring, and analytics run on realistic sample data for now — the backend endpoints for these don't exist yet (tracked in `docs/BACKEND_API.md`). Categories are fully wired to a real HTTP gateway; products and media remain local-storage-backed, ready for a real API to be plugged in behind the same interfaces.
 ### Known gaps
-Every feature above that reads "mock/local" or "seeded" has no real backend yet — see `docs/BACKEND.md` for the full punch list (categories, products, media, orders, transactions, users/roles, and monitoring/analytics all need real endpoints before they reflect production data). `docs/ADMIN.md` documents the architecture and trade-off decisions for each module in detail.
+Every feature above that reads "mock/local" or "seeded" has no real backend yet — see `docs/BACKEND_API_REMAINING_WORK.md` for the full punch list (products, media, orders, transactions, users/roles, and monitoring/analytics all need real endpoints before they reflect production data; categories are already wired end-to-end). `docs/ADMIN.md` documents the architecture and trade-off decisions for each module in detail. Full current status: `docs/PROJECT_INDEX.md`, `docs/FRONTEND-ROADMAP.md`, `docs/KNOWN-ISSUES.md`.
--- a/RELEASE-NOTES.md
+++ b/RELEASE-NOTES.md
@@ -1,18 +0,0 @@
 # Release Notes
 ## Admin Backoffice Expansion
 This release adds a complete admin backoffice on top of the existing dashboard and product management:
 - **Categories** — create, organize into a hierarchy, reorder by drag-and-drop, and publish categories from the admin panel.
 - **Products** — archive/restore, variants, related products, and a proper image gallery, now linked to real admin-managed categories.
 - **Media Library** — folders, tags, upload validation, automatic image compression, and one shared picker used everywhere an image is needed.
 - **Orders** — view and manage orders: change status, request refunds, cancel, leave notes, print invoices.
 - **Transactions** — track payments and refunds, retry failed ones, flag suspicious activity.
 - **Users & Roles** — invite teammates, assign roles, and review who's logged in.
 - **Monitoring** — one place to see recent admin activity, login attempts, and system health.
 - **Analytics** — sales, revenue, and top-product numbers with a simple date-range chart.
 ### Please note
 Orders, transactions, users/roles, monitoring, and analytics run on realistic sample data for now — the backend endpoints for these don't exist yet (tracked in `docs/BACKEND.md`). Categories, products, and media are fully wired to their own local storage and are ready for a real API to be plugged in behind the same interfaces.
--- a/docs/ADMIN.md
+++ b/docs/ADMIN.md
@@ -297,7 +297,7 @@ implementation) + `features/backoffice/media/` + the shared
 container/facade/service split as the rest of `admin/*`:
 - **No real data source exists for orders anywhere in this repo** (already
-  called out in Sprint 19's dashboard gap and `docs/backend/BACKEND-INTEGRATION.md#611-backoffice--orders-planned`) -
+  called out in Sprint 19's dashboard gap and `docs/BACKEND_API.md#611-backoffice--orders-planned`) -
  `AdminOrdersLocalGateway` seeds 24 deterministic synthetic orders in
  memory (cycling through all statuses/customers) rather than reading from
  `BackofficeDataService`, since there is nothing there to read. This is
@@ -355,14 +355,14 @@ routes at all, this is a net-new admin section.
  creates the local record.
 - **Passwordless login**: already existed before this sprint -
  `AdminAuthService`'s Telegram QR flow (`docs/ADMIN.md`'s existing admin
-  login section, `docs/backend/BACKEND-INTEGRATION.md#25-the-admin-authorization-gap-critical--security-relevant-unresolved`). This sprint's Users page links
+  login section, `docs/BACKEND_API.md#25-the-admin-authorization-gap-critical--security-relevant-unresolved`). This sprint's Users page links
  to it via a hint, doesn't reimplement it.
 - **Session manager / device manager**: per-user session list (device, IP,
  last active, current-session badge) with per-session revoke, mocked
  (`AdminUsersLocalGateway.loadSessions()` fabricates 2 sessions per user
  on first view) - the real `AdminAuthService`/session-cookie flow only
  ever tracks the *current* browser's session, so multi-device session
-  listing has no real backend counterpart yet (see `docs/backend/BACKEND-INTEGRATION.md#25-the-admin-authorization-gap-critical--security-relevant-unresolved`).
+  listing has no real backend counterpart yet (see `docs/BACKEND_API.md#25-the-admin-authorization-gap-critical--security-relevant-unresolved`).
 - **Audit**: per-user audit log (role/status changes), same dialog pattern
  as Sprint 24's per-transaction audit - not the system-wide security/audit
  log planned for Sprint 26.
@@ -492,7 +492,7 @@ final result, not just the later commit.
  multi-tenant platform - locales/categories/products/static pages are only
  known at runtime per tenant, not enumerable client-side at build time. A
  real per-tenant sitemap needs a backend/build-time generator - see
-  `docs/backend/BACKEND-INTEGRATION.md#619-sitemap-future--static-baseline-only-today`.
+  `docs/BACKEND_API.md#619-sitemap-future--static-baseline-only-today`.
 - **Responsive**: spot-checked the admin backoffice and customer-facing
  marketplace at mobile/tablet/desktop widths. `shared/ui/table` already
  wraps every admin table in `overflow-x: auto` (no changes needed); the
--- a/docs/ANGULAR22_PLAN.md
+++ b/docs/ANGULAR22_PLAN.md
@@ -14,7 +14,7 @@ Feasibility assessment for upgrading from the current Angular 21.1.5 to Angular
 | `@lucide/angular` | ^1.25.0 | no upper Angular bound (`>=17.0.0`) — not a blocker |
 | Node.js (this environment) | v22.16.0 | Angular 22 CLI requires `^22.22.3 \|\| ^24.15.0 \|\| >=26.0.0` — **current Node does not satisfy this** |
-Correction to the project's own status tracking: `docs/PROJECT.md`/`CLAUDE.md` describe this as "Angular 18+" — the repo is actually already on **21.1.5**, one major behind the latest stable (22.1). This is a much smaller jump than "18→22" would imply.
+Correction to the project's own status tracking: `docs/PROJECT_INDEX.md`/`CLAUDE.md` describe this as "Angular 18+" — the repo is actually already on **21.1.5**, one major behind the latest stable (22.1). This is a much smaller jump than "18→22" would imply.
 ## Verdict: upgrade is safe, with 2 concrete pre-requisites
--- a/docs/ARCHITECTURE.md
+++ b/docs/ARCHITECTURE.md
@@ -41,7 +41,7 @@ Component (container)  -->  Facade  -->  Domain Service  -->  Repository/Provide
 ## Bootstrap / configuration engine
- `ConfigService` loads `BootstrapConfig` (see `docs/backend/BACKEND-INTEGRATION.md#4-bootstrap`) once at startup; `PlatformRuntimeService` applies it (theme, branding, runtime state) and can `reloadFromBootstrap()` for in-memory preview without a full page reload.
+- `ConfigService` loads `BootstrapConfig` (see `docs/BACKEND_API.md#4-bootstrap`) once at startup; `PlatformRuntimeService` applies it (theme, branding, runtime state) and can `reloadFromBootstrap()` for in-memory preview without a full page reload.
 - The bootstrap is the single source of truth for pages, sections, widgets, theme, navigation, footer, static pages, and feature flags (ADR-004).
 - The Project Editor mutates an in-memory draft of the same `BootstrapConfig` — there is no parallel editor-only model.
@@ -65,7 +65,7 @@ Render pipeline: `page config -> section engine -> section renderer -> widget ho
 ## Feature flags / capability guards (ADR-009)
 - `bootstrap.featureFlags` (typed) plus the broader `bootstrap.features` (`MarketplaceFeaturesConfig`) surface for UI-facing toggles (wishlist, compare, reviews, recommendations, search history, etc.).
- Feature resolution falls back across older config surfaces to preserve behavior as the flag model evolved across sprints — see `docs/backend/BACKEND-INTEGRATION.md#4-bootstrap` for the full field list.
+- Feature resolution falls back across older config surfaces to preserve behavior as the flag model evolved across sprints — see `docs/BACKEND_API.md#4-bootstrap` for the full field list.
 ## Diagnostics (dev-only)
--- a/docs/AUTH.md
+++ b/docs/AUTH.md
@@ -5,7 +5,7 @@ code that exists in `src/app/core/auth/` today, wired to endpoints that do
 not exist on the backend yet. No route currently requires this flow — the
 live admin gate remains the Telegram-QR-based `AdminAuthService` /
 `adminAuthGuard` (`src/app/core/admin-auth/`, documented in
-`docs/backend/BACKEND-INTEGRATION.md` §2.4–2.5). This module is the
+`docs/BACKEND_API.md` §2.4–2.5). This module is the
 integration target once the backend ships the endpoints below.
 Do not point any live route's `canActivate` at `ed25519AuthGuard` until the
@@ -14,7 +14,7 @@ before then would lock every admin out.
 ## 1. Why this exists
-`docs/backend/BACKEND-INTEGRATION.md` §2.5 documents the current system's
+`docs/BACKEND_API.md` §2.5 documents the current system's
 biggest security gap: admin and customer login hit the *same* Telegram
 session endpoint, so the backend has no way to distinguish an admin login
 attempt from a customer one at the moment of login — authorization is
@@ -153,7 +153,7 @@ This is deliberately coarse and mirrors the existing bootstrap-level
 `PermissionsConfig` shape (`src/app/shared/models/config/permissions.model.ts`).
 Finer-grained, per-domain permissions (e.g. "can edit prices but not delete
 products") stay server-side until a real permission model exists there —
-see `docs/backend/BACKEND-INTEGRATION.md` §"Admin-role-required". Use
+see `docs/BACKEND_API.md` §"Admin-role-required". Use
 `PermissionService.has(permission)` / `permissionGuard(permission)` to gate
 UI and routes; never treat a passing client-side check as authorization by
 itself.
@@ -250,7 +250,7 @@ collaborators reachable through it.
  implemented here.
 - **The frontend is not the authorization boundary.** Every admin
  request must be independently checked server-side against the caller's
-  actual role, exactly as `docs/backend/BACKEND-INTEGRATION.md` §2.5
+  actual role, exactly as `docs/BACKEND_API.md` §2.5
  already states for the Telegram flow. A decoded JWT claim or a passing
  `PermissionService.has()` check is UX, not proof.
 - **Refresh tokens should rotate.** Every `POST /refresh` response is
--- a/docs/backend/BACKEND-INTEGRATION.md
+++ b/docs/backend/BACKEND-INTEGRATION.md
@@ -1,6 +1,6 @@
 # Backend Integration — Master Specification
-Status: canonical. This is the single authoritative backend/API contract for this Angular multi-tenant marketplace platform. It supersedes and replaces `docs/BACKEND.md`, `docs/BACKEND-INTEGRATION.md` (old), `docs/BACKEND-INTEGRATION-PROMPT.md`, `docs/BACKEND-DIFF-VS-MAIN.md`, `docs/architecture/backend/Backend-Platform-API-Spec.md`, and the API-contract portions of `docs/BOOTSTRAP.md`. Those files are deleted; this document is where all of that content now lives, verified against the current source tree on branch `B2B`.
+Status: canonical. This is the single authoritative backend/API contract for this Angular multi-tenant marketplace platform. It supersedes and replaces `docs/BACKEND.md`, `docs/BACKEND_API.md` (old), `docs/BACKEND-INTEGRATION-PROMPT.md`, `docs/BACKEND-DIFF-VS-MAIN.md`, `docs/architecture/backend/Backend-Platform-API-Spec.md`, and the API-contract portions of `docs/BOOTSTRAP.md`. Those files are deleted; this document is where all of that content now lives, verified against the current source tree on branch `B2B`.
 Audience: a backend engineer implementing this platform's API with no other context, and any frontend engineer who needs the ground truth for what the client sends and expects.
--- a/docs/BACKEND_API_REMAINING_WORK.md
+++ b/docs/BACKEND_API_REMAINING_WORK.md
@@ -0,0 +1,90 @@
 # Remaining backend work (everything except auth/session)
 Companion to the `API-CONTRACT.md` backend delivered separately (covers `GET /bootstrap`
 transport + `/users/sessions/*` — done, see prior conversation). This file lists what's
 still outstanding. Full request/response shapes, TypeScript
 interfaces, and validation rules for every item below already exist in
 [`docs/BACKEND_API.md`](BACKEND_API.md) — this is a prioritized
 punch list with links into that spec, not a duplicate of it. **Do not re-document
 endpoint shapes here** — edit the master spec if a shape needs to change.
 Status legend (same as master spec): **PLANNED** = shape fully specified client-side,
 served by a mock gateway today, nothing built server-side yet. **FUTURE** = reserved
 contract only, no urgency. Bootstrap's *content* (branding/theme/nav values, not the
 `GET /bootstrap` transport itself) is also still outstanding — see P0 below.
 ---
 ## Status legend for this list
 **DONE** = wired end-to-end on the frontend (real HTTP gateway or real call site, no mock
 left in the path). **PLANNED** = shape fully specified client-side, still served by a mock
 gateway, nothing wired yet. Everything below that isn't marked DONE is still open.
 ## P0 — blocks going live at all
 | # | Item | Status | Spec section |
 |---|---|---|---|
 | 1 | `bootstrap.json` real content (branding, theme, navigation, seo) — currently default stubs per backend's own note in API-CONTRACT.md | open | [§4](BACKEND_API.md#4-bootstrap) |
 | 2 | Builder — bootstrap draft/publish/validate (`GET/PUT /builder/bootstrap/draft`, `POST /builder/bootstrap/publish`, `POST /builder/bootstrap/validate`) — this is how the Marketplace Builder actually saves anything | open | [§6.7](BACKEND_API.md#67-builder--bootstrap-draftpublishvalidate-planned-highest-priority) |
 | 3 | Backoffice — Products CRUD + variants | open | [§6.10](BACKEND_API.md#610-backoffice--products-planned), DTOs [§7.2](BACKEND_API.md#72-products--srcappfeaturesadminproductsmodelsadmin-productmodelts) |
 | 4 | Backoffice — Categories CRUD (tree) | **DONE** — `admin-categories-api.gateway.ts` + `admin-categories-gateway.token.ts` wired, swaps on `RuntimeProviderStrategyService` | [§6.9](BACKEND_API.md#69-backoffice--categories-planned), DTOs [§7.1](BACKEND_API.md#71-categories--srcappfeaturesadmincategoriesmodelsadmin-categorymodelts) |
 | 5 | Media upload/delete/replace pipeline | open | [§6.18](BACKEND_API.md#618-media-planned--adr-0002), [§10](BACKEND_API.md#10-media) |
 ## P1 — needed for real order/commerce flow
 | # | Item | Status | Spec section |
 |---|---|---|---|
 | 6 | Backoffice — Orders CRUD + status transitions | open | [§6.11](BACKEND_API.md#611-backoffice--orders-planned), state machine [§8.1](BACKEND_API.md#81-orders--adminorderstatus) |
 | 7 | Backoffice — Transactions (list/detail, tied to orders) | open | [§6.12](BACKEND_API.md#612-backoffice--transactions-planned) |
 | 8 | Order creation — checkout calls `POST /orders` on payment success | **DONE** — `ApiService.createOrder()` + `CartComponent.recordOrder()`, fire-and-forget alongside `clearCart()`, doesn't touch the frozen payment call chain | [§16.9](BACKEND_API.md#169-order-creation-future--no-order-creation-endpoint-exists-anywhere-yet) |
 | 9 | Backoffice — Users/roles/invitations | open | [§6.13](BACKEND_API.md#613-backoffice--users-roles-invitations-planned) |
 | 10 | Backoffice — Moderation (review + report status transitions) | open | [§6.14](BACKEND_API.md#614-backoffice--moderation-reviews--reports-planned), state machines [§8.4](BACKEND_API.md#84-reviews--adminreviewstatus)/[§8.5](BACKEND_API.md#85-reports--adminreportstatus) |
 ## P2 — dashboards / operational visibility
 | # | Item | Status | Spec section |
 |---|---|---|---|
 | 11 | Backoffice — Dashboard metrics & recent activity | open | [§6.15](BACKEND_API.md#615-backoffice--dashboard-metrics--recent-activity-planned) |
 | 12 | Backoffice — Monitoring (all but Health) | open | [§6.16](BACKEND_API.md#616-backoffice--monitoring-planned-except-health) |
 | 13 | Backoffice — Analytics summary (real once orders are real) | open | [§6.17](BACKEND_API.md#617-backoffice--analytics-mostly-future--no-data-source) |
 | 14 | Builder — Content pages / CMS | open | [§6.8](BACKEND_API.md#68-builder--content-pages--cms-planned) |
 ## P3 — nice-to-have, no urgency
 | # | Item | Status | Spec section |
 |---|---|---|---|
 | 15 | Search suggestions / catalog filters | open | [§6.6](BACKEND_API.md#66-search--autocomplete--trending-planned) |
 | 16 | Cross-device wishlist/compare/saved-searches sync — backend confirmed id-only stays, added `GET /items/batch?ids=` for hydration. Frontend needs `UserExperienceRepository` redesign: id-array + local product cache hydrated via the batch endpoint, replacing today's fully-synchronous denormalized-object storage | open (unblocked, not started) | [§6.6](BACKEND_API.md#66-search--autocomplete--trending-planned) |
 | 17 | Analytics traffic/funnels/heatmaps — needs a tracking pipeline that doesn't exist yet, not just an endpoint | open | [§6.17](BACKEND_API.md#617-backoffice--analytics-mostly-future--no-data-source) |
 | 18 | Sitemap — dynamic generation (static baseline today) | open (server-side, no frontend action) | [§6.19](BACKEND_API.md#619-sitemap-future--static-baseline-only-today) |
 ---
 ## Explicitly not in this list
 - Auth / Telegram session (`GET /bootstrap` transport, `/users/sessions/*`) — covered by
  backend's `API-CONTRACT.md`, frontend wiring matches it exactly.
  - `authApiUrl` env value — **fixed**, now points at the same host as `apiUrl`
    (`https://api.dexarmarket.ru:445`) in both `environment.ts` and `environment.production.ts`.
  - `AdminWebSessionID` header — **fixed a real bug**: the interceptor only attached it to
    URLs containing `/admin/`, but every real backend path is `/backoffice/*`, `/builder/*`,
    `/media/*` — none of those matched, so every new admin call would have silently gone out
    with no admin auth header at all. Broadened the guard in `admin-auth-headers.interceptor.ts`.
  - `telegramBot` username — still unverified against `bot.go`'s `startbot()`.
  - Frontend deploy domain vs. CORS allow-list — **decided**: frontend and API stay on the
    same domain, so this is a non-issue by design rather than something to reconcile against
    an allow-list.
 - Payments — frozen, unchanged, out of scope per [§2.8](BACKEND_API.md#28-payments-frozen-documented-for-completeness).
 - Storefront reads/writes (categories, items, search, cart, reviews) — already real HTTP,
  already working, no backend work needed. See [§6.1](BACKEND_API.md#61-storefront-reads-current--frozen-shapes-srcappservicesapiservicets)–[§6.2](BACKEND_API.md#62-storefront-writes-current--frozen-shapes).
 ## For every open item above, when implementing
 Read the interface + model file cited in the linked spec section before writing the
 endpoint — the shape is already fixed by the frontend gateway interface, not up for
 renegotiation without a frontend change. Follow the pattern now established for Categories
 (`admin-categories-api.gateway.ts` + `admin-categories-gateway.token.ts`): one `*ApiGateway`
 class implementing the existing `*Gateway` interface, plus one `InjectionToken` factory that
 picks mock vs. real off `RuntimeProviderStrategyService`, then switch the facade(s) to inject
 the token instead of the concrete mock class. See [§14](BACKEND_API.md#14-backend-replacement-pattern) for the general pattern.
--- a/docs/EDITOR.md
+++ b/docs/EDITOR.md
@@ -2,7 +2,7 @@
 Replaces the old `docs/Project-Editor.md` (content merged in below and extended with the Sprint 19 field-description/dropdown work).
-The Project Editor (`src/app/features/project-editor/`) edits the tenant's `BootstrapConfig` (`docs/backend/BACKEND-INTEGRATION.md#4-bootstrap`) directly — no parallel model. It is out of scope for products, categories, orders, or analytics management (those live under `features/admin/*`/`features/backoffice/*`, see `docs/ADMIN.md`).
+The Project Editor (`src/app/features/project-editor/`) edits the tenant's `BootstrapConfig` (`docs/BACKEND_API.md#4-bootstrap`) directly — no parallel model. It is out of scope for products, categories, orders, or analytics management (those live under `features/admin/*`/`features/backoffice/*`, see `docs/ADMIN.md`).
 ```
 src/app/features/project-editor/
@@ -46,7 +46,7 @@ Route: `/edit/:section` or `/{lang}/edit/:section`. `/backoffice/static-pages` (
 - **Reset section**: reverts one section's bootstrap keys (per `EDITOR_SECTION_BOOTSTRAP_KEYS` in `models/project-editor.model.ts`) to `originalBootstrap`. Confirmation required.
 - **Reset draft**: reverts the entire bootstrap to `originalBootstrap` and clears the persisted local draft. Confirmation required.
 - **Per-field reset is not implemented** — no per-field default registry exists; only section- and project-level reset.
- **No backend persistence exists for any of this today** — see `docs/backend/BACKEND-INTEGRATION.md#67-builder--bootstrap-draftpublishvalidate-planned-highest-priority` for the endpoints needed.
+- **No backend persistence exists for any of this today** — see `docs/BACKEND_API.md#67-builder--bootstrap-draftpublishvalidate-planned-highest-priority` for the endpoints needed.
 ## Configuration schema, form engine, and validation architecture (Sprint X+1)
@@ -88,7 +88,7 @@ No changes to `ProjectEditorIoService` (export/import), `ProjectEditorDraftStora
 ## Admin Authentication (QR reuse)
-Admin login shares the exact same Telegram QR/session backend and `TelegramLoginComponent` as customer login (`mode: 'admin'` vs `'customer'`) — only the cookie name/`SameSite` policy, token storage keys, and guard differ. **Backend gap:** because both flows hit the same session endpoint, the backend cannot distinguish an admin scan from a customer scan today — real admin authorization must be enforced server-side. Full detail: `docs/backend/BACKEND-INTEGRATION.md#25-the-admin-authorization-gap-critical--security-relevant-unresolved`.
+Admin login shares the exact same Telegram QR/session backend and `TelegramLoginComponent` as customer login (`mode: 'admin'` vs `'customer'`) — only the cookie name/`SameSite` policy, token storage keys, and guard differ. **Backend gap:** because both flows hit the same session endpoint, the backend cannot distinguish an admin scan from a customer scan today — real admin authorization must be enforced server-side. Full detail: `docs/BACKEND_API.md#25-the-admin-authorization-gap-critical--security-relevant-unresolved`.
 ## Design system primitives (post-Sprint 30 redesign)
@@ -125,7 +125,7 @@ Interaction feedback + motion applied consistently, all gated behind `prefers-re
 **HTML-mode validation (Sprint X+2):** switching from raw-HTML back to the visual surface now runs `schema/validators/primitives.validateHtml` (stack-based tag-balance check) first; a malformed edit (unclosed/mismatched tag) stays in code mode with an inline error instead of silently corrupting the visual editor.
-**Caveat:** implemented on the deprecated `document.execCommand` API. It works in all current browsers today but is a legacy web API with no modern drop-in replacement; if a future browser drops it, this component needs a rewrite (e.g. a maintained rich-text library). By design it emits **raw, unsanitized** HTML — sanitization is a storefront-render concern, not an authoring one (see `docs/backend/BACKEND-INTEGRATION.md#68-builder--content-pages--cms-planned` on server-side content moderation on publish; `StaticPageComponent` and `StaticPagePreviewComponent` both run content through `DomSanitizer` before render).
+**Caveat:** implemented on the deprecated `document.execCommand` API. It works in all current browsers today but is a legacy web API with no modern drop-in replacement; if a future browser drops it, this component needs a rewrite (e.g. a maintained rich-text library). By design it emits **raw, unsanitized** HTML — sanitization is a storefront-render concern, not an authoring one (see `docs/BACKEND_API.md#68-builder--content-pages--cms-planned` on server-side content moderation on publish; `StaticPageComponent` and `StaticPagePreviewComponent` both run content through `DomSanitizer` before render).
 ## Field-description / dropdown UX (Sprint 19+)
--- a/docs/FRONTEND-ROADMAP.md
+++ b/docs/FRONTEND-ROADMAP.md
@@ -1,30 +1,30 @@
 # Frontend Roadmap
-Status snapshot, refreshed from recent commits only. Full sprint history: `docs/SPRINT-PLAN.md`. Open bugs: `docs/KNOWN-ISSUES.md`.
+Status snapshot, refreshed from recent commits only. Full sprint history: `docs/archive/SPRINT-PLAN.md`. Open bugs: `docs/KNOWN-ISSUES.md`.
 ## Recently shipped
 **RC-Visual-02 — Composition audit** (storefront, builder, backoffice)
-Fixed undefined CSS theme vars, hand-rolled skeletons/empty-states migrated to shared `app-skeleton`/`app-empty-state`/`app-button`, missing `<th scope="col">`, dead CSS (~530-line unused cart `.alt` theme). Detail: `docs/UI-COMPOSITION-REVIEW.md`.
+Fixed undefined CSS theme vars, hand-rolled skeletons/empty-states migrated to shared `app-skeleton`/`app-empty-state`/`app-button`, missing `<th scope="col">`, dead CSS (~530-line unused cart `.alt` theme). Detail: `docs/archive/UI-COMPOSITION-REVIEW.md`.
 **RC-Premium-01 — Storefront premium UX polish**
-Visual/interaction polish on top of the RC-Visual-02 baseline — no redesign, no logic/route changes. Fixed color-only state signaling app-wide (added `aria-pressed`/`aria-current`/`aria-live` + icon/checkmark pairing to selected swatches, active filters/tabs/sort, toggle buttons), normalized remaining hardcoded hex to design tokens, added hover/focus-visible/active/disabled states across interactive controls, capped legal/CMS prose at 70ch, converted FAQ to native `<details>` disclosures. Four commits (Home/Catalog/Search, Product/Compare/Wishlist, Cart/Checkout, Static Pages). Detail: `docs/STORE_FRONT_UX_REVIEW.md`.
+Visual/interaction polish on top of the RC-Visual-02 baseline — no redesign, no logic/route changes. Fixed color-only state signaling app-wide (added `aria-pressed`/`aria-current`/`aria-live` + icon/checkmark pairing to selected swatches, active filters/tabs/sort, toggle buttons), normalized remaining hardcoded hex to design tokens, added hover/focus-visible/active/disabled states across interactive controls, capped legal/CMS prose at 70ch, converted FAQ to native `<details>` disclosures. Four commits (Home/Catalog/Search, Product/Compare/Wishlist, Cart/Checkout, Static Pages). Detail: `docs/archive/STORE_FRONT_UX_REVIEW.md`.
 **RC STORE-01 — Storefront cleanup**
-Closed 2 of the 5 gaps RC-Premium-01 deliberately deferred: category/search skeleton markup migrated to shared `app-skeleton`, dead cart `.email-form` markup/CSS removed. The other 3 (payment modal, cart confirm() dialog, untokenized colors) need an architecture/design-system decision, correctly left alone again. Detail: `docs/STORE_REVIEW.md`.
+Closed 2 of the 5 gaps RC-Premium-01 deliberately deferred: category/search skeleton markup migrated to shared `app-skeleton`, dead cart `.email-form` markup/CSS removed. The other 3 (payment modal, cart confirm() dialog, untokenized colors) need an architecture/design-system decision, correctly left alone again. Detail: `docs/archive/STORE_REVIEW.md`.
 **RC PERF-01 — Performance audit** (production-readiness, app-wide)
-Initial bundle **1.47 MB → 1.12 MB raw (−24%)**: biggest win was lazy-loading en/hy i18n packs (346 KB were eagerly loaded regardless of visitor language), plus a dead `items-carousel`/primeng-only component deleted, dead global CSS removed. RxJS/change-detection audit found the codebase already clean (0 leaks, 190/191 components already OnPush). Detail: `docs/PERFORMANCE_REPORT.md`.
+Initial bundle **1.47 MB → 1.12 MB raw (−24%)**: biggest win was lazy-loading en/hy i18n packs (346 KB were eagerly loaded regardless of visitor language), plus a dead `items-carousel`/primeng-only component deleted, dead global CSS removed. RxJS/change-detection audit found the codebase already clean (0 leaks, 190/191 components already OnPush). Detail: `docs/archive/PERFORMANCE_REPORT.md`.
 **RC A11Y-01 — WCAG 2.1 AA audit** (storefront, builder, backoffice)
-Added the app's first skip link (didn't exist anywhere before), fixed cart's custom payment modals having zero focus-trap, fixed `app-icon`'s "decorative by default" claim never actually being implemented, fixed 2 keyboard-inaccessible drag-and-drop reorder UIs (Builder homepage/footer, Backoffice categories), fixed an undefined `--color-primary` token in Builder, fixed admin sidebar nav announcing itself as "Dashboard" everywhere. Contrast fixes applied where safe; genuine brand-color contrast failures flagged for theme-owner sign-off, not changed unilaterally. Detail: `docs/ACCESSIBILITY_REPORT.md`.
+Added the app's first skip link (didn't exist anywhere before), fixed cart's custom payment modals having zero focus-trap, fixed `app-icon`'s "decorative by default" claim never actually being implemented, fixed 2 keyboard-inaccessible drag-and-drop reorder UIs (Builder homepage/footer, Backoffice categories), fixed an undefined `--color-primary` token in Builder, fixed admin sidebar nav announcing itself as "Dashboard" everywhere. Contrast fixes applied where safe; genuine brand-color contrast failures flagged for theme-owner sign-off, not changed unilaterally. Detail: `docs/archive/ACCESSIBILITY_REPORT.md`.
 **Release Candidate — live browser walkthrough** (storefront, builder, backoffice)
-Found and fixed **2 P0s**: (1) `language.guard.ts`'s legacy-URL redirect broke query params on every route app-wide (silently dead-ended any bookmarked/shared deep link with query params); (2) Backoffice Categories CRUD was completely broken end-to-end — wrong gateway-resolution fallback always picked the real HTTP gateway instead of the local mock in this environment, so every create/publish silently failed with zero user feedback. Plus 6 P1s (cart description, compare table raw enum values, search empty-state messaging, footer link 404, missing placeholder image, builder save-bar reset-state bug, backoffice mislabeled button). Detail: `docs/RELEASE_REPORT.md`.
+Found and fixed **2 P0s**: (1) `language.guard.ts`'s legacy-URL redirect broke query params on every route app-wide (silently dead-ended any bookmarked/shared deep link with query params); (2) Backoffice Categories CRUD was completely broken end-to-end — wrong gateway-resolution fallback always picked the real HTTP gateway instead of the local mock in this environment, so every create/publish silently failed with zero user feedback. Plus 6 P1s (cart description, compare table raw enum values, search empty-state messaging, footer link 404, missing placeholder image, builder save-bar reset-state bug, backoffice mislabeled button). Detail: `docs/archive/RELEASE_REPORT.md`.
 ## Sprint status
-**Sprint 30 — Final Release**: verify pass re-run 2026-07-23 (tsc --noEmit, `npm run build`, `arch:check:boundaries`, `arch:check:cycles`) — all green, only pre-existing bundle-budget warning. Working tree otherwise clean. Only remaining item: `git push` of 10 local `B2B` commits to `origin/B2B` — awaiting explicit user go-ahead (declined once already this sprint, per safety rules re-ask each time). Full checklist: `docs/SPRINT-PLAN.md`.
+**Sprint 30 — Final Release**: verify pass re-run 2026-07-23 (tsc --noEmit, `npm run build`, `arch:check:boundaries`, `arch:check:cycles`) — all green, only pre-existing bundle-budget warning. Working tree otherwise clean. Only remaining item: `git push` of 10 local `B2B` commits to `origin/B2B` — awaiting explicit user go-ahead (declined once already this sprint, per safety rules re-ask each time). Full checklist: `docs/archive/SPRINT-PLAN.md`.
 ## Known open items (not yet scheduled)
@@ -41,7 +41,8 @@ Full detail in `docs/KNOWN-ISSUES.md`. Summary:
 - `dynamic-renderer/` pipeline exists but is unwired — needs a finish-or-delete decision.
 - `primeng`/`primeicons` still in `package.json` despite the only consumer being deleted (RC PERF-01) — `npm uninstall` blocked by an unrelated broken `barry-cache` devDependency (`ETARGET`); fix that first.
 - 2 large lazy chunks (`project-editor` 320 kB, `catalog-container` 126 kB) — no mechanical split found, needs a dedicated task.
- Backend integration: still mostly PLANNED/mock — a "backend ready" sprint was attempted and explicitly deferred (2026-07-24) pending a real API contract (no `docs/BACKEND-API.md`, no live endpoint confirmation beyond what's already CURRENT).
+- **CRITICAL**: `pages/category`, `pages/search`, `pages/item-detail`, `pages/info/**`, `pages/legal/**` (40+ files) are entirely unrouted dead code — `cmsContentRoutes` in `app.routes.ts` is a literal empty array. Several fixes in `docs/archive/` were applied to this dead code with zero production effect. See `docs/KNOWN-ISSUES.md` item 13 — needs a wire-it-up-or-delete-it decision.
 - Backend integration: still mostly PLANNED/mock — a "backend ready" sprint was attempted and explicitly deferred (2026-07-24) pending a real API contract (`docs/BACKEND_API.md` is the canonical spec — no live endpoint confirmation beyond what's already CURRENT).
 ## Not audited / out of scope
--- a/docs/FRONTEND.md
+++ b/docs/FRONTEND.md
@@ -51,4 +51,4 @@ src/app/
 ## Dynamic widget/section rendering from bootstrap JSON
-Full detail in `docs/ARCHITECTURE.md` and `docs/backend/BACKEND-INTEGRATION.md#4-bootstrap`. Summary: `page config (bootstrap.pages) -> Section Engine (order/layout/visibility) -> Page Renderer -> Widget Host (resolves component via Widget Manifest + data via Data Source Resolver) -> widget component (props + resolved data only)`. Nothing in this pipeline calls an API directly except the Data Source Resolver, which delegates to `CategoryFacade`/`ProductFacade`.
+Full detail in `docs/ARCHITECTURE.md` and `docs/BACKEND_API.md#4-bootstrap`. Summary: `page config (bootstrap.pages) -> Section Engine (order/layout/visibility) -> Page Renderer -> Widget Host (resolves component via Widget Manifest + data via Data Source Resolver) -> widget component (props + resolved data only)`. Nothing in this pipeline calls an API directly except the Data Source Resolver, which delegates to `CategoryFacade`/`ProductFacade`.
--- a/docs/KNOWN-ISSUES.md
+++ b/docs/KNOWN-ISSUES.md
@@ -38,7 +38,7 @@ don't fix inline unless asked.
   - Found: 2026-07-15, during Sprint 28 manual audit (reading templates +
     grepping i18n files, not live browser).
   - **Deferred to Sprint 29** ("translation validation" is explicit Sprint 29
-     scope per `docs/SPRINT-PLAN.md`) rather than fixed inline during Sprint
+     scope per `docs/archive/SPRINT-PLAN.md`) rather than fixed inline during Sprint
     28 polish - authoring ~534 correct strings across 3 languages is a large,
     separate, mechanical pass of its own and shouldn't be rushed inside a
     polish sprint. Sprint 28 only adds the handful of new keys it introduces
@@ -80,11 +80,11 @@ don't fix inline unless asked.
   Correction (2026-07-24, RC A11Y-01): the "already has focus-trap" assumption
   below was wrong — it had none. RC A11Y-01 ported `app-dialog`'s confirmed-
   correct focus-trap/Escape/return-focus pattern directly onto it
-   (`docs/ACCESSIBILITY_REPORT.md`), so the accessibility gap is closed. It's
+   (`docs/archive/ACCESSIBILITY_REPORT.md`), so the accessibility gap is closed. It's
   still a separate custom component, not the shared `app-dialog` itself —
   migrating it to the actual primitive remains a composition change,
   deliberately left out of every polish pass so far.
-   - Found: 2026-07-23, RC-Premium-01 (`docs/STORE_FRONT_UX_REVIEW.md`).
+   - Found: 2026-07-23, RC-Premium-01 (`docs/archive/STORE_FRONT_UX_REVIEW.md`).
 7. **Cart's `clearCart()` uses native `confirm()`, no styled confirm dialog.**
   No existing storefront pattern for a confirm-remove dialog to follow yet —
@@ -102,13 +102,13 @@ don't fix inline unless asked.
   `--success/--warning/--error/--info-color` fail 4.5:1 when used as plain
   text-on-white in a handful of places. Real palette colors, not a token
   bug — fixing means visibly changing the brand, needs theme-owner sign-off.
-   - Found: 2026-07-24, RC A11Y-01 (`docs/ACCESSIBILITY_REPORT.md`).
+   - Found: 2026-07-24, RC A11Y-01 (`docs/archive/ACCESSIBILITY_REPORT.md`).
 10. **Footer "Contacts" link has no static-page content in mock data.**
    Unlike the "About" link (which was a route-name mismatch, fixed), no
    content exists for Contacts at all — needs a content decision, not a
    code fix.
-    - Found: 2026-07-24, Release Candidate walkthrough (`docs/RELEASE_REPORT.md`).
+    - Found: 2026-07-24, Release Candidate walkthrough (`docs/archive/RELEASE_REPORT.md`).
 11. **Builder's static-page body editor is hidden and mislabeled.** The
    actual WYSIWYG content editor isn't on the "Content" tab (title/image
@@ -123,7 +123,46 @@ don't fix inline unless asked.
    pre-existing, unrelated broken `barry-cache` devDependency resolution —
    fix that first, then drop the now-fully-unused dependency (likely closes
    most of the remaining bundle-budget overage in one move).
-    - Found: 2026-07-24, RC PERF-01 (`docs/PERFORMANCE_REPORT.md`).
+    - Found: 2026-07-24, RC PERF-01 (`docs/archive/PERFORMANCE_REPORT.md`).
 13. **CRITICAL — `pages/category/*`, `pages/search/*`, `pages/item-detail/*`,
    `pages/info/**`, `pages/legal/**` (40+ files) are entirely unrouted dead
    code, not live pages.** Verified directly against `src/app/app.routes.ts`:
    `category/:id` and `category/:id/items` `redirectTo: 'catalog/:id'`
    (served by `CatalogContainerComponent`); `search` also routes to
    `CatalogContainerComponent`; `product/:id` routes to
    `ProductDetailsContainerComponent`, not `pages/item-detail`;
    `cmsContentRoutes` (meant to route `pages/info/**`/`pages/legal/**`) is a
    literal empty array (`app.routes.ts:292`) behind a
    `// TODO(CMS): Resolve informational/legal pages from backend content
    configuration here` comment — About/Contacts/FAQ/Delivery/Guarantee/
    Company-Details/Payment-Terms/Return-Policy/Public-Offer/Privacy-Policy
    are all actually served by the catch-all `:staticPath` route resolving
    `bootstrap.staticPages` (`pages/static-page/static-page.component.ts`),
    confirmed independently by `docs/FRONTEND.md`'s own routing section
    ("Static/CMS pages resolve dynamically... no hardcoded page list").
    **This means several "fixes" earlier in this document and in
    `docs/archive/` were applied to dead code with zero production effect**
    — see the correction note on Fixed item 7 below. This was missed by
    three separate passes this cycle (RC-Premium-01, RC STORE-01, and the
    dead-code cleanup sprint, which manually re-verified against
    `app.routes.ts` and still concluded these files were live — an error in
    that verification, not a tooling blind spot this time) before being
    caught during the documentation-consolidation pass. Needs a decision:
    wire `cmsContentRoutes` back up (restoring 10 hardcoded per-locale pages
    that duplicate what the CMS static-page renderer already does), or
    delete all 40+ files as genuinely dead now that the duplication is
    confirmed intentional-by-omission rather than accidental.
    - Found: 2026-07-25, Documentation Cleanup pass.
 14. **No `canDeactivate` guard on `admin/products/:id/edit`.** Categories
    protect against navigating away with unsaved changes
    (`adminCategoryDirtyGuard`, `app.routes.ts:121,131`); products do not,
    despite `AdminProductsFacade` having its own dirty-tracking draft logic.
    Inconsistent, low-effort fix (mirror the categories guard) but not
    applied here — this pass is documentation-only.
    - Found: 2026-07-19 (`docs/archive/PROJECT-STATE.md`), re-verified
      2026-07-25 against current `app.routes.ts` — still true.
 ## Fixed
@@ -280,7 +319,11 @@ don't fix inline unless asked.
   `.skeleton-card`/`.skeleton-image`/`.skeleton-line` shimmer CSS with
   hardcoded hex colors, duplicating what `app-skeleton` already provides
   and what `catalog-container`/`product-details-container` already use.
-   - Fixed: 2026-07-23, RC STORE-01 (`docs/STORE_REVIEW.md`).
+   - Fixed: 2026-07-23, RC STORE-01 (`docs/archive/STORE_REVIEW.md`).
   - **Correction (2026-07-25):** these files are unrouted dead code (Open
     item 13) — the fix is real and harmless but currently has zero
     production effect. Live category/search rendering goes through
     `CatalogContainerComponent`, not these files.
 8. **Cart's dead `.email-form` markup and CSS removed.** Post-payment
   email/phone-capture form was commented-out markup with a matching
@@ -295,7 +338,7 @@ don't fix inline unless asked.
   a dead route). This guard runs on every top-level route app-wide, so any
   bookmarked/shared deep link with query params was silently broken —
   found during the Builder RC walkthrough but affects all 3 surfaces.
-   - Fixed: 2026-07-24, Release Candidate walkthrough (`docs/RELEASE_REPORT.md`),
+   - Fixed: 2026-07-24, Release Candidate walkthrough (`docs/archive/RELEASE_REPORT.md`),
     `router.parseUrl()` instead of a hand-built path segment.
 10. **Backoffice Categories CRUD completely broken end-to-end (P0).**
--- a/docs/PROJECT-STRUCTURE.md
+++ b/docs/PROJECT-STRUCTURE.md
@@ -28,7 +28,7 @@ Standards referenced below are enforced, not suggestions: `docs/architecture/fou
 2. **Gateway interface** — `services/admin-dashboard-metrics.gateway.interface.ts`. An abstract contract (`AdminDashboardMetricsGateway`) for "however we get category/product counts" — deliberately decoupled from *how* (local computation vs. real API) so the facade never knows which implementation is active.
-3. **Gateway implementation** — `services/admin-dashboard-metrics.local.gateway.ts`. `AdminDashboardMetricsLocalGateway implements AdminDashboardMetricsGateway`, composing `BackofficeDataService.loadCategories()/loadProducts()` (already used elsewhere) into counts. A future `AdminDashboardMetricsApiGateway` would implement the same interface against a real endpoint (`docs/backend/BACKEND-INTEGRATION.md#615-backoffice--dashboard-metrics--recent-activity-planned`) — nothing above this layer changes when that happens.
+3. **Gateway implementation** — `services/admin-dashboard-metrics.local.gateway.ts`. `AdminDashboardMetricsLocalGateway implements AdminDashboardMetricsGateway`, composing `BackofficeDataService.loadCategories()/loadProducts()` (already used elsewhere) into counts. A future `AdminDashboardMetricsApiGateway` would implement the same interface against a real endpoint (`docs/BACKEND_API.md#615-backoffice--dashboard-metrics--recent-activity-planned`) — nothing above this layer changes when that happens.
 4. **DI token** — `services/admin-dashboard-metrics-gateway.token.ts`. `const ADMIN_DASHBOARD_METRICS_GATEWAY = new InjectionToken<AdminDashboardMetricsGateway>(...)`, bound to the local gateway by default in `app.config.ts`. This is the swap point: rebinding this token to a real API gateway is the *only* change needed to go from mock to real data.
@@ -56,5 +56,5 @@ Full narrative and known gaps: `docs/ADMIN.md`.
 8. Build the container/page component that injects the facade and wires routing.
 9. Add routes in `app.routes.ts`, with `adminAuthGuard` (or the relevant guard) if it's an admin surface.
 10. Add every new user-facing string to `i18n/translations.ts` (interface) then `en.ts`/`ru.ts`/`hy.ts` — never hardcode copy in a template.
-11. Document backend gaps (if any) in `docs/backend/BACKEND-INTEGRATION.md` (§6, endpoints by domain) using the same CURRENT/PLANNED/FUTURE tagging as the existing entries.
+11. Document backend gaps (if any) in `docs/BACKEND_API.md` (§6, endpoints by domain) using the same CURRENT/PLANNED/FUTURE tagging as the existing entries.
 12. Run `npm run arch:check` (import boundaries + circular dependencies) and `npx tsc -p tsconfig.app.json --noEmit` before committing.
--- a/docs/PROJECT.md
+++ b/docs/PROJECT.md
@@ -1,85 +0,0 @@
 # Marketplace Platform
 ## Read First
 - **DESIGN.md** — does not exist under this name; closest equivalent is [ARCHITECTURE.md](ARCHITECTURE.md) (system design) + `docs/architecture/foundation/**` (enforced standards/ADRs).
 - **BACKEND-API.md** — does not exist under this name; canonical spec is [backend/BACKEND-INTEGRATION.md](backend/BACKEND-INTEGRATION.md).
 - **[ADMIN.md](ADMIN.md)**
 - **[EDITOR.md](EDITOR.md)**
 - **[KNOWN-ISSUES.md](KNOWN-ISSUES.md)**
 - **[FRONTEND-ROADMAP.md](FRONTEND-ROADMAP.md)**
 - **ADR/** — `docs/architecture/foundation/adr/` (ADR-001…ADR-010) and `docs/context/adrs/`.
 ## What this is
 A configuration-driven, multi-tenant SaaS marketplace platform (Angular 18+, standalone components). One frontend codebase serves unlimited tenants ("marketplaces"). Tenant identity, theme, navigation, page/section/widget composition, and static content are all resolved from a per-tenant `bootstrap.json` fetched at runtime — no tenant-specific code paths exist in the frontend. See `docs/ARCHITECTURE.md` and `docs/backend/BACKEND-INTEGRATION.md#4-bootstrap` for the mechanics.
 Every tenant conceptually has three surfaces on this one codebase:
 - **Website** — the public storefront (catalog, product pages, cart, static pages).
 - **Builder** (Project Editor) — an in-app editor that edits the tenant's `BootstrapConfig` (see `docs/EDITOR.md`).
 - **Backoffice** (Admin) — an admin area for products, and (as of Sprint 19) a dashboard; more domains are placeholders pending backend (see `docs/ADMIN.md`).
 ## Tenant / marketplace model
 - Tenant is resolved **only by request domain/host** — never by query param, localStorage, or hardcoded ID.
 - The frontend loads `GET /bootstrap` (tenant resolved server-side by host) and renders entirely from that JSON: theme, layout, navigation, pages, sections, widgets, static pages, feature flags.
 - Widgets never call APIs directly; they receive resolved data through facades/resolvers.
 - New tenants are onboarded by domain + bootstrap config + backend data, not by forking the frontend.
 - Full contract: `docs/backend/BACKEND-INTEGRATION.md#4-bootstrap`.
 ## Doc index
 - **[ARCHITECTURE.md](ARCHITECTURE.md)** — layered architecture, container/facade/service pattern, bootstrap/theme/widget engines, links to the enforced ADRs.
 - **[backend/BACKEND-INTEGRATION.md](backend/BACKEND-INTEGRATION.md)** — the single canonical backend/API spec: architecture, auth, security, bootstrap, conventions, every endpoint (CURRENT/PLANNED/FUTURE), DTOs, state machines, validation, media, errors, localization, caching. Start here if you're a backend engineer picking up this project.
 - **[FRONTEND.md](FRONTEND.md)** — app structure, routing, i18n, theming, state management (signals/facades, no NgRx), dynamic rendering.
 - **[EDITOR.md](EDITOR.md)** — the Project Editor: every section, the save/publish/draft/reset model, and the field-description/dropdown UX.
 - **[StaticPages.md](StaticPages.md)** — the Static Pages module: full field reference, per-page draft/publish gating, CRUD/search/filter/bulk, rich text, device preview, nav integration (Sprint X+2).
 - **[PROJECT-STRUCTURE.md](PROJECT-STRUCTURE.md)** — folder-by-folder tour of `src/app/**` with a worked "add a new feature" example (admin dashboard).
 - **[ADMIN.md](ADMIN.md)** — Sprint 19 admin dashboard: routing, architecture, data sources, known gaps.
 - **[FRONTEND-ROADMAP.md](FRONTEND-ROADMAP.md)** — status snapshot refreshed from recent commits; sprint progress, known open items.
 - **[KNOWN-ISSUES.md](KNOWN-ISSUES.md)** — running list of open/fixed bugs found during manual verification.
 - **[PERFORMANCE_REPORT.md](PERFORMANCE_REPORT.md)** — RC PERF-01: bundle/reactivity/asset audit and fixes.
 - **[ACCESSIBILITY_REPORT.md](ACCESSIBILITY_REPORT.md)** — RC A11Y-01: WCAG 2.1 AA audit and fixes across all 3 surfaces.
 - **[RELEASE_REPORT.md](RELEASE_REPORT.md)** — live browser release-candidate walkthrough, P0/P1 findings and fixes.
 - `docs/architecture/foundation/**` — the enforced ADRs (ADR-001…ADR-010) and standards docs (Coding-Standards, Naming-Conventions, Dependency-Rules, Folder-Blueprint, Import-Boundary-Matrix, State-Management-Standards, Configuration-Standards, Component-Standards, Service-Standards). These are governance, not narrative — read them directly; `ARCHITECTURE.md` only links to them.
 - `docs/context/**` — Barry Cache's own source-backed memory system. Infrastructure, not project documentation; do not edit by hand.
 ## How to run it
 From `package.json`:
 ```bash
 npm install
 npm run start          # ng serve
 npm run start:dexar     # ng serve --configuration=development --port 4200
 npm run build           # ng build
 npm run build:dexar     # ng build --configuration=production
 npm run watch           # ng build --watch --configuration development
 npm run arch:check      # boundary + circular-dependency checks (tools/architecture/check-boundaries.mjs, madge)
 ```
 Barry Cache (repo memory, optional but recommended before/after non-trivial work):
 ```bash
 npm run barry -- resume --task "<task>"
 npm run barry -- validate
 ```
 See root `CLAUDE.md` for the full Barry Cache workflow and memory policy.
 ## Current Status
 - **Frontend: 96%**
 - **Backend:** in progress — still mostly PLANNED/mock gateways, no confirmed live backend contract (see `docs/backend/BACKEND-INTEGRATION.md`)
 - **Storefront polish:** done (RC-Visual-02, RC-Premium-01, RC STORE-01)
 - **Performance audit:** done — see [PERFORMANCE_REPORT.md](PERFORMANCE_REPORT.md) (initial bundle −24%)
 - **Angular v22:** pending
 - **Accessibility audit:** done — see [ACCESSIBILITY_REPORT.md](ACCESSIBILITY_REPORT.md) (WCAG 2.1 AA, storefront/builder/backoffice)
 - **Release-candidate walkthrough:** done — see [RELEASE_REPORT.md](RELEASE_REPORT.md) (2 P0s + 6 P1s found and fixed via live browser walkthrough)
 - **First client demo:** upcoming
 Detail behind each line: sprint-by-sprint history in [FRONTEND-ROADMAP.md](FRONTEND-ROADMAP.md) / `docs/SPRINT-PLAN.md` (Sprints 20-30, all shipped except Sprint 30's `git push`, pending explicit go-ahead), open defects in [KNOWN-ISSUES.md](KNOWN-ISSUES.md), backend gap list in `docs/backend/BACKEND-INTEGRATION.md` and `docs/backend/REMAINING-BACKEND-WORK.md`.
 Draft/publish for the Project Editor is still **frontend-only** (localStorage), with no backend persistence — the single largest backend gap, see `docs/backend/BACKEND-INTEGRATION.md#67-builder--bootstrap-draftpublishvalidate-planned-highest-priority`.
 This documentation set (`docs/PROJECT.md`, `ARCHITECTURE.md`, `backend/BACKEND-INTEGRATION.md`, `FRONTEND.md`, `EDITOR.md`, `PROJECT-STRUCTURE.md`) replaces ~35 previously scattered files under `docs/platform/`, `docs/backend-platform/`, and various one-off sprint reports, which have been consolidated and removed.
--- a/docs/PROJECT_INDEX.md
+++ b/docs/PROJECT_INDEX.md
@@ -0,0 +1,87 @@
 # Marketplace Platform — Documentation Index
 This is the entry point. Read this first — it links to everything else and tells you what's actually true right now versus what's historical.
 ## ⚠️ Read before touching routing or storefront static pages
 `pages/category/*`, `pages/search/*`, `pages/item-detail/*`, `pages/info/**`, and `pages/legal/**` (40+ files) look like live storefront pages but are **entirely unrouted dead code**. `src/app/app.routes.ts`'s `cmsContentRoutes` is a literal empty array. The real routes redirect `category/:id`/`search` to `CatalogContainerComponent`, `product/:id` to `ProductDetailsContainerComponent`, and every static/legal page (About, Contacts, FAQ, etc.) is served by the catch-all `:staticPath` route resolving `bootstrap.staticPages` — not by the hardcoded components under `pages/info`/`pages/legal`. Full detail: [KNOWN-ISSUES.md](KNOWN-ISSUES.md) item 13. Several polish passes in `docs/archive/` were applied to this dead code before this was caught — treat any claim in an archived doc about "the category page" or "the search page" as **not describing what currently renders in production**.
 ## What this is
 A configuration-driven, multi-tenant SaaS marketplace platform (Angular 21.1, standalone components). One frontend codebase serves unlimited tenants ("marketplaces"). Tenant identity, theme, navigation, page/section/widget composition, and static content all resolve from a per-tenant `bootstrap.json` fetched at runtime — no tenant-specific code paths exist in the frontend. New tenants are onboarded by domain + config + backend data, never by forking the frontend.
 Every tenant has three surfaces on this one codebase:
 - **Website** — the public storefront (catalog, product pages, cart, static pages).
 - **Builder** (Project Editor, `/edit/**`) — an in-app editor that edits the tenant's `BootstrapConfig`.
 - **Backoffice** (Admin, `/:lang/backoffice/**`) — the admin area: products, categories (live-wired to a real gateway), orders, transactions, users, monitoring, analytics, media.
 ## System overview
 - **Architecture**: `Component (container) → Facade → Domain Service → Repository/Provider (DI token, swappable mock↔API) → Mock | API`. Enforced by `npm run arch:check` (import boundaries + circular deps), not just convention. Full detail: [ARCHITECTURE.md](ARCHITECTURE.md), governance docs at `docs/architecture/foundation/**` (10 ADRs + 9 standards docs).
 - **State**: Signals-based facades everywhere, no NgRx (ADR-007).
 - **Rendering**: Bootstrap JSON → Section Engine → Page Renderer → Widget Host → registered widget component (ADR-005). 100% lazy-loaded routes.
 - **Theming**: CSS custom properties per tenant, 3 theme stylesheets, never hardcoded hex in a component (ADR-008). Design system spec: [`DESIGN.md`](../DESIGN.md) (root of repo).
 - **i18n**: 3 locales (en/ru/hy), compile-time-enforced key parity across locale files.
 - **Backend**: mostly PLANNED (mock gateways behind swappable provider tokens) — see [BACKEND_API.md](BACKEND_API.md) for the full CURRENT/PLANNED/FUTURE endpoint spec, [BACKEND_API_REMAINING_WORK.md](BACKEND_API_REMAINING_WORK.md) for the prioritized punch list. Categories is the one domain fully wired to a real HTTP gateway; everything else is local/mock.
 ## Doc index (living documents)
 Read these directly — they're the current source of truth, not one-off reports:
 | Doc | What it covers |
 |---|---|
 | [ARCHITECTURE.md](ARCHITECTURE.md) | Layered architecture, container/facade/service pattern, bootstrap/theme/widget engines, links to the enforced ADRs |
 | [BACKEND_API.md](BACKEND_API.md) | Canonical backend/API spec — every endpoint, DTO, state machine, error contract |
 | [BACKEND_API_REMAINING_WORK.md](BACKEND_API_REMAINING_WORK.md) | Prioritized backend punch list (companion to the spec above) |
 | [FRONTEND.md](FRONTEND.md) | App structure, routing, i18n, theming, state management, dynamic rendering |
 | [EDITOR.md](EDITOR.md) | The Project Editor: every section, save/publish/draft/reset model |
 | [StaticPages.md](StaticPages.md) | The Static Pages CMS module (the thing that actually serves About/Contacts/etc. today) |
 | [PROJECT-STRUCTURE.md](PROJECT-STRUCTURE.md) | Folder-by-folder tour of `src/app/**` with a worked feature-add example |
 | [ADMIN.md](ADMIN.md) | Admin backoffice: routing, architecture, data sources |
 | [AUTH.md](AUTH.md) | Ed25519 admin auth — prepared, not live; current live gate is Telegram-QR |
 | [FRONTEND-ROADMAP.md](FRONTEND-ROADMAP.md) | Status snapshot refreshed from recent commits — what shipped, what's open |
 | [KNOWN-ISSUES.md](KNOWN-ISSUES.md) | Running list of open/fixed bugs found during manual verification |
 | [ANGULAR22_PLAN.md](ANGULAR22_PLAN.md) | Angular 22 upgrade feasibility (research only, not yet executed) |
 | [SALES-GUIDE.md](SALES-GUIDE.md) | Plain-language guide for the sales team — what to demo, what's not live yet |
 | [`../DESIGN.md`](../DESIGN.md) | Visual design system: colors, typography, elevation, component specs |
 | [`../PRODUCT.md`](../PRODUCT.md) | Product positioning, users, brand personality, anti-references |
 | [`../CHANGELOG.md`](../CHANGELOG.md) | Keep-a-Changelog-format history of shipped features |
 | `docs/architecture/foundation/**` | Enforced ADRs (ADR-001…ADR-010) and standards docs — governance, read directly |
 | `docs/context/**` | Barry Cache's own source-backed memory system — infrastructure, not project documentation, do not edit by hand |
 **One topic, one place**: routing lives in FRONTEND.md, not repeated here. Backend contract lives in BACKEND_API.md, not repeated in ADMIN.md. Design tokens live in DESIGN.md, not repeated in the archived UI review docs. If you find the same fact stated two places with different values, the doc in this table wins over anything in `docs/archive/`.
 ## Historical / completed audits — `docs/archive/`
 One-time audit reports, sprint reports, and polish-pass logs. Useful for "why was this changed" archaeology, **not** for "what's true now" — check the living docs above for that. Contents: `SPRINT-PLAN.md`, `ADMIN-UX-AUDIT.md`, `ADMIN_REVIEW.md`, `RELEASE-CANDIDATE-AUDIT.md`, `STORE_FRONT_REVIEW.md`, `STORE_FRONT_UX_REVIEW.md`, `STORE_REVIEW.md`, `UI-COMPOSITION-REVIEW.md`, `UI-DESIGN-REVIEW.md`, `UI-ICON-AUDIT.md`, `PERFORMANCE_REPORT.md`, `ACCESSIBILITY_REPORT.md`, `RELEASE_REPORT.md`, `CLEANUP_REPORT.md`, `PROJECT-STATE.md`, plus 3 early sprint reports and a platform-standardization report at the repo root's `docs/archive/`. Every open finding worth keeping from these was merged into [KNOWN-ISSUES.md](KNOWN-ISSUES.md) or [FRONTEND-ROADMAP.md](FRONTEND-ROADMAP.md) before archiving — nothing was lost, just deduplicated.
 ## How to run it
 ```bash
 npm install
 npm run start           # ng serve
 npm run start:dexar      # ng serve --configuration=development --port 4200
 npm run build            # ng build
 npm run build:dexar      # ng build --configuration=production
 npm run arch:check       # boundary + circular-dependency checks
 ```
 Barry Cache (repo memory, optional but recommended before/after non-trivial work):
 ```bash
 npm run barry -- resume --task "<task>"
 npm run barry -- validate
 ```
 See root `CLAUDE.md` for the full Barry Cache workflow and memory policy.
 ## Current status
 - **Frontend**: ~96% of planned UI built. Storefront/Builder/Backoffice all have working UI; several polish/audit passes complete (see below).
 - **Backend**: in progress — mostly PLANNED/mock gateways, no confirmed live backend contract beyond auth/session and storefront reads. Categories is the one domain fully wired to a real gateway.
 - **Storefront polish, performance audit, WCAG 2.1 AA accessibility audit, release-candidate walkthrough**: all done — see [FRONTEND-ROADMAP.md](FRONTEND-ROADMAP.md) for the summary of each, `docs/archive/` for the full original reports.
 - **Angular 22 upgrade**: not started, feasibility researched — see [ANGULAR22_PLAN.md](ANGULAR22_PLAN.md) (verdict: safe, ~2-3.5 days, 2 tooling blockers to clear first).
 - **Documentation**: consolidated (this pass) — 19 one-off reports archived, 2 files renamed for clarity (`PROJECT.md`→`PROJECT_INDEX.md`, `backend/BACKEND-INTEGRATION.md`→`BACKEND_API.md`), 1 duplicate deleted (`RELEASE-NOTES.md` merged into `CHANGELOG.md`).
 - **First client demo**: upcoming — blocked on nothing documentation can fix; see [KNOWN-ISSUES.md](KNOWN-ISSUES.md) for what's still open, starting with the dead-routes finding at the top of this document.
 Draft/publish for the Project Editor is still **frontend-only** (localStorage), no backend persistence — the single largest backend gap, see [BACKEND_API.md §6.7](BACKEND_API.md#67-builder--bootstrap-draftpublishvalidate-planned-highest-priority).
--- a/docs/StaticPages.md
+++ b/docs/StaticPages.md
@@ -1,6 +1,6 @@
 # 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/BACKEND-INTEGRATION.md#46-staticpages`), no parallel content store.
+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_API.md#46-staticpages`), no parallel content store.
 `/backoffice/static-pages` (Admin dashboard) redirects here rather than hosting a second CRUD UI over the same data.
--- a/docs/architecture/foundation/adr/ADR-004-configuration-bootstrap-and-provider-abstraction.md
+++ b/docs/architecture/foundation/adr/ADR-004-configuration-bootstrap-and-provider-abstraction.md
@@ -2,10 +2,10 @@
 Status: Superseded
 Date: 2026-07-03
-Superseded by: `docs/backend/BACKEND-INTEGRATION.md` §4 (Bootstrap) and §14 (Backend replacement pattern)
+Superseded by: `docs/BACKEND_API.md` §4 (Bootstrap) and §14 (Backend replacement pattern)
 ## Original decision (preserved for history)
 Configuration must initially come from mock JSON and later from backend API without changing consumers. `ConfigService` is the only configuration entrypoint; consumers depend on typed selectors only; provider implementation is swappable (`MockBootstrapProvider` / `ApiBootstrapProvider`); the frontend calls `GET /bootstrap` when the API provider is enabled and never passes a tenant id.
-This decision remains in effect. The full, verified contract — endpoint, caching, field-by-field DTO reference, and the generalized mock↔API provider-swap pattern this ADR introduced (now used by every admin domain, not just bootstrap) — lives in `docs/backend/BACKEND-INTEGRATION.md`. Read that document for current, code-verified detail; this file is kept only so ADR-numbered references in `docs/architecture/foundation/README.md` continue to resolve.
+This decision remains in effect. The full, verified contract — endpoint, caching, field-by-field DTO reference, and the generalized mock↔API provider-swap pattern this ADR introduced (now used by every admin domain, not just bootstrap) — lives in `docs/BACKEND_API.md`. Read that document for current, code-verified detail; this file is kept only so ADR-numbered references in `docs/architecture/foundation/README.md` continue to resolve.
--- a/docs/architecture/foundation/adr/ADR-010-backward-compatibility-for-auth-payment-authorization.md
+++ b/docs/architecture/foundation/adr/ADR-010-backward-compatibility-for-auth-payment-authorization.md
@@ -2,10 +2,10 @@
 Status: Superseded
 Date: 2026-07-03
-Superseded by: `docs/backend/BACKEND-INTEGRATION.md` §2 (Authentication), §2.8 (Payments), §2.5 (admin authorization gap)
+Superseded by: `docs/BACKEND_API.md` §2 (Authentication), §2.8 (Payments), §2.5 (admin authorization gap)
 ## Original decision (preserved for history)
 Authentication and payment flows are proven and contract-sensitive. Platform refactoring must not break existing integrations. Freeze behavior and contracts for authentication flow, payment API interactions, and authorization logic. Allow only encapsulation and integration-layer isolation, not contract redesign.
-This decision remains in effect. The full, verified contract — the Telegram QR/session flow, cookie policy, the frozen payment endpoint shapes, and the still-unresolved admin-authorization gap this ADR's constraint interacts with — lives in `docs/backend/BACKEND-INTEGRATION.md` §2 and §2.5–§2.8. Read that document for current, code-verified detail; this file is kept only so ADR-numbered references in `docs/architecture/foundation/README.md` continue to resolve.
+This decision remains in effect. The full, verified contract — the Telegram QR/session flow, cookie policy, the frozen payment endpoint shapes, and the still-unresolved admin-authorization gap this ADR's constraint interacts with — lives in `docs/BACKEND_API.md` §2 and §2.5–§2.8. Read that document for current, code-verified detail; this file is kept only so ADR-numbered references in `docs/architecture/foundation/README.md` continue to resolve.
--- a/docs/archive/ACCESSIBILITY_REPORT.md
+++ b/docs/archive/ACCESSIBILITY_REPORT.md
--- a/docs/archive/ADMIN-UX-AUDIT.md
+++ b/docs/archive/ADMIN-UX-AUDIT.md
@@ -6,7 +6,7 @@
 **Screens covered:** Dashboard, Categories (list + create), Products (list + create), Orders (list + detail), Transactions, Users & permissions, Monitoring, Analytics, Media Library.
-> Scope note: the ~178-key missing-translation bug (every `adminProducts.*`, `adminCategories.*`, `adminOrders.*`, `adminTransactions.*`, `adminUsers.*`, `adminMonitoring.*`, `adminAnalytics.*` string rendering as a raw key like `adminProducts.create`) is **already tracked** in [KNOWN-ISSUES.md](KNOWN-ISSUES.md#2) and deferred to Sprint 29. This audit does not re-report it as a new bug, but treats it as the single biggest blocker to a first-time user understanding *any* admin screen, and uses the raw keys as a proxy for the intended copy when judging IA and labeling choices below.
+> Scope note: the ~178-key missing-translation bug (every `adminProducts.*`, `adminCategories.*`, `adminOrders.*`, `adminTransactions.*`, `adminUsers.*`, `adminMonitoring.*`, `adminAnalytics.*` string rendering as a raw key like `adminProducts.create`) is **already tracked** in [KNOWN-ISSUES.md](../KNOWN-ISSUES.md#2) and deferred to Sprint 29. This audit does not re-report it as a new bug, but treats it as the single biggest blocker to a first-time user understanding *any* admin screen, and uses the raw keys as a proxy for the intended copy when judging IA and labeling choices below.
 ---
@@ -85,7 +85,7 @@ Same shape and same issues as Categories list (filters/search/create button all
 3. Table structure itself (order #, customer, price, date, view) is legible even with raw status-key values, because the *layout* (a plain table) is a familiar pattern.
 4. **Confusing:**
   - Every status badge renders as `adminOrders.status.pending` / `.processing` / etc. instead of a real label — and there's no color-coding visible in the text-only pass to compensate (needs a live visual check for whether color alone carries the status, which would itself be an accessibility problem if true).
-   - Dates render as **`7/17/26, 11:39 PM`** — US month/day/year format — on a `ru` locale page. Confirmed locale-hardcoded date formatting bug, same family of issue as the previously-fixed `en/ru/hy` tab-hardcoding bug noted in [KNOWN-ISSUES.md](KNOWN-ISSUES.md).
+   - Dates render as **`7/17/26, 11:39 PM`** — US month/day/year format — on a `ru` locale page. Confirmed locale-hardcoded date formatting bug, same family of issue as the previously-fixed `en/ru/hy` tab-hardcoding bug noted in [KNOWN-ISSUES.md](../KNOWN-ISSUES.md).
   - "24 `adminProducts.items`" — the pagination footer on the *Orders* list borrows the word "items" from the *Products* translation namespace. Third confirmed instance (after Categories' visibility filter and this) of admin modules cross-borrowing copy from Products instead of having their own strings — suggests Products was built first and every later module was scaffolded by copy-pasting it without renaming keys.
 5. **Missing:** No bulk status update, no date-range filter (only a status filter is present), no order search by customer name/number.
 8. **Dangerous:** "Export" action with no visible confirmation or indication of what leaves the system (all orders? filtered view? does it include customer PII, and if so is that flagged for the user?). Worth a data-privacy pass, not just a UX one.
--- a/docs/archive/ADMIN_REVIEW.md
+++ b/docs/archive/ADMIN_REVIEW.md
--- a/docs/archive/CLEANUP_REPORT.md
+++ b/docs/archive/CLEANUP_REPORT.md
@@ -1,5 +1,7 @@
 # Cleanup Report
 > **Archived, correction (2026-07-25):** this pass concluded `pages/category`, `pages/search`, `pages/info/**`, `pages/legal/**`, `pages/item-detail` were live/routed and kept them — that conclusion was **wrong**. A later documentation-consolidation pass confirmed directly against `app.routes.ts` that all of these are genuinely unrouted dead code (`cmsContentRoutes` is a literal empty array). See `docs/KNOWN-ISSUES.md` item 13. Kept here for historical accuracy of the process description (the false-positive root-cause analysis re: knip's blind spot is still useful) — the conclusion about these files being "correctly kept" is superseded.
 App-wide dead-code sweep: dead components/services/routes/CSS, duplicate models/interfaces, unused imports/variables/assets/icons/SCSS/directories/modules. Business logic untouched — deletion only, no refactoring. One commit on branch `B2B` (not pushed): `e0bcf9d`.
 ## Important note on process
--- a/docs/archive/PERFORMANCE_REPORT.md
+++ b/docs/archive/PERFORMANCE_REPORT.md
--- a/docs/archive/PROJECT-STATE.md
+++ b/docs/archive/PROJECT-STATE.md
--- a/docs/archive/Platform-Standardization-Report.md
+++ b/docs/archive/Platform-Standardization-Report.md
--- a/docs/archive/RELEASE-CANDIDATE-AUDIT.md
+++ b/docs/archive/RELEASE-CANDIDATE-AUDIT.md
--- a/docs/archive/RELEASE_REPORT.md
+++ b/docs/archive/RELEASE_REPORT.md
--- a/docs/archive/SPRINT-PLAN.md
+++ b/docs/archive/SPRINT-PLAN.md
--- a/docs/archive/STORE_FRONT_REVIEW.md
+++ b/docs/archive/STORE_FRONT_REVIEW.md
--- a/docs/archive/STORE_FRONT_UX_REVIEW.md
+++ b/docs/archive/STORE_FRONT_UX_REVIEW.md
@@ -1,5 +1,7 @@
 # Storefront Premium UX Review — RC-Premium-01
 > **Archived, correction (2026-07-25):** the FAQ/legal-page polish below was applied to `pages/info/**`/`pages/legal/**`, which turned out to be unrouted dead code (the CMS static-page renderer serves these routes in production, not these components) — see `docs/KNOWN-ISSUES.md` item 13. Kept here for historical accuracy.
 Follow-up to `docs/UI-COMPOSITION-REVIEW.md` (RC-Visual-02). That sprint fixed *composition* bugs — undefined theme variables, hand-rolled skeletons/empty-states replaced with shared components, missing `scope="col"`. This sprint (RC-Premium-01) is a narrower, purely *visual/interaction* polish pass on top of that clean baseline: hierarchy, spacing, states, motion, accessibility signaling. No redesign, no business-logic changes, no route changes, no new components — reuses `src/app/shared/ui/*` and the existing token set in `src/styles.scss` exclusively.
 Executed as four sequential commits on branch `B2B` (not pushed):
--- a/docs/archive/STORE_REVIEW.md
+++ b/docs/archive/STORE_REVIEW.md
@@ -1,5 +1,7 @@
 # Storefront Review — RC STORE-01
 > **Archived, correction (2026-07-25):** the category/search skeleton fix below was applied to `pages/category/*`/`pages/search/*`, which turned out to be unrouted dead code — see `docs/KNOWN-ISSUES.md` item 13. The fix itself is harmless but has zero production effect. Kept here for historical accuracy.
 Mission: polish the customer-facing storefront only (Home, Catalog, Search, Product, Compare, Wishlist, Cart, Checkout, Static Pages). No redesign, no architecture change, no Builder/Backoffice changes. Reused existing `src/app/shared/ui/*` components exclusively.
 This is the third storefront-focused pass, on top of two prior sprints already documented:
--- a/docs/archive/Sprint-10-Advanced-Search-Report.md
+++ b/docs/archive/Sprint-10-Advanced-Search-Report.md
--- a/docs/archive/Sprint-11-User-Experience-Report.md
+++ b/docs/archive/Sprint-11-User-Experience-Report.md
--- a/docs/archive/Sprint-9-Product-Engagement-Report.md
+++ b/docs/archive/Sprint-9-Product-Engagement-Report.md
--- a/docs/archive/UI-COMPOSITION-REVIEW.md
+++ b/docs/archive/UI-COMPOSITION-REVIEW.md
--- a/docs/archive/UI-DESIGN-REVIEW.md
+++ b/docs/archive/UI-DESIGN-REVIEW.md
--- a/docs/archive/UI-ICON-AUDIT.md
+++ b/docs/archive/UI-ICON-AUDIT.md
--- a/docs/backend/REMAINING-BACKEND-WORK.md
+++ b/docs/backend/REMAINING-BACKEND-WORK.md
@@ -1,75 +0,0 @@
 # Remaining backend work (everything except auth/session)
 Companion to the `API-CONTRACT.md` backend delivered separately (covers `GET /bootstrap`
 transport + `/users/sessions/*` — done, see prior conversation). This file lists what's
 still outstanding. Full request/response shapes, TypeScript
 interfaces, and validation rules for every item below already exist in
 [`docs/backend/BACKEND-INTEGRATION.md`](BACKEND-INTEGRATION.md) — this is a prioritized
 punch list with links into that spec, not a duplicate of it. **Do not re-document
 endpoint shapes here** — edit the master spec if a shape needs to change.
 Status legend (same as master spec): **PLANNED** = shape fully specified client-side,
 served by a mock gateway today, nothing built server-side yet. **FUTURE** = reserved
 contract only, no urgency. Bootstrap's *content* (branding/theme/nav values, not the
 `GET /bootstrap` transport itself) is also still outstanding — see P0 below.
 ---
 ## P0 — blocks going live at all
 | # | Item | Spec section |
 |---|---|---|
 | 1 | `bootstrap.json` real content (branding, theme, navigation, seo) — currently default stubs per backend's own note in API-CONTRACT.md | [§4](BACKEND-INTEGRATION.md#4-bootstrap) |
 | 2 | Builder — bootstrap draft/publish/validate (`GET/PUT /builder/bootstrap/draft`, `POST /builder/bootstrap/publish`, `POST /builder/bootstrap/validate`) — this is how the Marketplace Builder actually saves anything | [§6.7](BACKEND-INTEGRATION.md#67-builder--bootstrap-draftpublishvalidate-planned-highest-priority) |
 | 3 | Backoffice — Products CRUD + variants | [§6.10](BACKEND-INTEGRATION.md#610-backoffice--products-planned), DTOs [§7.2](BACKEND-INTEGRATION.md#72-products--srcappfeaturesadminproductsmodelsadmin-productmodelts) |
 | 4 | Backoffice — Categories CRUD (tree) | [§6.9](BACKEND-INTEGRATION.md#69-backoffice--categories-planned), DTOs [§7.1](BACKEND-INTEGRATION.md#71-categories--srcappfeaturesadmincategoriesmodelsadmin-categorymodelts) |
 | 5 | Media upload/delete/replace pipeline | [§6.18](BACKEND-INTEGRATION.md#618-media-planned--adr-0002), [§10](BACKEND-INTEGRATION.md#10-media) |
 ## P1 — needed for real order/commerce flow
 | # | Item | Spec section |
 |---|---|---|
 | 6 | Backoffice — Orders CRUD + status transitions | [§6.11](BACKEND-INTEGRATION.md#611-backoffice--orders-planned), state machine [§8.1](BACKEND-INTEGRATION.md#81-orders--adminorderstatus) |
 | 7 | Backoffice — Transactions (list/detail, tied to orders) | [§6.12](BACKEND-INTEGRATION.md#612-backoffice--transactions-planned) |
 | 8 | Order creation endpoint — **does not exist anywhere yet**; checkout today only calls the frozen cart-payment endpoints, nothing creates an `AdminOrder` | [§16.9](BACKEND-INTEGRATION.md#169-order-creation-future--no-order-creation-endpoint-exists-anywhere-yet) |
 | 9 | Backoffice — Users/roles/invitations | [§6.13](BACKEND-INTEGRATION.md#613-backoffice--users-roles-invitations-planned) |
 | 10 | Backoffice — Moderation (review + report status transitions) | [§6.14](BACKEND-INTEGRATION.md#614-backoffice--moderation-reviews--reports-planned), state machines [§8.4](BACKEND-INTEGRATION.md#84-reviews--adminreviewstatus)/[§8.5](BACKEND-INTEGRATION.md#85-reports--adminreportstatus) |
 ## P2 — dashboards / operational visibility
 | # | Item | Spec section |
 |---|---|---|
 | 11 | Backoffice — Dashboard metrics & recent activity | [§6.15](BACKEND-INTEGRATION.md#615-backoffice--dashboard-metrics--recent-activity-planned) |
 | 12 | Backoffice — Monitoring (all but Health) | [§6.16](BACKEND-INTEGRATION.md#616-backoffice--monitoring-planned-except-health) |
 | 13 | Backoffice — Analytics summary (real once orders are real) | [§6.17](BACKEND-INTEGRATION.md#617-backoffice--analytics-mostly-future--no-data-source) |
 | 14 | Builder — Content pages / CMS | [§6.8](BACKEND-INTEGRATION.md#68-builder--content-pages--cms-planned) |
 ## P3 — nice-to-have, no urgency
 | # | Item | Spec section |
 |---|---|---|
 | 15 | Search suggestions / catalog filters | [§6.6](BACKEND-INTEGRATION.md#66-search--autocomplete--trending-planned) |
 | 16 | Cross-device wishlist/compare/saved-searches sync (currently 100% localStorage, works fine without this) | [§6.6](BACKEND-INTEGRATION.md#66-search--autocomplete--trending-planned) |
 | 17 | Analytics traffic/funnels/heatmaps — needs a tracking pipeline that doesn't exist yet, not just an endpoint | [§6.17](BACKEND-INTEGRATION.md#617-backoffice--analytics-mostly-future--no-data-source) |
 | 18 | Sitemap — dynamic generation (static baseline today) | [§6.19](BACKEND-INTEGRATION.md#619-sitemap-future--static-baseline-only-today) |
 ---
 ## Explicitly not in this list
 - Auth / Telegram session (`GET /bootstrap` transport, `/users/sessions/*`) — covered by
  backend's `API-CONTRACT.md`, frontend wiring already matches it exactly. Three small
  gaps remain from that delivery (see prior conversation): `authApiUrl` env value still
  points at the old host, `telegramBot` username unverified, frontend deploy domain needs
  confirming against the CORS allow-list. None of those are new backend work — they're
  config/confirmation follow-ups on what was already delivered.
 - Payments — frozen, unchanged, out of scope per [§2.8](BACKEND-INTEGRATION.md#28-payments-frozen-documented-for-completeness).
 - Storefront reads/writes (categories, items, search, cart, reviews) — already real HTTP,
  already working, no backend work needed. See [§6.1](BACKEND-INTEGRATION.md#61-storefront-reads-current--frozen-shapes-srcappservicesapiservicets)–[§6.2](BACKEND-INTEGRATION.md#62-storefront-writes-current--frozen-shapes).
 ## For every item above, when implementing
 Read the interface + model file cited in the linked spec section before writing the
 endpoint — the shape is already fixed by the frontend gateway interface, not up for
 renegotiation without a frontend change. When an endpoint is done, the frontend swap is
 a one-file gateway rebind (see [§14](BACKEND-INTEGRATION.md#14-backend-replacement-pattern)) — no page/component changes needed on our side.
`@@ -51,4 +51,4 @@ src/app/`

	`## Dynamic widget/section rendering from bootstrap JSON`	`## Dynamic widget/section rendering from bootstrap JSON`

	Full detail in `docs/ARCHITECTURE.md` and `docs/backend/BACKEND-INTEGRATION.md#4-bootstrap`. Summary: `page config (bootstrap.pages) -> Section Engine (order/layout/visibility) -> Page Renderer -> Widget Host (resolves component via Widget Manifest + data via Data Source Resolver) -> widget component (props + resolved data only)`. Nothing in this pipeline calls an API directly except the Data Source Resolver, which delegates to `CategoryFacade`/`ProductFacade`.	Full detail in `docs/ARCHITECTURE.md` and `docs/BACKEND_API.md#4-bootstrap`. Summary: `page config (bootstrap.pages) -> Section Engine (order/layout/visibility) -> Page Renderer -> Widget Host (resolves component via Widget Manifest + data via Data Source Resolver) -> widget component (props + resolved data only)`. Nothing in this pipeline calls an API directly except the Data Source Resolver, which delegates to `CategoryFacade`/`ProductFacade`.