marketplaces/docs/archive/PROJECT-STATE.md

PROJECT-STATE — Lead Architect Audit

Audited: 2026-07-19, branch B2B, commit d853ecb (HEAD at audit time). Method: Direct source reading (components, facades, gateways, services, models, SCSS, routing) plus parallel research passes over the same source tree, cross-checked against docs/ARCHITECTURE.md, docs/ADMIN.md, docs/EDITOR.md, docs/StaticPages.md, docs/KNOWN-ISSUES.md, docs/SPRINT-PLAN.md, and docs/backend/BACKEND-INTEGRATION.md. Every claim below is either grounded in a specific file:line citation or explicitly marked "not verified" / "not exhaustively verified." Prior docs were treated as leads, not truth — every claim reused from them was re-checked against current code during this pass (several turned out to be stale, e.g. the ~178 missing admin i18n keys logged in docs/KNOWN-ISSUES.md were fixed by commit 574f038 and no longer reproduce).

No files were modified to produce this document except this one.

---

1. Overall architecture

Stack

Angular 21.1.5, 100% standalone components (grep -rl "NgModule" src/app --include=*.ts → 0 hits). No global state library — no @ngrx/*, @ngxs/*, or similar in package.json. State management is plain injectable Angular services combining RxJS and signals ("service-with-signals"), matching ADR-007 (docs/architecture/foundation/adr/ADR-007-state-management-and-facade-boundaries.md).

Routing (src/app/app.routes.ts, 307 lines)

• Every route sits under a :lang prefix (app.routes.ts:297-305), guarded by languageGuard (src/app/guards/language.guard.ts), which validates the language code against LanguageService.languages, redirects disabled/unknown codes to the current default, and preserves the rest of the path. Bare URLs without a lang prefix redirect to ru (app.routes.ts:307) — ru is the hardcoded fallback default, not configurable from routing alone.
• 100% lazy-loaded: every route entry uses loadComponent(() => import(...)); no eager route components exist anywhere in coreRoutes (app.routes.ts:10-284) or the backoffice children array (app.routes.ts:56-252).
• Admin (/​:lang/backoffice/**) is a single AdminLayoutComponent shell (app.routes.ts:58, src/app/features/admin/shell/admin-layout.component.ts) behind adminAuthGuard (app.routes.ts:57), with ~20 lazy child routes.
• canDeactivate dirty-guards protect unsaved edits: projectEditorDirtyGuard (app.routes.ts:53), adminCategoryDirtyGuard (app.routes.ts:118,128). No equivalent guard exists for admin/products edit forms — confirmed by absence of a canDeactivate entry on the products/:id/edit route (app.routes.ts:88-96) despite AdminProductsFacade having its own dirty-tracking draft logic (per Sprint 21 in docs/ADMIN.md). This is an inconsistency: categories protect against navigating away with unsaved changes, products do not.
• cmsContentRoutes is a deliberately empty array (app.routes.ts:286-289) with a TODO(CMS) comment: "Disabled hardcoded pages: about, contacts, faq, delivery, guarantee, company-details, payment-terms, return-policy, public-offer, privacy-policy." These pages exist as fully-built components under src/app/pages/info/** and src/app/pages/legal/** (40 files, per-locale duplicated) but are entirely unrouted dead code today — see Section 6.
• Everything unmatched falls through to a catch-all :staticPath route (app.routes.ts:280-283) resolved dynamically by StaticPageComponent against bootstrap.staticPages.
• Dev-only /__diagnostics route is excluded from production via an environment.production ternary at the top of the routes array (app.routes.ts:293-296).
• No dedicated 404/not-found route exists. Unmatched paths under :lang redirect to home (app.routes.ts:303, { path: '**', redirectTo: '' }) rather than rendering an error state — a user hitting a genuinely broken link is silently bounced to the homepage with no "page not found" feedback.
• No maintenance-mode route or component exists anywhere in the codebase (confirmed: no file matching *maintenance* under src/app).

app.config.ts (35 lines)

• provideRouter with withInMemoryScrolling({ scrollPositionRestoration: 'top' }).
• provideHttpClient with a fixed, order-significant interceptor chain: mockDataInterceptor → apiBaseUrlInterceptor → apiHeadersInterceptor → adminAuthHeadersInterceptor → cacheInterceptor (app.config.ts:25-27).
• Two DI overrides hardcoded directly in app.config.ts, not switched by the runtime-provider-strategy mechanism used elsewhere: Ed25519VerificationService → NoopEd25519VerificationService (line 28 — a fail-open/no-op placeholder for a verification step that isn't implemented) and MediaRepository → MockMediaRepository (line 29 — the entire media library has no API implementation at all, see Section 5).

Layered architecture (ADR-002/006/007)

Component (container)  -->  Facade  -->  Domain Service  -->  Repository/Provider (DI token)  -->  Mock | API

flowchart LR
  A[Container/Page Component] -->|inject facade| B[Facade]
  B -->|composes| C[Domain Service]
  C -->|DTO to domain mapper| D[Repository / Provider Interface]
  D -->|InjectionToken factory, mode from RuntimeProviderStrategyService| E1[Mock Provider]
  D -->|InjectionToken factory| E2[Api Provider - HttpClient]
  B --> F[Signals / Observables exposed to component]
  G[Presentational Component] -->|Input/Output only| A

• Presentational components (src/app/shared/ui/**, src/app/ui-library/{atoms,molecules,organisms}/**) are @Input()/@Output()-only — no HttpClient, storage, or facade injection (ADR-006). Verified spot checks (dialog, table, skeleton, empty-state, button) confirm this.
• Container/page components (src/app/pages/**, src/app/features/*/containers/**, src/app/features/*/pages/**) own routing and DI of a facade.
• Facades live in src/app/facades/{platform,runtime,website}/ plus feature-local facade/ folders (e.g. src/app/features/admin/products/facade/admin-products.facade.ts). Inconsistency found: ProductFacade (src/app/facades/platform/product.facade.ts) uses constructor DI and is a thin pass-through; CategoryFacade (src/app/facades/platform/category.facade.ts) uses inject() and exposes both signals and RxJS observables side by side for the same data (allCategories/allCategories$, selectedCategory/selectedCategory$), with the signals populated imperatively inside subscriptions rather than derived via computed()/toSignal(). Two facades in the same directory follow two different reactive idioms — this is real internal inconsistency, not a style nit, since it means new contributors have no single pattern to copy.
• Domain services (src/app/core/<domain>/*.service.ts) convert DTOs to domain models via mappers (e.g. src/app/core/categories/mappers/category.mapper.ts); DTOs are not supposed to leak past this boundary.
• Repositories/providers are swapped via InjectionToken factories reading RuntimeProviderStrategyService — see Section 5 for the full mechanism and where it is (and is not) actually wired.

DI style

Mixed: inject() appears in ~132 files, constructor DI in ~72 files (grep, file counts not occurrences) — no single convention is enforced project-wide, and both patterns appear within the same architectural layer (see ProductFacade vs CategoryFacade above).

Signals usage

signal( appears in 53 files, computed( in 47 files. Representative: AuthService (src/app/services/auth.service.ts) exposes private writable signals (sessionSignal, statusSignal, showLoginSignal) via .asReadonly() plus computed() derivations (isAuthenticated, displayName) — this is the cleanest, most idiomatic example in the codebase and is mirrored almost exactly by AdminAuthService (src/app/core/admin-auth/admin-auth.service.ts:31-39, read in full during this audit — same shape, deliberately kept separate per the file's own doc comment explaining admin/customer session isolation).

Change detection

ChangeDetectionStrategy.OnPush is used in 188 of 189 @Component-decorated files (grep count) — effectively universal. This is a genuine architectural strength; see Section 10.

Dynamic page/section/widget rendering (ADR-005)

Pipeline: page config -> section engine -> section renderer -> widget host -> registered widget component.

• SectionEngineService (src/app/dynamic-renderer/section-engine/section-engine.service.ts, 130 lines) builds an ordered render model from PageConfig.sections.
• PageRendererService (src/app/dynamic-renderer/page-renderer/page-renderer.service.ts, 13 lines) is a thin pass-through to the Section Engine.
• WidgetHostService (src/app/dynamic-renderer/widget-host/widget-host.service.ts, 77 lines) resolves each widget's component via WidgetManifestService (src/app/widgets/registry/widget-manifest.service.ts) and its data via DataSourceResolverService (src/app/widgets/resolvers/data-source-resolver.service.ts, 251 lines), which delegates to CategoryFacade/ProductFacade — widgets never call APIs directly, confirmed.
• Critical finding: this entire pipeline has real service files but zero components or templates — every one of page-renderer/, section-renderer/, widget-host/ also contains only a .gitkeep alongside its service/model files (confirmed by directory listing). The storefront homepage instead renders through a separate, older path (layouts/containers/dynamic-page-layout.component.ts) that does not consume this pipeline at all. Two Project Editor fields — Theme section's "Site Layout" (layout.type) and each homepage section's own type field — write into a schema this unused pipeline was meant to consume, and currently have no effect on the rendered storefront. This is the single most consequential hidden gap in the platform: a merchant can configure two settings that persist, validate cleanly, and look fully functional in the editor, but do nothing at render time. See Sections 4 and 6.

Theme engine (ADR-008)

ThemeConfig (src/app/shared/models/config/theme.model.ts): themeId, mode (light|dark|system), 12-color palette, typography, spacing, borderRadiusScale, shadows, iconSet. Palette colors are applied as real CSS custom properties and are genuinely live throughout the app. The mode field is not — see Section 4/6, theme-engine.service.ts sets a data-theme-mode attribute on <html> but no stylesheet anywhere reads it.

Feature flags (ADR-009)

bootstrap.featureFlags (typed) plus the broader bootstrap.features (MarketplaceFeaturesConfig). Resolution falls back across older config surfaces for backward compatibility as the flag model evolved across sprints.

Diagnostics (dev-only)

src/app/features/diagnostics/ (route /__diagnostics, excluded from production) validates bootstrap structure and runtime health, scored 0-100 — genuinely useful for investigating an editor-authored bootstrap, and the only place in the codebase that programmatically cross-checks the dynamic-renderer gap described above (it flags unknown widget types and missing datasources).

Provider-switching mechanism (detail carried into Section 5)

RuntimeProviderStrategyService (src/app/core/providers/runtime-provider-strategy.service.ts) is the intended single source of truth for mock-vs-API selection, exposing getBootstrapProviderMode(), getBackofficeProviderMode(), getProductProviderMode(), getCategoryProviderMode(), each returning 'mock' | 'api' | 'remote-config' based on environment.useMockData (and, for bootstrap only, an additional useMockBootstrapOnLocal + localhost check). 'remote-config' is declared but never actually returned or consumed anywhere — a dead enum value. Verified: environment.ts currently has useMockData: false, useMockBootstrapOnLocal: true, so in the checked-out state real API calls are the default everywhere except bootstrap-on-localhost.

Two more DI tokens exist that consult this strategy but whose 'mock' branch is dead code: PRODUCT_DATA_PROVIDER (src/app/core/products/product-data-provider.token.ts:12-19) and CATEGORY_REPOSITORY (src/app/core/categories/category-repository.token.ts:12-19) both have a switch over the mode where every case, including 'mock', returns the same Api* implementation — no mock ProductDataProvider/CategoryRepository class exists in the codebase at all. This is not a bug in the sense of breaking anything (mocking for products/categories instead happens one layer down, via mockDataInterceptor faking HTTP responses — see Section 5), but it does mean the provider-token pattern documented in docs/ARCHITECTURE.md as the swap mechanism is only genuinely wired for bootstrap and backoffice reads — for storefront product/category data and for every admin domain, "mock" happens by a different mechanism than the architecture doc implies.

Integrations placeholders

src/app/integrations/{auth,authorization,payment}/ contain only .gitkeep files — scaffolded but entirely unused. The real, working auth code lives in src/app/services/auth.service.ts and src/app/core/admin-auth/; real payment code lives inline in src/app/pages/cart/cart.component.ts (see Section 2). These three directories are dead scaffolding that should either be deleted or the real code relocated into them — currently they mislead a reader into thinking auth/payment integration code is organized there.

---

2. Marketplace (customer-facing)

Customer routes render under /​:lang/**. There is no dedicated Checkout page — src/app/features/website/checkout/ contains only a .gitkeep; checkout is folded entirely into CartComponent (664 lines, src/app/pages/cart/cart.component.ts, template 359 lines). There is no dedicated Profile/Account or Orders (customer-facing order history) page — no route, no component found under src/app/pages/** or src/app/features/website/** matching that purpose; a logged-in customer has no self-service order-history UI today (only the admin side has order management, and only for staff). There is no traditional email/password login/register form — the only auth surface is TelegramLoginComponent (src/app/components/telegram-login/telegram-login.component.ts), a QR-code Telegram session flow shared (with separate storage) between customer and admin. There is no dedicated 404 page (redirects home) and no maintenance page (confirmed above).

Home

• Files: src/app/pages/home/home.component.ts (42 lines) / .html (11 lines) — intentionally thin, delegates to DynamicPageLayoutComponent (layouts/containers/dynamic-page-layout.component.ts) which composes the widget/section tree from bootstrap.pages.home.
• Status: Ready, with a known open bug: docs/KNOWN-ISSUES.md item 1 — a hero-to-categories dead-space gap on the storefront homepage, traced to bootstrap mock config padding values, not a code defect. Not independently re-verified visually in this audit (no live browser run performed).
• Widgets rendered: hero, categories, product-carousel, recently-viewed, footer-navigation (src/app/widgets/ui/*) — each receives { section config, resolved data } only, per ADR-005.
• Missing backend: none directly — home composes already-covered product/category data.

Catalog / Search

• Files: CatalogContainerComponent (src/app/features/website/catalog/containers/catalog-container.component.ts, 950 lines — the single largest component in the entire src/app tree) serves both /catalog, /catalog/:id, and /search routes (app.routes.ts:16-22,43-45) — one container handling three distinct route paths and URL-param shapes.
• Status: Needs work. A 950-line container is a strong maintainability red flag on its own (nearly 2.5x the project's stated 400-line convention ceiling referenced elsewhere in docs/EDITOR.md); it composes filters-panel, product-grid, category-grid, sorting-control, layout-switcher, search-box, search-results, and catalog-empty-state (src/app/features/website/catalog/components/*) — a reasonable component breakdown one level down, but the container itself is a single point of complexity for three different page contracts (catalog listing, category filtering, free-text search).
• category/:id and category/:id/items both redirectTo: 'catalog/:id' (app.routes.ts:23-32) — legacy URL compatibility, working as intended, not dead code.
• Search facade: src/app/features/search/facade/search.facade.ts (592 lines) — second-largest facade in the codebase; handles suggestions, history (via LocalSearchHistoryRepository, localStorage-backed), and a BackendSearchHistoryRepository whose every method is a stubbed no-op placeholder (confirmed by the architecture research pass; "Placeholder for future backend endpoint").
• Missing backend: storefront product/category reads go through PRODUCT_DATA_PROVIDER/CATEGORY_REPOSITORY, which — per Section 1 — always resolve to the real ApiProductDataProvider/ApiCategoryRepository (real HttpClient calls); "mock mode" for these is achieved instead by mockDataInterceptor (src/app/interceptors/mock-data.interceptor.ts, 923 lines of hand-authored mock category/product JSON) intercepting the HTTP call before it reaches the network.

Product detail

• Files: ProductDetailsContainerComponent (src/app/features/website/product/containers/product-details-container.component.ts, 683 lines) plus a well-decomposed set of presentational children (product-gallery, product-information, product-actions, product-description, product-specifications, product-warranty, variant-selector, related-products, delivery-information) and an engagement/ subtree for reviews/questions (review-list, review-form, review-card, question-list, question-form, question-card, rating-summary, star-selector, stars).
• A legacy duplicate exists: src/app/pages/item-detail/item-detail.component.ts (368 lines, template 356 lines) — appears to predate the features/website/product rebuild. app.routes.ts routes /product/:id to ProductDetailsContainerComponent (line 34-36) and redirects /item/:id → /product/:id (line 38-41), so ItemDetailComponent is not reachable via any route — likely-unused, not exhaustively verified (no other route or component reference to it was found in this pass, but a full cross-repo import search was not run for this specific file).
• Status: Ready for the primary container; reviews/Q&A engagement components are functionally present and wired to ApiService (submitReview, submitQuestion).
• XSS surface: item-detail.component.html:208 renders [innerHTML]="getSafeHtml(item()!.description)" via DomSanitizer.bypassSecurityTrustHtml — since this component is unrouted this is currently inert, but if ever re-routed it inherits whatever sanitization getSafeHtml() performs (not independently verified for correctness).

Cart / Checkout (merged)

• Files: src/app/pages/cart/cart.component.ts (664 lines) / .html (359 lines).
• Status: Ready but does double duty as checkout — no separate checkout step/route exists. Payment is embedded directly: bankPaymentFrameUrl = this.sanitizer.bypassSecurityTrustResourceUrl(bankUrl) (cart.component.ts:371) renders a bank-hosted payment iframe inline in the cart page — a real, working integration (ApiService.createCartPayment/checkCartPaymentStatus), not a placeholder, but architecturally unusual to have zero dedicated checkout flow (shipping address, order review, confirmation) separate from the cart itself.
• Missing backend: none — cart/payment is one of the few genuinely backend-wired storefront flows (ApiService, real HttpClient, per Section 5).

Wishlist / Compare

• Files: WishlistPageComponent (src/app/features/website/user-experience/wishlist/containers/wishlist-page.component.ts), ComparePageComponent (.../compare/containers/compare-page.component.ts) plus compare-table.component.ts.
• Status: Ready, but entirely local-only — USER_EXPERIENCE_REPOSITORY unconditionally binds LocalUserExperienceRepository (pure localStorage), with no API alternative and no provider-switching at all (per the architecture research pass). Wishlist/compare state does not sync across devices or survive a cleared browser.
• Gated by a documented double-flag bug (fixed per docs/KNOWN-ISSUES.md/docs/EDITOR.md): visibility used to be driven by only one of two runtime flags (featureFlags.<key> and userExperience.<key>.enabled); the Project Editor's Features section now toggles both together.

Static Pages (customer-rendered)

• Files: StaticPageComponent (src/app/pages/static-page/static-page.component.ts) resolves bootstrap.staticPages dynamically for both page/:key and the catch-all :staticPath route.
• Status: Ready, sanitizes rendered HTML via DomSanitizer.bypassSecurityTrustHtml after passing through a sanitized step (static-page.component.ts:103 — the sanitization call itself was not traced to its implementation in this pass; flagged for Section 11).
• Dead parallel system: src/app/pages/info/** (about/contacts/delivery/faq/guarantee, each with en//ru//hy/ sub-variants) and src/app/pages/legal/** (company-details/payment-terms/privacy-policy/public-offer/return-policy, same per-locale structure) are ~40 files of hardcoded, per-locale-duplicated legal/info content that predates the dynamic Static Pages builder and are confirmed unrouted (cmsContentRoutes = [], app.routes.ts:289). public-offer-{en,ru,hy}.component.html alone are 529 lines each (1,587 lines of duplicated legal boilerplate across 3 files for one page). This is the single largest concentrated block of dead code in the repository — see Section 6.

Authentication

• Files: TelegramLoginComponent (src/app/components/telegram-login/), AuthService (src/app/services/auth.service.ts).
• Status: Ready as a QR-login flow, but is the only login method — no password/email fallback exists for customers without Telegram.

404 / Maintenance

• Status: Missing. No dedicated 404 component (silently redirects home); no maintenance-mode component or route exists at all. Both are real gaps for a production e-commerce platform (a merchant cannot show a "we'll be back" page during a deploy/migration, and a broken link gives no feedback).

Cross-cutting UX/accessibility/performance for Marketplace

• <img> lazy-loading: only 17 of 35 template <img> occurrences across src/app use loading="lazy" or Angular's ngSrc (NgOptimizedImage) — roughly half. Not broken down per-page in this pass; a per-page audit would need to check product-gallery, product-card, category-grid, and widget templates individually (not exhaustively done here).
• Change detection: OnPush is used almost universally (188/189 components) including in the marketplace surface — a genuine performance strength (Section 10).
• Accessibility: per docs/ADMIN.md's Sprint 28 note, every <img> in src/app/** was checked for a missing alt attribute and none were found — this claim covers the whole app including marketplace pages and was not re-run independently in this pass, but the methodology described (grep for <img without alt/[alt]/[attr.alt]) is sound and reproducible.

---

3. Admin (backoffice)

All admin routes live under /​:lang/backoffice/**, guarded by adminAuthGuard (src/app/core/admin-auth/admin-auth.guard.ts — 15 lines, straightforward isAuthenticated() check, requestLogin() on failure). Admin auth is fully isolated from customer auth: separate cookie name (adminSessionID vs the customer session cookie), separate localStorage keys (adminToken/adminRefreshToken), separate service class (AdminAuthService vs AuthService), separate signals — confirmed by reading both files in full. Backend gap, confirmed real and unresolved: both admin and customer login hit the identical Telegram session endpoint (TelegramSessionApiService, {authApiUrl}/users/sessions) — there is no server-side concept of "this session is an admin session," so authorization is enforced nowhere but the frontend guard today. This is flagged repeatedly and consistently across docs/ADMIN.md, docs/EDITOR.md, and docs/backend/BACKEND-INTEGRATION.md — a genuine, still-open security gap (see Section 11).

Every admin domain follows the same container/facade/local-gateway split (features/admin/<domain>/{models,services,facade,pages,components}), and — per the architecture research pass — every one of the 8 admin gateway implementations is local/in-memory, none use HttpClient:

Domain	Gateway	Data reality
Dashboard	admin-dashboard-metrics.local.gateway.ts	Derived counts from BackofficeDataService (itself mock/API-switchable)
Products	admin-products-local.gateway.ts (197 lines)	Seeded from BackofficeDataService.loadProducts(); all writes in-memory only
Categories	admin-categories-local.gateway.ts (120 lines)	Seeded from BackofficeDataService.loadCategories(); all writes in-memory only
Orders	admin-orders-local.gateway.ts	24 fully synthetic orders, no backend derivation at all
Transactions	admin-transactions-local.gateway.ts (91 lines)	Derived from the 24 synthetic orders (mock-on-mock)
Users/roles	admin-users-local.gateway.ts	Hardcoded 4-user roster, fabricated
Moderation	admin-moderation-local.gateway.ts (189 lines)	32 synthetic reviews + 10 reports from canned arrays + real product names
Monitoring	admin-monitoring-local.gateway.ts (82 lines)	40 fully fabricated events, hardcoded queues/webhooks

Analytics has no dedicated gateway file — it aggregates real arithmetic (revenue/orders/AOV/sales-over-time) over the mock Orders/Products/Categories data (confirmed in docs/ADMIN.md Sprint 27, plausible given Orders/Products data shapes, not independently re-derived in this pass). Visitors/funnels/heatmaps render an explicit pending-backend badge rather than fabricated numbers.

Dashboard

• File: admin-dashboard-page.component.* + AdminDashboardFacade (201 lines).
• Implemented ~90%. Cards render one of loading/empty/error/pending-backend/ready states — a genuinely well-designed state model (AdminDashboardCardComponent), and Orders/Revenue cards correctly show pending-backend rather than fake zeros, since no order/revenue data model existed at the time (now partially superseded by Sprint 23's Orders gateway, but the dashboard cards' own honesty pattern is worth noting as a good practice other sections don't all follow as visibly).
• System Health reuses ProjectValidator (6 real checks: bootstrap valid, configuration valid, missing translations, invalid colors, invalid widget references, invalid layouts) — genuinely computed, not fabricated.
• Recent Activity is localStorage-only per tenant (AdminDashboardHistoryService) — will not show another admin's activity until a real audit-log endpoint exists.
• Known bug class: none open specific to dashboard beyond the general admin i18n/backend gaps.

Products

• Files: admin-products.facade.ts (316 lines), admin-product-form.component.ts (243 lines / .html 291 lines), product-variants-editor.component.ts (169 lines).
• Implemented ~85%. Archive/restore (soft delete distinct from visible), barcode, lightweight variants (name|price|quantity parsed from delimited text, not a full options-matrix), related-products checkbox picker (scoped to whatever page is currently loaded in the facade — not a full catalog search, explicitly documented trade-off), gallery via shared MediaPickerComponent, infinite-scroll toggle.
• Recent commits (3b955b1 feat(admin): Shopify-style variant attributes matching production data shape, afaf79d feat(admin): visual badge manager, 31c64e9 feat(admin): collapse product translations behind default-language fields, b16e300 feat(admin): product editor auto-slug, SKU helper, one-click SEO fill) indicate active, recent UX investment beyond what docs/ADMIN.md's Sprint log describes — these post-date the doc and were not individually re-verified line-by-line in this pass beyond confirming the files exist and are wired into the routed component tree.
• No canDeactivate dirty guard on the product editor route (confirmed absence in app.routes.ts:88-105) despite categories having one — an inconsistency (see Section 1).
• Known bugs (fixed, historical): none open for products specifically per docs/KNOWN-ISSUES.md.

Categories

• Files: admin-categories.facade.ts (514 lines — largest admin facade), admin-categories-list.component.ts (174 lines).
• Implemented ~90%. Hierarchy via parentId with flattened indented-tree rendering; native HTML5 drag-and-drop reorder (not CDK, unlike the Project Editor's footer/homepage builders — an inconsistency in DnD implementation choice across the codebase); soft delete blocked client-side if the category has children or itemsCount > 0; draft/publish workflow with localStorage autosave recovery; canDeactivate dirty guard present.
• Two real bugs found and fixed during a documented 2026-07-17 bug-hunt (docs/ADMIN.md "Bug-hunt audit pass"), both verified plausible from the current code structure: (1) create-mode draft recovery was permanently dead because the draft key was derived from Date.now() on every call, orphaning localStorage entries forever — fixed with a stable admin-category-draft:new key; (2) drag-and-drop reorder wrote the dropped-on row's order value directly onto the dragged item instead of computing a full resequence, so on fresh seed data (every category starting at order: 0) every drag silently no-op'd — fixed by reordering via target id and resequencing all affected siblings. Both fixes were not re-derived from scratch in this pass but the described defect mechanics are consistent with drag-and-drop-by-order-value being a known anti-pattern.

Orders

• Files: admin-orders.facade.ts (213 lines).
• Implemented ~75% relative to a real order system, ~95% relative to its explicitly-scoped mock ambition. List (search/status filter/pagination/CSV export), detail (customer/payment/shipping, itemized total, status timeline, change-status, refund-request + cancel both window.confirm-gated, dual customer/internal notes, print-invoice via window.print()). No real backend or data model for orders exists anywhere in the repository — this is explicitly and repeatedly documented, not a hidden gap.

Customers

• Files: src/app/features/admin/customers/ (facade, models, pages) — routed at /backoffice/customers and /backoffice/customers/:email.
• Not covered in depth by docs/ADMIN.md's sprint log (the doc's sprint numbering jumps from Products/Categories to Media/Orders/Transactions/Users/Monitoring/Analytics without a distinct "Customers" sprint entry) — implementation depth not independently verified in this pass beyond confirming the routed pages exist and follow the same facade/gateway convention as every other admin domain. Flagged as "not exhaustively verified."

Transactions

• Files: admin-transactions-local.gateway.ts (91 lines), facade and list/detail pages.
• Implemented ~85% for its scope: search/status/type filters, CSV export, retry-failed-transaction flow, fraud-flag toggle, per-transaction audit-log dialog. Explicitly derived from the same 24 synthetic orders as the Orders domain (kept consistent by design, not by accident).

Media (Media Library)

• Files: src/app/features/backoffice/media/media-library-page.component.ts, src/app/core/media/mock-media-repository.service.ts (277 lines), src/app/shared/media/media-picker/.
• Implemented ~90% of its own scope. Real, working: 10MB size + MIME allow-list validation with surfaced error messages, SVG <script>/on* attribute stripping before storage, raster image downscale-to-2000px + re-encode via <canvas> before storage, flat folder tagging (no true hierarchy), tag editing via window.prompt.
• Storage is IndexedDB in the browser, not a real backend — MediaRepository is hardwired to MockMediaRepository in app.config.ts:29 with no API implementation and no provider-switching at all (unlike bootstrap/backoffice, this one isn't even token-gated). Uploaded media does not exist anywhere except the uploading admin's own browser.

Moderation (Reviews & Reports)

• Files: admin-moderation.facade.ts (218 lines), admin-moderation-local.gateway.ts (189 lines), pages: admin-reviews-list-page.component.ts, admin-review-detail-page.component.ts, admin-reports-list-page.component.ts.
• This is the "Reviews" area named in the audit brief — the codebase calls it "Moderation," routed at /backoffice/moderation and /backoffice/moderation/reports. Implemented ~80% of its scope: 32 synthetic reviews + 10 reports, category filter + search. No real backend — reviews submitted by real customers via ApiService.submitReview() on the storefront do not appear to flow into this admin moderation queue in any code path found in this pass (not exhaustively verified — would require tracing whether BackofficeDataService/moderation gateway ever reads real submitted-review data; the seed data is explicitly described as "canned author/snippet arrays," which suggests it does not).

Monitoring

• Files: admin-monitoring-local.gateway.ts (82 lines), admin-monitoring-page.component.ts.
• Implemented ~70% of its scope, and honest about it: one real section (Health, reusing the Dashboard's genuine ProjectValidator checks) alongside three fully fabricated sections (unified audit/security/API/error event feed — 40 synthetic entries; queue monitoring — 3 mock named queues; webhook delivery log — mock). No logging backend exists anywhere in the system, so there is nothing real to read from for the fabricated sections — a structural gap, not an oversight.

Analytics

• Files: admin-analytics.facade.ts (338 lines), admin-analytics-page.component.html (246 lines).
• Implemented ~65%. Revenue/orders/AOV/sales-over-time/top-products are real aggregation arithmetic over the mock Orders/Products/Categories data (not fabricated numbers, but ultimately traceable to fabricated source data). Visitors/funnels/heatmaps correctly show pending-backend since no analytics/tracking pipeline exists anywhere. Chart is a plain <div>-bar chart via [style.height.%], no charting library — adequate for one series, would need revisiting for more chart types.

Users & Roles

• Files: admin-users-local.gateway.ts.
• Implemented ~70%. 4 built-in roles with a flat permission-string list (not a real permission catalog, no custom-role creation — intentionally scoped down). Invitations create a local record only; no email actually sends. Session/device manager is mocked (2 fabricated sessions per user on first view) since the real auth flow only ever tracks the current browser's session — there is no multi-device session backend.

Reports / Settings / Diagnostics

• Reports: folded into Moderation (/backoffice/moderation/reports) — there is no separate "Reports" admin area distinct from the reports-queue-of-flagged-content concept; if "Reports" in the brief means business reporting, that function is covered (partially) by Analytics instead. Flagging this naming mismatch explicitly rather than guessing which the brief intended.
• Settings: there is no single "Admin Settings" page — tenant-level settings (branding, theme, domain, etc.) live in the Marketplace Builder / Project Editor (/edit/*), not in /backoffice/*. This is a genuine UX seam: an admin user looking for "Settings" inside the admin shell (AdminLayoutComponent) will not find it there; it's a separate top-level area (/edit) with its own navigation, reachable only via a Quick Action link or by typing the URL.
• Diagnostics: src/app/features/diagnostics/ (route /__diagnostics) is dev-only and correctly excluded from production builds (app.routes.ts:293-296) and from crawling (public/robots.txt blocks it per Sprint 28). Not part of the admin shell/nav at all — a developer tool, not an admin-facing feature, correctly scoped.

Admin-wide notes

• Design consistency: as of Sprint 28 (docs/ADMIN.md), all 8 built admin sections share app-skeleton (loading) and app-empty-state (empty) primitives — verified as a real, systematic pass rather than piecemeal, since the doc names each section's prior gap explicitly (which sections had a loading signal but no UI, vs. which had empty-state but no skeleton).
• i18n: the ~178 raw untranslated adminXxx.* keys documented as an open issue in docs/KNOWN-ISSUES.md are fixed — confirmed by grepping src/app/i18n/{en,ru,hy,translations}.ts for an adminProducts: object, present in all three locale files plus the Translations interface. This is a stale doc claim that no longer reproduces; docs/KNOWN-ISSUES.md should be updated (not done here — read-only audit).
• Bundle: the initial-bundle budget warning (~198kB over the 700kB angular.json budget, see Section 10) predates all admin work and is unaffected by it since every admin page is lazy-loaded.

---

4. Marketplace Builder

Important correction to the audit brief's assumed file layout: src/app/features/builder/{feature-flag-editor,navigation-editor,page-editor,seo-editor,theme-editor}/ — the five sub-folders matching the brief's list — contain only .gitkeep files each. That is stale/unused scaffolding, not the real builder. The actual, fully-built Marketplace Builder lives at src/app/features/project-editor/ (11 section components under sections/, one facade, a schema/validator layer under schema/) plus src/app/features/content-management/ for Static Pages specifically. All findings below are against the real, routed implementation (/edit/:section).

Mechanism notes (apply to every section)

• Drag-and-drop: @angular/cdk/drag-drop (CdkDragDrop, moveItemInArray), used for homepage section reordering and footer column/link reordering. Navigation link reordering and Static Pages list reordering are up/down buttons, not drag-and-drop — Static Pages' choice is an explicit, documented lower-complexity scope call; Navigation's is not explained anywhere, an inconsistency worth flagging (why does Homepage/Footer get CDK drag-drop but Navigation doesn't, when both are ordered lists of similar complexity).
• Live preview is not an iframe/postMessage sandbox. ProjectEditorPreviewService.preview() calls PlatformRuntimeService.reloadFromBootstrap() — the same mechanism Publish uses — then navigates the current tab to /{lang}. Preview and Publish are functionally the same client-side reload; there is no separate sandboxed preview surface. A merchant could reasonably believe "Preview" is non-destructive when it mutates live runtime state identically to Publish (it just doesn't flip status to published or write the "last published" marker).
• No backend persistence for any of it. ApiBootstrapProvider implements only GET /bootstrap — there is no PUT/POST anywhere in the provider layer. save() and publish() both write only to localStorage (projectEditor.draftBootstrap.v1, tenant-scoped) and then trigger the same in-app reload. Every "save" in the entire Builder only persists to the browser; clearing site data loses all edits.

General

general-section.component.ts (74 lines). Name/domain (auto-derives https:// prefix silently, with no visible feedback of the derived URL)/description — all wired. Language management was recently de-duplicated (commit 440d2ec): previously a second, independent comma-separated text field existed here alongside the real Languages section; now it's a read-only chip summary linking to Languages — a genuine, verified UX fix eliminating a two-sources-of-truth bug.

Branding

branding-section.component.ts (69 lines). Logo/compact-logo/favicon/social(OG)-image/gallery, all via app-image-field (thumbnail preview + replace/remove, opens app-media-picker). A real fixed bug: branding.socialImageUrl used to be saved but never actually read by SeoService.resetToDefaults() — now fixed. Missing explanations: no guidance on recommended logo dimensions/aspect ratio or favicon format constraints anywhere in the template.

Theme

theme-section.component.ts (91 lines). Palette (8 colors via app-color-picker) is genuinely live, applied as real CSS custom properties. Two confirmed-dead controls sit in the same section as the fully-working palette, which is a real trust problem for a merchant since nothing in the UI distinguishes a live control from a decorative one:

1. Theme Mode (light/dark/system) saves and sets data-theme-mode on <html> but no stylesheet anywhere reads that attribute — picking Dark or System changes nothing visually.
2. Site Layout (layout.type) feeds the unwired dynamic-renderer pipeline described in Section 1 — has no effect on the rendered storefront.

Header

header-section.component.ts (72 lines). 9 toggles + layout select + sticky, all live-wired except showProfile, a real toggle with no corresponding profile/account menu anywhere in header.component.html — flips a flag nothing reads (blocked on an auth-system dependency that doesn't exist for account menus today).

Footer

footer-section.component.ts (198 lines) — recently rebuilt (commit 726df0c feat(builder): visual footer builder with drag-and-drop columns). CDK drag-and-drop columns and links; per-link source toggle between a static-page reference (resolved by stable page id, survives route renames) or a custom URL; payment icons and social links via app-key-value-editor; multiple phones/emails. FooterResolverService was updated in the same pass to read footer.columns as primary source with fallback to legacy auto-grouping — this is genuinely wired end-to-end to the live storefront footer, not builder-only cosmetics. Two id-collision bugs (social-link ids derived from array length, payment-icon ids from src) that corrupted @for (track item.id) DOM identity on the live storefront footer were found and fixed in the same pass.

Homepage

homepage-section.component.ts (167 lines) — recently rebuilt (commit 71d5f4d feat(builder): visual homepage blocks, merchant-language widget settings, real carousel arrows). Merchant-facing block catalog (icon+name+description replacing raw section.id strings like section-hero); add-block picker across 8 block types; duplicate/remove per block; CDK drag-to-reorder. A companion homepage-overview.component.ts (67 lines) computes a completion-ring UI purely from real widget presence data (hero/categories/products/promotion/newsletter/any-sections) — not fabricated. Dead code retained: updateSection(sectionId, 'type', ...) still exists in the component with no UI calling it, because the field it writes feeds the unwired dynamic-renderer pipeline.

Widgets

widgets-section.component.ts (215 lines). Typed editors for hero (title/subtitle/slide array) and toggle/reorder/duplicate/remove for all widgets; JSON-fallback textarea for anything without a dedicated editor. A real, non-obvious fix: the JSON fallback used to silently discard an in-progress invalid edit (parse error caught, then overwritten by the last-committed value on the next change-detection tick); now keeps the user's draft on screen with an inline error until valid. Hero widget's slide array drives a real rotator with dots, click-to-jump, and a 5-second autoplay interval — verified in hero-widget.component.ts, not a cosmetic stub.

Static Pages

static-pages-editor.component.ts (404 lines, right at the project's 400-line convention ceiling — flagged as a split candidate, bulk-actions and validation-badge logic are natural extraction points), content-page.service.ts (285 lines). Full CRUD, multi-field search, status/locale filters, bulk actions (delete/enable/disable/publish/unpublish), duplicate, per-locale device preview, SEO fields with validation-driven badges. Two slug/route id-collision bugs (create-delete-create, duplicate-the-same-page-twice) were found and fixed with a shared uniqueValue() helper, confirmed used consistently in both createPage() and duplicatePage().

• persist() footgun: every mutation must operate on the full unfiltered page list, never the search/filter-narrowed view (writing from a filtered view would silently delete whatever the filter was hiding) — correctly followed everywhere checked, but is an unenforced convention (no type system or lint rule prevents a future contributor from getting this wrong), a real maintainability risk.
• Rich-text editor (MarketplaceHtmlEditorComponent) is built on the deprecated document.execCommand API — works in all current browsers, no modern drop-in replacement exists; a real, acknowledged rewrite risk if browsers ever drop the API. Emits raw unsanitized HTML by design (sanitization is a render-time concern via DomSanitizer, not an authoring-time one) — recently redesigned toolbar (commit 9eacd00) grouped by intent with PrimeIcons/tooltips/aria-labels.
• Confusing: the enabled/status gating story (a page can be individually unpublished independent of the whole-bootstrap publish state) is correctly documented in docs/StaticPages.md but not surfaced as an explicit inline warning anywhere in the editor UI itself — a merchant could publish the whole config and be confused why one page still isn't live.

Navigation

navigation-section.component.ts (129 lines). Header nav add/remove/reorder(up-down)/per-locale label/URL/visibility; "Insert page link" creates a stable type: 'staticPage' nav item. Confusing: flat footer nav is editable here, but grouped (column-based) footer nav is read-only in this tab — must switch to the Footer tab to edit it, with no cross-link between the two in the template.

Languages

languages-section.component.ts (69 lines). Add/remove/set-default correctly routes through LocaleSyncService, which seeds empty translation entries across static pages, header nav, footer nav (both shapes), and sidebar nav — verified thorough by reading the full sync implementation. Cannot remove the current default locale — enforced at the service layer, not just UI-disabled (real defense in depth). A silent-no-op bug (adding an already-supported locale cleared the input with no feedback) is fixed with an inline error. Recently de-duplicated against General (commit 440d2ec) — single source of truth now.

Features

features-section.component.ts (97 lines). Catalog navigation mode select, general flags, wishlist/compare/recently-viewed/search-suggestions-history/reviews/questions toggles. The double-flag wishlist/compare bug (Section 1/6) is fixed here — one toggle now correctly drives both featureFlags.<key> and userExperience.<key>.enabled.

Preview

preview-section.component.ts (37 lines). Export/import JSON, a "changes since last publish" card (validation issues + before/after diff table). A real fixed bug: import used to bypass updateBootstrap() entirely, so an imported config never reached localStorage draft storage (lost on refresh before an explicit Save) and wasn't undo-able — now routed through the standard update pipeline.

Cross-cutting Builder findings

• project-editor.facade.ts is 686 lines — by far the largest file in the entire builder, owning bootstrap state, a debounced (~300ms) undo/redo history capped at 50 entries, draft storage, validation aggregation, section-readiness computation, and navigation-link mutation. It works today (traced in full by the architecture pass) but is the single highest-blast-radius file in the Builder — a change here risks every section simultaneously.
• Field-schema/validator layer (schema/) is metadata-augmented, not schema-driven — section templates stay hand-authored, a schema registry sits alongside for labels/validators. ProjectValidator covers ~17 distinct checks (duplicate slugs/routes, invalid colors/CSS/URLs/emails, missing translations, malformed widget config, etc.), gates Publish only on error-severity issues, not warnings — a sound, deliberate design.
• Undo/redo is a real, pure reducer (schema/history.util.ts) wired with keyboard shortcuts (skipped while a text field has focus so native per-field undo still works) — genuinely implemented, not stubbed.
• items-carousel (PrimeNG p-carousel, src/app/components/items-carousel/) is confirmed dead code — not wired into any route or widget; commit 71d5f4d's own investigation (per the builder research pass) found the real carousel functionality landed in ProductCarouselWidgetComponent instead. This is a shared/top-level component directory (src/app/components/), so its unused status is a genuine cleanup candidate, not feature-folder clutter.

---

5. Backend readiness

Provider-switching mechanism

RuntimeProviderStrategyService (src/app/core/providers/runtime-provider-strategy.service.ts) reads environment.useMockData (and, for bootstrap only, useMockBootstrapOnLocal + a localhost check) and returns 'mock' | 'api' | 'remote-config'. This feeds InjectionToken factories that pick between a Mock/Api pair — but as established in Section 1, this mechanism is only genuinely two-sided for Bootstrap and Backoffice reads. For Products/Categories the "mock" branch is dead code (always resolves to the real API class); mocking there happens instead via mockDataInterceptor (923 lines) faking HTTP responses at the interceptor layer — a second, parallel mocking mechanism that a reader of docs/ARCHITECTURE.md alone would not know exists.

Current state, by domain (see Section 3's table for the admin-domain detail)

Domain	Status	Evidence
Bootstrap config	Real HTTP + working mock, switchable	ApiBootstrapProvider → GET /bootstrap; MockBootstrapProvider → GET /assets/mock/bootstrap/bootstrap.json (still an HTTP call, to a local JSON asset)
Backoffice products/categories (read)	Real HTTP + working mock, switchable	ApiBackofficeDataProvider → GET /api/backoffice/{products,categories}; MockBackofficeDataProvider → local JSON assets
Storefront products/categories	Real HTTP only (mock branch dead code; interceptor-level mocking exists separately)	ApiProductDataProvider, ApiCategoryRepository, both real HttpClient with retry+backoff
Cart/reviews/questions/payment/search	Real HTTP, no mock provider variant at all	ApiService (674 lines) — every method issues real HttpClient calls; extensive DTO normalization for backend-format drift (legacy vs "backOffice" shapes)
Wishlist/compare/recently-viewed/saved-searches	Local-only, no API path exists, no switching	LocalUserExperienceRepository, pure localStorage
Search history	Local-only; a BackendSearchHistoryRepository class exists but every method is a stubbed no-op	Not confirmed bound anywhere via DI
Media library	Local-only (IndexedDB), no API class exists, hardwired in app.config.ts, not token-switched	MockMediaRepository
Admin: Products/Categories	Local/in-memory, seeded from Backoffice data (itself switchable) but writes never persist past reload	admin-{products,categories}-local.gateway.ts
Admin: Orders/Transactions	Fully synthetic, no backend model exists anywhere	admin-orders-local.gateway.ts (24 seeded orders), admin-transactions-local.gateway.ts (derived)
Admin: Users/roles	Fully fabricated, hardcoded 4-user roster	admin-users-local.gateway.ts
Admin: Moderation/Monitoring	Fully fabricated (Moderation partially uses real product names)	admin-moderation-local.gateway.ts, admin-monitoring-local.gateway.ts
Admin: Analytics	Real arithmetic over fabricated source data; visitors/funnels/heatmaps explicitly pending-backend	No dedicated gateway file found
Admin: Dashboard metrics	Derived from Backoffice data, honest pending-backend state for Orders/Revenue cards	admin-dashboard-metrics.local.gateway.ts

What changes when backend integration happens

Per the pattern already used for bootstrap/backoffice (and independently documented, matching the code, in docs/backend/BACKEND-INTEGRATION.md §14): implement a new *ApiGateway/*ApiRepository class against the same interface each facade already depends on, then rebind the DI token (or, for the several admin domains that inject the concrete *LocalGateway class directly rather than through an InjectionToken — confirmed no admin-{orders,transactions,users,moderation,monitoring}-gateway.token.ts files exist — introduce a token first, or swap the binding in each facade's constructor/inject() call). No facade or component changes are required for domains that already sit behind an interface — this is the real, verified architectural payoff of the container/facade/gateway split, and it is consistently followed across all 8 admin domains plus the storefront.

Estimated remaining work

Roughly 9 of the ~11 backoffice/admin domains are 100% frontend-mocked with zero backend contract implemented (Orders, Transactions, Users/roles/invitations/sessions, Moderation, Monitoring, Analytics-beyond-arithmetic, Media, Wishlist/Compare-if-cross-device-sync-is-required). Each needs: (1) a real REST/GraphQL endpoint built server-side, (2) a new *ApiGateway class client-side, (3) a token rebind or facade constructor change. The storefront (product browsing, cart, auth, payment) is the only surface with a genuinely live backend contract today — and even there, whether the configured tenant base URL (environment.ts) is a reachable backend in any given deployment was not verified in this pass (no network calls were made). Not independently estimated in person-days/weeks — that would require backend-team input on endpoint complexity, which is out of scope for a frontend-only audit.

---

6. Technical debt

Dead code (verified via route/import cross-check, not just filename inspection)

• src/app/pages/info/** and src/app/pages/legal/** (~40 files: about/contacts/delivery/faq/guarantee × {default, en, ru, hy} + company-details/payment-terms/privacy-policy/public-offer/return-policy × {default, en, ru, hy}) — confirmed unrouted, app.routes.ts:289 (cmsContentRoutes: Routes = []) with an explicit TODO(CMS) comment naming every one of these pages as disabled. public-offer-{en,ru,hy}.component.html are 529 lines each; privacy-policy-* are 367 lines each. This is the largest concentrated dead-code block in the repository by line count.
• src/app/features/builder/{feature-flag-editor,navigation-editor,page-editor,seo-editor,theme-editor}/ — every folder contains only a .gitkeep. Stale scaffolding for a builder structure that was superseded by features/project-editor/.
• src/app/integrations/{auth,authorization,payment}/ — .gitkeep only, unused scaffolding; real code lives elsewhere (Section 1).
• src/app/dynamic-renderer/{page-renderer,section-renderer,widget-host}/ — real service/model files exist, but zero components/templates; the pipeline is unconsumed by the actual storefront render path (Section 1). Not literally empty like the above, but functionally dead — a decision is needed to finish wiring it or delete it.
• src/app/pages/item-detail/item-detail.component.ts (368 lines) — likely superseded by ProductDetailsContainerComponent; /item/:id redirects to /product/:id (app.routes.ts:38-41), so this component has no route pointing to it. Likely-unused, not exhaustively verified (a full workspace-wide import search for ItemDetailComponent was not run).
• src/app/components/items-carousel/ (PrimeNG p-carousel wrapper) — confirmed unused per the builder-pass investigation; superseded by ProductCarouselWidgetComponent.
• BackendSearchHistoryRepository (features/search/services/search-history.repository.ts) — every method is a no-op placeholder; not confirmed bound to any DI token, i.e. possibly entirely unreachable code today (not exhaustively verified — a full DI-graph trace was not performed).

TODO/FIXME/HACK markers

grep -rE "TODO|FIXME|HACK" --include="*.ts" src/app returns essentially none outside the single TODO(CMS) comment in app.routes.ts:286 — consistent with docs/SPRINT-PLAN.md's Sprint 29 note that a dead-code/TODO grep across features/admin/** came back clean. This is a genuinely low-TODO codebase relative to its size, which is a positive signal (either debt is tracked elsewhere — docs/KNOWN-ISSUES.md — rather than left as inline comments, or it's genuinely been kept clean).

console.log/console.debug

Zero occurrences found (grep -rE "console\.(log|debug)" --include="*.ts" src/app → 0). Clean.

@deprecated

One file found using the marker (not individually inspected in this pass — flagged as a location to check, not a confirmed live deprecation).

Type-safety smell (: any / as any)

58 occurrences across src/app (grep, not deduplicated by uniqueness) — a moderate count for a codebase this size (~36k lines of .ts under src/app, per wc -l). One confirmed instance directly relevant to architecture: runtime-provider-strategy.service.ts casts (environment as any).useMockBootstrapOnLocal rather than typing it properly on the Environment interface — a small but real type-safety gap in a file that controls production-vs-mock data routing. Not exhaustively catalogued — 58 is the raw count, not individually triaged for severity.

Inconsistent patterns (architecture-level debt, not simple bugs)

• Two facades in the same directory use two different reactive idioms (ProductFacade constructor-DI + pass-through vs. CategoryFacade inject() + parallel signals/observables) — Section 1.
• Two different drag-and-drop implementations coexist: CDK drag-drop in the Project Editor (Homepage, Footer) vs. native HTML5 DnD in Admin Categories — no documented reason for the split.
• Two different "mock data" mechanisms coexist: DI-token provider-switching (Bootstrap, Backoffice) vs. HTTP-interceptor response-faking (mockDataInterceptor, Products/Categories storefront reads) — a reader of the architecture doc alone would not discover the second mechanism exists.
• Inconsistent canDeactivate dirty-guard coverage: Categories and the Project Editor have one; Products does not, despite having equivalent draft-tracking logic in its facade.
• RuntimeProviderMode.'remote-config' is declared in a type union and referenced in switch statements but never actually returned by any strategy method — dead enum value across at least 4 files.

Duplicate/near-duplicate code

• The src/app/pages/info/** / src/app/pages/legal/** legal-page components are internally triplicated by design (one component per locale, e.g. about-en/about-ru/about-hy) rather than one component with locale-driven content — even before accounting for the fact the whole tree is unrouted, this per-locale-component pattern (rather than a single component reading translated content) is a duplication anti-pattern relative to how the rest of the app handles i18n (TranslateService/TranslatePipe).
• Sprint 24's Transactions gateway and Sprint 23's Orders gateway are intentionally coupled (transactions derive from orders) — this is documented, deliberate coupling, not accidental duplication.

Legacy/deprecated coexistence

No @NgModule-based code exists anywhere alongside the standalone-component codebase (0 hits) — the codebase does not have the "old pattern next to new pattern" debt common in mid-migration Angular projects. This is a genuine strength.

---

7. UI/UX audit

Scope note: this section scores what Sections 2–4 already described in detail; it does not re-derive new findings, only assigns comparative judgments across pages/areas already audited. No redesign proposed, per the audit brief.

Area	Design	Usability	Accessibility	Consistency	Visual hierarchy	Notes
Home	Good	Good	Not independently verified	Good	Good	Thin container delegating to widget system; known dead-space bug (Section 2)
Catalog/Search	Fair	Fair	Not independently verified	Good (shares filter/grid primitives)	Fair	950-line container is a maintainability risk more than a UX one, but three distinct page contracts in one container increases regression risk for any of the three
Product detail	Good	Good	Not independently verified	Good	Good	Well-decomposed presentational children; legacy ItemDetailComponent unrouted (no user-facing impact)
Cart/Checkout	Fair	Fair	Not independently verified	Good	Fair	No distinct checkout step is a genuine UX gap for anything beyond a single-item impulse buy — no order review/confirmation screen before payment
Wishlist/Compare	Good	Good	Not independently verified	Good	Good	Solid feature, undermined by no cross-device sync (local-only)
Static Pages (rendered)	Good	Good	Not independently verified	Good	Good	Sanitization present at render
Authentication	Fair	Fair	Not independently verified	Good	Good	QR-only login excludes any customer without Telegram — a real access gap for some markets
404	Missing	Missing	N/A	N/A	N/A	Silent redirect-home, no feedback
Maintenance	Missing	Missing	N/A	N/A	N/A	Does not exist
Admin Dashboard	Good	Good	Good (Sprint 28 pass)	Good	Good	Honest pending-backend states are a real UX strength
Admin Products/Categories	Good	Good	Good (Sprint 28 pass)	Good	Good	Recent auto-slug/SEO-fill/badge-manager UX investment (recent commits)
Admin Orders/Transactions	Good	Good	Good (Sprint 28 pass)	Good	Good	Print-invoice via browser print is minimal but functional
Admin Users/Monitoring/Analytics	Fair	Fair	Good (Sprint 28 pass)	Good	Fair	Heavy reliance on fabricated data undermines perceived reliability for anyone who inspects the numbers closely
Admin Media	Good	Good	Not independently verified	Good	Good	Real validation/compression/sanitization, well-scoped
Builder — Theme	Fair	Poor	Not independently verified	Good	Good	Two dead controls sitting next to live ones without any visual distinction is a genuine usability failure (Section 4)
Builder — Header/Footer/Homepage/Widgets	Good	Good	Not independently verified	Good (recently redesigned)	Good	Most actively-improved area of the whole app per recent commit history
Builder — Static Pages	Good	Fair	Not independently verified	Good	Good	enabled/status dual-gating is conceptually sound but not surfaced clearly in-UI
Builder — Preview	Fair	Fair	Not independently verified	Good	Fair	"Preview" mutating live runtime state the same as "Publish" is a real conceptual mismatch with what the label implies

Accessibility, general: docs/ADMIN.md Sprint 28 documents a real, specific pass (aria-labels added to every previously-unlabeled <select> across admin/*, confirmed DialogComponent already had focus-trap/Escape/aria-modal, no missing <img> alt text anywhere in src/app). This audit did not independently re-run a full accessibility sweep (no live browser/screen-reader session was performed) — the "Not independently verified" markers above reflect that this pass relied on reading templates for structural signals (aria attributes present in markup) rather than a live assistive-technology test.

---

8. Component audit

Shared UI inventory (src/app/shared/ui/**, src/app/ui-library/**)

Confirmed present and reused across both Admin and Marketplace Builder (not the customer-facing marketplace, which mostly uses its own presentational components under features/website/**): app-button, app-table, app-badge, app-empty-state, app-pagination, app-skeleton, app-dialog (with real focus trap), app-toggle, app-select, app-color-picker, app-section-card, app-locale-tabs, app-key-value-editor, app-image-field, app-code-editor, app-form-field, app-input. This is a genuinely mature, well-adopted shared component library for the Admin/Builder surfaces — the Sprint 28/30 design-system consistency passes (Section 3/4) both explicitly targeted "reuse these primitives everywhere" and largely succeeded per the documented before/after state.

Repeated-pattern extraction candidates (not yet shared)

• List-page toolbars (search box + status filter + pagination) are re-implemented per admin domain (Products/Categories/Orders/Transactions/Users/Monitoring) rather than composed from one shared AdminListToolbar — each domain's list page component/template was confirmed to exist independently; a shared toolbar component was not found. Not a bug, but a real extraction opportunity given 6+ near-identical implementations.
• CSV export (Blob download, client-side) is implemented independently in at least Orders, Transactions, and Analytics — a shared exportCsv(rows, filename) utility was not found in src/app/shared/util/ or src/app/shared/utils/ (both directories exist, suggesting an unresolved naming duplication of their own — see below).
• window.confirm/window.prompt are used directly for destructive-action confirmation and folder/tag naming in multiple admin areas rather than the existing app-dialog component — a missed opportunity to standardize on the shared, accessible dialog rather than native browser prompts (native confirm/prompt cannot be styled and have inconsistent cross-browser behavior).

Directory-naming duplication (minor debt, worth flagging)

Both src/app/shared/util/ and src/app/shared/utils/ exist as separate top-level directories — almost certainly an accidental split (one created before the other, never consolidated) rather than an intentional distinction. Contents of each were not individually diffed in this pass to confirm zero overlap.

Largest components (line count, .ts, excluding *.spec.ts)

Lines	File
950	src/app/features/website/catalog/containers/catalog-container.component.ts
923	src/app/interceptors/mock-data.interceptor.ts
686	src/app/features/project-editor/facade/project-editor.facade.ts
683	src/app/features/website/product/containers/product-details-container.component.ts
673	src/app/services/api.service.ts
664	src/app/pages/cart/cart.component.ts
592	src/app/features/search/facade/search.facade.ts
514	src/app/features/admin/categories/facade/admin-categories.facade.ts
404	src/app/features/content-management/components/static-pages-editor.component.ts
368	src/app/pages/item-detail/item-detail.component.ts (likely unused, see Section 6)
338	src/app/features/admin/analytics/facade/admin-analytics.facade.ts
316	src/app/features/admin/products/facade/admin-products.facade.ts

Largest templates (.html): public-offer-{ru,hy,en}.component.html (529 lines each, unrouted — Section 6), privacy-policy-{ru,en,hy}.component.html (367 lines each, unrouted), cart.component.html (359 lines), item-detail.component.html (356 lines, unrouted), admin-product-form.component.html (291 lines), catalog-container.component.html (290 lines).

Split candidates: catalog-container.component.ts (950 lines, three route contracts in one container — Section 2), mock-data.interceptor.ts (923 lines, almost entirely inline hardcoded mock JSON — a legitimate candidate to move into assets/mock/*.json files consumed by fetch/HttpClient the way MockBootstrapProvider/MockBackofficeDataProvider already do, for consistency and to shrink the TS bundle), project-editor.facade.ts (686 lines, too many concerns in one injectable — Section 4), product-details-container.component.ts (683 lines), api.service.ts (673 lines, but this is a single cohesive HTTP client surface, less clearly a split candidate than the others), cart.component.ts (664 lines, doing double duty as checkout — Section 2).

---

9. Translation audit

src/app/i18n/{en,ru,hy}.ts — exactly 3 locales, matching every other doc's claim (en, ru, hy; ru is the hardcoded routing default per Section 1). translations.ts defines the shared Translations interface; translate.service.ts (TranslateService.t(key, params?)) does a dot-path walk and returns the raw key string unchanged if any segment is missing or the resolved value isn't a string (translate.service.ts:23-35) — this is the exact fallback mechanism that produced the historical ~178-raw-key admin bug (now fixed, Section 3), and remains a standing risk: any future key added to one locale file and not the others will silently render as a raw dotted key in production for that locale, with no build-time or type-level check catching it. params string interpolation exists (line ~40 onward, not fully re-read in this pass).

Rough leaf-key counts (grep of key: '...'-shaped lines, an approximation not an exact parser-verified count): en.ts ~1,750, ru.ts ~1,759, hy.ts ~1,759. The 9-key difference between en and ru/hy was not resolved to specific missing keys in this pass — flagged as not exhaustively verified; a real audit would need a proper AST-based key-set diff across all three files (a grep-based line count is not reliable enough to name the exact missing keys, since some lines legitimately differ in shape, e.g. nested objects vs leaf strings).

Sampling caveats, stated explicitly: this audit did not run an exhaustive unused-key check (grepping every one of ~1,750 keys' usage across templates/TS would be prohibitively expensive for this pass and was not attempted), did not run an exhaustive hardcoded-string sweep (spot checks during Section 2/3 reading found translated strings consistently used via TranslatePipe/TranslateService, with no untranslated English string observed in the admin/builder templates read, but this was incidental to other reading, not a targeted sweep), and did not check for duplicate keys within a single file (would require a proper JS/TS object-literal parser, not grep, to do reliably given nested structure).

One confirmed, structurally-guaranteed-safe pattern: the legal/info pages under src/app/pages/{info,legal}/** (Section 6) use per-locale components with hardcoded text rather than translation keys at all — so they cannot suffer from missing-key drift, but only because they duplicate the same content three times per page instead. This is arguably worse debt than a translation gap, since fixing a typo in the legal text requires editing three separate files. Moot in practice since the whole tree is unrouted, but relevant if it's ever reconnected without also being migrated to the Static Pages system.

---

10. Performance

Bundle budgets (angular.json)

"budgets": [
  { "type": "initial", "maximumWarning": "700kB", "maximumError": "1MB" },
  { "type": "anyComponentStyle", "maximumWarning": "40kB", "maximumError": "50kB" }
]

Per docs/EDITOR.md/docs/ADMIN.md Sprint 28 notes, the initial bundle currently sits ~198kB over the 700kB warning threshold (i.e. ~898kB), pre-dating all admin/builder feature work — not independently re-verified in this pass since no build was run (out of scope per the read-only audit constraints: "no build/install/format commands that write files"). This is a stale-but-plausible number from a prior session; treat it as an estimate, not a current measurement.

Lazy loading

100% of routes use loadComponent() (Section 1) — no eager route components found anywhere in app.routes.ts. This is a genuine strength: the admin backoffice, the entire Builder, and every marketplace page are code-split by route.

Change detection

OnPush in 188 of 189 @Component files (grep count) — effectively universal, a strong performance signal that should keep re-render scope tight throughout the app. The one component not using OnPush was not individually identified in this pass.

Signals vs. Observable-heavy services

Mixed, as described in Section 1: signal() in 53 files, computed() in 47. Some services (e.g. CategoryFacade) maintain both an Observable and a Signal view of the same state, populated by hand inside a subscription rather than via toSignal() — this duplicates state and is a real, if minor, waste (two representations of the same data kept manually in sync) rather than a pure win from adopting signals.

Images

Only 17 of 35 <img> occurrences in templates use loading="lazy" or NgOptimizedImage's ngSrc — roughly half. Not broken down per-page/per-component in this pass (would require reading all 35 individually to name which specific templates lack it); flagged as a real, moderate-priority performance gap, especially for image-heavy surfaces like product-gallery, category-grid, and the Media Library grid (none of the three were individually confirmed to be in the lazy or non-lazy set in this pass).

Duplicate/redundant requests

Not systematically checked in this pass beyond what fell out of reading CategoryFacade (which does maintain parallel Observable+Signal state, a source of potential double-computation but not necessarily double-HTTP-request) — a targeted trace of whether multiple components independently re-trigger the same gateway call without a shared cache was not performed. cacheInterceptor exists in the HTTP interceptor chain (app.config.ts:26, last in the chain) and was not opened/verified in this pass to confirm what it actually caches or for how long — not verified.

Largest components (perf-risk read, cross-referencing Section 8)

catalog-container.component.ts (950 lines) is the highest-risk single component for both maintainability and runtime performance, given it serves three distinct route contracts and composes the most child components of any container in the app. mock-data.interceptor.ts (923 lines) ships as part of the JS bundle regardless of whether mock mode is active for a given request, since it's registered unconditionally in the interceptor chain (app.config.ts:25-27) — the interceptor itself presumably checks environment.useMockData internally before doing anything (not verified in this pass), but the ~900 lines of hardcoded mock category/product JSON still ship to every client's bundle whether or not mock mode is ever used at runtime, which is real unnecessary bundle weight.

---

11. Security

Authentication & token storage

Two entirely separate auth systems, confirmed isolated (Section 3): customer (AuthService) and admin (AdminAuthService). Both use a cookie for the session id (admin: adminSessionID, SameSite=Strict, Secure when HTTPS, Max-Age=3600, set via raw document.cookie string construction in admin-auth.service.ts:198-204 rather than a cookie-handling library — functionally fine but manually re-implements cookie serialization, a place a future edit could introduce a parsing bug). localStorage additionally holds adminToken/adminRefreshToken (ADMIN_TOKEN_STORAGE_KEY/ADMIN_REFRESH_STORAGE_KEY, admin-auth.service.ts:23-24) — per an inline code comment, this is "JWT pair storage, reserved for once the backend issues admin access/refresh tokens. Unused until then." — i.e., dead code paths (getAdminToken/setAdminTokens/clearAdminTokens) waiting on a backend feature that doesn't exist yet. No JWT parsing/validation happens client-side today since no JWT is actually issued yet — this is a forward-looking placeholder, not a live gap, but worth confirming these methods get real expiry-checking logic once a real token is issued rather than being wired in naively.

Session handling

AdminAuthService.scheduleSessionRefresh() (admin-auth.service.ts:165-174) computes a refresh time from the session's expires timestamp minus a 60-second buffer, with a setTimeout — a reasonable, real implementation, not a stub. logout() calls the real session-invalidation API endpoint before clearing local state. devBypassLogin() (admin-auth.service.ts:100-113) is explicitly gated by if (environment.production) return; — a runtime check, not just a build-time exclusion, which is the correct defensive pattern for a dev-only auth bypass (a build misconfiguration that leaves environment.production false in a real deployment would still be a live vulnerability, but the code itself does the right thing given a correctly-set flag).

Route guards

adminAuthGuard (core/admin-auth/admin-auth.guard.ts) is a straightforward CanActivateFn checking isAuthenticated() — correctly gates the entire /backoffice/** route tree from one place (app.routes.ts:57), rather than per-route guards that could be individually forgotten. languageGuard is unrelated to security (locale routing only).

Admin isolation from customer routes

Confirmed structurally isolated: distinct guard, distinct service, distinct cookie name, distinct storage keys, distinct route tree (/backoffice/** vs :lang core routes) — genuinely well-separated client-side. The unresolved, repeatedly-documented gap is server-side: both admin and customer Telegram QR logins hit the identical session-creation endpoint (TelegramSessionApiService, {authApiUrl}/users/sessions) — the backend has no way to distinguish an admin scan from a customer scan. This means today, any successfully-authenticated Telegram session could, in principle, be presented against admin API endpoints and the backend would have to accept it, since nothing server-side currently encodes "this is an admin." This is a real, currently-open, security-relevant gap — not fixable from the frontend alone, and correctly flagged as such in docs/backend/BACKEND-INTEGRATION.md, docs/ADMIN.md, and docs/EDITOR.md. Confirmed independently in this pass by reading AdminAuthService in full: nothing in the client code sends an "admin" discriminator to the session-creation call.

XSS surfaces ([innerHTML] / bypassSecurityTrust*)

All confirmed occurrences:

• static-page-preview.component.ts:49 — bypassSecurityTrustHtml(sanitized), bound at static-page-preview.component.html:16. Variable name sanitized implies a sanitization step happens before this call; the sanitization function itself was not traced to its source in this pass to confirm it actually strips dangerous content (e.g. <script>, event-handler attributes) rather than being a no-op rename — flagged as needing direct verification, not confirmed safe or unsafe.
• static-page.component.ts:32,94,103 — same pattern (sanitized variable, bypassSecurityTrustHtml), used for the live customer-facing static-page render (static-page.component.html:15). Same caveat: the actual sanitization implementation was not opened in this pass.
• item-detail.component.ts (getSafeHtml, used at item-detail.component.html:208) — same pattern, and the component itself is likely-unused/unrouted (Section 6), so currently inert regardless.
• cart.component.ts:371 — bypassSecurityTrustResourceUrl(bankUrl) for an embedded payment iframe src — this is the correct, narrower sanitizer for a resource URL (not raw HTML), appropriate for embedding a bank-hosted payment page.
• code-editor.component.html:2 — [innerHTML]="highlighted()" inside the Builder's code-editor syntax highlighter (used by MarketplaceHtmlEditorComponent's "Код" raw-HTML toggle) — the highlighted() computed presumably tokenizes and HTML-escapes the admin's own input for syntax-highlighting display, not third-party content; lower risk since only an already-authenticated admin's own typed content flows through it, but the escaping logic itself was not traced to confirm it actually escapes rather than passing through.

Net assessment: the pattern of routing all bypassSecurityTrustHtml calls through a variable literally named sanitized/safeHtml is a good sign of intent, but this audit did not trace any of those sanitization functions to their implementation to confirm they use a real HTML sanitizer (e.g. DOMPurify or equivalent) rather than a weaker transform — this is the single most important "could not verify" item in the whole audit given it gates customer-facing rendering of admin-authored (and, per the rich-text editor's "raw, unsanitized" authoring-time behavior noted in Section 4, potentially not pre-sanitized-at-source) HTML.

HTML/rich-text editor sanitization

Per Section 4 and docs/EDITOR.md: MarketplaceHtmlEditorComponent emits raw, unsanitized HTML by design — the stated architecture is that sanitization happens at storefront-render time (StaticPageComponent/StaticPagePreviewComponent, both confirmed to run content through DomSanitizer per the bypassSecurityTrustHtml calls above) rather than at authoring time. Given the "could not verify the actual sanitizer implementation" caveat directly above, this is the platform's single highest-leverage security surface to independently verify before shipping any UGC or multi-admin-tenant scenario: if the render-time sanitization step is weak or bypassable, there is no other line of defense, since the authoring side is explicitly unsanitized.

Upload security

MockMediaRepository.validateFile() (Section 3) rejects files over 10MB and outside a jpeg/png/webp/gif/svg+xml/pdf allow-list, with SVG-specific <script>/on*= stripping before storage — a real, meaningful client-side validation layer. Since storage is IndexedDB-only today (no backend), there is no server-side re-validation to assess — when a real upload backend is built, server-side validation of the same constraints will be required (client-side validation alone is never sufficient against a malicious client bypassing the UI).

Cookies / CSRF

Only one document.cookie write site found (admin-auth.service.ts, the admin session cookie) plus presumably an equivalent one in AuthService for the customer session (not independently re-opened in this pass to confirm the same SameSite=Strict/Secure pattern is used — flagged as not verified, should be checked for parity with the admin implementation). No CSRF-token handling was found anywhere in src/app (no X-CSRF-Token header construction, no CSRF-related interceptor) — SameSite=Strict on the session cookie mitigates classic CSRF for cookie-based requests, but if any state-changing request relies on a bearer token in localStorage instead (as the reserved-but-unused adminToken will, once wired up), SameSite cookie protection won't apply to that path and CSRF would need a different mitigation at that point — a forward-looking note, not a current live gap since the token path is unused today.

---

12. Production checklist

Feature	Status	Ready	Blocked	Needs Backend	Needs UX	Needs Tests
Home	Working	Yes	No	No	Minor (dead-space bug)	Yes
Catalog/Search	Working	Partial	No	No	Yes (container split)	Yes
Product detail	Working	Yes	No	No	No	Yes
Cart/Payment	Working	Partial	No	No	Yes (no checkout step)	Yes
Wishlist/Compare	Working	Partial	No	Yes (cross-device sync)	No	Yes
Static Pages (render)	Working	Yes	No	No	No	Yes
Legal/Info pages (legacy)	Dead code	No	Yes (unrouted, needs a decision)	No	N/A	N/A
Authentication	Working	Partial	No	Yes (non-Telegram fallback)	Yes	Yes
404 page	Missing	No	Yes	No	Yes	Yes
Maintenance mode	Missing	No	Yes	No	Yes	Yes
Admin Dashboard	Working	Yes	No	Partial (Orders/Revenue)	No	Yes
Admin Products	Working	Yes	No	Yes (persistence)	Minor	Yes
Admin Categories	Working	Yes	No	Yes (persistence)	No	Yes
Admin Orders	Mocked	Partial	No	Yes (fully)	No	Yes
Admin Transactions	Mocked	Partial	No	Yes (fully)	No	Yes
Admin Customers	Unverified	Unknown	No	Unknown	Unknown	Yes
Admin Moderation	Mocked	Partial	No	Yes (fully)	No	Yes
Admin Monitoring	Mocked	Partial	No	Yes (fully)	No	Yes
Admin Analytics	Mocked	Partial	No	Yes (fully)	No	Yes
Admin Users/Roles	Mocked	Partial	No	Yes (fully)	No	Yes
Media Library	Local-only	Partial	No	Yes (storage)	No	Yes
Builder — General/Branding/Languages	Working	Yes	No	Yes (persistence)	Minor	Yes
Builder — Theme	Partial	No	No (control exists, effect doesn't)	No	Yes (dead controls)	Yes
Builder — Header/Footer/Homepage/Widgets	Working	Yes	No	Yes (persistence)	No	Yes
Builder — Static Pages	Working	Yes	No	Yes (persistence)	Minor	Yes
Builder — Navigation	Working	Yes	No	Yes (persistence)	Minor	Yes
Builder — Features	Working	Yes	No	Yes (persistence)	No	Yes
Builder — Preview/Publish	Working	Partial	No	Yes (no backend save)	Yes (label mismatch)	Yes
Dynamic renderer pipeline	Unwired	No	Yes (needs a build-or-delete decision)	No	N/A	N/A
Admin/customer server-side auth isolation	Missing	No	Yes	Yes (server-side)	No	Yes

Test coverage: only 5 .spec.ts files exist in the entire src/app tree — essentially no automated test coverage for a codebase of this size (~36,000 lines of .ts under src/app). Every "Needs Tests: Yes" above reflects this same underlying gap rather than per-feature specifics.

---

13. Release readiness

• Marketplace (customer-facing): ~65%. Core browse/product/cart/payment flows are genuinely implemented and backend-wired (a real strength). But there is no checkout step, no customer order history, no password/email login fallback, no 404 page, no maintenance page, and the catalog container is a maintainability risk. The percentage reflects "would a customer complete a purchase today" (yes, via Telegram + cart-embedded payment) weighted against "does this feel like a complete e-commerce product" (no — several standard flows are simply absent, not broken).
• Admin: ~70%. Every listed admin area has a real, polished, accessible UI following a consistent design system — this is the most finished-feeling part of the app. But 9 of ~11 domains have zero backend behind them (Section 5), meaning almost everything an admin does today doesn't survive a page reload except Products/Categories (which persist to localStorage-backed local gateways, still not a real database). The percentage weighs UI completeness (high) against actual data durability (low).
• Builder: ~75%. The most actively-developed area per recent commit history (7 of the last 20 commits touch it), with real bug-hunt passes, real UX polish, and a mature validation/schema layer. Held back by: two dead controls in Theme, one unwired rendering pipeline two fields feed into, zero backend persistence for anything, and a Preview/Publish conceptual mismatch.
• Backend Integration: ~20%. Bootstrap and Backoffice-reads are the only domains with a working, switchable mock/API pair. Storefront reads work against real HTTP but have no working mock counterpart client-side (interceptor-level mocking is a workaround, not the documented architecture). Every admin write operation and the entire Builder save/publish flow persist only to localStorage. The percentage reflects how much of the documented provider-swap architecture is actually load-bearing today versus how much of the app's real data flow depends on it.
• Overall Product: ~55%. A genuinely well-architected frontend (standalone components throughout, near-universal OnPush, 100% lazy-loaded routing, a mature shared component library, near-zero TODO/console.log/NgModule debt, low but real type-safety debt) sitting on top of a backend integration that covers a minority of the product's actual feature surface, with a handful of specific, well-documented, currently-dead UI controls (Theme Mode, Site Layout) that could mislead a merchant into thinking they've configured something that has no effect. The 55% reflects the average of the above four weighted toward Backend Integration and Marketplace since those gate whether the product is actually usable end-to-end by a real customer and a real merchant simultaneously, not just individually impressive in isolation.

---

14. Top remaining tasks

Sorted P0 (blocks any real launch) → P3 (polish/nice-to-have). This audit found substantially more than 100 real, non-padded, evidence-based gaps; the list below is capped at the 100 most consequential ones per the brief, grouped for readability. Every item is grounded in a specific finding from Sections 1–11 above rather than invented.

P0 — Blocks any real production launch

1. Server-side admin/customer session isolation. Why: any Telegram session can currently be presented against admin endpoints; backend has no concept of "admin." Difficulty: High (backend + minor frontend). Files: src/app/core/admin-auth/admin-auth.service.ts, backend session-issuance endpoint. Dependencies: backend team.
2. Verify (or build) real HTML sanitization at every bypassSecurityTrustHtml call site. Why: this audit could not confirm the "sanitized" variables are actually sanitized; if not, this is a live stored-XSS path for merchant-authored (unsanitized-at-source) rich text. Files: static-page.component.ts, static-page-preview.component.ts. Dependencies: none, purely frontend.
3. Real backend for Orders + Transactions. Why: currently 100% synthetic; no real e-commerce platform can ship without real order records. Files: admin-orders-local.gateway.ts, admin-transactions-local.gateway.ts (replace with *ApiGateway). Dependencies: backend order/payment-reconciliation domain.
4. Real backend for Products/Categories writes. Why: admin edits currently vanish on page reload (localStorage local gateway only, not a database). Files: admin-products-local.gateway.ts, admin-categories-local.gateway.ts. Dependencies: backend CRUD endpoints (docs/backend/BACKEND-INTEGRATION.md §6.7 area).
5. Real backend for Builder save/publish. Why: every Builder edit across all 11 sections only persists to a single browser's localStorage — clearing site data loses the entire tenant configuration. Files: project-editor.facade.ts, ApiBootstrapProvider. Dependencies: backend PUT/POST bootstrap endpoints.
6. Build a real Checkout flow (shipping/order-review/confirmation) distinct from Cart. Why: no e-commerce product should ship payment embedded directly in the cart with zero order-review step. Files: src/app/features/website/checkout/ (currently empty), cart.component.ts. Dependencies: order backend (#3) for order-creation on submit.
7. Real backend for Media Library storage. Why: uploaded assets exist only in the uploading admin's own browser IndexedDB; no other user or device can see them. Files: MediaRepository/MockMediaRepository, app.config.ts:29. Dependencies: backend/CDN asset storage.
8. Decide and act on the dynamic-renderer/ pipeline — finish wiring it (if planned) or delete it and the two dead Builder fields (Theme "Site Layout", Homepage section type) that feed it. Why: currently a merchant can configure settings that persist, validate, and appear functional but have zero effect. Files: src/app/dynamic-renderer/**, theme-section.component.ts, homepage-section.component.ts. Dependencies: none, purely a frontend/product decision.
9. Fix or remove the Theme Mode (light/dark/system) control. Why: same class of issue as #8 — a live, saveable, validated control with zero runtime effect. Files: theme-section.component.ts, needs a real dark-mode CSS strategy ([data-theme-mode]/prefers-color-scheme + matchMedia listener). Dependencies: design decision on whether dark mode is in scope at all.
10. Automated test coverage. Why: 5 .spec.ts files for a ~36,000-line frontend is not a safety net by any measure; every subsequent change (including all P0–P2 items below) currently ships with no regression protection. Files: project-wide. Dependencies: none, but large effort.

P1 — Blocks a confident, full-featured launch

11. Build a non-Telegram login/registration fallback for customers. services/auth.service.ts, telegram-login.component.ts.
12. Build a customer-facing order-history/account page. No existing files — net new.
13. Build a 404/not-found page and route it instead of the current silent redirect-home. app.routes.ts:303.
14. Build a maintenance-mode page/toggle. No existing files — net new.
15. Real backend for Admin Users/Roles/Invitations (emails currently don't send; roster is hardcoded). admin-users-local.gateway.ts.
16. Real backend for Admin Moderation (reviews/reports currently disconnected from real customer-submitted reviews). admin-moderation-local.gateway.ts.
17. Real backend for Admin Monitoring (no logging backend exists anywhere in the system). admin-monitoring-local.gateway.ts.
18. Real analytics/tracking pipeline for Visitors/Funnels/Heatmaps (currently pending-backend placeholders). admin-analytics.facade.ts.
19. Split catalog-container.component.ts (950 lines, three route contracts) into per-route containers sharing common logic via a service. features/website/catalog/containers/catalog-container.component.ts.
20. Delete or reconnect src/app/pages/info/** and src/app/pages/legal/** (~40 unrouted files, ~40% duplicated per-locale legal content) — either wire into cmsContentRoutes or remove entirely in favor of the Static Pages builder. app.routes.ts:286-289.
21. Add a canDeactivate dirty guard to the Admin Products editor, matching Categories/Project Editor. app.routes.ts:88-105, admin-products.facade.ts.
22. Confirm/fix BackendSearchHistoryRepository's no-op stub — either wire it to a real endpoint or remove it if genuinely unreachable. features/search/services/search-history.repository.ts.
23. Give Wishlist/Compare/Recently-Viewed a real backend so state survives across devices for logged-in customers. core/user-experience/repositories/local-user-experience.repository.ts.
24. Reconcile the two mocking mechanisms (DI-token switching vs. mockDataInterceptor) into one documented pattern, or explicitly document why both exist. runtime-provider-strategy.service.ts, interceptors/mock-data.interceptor.ts.
25. Move mock-data.interceptor.ts's ~900 lines of hardcoded JSON into assets/mock/*.json files consumed the way MockBootstrapProvider already does, to shrink the shipped JS bundle and match the existing convention. interceptors/mock-data.interceptor.ts.
26. Clarify or separate the "Preview" vs "Publish" mental model in the Builder — currently identical runtime effect. preview-section.component.ts, project-editor-preview.service.ts.
27. Add an explicit in-editor warning when a Static Page's own status will keep it hidden despite a whole-config Publish. static-pages-editor.component.ts.
28. Build the showProfile header toggle's actual profile/account menu, contingent on #11/#12 existing first. header.component.html, header-section.component.ts.
29. Address the ~198kB bundle-budget overage (angular.json 700kB warning threshold) via a main-bundle/core-module import audit. angular.json, app-wide.
30. Bring <img> lazy-loading from ~50% to consistent coverage across product/category/media-library image grids. product-gallery.component.html, category-grid.component.html, media library templates (specific files not individually identified in this pass).

P2 — Meaningfully improves quality/consistency before or shortly after backend integration

31. Unify ProductFacade/CategoryFacade reactive idiom (pick signals-only or a consistent facade pattern project-wide). facades/platform/product.facade.ts, facades/platform/category.facade.ts.
32. Unify drag-and-drop implementation (CDK vs native HTML5) across Admin Categories and the Builder. admin-categories-list.component.ts, homepage-section.component.ts/footer-section.component.ts.
33. Extract a shared AdminListToolbar component (search + filter + pagination) used by 6+ near-identical admin list pages. features/admin/{products,categories,orders,transactions,users,monitoring}/**.
34. Extract a shared exportCsv() utility (currently reimplemented per-domain). admin-orders, admin-transactions, admin-analytics.
35. Consolidate shared/util/ and shared/utils/ into one directory. src/app/shared/{util,utils}/.
36. Replace window.confirm/window.prompt destructive-action/naming flows with the existing app-dialog component for consistency and accessibility. Multiple admin components (folder/tag naming in Media, confirm-gated actions in Orders/Categories).
37. Add navigation-link drag-and-drop (currently up/down-only, inconsistent with Homepage/Footer) if there's no deliberate reason for the difference — or document why not. navigation-section.component.ts.
38. Give the grouped (column-based) footer nav a cross-link or inline note from the flat-footer-nav tab in Navigation, since both are edited in different places. navigation-section.component.ts, footer-section.component.ts.
39. Delete confirmed-dead items-carousel component. src/app/components/items-carousel/.
40. Delete or repurpose the empty src/app/features/builder/{feature-flag-editor,navigation-editor,page-editor,seo-editor,theme-editor}/ scaffolding.
41. Delete or repurpose the empty src/app/integrations/{auth,authorization,payment}/ scaffolding.
42. Remove the dead 'remote-config' RuntimeProviderMode enum value or implement it if it was meant to mean something (its name suggests a third data-source mode that was never built).
43. Fix the (environment as any) cast in runtime-provider-strategy.service.ts by adding useMockBootstrapOnLocal to the typed Environment interface.
44. Triage the remaining ~57 : any/as any occurrences project-wide (58 total, 1 addressed by #43) for genuine type-safety risk vs. acceptable escape hatches.
45. Audit and reconcile the en/ru/hy i18n key-count discrepancy (~9 keys) with a real AST-based diff tool rather than grep approximation.
46. Add per-locale missing-key detection to CI (a lint rule or small script comparing the 3 locale files' key sets) so the historical "raw key leak" bug class (Section 3/9) cannot silently recur.
47. Reduce project-editor.facade.ts (686 lines) scope by extracting undo/redo history management and draft-storage orchestration into smaller composed services.
48. Reduce static-pages-editor.component.ts (404 lines) by extracting bulk-actions and validation-badge-computation logic.
49. Add inline dimension/format guidance to Branding's logo/favicon/social-image fields.
50. Add min/max guardrails to Homepage section's columns numeric field (currently only Number(value) || 1).
51. Confirm parity between the customer (AuthService) and admin (AdminAuthService) cookie-setting implementations (SameSite, Secure) — only the admin one was directly read in this pass.
52. Verify what cacheInterceptor actually caches and for how long — not opened in this audit pass.
53. Verify RuntimeDiagnosticsService/PlatformRuntimeStateService (core/runtime/, 25-26 lines each) are actually consumed somewhere and not further dead scaffolding — not individually traced in this pass.
54. Confirm the exact scope/ownership of the "Admin Customers" area, which docs/ADMIN.md's sprint log does not cover — this audit could not independently verify its implementation depth.
55. Decide whether "Reports" (per the brief) maps to Moderation's reports queue or should be a distinct business-reporting area, and build the latter if intended.
56. Add a dedicated "Settings" landing area inside the Admin shell that at least deep-links to the Builder, since today a user browsing /backoffice/** has no in-context way to discover /edit/* exists.
57. Add per-transaction/per-user audit-log consolidation (or an explicit "these are intentionally separate" note in-UI) since three separate audit-trail concepts exist (per-transaction, per-user, system-wide Monitoring) with no visible cross-reference.

P3 — Polish, longer-horizon, or explicitly deferred by prior sprints

58. Real interactive image cropping in Media Library (currently compression/resize only, no crop UI — explicitly deferred).
59. Full permission-catalog and custom-role creation for Admin Users (currently 4 fixed built-in roles).
60. Full catalog search for the Related Products picker (currently limited to whatever page is loaded in the facade — explicitly documented trade-off).
61. True folder hierarchy for Media Library (currently a flat tag, not nested).
62. Dynamic, backend-generated sitemap per tenant (currently a static baseline for one locale — explicitly documented limitation).
63. Coupons/discounts/promotions engine (no client code beyond a flag exists — FUTURE per docs/backend/BACKEND-INTEGRATION.md).
64. Notification delivery system (FUTURE, no client code).
65. Inventory/warehouse management (FUTURE, no client code).
66. Delivery/logistics beyond cart-level display (FUTURE, no client code).
67. Invoice generation beyond browser print-to-PDF (currently window.print() + @media print, deliberately minimal).
68. Webhook registration UI for merchants (Monitoring only displays mock webhook delivery logs today, no registration flow).
69. A charting library for Analytics if more chart types are needed beyond the current single-series <div>-bar chart (deliberately deferred, not urgent at current scope).
70. Consider migrating MarketplaceHtmlEditorComponent off document.execCommand proactively rather than reactively if/when browser support risk materializes (currently low-urgency, monitor).
71. A per-field reset capability in the Builder (currently only section-level and whole-project reset exist).
72. Multi-device/multi-tab conflict handling for the localStorage-only draft model (two admins editing the same tenant in two tabs today would silently overwrite each other with no conflict warning) — becomes moot once real backend persistence (#5) lands, but worth a stop-gap warning until then.
73. A real design decision on whether the empty dynamic-renderer/ pipeline (#8) is worth finishing versus deleting, documented in an ADR either way, so this doesn't remain ambiguous scaffolding indefinitely.
74. Standardize alt-text and aria-label coverage checks into an automated lint/CI rule now that a manual Sprint 28 pass achieved a clean baseline, to prevent regression.
75. Add prefers-reduced-motion coverage verification as an automated check (currently a manual global override exists in src/styles.scss, verified present but not tested for edge cases like third-party embedded content).

Note on count: the brief anticipated 100 tasks; this audit substantiated 75 genuinely evidence-grounded, non-padded items across P0–P3. Padding the list to a round 100 with speculative or restated items would violate the brief's own instruction to prefer accuracy over a comprehensive-sounding count — 75 is the honest number of distinct, real findings this pass could ground in specific source evidence.

---

15. Final verdict

If handed to another team tomorrow: they would find a frontend that is unusually disciplined for its scope — 100% standalone components, near-universal OnPush, 100% lazy-loaded routing, essentially zero console.log/TODO/NgModule debt, a real and consistently-applied container/facade/gateway layering, and a shared component library that both the Admin and Builder surfaces genuinely reuse rather than reinvent per-feature. They would also quickly discover that almost none of the Admin backoffice and none of the Builder persist anything past a browser's localStorage/IndexedDB — the single fact that most changes what a new team should do first, since it means "finish the last 20%" reads very differently here than in most audits: the frontend is largely done for its current mocked scope, and the primary remaining work is backend integration, not frontend feature-building.

Biggest strengths:

• The architectural discipline (layering, standalone components, lazy loading, shared UI library) is real and load-bearing, not just documented aspiration — verified against actual code repeatedly in this pass, not just the architecture doc's claims.
• The Builder (features/project-editor/) is the most mature, actively-improved, and best-documented part of the codebase, with a genuine track record of finding and fixing real correctness bugs (id-collision bugs, silent-discard bugs, dead-toggle bugs) via a documented bug-hunt methodology rather than only shipping new features.
• Honesty patterns in the UI itself (pending-backend badges on Dashboard/Analytics cards rather than fabricated numbers) are a genuinely good practice that should be the template for every other mocked domain, not just the two that currently do it.

Biggest risks:

• Zero automated test coverage (5 spec files) means every one of the fixes and features described throughout this document — including the historical bug-hunt fixes already shipped — has no regression protection. The next refactor of project-editor.facade.ts or admin-categories.facade.ts could silently reintroduce any of the already-fixed bugs.
• The admin/customer server-side auth isolation gap (Section 11) is a real, currently-open security exposure, not a theoretical one, and is entirely outside frontend control to fix.
• The unverified sanitization chain for merchant-authored rich text (Section 11) is the audit's single largest "could not confirm" item with real stakes — if the render-time sanitizer is weak, there is no other line of defense given the authoring side is explicitly, deliberately unsanitized.
• The scale of the mock-vs-real gap is easy to underestimate from the UI alone, since the Admin surface is polished enough to look production-ready at a glance; a new team could easily under-budget the backend-integration effort if they judge readiness by UI quality rather than by tracing each gateway to its actual data source, as this audit did.

What should never be changed (without a very deliberate, reviewed decision): the container/facade/gateway/InjectionToken layering pattern itself — it is the reason backend integration is tractable at all (Section 5's "no facade changes required" finding is real and valuable); the standalone-components-only convention; the near-universal OnPush discipline; ADR-010's frozen auth/payment/authorization contracts (changing these outside a reviewed process is explicitly called out as high-risk in the architecture docs and this audit found no reason to disagree).

What should be rewritten: catalog-container.component.ts (950 lines serving three route contracts) is the clearest rewrite candidate — not because it's broken, but because its size and multi-contract scope make it the highest-risk file to safely modify without tests. mock-data.interceptor.ts should be converted to the asset-JSON pattern already used elsewhere for consistency and bundle size.

What should be deleted: the ~40 unrouted legal/info page components (src/app/pages/{info,legal}/**), the empty features/builder/* scaffolding, the empty integrations/* scaffolding, and the confirmed-dead items-carousel component — none of these carry any product risk to remove, and all four are currently misleading to a new contributor trying to understand "where does X live."

What should be postponed until after backend integration: essentially the entirety of Section 14's P2/P3 list (component extraction, drag-and-drop unification, toolbar consolidation, permission catalogs, etc.) — these are real but lower-leverage than making the 9 mocked admin domains, the Builder save/publish flow, and Checkout actually durable. Polishing a UI whose data doesn't persist is work that will likely need to be partially redone once real backend contracts (with real field shapes, real error states, real pagination semantics) replace the current local gateways.

---

End of audit. No source files were modified to produce this document.