Onboarding guide

27. Testing & Quality Infrastructure

What this group covers. Everything the codebase uses to prove itself: the four reusable test-support packages that ship out of MMCA.Common/Source/Hosting (MMCA.Common.Testing, MMCA.Common.Testing.Architecture, MMCA.Common.Testing.E2E, MMCA.Common.Testing.UI, four of the packages published from MMCA.Common and listed in MMCA.Common/FACTS.md:19-38), 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, 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 six moving parts. Five map onto the test pyramid plus one governance layer; the sixth evaluates a dependency that is not deterministic and so cannot be asserted exactly:

1. Integration-test scaffolding (IIntegrationTestFixture, IntegrationTestBase<TFixture>, SqlServerIntegrationTestFixtureBase<TEntryPoint>, CrossServiceFixtureBase, 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 twenty-nine ArchitectureRules partial files, and the forty-six abstract *TestsBase classes including RouteAuthorizationTestsBase, ModuleConformanceTestsBase<TModule> 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) render Blazor components in isolation with real MudBlazor services and faked HTTP/auth edges.
4. End-to-end (Playwright) testing (PlaywrightFixture, E2ETestBase, E2ETestConfiguration, AuthOutcomeRules, PageExtensions, AxeOptions, AccessibilityViolationException, WebVitalsCollector, the reusable page objects LoginPage / RegisterPage / ProfilePage / ForgotPasswordPage / ResetPasswordPage, and the shipped workflow suites such as AuthorizationTestsBase) drive a real browser against a running app, asserting accessibility and performance alongside behavior.
5. Contract and pipeline bases (SecurityHeadersTestsBase, OpenApiContractTestsBase<TFixture>, 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, ReplayHandler, LiveJudgeTests, PromptContractTests) 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.

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 (:81-84). It then builds a Respawn checkpoint that ignores __EFMigrationsHistory (:90-94); ResetDatabaseAsync (:99) replays that checkpoint between tests, and DisposeAsync (:115) drops the throwaway database (:167) and restores every pushed environment variable (:130, restore loop at :157-165, first-value-wins bookkeeping at :146-155 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 (:142, 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:41), 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). 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].

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 thirty ArchitectureRules partial files (cancellation tokens, cascade soft-delete, command validators, contracts, controllers, cycles, domain-event handler saves, domain throws, entities, error catalog, events, folder width, governance, handlers, handler results, idempotency, immutability, layers, localization, localized text, markup, modules, naming, protos, purity, slices, soft delete, specifications, 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/, forty-seven files today (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. 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:45-50: 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:15, [Rubric §32, Dependency & Supply-Chain]) checks the repo's pinned package majors and fails the build on two commercial-license traps a blanket package bump would otherwise walk into unnoticed: MassTransit at major 9 (DependencyVersionTestsBase.cs:24-37, ADR-016) and SixLabors.ImageSharp at major 4, whose MSBuild targets fail at build time without a license key (DependencyVersionTestsBase.cs:47-60). ConstructorDependencyCountTestsBase (Bases/ConstructorDependencyCountTestsBase.cs:14) turns the SRP judgement call into a numeric ceiling on Application-service constructors ([Rubric §1, SOLID]), with its own non-vacuity guard so a scan that finds no services fails rather than passes (Bases/ConstructorDependencyCountTestsBase.cs:33-34), and ObservabilityConventionTestsBase (Bases/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/ObservabilityConventionTestsBase.cs:6-13,39, [Rubric §13, Observability & Operability]).

Five of the newer bases show how far the pattern has been pushed. CancellationTokenConventionTestsBase (Bases/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/CancellationTokenConventionTestsBase.cs:3-9), with signatures the repo does not own exempted automatically (:11-14). NamespaceCycleTestsBase (Bases/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/NamespaceCycleTestsBase.cs:3-13). IdempotencyConventionTestsBase (Bases/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/IdempotencyConventionTestsBase.cs:3-8). ProtoContractTestsBase (Bases/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/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-12, 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.

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:37) 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:58, the provider class at :162) plus an IsAuthenticatedAuthorizationService (BunitComponentTestBase.cs:57, class at :176) so both <AuthorizeView> cascades and pages that inject the provider directly behave. Tests render anonymously by default via RenderUnderTest<TComponent> (BunitComponentTestBase.cs:124) or as a supplied ClaimsPrincipal via RenderAs<TComponent> (BunitComponentTestBase.cs:130, which sets the provider and the cascading AuthenticationState together at :135-140), with a SetUser hook (:121) 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:148) mounts the popover, dialog, and snackbar providers and returns them as a MudProviderHandles record (BunitComponentTestBase.cs:157) 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:100) 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:19), 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:21) 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). 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:8), whose nested AdminCredentials (E2ETestConfiguration.cs:66) and UserCredentials (E2ETestConfiguration.cs:78) 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:27) tunes the slowest step, the post-auth round-trip, independently of the 30-second general default (:18-19), and AuthGraceTimeout (E2ETestConfiguration.cs:38, default 15 seconds at :39) 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); 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:16-20, host built by BuildApp at :28). 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:38-48).

The host runs without a backend by registering stubs before AddUIShared so its TryAdd* registrations defer to them (GalleryHost.cs:55-63, AddUIShared at :95): 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:78-80), the framework's NullNotificationScopeProvider for the unscoped send page (GalleryHost.cs:85), and one empty GalleryUIModule (Stubs/GalleryUIModule.cs:14, registered at GalleryHost.cs:90) 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:19, registered at GalleryHost.cs:69-73) 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:99-108), 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:11) is one case: a session proposal, the exact Anthropic Messages API response recorded for it, and the band its overall score has to land in (GoldenCase.cs:7-10). GoldenCorpus (GoldenCase.cs:100) loads every case-*.json from the copied Golden/ folder ordered by id so a run is deterministic (GoldenCase.cs:112-123), and throws when it finds none, so a csproj that stopped copying the corpus fails loudly instead of passing on zero cases (GoldenCase.cs:125-128); it also exposes the Golden/prompt-versions.json path that maps a prompt version to its recorded hash (GoldenCase.cs:108-110).

Three suites read that corpus, and they fail for three different reasons. GoldenReplayTests (GoldenReplayTests.cs:25) is the regression half: every case runs through the real AnthropicScoringService against a ReplayHandler (GoldenReplayTests.cs:161) that returns the response recorded for it, so no API key and no network are involved and it runs on every CI leg (GoldenReplayTests.cs:13-15). It pins both directions at once, what goes out (the delimited envelope and the untrusted-input brief are asserted on the wire, including for the cases with no speakers and with an injection attempt) 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:17-22,47-60). LiveJudgeTests (LiveJudgeTests.cs:27) is the live half, scoring the same proposals through the real API 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 costs money and needs a key, so it is trait-gated Category=AiEval.Live and skips itself when ANTHROPIC_API_KEY is absent (LiveJudgeTests.cs:14-17,29). 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:20-24).

PromptContractTests (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 (PromptContractTests.cs:16-22). The canonical proposal is fixed in the test file rather than read from the corpus on purpose (PromptContractTests.cs:37-45), because editing a golden case must not be able to change what the contract hash covers (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 (PromptContractTests.cs:34-35). Together the three 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.

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:22, 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:141), 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:29) 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:371), 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:144), so a discovery regression that silently drops thousands of tests fails the build instead of reporting a green, empty run.

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

AbstractAnonymousFixtureControllerBase, AnonymousFixtureController, TypeLevelAnonymousFixtureController

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.Api · (see per-type table) · Level 0 · class

Three throwaway MVC controllers nested inside AnonymousEndpointTestsBaseTests (MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/AnonymousEndpointTestsBaseTests.cs). Between them they cover every placement of [AllowAnonymous] the scan has to recognize: on an action of a concrete controller, on an action of an abstract base, and on the controller type itself. They are the input side of the anonymous-endpoint allow-list gate; the subclasses that consume them supply the expectations.

• Depends on - Microsoft.AspNetCore.Mvc.ControllerBase and Microsoft.AspNetCore.Authorization.AllowAnonymousAttribute (AnonymousEndpointTestsBaseTests.cs:1-:2). No state, no behavior: every action is => Ok().
• Concept introduced - an allow-list is only as good as the identifier shapes it can be written in. AnonymousEndpointTestsBase turns each discovered [AllowAnonymous] into a string, and there are exactly two shapes: a type-level attribute becomes the type's FullName, and a method-level attribute becomes {declaring type FullName}.{method name} (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Bases/Api/AnonymousEndpointTestsBase.cs:133-:152). A repo's allow-list is hand-written against those strings, so if the emitter and the hand-written convention ever disagree the gate silently reports phantom offenders or, worse, accepts a stale entry. These three fixtures exist so both shapes are produced by a real scan and matched by a real allow-list in the framework's own CI. Two scoping decisions in the base are also on display here: ControllerBase, RouteAttribute and AllowAnonymousAttribute are all matched by full name through reflection (:32-:34) so the rule package carries no ASP.NET reference, and abstract controllers are deliberately included in the scan (IsController walks BaseType, :101-:112) because a framework base action is where the attribute is declared. [Rubric §11 - Security] assesses whether the authorization posture of the HTTP surface is deliberate; an ungated endpoint that nobody reviewed is the single cheapest way to lose an app. [Rubric §26 - Front-End Security] extends the same scan to routable Blazor components (IsRoutableComponent, :117-:118). [Rubric §14 - Testability] covers the fixtures themselves.
• Walkthrough - the scan enumerates LoadableTypes of each target assembly, keeps controllers and routable components, and projects each survivor through AnonymousEndpointsOf, distinct and ordinal-ordered (AnonymousEndpointTestsBase.cs:125-:131). Methods are read with BindingFlags.DeclaredOnly and inherit: false (:142,:146), which is what decides where an inherited action gets reported (see InheritingFixtureController).

• Why they're built this way - a gate whose fixtures only ever exercise one attribute placement would pass while being blind to the other, and the failure would land in a consumer repo rather than here. Nesting the fixtures inside the test class keeps them out of the assembly's public surface and, critically, out of the framework's real AnonymousEndpointTests scan, which targets the API and UI assemblies rather than this one. See ADR-015.
• Where they're used - scanned by the four nested subclasses DriftedTests, StaleAllowListTests, EmptyScanTests and ConformantTests, and named in the assertions of AnonymousEndpointTestsBaseTests.

AbstractFitnessControllerBase, IdempotentFitnessController, NonIdempotentFitnessController, UndeclaredFitnessController

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.Cqrs · (see per-type table) · Level 0 · class

Four throwaway MVC controllers nested inside IdempotencyFitnessTests (MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/IdempotencyFitnessTests.cs). Each is a ControllerBase subclass with exactly one [HttpPost] action, and the only thing that varies between them is which idempotency attribute the action carries. Together they form the truth table for the PostActionsDeclareIdempotencyIntent fitness function: one offender, one covered directly, one covered by inheritance, one opted out with a reason, and one abstract declaration site that must be skipped entirely.

• Depends on - Microsoft.AspNetCore.Mvc.ControllerBase (IdempotencyFitnessTests.cs:1), plus IdempotentAttribute and NonIdempotentAttribute from MMCA.Common.API.Idempotency (:2). Nothing else: these types have no state and no behavior worth exercising.
• Concept introduced - declared idempotency intent, and the truth table that proves a gate reads it. A POST that is retried by a client, a proxy, or a mobile app on a flaky connection either replays its original response or writes twice. IdempotentAttribute opts an action into the replay path served by IdempotencyFilter; NonIdempotentAttribute records in code why replaying would be wrong (issuing a token, revoking a credential, exchanging a single-use code). What the framework will not accept is silence, so ArchitectureRules.PostActionsDeclareIdempotencyIntent (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Rules/Cqrs/ArchitectureRules.Idempotency.cs:44) fails the build on any POST carrying neither attribute. These four fixtures exist because a gate like that has four distinct behaviors to prove, not one. [Rubric §9 - API & Contract Design] assesses whether the HTTP surface states its own semantics; a declared retry posture is part of the contract, not an implementation detail. [Rubric §29 - Resilience & Business Continuity] is the reason the rule exists at all: retries are the default failure response of every modern client, so a POST with undeclared replay semantics is a duplicate-write incident waiting for a network blip. [Rubric §14 - Testability] covers the fixtures themselves, which turn each branch of the rule into an observable case.
• Walkthrough - the rule reads attributes by simple type name ("IdempotentAttribute", "NonIdempotentAttribute", "HttpPostAttribute", ArchitectureRules.Idempotency.cs:6,:9,:12) so the rule package keeps no ASP.NET reference, and it reads them with inherit: true (:80-:81), which is what makes the inherited case work. Two filters decide what is even looked at: .SelectMany(a => a.ConcreteClasses) (:49), whose helper keeps only non-abstract classes (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/RuleHelpers.cs:36-:37), and .Where(IsController) (:51).

• Why they're built this way - a fitness function that only ever sees compliant code proves nothing, and one that flags everything is worse than none. Four controllers whose only difference is the attribute set turn the rule into something with a pass and a fail on either side of each branch (ADR-015). Keeping them nested inside the test class keeps them out of the assembly's public surface and out of any other rule's reach.
• Where they're used - reflected over by IdempotencyFitnessTests through IdempotencyTestMap, which registers this test assembly as the map's single Api layer.
• Caveats / not-in-source - these fixtures deliberately derive from raw ControllerBase rather than ApiControllerBase, which the framework's separate controller-inheritance rule would flag. They escape it only because that rule runs over CommonArchitectureMap, which does not include this test assembly.

ArchiveTicketCommand, CreateTicketCommand, PurgeTicketsCommand, RebuildTicketIndexCommand, ReopenTicketRequest, UpdateTicketRequest

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.CommandValidatorFixtures · (see per-type table) · Level 0 · record

Six internal sealed record payload types in one file (MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/CommandValidatorFixtures/CommandValidatorFixtures.cs), each a positional record with at most one property. They are the input side of the command-validation coverage truth table: four commands that a handler will pick up, and two request records that a bridged command embeds.

• Depends on - nothing beyond the BCL, except that the file as a whole references ICommandHandler<in TCommand, TResult> and ICommandWithRequest<out TRequest> from MMCA.Common.Application.UseCases (CommandValidatorFixtures.cs:2) and FluentValidation (:1). These six records implement neither: they are pure payload.
• Concept introduced - what makes a command "data-carrying", and why that decides whether it is judged at all. The validation-coverage rule does not ask "does every command have a validator". It asks the narrower question "does every command that could carry bad input have something checking it", and the test for that is mechanical: at least one public instance property with a public setter, init included (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Rules/Cqrs/ArchitectureRules.CommandValidators.cs:135-:138). A positional record is exactly that shape, which is why the usual command is inspected and why a payload-free marker command is skipped as having nothing to validate (rule remarks, :19-:21). The rule then keeps only commands whose type appears as the TCommand of some concrete ICommandHandler in scope, and only closed ones: an open generic handler base contributes a type parameter, not a command a repo ships (:96-:102). [Rubric §6 - CQRS & Event-Driven] assesses whether the command surface is a governed contract rather than an ad-hoc bag of DTOs. [Rubric §24 - Forms/Validation/UX Safety] is the property being defended at its far end: the Validating decorator runs before the transaction opens, so a command with no validator carries whatever the caller sent straight into the handler and the pipeline stage exists with nothing to run (rule doc, :9-:13). [Rubric §14 - Testability] covers the fixtures.
• Walkthrough - the file's header doc (:7-:12) enumerates the shapes deliberately: a command covered by its own validator, one covered only through the request bridge, one covered by neither, one carrying no payload at all, and a bridge command whose request has no validator.

• Why they're built this way - two uncovered commands rather than one is the load-bearing choice: an allowlist test that had only a single offender could not distinguish "the exemption worked" from "the rule stopped firing". Keeping every record to one property means a change in the rule's classifier is diagnosed by which fixture moved rather than by reading a wall of assertion output. See ADR-015.
• Where they're used - handled by the six fixture handlers (ArchiveTicketHandler and family), scanned through FixtureModuleMap, and named by nameof in the assertions of CommandValidatorCoverageFitnessTests.

ArgumentGuardFixture, IndirectThrowFixture, InvalidOperationThrowingFixture, NonThrowingFixture, RethrowingFixture, TicketDomainException

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.DomainThrowFixtures · (see per-type table) · Level 0 · class

Six types in one file (MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/DomainThrowFixtures/DomainThrowFixtures.cs): five static classes holding compiled throw sites and one custom exception for them to throw. They are the truth table for the domain-throw rule, which reads IL, so the only honest way to test it is to compile the throws it must and must not flag into this assembly and point a map at it (file doc, :3-:8).

• Depends on - the BCL only: ArgumentException, ArgumentNullException, ArgumentOutOfRangeException, InvalidOperationException, Exception, Action, ICollection<string>.
• Concept introduced - the Result pattern's build-time boundary, and the three exceptions it still allows. ADR-013 says the domain reports failure by returning Result, never by throwing: a thrown business failure skips Result.Combine invariant composition, turns a 4xx outcome into a 500, and pays an exception unwind on a path that is not exceptional (rule doc, MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Rules/Domain/ArchitectureRules.DomainThrows.cs:23-:29). The rule is not "never throw", though. Argument guards report a caller bug rather than a business outcome, and a caller cannot recover from passing null, so there is nothing for a Result to carry; exactly three exception types are permitted (:16-:21). Everything else in a Domain assembly is a violation. The mechanism is deliberately narrow: for each throw opcode the rule looks at the immediately preceding instruction, skipping the nops a Debug build interleaves, and reads the exception type off a newobj (:143-:154). If the preceding instruction is anything else, the thrown value came from somewhere the instruction stream cannot name, and the site is reported as UNVERIFIABLE rather than guessed at (:127-:131). [Rubric §4 - DDD] assesses whether the domain expresses outcomes in its own vocabulary; an exception is control flow borrowed from the host. [Rubric §15 - Best Practices & Code Quality] and [Rubric §14 - Testability] cover the rest.
• Walkthrough - a bare throw; inside a catch compiles to the distinct rethrow opcode, not throw, so it never even enters the scan (fixture doc, :72-:75). The rule also skips compiler-synthesized bodies: the skeleton members of a C# extension(T) block, and the explicit interface implementations on compiler-generated types such as the read-only list wrapper emitted for a collection expression (:156-:177).

• Why they're built this way - the rule has five outcomes (allowed guard, business exception, custom exception, rethrow, unverifiable) plus a clean case, and each needs a subject that trips exactly one of them. Every fixture except TicketDomainException is internal static, so nothing here widens the assembly's public surface, and putting them in their own namespace lets one allowlist entry silence the whole set for the escape-hatch facts. See ADR-015.
• Where they're used - scanned by DomainThrowFitnessTests through its FixtureAssemblyMap, which registers this test assembly as the map's single Domain layer.

CompliantFixtureService, MissingTokenFixtureService, MisplacedTokenFixtureService, MisnamedTokenFixtureService, ExemptableFixtureService, ExternalContractFixtureService

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.CancellationFixtures · (see per-type table) · Level 0 · class

Six tiny services in one file (MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/CancellationFixtures/CancellationTokenFixtures.cs), each a hand-shaped input for one branch of the AsyncMethodsDeclareTrailingCancellationToken fitness function. None of them does any work; the method signatures are the fixture.

• Depends on - the BCL only: Task/ValueTask, CancellationToken, IAsyncEnumerator<T>, and one [SuppressMessage] from System.Diagnostics.CodeAnalysis (CancellationTokenFixtures.cs:1).
• Concept introduced - the trailing-token convention, and why it is enforced mechanically. Work that cannot be cancelled keeps running against the database after its caller is gone. The framework's rule is not "accept a token somewhere" but the far stricter "every public awaitable method on an Application or Infrastructure type ends with a parameter of type CancellationToken named exactly cancellationToken" (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Rules/Cqrs/ArchitectureRules.CancellationTokens.cs:35). The uniformity is the point: only a positionally and nominally fixed parameter lets the decorator pipeline and the repositories forward a linked token mechanically, without a per-method decision. The rule scans only the Application and Infrastructure layers (:45-:47), only publicly visible non-delegate types (:92-:94), and only public, non-special-name, non-Dispose methods whose return type is Task, Task<T>, ValueTask, or ValueTask<T> (:97-:103). TokenProblem (:115) then classifies each survivor into one of three messages: "no CancellationToken parameter" (:134), "the CancellationToken must be the LAST parameter" (:131), or "the trailing CancellationToken must be named 'cancellationToken'" (:130). [Rubric §12 - Performance & Scalability] assesses whether the system sheds abandoned work instead of paying for it; an uncancellable query holds a connection for the full duration of a request nobody is waiting for. [Rubric §6 - CQRS & Event-Driven Design] applies because cancellation is plumbing that has to be uniform to be automatable, and [Rubric §14 - Testability] because these six fixtures are what make the classifier provable rather than assumed.
• Walkthrough - two escape hatches also need fixtures, and they work differently. The explicit one is the exemptMethods parameter (ArchitectureRules.CancellationTokens.cs:37), a caller-supplied list matched as "TypeName.MethodName" (:78); it exists for shipped public APIs where adding a parameter would be a breaking change. The automatic one is ExternallyFixedMethods (:141), which drops any method that overrides a base declared outside the map's assemblies or implicitly implements an interface declared outside them: a signature this repo does not own is not this repo's to fix.

• Why they're built this way - the six shapes are the rule's entire decision surface. Putting them in their own CancellationFixtures namespace keeps them out of the way of the other fitness maps in this assembly, and keeping every one of them trivial means a future change to the rule's classifier is diagnosed by which fixture moved, not by a wall of assertion output. See ADR-015.
• Where they're used - driven entirely by CancellationTokenFitnessTests through CancellationTestMap.

IBadgeGranter

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.DomainEventSaveFixtures · MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/DomainEventSaveFixtures/DomainEventSaveFixtures.cs:64 · Level 0 · interface

• What it is - a one-method fixture abstraction with a single implementation, existing only so that one of the domain-event handler fixtures reaches its save through an interface call rather than a direct one.
• Depends on - nothing. internal interface IBadgeGranter with Task GrantAsync(CancellationToken cancellationToken) (DomainEventSaveFixtures.cs:64-:67).
• Concept introduced - why an IL walk has to resolve interface dispatch, and why a fixture must force it to. Domain event handlers run inside the save that raised the event: dispatch happens after SaveChangesAsync, or after commit inside a transactional command. A handler that saves again therefore opens a second write in the middle of the first one, re-entering the change tracker, possibly raising a fresh event cascade, and persisting work the outer transaction may still roll back (rule doc, MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Rules/Cqrs/ArchitectureRules.DomainEventHandlerSaves.cs:23-:29). Catching that means following what a handler calls, and in IL a call through an abstraction records only the interface method: callvirt IBadgeGranter::GrantAsync, with no trace of the implementation that will actually run. A walker that stopped there would report nothing. The rule therefore expands each callee to the implementations in scope through CallGraphIndex, and this interface is the fixture that makes that expansion observable. The doc says it in one line: the collaborator is an abstraction, so IL records only the interface call (:63). [Rubric §6 - CQRS & Event-Driven] is the property; [Rubric §14 - Testability] is why the fixture exists. Full mechanism at DomainEventHandlerSaveFitnessTests.
• Walkthrough - one member, GrantAsync(CancellationToken) (:66). It takes a token but returns nothing meaningful; the signature exists only to be callable.
• Where it's used - implemented by BadgeGranter (:70) and injected into InterfaceDispatchSavingHandler (:83).

IFakeExportService

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.Layering · MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/Layering/ModuleConformanceTestsBaseTests.cs:25 · Level 0 · interface

• What it is - a marker-only cross-module contract that exists purely as test data: it stands in for the kind of service one module exports and another module resolves, so the module-conformance base can be proven to reach a real DI container.
• Depends on - nothing. The whole declaration is public interface IFakeExportService; (ModuleConformanceTestsBaseTests.cs:25), a body-less interface using the semicolon form, with a one-line doc above it (:24).
• Concept introduced - the cross-module export contract, in miniature. Under the module system (IModule, ModuleLoader), a module that is switched off in ModulesSettings still has to leave behind stub registrations, otherwise every other module that resolves its exported interface fails to construct. IFakeExportService is the smallest possible stand-in for such an exported interface. [Rubric §14 - Testability] assesses whether a rule can be proven with focused inputs; a marker interface is the least amount of surface that still lets the fitness base observe a real ServiceDescriptor.
• Walkthrough - no members. Its only role is to be the ServiceType that FakeDependentModule registers a stub against (:44) and that FakeDependentModuleConformanceTests looks up in the built collection (:74).
• Why it's built this way - a real cross-module contract would drag a module's whole application surface into the framework's architecture-test assembly. A local marker keeps the fixture self-contained, which is the same discipline the rule library itself follows (it matches framework types by full name rather than referencing them).
• Where it's used - implemented by DisabledFakeExportService and registered by FakeDependentModule.

LeftModelBase

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.CycleFixtures.Left · MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/CycleFixtures/Left/LeftFixtures.cs:13 · Level 0 · class

• What it is - one arm of a deliberately-built namespace cycle: an abstract base living in the Left fixture namespace, which a type in the Right namespace derives from. That inheritance edge is what closes the loop back into Left.
• Depends on - nothing. It is public abstract class LeftModelBase with a single int Id { get; set; } (LeftFixtures.cs:13-:17).
• Concept introduced - namespace cycles, and how a structural rule sees them. ArchitectureRules.NamespacesHaveNoDependencyCycles (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Rules/Layering/ArchitectureRules.Cycles.cs:45) groups a layer's types by the namespace segment directly beneath the layer's RootNamespace, records a directed edge A -> B whenever a type in A structurally references a type in B in the same assembly, and reports every strongly connected component of that graph (:12-:16). "Structurally" is precise here: base types, implemented interfaces, field and property types, method return and parameter types (public and non-public), and attribute types, with generics and array elements expanded (:25-:27). What it deliberately cannot see is a reference that exists only inside a method body, because the package carries no IL or Roslyn dependency (:30-:36), so a clean report is a statement about the type surface, not a claim of zero coupling. A base class is therefore the cheapest possible cycle edge to build: inheritance is always visible to reflection. [Rubric §34 - Architecture Governance & Documentation] assesses whether the codebase stays reasonable to reason about, and a two-namespace cycle is the classic early warning that two folders can no longer be understood, tested, or moved independently. [Rubric §7 - Microservices Readiness] is the sharper consequence: neither namespace can be extracted without the other.
• Walkthrough - one auto-property, int Id (:16), present only so the type is not empty. Being abstract is irrelevant to the cycle rule (which walks the type surface, not ConcreteClasses); what matters is that RightModel names it as a base.
• Why it's built this way - the fixture pair models the smallest honest cycle: one edge through a property type and one through inheritance, so the rule is proven against both edge kinds it claims to detect rather than just the easy one.
• Where it's used - the base of RightModel; the pair drives NamespaceCycleFitnessTests through CycleTestMap.

CreateTicketCommandValidator, UpdateTicketRequestValidator

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.CommandValidatorFixtures · (see per-type table) · Level 1 · class

Two one-line FluentValidation validators, identical in shape and different only in what they validate. Between them they supply both forms of coverage the command-validation rule accepts: a validator for the command itself, and a validator for the request a bridged command embeds.

• Depends on - FluentValidation.AbstractValidator<T> (CommandValidatorFixtures.cs:1) and the record each one validates.
• Concept introduced - direct coverage versus bridge coverage, and why the bridge needs both halves. A command is covered when a concrete IValidator<TCommand> exists for it, or when the command implements ICommandWithRequest<TRequest> and a concrete IValidator<TRequest> exists (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Rules/Cqrs/ArchitectureRules.CommandValidators.cs:112-:115). The second condition insists on both halves for a reason the rule doc spells out (:23-:29): CommandRequestValidator<TCommand, TRequest> is auto-registered for every bridged command, so a naive check for "is a validator registered" would always say yes, while the bridge adds no rule at all when no request validator resolves. Half a bridge is a validator that validates nothing. The rule also reads commands and validators from the same place the framework's AddValidatorsFromAssembly scan looks, the per-module Application assemblies (:32-:36), because a validator living anywhere else would not resolve at run time either. [Rubric §24 - Forms/Validation/UX Safety] and [Rubric §6 - CQRS & Event-Driven] are the properties; [Rubric §14 - Testability] covers the fixtures.
• Walkthrough - both are internal sealed, both declare an internal constructor with a single expression-bodied rule, and both use NotEmpty() on the one string property. Nothing about the rule content matters to the fitness function; the existence of a closed IValidator<T> implementation is the whole signal.

• Why they're built this way - having exactly one validator on each side of the bridge is what lets a single rule execution produce a positive result for both coverage forms while ReopenTicketCommand, whose request deliberately has none, still fails. Adding a second rule to either validator would prove nothing extra.
• Caveats / not-in-source - the rule's own limits section records two behaviors these fixtures do not exercise: a validator declared for a base command type does not count for its derived commands (matching FluentValidation's closed-type resolution), and abstract validators are ignored because nothing registers them (ArchitectureRules.CommandValidators.cs:37-:41).
• Where they're used - discovered by ValidatedTypes (ArchitectureRules.CommandValidators.cs:105-:109) during every fact of CommandValidatorCoverageFitnessTests.

DuplicateTicketErrors, DynamicErrors, SharedCodeErrors, TicketErrors, TwoBranchTicketErrors, UnprefixedErrors

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.ErrorCodeFixtures · (see per-type table) · Level 2 · class

Six internal static classes in one file (MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/ErrorCodeFixtures/ErrorCodeFixtures.cs), each holding one or two expression-bodied factory methods that construct an Error. Together they compile the error catalog the two catalog rules have to judge: well-formed codes, a cross-type collision, an unprefixed code, one code reused across two branches of a single type, a shared framework static, and a code built at run time.

• Depends on - Error and its static factories NotFoundError, Conflict and Validation (ErrorCodeFixtures.cs:1). Nothing else.
• Concept introduced - the error code as the module's public vocabulary, read out of IL. A client switches on Order.NotFound and a support ticket quotes it, so two modules both shipping Item.Invalid make that vocabulary ambiguous in a way that only surfaces in production (rule doc, MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Rules/Contracts/ArchitectureRules.ErrorCatalog.cs:31-:37). Two rules police it. ErrorCodesAreUnique (:62) fails when the same literal code is constructed by more than one type, and the choice of "type" as the unit is deliberate: one error with two exits in the same class is not a collision, which keeps a normal two-branch handler out of the report (:45-:50). ErrorCodesUseAnAllowedPrefix (:102) fails on any literal code whose prefix a caller-supplied delegate rejects, so the convention stays the consumer's rather than the framework's (:92-:98). Both read the code out of the compiled IL: the scan looks for calls to any of nine Error factory names plus .ctor (:17-:29) and reads the first argument, and both deliberately skip the record copy constructor through a first-parameter-is-string check so error with { Source = ... } is not mistaken for a new code (:11-:15). Codes that are not literals cannot be judged statically, and the rules refuse to guess: they are listed as UNVERIFIABLE in the failure message so the reader knows the catalog has a blind spot (:51-:55). [Rubric §9 - API & Contract Design] assesses whether the published failure vocabulary is governed; [Rubric §15 - Best Practices & Code Quality] covers traceability, since a prefixed code alone says where it came from; [Rubric §14 - Testability] covers the fixtures.
• Walkthrough - scope is the per-module Domain and Application assemblies only (:38-:44), which is why the self-test map registers this assembly as a module Application layer rather than a framework one.

• Why they're built this way - the pairs are what make each rule discriminating rather than merely loud. TicketErrors and DuplicateTicketErrors are the collision; TwoBranchTicketErrors is the shape a naive "count the construction sites" implementation would wrongly flag; SharedCodeErrors proves the exemption is honored on the prefix rule as well as the uniqueness rule. Keeping every fixture internal static with expression-bodied members means the IL is minimal and the reported owner name is unambiguous. See ADR-015.
• Where they're used - compiled into this assembly and scanned by ErrorCatalogFitnessTests through its FixtureModuleMap, which anchors the module Application layer on typeof(TicketErrors).Assembly (ErrorCatalogFitnessTests.cs:112).

