Architecture governance

MMCA.Store: Architecture Remediation Backlog

Derived from ArchitectureScorecard.md: Maturity 97.5% (308/316) / Implementation 83.2% (657/790), evidence as of 2026-10-18 at MMCA.Common.* v1.244.0 (lockstep, HEAD b40baf14, clean tree). Items are ranked on both scorecard axes, one band per axis. The maturity band holds categories scoring maturity < 4, ranked by priority = (4 − maturity) × weight. The implementation band holds categories scoring implementation <= 8**, ranked by **implPriority = max(0, 9 − implementation) × weight**; the scheduling target is **9, not 10**, because a 10 is recognition earned at re-score time rather than scheduled work, and ranking against 10 would put nearly every strong category in the band and drown the real gaps. Ties break by weight descending, then category number. A category leaves each band independently and reaches the protect list only at **maturity 4 AND implementation >= 9; the indices keep their × 4 and × 10 denominators, and the 9-target governs scheduling only.

The scorecard is the source of truth for scores, ../MMCA.Common/FACTS.md for framework-wide facts, and the workspace-internal Docs/Architecture/ArchitectureRemediation.md (not published) for the cross-repo [C→A] roll-up. Tactical deferrals are recorded here as TD sub-items under their category (the single-ledger model). Status: [ ] open, [~] under way, [x] resolved.

Open work at a glance

