5374401257
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>
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
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.