ArchiveTicketHandler, CreateTicketHandler, PurgeTicketsHandler, RebuildTicketIndexHandler, ReopenTicketHandler, UpdateTicketHandler

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.CommandValidatorFixtures · (see per-type table) · Level 3 · class

Six byte-identical handlers, one per fixture command, each a single expression-bodied HandleAsync returning Task.FromResult(Result.Success()). They do nothing, and that is the design: their only job is to make their command handled, which is the condition that puts a command into the coverage rule's scope at all.

• Depends on - ICommandHandler<in TCommand, TResult> closed over the fixture command and Result (CommandValidatorFixtures.cs:2-:3).
• Concept introduced - "has a handler" is the scoping predicate, not "is named Command". The rule never matches on a naming convention. It projects every concrete class in the module Application assemblies through the closed generic arguments of the command-handler interface and takes the first type argument (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Rules/Cqrs/ArchitectureRules.CommandValidators.cs:96-:102). A record that nobody handles is not a command the repo dispatches, so it is not a command the pipeline can fail to validate, and inventing a naming rule instead would both miss unconventionally-named commands and flag DTOs that merely end in Command. These six handlers exist so the fixture commands satisfy that predicate honestly rather than by declaration.
• Walkthrough - every one has the same body: public Task<Result> HandleAsync({Command} command, CancellationToken cancellationToken = default) => Task.FromResult(Result.Success());. Note the trailing token with its conventional name, which keeps these fixtures compliant with the framework's own cancellation rule even though nothing here awaits.

• Why they're built this way - one handler per command, with no shared abstract base, keeps the discovery pass honest: an abstract or open-generic handler would contribute a type parameter rather than a command and would silently shrink the inventory. The uniform empty body means no handler can accidentally become the reason a fact passes.
• Where they're used - counted by HandledCommandCount (ArchitectureRules.CommandValidators.cs:80), which CommandInventory_CountsTheDataCarryingCommands pins at exactly 5, the five data-carrying commands with the payload-free marker excluded (MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/Cqrs/CommandValidatorCoverageFitnessTests.cs:100-:108).

FixtureCompliantV1, FixtureCompliantV2, FixtureCompliantV3, FixtureContestedV1, FixtureContestedV2, FixtureContestedV3, FixtureBackwardsV1, FixtureBackwardsV2

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.UpcasterFixtures.IntegrationEvents · (see per-type table) · Level 3 · record

Eight throwaway integration-event contracts in one file (MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/UpcasterFixtures/IntegrationEvents/EventUpcasterFixtures.cs), forming three groups: a compliant three-rung version ladder, a pair of rival successors to one contested source, and a backwards pair whose "successor" is older than its source. They are the data the two event-upcaster fitness rules are proven against.

• Depends on - BaseIntegrationEvent (every one of them derives from it, EventUpcasterFixtures.cs:2). Each is a one-parameter positional record carrying a single string Sku.
• Concept introduced - SchemaVersion as the ordering a fixture set has to make visible. BaseIntegrationEvent declares public virtual int SchemaVersion => 1 (MMCA.Common/Source/Core/MMCA.Common.Domain/DomainEvents/BaseIntegrationEvent.cs:32), so a contract that overrides nothing is version 1 and a successor states its own number (ADR-010). That default is what lets these fixtures be as small as they are: the V1 of each group is a bare record and only the successors carry an override. The rule reads the property without running a constructor, through RuntimeHelpers.GetUninitializedObject (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Rules/Contracts/ArchitectureRules.Upcasters.cs:103), which is why a get-only virtual returning a literal is the required shape and why no event needs a parameterless factory just to be inspected. [Rubric §6 - CQRS & Event-Driven] assesses whether event contracts are versioned and governed rather than edited in place; [Rubric §9 - API & Contract Design] applies because a published event is a wire contract; [Rubric §14 - Testability] covers the fixtures.
• Walkthrough - the file's header doc records a subtlety worth internalizing (:9-:13): the contracts sit in a *.IntegrationEvents namespace so that the residency rule, which EventScopeFitnessTests exercises over this same assembly through a consumer-shaped map, stays satisfied. A fixture that broke a neighbouring rule to prove its own would be a poor fixture. They also never leave this test assembly, so no shipped event contract churns because of them.

• Why they're built this way - three groups because the two rules have three distinct outcomes to prove between them (clean, duplicate claim, wrong direction), and because a chain has to be distinguishable from a duplicate claim. Nothing but Sku on any of them: the payload is irrelevant to both rules, and every byte of fixture that is not load-bearing is a byte that can mislead a future reader about what is being tested. See ADR-090.
• Where they're used - the type arguments of the five fixture upcasters (FixtureCompliantV1ToV2Upcaster and family), named by nameof in the assertions of EventUpcasterFitnessTests, and, because they are this assembly's only integration events, the live contract IntegrationEventContractTestsBaseTests mutates.

FixtureCompliantV1ToV2Upcaster, FixtureCompliantV2ToV3Upcaster, FixtureContestedClaimUpcaster, FixtureRivalClaimUpcaster, FixtureBackwardsVersionUpcaster

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.UpcasterFixtures.IntegrationEvents · (see per-type table) · Level 4 · class

Five internal sealed upcasters over the eight fixture contracts, each a single expression-bodied Upcast that copies the one field across. Between them they are the truth table for the two event-upcaster fitness rules (ADR-090): two clean rungs of a chain, two rivals claiming one source, and one pointing backwards down the version ladder.

• Depends on - IEventUpcaster in its two-parameter form (EventUpcasterFixtures.cs:1) and the fixture event contracts they are generic over.
• Concept introduced - the upcast chain must be a function, and it must run forwards. When a retired contract arrives from the outbox, the consumer resolves the one upcaster registered for that type and replays the message as its successor. Two properties make that mechanical rather than lucky. First, at most one upcaster may read a given source contract: with two claimants, which one runs would depend on DI registration order, so EventUpcastersHaveUniqueSourceTypes groups by source and reports any group with more than one entry (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Rules/Contracts/ArchitectureRules.Upcasters.cs:14-:17). Second, the target must declare a strictly higher SchemaVersion than the source, because an upcaster that moves sideways or down is not producing a successor at all and the chain stops being a ladder anyone can reason about; EventUpcastersIncreaseSchemaVersion compares the two declared versions and flags targetVersion <= sourceVersion (:44-:48). Note what the second rule deliberately does not do: a missing or non-int SchemaVersion is skipped rather than reported (:37-:42), because that is the business of the separate IntegrationEventsDeclareSchemaVersion rule. One rule, one judgement. Both rules find their subjects by matching the interface on name and arity, "IEventUpcaster`2" (:81-:83), which is how the rule library stays free of a compile dependency on the framework's own Application package. [Rubric §6 - CQRS & Event-Driven] assesses whether asynchronous contracts evolve safely; [Rubric §9 - API & Contract Design] covers the versioning discipline; [Rubric §29 - Resilience & Business Continuity] is the operational consequence, since an outbox row written against a retired contract has to be replayable weeks later.
• Walkthrough - every one of the five has the same body shape, public {Target} Upcast({Source} integrationEvent) => new(integrationEvent.Sku);, which is the typed overload declared by IEventUpcaster (MMCA.Common/Source/Core/MMCA.Common.Application/Interfaces/Events/IEventUpcaster.cs:82); SourceType and TargetType come free as default interface implementations off the generic arguments (:72,:75), which is exactly what the rules read.

• Why they're built this way - the two rules judge different things about the same set of types, so the fixture set is designed so that each offender trips exactly one of them. If the backwards upcaster also shared a source, a failure in the unique-source rule would mask a regression in the version rule. Being internal keeps them off the assembly's public surface while still visible to ConcreteClasses, which is what the rule enumerates (ArchitectureRules.Upcasters.cs:67).
• Where they're used - reflected over by EventUpcasterFitnessTests through UpcasterTestMap, and named by nameof in its assertions.

ChildlessFixture, ExemptedOffenderFixture, HelperCascadingFixture, LoopCascadingFixture, MissingOverrideFixture, SelfOnlyDeleteFixture

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.CascadeFixtures · (see per-type table) · Level 5 · class

Six aggregate roots in one file, every one an internal sealed class deriving AuditableAggregateRootEntity<TIdentifierType> over int, differing only in what (if anything) their Delete() override does with their child collection. They are the six-way truth table for the cascade-soft-delete rule.

• Depends on - AuditableAggregateRootEntity<TIdentifierType>, CascadeChildFixture, and Result (CascadeFixtures.cs:1-:2).
• Concept - cross-references the cascade concept introduced by CascadeChildFixture. What this set adds is the body half of the rule, and it is the sharper half. The rule reads the IL of the Delete() override and accepts exactly two shapes: a direct call to DeleteChildren (the helper on the aggregate base, MMCA.Common/Source/Core/MMCA.Common.Domain/Entities/AuditableAggregateRootEntity.cs:273), or a zero-argument Delete reached through the callvirt opcode, which is what a hand-rolled foreach (var line in _lines) line.Delete(); compiles to (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Rules/Domain/ArchitectureRules.CascadeSoftDelete.cs:172-:186). What it deliberately refuses to accept is base.Delete(), and the reason is a small piece of C# trivia doing real work: base.X() on a virtual member is the one thing C# emits as a non-virtual call, and nothing else in the language produces that pairing, so excluding it separates "delete myself" from "delete my children" without guessing (:178-:182). That single discrimination is what makes SelfOnlyDeleteFixture catchable at all.
• Walkthrough - the rule reports two distinct reasons and names the offending collection in both, so the failure text tells a developer which member to fix: "no Delete() override, so its children ({names}) stay active" (:160) and "Delete() never deletes a child, so its children ({names}) stay active" (:165). Allowlist entries are type full names or namespace prefixes, matched ordinally exactly as the hard-delete rule matches (:79-:83).

• Why they're built this way - three passing and three interesting failing cases, with the two offenders made structurally identical so the allowlist fact has an unambiguous control. Every fixture is internal and namespaced, which is what keeps them invisible to the framework rules that run over CommonArchitectureMap and to the other self-tests in this assembly (file doc, :10-:15). See ADR-005 and ADR-015.
• Caveats / not-in-source - the rule's documented limits apply to these fixtures too (ArchitectureRules.CascadeSoftDelete.cs:84-:93): only direct calls in the override are read, so an aggregate that delegates the loop to a private helper is reported; the rule proves a cascade exists, not that it covers every collection; only fields declared on the aggregate are inspected; and grandchildren are the child's own cascade to own. No fixture here exercises those boundaries.
• Where they're used - scanned by CascadeSoftDeleteFitnessTests through its FixtureAssemblyMap, and named by nameof in all six of its facts.

AggregateConventionTests, CancellationTokenConventionTests, DomainPurityTests, EventVersioningConventionTests, HandlerResultConventionTests, IdempotencyConventionTests, LayerDependencyTests, LocalizedTextConventionTests, MicroserviceExtractionTests, NamespaceCycleTests, PiiConventionTests, RawQueryableConventionTests, SliceCohesionTests, StateManagementConventionTests, UIArchitectureConventionTests

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.Domain · (see per-type table) · Level 13 · class

These fifteen sealed classes share one shape: each is a thin subclass of a shared *TestsBase rule from the MMCA.Common.Testing.Architecture package, supplying the repo's CommonArchitectureMap (and, for a few, one extra override) so the same rule body runs identically across MMCA.Common, MMCA.Store, and MMCA.ADC. This is the [Rubric §34 - Architecture Governance & Documentation] and [Rubric §14 - Testability] story: architecture conventions are executable and enforced in CI rather than left to review, and the rule logic lives in exactly one place (ADR-015). See the thin-subclass pattern introduced by DependencyVersionTests. The canonical body of each rule is the corresponding *TestsBase; these subclasses only wire in the map and any repo-specific floor or allowlist. Each fails the build-and-test CI job on violation, and a couple are deliberately vacuous today (they assert nothing until the framework grows a type that could break the convention, at which point they fire).

Where a subclass carries an override beyond Map, that override is itself a documented architectural decision, not configuration: the exemption lists below (NamespaceCycleTests, CancellationTokenConventionTests, StateManagementConventionTests, RawQueryableConventionTests) all carry their justification in code, which is the point of putting the escape hatch in a compiled file rather than a wiki.

• Why they're built this way - see the two-layer "Architecture Enforcement" model in MMCA.Common/CLAUDE.md: rules are enforced at compile time (Source/Build/MMCA.Common.LayerEnforcement.targets) and at runtime here, with the runtime bodies factored into one shared package so Common, Store, and ADC stay identical. Each subclass exists only so xUnit discovers the rule in this repo's assembly with this repo's map.
• Where they're used - all fifteen run in the MMCA.Common.Architecture.Tests project during CI's build-and-test job (fast, no database).
• Caveats / not-in-source - the per-rule fact counts live in each *TestsBase, not in these subclasses; the base sections elsewhere in this chapter are the authority on exactly what each rule asserts.

CascadeSoftDeleteConventionTests, ConcurrencyConventionTests, ContractImplementationTests

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.Domain · (see per-type table) · Level 13 · class

Three more thin subclasses of the same shape as the fifteen above, each supplying only Map. They are grouped separately because they share a second property that is worth understanding on its own: all three are ratchets rather than assertions in this repo. MMCA.Common has nothing today that could violate them, so a green run proves nothing about the framework's current code, and each subclass's own doc says so plainly.

• Depends on - the corresponding *TestsBase and CommonArchitectureMap, and nothing else.
• Concept introduced - a deliberately vacuous gate, kept because of when it will first fire. The instinct is to delete a test that asserts nothing, and for a unit test that instinct is right. For a convention gate it is wrong, and the reason is timing. A convention is cheapest to hold on the first type that could break it, when the shape is still a draft and nobody depends on it; it is most expensive to retrofit later, across every type that has since copied the first one. Running the rule from the start means the invariant is enforced from that first type onward with no test for anyone to remember to write. The cost is that the suite carries three facts that currently read nothing, and the mitigation is that each carries its own note saying so, so a reader is never misled into thinking the framework has been checked. Compare PiiConventionTests, which is vacuous in the same way and is paired with a non-vacuous behavioral test, and ServiceContractPurityTests, which spells the ratchet argument out at length. [Rubric §34 - Architecture Governance & Documentation] is the category: a ratchet is governance expressed as code with a known, dated cost.

• Why they're built this way - each is a two-line subclass with a doc comment that is longer than its body, which is the correct ratio for a ratchet: the code says nothing surprising and the comment carries the whole decision. Keeping them in this repo also means the framework is held to the same bar it exports, so a new framework type that would break a consumer's gate fails here first rather than in the consumers after a release.
• Where they're used - all three run in the MMCA.Common.Architecture.Tests project during CI's build-and-test job. The same three bases are subclassed non-vacuously by MMCA.Store and MMCA.ADC over their own modules.
• Caveats / not-in-source - a green run of any of these three says nothing about the framework's code today. Only CascadeSoftDeleteConventionTests has a companion that proves its rule fires at all (CascadeSoftDeleteFitnessTests); the other two rules have no fixture-backed proof in this repo.

CustomExceptionThrowingFixture

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.DomainThrowFixtures · MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/DomainThrowFixtures/DomainThrowFixtures.cs:67 · Level 1 · class

• What it is - a one-method static fixture that throws the file's custom domain exception, so the domain-throw rule can be shown to judge by constructed type rather than by a list of framework exception names.
• Depends on - TicketDomainException (DomainThrowFixtures.cs:69).
• Concept - cross-references the domain-throw concept introduced by its sibling fixtures. What this one adds is the discrimination that matters most in practice: teams that adopt the Result pattern often keep a DomainException hierarchy as a compromise, and a rule built around a deny-list of BCL exception names would wave it through. The rule instead allows exactly three types and reports everything else (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Rules/Domain/ArchitectureRules.DomainThrows.cs:16-:21,:132-:135), so a custom exception is caught for what it is. The fixture doc puts it in one sentence: the same defect wearing a domain name (:48).
• Walkthrough - the whole type is internal static class CustomExceptionThrowingFixture (MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/DomainThrowFixtures/DomainThrowFixtures.cs:67) with one member, internal static void Reject() => throw new TicketDomainException("The ticket was rejected"); (:69). The newobj immediately precedes the throw, so ConstructedExceptionType names it and the site is a hard violation rather than an UNVERIFIABLE.
• Where it's used - the subject of CustomDomainException_IsAlsoFlagged (MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/Domain/DomainThrowFitnessTests.cs:48-:57), and the residual offender the allowlist facts assert is still reported when only its sibling is exempted (:114-:126).

DisabledFakeExportService

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.Layering · MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/Layering/ModuleConformanceTestsBaseTests.cs:28 · Level 1 · class

• What it is - the stub implementation a disabled FakeDependentModule leaves behind, so the fixture models the real "module off, contract still resolvable" behavior rather than describing it.
• Depends on - IFakeExportService (public sealed class DisabledFakeExportService : IFakeExportService;, ModuleConformanceTestsBaseTests.cs:28).
• Concept - cross-references the disabled-stub concept introduced by IFakeExportService. The pairing matters: a stub type distinct from the real implementation is what lets an assertion prove which implementation the container holds, not merely that the service type is registered.
• Walkthrough - no members; a body-less sealed class with its doc comment at :27. It is the exact type FakeDependentModuleConformanceTests asserts on via descriptor.ImplementationType.Should().Be<DisabledFakeExportService>() (:76).
• Where it's used - registered as a singleton by FakeDependentModule.RegisterDisabledStubs (:43-:44).

FixtureDomainEvent

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.DomainEventSaveFixtures · MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/DomainEventSaveFixtures/DomainEventSaveFixtures.cs:13 · Level 1 · record

• What it is - the single throwaway domain event every handler fixture in DomainEventSaveFixtures is generic over. It carries no meaning; it exists so the four fixture handlers can implement a real, closed IDomainEventHandler<T>.
• Depends on - IDomainEvent (public sealed record FixtureDomainEvent(DateTime DateOccurred, Guid MessageId) : IDomainEvent;, DomainEventSaveFixtures.cs:13, with the interface import at :3).
• Concept - cross-references the handler-save concept introduced by IBadgeGranter. Its own contribution is the closure: the rule finds handlers by asking CallGraphIndex whether a type implements the open interface MMCA.Common.Application.Interfaces.IDomainEventHandler1 matched by full name with Cecil's arity marker (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Rules/Cqrs/ArchitectureRules.DomainEventHandlerSaves.cs:8-:9,:96`), so any closed instantiation works and one event type is enough for the whole fixture set.
• Walkthrough - two positional members, DateTime DateOccurred and Guid MessageId, which are the two members IDomainEvent requires. It is the only public type in the file; the handlers around it are all internal.
• Where it's used - the type argument of DirectSavingHandler, TransitiveSavingHandler, InterfaceDispatchSavingHandler and InnocentHandler, and the assembly anchor of DomainEventHandlerSaveFitnessTests's FixtureAssemblyMap (DomainEventHandlerSaveFitnessTests.cs:116).

InheritingFitnessController

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.Cqrs · MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/Cqrs/IdempotencyFitnessTests.cs:81 · Level 1 · class

• What it is - a body-less concrete controller that inherits AbstractFitnessControllerBase and, with it, the base's declared POST action. It is the fixture for the "covered by inheritance" branch of the idempotency gate.
• Depends on - AbstractFitnessControllerBase (public sealed class InheritingFitnessController : AbstractFitnessControllerBase;, IdempotencyFitnessTests.cs:81).
• Concept introduced - inherited attributes are the reason a base-class action does not have to be redeclared. Reflection over a derived type reports the base's CreateInheritedAsync as one of its public methods, and the rule reads attributes with inherit: true (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Rules/Cqrs/ArchitectureRules.Idempotency.cs:80-:81), so the [Idempotent] sitting on the base action covers every subclass. That is not a detail of the fixture: in the real framework, a concrete controller deriving from AuthControllerBase or AggregateRootEntityControllerBase satisfies the gate through those bases (ArchitectureRules.Idempotency.cs:31-:34), which is the only reason the rule is not a wall of duplicate annotations. This fixture is what pins that behavior. [Rubric §9 - API & Contract Design] and [Rubric §14 - Testability] apply, as for its sibling fixtures.
• Walkthrough - no members at all; the declaration ends at its semicolon (:81). Being concrete is what puts it into the rule's ConcreteClasses scan while its abstract base stays out.
• Where it's used - asserted absent from the rule's failure message by Rule_AcceptsDirectAndInheritedAndOptedOutDeclarations (IdempotencyFitnessTests.cs:34-:36).

InheritingFixtureController

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.Api · MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/Api/AnonymousEndpointTestsBaseTests.cs:94 · Level 1 · class

• What it is - a body-less concrete controller deriving AbstractAnonymousFixtureControllerBase. It is the fixture for the ruling that an inherited [AllowAnonymous] is reported once, at the base that declares it, and never again on the derived type.
• Depends on - AbstractAnonymousFixtureControllerBase (public sealed class InheritingFixtureController : AbstractAnonymousFixtureControllerBase;, AnonymousEndpointTestsBaseTests.cs:94).
• Concept introduced - the same inheritance question, answered the opposite way from the idempotency gate. InheritingFitnessController exists because the idempotency rule reads attributes with inherit: true, so a base declaration covers every subclass. The anonymous-endpoint scan does the reverse: it reads methods with BindingFlags.DeclaredOnly and attributes with inherit: false (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Bases/Api/AnonymousEndpointTestsBase.cs:142,:146). Both choices are correct for their own rule, and the reason is who writes the allow-list. Idempotency intent is declared by the framework and must flow down to consumers, so inherited reads are what stop a wall of duplicate annotations. An anonymous endpoint must be reviewed, and if the scan reported the framework's base action once per derived controller, every consumer repo would have to re-approve the framework's six credential-exchange endpoints under its own type names, forever. The base's own comment states exactly that (:140-:141). [Rubric §11 - Security] is the property; [Rubric §33 - Developer Experience] is the reason for the shape, since a gate that demands the same approval in every downstream repo gets rubber-stamped rather than read.
• Walkthrough - no members; the declaration ends at its semicolon (:94). Being concrete puts it in the scan (IsController walks the base chain, AnonymousEndpointTestsBase.cs:101-:112), and the DeclaredOnly filter is what keeps it silent: it declares no methods of its own, so AnonymousEndpointsOf yields nothing for it.
• Where it's used - the subject of Base_DoesNotReport_AnInheritedAttributeOnTheDerivedController (AnonymousEndpointTestsBaseTests.cs:61-:71), which reads ConformantTests's scan output and asserts it does not contain {InheritingFixtureController.FullName}.InheritedAnonymousAsync (:69-:70). The inline comment there names the consequence being prevented (:64-:66).

NavigationContractTests

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.Ui · MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/Ui/NavigationContractTests.cs:19 · Level 1 · class

• What it is - a documentation-drift gate for navigation (rubric §25): it asserts that the "Routes shipped by the framework" table in NavigationFlow.md stays in lockstep with the routable pages the MMCA.Common.UI assembly actually ships, that each route's documented auth posture matches the [Authorize] reality on the page, and that every route parameter carries a type constraint.
• Depends on - UISharedAssemblyReference (the reflection anchor for the shared UI assembly, NavigationContractTests.cs:105), plus externals: ASP.NET Core RouteAttribute and AuthorizeAttribute (the route and guard metadata reflected over, :107,:113), two source-generated regexes via [GeneratedRegex] partial properties (:139,:142), the embedded NavigationFlow.md manifest resource (:125; wired by the csproj at MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/MMCA.Common.Architecture.Tests.csproj:11-:13), xUnit [Fact], and AwesomeAssertions.
• Concept introduced - documentation as an executable contract. This is the first place a test asserts a hand-authored markdown doc against live code reality rather than the reverse. NavigationFlow.md lives next to the framework code (it is an embedded resource of this test project, per MMCA.Common/CLAUDE.md) precisely so this gate can parse it; a page added, removed, or re-routed without the doc moving in the same change fails the build, and so does an auth-posture lie in either direction. [Rubric §25 - Navigation & IA] assesses whether routing and information architecture are deliberate and documented; this test turns the route table into a build-enforced invariant instead of review discipline, and its fourth fact holds the typed-deep-link half of the same category. [Rubric §11 - Security] and [Rubric §26 - Front-End Security] also apply: a route the doc calls Authenticated must carry [Authorize], and a route it calls Anonymous must not, so a mis-documented guard cannot pass silently. [Rubric §34 - Architecture Governance & Documentation] is the umbrella: the documentation is proven current by CI.
• Walkthrough - two constants pin the contract: MinimumRoutes = 8 (:21) and DocResource = "NavigationFlow.md" (:22). Four [Fact]s enforce it.
  • RoutablePages_AreDiscovered_GateIsNotVacuous (:24-:28) asserts reflection finds at least eight routed pages, so a broken anchor cannot let the whole gate pass having scanned nothing.
  • EveryRoutablePage_IsDocumented_AndEveryDocumentedRoute_Exists (:30-:43) computes the set difference both ways: undocumented routes (real but missing from the doc, :36) and phantom routes (documented but no longer real, :37) must both be empty.
  • EveryDocumentedAuthPosture_MatchesTheRouteAttributeReality (:45-:79) walks each documented route, skips ones the set-equality fact already reports as phantoms (:54-:57), classifies the auth cell as Authenticated..., Anonymous, or Any (:59-:61), and flags three violation kinds: an unrecognized posture string (:63-:66), a doc that promises authentication where the page carries no [Authorize] (:67-:69), and a doc that promises an open route where the page is actually guarded (:71-:73).
  • RouteTemplateParameters_AllCarryTypeConstraints (:81-:100) matches every {...} segment of every discovered template with RouteParameterRegex and fails any whose body carries no : (:90-:94). The violation text states the ruling: an unconstrained parameter accepts arbitrary strings, so the page rather than the router becomes the validation boundary, where a constrained one renders NotFound before the component is reached.
  • Two private helpers supply the two sides. DiscoverRoutedPages (:102-:121) reflects over the shared-UI assembly, collecting each RouteAttribute.Template and whether the type carries [Authorize] (inherited attributes included, :113); DiscoverDocumentedRoutes (:123-:137) reads the embedded doc, throwing a clear InvalidOperationException when the resource is missing (:125-:126), and extracts route rows via the source-generated RouteRowRegex (:139-:140, a 2000ms-timeout [GeneratedRegex] partial property).
• Why it's built this way - NavigationFlow.md is deliberately kept in MMCA.Common next to the routed pages (not in the Website docs library) so this gate can embed and parse it; making route and auth-posture documentation a compiled assertion is what keeps a public navigation contract from rotting. ADR-015 establishes the fitness-function approach this class applies to documentation.
• Where it's used - an independent class in the MMCA.Common.Architecture.Tests suite; it runs in CI's build-and-test job (fast, no database) and has no Store or ADC counterpart because it guards the framework's own shared-UI route table. It is also one of the two entries DomainThrowFitnessTests allowlists, because its missing-resource guard is a real InvalidOperationException throw inside this assembly (DomainThrowFitnessTests.cs:31).

ObservabilityConventionTestsBaseTests

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.Governance · MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/Governance/ObservabilityConventionTestsBaseTests.cs:14 · Level 1 · class

• What it is - a cross-assembly regression guard for the shared SLO alert-to-runbook pairing rule. It subclasses ObservabilityConventionTestsBase from an assembly other than the one the base ships in, re-points it at a fixture IaC pair embedded in this test project, and asserts the base resolves its manifest resources from the derived type's assembly.
• Depends on - ObservabilityConventionTestsBase (public sealed class ObservabilityConventionTestsBaseTests : ObservabilityConventionTestsBase, ObservabilityConventionTestsBaseTests.cs:14) and the two fixture resources embedded by the csproj under the logical names fixtures.observability-main.bicep and fixtures.observability-OPERATIONS.md (MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/MMCA.Common.Architecture.Tests.csproj:17-:22). Externals: System.Reflection.Assembly, xUnit [Fact], AwesomeAssertions.
• Concept introduced - proving a shipped base class's defaults from outside its own assembly. The rule library ships as the MMCA.Common.Testing.Architecture package (ArchitectureRules plus its *TestsBase family), so a base can carry a default that is only ever wrong for a consumer: ResourceAssembly => GetType().Assembly (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Bases/Governance/ObservabilityConventionTestsBase.cs:51) must bind to the subclass's assembly, because the base's own assembly never contains a consumer's bicep. Testing that default inside the base's own assembly would prove nothing (both assemblies would be the same one), so the guard is deliberately located here, one assembly away. [Rubric §13 - Observability & Operability] assesses whether alerts stay operable, and the rule this class exercises is the one that keeps every provisioned SLO alert paired with a severity-correct runbook section. [Rubric §14 - Testability] applies because this is a meta-test that keeps a shared gate honest, and [Rubric §33 - Developer Experience] because the alternative failure mode is a break that surfaces only in the first downstream repo to adopt the base.
• Walkthrough - two property overrides re-point the base's resource names at the fixtures: BicepResource => "fixtures.observability-main.bicep" (:16) and RunbookResource => "fixtures.observability-OPERATIONS.md" (:18), replacing the base defaults infra.main.bicep and infra.OPERATIONS.md (ObservabilityConventionTestsBase.cs:42,:45). One own [Fact], ResourceAssembly_DefaultsToTheDerivedTypesAssembly (:24-:29), asserts the resolved ResourceAssembly is the same object as this class's assembly and is not the base's assembly. Inheritance supplies the rest: the base's three [Fact]s (ObservabilityConventionTestsBase.cs:53,:63,:91) run against the fixture pair, so the whole discovery-and-pairing path is exercised across the assembly boundary. The fixture bicep declares exactly three well-formed specs plus the two parse anchors the base looks for, var sloAlertSpecs and resource sloAlerts (MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/Fixtures/observability-main.bicep:6-:25), which meets the base's default MinimumAlertSpecs => 3 (ObservabilityConventionTestsBase.cs:39); the fixture runbook carries a matching ### fixture-alert-<key> (sev N) heading per spec (MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/Fixtures/observability-OPERATIONS.md:9-:19), so both pairing directions and the severity check pass.
• Why it's built this way - the class doc records the exact regression it exists for (:5-:13): resolving against the base's own assembly instead of the subclass's is a silent break, since the framework's CI would stay green and only the first adopting consumer would fail. Keeping the guard in a different assembly is the only way to make that difference observable. It is the packaging discipline ADR-058 describes for shipped conformance suites, applied to a fitness base; the rule it guards implements the alerting side of ADR-041.
• Where it's used - an independent class in the Common architecture suite. The real adopters are ObservabilityConventionTests in MMCA.ADC and MMCA.Store (MMCA.ADC/Tests/Architecture/MMCA.ADC.Architecture.Tests/Governance/ObservabilityConventionTests.cs:7, MMCA.Store/Tests/Architecture/MMCA.Store.Architecture.Tests/ObservabilityConventionTests.cs:7), which subclass the same base with no overrides at all and rely entirely on the default this class pins.
• Caveats / not-in-source - the fixture bicep is deliberately minimal (its own header comment says so, observability-main.bicep:1-:4): it proves the base's parse-and-pair logic, not that any real consumer template is well formed. The consumers' own subclasses do that against their real infra/ files.

ReopenTicketCommand, UpdateTicketCommand

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.CommandValidatorFixtures · (see per-type table) · Level 1 · record

Two bridged commands: each is a one-property record that wraps a request record and implements ICommandWithRequest<out TRequest>. They differ in exactly one thing, whether the wrapped request has a validator, and that single difference is what proves the bridge is checked on both halves.

• Depends on - ICommandWithRequest<out TRequest> (CommandValidatorFixtures.cs:2) and the request record each wraps.
• Concept - cross-references the coverage concept introduced by CreateTicketCommandValidator and UpdateTicketRequestValidator. The pair is the negative-control design that makes the bridge check meaningful: both commands are structurally identical to the rule's discovery pass (both are closed types with a settable property, both are handled, both implement the bridge marker), so the only variable left is whether ValidatedTypes contains their request. One passes, one fails, and nothing else about them can explain the difference.
• Walkthrough - the rule reaches the request type by projecting the command through the closed generic arguments of ICommandWithRequest1 matched by full name (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/ArchitectureRules.CommandValidators.cs:5,:114), then asks whether any of those arguments is in the validated set. Matching the interface by name rather than by reference is what keeps the rule package free of a compile dependency on the framework's Application layer (:117-:120`).

