Onboarding guide

29. Testing & Quality Infrastructure

What this group covers. Everything the codebase uses to prove itself: the six reusable test-support packages that ship out of MMCA.Common/Source/Hosting (MMCA.Common.Testing, MMCA.Common.Testing.Architecture, MMCA.Common.Testing.Aspire, MMCA.Common.Testing.Azure, MMCA.Common.Testing.E2E, MMCA.Common.Testing.UI, six of the twenty-six packages published from MMCA.Common and listed in MMCA.Common/FACTS.md:19-47; the seventh test-support package, MMCA.Common.AI.Testing, belongs to group-27), the architecture-fitness rule library that gates the build, the runtime-conformance bases that gate a booted host, the backend-less component Gallery harness, the BenchmarkDotNet performance suite, the weekly load tier, and the many per-repo test projects that consume all of it. The distinction to hold onto while reading: most of the types in this group are reusable bases, fixtures, harnesses, and helpers compiled into and shipped by MMCA.Common, while the concrete [Fact]-bearing test classes that subclass them live in each consumer repo (MMCA.Common.*.Tests, MMCA.ADC.*.Tests, MMCA.Store.*.Tests). Those individual test classes are cataloged by project in the companion rollup section; this chapter teaches the machinery they stand on. For how the tiers map onto CI jobs and solution filters, see Testing Architecture & Solution Composition.

There are seven moving parts. Five map onto the test pyramid, one is a governance layer, and one evaluates a dependency that is not deterministic and so cannot be asserted exactly:

1. Integration-test scaffolding (IIntegrationTestFixture, IntegrationTestBase<TFixture>, SqlServerIntegrationTestFixtureBase<TEntryPoint>, CrossServiceFixtureBase, CrossServiceHostIsolation, ProductionHostApplicationFactory<TEntryPoint>, JwtTokenGenerator, FeatureManagementTestExtensions, TestPolling, EntityBuilderBase<TBuilder, TEntity>) boots a real service host in-process against a throwaway SQL Server database and drives it over HTTP.
2. Architecture fitness functions (IArchitectureMap, ArchitectureMapBase, Layer, LayerRef, ArchitectureAssert, RuleHelpers, CrossEntityNavigationFinder, the forty-four ArchitectureRules partial files, and the sixty-four abstract *TestsBase classes including RouteAuthorizationTestsBase, ModuleConformanceTestsBase<TModule>, SubstitutabilityTestsBase, PiiInventoryTestsBase and BrandColorTokenTestsBase) turn architectural rules into build-gating assertions that run identically across every repo.
3. Component (bUnit) testing (BunitComponentTestBase, TestPrincipal, BunitInteractionExtensions, CapturingHttpMessageHandler, UiHttpServiceHarness, HttpTestDoubles, StubTokenStorageService, MarkupSnapshot, FieldErrorAccessibilityExtensions) render Blazor components in isolation with real MudBlazor services and faked HTTP/auth edges; the last of them asserts that a field's validation error reaches assistive technology, not just sighted users (a role="alert" element, aria-invalid="true" on the field, and an aria-describedby target holding the message, MMCA.Common.Testing.UI/Infrastructure/FieldErrorAccessibilityExtensions.cs:7-26).
4. End-to-end (Playwright) testing (PlaywrightFixture, E2ETestBase, E2ETestConfiguration, AuthOutcomeRules, PageExtensions, AxeOptions, AccessibilityViolationException, WebVitalsCollector, the reusable page objects LoginPage / RegisterPage / ProfilePage / ForgotPasswordPage / ResetPasswordPage / RoleAdminPage, the E2EPolling wait helper, and the shipped workflow suites such as AuthorizationTestsBase and KeyboardOperabilityTestsBase, whose four keyboard-only checks cover the skip link, the dialog focus trap, Escape returning focus to the opener, and a visible focus indicator on the leading Tab stops, MMCA.Common.Testing.E2E/Workflows/Accessibility/KeyboardOperabilityTestsBase.cs:11-29,41) drive a real browser against a running app, asserting accessibility and performance alongside behavior.
5. Contract and pipeline bases (SecurityHeadersTestsBase, OpenApiContractTestsBase<TFixture>, OpenApiBreakingChangeDetector, TenantResolutionTestsBase, ProblemDetailsContractTestsBase<TFixture>, ServiceInfoVersioningContractTestsBase<TFixture>, GracefulShutdownTestsBase<TEntryPoint>, DecoratorPipelineOrderTestsBase<TCommand, TCommandResult, TQuery, TQueryResult>, MiddlewarePipelineOrderTestsBase, DependencyInjectionAssert, HandlerTestBase<THandler>) pin cross-cutting HTTP and pipeline guarantees so a refactor cannot silently drop them.
6. Model-evaluation tests (GoldenCase, GoldenCorpus, GoldenReplayTests, LiveJudgeTests, PromptContractTests, SessionScoringPromptContractPinTests) hold ADC's AI session-scoring judge to a committed corpus of recorded cases, one half replayed offline on every CI leg and one half scored by the real model behind a trait gate.
7. Orchestration smoke tests (AppHostFixtureBase, AppHostTestBase<TFixture>, AppHostEnvironmentRequirement, AppHostEnvironmentGate, DockerAvailability, DeveloperCertificateAvailability, EphemeralRsaKeyPair, AppHostReadinessBudget, AppHostProbePaths, H2cProbe) boot a real Aspire AppHost once per collection and assert the orchestration every other tier boots past.

The cloud adapter packages of chapter 28 add a vendor dimension to that pyramid, and the group carries it in three layers. Each adapter package has a plain unit-test project (MMCA.Common.Aws.Tests, MMCA.Common.Azure.Tests, MMCA.Common.Gcp.Tests) that drives the adapter against in-process fakes such as FakeSecretsStore, FakeFcmMessagingClient and InMemoryGcsStorageClient, and each carries a CloudVendorRulesTests class of its own. Behind them sit the emulator tiers, each starting one pinned container per test assembly through an xUnit assembly fixture: LocalStackFixture for S3, SQS, SNS, Secrets Manager, Systems Manager and DynamoDB (MMCA.Common/Tests/Hosting/MMCA.Common.Aws.LocalStack.Tests/LocalStackFixture.cs:9,19), and FakeGcsServerFixture plus FirestoreEmulatorFixture for Cloud Storage and the FCM installation registry (MMCA.Common/Tests/Hosting/MMCA.Common.Gcp.Emulator.Tests/FakeGcsServerFixture.cs:7,18, FirestoreEmulatorFixture.cs:5,14). Each image is pinned so an upstream emulator change cannot turn into a red CI run nobody caused (LocalStackFixture.cs:14-17). The Azure Service Bus tier is the one that ships as a package: ServiceBusEmulatorFixtureBase (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Azure/Fixtures/ServiceBusEmulatorFixtureBase.cs:54) starts one warm emulator for the whole broker-parity tier to respect the emulator's connection quota and admin-plane throttle (:12-18), pins a 2.x image because the management plane MassTransit provisions its topology through first shipped in 2.0.0 (:20-27), keeps the bus on the fixture rather than on the per-test class so the topology is provisioned once per run (:29-38), and bounds both startup phases so a hang fails with a named timeout instead of being killed silently at the job timeout (:40-46). The third layer is the fitness rule that keeps the vendor SDKs out of the core: CloudVendorIsolationTestsBase (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Bases/Layering/CloudVendorIsolationTestsBase.cs:15) fails the build when an assembly a repo declares cloud-neutral names an Azure, AWS or Google Cloud SDK type, references a vendor SDK or broker-transport assembly, or references a vendor adapter package (:4-7, two facts at :27-33). It is the compiled-assembly half of the EnforceCloudVendorBoundary build guard, which judges only the declared package references, so a vendor type arriving through a transitive path is caught too (:9-12, ADR-134). MMCA.Common activates it in CloudVendorIsolationTests (MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/Layering/CloudVendorIsolationTests.cs:17).

This whole group is the [Rubric §14, Testability] story made concrete: the framework does not merely permit testing, it ships the reusable substrate so every consumer tests the same way. The front-end tiers additionally carry [Rubric §21, Accessibility], [Rubric §22, Responsive/Cross-Browser], [Rubric §23, Front-End Performance], and [Rubric §28, Front-End Testing]; the fitness library carries [Rubric §34, Architecture Governance & Documentation]. Two ADRs govern the two governance tiers and are worth reading before touching anything here: ADR-015 for the structural rules, and ADR-058 for the runtime conformance suites that cover exactly what ADR-015 declared out of scope: "the tests assert structure / registration, not runtime behavior" (Website/docs-src/adr/015-architecture-fitness-functions.md:64-65).

Integration tests: a real host, a throwaway database, a per-test reset

The integration tier boots the actual application, not a mock of it. The abstraction at its center is IIntegrationTestFixture (MMCA.Common.Testing/Fixtures/IIntegrationTestFixture.cs:8): a two-method contract, CreateClient() (IIntegrationTestFixture.cs:11) and ResetDatabaseAsync() (IIntegrationTestFixture.cs:19), that hides how the host and its database are provisioned. Its remarks are load-bearing: a host running multiple physical data sources (database per service, see primer and ADR-006) must reset every relational source, and a fixture can resolve IEntityDataSourceRegistry / IDataSourceResolver from the booted host to enumerate them (IIntegrationTestFixture.cs:13-18).

IntegrationTestBase<TFixture> (MMCA.Common.Testing/Fixtures/IntegrationTestBase.cs:13) is the per-test base every integration test class inherits. It implements xUnit's IAsyncLifetime, so InitializeAsync resets the database before each test (IntegrationTestBase.cs:31) and DisposeAsync disposes the HTTP client after (IntegrationTestBase.cs:34-39). It exposes typed HTTP helpers (GetAsync<T>, PostAsync<T>, PutAsync<T>, PutAsync, DeleteAsync, IntegrationTestBase.cs:51-72), bearer-token management (SetBearerToken / ClearAuthentication, IntegrationTestBase.cs:42-48), and a thread-safe NextId() counter seeded at 1000 (IntegrationTestBase.cs:16,75) so parallel tests never collide on generated identifiers. Downstream projects subclass it to add domain-specific auth and entity helpers.

SqlServerIntegrationTestFixtureBase<TEntryPoint> (MMCA.Common.Testing/Fixtures/SqlServerIntegrationTestFixtureBase.cs:27) is the concrete fixture scaffolding. InitializeAsync (SqlServerIntegrationTestFixtureBase.cs:67) mints a GUID-suffixed database name (:71-72), sets ASPNETCORE_ENVIRONMENT=Testing and the top-level connection string as process environment variables (so the host reads them at configure-time, :75-77), builds the subclass-supplied WebApplicationFactory (:79), and forces database creation by requesting the first client, which runs the host's Migrate init strategy (:87-89). The "may need dropping" flag is set before that first client (:81-85), and the drop is guarded by IF DB_ID(...) (:186-188), so a host that fails after its migration created the database still has it dropped rather than leaked on the shared server. It then builds a Respawn checkpoint that ignores __EFMigrationsHistory (:95-99); ResetDatabaseAsync (:104) replays that checkpoint between tests, and DisposeAsync (:120) drops the throwaway database (:130-133, DropDatabaseAsync at :172) and restores every pushed environment variable (:135, restore loop at :162-170, first-value-wins bookkeeping at :151-160 so a re-pushed key cannot clobber its own restore point). The Testing environment is chosen deliberately so appsettings.Development.json (which points a module's DataSources entry at localhost) does not load, leaving the resolver to collapse onto the overridden top-level connection string, a single-database monolith shape (:16-24). Server selection defaults to LocalDB but is overridable through SqlBaseEnvironmentVariable (:58, read at :69-70) so CI can target a SQL service container. Subclasses push their own host-specific settings (test JWT key material, throttle lifts, faked gRPC edges) through the ConfigureTestEnvironment hook (:147, invoked at :77), which routes them through the same restore bookkeeping. The fixture also exposes ConnectionString (:45) so SQL-fidelity tests can read the raw tables, and Services (:52) so a cross-service test can resolve a consumer-side handler out of the booted host. Because these fixtures need a reachable SQL Server, the per-module *.Integration.slnf suites build in a headless sandbox but only run in CI.

One tier up sits CrossServiceFixtureBase (MMCA.Common.Testing/Fixtures/CrossServiceFixtureBase.cs:47), which boots several hosts in one process against a real Testcontainers SQL Server and a real Testcontainers RabbitMQ (CrossServiceFixtureBase.cs:2-3,18-25), so the genuine outbox to broker to consumer round-trip is exercised rather than faked. Each logical source it routes is a CrossServiceDataSource record pairing the config key with its physical database (CrossServiceFixtureBase.cs:15, list supplied by the subclass at :60). The design note worth internalizing is why the hosts must boot strictly sequentially: every host reads its connection string, MessageBus settings and JWT settings from configuration at configure-time, before builder.Build(), so process environment variables are the only override channel that lands in time, and the one genuinely per-host key is the SQL connection string (CrossServiceFixtureBase.cs:26-39). A booted host has already snapshotted its connection, so mutating the environment for the next one is safe. Two smaller decisions in the same file are worth knowing because they are non-obvious: the databases are pre-created before any host boots, since EF's CREATE DATABASE runs before its migration lock is taken and a double-booted host would race itself (CrossServiceFixtureBase.cs:107-111), and each module is routed to a named data source whose connection string differs only by Application Name, so EF's process-global model cache keys each host's model separately instead of letting the first booted host win (CrossServiceFixtureBase.cs:231-246,260-276). Booting several hosts in one process has a second trap that the model-cache keying does not close: the default entity-configuration assembly provider scans AppDomain.GetAssemblies, so each host would see its peers' module assemblies, claim their data sources, and let its outbox and internal-command processors drain the peer databases, dead-lettering a row as handler_missing when only the peer holds its handler (MMCA.Common.Testing/Fixtures/CrossServiceHostIsolation.cs:14-21). CrossServiceHostIsolation (CrossServiceHostIsolation.cs:30) closes it with one extension member, IsolateCrossServiceHost<TEntryPoint>() (:42), which every host factory of a CrossServiceFixtureBase subclass calls from ConfigureTestServices: it replaces the registered provider with a private decorator, HostScopedAssemblyProvider (:115-118), that narrows the inner result to the assemblies the host's own .deps.json names (the set it would load in its own process) and keeps explicitly registered AdditionalAssemblies unfiltered (:23-28,47-59), and it throws when that .deps.json is missing rather than silently scanning everything (:86-91). ADC's four cross-service factories each make that call (MMCA.ADC/Tests/Integration/MMCA.ADC.CrossService.IntegrationTests/Infrastructure/ConferenceCrossServiceFactory.cs:46, and the Identity, Engagement and Notification siblings at IdentityCrossServiceFactory.cs:40, EngagementCrossServiceFactory.cs:55, NotificationCrossServiceFactory.cs:56). A host that needs no database at all gets the much smaller boot path: ProductionHostApplicationFactory<TEntryPoint> (MMCA.Common.Testing/Fixtures/ProductionHostApplicationFactory.cs:23) pins UseEnvironment("Production") (ProductionHostApplicationFactory.cs:36) so the production-only branches (restrictive CORS, HSTS emission) are the ones under test, and captures the started IHost (ProductionHostApplicationFactory.cs:29) because StopAsync is not reachable through the WebApplicationFactory surface at all.

Four helpers round out the tier. JwtTokenGenerator (MMCA.Common.Testing/Support/JwtTokenGenerator.cs:30) issues RS256-signed tokens (GenerateToken, JwtTokenGenerator.cs:112, signing credentials built at :130-131) using an embedded development RSA keypair (DefaultPublicKeyPem at :49, DefaultPrivateKeyPem at :68) under a fixed kid of mmca-test-key (:41), so integration tests exercise the exact JWKS/RS256 validation code path production runs (ADR-004); its ConfigureInProcessTokenValidation (:170) is what a test factory calls to re-point a host's JwtBearerOptions at that committed key instead of a network authority (it nulls both Authority and ConfigurationManager, :174-175). The class remarks flag, correctly, that the committed keypair is insecure by design and must never be used in a real deployment (:22-28). FeatureManagementTestExtensions (MMCA.Common.Testing/Support/FeatureManagementTestExtensions.cs:10) adds a ConfigureTestFeatureFlags extension member (:35) that layers an in-memory FeatureManagement:* collection on top of the configuration the host already registered and re-registers the merged root in its place (:40-59); building a flags-only root instead would silently hand every component constructed afterwards a configuration with nothing but feature flags in it, because .NET DI resolves a non-collection dependency to the last registration (:18-25). TestPolling (MMCA.Common.Testing/Support/TestPolling.cs:9) replaces the pre-assert sleep that eventually-consistent paths tempt you into: PollUntilAsync (TestPolling.cs:22) probes until the condition holds or a 60-second budget expires at a 500 ms interval (TestPolling.cs:31-32) and returns the last probed value either way, so a timeout still fails on the real assertion message. EntityBuilderBase<TBuilder, TEntity> (MMCA.Common.Testing/Builders/EntityBuilderBase.cs:9) is a minimal fluent-builder base whose single abstract Build() (:17) returns the entity through its domain factory, so test setup specifies only what a test cares about. Together these embody [Rubric §11, Security] (real token validation rather than bypassed auth middleware) and [Rubric §14, Testability].

Orchestration smoke tests: booting a real AppHost

Every tier above boots hosts directly, which means none of them ever runs the file that states how a whole stack fits together. The AppHost declares the project resources, the per-service databases, the broker, the JWKS and gRPC references and the WaitFor graph, and nothing else compiles a claim about any of it: a build type-checks its C# but never executes it, and the integration tier boots each host through WebApplicationFactory, bypassing the orchestration entirely (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Aspire/Fixtures/AppHostFixtureBase.cs:16-20, Website/docs-src/adr/117-apphost-integration-test-base.md:13-21). MMCA.Common.Testing.Aspire is the tier that closes that gap, shipped as one of the five test-support packages rather than copied per repo (ADR-117, accepted 2026-09-09 and revised 2026-09-11 once both consumer tiers subclassed it, Website/docs-src/adr/117-apphost-integration-test-base.md:3-10), and it adds the tier ADR-098 deliberately left out.

AppHostFixtureBase (MMCA.Common.Testing.Aspire/Fixtures/AppHostFixtureBase.cs:41) is the xUnit collection fixture: it boots a real AppHost once and hands the running DistributedApplication to every test in the collection. Its central distinction is readiness rather than liveness, per resource. "The application started" only means the orchestrator launched the processes, so resources carrying a health check are awaited healthy while resources carrying none can only be awaited Running, and the fixture says which of the two happened instead of pretending they are the same (AppHostFixtureBase.cs:22-28). Like the SQL fixtures it records only the first original value of every environment variable it pushes, so a re-pushed key cannot clobber its own restore point and a collection cannot leak key material into the ones that run after it (AppHostFixtureBase.cs:43-48). An unmet precondition is a skip, not a failure: the gate sets SkipReason and nothing is started (AppHostFixtureBase.cs:56, IsAvailable at :59), and the consuming project owns the skip call, because this package deliberately takes no dependency on the xUnit assertion library (AppHostFixtureBase.cs:29-34). The call is written as a branch, if (!Fixture.IsAvailable) { Assert.Skip(Fixture.SkipReason!); }, never as Assert.SkipWhen(!Fixture.IsAvailable, Fixture.SkipReason!): SkipWhen validates its reason before the condition, and the reason is null exactly when the stack did start, so that form throws on every runner able to boot the AppHost (AppHostFixtureBase.cs:34-38).

What counts as a precondition is declared, not guessed. AppHostEnvironmentRequirement (MMCA.Common.Testing.Aspire/Preconditions/AppHostEnvironmentRequirement.cs:10) is a [Flags] enum of None, OptIn, Docker and DeveloperCertificate (:12-30), and AppHostEnvironmentGate (MMCA.Common.Testing.Aspire/Preconditions/AppHostEnvironmentGate.cs:9) turns the missing ones into a sentence a human can act on, or null to run (AppHostEnvironmentGate.cs:23-27, with a testable core that takes every machine fact as a delegate at :38-42). The opt-in is the MMCA_APPHOST_TESTS variable (AppHostEnvironmentGate.cs:16), absent by default so an ordinary unit loop never starts an orchestrator (:12-14). The other two probes encode failures that cost real debugging time. DockerAvailability (MMCA.Common.Testing.Aspire/Preconditions/DockerAvailability.cs:13) checks DOCKER_HOST, the /var/run/docker.sock socket and the docker_engine named pipe (DockerAvailability.cs:16,19,22) rather than shelling out to docker info, because a process launch that can block for seconds on a misconfigured daemon is the wrong thing to put in front of a skip decision (DockerAvailability.cs:6-11). DeveloperCertificateAvailability (MMCA.Common.Testing.Aspire/Preconditions/DeveloperCertificateAvailability.cs:22) detects the ASP.NET Core HTTPS development certificate by the SDK's own extension OID 1.3.6.1.4.1.311.84.1.1 (:28, validity judged at :44-52) and detects only, never running dotnet dev-certs (:15-20): without that certificate an https resource answers its probe with UntrustedRoot, never turns healthy, and every WaitFor edge into it waits out the whole budget, so the symptom is a timeout on an unrelated resource (:7-14). EphemeralRsaKeyPair (MMCA.Common.Testing.Aspire/Preconditions/EphemeralRsaKeyPair.cs:20) closes the matching auth-side failure: it mints a throwaway RSA-2048 keypair (:38,42-46) into E2E_JWT_PRIVATE_KEY_PEM and E2E_JWT_PUBLIC_KEY_PEM (:26,32), the variables the framework's WithE2eRsaKeys() AppHost extension forwards to an Identity resource, because otherwise the appsettings.json placeholder reaches the JwtBearer options factory, which throws on the first request, so every request including the liveness probe answers 500 and the resource never turns healthy (:8-16).

Timing and probing are the remaining pieces. AppHostReadinessBudget (MMCA.Common.Testing.Aspire/Fixtures/AppHostReadinessBudget.cs:16) splits the wait into a startup budget and a readiness budget, five minutes each by default (:23-24), because the two fail for different reasons (a cold agent pulling container images versus a wedged health check) and one number makes those indistinguishable in the failure message (:6-11); Remaining(elapsed) (:37-38) keeps readiness a single shared deadline rather than a per-resource allowance, so a stack that wedges on the last of five resources still says so once (:28-33), and Validate (:45-49) rejects a non-positive budget that would cancel its own first wait. AppHostProbePaths (MMCA.Common.Testing.Aspire/Probes/AppHostProbePaths.cs:15) pins the paths a probe uses, /health (:18), /alive (:26), /health/ready (:32), the key set at /.well-known/jwks.json (:35) and the cleartext endpoint name http (:41); it mirrors the framework constants instead of referencing them, with a unit test in MMCA.Common.Testing.Aspire.Tests cross-asserting each pair so a rename cannot silently orphan a probe (:5-13). Its /alive remark carries the operational lesson: gate a startup wait on liveness, never on readiness, because a readiness endpoint aggregates downstream and warm-up checks and a gateway waiting for a service whose own readiness warms up through that gateway deadlocks (:20-25). H2cProbe (MMCA.Common.Testing.Aspire/Probes/H2cProbe.cs:25) asserts that a service's cleartext listener really speaks the protocol its gRPC callers need: with no TLS there is no ALPN to negotiate with, so the request goes out as HTTP/2 with prior knowledge pinned by RequestVersionExact and an HTTP/1.1-only listener answers with a connection error rather than a response (:9-16), under a deliberately short ten-second budget (:28); its keep-alive ping trio (one-second delay, one-second timeout, Always, :30-36) is load-bearing rather than tuning, because HTTP/2 pools one connection per origin and a connection accepted but never answered would otherwise queue every later probe behind it forever (:17-23). On top of all of it, AppHostTestBase<TFixture> (MMCA.Common.Testing.Aspire/Fixtures/AppHostTestBase.cs:29) gives a test the two things only a running application can supply, an HttpClient bound to a named resource endpoint (:44-45) and a resolved connection string (:54-55), plus an RS256 bearer token the booted stack accepts (:57-58). The package tests itself both ways: unit tests over the gates, budgets and probes in MMCA.Common.Testing.Aspire.Tests, and a real boot in MMCA.Common.Testing.Aspire.AppHostTests, where SampleAppHostFixture (MMCA.Common/Tests/Hosting/MMCA.Common.Testing.Aspire.AppHostTests/SampleAppHostFixture.cs:13), SampleAppHostCollection (SampleAppHostCollection.cs:9) and SampleAppHostTests (SampleAppHostTests.cs:21) exercise the fixture against a minimal AppHost. This tier is [Rubric §14, Testability] pointed at the one file every other tier looks past.

Architecture fitness functions: rules that gate the build

The layering and DDD conventions this codebase commits to are not left to code review, they are executed as tests. The reusable rule library lives in MMCA.Common.Testing.Architecture and is the subject of ADR-015. Its keystone is IArchitectureMap (MMCA.Common.Testing.Architecture/IArchitectureMap.cs:39): the single per-repo boundary every fitness function keys off. Each repo supplies one implementation (for example StoreArchitectureMap) declaring its layer and module assemblies as LayerRef records (IArchitectureMap.cs:31) tagged by the Layer enum (IArchitectureMap.cs:9), and exposes them through query members such as OfLayer, ModuleDomain, ModuleApplication, For, ModuleOf, and OtherModuleNamespaces (IArchitectureMap.cs:51-81). Most of that surface is derived rather than hand-written: ArchitectureMapBase (MMCA.Common.Testing.Architecture/ArchitectureMapBase.cs:11) computes the projections from a single DefineLayers() declaration (ArchitectureMapBase.cs:22, lazily materialized at :13,15-16,25), which also centralizes every assembly and namespace string in one file so Ubuntu CI's case sensitivity is handled in one place (ArchitectureMapBase.cs:8-9); it additionally ships a FindRepoRoot(solutionFileName) walker (ArchitectureMapBase.cs:79) so doc- and config-consistency rules can read committed files no matter what the runner's working directory is. The shared rules consume only the interface, which is why one rule body runs identically across MMCA.Common, MMCA.Store, MMCA.ADC, and Helpdesk: the map is the only thing that varies. Layer deliberately includes optional layers (Ui, Grpc, Contracts, ServiceHost, IArchitectureMap.cs:16-19) that a repo simply omits, so a rule iterating them is vacuously satisfied with no compile dependency on an absent assembly (IArchitectureMap.cs:3-7).

The rule bodies are split across forty-four ArchitectureRules partial files (AI model boundary, anonymization, cancellation tokens, cascade soft-delete, clock reads, cloud vendors, command validators, contracts, controllers, cycles, delete behavior, domain-event handler saves, domain throws, entities, error catalog, events, feature flags, folder width, forwarded JWT audiences, governance, handlers, handler results, idempotency, immutability, inline styles, integration-event purity, layers, lifetime tokens, localization, localized text, markup, modules, naming, PII inventory, protos, purity, query-handler repositories, slices, soft delete, specifications, strongly typed ids, substitutability, transport, and upcasters; the partial type is declared in the first of them at MMCA.Common.Testing.Architecture/Rules/Cqrs/ArchitectureRules.CancellationTokens.cs:5). The aggregate-convention rules live inside ArchitectureRules.Entities.cs (for example DomainExposesAggregateRoots at MMCA.Common.Testing.Architecture/Rules/Domain/ArchitectureRules.Entities.cs:8, AggregateRootsHaveResultFactory at :19, and the generalized DomainFactoriesReturnResult at :53 that extends the "factories always return Result<T>" convention from aggregate roots to value objects) rather than in a dedicated partial, and are surfaced through AggregateConventionTestsBase (MMCA.Common.Testing.Architecture/Bases/Domain/AggregateConventionTestsBase.cs:10). Above the rules sit the abstract *TestsBase classes under Bases/, sixty-four today (MMCA.Common/FACTS.md:89: LayerDependencyTestsBase, DomainPurityTestsBase, MicroserviceExtractionTestsBase, ModuleIsolationTestsBase, PiiConventionTestsBase, DependencyVersionTestsBase, IntegrationEventContractTestsBase, DataResidencyTestsBase, RawQueryableConventionTestsBase, and more), each exposing its rules as [Fact]s that a sealed per-repo subclass activates by supplying its map. Five of the newest carry the pattern into areas that used to be review questions: AiDependencyIsolationTestsBase (MMCA.Common.Testing.Architecture/Bases/Layering/AiDependencyIsolationTestsBase.cs:19) confines a language-model dependency to Infrastructure and the governed MMCA.Common.AI package in both directions, so a vendor SDK reference and a PromptContract used as a domain type both fail (AiDependencyIsolationTestsBase.cs:3-13, [Rubric §16, AI-Native]); DeleteBehaviorConventionTestsBase (Bases/Domain/DeleteBehaviorConventionTestsBase.cs:21) reads the MMCA:DeleteBehaviorSource stamp the framework's RestrictDeleteByDefaultConvention leaves on every foreign key back off a finalized EF Core model, so nothing cascades unless a configuration said so, asserted against an in-memory relational model with no server needed (DeleteBehaviorConventionTestsBase.cs:3-19); FeatureFlagLifecycleTestsBase (Bases/Governance/FeatureFlagLifecycleTestsBase.cs:10) makes every flag constant declare whether it is a permanent capability switch or a temporary rollout toggle and fails the build once a temporary one is past its RemoveBy date, with the judging date overridable so a release, not the build clock, decides (FeatureFlagLifecycleTestsBase.cs:3-9,14-18, ADR-031); IntegrationEventPayloadPurityTestsBase (Bases/Contracts/IntegrationEventPayloadPurityTestsBase.cs:33) requires an integration event to ship from a *.Shared assembly and no property on its wire shape to reach a *.Domain type, nested payload records included (IntegrationEventPayloadPurityTestsBase.cs:3-26, ADR-010); and RawSqlConventionTestsBase (Bases/Cqrs/RawSqlConventionTestsBase.cs:31) bans FromSqlRaw, SqlQueryRaw, ExecuteSqlRaw and ExecuteSqlRawAsync in module code while leaving the interpolated siblings and the framework's IRawSqlQueryExecutor allowed, because the raw four take a plain string, so a concatenated value compiles and every distinct value produces its own statement text (RawSqlConventionTestsBase.cs:5-26). A sixth, StronglyTypedIdTestsBase (Bases/Domain/StronglyTypedIdTestsBase.cs:9), is vacuously satisfied in every repo today: the primitive identifier aliases remain the default identifier model, and the base exists so the first wrapper a repo declares is held to the shape the framework's converters, comparer and route binding are written against (StronglyTypedIdTestsBase.cs:3-8, ADR-115). Two more pin a testability property and a read/write boundary: ClockReadTestsBase (Bases/Domain/ClockReadTestsBase.cs:15) fails when Domain or Application code reads DateTime.UtcNow, DateTime.Now or their DateTimeOffset siblings, so a handler injects TimeProvider and passes the instant in, with BaseDomainEvent's occurrence stamp always exempt and a reviewed AllowedClockReaders list for the deliberate cases (ClockReadTestsBase.cs:3-12,23, the rule at Rules/Domain/ArchitectureRules.ClockReads.cs:55); and QueryHandlerReadRepositoryTestsBase (Bases/Cqrs/QueryHandlerReadRepositoryTestsBase.cs:15) reads the IL of every IQueryHandler<,>, async and lambda bodies included, and fails any that calls IUnitOfWork.GetRepository instead of GetReadRepository, because the write repository hands a query a mutation surface it must not use (QueryHandlerReadRepositoryTestsBase.cs:3-13, the rule at Rules/Cqrs/ArchitectureRules.QueryHandlerRepositories.cs:37). ADC activates both with one-line sealed subclasses (MMCA.ADC/Tests/Architecture/MMCA.ADC.Architecture.Tests/Domain/ClockReadTests.cs:8, MMCA.ADC/Tests/Architecture/MMCA.ADC.Architecture.Tests/Cqrs/QueryHandlerReadRepositoryTests.cs:9). AggregateConventionTestsBase shows the shape in miniature: one abstract Map property and one [Fact] per rule (MMCA.Common.Testing.Architecture/Bases/Domain/AggregateConventionTestsBase.cs:12-24). How many fitness methods the package ships, and how many of them MMCA.Common's own build executes, is a generated and CI-gated number in MMCA.Common/FACTS.md:80-85: read it there rather than restating it anywhere else.

