Architecture governance

MMCA.Store — Architecture Scorecard

Canonical, version-controlled scorecard for this repo — the single source of truth for MMCA.Store's architecture scores. This is Store's first in-repo governance artifact (previously its posture lived only in the workspace docs + memory). Scored against the rubric at ../MMCA.Common/ArchitectureEvaluationCriteria.md; framework-wide facts in ../MMCA.Common/FACTS.md. Remediation lives in RemediationBacklog.md; the cross-repo comparison in ../Docs/Architecture/CrossRepoComparison.md.

Rubric: ../MMCA.Common/ArchitectureEvaluationCriteria.md • Date: 2026-07-17 • Two axes per category: Maturity (0-4, process/governance) and Implementation (0-10, substance/execution). Indices computed deterministically from the scores below. Verified against current source at HEAD 89e4a04 (clean tree); framework dependency pinned at MMCA.Common. v1.117.0* (all 15 packages, lockstep, confirmed no divergence; ADR set 001-048 lives in MMCA.Common). What moved this cycle (2026-07-03 drift-plan execution, D1/D4/D5/D8/D9/D10): §21 Accessibility M3→4 and §28 Front-End Testing M3→4 (the Playwright + axe suite now gates the deploy: e2e-gate joined deploy.yml's needs after two consecutive fully green E2E runs, 28682334766 chromium 83/83 with firefox + webkit also green, confirmed by 28683063228), §12 Performance I7→8 (client Web Vitals are now measured in CI: WebVitalsTests writes LCP/CLS/TTFB/FCP artifacts per run), §23 Front-End Performance I6→8 (the public CatalogBrowse moved to server-side paging via GetPagedAsync + bounded MobileInfiniteScrollList, and cart enrichment now uses a targeted by-variant-id batch lookup instead of fetching the whole product list), and §32 Supply-Chain I7→8 (all three CI restores run --locked-mode and the suppress-aware vulnerability audit is now gating, D8/D9). The prior cycle's moves (2026-07-02 docs sweep: §16/§25/§20 M3→4, §27 scored M4/I7, §14 I6→9, §34 I7→9) are retained in the rows below. A same-day i18n completion sweep (2026-07-03, ADR-027 Decision 9) then lifted §27 Implementation 7→8 (zero residual literals incl. the cart/checkout/Stripe snackbars, dual CI gates, MudBlazor chrome + nav localized; indices Implementation 80.3%→80.4%). A subsequent 2026-07-11 drift-convergence cycle (drift plan D1-D13, pin v1.113.0) moved six scores: §1 SOLID Implementation 8→9 (the ctor-dependency-ceiling gate ConstructorDependencyCountTests + TimeProvider injection, D9), §9 API Implementation 8→9 (the v2 ServiceInfoController + two deploy-gating Contract tests, D12), §24 Forms Maturity 3→4 (the CI-gated FormsConventionTests, D11), §28 Front-End Testing Implementation 6→8 (bUnit breadth grown to 214 facts across 40 files, D7), §29 Resilience Implementation 8→9 (the dr-freshness deploy gate + weekly dr-drill cron + GracefulShutdownTests, D3), and §21 Accessibility Maturity 4→3 with Implementation 7→8 (honest reconciliation to ADC's M3: 22 axe scans + the new screen-reader runbook, but no dated SR pass yet, D6). D2 (MI-SQL activation wiring) and D4 (cost-guard deploy gate) also landed, with no §17/§31 score move. Indices Maturity 94.4%→94.1%, Implementation 80.4%→82.5%. A 2026-07-16 full re-score (34 categories, two-pass with adversarial verification) moved three scores: §13 Observability Implementation 8→9 (both prior deductions closed: the SLO workbook is provisioned in IaC at infra/main.bicep:274 and the per-alert infra/OPERATIONS.md runbook is in-repo; Maturity holds 3 because dashboards/runbooks are IaC/review-enforced, not CI-gated), and §18 UI Architecture + §19 State Management Maturity 3→4 (the sealed UIArchitectureConventionTests and StateManagementConventionTests subclasses of the shared v1.116.0 fitness bases run non-vacuously in the deploy-gating MMCA.Store.CI.slnf on every push and PR, the same mechanism that earned ADC its M4; their proposed Implementation bumps were adversarially rejected as enforcement gains mis-posted to the substance axis). The same re-score DECLINED the recorded maturity candidacies on §12 (k6 stays monthly/on-demand, not a merge gate) and §22 (firefox/webkit are still continue-on-error in e2e.yml:71, contrary to the backlog's promotion claim), and held the §20/§24/§27 impl candidacies. §17 Implementation 8→9 additionally banked on directly verified evidence: MI-SQL is active in production (repo variable USE_MANAGED_IDENTITY_SQL=true since 2026-07-12, activation deploy 29192048197 green), correcting the row's stale inert claim. Indices Maturity 94.1%→95.9%, Implementation 82.5%→83.0%. A same-day drift-analysis fold (2026-07-16, cross-repo ADC-vs-Store comparison, each move adversarially verified) moved two more scores: §23 Maturity 3→4 (the CWV budgets are hard assertions in the deploy-gating chromium e2e-gate, the identical evidence ADC's twentieth cycle credited; the earlier same-day hold at M3 had wrongly imported §12's k6-cadence reasoning) and §32 Implementation 8→9 (capability-level parity with ADC's I9: identical --locked-mode/audit/SBOM gating; the earlier FLAG reasoned from stale scorecard text, not capability). Doc corrections in the same fold: §16's narrated pin 1.113.0→1.116.0, §32's lock-file count 49→55, and the README gained the ADC-parity broker note (§33). Indices Maturity 95.9%→96.6%, Implementation 83.0%→83.3%. A 2026-07-17 full re-score (34 categories, two-pass with adversarial verification, pin v1.117.0) moved four scores: §5 Vertical Slice M3→4 and I7→8 (the sealed SliceCohesionTests subclass runs non-vacuously in the deploy-gating MMCA.Store.CI.slnf, the identical gate ADC credits at M4/I8; the layered-by-project hybrid stays a deliberate implementation-axis cap, no longer a maturity deduction), §13 Observability M3→4 (ObservabilityConventionTests machine-enforces the sloAlertSpecs-to-OPERATIONS.md pairing in the CI merge gate, closing exactly the "not CI-gated" reasoning that held M3), §22 Responsive M3→4 (the 2026-07-16 gate flip verified live: continue-on-error in e2e.yml is scoped to scheduled non-chromium runs only, so all three engines the e2e-gate invokes can fail a deploy), and §27 i18n I8→9 (the PseudoLocalizationTests candidacy granted: pseudo-loc sentinel, no-overflow, and en-US leak probes run over Store's own /, /catalog, and /login pages in the deploy-gating chromium e2e-gate). The narrated framework pin refreshed 1.116.0→1.117.0 throughout. Indices Maturity 96.6%→98.4%, Implementation 83.3%→83.6%.

Executive summary

MMCA.Store is a .NET 10.0 (LangVersion preview) DDD/Clean Architecture e-commerce system (Catalog, Sales, Identity modules; Stripe checkout) extracted into independently-hosted services behind a YARP gateway, collaborating via Result-over-the-wire gRPC and MassTransit integration events on the outbox pattern. It consumes the shared MMCA.Common.* framework at v1.117.0 in lockstep with MMCA.ADC. Architecturally it is at ADC parity — and one prior assumption is corrected here: Store runs database-per-service (Store_Catalog/Store_Sales/Store_Identity, each with its own dbo.OutboxMessages; the legacy single MMCAStore DB is retained read-only as an archive/rollback only), not a single shared database. Its tactical depth (Clean Architecture, DDD, CQRS, the decorator pipeline, soft-delete/audit, RowVersion concurrency) is inherited framework substance, enforced by 23 NetArchTest fitness-test classes (shared *TestsBase subclasses from MMCA.Common.Testing.Architecture plus Store-local guards such as DataResidencyTests, PiiConventionTests, and IntegrationEventContractTests, ADR-015; the compile-time layer-guard MSBuild target is MMCA.Common-internal and does not run here).

The two axes are asymmetric: Maturity 98.4% vs Implementation 83.6%. Implementation is the weaker axis by ~15 points, a wider gap than ADC's. The maturity is high because Store inherits the framework's governed mechanisms and adds a strong operational floor (two-phase Bicep IaC, OIDC + Key Vault managed identity, a post-deploy smoke gate with auto-rollback, a drilled DR restore, a cost-guard surge-drift check, a k6 load test, and now a chromium E2E/axe deploy gate at ADC parity). The former §21/§28 gate gap and the §23 catalog fetch-all are closed this cycle, and the §27 residual unlocalized strings were closed by the same-day i18n completion sweep (I7→8; zero literals, dual CI gates); the former §18/§19 review-only maturity gap closed on 2026-07-16 (both are now CI-enforced by the shared convention fitness gates at M4), and the same-day drift-fold closed §23 (the deploy-gated CWV budget assertions credited at M4, ADC parity); the 2026-07-17 re-score then closed §5 (slice cohesion CI-gated, the hybrid kept as an implementation cap), §13 (the alert-to-runbook pairing gate), and §22 (the three-engine gate flip verified live), leaving §12 (k6 not a merge gate) and §21 (screen-reader pass pending) as the only below-4 maturity categories. §14's former coverage gap is closed: the deploy-gating floor is 51.6 measured on Store's own code (+MMCA.Store.*;-*.Tests, ~54% actual). Supply-chain (§32): the vulnerability gate is NuGetAudit + TreatWarningsAsErrors at restore plus the gating suppress-aware audit, the SBOM is a hard gate, and all three CI restores run --locked-mode.

Front-end security is the standout (§26, impl 9): access token in-memory, refresh token in an HttpOnly cookie (no localStorage), a hardened origin-pinned CSP, and runtime-config fetch (no secrets in the bundle), confirmed at ADC parity. No category is N/A: §27 Internationalization is scored (M4/I9 after the 2026-07-03 completion sweep and the 2026-07-17 pseudo-loc layout-tolerance grant) since the ADR-027 en-US + es localization shipped with its CI-gated translation-completeness fitness function, superseding ADR-011's single-locale exclusion; the sweep added the LocalizedTextConventionTests literal gate and removed every residual hard-coded string.

Scorecard

Weighted = Maturity·weight / Implementation·weight. Axis-gap finding: §21 Accessibility is honestly M3/I8 (the chromium axe gate earns Implementation 8; Maturity caps at 3 pending a recorded manual screen-reader pass, matching ADC, D6); §13 is the mirror case resolved this cycle (M4/I9 after the pairing gate shipped). The widest remaining M-over-I gap is §20 (M4/I7, residual inline styles).

Indices

• Maturity index = Σ(maturity×weight) ÷ Σ(weight×4) = 315 ÷ 320 = 98.4% (2026-07-17 re-score: §5 M3→4, §13 M3→4, and §22 M3→4, +2 each at weight 2, 309→315; only §12 and §21 remain at maturity 3)
• Implementation index = Σ(impl×weight) ÷ Σ(weight×10) = 669 ÷ 800 = 83.6% (2026-07-17 re-score: §5 I7→8, +2 at weight 2, and §27 I8→9, +1 at weight 1, 666→669)
• Weaker axis: Implementation (execution quality), by ~15 points.
• No N/A categories: §27 joined the denominators this cycle (ADR-027 superseded ADR-011). §32 weight = 2 (default; raised to 3 only for the published framework MMCA.Common).

Top 5 strengths

1. Clean Architecture + DDD + CQRS depth, fitness-enforced: §3/§4 (impl 9): inherited framework substance, guarded by the shared NetArchTest suite (23 test classes, StoreArchitectureMap.cs:14-43).
2. Full microservices parity — §7 (impl 8): database-per-service + per-service outbox + versioned gRPC + MassTransit broker + RS256/JWKS, extractable modules (infra/main.bicep:396-418 per-service DBs, :445-474 Service Bus). (Corrects the prior "single shared DB" assumption.)
3. Exemplary DevOps / operational floor: §17 (impl 9) / §31 / §12: two-phase Bicep, OIDC + Key Vault MI, passwordless MI-SQL active in prod (2026-07-12), post-deploy smoke gate with auto-rollback (deploy.yml:461-518), cost-guard/dr-drill/load-test workflows.
4. Reference front-end security — §26 (impl 9): in-memory access token + HttpOnly refresh cookie (no localStorage), hardened origin-pinned CSP, runtime-config fetch (ServerTokenStorageService.cs:10-13, BlazorCspPolicyProvider.cs:71).
5. Drilled DR + real erasure path (§29 impl 9 / §30 impl 8): recorded 28.9-min restore (DISASTER-RECOVERY.md:146-148), the dr-freshness deploy gate + weekly cron + CI-gated GracefulShutdownTests, IAnonymizable anonymize-in-place + export + residency/PII fitness functions.

Top 5 risks

1. Accessibility maturity is capped pending a human pass: §21 (mat 3, weight 3): the 22-scan axe suite gates the deploy (impl 8), but the rubric pairs axe-in-CI with a recorded manual screen-reader pass and the ACCESSIBILITY-SCREENREADER-PASS.md results log is still empty (matching ADC's M3).
   • Remediation: record a dated NVDA/VoiceOver pass in the runbook against the running app (needs a human; cannot be done headless). Expected: §21 mat 3→4.
2. Load evidence is capacity-planning cadence, not a merge gate: §12 (mat 3): the k6 suite is real with pass/fail thresholds and a load-freshness deploy gate, but the test itself runs monthly/on-demand, so a latency regression can merge and deploy inside the freshness window.
   • Remediation: right-size deliberately: either accept the monthly cadence as the recorded posture (matching ADC's accepted §12 M3) or add a cheap latency-regression smoke to the merge path. Expected: decision recorded either way; §12 mat 3→4 only with a gate.
3. Design-system residual inline styles: §20 (impl 7, the widest M-over-I gap): the token convention is CI-enforced (BrandColorTokenTests), but MudBlazor Style=/CellStyle= parameter values that CSS isolation cannot target without a DOM-changing wrapper remain in cart/catalog markup (ProductList.razor:118).
   • Remediation: move the residual values behind semantic classes via wrapper elements or theme tokens where feasible. Expected: §20 impl 7→8.
4. Client validation short of server parity: §24 (impl 8): the four create forms' guard/dirty/validated-MudForm markers are CI-gated (FormsConventionTests, M4), but client validation stays MudForm-level rather than full FluentValidation parity with the server rules.
   • Remediation: mirror the remaining server-only rules client-side where they do not need the DB. Expected: §24 impl 8→9.
5. Concurrency seam residual [C→A]: the ADR-035 client half shipped (11 property-edit requests implement IConcurrencyAware, DTOs expose RowVersion, handlers call SetOriginalRowVersion, stale-token 409 integration-tested), but child-level entities (e.g. ProductVariant under Product) need a child-typed SetOriginalRowVersion overload in MMCA.Common before their edits get the same protection.
   • Remediation: add the aggregate-child overload in Common and sweep (lands in Common, both consumers in one pass). Expected: §8 evidence completes across child edits.

Cross-repo comparison

How Store relates to MMCA.Common (the framework) and MMCA.ADC (the sibling consumer) is maintained once, for all three repos, in ../Docs/Architecture/CrossRepoComparison.md.