• Why they're built this way - the half-bridge is the failure mode a validation-coverage rule is most likely to miss, because the registration exists and only the resolution is empty. Compiling both halves side by side is what turns that from a code-review concern into an assertion.
• Where they're used - named by nameof in CommandCoveredThroughTheRequestBridge_IsCovered and BridgeWithNoRequestValidator_IsNotCoverage (MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/Cqrs/CommandValidatorCoverageFitnessTests.cs:44-:64), and handled by ReopenTicketHandler and UpdateTicketHandler.

RightModel

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.CycleFixtures.Right · MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/CycleFixtures/Right/RightFixtures.cs:6 · Level 1 · class

• What it is - the other arm of the deliberate namespace cycle: a type in the Right fixture namespace that derives from a base in Left, supplying the Right -> Left edge.
• Depends on - LeftModelBase (public sealed class RightModel : LeftModelBase, RightFixtures.cs:6, with the using of the Left namespace at :1).
• Concept - cross-references the namespace-cycle concept introduced by LeftModelBase. This half contributes the inheritance edge; LeftService contributes the property-type edge in the other direction. Two edges pointing opposite ways between two namespace nodes is the minimum strongly connected component the rule can report.
• Walkthrough - one auto-property, string Name initialized to string.Empty (:9), present only so the type is not empty.
• Where it's used - the property type of LeftService.Model, which is what closes the loop; both are scanned by NamespaceCycleFitnessTests.

FakeDependentModule

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.Layering · MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/Layering/ModuleConformanceTestsBaseTests.cs:31 · Level 2 · class

• What it is - the "hard" module fixture: a module that declares dependencies, refuses to start without them, and exports a disabled stub. It exercises every member of the module contract that a leaf module leaves at its default.
• Depends on - IModule (public sealed class FakeDependentModule : IModule, ModuleConformanceTestsBaseTests.cs:31), ApplicationSettings (the Register parameter, :39), IFakeExportService and DisabledFakeExportService (the stub pair, :44), plus IServiceCollection and IConfigurationBuilder from Microsoft.Extensions.* (:1-:2).
• Concept introduced - the full module contract as a testable surface. IModule has five members, three of which are defaulted (Dependencies => [], RequiresDependencies => false, RegisterDisabledStubs as an empty body, MMCA.Common/Source/Core/MMCA.Common.Application/Modules/IModule.cs:17,:23,:34), so the entire contract ModuleLoader registers on can be silently wrong without a compile error. This fixture is the one that overrides all three, so the conformance base is exercised against real (not defaulted) values. [Rubric §14 - Testability] covers the fixture role; [Rubric §7 - Microservices Readiness] is what the stub half protects, since a module that can be switched off without breaking the modules that import its contract is a module that can also be extracted (ADR-059).
• Walkthrough
  • Name => "FakeDependent" (:33): the key ModulesSettings entries and other modules' dependency lists match on.
  • Dependencies => ["FakeLeaf", "FakeOther"] (:35): two entries, one of which (FakeLeafModule) exists in the fixture set and one of which deliberately does not, so the list is a pure data declaration rather than a resolvable graph.
  • RequiresDependencies => true (:37): the flag that turns a disabled dependency into a startup failure instead of a substituted stub.
  • Register(...) (:39-:41): an empty body. Registration behavior is not what the conformance base asserts, so the fixture spends nothing on it.
  • RegisterDisabledStubs(IServiceCollection services) (:43-:44): a single expression-bodied services.AddSingleton<IFakeExportService, DisabledFakeExportService>(), which is the only member with observable behavior and the one FakeDependentModuleConformanceTests inspects.
• Why it's built this way - the doc comment (:30) names the intent: this is the shape of the two real consumer modules that are not leaves (Store Sales, ADC Notification). Modeling them locally means the shared base is proven against both module shapes inside MMCA.Common's own CI, before any consumer sees it (ADR-015).
• Where it's used - the TModule of FakeDependentModuleConformanceTests (:60) and of the deliberately-drifted DriftedTests (:131).

FakeLeafModule

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.Layering · MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/Layering/ModuleConformanceTestsBaseTests.cs:15 · Level 2 · class

• What it is - the minimal module fixture: Name plus an empty Register, and nothing else. Its whole purpose is to not override Dependencies or RequiresDependencies, so the conformance base has to reach the interface's default implementations to read them.
• Depends on - IModule (public sealed class FakeLeafModule : IModule, ModuleConformanceTestsBaseTests.cs:15) and ApplicationSettings (the Register parameter, :19).
• Concept introduced - default interface implementations are only reachable through the interface. A default member declared on IModule (IModule.cs:17,:23) does not exist on the concrete class, so module.Dependencies will not compile against FakeLeafModule and a reflection lookup on the concrete type finds nothing. The shared base solves this by locating the IModule interface by full name and reading the property off the interface (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Bases/Layering/ModuleConformanceTestsBase.cs:80-:99), which dispatches to the override when there is one and to the framework default when there is not. Before the base existed, the hand-written consumer tests needed an explicit (IModule) cast to get the same reach (class doc, :9-:14). [Rubric §14 - Testability] and [Rubric §1 - SOLID] both apply: the fixture exists so the base's interface-dispatch contract is provable rather than assumed.
• Walkthrough - Name => "FakeLeaf" (:17) and an empty Register(...) (:19-:21). That is the entire type; the absence of members is the fixture.
• Why it's built this way - this is the exact shape the three byte-identical consumer {X}ModuleTests files collapse into (class doc, :12-:13), so the leaf path is the most-travelled one and the one whose silent breakage would be widest.
• Where it's used - the TModule of FakeLeafModuleConformanceTests (:51), which in turn is driven directly by two of ModuleConformanceTestsBaseTests's facts (:112-:129).

InnocentHandler

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.DomainEventSaveFixtures · MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/DomainEventSaveFixtures/DomainEventSaveFixtures.cs:95 · Level 2 · class

• What it is - the negative control for the domain-event handler save rule: a handler that mutates in-memory state and returns, which is what a conforming handler looks like.
• Depends on - IDomainEventHandler<in TDomainEvent> closed over FixtureDomainEvent (DomainEventSaveFixtures.cs:95, imports at :1).
• Concept - cross-references the handler-save concept from IBadgeGranter. Its contribution is discrimination. The rule walks the call graph out of every method on a handler type up to a depth bound, and a walker that reported any handler with any outbound call would be useless. This fixture makes calls (GetType(), List<string>.Add, ArgumentNullException.ThrowIfNull) and reaches no save, so a green result for it is a statement that the classifier looked and found nothing rather than that it stopped looking.
• Walkthrough - one private List<string> _seen initialized with a collection expression (:97), and a HandleAsync that guards its argument, records the event's type name, and returns Task.CompletedTask (:99-:105). No constructor and no injected collaborator, which is the point: nothing it holds can lead to a unit of work.
• Why it's built this way - the doc states the ruling directly (:91-:94): this is what the rule protects, so it must never appear in the report.
• Where it's used - asserted absent from the failure message by HandlerThatOnlyMutates_IsNotFlagged (MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/Cqrs/DomainEventHandlerSaveFitnessTests.cs:58-:67).

InterfaceDispatchSavingHandler

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.DomainEventSaveFixtures · MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/DomainEventSaveFixtures/DomainEventSaveFixtures.cs:81 · Level 2 · class

• What it is - the handler fixture whose save is reachable only through an abstraction: it calls IBadgeGranter and never touches a unit of work itself.
• Depends on - IDomainEventHandler<in TDomainEvent>, FixtureDomainEvent, and IBadgeGranter (the constructor-injected collaborator, DomainEventSaveFixtures.cs:83,:85).
• Concept - cross-references IBadgeGranter. The mechanism this fixture forces is CallGraphIndex.TargetsOf, which the walk calls for every callee that is not itself a save (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Rules/Cqrs/ArchitectureRules.DomainEventHandlerSaves.cs:170-:177): an interface method reference is expanded into the implementations present in the scanned modules, and each unvisited, non-allowlisted target is queued one depth deeper. Without that expansion the walk would see IBadgeGranter.GrantAsync and stop, because an interface method has no body to read.
• Walkthrough - one field, one constructor, and a HandleAsync that returns _granter.GrantAsync(cancellationToken) directly (:87-:88). It is not async, which is deliberate: the save is exactly two IL calls away with no state machine in between, so the reported chain stays short and the fixture isolates interface resolution from the state-machine traversal that TransitiveSavingHandler exercises.
• Where it's used - asserted present in the failure message by SaveBehindAnInterface_IsResolvedToItsImplementation (MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/Cqrs/DomainEventHandlerSaveFitnessTests.cs:47-:56), whose because states the ruling: IL records the interface call, so the walk must expand it to the implementations in scope.

LeftService

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.CycleFixtures.Left · MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/CycleFixtures/Left/LeftFixtures.cs:6 · Level 2 · class

• What it is - the Left -> Right half of the fixture cycle: a Left type whose property type lives in the Right namespace.
• Depends on - RightModel (the nullable Model property, LeftFixtures.cs:9, with the using at :1).
• Concept - cross-references LeftModelBase. What this type adds is the second edge kind: a property type rather than a base type. The cycle rule records both (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Rules/Layering/ArchitectureRules.Cycles.cs:25-:27), and having one of each in the fixture means a regression that drops either edge kind from the graph builder is caught instead of being masked by the other.
• Walkthrough - one member, public RightModel? Model { get; set; } (:9). Nullability is irrelevant to the rule (it reads the property type); the reference itself is the fixture.
• Where it's used - referenced by AcyclicConsumer and scanned by NamespaceCycleFitnessTests.

PasswordHashingFitnessTests

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.Governance · MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/Governance/PasswordHashingFitnessTests.cs:15 · Level 2 · class

• What it is - a structural credential-storage gate asserted against compiled IL rather than source text: PasswordHasher must depend on Rfc2898DeriveBytes (a deliberately slow key-derivation function) and on CryptographicOperations (the constant-time comparison), so a rewrite cannot quietly swap either out.
• Depends on - PasswordHasher as the assembly anchor and the type under scan (PasswordHashingFitnessTests.cs:1,:21), ArchitectureAssert (:37,:50), NetArchTest's Types / PredicateList query API (:56-:59), and externals xUnit plus AwesomeAssertions.
• Concept introduced - asserting on a dependency edge instead of on an output value. A hashing routine can be verified two ways. A known-answer test pins the values (iteration count, salt length, digest length) and is what PasswordHasherSecurityTests does; this class pins the shape, which catches a class of change the value tests cannot. Swap PBKDF2 for a single SHA-512 pass and keep the same 32-byte output length and the known-answer pin can be regenerated by whoever made the change, but the Rfc2898DeriveBytes reference disappears from the IL and this test goes red. Same for replacing CryptographicOperations.FixedTimeEquals with SequenceEqual: identical behavior on every test input, and a timing side channel in production. The two because strings spell out the attacks precisely: commodity GPUs trying billions of candidates per second against a stolen table (:38-:39), and a short-circuiting comparison leaking the matching prefix length so a digest is recovered byte by byte (:51-:53). [Rubric §11 - Security] assesses whether credential storage resists offline cracking and side channels; this is the build-time half of that guarantee. [Rubric §14 - Testability] covers the technique, and [Rubric §32 - Dependency & Supply-Chain] applies at the edges, since the assertion is that a specific BCL cryptographic primitive is actually reached.
• Walkthrough - two private const string fully-qualified type names, CryptographicOperationsType (:17) and Rfc2898DeriveBytesType (:19), keep the matched names in one place. Infrastructure (:21) anchors the scanned assembly through typeof(PasswordHasher).Assembly, and the private PasswordHasherTypes() helper (:56-:59) narrows it with Types.InAssembly(Infrastructure).That().HaveName(nameof(PasswordHasher)).
  • ScannedPasswordHasherSet_IsNotEmpty (:23-:27): the non-vacuity guard, and the first fact for a reason. HaveName matches on the simple name, so a renamed or moved type would leave the predicate list empty and both dependency assertions would pass having inspected nothing. ContainSingle on the full name (:25-:26) closes that.
  • PasswordHasher_DependsOnASlowKeyDerivationFunction (:29-:40) and PasswordHasher_DependsOnConstantTimeComparison (:42-:54): each runs .Should().HaveDependencyOnAll(<type name>).GetResult() and routes the result through ArchitectureAssert.NoViolations. HaveDependencyOnAll is the positive form (the dependency must be present), which is the unusual direction for an architecture rule and the right one here.
• Why it's built this way - ADR-032 fixes the hashing scheme; the real implementation calls Rfc2898DeriveBytes.Pbkdf2 (MMCA.Common/Source/Core/MMCA.Common.Infrastructure/Auth/PasswordHasher.cs:35) and CryptographicOperations.FixedTimeEquals (:58). Pinning the decision as a fitness function rather than a code-review convention is the ADR-015 approach, and it is the one that survives a refactor by someone who has not read the ADR.
• Where it's used - an independent class in the Common architecture suite. It is the shape half of a pair; the parameter values are pinned by PasswordHasherSecurityTests in the Infrastructure unit-test project (MMCA.Common/Tests/Core/MMCA.Common.Infrastructure.Tests/Auth/PasswordHasherSecurityTests.cs:18), which holds PBKDF2-HMAC-SHA512 at 600,000 iterations with a 32-byte salt and a 64-byte output as reflected private constants (:20-:22). The class doc here records the division of labour (PasswordHashingFitnessTests.cs:10-:13).
• Caveats / not-in-source - HaveDependencyOnAll reports a reference in the compiled IL, not that the reference is on the hashing path. It cannot tell an actually-used PBKDF2 call from a dead one, which is why the value pins in the companion test remain load-bearing.

AcyclicConsumer

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.CycleFixtures.Acyclic · MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/CycleFixtures/Acyclic/AcyclicFixtures.cs:6 · Level 3 · class

• What it is - the negative control for the namespace-cycle rule: a third fixture namespace that points into Left and that nothing points back at, so it must never appear in a cycle report.
• Depends on - LeftService (the one-way Service property, AcyclicFixtures.cs:9, using at :1).
• Concept - cross-references LeftModelBase. Its role is the discrimination half of the proof: a rule that reported every namespace with any edge would also "pass" the cycle test, so the fixture set needs a namespace that is genuinely coupled yet genuinely acyclic. Depending on Left (a namespace that is in a cycle) is deliberate: it proves the rule reports strongly connected components, not merely everything reachable from a cycle.
• Walkthrough - one member, public LeftService? Service { get; set; } (:9).
• Where it's used - asserted absent from the failure message by Rule_FlagsTwoNamespaceCycle_ButNotAcyclicNamespaces (NamespaceCycleFitnessTests.cs:23-:25).

DriftedTests

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.Layering · MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/Layering/ModuleConformanceTestsBaseTests.cs:131 (and a same-named sibling in Api/AnonymousEndpointTestsBaseTests.cs:100) · Level 3 · class

• What it is - the name is used twice in this assembly, once per fitness base under proof, and both are the same idea: a private sealed subclass of a shipped *TestsBase whose configuration is deliberately wrong, so the base's assertions can be shown to actually fail on the drift they claim to catch. They are nested in different outer classes, so their full names differ and neither is visible outside its own file.
• Depends on - the base each one drifts from, plus the fixture it points at: ModuleConformanceTestsBase<TModule> with FakeDependentModule for one, AnonymousEndpointTestsBase with the fixture controllers for the other.
• Concept introduced - negative fixtures, and hiding them from test discovery. A fitness base that asserts nothing passes everywhere; the only way to know an assertion bites is to feed it a case that must fail. But a public subclass of an xUnit base is itself collected, so its inherited [Fact]s would run and report as red tests of their own. Declaring the drifted subclass private and nested keeps xUnit from collecting it, while the enclosing class can still instantiate it and invoke the inherited methods directly as delegates (var assert = new DriftedTests().Module_ShouldDeclare_ExpectedName;, ModuleConformanceTestsBaseTests.cs:91). Both class docs record that reasoning in the same words (ModuleConformanceTestsBaseTests.cs:81-:85, AnonymousEndpointTestsBaseTests.cs:10-:11). [Rubric §14 - Testability] assesses whether the guardrails themselves are trustworthy; this is the fixture shape that earns that trust. Compare NavigatingSpec, the same negative-fixture technique applied to a specification rule, and ProbeTests, which parameterizes the drift instead of hard-coding it.

• Walkthrough - one wrong value per assertion, and no more. If a single drifted subclass were wrong in three ways at once and the base only ever threw on the first, the other two assertions could rot undetected; the module-side fixture avoids that by being driven three separate times, once per fact.
• Where it's used - the anonymous-endpoint one drives Base_Fails_WhenAnAnonymousEndpointIsNotAllowListed (AnonymousEndpointTestsBaseTests.cs:15-:24); the module one is instantiated three times by ModuleConformanceTestsBaseTests (:91,:99,:107), once per assertion under proof.

EmptyScanTests

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.Api · MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/Api/AnonymousEndpointTestsBaseTests.cs:117 · Level 3 · class

• What it is - the adversarial fixture for the anonymous-endpoint gate's non-vacuity guard: a subclass pointed at an assembly that contains no controllers and no routable components at all, so the scan finds nothing and the guard must fail.
• Depends on - AnonymousEndpointTestsBase (private sealed class EmptyScanTests : AnonymousEndpointTestsBase, AnonymousEndpointTestsBaseTests.cs:117) and the MMCA.Common.Shared assembly reached through typeof(Shared.Abstractions.Result).Assembly (:121).
• Concept introduced - guarding the guard: why a fitness function needs a floor. The allow-list assertion is offenders.Should().BeEmpty() (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Bases/Api/AnonymousEndpointTestsBase.cs:60-:62), and an empty scan produces zero offenders, so the gate passes loudest exactly when it has stopped looking. A renamed assembly, a moved anchor type, or a repo re-layout all produce that failure mode, and none of them is visible in a green run. The base therefore ships a third fact, ScannedEndpointSet_IsNotEmpty (:66-:76), that counts the discovered controller and routable-component types and requires at least MinimumScannedTypes, whose default is 1 (:51). This fixture is what proves the counter is real: point it at an assembly that genuinely has neither shape and the fact must throw. Compare the equivalent floors elsewhere in the suite: MinimumScannedTypes => 21 on AnonymousEndpointTests, MinimumBaseResources => 3 on LocalizationResourceTests, MinimumRoutes = 8 in NavigationContractTests, and the DistinctErrorCodeCount and HandledCommandCount inventories the catalog and validator rules expose for the same purpose. [Rubric §14 - Testability] assesses whether the guardrails are themselves trustworthy, and a vacuity floor is the cheapest thing that keeps one honest over a decade of refactors.
• Walkthrough - two overrides and an inline comment that states why the chosen assembly works: the Shared package has neither controllers nor routable components (:119). TargetAssemblies returns that one assembly (:120-:121), and AllowedAnonymousEndpoints is empty (:123), which is irrelevant here because nothing is discovered to compare against. Being private and nested is what keeps xUnit from collecting its three inherited facts as deliberately-red tests of their own (class doc, :10-:11).
• Where it's used - the subject of Base_Fails_WhenNothingWasScanned (AnonymousEndpointTestsBaseTests.cs:37-:43), which converts the inherited ScannedEndpointSet_IsNotEmpty into a delegate and asserts it throws (:40-:42).
• Caveats / not-in-source - that fact asserts only that an exception is thrown, not what its message says. It proves the floor bites; it does not pin the wording.

FakeDependentModuleConformanceTests

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.Layering · MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/Layering/ModuleConformanceTestsBaseTests.cs:60 · Level 3 · class

• What it is - the shared module-conformance base wired up against the "hard" fixture module: the subclass shape a real non-leaf module (Store Sales, ADC Notification) uses, with all three expectations declared and the disabled-stub hook implemented.
• Depends on - ModuleConformanceTestsBase<TModule> (public sealed class FakeDependentModuleConformanceTests : ModuleConformanceTestsBase<FakeDependentModule>, ModuleConformanceTestsBaseTests.cs:60), FakeDependentModule, IFakeExportService, DisabledFakeExportService, and Microsoft.Extensions.DependencyInjection's ServiceCollection / ServiceLifetime (:70,:77).
• Concept introduced - asserting on a ServiceCollection instead of a built container. The disabled-stub hook is a registration contract, not a resolution one, so the fixture never builds a provider: it constructs a bare ServiceCollection (:70), calls RegisterDisabledStubs on it (:72), and then inspects the resulting ServiceDescriptor directly (:74). That is what lets one assertion cover all three things that can go wrong (wrong service type, wrong implementation type, wrong lifetime) without any of the module's real dependencies having to exist. [Rubric §7 - Microservices Readiness] is the property under guard: a module that can be switched off while its exported contract stays resolvable is a module that can be extracted. [Rubric §14 - Testability] covers the technique.
• Walkthrough - three property overrides declare the expectations: ExpectedName => "FakeDependent" (:62), ExpectedDependencies => ["FakeOther", "FakeLeaf"] (:64), and ExpectedRequiresDependencies => true (:66). The dependency list is written in the opposite order to the module's own declaration (:35), which is deliberate: the base compares with BeEquivalentTo (ModuleConformanceTestsBase.cs:51), so order must not matter, and writing it reversed proves it does not. AssertDisabledStubs(FakeDependentModule module) (:68-:78) is the one real override: single descriptor for IFakeExportService (:74-:75), implementation type DisabledFakeExportService (:76), lifetime Singleton (:77).
• Where it's used - collected and run directly by xUnit (it is public and sealed, so its four inherited [Fact]s are real tests of the fixture module), and referenced by ModuleConformanceTestsBaseTests as the non-leaf half of the base's coverage.

FakeLeafModuleConformanceTests

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.Layering · MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/Layering/ModuleConformanceTestsBaseTests.cs:51 · Level 3 · class

• What it is - the same shared base wired up against the leaf fixture, declaring only ExpectedName and leaving every other expectation at the base's default. It is the exact subclass shape the three byte-identical consumer {X}ModuleTests files collapse into.
• Depends on - ModuleConformanceTestsBase<TModule> (public sealed class FakeLeafModuleConformanceTests : ModuleConformanceTestsBase<FakeLeafModule>, ModuleConformanceTestsBaseTests.cs:51) and FakeLeafModule.
• Concept - cross-references the default-interface-dispatch concept from FakeLeafModule. The pairing is what makes the proof work: the fixture module declares neither Dependencies nor RequiresDependencies, and this subclass declares neither expectation, so the base's defaults ([] and false, ModuleConformanceTestsBase.cs:29,:35) must line up with IModule's defaults read through the interface. If either side stopped reaching the interface, this pair would go red.
• Walkthrough - one member: ExpectedName => "FakeLeaf" (:53). Everything else is inherited, including the vacuous AssertDisabledStubs default, which is exactly what makes the fourth fact a no-op here.
• Where it's used - collected by xUnit in its own right, and driven directly (as an object, not as a test class) by two of ModuleConformanceTestsBaseTests's facts (:112-:129).

StubMap

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.Layering · MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/Layering/ModuleIsolationTestsBaseTests.cs:75 · Level 3 · class

• What it is - a hand-built IArchitectureMap implementation, written from scratch rather than derived from ArchitectureMapBase, so a test can declare exactly one forbidden namespace for exactly one layer.
• Depends on - IArchitectureMap, LayerRef and the Layer enum (ModuleIsolationTestsBaseTests.cs:75-:79). Four constructor parameters carry the whole configuration: fromLayer, forbiddenLayer, forbiddenNamespace, and the assembly to register.
• Concept introduced - when the map base is the wrong tool, and why implementing the interface directly is the honest alternative. Every other map in this chapter subclasses ArchitectureMapBase, which derives every other module's namespaces mechanically from the repo token. That derivation is exactly what makes a real map cheap and exactly what makes it useless here: the isolation rules ask a map for OtherModuleNamespaces(module, layer), and to test one specific cross-layer pair the answer has to be one namespace for one layer and empty for the rest. The base cannot express that, so this stub implements all eleven interface members itself (:81-:110) and puts the whole test in OtherModuleNamespaces, a one-line conditional (:109-:110). The class doc states the reasoning verbatim (:70-:74). [Rubric §7 - Microservices Readiness] is the property the rules under test defend; [Rubric §1 - SOLID] is why this substitution is even possible, since the rule library consumes only the interface and never the base; [Rubric §14 - Testability] is the technique.
• Walkthrough
  • RepoToken => "MMCA.Fixture" (:81) and ModuleNames => ["Beta", "Gamma"] (:83): two declared modules, so the isolation rules have a cross product to iterate, even though only one of them registers an assembly.
  • Layers (:85-:86) is a single LayerRef for module "Beta" at the caller's fromLayer, pointing at the caller's assembly with a derived root namespace.
  • OfLayer and the five convenience accessors (:88-:99) all project off that one list, so a layer with no entry yields an empty sequence and the corresponding rule is vacuous rather than broken.
  • OtherModuleNamespaces(module, layer) (:109-:110) returns the single forbidden namespace when layer == forbiddenLayer and an empty array otherwise. That single line is what isolates the pair under test from every other pair the rules would otherwise check.
• Why it's built this way - the test it serves needs a violation that is real: the registered assembly genuinely does depend on MMCA.Common.Application (it is the Infrastructure assembly, :25), and the map declares that namespace as another module's Application layer. A hand-written map is the only way to arrange a true dependency edge into a fabricated module boundary without inventing assemblies. See ADR-059 for the module boundary the rules enforce.
• Where it's used - constructed twice in ModuleIsolationTestsBaseTests: once as the static CrossLayerViolation shared by two facts (:21-:25) and once as a clean map pointed at a namespace nothing references (:59-:63).

AnonymousEndpointTestsBaseTests

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.Api · MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/Api/AnonymousEndpointTestsBaseTests.cs:13 · Level 4 · class

• What it is - the meta-test for the shipped anonymous-endpoint base: five facts proving each of its three assertions fails on the drift it claims to catch, that both allow-list identifier shapes are accepted, and that an inherited attribute is not double-reported on the derived controller.
• Depends on - AnonymousEndpointTestsBase (the type under test), its own nested fixtures (AnonymousFixtureController and family, InheritingFixtureController, DriftedTests, StaleAllowListTests, EmptyScanTests, ConformantTests), plus xUnit [Fact] and AwesomeAssertions' delegate assertions.
• Concept introduced - cross-references the "test a shipped test base from the outside by invoking its facts as delegates" technique introduced by ModuleConformanceTestsBaseTests. What this class adds is a third assertion axis. The module base is proven by failing it three ways; this base also has to be proven to accept the two identifier shapes its allow-list is written in, because that is a data contract between the base's emitter and every consumer's hand-written list, and getting it wrong makes the gate fail in the one repo the framework's CI never runs. The class doc states both halves (:8-:11). [Rubric §14 - Testability] assesses whether guardrails are trustworthy; [Rubric §11 - Security] is the property at stake, since a broken anonymous-endpoint gate is a gate that stops noticing lost authorization; [Rubric §33 - Developer Experience] covers the failure mode, a break that would only appear downstream after a release (ADR-058).
• Walkthrough
  • Base_Fails_WhenAnAnonymousEndpointIsNotAllowListed (:15-:24): drives DriftedTests and asserts the thrown message names AnonymousFixtureController (:22), with the because stating the ruling, that the offender message must name the endpoint that lost its gate (:23).
  • Base_Fails_WhenTheAllowListHasAStaleEntry (:26-:35): drives StaleAllowListTests and asserts the message contains "NoLongerAnonymous" (:33), the type name from an entry that matches nothing.
  • Base_Fails_WhenNothingWasScanned (:37-:43): drives EmptyScanTests and asserts the non-vacuity fact throws (:42).
  • Base_Accepts_TypeLevelAndMethodLevelEntries (:45-:59): the positive case. It calls all three of ConformantTests's inherited facts inside one delegate (:50-:55) and asserts NotThrow (:57-:58). Running all three together matters: the allow-list is only correct if it is simultaneously complete (no offenders) and exact (no stale entries).
  • Base_DoesNotReport_AnInheritedAttributeOnTheDerivedController (:61-:71): reads the scan output through ConformantTests's AnonymousEndpointsForTest() and asserts the derived-controller identifier is absent (:69-:70). This is the only fact that inspects the emitted set rather than an assertion's outcome.
• Why it's built this way - the four drifted and conformant subclasses are all private, which is what keeps xUnit from collecting their inherited facts as deliberately-failing tests of their own (class doc, :10-:11). The base ships in the MMCA.Common.Testing.Architecture package, so proving it here is proving it before a release rather than after one.
• Where it's used - an independent class in the Common architecture suite. The base it protects is bound for real by AnonymousEndpointTests here and by the equivalent subclass in each consumer repo.

CascadeChildFixture

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.CascadeFixtures · MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/CascadeFixtures/CascadeFixtures.cs:17 · Level 4 · class

• What it is - the child entity every cascade fixture aggregate owns a collection of. It is what makes those collections child-entity collections in the rule's eyes rather than ordinary lists.
• Depends on - AuditableBaseEntity<TIdentifierType> closed over int (CascadeFixtures.cs:17, import at :1).
• Concept introduced - soft-delete does not cascade, and the shape of a rule that can tell. Setting IsDeleted = true on an aggregate root hides the root behind the global query filter and leaves every child row ACTIVE: an order line of a deleted order, a session of a deleted event. Nothing reads those rows through the root any more, so the orphans are invisible until a report, an export or a per-child query surfaces them, and an erasure request that walks the child table finds data whose owner was "deleted" months ago. The database cannot help either, because a soft delete is an ordinary UPDATE and there is no ON DELETE CASCADE to fire (rule doc, MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Rules/Domain/ArchitectureRules.CascadeSoftDelete.cs:35-:42). AggregatesCascadeSoftDeleteToChildren (:100) therefore fails any concrete type deriving from AuditableAggregateRootEntity<T> that declares a collection of AuditableBaseEntity<T> children and does not delete them in its own Delete() override. The child-collection test is deliberately narrow: an instance field on the aggregate whose type is one of six named generic collection types (:25-:33) over an element type deriving from the auditable entity base (:200). Auto-properties are covered by the same pass, because an auto-property is a compiler-generated instance field, and the backing field name is normalized back to the property name for the report (:192-:197,:242). The aggregate's own _domainEvents escapes twice over: it is declared on the base rather than on the aggregate, and IDomainEvent is not an entity (:66-:68). [Rubric §8 - Data Architecture] assesses whether the data model's lifecycle rules actually hold; [Rubric §30 - Compliance/Privacy/Data Governance] is the sharper consequence, since an orphaned child row is data nobody accounts for at erasure time (ADR-005); [Rubric §14 - Testability] covers the fixtures.
• Walkthrough - one member, public string Label { get; init; } = string.Empty; (:19). Deriving from AuditableBaseEntity<TIdentifierType> is the entire fixture: strip that base and every collection in the file becomes invisible to the rule, which is precisely what ChildlessFixture's List<string> demonstrates from the other side.
• Why it's built this way - the file doc explains why every fixture here is internal and in its own namespace (:10-:15): it keeps them invisible to the framework rules that run over CommonArchitectureMap, which registers the Source/ assemblies and never this test assembly.
• Where it's used - the element type of five collections across the six cascade aggregates, and the assembly anchor of CascadeSoftDeleteFitnessTests's FixtureAssemblyMap (CascadeSoftDeleteFitnessTests.cs:103).

ConformantTests

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.Api · MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/Api/AnonymousEndpointTestsBaseTests.cs:126 · Level 4 · class