Failures report through ArchitectureAssert (MMCA.Common.Testing.Architecture/ArchitectureAssert.cs:8), which has two overloads: one lists the failing types from a NetArchTest TestResult (ArchitectureAssert.cs:11-23), the other lists a reflection-derived violation set (ArchitectureAssert.cs:26-32). Rules NetArchTest cannot express (method return types, generic constraints, property accessors, attribute usage) reflect over loaded types via the internal RuleHelpers (MMCA.Common.Testing.Architecture/RuleHelpers.cs:14), whose LoadableTypes extension property tolerates a partially resolvable assembly by falling back to the ReflectionTypeLoadException's resolved types (RuleHelpers.cs:19-33), and whose HasPublicMutableSetter treats an init-only setter as immutable by checking for the IsExternalInit required modifier (RuleHelpers.cs:121-137). One such walk, CrossEntityNavigationFinder (MMCA.Common.Testing.Architecture/Rules/Domain/ArchitectureRules.Specifications.cs:97), is an ExpressionVisitor that collects the entity types a specification's criteria navigates to beyond its own (ArchitectureRules.Specifications.cs:101-119), because in a polyglot setup that navigation may cross a physical data source where the join is not translatable (ArchitectureRules.Specifications.cs:9-15). These runtime rules are the second of two enforcement layers, the first being the compile-time MSBuild layer guard (MMCA.Common/Source/Build/MMCA.Common.LayerEnforcement.targets, see group 14); ADR-015 describes both, and this is the clearest [Rubric §34, Architecture Governance] expression in the codebase.

The fitness library reaches beyond pure layering into cross-cutting product guarantees. RouteAuthorizationTestsBase (MMCA.Common.Testing.Architecture/Bases/Api/RouteAuthorizationTestsBase.cs:22, tagged rubric §25 in its own remarks, [Rubric §25, Navigation & IA]) reflects over routable Blazor pages and asserts every governed page keeps its [Authorize(Roles = "...")] gate (RouteAuthorizationTestsBase.cs:49-61), so an admin route cannot regress to a bare [Authorize] any authenticated user can reach. It detects RouteAttribute and AuthorizeAttribute by full-name reflection (RouteAuthorizationTestsBase.cs:24-25) so the package stays free of ASP.NET references, and a MinimumGovernedPages floor (:47, asserted at :63-74) guards against a moved namespace silently emptying the scan. ModuleConformanceTestsBase<TModule> (MMCA.Common.Testing.Architecture/Bases/Layering/ModuleConformanceTestsBase.cs:21) pins the three-member contract ModuleLoader actually registers on (Name, Dependencies, RequiresDependencies), because drift in any of them does not throw, it silently reorders registration or swaps a real service for a disabled stub (ModuleConformanceTestsBase.cs:3-10); it reads those members through the IModule full name by reflection (:24) so the package stays free of the framework's transitive graph and still dispatches to the interface's default implementations (:12-17). BrandColorTokenTestsBase (MMCA.Common.Testing.Architecture/Bases/Ui/BrandColorTokenTestsBase.cs:13, [Rubric §20, Design System & Theming]) reads landing-page stylesheets embedded as manifest resources and fails the build if a host re-hardcodes the brand hex #1565C0 instead of sourcing var(--mmca-primary) from the shared token (BrandColorTokenTestsBase.cs:15-16,41-49), with a non-empty check on the embedded list so the guard cannot pass vacuously (:27-28). DependencyVersionTestsBase (MMCA.Common.Testing.Architecture/Bases/Governance/DependencyVersionTestsBase.cs:16, [Rubric §32, Dependency & Supply-Chain]) checks the repo's pinned package majors and fails the build on the MassTransit commercial-license trap a blanket package bump would otherwise walk into unnoticed: any of the five MassTransit packages it lists (DependencyVersionTestsBase.cs:18-25) at major 9 or above (:27-40, ADR-016), a failure CI would never see on its own because no CI leg starts a broker (:4-6). A consumer that pins only some of those packages overrides the list rather than inheriting it (:7-14). ConstructorDependencyCountTestsBase (Bases/Cqrs/ConstructorDependencyCountTestsBase.cs:20) turns the SRP judgement call into three numeric ceilings, one each for Application *Service facades, API controllers and CQRS handlers (MaxConstructorDependencies, MaxControllerConstructorDependencies, MaxHandlerConstructorDependencies at :34,41,49), each a ratchet a consumer sets at its current high-water mark rather than a budget (:14-16, [Rubric §1, SOLID]), with its own non-vacuity guard so a scan that finds no services fails rather than passes (Bases/Cqrs/ConstructorDependencyCountTestsBase.cs:60-61). ConstructorDependencyCountTestsBaseTests (MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/Cqrs/ConstructorDependencyCountTestsBaseTests.cs:14) proves the two newer populations actually fail on drift and name the offender, driving private subclasses over fixture controllers and handlers such as FatFixtureController so xUnit does not collect their deliberately failing facts (ConstructorDependencyCountTestsBaseTests.cs:6-13), and ObservabilityConventionTestsBase (Bases/Governance/ObservabilityConventionTestsBase.cs:30) pairs every SLO alert a consumer's infra/main.bicep provisions with a same-severity triage section in its infra/OPERATIONS.md, in both directions, with a minimum-spec floor so a drifted parse anchor fails loudly instead of passing with zero discovered alerts (Bases/Governance/ObservabilityConventionTestsBase.cs:6-13,39, [Rubric §13, Observability & Operability]). MMCA.Common runs that base against the artifact it ships rather than against a fixture: SampleDeploymentObservabilityTests (MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/Governance/SampleDeploymentObservabilityTests.cs:12) points it at samples/deployment, the worked example consumers copy, pairing that sample's main.bicep with its OPERATIONS.md under a floor of four alert specs (SampleDeploymentObservabilityTests.cs:14-20), so a runbook section that goes missing there fails here instead of propagating into every repo that lifted it (SampleDeploymentObservabilityTests.cs:5-11).

Five of the newer bases show how far the pattern has been pushed. CancellationTokenConventionTestsBase (Bases/Cqrs/CancellationTokenConventionTestsBase.cs:16) requires every public async method on a public Application- or Infrastructure-layer type to declare a trailing CancellationToken cancellationToken, because cancellation is only end-to-end if it is uniform: one method that swallows the token turns a cancelled request, an expired CQRS timeout budget or a stopping host into work that keeps running against the database, and a token in a non-trailing position or under a different name defeats the mechanical forwarding the decorator pipeline and the repositories rely on (Bases/Cqrs/CancellationTokenConventionTestsBase.cs:3-9), with signatures the repo does not own exempted automatically (:11-14). NamespaceCycleTestsBase (Bases/Layering/NamespaceCycleTestsBase.cs:15) requires the top-level namespaces inside each layer assembly to form a directed acyclic graph, catching the folder pair that has grown into one tangled unit at a granularity the two coarse layer rules cannot see inside; its own remarks are careful to say the rule is signature-level reflection blind to method bodies, so green means "no structural cycle", not "no coupling" (Bases/Layering/NamespaceCycleTestsBase.cs:3-13). IdempotencyConventionTestsBase (Bases/Cqrs/IdempotencyConventionTestsBase.cs:10) requires every POST action in a repo's API layer to state in code whether a retried request replays the original response ([Idempotent]) or deliberately does not ([NonIdempotent("why")]), so the answer is a compile-time artifact rather than tribal knowledge (Bases/Cqrs/IdempotencyConventionTestsBase.cs:3-8). ProtoContractTestsBase (Bases/Contracts/ProtoContractTestsBase.cs:19) is the synchronous counterpart to IntegrationEventContractTestsBase: it rebuilds a repo's live gRPC .proto contract and diffs it against a committed snapshot, and it is explicitly consumer-facing, because MMCA.Common ships the gRPC plumbing rather than any contracts of its own (Bases/Contracts/ProtoContractTestsBase.cs:3-11). FolderWidthTestsBase (MMCA.Common.Testing.Architecture/Bases/Governance/FolderWidthTestsBase.cs:14, [Rubric §5, Vertical Slice]) walks a repo root and fails when any folder under Source/ or Tests/ holds more than MaxDirectFiles direct code files, twelve by default (FolderWidthTestsBase.cs:23), so a folder keeps naming a feature instead of drifting into a technical bucket (FolderWidthTestsBase.cs:3-13); a .razor component and its code-behind count as one unit, resource and generated files do not count at all, and build output plus tool-owned trees (bin, obj, Migrations, Platforms, Resources, wwwroot) are skipped outright (:8-12). A repo activates it with a thin subclass supplying its RepoRoot (:20) and, where a flat layout is documented, its ExemptFolderSuffixes (:29); the single [Fact] delegates to the ArchitectureRules.FoldersStayNarrow rule body (:31-33), which is how the feature-by-folder convention of ADR-109 became a build gate rather than a review note. Sibling bases pin integration-event contracts (ADR-010), the one-upcaster-per-source-contract rule that keeps the upcast chain a function (so which contract a handler receives cannot depend on DI registration order, MMCA.Common.Testing.Architecture/Rules/Contracts/ArchitectureRules.Upcasters.cs:7-14, ADR-090), service-contract purity so an extracted service's wire surface carries only Shared and contract types and never the producer's internals (MMCA.Common.Testing.Architecture/Rules/Contracts/ArchitectureRules.Contracts.cs:13-18, ADR-007), data residency, forms conventions, localization resources, concurrency, controller shape, state management, UI architecture, and framework-version consistency, so the governance-as-tests pattern spans much of the 34-category rubric.

The newest gate in the library is also the one that tests itself. SliceCohesionTestsBase (MMCA.Common.Testing.Architecture/Bases/Cqrs/SliceCohesionTestsBase.cs:10, tagged to the vertical-slice rubric category in its own summary, :3-9) asks a repo only for its map and exposes two facts, one for handlers and one for validators (SliceCohesionTestsBase.cs:14-20), each delegating to a rule body in MMCA.Common.Testing.Architecture/Rules/Cqrs/ArchitectureRules.Slices.cs: a use-case slice keeps its command or query, the handler that serves it and its validator in one namespace, the .../UseCases/{Action}/ folder, instead of stranding the handler in a horizontal Handlers/ folder away from its contract (ArchitectureRules.Slices.cs:6-9). Two carve-outs keep it honest. Only same-assembly contracts are checked, because a module reusing a framework-generic command such as UpdateEntityCommand<,,> is legitimately not co-located with it, while a command the module derives from that generic is declared in its own assembly and is checked like any other (ArchitectureRules.Slices.cs:9-15); and the scope stops at the contract, its validator and its handler, because DTOs/, Specifications/ and a shared Validation/ rule set are aggregate-scoped by design, so forcing them into one slice's folder would either duplicate them per slice or make one slice the arbitrary owner the others reach into (ArchitectureRules.Slices.cs:17-25). Since the rule scans abstract handler bases too, which is the shape a consumer actually derives from (ArchitectureRules.Slices.cs:28-30), it carries its own self-test: SliceCohesionFitnessTests (MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/Cqrs/SliceCohesionFitnessTests.cs:17) points a fixture map at the test assembly itself (FixtureApplicationMap, SliceCohesionFitnessTests.cs:70-78) and pins the three shapes that matter: a stranded abstract base is flagged (StrandedFixtureHandlerBase, MMCA.Common.Architecture.Tests/SliceFixtures/Stranded/StrandedFixtureHandler.cs:11), a base declared beside its contract is not (GetFixturePreferencesHandlerBase, MMCA.Common.Architecture.Tests/SliceFixtures/SliceFixtures.cs:19, next to the GetFixturePreferencesQuery it serves at SliceFixtures.cs:13), and a base parameterized over its contract is skipped, because a type parameter is not a type any folder can hold (GetFixtureEntityHandlerBase<TQuery>, SliceFixtures.cs:33, all three asserted at SliceCohesionFitnessTests.cs:21-53). A fitness rule is production code for the build, and a rule whose own edge cases are compiled as fixtures is what holding it to that standard looks like.

Component tests: real MudBlazor, faked edges

The bUnit tier renders a single Blazor component in-process with its real dependencies but stubbed network and auth. BunitComponentTestBase (MMCA.Common.Testing.UI/Infrastructure/BunitComponentTestBase.cs:38) registers MudBlazor services and the vendor-neutral toast/confirm facades every migrated page injects (BunitComponentTestBase.cs:46,53), puts JSInterop in loose mode so MudBlazor components that probe JS during render do not throw (BunitComponentTestBase.cs:55), then wires a mutable AuthenticationStateProvider (BunitComponentTestBase.cs:63, the provider class at :167) plus the real DefaultAuthorizationService (BunitComponentTestBase.cs:62) so both <AuthorizeView> cascades and pages that inject the provider directly behave. The real service is registered explicitly because bUnit pre-registers a placeholder that throws and AddAuthorizationCore only TryAdds, and because it evaluates the requirements a view actually builds (roles, the default deny-anonymous policy) where a permissive double would authorize every authenticated principal whatever the view asks for (BunitComponentTestBase.cs:58-61). Tests render anonymously by default via RenderUnderTest<TComponent> (BunitComponentTestBase.cs:129) or as a supplied ClaimsPrincipal via RenderAs<TComponent> (BunitComponentTestBase.cs:135, which sets the provider and the cascading AuthenticationState together at :140-143), with a SetUser hook (:126) for mid-test auth changes and TestPrincipal (MMCA.Common.Testing.UI/Infrastructure/TestPrincipal.cs:7) minting the authenticated principal: a name claim, the user identifier written twice (under sub and under NameIdentifier, because a real principal reaches a page under either name), the requested roles, and an authentication type so IsAuthenticated is true (TestPrincipal.cs:22-32, rationale at :14-21). RenderMudProviders (BunitComponentTestBase.cs:153) mounts the popover, dialog, and snackbar providers and returns them as a MudProviderHandles record (BunitComponentTestBase.cs:162) so components that open a dialog or raise a toast have somewhere to render. One helper is worth knowing before you write your first list-page test: ConfigureDataGridListPageHost (BunitComponentTestBase.cs:105) wires the list-page state services, an inert viewport double so IsMobile is deterministic (:108-111), persistent component state (:114), and SetRendererInfo last (:116-117), because SetRendererInfo freezes the bUnit service provider and every registration made after it is silently ignored (:77-83). The class is pinned to bUnit v2 (the line compatible with xUnit v3 and Microsoft Testing Platform) and isolates every version-specific symbol here so a bUnit change touches only this file (BunitComponentTestBase.cs:29-34). Localization is pre-registered (AddLocalization, BunitComponentTestBase.cs:63-64) so components injecting IStringLocalizer<T> (ADR-027) render without per-test setup, a [Rubric §27, i18n] touch. Test bodies then read as user actions rather than DOM queries through BunitInteractionExtensions (MMCA.Common.Testing.UI/Infrastructure/BunitInteractionExtensions.cs:12), a generic extension<TComponent>(IRenderedComponent<TComponent>) block (:14) offering FindButtonByText (:18, which throws listing every button present when nothing matches), ClickButtonByText (:28), and HasText (:32), all keyed on accessible text rather than brittle CSS paths.

HTTP-backed UI services are exercised without a server through CapturingHttpMessageHandler (MMCA.Common.Testing.UI/Infrastructure/CapturingHttpMessageHandler.cs:20), a canned-response, request-recording HttpMessageHandler supporting both a responder delegate (CapturingHttpMessageHandler.cs:39) and route registration (SetResponse, CapturingHttpMessageHandler.cs:49), with registered routes consulted first and unmatched requests returning 404 to mirror the WebAPI's not-found behavior (CapturingHttpMessageHandler.cs:7-17,119-137); it rebuilds each response fresh so a Polly retry never reuses a consumed HttpContent (CapturingHttpMessageHandler.cs:141-150), and records every request as a CapturedRequest (CapturingHttpMessageHandler.cs:158) against a registered Route (CapturingHttpMessageHandler.cs:139), flattening request and content headers into one case-insensitive lookup so a caller asserting If-Match or Content-Type does not have to know which half carries it (:94-117). UiHttpServiceHarness (MMCA.Common.Testing.UI/Infrastructure/UiHttpServiceHarness.cs:12) wraps that handler with a FreshApiClientFactory (UiHttpServiceHarness.cs:73) returning a fresh client per call, which is load-bearing because the UI services dispose the client after each request, so a caching factory would hand later calls a disposed one (UiHttpServiceHarness.cs:66-72), plus a fixed-token StubTokenStorageService (MMCA.Common.Testing.UI/Infrastructure/StubTokenStorageService.cs:13, constructed and exposed at UiHttpServiceHarness.cs:48,61), all on a https://gateway.test/ base address (UiHttpServiceHarness.cs:15). Tests that would rather wire the pieces individually reach for HttpTestDoubles (MMCA.Common.Testing.UI/Infrastructure/HttpTestDoubles.cs:12), which exposes the same factory and token stub standalone (:23,28) alongside the canned JsonResponse/EmptyResponse/ProblemResponse builders (:33,37,47) that reproduce the shapes the WebAPI actually emits. MarkupSnapshot (MMCA.Common.Testing.UI/Infrastructure/MarkupSnapshot.cs:22) adds dependency-free golden-markup regression testing: Match (MarkupSnapshot.cs:31) normalizes the per-render GUIDs MudBlazor injects (MarkupSnapshot.cs:64-70), compares against a committed baseline under Snapshots/ next to the calling test (located through a [CallerFilePath] argument, MarkupSnapshot.cs:31,37), and returns a MarkupSnapshotResult (MarkupSnapshot.cs:104) for the caller to assert on, which keeps the shipped package free of an assertion-library dependency (MarkupSnapshot.cs:10-12). UPDATE_SNAPSHOTS=1 rewrites baselines (MarkupSnapshot.cs:41-46) and a missing baseline is written but reported as a non-match so a regression cannot slip through on an absent snapshot (MarkupSnapshot.cs:48-54). Whole page suites ship on top of that base for the framework-owned pages of ADR-116: ConfirmEmailPageTestsBase (MMCA.Common.Testing.UI/Pages/ConfirmEmailPageTestsBase.cs:26) pins the anonymous /confirm-email page (a complete link redeemed once on arrival, an incomplete one landing on manual entry, a resend that answers the same whether or not the address has an account, ConfirmEmailPageTestsBase.cs:13-19), while RoleAdminListPageTestsBase<TPage> (Pages/RoleAdminListPageTestsBase.cs:21) and RoleAdminEditPageTestsBase<TPage> (Pages/RoleAdminEditPageTestsBase.cs:22) pin the consumer's own half of the routed shells over the shared role roster and permission editor: route parameters, links back and forth, the compiled permission locked, and a save that submits the stored set (RoleAdminEditPageTestsBase.cs:13-19). Each is activated by a one-line sealed subclass in the consuming repo, the ADR-015 pattern carried into the component tier. This tier is [Rubric §28, Front-End Testing] and [Rubric §18, UI Architecture].

End-to-end tests: a real browser, accessibility and performance as gates

The E2E tier drives a real browser through Playwright. PlaywrightFixture (MMCA.Common.Testing.E2E/Infrastructure/PlaywrightFixture.cs:6) is an xUnit collection fixture (its E2ETestCollection definition sits beside it at PlaywrightFixture.cs:47-51, the class itself at :48) that launches the engine selected from configuration, chromium, firefox, or webkit, with unknown values falling back to Chromium (PlaywrightFixture.cs:17-22). That environment-selected engine is what lets CI run the same suite as a cross-browser matrix, [Rubric §22, Responsive/Cross-Browser]: MMCA.Common's ui-e2e job is a three-engine matrix (MMCA.Common/.github/workflows/ci.yml:236-237) with E2E_BROWSER handed to each leg (:298). Headless mode, slow motion, base URL, timeouts, trace capture, and the seeded admin/user credentials all come from E2ETestConfiguration (MMCA.Common.Testing.E2E/Infrastructure/E2ETestConfiguration.cs:15), whose nested AdminCredentials (E2ETestConfiguration.cs:80) and UserCredentials (E2ETestConfiguration.cs:92) let a downstream project set app-specific defaults through a [ModuleInitializer] while environment variables always win. Two of its knobs exist purely to de-flake CI: AuthTimeout (E2ETestConfiguration.cs:34) tunes the slowest step, the post-auth round-trip, independently of the 30-second general default (:25-26), and AuthGraceTimeout (E2ETestConfiguration.cs:45, default 15 seconds at :46) gives the success signal a window to appear after a transient error alert flashes during the success-path reload.

E2ETestBase (MMCA.Common.Testing.E2E/Infrastructure/E2ETestBase.cs:9) is the per-test base on top of that fixture. It opens a fresh browser context per test with IgnoreHTTPSErrors and the configured base URL (E2ETestBase.cs:20-37), optionally records a Playwright trace (:32-35) and, when E2E_TRACE names a directory, keeps only the traces of tests that failed so a full-suite run yields exactly the inspectable failures (:68-90, the failed-only branch at :79-85). Its LoginAsync (E2ETestBase.cs:98) clears both token stores before signing in (localStorage for the WASM host and the HttpOnly session cookie for the Server host, :100-114), and WaitForAuthResultAsync (:214) races three signals so success detection does not depend on the logout button having hydrated (:219-228, rationale at :206-213). The verdict itself is not inline: it is a pure function, AuthOutcomeRules.Classify (MMCA.Common.Testing.E2E/Infrastructure/AuthOutcomeRules.cs:38, invoked at E2ETestBase.cs:236-239), which returns an AuthOutcome (AuthOutcomeRules.cs:4) of Succeeded, ErrorShown, or Silent, so the classification is testable without a browser and the silent case (no navigation and no rendered error) can no longer be mistaken for success (AuthOutcomeRules.cs:19-26); anything other than success gets the grace window once (E2ETestBase.cs:248, AuthSucceededWithinGraceAsync at :282). ScanAsync (:334) and ScanGridAsync (:324) wrap the accessibility gate for settled pages and for MudDataGrid list pages respectively: the grid variant waits for a data row and for the loading bar to disappear before scanning and applies the pager carve-out (:326-329), while the plain scan stays fully strict on WCAG 2.1 AA (:336-337).

The hard part of Blazor E2E is timing, and PageExtensions (MMCA.Common.Testing.E2E/Infrastructure/PageExtensions.cs:23) is where that knowledge is centralized, as C# extension(IPage) and extension(ILocator) blocks (PageExtensions.cs:62,335, see primer §4). The app uses InteractiveAuto with prerendering, so a page appears as static HTML before the runtime wires its event handlers, and the runtime flag alone is a false green. WaitForBlazorAsync (PageExtensions.cs:85) therefore waits in two phases: first for window.Blazor._internal (:39), which only says the WASM CLR or the SignalR circuit is ready, then for the data-mmca-interactive attribute that MmcaThemeProviders stamps on the document element from its first interactive render (:47-48), which is the honest gate, and finally flushes one animation frame (:60,96). GotoAndWaitForBlazorAsync (:103) pairs navigation with that wait and deliberately settles on Load rather than NetworkIdle, because the persistent SignalR WebSocket means network idle never arrives (:106-108); BlazorNavigateAsync (:118) routes client-side so a protected page is not re-prerendered without its token, polling window.location instead of WaitForURLAsync because a same-document navigation fires no load event (:132-138); and GotoProtectedAsync (:160) probes the same runtime predicate and loads a public page first when the runtime is not yet up (:167-188). FillAndVerifyAsync (:347) fills a field then auto-waits until the value sticks, retyping character by character if hydration wiped it (:353-365), and ClickAndVerifyAsync (:380) and ClickAndWaitForUrlAsync (:423) retry a click until its visible effect appears so a click that beats hydration is not silently swallowed (:389-410). List-page helpers built on the same primitives (SearchAndWaitForRowAsync :233, ConfirmDeleteAsync :266, WaitForGridToSettleAsync :293) keep grid interactions out of every page object. These helpers encode hard-won lessons about the prerender and hydration race and are shared by every page object.

Accessibility and performance are asserted here, not deferred to a separate audit. AssertNoAccessibilityViolationsAsync (PageExtensions.cs:307) runs an axe-core scan and throws AccessibilityViolationException (MMCA.Common.Testing.E2E/Infrastructure/AccessibilityViolationException.cs:7) with a compact per-node summary of every violation (PageExtensions.cs:320-331), so an inaccessible page fails the build, [Rubric §21, Accessibility]. The scan scope itself is shipped as AxeOptions (MMCA.Common.Testing.E2E/Infrastructure/AxeOptions.cs:9): Wcag21Aa (AxeOptions.cs:17) pins the documented target of WCAG 2.1 AA tags (AxeOptions.cs:19-23) and deliberately excludes axe's advisory best-practice rules, and Wcag21AaExceptMudPagerCombobox (AxeOptions.cs:35) is the one documented carve-out, disabling only aria-input-field-name for MudBlazor 9.6.0's unlabeled pager select (AxeOptions.cs:26-33,42-45). WebVitalsCollector (MMCA.Common.Testing.E2E/Infrastructure/WebVitalsCollector.cs:20) installs PerformanceObserver-based Core Web Vitals capture (LCP, CLS, FCP, TTFB, INP) as an init script before first paint (InstallAsync, WebVitalsCollector.cs:40, script at :26-35), reads the accumulated values back as a WebVitalsSample (CollectAsync, WebVitalsCollector.cs:47,76), and writes a citable JSON artifact under WEB_VITALS_OUTPUT_DIR (WriteArtifactAsync, WebVitalsCollector.cs:63, artifact record WebVitalsArtifact at :90) for CI, with WebVitalsBudget (:103) as the shared assert mechanics defaulting to the Core Web Vitals "good" band, LCP 2500 ms / FCP 1800 ms / TTFB 800 ms / CLS 0.1 / INP 500 ms (WebVitalsCollector.cs:104-108), and skipping the INP assertion when no interaction cleared the 16 ms threshold (:148-151), [Rubric §23, Front-End Performance] (the source tags it rubric §12). LCP and CLS are Chromium-only, so on Firefox and WebKit those fields stay 0 and the observers fail silently rather than throwing (WebVitalsCollector.cs:14-16,22-25).