Triage 2026-10-19. The S2 wave (Store #213, MMCA.Common v1.245.0) shipped the #10, #15, #17 (rollback report), #22 (phone viewport), #25 (Roles item) and #27 levers and corrected the SQL comment under #11; each is marked shipped below, with its score movement pending the next re-score. The Data Protection wrap of the cached Stripe secret was dropped by user decision. Every other open item was weighed for over-engineering: the ones closed are under Deliberate and accepted (Closed as over-engineering, 2026-10-19) and must not be re-proposed without new evidence. Scores are unchanged, so every row keeps its band position. Three items stayed open at triage: the seed-account check, the screen-reader pass (both need a human) and typed route parameters; the typed route parameters have since shipped (Store #214), so two remain.

Open items

• [closed] #11 Security, implementation 7: secret handling. Triage 2026-10-19: the stale SQL comment is corrected (Store #213), and protecting the cached signing secret is dropped by user decision, because the Sales host registers no shared Data Protection key ring, so a wrap would need key-ring infrastructure for one secret already guarded by Redis access (recorded under Deliberate and accepted). No scheduled work remains in this item. The original finding follows. Three red flags hold the row at 7. The Stripe webhook signing secret is cached in plaintext in the shared Redis with a 365-day lifetime (SharedCacheStripeWebhookSecretStore.cs:79, lifetime at :54); the registration service never prints it (StripeWebhookRegistrationService.cs:200-202). One shared identity is db_owner in all three databases (infra/SQL-MANAGED-IDENTITY.md:80), and every per-app Service Bus SAS rule carries Manage rights (infra/main.bicep:1069,1081,1093), kept because MassTransit creates the topology at runtime (:1052-1057); both are accepted at this scale (Deliberate and accepted below), so the signing-secret cache is the one red flag with scheduled work. A stale comment also says every service still connects with the SQL server administrator login although USE_MANAGED_IDENTITY_SQL=true (infra/main.bicep:869-870). The internal Customers gRPC edge requires a user or service token (Resolved below). Next: protect the cached signing secret, and correct the stale comment. Effort: S.
• #10 Messaging, maturity 3 / implementation 8: the broker error queue has no operating procedure. Shipped 2026-10-19 (Store #213): store-alert-broker-error-queue matches "moved to the error queue" (infra/main.bicep:510), infra/OPERATIONS.md:175 holds the inspect, replay and discard runbook, and the outbox runbook names all five consumer flows. The [EventName] rule is already required: Tests/Architecture/MMCA.Store.Architecture.Tests/Contracts/EventConventionTests.cs:3 subclasses Common's EventConventionTestsBase. The real-broker round-trips and the ProductVariantChanged ordering declaration are closed (Deliberate and accepted). Re-score pending. The original finding follows. The rubric requires a dead-letter path with an operational procedure: alert, inspect, replay or discard (ArchitectureEvaluationCriteria.md:336). The only messaging alert matches the outbox text "dead-lettered" (infra/main.bicep:462), while a consumer that exhausts its retries logs "moved to the error queue" (Common FaultIntegrationEventConsumer.cs:57), which no Store alert matches and no infra/*.bicep alert covers. infra/OPERATIONS.md has an outbox-row replay (:166) and no error-queue section, and ADR-087 records no alert, runbook or replay path for that queue (087-broker-poison-message-handling.md:202). Nothing requires [EventName] on every event: Common keys the contract by type name when the attribute is absent (ArchitectureRules.Events.cs:42), and all four Store events carry it by convention only. The same gap holds ADC's §10 at M3. Store-specific residuals: the dead-letter runbook names one live consumer flow where five run (OPERATIONS.md:164; the consumers are at Sales.Service/Program.cs:261 and Catalog.Service/Program.cs:274), CustomerErased and ProductInfoChanged have no real-broker round-trip test, and ProductVariantChanged declares no ordering expectation (IntegrationEventContractTests.cs:12), so a late redelivery could overwrite newer labels. Next: an alert-as-code on the error-queue log line or the broker metric, an OPERATIONS.md runbook with a replay-or-discard procedure, and a fitness rule requiring [EventName] (that rule is Common-side). Effort: S-M.
• #11 Security: rotate or remove the identity seed accounts created before the environment gate. Kept open on 2026-10-19: a weak-password admin account in production would be a live defect, and the check is a single query. The framework leaves the choice to the app: IdentityModuleDbSeederBase.ShouldSeed defaults to true (IdentityModuleDbSeederBase.cs:57), directly under a security notice saying the seed credentials are deliberately weak plaintext values and that deployed environments must disable seeding (:31-35). Store overrides it on Seeding:IncludeSampleUsers, default false (IdentityModuleSeeder.cs:28-30; the AppHost opts in at AppHost/Program.cs:194-195, the integration fixture at IdentityIntegrationTestFixture.cs:61,69, infra/main.bicep sets nothing, IdentityModuleSeederTests pins it), the same shape as ADC (MMCA.ADC.Identity.API/IdentityModuleSeeder.cs:22-30). The seeded set is an admin account plus a customer account with weak plaintext passwords, one of them a real personal address (MMCA.Store.Identity.Infrastructure/.../IdentityModuleDbSeeder.cs:23,37-38), and the per-account EmailExistsAsync probe (:45-52) skips an account that already exists. Next: check the deployed Store Identity database for accounts seeded by builds that predate the gate (Store PR #124) and rotate or remove them (user-side; not provable from the repo).
• [~] #21 Accessibility, maturity 3 → 4: record a dated manual screen-reader pass. The axe + Playwright suite gates the deploy (e2e-gate, chromium, workflow_call into e2e.yml, in deploy.yml's needs; UI-scoped and skippable, an accepted trade-off under Deliberate and accepted) with 32 axe scans over the public, shopper, and Catalog/Sales/Identity admin surfaces (AccessibilityTests.cs, dark-palette home scan at :495) plus the cart-drawer keyboard test (CartDrawerKeyboardTests.cs:21, on the shared KeyboardOperabilityTestsBase), which earns Implementation 8. The rubric pairs axe-in-CI with a recorded manual screen-reader pass: the store-ACCESSIBILITY-SCREENREADER-PASS.md runbook (Website docs-src/guides/) exists, but its results log holds only the placeholder row (:70, header :68-69). Next: a dated NVDA/VoiceOver pass against the running Aspire app (needs a human; cannot be done headless).
• #15 Best Practices & Code Quality, implementation 8 → 9: the MAUI head is outside CI analyzer enforcement. Shipped 2026-10-19 (Store #213): the weekly maui-audit.yml builds MMCA.Store.UI for net10.0-android in Release with analyzers and TreatWarningsAsErrors (.github/workflows/maui-audit.yml:198). Detection only, no per-PR leg. Re-score pending. The original finding follows. The MAUI head is in neither .slnf (MMCA.Store.CI.slnf:24-25 lists only UI.Web and UI.Web.Client; maui-audit.yml:17 and .editorconfig:841 say so), so its analyzers and TWAE run only in a full local solution build. Its vulnerability audit is covered by the weekly maui-audit.yml (:111-163). Next: put the MAUI head's analyzers and TWAE under a CI check.
• #17 DevOps & Deployment, implementation 8 → 9: the rollback covers only a failed activation. First half shipped 2026-10-19 (Store #213): the step prints a per-app outcome and a counted summary (deploy.yml:1521, :1529) and its comment matches the skip-live behavior (:1491). Probe-only rollback and a Bicep what-if are closed (Deliberate and accepted). Re-score pending. The original finding follows. The smoke step (deploy.yml:1355) skips every app whose newest revision is live (:1497), so a failure caught only by the tier-2 HTTP probes rolls nothing back, and the step still prints "All apps rolled back" (:1525); its comment says a healthy newest revision steps back one revision (:1487-1488), and under activeRevisionsMode: 'Single' (infra/main.bicep:1469) the predecessor is already inactive, so the active-revision filter (deploy.yml:1504) finds no candidate. ADR-080 keeps the skip-live guard and accepts single-revision mode; no rollback rehearsal is recorded. The other residuals: no Bicep build, lint or what-if before azure/arm-deploy (:1315-1317), a prod-only environment (:41), and SQL dual-auth with public network access (infra/main.bicep:831-835, deploy.yml:1146). Next: make the rollback summary report what it did and align the comment (Store-local, S); then decide whether a probe-only failure should roll back, and add a Bicep what-if step before merge. Effort: S-M.
• [closed] #20 Design System, implementation 8 → 9: the StoreHome palette (closed 2026-10-19, see Deliberate and accepted). The StoreHome landing stylesheet hard-codes a hex palette behind !important with only --mmca-primary tokenized (Catalog.UI/Pages/Home/StoreHome.razor.css:218,289; one stylesheet in Catalog.UI serves both hosts). Next: tokenize the palette onto the theme variables in that shared stylesheet, drop the !important overrides, and extend BrandColorTokenTests to the full literal set.
• [~] #22 Responsive & Cross-Browser, implementation 8 → 9: density and touch. The mobile-viewport half shipped 2026-10-19 (Store #213, Tests/E2E/MMCA.Store.E2E.Tests/Workflows/PhoneViewportTests.cs, in the chromium e2e-gate); the density toggle and coarse-pointer CSS are closed (Deliberate and accepted). Re-score pending. The original finding follows. Density is hard-coded Dense="true" with no comfortable/compact option (ProductList.razor:61, ReviewList.razor:57), and there is no coarse-pointer/touch-target CSS and no mobile-viewport E2E coverage (zero SetViewportSize hits under Tests/E2E). Common's DataGridListPageBase carries a DenseGrid toggle, so the density half is a Common-adoption task.
• #25 Navigation, implementation 8 → 9: the navigation doc has no test to catch drift. Triage 2026-10-19: the Roles menu item now names the Admin role its page requires (Store #213, pinned by Tests/Modules/Identity/MMCA.Store.Identity.UI.Tests/IdentityUIModuleTests.cs), and the full NavigationContractTests is closed (Deliberate and accepted). Shipped 2026-10-19 (Store #214): the eight detail routes are typed {Id:int} the way ADC's are (for example Source/Modules/Catalog/MMCA.Store.Catalog.UI/Pages/Products/ProductDetail.razor:1, with a typed int Id parameter at ProductDetail.razor.cs:27 in place of the Id.Parse<T>() coercion), so a malformed id answers with the router's not-found page; /roles/{Role} stays an untyped role name, as in ADC, and the store-NavigationFlow.md Route Contract rows now carry the constraint. Score movement is pending the next re-score. The original finding follows. store-NavigationFlow.md matches the shell: /users is listed as route-tested (:15, governed by IdentityRouteAuthorizationTests.cs:26-32), /orders/{Id} is [AllowAnonymous] (:66, :225, matching OrderDetail.razor:11), the notification pages are hidden (:236, UI.Web/appsettings.json:18), and a Route Contract table lists every routable Store page with its required access (:188). No Store test reads that contract (no *Navigation*Tests.cs under Tests/), so a new @page or a changed attribute can drift from the doc unnoticed. Two smaller residuals: route parameters are untyped (ProductDetail.razor.cs:28), and the Roles menu item is shown by capability (IdentityUIModule.cs:29-35) while /roles requires the Admin role (RoleList.razor:2). Next: add a Store NavigationContractTests that reads the Route Contract (store-NavigationFlow.md:188) and compares it with every @page route and its authorization attributes (the ADC pattern). Effort: M.
• #27 Internationalization, implementation 8 → 9: pluralization. Shipped 2026-10-19 (Store #213): ProductReviewsPanel.resx:9-10 and the CatalogBrowse rating label resolve through L.Plural with .One/.Other keys, and the dead (s) base keys are removed in en and es. Re-score pending. The original finding follows. Money formatting is culture-aware (MoneyExtensions.cs:54,90, inside the v1.244.0 pin at Directory.Packages.props:19). Common ships StringLocalizerPluralExtensions.cs:46 and the cart strings have .One/.Other keys, but ProductReviewsPanel.resx:9 and CatalogBrowse.resx:31 are single-form count keys ("(1 reviews)" renders at ProductReviewsPanel.razor:10), and single-form (s) keys survive in CartDrawer.resx:9 (Aria.ItemsInCart) and :22, CartButton.resx:7,10, CatalogProductDetail.resx:65 and ShoppingCartList.resx:11. Store-local, not [C→A].
• #18 UI Architecture & Components, implementation 8: create and detail forms share one field block. Shipped 2026-10-19 (Store #215): each create page and its detail page's inline editor render one field block bound to one abstract form model with create and edit subclasses, so the two forms cannot drift apart: CategoryFormFields over CategoryFormModel (Catalog.UI/Pages/Categories/CategoryCreate.razor:35, CategoryDetail.razor:42), ProductFormFields over ProductFormModel (Products/ProductCreate.razor:34, ProductDetail.razor:43) and CustomerFormFields over CustomerFormModel (Identity.UI/Pages/Customers/CustomerCreate.razor:27, CustomerDetail.razor:42). The detail editors validate through the model's DataAnnotations instead of page-local checks, and each block has a bUnit test (CategoryFormFieldsTests, ProductFormFieldsTests, CustomerFormFieldsTests). Re-score pending; the 400-line code-behind cap is unchanged.
• TD · #27: six Spanish count values drop the accent. Shipped 2026-10-19 (Store #213): the plural forms now carry the accent their base keys had. The original finding follows. The .One and .Other values in ShoppingCartList.es.resx:12-13, CartDrawer.es.resx:23-24 and the Aria.ItemsInCart.One/.Other pair at CartDrawer.es.resx:10-11 spell the noun without its accent while the base keys they pair with (ShoppingCartList.es.resx:11, CartDrawer.es.resx:9,22) keep it, so a Spanish shopper sees two spellings of the same word depending on the count. User-visible, Store-local. Blocker: none. Resolution path: correct the six resx values; TranslationCompletenessTests checks presence, not spelling, so add the accented form to the pseudo-loc leak probe only if this recurs. Effort: S.

Implementation band

22 categories, 54 gap points, the largest of the three repos. Levers are cited only where this ledger or the scorecard records one; an unnamed lever is named at the next re-score, never invented here. Ties break by priority desc, then weight desc, then category asc. The rows and levers below are as scored on 2026-10-18. After the 2026-10-19 triage, the #10, #15, #17 (rollback report), #22 (phone viewport) and #27 levers have shipped (Store #213, re-score pending); every row marked "not yet identified", and the #20, #22 (density, touch) and #25 (contract test) levers, are closed (Deliberate and accepted). The #25 typed routes have since shipped (Store #214, re-score pending), and so has the #18 field-block reuse (Store #215, re-score pending). The remaining scheduled work is the #11 seed-account check and the #21 screen-reader pass.

Maturity band

3 categories, 8 gap points. Ties break by priority desc, then weight desc, then category asc.

Deliberate and accepted

• Closed as over-engineering, 2026-10-19. Each was weighed against one developer and about 67 peak users; none has a defect behind it that an existing gate misses, so each would add permanent machinery for a score point. Do not re-propose without new evidence (a named re-open trigger, an incident, or an explicit ask).
  • #11 Data Protection wrap of the cached Stripe signing secret (user decision): the Sales host registers no shared key ring, so the wrap would first need key-ring infrastructure, for a secret whose only exposure is read access to Redis.
  • #10 real-broker round-trips for CustomerErased/ProductInfoChanged and an ordering declaration for ProductVariantChanged: the contract snapshot and the required [EventName] rule cover the wire-name failure; the ordering race is theoretical at this load.
  • #17 Bicep what-if before arm-deploy, and probe-only rollback: what-if needs Azure credentials in pull-request workflows, arm-deploy already fails on bad Bicep, and ADR-080 keeps skip-live.
  • #20 StoreHome palette tokenization: cosmetic; the dark-palette axe scan passes and the brand token is already guarded.
  • #22 density toggle and coarse-pointer touch-target CSS: no shopper need; the phone-viewport E2E now guards the shopper pages.
  • #25 full NavigationContractTests against the Website Route Contract: it protects a document and would make every route change wait on a Website PR; the route-authorization tests already gate every Admin page.
  • #28 port of ADC's ComponentsSnapshotTests: brittle on every MudBlazor bump.
  • #6 AddVariantHandler returning a failure on a refused schedule: the lever is wrong. The handler reports success on purpose, because a retry with a null SKU would create a duplicate variant.
  • Rows with no recorded lever (#18, #19, #23, #30, #31, #33): #18 is under the cap, which forces a split when due (the field-block reuse that has since shipped, Store #215, is recorded under Open items); #19's client cache was withdrawn after staleness failures; #23's product-image derivatives are a storage redesign while the browse CWV budgets pass; #30's consent capture has no processing that needs consent (no marketing mail); #31 and #33 are recorded postures below.
  • TD product-image derivatives (#12, #23): closed with #23 above. Re-open: a browse-page Web Vitals budget failure.
• §16 AI-Native Application Architecture is N/A (rubric v2, ADR-110): no product feature calls a language model, so its weight 2 leaves both denominators until one does.
• #5 layered-by-project hybrid. Cross-cutting concerns live in the pipeline and module projects keep a layered split; a deliberate design choice that caps §5 at Implementation 8, not a maturity deduction.
• Chromium-only deploy E2E gate (#22, #21): accepted CI-cost trade-off. The deploy-gating e2e-gate runs a single engine (job at deploy.yml:752, rationale :743-751, browsers: '["chromium"]' at :765); firefox and webkit run on the advisory schedule, one alternating engine per week (the browser matrix expression at e2e.yml:139-142, Monday firefox :140, Thursday webkit :141, crons :46-47, schedule-scoped continue-on-error at :149). The cross-browser-freshness gate bounds each engine's blind window at 10 days as a hard deploy condition (deploy.yml:857, :1084, :1114). Revisit if a webkit-only or firefox-only defect reaches production, which is the risk being priced. The UI-scoping of the gate is the separate entry below.
• UI-scoped e2e-gate (#21, #22, #28): accepted Actions-minute trade-off, next to the chromium-only entry. The e2e-gate job runs only when needs.changes.outputs.ui == 'true' (deploy.yml:762, job at :752, rationale comment :754-761, chromium-only input at :765), and the deploy job accepts it as success OR skipped (:1117, with e2e-gate in the deploy needs list at :1084). On a backend-only merge the 32 WCAG 2.1 AA axe scans (Tests/E2E/MMCA.Store.E2E.Tests/Workflows/AccessibilityTests.cs) and the Playwright workflow suite do not run. Backend tests precede every code deploy: the required build-and-test check runs the MMCA.Store.CI.slnf unit + architecture + bUnit tier (deploy.yml:255, test run at :338), branch protection enforces admins with strict up-to-date required checks, so the merged tree is the PR-tested tree, and the post-deploy smoke gate probes Catalog and Sales through the gateway. Revisit if a UI defect reaches production through a backend-only merge.
• TD · #22: the cross-browser-freshness gate is break-glass skippable. The gate proves a green firefox and webkit leg within 10 days (deploy.yml:873), not that this exact tree passes on those engines, and the skip_freshness_gates workflow_dispatch input (declared at deploy.yml:26) that also skips #12's load-freshness skips it with a justification (:880-881). Accepted as priced on the ADC precedent, whose row carries the identical caveat. Blocker: none; a per-change three-engine gate is the Actions-minute cost the chromium-only entry prices. Resolution path: none scheduled; revisit if a single-engine defect reaches production or the break-glass is used outside an incident. Effort: S (denying the skip is one if: change).
• #33 Service Bus emulator tier gates through recency. Tests/Integration/MMCA.Store.ServiceBusEmulator.IntegrationTests runs MassTransit v8 against the official Service Bus emulator (pinned 2.0.1) with the real ProductVariantChanged contract, and cross-service-freshness requires both it and the RabbitMQ tier to have succeeded in the same nightly run (the cross-service-freshness step of the freshness job, deploy.yml:826, required jobs :841-843, freshness in deploy needs at :1084). The tier needs Docker, so it stays out of both solution filters and reaches the deploy chain through the recency check rather than per PR. Mirrors ADC's TD-17; ADR-066 records the gated end state in both consumers.
• TD · Product-image derivatives (#12, #23): closed 2026-10-19. Images are full-size DB blobs streamed as-is and rendered as card thumbnails with no srcset/dimensions, so a 12-card browse grid can pull 12 full-size assets. Fixing it is a storage-design decision, not a local change; closed as over-engineering (above).
• Single-region deployment: accepted in infra/DISASTER-RECOVERY.md (real load does not justify multi-region cost).
• All per-service DBs on one physical SQL server: logical isolation is complete; the shared server is a cost choice (minor §7/§8).
• #7 lockstep deploy: per-service image parameters are not adopted. The deploy is one azure/arm-deploy of the whole main.bicep (deploy.yml:1317) with all five images on one IMAGE_SHA (:1145) and a whole-fleet rollback (:1481-1527). Splitting the image parameters per service would add permanent complexity to the deploy and rollback logic for a five-app, one-developer fleet, so the lockstep deploy is accepted and caps section 7 at Implementation 8. The build half stays per-image incremental (per-image dirty flags in the changes job, deploy.yml:80-218, matrix :956).
• #11 per-service database identities and Bicep-created Service Bus topology: not adopted. One shared identity is db_owner in all three databases (infra/SQL-MANAGED-IDENTITY.md:80) and every per-app SAS rule keeps Manage rights (infra/main.bicep:1069,1081,1093) because MassTransit creates the topology at runtime (:1052-1057). Pre-creating the topology in Bicep would make every new consumer a Bicep edit, and a missing subscription loses messages silently, so the shared identity and SAS Manage are accepted at this scale. They remain red flags on the section 11 row.
• #12 in-band k6 on every deploy, and a shopper script that writes to production: not adopted. Either would load production on every deploy at a peak of about 67 users. The monthly load-test.yml run (:21, dispatch at :12) plus the 35-day load-freshness deploy gate (deploy.yml:807, window :816) is the accepted posture, with the Web Vitals budgets asserted per deploy in the chromium e2e-gate; section 12 stays at Maturity 3 on it.
• #18 code-behind cap lowered to 300: not adopted. Lowering the cap would force about a dozen extractions at once; the cap stays at 400 (UIArchitectureConventionTests.cs:9), and only the files near 400 are candidates for extraction (ProductReviewsPanel.razor.cs at 389 lines is the largest).
• #31 scheduled revert of surge drift: not adopted. cost-guard stays read-only (cost-guard.yml:7, manual reset printed at :109), because a scheduled revert would act on production unwatched (schedule detection, never action). The guard still blocks the deploy on drift (deploy.yml:730,1113) and runs on the Monday cron (cost-guard.yml:21); it caps section 31 at Implementation 8, the same basis as ADC's.
• SQL public network access (no VNet): the documented acceptance behind the §17 cap, the same caveat ADC carries.
• ADR-042 device capability abstraction: latent. The core extension point is converged (Store wires browser + MAUI capabilities via UseMauiDeviceCapabilities/AddBrowserDeviceCapabilities and renders the shared OfflineBanner), but Store consumes no further capability in its own product UI: no ExternalLink, no DeviceUIModule/DeepLinkListener, no app actions. No Store product page carries an external anchor, so the WebView dead-end risk is latent, not a live defect. Adopt ExternalLink on any Store product page that grows an external anchor, and register a Store IUIModule with DeepLinkListener (the way ADC's DeviceUIModule does) if a Store MAUI feature surface is wanted. The framework side is complete in Common (18 capability contracts + the MMCA.Common.UI.Maui package), so this is consumer-side only, not [C→A].
• ADR-043 adoption (mobile deep links / app association / native OAuth callback): deferred. Adoption is feature-scale (Store-scheme deep links, iOS/Android manifest entries, associated domains) and rides the same trigger as ADR-042: adopt when a Store MAUI surface is actively wanted.
• ADR-044 adoption (native push, third notification channel): deferred. Store has no user-notification pipeline (no ADR-024 inbox, no SignalR channel), so adoption means adopting the whole notification stack first: a product decision, not remediation. Schedule only if Store wants user notifications.
• #14 dedicated rate-limit fixtures: skipped. The WAFs neutralize the limiter and a tight-limit variant is low value for the volume; revisit only if abuse is observed.
• #11 login throttle shared by Blazor Server circuits. The per-IP anti-spray throttle inherited from Common's AuthControllerBase counts every Server-circuit user against the UI host's IP (a 30/min window), because Blazor Server issues the login call server-side. Watch the 429 rate; tune with AddCommonRateLimiting(authIpPermitLimit: N).
• #1 constructor ceilings (services 6, controllers 8, handlers 7). Set in ConstructorDependencyCountTests.cs:35,53,71: AuthenticationService holds the service ceiling at 6 (AuthenticationService.cs:26-32), and three controllers sit at 8 (ShoppingCartsController.cs:51, ReviewsController.cs:55, ProductVariantsController.cs:37). The controller ceiling sits at the rubric's 8+ dependency red flag by recorded choice, which caps §1 at Implementation 8 the way the layered hybrid caps §5. The clock fitness rule carries one allowlist entry, the backfill-only Order.RepublishFulfillment (ClockReadTests.cs:18).
• #11 threat model: not maintained, by decision. No threat-model document is kept for Store, matching the Common backlog; §11 is scored on its other red flags, and a re-score does not add a threat-model item.
• #23 catalog trade-offs: price sorts fall back to Newest; search is Name-contains.
• #24 server-only and inline rules: SKU uniqueness stays server-only (it needs the DB); the Profile-form password fields stay inline by design, in both consumers.
• #24 full FluentValidation parity on the client: not adopted. All four create forms (CategoryCreate, ProductCreate, CustomerCreate, InventoryItemCreate) source their field rules from a DataAnnotations form model through Common's ModelValidation bridge, and the existing per-field parity is kept: email format (mirroring CustomerEmailRules' algorithm) on CustomerCreate and CustomerDetail, and NewPassword min-length/128-cap plus confirm-match on the Profile change-password form (localized en + es keys). Full parity would duplicate the server rule set, so it caps section 24 at Implementation 8.
• #19 silent cart initialization: CartStateService.InitializeAsync loads the cart without raising OnChange; initialization is silent and only user-visible mutations notify (pinned intended behavior).
• OrderDetail without [Authorize]: a recorded deliberate choice from the E2E gap review.

Resolved