Goal: this document alone, pasted into a fresh Claude session, should be enough for a backend dev to implement against without getting stuck or inventing conventions the frontend doesn't actually need. Fixed a real bug: ~65 cross-references throughout the document pointed to docs/AUTHENTICATION.md, docs/ERROR_CONTRACT.md, docs/MAINTENANCE_MODE.md - three sibling docs that were deleted and fully merged into this document's own §4/§6/§10 during the earlier doc-consolidation pass, but the in-text references were never updated. A fresh agent following those links would hit dead ends repeatedly. Bulk-replaced with in- document section references; hand-fixed ~4 sentences that framed §6/ §10 as "sibling task, in progress" (stale - both are complete, this document's §6/§10 already are the settled contract, nothing to wait on). Added "Recommended default" to every item across the document's 5 consolidated "Requires backend decision" registers (§2.12 framework, §3.21 CRUD cross-cutting - 18 items, §4 §12 auth open items - 9 items, §6 error-model summary - 9 items, §10 maintenance-mode list - 5 items). Each default is derived from what the frontend already implies or standard REST/security convention - no invented APIs or business rules. ~6 items are explicitly flagged as real business/security decisions instead (order state-machine rules, Ed25519 cutover strategy, refresh-token reuse-detection posture) since those carry consequences no amount of frontend-code-reading can resolve. Added a "How to use this document" preamble up front: work in §9's dependency order not document order, apply recommended defaults and keep moving, only stop for the explicitly-flagged business/security items, don't invent beyond what's written or directly implied. Frontend side: confirmed nothing else is left. docs/TODO.md already has zero blockers; docs/KNOWN-ISSUES.md's one open item (unreachable Ed25519 error-code UI) is correctly left open and documented rather than faked closed - fixing it needs a real backend emitting real distinguishable error codes, which doesn't exist yet and can't be fabricated without inventing an API contract. No frontend code touched. No architecture changed. No APIs invented.
Marketplace Frontend
Angular 21 multi-tenant marketplace platform frontend. Standalone components, signals, no NgRx. One codebase serves unlimited tenants ("marketplaces") via a per-tenant bootstrap.json fetched at runtime — no tenant-specific code paths.
Three surfaces on this one codebase:
- Storefront (
/) — the public shopping site: catalog, product pages, cart, static/CMS pages. - Builder / Project Editor (
/edit/**) — in-app editor that edits the tenant'sBootstrapConfig(theme, nav, homepage sections, widgets, footer, languages, static pages). - Backoffice / Admin (
/:lang/backoffice/**) — products, categories, orders, transactions, users, moderation, media, monitoring, analytics.
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: docs/ARCHITECTURE.md, governance ADRs at docs/architecture/foundation/**.
Frontend status
Release Candidate — feature-complete. See docs/PROJECT_STATUS.md for the honest current-state breakdown (completion %, known limitations, readiness for demo/production/backend).
Backend
Not implemented yet — fully specified. Every domain currently runs against an in-memory/mock gateway except Categories (the one domain wired to a real HTTP API). The complete contract a backend engineer needs — every endpoint, DTO, auth flow, error model, upload contract, and a step-by-step implementation checklist — lives in one canonical document:
How to switch Mock ↔ API
Toggle useMockData in src/environments/environment.ts (or environment.production.ts). RuntimeProviderStrategyService (src/app/core/providers/runtime-provider-strategy.service.ts) reads this flag per-domain to decide whether a facade gets the mock or real gateway. On localhost with useMockData: false, some domains (bootstrap, categories) still fall back to mock automatically so local dev never silently hits a real backend by accident — see that service for the exact per-domain logic.
Development
npm install # install dependencies
npm start # local dev server
npm run build # production build -> dist/dexarmarket/
npm run arch:check # import-boundary + circular-dependency check
Folder structure
src/
├── app/
│ ├── components/ # Shared storefront components (header, footer, product-card, etc.)
│ ├── core/ # Auth, admin-auth, config/tenant resolution, DI providers, interceptors
│ ├── dynamic-renderer/ # Bootstrap JSON -> section/widget rendering pipeline (live homepage engine)
│ ├── facades/ # Runtime, website, builder, and backoffice facades
│ ├── features/ # Domain features: admin/*, project-editor, content-management, website/*
│ ├── guards/ # Route guards (language, admin-auth, dirty-state, etc.)
│ ├── i18n/ # Translation service, pipe, and locale packs (en/ru/hy)
│ ├── pages/ # Top-level routed pages: home, cart, static-page
│ ├── services/ # API, cart, auth, SEO, Telegram, and language services
│ ├── shared/ # Shared UI primitives (button, dialog, confirm-dialog, table, etc.)
│ └── widgets/ # Dynamic-renderer widget components
├── assets/mock/ # Local mock configuration and catalog data
├── environments/ # Development and production environment settings (incl. useMockData)
└── styles/ # Shared global styles and themes
Documentation map
Full index: docs/PROJECT_INDEX.md. Key entry points:
| Doc | What it covers |
|---|---|
docs/PROJECT_STATUS.md |
Current completion status, honest limitations, demo/production readiness |
docs/BACKEND.md |
The one canonical backend spec — endpoints, DTOs, auth, security, errors, uploads, checklist |
docs/NEXT_PHASE.md |
Roadmap: backend integration → testing → performance → monitoring → v2 |
docs/TODO.md |
Release blockers only |
docs/KNOWN-ISSUES.md |
Real, reproducible, currently-open frontend bugs |
docs/PRODUCT_BACKLOG.md |
Items needing a client/business decision |
DESIGN.md |
Visual design system |
PRODUCT.md |
Product positioning |
Notes
- Authentication and payment integrations are on their existing contracts — see
docs/BACKEND.mdfor the auth/security contract a real backend must satisfy. - Client-facing content should avoid placeholder names, mock labels, and temporary routes.