Five reusable identity page objects ship with the package: LoginPage (MMCA.Common.Testing.E2E/PageObjects/LoginPage.cs:6), RegisterPage (MMCA.Common.Testing.E2E/PageObjects/RegisterPage.cs:6), ProfilePage (MMCA.Common.Testing.E2E/PageObjects/ProfilePage.cs:6), ForgotPasswordPage (MMCA.Common.Testing.E2E/PageObjects/ForgotPasswordPage.cs:6), and ResetPasswordPage (MMCA.Common.Testing.E2E/PageObjects/ResetPasswordPage.cs:6). They wrap the framework's real auth surfaces with role- and label-based locators (LoginPage.cs:12-18) and route their own fills through the anti-race helper (LoginPage.cs:31-32, invoked at :25-26). A sixth, RoleAdminPage (MMCA.Common.Testing.E2E/PageObjects/RoleAdminPage.cs:18), drives the ADR-116 role roster at /roles and editor at /roles/{role} purely through the data-testid and data-permission attributes the shared components render, so a MudBlazor upgrade cannot break it (RoleAdminPage.cs:5-17). For eventually-consistent state inside a browser test, E2EPolling (MMCA.Common.Testing.E2E/Infrastructure/E2EPolling.cs:18) is the package's counterpart of the integration tier's TestPolling (the E2E package does not reference MMCA.Common.Testing): PollUntilAsync (E2EPolling.cs:38,70) returns as soon as the condition holds, bounded by a 30-second deadline at a 500 ms interval by default (E2EPolling.cs:21,24), and serves only "until present" waits (E2EPolling.cs:13-16). Downstream apps add their own family, for example the 45 page-object classes under MMCA.ADC.E2E.Tests/PageObjects/ covering events, sessions, speakers, rooms, questions, feedback, sponsors, and the QR check-in and points surfaces. Whole workflows ship too, not just page objects: eight abstract suites under MMCA.Common.Testing.E2E/Workflows/ (six identity flows, AuthorizationTestsBase, UserLoginTestsBase, UserRegistrationTestsBase, LogoutTestsBase, ProfileManagementTestsBase and PasswordResetTestsBase, plus UserPreferencesTestsBase (Workflows/Preferences/UserPreferencesTestsBase.cs:21) and PseudoLocalizationTestsBase (Workflows/Globalization/PseudoLocalizationTestsBase.cs:52)) are authored once and re-run per consumer. Their shape is the same supply-only-your-facts contract as the fitness bases: AuthorizationTestsBase (MMCA.Common.Testing.E2E/Workflows/Identity/AuthorizationTestsBase.cs:18) asks the subclass only for its route lists (ProtectedPaths :26, PublicPaths :29, optional AuthenticatedUserPath :35 and AdminPaths :44) and owns the assertions, including the non-empty guard that keeps the anonymous-redirect check from passing vacuously (:49-50). PasswordResetTestsBase (MMCA.Common.Testing.E2E/Workflows/Identity/PasswordResetTestsBase.cs:17) shows where the tier draws its own boundary: it asserts the recovery flow is reachable from the login page (:24-41) and that an unknown address produces the identical anti-enumeration confirmation (:43-58), but deliberately does not consume a real reset token, because that token only reaches the user by email and so belongs to an app-side integration test (:10-16).

The Gallery harness

Component and E2E coverage of MMCA.Common's own UI needs a page to render, but the framework is not a runnable app. MMCA.Common.UI.Gallery is a deliberately backend-less Blazor host that renders the real MMCA.Common.UI auth pages (/login, /register), the shared notification pages, and a primitives showcase (/components), so a real-browser axe scan can run inside MMCA.Common's own CI (GalleryHost, MMCA.Common.UI.Gallery/GalleryHost.cs:24, host built by BuildApp at :31). It is kept outside MMCA.Common.slnx (together with MMCA.Common.UI.E2E.Tests) so the unit-test run stays fast; the CI ui-e2e job builds that out-of-slnx graph directly by csproj path and runs the axe plus render smoke against the gallery (MMCA.Common/.github/workflows/ci.yml:223-227,260-264,293-306). Because the E2E suite self-hosts it in-process, where the entry assembly is the test host and the environment is Production, the host also has to point the static-web-assets loader at the gallery's own runtime manifest and force it on, otherwise the auth pages render unstyled, never become interactive, and axe's contrast checks are meaningless (GalleryHost.cs:36-50).

The host runs without a backend by registering stubs before AddUIShared so its TryAdd* registrations defer to them (GalleryHost.cs:57-65, AddUIShared at :102): NoOpAuthUIService (MMCA.Common.UI.Gallery/Stubs/NoOpAuthUIService.cs:14), NullTokenStorageService (MMCA.Common.UI.Gallery/Stubs/NullTokenStorageService.cs:11), NullTokenRefresher (MMCA.Common.UI.Gallery/Stubs/NullTokenRefresher.cs:9), and GalleryAuthenticationStateProvider (MMCA.Common.UI.Gallery/Stubs/GalleryAuthenticationStateProvider.cs:16), plus canned notification services (StubNotificationInboxUIService (Stubs/StubNotificationInboxUIService.cs:11), StubPushNotificationUIService (Stubs/StubPushNotificationUIService.cs:11)) so the bell and the inbox render populated markup (GalleryHost.cs:77-82), the framework's NullNotificationScopeProvider for the unscoped send page (GalleryHost.cs:87), and one empty GalleryUIModule (Stubs/GalleryUIModule.cs:14, registered at GalleryHost.cs:97) so the shared Router discovers the gallery's own page alongside the real ones. Because the notification pages carry a real [Authorize] that MapRazorComponents surfaces as endpoint metadata, the gallery also needs a genuine authentication scheme: GalleryFakeAuthenticationHandler (MMCA.Common.UI.Gallery/Stubs/GalleryFakeAuthenticationHandler.cs:21, registered at GalleryHost.cs:67-75) authenticates only requests carrying the gallery_auth=1 cookie (GalleryFakeAuthenticationHandler.cs:26,30-39), so the guarded pages are scanned signed in while /login, /register, and /components are scanned in their deliberate anonymous state (GalleryFakeAuthenticationHandler.cs:8-18). The gallery is also where the i18n evidence is produced: it enables the qps-Ploc pseudo-locale unconditionally (GalleryHost.cs:104-112), which real hosts keep Development-only, because the pseudo-localization pass is a required CI gate for [Rubric §27, i18n] and this host is unpackaged test infrastructure that is never deployed.

Evaluating a nondeterministic dependency: the AI-scoring golden corpus

Every tier above assumes a deterministic system under test. ADC's session-scoring judge is not one: it asks a hosted model for a structured score, and the same prompt can return a different number on a different day. MMCA.ADC.Conference.Scoring.Evaluation.Tests is the tier built for that case, and it is the subject of ADR-111. The corpus is a folder of committed JSON files copied next to the test assembly. GoldenCase (MMCA.ADC/Tests/Modules/Conference/MMCA.ADC.Conference.Scoring.Evaluation.Tests/GoldenCase.cs:18) is one case: a session proposal, a stable id, a one-line note on what it pins, and the band its overall score has to land in. The recorded answer is no longer part of the record: it lives beside the case as Golden/<id>.response.json, written by the framework's RecordedResponses in the ChatResponse shape rather than a provider's wire format, so a provider swap cannot invalidate the corpus (GoldenCase.cs:7-17). GoldenCorpus (GoldenCase.cs:106) loads every case-*.json from the copied Golden/ folder ordered by id so a run is deterministic (GoldenCase.cs:118-129), and throws when it finds none, so a csproj that stopped copying the corpus fails loudly instead of passing on zero cases (GoldenCase.cs:131-134); it also exposes the Golden/prompt-versions.json path that maps a prompt version to its recorded hash (GoldenCase.cs:114-116).

