f2499df6a9
Audit only, no code changed - every fact gathered by reading current facades/gateways/components on this branch, not assumed. Covers all 13 admin modules (Dashboard, Products, Categories, Orders, Customers, Users, Analytics, Reviews/Moderation, Media, CMS, Builder, Settings, Monitoring, Transactions). Per module: answers the 3 readiness questions (does Marketplace Owner see everything / would Seller see only their own / would Seller Staff be limited), documents where a future scope would be injected (an existing method/interface parameter to extend - no "if seller" checks introduced anywhere), lists components that currently assume global ownership, and classifies Ready / Needs scope / Needs permissions / Needs API change. Key findings: - Only 3 of 13 gateways (Categories, Dashboard-metrics, Media) are DI-token-swappable today; everything else needs that seam added first, independent of seller scoping. - Orders is the load-bearing blocker: Customers, Transactions, and half of Analytics all derive from its same unscoped full-fetch order list, and AdminOrderItem has no per-item seller attribution at all - the concrete gap behind Seller-Management.md's open Unified-vs-Split- Orders question. - Users already carries an AdminUserScope/AdminRole concept (label- only today) - the natural future home for the Marketplace Owner/ Seller/Seller Staff/Platform Admin role vocabulary. - CMS/Static Pages and Builder/Project Editor are structurally not about data scoping at all (marketplace-wide content, single global config document respectively) - seller-level work there is new product surface, not an extension. - No admin module anywhere does role-based hiding of buttons or data today - confirmed, not assumed. Linked from docs/architecture/foundation/README.md alongside the other Seller Management docs.
Marketplace Platform Architecture Foundation
Status: Approved Owner: Lead Software Architect Date: 2026-07-03
Purpose
This folder defines the mandatory engineering governance for transforming this codebase into a reusable, configuration-driven, multi-tenant Marketplace Platform (Marketplace-as-a-Service).
This repository is not treated as a single marketplace website. It is a platform runtime that must support unlimited tenants from one Angular application.
Platform Principles
- One codebase, unlimited tenants.
- Every tenant has three surfaces: Website, Builder, Backoffice.
- Frontend contains no tenant-specific implementation code.
- Tenant behavior is controlled by configuration loaded at bootstrap.
- Authentication, payment, authorization behavior and contracts remain unchanged.
- Prefer composition over inheritance.
- Prefer configuration over conditionals.
- No circular dependencies.
- Shared and UI layers are feature-agnostic.
Non-Negotiable Constraints
- Authentication behavior remains exactly as current implementation.
- Payment API behavior remains exactly as current implementation.
- Authorization behavior remains exactly as current implementation.
- Existing authentication and payment API contracts cannot be changed.
- Proven modules are reused, wrapped, and isolated, not redesigned.
Document Set
Architecture Decision Records
Seller Management (optional, in preparation — not built)
- Seller-Management.md — capability overview, start here
- ADR-011 — decision record
- Seller-Management-Diagrams.md — hierarchy, bootstrap gate, type diagram
- Seller-Management-Domain-Models.md — typed models, optional sellerId fields
- Seller-Management-UX-Review.md — UX/accessibility review of the Phase 1 UI
- Seller-Management-Backoffice-Readiness-Audit.md — per-module scoping/permissions readiness audit
Engineering Rule Documents
- Folder Blueprint
- Import Boundary Matrix
- Dependency Rules
- Naming Conventions
- Coding Standards
- Component Standards
- Service Standards
- Configuration Standards
- State Management Standards
Compliance
All new work must comply with this foundation. If an implementation conflicts with these rules, implementation must be adjusted. If a rule must change, an ADR update is required first.
Sprint 11.5 Standardization Audit (2026-07-09)
Platform-wide standardization was executed before Admin Platform work.
Completed Standardization
- Verified and enforced container/facade/domain/infrastructure boundaries across active website features.
- Removed remaining legacy variant naming in application-layer templates/styles.
- Removed duplicate legacy search-history implementation in catalog feature module.
- Standardized design-token surface with explicit spacing, radius, shadow, and transition tokens.
- Added widget metadata support for title/subtitle/visibility/layout/animation/style/permissions in shared contracts and dynamic rendering path.
- Converted remaining identified hardcoded UI strings in audited runtime pages/components to translation keys.
Bootstrap/Configuration Gaps Identified
- Widget permission model supports auth gating but role/permission enforcement is limited by current auth session shape (no role list in session model).
- Popular search defaults are currently facade-local and should be moved to bootstrap-configurable catalog search settings.
- Storage key naming conventions for local persistence are platform-scoped but still static constants; optional bootstrap override could improve tenant isolation.
Validation Baseline
- Build and architecture checks are required for acceptance of this sprint.
- Final details and file-level changes are tracked in
Platform-Standardization-Report.md.
Mandatory Phase Order
Implementation must proceed only in this order:
- Foundation structure only, app compiles.
- Shared interfaces and types only.
- Mocked configuration payloads only.
- ConfigService abstraction only.
- Theme engine.
- Dynamic rendering engine.
- Reusable widget library.
- Website from configuration.
- Builder from configuration domain.
- Backoffice from business domain.
- Backend documentation.
For each phase:
- Explain what will be created.
- Explain why.
- List files to create.
- Explain dependencies.
- Implement only that phase.
- Verify build integrity.
- Stop and wait.