Onboarding guide

Primer, the concepts, stack, and conventions you need first

This chapter teaches the cross-cutting things once, so the per-type chapters can stay focused. Read it before the group chapters (start with group-01). Everything here is either an architectural style the codebase commits to, an external dependency (BCL/NuGet, "external Level 0"), a build/language convention, or the architecture-evaluation lens the guide tags against. Later sections cross-reference back here.

1. The big picture

Two codebases are in scope:

• MMCA.Common: a framework, published as seventeen NuGet packages (the count and list are owned by MMCA.Common/FACTS.md) to nuget.org (the documented install path) and mirrored to GitHub Packages (ADR-053) (four core: .Shared, .Domain, .Application, .Infrastructure; five presentation: .API, .Grpc, .UI, .UI.Maui, .UI.Web; three hosting: .Aspire, .Aspire.Hosting, .Gateway; four testing: .Testing, .Testing.E2E, .Testing.UI, .Testing.Architecture; plus the MMCA.Common metapackage that bundles the six a standard host always takes, ADR-101). It is not a runnable app; it ships the base classes and infrastructure for building modular monoliths with DDD + Clean Architecture + CQRS, plus the extension points to extract a module into its own microservice later. The packages release in lockstep (one version tags all of them).
• MMCA.ADC: the Atlanta Developers Conference application, a consumer of those packages. It has modules (Conference, Engagement, Identity, Notification), a Blazor UI, a YARP gateway, and Azure infrastructure.

MMCA.ADC depends on MMCA.Common; MMCA.Common depends on neither. That is why the Common framework groups come first in this guide and the ADC business-module groups build on them, and within every group, the per-type sections run in ascending dependency Level.

The layered dependency flow (Clean Architecture)

MMCA.Common's own layering, enforced top-to-bottom (MMCA.Common/CLAUDE.md, "Architecture"):

API / Grpc        (presentation / transport)
     ↓
Infrastructure    (EF Core, caching, JWT, JWKS, outbox, message bus, SignalR)
     ↓
Application       (CQRS handlers, decorators, module system, IMessageBus)
     ↓
Domain            (entities, aggregates, domain events, specifications)
     ↓
Shared            (Result pattern, errors, DTOs, value objects)

Each layer references only layers below it, the dependency rule of Clean Architecture: source dependencies point inward, toward the domain, and the domain depends on nothing framework-specific. Two deliberate exceptions: UI and Grpc depend on Shared only, UI for Blazor WebAssembly compatibility, Grpc because it is pure transport that must not couple to business layers. The two host-support presentation packages sit above those: UI.Maui may reference UI and Shared only, and UI.Web (the Blazor Web host bridge) references UI, API, and Aspire, never Domain/Application/Infrastructure directly, which is why it disables transitive project references and carries its own boundary check (MMCA.Common/Source/Build/MMCA.Common.LayerEnforcement.targets:90-123).

MMCA.ADC repeats the same layering per module: each of Conference/Engagement/Identity has .Shared, .Domain, .Application, .Infrastructure, .API, and .UI projects following the same inward rule.

2. Architectural styles this codebase commits to

These are the recurring ideas. Each is taught fully at its first concrete appearance in a group chapter; here is the orientation so the vocabulary is familiar.

• Domain-Driven Design (DDD). The model mirrors the business. Aggregates (a root entity plus the children it owns) enforce invariants inside their boundary; references between aggregates are by ID, not object graph. Value objects (Money, Address, Email) model concepts with no identity and are immutable. Domain events announce meaningful state changes. Factory methods return Result<T> so an invalid entity cannot be constructed. First concrete code: group-02 (ValueObject, IBaseEntity<T>) and group-04 (IDomainEvent).

• Clean Architecture. See §1. The domain layer is free of EF/ASP.NET/serialization attributes; the application layer defines ports (interfaces) that infrastructure implements as adapters.

• CQRS (Command/Query Responsibility Segregation). Writes (commands, which mutate and return a Result) are separated from reads (queries, side-effect-free). Both flow through a decorator pipeline: commands run FeatureGate → Logging → Caching → Validating → Transactional → handler, queries run FeatureGate → Logging → Caching → handler (no validation and no transaction on the read side). The order is set by the registrations in AddApplicationDecorators, which Scrutor's TryDecorate applies in reverse, so the last registered is the outermost (MMCA.Common/Source/Core/MMCA.Common.Application/DependencyInjection.cs:93-102). Cross-cutting concerns live in the pipeline, not in each handler. First concrete code: the ICommandHandler/IQueryHandler contracts and their decorators in group-05.

