96c1527d1b
Principal-architect-level review of the entire Seller Management body of work (7 prior docs + all touched code), verified against fresh tsc --noEmit and arch:check runs, not recalled from memory. Real bug found and fixed (in scope per this mission's "unless absolutely required" carve-out - a one-line correctness fix to already-committed code, not new feature work): AdminSellerManagementPageComponent.sellerManagementEnabled read the bootstrap snapshot once via a plain signal() at construction, not reactively via bootstrapRevision() the way UiRuntimeFacade/SeoService both correctly do elsewhere in this codebase. Fixed to computed() keyed on bootstrapRevision(). Currently invisible (flag is always false, signal was never even read in the template) but would have gone stale the moment bootstrap ever reloaded with the flag true. tsc clean after the fix. Findings documented in Seller-Management-Final-Design-Review.md (no Critical/High severity found anywhere): - Medium: SellerConfig (bootstrap wire shape) and Seller/SellerBranding (domain entity) are two unreconciled type hierarchies for the same concept - self-flagged already in BACKEND.md SS11.6, restated here as an independently-confirmed finding rather than letting it drift. - Medium: no reusable capability-guard abstraction exists anywhere in the codebase, despite ADR-009/ADR-011 both prescribing "check the flag in one place" - ADR-009's own described FeatureFlagService was never built. Fine with one consumer, a real drift risk the moment a second one needs the same check. - Medium: the flag's true branch has never been exercised, even manually - every verification claim in this whole body of work was tested at the flag's real value (false). - Low/nice-to-have: sellerId typed as bare string instead of the UUID alias used everywhere else in the new sellers domain; MarketplaceRef vs TenantConfig overlap (deliberate, documented, but worth watching); documentation-to-code ratio (8 docs, zero backend bytes) carries a consolidation-burden risk, especially the Unified/Split-Orders question restated independently in 4 different docs. - Explicitly checked for and did NOT find: circular dependencies, scattered tenant/seller conditionals, over-engineering relative to the typed-models-only mandate, or any auth/payment code touched. Verdict: not an unqualified "ready for implementation" - two Medium findings should be resolved by decision/small build before real backend work starts, not because they block anything today but because both compound in cost the longer they're left unresolved. Everything actually built (typed foundation, disabled-by-default flag, Phase 1 UI, plus the bug this review fixed) is solid and ready to stay exactly as-is. No Critical or High-severity issue found anywhere.
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.