• What it is - the positive fixture for the anonymous-endpoint gate: a subclass whose allow-list correctly names every anonymous endpoint in the fixture set, in both identifier shapes, so all three inherited facts must pass.
• Depends on - AnonymousEndpointTestsBase (private sealed class ConformantTests : AnonymousEndpointTestsBase, AnonymousEndpointTestsBaseTests.cs:126) and the three fixture controllers it allow-lists.
• Concept introduced - building allow-list entries with typeof(...).FullName and nameof(...) rather than string literals. Each of the three entries is interpolated from live metadata (:133-:135): $"{typeof(AnonymousFixtureController).FullName}.{nameof(AnonymousFixtureController.PeekAsync)}" for the method-level shape, the same construction against the abstract base for the inherited action, and a bare typeof(TypeLevelAnonymousFixtureController).FullName! for the type-level shape. Renaming any fixture is then a compile error instead of a silently-drifting test. That discipline is not available to a real consumer's list (the framework's endpoints are strings there, as in AnonymousEndpointTests), which is precisely why the stale-entry fact exists to catch what nameof would have caught. [Rubric §15 - Best Practices & Code Quality] and [Rubric §14 - Testability] apply.
• Walkthrough - TargetAssemblies is this test assembly (:128-:129), so the scan sees the nested fixture controllers. AllowedAnonymousEndpoints (:131-:136) holds the three entries described above; note the abstract base is listed at its own name rather than the deriving controller's, which is the ruling InheritingFixtureController pins. MinimumScannedTypes is left at the base's default of 1, which the fixture set clears comfortably. One member is added beyond the base's surface: internal IReadOnlyCollection<string> AnonymousEndpointsForTest() => [.. AnonymousEndpoints()]; (:138), which materializes the base's protected enumeration so the enclosing test class can assert on the emitted set directly. The base exposes AnonymousEndpoints() as protected for exactly this kind of extension (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Bases/Api/AnonymousEndpointTestsBase.cs:120-:125).
• Where it's used - Base_Accepts_TypeLevelAndMethodLevelEntries (AnonymousEndpointTestsBaseTests.cs:45-:59) runs its three inherited facts, and Base_DoesNotReport_AnInheritedAttributeOnTheDerivedController (:61-:71) reads its AnonymousEndpointsForTest() output.

DriftedTests

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests · (see per-type table) · Level 4 · class

The name is used twice in this assembly, once per fitness base under proof, and both are the same idea: a private sealed subclass of a shipped *TestsBase whose configuration is deliberately wrong, so the base's assertions can be shown to actually fail on the drift they claim to catch. They are nested in different outer classes, so their full names differ and neither is visible outside its own file.

• Depends on - the base each one drifts from, plus the fixture it points at: ModuleConformanceTestsBase<TModule> with FakeDependentModule for one, AnonymousEndpointTestsBase with the fixture controllers for the other.
• Concept introduced - negative fixtures, and hiding them from test discovery. A fitness base that asserts nothing passes everywhere; the only way to know an assertion bites is to feed it a case that must fail. But a public subclass of an xUnit base is itself collected, so its inherited [Fact]s would run and report as red tests of their own. Declaring the drifted subclass private and nested keeps xUnit from collecting it, while the enclosing class can still instantiate it and invoke the inherited methods directly as delegates (var assert = new DriftedTests().Module_ShouldDeclare_ExpectedName;, ModuleConformanceTestsBaseTests.cs:91). Both class docs record that reasoning in the same words (ModuleConformanceTestsBaseTests.cs:81-:85, AnonymousEndpointTestsBaseTests.cs:10-:11). [Rubric §14 - Testability] assesses whether the guardrails themselves are trustworthy; this is the fixture shape that earns that trust. Compare NavigatingSpec, the same negative-fixture technique applied to a specification rule, and ProbeTests, which parameterizes the drift instead of hard-coding it.

• Why they're built this way - one wrong value per assertion, and no more. If a single drifted subclass were wrong in three ways at once and the base only ever threw on the first, the other two assertions could rot undetected; the module-side fixture avoids that by being driven three separate times, once per fact.
• Where they're used - the anonymous-endpoint one drives Base_Fails_WhenAnAnonymousEndpointIsNotAllowListed (AnonymousEndpointTestsBaseTests.cs:15-:24); the module one is instantiated three times by ModuleConformanceTestsBaseTests (:91,:99,:107), once per assertion under proof.

FakeArchitectureMap

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.Layering · MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/Layering/LayerDependencyOverrideTests.cs:127 · Level 4 · class

• What it is - a map that declares exactly the module and layer pairs a test hands it, with no relation to any real assembly layout. Its only purpose is to let the map-completeness rule's arithmetic be tested directly.
• Depends on - ArchitectureMapBase (private sealed class FakeArchitectureMap(params IEnumerable<LayerRef>[] modules) : ArchitectureMapBase, LayerDependencyOverrideTests.cs:127) and LayerRef.
• Concept - cross-references the map concept from CommonArchitectureMap. What is different here is that the map is data, not a description of reality: a primary constructor takes any number of LayerRef sequences and DefineLayers() simply flattens them (:131). Every LayerRef points at this same test assembly with a fabricated root namespace of the form MMCA.Fake.{module}.{layer} (:123-:124), and RepoToken is "MMCA.Fake" (:129), so nothing about the entries can be confused with the framework's own map. The class doc says why that is legitimate (:14-:16): the point under test is the rule's arithmetic over module names and layers, not any particular assembly, so a fixture map is more honest than borrowing a real one.
• Walkthrough - the test class supplies the data through two helpers rather than the map: Full(module) yields a LayerRef for all five layers, and Thin(module) yields only Shared, Application and Api (:117-:121), which is the shape of a module with no aggregate and no persistence. Ref(module, layer) (:123-:124) builds each entry.
• Why it's built this way - a real map cannot be made to declare a module that is missing a layer without deleting an assembly, which is not something a test can arrange. Constructing the map from literal layer lists turns "module Notification declares no Domain assembly" into a one-line fixture.
• Where it's used - constructed once per fact in LayerDependencyOverrideTests (:26,:39,:59,:80,:99,:109).

FitnessPrincipal

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.Domain · MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/Domain/SpecificationFitnessTests.cs:57 · Level 4 · class

• What it is - a throwaway "principal" entity used only as test data for the specification-navigation fitness function. It is the entity that a dependent record points at, so a specification can be written that tries to reach across the navigation into it.
• Depends on - AuditableBaseEntity<TIdentifierType> (it is a public sealed class FitnessPrincipal : AuditableBaseEntity<int>, SpecificationFitnessTests.cs:57).
• Concept introduced - test fixture entities for a fitness function. A fitness function is an executable architecture rule (see ArchitectureRules); to prove such a rule actually fires you feed it a deliberately-crafted model rather than the real domain. FitnessPrincipal is one half of that crafted model: a bare entity carrying a single scalar (IsActive, SpecificationFitnessTests.cs:59) so a specification can navigate to it. [Rubric §14 - Testability] assesses whether rules are provable with focused inputs; this fixture exists precisely so the guard is tested against a known-unsafe shape instead of hoping a real specification trips it.
• Walkthrough - one auto-property, bool IsActive (:59). That is the only member; identity and audit fields come from the base. It is the navigation target referenced by FitnessDependent.Principal. Deriving from AuditableBaseEntity<int> is load-bearing rather than cosmetic: the rule's navigation walker only counts a property as an entity navigation when its type (or its collection element type) inherits the auditable entity base (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Rules/Domain/ArchitectureRules.Specifications.cs:121-:138).
• Why it's built this way - the fitness test must be non-vacuous: it needs a real cross-entity navigation to flag. A minimal principal with a single scalar is the smallest thing a specification can legally navigate into.
• Where it's used - referenced by FitnessDependent and, through it, by NavigatingSpec and NavigatingQuerySpec; the whole fixture set drives SpecificationFitnessTests.

FixtureAssemblyMap

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.Cqrs · (see per-type table) · Level 4 · class

The name is used four times in this assembly, once per IL-reading rule under proof, and all four are the same one-entry map: this test assembly registered as a single framework layer, so the rule's whole-layer scan lands on the fixtures. They are nested in different outer classes, so their full names differ and none is visible outside its own file.

• Depends on - ArchitectureMapBase, LayerRef and the Layer enum.
• Concept introduced - the layer a fixture map declares is not decoration, it is the scope selector. Each of these four rules starts from a different part of the map, so each map has to name the matching layer or the rule reads nothing and passes vacuously. The cascade and hard-delete rules walk every assembly the map registers, through ScannableAssemblyLocations (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Rules/Domain/ArchitectureRules.SoftDelete.cs:88-:92), so their layer choice is nominal; the domain-throw rule reads map.OfLayer(Layer.Domain) and nothing else (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Rules/Domain/ArchitectureRules.DomainThrows.cs:107-:111), so registering Domain is mandatory there. All four use Framework(...) rather than Module(...), which is the opposite choice from FixtureModuleMap and correct for the same reason: these rules do not filter on module ownership, so the simplest entry is the honest one. Reading assemblies off disk by Assembly.Location also explains a shared limitation: a rule in this family cannot inspect a dynamic or single-file assembly, and the helper silently skips any location that does not exist on disk. [Rubric §14 - Testability] assesses whether a guardrail is provable with focused inputs, and a map that scopes the scan to fixtures is what makes each of these four rules provable at all.
• Walkthrough - each declares RepoToken => "MMCA.Common" and a single-entry DefineLayers() naming one layer and one anchor type from the fixture namespace it serves. Anchoring by typeof(SomeFixture).Assembly rather than by Assembly.GetExecutingAssembly() is deliberate: it ties the map to a type a compiler would fail on if the fixtures moved.

• Why they're built this way - four nested six-line classes rather than one shared fixture map, so each test file is readable end to end and no test can change another's scope by editing a shared file. It is the same trade-off FixtureModuleMap makes.
• Caveats / not-in-source - because each map registers the whole test assembly, a rule in this family sees every type in it, not just the fixtures in its own namespace. Three of the four are unaffected because their fixtures are the only matching shapes present; the domain-throw rule is not, which is why it carries an explicit allowlist of the assembly's non-fixture throws (DomainThrowFitnessTests.cs:29-:33).
• Where they're used - constructed once as a readonly field per test class (CascadeSoftDeleteFitnessTests.cs:21, SoftDeleteEnforcementFitnessTests.cs:19, DomainEventHandlerSaveFitnessTests.cs:21, DomainThrowFitnessTests.cs:35) and passed to every rule call in each.

FixtureEntity

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.HardDeleteFixtures · MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/HardDeleteFixtures/HardDeleteFixtures.cs:11 · Level 4 · class

• What it is - the entity type the hard-delete fixtures erase, keep, and soft-delete. It is the T of the DbSet<T>, IQueryable<T> and List<T> those fixtures operate on.
• Depends on - AuditableBaseEntity<TIdentifierType> closed over int (HardDeleteFixtures.cs:11, import at :2).
• Concept introduced - soft-delete as the framework's deletion model, and the EF members that bypass it. An entity sets IsDeleted = true and the global query filter hides it, so the row survives for audit, restore and erasure accounting; a hard delete bypasses all of that (rule doc, MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Rules/Domain/ArchitectureRules.SoftDelete.cs:26-:30). HardDeletesOnlyInAllowedTypes (:62) reads every scannable assembly's IL and reports any call to one of four EF Core member names, Remove, RemoveRange, ExecuteDelete and ExecuteDeleteAsync (:10-:11), from a type outside the repo's allowlist. The interesting half is the disambiguation. Remove is an ordinary collection method name, so it only counts when the declaring type is one of four EF entity-set types, DbContext, DbSet<T>, InternalDbSet<T,T> or LocalView<T> (:18-:24,:138-:139); ExecuteDelete and ExecuteDeleteAsync are unambiguous wherever EF declares them, so any declaring type under the Microsoft.EntityFrameworkCore prefix counts (:130,:138). Without that scoping the rule would fire on every dictionary and cache in the repo, which is the version of this idea that gets deleted after a week. [Rubric §8 - Data Architecture] assesses whether the storage model's deletion semantics hold everywhere; [Rubric §30 - Compliance/Privacy/Data Governance] is why it matters, since an erased row silently drops out of audit and erasure accounting (ADR-005); [Rubric §14 - Testability] covers the fixtures.
• Walkthrough - one member, public string Name { get; set; } = string.Empty; (:13). It is public (unlike the fixtures around it) because it appears in the public signatures of the static fixture methods and is the anchor type the self-test's map resolves the assembly from (SoftDeleteEnforcementFitnessTests.cs:83).
• Where it's used - the entity parameter of all five members across DbSetRemovingFixture and family, and the map anchor of SoftDeleteEnforcementFitnessTests.

FixtureModuleMap

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.Contracts and MMCA.Common.Architecture.Tests.Cqrs · (see per-type table) · Level 4 · class

The name is used twice in this assembly, once per catalog-style rule under proof, and both are the same one-entry map: this test assembly registered as a module Application layer so a consumer-facing rule sees the fixtures. They are nested in different outer classes, so their full names differ.

• Depends on - ArchitectureMapBase, LayerRef and the Layer enum.
• Concept introduced - why a self-test sometimes has to pretend to be a consumer. Several rules deliberately read only the per-module assemblies and skip framework layers, because a framework's own types are not the consumer's catalog: the error-catalog rules take ModuleDomain() plus ModuleApplication() (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Rules/Contracts/ArchitectureRules.ErrorCatalog.cs:38-:44), and the validator-coverage rule takes ModuleApplication() alone, mirroring where the framework's AddValidatorsFromAssembly scan looks (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Rules/Cqrs/ArchitectureRules.CommandValidators.cs:88-:89). A map built from Framework(...) entries has Module set to the empty string (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/ArchitectureMapBase.cs:94-:95) and the module-layer lookup keeps only entries with l.Module.Length > 0 (:101-:102), so ModuleApplication() returns nothing and both rules would pass having read nothing at all. Using Module("Tickets", ...) is therefore not decoration: it is the one thing that puts the fixtures in scope. Compare FixtureAssemblyMap, whose rules read whole layers and which uses Framework(...) for the opposite reason, and FakeConsumerMap, which flips the same switch to prove a rule excludes framework types.
• Walkthrough - both declare RepoToken => "MMCA.Common" and a single-entry DefineLayers() returning Module("Tickets", Layer.Application, <anchor>.Assembly). The module name "Tickets" is arbitrary except that the error-catalog self-test's prefix delegate closes over the same word (ErrorCatalogFitnessTests.cs:100), which is how a consumer's real prefix convention is modelled.

• Why they're built this way - each is nested private sealed inside the test class that uses it, so neither is visible to the other and neither can be mistaken for a repo map. Duplicating eight lines is cheaper than a shared fixture map whose meaning would have to be read from another file.
• Where they're used - constructed once as a readonly field per test class (CommandValidatorCoverageFitnessTests.cs:20, ErrorCatalogFitnessTests.cs:19) and passed to every rule call in each.

StaleAllowListTests

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.Api · MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/Api/AnonymousEndpointTestsBaseTests.cs:108 · Level 4 · class

• What it is - the adversarial fixture for the stale-entry half of the anonymous-endpoint gate: a subclass whose allow-list names an endpoint that does not exist, so the base's AllowList_HasNoStaleEntries fact must report it rather than shrug.
• Depends on - AnonymousEndpointTestsBase (private sealed class StaleAllowListTests : AnonymousEndpointTestsBase, AnonymousEndpointTestsBaseTests.cs:108).
• Concept introduced - an allow-list rots in two directions, and only one of them is obvious. A missing entry fails loudly the moment a new [AllowAnonymous] lands. A stale entry fails silently and permanently: the endpoint gets renamed, re-gated with [Authorize], or deleted, and the list keeps granting a permission that is no longer being requested. Nothing breaks, so nobody looks, and the next endpoint that happens to match that identifier inherits an approval nobody granted it. The base therefore runs the comparison both ways, computing stale as the allow-list entries with no match in the scanned set (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Bases/Api/AnonymousEndpointTestsBase.cs:83-:89), with a because that spells out the consequence: an entry that no longer matches hides a renamed or re-gated endpoint behind a permission that is no longer being granted (:88). [Rubric §11 - Security] is the property; [Rubric §15 - Best Practices & Code Quality] is the mechanism, since a self-pruning list is one that stays readable.
• Walkthrough - TargetAssemblies is this test assembly (:110-:111), so the fixture controllers are discovered normally. AllowedAnonymousEndpoints holds exactly one entry, "MMCA.Common.Architecture.Tests.NoLongerAnonymousController.ReadAsync" (:113-:114), naming a controller that has never existed. That makes the fixture fail both facts at once (every real fixture endpoint is now an unlisted offender as well), which is harmless because the fact under proof invokes only AllowList_HasNoStaleEntries as a delegate.
• Where it's used - the subject of Base_Fails_WhenTheAllowListHasAStaleEntry (AnonymousEndpointTestsBaseTests.cs:26-:35), which asserts the message contains "NoLongerAnonymous" (:33), the distinctive fragment of the phantom identifier.

ModuleConformanceTestsBaseTests

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.Layering · MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/Layering/ModuleConformanceTestsBaseTests.cs:86 · Level 5 · class

• What it is - the meta-test for the shipped per-module conformance base: five facts that prove each of the base's assertions actually fails on the drift it claims to catch, that the base reaches IModule's default implementations for a leaf module, and that its disabled-stub hook is harmlessly vacuous when a subclass does not override it.
• Depends on - ModuleConformanceTestsBase<TModule> (the type under test), its own fixtures DriftedTests, FakeLeafModuleConformanceTests, FakeLeafModule and FakeDependentModule, plus xUnit [Fact] and AwesomeAssertions' Should().Throw<Exception>() / NotThrow() delegate assertions.
• Concept introduced - testing a shipped test base, from the outside, by invoking its facts as delegates. The base lives in the MMCA.Common.Testing.Architecture package and is consumed by five subclasses across MMCA.ADC and MMCA.Store, so a regression in it would surface as green consumer suites that assert nothing. This class converts each inherited [Fact] into a method group (var assert = new DriftedTests().Module_ShouldDeclare_ExpectedName;, :91) and asserts on the delegate's behavior, which is what lets one xUnit test observe another test method failing. [Rubric §14 - Testability] assesses whether guardrails are themselves trustworthy; [Rubric §34 - Architecture Governance & Documentation] is the reason the guardrail exists at all (ADR-015 makes module conformance build-gating); and [Rubric §33 - Developer Experience] covers the failure mode being prevented, a silent break that would only appear in a downstream repo after a release (ADR-058).
• Walkthrough
  • Three adversarial facts, one per assertion the base makes, each pointing at DriftedTests and asserting the delegate throws: Base_Fails_WhenTheNameDrifts (:88-:94), Base_Fails_WhenADependencyIsMissing (:96-:102), and Base_Fails_WhenRequiresDependenciesDrifts (:104-:110).
  • Base_ReadsDefaultInterfaceImplementations_ForALeafModule (:112-:121): instantiates FakeLeafModuleConformanceTests and calls the two inherited assertions directly (:119-:120). Passing proves the base reached IModule's defaults, because the leaf fixture declares neither member (inline comment, :115-:116).
  • Base_DisabledStubHook_IsVacuous_ByDefault (:123-:129): asserts the fourth inherited fact does not throw for a module that exports nothing, so a leaf subclass never has to override AssertDisabledStubs (the base's default is an empty body, MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Bases/Layering/ModuleConformanceTestsBase.cs:75-:77).
  • The nested private sealed class DriftedTests (:131-:138) closes the file; being private is what keeps xUnit from collecting its three deliberately-failing inherited facts as tests of their own (class doc, :81-:85).
• Why it's built this way - the three module members the base asserts on are the entire contract ModuleLoader registers on: it topologically orders on Dependencies, matches ModulesSettings entries by Name, and chooses between a hard start failure and stub registration from RequiresDependencies (the base's own because clauses spell each one out, ModuleConformanceTestsBase.cs:40,:52,:61). None of those drifts throws at build time, so the fitness base is the only guard, and this class is the guard on the guard (ADR-059).
• Where it's used - an independent class in the Common architecture suite. The base it protects is subclassed by five real module tests: MMCA.ADC/Tests/Modules/Notification/MMCA.ADC.Notification.API.Tests/NotificationModuleTests.cs:8, MMCA.ADC/Tests/Modules/Identity/MMCA.ADC.Identity.API.Tests/IdentityModuleTests.cs:5, MMCA.Store/Tests/Modules/Sales/MMCA.Store.Sales.API.Tests/SalesModuleTests.cs:5, MMCA.Store/Tests/Modules/Identity/MMCA.Store.Identity.API.Tests/IdentityModuleTests.cs:5, and MMCA.Store/Tests/Modules/Catalog/MMCA.Store.Catalog.API.Tests/CatalogModuleTests.cs:5.
• Caveats / not-in-source - the three adversarial facts assert only that an exception is thrown (Should().Throw<Exception>(), :93,:101,:109), not which assertion produced it or what its message says. They prove the base is not vacuous; they do not pin its failure text.

AnonymousEndpointTests

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.Api · MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/Api/AnonymousEndpointTests.cs:14 · Level 5 · class