• One shared HTTP middleware pipeline (ADR-079). The HTTP-side sibling of the decorator chain: every REST/gRPC service host builds its request pipeline from one UseCommonMiddlewarePipeline call, which fixes the middleware order once (exception handler through controllers) with the load-bearing adjacencies commented in code (authentication before the rate limiter and before tenant resolution, forwarded headers before both). Conditional middleware registers unconditionally and stays inert by config, so hosts differ by configuration, not by pipeline shape. Adopted by all seven ADC/Store service hosts, Helpdesk, and the template; the gateways and Blazor UI hosts sit deliberately outside it. First concrete code: group-12.

• Vertical Slice Architecture. Within a module, a feature is a cohesive slice (command/query + handler + validator + DTO + mapper together), not scattered across horizontal Services/, Repositories/, Validators/ folders. Adding a feature means adding a slice.

• Modular Monolith → extractable services. Modules implement a common IModule contract and are discovered and registered in dependency (topological) order by a module loader. Each module can later run as its own service host behind a YARP gateway without a rewrite, because application code talks to abstractions (IMessageBus, typed gRPC clients) and the transport choice lives at the edges. (ADRs 007 "gRPC extraction", 008 "service-extraction topology".)

• Cross-service auth without shared secrets (ADR-004). Only the Identity service ever holds token-signing key material. The moment auth crosses a service boundary, tokens are signed asymmetrically (RS256) and every other service validates them via JWKS / OIDC discovery: AddForwardedJwtBearer points the bearer middleware at an authority, fetches /.well-known/openid-configuration, and follows jwks_uri to the published public key. So a compromised non-Identity service cannot mint tokens, and key rotation is publish-once at the issuer. The issuer is deliberately taken from the discovery document rather than pinned, because the internal service-discovery hostname differs from the public gateway origin, and both validators pin ValidAlgorithms so an attacker cannot force an algorithm swap. Downstream gRPC calls forward the already-validated JWT (ADR-007's JwtForwardingClientInterceptor). This is the auth half of the extraction promise in the previous bullet: token validation survives the issuer/validator split without a rewrite. Adoption note (verified by source): the guarantee is scoped to cross-service auth. The in-process monolith default stays HS256 with a shared symmetric secret behind the same JwtSettings.SigningAlgorithm switch, and MMCA.Helpdesk (the monolith seed) runs issuer-less. ADC's Conference, Engagement, and Notification services all validate through the gateway-routed discovery path today. First concrete code: group-08.

• Write-once UI, render everywhere (Blazor + .NET MAUI Hybrid). A UI page is authored once as a Razor component in a per-module Razor Class Library (MMCA.ADC.{Module}.UI, e.g. Conference.UI's EventList.razor/EventDetail.razor). Both the web host (MMCA.ADC.UI.Web / .Web.Client, Blazor Server + WebAssembly) and the .NET MAUI host (MMCA.ADC.UI) ProjectReference the same UI libraries, so one page renders across Web, Android, iOS, macOS, and Windows with no per-platform reimplementation, MAUI hosts the shared components in a BlazorWebView (MMCA.ADC/Source/Hosts/UI/MMCA.ADC.UI/MainPage.xaml:16, wired by AddMauiBlazorWebView() in MMCA.ADC/Source/Hosts/UI/MMCA.ADC.UI/MauiProgram.cs:64). The only platform-specific code is tiny entry points (App/AppDelegate/MainApplication, MauiProgram). First concrete code: the MAUI bootstraps and host shells in group-25; the supported device/browser matrix is in MMCA.ADC/CLAUDE.md.

• Event-driven integration + the Outbox pattern. When an aggregate changes, its domain events are serialized into an OutboxMessage row in the same transaction as the data, then a background processor delivers them at-least-once. This avoids the "save then publish and hope" dual-write bug. (ADR-003 "outbox dual-dispatch".)

• Database-per-service. Each module/service owns its own SQL database and its own outbox table; there is one concrete SQLServerDbContext class but one instance per database. Cross-source relationships auto-degrade (the FK is dropped, navigation flows through batch loaders), and the outbox is the cross-source consistency mechanism. (ADR-006.)

• Engine-agnostic entities, the storage provider is a one-token choice (ADR-018). A domain entity carries no persistence-engine choice; it is a plain class. What decides whether it is stored in SQL Server, Cosmos DB, or SQLite is a single [UseDataSource(<engine>)] attribute on its Infrastructure/Persistence/EntityConfiguration/{Entity}Configuration class, carried for you by one of three thin engine shim base classes (EntityTypeConfigurationSQLServer<TEntity, TId>, …Cosmos<…>, …Sqlite<…>). All three derive from a single engine-aware EntityTypeConfiguration<TEntity, TId> base (which reads the attribute and applies the matching table/container/schema/key conventions) over EntityTypeConfigurationBase<TEntity, TId>, group-07. So swapping just that base (or attribute) re-points the same entity to a different engine with no configuration-body edits and zero change to the domain, application layer, or entity, the engine is resolved up front by the EntityDataSourceRegistry, the right DbContext is built per data source, cross-source relationships auto-degrade, and a cross-source filter goes through CrossSourceSpecification (so even a "published-event" predicate stays translatable). First concrete code: the configuration hierarchy in group-07; this is the per-entity half of database-per-service (ADR-006) plus the polyglot story (ADR-018). Adoption note (verified by source): this is a real, tested capability that no entity routes to yet. Today every entity configuration in ADC derives from the …SQLServer base (ADC runs SQL Server only, four databases: ADC_Identity, ADC_Conference, ADC_Engagement, ADC_Notification, MMCA.ADC/Source/Hosting/MMCA.ADC.AppHost/Program.cs:32-35), and the ADR-018 work shipped the full polyglot machinery (unified base, cross-source spec + fitness rule, Cosmos-index skip, SQLite EnsureCreated, Cosmos/SQLite Aspire helpers, portability tests). An end-to-end trial moving ADC Conference's Session to Cosmos and Room to SQLite was built and tested locally, then deliberately reverted to all-SQL-Server with every framework extension point kept. Treat Cosmos/SQLite as supported, exercised extension points, see the coverage audit's extension-point inventory.

• The Result pattern. Expected error paths use a Result/Result<T> return value carrying Errors, not exceptions. This is the single most pervasive idiom in the codebase, taught in full in group-01 (ErrorType, Error, Result).

• Soft-delete + audit fields. Entities are never hard-deleted; an IsDeleted flag plus EF global query filters exclude them. CreatedOn/By and LastModifiedOn/By are stamped centrally in SaveChangesAsync. For genuine erasure (GDPR/CCPA) there is a separate anonymize path. (ADR-005.) Since ADR-075 the same idea extends to an opt-in field-level audit trail: a third SaveChangesInterceptor, registered last so it diffs freshly stamped values, writes per-property AuditTrailEntries in the same transaction as the data, with [Pii] values captured redacted (opt-in twice: AddAuditTrail plus an IAuditedEntity marker per entity; retention is an ADR-074 scheduled purge).

• Multi-tenancy as a persistence-layer commitment (ADR-073). Tenancy is not per-handler filtering: a second named EF query filter, "Tenant", composes by AND with the "SoftDelete" filter and embeds the executing tenant as a SQL parameter, so one cached model per source serves every tenant (a null tenant is the system context and sees all). ITenantContext resolves claim-then-header behind TenantResolutionMiddleware, a dedicated SaveChangesInterceptor stamps writes and refuses cross-tenant ones, the outbox drains per (source, tenant) pair, the caching decorators prefix keys with the tenant, and DB-per-tenant is a per-tenant connection-string override under the same DataSourceKey. Adoption note (verified by source): like the polyglot machinery above, this is a real, tested capability with one reference adopter: MMCA.Helpdesk runs it end to end, while ADC and Store stay single-tenant (the filter is inert without opt-in). First concrete code: group-07 (filters, interceptor) and group-12 (resolution middleware).

• Primitive identifier type aliases (ADR-048). Each entity's ID type is a per-module global using XIdentifierType = int; (or = System.Guid;) alias, linked into every project via Directory.Build.props. Code says EventIdentifierType, not bare int, so the ID type can change in one place: ADC's SpeakerIdentifierType is a System.Guid beside fourteen int siblings in the same file (MMCA.ADC.Conference.GlobalUsings.IdentifierType.cs:18, in MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Shared/). These are aliases, not wrapper structs: the alias is erased at compile time, so it buys readability and one-place change, not compile-time protection against passing the wrong same-typed ID. (The identifier-alias mechanism is covered with the entity contracts in group-02.)

The decision records (ADRs) this guide tags

The why behind these patterns lives in the accepted ADRs (the Website repo's docs-src/adr/README.md owns the count and range), version-controlled in Website/docs-src/adr/ and published at https://ivanball.github.io/docs/adr/ (its README.md is the canonical index with one-line summaries). Group chapters tag the relevant one inline (e.g. "ADR-003"); the full set, for orientation:

The canonical index for the full set can be found at https://ivanball.github.io/docs/adr/.

3. The external stack (BCL / NuGet, "external Level 0")

These are not first-party and get no per-type sections. Versions are from MMCA.Common/Directory.Packages.props and MMCA.ADC/Directory.Packages.props (Central Package Management, see §4). What each is and why it's here:

Web / API

• ASP.NET Core 10 (minimal hosting, MVC controllers), the API surface.
• Asp.Versioning.Mvc 10: API versioning for controllers.
• Microsoft.AspNetCore.Authentication.JwtBearer 10: validates JWT bearer tokens.
• Yarp.ReverseProxy 2.3.0 (ADC), the gateway that fronts the extracted module services; with Microsoft.Extensions.ServiceDiscovery.Yarp it routes to services by name.

Application / mapping / validation

• FluentValidation 12: request/command validators, run by a pipeline decorator.
• Riok.Mapperly 4.3.1: a source-generated, compile-time object mapper (no runtime reflection). Note ADR-001 chose manual DTO mapping over reflection-based AutoMapper; Mapperly is the compile-time, allocation-free way to keep mapping explicit and fast.
• Scrutor 7: assembly scanning and decorator registration (TryDecorate) for DI; this is how the CQRS decorator pipeline is wired.
• Microsoft.FeatureManagement 4.6: feature flags (e.g. Notification.PushNotifications).
• System.Linq.Dynamic.Core: dynamic OrderBy/filtering for query endpoints.

Persistence

• EF Core 10 with providers SqlServer, Cosmos, and Sqlite: the ORM. Sqlite is used for fast integration tests; Cosmos is a supported document source. EF concepts you must know: DbContext (unit of work + change tracker), entity configurations (IEntityTypeConfiguration<T>), migrations (versioned schema deltas), global query filters (the soft-delete mechanism), and interceptors (SaveChanges hooks for audit + domain-event capture).
• StackExchange.Redis / SignalR Redis backplane, distributed cache and SignalR scale-out.

Messaging

• MassTransit 8.5.5 (RabbitMQ + Azure Service Bus transports), the broker abstraction behind IMessageBus's broker implementation. Pinned to v8 by policy: v9 requires a commercial license and crashes broker-enabled hosts at startup; a build-time test fails if the major reaches 9 (MMCA.Common/Directory.Packages.props:49-56 carries the pin and the warning comment, and see §4).

Transport (service extraction)

• Grpc.AspNetCore / Grpc.Net.ClientFactory / Grpc.Tools / Google.Protobuf: gRPC server + client
  • .proto compilation, for synchronous inter-service calls between extracted modules (ADR-007).

UI

• MudBlazor 9.7.0: the Blazor component library and design system (grids, dialogs, forms, theme). Used by both MMCA.Common.UI and the ADC UIs.
• Microsoft.AspNetCore.Components.*: Blazor (Server + WebAssembly) runtime and authorization.
• Polly 8 (via Microsoft.Extensions.Http.Resilience), retry/timeout/circuit-breaker resilience on outbound HTTP/gRPC clients.

Hosting / observability (.NET Aspire)

• Aspire.Hosting 13.4.6 (+ RabbitMQ, Azure CosmosDB integrations), local orchestration: the AppHost spins up every service, database, broker, and a dashboard with one command.
• OpenTelemetry (Api/Exporter/Instrumentation) + Azure.Monitor.OpenTelemetry.AspNetCore, structured logs, distributed traces, and metrics, exported to Azure Application Insights.
• Microsoft.Extensions.ServiceDiscovery: resolves service names to endpoints (local and cloud).
• AspNetCore.HealthChecks.*: Redis/RabbitMQ health probes.

Auth / crypto

• System.IdentityModel.Tokens.Jwt 8: JWT creation/validation; JWKS key publishing for cross-service token validation (ADR-004 "authentication dual-fetch").

Versioning / build

• MinVer 7: derives the package version from the git tag (vX.Y.Z), so releases are tag-driven.

Analyzers (all at error severity, see §4)

• Meziantou.Analyzer, SonarAnalyzer.CSharp, StyleCop.Analyzers, Roslynator.Analyzers, Microsoft.VisualStudio.Threading.Analyzers.

Testing

• xunit.v3 3.2: the test framework (xUnit v3, not v2).
• Microsoft Testing Platform (MTP): the test runner (global.json sets "runner": "Microsoft.Testing.Platform"), not VSTest. This changes how you run a single test (see §6).
• bUnit 2: Blazor component testing (the v2 line is the one compatible with xUnit v3 / MTP).
• Microsoft.Playwright 1.61 + Deque.AxeCore.Playwright 4.12: browser E2E and axe-core accessibility (WCAG 2.1 AA) scanning.
• NetArchTest.eNhancedEdition: architecture fitness tests (assert layer/purity rules against compiled assemblies).
• Moq 4 (mocking), AwesomeAssertions 9 (fluent assertions, a FluentAssertions-compatible fork), coverlet (coverage).

4. C#, build, and code-style conventions

• .NET 10.0, LangVersion: preview: required because the codebase uses C# extension types (extension(T) syntax, see below).
• Central Package Management (CPM). All NuGet versions live in each repo's Directory.Packages.props (ManagePackageVersionsCentrally = true); individual .csproj files reference packages by name only. To change a version, edit the props file. [Rubric §15, §32]
• NuGet lock files + pinned, audited sources. MMCA.Common commits lock files and pins packageSourceMapping to nuget.org, so it builds/tests with no GitHub token. CI runs dotnet list package --vulnerable and fails on any vulnerable package. The MassTransit v8 pin is enforced by a build-time test (DependencyVersionTests), a blanket "update all packages" that reintroduces v9 will fail the build by design. [Rubric §32, Dependency & Supply-Chain]
• TreatWarningsAsErrors globally, and five analyzers at error severity. The code must be warning-free to compile. [Rubric §15, Best Practices & Code Quality]
• .editorconfig enforces style at error severity (MMCA.Common/.editorconfig): file-scoped namespaces (csharp_style_namespace_declarations = file_scoped:error, line 102), braces always required (csharp_prefer_braces = true:error, line 138), var only when the type is apparent (lines 105-107), expression-bodied members preferred (lines 110-117), all accessibility modifiers required (line 73), no this. qualification (lines 57-60), readonly where possible (line 94), interfaces begin with I (error, line 212). The naming rules below that (private fields _camelCase, constants PascalCase) are declared at warning, which TreatWarningsAsErrors promotes to a build break anyway. Test files relax method-naming and complexity rules via the [Tests/**/*.cs] section (line 737).

C# extension(T) types, read this once

C# 14 (preview) extension members let a static class add members to a type via an extension block:

public static class DomainHelper
{
    extension(string? id)                 // receiver: the "this" value
    {
        public TIdentifier Parse<TIdentifier>() { ... }   // usable as someString.Parse<int>()
    }
}

The codebase uses this heavily for DI registration, every DependencyInjection.cs adds methods like AddApplication() directly onto IServiceCollection through an extension(IServiceCollection) block. You'll first meet the syntax in group-02 (DomainHelper, EntityTypeExtensions). (A practical note for the leveling: references written inside an extension block belong to the enclosing static class, that's how this guide attributes their dependencies.)

Architecture enforcement is doubled (fitness functions) [Rubric §34, §3]

The layer rules are not just convention, they are enforced twice:

1. Compile-time, Source/Build/MMCA.Common.LayerEnforcement.targets, imported for every MMCA.Common.* project under Source/ (MMCA.Common/Directory.Build.props:99-100), inspects ProjectReferences before build and fails with a descriptive error if a layer references a forbidden upstream layer.
2. Runtime (test), Tests/Architecture/MMCA.Common.Architecture.Tests (NetArchTest) asserts the same rules against compiled assemblies: layer flow, domain purity, and microservice extraction rules (e.g. Application/Domain/Shared must never reference MassTransit directly, depend on IMessageBus instead). The rule bodies themselves now live once in the shipped MMCA.Common.Testing.Architecture package (one of the lockstep-released packages, see FACTS.md): a reusable rule library + abstract *TestsBase classes that each repo's arch-test project subclasses, supplying only a repo-specific IArchitectureMap, so MMCA.Common and MMCA.ADC (and, outside this guide's scope, MMCA.Store and MMCA.Helpdesk) all enforce one rule set (ADR-015).

When you move a type between packages, expect both gates to react. This is the codebase's "executable governance", covered fully in the architecture-tests chapter.

5. The solution / test layout

• *.slnx: the human solution (XML format). *.slnf, a solution filter used in CI to build a subset fast (MMCA.Store.CI.slnf, MMCA.ADC.CI.slnf).
• Microsoft Testing Platform, not VSTest. To run one test class/method you target the test project and pass an MTP filter after --:

  dotnet test --project Tests/<path>/<Name>.Tests.csproj -- --filter-method "*Pattern*"
  #                                                      -- --filter-class  "*FooTests*"

  Always --project <csproj>, never a bare path, and get the flag right: a wrong filter flag exits 5 having run zero tests instead of erroring out loudly. Every test project must contain at least one test or MTP exits 8, so CI passes --minimum-expected-tests on every run: 1 on the ADC legs (MMCA.ADC/.github/workflows/deploy.yml:219) and 2000 on MMCA.Common's full solution run, where the point is to fail a discovery regression that silently drops thousands of tests (MMCA.Common/.github/workflows/ci.yml:144).
• Some UI test projects (MMCA.Common.UI.Gallery, MMCA.Common.UI.E2E.Tests) are deliberately excluded from the .slnx so the unit-test run stays fast; they run in a dedicated CI job and are built by csproj path.

6. The 34-category architecture-evaluation lens

This codebase is also scored against a 34-category rubric (Website/docs-src/governance/ArchitectureEvaluationCriteria.md, published at https://ivanball.github.io/docs/governance/). This guide weaves the rubric in so you learn the system and the lens it's judged by at the same time. Each type section tags the categories it genuinely touches as [Rubric §N, Name], with a one-line "what §N assesses" and "how this code embodies (or under-uses) it". The first occurrence of a category teaches it; later ones cross-reference back. The guide explains categories; it does not score them, the filled scorecards live beside the rubric as one repo-prefixed file per repo (Website/docs-src/governance/common-ArchitectureScorecard.md, adc-ArchitectureScorecard.md, store-ArchitectureScorecard.md), each paired with a *-RemediationBacklog.md.

Two axes (so a tag can say "mature but mediocre" or vice-versa)

• Maturity (0 to 4), process: how consistently/automatically the pattern is governed (ad-hoc → enforced by CI).
• Implementation (0 to 10), substance: how good the implementation is right now, against the category's criteria and red flags.

The categories, in three parts (quick index, full criteria in the rubric file)

Part A, Application / Backend (§1 to §17): §1 SOLID · §2 Design Patterns · §3 Clean Architecture · §4 Domain-Driven Design · §5 Vertical Slice · §6 CQRS & Event-Driven · §7 Microservices Readiness · §8 Data Architecture · §9 API & Contract Design · §10 Messaging & Integration Architecture · §11 Security · §12 Performance & Scalability · §13 Observability & Operability · §14 Testability & Test Strategy · §15 Best Practices & Code Quality · §16 AI-Native Application Architecture · §17 DevOps & Deployment.

Part B, Front-End / UI (§18 to §28): §18 UI Architecture & Component Design · §19 State Management & Data Flow · §20 Design System, Theming & UI Consistency · §21 Accessibility (a11y) · §22 Responsive Design & Cross-Browser/Device · §23 Front-End Performance & Rendering · §24 Forms, Validation & UX Safety · §25 Navigation, Routing & Information Architecture · §26 Front-End Security · §27 Internationalization & Localization · §28 Front-End Testing & Quality.

Part C, Operational, Governance & Cross-Cutting (§29 to §34): §29 Resilience, Reliability & Business Continuity · §30 Compliance, Privacy & Data Governance · §31 Cost Efficiency / FinOps · §32 Dependency & Supply-Chain Management · §33 Developer Experience & Inner Loop · §34 Architecture Governance & Documentation.

Some categories live most naturally in the DevOps/test chapters (§13 to §14, §17, §28, §29 to §34) and are explained there. The coverage audit will include a matrix proving every one of the 34 is explained at least once against real code or a real artifact.

You're ready for group-01, Result & Error Handling.