Three suites read that corpus, and they fail for three different reasons. GoldenReplayTests (GoldenReplayTests.cs:35) is the regression half, a subclass of the framework's GoldenReplayTestsBase: every case runs through the real SessionScoringService against a fresh ReplayChatClient that returns the response recorded for it, so no API key and no network are involved, it runs on every CI leg, and the base collects every broken case instead of stopping at the first (GoldenReplayTests.cs:15-25). The replay client is the innermost provider under the host's own governed pipeline, composed through the same AddConferenceAiGuardrails call the Conference service makes, and the test asserts a GuardrailChatClient really is in front of it, so a guardrail that would change a production score fails here instead of shipping (GoldenReplayTests.cs:49-61,165-183). It pins both directions at once, what goes out (the delimited envelope and the untrusted-input brief on the request, including for the cases with no speakers and with an injection attempt, plus proof that request-side redaction stripped the contact details from the contact-details-in-bio case before they reached the provider) and what comes back (a recorded response still parses, still succeeds, and still produces the same weighted overall inside the case's band), so a change to prompt assembly or to the weighting math fails here with the case that noticed it named (GoldenReplayTests.cs:26-32,67-80,143,160). LiveJudgeTests (LiveJudgeTests.cs:39) is the live half, scoring the same proposals through the real provider to catch what a replay cannot: a model deprecation, a structured-output contract change, a prompt edit that reads fine but scores everything a point lower. It composes the client exactly as the host does, from the host's deployed Ai section and the provider adapter named by Ai:Provider, so it names no vendor type and keeps no guardrail list of its own (LiveJudgeTests.cs:23-30). It costs money and needs a key, so it is trait-gated Category=AiEval.Live and skips itself when AI_API_KEY is absent (LiveJudgeTests.cs:17-21,41,59). Its bands are deliberately generous, roughly plus or minus 1.5 around the recorded value and clamped to the 1.0 to 10.0 range, because a judge model is not deterministic even at the same prompt and a tight band would produce a flaky gate that gets ignored, which is worse than no gate: what the bands catch is a shift, not a wobble (LiveJudgeTests.cs:32-36).

PromptContractTests (MMCA.ADC.Conference.Scoring.Evaluation.Tests/PromptContractTests.cs:29) closes the loop that makes a persisted score meaningful. Scores are stored with the prompt version that produced them, which is worth something only if the version actually moves when the prompt does, so this suite renders the system brief plus the user message for one canonical proposal, hashes it, and compares against Golden/prompt-versions.json: a prompt edit without a version bump fails because the recorded hash for the current version no longer matches, and a version bump with no recorded hash fails too (MMCA.ADC.Conference.Scoring.Evaluation.Tests/PromptContractTests.cs:16-22). The canonical proposal is fixed in the test file rather than read from the corpus on purpose (MMCA.ADC.Conference.Scoring.Evaluation.Tests/PromptContractTests.cs:37-45), because editing a golden case must not be able to change what the contract hash covers (MMCA.ADC.Conference.Scoring.Evaluation.Tests/PromptContractTests.cs:25-26); it is chosen to exercise every branch of the prompt assembly, with a description and two speakers, one of them with no tagline and no bio (MMCA.ADC.Conference.Scoring.Evaluation.Tests/PromptContractTests.cs:34-35). Beside it in the same file, SessionScoringPromptContractPinTests (PromptContractTests.cs:180) runs the framework's own prompt-change protocol, PromptContractPinTestsBase, over the scorer's one contract: it pins the normalized contract hash (name, version, model and system brief) in the same Golden/prompt-versions.json under a session-scoring@<version> key, while the bare <version> keys stay the rendered-prompt hashes PromptContractTests reads, and each base ignores the keys it does not own (PromptContractTests.cs:166-187). Together these suites are [Rubric §14, Testability] applied to a dependency that cannot be asserted exactly, and [Rubric §29, Resilience & Business Continuity] on the operational side: the offline gate is free and always on, the paid gate is opt-in, and neither one can pass vacuously.

The framework side of the same dependency is tested differently, because what MMCA.Common ships is pipeline mechanics rather than a model. MMCA.Common.AI.Tests pins when the pieces run and what they do, against stub edges rather than a hosted model: GuardrailChatClientTests (MMCA.Common/Tests/Core/MMCA.Common.AI.Tests/GuardrailChatClientTests.cs:12) holds the guardrail layer to being an extension point and not a policy (ADR-120), asserting when an application's guardrail runs and what a block does, never what a guardrail should consider unsafe (GuardrailChatClientTests.cs:7-11), driven by a StubGuardrail whose request, response and per-update verdicts the test supplies and which counts its request, response and streamed-update inspections (MMCA.Common/Tests/Core/MMCA.Common.AI.Tests/Fixtures/StubGuardrail.cs:10-13,16,19,22), so the pipeline tests need no real policy. The shipped policies are asserted from the innermost client's point of view, because what the provider was actually sent is the only place they count: ContentPolicyGuardrailTests pins both what a marker costs an attacker and which benign sentences must still pass (MMCA.Common/Tests/Core/MMCA.Common.AI.Tests/Guardrails/ContentPolicyGuardrailTests.cs:7-12), RequestRedactionTests that redaction reaches the provider without rewriting the caller's own messages (Guardrails/RequestRedactionTests.cs:8-14), ToolPolicyTests that a tool the policy removed is absent from what the model was offered (Guardrails/ToolPolicyTests.cs:10-15), and StreamedGuardrailTests that every streamed update is inspected before it is yielded (Guardrails/StreamedGuardrailTests.cs:7-12). The evaluation harness ADC's corpus runs on is held to the same standard before anything it gates is trusted: ReplayChatClientTests pins the replay client and the golden base so neither can answer with the wrong recording or pass on an empty corpus (Evaluation/ReplayChatClientTests.cs:6-13), RecordedResponsesTests pins the two on-disk formats and the exact failure messages of the prompt pin (Evaluation/RecordedResponsesTests.cs:6-12), and ReferenceGoldenReplayTests drives a tiny reference summarizer through GoldenReplayTestsBase against three recorded answers so the shipped base runs on every Common pull request, not only in the repos that consume it (Evaluation/ReferenceGoldenReplayTests.cs:6-14). On the ADC side, ConferenceAiGuardrailsRegistrationTests guards the one guardrail list the Conference host and both evaluation tiers share (MMCA.ADC/Tests/Modules/Conference/MMCA.ADC.Conference.Infrastructure.Tests/Services/ConferenceAiGuardrailsRegistrationTests.cs:12-17), SessionScoreResponseGuardrailTests asserts the answer rules at the pipeline extension point where they now live, a blocked answer returning as an ordinary failed score (Services/SessionScoreResponseGuardrailTests.cs:11-18), and SessionScoringServiceTests talks to a recording stub IChatClient rather than a fake provider HTTP handler, leaving token-cost counters to the framework's own meter (Services/SessionScoringServiceTests.cs:13-22); UsageRecordingChatClientTests does the same for the token-usage recorder, collecting what was emitted through a DurationMeasurement record declared in the test file itself (MMCA.Common/Tests/Core/MMCA.Common.AI.Tests/UsageRecordingChatClientTests.cs:212). One fact in that family sits deliberately outside the AI package: AiTelemetryExportTests (MMCA.Common/Tests/Hosting/MMCA.Common.Aspire.Tests/Telemetry/AiTelemetryExportTests.cs:20) asserts that the meter and the activity source named MMCA.Common.AI really are exported by the Aspire defaults, which subscribe that name as a literal string because AiDependencyIsolationTestsBase bars a project reference from the Aspire package to the AI one, so a rename on either side goes red here instead of quietly taking model-spend telemetry off every dashboard (AiTelemetryExportTests.cs:12-19,22).

Contract, pipeline, and benchmark bases

The last family pins guarantees that live in the composition of the stack rather than in any one type, and it is the subject of ADR-058: these suites ship in MMCA.Common.Testing as abstract behavioral bases and every one of them runs against a host that was actually booted. SecurityHeadersTestsBase (MMCA.Common.Testing/Conformance/SecurityHeadersTestsBase.cs:16, [Rubric §11, Security] and [Rubric §26, Front-End Security]) probes an always-responding endpoint (ProbePath, default /alive, SecurityHeadersTestsBase.cs:19) and asserts the hardened header set: X-Content-Type-Options: nosniff, X-Frame-Options: DENY, Referrer-Policy: strict-origin-when-cross-origin, a Permissions-Policy containing geolocation=(), a Content-Security-Policy containing frame-ancestors 'none', and, in the Production environment, HSTS (SecurityHeadersTestsBase.cs:29-35). Its siblings OpenApiContractTestsBase<TFixture> (MMCA.Common.Testing/Conformance/OpenApiContractTestsBase.cs:32, with a MinimumPathCount floor at :37, a pinned CorePublicResources list at :50, and deliberately no committed snapshot file so a new controller can never leave a stale baseline behind, :14-16), ProblemDetailsContractTestsBase<TFixture> (MMCA.Common.Testing/Conformance/ProblemDetailsContractTestsBase.cs:22, asserting the RFC 9457 shape across both error-shaping paths, model validation at :30 and the framework's HandleFailure mapping at :42, through one shared AssertProblemDetailsShapeAsync at :67), and ServiceInfoVersioningContractTestsBase<TFixture> (MMCA.Common.Testing/Conformance/ServiceInfoVersioningContractTestsBase.cs:20, driving /ServiceInfo at both api-version: 1.0 and 2.0 and checking the deprecated/supported reporting headers at :38,:54) all subclass IntegrationTestBase<TFixture> and pin the corresponding API contracts, [Rubric §9, API & Contract Design]. The non-HTTP member of the family is GracefulShutdownTestsBase<TEntryPoint> (MMCA.Common.Testing/Conformance/GracefulShutdownTestsBase.cs:25, [Rubric §29, Resilience & Business Continuity]): it boots a host through ProductionHostApplicationFactory, calls a real IHost.StopAsync under a bounded token defaulting to 20 seconds (:28,:55-56), and asserts ApplicationStopping then ApplicationStopped fired (:58-61). The failure it catches, a hosted service that refuses to drain, is invisible in production until it wedges a rolling deploy.

Four bases guard the composition of the pipelines themselves. DecoratorPipelineOrderTestsBase<TCommand, TCommandResult, TQuery, TQueryResult> (MMCA.Common.Testing/Conformance/DecoratorPipelineOrderTestsBase.cs:38) is the opt-in fitness function for ADR-014: it builds a real ServiceCollection through the repo's own registration sequence (ConfigureServices, :46), resolves the decorated handlers, unwraps each decorator's private inner-handler field by reflection so it verifies the constructed object graph rather than the registration list (:105-125), and asserts the runtime nesting is exactly FeatureGate, Authorization, Logging, Caching, Validating, Timeout, Transactional, handler for commands (DecoratorPipelineOrderTestsBase.cs:49-58) and FeatureGate, Authorization, Logging, Caching, Validating, Timeout, handler for queries (:61-69), through the two [Fact]s at :71-77, with a final check that the innermost element is not itself a decorator (:96-97). Authorization and Timeout are the newest links in both chains, inserted by ADR-014's 2026-08-18 revision (Website/docs-src/adr/014-cqrs-decorator-pipeline.md:96-107); note that the revision's query line (:107) omits Validating, while the shipped registration and this base both include it (MMCA.Common/Source/Core/MMCA.Common.Application/DependencyInjection.cs:144), so the code is the authority here. Because Scrutor's TryDecorate applies decorators in reverse registration order, an innocent-looking reorder of the AddApplicationDecorators() lines silently changes runtime behavior, and this base turns that into a test failure (see group 5). MiddlewarePipelineOrderTestsBase (MMCA.Common.Testing/Conformance/MiddlewarePipelineOrderTestsBase.cs:31) is its counterpart on the HTTP edge: it seeds MiddlewarePipelineBuilder.CreateDefault, applies the host's own Configure customization when it has one (:35), and asserts the eighteen-step order from the exception handler down to the controller endpoints (:38-58). Several adjacencies there are load-bearing (the pre-forwarded capture immediately before UseForwardedHeaders, authentication immediately before tenant resolution, authentication before the rate limiter per ADR-019, forwarded headers before the HTTPS redirect), and a reorder that breaks one of them fails at runtime looking like a configuration bug: an unreachable jwks_uri, a tenant that never resolves, a per-user rate cap that never engages (:13-18). Unlike the contract bases it needs no host at all, because the steps are pure data until they are applied, so it runs in the fast unit tier (:24-27). DependencyInjectionAssert (MMCA.Common.Testing/Support/DependencyInjectionAssert.cs:13) guards the other half of that composition: ReturnsSameCollection (:21) asserts a registration extension hands back the very IServiceCollection it was given (:29-31), because an extension that returns a new collection silently drops every registration chained after it and nothing else catches services that are simply absent (:6-11). HandlerTestBase<THandler> (MMCA.Common.Testing/Support/HandlerTestBase.cs:38) is the fast unit-tier counterpart for exercising a single handler without a host: it owns a Mock<IUnitOfWork> whose SaveChangesAsync is pre-configured to succeed (HandlerTestBase.cs:41-42,45), a NullLogger<THandler> (:48), and RegisterRepository<TEntity, TIdentifierType>() (:56) / RegisterReadRepository<TEntity, TIdentifierType>() (:72) helpers that wire a repository mock into the read and write accessors (the read-only variant exists for child entities, which expose no read-write repository).

A smaller final tier measures rather than asserts behavior. MMCA.Common.Benchmarks (BenchmarkDotNet) covers the per-request query pipeline, where the dynamic-LINQ predicate is re-parsed per call and the shaper reflects over DTO properties (QueryPipelineBenchmarks, MMCA.Common.Benchmarks/QueryPipelineBenchmarks.cs:9-17), and the specification hot path (SpecificationBenchmarks, MMCA.Common.Benchmarks/SpecificationBenchmarks.cs:8-14), both with [MemoryDiagnoser] allocation tracking. Its results are compared in CI by build/perfgate against the committed MMCA.Common/Tests/Performance/perf-baseline.json (MMCA.Common/.github/workflows/ci.yml:397), so moving a number has to be a deliberate, reviewed change, [Rubric §12, Performance & Scalability]. The same job family carries one more quiet gate worth knowing: the unit run is invoked with --minimum-expected-tests 2000 (MMCA.Common/.github/workflows/ci.yml:161), so a discovery regression that silently drops thousands of tests fails the build instead of reporting a green, empty run.

Benchmarks time one operation in isolation; MMCA.Common.LoadTests measures the framework at volume. LoadStack (MMCA.Common/Tests/Performance/MMCA.Common.LoadTests/Support/LoadStack.cs:25) wires the real persistence stack exactly as a host does, AddApplication() plus AddInfrastructure(configuration), over one temp-file SQLite database, substituting nothing below the service registrations (LoadStack.cs:13-19); it is a file rather than :memory: because each scenario opens one connection per scope, as a deployed host does (LoadStack.cs:20-24). Two suites run on it. OutboxThroughputLoadTests (MMCA.Common.LoadTests/OutboxThroughputLoadTests.cs:20) enqueues 10,000 integration events as the framework writes them and lets the real OutboxProcessor, resolved as a hosted service with its default settings, drain them to a CountingMessageBus: every message must be delivered exactly once and stamped processed, above a floor of 500 messages per second (OutboxThroughputLoadTests.cs:12-19,22,30). PagedQueryLoadTests (MMCA.Common.LoadTests/PagedQueryLoadTests.cs:13) drives EntityQueryService.GetAllAsync over 100,000 rows seeded by PagedQueryFixture, asserting exact rows rather than a count (so a fast wrong answer still fails) under per-shape median latency ceilings and a p95 ceiling across 50 concurrent paged reads (PagedQueryLoadTests.cs:7-12,23-31). Each constant carries the local measurement it was derived from, with about 3x headroom over the worst of 25 runs. The tier is deliberately outside ci.yml and not a required check: the project sits outside MMCA.Common.slnx, so the solution-wide test run never discovers it, and a timing tier on shared runners is a trend signal rather than a merge gate, so load-tests.yml runs it weekly on a schedule plus manual dispatch (MMCA.Common/.github/workflows/load-tests.yml:3-17).

The takeaway for a new engineer: pick the tier that matches what you are proving (a fast unit test for domain logic, bUnit for a component, an integration fixture for a full request path, a cross-service fixture for a real broker round-trip, an AppHost collection for the orchestration itself, an E2E page object for a browser flow, a *TestsBase subclass for an architectural invariant, a contract base for a runtime guarantee of the composed host, a golden case for a change in what the scoring model returns, a benchmark for an allocation budget), and, for every tier but the ADC-local model-evaluation suite, the reusable base you need is already in one of the five MMCA.Common.Testing.* packages. Adoption is opt-in per host in both governance tiers, which is the standing caveat in ADR-015 and ADR-058 alike: the framework ships the gate, a host gets it only once someone writes the subclass (Website/docs-src/adr/015-architecture-fitness-functions.md:68-70, Website/docs-src/adr/058-runtime-conformance-suites-as-a-package.md:173-175). Every remaining concrete test class is cataloged by project in the companion per-project test rollup for this chapter.

ContractRow

MMCA.ADC.Architecture.Tests · MMCA.ADC.Architecture.Tests.Api · MMCA.ADC/Tests/Architecture/MMCA.ADC.Architecture.Tests/Api/NavigationContractTests.cs:330 · Level 0 · record (private, sealed, nested)

• What it is - one parsed data row of the ## Route Contract table in adc-NavigationFlow.md: the backticked route template, the page cell and the access word, as three strings (NavigationContractTests.cs:330).
• Depends on - nothing but the BCL; it is a positional record nested inside NavigationContractTests.
• Concept introduced, a row as a value. Parsing the markdown table once into a value type lets every fact compare rows by Route, Page and Access instead of re-splitting text. ReadContractTable builds it from exactly three trimmed cells (:243, constructed at :268-:278 of the table reader).
• Where it's used - only inside the defining file: ContractTable.Rows carries it, and EveryContractAccess_MatchesThePageGuard and RouteContractTable_IsWellFormed read it (:79, :107).

PageRoute

MMCA.ADC.Architecture.Tests · MMCA.ADC.Architecture.Tests.Api · MMCA.ADC/Tests/Architecture/MMCA.ADC.Architecture.Tests/Api/NavigationContractTests.cs:328 · Level 0 · record (internal, sealed, nested)

• What it is - one routable ADC page as discovered from the source tree: Route (the @page template), RelativePath (the .razor file), PageName (file name without extension), Access (Anonymous, Authenticated or Organizer, null when unclassifiable) and Violation (why classification failed, else null) (NavigationContractTests.cs:328).
• Depends on - nothing but the BCL; nested in NavigationContractTests.
• Concept introduced, carry the failure with the fact. Classify returns (Access, Violation) and DiscoverPageRoutes stores both on the record (:209, :139), so the guard-presence fact can report a page with no or several access attributes without a second scan.
• Where it's used - the four facts and the table-hygiene check in the defining file consume DiscoverPageRoutes() results (:38-:107). The record is internal rather than private because DiscoverPageRoutes is now internal static (:332) and NavItemGuardContractTests.DiscoverGuardedPages reuses it to map each page to a GuardedPage (MMCA.ADC/Tests/Architecture/MMCA.ADC.Architecture.Tests/Api/NavItemGuardContractTests.cs:318-:324).

PageGuard

MMCA.ADC.Architecture.Tests · MMCA.ADC.Architecture.Tests.Api · MMCA.ADC/Tests/Architecture/MMCA.ADC.Architecture.Tests/Api/NavItemGuardContractTests.cs:464 · Level 0 · record (private, sealed, nested)

• What it is - the normalized access requirement of one page, as five fields: RequiresAuthentication, AnyOfRoles (the roles of which a caller needs one), ClaimType, Permission and a human-readable Description such as [Authorize(Roles = RoleNames.Organizer)] (NavItemGuardContractTests.cs:464).
• Depends on - nothing but the BCL; nested in NavItemGuardContractTests.
• Concept introduced, a guard as a comparable value. Every page guard form ([AllowAnonymous], [Authorize], roles, a policy resolved to the claim or permission it enforces) reduces to this one shape (:321-:323, :354, :403), so Compare (:108) can test a nav item against it with four independent checks: signed-in, role, claim, permission (:117-:135).
• Where it's used - only inside the defining file, held by GuardedPage.

GuardedPage

MMCA.ADC.Architecture.Tests · MMCA.ADC.Architecture.Tests.Api · MMCA.ADC/Tests/Architecture/MMCA.ADC.Architecture.Tests/Api/NavItemGuardContractTests.cs:462 · Level 1 · record (private, sealed, nested)

• What it is - one routable page paired with its guard: Route, Source (the .razor path for ADC pages, the component's full type name for framework pages), Guard (a PageGuard, null when unreadable) and Problem (why it was unreadable) (NavItemGuardContractTests.cs:462).
• Depends on - PageGuard and, for ADC pages, PageRoute from NavigationContractTests.DiscoverPageRoutes().
• Concept introduced, carry the failure with the fact. Like PageRoute, an unreadable guard is data, not an exception: DiscoverGuardedPages (:316) builds a null Guard plus the Violation for an unclassified ADC page (:324), and Compare turns that into a violation (:110-:113) rather than skipping the page, so the gate cannot pass over a page it failed to read. ADC pages come from source text (:318-:324); the framework's routable components in MMCA.Common.UI are added by reflection (:333).
• Where it's used - only inside the defining file: EveryNavItem_OpensARoutablePage (:75) matches nav hrefs against its Route, and EveryNavItem_IsNoLooserThanTheGuardOfThePageItOpens (:89) compares item against Guard.

ContractTable

MMCA.ADC.Architecture.Tests · MMCA.ADC.Architecture.Tests.Api · MMCA.ADC/Tests/Architecture/MMCA.ADC.Architecture.Tests/Api/NavigationContractTests.cs:332 · Level 1 · record (private, sealed, nested)

• What it is - the parse result of the route-contract table: Rows (a List<ContractRow>) plus Problems (a List<string> of structural defects found while reading) (NavigationContractTests.cs:332).
• Depends on - ContractRow, nested in NavigationContractTests.
• Concept introduced, parse problems are data. ReadContractTable (:243) never throws on a malformed table. A missing ## Route Contract heading, a missing | Route | Page | Access | header, a row that is not three cells with a backticked route, or an empty table each append to Problems and return early with an empty Rows. RouteContractTable_IsWellFormed then surfaces them (:107).
• Where it's used - only inside the defining file; ReadContractTable().Rows feeds three facts and .Problems feeds the hygiene fact.

CostTagConventionTests

MMCA.ADC.Architecture.Tests · MMCA.ADC.Architecture.Tests.Governance · MMCA.ADC.Architecture.Tests/Governance/CostTagConventionTests.cs:10 · Level 1 · class (public, sealed)

• What it is - the cost-attribution gate over ADC's infra/main.bicep: every container app must carry a service tag, and every per-service database must carry the matching one, so per-service spend is readable straight off the Azure cost report. It is a thin subclass of CostTagConventionTestsBase that supplies two values, MinimumContainerApps => 6 (MMCA.ADC.Architecture.Tests/Governance/CostTagConventionTests.cs:12) and DatabaseNamePrefix => "ADC_" (:14).
• Depends on - CostTagConventionTestsBase (see the per-project rollup; MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Bases/Governance/CostTagConventionTestsBase.cs:29), and the infra.main.bicep manifest resource the base reads from the derived type's assembly (CostTagConventionTestsBase.cs:45, :51), the same resource ObservabilityConventionTests uses.
• Concept introduced, cost as a governed dimension, authored once. Nothing in Bicep enforces a tagging convention; an untagged container app or database still deploys, it just becomes an unattributed line in the bill. The base owns both facts. EveryContainerApp_CarriesAServiceTag (CostTagConventionTestsBase.cs:59) requires at least MinimumContainerApps apps to be discovered (so the check cannot pass off a parse that matched nothing; ADC's six are four services, the Gateway and the UI host) and fails any app whose captured tags line lacks service: (:68). ServiceDatabases_CarryTheServiceTagOfTheOwningApp (:82) builds the expected literal tags: union(commonTags, { service: toLower(replace(dbName, '<prefix>', '')) }) from DatabaseNamePrefix (:88) and asserts the Bicep contains it, so a database's tag is derived from its own name. [Rubric §34 - Architecture Governance & Documentation] is the base's stated category (:6); the FinOps half of [Rubric §29 - Resilience & Business Continuity] applies too.
• Walkthrough - two overrides and no test method. The prefix is why the base takes a parameter: ADC strips ADC_ to get conference, and an empty prefix fails the second fact (:84).
• Why it's built this way - the rule lives in the shared package so Store and ADC cannot drift on it; ADC keeps only its identity (the same thin-subclass shape as BrandColorTokenTests). The trade-off is the hand-maintained floor: a new deployable raises the count and the override must follow.
• Where it's used - runs with the rest of the architecture suite in ADC's build-and-test job.
• Caveats / not-in-source - the tag test is a substring match on the captured tags: line, so a service: text elsewhere on that line would satisfy it.

SqlAuditConventionTests

MMCA.ADC.Architecture.Tests · MMCA.ADC.Architecture.Tests.Governance · MMCA.ADC.Architecture.Tests/Governance/SqlAuditConventionTests.cs:12 · Level 0 · class

• What it is - the guard that every database carrying dbo.AuditTrailEntries also provisions a database-scoped SQL auditing policy that records an UPDATE or DELETE against that table by ANY principal, the admin login included (MMCA.ADC.Architecture.Tests/Governance/SqlAuditConventionTests.cs:97-:110, :112-:129). See ADR-075.
• Depends on - the same embedded infra.main.bicep resource CostTagConventionTests reads, loaded independently by its own ReadBicep() (:131-:138).
• Concept introduced, the audit trail must itself be tamper-evident. AuditSaveChangesInterceptorTests (elsewhere in this unit) proves the application writes an audit row for every change; this type proves the database layer under that write cannot be bypassed by a principal with direct SQL access, the admin login included, which is exactly the actor the application-level interceptor cannot see. DatabaseAuditingPolicy_RecordsTrailUpdatesAndDeletes (:96) asserts three literal substrings: the resource type must be Microsoft.Sql/servers/databases/auditingSettings@... (database-scoped, never the server-level policy, because object-scoped actions like UPDATE ON dbo.AuditTrailEntries are only valid there), and the two action groups 'UPDATE ON dbo.AuditTrailEntries BY public' and 'DELETE ON dbo.AuditTrailEntries BY public'. AuditTrailDatabases_IncludeEveryDatabaseThatCarriesTheTrail (:112) is a [Theory] over the three databases that carry the trail table, ADC_Identity, ADC_Conference, ADC_Engagement (:113-:115), and asserts each name appears inside the auditTrailDatabaseNames array the DML audit loop iterates, so a fourth module that starts writing audit rows but is never added to that array fails the build instead of shipping an unaudited trail silently. [Rubric §11 - Security] and [Rubric §30 - Compliance/Privacy/Data Governance] are the direct targets: an audit trail that can be quietly altered or deleted by a privileged account is not evidence.
• Walkthrough - AuditTrailDatabases_IncludeEveryDatabaseThatCarriesTheTrail locates the var auditTrailDatabaseNames = [ declaration by substring search (:120), asserts it was found at all (:121), then slices to the matching ] and checks membership of the quoted database name inside that slice (:123-:128), so the assertion is scoped to the declared list and cannot be satisfied by the name appearing anywhere else in the file.
• Why it's built this way - BY public is the SQL Server auditing wildcard for "every principal", written into the policy rather than into an allowlist of expected callers, because the whole point is that the admin login itself cannot make an audit-trail change disappear from the trail.
• Where it's used - runs with the rest of the suite in the build-and-test job (MMCA.ADC/.github/workflows/deploy.yml:189, :284).
• Caveats / not-in-source - the three literal substrings are exact-text assertions against the compiled Bicep, so a semantically equivalent but differently formatted policy declaration (reordered JSON keys, a different quoting style) would fail this check even though the deployed policy is correct.

ObservabilityConventionTests

MMCA.ADC.Architecture.Tests · MMCA.ADC.Architecture.Tests.Governance · MMCA.ADC.Architecture.Tests/Governance/ObservabilityConventionTests.cs:7 · Level 1 · class (public, sealed)

• What it is - the SLO alert-to-runbook pairing gate for ADC. It derives from ObservabilityConventionTestsBase and overrides one member, raising the non-vacuity floor from the base's default of 3 to 6 (MMCA.ADC.Architecture.Tests/Governance/ObservabilityConventionTests.cs:7-:15).
• Depends on - ObservabilityConventionTestsBase, plus two EmbeddedResource entries in the csproj that supply the files the base reads: infra/main.bicep under the logical name infra.main.bicep and infra/OPERATIONS.md under infra.OPERATIONS.md (MMCA.ADC.Architecture.Tests/MMCA.ADC.Architecture.Tests.csproj:17-:22).
• Concept introduced, identity by inheritance plus a floor override. This is the thin-subclass pattern from BrandColorTokenTests, extended one step. The base defaults ResourceAssembly to GetType().Assembly (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Bases/Governance/ObservabilityConventionTestsBase.cs:51), so the derived type is the configuration: deriving in this assembly is what points the rule at ADC's embedded bicep and runbook, the same identity-only wiring the file comment describes ("this repo supplies only its identity", ObservabilityConventionTests.cs:3-:6). On top of that wiring, this subclass raises MinimumAlertSpecs from the base's default of 3 to 6 (:14), because ADC declares six SLO alert specs, the five request and resilience SLOs plus the AI scoring token ceiling (moved into sloAlertSpecs so the pairing gate covers it), and leaving the base floor in place would let the gate pass vacuously if the parse anchors drifted and discovered only three. [Rubric section 13 - Observability & Operability] assesses whether the system can be operated under failure, which means alerts that lead somewhere; this pairs each provisioned alert with a runbook section at build time instead of at 3am.
• Walkthrough - one member. MinimumAlertSpecs => 6 (:14) raises the base's default of 3 (ObservabilityConventionTestsBase.cs:39) to ADC's actual alert-spec count, now that the AI scoring token ceiling moved into sloAlertSpecs alongside the five request and resilience SLOs. Everything else runs from the base's three inherited facts: SloAlertSpecs_AreDiscovered_GateIsNotVacuous (ObservabilityConventionTestsBase.cs:82) enforces that floor; EveryProvisionedSloAlert_HasASeverityCorrectRunbookSection (:64) walks the alerts declared in the embedded bicep and requires a matching, severity-correct section in the embedded runbook; and EveryRunbookAlertSection_MapsToAProvisionedAlert (:92) closes the other direction, failing on an orphan runbook section for an alert that no longer exists. The resource names the base reads default to infra.main.bicep and infra.OPERATIONS.md (:42, :45), which is why the csproj logical names must match exactly.
• Why it's built this way - alert definitions live in infrastructure-as-code and the response procedure lives in a Markdown runbook; nothing in either file references the other, so the pairing is exactly the kind of invariant that decays silently. Embedding both into the test assembly turns the pairing into a compile-and-run artifact.
• Where it's used - runs with the rest of the suite in the build-and-test job (MMCA.ADC/.github/workflows/deploy.yml:189, :284).

BrandColorTokenTests

MMCA.ADC.Architecture.Tests · MMCA.ADC.Architecture.Tests.Ui · MMCA.ADC.Architecture.Tests/Ui/BrandColorTokenTests.cs:12 · Level 1 · class (public, sealed)

• What it is - the ADC end of the brand-token drift guard. It is a six-line subclass of the shared BrandColorTokenTestsBase that names one embedded stylesheet, ADCHome.Shared.razor.css (MMCA.ADC.Architecture.Tests/Ui/BrandColorTokenTests.cs:14-:17); the rule body itself lives in MMCA.Common.
• Depends on - BrandColorTokenTestsBase from the MMCA.Common.Testing.Architecture package (referenced at MMCA.ADC.Architecture.Tests/MMCA.ADC.Architecture.Tests.csproj:41), plus the EmbeddedResource item that maps the conference landing page's scoped stylesheet into this assembly under that logical name (MMCA.ADC.Architecture.Tests/MMCA.ADC.Architecture.Tests.csproj:11-:13). Externals: xUnit v3, AwesomeAssertions, and NetArchTest (MMCA.ADC.Architecture.Tests.csproj:25-:27), the last two reachable everywhere in the assembly through the global usings (MMCA.ADC.Architecture.Tests/GlobalUsings.cs:1-:5).
• Concept introduced, the thin-subclass fitness function. Every type in this unit follows one shape, so learn it once here. A fitness function is an executable test that asserts an architectural property instead of a behavior. MMCA keeps the property's logic in exactly one place, an abstract *TestsBase in the shared MMCA.Common.Testing.Architecture package, and each repo derives a sealed subclass that supplies only its own identity: which assemblies to scan, which floors and allowlists apply, which files to read. xUnit discovers [Fact]s on inherited members, so the subclass needs no test method of its own; deriving the class is what makes the rule run in this repo (ADR-015). [Rubric §34 - Architecture Governance & Documentation] assesses whether architectural decisions are recorded and enforced rather than trusted to reviewers; here the decision is enforced by a build that goes red. [Rubric §20 - Design System & Theming] assesses whether a design system has one source of truth for its tokens; this rule is what stops a host copy of the landing page from re-hardcoding the brand hex.
• Walkthrough - one member. EmbeddedCssLogicalNames (BrandColorTokenTests.cs:14-:17) is a collection expression with a single entry, "ADCHome.Shared.razor.css". That string is not a file path: it is the LogicalName the csproj assigns when it embeds Source/Modules/Conference/MMCA.ADC.Conference.UI/Pages/Home/ADCHome.razor.css as a manifest resource (MMCA.ADC.Architecture.Tests.csproj:11-:13), which is how a test assembly reads a file from a project it does not reference. The inherited fact LandingPageCss_SourcesBrandColorFromToken_NotHardcodedHex (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Bases/Ui/BrandColorTokenTestsBase.cs:25) then loads each named resource and asserts the token rule over it; the abstract hook this class implements is declared at :22.
• Why it's built this way - the class comment records the split (BrandColorTokenTests.cs:3-:11): MMCA.Common's own BrandColorTokenTests guards the C#-to-CSS token definition, and this one guards the ADC consumer of it. Embedding the stylesheet rather than reading it off disk means the guard travels with the compiled test assembly and cannot be defeated by a runner whose working directory differs.
• Where it's used - the whole project is inside ADC's CI solution filter (MMCA.ADC/MMCA.ADC.CI.slnf:58), which the build-and-test job restores, builds, and tests on every PR and every push to main (MMCA.ADC/.github/workflows/deploy.yml:4-:7, :189, :264, :270, :284).
• Caveats / not-in-source - the guard only covers stylesheets that are both embedded and listed. ADC lists exactly one, so a second landing-page stylesheet added later is invisible to the rule until someone adds it to both places.

MessageBusBackpressureTests

MMCA.ADC.Architecture.Tests · MMCA.ADC.Architecture.Tests.Governance · MMCA.ADC.Architecture.Tests/Governance/MessageBusBackpressureTests.cs:10 · Level 1 · class (public, sealed)

• What it is - the broker-backpressure gate for ADC's four service hosts. It overrides one member, Services, as ["Conference", "Identity", "Engagement", "Notification"] (MMCA.ADC.Architecture.Tests/Governance/MessageBusBackpressureTests.cs:12).
• Depends on - MessageBusBackpressureTestsBase (see the per-project rollup; MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Bases/Governance/MessageBusBackpressureTestsBase.cs:31), plus one embedded appsettings.json per listed service under the logical name services.{Service}.appsettings.json (MessageBusBackpressureTestsBase.cs:63).
• Concept introduced, an unset knob is a silent default. MessageBusSettings leaves PrefetchCount and ConcurrentMessageLimit null and ignores values of zero or less, so a service that omits them runs on the transport's own defaults with nothing failing (MessageBusBackpressureTestsBase.cs:7-:12). The inherited fact EveryServiceAppSettings_BoundsBrokerBackpressure (:70) requires a non-empty service list, then for each service both keys set and positive and the prefetch window at least the concurrency it feeds; the public static Check (:93) holds the parse so it can be tested over a fixture document. The settings are read with System.Text.Json, not bound to MessageBusSettings, because the package takes no framework reference (:24-:28). [Rubric §12] is the base's stated category (:7).
• Walkthrough - one member. The list names all four services, Notification included.
• Why it's built this way - the key names are pinned against MessageBusSettings by MMCA.Common's own tests (:27-:28), so a rename there fails in the framework before it can desynchronize this gate.
• Where it's used - runs with the architecture suite in ADC's build-and-test job.
• Caveats / not-in-source - the gate reads the checked-in appsettings.json; a value overridden by an environment variable in Azure is not seen.

ImageSizingTests

MMCA.ADC.Architecture.Tests · MMCA.ADC.Architecture.Tests.Ui · MMCA.ADC.Architecture.Tests/Ui/ImageSizingTests.cs:13 · Level 4 · class (public, sealed, partial)

• What it is - a markup-to-stylesheet drift guard for two images that can overflow a phone: the public sponsor-list logo and the badge QR code. Each fact finds the element in its .razor file, reads its Class attribute, and asserts some stylesheet rule under Source/ that names one of those classes declares the sizing the page needs (MMCA.ADC.Architecture.Tests/Ui/ImageSizingTests.cs:19, :33).
• Depends on - ArchitectureMapBase.FindRepoRoot("MMCA.ADC.slnx") for the source root (:15), System.Text.RegularExpressions through GeneratedRegex properties with a 2000 ms timeout (:85-:109), and xUnit and AwesomeAssertions.
• Concept introduced, assert the cascade without a browser. PublicSponsorListLogo_IsCappedToItsCardWidth (:19) requires a rule with max-width: 100%, height: auto and a max-height cap on the MudImage bound to sponsor.LogoUrl in PublicSponsorList.razor. MyBadgeQrCode_ShrinksToThePhoneWidthAndStaysCrisp (:33) requires max-width: 100%, height: auto and image-rendering: pixelated on the QrCodeImage in MyBadge.razor, so a scaled QR stays scannable. [Rubric §34 - Architecture Governance & Documentation] covers the enforced-not-trusted half: a responsive-layout regression fails the build instead of reaching a phone.
• Walkthrough - two facts and two helpers. ClassesOf (:46) locates the element with a regex, fails if the markup moved, and splits its Class attribute. RulesFor (:60) walks every *.css under Source/ outside bin and obj (global sheets and scoped .razor.css alike), strips comments, and returns the declaration body of each rule whose selector names one of the classes, matched with a trailing (?![\w-]) so logo does not match logo-large.
• Why it's built this way - reading CSS as text lets a plain architecture assembly check a Blazor UI it does not render. The because: text lists the classes found, so a failure names what to fix.
• Where it's used - only inside the defining file.
• Caveats / not-in-source - the rule regex excludes inner braces (:97), so a rule nested in a media query is not understood.

LegalDocumentConsistencyTests

MMCA.ADC.Architecture.Tests · MMCA.ADC.Architecture.Tests.Governance · MMCA.ADC.Architecture.Tests/Governance/LegalDocumentConsistencyTests.cs:22 · Level 4 · class (public, sealed, partial)

• What it is - the guard that ADC's legal surface cannot drift apart: the terms version the Identity service enforces, the two copies of the privacy policy, and the production legal links the UI hosts ship (MMCA.ADC.Architecture.Tests/Governance/LegalDocumentConsistencyTests.cs:41, :62, :74).
• Depends on - ArchitectureMapBase.FindRepoRoot("MMCA.ADC.slnx") (:30), System.Text.Json for the settings files (JsonOptions skips comments and allows trailing commas, :24-:28), a source-generated regex for the effective date (:132), and xUnit and AwesomeAssertions.
• Concept introduced, documents as executable contracts. CurrentTermsVersion_IsPrintedVerbatimInTermsHtml (:41) reads Legal:CurrentTermsVersion from the Identity service's appsettings.json, requires it non-blank (an empty value silently turns terms acceptance off), and asserts the Gateway's wwwroot/terms.html contains it verbatim. PrivacyMarkdownAndPrivacyHtml_StateTheSameEffectiveDate (:62) parses the Effective date: line of PRIVACY.md and of privacy.html with ReadEffectiveDate (:114, format MMMM d, yyyy) and requires them equal. The [Theory] ProductionLegalUrls_AreAbsoluteHttpsOnAPublicHost_AndPointAtTheGatewayPages (:74) runs over ProductionLegalSettingsFiles (:34, the Web host's appsettings.Production.json and the MAUI host's appsettings.json) and calls AssertPublicHttpsUrl (:90) for TermsUrl (suffix /terms), PrivacyUrl (/privacy) and DeleteAccountUrl (/delete-account), plus CodeOfConductUrl when present: absolute, https, and not a local host (IsLocalHost, :109). [Rubric §30 - Compliance/Privacy/Data Governance] assesses whether legal commitments stay consistent with what ships.
• Walkthrough - three guards, one per drift path: version against the page the user reads, markdown against html copy, and configuration against the Gateway's pages.
• Why it's built this way - the assertion messages state the maintenance rule ("when the terms change, update terms.html and bump the version together", :55-:58), so the failure is the instruction.
• Where it's used - only inside the defining file.
• Caveats / not-in-source - the version check is a substring test, so 1.1 would also pass against a page that prints 1.10.

MauiHostShellTests

MMCA.ADC.Architecture.Tests · MMCA.ADC.Architecture.Tests.Ui · MMCA.ADC.Architecture.Tests/Ui/MauiHostShellTests.cs:18 · Level 4 · class (public, sealed, partial)

• What it is - four text-level guards over the MAUI head's native shell, which the architecture assembly does not reference: the Android camera intent query, the pre-theme host page background, a language-neutral loading placeholder, and the Android App Links path restrictions (MMCA.ADC.Architecture.Tests/Ui/MauiHostShellTests.cs:26, :42, :61, :77).
• Depends on - ArchitectureMapBase.FindRepoRoot("MMCA.ADC.slnx") to locate Source/Hosts/UI/MMCA.ADC.UI (:22), System.Xml.Linq for the manifest (the Android namespace, :20), and GeneratedRegex properties (:126-:160). It is the sibling of MobileHostParityTests, which guards the hostnames.
• Concept introduced, platform requirements as tests. AndroidManifest_DeclaresTheImageCaptureIntentQuery (:26) requires a <queries><intent><action> for android.media.action.IMAGE_CAPTURE, because on Android 11+ the camera app is invisible to MediaPicker.CapturePhotoAsync without it and Take photo silently does nothing. HostPage_DoesNotPaintALightBackgroundBeforeTheThemeApplies (:42) joins the inline styles of wwwroot/index.html with app.css and requires the html/body rule to be transparent, or a prefers-color-scheme: dark block plus a background. HostPage_LoadingPlaceholderIsLanguageNeutral (:61) takes the text between the #app root and the first <script, strips tags, and requires no letter (\p{L}), since it renders before localization exists. AndroidAppLinks_ClaimOnlyTheDeepLinkablePaths (:77) finds each [IntentFilter] mentioning PublicWebHost in MainActivity.cs, resolves its DataPathPrefix values through PathPrefixValues (:105, literals and const string names), requires them non-empty, requires /conference/, /happening-now, /feedback/ and /auth/oauth-complete to be claimed, and forbids /, empty and /login*. [Rubric §34 - Architecture Governance & Documentation] is the enforced-not-trusted half.
• Walkthrough - four facts; the fourth is the interesting one, because an App Links filter with no path restriction claims the whole host, so /login would open the app instead of the browser.
• Why it's built this way - each assertion's because: records the platform failure it prevents, the part a reader cannot infer from the attribute or CSS alone.
• Where it's used - only inside the defining file.
• Caveats / not-in-source - these are regex reads of source text, not a build of the MAUI head; a differently shaped IntentFilter declaration would need the regexes revisited.

UIModuleNavItems

MMCA.ADC.Architecture.Tests · MMCA.ADC.Architecture.Tests.Api · MMCA.ADC/Tests/Architecture/MMCA.ADC.Architecture.Tests/Api/NavItemGuardContractTests.cs:460 · Level 2 · record (private, sealed, nested)

• What it is - the nav items read from one ADC UI module: Name, RelativePath (the module's source file), Items (IReadOnlyList<NavItem>) and Problems (strings for anything that could not be read) (NavItemGuardContractTests.cs:460).
• Depends on - NavItem and IUIModule from MMCA.Common.UI; nested in NavItemGuardContractTests.
• Concept introduced, two read paths, one result shape. ReadModule (:156) instantiates the module and reads NavItems when its assembly is next to the test binaries (:159-:165); otherwise ReadModuleFromSource (:185) parses the NavItems { get; } = [ ... ]; initializer with regexes, which is how the MAUI head's DeviceUIModule is covered although a net10.0 test project cannot reference it. Both return this record, and Problems carries unreadable entries (:190, :204) so NavItems_AreReadFromEveryUIModule_GateIsNotVacuous (:55) fails instead of skipping them.
• Where it's used - only inside the defining file: DiscoverModules (:139) builds the list that the three facts iterate.

MobileHostParityTests

MMCA.ADC.Architecture.Tests · MMCA.ADC.Architecture.Tests.Ui · MMCA.ADC.Architecture.Tests/Ui/MobileHostParityTests.cs:16 · Level 4 · class (public, sealed, partial)

• What it is - the drift guard over the production hostnames the MAUI head hardcodes in four places no compiler connects: Api:ApiEndpoint and PublicSite:BaseUrl in the embedded appsettings.json, the Android App Links host MainActivity.PublicWebHost, and the iOS applinks: associated-domains entitlement (MMCA.ADC/Tests/Architecture/MMCA.ADC.Architecture.Tests/Ui/MobileHostParityTests.cs:6-:15). Unlike the other UI rules in this unit it derives from no shared base: it is an ADC-only test with one fact.
• Depends on - ArchitectureMapBase.FindRepoRoot("MMCA.ADC.slnx") to locate Source/Hosts/UI/MMCA.ADC.UI from the compiled test assembly (MobileHostParityTests.cs:36-:37), and the BCL System.Text.Json and System.Text.RegularExpressions (:1-:2). Externals: xUnit v3 and AwesomeAssertions, global-used across the assembly (MMCA.ADC.Architecture.Tests/GlobalUsings.cs:1-:5).
• Concept introduced, a cross-file configuration parity check. The four values live in a JSON file, a C# constant and a plist, so a type system cannot tie them together; only a test that reads all three files can. The rule states two different relationships. The web UI serves the app-link association, so PublicSite:BaseUrl, the Android host and the iOS applinks: host must be the identical host. The API endpoint is the gateway, a different app, so it is only required to share the Container Apps environment domain with the web host (:10-:13). [Rubric §34 - Architecture Governance & Documentation] covers the enforced-not-trusted half: an environment move or a custom-domain cutover that misses one spot fails the build instead of shipping a mobile build whose deep links or API calls point at the old environment (:13-:14).
• Walkthrough - one fact and four helpers.
  • PublicSiteAndAppLinkHosts_AreIdentical_AndTheApiSharesTheirEnvironment (:33-:59) parses appsettings.json with JsonOptions (comments skipped, trailing commas allowed, :27-:31) and takes the Host of Api:ApiEndpoint and PublicSite:BaseUrl (:39-:43); today those are the adc-prod-gateway and adc-prod-ui hosts (MMCA.ADC/Source/Hosts/UI/MMCA.ADC.UI/appsettings.json:20, :23). It reads Platforms/Android/MainActivity.cs and Platforms/iOS/Entitlements.plist as text (:45-:52), whose declarations sit at MMCA.ADC/Source/Hosts/UI/MMCA.ADC.UI/Platforms/Android/MainActivity.cs:44 and MMCA.ADC/Source/Hosts/UI/MMCA.ADC.UI/Platforms/iOS/Entitlements.plist:11. It then asserts Android equals the public-site host, iOS equals the public-site host, and the environment domains of the API and public-site hosts are equal, each with a because: that names the platform requirement (:54-:58).
  • SingleCapture (:61-:66) requires exactly one match before returning the host group, so a duplicated or missing declaration fails with "exactly one declaration of {what} is expected" rather than silently comparing the first hit.
  • EnvironmentDomain (:68-:69) strips everything up to the first dot, turning adc-prod-ui.<env>.eastus2.azurecontainerapps.io into <env>.eastus2.azurecontainerapps.io.
  • AndroidPublicWebHost and IosAppLinksHost (:71-:75) are GeneratedRegex properties with ExplicitCapture and a 2000 ms match timeout, matching PublicWebHost = "..." and <string>applinks:...</string> respectively.
• Why it's built this way - reading the platform files as text rather than compiling them is what lets an architecture test assembly check a MAUI head it does not reference (the MAUI head is not in ADC's CI solution filter, which lists this test project at MMCA.ADC/MMCA.ADC.CI.slnf:59). The MainActivity constant carries its own comment pointing back at PublicSite:BaseUrl (MainActivity.cs:37), and this test is what makes that comment binding.
• Where it's used - no usage outside the defining file; it runs with the rest of the architecture suite in the build-and-test job (MMCA.ADC/.github/workflows/deploy.yml:220), whose test step runs dotnet test --solution MMCA.ADC.CI.slnf (:346).
• Caveats / not-in-source - the environment check compares everything after the first label, so it assumes both hosts are single-label app names under the same environment suffix; a custom domain that is not shaped <app>.<environment domain> would need the rule revisited. Not determinable from source: whether an Android AndroidManifest intent filter or other platform files carry the host as well (the test reads only the three files named above).

NavigationContractTests

MMCA.ADC.Architecture.Tests · MMCA.ADC.Architecture.Tests.Api · MMCA.ADC/Tests/Architecture/MMCA.ADC.Architecture.Tests/Api/NavigationContractTests.cs:20 · Level 4 · class (public, sealed, partial)

• What it is - ADC's navigation drift gate (rubric §25): the ## Route Contract table in adc-NavigationFlow.md must list exactly the routable pages ADC ships, each row's Access word must match the page's guard, and every page must state its guard as exactly one recognized attribute. It is the ADC counterpart of the framework's own same-named gate in MMCA.Common.Architecture.Tests.Ui, a different class.
• Depends on - ArchitectureMapBase.FindRepoRoot("MMCA.ADC.slnx") (NavigationContractTests.cs:28), the nested records PageRoute, ContractRow and ContractTable (:328-:332), GeneratedRegex properties (:296-:325), and xUnit and AwesomeAssertions. Unlike the framework gate it reflects over nothing: it scans *.razor source text.
• Concept introduced, documentation as an executable contract, read from source text. The doc lives in the Website repo, not next to the code, so ResolveDocPath (:288) reads it from the ADC_NAVIGATION_DOC environment variable (DocVariable, :23) and otherwise from ../Website/docs-src/guides/adc-NavigationFlow.md (DefaultDocPath, :30-:31); the existence assertion in ReadContractTable (:243) says CI downloads the published copy and sets the variable. [Rubric §25 - Navigation & IA] is the target; [Rubric §11 - Security] and [Rubric §26 - Front-End Security] apply because the guard column is verified against [AllowAnonymous], [Authorize] and [Authorize(Roles = RoleNames.Organizer)].
• Walkthrough - a floor MinimumRoutes = 55 (:22) and five facts.
  • RoutablePages_AreDiscovered_GateIsNotVacuous (:38) requires at least 55 discovered routes (59 when written), so a moved tree cannot let the gate pass over nothing.
  • EveryRoutablePage_DeclaresARecognizedAccessAttribute (:44) reports pages whose Classify produced a violation (none, several, or an unrecognized attribute, :207) and any route declared by more than one page.
  • EveryRoutablePage_IsInTheRouteContract_AndEveryContractRoute_Exists (:63) compares route sets both ways, undocumented and phantom, verbatim including constraints such as {Id:int}.
  • EveryContractAccess_MatchesThePageGuard (:79) compares each row's Access with the page's classified guard, skipping rows the other facts already report.
  • RouteContractTable_IsWellFormed (:107) surfaces Problems, duplicate route rows, Access words outside Anonymous, Authenticated and Organizer, and Page cells that are neither - nor the declaring file's name.
  • Discovery is DiscoverPageRoutes (:139, internal static so NavItemGuardContractTests reuses it to read ADC's pages, :332): every *.razor under Source/ outside bin and obj (IsSourceFile, :170) with an @page line; access comes from @attribute lines, else from attribute lines above the matching partial class in the .razor.cs (ReadCodeBehindAccessAttributes, :180).
• Why it's built this way - the failure messages name the remedy and its order ("landing that change before or with the code change"), so a missing row is a documentation task, not a mystery.
• Where it's used - runs in ADC's architecture suite; a checkout without the Website repo and without ADC_NAVIGATION_DOC fails at ReadContractTable's existence assertion (:243).
• Caveats / not-in-source - the code-behind lookup scans attribute lines directly above the first partial class matching the page name; an attribute placed elsewhere reads as no guard.

SpanishAccentTests

MMCA.ADC.Architecture.Tests · MMCA.ADC.Architecture.Tests.Governance · MMCA.ADC.Architecture.Tests/Governance/SpanishAccentTests.cs:9 · Level 4 · class (public, sealed)

• What it is - the Spanish-localization gate for ADC: no *.es.resx string may ship a common word with its accent or n-tilde missing. It overrides one member, ResourceRoot, as Source/ under the repo root found by ArchitectureMapBase.FindRepoRoot("MMCA.ADC.slnx") (MMCA.ADC.Architecture.Tests/Governance/SpanishAccentTests.cs:11-:12).
• Depends on - SpanishAccentTestsBase (see the per-project rollup; MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Bases/Governance/SpanishAccentTestsBase.cs:27) and ArchitectureMapBase.
• Concept introduced, a localization defect that every functional test misses. An unaccented word compiles, renders and passes behavior tests, so a Spanish-speaking user finds it. The base's single fact Spanish_resources_keep_their_accents (SpanishAccentTestsBase.cs:68) enumerates *.es.resx under the root outside build output, requires at least MinimumResourceFileCount (default 1, :64) so a wrong root cannot pass vacuously, builds one whole-word case-insensitive regex from UnaccentedWords (default list :32, extendable per consumer, :51), and checks only string <value> text, not keys or comments. AllowedEntries (:58) holds deliberate exceptions as {path}:{key}. ADC overrides neither, so it takes the framework list and no exceptions. [Rubric §34 - Architecture Governance & Documentation] covers the enforced-not-trusted half.
• Walkthrough - one override; the rule is inherited.
• Why it's built this way - the word list leaves out words correct both ways (esta, solo) and plurals that drop the accent by rule (SpanishAccentTestsBase.cs:20-:23), trading recall for a gate with no false positives.
• Where it's used - runs with the architecture suite in ADC's build-and-test job; the framework's own SpanishAccentTests subclasses the same base.
• Caveats / not-in-source - only the listed words are caught; a missing accent on any other word passes.

NavItemGuardContractTests

MMCA.ADC.Architecture.Tests · MMCA.ADC.Architecture.Tests.Api · MMCA.ADC.Architecture.Tests/Api/NavItemGuardContractTests.cs:41 · Level 5 · class (public, sealed, partial)

• What it is - the menu-to-page guard contract: every sidebar entry an ADC UI module contributes must be no looser than the guard of the page it opens, so the menu never offers a link the page will refuse. Three facts enforce it: the nav items were actually read, every item opens a routable page, and every item requires at least what that page's guard enforces (MMCA.ADC.Architecture.Tests/Api/NavItemGuardContractTests.cs:54-:106). The contract is written out in the class summary (:16-:40).
• Depends on - IUIModule and NavItem (with NavSection) for the menu side, NavigationContractTests for ADC's own page routes and access classification (NavigationContractTests.DiscoverPageRoutes, called at :318), RoleNames for the Organizer role, and ArchitectureMapBase for FindRepoRoot("MMCA.ADC.slnx") (:45). It takes no architecture map.
• Concept introduced, comparing two guards that are written in different places. A navigation entry and the page behind it each carry an access decision, declared independently, so nothing in a single file notices when the menu shows a signed-out visitor a link that ends in a sign-in challenge. The shared NavMenu shows an item to a caller who satisfies its RequiredRole, RequiredClaim and RequiredPermission (each only when set), and shows the User and Admin sections to signed-in callers only, so an item counts as anonymous exactly when it sets none of the three and sits in NavSection.General (:116). Compare (:108-:136) then yields a problem per rule: an authenticated page needs a non-anonymous item, a page naming roles needs an item requiring one of them (no permission or claim implies a role statically, because the role-to-permission map is editable at runtime), and a page requiring a claim or a permission needs an item carrying the same one. [Rubric §25] is the section the assertion messages cite (:71, :85, :105); [Rubric §11 - Security] and [Rubric §26 - Front-End Security] apply because the pages are the authorization boundary and the menu must not contradict it.
• Walkthrough - three facts, then the readers behind them.
  • NavItems_AreReadFromEveryUIModule_GateIsNotVacuous (:54-:72) fails when no IUIModule implementation is found under Source/, when a module reports a read problem, or when zero items were read in total, so the gate cannot pass by reading nothing.
  • EveryNavItem_OpensARoutablePage (:74-:86) fails on a dead link: an item whose Href matches no @page route, which would also make the guard comparison pass without checking anything.
  • EveryNavItem_IsNoLooserThanTheGuardOfThePageItOpens (:88-:106) runs Compare for each item against every page its Href resolves to. The failure message says to fix the nav item (add the role, claim or permission, or move it to the User or Admin section), never to loosen the page guard.
  • DiscoverModules (:139-:154) finds module classes in source with ModuleDeclarationRegex (:442), skipping bin and obj (:435-:440). ReadModule (:156-:169) uses the real instance (Activator.CreateInstance, .NavItems) when the owning project's assembly sits beside the test binary (FindOwningAssemblyName, :171-:183), and otherwise ReadModuleFromSource (:185-:209). That fallback exists for the MAUI head's DeviceUIModule, which a net10.0 test project cannot reference (:34-:39). It parses the NavItems { get; } = [ ... ]; initializer with generated regexes (:442-:458), splits arguments depth-aware (SplitArguments, :283-:313) and resolves only string literals, null, RoleNames.* and NavSection.* (TryResolveValue, :250-:281). An entry it cannot resolve is reported as a problem, so it fails the first fact instead of being skipped (ParseEntry, :211-:245).
  • DiscoverGuardedPages (:316-:337) builds the page side two ways. ADC's own routable components come from NavigationContractTests, whose access string (Anonymous, Authenticated, Organizer) is mapped to a PageGuard (:318-:326). The framework's routable components in MMCA.Common.UI are read by reflection: ReadComponentGuard (:350-:404) collects [Authorize] roles and, for each named policy, walks the policy requirements. It understands deny-anonymous, roles, a single-value permission claim, any other claim type, and NotificationPageRequirement by type name (:376-:399).
  • RouteMatches (:407-:433) compares segment by segment, case-insensitively, treating {param} as a wildcard, {*catchall} as matching the rest, and trailing {x?} as optional; the query string and fragment are stripped first (:409).
• Why it's built this way - policies are read from the real registration rather than restated: ReadFrameworkAuthorizationOptions builds a ServiceCollection, calls AddUIShared, and pulls AuthorizationOptions from the provider (:339-:348), so the gate follows the framework's actual policy. An unrecognized requirement type returns a problem naming itself ("teach NavItemGuardContractTests what it enforces", :397) instead of silently passing. The unresolved cases always fail loudly: that is the design rule that keeps a contract test from going vacuous.
• Where it's used - runs with the architecture suite; the nav items it reads come from the Identity, Conference, Engagement and device UI modules, for example MMCA.ADC/Source/Modules/Identity/MMCA.ADC.Identity.UI/IdentityUIModule.cs.
• Caveats / not-in-source - the source reader understands only literal forms; a nav item built from a constant or a helper must be rewritten in literal form or its module referenced by the test project. The comparison is static on roles, so it cannot prove a permission-gated item reaches a role-gated page.

AnonymousEndpointTests

MMCA.ADC.Architecture.Tests · MMCA.ADC.Architecture.Tests.Api · MMCA.ADC.Architecture.Tests/Api/AnonymousEndpointTests.cs:23 · Level 6 · class (public, sealed)

• What it is - the security gate that no endpoint loses its authorization unnoticed: every [AllowAnonymous] reachable in ADC's three module API assemblies and three module UI assemblies must appear as a reviewed line in this file (MMCA.ADC.Architecture.Tests/Api/AnonymousEndpointTests.cs:25-:33, :35-:131). It is the largest subclass in the unit: 60 allowlist entries covering controllers and routable pages alike.
• Depends on - AnonymousEndpointTestsBase, System.Reflection.Assembly (global-used at MMCA.ADC.Architecture.Tests/GlobalUsings.cs:1), and, as type references pinning the three API assemblies, IdentityModule, ConferenceModule, and EngagementModule (:27-:29). The three UI assemblies are loaded by name (:30-:32). Note it does not take the map: it names its own assembly set.
• Concept introduced, the reviewed-allowlist gate. The rules elsewhere in this unit assert a structural property. This one asserts a review property: the set of anonymous endpoints is not wrong, it is simply not allowed to change silently. The base makes that stick in three directions at once: AnonymousEndpoints_AreAllowListed fails on an unlisted [AllowAnonymous] (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Bases/Api/AnonymousEndpointTestsBase.cs:80), ScannedEndpointSet_IsNotEmpty fails when fewer than MinimumScannedTypes endpoint types were discovered at all (:92), and AllowList_HasNoStaleEntries fails on a listed entry that no longer matches anything (:105), which is what stops the list from silently accumulating names for endpoints that were renamed or re-gated. [Rubric §11 - Security] assesses whether the authorization posture is deliberate and verifiable; an allowlist that must be edited, in a file a reviewer reads, is the mechanism. [Rubric §26 - Front-End Security] applies too, because routable Blazor components are scanned alongside controllers.
• Walkthrough - four members.
  • TargetAssemblies (:25-:33) names six assemblies: the Identity, Conference, and Engagement API assemblies by anchor type, and the matching three UI assemblies via Assembly.Load. The base scans each for the two shapes it understands, MVC controllers (any type whose base chain reaches ControllerBase, AnonymousEndpointTestsBase.cs:156-:170) and routable Blazor components (any type carrying a RouteAttribute, :172-:176), both matched by attribute full name so the rule library keeps no ASP.NET reference (:34-:35).
  • AllowedAnonymousEndpoints (:35-:131) is the reviewed list, grouped by justification rather than alphabetically. Two Identity credential-exchange actions on AuthController, LoginAsync and RegisterAsync, because requiring a token to mint one would be circular; they are throttled by the auth-ip rate-limit policy instead (:37-:41). Then the Conference public-browse reads: the GetAllAsync / GetAllForLookupAsync / GetByIdAsync triple on fourteen agenda controllers (ActivitiesController, CategoryItemsController, EventsController, PartnersController, QuestionsController, RoomsController, SessionsController, SpeakersController, SponsorsController, and their category and join siblings, :47-:88), because the conference website is readable without an account and is output-cached per ADR-040; the comment is careful to note that every create/update/delete on those same controllers stays behind the class-level [HasPermission] (:43-:46). Then the session-materials read on SessionAssetsController.GetBySessionAsync (:95), part of the public session page and output-cached like the agenda reads above, scoped by the same public-session projection so a session the public cannot see answers an EMPTY list rather than leaking one; every write on that controller stays behind [Authorize] and is re-authorized in the handler against the session's own speaker list (:90-:94). Then three smaller families with their own reasons: the Now/Next wayfinding reads (:97-:100), the ICS calendar exports a calendar client fetches without a bearer token (:102-:105), and the aggregate bookmark counts behind the popularity badge, counts only and never a per-user list (:107-:110). Then the type-level entry for ServiceInfoController, which must answer before a caller has a token to negotiate with (:114). Last, the eight public conference-website pages (PublicActivityList, PublicEventDetail, PublicEventList, PublicSessionDetail, PublicSessionList, PublicSpeakerDetail, PublicSpeakerList, PublicSponsorList, :123-:130) that render the agenda, speakers, sponsors and activities a visitor browses before creating an account. Type-level and method-level attributes use different identifier shapes, a bare FullName versus FullName.MethodName, which is why the ServiceInfoController entry and the page entries carry no method suffix.
  • RequireExplicitAuthorizationDecision => true (:139) is SEC-ADC-03: an endpoint carrying neither [Authorize] nor [AllowAnonymous] is invisible to the allowlist check above, exactly the shape a forgotten [Authorize] produces. The base now defaults the same way (AnonymousEndpointTestsBase.cs:69, backed by Endpoints_DeclareAnAuthorizationDecision at :119), so the ADC override restates the default explicitly. On a controller the framework's fallback authorization policy also closes the gap at run time; on a routable page nothing does, because AuthorizeRouteView reads attributes and ignores the fallback entirely, so for pages this flag is the only control (AnonymousEndpointTests.cs:133-:138).
  • MinimumScannedTypes => 80 (:144) raises the base floor of 1 (AnonymousEndpointTestsBase.cs:52) to the exact count of controller and routable-component types across the six assemblies today, SessionAssetsController included, so a renamed assembly or a dropped surface is a failure rather than a quietly smaller scan (:141-:143).
• Why it's built this way - the class comment explains what the absences mean, which is the part a reader cannot infer. The two password-recovery actions on PasswordResetController and the two email-confirmation actions on EmailConfirmationController (ADR-116) are anonymous for the same circularity reason as login, but ADC does not override them, so the framework bases own their allowlist entries and none appear here (:11-:16); the same is true of refresh (:39). The base reads attributes with DeclaredOnly and inherit: false precisely so an inherited framework action is reported once at its declaration site rather than once per derived controller in every consumer (AnonymousEndpointTestsBase.cs:262-:264). Notification is absent because that module ships no controller and no routable component, hosting only the SignalR hub, so it contributes nothing to the scan (:18-:21).
• Caveats / not-in-source - the base states its own blind spot: minimal-API endpoints opt out through the .AllowAnonymous() builder call, which produces endpoint metadata at map time and is invisible to static reflection, so the framework's own small anonymous minimal-API surface (JWKS, OIDC discovery, app-association, session-cookie refresh, health) is not covered here (AnonymousEndpointTestsBase.cs:18-:24). Nothing recomputes the 80 floor, so it is a lower bound a human maintains.

InlineStyleTests

MMCA.ADC.Architecture.Tests · MMCA.ADC.Architecture.Tests.Ui · MMCA.ADC.Architecture.Tests/Ui/InlineStyleTests.cs:10 · Level 6 · class (public, sealed)

• What it is - the gate that no .razor file under Source/ carries an inline style=/Style=/...StyleFunc= attribute, so every visual rule lives in a stylesheet (adc-ui.css or a component's scoped .razor.css) instead of scattered inline across markup. ADC's class is now a thin subclass of the framework's shared base (MMCA.ADC/Tests/Architecture/MMCA.ADC.Architecture.Tests/Ui/InlineStyleTests.cs:10-:16).
• Depends on - InlineStyleTestsBase (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Bases/Ui/InlineStyleTestsBase.cs:12) and ArchitectureMapBase.FindRepoRoot to locate the repo root from the compiled test assembly (InlineStyleTests.cs:12).
• Concept introduced, a text scan authored once and re-run per repo. The other UI fitness functions in this unit (BrandColorTokenTests, SortableColumnConventionTests) read a compiled artifact; this one reads source .razor files, because inline styles are a markup-authoring concern that never survives into a compiled component in a form worth inspecting. The scan itself lives in ArchitectureRules.RazorMarkupCarriesNoInlineStyles (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Rules/Ui/ArchitectureRules.InlineStyles.cs:37), which the base's single fact RazorMarkup_CarriesNoInlineStyles calls (InlineStyleTestsBase.cs:30-:31) with the subclass's MinimumRazorFiles floor. The floor is 80 (InlineStyleTests.cs:15, "enough to prove the scan actually walked the UI tree, three module UI projects and both heads"), so a moved or renamed Source/ root fails loudly rather than passing on zero files scanned. [Rubric §20 - Design System & Theming] is the direct target: a single source of truth for styling is what an inline style= attribute bypasses outright, and [Rubric §34 - Architecture Governance & Documentation] covers the enforced-not-trusted half.
• Walkthrough - two overrides and one inherited fact. RepoRoot (InlineStyleTests.cs:12) is ArchitectureMapBase.FindRepoRoot("MMCA.ADC.slnx"), implementing the base's abstract root (InlineStyleTestsBase.cs:14-:15), and MinimumRazorFiles => 80 (:15) implements the abstract floor (InlineStyleTestsBase.cs:18). The inherited RazorMarkup_CarriesNoInlineStyles (InlineStyleTestsBase.cs:30) passes MarkupRoots and AllowedInlineStyles to the rule; ADC adds no allow-list, as the class summary states ("No allow-list: a genuinely dynamic value belongs in a class toggled from code or a CSS custom property", InlineStyleTests.cs:3-:8).
• Why it's built this way - a component-parameter convention (Style="..." on a MudBlazor component, say) is textually indistinguishable from the native HTML style= attribute, so the rule catches both the same way a reviewer scanning markup would, rather than special-casing every UI library's parameter names. Moving the regex and file walk into the shared base means MMCA.Common and ADC run one implementation and differ only in root and floor.
• Where it's used - runs with the rest of the suite in the build-and-test job (MMCA.ADC/.github/workflows/deploy.yml:189, :284).
• Caveats / not-in-source - the exact regex and its lookbehind now live in the shared rule, not in this class; the rule file was not re-read for this section beyond its signature, so its false-positive heuristics are Not determinable from this unit's source.

LifetimeTokenConventionTests

MMCA.ADC.Architecture.Tests · MMCA.ADC.Architecture.Tests.Ui · MMCA.ADC.Architecture.Tests/Ui/LifetimeTokenConventionTests.cs:10 · Level 6 · class (public, sealed)

• What it is - the component-lifetime gate for ADC's module UI code: no component under Source/Modules reads _cts.Token directly (MMCA.ADC/Tests/Architecture/MMCA.ADC.Architecture.Tests/Ui/LifetimeTokenConventionTests.cs:10-:17).
• Depends on - LifetimeTokenConventionTestsBase (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Bases/Ui/LifetimeTokenConventionTestsBase.cs:13) and ArchitectureMapBase.FindRepoRoot (LifetimeTokenConventionTests.cs:13).
• Concept introduced, reading a cancellation token off a disposed source. Reading Token off a disposed CancellationTokenSource throws ObjectDisposedException and crashes the Blazor circuit after a navigation away, so components must read it as _cts.LifetimeToken() (MMCA.Common.UI) or through a LifetimeToken property (LifetimeTokenConventionTestsBase.cs:6-:9). The rule ArchitectureRules.ComponentsReadTheirTokenThroughLifetimeToken (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Rules/Ui/ArchitectureRules.LifetimeTokens.cs:28) does the scan; the base's single fact Components_ReadTheirTokenOnlyThroughLifetimeToken (LifetimeTokenConventionTestsBase.cs:28-:29) calls it with the subclass's scan root and file floor. [Rubric §34 - Architecture Governance & Documentation] covers the enforced-not-trusted half.
• Walkthrough - two overrides and one inherited fact. ScanRoot (LifetimeTokenConventionTests.cs:12-:13) is Source/Modules under the repo root found via FindRepoRoot("MMCA.ADC.slnx"), and MinimumCodeBehindFiles => 60 (:16, "enough to prove the scan actually walked the module UI code-behind, three module UI projects") is the vacuity floor, so a moved root cannot pass on zero files (LifetimeTokenConventionTestsBase.cs:18-:19). The base's optional ScanAllCodeFiles (:25) stays at its default false, so only .razor and .razor.cs files are scanned (:21-:25).
• Why it's built this way - authored once in the framework and re-run as a thin subclass in each repo, which supplies only the root and the floor (LifetimeTokenConventionTestsBase.cs:9-:11); MMCA.Common has its own subclass of the same base.
• Caveats / not-in-source - the rule's matching details are not re-read here, so how it treats a token read through a helper other than LifetimeToken is Not determinable from this unit's source.

ProtoContractTests

MMCA.ADC.Architecture.Tests · MMCA.ADC.Architecture.Tests.Contracts · MMCA.ADC.Architecture.Tests/Contracts/ProtoContractTests.cs:3 · Level 6 · class (public, sealed)

• What it is - the frozen wire contract for ADC's synchronous cross-service API. It names the eight .proto files the four *.Contracts projects compile and commits a 99-line snapshot of everything they declare, so a renumbered field or a renamed rpc fails the build (MMCA.ADC.Architecture.Tests/Contracts/ProtoContractTests.cs:9-:19, :21-:122).
• Depends on - ProtoContractTestsBase. Nothing else: the rule reads .proto files off disk from the repo root, so this class takes no map and the csproj needs no reference to the *.Contracts projects.
• Concept introduced, pinning a contract that no compiler checks. A .proto file is a published contract between processes that are built separately, so nothing in a single repo's build notices when it changes incompatibly. The rule library rebuilds the live contract by parsing the files and diffs it against the committed list, reporting each side separately as "present in the .proto files but NOT frozen" and "frozen but NOT present in the .proto files" (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Rules/Contracts/ArchitectureRules.Protos.cs:68-:77). What gets pinned is exactly the wire surface: the package, every rpc with its request/response types and streaming flags, every message field with its declared type, label, and field number, and every enum value with its number (ArchitectureRules.Protos.cs:22-:24). What is deliberately not pinned is syntax, import, and option lines including csharp_namespace, because none of them changes a byte on the wire and failing on them is the fastest way to teach a team to update a snapshot without reading it (:27-:31). [Rubric §9 - API & Contract Design] assesses contract governance across the whole surface, not just REST. [Rubric §7 - Microservices Readiness]: this list is the synchronous coupling between ADC's four services, in the same way IntegrationEventContractTests is the asynchronous one (ADR-007).
• Walkthrough - three members, all implementing abstract hooks.
  • SolutionFileName => "MMCA.ADC.slnx" (:5) implements ProtoContractTestsBase.SolutionFileName (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Bases/Contracts/ProtoContractTestsBase.cs:22). The rule resolves the repo root from it via ArchitectureMapBase.FindRepoRoot (ArchitectureRules.Protos.cs:46), so the files are read from the working tree regardless of the runner's working directory.
  • ProtoFiles (:9-:19) lists eight repo-root-relative paths, and the comment states the scope rule: every .proto compiled by the four *.Contracts projects (:7-:8). Three from Conference (event_live_validation, session_bookmark_validation, user_conference_export), two from Engagement (bookmark_count, user_engagement_export), one from Identity (attendee_query), and two from Notification (live_channel, user_notification_export).
  • FrozenProtoContracts (:21-:122) is the snapshot: 85 message ... lines (:23-:107), one per field, each ending in = <number> : <type>, and 14 service ... lines (:108-:121), one per rpc. The entries are sorted, which is what makes a regenerated snapshot diff line by line, and the base's <remarks> explains how to regenerate it (print ArchitectureRules.BuildProtoContract(...) and paste, ProtoContractTestsBase.cs:12-:17). Reading the list is the fastest way to see what ADC's services actually say to each other: live-window validation, current-room lookup, sponsor live info and the overlapping-session lookup from Conference (GetOverlappingSessionIds, :110), plus its per-user event and session answer export (UserConferenceExportService, :23-:30, :58-:60, :115), bookmark counts and the engagement export from Engagement (the export response now also carries poll_votes = 7 and question_upvotes = 8, with their own EngagementPollVoteExportItem and EngagementQuestionUpvoteExportItem messages, ProtoContractTests.cs:91-:92, :73-:77), the attendee user-id list from Identity, and channel push plus the notification export from Notification.
  • The single inherited fact is ProtoContracts_ShouldMatch_TheFrozenSnapshot (ProtoContractTestsBase.cs:33).
• Why it's built this way - the base is explicit that this is consumer-facing only: MMCA.Common ships the gRPC plumbing but no .proto of its own, so the framework does not subclass it, and a repo with a *.Contracts project does (ProtoContractTestsBase.cs:9-:11). The four *.Contracts projects are not registered in AdcArchitectureMap at all: this rule works from file paths rather than mapped assemblies, which is why it reaches them anyway.
• Caveats / not-in-source - the file list is hand-maintained, so a brand-new .proto added to a *.Contracts project is not pinned until someone lists it here. Nothing asserts that ProtoFiles covers every .proto in the tree.

SortableColumnConventionTests

MMCA.ADC.Architecture.Tests · MMCA.ADC.Architecture.Tests.Ui · MMCA.ADC.Architecture.Tests/Ui/SortableColumnConventionTests.cs:11 · Level 6 · class (public, sealed)

• What it is - the MudDataGrid sorting guard: a column marked sortable must be a PropertyColumn, not a TemplateColumn. The subclass supplies one scan root, the whole ADC Source tree (MMCA.ADC.Architecture.Tests/Ui/SortableColumnConventionTests.cs:14-:17).
• Depends on - SortableColumnConventionTestsBase, and ArchitectureMapBase called statically for the repo root (:16). Like ProtoContractTests and TranslationCompletenessTests, it takes no map: the rule is a markup text scan, so a directory is all it needs.
• Concept introduced, guarding a defect that renders correctly. Server-side sort reads the bound property off the column, and a TemplateColumn has none, so Sortable="true" on one produces a header that toggles a sort arrow without ordering the data (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Bases/Ui/SortableColumnConventionTestsBase.cs:4-:8). The defect compiles, renders, and stays invisible until somebody checks the order, which is the exact profile of a bug a fitness function should own rather than a code review. [Rubric §24 - Forms/Validation/UX Safety] is the base's own stated target, since an affordance that lies to the user is a UX-safety failure; [Rubric §18 - UI Architecture] and [Rubric §12 - Performance & Scalability] are the neighbours, because the whole point of server-side sort is to keep the grid from pulling the full set into the browser.
• Walkthrough - one member. MarkupRoots (:14-:17) is a single-element collection expression: Path.Combine(ArchitectureMapBase.FindRepoRoot("MMCA.ADC.slnx"), "Source"). Building the path from FindRepoRoot rather than a relative path is what makes the scan independent of the runner's working directory (SortableColumnConventionTestsBase.cs:19-:23), and pointing it at the whole Source tree rather than one project is what makes it cover the three module UI projects and both web heads, which the class comment states explicitly (SortableColumnConventionTests.cs:7-:9). The inherited fact is SortableColumns_ShouldNotBe_TemplateColumns (SortableColumnConventionTestsBase.cs:27), delegating to ArchitectureRules.SortableGridColumnsUsePropertyColumn(MarkupRoots). The base notes that @* *@ comments are ignored and that a root which does not exist fails the test rather than silently passing (:12-:13).
• Why it's built this way - the class comment records that ADC already used PropertyColumn for every sortable column when the rule was adopted, so this subclass freezes an already-clean state rather than pinning debt (SortableColumnConventionTests.cs:7-:8). Compare RawQueryableConventionTests, which had to be adopted the other way, over an existing set of violations.
• Caveats / not-in-source - detection is textual over .razor markup, so a grid composed at runtime, or a column whose Sortable value comes from a variable rather than a literal, is outside what a text scan can judge.

TranslationCompletenessTests

MMCA.ADC.Architecture.Tests · MMCA.ADC.Architecture.Tests.Ui · MMCA.ADC.Architecture.Tests/Ui/TranslationCompletenessTests.cs:12 · Level 6 · class (public, sealed)

• What it is - the internationalization completeness gate: every base *.resx under Source/ must have a complete, non-empty Spanish .es.resx sibling, so adding an English key without its translation fails CI instead of shipping a half-translated UI (MMCA.ADC.Architecture.Tests/Ui/TranslationCompletenessTests.cs:3-:11).
• Depends on - LocalizationResourceTestsBase. Note the deliberate name divergence: the ADC subclass is named for what it guarantees (translation completeness), not for the base it derives from.
• Concept introduced, the non-vacuity floor. A convention scan that discovers nothing passes trivially, which is the failure mode that makes fitness functions untrustworthy over time. The MMCA bases answer it with a minimum-count floor that the subclass raises to the repo's real magnitude, so a broken scan root (a moved directory, a renamed convention, a case-sensitivity slip on the Ubuntu runner) fails loudly instead of going green while checking zero files. You have already seen the floor in AnonymousEndpointTests, and you will see it again in CommandValidatorCoverageTests, ErrorCatalogTests, FormsConventionTests, and LocalizedTextConventionTests. [Rubric §27 - i18n] assesses whether localization is enforced rather than aspirational; the gate is the enforcement, and ADR-027 (which supersedes the single-locale ADR-011) is the decision it executes.
• Walkthrough - two members. RequiredCultures => ["es"] (TranslationCompletenessTests.cs:14) implements the base's abstract culture list (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Bases/Ui/LocalizationResourceTestsBase.cs:13), so Spanish is the one culture ADC contractually completes. MinimumBaseResources => 40 (TranslationCompletenessTests.cs:16) raises the base's default of 0 (LocalizationResourceTestsBase.cs:21), which would otherwise let an empty scan pass. The inherited fact is Translations_AreComplete_ForEveryRequiredCulture (LocalizationResourceTestsBase.cs:24).
• Why it's built this way - the class comment justifies the floor from the repo's real shape: ADC has 40 or more localized resource sets across the three module UIs, the UI hosts' landing page, the nav-item module descriptors, and the API error-resource sets, so a near-zero discovery count means the scan path is wrong (TranslationCompletenessTests.cs:8-:10).
• Caveats / not-in-source - the floor is a lower bound stated in the subclass, not a count computed from the tree, so it stays correct only as long as someone raises it when the resource set grows materially.

FolderWidthTests

MMCA.ADC.Architecture.Tests · MMCA.ADC.Architecture.Tests.Governance · MMCA.ADC.Architecture.Tests/Governance/FolderWidthTests.cs:10 · Level 6 · class (public, sealed)

• What it is - the layout gate: no folder under ADC's Source/ or Tests/ tree may hold more than 12 direct code files, so a folder keeps naming a feature instead of turning into a technical bucket. It is a four-line subclass whose only override supplies the repository root (MMCA.ADC.Architecture.Tests/Governance/FolderWidthTests.cs:10-:13).
• Depends on - FolderWidthTestsBase and ArchitectureMapBase, whose static FindRepoRoot("MMCA.ADC.slnx") walks up from the test assembly until it finds the solution file, which is how the rule locates the working tree regardless of the runner's working directory (FolderWidthTests.cs:12).
• Concept introduced, a fitness function that reads the filesystem rather than IL. Every other rule in this unit reflects over compiled assemblies. This one cannot: the defect is a layout defect, so the rule walks directories from disk (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Rules/Governance/ArchitectureRules.FolderWidth.cs:9-:11, :42-:63). That is also why the subclass supplies a path instead of a map. [Rubric §5 - Modular Monolith & Vertical Slices] assesses whether the code is organized by feature rather than by technical layer; this makes "module by project, feature by folder, use case by leaf" an assertion instead of a review habit (ADR-109).
• Walkthrough - one member. RepoRoot (:12) is the single override. Everything else is inherited: the cap MaxDirectFiles => 12 (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Bases/Governance/FolderWidthTestsBase.cs:23), an empty ExemptFolderSuffixes default that ADC does not override, so ADC carries no documented exemption (:29), and the single fact Folders_stay_narrow, which hands both to the rule (:31-:33). The counting rules are the interesting part: only files directly in the directory count, a .razor component and its co-located X.razor.cs code-behind count as one unit, .resx satellites never count, and generated files (*.g.cs, *.generated.cs, *.Designer.cs) never count because nobody chose to put them there (ArchitectureRules.FolderWidth.cs:13-:19). Directories with a path segment named bin, obj, Migrations, Platforms, Resources, node_modules, wwwroot or .git are skipped outright, being build output or tool-owned trees whose shape is not the author's decision (:22-:24). Violations are collected, sorted ordinally, and reported together through ArchitectureAssert.NoViolations with the remedy in the message, "split it by feature or aggregate" (:66-:70).
• Why it's built this way - the class comment names the layouts the rule protects, Services/{Feature}/ beside Pages/{Feature}/, Controllers/{Aggregate}/, EntityConfiguration/{Aggregate}/, and states the failure mode it prevents: drifting back into flat technical buckets (FolderWidthTests.cs:3-:8). A cap enforced per repo rather than per project is deliberate, because the drift shows up wherever a folder is convenient, not only in the module the change belongs to.
• Where it's used - the project is inside ADC's CI solution filter (MMCA.ADC/MMCA.ADC.CI.slnf:59), which the build-and-test job builds and tests on every PR (MMCA.ADC/.github/workflows/deploy.yml:205, :284, :300).
• Caveats / not-in-source - the rule sees files, not namespaces, so a folder that stays under 12 while mixing unrelated features passes; the cap is a ceiling on width, not a check that the folder names one thing.

DecoratorPipelineOrderTests

MMCA.ADC.Architecture.Tests · MMCA.ADC.Architecture.Tests.Cqrs · MMCA.ADC.Architecture.Tests/Cqrs/DecoratorPipelineOrderTests.cs:29 · Level 9 · class (public, sealed)

• What it is - the one type in this unit that builds a real DI container instead of reading metadata. It asserts that ADC's genuine registration sequence produces the ADR-014 decorator nesting at runtime, exercised against a real Identity command/query pair (MMCA.ADC.Architecture.Tests/Cqrs/DecoratorPipelineOrderTests.cs:19-:28).
• Depends on - DecoratorPipelineOrderTestsBase<TCommand, TCommandResult, TQuery, TQueryResult> from the MMCA.Common.Testing package (MMCA.ADC.Architecture.Tests.csproj:43), closed over ChangePreferencesCommand / Result and GetUserPreferencesQuery / Result<UserPreferencesResponse> (DecoratorPipelineOrderTests.cs:30). Externals: Microsoft.Extensions.DependencyInjection, Microsoft.FeatureManagement, NullLogger<>, and Moq (:1-:13).
• Concept introduced, an object-graph assertion. Scrutor's TryDecorate applies decorators in reverse registration order, so the last decorator registered becomes the outermost wrapper. That makes an innocent-looking reorder of the AddApplicationDecorators() lines, or a module handler scan that runs after it instead of before, a silent change in runtime behavior: the code still compiles, the container still resolves, and the pipeline quietly runs validation after the transaction opens. The base turns that into a test failure by resolving the handler and walking the constructed graph via reflection over each decorator's private inner-handler field, so it verifies the objects that actually exist rather than the registration list (MMCA.Common/Source/Hosting/MMCA.Common.Testing/Conformance/DecoratorPipelineOrderTestsBase.cs:29-:32, :100-:125). [Rubric §2 - Design Patterns] assesses whether patterns are applied deliberately and correctly; the decorator chain is the framework's central pattern and this is the only test that proves its composition. [Rubric §14 - Testability]: the fact that a production registration sequence can be replayed in a bare ServiceCollection with seven mocked dependencies is itself the evidence that the composition root is not entangled with hosting.
• Walkthrough - two members.
  • ConfigureServices(IServiceCollection) (DecoratorPipelineOrderTests.cs:32) implements the base's single abstract hook (DecoratorPipelineOrderTestsBase.cs:46) and reads in two halves. Test doubles for the decorator constructor dependencies (:33-:39): Mock.Of<IFeatureManager>(), Mock.Of<ICurrentUserService>(), Mock.Of<IPermissionRegistry>(), Mock.Of<ICorrelationContext>(), and Mock.Of<ICacheService>() as singletons, a scoped IUnitOfWork factory, and the open generic ILogger<> mapped to NullLogger<>. These exist only so the decorators can be constructed; the test never invokes a handler. The base names the same seven dependencies as the contract for a subclass (DecoratorPipelineOrderTestsBase.cs:22-:25). The real registration sequence (:41-:42) is now one composed call, services.AddMmcaApplicationPipeline(pipeline => pipeline.ScanModule<MMCA.ADC.Identity.Application.ClassReference>()), written this way rather than the three hand-sequenced calls (AddApplication(), the module scan, AddApplicationDecorators()) so this fitness function exercises the same helper the four service hosts compose with: a regression in the helper's own ordering surfaces here as a wrong nesting rather than only as a startup failure nobody runs. AddMmcaApplicationPipeline still runs AddApplication() first, then the module's handler scan, then AddApplicationDecorators() last (Scrutor's TryDecorate can only wrap handlers already registered), and seals the collection.
  • ComposedPipeline_LeavesNoHandlerUndecorated (:45-:56) is a [Fact] of its own, not inherited: it builds a fresh ServiceCollection, calls ConfigureServices on it, then asserts services.VerifyDecoratorPipeline(). The base's nesting facts (below) prove ONE command and ONE query are wrapped correctly; this proves no handler in the whole Identity module escaped the pipeline, the failure mode that ships silently because an undecorated handler runs with no feature gate, authorization, validation or transaction and nothing throws at startup to say so.
  • The two inherited facts then assert the chains. CommandPipeline_NestsDecorators_InAdr014Order (DecoratorPipelineOrderTestsBase.cs:72) expects FeatureGate, Authorization, Logging, Caching, Validating, Timeout, Transactional, then the concrete handler (:49-:58); QueryPipeline_NestsDecorators_InAdr014Order (:76) expects FeatureGate, Authorization, Logging, Caching, Validating, Timeout, then the handler (:61-:69). The query chain carries a ValidatingQueryDecorator too (:67), so the two lists differ only by the transactional stage. Both are asserted by AssertPipeline (:79-:98), which compares every element except the last against the expected list (:93-:94) and then requires the innermost element not to end in "Decorator" (:96-:97), so a truncated chain cannot pass. ADC overrides neither expected list, so it accepts the framework default order as its contract.
• Why it's built this way - the pair was chosen for realism rather than convenience. ChangePreferencesCommand and its handler are shipped ADC Identity use cases, while GetUserPreferencesQuery is declared in MMCA.Common.Application and its concrete GetUserPreferencesHandler lives in ADC on top of Common's GetUserPreferencesHandlerBase<TUser>. So the scan-then-decorate ordering is exercised across the framework and app boundary rather than against a fixture, which is exactly what the base asks a subclass to supply (DecoratorPipelineOrderTestsBase.cs:26-:27).
• Where it's used - not an independent class any more: ComposedPipeline_LeavesNoHandlerUndecorated's own base (MMCA.Common/Tests/Hosting/MMCA.Common.Testing.Tests/Conformance/DecoratorPipelineOrderTests.cs) exercises the same helper, and MiddlewarePipelineOrderTests is a sibling gate over the same registration sequence at the middleware layer rather than a consumer of this type.
• Caveats / not-in-source - the nesting chain is still unwrapped by reading compiler-generated private fields (DecoratorPipelineOrderTestsBase.cs:105-:125), so a future decorator that stores its inner handler somewhere other than a field (a property-only or captured-closure design) would be invisible to that walk. VerifyDecoratorPipeline() proves every handler is wrapped by something, but does not itself replay the exact wrapper order for each one; that is still the base's job. The base flags the reflection strategy explicitly (:29-:32).

AdcArchitectureMap

MMCA.ADC.Architecture.Tests · MMCA.ADC.Architecture.Tests · MMCA.ADC.Architecture.Tests/AdcArchitectureMap.cs:14 · Level 12 · class (internal, sealed)

• What it is - the single declaration of what "the ADC architecture" is, in assembly terms: five MMCA.Common framework layers, the Identity, Conference, and Engagement modules at six layers each, and the thin Notification module at three, 26 entries in all (MMCA.ADC.Architecture.Tests/AdcArchitectureMap.cs:18-:55). Every map-driven rule in this unit scans exactly the assemblies listed here.
• Depends on - ArchitectureMapBase (which implements IArchitectureMap), the Layer enum and the LayerRef record, and System.Reflection.Assembly (global-used at MMCA.ADC.Architecture.Tests/GlobalUsings.cs:1). Through its anchor types it also depends on Result, BaseEntity<TIdentifierType>, EntityQueryService<TEntity, TEntityDTO, TIdentifierType>, ApplicationDbContext, and ApiControllerBase on the framework side, and on User, Event, UserSessionBookmark, UserNotificationExportItemDTO, their sibling DTOs, and the four IdentityModule / ConferenceModule / EngagementModule / NotificationModule entry points on the app side.
• Concept introduced, the architecture map as data. NetArchTest works on Assembly objects, so a fitness function needs some way to know which assembly plays which role. Rather than hard-coding assembly names inside each rule, MMCA reifies the answer in one object: a flat list of (module, layer, assembly) triples. ArchitectureMapBase derives everything else from that list: the module-name set, per-layer projections, namespace derivation, and the module-isolation target sets (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/ArchitectureMapBase.cs:28-:72). The consequence is that adding a module to ADC is a three-line change here, after which roughly three dozen rules start covering it. [Rubric §3 - Clean Architecture] assesses whether layer boundaries are real rather than aspirational, and this is the machine-readable statement of those boundaries. [Rubric §7 - Microservices Readiness]: the map's Module grouping is what lets the isolation and extraction rules ask "could this module leave the process", which for ADC is not hypothetical, since every module already runs as its own service host.
• Walkthrough
  • RepoToken => "MMCA.ADC" (AdcArchitectureMap.cs:16) is more load-bearing than it looks. The base composes namespaces from it ({RepoToken}.{Module}.{Segment}, ArchitectureMapBase.cs:63-:66, :98-:99), and the doc/config rules resolve the repository root by walking up from the test binary until they find {RepoToken}.slnx (ArchitectureMapBase.cs:79-:91), which is how DataResidencyTests, FormsConventionTests, and RawQueryableConventionTests read committed files regardless of the runner's working directory.
  • Framework layers (AdcArchitectureMap.cs:21-:25) are declared with the Framework(layer, assembly) helper, which records an empty module name (ArchitectureMapBase.cs:94-:95), so they are excluded from the per-module projections. Each is pinned by an anchor type rather than a string: Result for Shared, BaseEntity<> for Domain, EntityQueryService<,,> for Application, ApplicationDbContext for Infrastructure, and ApiControllerBase for API. A rename or a package move breaks the compile instead of silently producing an empty scan.
  • Module layers (:28-:54) use the instance Module(name, layer, assembly) helper. Identity, Conference, and Engagement each declare six layers; Domain, Shared, and API are pinned by anchor type (Identity.Domain.Users.User, Conference.Shared.Events.EventDTO, Engagement.API.EngagementModule, and their siblings) while Application, Infrastructure, and UI are loaded by name through Assembly.Load (for example :29, :30, :33), because those assemblies have no convenient public anchor type (:5-:6). Assembly.Load succeeds here only because the csproj takes a ProjectReference on all 21 module projects (MMCA.ADC.Architecture.Tests.csproj:46-:71), which is what puts the DLLs beside the test binary.
  • Notification (:52-:54) declares three layers, not six: Application (loaded by name), Shared (pinned by Notification.Shared.UserNotifications.UserNotificationExportItemDTO), and Api (pinned by Notification.API.NotificationModule). The class comment states why (:7-:12): Notification is a deliberately thin module that owns no aggregate and no persistence, so it ships no Domain, Infrastructure, or UI assembly, and LayerDependencyTests records that shape as a per-module required-layer override rather than letting the whole repo drop the requirement.
  • Laziness is inherited: DefineLayers() is materialized once through a Lazy<IReadOnlyList<LayerRef>> built in the base constructor (ArchitectureMapBase.cs:13-:16), so the three dozen subclasses that each construct their own map instance still pay the Assembly.Load cost only on first use.
• Why it's built this way - centralizing every namespace and assembly string in one file also fixes Ubuntu CI case sensitivity in one place, which the base states as an explicit goal (ArchitectureMapBase.cs:8-:9). Compare CommonArchitectureMap, the same abstraction for a repo with no business modules.
• Where it's used - instantiated as a field initializer by every map-driven subclass in this unit (34 of the 43 types here, all of them at Level 13), for example ConcurrencyConventionTests.cs:5. It is internal, so it never leaves this assembly. The nine non-map types are the two embedded-resource guards, AnonymousEndpointTests, ProtoContractTests, SortableColumnConventionTests, TranslationCompletenessTests, the two pipeline-order tests, and the map itself.
• Caveats / not-in-source - the four *.Contracts service projects under Source/Services/ are not registered, so no map-driven rule scans the gRPC adapters directly; ProtoContractTests covers that surface by file path instead. Nothing in this repository asserts that the map lists every module that exists, so a fifth module would have to be added here by a human.

MiddlewarePipelineOrderTests

MMCA.ADC.Architecture.Tests · MMCA.ADC.Architecture.Tests.Api · MMCA.ADC.Architecture.Tests/Api/MiddlewarePipelineOrderTests.cs:16 · Level 12 · class (public, sealed)

• What it is - the HTTP-edge counterpart of DecoratorPipelineOrderTests, and, like ObservabilityConventionTests, a bodyless declaration: public sealed class MiddlewarePipelineOrderTests : MiddlewarePipelineOrderTestsBase; (MMCA.ADC.Architecture.Tests/Api/MiddlewarePipelineOrderTests.cs:16). Deriving it is the whole assertion.
• Depends on - MiddlewarePipelineOrderTestsBase from the MMCA.Common.Testing package (using MMCA.Common.Testing;, :1), and transitively on MiddlewarePipelineBuilder and MiddlewarePipelineStepNames.
• Concept introduced, an empty subclass as a conformance claim. The class comment states what the emptiness means (:5-:14): every ADC REST and gRPC service host calls the zero-argument UseCommonMiddlewarePipeline(), so the framework's default step order is ADC's contract and the base needs no overrides. The two hooks that exist are the escape hatch a host would use if it customized the pipeline: Configure, which defaults to null (MMCA.Common/Source/Hosting/MMCA.Common.Testing/Conformance/MiddlewarePipelineOrderTestsBase.cs:37), and ExpectedStepNames (:38-:58). Leaving both alone is a positive statement, not an omission. [Rubric §12 - Performance & Scalability] assesses whether cross-cutting behavior is applied uniformly rather than per host; [Rubric §11 - Security] is the sharp edge, because the ordering invariants below are authentication and rate-limiting invariants.
• Walkthrough - no members. Two inherited facts run against a builder seeded from MiddlewarePipelineBuilder.CreateDefault() (MiddlewarePipelineOrderTestsBase.cs:81-:84).
  • EdgePipeline_OrdersSteps_InDocumentedOrder (:61) compares builder.StepNames against the 18-step default sequence, outermost first: exception handler, correlation id, request localization, pre-forwarded capture, forwarded headers, HTTPS redirection, response compression, routing, CORS, authentication, tenant resolution, rate limiting, soft-deleted-user filter, authorization, output cache, JWKS endpoint, OIDC discovery endpoint, controllers (:40-:57).
  • EdgePipeline_SatisfiesLoadBearingInvariants (:70) calls Build() and requires it not to throw, because Build() re-checks the load-bearing adjacencies at startup, so a pipeline that failed here would have thrown while the host was starting (:73-:76).
  • Four adjacencies are named as load-bearing in both the base and the ADC comment: the pre-forwarded capture immediately before the forwarded-headers rewrite (or jwks_uri stops being reachable), authentication immediately before tenant resolution (so the claim strategy sees HttpContext.User), authentication before the rate limiter per ADR-019 (so the per-user cap engages), and forwarded headers before the HTTPS redirect (MiddlewarePipelineOrderTests.cs:10-:13, MiddlewarePipelineOrderTestsBase.cs:68).
• Why it's built this way - a reorder here fails at runtime in ways that look like configuration bugs: an unreachable jwks_uri, a tenant that never resolves, a per-user rate cap that never engages (MiddlewarePipelineOrderTestsBase.cs:16-:18). Making it a red test in the consumer repo is what turns a framework-side reorder into a build failure rather than a silent production behavior change (ADR-079). No WebApplication is built: the steps are pure data until they are applied, so this runs in the fast unit tier with no database and no host (:24-:27).
• Caveats / not-in-source - the test asserts the framework default, seeded from CreateDefault(). It does not read any ADC Program.cs, so the claim that every ADC host calls the zero-argument overload is asserted by the comment, not by this test. A host that started passing a customization would silently fall outside this gate unless someone also overrode Configure here.

CommandValidatorCoverageTests

MMCA.ADC.Architecture.Tests · MMCA.ADC.Architecture.Tests.Cqrs · MMCA.ADC.Architecture.Tests/Cqrs/CommandValidatorCoverageTests.cs:18 · Level 13 · class (public, sealed)

• What it is - the gate that every data-carrying command has something for the Validating decorator to run. It freezes the 26 entries that are exempt today, and fails on any new one (MMCA.ADC.Architecture.Tests/Cqrs/CommandValidatorCoverageTests.cs:23-:86).
• Depends on - CommandValidatorCoverageTestsBase and AdcArchitectureMap.
• Concept introduced, the allowlist grouped by reason rather than by name. The list is not alphabetical: it is split into three commented buckets, because the entries are not equally benign and a reviewer needs to see which kind an entry is (:25-:30). That is the difference between an inventory and a mute button. [Rubric §6 - CQRS & Event-Driven] assesses whether the pipeline stages actually do work; the Validating decorator is present for every command whether or not a validator resolves, so a missing validator is a stage that runs and asserts nothing. [Rubric §11 - Security] and [Rubric §24 - Forms/Validation/UX Safety]: the base's framing is that a command with no validator carries whatever the caller sent straight into the handler, and the gap is invisible until bad input reaches the domain (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Bases/Cqrs/CommandValidatorCoverageTestsBase.cs:4-:7).
• Walkthrough - three members.
  • Map (:20).
  • AllowedUnvalidatedCommands (:23-:85) overrides the base's empty default (CommandValidatorCoverageTestsBase.cs:31) with 26 entries in three groups. (1) Identifier-only commands (:25-:61), twenty-two entries whose whole payload is a server-supplied or route-supplied id plus, in a few cases, a RowVersion or an enum the compiler already constrains: seventeen remove/publish/link/delete commands across Conference and Engagement, the live-poll Close, Delete and Open among them (:31-:47), ModerateQuestionCommand with its own note that every field is an id or type-constrained and the authorization decision is the handler's (:49-:51), SetLeaderboardParticipationRequest because "there is no invalid value of a bool" (:53-:54), two Identity deletes (:56-:57), and the framework's generic MMCA.Common.Application.UseCases.Crud.DeleteEntityCommand closed over ADC aggregates, which ADC does not author (:59-:61). (2) False positives of the scan (:63-:77): ForgotPasswordCommand and ResetPasswordCommand (:70-:71), plus the email-confirmation pair (ADR-116), SendEmailConfirmationCommand and ConfirmEmailCommand (:76-:77), all four carrying an ICommandWithRequest<T> whose IValidator<T> is real but lives in MMCA.Common.Application, and the rule reads only the repo's per-module Application assemblies, so it cannot see the framework half of the bridge. The comment ends with an instruction to a future maintainer: these are validated at runtime, do not "fix" them by writing a duplicate. (3) Frozen debt (:79-:85): empty, and the comment records what left it (the two question-answer updates, ChangePreferences, and SetUserAvatar each now carry a validator in their own slice).
  • MinimumCommands => 55 (:93) raises the base floor of 1 (CommandValidatorCoverageTestsBase.cs:38). The comment states the measurement it sits under: the scan found 62 handled, data-carrying commands at adoption, so the floor leaves room for normal churn while still failing loudly if a module drops out of the map (:88-:92).
  • Two facts are inherited: Commands_ShouldHave_ValidationCoverage (CommandValidatorCoverageTestsBase.cs:41) and the non-vacuity check CommandInventory_ShouldNotBe_Empty (:45).
• Why it's built this way - the base explains why both halves of the request bridge are required for a command to count as covered: the framework registers the bridge validator for every ICommandWithRequest<TRequest> whether or not a request validator resolves, and one that resolves none adds no rules (CommandValidatorCoverageTestsBase.cs:9-:15). Counting the bridge without the request validator would have made the gate pass on exactly the commands it exists to catch.
• Caveats / not-in-source - group (2) is a stated limitation of the scan rather than a property of ADC, so an ADC command that legitimately binds a framework request validator in future would land in the same bucket and would need the same hand-written note.

ClockReadTests

MMCA.ADC.Architecture.Tests · MMCA.ADC.Architecture.Tests.Domain · MMCA.ADC.Architecture.Tests/Domain/ClockReadTests.cs:8 · Level 13 · class (public, sealed)

• What it is - the map-only ADC subclass of the framework's clock-read fitness function: the whole body is one line supplying AdcArchitectureMap (MMCA.ADC.Architecture.Tests/Domain/ClockReadTests.cs:8-:11).
• Depends on - ClockReadTestsBase from MMCA.Common.Testing.Architecture and AdcArchitectureMap.
• Concept introduced - the same thin-subclass shape as BrandColorTokenTests and AiDependencyIsolationTests: the rule body lives once in the shared base, and deriving a sealed subclass over ADC's map is what turns it on for this repo (ADR-015). The base's own concern (proved once in MMCA.Common and exercised here by name only) is that direct reads of DateTime.Now/DateTime.UtcNow/DateTimeOffset.Now inside domain and application code are untestable and non-deterministic; production code is expected to take an injected clock abstraction instead. [Rubric §14 - Testability] is the direct target.
• Walkthrough - one member, Map (:10), implementing the base's abstract property over ADC's assemblies.
• Why it's built this way - identical rationale to every other map-only subclass in this unit: the fixture proof lives once in MMCA.Common (see MMCA.Common.Architecture.Tests/Domain/ClockReadTests.cs and MMCA.Common.Architecture.Tests/ClockReadFixtures/ClockReadFixtures.cs), so each consumer repo need only wire its own map to gain the coverage.
• Where it's used - runs with the rest of the suite in the build-and-test job; not consumed by any other type in this unit.

CascadeSoftDeleteConventionTests

MMCA.ADC.Architecture.Tests · MMCA.ADC.Architecture.Tests.Domain · MMCA.ADC.Architecture.Tests/Domain/CascadeSoftDeleteConventionTests.cs:12 · Level 13 · class (public, sealed)

• What it is - the guard that an aggregate root which owns auditable children deletes them in its own Delete() override, carrying exactly one reviewed exemption (MMCA.ADC.Architecture.Tests/Domain/CascadeSoftDeleteConventionTests.cs:17-:26).
• Depends on - CascadeSoftDeleteConventionTestsBase and AdcArchitectureMap.
• Concept introduced, the consequence of soft delete not being a delete. MMCA never removes a row: an entity sets IsDeleted = true and the EF global query filter hides it. That means nothing cascades for free, because a soft delete is an ordinary UPDATE. Without an explicit cascade the root vanishes behind the filter while its child rows stay active, orphaned and unreachable through the root, yet still present for exports, reports, and erasure requests (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Bases/Domain/CascadeSoftDeleteConventionTestsBase.cs:4-:9). The framework's DeleteChildren<TChild, TChildId>(...) helper is the one-line fix, and a hand-rolled loop over the children counts too. [Rubric §8 - Data Architecture] assesses whether the persistence model's invariants hold end to end; [Rubric §30 - Compliance/Privacy/Data Governance] is the sharper edge, since an orphaned child row is data a subject-access or erasure request has to account for (ADR-005).
• Walkthrough - two members. Map (:14), and AllowedCascadeExemptTypes (:17-:26), which overrides the base's empty default (CascadeSoftDeleteConventionTestsBase.cs:27) with a single entry, MMCA.ADC.Conference.Domain.Speakers.Speaker. The inherited fact is AggregatesWithChildCollections_MustCascadeSoftDelete_InDelete (:30).
• Why it's built this way - the exemption is justified in place rather than in a wiki (CascadeSoftDeleteConventionTests.cs:19-:24): Speaker's junction rows (SpeakerCategoryItems, SpeakerQuestionAnswers) deliberately outlive the soft-deleted root per BR-70/BR-71, because the Sessionize import reactivates them in place when the speaker returns (BR-135) and no cascade-restore counterpart exists, so cascading here would silently drop a returning speaker's categories and answers. The safety argument is the second half: junction reads follow the parent's visibility (BR-132), so the surviving children are not observable while the speaker is deleted. The base frames the whole exemption list this way, as the point of the rule rather than a concession: it turns "delete cascades, mostly" into a reviewed inventory of every aggregate that leaves children behind on purpose (CascadeSoftDeleteConventionTestsBase.cs:11-:15).
• Caveats / not-in-source - the entry is a type full name, so the exemption is matched by string; the reactivation behavior it depends on (BR-135) is asserted by the Sessionize import tests, not here.

AiDependencyIsolationTests

MMCA.ADC.Architecture.Tests · MMCA.ADC.Architecture.Tests.Layering · MMCA.ADC.Architecture.Tests/Layering/AiDependencyIsolationTests.cs:14 · Level 13 · class (public, sealed)

• What it is - the model-boundary fitness function for ADC: a language-model dependency must stay confined to Infrastructure and to the governed MMCA.Common.AI package, in both directions. Map-only shape (ConcurrencyConventionTests): the whole body is one line supplying the map (MMCA.ADC.Architecture.Tests/Layering/AiDependencyIsolationTests.cs:16).
• Depends on - AiDependencyIsolationTestsBase and AdcArchitectureMap.
• Walkthrough - one member, Map (:16), implementing the base's abstract property (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Bases/Layering/AiDependencyIsolationTestsBase.cs:21). Two inherited facts: LanguageModelSdks_ShouldStayAt_TheModelBoundary (:24) fails on a module naming the vendor SDK directly (Anthropic, OpenAI, Azure.AI, or Microsoft.Extensions.AI itself) outside Infrastructure, and GovernedAiPackage_ShouldStayBehind_Infrastructure (:28) fails on a module taking the framework's governed MMCA.Common.AI package as a convenience and passing a PromptContract around as a domain type.
• Why it's built this way - the base's summary states the reason both directions are checked: either leak turns "the app calls a model at one place" into "the model is spread through the app", and a dependency that is everywhere cannot be versioned, evaluated, capped or swapped (AiDependencyIsolationTestsBase.cs:7-:12). [Rubric §16 - AI-Native Development] is the direct target.

ConcurrencyConventionTests

MMCA.ADC.Architecture.Tests · MMCA.ADC.Architecture.Tests.Domain · MMCA.ADC.Architecture.Tests/Domain/ConcurrencyConventionTests.cs:3 · Level 13 · class (public, sealed)

• What it is - the guard that no *UpdateRequest carries a concurrency token in its body. It is also the plainest example of the Level 13 shape in this unit: a sealed class whose entire body is one line supplying the map (MMCA.ADC.Architecture.Tests/Domain/ConcurrencyConventionTests.cs:5).
• Depends on - ConcurrencyConventionTestsBase and AdcArchitectureMap.
• Concept introduced, the map-only subclass. Eighteen of the 34 map-driven types in this unit are exactly this: protected override IArchitectureMap Map { get; } = new AdcArchitectureMap(); and nothing else. Note the property is an auto-property with an initializer, not an expression body, so each class constructs its map once per test-class instance rather than per fact. Everything else (the rule bodies, the [Fact] attributes, the failure messages) is inherited, which is precisely the point: MMCA.Common, MMCA.Store, and MMCA.ADC run byte-identical rule logic and differ only in what they point it at. The sections below for the other map-only subclasses do not repeat this explanation; they name the base and list what it asserts. [Rubric §15 - Best Practices & Code Quality] assesses duplication and change cost: a new rule ships to all three repos by adding a base and one derived line per repo.
• Walkthrough - one member, Map (:5), implementing the base's abstract property (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Bases/Domain/ConcurrencyConventionTestsBase.cs:11). The inherited fact is UpdateRequests_ShouldNotImplement_IConcurrencyAware (:14), which delegates to ArchitectureRules.UpdateRequestsAreNotConcurrencyAware(Map). [Rubric §8 - Data Architecture] and [Rubric §9 - API & Contract Design]: the rule enforces a single source for the token. The version a conditional update is checked against is read from the If-Match request header, so a token in the request body would give the same check a second, competing source (ConcurrencyConventionTestsBase.cs:4-:7). That is the inverse of what the same-named rule asserted before the header became the only path, and it is why IConcurrencyAware must now be absent from request bodies rather than present. The base notes that modules with no mutable aggregate are legitimately vacuous here (:7).
• Where it's used - runs with the whole suite in the build-and-test job (MMCA.ADC/.github/workflows/deploy.yml:189, :284). The same is true of every remaining type in this unit and is not repeated below.

ConstructorDependencyCountTests

MMCA.ADC.Architecture.Tests · MMCA.ADC.Architecture.Tests.Cqrs · MMCA.ADC.Architecture.Tests/Cqrs/ConstructorDependencyCountTests.cs:20 · Level 13 · class (public, sealed)

• What it is - a single-responsibility ceiling applied to three separate populations: no *Service in a mapped module Application assembly may exceed eight constructor dependencies, no API controller may exceed ten, and no CQRS handler may exceed seven (MMCA.ADC.Architecture.Tests/Cqrs/ConstructorDependencyCountTests.cs:22-:31, :59, :68).
• Depends on - ConstructorDependencyCountTestsBase and AdcArchitectureMap.
• Concept introduced, the ratchet set to the real high-water mark, and its history kept in the file. A ceiling is only a ceiling if it sits at the current maximum, so the class comment keeps a ledger of every move, on the stated principle that "a ceiling only means something if every move of it was deliberate". It was 8 while the comment claimed AuthenticationService had 8 dependencies; it had 7, so the gate carried a phantom slot of headroom and was tightened to the real mark on 2026-07-28. It moved to 9 when refresh tokens became multi-device sessions: the framework's AuthenticationServiceBase constructor took on the session store and its options, and ADC's subclass passed both through on top of the IExternalLoginEmailVerifier its OAuth auto-link gate needs. It moved again, 9 to 10, on 2026-09-23: the AuthenticationServiceSettings holder that had bundled IOptions<RefreshSessionSettings> and IOptions<EmailConfirmationSettings> into one slot was deleted, and both options now reach the framework base directly (ConstructorDependencyCountTests.cs:24-:27). It then moved down, 10 to 8, on 2026-10-06: Common 1.218.1 folded the session store into IAuthSessionIssuer, so AuthenticationService takes 8, and the base's ApplicationServices_ConstructorDependencyCeilingIsTight now fails whenever the ceiling is left above the observed mark (:28-:31). The comment then makes the judgement explicit each time: the additions are framework-imposed collaborators of the same facade rather than a second responsibility, so the honest response is a raised ceiling and not an artificial bundle. [Rubric section 1 - SOLID] assesses single responsibility among other things; constructor arity is the cheapest mechanical proxy for a class that has accumulated too many jobs, and the comment is careful to distinguish a cohesive facade from a bundle.
• Walkthrough - four members. Map (:22), and MaxConstructorDependencies => 8 (:31), which implements the base's abstract service ceiling (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Bases/Cqrs/ConstructorDependencyCountTestsBase.cs:43) and backs ApplicationServices_DoNotExceedConstructorDependencyCeiling (:52), which scans every non-abstract class whose name ends in "Service" in the map's module Application assemblies (:54-:58), asserts the set is non-empty so the guard cannot pass vacuously (:60-:61), and reports each offender with its own arity (:63-:80). The subclass comment names AuthenticationService, now at the mark of 8, and CreateSessionHandler next at 7 (ConstructorDependencyCountTests.cs:6-:8). The other two members arrived with the framework's 2026-09 wave, which added a controller ceiling and a handler ceiling to the base alongside the existing service one. MaxControllerConstructorDependencies => 10 (:59) implements the base's Controllers_DoNotExceedConstructorDependencyCeiling (ConstructorDependencyCountTestsBase.cs:119), which scans every concrete ControllerBase-derived class across the map's API assemblies. Its own doc comment keeps the same kind of ledger: the fact first reported 14 (SpeakersController), 12 (EventsController), 11 (SessionsController) and 10 (LivePollsController), each serving several sub-resources from one class; each was split by sub-resource into sibling controllers on the same route prefix, action templates and authorization attributes, so no URL, verb or authorization posture moved (SpeakerLinksController/SpeakerSessionsController 14 to 9, EventLifecycleController 12 to 9, SessionCalendarController 11 to 10, LivePollVotingController 10 to 7). SessionsController stops at 10 rather than 9 deliberately: its remaining dependency is IEntityQueryService<Event, ...>, held only for the BR-86 advisory X-Warning header on create, which the update path gets from UpdateSessionResult.HasDateRangeWarning but the create path cannot, because the framework base fixes its create handler at ICommandHandler<SessionCreateRequest, Result<SessionDTO>> and the Application layer has no way to set a response header; the honest mark is therefore 10, to be lowered the moment a framework change makes 9 true (ConstructorDependencyCountTests.cs:36-:58). MaxHandlerConstructorDependencies => 7 (:68) implements Handlers_DoNotExceedConstructorDependencyCeiling (ConstructorDependencyCountTestsBase.cs:143), scanning every concrete ICommandHandler<,> / IQueryHandler<,> implementation in the map's module Application assemblies, set at the mark the fact first reported: ResetPasswordHandler and SubmitQuestionHandler jointly at 7, with CreateSessionHandler, RefreshFromSessionizeHandler, UploadSessionAssetHandler, CreateBookmarkHandler and RecordRoomCheckInHandler next at 6 (:62-:67).
• Why it's built this way - each ceiling is meant to be raised consciously rather than drifted past, which is what the comments ask for and what their own history demonstrates. The controller split is the sharpest example: four controllers that had accreted several sub-resources were split along existing route and authorization boundaries rather than pinned at their old, inflated marks.
• Caveats / not-in-source - the sibling rule HandlerConventionTests raises the base's separate arity check to 10 for a different population (HandlerConventionTests.cs:18), and its <remarks> states the coupling directly: the two guards must move together, or the stricter one turns the other into a comment (:11-:12). Note the service scan is name-based (*Service), so a handler or a builder with the same arity is judged only by its own ceiling, not this one.

ContractImplementationTests

MMCA.ADC.Architecture.Tests · MMCA.ADC.Architecture.Tests.Contracts · MMCA.ADC.Architecture.Tests/Contracts/ContractImplementationTests.cs:20 · Level 13 · class (public, sealed)

• What it is - the encapsulation half of the [ServiceContract] boundary: the concrete class serving a published contract interface must not be public. Map-only shape (ConcurrencyConventionTests): the body is one line (MMCA.ADC.Architecture.Tests/Contracts/ContractImplementationTests.cs:22).
• Depends on - ContractImplementationTestsBase and AdcArchitectureMap.
• Concept introduced, guarding a boundary from both sides. This rule is the twin of ServiceContractPurityTests, and the base says so in as many words: purity keeps the producer's internals out of the contract, this keeps the contract's implementation out of the consumer's reach (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Bases/Contracts/ContractImplementationTestsBase.cs:11-:13). A public implementation lets a consumer reference, construct, or subclass the type, and each of those references is a coupling the extraction has to sever later, because an interface can be answered over a wire and a class cannot (:5-:8). [Rubric §7 - Microservices Readiness] assesses whether extraction is reversible in practice; [Rubric §1 - SOLID]: this is dependency inversion enforced at the assembly boundary rather than only at the call site (ADR-007).
• Walkthrough - one member, Map (:21), implementing the base's abstract property (ContractImplementationTestsBase.cs:22). One inherited fact, ServiceContractImplementations_ShouldNotBe_Public (:33), and the AllowedPublicImplementations hook (:30) is left at its empty default. The subclass documentation is where the real teaching is (ContractImplementationTests.cs:3-:18): ADC's six contracts (IAttendeeQueryService, IBookmarkCountService, IEventLiveValidationService, ISessionBookmarkValidationService, IUserEngagementExportService, IUserNotificationExportService) each have three implementations, the in-process one in *.Application, the Disabled* stub in *.Shared, and the gRPC adapter in Services/*.Contracts, and all of them are internal sealed. The <remarks> explains why the allowlist stays empty: nothing in ADC ships a contract implementation a consumer is meant to construct, and the assemblies that register or exercise these classes reach them through InternalsVisibleTo on the producing projects rather than through a public type (:14-:18).
• Caveats / not-in-source - the rule is scoped to the assemblies AdcArchitectureMap registers, and the Services/*.Contracts projects are not among them, so the gRPC adapters' internal visibility is asserted by the class comment rather than by this test.

ControllerConventionTests

MMCA.ADC.Architecture.Tests · MMCA.ADC.Architecture.Tests.Api · MMCA.ADC.Architecture.Tests/Api/ControllerConventionTests.cs:3 · Level 13 · class (public, sealed)

• What it is - the API-layer convention guard, with a two-entry exemption list for the controllers that legitimately do not route through the framework's base controller (MMCA.ADC.Architecture.Tests/Api/ControllerConventionTests.cs:11-:15).
• Depends on - ControllerConventionTestsBase, AdcArchitectureMap, and, by name only (they are strings, not type references), OAuthController and ServiceInfoController.
• Concept introduced, the documented exemption. A rule with no escape hatch gets deleted the first time reality disagrees with it; a rule with an undocumented escape hatch rots. The middle path here is an allowlist of fully qualified names, each justified in the comment above it (:7-:10): the OAuth controller drives a redirect, challenge, and cookie flow with an out-of-band token exchange, and the service-info controller is an anonymous version-discovery diagnostic, so neither returns a domain Result and neither has anything to gain from the Result-to-HTTP mapping in ApiControllerBase. [Rubric §9 - API & Contract Design] assesses consistency of the HTTP surface; the rule keeps the default consistent while naming the two deliberate outliers.
• Walkthrough - two members. Map (:5) and ControllersExemptFromApiControllerBase (:11-:15), which overrides the base's empty default (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Bases/Api/ControllerConventionTestsBase.cs:12). Four facts are inherited: controllers do not depend on Infrastructure (:15), do not depend on EF Core (:18), are sealed (:21), and inherit ApiControllerBase except for the exempt names (:24).
• Caveats / not-in-source - the exemptions are matched as strings, so renaming or moving either controller silently drops it from the list and turns the rule red rather than passing wrongly, which is the safe direction.

DataResidencyTests

MMCA.ADC.Architecture.Tests · MMCA.ADC.Architecture.Tests.Governance · MMCA.ADC.Architecture.Tests/Governance/DataResidencyTests.cs:12 · Level 13 · class (public, sealed)

• What it is - a compliance drift guard: the data-residency statement published in ADC's PRIVACY.md must match the Azure region where personal data is actually provisioned, parsed out of the deployment workflow (MMCA.ADC.Architecture.Tests/Governance/DataResidencyTests.cs:3-:11).
• Depends on - DataResidencyTestsBase, AdcArchitectureMap, System.IO.File/Path, and AwesomeAssertions (used directly inside the override, :26).
• Concept introduced, a test as the join between a document and an infrastructure fact. Most of the rules in this unit compare code to code. This one compares prose to infrastructure: it reads the deployed region out of the source of truth (SQL_LOCATION="${SQL_LOCATION_OVERRIDE:-westus2}", MMCA.ADC/.github/workflows/deploy.yml:1158) and then requires PRIVACY.md to say the same thing, comparing whitespace-insensitively and case-insensitively so "West US 2" matches the westus2 region token. [Rubric §30 - Compliance/Privacy/Data Governance] assesses whether privacy claims are true and stay true; a policy that names a region the data never lived in is a compliance defect that no code review would catch, and this is the mechanism that closes it.
• Walkthrough - three members.
  • Map (:14) exists only so the base can resolve the repo root through ArchitectureMapBase.FindRepoRoot($"{Map.RepoToken}.slnx"); no assembly scanning happens in this rule.
  • ForbiddenResidencyClaims => ["central United States"] (:16) overrides the base's empty default (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Bases/Governance/DataResidencyTestsBase.cs:24) and blocks a specific stale statement from returning, one that once contradicted the deployed region (DataResidencyTests.cs:9-:10).
  • ExtractDeployedRegion(string repoRoot) (:20-:31) implements the base's abstract hook (DataResidencyTestsBase.cs:87). It reads .github/workflows/deploy.yml (:22), locates the literal marker SQL_LOCATION_OVERRIDE:- with an ordinal IndexOf (:24-:25), asserts the marker exists with a because explaining what the workflow must declare (:26-:27), then takes the alphanumeric run that follows as the region (:29-:30). Assert-then-parse rather than return-empty is what the base asks implementations to do.
  • The inherited fact PrivacyPolicy_DataStorageRegion_MatchesDeployedRegion (DataResidencyTestsBase.cs:27) then asserts the normalized policy contains the normalized region and contains none of the forbidden claims.
• Why it's built this way - the account data and session bookmarks live in the Azure SQL database, and the QiMata Sponsorship subscription forces that SQL server into a different region from the Container Apps (DataResidencyTests.cs:5-:9), so "where the app runs" is genuinely not "where the personal data sits". Parsing the SQL region default rather than the app region encodes that distinction.
• Caveats / not-in-source - the parse is positional: it takes the first occurrence of the marker in deploy.yml. The workflow contains both a job-level SQL_LOCATION_OVERRIDE env binding (deploy.yml:1111) and the shell default (:1158), so the rule depends on the marker string SQL_LOCATION_OVERRIDE:- appearing only in the latter form.

DomainEventHandlerSaveTests

MMCA.ADC.Architecture.Tests · MMCA.ADC.Architecture.Tests.Cqrs · MMCA.ADC.Architecture.Tests/Cqrs/DomainEventHandlerSaveTests.cs:11 · Level 13 · class (public, sealed)

• What it is - the rule that a domain-event handler mutates state and lets the owning unit of work flush it, rather than persisting on its own. It carries two allowlisted entries (MMCA.ADC.Architecture.Tests/Cqrs/DomainEventHandlerSaveTests.cs:16-:28).
• Depends on - DomainEventHandlerSaveTestsBase and AdcArchitectureMap.
• Concept introduced, the transitive call-graph rule. Every other assembly-scanning rule in this unit judges a type by its own declarations. This one walks the call graph out of every handler method, so the common real shape (handler to a domain service to SaveChangesAsync) is caught rather than only a save typed directly into the handler (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Bases/Cqrs/DomainEventHandlerSaveTestsBase.cs:10-:14). The walk depth is bounded by MaxCallDepth, defaulted to 6, which the base describes as covering the realistic handler-to-service-to-helper-to-repository chain while keeping the scan fast (:35-:40); ADC does not override it. [Rubric §6 - CQRS & Event-Driven] assesses the discipline around dispatch; [Rubric §8 - Data Architecture]: dispatch runs after SaveChangesAsync, and after commit inside an ITransactional command, so a handler that saves opens a second write in the middle of the first one, re-entering the change tracker, potentially raising a fresh event cascade, and persisting work the outer transaction may still roll back (:4-:9).
• Walkthrough - two members. Map (:13), and AllowedSavingTypes (:16-:28), which overrides the base's default (DomainEventHandlerSaveTestsBase.cs:33) with two entries. The first, "MMCA.Common" (:20), is the base's own default carried forward: the framework's outbox event bus persists by design, and a handler publishing an integration event is not the defect the rule hunts (:18-:19). The second is PointsAwarder (:27), labelled an accepted deliberate trade-off: the gamification points ledger is written by the awarder that the point-scoring domain-event handlers call, so awarding points is a second write that follows the first, and the comment states plainly that the flow is intentional and is not to be refactored onto the outbox, because a point award that lost its triggering write would be worse than one that trails it (:22-:26). The inherited fact is DomainEventHandlers_ShouldNotReach_SaveChanges (DomainEventHandlerSaveTestsBase.cs:43).
• Why it's built this way - an allowlist entry both silences the type and stops the walk from descending into it (DomainEventHandlerSaveTestsBase.cs:16-:19), which is why the class comment insists the two accepted ADC cascades are named explicitly rather than silenced module-wide (DomainEventHandlerSaveTests.cs:8-:9): a namespace-wide entry would have hidden whatever lies beyond it too.
• Caveats / not-in-source - the depth bound is 6, so a save reached through a deeper chain is outside the walk. The base names that as a tuning knob rather than a guarantee.

DomainPurityTests

MMCA.ADC.Architecture.Tests · MMCA.ADC.Architecture.Tests.Layering · MMCA.ADC.Architecture.Tests/Layering/DomainPurityTests.cs:3 · Level 13 · class (public, sealed)

• What it is - the Clean Architecture purity guard, plus one repo-specific addition: RabbitMQ is added to the forbidden-dependency list for Domain and Shared (MMCA.ADC.Architecture.Tests/Layering/DomainPurityTests.cs:9).
• Depends on - DomainPurityTestsBase and AdcArchitectureMap.
• Concept introduced - the map-only shape from ConcurrencyConventionTests, extended by a one-line hook. The extra entry is not decoration: ADC runs on a broker (RabbitMQ locally, Azure Service Bus in production, :7-:8), and a broker client reference inside Domain would tie the model to a transport. [Rubric §3 - Clean Architecture] assesses inward-only dependencies; [Rubric §7 - Microservices Readiness]: keeping the transport out of the core is what makes IMessageBus substitutable between in-process and broker delivery.
• Walkthrough - two members: Map (:5) and ExtraForbiddenDomainDependencies => ["RabbitMQ"] (:9), overriding the base's empty default (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Bases/Layering/DomainPurityTestsBase.cs:12). Four facts are inherited: Domain is framework-free (:15), Shared is framework-free (:18), Application does not depend on EF Core (:21), and Application does not depend on ASP.NET Core (:24). The extra token is passed to the first two only.

DomainThrowTests

MMCA.ADC.Architecture.Tests · MMCA.ADC.Architecture.Tests.Domain · MMCA.ADC.Architecture.Tests/Domain/DomainThrowTests.cs:9 · Level 13 · class (public, sealed)

• What it is - the Result-pattern purity guard: no throw in ADC's Domain assemblies except an argument guard. The allowlist is present and empty (MMCA.ADC.Architecture.Tests/Domain/DomainThrowTests.cs:14-:17).
• Depends on - DomainThrowTestsBase and AdcArchitectureMap.
• Concept introduced, the cost of a thrown business failure. The framework's whole error model is that a business outcome comes back as a Result (ADR-013), and the base names the three concrete consequences of throwing one instead: it skips Result.Combine invariant composition, it arrives at the API as a 500 rather than an outcome the caller can act on, and it pays an exception unwind on a path that is not exceptional (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Bases/Domain/DomainThrowTestsBase.cs:4-:9). Argument guards stay allowed because they report a caller bug rather than a business outcome, and the modern guard style always passes anyway: a bare throw; rethrow is ignored, and the ArgumentNullException.ThrowIfNull family emits no throw in the caller at all (:11-:12). [Rubric §15 - Best Practices & Code Quality] assesses whether a stated convention actually holds; [Rubric §9 - API & Contract Design]: which failures a caller can handle is part of the contract.
• Walkthrough - two members. Map (:11), and AllowedThrowingTypes (:14-:17), which overrides the base's empty default (DomainThrowTestsBase.cs:31) with a collection expression containing only a comment, TRIAGE PLACEHOLDER: filled from the first run (DomainThrowTests.cs:16). Since the list is empty and the rule is in the CI suite, that comment is now a historical note rather than an open item: ADC's Domain assemblies throw nothing beyond the argument guards, or the gate would be red. The inherited fact is Domain_ShouldNotThrow_ExceptArgumentGuards (DomainThrowTestsBase.cs:34).
• Why it's built this way - the base spells out the adoption path the placeholder anticipated (:14-:19): subclass, run once, then either convert each reported site to a Result.Failure or move it into the list with a comment. ADC took the first branch everywhere, which is why the list stayed empty.
• Caveats / not-in-source - the exception filter is by type (ArgumentException, ArgumentNullException, ArgumentOutOfRangeException), so a custom guard exception outside that family would be reported.

EntityConventionTests

MMCA.ADC.Architecture.Tests · MMCA.ADC.Architecture.Tests.Domain · MMCA.ADC.Architecture.Tests/Domain/EntityConventionTests.cs:3 · Level 13 · class (public, sealed)

• What it is - the DDD entity-shape guard for ADC's three module domains: aggregate roots exist, each has a Result-returning static factory and no public constructor, domain entities are sealed and live in the Domain layer, entity properties carry no public setters, and DTOs or requests do not live in Domain or Infrastructure.
• Depends on - EntityConventionTestsBase and AdcArchitectureMap. Map-only shape (ConcurrencyConventionTests).
• Walkthrough - one member, Map (:5). Eight inherited facts (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Bases/Domain/EntityConventionTestsBase.cs:15, :18, :21, :24, :27, :30, :33, :36) cover aggregate-root exposure, the Result-returning Create factory, constructor visibility, factory return types, sealing, layer placement, non-public property setters, and the DTO/request exclusion. [Rubric §4 - DDD] assesses whether the tactical patterns are actually applied; this is the rule that keeps the factory-plus-Result construction contract from being optional in a new module, and the setter check is what keeps an entity's state from being reachable without going through a behavior method.

ErrorCatalogTests

MMCA.ADC.Architecture.Tests · MMCA.ADC.Architecture.Tests.Contracts · MMCA.ADC.Architecture.Tests/Contracts/ErrorCatalogTests.cs:20 · Level 13 · class (public, sealed)

• What it is - the guard over ADC's error-code vocabulary: one literal code means one thing, and a code carries the prefix of the vocabulary that owns it. It is the second-largest subclass in the unit, at 108 lines, and almost all of it is justification (MMCA.ADC.Architecture.Tests/Contracts/ErrorCatalogTests.cs:28-:59, :65-:81).
• Depends on - ErrorCatalogTestsBase and AdcArchitectureMap.
• Concept introduced, treating error codes as a public contract. The class comment states the constraint that shapes every decision in this file (:12-:18): error codes reach clients in problem-details payloads and get quoted in support tickets, so nothing already shipped is renamed to satisfy the rule. Today's catalog is locked exactly as it stands and only new drift is gated. [Rubric §9 - API & Contract Design] assesses whether the error surface is governed like the rest of the API; [Rubric §15 - Best Practices & Code Quality]: a vocabulary in which one code means two things is a vocabulary a client cannot switch on.
• Walkthrough - three members plus three inherited facts.
  • Map (:22).
  • AllowedCodePrefixes (:28-:59) overrides the base's default of the map's module names (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Bases/Contracts/ErrorCatalogTestsBase.cs:29) because ADC namespaces its codes by aggregate (Session.Room.DoubleBooked) rather than by module. It spreads Map.ModuleNames (:30) and then adds 22 literal aggregate prefixes in three commented groups: ten Conference aggregates and children (:33-:42, SessionAsset newly added), nine Engagement ones (:45-:53), and three Identity ones (:56-:58). The comment frames the list as an inventory: a code under a new prefix fails until the prefix is reviewed and added, which is the drift the gate exists to catch (:8-:10).
  • AllowedSharedCodes (:65-:81) spreads the base's three generic statics (ErrorCatalogTestsBase.cs:35-:36) and freezes seven ADC codes that two types both construct today (:74-:80). Each carries an inline note naming the pair, for example CheckIns.EventNotPublished reached from CheckInProcessor, RecordRoomCheckIn and RecordSponsorVisit, and SessionQuestion.InvalidTransition reached from ModerateQuestionHandler and the SessionQuestion aggregate. The reasoning is stated once above them (:69-:73): each pair is the same failure reported at two entry points, so the sharing is the correct behavior, a client switching on the code wants one answer rather than three near-identical ones, and renaming them would break that client. The rule is therefore told the sharing is deliberate rather than told to look away.
  • MinimumErrorCodes => 57 (:107) raises the base floor of 1 (ErrorCatalogTestsBase.cs:43), and its documentation is the most instructive passage in the file (ErrorCatalogTests.cs:83-:106). The catalog held 73 distinct non-generic codes at adoption; the floor has since been lowered twice, and both times for the same non-alarming cause: a code stopped being a literal the IL scan can see, because it moved from an Error factory call in an ADC module into an argument of a framework member that builds the Error inside MMCA.Common. The comment records each move (70 to 66 when five X.NotDeleted codes moved into RestoreChild(notDeletedErrorCode: ...) arguments; 66 to 57 when eight more moved into ICurrentUserService.RequireUserId(code, ...) and CommonInvariants members), notes that the codes themselves ship unchanged, and states that the scanned count after the change is 60, measured from a run rather than modelled.
  • The three inherited facts are ErrorCodes_ShouldBe_Unique (ErrorCatalogTestsBase.cs:46), ErrorCodes_ShouldCarry_TheOwningModulePrefix (:50), and the non-vacuity check ErrorCodeCatalog_ShouldNotBe_Empty (:54). Prefix matching is prefix + ".", ordinal (:62-:67).
• Why it's built this way - codes are read out of IL at the Error factory call sites, so a code that is not a literal cannot be judged statically; the base lists such codes as UNVERIFIABLE in the failure message rather than passing or failing them (ErrorCatalogTestsBase.cs:9-:12). That design is exactly what makes the floor drift downward as code construction moves into framework arguments, and why the subclass documents each drop instead of quietly editing the number.
• Caveats / not-in-source - a scanner follow-up that would also read framework-member code arguments is described in the comment as tracked in the Wave 6 plan (ErrorCatalogTests.cs:90-:90); nothing in this repository implements it today. Also note the floor of 57 now sits below a measured 60, so it is a margin rather than an exact count.

EventConventionTests

MMCA.ADC.Architecture.Tests · MMCA.ADC.Architecture.Tests.Contracts · MMCA.ADC.Architecture.Tests/Contracts/EventConventionTests.cs:3 · Level 13 · class (public, sealed)

• What it is - the integration-event shape guard: every integration event declares a schema version, inherits the framework's base integration event, and lives in an *.IntegrationEvents namespace under Shared; and every event upcaster is unique and moves the version forward.
• Depends on - EventConventionTestsBase and AdcArchitectureMap. Map-only shape (ConcurrencyConventionTests).
• Walkthrough - one member, Map (:5). Five inherited facts (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Bases/Contracts/EventConventionTestsBase.cs:15, :17, :20, :23, :26). The first three enforce SchemaVersion, base-type inheritance, and namespace placement (ADR-010). The last two guard the upcaster machinery that ADR-010 depends on: EventUpcasters_ShouldHave_UniqueSourceTypes (:23), so two upcasters cannot claim the same source shape, and EventUpcasters_ShouldIncrease_SchemaVersion (:26), so an upcaster cannot map an event onto the same or an earlier version. [Rubric §6 - CQRS & Event-Driven] assesses the discipline around asynchronous contracts; this rule handles the shape, while IntegrationEventContractTests freezes the content.

FeatureFlagLifecycleTests

MMCA.ADC.Architecture.Tests · MMCA.ADC.Architecture.Tests.Governance · MMCA.ADC.Architecture.Tests/Governance/FeatureFlagLifecycleTests.cs:9 · Level 13 · class (public, sealed)

• What it is - the feature-flag lifecycle guard (ADR-031): every flag constant declares whether it is a permanent capability switch or a temporary rollout toggle, and a temporary one fails the build once its RemoveBy date has passed. Map-only shape (ConcurrencyConventionTests): the body is one line (MMCA.ADC.Architecture.Tests/Governance/FeatureFlagLifecycleTests.cs:11).
• Depends on - FeatureFlagLifecycleTestsBase and AdcArchitectureMap.
• Concept introduced, the dead-toggle detector. A flag that gates a finished rollout stops being a choice and becomes a branch nobody takes, and nothing else in a codebase notices; the base's summary names this the open trade-off the two rules close (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Bases/Governance/FeatureFlagLifecycleTestsBase.cs:4-:8). [Rubric §31 - Observability] and [Rubric §15 - Best Practices & Code Quality]: an undeclared flag or one still gating code long after its rollout finished is exactly the kind of silent drift a fitness function, not a code review, is positioned to catch on every build.
• Walkthrough - one member, Map (:11). Two inherited facts: FeatureFlags_ShouldDeclare_Lifetime (FeatureFlagLifecycleTestsBase.cs:21), delegating to ArchitectureRules.FeatureFlagsDeclareLifetime(Map), and TemporaryFeatureFlags_ShouldNotBe_PastRemoveBy (:24-:25), delegating to ArchitectureRules.TemporaryFeatureFlagsAreNotPastRemoveBy(Map, Today). Today is the base's virtual DateOnly Today => DateOnly.FromDateTime(DateTime.UtcNow) (:18), which ADC does not override, so the expiry check judges against the build's own clock rather than a frozen date.
• Why it's built this way - the [FeatureFlag(FeatureFlagLifetime.Permanent|Temporary, RemoveBy, Owner)] attribute and the FeatureFlagRegistry runtime inventory it feeds are the mechanism (MMCA.Common/CLAUDE.md, ADR-031's 2026-09-11 revision); this class is ADC's adoption of the pair of fitness rules built to enforce that attribute against ADC's own flag constants, mirroring the identical subclass shape MMCA.Common carries for its own flags.
• Caveats / not-in-source - adoption is per repo (ADR-031): the rule only ever sees flags declared in assemblies the map scans, so a flag constant outside those assemblies is invisible to it.

FormsConventionTests

MMCA.ADC.Architecture.Tests · MMCA.ADC.Architecture.Tests.Ui · MMCA.ADC.Architecture.Tests/Ui/FormsConventionTests.cs:13 · Level 13 · class (public, sealed)

• What it is - the UX-safety guard over ADC's admin forms. It is now a Map-plus-floor subclass of the shared rule: the whole body is two overrides, and the requiredness and Profile facts that ADC once hand-wrote here live in the base (MMCA.ADC.Architecture.Tests/Ui/FormsConventionTests.cs:13-:18). The <summary> still names what the nine Conference create forms must keep (:3-:12).
• Depends on - FormsConventionTestsBase and AdcArchitectureMap.
• Concept introduced, a default that became the convention. ADC used to replace the base's marker list and carry two facts of its own, because the shared rule could not yet reach the model-bridge markers, the shared *FormFields.razor component, or the Profile page. The base now defaults to exactly that set, so the subclass shrank to configuration: the summary says the base's default markers are the model-bridge set ADC uses and that the Identity Profile page is checked at the base's conventional path (FormsConventionTests.cs:10-:11). Rubric tags: [Rubric §24 - Forms/Validation/UX Safety] (users are protected from losing work and from unclear validation) and [Rubric §18 - UI Architecture] (the field block is a shared component the scan follows).
• Walkthrough
  • Map (:15) returns a new AdcArchitectureMap, and MinimumCreateForms => 9 (:17) lifts the base default of 1 (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Bases/Ui/FormsConventionTestsBase.cs:53) to ADC's nine Conference create forms (Activity, ConferenceCategory, Event, Partner, Question, Room, Session, Speaker, Sponsor; FormsConventionTests.cs:5-:6).
  • Three inherited facts run: AdminCreateForms_KeepUnsavedChangesGuardAndValidation (FormsConventionTestsBase.cs:148) checks the ten default RequiredMarkers (:63-:75): UnsavedChangesGuard, IsDirtyAccessor, _isDirty, <MudForm, Model="_model", Validation="@_validate", <ErrorSummary, Result="_saveResult", Messages="_form?.Errors" and Validation.CorrectFollowing. AdminCreateForms_ReadRequirednessOffTheirModel (:156) looks for ModelValidation.IsRequired across the create page plus its sibling *FormFields.razor. ProfileForm_KeepsErrorSummaryAndPasswordValidation (:188) checks the Profile page.
  • The Profile page path is the base's virtual ProfileFormPath (:82-:92), built as Source/Modules/Identity/{RepoToken}.Identity.UI/Pages/Users/Profile/Profile.razor; ADC does not override it.
• Why it's built this way - the Profile form is a single-section password and delete form with no navigate-away step, so it carries no unsaved-changes guard and does not match the *Create.razor glob; the base checks the markers that do apply instead (FormsConventionTestsBase.cs:86-:80). Hoisting the facts into the base means Store and any later consumer get the same coverage by subclassing.
• Caveats / not-in-source - ProfileFormPath is conventional, so moving ADC's Profile.razor fails the test until the property is overridden (the safe direction); the ADC AGENTS.md notes the same.

ForwardedJwtAudienceTests

MMCA.ADC.Architecture.Tests · MMCA.ADC.Architecture.Tests.Api · MMCA.ADC.Architecture.Tests/Api/ForwardedJwtAudienceTests.cs:10 · Level 13 · class (public, sealed)

• What it is - the fail-closed audience gate (ADR-004) for ADC's extracted service hosts: every host that calls AddForwardedJwtBearer must pass its audience as JwtAudience.RequireConfigured(configuration[JwtAudience.ConfigKey]) with no ?? fallback, so a host deployed without Jwt:Audience fails at startup rather than validating against a hard-coded default (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Bases/Api/ForwardedJwtAudienceTestsBase.cs:3-:10). The subclass is two members (MMCA.ADC.Architecture.Tests/Api/ForwardedJwtAudienceTests.cs:10-:15).
• Depends on - ForwardedJwtAudienceTestsBase, AdcArchitectureMap and ArchitectureRules.ForwardedJwtBearerAudienceIsFailClosed (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Rules/Api/ArchitectureRules.ForwardedJwt.cs:25).
• Concept introduced, a security default enforced by scanning source. The rule is a source scan, not a reflection check: it walks the *.cs files under SourceRoots (default: the repo's Source folder, ForwardedJwtAudienceTestsBase.cs:24-:25) and fails any AddForwardedJwtBearer call whose audience is not wrapped in RequireConfigured.
• Walkthrough - Map (:12) and MinimumForwardedJwtHosts => 3 (:14), the non-vacuity floor: the scan must find at least three calls, matching the base's description of "the repo's number of extracted service hosts that are not the token issuer" (ForwardedJwtAudienceTestsBase.cs:15-:19). ADC has four service modules and Identity issues the tokens, so three forwarding hosts is the expected count. One inherited fact, ForwardedJwtBearerHosts_ResolveTheirAudienceFailClosed (:27-:29).
• Why it's built this way - authored once in Common and re-run as a thin subclass per repo, the same shape as the other Map-plus-number subclasses (FormsConventionTests); the floor keeps the gate from passing vacuously if a refactor moves the call sites.
• Caveats / not-in-source - the count of three is a floor, not an equality: a fourth forwarding host does not fail the test, and a host that stops forwarding only fails once the count drops below three.

FrameworkVersionConsistencyTests

MMCA.ADC.Architecture.Tests · MMCA.ADC.Architecture.Tests.Governance · MMCA.ADC.Architecture.Tests/Governance/FrameworkVersionConsistencyTests.cs:9 · Level 13 · class (public, sealed)

• What it is - the lockstep-versioning gate: every MMCA.Common.* package pinned in ADC's Directory.Packages.props must carry one and the same version, so a partial sweep fails CI instead of producing a subtly mismatched framework surface at runtime (MMCA.ADC.Architecture.Tests/Governance/FrameworkVersionConsistencyTests.cs:3-:8).
• Depends on - FrameworkVersionConsistencyTestsBase and AdcArchitectureMap. Map-only shape (ConcurrencyConventionTests); the map is used for its repo token, to find the props file from the repo root.
• Concept introduced - a policy made executable. ADR-016 says consumers bump every MMCA.Common.* entry together, with no phased rollout. A policy that lives only in a document is enforced by memory; this rule enforces it by build. [Rubric §32 - Dependency & Supply-Chain] assesses how dependency versions are governed; [Rubric §15 - Best Practices & Code Quality]: a half-swept pin set is the kind of defect that surfaces as an unrelated runtime error weeks later.
• Walkthrough - one member, Map (:11). The inherited fact is AllMmcaCommonPackages_ArePinnedToOneVersion (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Bases/Governance/FrameworkVersionConsistencyTestsBase.cs:25), and the base's non-vacuity floor MinimumCommonPackageCount stays at its default of 13 (:22). ADC currently pins 16 MMCA.Common.* packages in MMCA.ADC/Directory.Packages.props, so the floor is met with room to spare.

HandlerConventionTests

MMCA.ADC.Architecture.Tests · MMCA.ADC.Architecture.Tests.Cqrs · MMCA.ADC.Architecture.Tests/Cqrs/HandlerConventionTests.cs:16 · Level 13 · class (public, sealed)

• What it is - the CQRS handler placement and composition guard: handlers and validators live in the Application layer, handlers do not inject other handlers, application services do not inject handlers, domain event handlers are sealed and live in Application, and application services respect a constructor-arity limit that ADC raises to ten (MMCA.ADC.Architecture.Tests/Cqrs/HandlerConventionTests.cs:18).
• Depends on - HandlerConventionTestsBase and AdcArchitectureMap.
• Walkthrough - two members. Map (:16) and MaxServiceConstructorParameters => 10 (:18), raising the base default of 8 (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Bases/Cqrs/HandlerConventionTestsBase.cs:12). Six facts are inherited (:15, :18, :21, :24, :27, :30). [Rubric §6 - CQRS & Event-Driven] assesses whether the command/query split is structural rather than nominal; a handler that injects another handler is the classic way that split quietly becomes a call graph. [Rubric §1 - SOLID] covers the arity half.
• Why it's built this way - the <remarks> (:6-:13) records both the reason for the raise and the coupling it creates. The shared AuthenticationServiceBase constructor took on the refresh-session store and its options, and ADC's subclass passed both through alongside the IExternalLoginEmailVerifier its OAuth auto-link gate needs; the rationale lives in ConstructorDependencyCountTests, which sets the same ceiling. Both moved 9 to 10 on 2026-09-23 for AuthenticationService, when the options holder that bundled its two settings objects into one slot was deleted (:11-:13). The last sentence of the <remarks> is the operative one: the two guards must move together, or the stricter one turns the other into a comment.
• Caveats / not-in-source - ADC therefore has two overlapping arity limits with the same value (10) but different scans (this one over application services generally, the sibling over *Service types in module Application assemblies). Whether they cover an identical type set is decided inside ArchitectureRules and is not determinable from these subclasses.

IntegrationEventPayloadPurityTests

MMCA.ADC.Architecture.Tests · MMCA.ADC.Architecture.Tests.Contracts · MMCA.ADC.Architecture.Tests/Contracts/IntegrationEventPayloadPurityTests.cs:14 · Level 13 · class (public, sealed)

• What it is - the guard on ADC's cross-service async contract (ADR-010): every integration event ships from a *.Shared assembly, and no property on its wire shape, including a nested payload record, reaches a type declared in a *.Domain assembly.
• Depends on - IntegrationEventPayloadPurityTestsBase and AdcArchitectureMap. Map-only shape (ConcurrencyConventionTests).
• Walkthrough - one member, Map (IntegrationEventPayloadPurityTests.cs:16). Two inherited facts, IntegrationEvents_ShouldShipFrom_SharedAssemblies and IntegrationEventPayloads_ShouldNotExpose_DomainTypes (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Bases/Contracts/IntegrationEventPayloadPurityTestsBase.cs:38, :41). [Rubric §9 - API & Contract Design] and [Rubric §7 - Microservices Readiness]: a domain event is an internal fact free to change with the model that raises it, an integration event is a public contract another service deserializes by shape and cannot be asked to redeploy because a producer renamed a field, and the two rules keep that distinction structural rather than cultural (IntegrationEventPayloadPurityTestsBase.cs:6-:10).

LayerDependencyTests

MMCA.ADC.Architecture.Tests · MMCA.ADC.Architecture.Tests.Layering · MMCA.ADC.Architecture.Tests/Layering/LayerDependencyTests.cs:3 · Level 13 · class (public, sealed)

• What it is - the Clean Architecture layer-flow guard, and the highest-fact-count rule in the unit: fifteen inherited facts covering which layer may reference which, plus one override that records Notification's deliberately thin shape (MMCA.ADC.Architecture.Tests/Layering/LayerDependencyTests.cs:15-:19).
• Depends on - LayerDependencyTestsBase and AdcArchitectureMap.
• Concept introduced, the per-module exception recorded where it is true. Two of the fifteen facts are map-completeness checks: LayerMap_DeclaresEveryExpectedLayer and LayerMap_ModulesDeclareEveryExpectedLayer (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Bases/Layering/LayerDependencyTestsBase.cs:53, :56) require the five core layers Shared, Domain, Application, Infrastructure, and Api to be declared, both overall and by every mapped module (:16-:17, :27). ADC has one module that legitimately cannot satisfy the module half, so it uses the narrow hook rather than the broad one. The base is explicit about why that matters (:22-:25): trimming RequiredModuleLayers would apply to every module, so one thin module would stop the rule from catching a forgotten assembly anywhere in the repo. [Rubric §3 - Clean Architecture] is the whole point of the rule; [Rubric §34 - Architecture Governance & Documentation]: the exception is written down, in code, at the one place it is true.
• Walkthrough - two members. Map (:5), and ModuleRequiredLayerOverrides (:15-:19), which overrides the base's empty dictionary (LayerDependencyTestsBase.cs:49-:50) with one entry mapping "Notification" to [Layer.Shared, Layer.Application, Layer.Api]. Its <summary> states the justification (LayerDependencyTests.cs:7-:14): Notification owns no aggregate and no persistence, so there is no Domain and no Infrastructure assembly to declare, and it has no pages of its own so there is no UI assembly either; its API project composes MMCA.Common's notification infrastructure (the SignalR hub and sender) directly rather than wrapping it in an ADC Infrastructure layer. The remaining thirteen facts (LayerDependencyTestsBase.cs:60 through :96) assert the directed rules: Domain depends on neither Application, Infrastructure, nor Api; Application on neither Infrastructure nor Api; Infrastructure not on Api; Shared on nothing above it; and Ui on none of Domain, Application, or Infrastructure. Note the two-gate model described in MMCA.Common/CLAUDE.md: the same boundaries are enforced at compile time in the framework by MMCA.Common.LayerEnforcement.targets, and here at test time against compiled assemblies.

LocalizedTextConventionTests

MMCA.ADC.Architecture.Tests · MMCA.ADC.Architecture.Tests.Ui · MMCA.ADC.Architecture.Tests/Ui/LocalizedTextConventionTests.cs:15 · Level 13 · class (public, sealed)

• What it is - the companion to TranslationCompletenessTests. Where that one asks "is every key translated", this one asks "does every user-visible string go through a key at all": no hard-coded literals in .razor or .razor.cs under Source/ (MMCA.ADC.Architecture.Tests/Ui/LocalizedTextConventionTests.cs:3-:14).
• Depends on - LocalizedTextConventionTestsBase and AdcArchitectureMap.
• Concept introduced - the per-line escape marker. Some literals genuinely should not be translated (the conference brand name, content data), so the rule exempts them with an i18n: allow comment on the offending line rather than an allowlist file (:10-:11). Keeping the exemption physically next to the literal is what makes it reviewable. [Rubric §27 - i18n], executing ADR-027.
• Walkthrough - the class is a thin subclass with no facts of its own: it declares only Map (:17) and MinimumScannedFiles => 60 (:19). The floor of 60 raises the base default of 1 (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Bases/Ui/LocalizedTextConventionTestsBase.cs:22); the comment sizes it against roughly 77 razor files across the three module UIs and the UI hosts (LocalizedTextConventionTests.cs:12-:13). The inherited fact is UserVisibleText_IsLocalized (LocalizedTextConventionTestsBase.cs:32), which resolves the repo root from Map.RepoToken and scans Source/ (:34-:38); the base's AllowedFiles hook (:29) is left empty, so ADC exempts nothing at file granularity. The scan covers snackbar messages, page Title properties, <PageTitle> markup, breadcrumb labels, NavItem titles (which must carry a TitleResource), and the shared delete confirmation's EntityType noun (LocalizedTextConventionTests.cs:6-:9).
  • The EntityType check lives in the shared rule, not in ADC. The delete confirmation renders EntityType in its dialog title and prompt, so a literal noun would show an English word inside a Spanish sentence. ArchitectureRules.UserVisibleTextIsLocalized tracks a DeleteConfirmation start tag across lines until it closes and reports any line matching the LiteralEntityType generated regex as file:line passes a literal EntityType to DeleteConfirmation (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Rules/Ui/ArchitectureRules.LocalizedText.cs:133-:146). That regex flags a quoted value not starting with @ or an unquoted bare word, so a razor expression such as EntityType="@EntityName" passes (:38-:41, with a 1000 ms match timeout). Omitting the attribute is also fine, because the component then falls back to its own localized generic noun.

MicroserviceExtractionTests

MMCA.ADC.Architecture.Tests · MMCA.ADC.Architecture.Tests.Layering · MMCA.ADC.Architecture.Tests/Layering/MicroserviceExtractionTests.cs:3 · Level 13 · class (public, sealed)

• What it is - the single-fact guard that transport never leaks into the core layers, so a module behaves identically in-process or extracted.
• Depends on - MicroserviceExtractionTestsBase and AdcArchitectureMap. Map-only shape (ConcurrencyConventionTests).
• Walkthrough - one member, Map (:5). One inherited fact, CoreLayers_ShouldNotDependOn_Transport (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Bases/Layering/MicroserviceExtractionTestsBase.cs:13). [Rubric §7 - Microservices Readiness] assesses whether extraction is a configuration change or a rewrite. ADC is the repo where this rule has already been cashed in: all four modules run as separate service hosts behind a YARP gateway (ADR-007, ADR-008), and the rule is what keeps the core layers clean enough for the next one.

ModuleIsolationTests

MMCA.ADC.Architecture.Tests · MMCA.ADC.Architecture.Tests.Layering · MMCA.ADC.Architecture.Tests/Layering/ModuleIsolationTests.cs:3 · Level 13 · class (public, sealed)

• What it is - the guard that Identity, Conference, Engagement, and Notification do not reach into each other: module Domains, Applications, Infrastructures, and APIs are each isolated from their siblings, neither Domain nor Application may reach another module's Infrastructure, and a seventh rule closes every remaining internal-layer pair.
• Depends on - ModuleIsolationTestsBase and AdcArchitectureMap. Map-only shape (ConcurrencyConventionTests).
• Walkthrough - one member, Map (:5). Seven inherited facts (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Bases/Layering/ModuleIsolationTestsBase.cs:13, :16, :19, :22, :25, :28, :36). The last, ModuleInternalLayers_ShouldNotReach_OtherModuleInternalLayers (:36), exists to close the coverage the first six leave open: every remaining cross-module internal-layer pair (Domain to another Application or Api, Application to another Domain or Api, Infrastructure and Api to anything but their own module), with UI excluded on purpose (:30-:34). The targets are computed by the map: for each module and layer it derives the other modules' root namespaces (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/ArchitectureMapBase.cs:69-:72), which is why adding a module to the map immediately expands what every other module is forbidden to touch. [Rubric §7 - Microservices Readiness] and [Rubric §5 - Vertical Slice]: cross-module collaboration in ADC goes through interfaces satisfied by gRPC clients, and this rule is what stops a direct reference from quietly becoming the cheaper option.

NamingConventionTests

MMCA.ADC.Architecture.Tests · MMCA.ADC.Architecture.Tests.Governance · MMCA.ADC.Architecture.Tests/Governance/NamingConventionTests.cs:3 · Level 13 · class (public, sealed)

• What it is - the ten-fact naming and sealing guard: handler, command, query, validator, DTO, specification, repository, and EF configuration suffixes, plus domain events sealed in a *.DomainEvents namespace and invariant classes static.
• Depends on - NamingConventionTestsBase and AdcArchitectureMap. Map-only shape (ConcurrencyConventionTests).
• Walkthrough - one member, Map (:5). Ten inherited facts (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Bases/Governance/NamingConventionTestsBase.cs:13 through :40). [Rubric §15 - Best Practices & Code Quality], and more practically [Rubric §15 - Best Practices & Code Quality]: several framework mechanisms (the Scrutor handler scan, the DTO/mapper registration, the decorator wrapping) find their targets by convention, so a naming slip is not cosmetic, it silently un-registers a type.

PiiConventionTests

MMCA.ADC.Architecture.Tests · MMCA.ADC.Architecture.Tests.Privacy · MMCA.ADC.Architecture.Tests/Privacy/PiiConventionTests.cs:18 · Level 13 · class (public, sealed)

• What it is - the privacy structural guard, in both directions (ADR-005): every domain entity declaring a PiiAttribute-marked property must implement IAnonymizable, so an entity that holds personal data always has an erasure path; and whatever Anonymize() overwrites must itself carry [Pii], so the audit trail redacts it instead of keeping the pre-erasure value as an OldValue.
• Depends on - PiiConventionTestsBase and AdcArchitectureMap.
• Walkthrough - two members: Map (:44) and AnonymizableSamples (:46), which overrides the base's empty default (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Bases/Governance/PiiConventionTestsBase.cs:31) with a private Samples dictionary (:20-:42). Three inherited facts: EntitiesWithPiiProperties_ShouldImplement_IAnonymizable (PiiConventionTestsBase.cs:34), EveryAnonymizableDomainEntity_IsCoveredBySample (:37), and PropertiesOverwrittenByAnonymize_MustCarryPii (:43). The reverse rule is behavioral, so it only sees what a sample actually populates. The Identity.Domain.Users.User sample is an external account (CreateExternal, which sets LoginProvider and ProviderKey) with every device field and an avatar filled in, so each field the erasure nulls starts at a value it has to move (PiiConventionTests.cs:23-:30). The Conference.Domain.Speakers.Speaker sample fills every profile field and links a user (:31-:41), so an Anonymize() that moved anything beyond the email would fail the reverse rule on a public field that carries no [Pii]. [Rubric §30 - Compliance/Privacy/Data Governance] assesses whether privacy obligations are structural rather than procedural: soft delete is the default everywhere in MMCA, so erasure has to be an explicit, tested capability (ADR-005). Unlike its counterpart in MMCA.Common, this instance is non-vacuous: ADC's Identity domain holds real attendee data.

PiiInventoryTests

MMCA.ADC.Architecture.Tests · MMCA.ADC.Architecture.Tests.Privacy · MMCA.ADC.Architecture.Tests/Privacy/PiiInventoryTests.cs:15 · Level 13 · class (public, sealed)

• What it is - the two-way personal-data inventory gate for ADC: the [Pii] markers in the domain code and the inventory table in PRIVACY.md must describe the same set of members (ADR-005).
• Depends on - PiiInventoryTestsBase (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Bases/Privacy/PiiInventoryTestsBase.cs:33), AdcArchitectureMap, and ArchitectureMapBase (statically, for the repo root). Companion to PiiConventionTests, which checks the erasure path rather than the documentation.
• Walkthrough - two members, both supplying the base's abstract inputs. Assemblies (PiiInventoryTests.cs:17) is every Domain-layer assembly the map knows, new AdcArchitectureMap().OfLayer(Layer.Domain). PrivacyPolicyPath (:19-:20) is PRIVACY.md at the repo root, found via FindRepoRoot("MMCA.ADC.slnx"). Two inherited facts do the work. PiiMembers_ShouldHave_CompleteInventoryRows (PiiInventoryTestsBase.cs:42) requires every [Pii] property to have an inventory row with the Purpose, Lawful basis and Retention cells filled. InventoryRows_ShouldMapTo_LivePiiMembers (:46) is the reverse, so the policy cannot keep promising things about data the code no longer marks. The table is any Markdown table in PRIVACY.md whose header holds Member, Purpose, Lawful basis and Retention, with the member written Type.Property (PiiInventoryTestsBase.cs:13-:25). If the file is missing, the base fails with a message naming the path (:51-:52). [Rubric §30 - Compliance/Privacy/Data Governance].

QueryHandlerReadRepositoryTests

MMCA.ADC.Architecture.Tests · MMCA.ADC.Architecture.Tests.Cqrs · MMCA.ADC.Architecture.Tests/Cqrs/QueryHandlerReadRepositoryTests.cs:9 · Level 13 · class (public, sealed)

• What it is - the read-repository guard: every IQueryHandler in ADC's module Application assemblies must take IUnitOfWork.GetReadRepository and never the write repository, since a query handler reads and the write repository hands it the mutation surface (add, remove, tracked reads) meant only for aggregate roots (MMCA.ADC.Architecture.Tests/Cqrs/QueryHandlerReadRepositoryTests.cs:3-:7).
• Depends on - QueryHandlerReadRepositoryTestsBase and AdcArchitectureMap. Map-only shape (ConcurrencyConventionTests).
• Walkthrough - one member, Map (:11). One inherited fact, QueryHandlers_ShouldUseReadRepositories (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Bases/Cqrs/QueryHandlerReadRepositoryTestsBase.cs:24-:26), delegating to ArchitectureRules.QueryHandlersUseReadRepositories(Map, AllowedHandlers), which reads the IL of every IQueryHandler<,> implementation in the map's Application assemblies, async and lambda bodies included (QueryHandlerReadRepositoryTestsBase.cs:6-:8). ADC adopts it with an empty allowlist: AllowedHandlers keeps the base's empty default, because every query handler already reads through the narrow interfaces (QueryHandlerReadRepositoryTests.cs:6-:7; QueryHandlerReadRepositoryTestsBase.cs:22). [Rubric §8 - Data Architecture] assesses this same read/write separation directly; ADC's read-only data access convention (handler locals take IEntityQuerier<,>/IEntityReader<,> from IUnitOfWork.GetReadRepository<>()) is what this rule verifies structurally rather than by review.
• Why it's built this way - the base's own doc comment states the adoption path for a repo with existing offenders: subclass, run once, and either switch each reported handler to GetReadRepository or move it into AllowedHandlers with a comment saying why it needs the write surface (QueryHandlerReadRepositoryTestsBase.cs:9-:13). ADC needed neither: the empty allowlist means the rule already passed clean on adoption.
• Where it's used - MMCA.Common carries the base's own self-test in MMCA.Common.Architecture.Tests, which runs the same rule over Common's own Application layer and also over compiled fixtures in ReadRepositoryFixtures, proving the IL-reading rule catches a write-repository call sitting after an await, inside the compiler's state machine (MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/Cqrs/Repositories/QueryHandlerReadRepositoryTests.cs:8-:12, :23-:26).

RawQueryableConventionTests

MMCA.ADC.Architecture.Tests · MMCA.ADC.Architecture.Tests.Cqrs · MMCA.ADC.Architecture.Tests/Cqrs/RawQueryableConventionTests.cs:11 · Level 13 · class (public, sealed)

• What it is - the rule that Application-layer code must not use the repository's raw IQueryable surfaces (Table / TableNoTracking*), carrying a seven-file allowlist that pins ADC's existing deliberate uses (MMCA.ADC.Architecture.Tests/Cqrs/RawQueryableConventionTests.cs:3-:10, :33-:49).
• Depends on - RawQueryableConventionTestsBase, AdcArchitectureMap, ArchitectureMapBase (statically, for the repo root at :28), and System.IO.Path.
• Concept introduced, the adoption ratchet. A convention introduced into a codebase that already violates it in seven places has two bad options: fail the build on day one, or exempt the whole layer. The ratchet is the third: enumerate the existing violations explicitly so that new code is what the rule blocks, then shrink the list over time. The comment states the discipline directly, "Shrink it over time; never grow it without the same scrutiny" (:8-:9). [Rubric §8 - Data Architecture] assesses how query access is layered; [Rubric §7 - Microservices Readiness] is the stated motivation: a raw-queryable handler is EF-coupled and cannot move behind a gRPC boundary (:5-:6).
• Walkthrough - three members.
  • Map (:13).
  • ApplicationSourceDirectories() (:21-:30) overrides the base's virtual enumeration (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Bases/Cqrs/RawQueryableConventionTestsBase.cs:45) by yielding everything the base produces (:23-:26) and then appending one more path: Source/Modules/Notification/MMCA.ADC.Notification.Application, resolved from FindRepoRoot("MMCA.ADC.slnx") (:28-:29).
  • AllowedFiles (:33-:49) overrides the base's empty default (RawQueryableConventionTestsBase.cs:38) with seven file names, each grouped under a comment saying why it is exempt: the Engagement live layer's conference-day hot-path aggregations, which need GROUP BY and COUNT shapes the focused repository surface cannot express (LivePollResultsBuilder, SessionQuestionViewBuilder, GetModerationQueueHandler, GetSessionQuestionsHandler, :35-:40); the Engagement bookmark count and page projection (BookmarkCountService, GetUserBookmarksHandler, :42-:45); and Notification's GDPR export joins (UserNotificationExportService, :47-:48). The two Identity entries (the user-list paging handler and the administration-roster service) are no longer allowlisted. Every entry is annotated as intra-module, which is the actual test for whether an exemption is safe: the queries never cross a module boundary, so they would travel with the module if it moved.
  • The inherited fact is ApplicationLayer_DoesNotUseRawQueryableSurfaces (RawQueryableConventionTestsBase.cs:61), a textual scan rather than an assembly scan, which is why it needs directories rather than the map's assemblies; it also asserts the directory set is non-empty first (:65-:66).
• Caveats / not-in-source - AllowedFiles matches by file name, not by path, so two files with the same name in different modules would both be exempted. The <remarks> on the directory override still says the thin Notification module "is not a mapped module" (:16-:20), but AdcArchitectureMap now registers it (AdcArchitectureMap.cs:52-:54) and the base derives its directories from Map.ModuleNames (RawQueryableConventionTestsBase.cs:50-:57), so the appended path is a duplicate of one the base already yields and the comment no longer matches the map. Nothing here enforces the "shrink it over time" discipline the class comment asks for.