• What it is - the framework's own anonymous-endpoint allow-list: the live, reviewed statement of every controller action MMCA.Common ships without an authorization gate. Six entries today, all of them credential-exchange or credential-recovery endpoints.
• Depends on - AnonymousEndpointTestsBase (public sealed class AnonymousEndpointTests : AnonymousEndpointTestsBase, AnonymousEndpointTests.cs:14), ApiControllerBase as the anchor for the API assembly (:18), and UISharedAssemblyReference as the anchor for the shared UI assembly (:19).
• Concept introduced - an allow-list as a review artifact, not a suppression list. The gate's value is not that it blocks [AllowAnonymous]; it is that adding one becomes a line in a test file with a comment next to it, landing in a diff that a human reads. Every entry here carries its justification inline, and each justification is the same argument: requiring a token would be circular, because minting or recovering the token is what the endpoint does. Login, register and refresh mint or rotate the token pair (:24-:28); the OAuth completion code is the caller's only credential at that point and is single-use, burned on first exchange (:29-:31); forgot-password and reset-password are for a caller who has lost the credential, are throttled by the same auth-ip rate-limit policy, and forgot-password always answers 202 so it reveals nothing about which addresses hold accounts (:32-:34). [Rubric §11 - Security] assesses the deliberateness of the authorization posture; note that the compensating control for every entry is rate limiting rather than authentication (ADR-029). [Rubric §9 - API & Contract Design] applies because the anonymous surface is part of the published contract, and [Rubric §34 - Architecture Governance & Documentation] because the reasoning lives in compiled code rather than a wiki page.
• Walkthrough
  • TargetAssemblies (:16-:20) names two assemblies by anchor type, so the scan covers both the controllers and the routable Blazor pages the framework ships.
  • AllowedAnonymousEndpoints (:22-:39) is the six-entry list. Two of them are worth reading closely: PasswordResetAuthControllerBase`2.ForgotPasswordAsync and its reset sibling (:37-:38) carry a backtick-2 arity suffix, because PasswordResetAuthControllerBase<TForgotPasswordCommand, TResetPasswordCommand> is generic over the app's command records and reflection renders a generic type's FullName that way. The comment above them says exactly that (:35-:36), which is the kind of note that saves the next person an hour.
  • MinimumScannedTypes => 21 (:43) raises the base's default floor of 1 to this repo's known count, described in the comment as a floor and not an equality: 12 API controller types plus the routable UI pages (:41-:42). Removing a scanned type is therefore a failure rather than a quietly smaller scan.
• Why it's built this way - the endpoints that cannot require a token are exactly the ones an attacker reaches first, so the framework's position is that they must be enumerated, justified, and rate-limited rather than merely working. The base's own doc records the one thing this gate cannot see: minimal-API endpoints opt out through the .AllowAnonymous() builder call, which is endpoint metadata produced at map time and invisible to static reflection (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Bases/Api/AnonymousEndpointTestsBase.cs:18-:24). The framework's minimal-API anonymous surface (JWKS, OIDC discovery, app-association, session-cookie refresh, health) is deliberate and small, but it is not covered here.
• Where it's used - collected and run by xUnit in the Common architecture suite; its three facts come entirely from the base. Consumers write their own subclass with their own list.
• Caveats / not-in-source - the minimal-API blind spot above is stated in the base's documentation, and closing it would need an endpoint-metadata check over a built host. Nothing in this class compensates for it.

CancellationTestMap

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.Cqrs · MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/Cqrs/CancellationTokenFitnessTests.cs:63 · Level 5 · class

• What it is - a one-layer architecture map used only by CancellationTokenFitnessTests: it registers this test assembly as the map's single Application layer so the cancellation-token rule scans the fixture services and nothing else.
• Depends on - ArchitectureMapBase (private sealed class CancellationTestMap : ArchitectureMapBase, CancellationTokenFitnessTests.cs:63), the Layer enum, and LayerRef.
• Concept - cross-references the map concept from CommonArchitectureMap. The narrowing matters twice over here. First, the cancellation rule only visits the Application and Infrastructure layers (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Rules/Cqrs/ArchitectureRules.CancellationTokens.cs:45-:47), so registering the test assembly as Application is what puts the fixtures in scope at all. Second, the rule's automatic exemption compares against map.Layers.Select(l => l.Assembly) (:42), so a map holding only this assembly is what makes IAsyncEnumerator<T> (declared in the BCL, outside the map) count as an externally-fixed contract. A wider map would not change that result here, but the single entry keeps the fixture's meaning unambiguous.
• Walkthrough - RepoToken => "MMCA.Common" (:65) and a one-entry DefineLayers() returning Framework(Layer.Application, typeof(CancellationTokenFitnessTests).Assembly) (:67-:68).
• Where it's used - constructed on every call of the test class's private RunRule helper (:56).

CancellationTokenFitnessTests

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.Cqrs · MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/Cqrs/CancellationTokenFitnessTests.cs:12 · Level 5 · class

• What it is - the meta-test for the trailing-CancellationToken rule: three facts that prove it flags a missing, misplaced, or misnamed token, leaves compliant and out-of-scope members alone, honors the caller-supplied exemption list, and never flags a signature the repo does not own.
• Depends on - ArchitectureRules (the rule under test, CancellationTokenFitnessTests.cs:55), its own CancellationTestMap (:56), the six fixture services in MMCA.Common.Architecture.Tests.CancellationFixtures (:1), and externals xUnit [Fact] plus AwesomeAssertions' Should().Throw<Exception>().Which (:59).
• Concept introduced - asserting on a rule's failure message rather than on whether it threw. Every fixture in this file is deliberately in scope at once, so the rule always throws; a bare "it threw" assertion would prove nothing. Instead the private RunRule helper (:53-:60) captures the exception's message once and each fact makes positive and negative Contain assertions against that single string. The result is one rule execution that proves six independent behaviors, and every assertion carries a because clause spelling out the ruling it pins (:19-:24). [Rubric §14 - Testability] assesses whether guardrails are themselves trustworthy; this is the technique that makes a multi-branch classifier provable in three facts. [Rubric §12 - Performance & Scalability] is the property being defended, as taught in the fixture family section.
• Walkthrough
  • Rule_FlagsMissingToken_ButNotCompliantOrNonAsyncMembers (:14-:25): asserts both MissingTokenFixtureService.RunAsync and .PingAsync appear (:19-:22), and that neither CompliantFixtureService nor the internal HiddenAsync does (:23-:24).
  • Rule_FlagsMisplacedAndMisnamedTokens (:27-:36): asserts the two offender method names appear together with the rule's exact classifier strings, "must be the LAST parameter" (:33) and "must be named 'cancellationToken'" (:35), so the message a developer will actually read is pinned, not just the fact of a failure.
  • Rule_HonorsExemptions_AndSignaturesTheRepoDoesNotOwn (:38-:51): runs the rule twice. Without exemptions, ExemptableFixtureService.LegacyAsync is reported (:41-:43); with that one entry passed in (:45), it disappears (:47). The same run also asserts MoveNextAsync never appears (:48-:50), which is the automatic exemption rather than the explicit one.
• Why it's built this way - the rule is one of the framework's broadest (it judges every public awaitable method in two layers), so its false-positive behavior matters as much as its true-positive behavior. Pinning the message text also protects the developer experience: the classifier's wording is what tells someone how to fix the build. See ADR-015.
• Where it's used - an independent class in the Common architecture suite; the shipped consumer-facing binding of the same rule is CancellationTokenConventionTests.

CommandValidatorCoverageFitnessTests

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.Cqrs · MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/Cqrs/CommandValidatorCoverageFitnessTests.cs:16 · Level 5 · class

• What it is - the meta-test for the command-validation coverage rule: eight facts that pin each coverage shape, both escape hatches, and the inventory count that keeps the whole gate from passing vacuously.
• Depends on - ArchitectureRules (CommandsHaveValidators and HandledCommandCount, CommandValidatorCoverageFitnessTests.cs:25,:103), its nested FixtureModuleMap, the thirteen types in MMCA.Common.Architecture.Tests.CommandValidatorFixtures (:1), and Xunit.Sdk.XunitException (:3), which every fact asserts on by exact type rather than as a bare Exception.
• Concept introduced - proving a rule and proving it is not vacuous, in the same class. Seven of the eight facts read the failure message of a rule that always throws, the same technique CancellationTokenFitnessTests uses. The eighth is different in kind: CommandInventory_CountsTheDataCarryingCommands calls HandledCommandCount and pins it at exactly 5 (:100-:108). That number exists because a map that resolved to no module Application assemblies would make every other fact in the class pass while reading nothing, and the same counter is what CommandValidatorCoverageTestsBase exposes to consumers as their own non-vacuity guard (rule doc, MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Rules/Cqrs/ArchitectureRules.CommandValidators.cs:73-:77). Pinning an exact count rather than a floor is affordable here because the fixture set is closed; a consumer uses a floor. [Rubric §14 - Testability] and [Rubric §24 - Forms/Validation/UX Safety] apply.
• Walkthrough - one private const string FixtureNamespace (:18) and one readonly FixtureModuleMap (:20) are shared by every fact.
  • CommandWithNoValidation_IsFlagged (:22-:31) and CommandWithItsOwnValidator_IsCovered (:33-:42): the offender and the direct-coverage case, asserted by Contain and NotContain on the one message.
  • CommandCoveredThroughTheRequestBridge_IsCovered (:44-:53) and BridgeWithNoRequestValidator_IsNotCoverage (:55-:64): the two halves of the bridge, with the second because stating exactly why a registered CommandRequestValidator is not coverage on its own (:63).
  • PayloadFreeCommand_IsSkipped (:66-:75): the marker command, absent from the report because it has no settable property to validate.
  • AllowlistedCommand_IsExempt (:77-:89): passes one fully-qualified command name and asserts that command disappears while the other offender is still reported (:87-:88). That second assertion is what distinguishes a working exemption from a rule that stopped firing.
  • AllowlistedNamespace_SilencesTheRule (:91-:98): passes the fixture namespace and asserts NotThrow, the only fact in the class where the rule is quiet.
  • CommandInventory_CountsTheDataCarryingCommands (:100-:108): the count, with the because enumerating the five commands by name.
• Why it's built this way - the escape hatch has two granularities (a type and a namespace) and both need proof, because a repo records "this command genuinely has nothing to check" at whichever level fits. Asserting on XunitException specifically rather than Exception means an unexpected failure inside the rule (a null reference, a bad cast) fails the fact instead of being mistaken for the rule firing. See ADR-015.
• Where it's used - an independent class in the Common architecture suite; the shipped consumer-facing binding of the same rule is CommandValidatorCoverageTestsBase, which MMCA.Common itself does not subclass because it declares no modules.

CycleTestMap

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.Layering · MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/Layering/NamespaceCycleFitnessTests.cs:52 · Level 5 · class

• What it is - a one-layer map for the namespace-cycle fitness test, rooted at the CycleFixtures namespace so the rule sees only the three fixture namespaces and none of the real test code.
• Depends on - ArchitectureMapBase (private sealed class CycleTestMap : ArchitectureMapBase, NamespaceCycleFitnessTests.cs:52), LayerRef, and the Layer enum.
• Concept introduced - constructing a LayerRef directly to override the derived root namespace. Every other map in this chapter uses the Framework(layer, assembly) helper, which computes the layer's root namespace as MMCA.Common.{segment} (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/ArchitectureMapBase.cs:94-:95). That is wrong here, because the cycle rule groups types by the namespace segment directly beneath LayerRef.RootNamespace (ArchitectureRules.Cycles.cs:12-:16) and skips types outside it entirely: with a derived root the fixtures would not be grouped into Left / Right / Acyclic nodes at all. So this map builds the LayerRef by hand with FixtureRoot as the fourth argument (:58-:62), which is the one place in the suite where the record's positional constructor (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/IArchitectureMap.cs:31) is used directly. [Rubric §14 - Testability] is the theme: scoping the map is what keeps the assertion about the fixtures instead of about whatever else the test assembly happens to contain.
• Walkthrough - RepoToken => "MMCA.Common" (:54) and a DefineLayers() returning a single new LayerRef(string.Empty, Layer.Application, typeof(NamespaceCycleFitnessTests).Assembly, FixtureRoot) (:56-:63), where FixtureRoot is the class constant "MMCA.Common.Architecture.Tests.CycleFixtures" (:13). The empty first argument is the module name, which is what marks the layer as framework-owned rather than module-owned.
• Where it's used - constructed once per fact in NamespaceCycleFitnessTests (:18,:32,:42).

DataSubjectSample

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.Governance · MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/Governance/PiiErasureContractFitnessTests.cs:79 · Level 5 · class

• What it is - a representative "data subject" fixture: a single object that carries [Pii] members alongside non-PII fields and implements an in-place erasure path, so the framework's privacy machinery can be exercised end to end against a realistic shape.
• Depends on - IAnonymizable (it is private sealed class DataSubjectSample : IAnonymizable, PiiErasureContractFitnessTests.cs:79), PiiAttribute (marks Email and FullName, :91,:94), and Result (returned from Anonymize, :99).
• Concept introduced - closing a vacuous fitness function with a stand-in data subject. The framework's [Pii] => IAnonymizable scan (PiiConventionTests) has nothing to assert because MMCA.Common ships no PII-bearing domain entity of its own. Rather than invent a fake aggregate in the Domain layer, this fixture models the exact contract a consumer PII aggregate (for example MMCA.ADC's User) must satisfy, and lets PiiErasureContractFitnessTests prove the three §30 mechanisms compose. [Rubric §30 - Compliance/Privacy/Data Governance] assesses whether erasure, redaction, and masking actually work together; this sample is the vehicle that keeps the framework's proof of that non-vacuous.
• Walkthrough - public constants publish the expected before and after values so the tests can assert without magic literals: SampleId = 7, PublicCity = "Atlanta", OriginalEmail, OriginalFullName (:81-:84), plus private anonymized placeholders (:86-:87). Id (:89) and City (:97) are non-PII init pass-through fields; Email and FullName are [Pii] with private setters (:91-:95), which is what lets Anonymize rewrite them in place while no caller outside the type can. Anonymize() (:99-:105) overwrites both PII fields with the fixed placeholders and returns Result.Success(); because it re-applies constants, calling it twice is idempotent by construction (:101).
• Why it's built this way - ADR-005 (soft-delete versus erasure) requires that a right-to-erasure path be idempotent and leave no clear text behind. The fixture encodes that contract in the smallest object that can be pushed through PiiRedactor and Anonymize together.
• Where it's used - the sole fixture for PiiErasureContractFitnessTests.

DbSetRemovingFixture, ExecuteDeletingFixture, SoftDeletingFixture

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.HardDeleteFixtures · (see per-type table) · Level 5 · class

Three internal static classes holding five one-line methods between them: three that erase rows through EF Core and two that do not. They are the compiled call sites the hard-delete rule has to tell apart.

• Depends on - Microsoft.EntityFrameworkCore for DbSet<T> and the ExecuteDeleteAsync queryable extension (HardDeleteFixtures.cs:1) and FixtureEntity as the element type.
• Concept - cross-references the hard-delete concept introduced by FixtureEntity. What this set proves is the disambiguation, which is the whole engineering content of the rule. SoftDeletingFixture.Forget calls List<FixtureEntity>.Remove (:41), which is the same method name the rule bans, on a type the rule must ignore. Its own doc says why that matters (:32-:36): Remove on a List<T> is what makes the naive "ban the name Remove" version of this rule useless. Having a genuine List<T>.Remove compiled next to a genuine DbSet<T>.Remove is what turns the declaring-type check from an implementation detail into a proven behavior.
• Walkthrough - the rule reports each site as {type.FullName}.{method.Name} calls {DeclaringType.Name}.{callee.Name} (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Rules/Domain/ArchitectureRules.SoftDelete.cs:115), so the failure text names both ends. The allowlist is checked at the type level before any method is walked (:99-:102), which is why an entry silences a whole type rather than one call.

• Why they're built this way - two erasing types rather than one is what makes the type-level allowlist fact meaningful: exempting DbSetRemovingFixture must leave ExecuteDeletingFixture reported. Keeping all five methods to a single expression means the compiled IL contains the call under test and essentially nothing else.
• Where they're used - scanned by SoftDeleteEnforcementFitnessTests through its FixtureAssemblyMap, which registers this assembly as the map's single Infrastructure layer.

ErrorCatalogFitnessTests

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.Contracts · MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/Contracts/ErrorCatalogFitnessTests.cs:15 · Level 5 · class

• What it is - the meta-test for the two error-catalog rules: seven facts that pin the cross-type collision, the two-branch near-miss, the shared-code exemption on both rules, the unprefixed offender, the UNVERIFIABLE report for a dynamically-built code, and the distinct-code inventory.
• Depends on - ArchitectureRules (ErrorCodesAreUnique, ErrorCodesUseAnAllowedPrefix and DistinctErrorCodeCount, ErrorCatalogFitnessTests.cs:24,:58,:92), its nested FixtureModuleMap, the six fixture catalogs (:1), and Xunit.Sdk.XunitException (:3).
• Concept introduced - the third verdict: UNVERIFIABLE, and why a static analyser should have one. Most fitness functions are binary. These are not, because a code assembled at run time genuinely cannot be read out of the instruction stream, and both available binary answers are wrong: passing it hides a possible collision, failing it bans a legitimate pattern the framework never decided to ban. The rules take the third option and surface those sites in the failure message under an UNVERIFIABLE heading (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Rules/Contracts/ArchitectureRules.ErrorCatalog.cs:151-:159), so the reader learns the catalog has a blind spot and where it is. DomainThrowFitnessTests pins the same verdict for the same reason on a different rule. [Rubric §14 - Testability] assesses whether a guardrail is honest about its own limits, which is exactly what a named third verdict is; [Rubric §9 - API & Contract Design] is the property.
• Walkthrough - a private static readonly string[] SharedCodes = ["Error.NotFound"] (:17) stands in for a repo's allowed-shared-codes list, and IsTicketsCode (:100) is the prefix delegate, closing over the fixture module's name exactly as a consumer's would close over its real module names.
  • DuplicateCode_AcrossTwoTypes_IsFlagged (:21-:31): asserts the message names the code and both owning types (:28-:30), which is what makes a collision actionable.
  • CodeReusedAcrossBranchesOfOneType_IsNotADuplicate (:33-:42): the near-miss, absent from the report because uniqueness is measured per declaring type.
  • SharedCode_OnTheAllowList_IsExemptFromUniqueness (:44-:53) and PrefixedCodes_AndAllowedSharedCodes_PassThePrefixRule (:66-:76): the shared-code exemption proven against both rules, not just the one it was written for.
  • UnprefixedCode_IsFlagged (:55-:64): asserts both the code and the owning type appear (:62-:63).
  • DynamicCode_IsReportedAsUnverifiable (:78-:87): asserts the literal string "UNVERIFIABLE" and the owning type name are both present (:85-:86).
  • DistinctCodeCount_CountsTheLiteralCatalog (:89-:97): the non-vacuity guard, asserted as a floor of 5 with the five literal codes enumerated in the because (:94-:96). A floor rather than an equality, because the count is over literals the scan can read and a future fixture addition should not be a test failure.
• Why it's built this way - both rules read the same collected sites, so proving them in one class against one fixture catalog keeps the two verdicts comparable, and each fact makes exactly one claim about the shared message. See ADR-015.
• Where it's used - an independent class in the Common architecture suite; the shipped consumer-facing binding of both rules is ErrorCatalogTestsBase, whose default prefix delegate closes over the repo's own module names.

FitnessDependent

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.Domain · MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/Domain/SpecificationFitnessTests.cs:48 · Level 5 · class

• What it is - the other half of the specification-navigation fixture: an entity that holds a foreign-key scalar and a navigation to a FitnessPrincipal, so both a safe (scalar-only) and an unsafe (navigating) specification can be written over it.
• Depends on - AuditableBaseEntity<TIdentifierType> (public sealed class FitnessDependent : AuditableBaseEntity<int>, SpecificationFitnessTests.cs:48) and FitnessPrincipal (the Principal? navigation, :52).
• Concept introduced - cross-references the fixture concept introduced by FitnessPrincipal. This type adds the parts a specification can filter on: PrincipalId (scalar FK, :50), a nullable Principal navigation (:52), and a Flag scalar (:54). The scalar-versus-navigation split is the whole point: it lets one fixture support both the pattern the rule must flag and the pattern it must leave alone.
• Walkthrough - three auto-properties: int PrincipalId (:50), FitnessPrincipal? Principal (:52), bool Flag (:54). ScalarOnlySpec filters on PrincipalId and Flag; NavigatingSpec reaches through Principal.
• Where it's used - the entity type parameter for all four fixture specifications in SpecificationFitnessTests: NavigatingSpec, ScalarOnlySpec, and the two query variants (NavigatingQuerySpec, ScalarOnlyQuerySpec).

FixtureAssemblyMap

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.Domain · (see per-type table) · Level 5 · class

The name is used four times in this assembly, once per IL-reading rule under proof, and all four are the same one-entry map: this test assembly registered as a single framework layer, so the rule's whole-layer scan lands on the fixtures. They are nested in different outer classes, so their full names differ and none is visible outside its own file.

• Depends on - ArchitectureMapBase, LayerRef and the Layer enum.
• Concept introduced - the layer a fixture map declares is not decoration, it is the scope selector. Each of these four rules starts from a different part of the map, so each map has to name the matching layer or the rule reads nothing and passes vacuously. The cascade and hard-delete rules walk every assembly the map registers, through ScannableAssemblyLocations (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Rules/Domain/ArchitectureRules.SoftDelete.cs:87-:91), so their layer choice is nominal; the domain-throw rule reads map.OfLayer(Layer.Domain) and nothing else (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Rules/Domain/ArchitectureRules.DomainThrows.cs:106-:110), so registering Domain is mandatory there. All four use Framework(...) rather than Module(...), which is the opposite choice from FixtureModuleMap and correct for the same reason: these rules do not filter on module ownership, so the simplest entry is the honest one. Reading assemblies off disk by Assembly.Location also explains a shared limitation: a rule in this family cannot inspect a dynamic or single-file assembly, and the helper silently skips any location that does not exist on disk.
• Walkthrough - each declares RepoToken => "MMCA.Common" and a single-entry DefineLayers() naming one layer and one anchor type from the fixture namespace it serves. Anchoring by typeof(SomeFixture).Assembly rather than by Assembly.GetExecutingAssembly() is deliberate: it ties the map to a type a compiler would fail on if the fixtures moved.

• Why they're built this way - four nested six-line classes rather than one shared fixture map, so each test file is readable end to end and no test can change another's scope by editing a shared file. It is the same trade-off FixtureModuleMap makes.
• Caveats / not-in-source - because each map registers the whole test assembly, a rule in this family sees every type in it, not just the fixtures in its own namespace. Three of the four are unaffected because their fixtures are the only matching shapes present; the domain-throw rule is not, which is why it carries an explicit allowlist of the assembly's non-fixture throws (DomainThrowFitnessTests.cs:29-:33).
• Where they're used - constructed once as a readonly field per test class (CascadeSoftDeleteFitnessTests.cs:21, SoftDeleteEnforcementFitnessTests.cs:19, DomainEventHandlerSaveFitnessTests.cs:21, DomainThrowFitnessTests.cs:35) and passed to every rule call in each.

IdempotencyFitnessTests

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.Cqrs · MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/Cqrs/IdempotencyFitnessTests.cs:12 · Level 5 · class

• What it is - the meta-test for the POST idempotency-intent gate: three facts that prove the rule names the undeclared controller, stays silent about the three declared ones, and skips abstract controllers entirely.
• Depends on - ArchitectureRules (ArchitectureRules.PostActionsDeclareIdempotencyIntent, IdempotencyFitnessTests.cs:17), its nested IdempotencyTestMap and four controller fixtures, IdempotentAttribute and NonIdempotentAttribute (:2), plus Microsoft.AspNetCore.Mvc (:1), xUnit, and AwesomeAssertions.
• Concept introduced - nameof instead of string literals in message assertions. Every assertion here is built from nameof(UndeclaredFitnessController) and friends (:21,:32,:35,:38,:48), so renaming a fixture is a compile-time event rather than a silently-passing test. Combined with the always-throwing design (CancellationTokenFitnessTests uses the same shape), it means the suite fails loudly on refactors instead of drifting. [Rubric §14 - Testability] and [Rubric §15 - Best Practices & Code Quality] both apply.
• Walkthrough
  • Rule_FlagsThePostThatDeclaresNothing (:14-:23): calls the rule through an act delegate, captures the thrown exception, and asserts the message contains UndeclaredFitnessController.CreateThingAsync (:20-:22). Note it asserts the qualified member, so the fact fails if the rule reports a type without its offending action.
  • Rule_AcceptsDirectAndInheritedAndOptedOutDeclarations (:25-:40): three NotContain assertions covering the direct declaration (:31-:33), the inherited one (:34-:36), and the justified opt-out (:37-:39), each with a because clause stating the ruling.
  • Rule_SkipsAbstractControllers (:42-:50): asserts AbstractFitnessControllerBase is absent, which is the ConcreteClasses filter's doing, not an attribute's.
• Why it's built this way - one deliberately-offending fixture means the rule always throws, so all three facts can read the same message shape without any of them having to construct a passing map. The gate itself exists because an undeclared POST is a duplicate-write incident waiting to happen (ADR-015 for the enforcement approach).
• Where it's used - an independent class in the Common architecture suite; the shipped binding of the same rule over real code is IdempotencyConventionTests.

IdempotencyTestMap

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.Cqrs · MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/Cqrs/IdempotencyFitnessTests.cs:52 · Level 5 · class

• What it is - a one-layer map that registers this test assembly as the Api layer, which is the only layer the POST idempotency rule scans.
• Depends on - ArchitectureMapBase (private sealed class IdempotencyTestMap : ArchitectureMapBase, IdempotencyFitnessTests.cs:52), the Layer enum, and LayerRef.
• Concept - cross-references the map concept from CommonArchitectureMap. The layer choice is the whole configuration: PostActionsDeclareIdempotencyIntent starts from map.OfLayer(Layer.Api) (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Rules/Cqrs/ArchitectureRules.Idempotency.cs:48), so pointing the Api layer at the test assembly is what substitutes the fixture controllers for the framework's real ones.
• Walkthrough - RepoToken => "MMCA.Common" (:54) and a one-entry DefineLayers() returning Framework(Layer.Api, typeof(IdempotencyFitnessTests).Assembly) (:56-:57). The root namespace the helper derives (MMCA.Common.API) is unused by this rule, which scans whole assemblies rather than namespace-scoped subsets.
• Where it's used - constructed once per fact in IdempotencyFitnessTests (:17,:28,:45).

LayerDependencyOverrideTests

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.Layering · MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/Layering/LayerDependencyOverrideTests.cs:18 · Level 5 · class

• What it is - six facts pinning the per-module escape on the map-completeness rule ModulesDeclareLayers: a thin module fails under the strict default, passes when the override names its own layers, and every other module stays strict while one is overridden.
• Depends on - ArchitectureRules (ModulesDeclareLayers in both overloads, LayerDependencyOverrideTests.cs:30,:43), its nested FakeArchitectureMap, LayerRef and the Layer enum.
• Concept introduced - why an escape hatch is per-module rather than a trimmed default. ModulesDeclareLayers is the rule that stops every other per-module layer rule from passing vacuously: it fails when a repo forgets to register a module's assembly in its map (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Rules/Layering/ArchitectureRules.Layers.cs:82-:88). That creates a real problem for a deliberately thin module, one that owns no aggregate and no persistence, so no Domain and no Infrastructure assembly exists to register. Before the override existed there was exactly one way to express that: trim the default list, which silently stops enforcing those layers for every other module in the repo. One thin module would buy blanket permission to forget an assembly anywhere (rule doc, :96-:104). The three-argument overload (:113) instead takes a per-module dictionary and replaces the required list for the modules it names, leaving everything else at the strict default (:131-:137). Naming the exception keeps the weakening exactly where it is true. [Rubric §3 - Clean Architecture] assesses whether layer boundaries are declared and enforced; [Rubric §34 - Architecture Governance & Documentation] is the mechanism, since the exception ends up written in code with a reason next to it rather than silently absent; [Rubric §14 - Testability] is why an override needs its own test at all, since an escape hatch that is too wide is indistinguishable from a disabled rule.
• Walkthrough - a static FiveLayers list (:20-:21) is the required set every fact starts from, and two helpers build maps from it: Full(module) yields all five layers, Thin(module) yields only Shared, Application and Api (:117-:121).
  • ModulesDeclareLayers_FailsForAThinModule_WhenEveryModuleIsHeldToTheFullList (:23-:34): the baseline, asserting the exact message "*module 'Notification' declares no Layer.Domain*" (:33).
  • ModulesDeclareLayers_PassesForAThinModule_WhenTheOverrideNamesItsOwnLayers (:36-:52): the same map with an override naming Notification's three real layers, asserted NotThrow.
  • ModulesDeclareLayers_KeepsEveryOtherModuleStrict_WhileOneIsOverridden (:54-:73): the load-bearing fact. Both modules are thin and only one is overridden, so the other must still fail (:71-:72). Its inline comment states the whole reason the override exists rather than a trimmed default list (:57-:58).
  • ModulesDeclareLayers_OverrideCanAlsoDemandMore_NotJustLess (:75-:92): overrides a full module with the five layers plus Layer.Ui and asserts it now fails (:87,:91). Pins that the override replaces rather than subtracts, so a repo can hold one module to a stricter bar than the rest.
  • ModulesDeclareLayers_TwoArgumentOverloadIsUnchanged (:94-:104) and ModulesDeclareLayers_NullOverrides_HoldEveryModuleToTheDefaultList (:106-:115): the two backward-compatibility facts, since the two-argument overload is what every current consumer calls (comment, :96-:98) and it forwards overrides: null (ArchitectureRules.Layers.cs:89-:90).
• Why it's built this way - the map is a fixture rather than any real repo's, because the point under test is the rule's arithmetic over module names and layers, not any particular assembly (class doc, :14-:16). Asserting on the exact message with WithMessage rather than on a bare throw is what pins which module and which layer got reported, which is the only part of the output a developer acts on.
• Where it's used - an independent class in the Common architecture suite. The rule it guards is called by LayerDependencyTestsBase (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Bases/Layering/LayerDependencyTestsBase.cs:57), which passes the subclass's ModuleRequiredLayerOverrides; MMCA.Common's own LayerDependencyTests declares no modules, so the rule is vacuous there and the consumers are the real users.

NamespaceCycleFitnessTests

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.Layering · MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/Layering/NamespaceCycleFitnessTests.cs:11 · Level 5 · class

• What it is - the meta-test for the namespace-acyclicity rule: three facts that prove it reports the two-namespace fixture cycle, leaves the acyclic fixture namespace out of the report, accepts the cycle when the allowance covers every namespace on it, and still fails when the allowance covers only part of it.
• Depends on - ArchitectureRules (ArchitectureRules.NamespacesHaveNoDependencyCycles, NamespaceCycleFitnessTests.cs:18), its nested CycleTestMap, the three fixture namespaces under CycleFixtures (LeftModelBase, LeftService, RightModel, AcyclicConsumer), and externals xUnit plus AwesomeAssertions.
• Concept introduced - why a cycle allowance must cover the whole component, not just a name on the path. The rule takes an optional allowedCycleNamespaces list and skips a cycle only when every namespace on it is listed (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Rules/Layering/ArchitectureRules.Cycles.cs:39-:44,:61). The reason is subtle and worth internalizing: if a partial allowance sufficed, a fourth namespace joining an already-accepted tangle would slip in silently, because the reported shortest path might not even mention it (:57-:60). The third fact in this class is the executable proof of exactly that policy. [Rubric §15 - Best Practices & Code Quality] and [Rubric §7 - Microservices Readiness] are the properties defended; [Rubric §34 - Architecture Governance & Documentation] covers the allowance mechanism, which forces an accepted tangle to be written down in code rather than tolerated in review.
• Walkthrough - a class constant FixtureRoot = "MMCA.Common.Architecture.Tests.CycleFixtures" (:13) is shared by the map and every assertion, so the namespace strings cannot drift apart.
  • Rule_FlagsTwoNamespaceCycle_ButNotAcyclicNamespaces (:15-:26): asserts the message contains both ...CycleFixtures.Left and ...CycleFixtures.Right (:21-:22) and not ...CycleFixtures.Acyclic (:23-:25), each with a because naming the edge that put it there.
  • Rule_Passes_WhenTheWholeCycleIsAllowed (:28-:36): passes both namespaces as the allowance and asserts NotThrow() (:31-:35). This is the only fact in the class where the rule does not throw.
  • Rule_StillFails_WhenOnlyPartOfTheCycleIsAllowed (:38-:46): passes only Left and asserts it still throws, with the reason stated inline as "a partial allowance must never hide a cycle" (:45).
• Why it's built this way - the allowance is the rule's only escape hatch, and an escape hatch that can be misused silently is worse than none. Proving both its accepting and its refusing behavior is what lets the framework's own NamespaceCycleTests carry a real three-namespace allowance without weakening the gate.
• Where it's used - an independent class in the Common architecture suite.

ProtoContractFitnessTests

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.Contracts · MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/Contracts/ProtoContractFitnessTests.cs:14 · Level 5 · class

• What it is - the meta-test for the frozen-.proto contract gate: five facts that prove a pinned proto matches its committed snapshot, that a renumbered field and an added rpc are both reported, that a missing file fails loudly, and that the parser ignores the lines that are not part of the wire contract.
• Depends on - ArchitectureRules (ProtoContractsMatchFrozenList, ProtoContractFitnessTests.cs:47, and BuildProtoContract, :93), ArchitectureMapBase (FindRepoRoot, :92), two fixture .proto files under TestData/, and externals xUnit plus AwesomeAssertions.
• Concept introduced - a wire contract as a committed, sorted string snapshot. A .proto file is a published contract: a renumbered field silently breaks every deployed peer, because protobuf keys on the number and not the name. The rule renders each file into a canonical, ordered list of lines (one per rpc with its streaming flag, one per message field with its label, type and NUMBER, one per enum value) and compares that list to a frozen array checked into the test (:28-:42). Regenerating the snapshot is a deliberate act: you print BuildProtoContract and paste the result, which is what makes a contract change a reviewable diff rather than a silent one. [Rubric §9 - API & Contract Design] assesses whether published contracts are versioned and change-controlled; this is the gRPC half of that discipline, and it is the same technique the integration-event contract snapshot uses (IntegrationEventContractTestsBaseTests proves that side). [Rubric §7 - Microservices Readiness] applies because these are exactly the contracts that survive extraction (ADR-007).
• Walkthrough - three constants locate the fixtures relative to the repo root: SolutionFileName = "MMCA.Common.slnx" (:16), the TestData directory (:18), and the pinned and drifted file arrays (:20,:22). The 12-line FrozenContract (:28-:42) is the snapshot, sorted so the comparison is order-independent for the author and deterministic for the diff.
  • Rule_PassesWhenTheProtoMatchesItsFrozenSnapshot (:44-:50): the positive case.
  • Rule_FlagsARenumberedField (:52-:64): asserts both sides of the change are reported, the new product_id = 7 line as unexpected (:58-:60) and the frozen product_id = 1 line as missing (:61-:63), which is what makes a renumbering legible in the failure output.
  • Rule_FlagsAnAddedRpc (:66-:74): asserts the added DeleteProduct rpc is named, because an addition peers have not been told about is still a contract change.
  • Rule_ReportsAMissingProtoFileExplicitly (:76-:87): a path typo must produce <missing proto file> does-not-exist.proto rather than silently pinning an empty contract, the classic way a snapshot gate rots into a no-op.
  • BuildProtoContract_IgnoresSyntaxImportAndOptionLines (:89-:98): resolves the repo root, builds the contract from the pinned file, and asserts it equals FrozenContract exactly and contains neither the csharp_namespace option nor the timestamp.proto import (:95-:97). Those lines are code-generation details, not wire contract, so churning them must not fail anyone's build.
• Why it's built this way - MMCA.Common ships no protos of its own, so this is the framework's only exercise of a consumer-facing rule (class doc, :9-:12); consumers subclass ProtoContractTestsBase. The two fixture files differ by exactly the two breaking changes under test (MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/TestData/fitness-catalog.proto versus fitness-catalog-drifted.proto), and the pinned one deliberately includes a nested message, a nested enum, a repeated field, an optional field, and a streaming rpc so the parser is exercised on every shape it claims to handle.
• Where it's used - an independent class in the Common architecture suite. Neither fixture proto is compiled by any project.

SortableColumnFitnessTests

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.Ui · MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/Ui/SortableColumnFitnessTests.cs:15 · Level 5 · class

• What it is - the meta-test for the MudDataGrid sortable-column rule: four facts proving it reports a sortable TemplateColumn with its file and line, catches the same defect written as a Razor expression, stays silent on every near-miss, and fails loudly on a missing scan root.
• Depends on - ArchitectureRules (SortableGridColumnsUsePropertyColumn, SortableColumnFitnessTests.cs:31), ArchitectureMapBase (FindRepoRoot, :18), four real .razor fixture files under RazorFixtures/, and Xunit.Sdk.XunitException (:2).
• Concept introduced - scanning markup text, and the near-misses that decide whether a text scan is usable. MudBlazor's server-side sort reads the bound property off a PropertyColumn; a TemplateColumn has no bound property, so marking one Sortable="true" produces a clickable header that sorts nothing, or sorts only the page's local slice. The failure is silent: the grid renders, the arrow toggles, and the order is wrong (rule doc, MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Rules/Ui/ArchitectureRules.Markup.cs:10-:15). The defect lives in markup that compiles perfectly, so this is the one rule in the suite that reads .razor text rather than IL or reflection (:16-:19). That choice imports every classic text-scanning hazard, and the rule addresses each one: the tag is read to its closing > through quoted attribute values, so attribute order, wrapped lines and a generic T="Foo<Bar>" argument all work (:22-:29); the Sortable value is matched quoted or unquoted, with or without an @ expression prefix and parentheses, while a value bound to a field is left alone because its value is not knowable from markup; and @* *@ comments are blanked with spaces before the scan, newlines preserved, so a commented example neither fails the gate nor shifts the reported line numbers (:31-:34,:82-:108). [Rubric §18 - UI Architecture] and [Rubric §23 - Front-End Performance] both apply, since server-side sorting is what keeps a grid from paging in memory; [Rubric §14 - Testability] is the technique.
• Walkthrough - FixtureRoot is built from ArchitectureMapBase.FindRepoRoot("MMCA.Common.slnx") plus the four path segments down to RazorFixtures (:17-:22), with Offending and Clean as expression-bodied properties over it (:24,:26).
  • SortableTemplateColumn_IsFlaggedWithFileAndLine (:28-:37): asserts the message contains SortableTemplateColumnGrid.razor:7. That exact number is the point: in the fixture the element opens on line 7 and the Sortable="true" attribute sits on line 8 (MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/RazorFixtures/Offending/SortableTemplateColumnGrid.razor:7-:9), and the rule must report where the element starts, not where the attribute happens to land.
  • ExpressionBoundLiteralTrue_IsAlsoFlagged (:39-:48): pins ExpressionSortableTemplateColumnGrid.razor:5, a one-line element with Sortable="@(true)" written first (RazorFixtures/Offending/ExpressionSortableTemplateColumnGrid.razor:5).
  • ConformingMarkup_Passes (:50-:57): the discrimination fact, and the one carrying the most fixture. ConformingGrid.razor packs seven near-misses into one file: a sortable PropertyColumn (:6), a TemplateColumn with no Sortable at all (:9), one explicitly Sortable="false" (:16), one bound to a field (:19), a longer attribute name IsSortable="true" (:22), a generic argument carrying an angle bracket inside a quoted value with a real sortable PropertyColumn on the line below it (:26-:27), and a longer element name TemplateColumnGroup (:30). CommentedOutGrid.razor holds the eighth: the whole defect inside a @* *@ block (:3-:9).
  • MissingRoot_FailsRatherThanScanningNothing (:59-:70): points the rule at a folder that does not exist and asserts the message contains "markup root not found" (:67), which is this rule's version of the non-vacuity floor. A path typo must fail the gate rather than quietly making it pass.
• Why it's built this way - the fixtures are real .razor files rather than inline strings because the rule takes directory roots and enumerates files itself, excluding bin and obj (ArchitectureRules.Markup.cs:71-:76); testing it through anything but the filesystem would be testing a different method. The generic-argument case (ConformingGrid.razor:24-:27) is the sharpest of the seven: its own comment records the failure being prevented, a tag scan that runs past the element and swallows the sortable PropertyColumn below it.
• Where it's used - an independent class in the Common architecture suite; the shipped consumer-facing binding of the rule is SortableColumnConventionTestsBase, which supplies the repo's real markup roots.
• Caveats / not-in-source - a Sortable value bound to a field or property is deliberately not judged, so a TemplateColumn whose binding evaluates to true at run time passes this gate. ConformingGrid.razor:19 is that shape, listed as conforming.

CascadeSoftDeleteFitnessTests

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.Domain · MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/Domain/CascadeSoftDeleteFitnessTests.cs:17 · Level 6 · class

• What it is - the meta-test for the cascade-soft-delete rule: six facts that pin both accepted cascade forms, both violation reasons with their named child collection, the out-of-scope aggregate, and both granularities of the exemption list.
• Depends on - ArchitectureRules (AggregatesCascadeSoftDeleteToChildren, CascadeSoftDeleteFitnessTests.cs:26), its nested FixtureAssemblyMap, the seven types in MMCA.Common.Architecture.Tests.CascadeFixtures (:1), and Xunit.Sdk.XunitException (:3).
• Concept introduced - a rule that reads IL cannot be verified by reading it. The class doc states the principle in those words (:7-:16), and it is the organizing idea behind this whole family of self-tests. AggregatesCascadeSoftDeleteToChildren decides its verdict from the instruction stream of a Delete() override, so no amount of reviewing the rule's source proves it distinguishes base.Delete() from child.Delete(). The only proof is to compile both shapes side by side and point a map at them. [Rubric §14 - Testability] is the technique; [Rubric §8 - Data Architecture] and [Rubric §30 - Compliance/Privacy/Data Governance] are the properties, taught at CascadeChildFixture.
• Walkthrough - a private const string FixtureNamespace (:19) and a readonly FixtureAssemblyMap (:21) are shared by every fact, and five of the six read the message of a rule call that always throws.
  • AggregateWithoutDeleteOverride_IsFlagged_WithItsChildCollection (:23-:33): asserts three things about one line, the type name, the reason "no Delete() override", and the collection name "_orphans" (:30-:32). Pinning the collection name is what makes the failure actionable rather than merely true.
  • DeleteOverrideThatOnlyDeletesItself_IsFlagged_WithItsChildCollection (:35-:45): the same three assertions for the other reason, "Delete() never deletes a child" and "_ignored". The two distinct reason strings are the rule distinguishing "you forgot" from "you tried and it does not work".
  • BothCascadeForms_AreAccepted (:47-:60): asserts both the helper form and the hand-rolled loop are absent, each with a because naming the form.
  • AggregateWithNoChildEntities_IsIgnored (:62-:71): the scope fact, with the ruling stated inline, a List<string> is not a child-entity collection.
  • AllowlistedType_SilencesOnlyThatType (:73-:85) and AllowlistedNamespace_SilencesTheRule (:87-:94): the two exemption granularities. The type-level fact carries the control assertion, that the other offender is still reported (:83-:84).
• Why it's built this way - two structurally identical offenders is what makes the type-level exemption fact meaningful; two distinct violation reasons is what keeps a regression in the body reader from hiding behind the simpler missing-override check. See ADR-005 and ADR-015.
• Where it's used - an independent class in the Common architecture suite; the shipped binding of the same rule over real code is CascadeSoftDeleteConventionTestsBase, activated here by CascadeSoftDeleteConventionTests and in both consumer repos over their own modules.

DependencyVersionTests

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.Governance · MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/Governance/DependencyVersionTests.cs:9 · Level 6 · class

• What it is - the MMCA.Common binding of the shared dependency-pin rule: a one-line sealed subclass that turns on the checks enforcing this repo's two commercial-license package ceilings, MassTransit below major 9 and SixLabors.ImageSharp below major 4.
• Depends on - DependencyVersionTestsBase (public sealed class DependencyVersionTests : DependencyVersionTestsBase;, DependencyVersionTests.cs:9), which in turn calls ArchitectureRules.PinnedPackageMajorBelow against this repo's Directory.Packages.props.
• Concept introduced - the thin-subclass fitness pattern. Almost every rule in this project lives once in the reusable MMCA.Common.Testing.Architecture package as an abstract *TestsBase, and each repo activates it with a near-empty subclass. This is the first of many such subclasses; the body-less form here is the extreme case (no configuration at all: the declaration ends at its semicolon, DependencyVersionTests.cs:9). [Rubric §32 - Dependency & Supply-Chain] assesses guarding against risky dependency drift; the base parses the pinned versions and fails the build before either ceiling is crossed, so a "just bump the version" edit cannot slip through.
• Walkthrough - no members; the entire behavior is inherited. The base contributes two [Fact]s. MassTransit_MustNotExceed_MajorVersion8 (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Bases/Governance/DependencyVersionTestsBase.cs:24-:37) walks the three MassTransit package ids MassTransit, MassTransit.RabbitMQ, and MassTransit.Azure.ServiceBus.Core (:17-:22) with an exclusiveMajorCeiling of 9, because v9 requires a commercial license (MT_LICENSE) and every broker-enabled host fails its startup license check without one, while CI never starts a broker so the build would otherwise stay green (:32-:35). ImageSharp_MustNotExceed_MajorVersion3 (:47-:60) does the same for SixLabors.ImageSharp (:45) with a ceiling of 4, because ImageSharp v4's MSBuild targets fail at build time without a $(SixLaborsLicenseKey) (:55-:58). Both id lists are protected virtual, so a repo that pins neither package can override them to an empty list and make the rule vacuous.
• Why it's built this way - the pins are real only in MMCA.Common (where these packages are actually declared); ADC and Store inherit MassTransit transitively through MMCA.Common.Infrastructure and deliberately do not subclass the base, because the default list would assert a Directory.Packages.props entry they do not declare (DependencyVersionTestsBase.cs:8-:13). See ADR-016, which records the lockstep-versioning policy and the license-ceiling pattern these two facts implement.
• Where it's used - run by the MMCA.Common.Architecture.Tests suite in CI's build-and-test job.
• Caveats / not-in-source - the class's own doc comment (DependencyVersionTests.cs:5-:8) still describes only the MassTransit trap; the ImageSharp ceiling arrived later on the base and the subclass doc was not extended. The behavior is the base's two facts, not the comment.

FixtureMap

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.Contracts · MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/Contracts/IntegrationEventContractTestsBaseTests.cs:124 · Level 6 · class

• What it is - a consumer-shaped map over this test assembly, declaring one module Shared layer, so the integration-event contract scan covers the fixture events here and none of the framework's own.
• Depends on - ArchitectureMapBase (private sealed class FixtureMap : ArchitectureMapBase, IntegrationEventContractTestsBaseTests.cs:124), LayerRef and the Layer enum.
• Concept - cross-references the module-versus-framework distinction taught at FixtureModuleMap and FakeConsumerMap. The single Module("Fixture", Layer.Shared, ...) entry (:130) does two things at once. It makes the map module-bearing, so IntegrationEvents excludes framework layers (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Rules/Contracts/ArchitectureRules.Events.cs:70-:73) and no framework-shipped event can leak into the contract the probes compare; and it names Shared, which is where a consumer's integration events are required to live, so the fixture events do not simultaneously trip the residency rule. RepoToken => "MMCA.FixtureRepo" (:126) is deliberately unlike MMCA.Common, so nothing derived from the token can collide with the real framework namespaces.
• Walkthrough - DefineLayers() is a yield-based iterator with one entry (:128-:131). The events it brings into scope are the eight upcaster fixture contracts, which are the only IIntegrationEvent implementations this assembly declares. That reuse is what makes the class doc's promise hold, that the mutation cases stay honest as the fixture types change (:9-:10): the baseline is rebuilt from live types on every call rather than hard-coded.
• Where it's used - built fresh by LiveContract() (:86-:87) on every mutation, and supplied as the Map of every ProbeTests instance (:136).

FolderWidthTests

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.Governance · MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/Governance/FolderWidthTests.cs:18 · Level 6 · class

• What it is - the MMCA.Common binding of the folder-width rule: a sealed subclass that points the shared rule at this repo's root and declares the three folders this repo keeps deliberately flat.
• Depends on - FolderWidthTestsBase (public sealed class FolderWidthTests : FolderWidthTestsBase, FolderWidthTests.cs:18) and ArchitectureMapBase for FindRepoRoot("MMCA.Common.slnx") (FolderWidthTests.cs:20), which walks upward until it finds the solution file so the test does not depend on the working directory.
• Concept - the same thin-subclass fitness pattern taught at DependencyVersionTests, here with configuration rather than none: the repo supplies RepoRoot and, because it has documented exceptions, ExemptFolderSuffixes. [Rubric §5 - Modularity & Structure] is the property. The rule enforces "feature by folder, use case by leaf": no folder under Source/ or Tests/ may hold more than MaxDirectFiles direct code units, defaulting to 12 (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Bases/Governance/FolderWidthTestsBase.cs:23), so a folder keeps naming a feature instead of drifting into a technical bucket (base doc, FolderWidthTestsBase.cs:3-:13).
• Walkthrough - two overrides and no facts of its own.
  • RepoRoot (FolderWidthTests.cs:20) is an initialized get-only property, so the upward search for MMCA.Common.slnx runs once per test instance.
  • ExemptFolderSuffixes (FolderWidthTests.cs:28-:33) returns three repo-relative suffixes: MMCA.Common.Application/UseCases/Decorators, MMCA.Common.Application.Tests/Decorators, and MMCA.Common.Domain/Interfaces. The doc above it (:22-:27) gives the reason for the first pair: the decorator pipeline is nine cross-cutting concerns times command and query, so splitting it by concern would yield nine two-file folders, and the test twin mirrors it. The third is the entity marker interfaces.
  • The single inherited [Fact], Folders_stay_narrow (FolderWidthTestsBase.cs:31-:33), delegates to ArchitectureRules.FoldersStayNarrow (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Rules/Governance/ArchitectureRules.FolderWidth.cs:34), which walks Source and Tests recursively (:42-:50), skips the tool-owned and build-output segments bin, obj, Migrations, Platforms, Resources, node_modules, wwwroot and .git (:82), and counts a .razor component and its co-located X.razor.cs code-behind as one unit (:105-:119).
• Why it's built this way - counting code units rather than files is what keeps the cap honest for a Blazor project, where a component is three files that describe one thing; skipping Migrations/ and Platforms/ is what keeps generated and SDK-owned trees from failing a rule about human-authored layout. Exemptions are folder-path suffixes rather than a blanket switch, so each accepted flat namespace is a line someone had to write and can be read back. See ADR-109 for the convention itself and ADR-015 for the fitness-function approach.
• Where it's used - run by the MMCA.Common.Architecture.Tests suite in CI. The same base is activated once per repo; the ADC binding is the identical shape with FindRepoRoot("MMCA.ADC.slnx") and no exemptions at all (MMCA.ADC/Tests/Architecture/MMCA.ADC.Architecture.Tests/Governance/FolderWidthTests.cs:10-:12).
• Caveats / not-in-source - the class-level doc comment (FolderWidthTests.cs:5-:17) describes a wider exemption set than the class configures, naming the application contracts, the shared auth contracts, the API startup extensions and the integration-test package root. The behavior is the three suffixes actually listed at :30-:32; the property's own doc (:22-:27) records the current rationale and points at UPGRADING.md.

IntegrationEventContractTestsBaseTests

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.Contracts · MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/Contracts/IntegrationEventContractTestsBaseTests.cs:13 · Level 6 · class

• What it is - the meta-test for the frozen integration-event contract base: six facts proving that a reordered member list is not a break, and that everything a consumer can actually observe (a missing member, an extra member, a retyped member, a missing event) still is.
• Depends on - IntegrationEventContractTestsBase (the type under test, through the nested ProbeTests), ArchitectureRules (BuildIntegrationEventContract, :87), its nested FixtureMap, and externals xUnit plus AwesomeAssertions.
• Concept introduced - a snapshot gate has to be insensitive to everything the wire is insensitive to, or it trains people to update it by rote. The base compares each event's member list as a SET rather than a sequence, and the reason is stated plainly in its own doc (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Bases/Contracts/IntegrationEventContractTestsBase.cs:10-:16): JSON carries no member order, so reordering two properties in a record declaration changes nothing a consumer can observe, and failing the build for it would teach a team to regenerate the one gate that guards real breakage without reading it. The comparison therefore reports four kinds of difference and no others: MISSING EVENT, NEW EVENT (:52-:56), and per event MISSING member, changed type and EXTRA member (:78-:96). The retype is reported as a retype rather than as an unrelated add and remove, because that is the failure a consumer actually sees: the property still deserializes, into the wrong shape (:64-:68). [Rubric §6 - CQRS & Event-Driven] and [Rubric §9 - API & Contract Design] are the properties; [Rubric §33 - Developer Experience] is the reason for the set comparison, since a gate that cries wolf stops being read.
• Walkthrough - the class never hard-codes an expected contract. It builds the live one from FixtureMap through LiveContract() (:86-:87) and then mutates it, so every case stays honest as the fixture types change (class doc, :8-:10).
  • Base_Passes_WhenTheCommittedLiteralsAreAlphabetical (:15-:23): the unmutated baseline, which is the shape every consumer's committed literal is written in today.
  • Base_Passes_WhenMembersAreListedInADifferentOrder (:25-:34): reverses each line's member list through ReverseMembers (:90-:94) and asserts NotThrow, with the because stating why order is not observable.
  • Base_Fails_WhenTheCodeDeclaresAMemberTheContractDoesNot (:36-:47) and Base_Fails_WhenTheContractDeclaresAMemberTheCodeDropped (:49-:60): drop the first member and append a GhostProperty:String, asserting "EXTRA member" and "MISSING member GhostProperty:String" respectively.
  • Base_Fails_WhenAMembersTypeChanges (:62-:74): rewrites the first member's type to Guid and asserts "changed type".
  • Base_Fails_WhenAnEventIsMissingFromTheSnapshot (:76-:83): drops the first line entirely and asserts "NEW EVENT", which is the direction that matters most, an event shipped without a consumer rollout.
  • MutateFirstMultiMemberEvent (:100-:109) is the helper that keeps all four failure cases robust: it finds the first event declaring more than one member and asserts that such an event exists (:104), so a fixture reshaped down to single-member events fails loudly instead of making the cases vacuous. Split (:111-:118) parses one line back into a name and a member array.
• Why it's built this way - deriving the expectations from the live contract and mutating them is what stops this meta-test from becoming a second snapshot that also needs maintaining. The probe subclasses are private so xUnit does not collect their inherited facts as tests of their own (class doc, :10-:11), the same discipline DriftedTests follows.
• Where it's used - an independent class in the Common architecture suite. The base it protects is subclassed per repo by the consumers, whose committed ExpectedContract literals are the real subject of the gate.
• Caveats / not-in-source - the base's Parse keeps a malformed committed line whole as an event with no members (IntegrationEventContractTestsBase.cs:99-:122) so it surfaces as a mismatch rather than being silently dropped. No fact here exercises that path.

LocalizationResourceTests

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.Ui · MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/Ui/LocalizationResourceTests.cs:12 · Level 6 · class

• What it is - the MMCA.Common binding of the resource-completeness rule: it asserts the framework's own .resx files fully translate every supported non-default culture, deriving the required-culture set from the live allowlist rather than restating it.
• Depends on - LocalizationResourceTestsBase (base rule, LocalizationResourceTests.cs:12) and SupportedCultures (source of the required cultures, :15).
• Concept introduced - deriving a gate's expectations from the same allowlist production uses. Instead of hardcoding "translate Spanish," the override computes RequiredCultures as SupportedCultures.All minus SupportedCultures.Default (:14-:17), so adding a locale to the app automatically extends the coverage requirement. [Rubric §27 - i18n] assesses whether localization is complete and enforced; this gate makes a missing translation a build failure and self-updates when the supported set grows.
• Walkthrough - two members. RequiredCultures (:14-:17) filters SupportedCultures.All to the non-default entries; the allowlist is [Default, "es"] with Default = "en-US" (MMCA.Common/Source/Core/MMCA.Common.Shared/Globalization/SupportedCultures.cs:12,:18), so the required set is today exactly es. MinimumBaseResources => 3 (:21) sets a non-vacuous floor: the scan must find at least three base resources (ErrorResources for the API, plus SharedResource and MudTranslations for the UI), so a wrong scan root or repo re-layout cannot let the gate pass having checked nothing. The base's default for that floor is zero, which skips the guard entirely (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Bases/Ui/LocalizationResourceTestsBase.cs:21), so overriding it here is what makes the gate honest. The single inherited [Fact] is Translations_AreComplete_ForEveryRequiredCulture (LocalizationResourceTestsBase.cs:23-:25).
• Why it's built this way - ADR-027 (localization) requires supported cultures to be fully translated; the derived allowlist plus the minimum-count floor turn that into a self-maintaining CI gate. The pseudo-locale qps-Ploc is deliberately kept out of SupportedCultures.All (SupportedCultures.cs:20-:28) precisely so this gate does not demand a .qps-Ploc.resx sibling.
• Where it's used - run by the MMCA.Common.Architecture.Tests suite.

NavigatingQuerySpec, ScalarOnlyQuerySpec

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.Domain · (see per-type table) · Level 6 · class

The same unsafe and safe pair as NavigatingSpec and ScalarOnlySpec, rebuilt one level further down the specification hierarchy as QuerySpecification<TEntity, TIdentifierType> subclasses. They exist to pin a single ruling: adding includes, ordering, and paging to a specification must not take it out of the navigation rule's reach.

• Depends on - QuerySpecification<TEntity, TIdentifierType> (both, SpecificationFitnessTests.cs:76,:89), FitnessDependent and FitnessPrincipal (the entities), and System.Linq.Expressions (:1).
• Concept introduced - walking the whole base chain instead of matching one type. The rule selects candidates with HasBaseTypeStartingWith("MMCA.Common.Domain.Specifications.Specification") (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Rules/Domain/ArchitectureRules.Specifications.cs:7,:33), and that helper climbs BaseType all the way up (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/RuleHelpers.cs:80-:91). Because QuerySpecification itself derives from Specification, the prefix still matches two levels down, and the string prefix match means both Specification and QuerySpecification are caught by the one condition. That is the kind of thing that is true today and could quietly stop being true after a refactor of the specification hierarchy, which is exactly why it gets its own fact rather than being left as an assumption. [Rubric §7 - Microservices Readiness] and [Rubric §8 - Data Architecture] are the underlying properties (a navigating predicate cannot cross a data-source boundary, ADR-006); [Rubric §14 - Testability] is why the pair exists.
• Walkthrough - both declare an explicit parameterless constructor, which is load-bearing: the rule instantiates candidates to read Criteria and skips any type without one (ArchitectureRules.Specifications.cs:37-:41). Each constructor also exercises a different part of the query surface, so the fixtures prove that the extra machinery does not interfere with the analysis.

• Why they're built this way - ScalarOnlyQuerySpec is the sharper of the two. Without it, a future rule implementation that (reasonably but wrongly) also inspected Includes would still pass every other fixture in the file. Both are declared public while their plain-Specification siblings are private, which makes no difference to the rule (it scans ConcreteClasses across the assembly, not by visibility).
• Where they're used - the two inputs to Rule_AlsoAnalyzesQuerySpecifications in SpecificationFitnessTests (:26-:38).

NavigatingSpec

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.Domain · MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/Domain/SpecificationFitnessTests.cs:63 · Level 6 · class

• What it is - the deliberately-unsafe fixture specification: its Criteria navigates from the dependent into a related entity, the exact pattern the fitness function must flag.
• Depends on - Specification<TEntity, TIdentifierType> (private sealed class NavigatingSpec : Specification<FitnessDependent, int>, SpecificationFitnessTests.cs:63) and FitnessDependent / FitnessPrincipal (the entities it filters over).
• Concept introduced - why cross-entity navigation in a specification is unsafe across data sources. Under database-per-service (ADR-006), a d => d.Principal!.IsActive predicate (:65) assumes the related entity lives in the same queryable model; once the principal is extracted to another physical source, that navigation cannot translate to SQL (and on Cosmos the cross-source navigation is degraded out of the model entirely, MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Rules/Domain/ArchitectureRules.Specifications.cs:9-:15). The fitness function SpecificationsDoNotNavigateToOtherEntities treats it as a violation and points at the fix: resolve the related keys first and filter on the foreign-key column instead. [Rubric §7 - Microservices Readiness] assesses whether the code stays extractable; this fixture is the negative example that proves the readiness guard fires.
• Walkthrough - one member, an overridden Criteria expression that dereferences the Principal navigation (:65). Being parameterless matters: the rule only instantiates and inspects specifications that expose a parameterless constructor (ArchitectureRules.Specifications.cs:37-:41), so a fixture with constructor dependencies would be skipped and prove nothing. The test asserts the rule's exception message contains this type's name.
• Where it's used - the "should be flagged" input to SpecificationFitnessTests; paired with ScalarOnlySpec.

PiiErasureContractFitnessTests

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.Governance · MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/Governance/PiiErasureContractFitnessTests.cs:19 · Level 6 · class

• What it is - a non-vacuous §30 fitness test that pushes a representative [Pii] data subject through the framework's own privacy machinery, proving that PII detection, redaction and masking, and in-place erasure compose end to end rather than each being verified in isolation.
• Depends on - DataSubjectSample (the fixture), PiiRedactor, IAnonymizable, and Result. Externals: xUnit [Fact], AwesomeAssertions.
• Concept introduced - a contract-composition fitness function. Where the plain [Pii] => IAnonymizable scan is structural (does every marked type also expose an erasure path), this test exercises the behavior the scan presumes. It is the pattern for proving a cross-cutting compliance contract actually holds when its parts run together. [Rubric §30 - Compliance/Privacy/Data Governance] assesses that erasure and log-masking genuinely protect subject data; this test is the framework's executable evidence.
• Walkthrough - four [Fact]s, each isolating one link in the contract. DataSubject_DeclaresPii_SoTheContractIsNotVacuous (:21-:24) asserts PiiRedactor.HasPii recognizes the sample, so the later guards assert against something real. PiiRedactor_MasksEveryPiiMember_AndPassesThroughNonPii (:26-:35) redacts an instance and checks Email and FullName become PiiRedactor.RedactedToken while Id and City pass through unchanged (:31-:34). PiiRedactor_LeaksNoClearTextPii_ToLogsOrTelemetry (:37-:50) verifies neither the redacted dictionary values (:42-:44) nor RedactToString output (:46-:49) contain the original email or name, covering both the structured-log and the flat-string rendering paths. The fourth fact (:52-:72) asserts the sample is IAnonymizable (:56), that Anonymize() succeeds and changes the PII fields (:59-:62), that a second call also succeeds and leaves the fields erased (idempotence, :64-:66, ADR-005), and finally that an anonymized subject still leaks no original clear text when redacted (:69-:71), proving erasure and redaction compose.
• Why it's built this way - the plain [Pii] => IAnonymizable scan is vacuous in the framework (no PII entity in Common's Domain); this test closes that gap by forcing the machinery through a stand-in subject, so the §30 guarantee is proven, not merely assumed. Consumers (MMCA.ADC's User) run the same contract against their real aggregates.
• Where it's used - an independent test class in the Common architecture suite; its structural counterpart is PiiConventionTests, whose own doc names this class as the non-vacuous half of the pair (MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/Governance/PiiConventionTests.cs:9-:11).

ProbeTests

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.Contracts · MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/Contracts/IntegrationEventContractTestsBaseTests.cs:134 · Level 6 · class

• What it is - a parameterized negative fixture: a private sealed subclass of the frozen-contract base whose ExpectedContract is whatever the enclosing test hands its constructor.
• Depends on - IntegrationEventContractTestsBase (private sealed class ProbeTests(IReadOnlyList<string> expected) : IntegrationEventContractTestsBase, IntegrationEventContractTestsBaseTests.cs:134) and FixtureMap (:136).
• Concept introduced - parameterizing the drift instead of hard-coding it. DriftedTests is the same technique with fixed wrong values, which works when a base has three assertions and each needs one wrong constant. Here the base has one assertion with six interesting failure modes, so a fixed drifted subclass would mean six near-identical nested classes. A primary-constructor parameter collapses them into one type instantiated six times with different data (:20,:30,:41,:54,:68,:79). The trade-off is worth naming: the parameterized form is only safe because the expected contract is derived from the live one and then mutated, so a probe can never assert against a stale hand-written literal.
• Walkthrough - two overrides, both initialized rather than computed: Map { get; } = new FixtureMap() (:136) and ExpectedContract { get; } = expected (:138). Being private keeps xUnit from collecting the inherited IntegrationEventContracts_ShouldMatch_TheFrozenSnapshot as a test of its own, and the enclosing facts invoke it as a delegate instead.
• Where it's used - constructed six times across the facts of IntegrationEventContractTestsBaseTests, once per contract mutation.

ScalarOnlySpec

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.Domain · MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/Domain/SpecificationFitnessTests.cs:69 · Level 6 · class

• What it is - the deliberately-safe counterpart to NavigatingSpec: its Criteria filters only on the entity's own scalar columns, the pattern the fitness function must leave alone.
• Depends on - Specification<TEntity, TIdentifierType> (private sealed class ScalarOnlySpec : Specification<FitnessDependent, int>, SpecificationFitnessTests.cs:69) and FitnessDependent.
• Concept introduced - cross-references the navigation-safety concept from NavigatingSpec; this is the positive example. A predicate over the entity's own scalars (d => d.PrincipalId == 1 && d.Flag, :71) translates to SQL on any engine and survives extraction, so the rule must not flag it. Having both a flagged and an un-flagged fixture is what makes the test prove the rule discriminates rather than just always throwing.
• Walkthrough - one overridden Criteria filtering on PrincipalId and Flag (:71). The test asserts the rule's exception message does not contain this type's name.
• Where it's used - the "should not be flagged" input to SpecificationFitnessTests.

SoftDeleteEnforcementFitnessTests

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.Domain · MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/Domain/SoftDeleteEnforcementFitnessTests.cs:15 · Level 6 · class

• What it is - the meta-test for the hard-delete rule: five facts proving EF's erasing members are caught by name and declaring type, that every erasing member in a type is reported rather than just the first, that an ordinary collection Remove is never mistaken for one, and that both allowlist granularities work.
• Depends on - ArchitectureRules (HardDeletesOnlyInAllowedTypes, SoftDeleteEnforcementFitnessTests.cs:24), its nested FixtureAssemblyMap, the four types in MMCA.Common.Architecture.Tests.HardDeleteFixtures (:1), and Xunit.Sdk.XunitException (:3).
• Concept - cross-references the hard-delete concept taught at FixtureEntity. The fact worth dwelling on is HardDelete_ReportsEveryErasingMember (:30-:40), which asserts all three method names Purge, PurgeMany and PurgeAsync appear in one message. A rule that stopped at the first hit per type would still pass every other fact in the class, and a partial report is worse than none in a codebase-wide sweep: a developer fixes the one named site, the build goes green on the next run only because the next offender is now first, and the sweep takes as many rounds as there are call sites. The rule's collector is a nested yield return over every method and every instruction (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Rules/Domain/ArchitectureRules.SoftDelete.cs:104-:118), and this fact is what pins that.
• Walkthrough - a private const string FixtureNamespace (:17) and a readonly FixtureAssemblyMap (:19) are shared by every fact.
  • HardDelete_OutsideTheAllowlist_IsFlagged (:21-:28): the baseline, asserted with WithMessage("*DbSetRemovingFixture*").
  • HardDelete_ReportsEveryErasingMember (:30-:40): the completeness fact described above, with a because naming which EF member each one maps to.
  • OrdinaryCollectionRemove_IsNotAHardDelete (:42-:51): the discrimination fact, asserting the whole SoftDeletingFixture type name is absent even though it contains a literal Remove call.
  • AllowlistedNamespace_SilencesTheRule (:53-:60) and AllowlistedType_SilencesOnlyThatType (:62-:74): the two granularities, the second carrying the control assertion that ExecuteDeletingFixture is still reported (:72-:73).
• Why it's built this way - the class doc names the principle again (:7-:14): a rule that reads IL cannot be verified by reading it, so the offending and the innocent call sites are compiled side by side and a map is pointed at them. See ADR-005 and ADR-015.
• Where it's used - an independent class in the Common architecture suite; the shipped binding of the same rule over real code is SoftDeleteEnforcementTestsBase, activated here by SoftDeleteEnforcementTests with the framework's four reviewed eraser types.

SpecificationFitnessTests

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.Domain · MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/Domain/SpecificationFitnessTests.cs:13 · Level 7 · class

• What it is - the test that verifies the SpecificationsDoNotNavigateToOtherEntities fitness function actually discriminates: it must flag a specification that navigates into another entity, must leave a scalar-only specification alone, and must reach both shapes through the QuerySpecification subclass as well.
• Depends on - ArchitectureRules (the rule under test), and its own nested fixtures SpecTestMap, FitnessDependent, FitnessPrincipal, NavigatingSpec, ScalarOnlySpec, and the two query variants (NavigatingQuerySpec, ScalarOnlyQuerySpec).
• Concept introduced - testing the test: verifying a fitness function is neither vacuous nor over-broad. A rule that never fires is useless; a rule that flags everything is worse. This class proves the specification-navigation guard does exactly one thing by feeding it both a positive and a negative fixture in a single run. [Rubric §14 - Testability] assesses whether the guardrails themselves are trustworthy; this is the meta-test that earns that trust, and ADR-015 is the decision that makes such guardrails build-gating in the first place. Compare ModuleConformanceTestsBaseTests, which applies the same discipline to the module-conformance base.
• Walkthrough - two [Fact]s, both driving the same single rule execution shape. Rule_FlagsNavigatingSpecification_ButNotScalarSpecification (:15-:24) wraps the rule call in an act delegate, ArchitectureRules.SpecificationsDoNotNavigateToOtherEntities(new SpecTestMap()) (:18), captures the thrown exception through Should().Throw<Exception>().Which (:20), and asserts its message contains NavigatingSpec and the word "navigates" while not containing ScalarOnlySpec (:21-:23). Both halves matter: the first two assertions prove the rule fires, the third proves it does not over-report. Rule_AlsoAnalyzesQuerySpecifications (:26-:38) repeats the pair one level down the hierarchy, asserting NavigatingQuerySpec is reported and ScalarOnlyQuerySpec is not (:32-:37). The nested types below the facts supply the model: SpecTestMap (:40), the two entities (:48,:57), and the four specifications (:63,:69,:76,:89).
• Why it's built this way - the navigation rule protects future extraction (a navigating specification cannot cross a data-source boundary, ADR-006); a discriminating test keeps the rule honest as it evolves, and the second fact keeps it honest as the specification hierarchy evolves.
• Where it's used - an independent class in the Common architecture suite.

SpecTestMap

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.Domain · MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/Domain/SpecificationFitnessTests.cs:40 · Level 7 · class

• What it is - a minimal architecture map used only by SpecificationFitnessTests: it registers this test assembly as the single Application layer so the specification-navigation rule has a model to scan.
• Depends on - ArchitectureMapBase (private sealed class SpecTestMap : ArchitectureMapBase, SpecificationFitnessTests.cs:40), the Layer enum, and LayerRef.
• Concept introduced - cross-references the map concept from CommonArchitectureMap. Where the real map spans seven packages, this one collapses to a single self-referential Application layer (Framework(Layer.Application, typeof(SpecificationFitnessTests).Assembly), :45) because the fixtures (the four specifications and two entities) live in the test assembly itself. It is the smallest map that lets a fitness function run against hand-crafted types; the rule scans Application and Domain layers for specification subclasses (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Rules/Domain/ArchitectureRules.Specifications.cs:30-:33), so one Application entry is enough.
• Walkthrough - RepoToken => "MMCA.Common" (:42) and a one-entry DefineLayers() (:44-:45) pointing at this assembly.
• Where it's used - instantiated once per fact inside SpecificationFitnessTests (:18,:29).

BadgeGranter, DirectSavingHandler, PointsWriter

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.DomainEventSaveFixtures · (see per-type table) · Level 8 · class

The three fixture types that actually call IUnitOfWork.SaveChangesAsync. Each is an internal sealed class with one injected IUnitOfWork, one constructor, and one method whose whole body is the save. They are the terminals of every call chain the domain-event handler save rule has to find.

• Depends on - IUnitOfWork (DomainEventSaveFixtures.cs:2), plus the handler interface and event for the one that is itself a handler.
• Concept - cross-references the handler-save concept from IBadgeGranter. What this trio pins is how the rule recognizes a save at all, which is broader than a single interface. IsSaveCall accepts a callee named SaveChanges or SaveChangesAsync (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Rules/Cqrs/ArchitectureRules.DomainEventHandlerSaves.cs:12) whose declaring type is either under the Microsoft.EntityFrameworkCore namespace prefix, or whose simple name ends with one of four suffixes: DbContext, DbContextFactory, UnitOfWork or Repository (:20-:21,:235-:255). Matching by suffix rather than by a full type name is what lets the rule see EF's own contexts, the framework's DbContextFactory save surface, a consumer's SQLServerDbContext, and any IRepository that forwards to one, without the rule package taking a compile dependency on any of them. These three fixtures all reach it through IUnitOfWork, the suffix case.
• Walkthrough - all three share the same shape: a private readonly IUnitOfWork _unitOfWork, an internal constructor assigning it, and one method returning or awaiting _unitOfWork.SaveChangesAsync(cancellationToken). What differs is where they sit in a chain.

• Why they're built this way - three different routes to the same terminal is the design. If all three saves were direct, the walk's traversal, its state-machine handling and its interface resolution would all be untested; if the direct one did not exist, nothing would prove that a save at depth zero is caught independently of the walk at all, which is the assertion the allowlist and depth-bound facts rest on.
• Where they're used - DirectSavingHandler is named by three facts of DomainEventHandlerSaveFitnessTests (:30,:92,:103); PointsWriter is asserted to appear in the reported chain (:43); BadgeGranter is reached transitively and is the reason InterfaceDispatchSavingHandler is reported at all.

PointsAwarder

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.DomainEventSaveFixtures · MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/DomainEventSaveFixtures/DomainEventSaveFixtures.cs:42 · Level 9 · class

• What it is - hop one of the transitive save chain: a service that saves nothing itself and delegates to PointsWriter, which does.
• Depends on - PointsWriter (constructor-injected, DomainEventSaveFixtures.cs:44,:46).
• Concept - cross-references IBadgeGranter. Its distinctive job is to be the middle of a chain, which is what makes it the natural subject of the allowlist-pruning fact. Allowlist entries in this rule do two things at once: a matching type is neither reported nor walked into (rule doc, MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Rules/Cqrs/ArchitectureRules.DomainEventHandlerSaves.cs:72-:74), because EnqueueTargets filters targets by the same allowlist before queueing them (:170-:172). Allowlisting a collaborator therefore stops the walk at that node and the handler behind it disappears from the report, while a handler that saves directly is unaffected because its save is found at the call site rather than through a target expansion. That distinction is exactly what one fact pins.
• Walkthrough - one field, one internal constructor, and internal async Task AwardAsync(CancellationToken cancellationToken) => await _writer.WriteAsync(cancellationToken).ConfigureAwait(false); (:48-:49). Being internal rather than public is irrelevant to the rule, which reads Cecil type definitions rather than reflected public surface.
• Where it's used - asserted to appear in the reported chain as the first hop (DomainEventHandlerSaveFitnessTests.cs:42), and used as the allowlist entry in AllowlistedCollaborator_PrunesTheWalkWithoutHidingDirectSaves (:81).

TransitiveSavingHandler

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.DomainEventSaveFixtures · MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/DomainEventSaveFixtures/DomainEventSaveFixtures.cs:31 · Level 10 · class

• What it is - the real-world offender shape: a handler that delegates to a service, which delegates to a writer, which saves. Two hops, both through async methods.
• Depends on - IDomainEventHandler<in TDomainEvent> closed over FixtureDomainEvent, and PointsAwarder (DomainEventSaveFixtures.cs:31,:33).
• Concept - cross-references IBadgeGranter. This is the fixture that forces the two hardest parts of the walk. First, both hops are async, so the calls the walk needs are not in the declared method bodies at all: the C# compiler moves them into generated state-machine types. The rule handles that by resolving each method's AsyncStateMachineAttribute to its generated type and reading that type's methods too (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Rules/Cqrs/ArchitectureRules.DomainEventHandlerSaves.cs:200-:231), then collapsing those generated types back onto their declaring type for the report so the printed chain reads like source (:265-:277). The fixture doc says exactly this (:26-:29): the walk must follow the compiler-generated state machines to see anything at all. Second, the walk is breadth-first with a visited set and a depth bound (:120-:158), which is what makes it cycle-safe and what makes the depth-bound fact possible.
• Walkthrough - one field, one internal constructor, and public async Task HandleAsync(...) => await _awarder.AwardAsync(cancellationToken).ConfigureAwait(false); (:37-:38). The reported chain for it names three nodes and the save: the handler, PointsAwarder, PointsWriter, and SaveChangesAsync.
• Where it's used - the subject of TransitiveSave_TwoHopsAway_IsFlagged (DomainEventHandlerSaveFitnessTests.cs:34-:45), which asserts all four names appear, and the control in both AllowlistedCollaborator_PrunesTheWalkWithoutHidingDirectSaves (:88-:90) and DepthBound_StopsTheWalk (:104-:106), where it must not appear.

DomainEventHandlerSaveFitnessTests

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.Cqrs · MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/Cqrs/DomainEventHandlerSaveFitnessTests.cs:17 · Level 11 · class

• What it is - the meta-test for the domain-event-handler save rule: seven facts pinning a direct save, a two-hop transitive save with its full chain, an interface call resolved to its implementation, a clean handler, both allowlist behaviors, and the depth bound.
• Depends on - ArchitectureRules (DomainEventHandlersDoNotSave, DomainEventHandlerSaveFitnessTests.cs:26), its nested FixtureAssemblyMap, the eight types in MMCA.Common.Architecture.Tests.DomainEventSaveFixtures (:1), and Xunit.Sdk.XunitException (:3).
• Concept introduced - a call-graph walk, and the three things a test of one has to pin. The rule is the most machinery-heavy in the suite: it reads every scannable assembly into Mono.Cecil, builds a CallGraphIndex over them, finds every type implementing the domain-event-handler interface, and breadth-first searches outward from each of its methods for a save, reporting the shortest chain it finds (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Rules/Cqrs/ArchitectureRules.DomainEventHandlerSaves.cs:93-:109,:125-:158). Three properties of such a walk need proof and none is visible by reading it. That it reaches far enough: the transitive fact. That it resolves indirection: the interface fact. That it stops: the depth-bound fact. The last is the one teams usually skip, and it matters twice over here, because maxCallDepth defaults to 6 (:79) and a walk with no bound over a real repo's assemblies would not terminate usefully. The reported chain is itself part of the contract, which is why the transitive fact asserts on every node rather than on the handler alone: a report that named only the handler would leave a developer to rediscover the path by hand. [Rubric §6 - CQRS & Event-Driven] is the property; [Rubric §12 - Performance & Scalability] is why the bound exists; [Rubric §14 - Testability] is the technique.
• Walkthrough - a private const string FixtureNamespace (:19) and a readonly FixtureAssemblyMap (:21) are shared by every fact.
  • DirectSave_InTheHandler_IsFlagged (:23-:32) and TransitiveSave_TwoHopsAway_IsFlagged (:34-:45): the two reach cases, the second asserting the handler, both hops and SaveChangesAsync all appear, each with a because naming what that node proves.
  • SaveBehindAnInterface_IsResolvedToItsImplementation (:47-:56): the indirection case.
  • HandlerThatOnlyMutates_IsNotFlagged (:58-:67): the discrimination case.
  • AllowlistedNamespace_SilencesTheRule (:69-:76): the whole fixture namespace exempted, asserted NotThrow, with the because naming the real use, a cascade a repo accepts while migrating.
  • AllowlistedCollaborator_PrunesTheWalkWithoutHidingDirectSaves (:78-:94): the sharpest fact in the class. Allowlisting PointsAwarder removes TransitiveSavingHandler from the report because the walk stops at the pruned node, and leaves DirectSavingHandler reported because a direct save is detected at the call site. Both halves are asserted, which is what distinguishes a working prune from a broken rule.
  • DepthBound_StopsTheWalk (:96-:107): calls the rule with maxCallDepth: 1 and asserts the direct save is still found while the two-hop save is not, with the because calling the bound the documented limit of the walk.
• Why it's built this way - every fixture shape maps to one branch of the walk, and the allowlist and depth facts each carry a control assertion so a rule that simply stopped working could not pass them. The rule exists because a handler that saves opens a second write inside the first: it re-enters the change tracker, can raise a fresh event cascade, and persists work the outer transaction may still roll back (rule doc, :23-:29). Handlers mutate state and let the owning unit of work flush it; anything needing an independent write belongs on the outbox (ADR-003).
• Where it's used - an independent class in the Common architecture suite; the shipped consumer-facing binding of the rule is DomainEventHandlerSaveTestsBase.

CommonArchitectureMap

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests · MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/CommonArchitectureMap.cs:15 · Level 12 · class

• What it is - the architecture map for the MMCA.Common framework: it names each package's layer and pins the layer to a concrete assembly, so the shared rule library knows which assembly is Shared, Domain, Application, and so on for this repo.
• Depends on - ArchitectureMapBase (internal sealed class CommonArchitectureMap : ArchitectureMapBase, CommonArchitectureMap.cs:15), the Layer enum, LayerRef, and one anchor type per package (Result, BaseEntity<>, DomainEventDispatcher, ApplicationDbContext, ApiControllerBase, ResultGrpcExtensions, UISharedAssemblyReference, :21-:27).
• Concept introduced - the map as the single point of repo-specific truth for architecture rules. The rule bodies live once in MMCA.Common.Testing.Architecture and are parameterized by an IArchitectureMap; each repo supplies exactly one map so the same rules run identically across Common, Store, and ADC. Because Common is a module-less framework, every layer is registered as a framework layer via the Framework(...) helper rather than a module layer, and that distinction is load-bearing well beyond bookkeeping: several rules branch on map.ModuleNames.Count to decide whether they are judging a framework or a consumer (see EventScopeFitnessTests), and several others read only the per-module accessors, which is why the self-tests for those use FixtureModuleMap instead of this one. [Rubric §3 - Clean Architecture] assesses whether layer boundaries are explicit and enforced; this map is the machine-readable statement of those boundaries.
• Walkthrough - RepoToken => "MMCA.Common" (:17) identifies the repo and is what the source-scanning rules use to locate the repo root (they look for {RepoToken}.slnx). DefineLayers() (:19-:28) returns one Framework(Layer.X, anchorType.Assembly) entry per package, using a single anchor type to resolve each assembly (mirrors the old PackageAssemblies helper): Shared, Domain, Application, Infrastructure, Api, Grpc, and Ui (:21-:27). The doc comment (:8-:13) records a deliberate omission: MMCA.Common.UI.Maui (ADR-042) is absent because its four MAUI TFM assemblies cannot load in the ubuntu net10.0 test process, so its UI-plus-Shared boundary is enforced at compile time by EnforceUIMauiLayerBoundary in Source/Build/MMCA.Common.LayerEnforcement.targets and the windows build-maui CI job instead.
• Why it's built this way - one map per repo keeps the rule bodies DRY and identical everywhere (see the "Architecture Enforcement" section in MMCA.Common/CLAUDE.md); anchoring by type keeps the assembly reference refactor-safe.
• Where it's used - supplied as Map by every thin *ConventionTests subclass in this unit, used directly by EventScopeFitnessTests as the module-less contrast case (EventScopeFitnessTests.cs:39), by EventUpcasterFitnessTests as the map that owns no upcasters (EventUpcasterFitnessTests.cs:51) and by DomainThrowFitnessTests as the framework's own ADR-013 reference run (DomainThrowFitnessTests.cs:131). It is also the pattern the single-layer fitness maps (SpecTestMap, IdempotencyTestMap, CancellationTestMap, CycleTestMap, FixtureAssemblyMap) collapse.

FrameworkSanityTests

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.Governance · MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/Governance/FrameworkSanityTests.cs:13 · Level 12 · class

• What it is - the home for the few architecture checks that are Common-only and do not generalize into the shared rule library: the MMCA.Common.Grpc transport boundary and the placement of the IMessageBus, IJwksProvider, and ILiveChannelPublisher abstractions.
• Depends on - IMessageBus, IJwksProvider, ILiveChannelPublisher, and the NetArchTest Types query API routed through ArchitectureAssert.
• Concept introduced - repo-specific sanity next to the shared library. Not every rule fits the parameterized base classes; some assert facts true only of the framework repo. Keeping them in one explicitly-named class documents the boundary between "shared rule applied here" and "Common-only invariant." [Rubric §7 - Microservices Readiness] (transport isolation) and [Rubric §3 - Clean Architecture] (abstraction placement) both apply: gRPC is pure transport and must not couple to Domain, Application, or Infrastructure, and the cross-cutting abstractions must sit in the layer their consumers depend on.
• Walkthrough - three private static Assembly accessors anchor the Grpc, Application, and Infrastructure assemblies by an anchor type each (:15-:19). Three [Fact]s assert MMCA.Common.Grpc has no dependency on Domain, Application, or Infrastructure (:21-:34) via the AssertNoDependency helper (:51-:59), which runs a Types.InAssembly(...).ShouldNot().HaveDependencyOnAny(...) NetArchTest query and routes the result through ArchitectureAssert.NoViolations (:58). Three more [Fact]s assert placement by comparing the abstraction's declaring assembly against the anchored layer assembly: IMessageBus lives in Application (:36-:39), IJwksProvider in Infrastructure because it handles crypto and PEM material (:41-:44), and ILiveChannelPublisher in Application beside IPushNotificationSender (:46-:49).
• Why it's built this way - the message-bus abstraction must stay in Application so application code depends on transport through it (extraction boundary, ADR-007); the JWKS provider is crypto and belongs in Infrastructure (ADR-004). These are load-bearing placements, so they get their own asserted facts.
• Where it's used - an independent class in the Common architecture suite; it has no counterpart in Store or ADC because only Common owns the Grpc package and defines these abstractions.

ModuleIsolationTestsBaseTests

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.Layering · MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/Layering/ModuleIsolationTestsBaseTests.cs:16 · Level 12 · class

• What it is - coverage of the module-isolation rule set itself, and in particular of the one rule that closes a gap the six named rules leave open: a module's Domain reaching another module's Application.
• Depends on - ArchitectureRules (seven isolation rules called by name, ModuleIsolationTestsBaseTests.cs:30,:42-:47,:65), its nested StubMap, and the framework's Infrastructure and Domain assemblies as the two real subjects (:25,:63).
• Concept introduced - a cross product beats a hand-written pair list, and a test can document why. The six named isolation rules cover Domain, Application, Infrastructure and Api each against their own layer in another module, plus Domain and Application against another module's Infrastructure (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Rules/Layering/ArchitectureRules.Modules.cs:7-:29). That leaves ten pairs unchecked, and one of them matters: a Sales.Domain -> Catalog.Application project reference passed every gate while compile-coupling two modules that ADR-007 and ADR-008 promise can be extracted separately. The per-module layer rules do not catch it because they forbid only the same module's higher layers, and the compile-time layer guard does not because it only knows MMCA.Common.* references (rule doc, :34-:41; class doc, :8-:14). ModuleInternalLayersAreIsolated (:47) closes it by iterating the full four-by-four product, with Layer.Ui deliberately excluded because a module's UI composing another module's UI is a real, intended arrangement in the shipped apps (:42-:45). MMCA.Common declares no modules, so every one of these rules is vacuous against the real map, which is exactly why a stub map is what makes the pairs assertable at all. [Rubric §7 - Microservices Readiness] is the property (ADR-059); [Rubric §34 - Architecture Governance & Documentation] is the second fact's contribution; [Rubric §14 - Testability] is the technique.
• Walkthrough - a static readonly StubMap named CrossLayerViolation (:21-:25) declares module "Beta" owning one Domain assembly, and names MMCA.Common.Application as another module's Application layer. The assembly it registers is the framework's Infrastructure assembly, which really does depend on that namespace, so the violation is genuine rather than simulated (comment, :18-:20).
  • ModuleInternalLayersAreIsolated_CatchesADomainReachingAnotherModulesApplication (:27-:33): asserts the cross-product rule throws.
  • TheSixNamedRules_DoNotCoverThatPair (:35-:54): the unusual one. It calls all six named rules against the same violating map and asserts each one does not throw. Its inline comment states the purpose (:38-:39): it documents exactly why the cross-product rule exists, and if one of the six ever does start covering the pair, this test says so and the new rule can be re-scoped. That is a test whose failure is a prompt to think rather than a defect report.
  • ModuleInternalLayersAreIsolated_IsSatisfiedWhenNothingCrossesAModuleBoundary (:56-:68): a second stub map naming a namespace nothing references, over the framework's Domain assembly, asserted NotThrow. The discrimination half.
• Why it's built this way - proving a gap requires asserting six negatives, which is only legible because they are listed as an array of Action and looped (:40-:53). Writing them as six separate facts would have buried the point. See ADR-015.
• Where it's used - an independent class in the Common architecture suite. The rules it covers are bound for real by ModuleIsolationTestsBase in the two module-bearing consumer repos; MMCA.Common has no modules, so it runs none of them outside this file.

DomainThrowFitnessTests

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests · MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/Domain/DomainThrowFitnessTests.cs:17 · Level 13 · class

• What it is - the meta-test for the domain-throw rule: nine facts pinning both offender kinds, the three permitted argument guards, the bare rethrow, the non-throwing control, the UNVERIFIABLE verdict, both allowlist granularities, and a final run of the rule against MMCA.Common's own Domain.
• Depends on - ArchitectureRules (DomainThrowsOnlyArgumentGuards, DomainThrowFitnessTests.cs:40), its nested FixtureAssemblyMap, CommonArchitectureMap (:131), the six types in MMCA.Common.Architecture.Tests.DomainThrowFixtures (:1), and Xunit.Sdk.XunitException (:3).
• Concept introduced - the allowlist doing its day job, in the test's own setup. Every other self-test in this assembly points its map at a namespace whose only inhabitants are its fixtures. This one cannot: the rule reads the whole Domain-layer assembly, and this assembly contains two throws that are not fixtures. NavigationContractTests guards its embedded resource with an InvalidOperationException, and the OpenAPI XML-comment source generator emits a transformer into every assembly that references the API layer. Both are allowlisted in a named static array with a doc comment explaining each (:21-:33), and the comment makes the wider point: generated plumbing is exactly what an allowlist is for. The first entry is a fully qualified type name, MMCA.Common.Architecture.Tests.Ui.NavigationContractTests (:31), so the allowlist tracks the test's folder: moving that class under Ui/ moved the string with it. Reading that array teaches more about how the escape hatch is meant to be used than any of the escape-hatch facts do. The final fact is a different kind of assertion again: MMCACommonDomain_HoldsOnlyArgumentGuards (:128-:135) runs the rule against the real CommonArchitectureMap with an empty allowlist and asserts NotThrow, with the because recording the fact that makes it interesting, that MMCA.Common's own Domain is the reference implementation of ADR-013 and its single throw is the ArgumentNullException guard in Specification.cs. That is the framework holding itself to the rule it exports, with no exemptions at all. [Rubric §4 - DDD] and [Rubric §15 - Best Practices & Code Quality] are the properties; [Rubric §34 - Architecture Governance & Documentation] covers the allowlist-with-reasons discipline; [Rubric §14 - Testability] is the technique.
• Walkthrough - a private const string FixtureNamespace (:19), the NonFixtureThrows array (:29-:33) and a readonly FixtureAssemblyMap (:35) are shared; every fixture fact passes NonFixtureThrows so the fixtures are the only subject.
  • BusinessException_IsFlagged (:37-:46): asserts both the owning type and the exception's full name System.InvalidOperationException appear (:44-:45). Naming the exception is what tells a developer which throw to convert.
  • CustomDomainException_IsAlsoFlagged (:48-:57): the custom-exception case.
  • ArgumentGuards_AreNotFlagged (:59-:68): the permitted-guard case, with a because listing all three exception types and stating why they are exempt, a caller bug rather than a business outcome.
  • BareRethrow_IsNotFlagged (:70-:79) and NonThrowingCode_IsNotFlagged (:81-:90): the two silent cases.
  • ThrowOfAValueBuiltElsewhere_IsReportedAsUnverifiable (:92-:101): asserts the literal "UNVERIFIABLE" and the owning method's type name, the same third-verdict discipline ErrorCatalogFitnessTests pins for the catalog rules.
  • AllowlistedNamespace_SilencesTheRule (:103-:112) and AllowlistedType_SilencesOnlyThatType (:114-:126): the two granularities, each built by spreading NonFixtureThrows and appending one entry, with the type-level fact carrying the control assertion that the other offender is still reported (:124-:125).
  • MMCACommonDomain_HoldsOnlyArgumentGuards (:128-:135): the self-application described above.
• Why it's built this way - nine facts for one rule is the highest count in the suite, and the reason is that this rule has the widest blast radius: it judges every throw in every Domain assembly of every repo that adopts it, so both its false positives and its blind spots are expensive. Asserting the exception's full name rather than just the type's is what makes the report usable. See ADR-013 and ADR-015.
• Where it's used - an independent class in the Common architecture suite; the shipped consumer-facing binding of the rule is DomainThrowTestsBase.
• Caveats / not-in-source - the Microsoft.AspNetCore.OpenApi.Generated allowlist entry (:32) silences a whole generated namespace. If the generator ever emitted a type a developer also wrote into that namespace, its throws would be silenced too; nothing in the class detects that. The sibling entry is a string, not a typeof, so renaming or relocating NavigationContractTests without editing :31 would quietly re-arm the rule against it.

EventScopeFitnessTests

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.Contracts · MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/Contracts/EventScopeFitnessTests.cs:13 · Level 13 · class

• What it is - the ownership-scoping guard for the integration-event rules: three facts pinning that a consumer-shaped map neither snapshots nor polices the framework's own events, while the framework's module-less map still covers them at the source.
• Depends on - ArchitectureRules (BuildIntegrationEventContract and IntegrationEventsResideInSharedIntegrationEventsNamespace, EventScopeFitnessTests.cs:18,:30), CommonArchitectureMap (:39), its own FakeConsumerMap, and BaseIntegrationEvent as the Domain-assembly anchor (:1,:56).
• Concept introduced - a rule's scope is part of its contract, and ownership decides it. Both event rules ask the same question of a map, and both answer differently depending on whether the map declares modules. IntegrationEvents includes framework layers only when map.ModuleNames.Count == 0 (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Rules/Contracts/ArchitectureRules.Events.cs:68-:73), and the residency rule enforces the Shared-layer requirement only when the map is module-bearing (:31,:33). The reasoning is ownership: a framework-shipped event is the framework's contract, gated by the framework's own conventions and public-API baseline, so a consumer's frozen snapshot must neither churn on it nor claim jurisdiction over where it lives. This class is a regression guard, and the class doc names the incident that motivated it (:6-:12): when the framework shipped its first concrete integration event, OutputCacheEvictionRequested, the Helpdesk canary broke. [Rubric §6 - CQRS & Event-Driven] assesses whether event contracts are governed; [Rubric §9 - API & Contract Design] covers the frozen-snapshot mechanism; [Rubric §33 - Developer Experience] is the failure mode being prevented, a framework release that reds every consumer's architecture suite for a change they did not make.
• Walkthrough
  • ModuleBearingMap_ExcludesFrameworkEvents_FromContractSnapshot (:15-:23): builds the contract from FakeConsumerMap and asserts no line mentions OutputCacheEvictionRequested.
  • ModuleBearingMap_PassesResidencyRule_DespiteFrameworkEvents (:26-:34): asserts the residency rule does not throw for the consumer map, even though the framework's Domain assembly hosts that event outside any Shared assembly (inline comment, :28-:29).
  • ModuleLessMap_StillCoversFrameworkEvents (:36-:44): the other half of the proof, using the real CommonArchitectureMap and asserting the same event is in the contract. Without this third fact the scoping change would be indistinguishable from simply having disabled the rule.
• Why it's built this way - a scoping fix is exactly the kind of change that silently over-corrects. Pinning both the exclusion and the retention, against a real framework event rather than a fixture one, is what keeps the fix from becoming a hole.
• Where it's used - an independent class in the Common architecture suite; the rules it scopes are bound for real by EventVersioningConventionTests here and by the per-repo IntegrationEventContractTestsBase subclasses in the consumers.

EventUpcasterFitnessTests

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.Contracts · MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/Contracts/EventUpcasterFitnessTests.cs:12 · Level 13 · class

• What it is - the meta-test for the two event-upcaster fitness rules: four facts proving the unique-source rule reports a contract claimed twice, that it leaves a legitimate chain alone, that the version rule reports an upcaster pointing at a lower SchemaVersion, and that both rules pass on a map owning no upcasters at all.
• Depends on - ArchitectureRules (EventUpcastersHaveUniqueSourceTypes and EventUpcastersIncreaseSchemaVersion, EventUpcasterFitnessTests.cs:53,:55,:61,:68), the fixture contracts and fixture upcasters (:1), its nested UpcasterTestMap, CommonArchitectureMap (:51), plus xUnit and AwesomeAssertions.
• Concept introduced - proving a rule is not vacuous when the framework itself has nothing to judge. MMCA.Common ships no upcaster of its own, so running either rule over the real CommonArchitectureMap proves only that it does not crash. That is a real property worth pinning (a rule that threw on an empty set would red every consumer that has not adopted upcasting yet), and the fourth fact pins exactly it. But the other three facts have to manufacture their subjects, which is what the UpcasterFixtures namespace and the private map are for. The pattern to take away: a fitness function for a consumer-facing convention is proven in the framework repo against fixtures, and only smoke-tested against the framework's own code. ProtoContractFitnessTests, CommandValidatorCoverageFitnessTests and ServiceContractPurityTests sit in the same position for their rules. [Rubric §6 - CQRS & Event-Driven] and [Rubric §9 - API & Contract Design] are the properties defended; [Rubric §14 - Testability] is the technique.
• Walkthrough - two private helpers each run one rule against a fresh UpcasterTestMap and return the thrown message: RunUniqueSourceRule (:59-:64) and RunSchemaVersionRule (:66-:71). Because the fixtures always contain an offender for each rule, both helpers can assert Should().Throw<Exception>().Which.Message unconditionally and let the facts make positive and negative Contain assertions against the one string.
  • UniqueSourceRule_FlagsTheContestedContract_ButNotTheCompliantLadder (:14-:25): asserts the message names the contested contract and both rival upcasters (:19-:21), which is what makes the failure actionable, and that the compliant first rung is absent (:22-:24).
  • UniqueSourceRule_DoesNotFlag_AnUpcasterWhoseSourceIsAnotherUpcastersTarget (:31-:33): the sharp one, given its own fact and its own doc comment (:27-:30). The compliant ladder's middle contract is both a target and a source; that is a chain, not a duplicate claim, and the rule must leave it alone.
  • SchemaVersionRule_FlagsTheBackwardsUpcaster_ButNotTheCompliantLadder (:35-:46): names the offender (:40) and, notably, pins the message text "must declare a HIGHER SchemaVersion" (:41-:43), because the wording is what tells a developer which direction is allowed. Both clean rungs are asserted absent (:44-:45).
  • BothRules_Pass_OnAMapThatOwnsNoUpcasters (:48-:57): runs both rules against the real framework map and asserts NotThrow, with the because stating that the framework ships no upcaster so the rule passes vacuously (:54).
• Why it's built this way - the two rules exist because an upcast chain that is not a function, or that runs backwards, produces a bug that only appears when an old outbox row is replayed, potentially long after the change that caused it (ADR-090, building on ADR-010). Catching it at build time is worth a fixture namespace.
• Where it's used - an independent class in the Common architecture suite. The shipped binding of both rules is EventConventionTestsBase, whose two facts call them for every repo (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Bases/Contracts/EventConventionTestsBase.cs:23,:26), and which MMCA.Common activates through EventVersioningConventionTests.

FakeConsumerMap

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.Contracts · MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/Contracts/EventScopeFitnessTests.cs:50 · Level 13 · class

• What it is - a consumer-shaped architecture map: the framework's Domain assembly registered as a framework layer plus one module layer, which is the minimum that makes a map module-bearing.
• Depends on - ArchitectureMapBase (private sealed class FakeConsumerMap : ArchitectureMapBase, EventScopeFitnessTests.cs:50), LayerRef, the Layer enum, and BaseIntegrationEvent as the anchor for the framework Domain assembly (:56).
• Concept introduced - the Module(...) factory, and what a single module entry changes. Every other map in this chapter uses only Framework(...), whose LayerRef.Module is the empty string (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/ArchitectureMapBase.cs:94-:95). Module(name, layer, assembly) sets it to the module name and derives the root namespace as {RepoToken}.{module}.{segment} (:98-:99), and ModuleNames is computed from exactly those non-empty entries (:27-:32). One module layer is therefore all it takes to flip a map from "framework" to "consumer" for every rule that branches on ownership. Building that shape from the framework's own assemblies, rather than referencing a real consumer, keeps the regression guard inside MMCA.Common's CI where it can run before a release.
• Walkthrough - RepoToken => "MMCA.FakeConsumer" (:52), deliberately not MMCA.Common, so the derived module namespace looks like a consumer's. DefineLayers() (:54-:58) is a yield-based iterator returning two entries: Framework(Layer.Domain, typeof(BaseIntegrationEvent).Assembly) (:56), which brings the framework's real integration event into the map, and Module("Fake", Layer.Shared, typeof(EventScopeFitnessTests).Assembly) (:57), a stand-in module Shared layer that ships no integration events of its own (class doc, :46-:49). That combination is the exact situation the guard exists for: a consumer whose map can see a framework event but does not own it.
• Where it's used - the input to the first two facts of EventScopeFitnessTests (:18,:31).
• Caveats / not-in-source - the class doc says the stand-in module Shared layer ships no integration events (:46-:49), but the assembly it points at is this whole test assembly, which does declare the eight upcaster fixture contracts. Those fixtures live in a *.IntegrationEvents namespace precisely so the residency fact still passes (EventUpcasterFixtures.cs:9-:13), and the contract fact only asserts the absence of the framework's event, so neither fact is affected. The doc comment is narrower than the code.

NamespaceCycleTests

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.Layering · MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/Layering/NamespaceCycleTests.cs:9 · Level 13 · class

• What it is - the MMCA.Common binding of the namespace-acyclicity rule: a thin subclass that supplies the repo's map and then spends twenty-nine lines arguing, edge by edge, for the one namespace cycle the framework accepts.
• Depends on - NamespaceCycleTestsBase (public sealed class NamespaceCycleTests : NamespaceCycleTestsBase, NamespaceCycleTests.cs:9) and CommonArchitectureMap (:11); the rule body and its fact counts live in the base, and the rule's behavior is proven against fixtures by NamespaceCycleFitnessTests.
• Concept introduced - an allowlist that must name a whole strongly connected component, not an edge. A cycle-breaking exemption is the easiest place in an architecture suite to hide a design failure, so this override is written to make hiding expensive. AllowedCycleNamespaces lists three namespaces, not three edges, because the allowance covers the entire SCC: a fourth namespace joining the tangle changes the component and still fails the test (:37-:38). And the justification sits in the compiled file next to the list, so a diff that adds a fourth entry is a diff that has to argue against three paragraphs. [Rubric §15 - Best Practices & Code Quality] is the property being defended; [Rubric §34 - Architecture Governance & Documentation] is the escape-hatch-with-reasons discipline (ADR-015).
• Walkthrough - two members. Map (:11) is the usual override. AllowedCycleNamespaces (:42-:47) returns MMCA.Common.Infrastructure, MMCA.Common.Infrastructure.Persistence and MMCA.Common.Infrastructure.Messaging (:44-:46), the accepted root -> Messaging -> Persistence -> root tangle inside a single assembly and a single package (:14-:16). Its doc comment (:13-:41) takes the three edges one at a time:
  • root -> Messaging (:19-:20): DependencyInjection lives in the root namespace and binds the buses and their settings, which is what a composition root is for.
  • Messaging -> Persistence (:23-:27): the buses are the outbox transport. InProcessEventBus and BrokerEventBus enqueue OutboxMessage rows and wake the OutboxProcessor through IOutboxSignal, the consumers resolve the physical source through IDataSourceResolver, and the outbox reports through BrokerMetrics and reads MessageBusSettings. Splitting the two would put half of one delivery guarantee on each side of a package boundary.
  • Persistence -> root (:30-:34): the EntityTypeConfiguration* shims carry [UseDataSource] and [UseDatabase], marker attributes that stay in the root namespace because consumers annotate their own configurations with them. Pushing them down into Persistence would deepen the public annotation surface for every consumer in order to fix an internal graph edge.
• Why it's built this way - a comment closes with the history of the exemption itself (:38-:40): before the 2026-09 feature-by-folder reorganization the third node was MMCA.Common.Infrastructure.Settings, that folder dissolved into the features it configured, and TenancySettingsValidator, which carried the old Settings -> Persistence edge, now lives under Persistence/Tenancy. The list moved because the code moved, which is the argument for keeping the allowlist in a compiled file rather than a wiki page nobody re-reads.
• Where it's used - run by the MMCA.Common.Architecture.Tests suite in CI's build-and-test job (fast, no database). Store and ADC subclass the same base with their own maps and their own allowlists.

ServiceContractPurityTests

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.Layering · MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/Layering/ServiceContractPurityTests.cs:11 · Level 13 · class

• What it is - the MMCA.Common binding of the [ServiceContract] purity rule: a two-line subclass that supplies the repo's map so any type marked as part of a published wire surface is checked for dependencies on the producing service's Domain, Application or Infrastructure.
• Depends on - ServiceContractPurityTestsBase (public sealed class ServiceContractPurityTests : ServiceContractPurityTestsBase, ServiceContractPurityTests.cs:11), IArchitectureMap and CommonArchitectureMap (the single override, :13), and indirectly ServiceContractAttribute, which the rule matches by full name rather than by reference.
• Concept introduced - a rule that is deliberately vacuous today, kept as a ratchet. Most gates in this chapter earn their place by failing on real code. This one asserts nothing in MMCA.Common, because the framework marks no type with [ServiceContract], and both the subclass doc (:9-:10) and the base's remarks (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Bases/Layering/ServiceContractPurityTestsBase.cs:12-:17) say so plainly. The value is in the timing, the same argument the three ratchet subclasses rest on: the invariant is enforced from the first marked type onward, with no test for anyone to remember to write, at the moment when a contract package's shape is still cheap to change. Two design choices follow from that. It is attribute-driven rather than Layer.Contracts-driven, because no repo registers that layer today and a layer-iterating rule would pass vacuously forever (base remarks, :9-:11); and it scans every assembly the map registers, so a marked type is judged wherever it lives. A marked type sitting inside a Domain, Application or Infrastructure assembly then fails by construction, which the rule's own remarks call the intent: a published contract belongs in a *.Contracts or Shared assembly, not inside the service it describes (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Rules/Contracts/ArchitectureRules.Contracts.cs:26-:29). [Rubric §7 - Microservices Readiness] is the property: a contract that leaks a domain entity, a handler abstraction or a persistence type forces every consumer to take the producer's internals as a package dependency, which is what makes an extraction irreversible (:16-:18). [Rubric §9 - API & Contract Design] covers the wire surface itself, and [Rubric §34 - Architecture Governance & Documentation] the ratchet.
• Walkthrough - one member, protected override IArchitectureMap Map { get; } = new CommonArchitectureMap(); (:13). Everything else is inherited: the base contributes a single [Fact], ServiceContracts_ShouldNotDependOn_ServiceInternals (ServiceContractPurityTestsBase.cs:24-:26), which calls ArchitectureRules.ServiceContractsDoNotDependOnServiceInternals(Map). The rule first derives the forbidden namespace set from the map's Domain, Application and Infrastructure layers (ArchitectureRules.Contracts.cs:57-:66) and returns immediately when that set is empty (:35-:38), then walks every layer, selects marked types through the Mono.Cecil custom rule CarriesServiceContractAttribute (:44,:69-:74), and asserts ShouldNot().HaveDependencyOnAny(forbidden) per layer with the layer's root namespace in the message (:42-:52).
• Why it's built this way - matching the marker by its full-name string, "MMCA.Common.Shared.Abstractions.ServiceContractAttribute" (ArchitectureRules.Contracts.cs:10-:11), is the same zero-reference idiom the rest of the rule library uses: the testing package deliberately takes no compile dependency on the framework assemblies it inspects. The rule complements, and does not replace, the transport- and layer-purity rules that guard the same boundary from the layer side (ADR-007, ADR-015).
• Where it's used - run by the MMCA.Common.Architecture.Tests suite in CI's build-and-test job. Its siblings in this chapter are ProtoContractFitnessTests and ContractImplementationTests, the other consumer-facing contract gates the framework exercises without owning any subject of its own.
• Caveats / not-in-source - because the framework marks no type, this class asserts nothing today; there is no fixture proving the rule fires. That proof exists only in whichever repo first marks a type.

SoftDeleteEnforcementTests

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.Domain · MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/Domain/SoftDeleteEnforcementTests.cs:19 · Level 13 · class

• What it is - the MMCA.Common binding of the hard-delete rule, and the one thin subclass in this unit whose override is a substantial, individually-argued document: the four framework types that are allowed to erase rows, each with the reason written next to it.
• Depends on - SoftDeleteEnforcementTestsBase (public sealed class SoftDeleteEnforcementTests : SoftDeleteEnforcementTestsBase, SoftDeleteEnforcementTests.cs:19) and CommonArchitectureMap (:21).
• Concept introduced - the rule turned back on its own author, and why that keeps a downstream allowlist honest. Store and ADC subclass the same base and allowlist exactly these four framework types, because no module of theirs erases a row of its own. Running the rule here is what keeps that list correct: a NEW framework eraser would otherwise land in the packages and fail downstream, in a repo whose maintainers did not write it and cannot judge it, rather than in the repo where the change was made (class doc, :10-:17). The second decision in that doc is finer: each entry is named individually rather than exempting the MMCA.Common.Infrastructure.Persistence namespace, so a fifth eraser under that namespace still fails here and gets reviewed. A namespace exemption would have been two characters shorter and would have silently pre-approved every future eraser in the framework's persistence layer. [Rubric §8 - Data Architecture] and [Rubric §30 - Compliance/Privacy/Data Governance] are the properties (ADR-005); [Rubric §34 - Architecture Governance & Documentation] is the allowlist-with-reasons discipline; [Rubric §33 - Developer Experience] is the failure-location argument.
• Walkthrough - two members. Map (:21) is the usual override. AllowedHardDeleteTypes (:24-:47) is the substance, four fully-qualified entries each preceded by its justification:
  • EFRepository<TEntity, TIdentifierType> (:31, listed by its arity-suffixed metadata name under MMCA.Common.Infrastructure.Persistence.Repositories), the framework's set-based delete escape hatch. The comment states the calling convention that makes it acceptable (:26-:30): erasing is the caller's explicit ask (the method is named ExecuteDeleteAsync), and it targets derived rows the caller is about to rewrite, never user data carrying an audit or erasure obligation. Allowlisting the implementation rather than the abstraction is what leaves IRepository free to be used everywhere else.
  • OutboxCleanupService (:36, now under ...Persistence.Outbox.Administration), for PurgeAsync, PurgeInboxAsync and SweepDeadLettersAsync. These rows are delivery plumbing with a bounded lifetime, and the sweep is the retention policy; soft-deleting them would grow the table the job exists to bound (:33-:35).
  • AuditTrailCleanupJob (:40), for audit-trail retention. The comment inverts the usual instinct (:38-:39): erasing past the retention window IS the requirement, and keeping an audit row forever is the privacy defect rather than the safeguard.
  • RefreshSessionCleanupService (:46), for refresh-session retention. A session row is framework bookkeeping rather than an aggregate: it carries no IsDeleted flag and no audit stamps, and its content is a credential digest plus the IP and user-agent of a device, so flagging it instead of erasing it would keep a growing record of a data subject's devices past any use for it (:42-:45).
• Why it's built this way - because the entries are fully-qualified type names, a namespace move is a test failure until the list is updated: the 2026-09 folder reorganization that put the outbox cleanup job under Outbox/Administration had to be reflected here (:36). Four reasons written in a compiled file are also four reasons that get read in a diff when someone adds a fifth. That is the whole argument for an allowlist over a suppression: the list is where the erasure policy actually lives. See ADR-005 and ADR-015; the rule's own behavior is proven against compiled fixtures by SoftDeleteEnforcementFitnessTests.
• Where it's used - run by the MMCA.Common.Architecture.Tests suite in CI's build-and-test job. The same four entries appear in the Store and ADC subclasses of the same base (MMCA.ADC/Tests/Architecture/MMCA.ADC.Architecture.Tests/Domain/SoftDeleteEnforcementTests.cs).

UIArchitectureConventionTests

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.Ui · MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/Ui/UIArchitectureConventionTests.cs:11 · Level 13 · class

• What it is - the framework repo's binding of the shared UI-architecture fitness rules: a three-line sealed subclass that supplies the map and inherits both [Fact]s, so MMCA.Common's own shared pages and primitives are held to the code-behind and inline-@code caps.
• Depends on - UIArchitectureConventionTestsBase (public sealed class UIArchitectureConventionTests : UIArchitectureConventionTestsBase, UIArchitectureConventionTests.cs:11), CommonArchitectureMap and the IArchitectureMap abstraction it satisfies (UIArchitectureConventionTests.cs:13).
• Concept - cross-references the base-plus-thin-subclass shape of the shared fitness bases (see CancellationTokenConventionTestsBase and AggregateConventionTestsBase for the same arrangement): the rule is authored once in MMCA.Common.Testing.Architecture and re-run per repo by a subclass whose only job is to name the repo. [Rubric §18] is the category the rule's own doc comment cites (UIArchitectureConventionTests.cs:6): it asks whether the container/presentational split is actually held, and this class is the mechanical answer for the framework repo. The caps are convention rather than measurement, so the base marks them virtual and the doc comment says they should move only with a recorded decision (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Bases/Ui/UIArchitectureConventionTestsBase.cs:11-:12); this subclass overrides none of them.
• Walkthrough - one member: protected override IArchitectureMap Map { get; } = new CommonArchitectureMap(); (UIArchitectureConventionTests.cs:13). Everything else is inherited. The map is the only thing the base needs from a repo: it takes Map.RepoToken, finds the repo root by walking up to {RepoToken}.slnx, and scans that repo's Source/ tree (UIArchitectureConventionTestsBase.cs:89, :91-:92), skipping obj/ and bin/ plus any ExcludedPathFragments (:97-:99, empty here since the subclass does not override :41). The two inherited facts then run: CodeBehinds_StayWithinTheLineCap globs *.razor.cs and fails any file over MaxCodeBehindLines = 400 (:44, :46, :22), first asserting at least MinimumCodeBehindFiles = 1 file was discovered so a glob that matched nothing cannot pass vacuously (:35); RazorFiles_KeepInlineCodeBlocksSmall globs *.razor, measures each file's inline block from the first line starting with @code to end of file, and fails anything over MaxInlineCodeLines = 120 (:63, :65, :29).
• Why it's built this way - the caps catch the failure mode directly (a ballooning code-behind is the visible symptom of page logic that belongs in an injected UI service or an extracted sub-component, UIArchitectureConventionTestsBase.cs:5-:10), and putting them in CI makes the split enforced rather than review-enforced. Measuring the @code block as "the tail of the file" is a deliberate convention shortcut (:24-:27) rather than a Razor parse.
• Where it's used - discovered and run by xUnit as part of MMCA.Common.Architecture.Tests; nothing constructs it. Its two sibling bindings are the identical subclasses in the consumer repos, MMCA.ADC/Tests/Architecture/MMCA.ADC.Architecture.Tests/Ui/UIArchitectureConventionTests.cs:10 (map: AdcArchitectureMap) and MMCA.Store/Tests/Architecture/MMCA.Store.Architecture.Tests/Ui/UIArchitectureConventionTests.cs:9 (map: StoreArchitectureMap), neither of which overrides a cap either.

UpcasterTestMap

MMCA.Common.Architecture.Tests · MMCA.Common.Architecture.Tests.Contracts · MMCA.Common/Tests/Architecture/MMCA.Common.Architecture.Tests/Contracts/EventUpcasterFitnessTests.cs:74 · Level 13 · class

• What it is - a one-layer architecture map used only by EventUpcasterFitnessTests: it registers this test assembly as the map's single Application layer so the two upcaster rules see the fixture upcasters and nothing else.
• Depends on - ArchitectureMapBase (private sealed class UpcasterTestMap : ArchitectureMapBase, EventUpcasterFitnessTests.cs:74), LayerRef, and the Layer enum.
• Concept - cross-references the map concept from CommonArchitectureMap, with one detail specific to these rules. Both of them scope by ownership exactly as the integration-event rules do: EventUpcasters includes framework layers only when the map declares no modules (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Rules/Contracts/ArchitectureRules.Upcasters.cs:62-:64). Because this map is built entirely from Framework(...) entries, ModuleNames is empty and the single Application layer is scanned, which is what puts the fixtures in scope. Registering a module layer instead would silently exclude them and both rules would pass vacuously, so the choice is load-bearing rather than incidental. Compare FakeConsumerMap and FixtureModuleMap, which flip exactly that switch on purpose for rules that scope the other way.
• Walkthrough - RepoToken => "MMCA.Common" (:76) and a one-entry DefineLayers() returning Framework(Layer.Application, typeof(EventUpcasterFitnessTests).Assembly) (:78-:79). The doc comment states the intent in one line (:73). The layer's derived root namespace is unused by these rules, which enumerate ConcreteClasses across whole assemblies (ArchitectureRules.Upcasters.cs:67) rather than namespace-scoped subsets.
• Where it's used - constructed on every call of the test class's two private rule helpers (EventUpcasterFitnessTests.cs:61,:68).

CrossServiceDataSource

MMCA.Common.Testing · MMCA.Common.Testing.Fixtures · MMCA.Common/Source/Hosting/MMCA.Common.Testing/Fixtures/CrossServiceFixtureBase.cs:15 · Level 0 · sealed record

• What it is: a two-field record naming one logical data source a cross-service fixture routes to its own physical database: the logical name the framework's DataSources configuration section keys on (normally the module name) and the database that name resolves to on the shared SQL Server container (MMCA.Common/Source/Hosting/MMCA.Common.Testing/Fixtures/CrossServiceFixtureBase.cs:8-15).
• Depends on: nothing. A positional sealed record of two strings, declared above CrossServiceFixtureBase in the same file.
• Concept: it is the declarative half of database-per-service (ADR-006, taught in primer §2) expressed as test data. The doc's own examples are the shape to hold onto: LogicalName is Conference, DatabaseName is ADC_Conference (MMCA.Common/Source/Hosting/MMCA.Common.Testing/Fixtures/CrossServiceFixtureBase.cs:13-14). [Rubric §8, Data Architecture] assesses whether each service owns its own store; this record is how a test fixture states that ownership once and derives everything else from it.
• Walkthrough: two positional members, LogicalName and DatabaseName (MMCA.Common/Source/Hosting/MMCA.Common.Testing/Fixtures/CrossServiceFixtureBase.cs:15), so it gets structural equality and immutability for free. The base consumes each instance three ways: the database name drives the pre-create loop (CrossServiceFixtureBase.cs:213), and the logical name drives both environment keys SetNamedDataSource pushes, DataSources__{LogicalName}__SQLServerConnectionString and DataSources__{LogicalName}__SQLServerMigrationsAssembly (CrossServiceFixtureBase.cs:272-275).
• Where it's used: as the DataSources list a subclass supplies (CrossServiceFixtureBase.cs:60); ADC declares three, Identity, Conference and Engagement (MMCA.ADC/Tests/Integration/MMCA.ADC.CrossService.IntegrationTests/Infrastructure/CrossServiceFixture.cs:62-67), and Store declares two, Catalog and Sales (MMCA.Store/Tests/Integration/MMCA.Store.CrossService.IntegrationTests/Infrastructure/CrossServiceFixture.cs:56-60).

DependencyInjectionAssert

MMCA.Common.Testing · MMCA.Common.Testing.Support · MMCA.Common/Source/Hosting/MMCA.Common.Testing/Support/DependencyInjectionAssert.cs:13 · Level 0 · class (static)

• What it is: a one-method assertion helper for the DI registration extensions every module and layer exposes. It proves a registration extension hands back the very IServiceCollection it was given, so a fluent chain stays intact.
• Depends on: AwesomeAssertions and Microsoft.Extensions.DependencyInjection (MMCA.Common/Source/Hosting/MMCA.Common.Testing/Support/DependencyInjectionAssert.cs:1-2). No first-party dependency.
• Concept introduced, the fluent-contract guard. The framework's registration methods are fluent by convention: hosts chain AddApplication().AddInfrastructure(...).AddAPI(...). An extension that returns a new collection silently drops every registration chained after it, and no other test catches that, because the dropped services are simply absent rather than wrong (MMCA.Common/Source/Hosting/MMCA.Common.Testing/Support/DependencyInjectionAssert.cs:6-11). [Rubric §14, Testability] assesses whether an invariant can be checked cheaply; this one turns an otherwise invisible composition failure into a one-line test. [Rubric §15, Best Practices & Code Quality] covers the convention itself: the return-the-same-collection contract is what lets host composition stay declarative.
• Walkthrough
  • ReturnsSameCollection(Func<IServiceCollection, IServiceCollection> register) (MMCA.Common/Source/Hosting/MMCA.Common.Testing/Support/DependencyInjectionAssert.cs:21-32): null-guards the delegate (:23), creates the ServiceCollection itself so the call site stays one line (:25, the doc shows the shape at :16-18), invokes the registration under test (:27), and asserts result.Should().BeSameAs(services, ...) with a because-reason that spells out the consequence of failing (:29-31).
  • Reference equality is the whole assertion. It deliberately says nothing about what was registered; the per-module tests that call it assert their own service descriptors separately.
• Why it's built this way: creating the collection inside the helper is what keeps adoption free. A module's DI test adds one line per registration extension rather than three lines of arrange plus an assertion nobody remembers to write.
• Where it's used: seven module DI test classes across the two apps, for example MMCA.Store/Tests/Modules/Sales/MMCA.Store.Sales.Infrastructure.Tests/DependencyInjectionTests.cs:29, MMCA.Store/Tests/Modules/Sales/MMCA.Store.Sales.API.Tests/DependencyInjectionTests.cs:63,68, MMCA.Store/Tests/Modules/Catalog/MMCA.Store.Catalog.API.Tests/DependencyInjectionTests.cs:68,73, MMCA.Store/Tests/Modules/Identity/MMCA.Store.Identity.API.Tests/DependencyInjectionTests.cs:49,54, MMCA.ADC/Tests/Modules/Identity/MMCA.ADC.Identity.API.Tests/DependencyInjectionTests.cs:26,31, and MMCA.ADC/Tests/Modules/Notification/MMCA.ADC.Notification.Application.Tests/DependencyInjectionTests.cs:35. MMCA.Common self-tests the helper, including that it fails for an extension returning a different collection (MMCA.Common/Tests/Hosting/MMCA.Common.Testing.Tests/Support/DependencyInjectionAssertTests.cs:13).

EntityBuilderBase<TBuilder, TEntity>

MMCA.Common.Testing · MMCA.Common.Testing.Builders · MMCA.Common/Source/Hosting/MMCA.Common.Testing/Builders/EntityBuilderBase.cs:9 · Level 0 · class (abstract)

• What it is: the tiny root of the framework's fluent test-data builders. A subclass fixes sensible defaults for one entity type so a test only has to state the properties it actually cares about, then calls Build() to materialize the entity through its real domain factory.
• Depends on: nothing first-party, and no BCL surface beyond object. Two type parameters and one abstract method is the whole type (MMCA.Common/Source/Hosting/MMCA.Common.Testing/Builders/EntityBuilderBase.cs:9-18).
• Concept introduced, the Test Data Builder plus the self-referencing generic (CRTP). [Rubric §14, Testability] assesses how easily the code can be exercised in isolation; a builder base is a textbook §14 affordance, it removes the copy-pasted setup that otherwise bloats every arrange step. The signature EntityBuilderBase<TBuilder, TEntity> where TBuilder : EntityBuilderBase<TBuilder, TEntity> (MMCA.Common/Source/Hosting/MMCA.Common.Testing/Builders/EntityBuilderBase.cs:9-10) is the curiously-recurring template pattern: a concrete builder passes itself as TBuilder, so the WithX(...) methods a subclass adds can return the concrete builder type and keep a fluent chain strongly typed without a cast.
• Walkthrough
  • Build() (MMCA.Common/Source/Hosting/MMCA.Common.Testing/Builders/EntityBuilderBase.cs:17): the single abstract member. The XML doc (EntityBuilderBase.cs:12-15) records the contract, the subclass calls the entity's Result-returning factory (ADR-013) and throws if it failed, so a builder never yields a domain object that violated its invariants. The base deliberately owns no state and no default WithX helpers, those live on each concrete builder because defaults are per-entity.
• Why it's built this way: keeping the base to one abstract method means it adds zero coupling and zero opinions beyond "a builder produces a TEntity". The CRTP is the only structural rule it enforces, and it exists purely so fluent chaining stays type-safe down in the subclasses.
• Where it's used: the domain-test builders in both apps subclass it, ten today: MMCA.ADC/Tests/Modules/Conference/MMCA.ADC.Conference.Domain.Tests/Builders/ActivityBuilder.cs:10, .../Builders/EventBuilder.cs:10, .../Builders/SessionBuilder.cs:10, .../Builders/SpeakerBuilder.cs:10, .../Builders/SponsorBuilder.cs:11, MMCA.ADC/Tests/Modules/Identity/MMCA.ADC.Identity.Domain.Tests/Builders/UserBuilder.cs:10, MMCA.Store/Tests/Modules/Catalog/MMCA.Store.Catalog.Domain.Tests/Builders/CategoryBuilder.cs:10, .../Builders/ProductBuilder.cs:10, MMCA.Store/Tests/Modules/Identity/MMCA.Store.Identity.Domain.Tests/Builders/CustomerBuilder.cs:11, and MMCA.Store/Tests/Modules/Sales/MMCA.Store.Sales.Domain.Tests/Builders/OrderBuilder.cs:11.
• Caveats / not-in-source: the "throws on failure" and "sensible defaults" behavior is documented on the base but implemented only in those subclasses, which live outside this unit.

FeatureManagementTestExtensions

MMCA.Common.Testing · MMCA.Common.Testing.Support · MMCA.Common/Source/Hosting/MMCA.Common.Testing/Support/FeatureManagementTestExtensions.cs:10 · Level 0 · class (static)

• What it is: a one-method helper that lets an integration-test host force feature-flag values, overriding whatever appsettings.json would otherwise resolve, so a test can pin a flag on or off and assert both branches of a feature-gated command or query.
• Depends on: BCL and NuGet only, IServiceCollection and IConfiguration from Microsoft.Extensions.* plus AddFeatureManagement from Microsoft.FeatureManagement (MMCA.Common/Source/Hosting/MMCA.Common.Testing/Support/FeatureManagementTestExtensions.cs:1-3). No first-party dependency.
• Concept: this is the test-side counterpart to the framework's FeatureGateCommandDecorator<TCommand, TResult>, the outermost link in the CQRS pipeline (taught in primer §2). [Rubric §14, Testability] again: a gated handler is only meaningfully testable if a test can flip its flag deterministically. [Rubric §17, DevOps & Deployment] applies too, feature management (ADR-031) is a cross-cutting concern, and this helper keeps its test-time configuration in one reusable place.
• Walkthrough
  • The whole class body is a single C# preview extension(IServiceCollection services) block (MMCA.Common/Source/Hosting/MMCA.Common.Testing/Support/FeatureManagementTestExtensions.cs:12), the same extension-member style the framework uses for DI registration (see primer §4), not a classic this-parameter extension method.
  • ConfigureTestFeatureFlags(Dictionary<string, bool> features) (MMCA.Common/Source/Hosting/MMCA.Common.Testing/Support/FeatureManagementTestExtensions.cs:35-62): null-guards the dictionary (:38), then layers the flags on top of the configuration the host already registered rather than replacing it. It finds the last IConfiguration descriptor and reads its ImplementationInstance (:40-42), seeds a ConfigurationBuilder from it when one was found (:44-48), appends the flags as in-memory FeatureManagement:{Name} keys so they win over any FeatureManagement section the host configured (:50-56), registers the composed root as the IConfiguration singleton (:58), calls AddFeatureManagement against its FeatureManagement section (:59), and returns the collection for chaining (:61).
  • The layering is the load-bearing detail, and the doc says why (:18-25): .NET DI hands a non-collection dependency the last registration, so building a flags-only root here would give every component constructed afterwards a configuration containing nothing but FeatureManagement, silently losing connection strings, authentication settings and the data-source section.
  • The pick-up is instance-only by design (:26-31): a configuration registered behind a factory cannot be read without building the provider, so in that case the flags stand alone.
• Why it's built this way: pushing overrides through the real IConfiguration plus AddFeatureManagement path (rather than mocking an IFeatureManager) means the test exercises the same feature-evaluation code the production host runs, only the source of the flag value changes.
• Where it's used: it is intended for a test WebApplicationFactory's ConfigureServices, and the XML doc says exactly that (MMCA.Common/Source/Hosting/MMCA.Common.Testing/Support/FeatureManagementTestExtensions.cs:14-17). MMCA.Common covers all three behaviors directly: that the flags layer on top of a host configuration (MMCA.Common/Tests/Hosting/MMCA.Common.Testing.Tests/Support/FeatureManagementTestExtensionsTests.cs:20), that they drive a resolved IFeatureManager (:43), and that a collection with no configuration at all still gets the flags (:62).
• Caveats / not-in-source: as of this pass no application test project calls it. A workspace-wide search finds ConfigureTestFeatureFlags only at its definition (MMCA.Common/Source/Hosting/MMCA.Common.Testing/Support/FeatureManagementTestExtensions.cs:35) and in MMCA.Common's own unit tests; neither ADC, Store nor Helpdesk uses it. It ships in the package as available capability, not as a technique any application suite currently uses.

IIntegrationTestFixture

MMCA.Common.Testing · MMCA.Common.Testing.Fixtures · MMCA.Common/Source/Hosting/MMCA.Common.Testing/Fixtures/IIntegrationTestFixture.cs:8 · Level 0 · interface

• What it is: the contract every integration-test fixture implements, the two capabilities a test base needs from a booted host: hand me an HttpClient, and reset the database to clean between tests.
• Depends on: BCL only (HttpClient, Task). No first-party dependency, which is what lets it sit at Level 0 and be referenced by everything above it.
• Concept introduced, the test fixture as an abstraction boundary. [Rubric §14, Testability]: by depending on this interface rather than a concrete WebApplicationFactory, the reusable IntegrationTestBase<TFixture> stays host-agnostic, and each downstream app supplies its own concrete fixture with its own Program, JWT keys, and data sources. This is the boundary that keeps the shared test scaffolding in MMCA.Common.Testing and the app-specific wiring in each repo, which is the whole premise of ADR-058.
• Walkthrough
  • CreateClient() (MMCA.Common/Source/Hosting/MMCA.Common.Testing/Fixtures/IIntegrationTestFixture.cs:11): returns an HttpClient configured for the in-process test server.
  • ResetDatabaseAsync() (MMCA.Common/Source/Hosting/MMCA.Common.Testing/Fixtures/IIntegrationTestFixture.cs:19): resets the database between tests (the doc names Respawn as the typical mechanism). The doc comment (IIntegrationTestFixture.cs:13-18) records a load-bearing rule for the database-per-service topology (ADR-006): a host with multiple physical data sources must reset every relational source, and can enumerate them by resolving IEntityDataSourceRegistry and IDataSourceResolver from the host's services.
• Why it's built this way: two members, no state, no host coupling. The interface is deliberately minimal so the reset strategy (single database versus multi-source) is the fixture's problem, not the base's.
• Where it's used: implemented by SqlServerIntegrationTestFixtureBase<TEntryPoint> (MMCA.Common/Source/Hosting/MMCA.Common.Testing/Fixtures/SqlServerIntegrationTestFixtureBase.cs:27) and through it by every per-service fixture in both apps; consumed as the TFixture constraint on IntegrationTestBase<TFixture> (MMCA.Common/Source/Hosting/MMCA.Common.Testing/Fixtures/IntegrationTestBase.cs:14) and therefore by all three contract bases in this unit.

JwtTokenGenerator

MMCA.Common.Testing · MMCA.Common.Testing.Support · MMCA.Common/Source/Hosting/MMCA.Common.Testing/Support/JwtTokenGenerator.cs:30 · Level 0 · class (static)

• What it is: a static factory that mints signed JWT bearer tokens for integration tests, plus the matching switch that re-points a test host's Bearer scheme at the same committed key. Together they let a test call an authorized endpoint as any role or user without standing up the real login flow or a reachable JWKS endpoint. Each downstream project wraps the generator with role-specific convenience methods (AdminToken, OrganizerToken, and so on, MMCA.Common/Source/Hosting/MMCA.Common.Testing/Support/JwtTokenGenerator.cs:11-12).
• Depends on: BCL and NuGet only, System.Globalization, System.IdentityModel.Tokens.Jwt, System.Security.Claims, System.Security.Cryptography (RSA), Microsoft.AspNetCore.Authentication.JwtBearer (for the options type the second member configures), and Microsoft.IdentityModel.Tokens (MMCA.Common/Source/Hosting/MMCA.Common.Testing/Support/JwtTokenGenerator.cs:1-6). The generated claim layout mirrors the framework's ITokenService so downstream auth middleware cannot tell a test token from a real one (JwtTokenGenerator.cs:99-102). The userId parameter is typed UserIdentifierType (JwtTokenGenerator.cs:114), the solution-wide identifier alias (ADR-048).
• Concept introduced, exercising the real RS256 path in tests. [Rubric §11, Security] assesses how authentication and key handling are done; the deliberate choice here is that tests sign with RS256 (SecurityAlgorithms.RsaSha256, JwtTokenGenerator.cs:131) using an embedded RSA-2048 dev keypair, the same asymmetric algorithm production uses, so integration tests run the identical validation code path (ADR-004, taught in primer §2) rather than a weaker HMAC shortcut. [Rubric §14, Testability] covers the ergonomics: deterministic tokens with no per-run key generation, and a host that validates them with no network dependency at all.
• Walkthrough
  • Public constants (MMCA.Common/Source/Hosting/MMCA.Common.Testing/Support/JwtTokenGenerator.cs:33-96): DefaultIssuer (https://localhost:6001, line 33), DefaultKeyId (mmca-test-key, line 41, the kid the host advertises on its JWKS document), and the paired DefaultPublicKeyPem (line 49) and DefaultPrivateKeyPem (line 68). The class doc records the wiring contract: test host appsettings set Jwt:SigningAlgorithm=RS256, Jwt:RsaPublicKeyPem, and Jwks:KeyId (JwtTokenGenerator.cs:18-20) so RsaJwksProvider publishes a JWKS entry with the matching kid.
  • GenerateToken(...) (JwtTokenGenerator.cs:112-156): imports the PEM private key into RSAParameters inside a using so the RSA instance can be disposed without invalidating the key held by SigningCredentials (:121-131), assembles the claim set (:137-141) and appends any caller-supplied extras (:143-146), then writes a one-hour token (:148-155). Defaulted parameters mean a caller normally passes only audience, user id, and role (:112-119).
  • The claim set is exactly two claims, ClaimTypes.NameIdentifier carrying the culture-invariant user id and ClaimTypes.Role (:137-141). NameIdentifier is what the JWT bearer handler produces for a real token's sub under its default inbound mapping, so a test token carrying it reaches every reader the way a production one does; the comment above it (:133-136) records that the duplicate custom claim that used to ride alongside it is gone, matching ITokenService, because two claims for one identity can disagree.
  • ConfigureInProcessTokenValidation(JwtBearerOptions options, string audience) (JwtTokenGenerator.cs:170-192): the validation half. It nulls Authority and ConfigurationManager and clears RequireHttpsMetadata (:174-176) to stop OIDC/JWKS discovery outright, imports the public key (:178-183), and pins the token-validation parameters to that static key plus the fixed issuer and the caller's audience (:185-191). The doc explains why it has to exist (:158-167): AddForwardedJwtBearer otherwise fetches the issuer and signing keys from the Identity service's JWKS document through the gateway, which no in-process test topology serves.
• Why it's built this way: the whole point is fidelity. Tokens are indistinguishable in shape and signing algorithm from production, so auth middleware and role checks are under test rather than stubbed. Splitting the key material into a mint side and a validate side is what lets a single-host fixture and a multi-host cross-service fixture share one committed keypair.
• Where it's used: tokens are applied to a client through IntegrationTestBase<TFixture>'s SetBearerToken(...) (MMCA.Common/Source/Hosting/MMCA.Common.Testing/Fixtures/IntegrationTestBase.cs:42-44) and wrapped by each app's role-specific token helpers. ConfigureInProcessTokenValidation is called from a PostConfigure<JwtBearerOptions> in the test factories of the non-Identity hosts, in ADC (MMCA.ADC/Tests/Integration/MMCA.ADC.Conference.IntegrationTests/Infrastructure/ConferenceTestWebApplicationFactory.cs:49,77, .../MMCA.ADC.Engagement.IntegrationTests/Infrastructure/EngagementTestWebApplicationFactory.cs:56,86, .../MMCA.ADC.Notification.IntegrationTests/Infrastructure/NotificationTestWebApplicationFactory.cs:50,69) and in Store (MMCA.Store/Tests/Integration/MMCA.Store.Catalog.IntegrationTests/Infrastructure/CatalogTestWebApplicationFactory.cs:40,43, .../MMCA.Store.Sales.IntegrationTests/Infrastructure/SalesTestWebApplicationFactory.cs:47,57), plus the cross-service factories (MMCA.ADC/Tests/Integration/MMCA.ADC.CrossService.IntegrationTests/Infrastructure/ConferenceCrossServiceFactory.cs:45, .../EngagementCrossServiceFactory.cs:54, MMCA.Store/Tests/Integration/MMCA.Store.CrossService.IntegrationTests/Infrastructure/CatalogCrossServiceFactory.cs:50, .../SalesCrossServiceFactory.cs:52). It is covered directly by MMCA.Common/Tests/Hosting/MMCA.Common.Testing.Tests/Support/JwtTokenGeneratorTests.cs:39-95.
• Caveats / not-in-source: the class doc (MMCA.Common/Source/Hosting/MMCA.Common.Testing/Support/JwtTokenGenerator.cs:22-28) carries an explicit security warning, the embedded keypair is committed to the public git repo and is insecure by design, it exists only to make integration tests deterministic. Production keys are provisioned via user-secrets or Azure Key Vault per JwtSettings.RsaPrivateKeyPem and must never be this keypair.