Vip32/Naos

What it measures: How tangled the control flow is — methods with many branches are hard to test and change.

Method: Cyclomatic complexity per method (1 + decision points), computed exhaustively across production source; test projects separated by convention. Deterministic.

Maturity: Documented → Verified → Prevented · effective 8.6 / 10 · rule-coverage 100% · ceiling Prevented

5 method(s) exceeded the cyclomatic complexity threshold of 15; the worst was SqlBuilder.BuildExpressionSelect at 38. A further 2 method(s) were over the threshold but excluded as flat dispatchers (a long switch/match over independent cases: many branches, almost no nesting), the largest being ExpressionVisitor.Visit at 46 — they are counted neither in the figure above nor in this dimension's score.

What to do

1. Resolve the 1 SqlBuilder.BuildExpressionSelect (cyclomatic 38) finding(s) in Cyclomatic Complexity — start with SqlBuilder.cs. — One of this dimension's main actionable groups (1 warning-level).
2. Resolve the 1 FileStorageKeyValueStorage.Match (cyclomatic 35) finding(s) in Cyclomatic Complexity — start with FileStorageKeyValueStorage.cs. — One of this dimension's main actionable groups (1 warning-level).
3. Resolve the 1 Extensions.To (cyclomatic 18) finding(s) in Cyclomatic Complexity — start with To.cs. — One of this dimension's main actionable groups (1 warning-level).
4. Enforce Cyclomatic Complexity in CI to reach Verified (currently Documented). — Hardens enforcement from Documented toward Prevented — provenance only; does not change the score.

Detailed fixes: d1_recommendation.md · top locations in Appendix A, every location in findings.md.

What it measures: How hard the code is for a person to follow, beyond raw branching.

Method: Cognitive complexity per method (Sonar-style nesting-penalized score), computed exhaustively over production code, excluding test projects. Deterministic.

Maturity: Documented → Verified → Prevented · effective 6.8 / 10 · rule-coverage 100% · ceiling Prevented

31 method(s) exceeded the cognitive complexity threshold of 15; the worst was FileStorageKeyValueStorage.Match at 46.

+ 22 more group(s) — more in Appendix A; the complete list is findings.md.

What to do

1. Resolve the 2 EntityFrameworkRepository.UpsertAsync (cognitive 20) finding(s) in Cognitive Complexity — start with EntityFrameworkRepository{TEntity,TDestination}.cs, EntityFrameworkRepository{TEntity}.cs. — One of this dimension's main actionable groups (2 warning-level).
2. Resolve the 2 CosmosSqlRepository.UpsertAsync (cognitive 18) finding(s) in Cognitive Complexity — start with CosmosSqlRepository{TEntity,TDestination}.cs, CosmosSqlRepository{TEntity}.cs. — One of this dimension's main actionable groups (2 warning-level).
3. Resolve the 2 MongoRepository.UpsertAsync (cognitive 18) finding(s) in Cognitive Complexity — start with MongoRepository{TEntity,TDestination}.cs, MongoRepository{TEntity}.cs. — One of this dimension's main actionable groups (2 warning-level).
4. Enforce Cognitive Complexity in CI to reach Verified (currently Documented). — Hardens enforcement from Documented toward Prevented — provenance only; does not change the score.

Detailed fixes: d2_recommendation.md · top locations in Appendix A, every location in findings.md.

What it measures: Over-large classes that try to do too much ("god classes").

Method: God-class detection by line and method-count thresholds per logical type (partial classes unified), filtered for generated code and registration/contract false positives. Deterministic.

Maturity: Documented → Verified → Prevented · effective 9.6 / 10 · rule-coverage 100% · ceiling Prevented

4 god class(es) detected.

✓ On the Gold path — maintain.

Detailed fixes: d3_recommendation.md · top locations in Appendix A, every location in findings.md.

What it measures: Copy-pasted code that should be shared instead.

Method: Code duplication via token-stream sliding windows with type-aware normalization (locals masked, type names preserved), density-scored per KLoC of production code. Deterministic.

Maturity: Documented → Verified → Prevented · effective 9.5 / 10 · rule-coverage 100% · ceiling Verified

51 duplicated block group(s) detected.

+ 24 more group(s) — more in Appendix A; the complete list is findings.md.

✓ On the Gold path — maintain.

Detailed fixes: d4_recommendation.md · top locations in Appendix A, every location in findings.md.

What it measures: Whether volatile projects sit underneath others that depend on them (so their churn ripples upward), and whether project dependencies form cycles. A widely-depended-on but stable shared/kernel project is healthy, not penalised.

Method: Dependency cycles via elementary-DFS over real .csproj references, plus Martin instability (afferent/efferent) per project. Exhaustive over the reference graph, deterministic.

Coverage: Exhaustive · type-level: afferent/efferent coupling + cycles computed over every production type — the population is all types, not a name convention.

Maturity: Documented → Verified → Prevented · effective 8.9 / 10 · rule-coverage 100% · ceiling Prevented

121 projects, 0 dependency cycle(s), 1 unstable depended-on project(s).

What to do

1. Resolve the 42 Layer violation finding(s) in Coupling. — One of this dimension's main actionable groups (42 issue-level).
2. Resolve the 16 Off the main sequence finding(s) in Coupling. — One of this dimension's main actionable groups (16 warning-level).
3. Resolve the 1 Unstable project Application finding(s) in Coupling. — One of this dimension's main actionable groups (1 warning-level).
4. Enforce Coupling in CI to reach Verified (currently Documented). — Hardens enforcement from Documented toward Prevented — provenance only; does not change the score.

Detailed fixes: d5_recommendation.md · top locations in Appendix A, every location in findings.md.

What it measures: Whether a class's methods are focused on a single responsibility.

Method: LCOM4 cohesion per production class with at least two methods: connected components of methods sharing state or calls, computed syntactically. Deterministic, not a proxy.

Coverage: Exhaustive · type-level: LCOM4 cohesion computed over every production class — the population is all types, not a name convention.

Maturity: Documented → Verified → Prevented · effective 9.6 / 10 · rule-coverage 100% · ceiling Verified

4 of 133 classes have LCOM4 above 3.

✓ On the Gold path — maintain.

Detailed fixes: d6_recommendation.md · top locations in Appendix A, every location in findings.md.

What it measures: How much of the code is actually exercised by tests.

Method: Coverage from coverlet runs or committed reports (Cobertura/OpenCover/lcov), computed per-file with structured exclusions for generated, trivial, and glue code. When the suite can't be built/run in-image AND no report is committed, coverage is reported NOT-MEASURED (excluded from the score) with the precondition to make it measurable — never a LoC-ratio proxy folded in as if measured. Deterministic.

Maturity: Documented → Verified → Prevented · effective 3.7 / 10 · rule-coverage 100% · ceiling Verified

Line coverage 15.1% — read from a committed opencover report (tests/Foundation.UnitTests/coverage.opencover.xml); the in-image collector couldn't run the suite (commonly external-service dependencies). A real measurement, but from a committed artifact rather than a fresh in-image run.

What to do

1. Enforce Code Coverage in CI to reach Verified (currently Documented). — Hardens enforcement from Documented toward Verified — provenance only; does not change the score.

Detailed fixes: d8_recommendation.md · top locations in Appendix A, every location in findings.md.

What it measures: Whether the test suite has a healthy mix of unit / integration / end-to-end tests.

Method: Test projects classified (Unit/Integration/BDD/E2E) from compiled metadata; test methods counted exhaustively across projects with placement-agnostic disk fallback. Deterministic.

Maturity: Documented → Verified → Prevented · effective 10.0 / 10 · rule-coverage 100% · ceiling Documented

552 test methods: 381 unit, 171 integration, 0 BDD, 0 e2e.

✓ On the Gold path — maintain.

Detailed fixes: d9_recommendation.md.

What it measures: Whether the tests truly assert behaviour rather than just running the code.

Method: Per-test assertions, skips, and mock references analyzed via Roslyn; structured skip-reason tags (BUG:/ENV:) separate documented deferrals from debt. Deterministic.

Maturity: Documented → Verified → Prevented · effective 9.9 / 10 · rule-coverage 100% · ceiling Prevented

9 skipped (9 with a documented reason), 2 zero-assertion, 6 mock references across 552 tests.

✓ On the Gold path — maintain.

Detailed fixes: d10_recommendation.md · top locations in Appendix A, every location in findings.md.

What it measures: Whether dependencies are current, secure, and not bloated.

Method: Manifest scan via dotnet list package across all projects; worst-signal-per-package deduction (saturating for vulnerabilities, capped-linear for deprecation/outdated) per KLoC. Exhaustive, deterministic.

Maturity: Documented → Verified → Prevented · effective 0.0 / 10 · rule-coverage 100% · ceiling Verified

121 outdated, 9 vulnerable, 25 deprecated, 1 prerelease packages.

What to do

1. Resolve the 25 Deprecated finding(s) in Dependency Hygiene. — One of this dimension's main actionable groups (25 warning-level).
2. Resolve the 9 Vulnerable finding(s) in Dependency Hygiene. — One of this dimension's main actionable groups (9 issue-level).
3. Resolve the 1 Prerelease dependency finding(s) in Dependency Hygiene. — One of this dimension's main actionable groups (1 warning-level).
4. Enforce Dependency Hygiene in CI to reach Verified (currently Documented). — Hardens enforcement from Documented toward Verified — provenance only; does not change the score.

Detailed fixes: d12_recommendation.md · top locations in Appendix A, every location in findings.md.

What it measures: Whether any secrets (keys, tokens, passwords) have leaked into the code.

Method: In-process native secret scanner (entropy plus signature patterns) across all tracked files; no external tool. A clean result is a measured 10, not no-data zero. Deterministic.

Maturity: Documented → Verified → Prevented · effective 10.0 / 10 · rule-coverage 100% · ceiling Prevented

Secret scan ran and found no leaked secrets.

✓ On the Gold path — maintain.

Detailed fixes: d13_recommendation.md.

What it measures: Whether the licenses of third-party packages are compatible with your policy.

Method: Third-party package licenses resolved from declared package metadata and checked against the configured policy (allow/deny/copyleft). Deterministic; clean = no incompatible license found at metadata depth.

Maturity: Documented → Verified → Prevented · effective 10.0 / 10 · rule-coverage 100% · ceiling Verified

0 of 130 packages use a banned license.

✓ On the Gold path — maintain.

Detailed fixes: d14_recommendation.md.

What it measures: Files that change often and are also complex — the riskiest hotspots.

Method: Per production file churn times cyclomatic complexity over a rolling window, computed from git and Roslyn/JS/Razor analysis. Exhaustive, deterministic per commit date.

Maturity: Documented → Verified → Prevented · effective 10.0 / 10 · rule-coverage 100% · ceiling Documented

No churn × complexity hotspots in the window.

✓ On the Gold path — maintain.

Detailed fixes: d15_recommendation.md.

What it measures: Acknowledged debt left in the code — TODOs, dead code, suppressed warnings.

Method: Roslyn syntactic debt markers (suppressions/TODO/FIXME/HACK/empty-catch/commented-code/Obsolete) plus SymbolFinder dead-code analysis; weighted-debt-per-KLoC density deducted 2.0x per unit. Deterministic, exhaustive.

Maturity: Documented → Verified → Prevented · effective 6.3 / 10 · rule-coverage 100% · ceiling Prevented

570 deducted debt markers + 0 dead symbols across 52730 LoC (1.8/KLoC) → score 6.3.

+ 3 more group(s) — more in Appendix A; the complete list is findings.md.

What to do

1. Resolve the 297 TodoComment finding(s) in Explicit Debt — start with NaosExtensions.cs (22), Startup.cs (17), CosmosSqlProviderV2.cs (9). — One of this dimension's main actionable groups (297 warning-level).
2. Resolve the 3 EmptyCatchBlock finding(s) in Explicit Debt — start with Expando.cs (3). — One of this dimension's main actionable groups (3 issue-level).
3. Resolve the 112 CommentedOutCode finding(s) in Explicit Debt — start with CosmosDbSqlProviderV3Tests.cs (6), State.cs (6), CosmosSqlProviderV2.cs (5). — One of this dimension's main actionable groups (112 warning-level).
4. Enforce Explicit Debt in CI to reach Verified (currently Documented). — Hardens enforcement from Documented toward Prevented — provenance only; does not change the score.

Detailed fixes: d17_recommendation.md · top locations in Appendix A, every location in findings.md.

What it measures: Whether the solution is laid out in a sensible, conventional structure.

Method: Solution structure: project count, decomposition, shell-project detection, build success (confirmed failures cap the score); traced to actual .sln files and binaries. Deterministic.

Maturity: Documented → Verified → Prevented · effective 10.0 / 10 · rule-coverage 100% · ceiling Documented

123 projects, 1433 source files, 67842 hand-written lines of code (52730 production / 15112 test), plus 518 generated (machine-written code — designer, scaffolded and tool-emitted files — excluded from quality), 2172 inter-project edges (build failed).

✓ On the Gold path — maintain.

Detailed fixes: d18_recommendation.md · top locations in Appendix A, every location in findings.md.

What it measures: Whether the project's documentation is clear, complete, and useful.

Method: Judged by language model at low temperature (0.0-0.1) on a deterministic doc sample (READMEs plus first 25 architecture docs), with two-pass stability filtering. Advisory, sampled.

Maturity: Documented → Verified → Prevented · effective Weak / 10 · rule-coverage 100% · ceiling Documented

The Naos project has a strong README with an architectural concepts section and a dev stack list but is otherwise thin on content. The visible documentation is mostly a single markdown file (the 'Architectural concepts' section) plus the Dev Stack and a brief logo; no architecture or per-module design docs, and XML-doc coverage across 120 modules is below 5% for most namespaces.

What to do

1. Resolve the 92 Low XML-doc coverage finding(s) in Documentation Quality — start with Application.Web.csproj (2), Application.csproj, Domain.csproj. — One of this dimension's main actionable groups (92 warning-level).
2. Resolve the 1 The README contains only an architectural Concepts section (a single… finding(s) in Documentation Quality. — One of this dimension's main actionable groups (1 recommendation-level).
3. Resolve the 1 No architecture or per-module design documentation describing how each… finding(s) in Documentation Quality. — One of this dimension's main actionable groups (1 recommendation-level).

Detailed fixes: d19_recommendation.md · top locations in Appendix A, every location in findings.md.

What it measures: Whether names — types, methods, variables — are clear and consistent.

Method: Judged by language model at low temperature (0.0-0.1) on a deterministic random symbol sample (fixed size, not exhaustive), with disclosed confidence band. Advisory, sampled.

Maturity: Documented → Verified → Prevented · effective Exemplary / 10 · rule-coverage 100% · ceiling Verified

0 naming inconsistencies across 200 sampled symbols.

✓ On the Gold path — maintain.

Detailed fixes: d21_recommendation.md.

What it measures: Whether each project is a focused, coherent unit rather than an oversized grab-bag.

Method: Project size overshoot penalties (LoC / public-type count / namespace count, 2-of-3 flag) weighted by log magnitude. Exhaustive across projects, deterministic, LLM-independent.

Maturity: Documented → Verified → Prevented · effective 10.0 / 10 · rule-coverage 100% · ceiling Documented

0 of 109 projects flagged as possibly oversized/incoherent.

✓ On the Gold path — maintain.

Detailed fixes: d26_recommendation.md.

What it measures: How far you must trace to follow a call — low indirection and co-located slices read easier.

Method: Call indirection (interface hops, cross-namespace calls, slice-locality scaled) over a sampled set of method invocations, size-aware baseline. Sampled; confidence discounted by symbol-resolution gaps.

Coverage: Slice locality from the first namespace segments, SAMPLED (≤400 methods) — not exhaustive.

Maturity: Documented → Verified → Prevented · effective 8.2 / 10 · rule-coverage 100% · ceiling Documented

87 % of calls cross a namespace and 12 % go through an interface, but 100 % of collaborators are co-located — so a call's collaborators sit together and tracing stays easy. Baseline: large — vertical-slice locality expected.

What to do

1. Improve Navigability — currently 8.2/10. — 87 % of calls cross a namespace and 12 % go through an interface, but 100 % of collaborators are co-located — so a call's collaborators sit together and tracing stays easy. Baseline: large — vertical-slice locality expected.

Detailed fixes: d27_recommendation.md.

What it measures: Whether any secrets were ever committed — scanned across the full git history, not just now.

Method: Git-history secret scan via gitleaks detect over full history in an isolated checkout; each match flagged High. Exhaustive; degrades cleanly when tool absent.

Maturity: Documented → Verified → Prevented · effective 9.0 / 10 · rule-coverage 100% · ceiling Documented

1 finding(s): 0 critical, 1 high, 0 medium, 0 low. Remediation for historically-committed secrets is credential rotation — they remain in history regardless of later deletion.

✓ On the Gold path — maintain.

Detailed fixes: d28_recommendation.md · top locations in Appendix A, every location in findings.md.

What it measures: Real static-analysis (SAST) findings — likely security bugs in the code, any language.

Method: Polyglot static analysis via semgrep across the repo using the pinned, image-baked p/security-audit + p/owasp-top-ten rulesets (no scan-time registry fetch); severity rules (ERROR/WARNING/INFO) map to a full-band severity-weighted score. Exhaustive, deterministic; degrades on parse failure.

Coverage: semgrep pattern rules over all files — exhaustive for the rule set, blind to classes of bug without a rule (clean = no rule matched).

Maturity: Documented → Verified → Prevented · effective 5.0 / 10 · rule-coverage 100% · ceiling Documented

4 finding(s): 0 critical, 4 high, 0 medium, 0 low.

What to do

1. Resolve the 4 High finding(s) in Static Analysis (SAST) — start with SigningHelper.cs (2), BinarySerializer.cs, SerializationHelper.cs. — One of this dimension's main actionable groups (4 issue-level).

Detailed fixes: d29_recommendation.md · top locations in Appendix A, every location in findings.md.

What it measures: Whether anyone still has living knowledge of each file, or it has been orphaned — last understood long ago by someone now gone quiet. The sibling of the bus factor: D16 asks who owns it, D34 asks whether anyone still knows it.

Method: File orphaning as total living-knowledge decay below one focused-commit's worth within a year, computed per-file from the D16 decay model. Exhaustive, deterministic over fixed history.

Maturity: Documented → Verified → Prevented · effective 0.0 / 10 · rule-coverage 100% · ceiling Documented

274 of 274 significant source file(s) are orphaned — their living knowledge has decayed to nothing, so no one currently understands them. The largest is src/Foundation.ContentTypes/ContentType.cs.

What to do

1. Resolve the 3 Largest orphaned file finding(s) in Knowledge Freshness — start with ContentType.cs, SqlServerDocumentProvider.cs, CosmosSqlProviderV2.cs. — One of this dimension's main actionable groups (3 recommendation-level).
2. Resolve the 1 Dormant codebase finding(s) in Knowledge Freshness. — One of this dimension's main actionable groups (1 recommendation-level).

Detailed fixes: d34_recommendation.md · top locations in Appendix A, every location in findings.md.

What it measures: Whether files that change together actually belong together — pairs that repeatedly co-change in git history despite having no explicit code dependency, surfacing the hidden/logical coupling (and boundaries in the wrong place) a static scan can't see.

Method: Pairwise co-occurrence over the per-commit file sets in git history (production source only — tests and generated dropped): Degree-of-Coupling = shared ÷ min individual revisions, reported above noise floors (each file ≥10 revisions, ≥5 shared commits, ≥50% strength); sweeping commits excluded. Deterministic over fixed history.

Coverage: Population: PRODUCTION source files only — test and generated files are dropped before pairing, so a class co-changing with its own test (trivially ~100%) can't drown the real production↔production coupling. Pairs ranked by Degree-of-Coupling; coupling through a build step, config, or non-source file isn't seen.

Maturity: Documented → Verified → Prevented · effective 9.6 / 10 · rule-coverage 100% · ceiling Documented

Strongest change-coupling: ISqlBuilder.cs↔SqlServerDocumentProvider.cs 100%; CommandRequestWrapper.cs↔MediatorDispatcherCommandRequestExtension.cs 73%; AsyncLocalScope.cs↔IScopeManager.cs 73%

✓ On the Gold path — maintain.

Detailed fixes: d35_recommendation.md · top locations in Appendix A, every location in findings.md.

What it measures: Whether the build pipeline provides supply-chain integrity — generated provenance/attestation, signed artifacts (cosign/sigstore), an SBOM, and pinned build actions. Presence of the configuration, not a runtime guarantee.

Method: Supply-chain provenance/signing read deterministically from CI/build config (.github/workflows, .gitlab-ci.yml, azure-pipelines, Jenkinsfile, .circleci) + the release surface: four signals — generated provenance/attestation (SLSA/in-toto/actions-attest), artifact signing (cosign/sigstore/gitsign), an SBOM (syft/sbom-action/*.spdx.json/*.cdx.json), and SHA-pinned build actions — scored 10·present/denom. NotApplicable without a build pipeline. Detects configuration presence, not runtime enforcement.

Maturity: Documented → Verified → Prevented · effective 0.0 / 10 · rule-coverage 100% · ceiling Documented

0/3 supply-chain integrity signals present (provenance, signing, SBOM).

What to do

1. Resolve the 1 No build provenance finding(s) in Supply-chain Provenance & Signing. — One of this dimension's main actionable groups (1 recommendation-level).
2. Resolve the 1 No artifact signing finding(s) in Supply-chain Provenance & Signing. — One of this dimension's main actionable groups (1 recommendation-level).
3. Resolve the 1 No SBOM finding(s) in Supply-chain Provenance & Signing. — One of this dimension's main actionable groups (1 recommendation-level).

Detailed fixes: d36_recommendation.md · top locations in Appendix A, every location in findings.md.

Other · Architecture — Whether any singleton service captures a scoped/transient dependency — a silent lifetime/threading bug.

Method: Roslyn scan: DI registrations parsed from AddSingleton/Scoped/Transient; each singleton checked for captured shorter-lifetime dependencies. Exhaustive, deterministic.

Other · Architecture — How the codebase splits by code ROLE — domain, application, infrastructure, test, generated. The significance map behind the knowledge/coupling weighting, and a DDD signal in its own right: a thin domain core under fat infrastructure is the anemic-domain smell, quantified.

Method: Roslyn line-count by code ROLE: every source file classified Domain/Application/Infrastructure/Test/Generated by namespace + path convention (the shared CodeRoleClassifier), then significant lines summed per role. Deterministic; the advisory score is the business-logic (domain+application) share of production code.

Coverage: Population: ALL source files, each bucketed into ONE of five roles (Domain/Application/Infrastructure/Test/Generated) by namespace + path convention — a file whose layer isn't named in the convention falls to Application (the neutral default), and the split is line-count, not semantic depth or business value.

Other · Architecture — Whether singleton services avoid mutable shared instance state that concurrent callers would race on.

Method: Roslyn scan: singleton field mutations unguarded by lock or Interlocked, per type; syntax-based guard detection. Deterministic, traceable per field.

• `ServiceDiscoveryHostedService` is a singleton (one shared instance) but mutates instance state outside any lock (serviceAddress; e.g. `serviceAddress` at line 59). — ServiceDiscoveryHostedService.cs:15
• `CommandRequestRegistration` is a singleton (one shared instance) but mutates instance state outside any lock (route; e.g. `route` at line 26). — CommandRequestRegistration.cs:12

What to do

• Keep singletons stateless or back their state with thread-safe types (Concurrent*/Immutable*); otherwise concurrent callers race.

Other · Architecture — Whether the project-reference graph is acyclic (cycles block independent build/deploy and signal eroding boundaries).

Method: Project reference cycles via elementary-DFS over real .csproj references, using the engine shared with D5/D7; cyclic versus acyclic. Exhaustive, deterministic.

Other · Architecture — Whether dependencies point inward (Domain ← Application ← Infrastructure/Web) — the clean-architecture dependency rule, checked across the project graph.

Method: Layer violations by name-segment inference (Domain/Core to Application to Infrastructure/Web) over the project-reference graph. Exhaustive over all projects, deterministic.

• `Sample.Application.Web2` is a Application project but references `Commands.Infrastructure.FileStorage`, a Infrastructure project. The clean-architecture rule is that dependencies point INWARD — the domain/application core must not depend on outer layers (infrastructure/web). Invert it: define the abstraction in the inner layer and implement it in the outer one.
• `Sample.Application.Web2` is a Application project but references `FileStorage.Infrastructure.Azure`, a Infrastructure project. The clean-architecture rule is that dependencies point INWARD — the domain/application core must not depend on outer layers (infrastructure/web). Invert it: define the abstraction in the inner layer and implement it in the outer one.
• `Sample.Application.Web2` is a Application project but references `Operations.Infrastructure.Azure`, a Infrastructure project. The clean-architecture rule is that dependencies point INWARD — the domain/application core must not depend on outer layers (infrastructure/web). Invert it: define the abstraction in the inner layer and implement it in the outer one.
• `Sample.Application.Web2` is a Application project but references `Operations.Infrastructure.Mongo`, a Infrastructure project. The clean-architecture rule is that dependencies point INWARD — the domain/application core must not depend on outer layers (infrastructure/web). Invert it: define the abstraction in the inner layer and implement it in the outer one.
• `Sample.Application.Web2` is a Application project but references `Tracing.Infrastructure.Zipkin`, a Infrastructure project. The clean-architecture rule is that dependencies point INWARD — the domain/application core must not depend on outer layers (infrastructure/web). Invert it: define the abstraction in the inner layer and implement it in the outer one.
• `Sample.Application.Web` is a Application project but references `Commands.Infrastructure.FileStorage`, a Infrastructure project. The clean-architecture rule is that dependencies point INWARD — the domain/application core must not depend on outer layers (infrastructure/web). Invert it: define the abstraction in the inner layer and implement it in the outer one.
• `Sample.Application.Web` is a Application project but references `FileStorage.Infrastructure.Azure`, a Infrastructure project. The clean-architecture rule is that dependencies point INWARD — the domain/application core must not depend on outer layers (infrastructure/web). Invert it: define the abstraction in the inner layer and implement it in the outer one.
• `Sample.Application.Web` is a Application project but references `Operations.Infrastructure.Azure`, a Infrastructure project. The clean-architecture rule is that dependencies point INWARD — the domain/application core must not depend on outer layers (infrastructure/web). Invert it: define the abstraction in the inner layer and implement it in the outer one.
• `Sample.Application.Web` is a Application project but references `Operations.Infrastructure.Mongo`, a Infrastructure project. The clean-architecture rule is that dependencies point INWARD — the domain/application core must not depend on outer layers (infrastructure/web). Invert it: define the abstraction in the inner layer and implement it in the outer one.
• `Sample.Application.Web` is a Application project but references `Tracing.Infrastructure.Zipkin`, a Infrastructure project. The clean-architecture rule is that dependencies point INWARD — the domain/application core must not depend on outer layers (infrastructure/web). Invert it: define the abstraction in the inner layer and implement it in the outer one.
• `Tracing.Application.Zipkin` is a Application project but references `Tracing.Infrastructure.Zipkin`, a Infrastructure project. The clean-architecture rule is that dependencies point INWARD — the domain/application core must not depend on outer layers (infrastructure/web). Invert it: define the abstraction in the inner layer and implement it in the outer one.
• `Queueing.Application.RabbitMQ` is a Application project but references `Infrastructure.RabbitMQ`, a Infrastructure project. The clean-architecture rule is that dependencies point INWARD — the domain/application core must not depend on outer layers (infrastructure/web). Invert it: define the abstraction in the inner layer and implement it in the outer one.
• `Queueing.Application.RabbitMQ` is a Application project but references `Queueing.Infrastructure.RabbitMQ`, a Infrastructure project. The clean-architecture rule is that dependencies point INWARD — the domain/application core must not depend on outer layers (infrastructure/web). Invert it: define the abstraction in the inner layer and implement it in the outer one.
• `Queueing.Application.Azure` is a Application project but references `Infrastructure.Azure.ServiceBus`, a Infrastructure project. The clean-architecture rule is that dependencies point INWARD — the domain/application core must not depend on outer layers (infrastructure/web). Invert it: define the abstraction in the inner layer and implement it in the outer one.
• `Queueing.Application.Azure` is a Application project but references `Infrastructure.Azure`, a Infrastructure project. The clean-architecture rule is that dependencies point INWARD — the domain/application core must not depend on outer layers (infrastructure/web). Invert it: define the abstraction in the inner layer and implement it in the outer one.
• `Queueing.Application.Azure` is a Application project but references `Queueing.Infrastructure.Azure`, a Infrastructure project. The clean-architecture rule is that dependencies point INWARD — the domain/application core must not depend on outer layers (infrastructure/web). Invert it: define the abstraction in the inner layer and implement it in the outer one.
• `Operations.Application.Web` is a Application project but references `Infrastructure.Azure`, a Infrastructure project. The clean-architecture rule is that dependencies point INWARD — the domain/application core must not depend on outer layers (infrastructure/web). Invert it: define the abstraction in the inner layer and implement it in the outer one.
• `Operations.Application.Web` is a Application project but references `FileStorage.Infrastructure.Azure`, a Infrastructure project. The clean-architecture rule is that dependencies point INWARD — the domain/application core must not depend on outer layers (infrastructure/web). Invert it: define the abstraction in the inner layer and implement it in the outer one.
• `Operations.Application.Web` is a Application project but references `FileStorage.Infrastructure.FileSystem`, a Infrastructure project. The clean-architecture rule is that dependencies point INWARD — the domain/application core must not depend on outer layers (infrastructure/web). Invert it: define the abstraction in the inner layer and implement it in the outer one.
• `Operations.Application.Web` is a Application project but references `Utilities.Web`, a Web project. The clean-architecture rule is that dependencies point INWARD — the domain/application core must not depend on outer layers (infrastructure/web). Invert it: define the abstraction in the inner layer and implement it in the outer one.
• `Messaging.Application.RabbitMQ` is a Application project but references `Infrastructure.RabbitMQ`, a Infrastructure project. The clean-architecture rule is that dependencies point INWARD — the domain/application core must not depend on outer layers (infrastructure/web). Invert it: define the abstraction in the inner layer and implement it in the outer one.
• `Messaging.Application.RabbitMQ` is a Application project but references `Messaging.Infrastructure.RabbitMQ`, a Infrastructure project. The clean-architecture rule is that dependencies point INWARD — the domain/application core must not depend on outer layers (infrastructure/web). Invert it: define the abstraction in the inner layer and implement it in the outer one.
• `Messaging.Application.FileStorage` is a Application project but references `FileStorage.Infrastructure.FileSystem`, a Infrastructure project. The clean-architecture rule is that dependencies point INWARD — the domain/application core must not depend on outer layers (infrastructure/web). Invert it: define the abstraction in the inner layer and implement it in the outer one.
• `Messaging.Application.FileStorage` is a Application project but references `Messaging.Infrastructure.FileStorage`, a Infrastructure project. The clean-architecture rule is that dependencies point INWARD — the domain/application core must not depend on outer layers (infrastructure/web). Invert it: define the abstraction in the inner layer and implement it in the outer one.
• `Messaging.Application.Azure` is a Application project but references `Messaging.Infrastructure.Azure`, a Infrastructure project. The clean-architecture rule is that dependencies point INWARD — the domain/application core must not depend on outer layers (infrastructure/web). Invert it: define the abstraction in the inner layer and implement it in the outer one.
• `Messaging.Application.Azure.SignalR` is a Application project but references `Messaging.Infrastructure.Azure.SignalR`, a Infrastructure project. The clean-architecture rule is that dependencies point INWARD — the domain/application core must not depend on outer layers (infrastructure/web). Invert it: define the abstraction in the inner layer and implement it in the outer one.
• `Application.Web.Startup.EntityFramework` is a Application project but references `Infrastructure.EntityFramework`, a Infrastructure project. The clean-architecture rule is that dependencies point INWARD — the domain/application core must not depend on outer layers (infrastructure/web). Invert it: define the abstraction in the inner layer and implement it in the outer one.
• `Configuration.Application` is a Application project but references `Infrastructure.Azure.KeyVault`, a Infrastructure project. The clean-architecture rule is that dependencies point INWARD — the domain/application core must not depend on outer layers (infrastructure/web). Invert it: define the abstraction in the inner layer and implement it in the outer one.
• `Commands.Application.Web` is a Application project but references `Utilities.Web`, a Web project. The clean-architecture rule is that dependencies point INWARD — the domain/application core must not depend on outer layers (infrastructure/web). Invert it: define the abstraction in the inner layer and implement it in the outer one.
• `Commands.Application.Web` is a Application project but references `Queueing.Infrastructure.Azure`, a Infrastructure project. The clean-architecture rule is that dependencies point INWARD — the domain/application core must not depend on outer layers (infrastructure/web). Invert it: define the abstraction in the inner layer and implement it in the outer one.
• `Commands.Application.Web` is a Application project but references `FileStorage.Infrastructure.Azure`, a Infrastructure project. The clean-architecture rule is that dependencies point INWARD — the domain/application core must not depend on outer layers (infrastructure/web). Invert it: define the abstraction in the inner layer and implement it in the outer one.
• `Commands.Application.Web` is a Application project but references `FileStorage.Infrastructure.FileSystem`, a Infrastructure project. The clean-architecture rule is that dependencies point INWARD — the domain/application core must not depend on outer layers (infrastructure/web). Invert it: define the abstraction in the inner layer and implement it in the outer one.
• `Commands.Application.Web.RabbitMQ` is a Application project but references `Infrastructure.RabbitMQ`, a Infrastructure project. The clean-architecture rule is that dependencies point INWARD — the domain/application core must not depend on outer layers (infrastructure/web). Invert it: define the abstraction in the inner layer and implement it in the outer one.
• `Commands.Application.Web.RabbitMQ` is a Application project but references `Queueing.Infrastructure.RabbitMQ`, a Infrastructure project. The clean-architecture rule is that dependencies point INWARD — the domain/application core must not depend on outer layers (infrastructure/web). Invert it: define the abstraction in the inner layer and implement it in the outer one.
• `Commands.Application.Web.Azure` is a Application project but references `Queueing.Infrastructure.Azure`, a Infrastructure project. The clean-architecture rule is that dependencies point INWARD — the domain/application core must not depend on outer layers (infrastructure/web). Invert it: define the abstraction in the inner layer and implement it in the outer one.

What to do

• Keep dependencies pointing inward: domain/application define interfaces, infrastructure/web implement them (Dependency Inversion).

Other · Architecture — Whether the codebase has a recognisable, scale-appropriate structure (a named architectural style, or modular enough for its size) rather than being an ad-hoc ball of mud.

Method: Roslyn plus csproj analysis: architecture style detection (DDD, clean, vertical-slice, CQRS) and structure fitness for repo size. Deterministic.

Other · Architecture — Whether interfaces stay focused rather than fat — the Interface-Segregation principle (SOLID 'I').

Method: Roslyn scan: public interface member counts; fat-interface threshold (over 15 members) flagged per type. Deterministic, type-level.

• `IQueueItem<TData>` declares 19 members. A wide interface forces every implementer and caller to depend on methods they don't use (the Interface-Segregation 'I' in SOLID). Split it into focused role-interfaces. — IQueueItem.cs:7
• `ISpan` declares 25 members. A wide interface forces every implementer and caller to depend on methods they don't use (the Interface-Segregation 'I' in SOLID). Split it into focused role-interfaces. — ISpan.cs:7
• `IDocumentProvider<T>` declares 17 members. A wide interface forces every implementer and caller to depend on methods they don't use (the Interface-Segregation 'I' in SOLID). Split it into focused role-interfaces. — IDocumentProvider.cs:9

What to do

• Split fat interfaces into focused role-interfaces so clients depend only on what they use.

Other · Architecture — Whether production projects stay free of references to test projects — tests may depend on production, never the reverse.

Method: Csproj graph: each production project checked for references to test projects (identified by test-framework presence, not name). Zero violations is clean. Deterministic.

Other · Architecture — Whether read (query) handlers stay side-effect-free — a query that writes persistent state or raises events breaks CQS and makes reads unsafe to retry, cache, or route to a read replica.

Method: Roslyn scan: CQRS handlers classified query-vs-command by interface (IQueryHandler/ICommandHandler/IRequestHandler<TQuery,TResult>) and name convention (*Query/Get*/Find* vs *Command); each query handler's body checked for persistent-state writes (SaveChanges/repository Add-Update) or event publishes by resolved invocation. Deterministic, type-level, exhaustive over the detected handlers.

Coverage: Population: CQRS handlers identified by IQueryHandler/ICommandHandler/IRequestHandler interface + *Query/Get*/Find*/*Command NAME convention; query purity then checked exhaustively within that set — a query handler using neither convention is invisible, and mutation is a resolved persistence/publish CALL, not full dataflow.

• `Application.MessagingConsoleCommandEventHandler` is a read (query) handler but its body raises events — a query must stay side-effect-free so reads are safe to retry, cache, and route to a read replica. — MessagingConsoleCommandEventHandler.cs:12
• `Application.TracesConsoleCommandEventHandler` is a read (query) handler but its body writes persistent state — a query must stay side-effect-free so reads are safe to retry, cache, and route to a read replica. — TracesConsoleCommandEventHandler.cs:12

What to do

• Keep query handlers read-only — move the writes/event-publishes into a command handler so reads stay safe to retry, cache, and route to a read replica.

Other · Security — Whether access is authorized by default — a framework authorization attribute/decorator or policy, or imperative guard methods (throw-on-violation) called from handlers.

Method: Roslyn scan: [Authorize] usage and authorization policies, plus imperative throw-on-violation guard methods detected via syntax. Deterministic.

Other · Domain Modelling — Whether aggregates reference each other by identity (id) rather than by direct object reference — the core DDD consistency-boundary rule.

Method: Roslyn (DDD-gated): aggregate roots identified by convention; each aggregate field checked for direct references to other aggregates versus id-only. Deterministic, DDD-native.

Coverage: Population: aggregate roots identified by AggregateRoot/IAggregateRoot base/interface NAME convention; reference-by-identity then checked exhaustively within that set — a root not using those names is invisible.

Other · Domain Modelling — How much of the domain uses strongly-typed ids vs raw Guid/string/int — adoption curve, not all-or-nothing.

Method: Roslyn (DDD-gated): strongly-typed id adoption on domain entities/events; raw Guid/int/string ids counted versus wrapped types. Deterministic, adoption percentage.

Coverage: Population: id-like members by *Id/*Key NAME suffix; strongly-typed-ID shape then checked semantically — non-suffixed identifiers are not seen.

• `DomainEventBase.EventId` is a raw `Guid` — give it a strongly-typed id: a dedicated single-field type wrapping the `Guid`, in whatever form your language spells that. — DomainEventBase.cs:34
• `DomainEventBase.CorrelationId` is a raw `String` — give it a strongly-typed id: a dedicated single-field type wrapping the `String`, in whatever form your language spells that. — DomainEventBase.cs:42
• `TenantEntity.TenantId` is a raw `String` — give it a strongly-typed id: a dedicated single-field type wrapping the `String`, in whatever form your language spells that. — TenantEntity.cs:14
• `Message.CorrelationId` is a raw `String` — give it a strongly-typed id: a dedicated single-field type wrapping the `String`, in whatever form your language spells that. — Message.cs:58
• `LogEvent.Key` is a raw `String` — give it a strongly-typed id: a dedicated single-field type wrapping the `String`, in whatever form your language spells that. — LogEvent.cs:36
• `LogEvent.CorrelationId` is a raw `String` — give it a strongly-typed id: a dedicated single-field type wrapping the `String`, in whatever form your language spells that. — LogEvent.cs:46
• `LogEvent.TrackId` is a raw `String` — give it a strongly-typed id: a dedicated single-field type wrapping the `String`, in whatever form your language spells that. — LogEvent.cs:58
• `Command.CorrelationId` is a raw `String` — give it a strongly-typed id: a dedicated single-field type wrapping the `String`, in whatever form your language spells that. — Command.cs:26
• `LogTrace.Key` is a raw `String` — give it a strongly-typed id: a dedicated single-field type wrapping the `String`, in whatever form your language spells that. — LogTrace.cs:36
• `LogTrace.CorrelationId` is a raw `String` — give it a strongly-typed id: a dedicated single-field type wrapping the `String`, in whatever form your language spells that. — LogTrace.cs:46
• `LogTrace.TrackId` is a raw `String` — give it a strongly-typed id: a dedicated single-field type wrapping the `String`, in whatever form your language spells that. — LogTrace.cs:58
• `LogTrace.TraceId` is a raw `String` — give it a strongly-typed id: a dedicated single-field type wrapping the `String`, in whatever form your language spells that. — LogTrace.cs:62
• `LogTrace.SpanId` is a raw `String` — give it a strongly-typed id: a dedicated single-field type wrapping the `String`, in whatever form your language spells that. — LogTrace.cs:64
• `LogTrace.ParentSpanId` is a raw `String` — give it a strongly-typed id: a dedicated single-field type wrapping the `String`, in whatever form your language spells that. — LogTrace.cs:66

What to do

• Adopt strongly-typed ids across the domain — finish the migration or document the boundary; primitive ids invite transposed-argument bugs.

Other · Domain Modelling — Whether aggregates/entities carry the behaviour that protects their invariants, rather than being data bags driven by external services.

Method: Roslyn (DDD-gated): entity method BODIES classified mutator-vs-query — only methods that mutate the entity's own declared state count as invariant-protecting behaviour, so a getter/passthrough doesn't rescue an anemic class. Deterministic, exhaustive over domain-layer entities.

Coverage: Population: entities by name/base convention; rich-vs-anemic judged by classifying each method body mutator-vs-query — logic-bearing domain types outside the convention are invisible.

• `AggregateRoot` is an aggregate/entity with 1 data propert(ies) but no state-changing behaviour (only data and queries) — the business logic lives in a service. — AggregateRoot.cs:30
• `EchoEntity` is an aggregate/entity with 1 data propert(ies) but no state-changing behaviour (only data and queries) — the business logic lives in a service. — EchoEntity.cs:3
• `TenantAggregateRoot` is an aggregate/entity with 1 data propert(ies) but no state-changing behaviour (only data and queries) — the business logic lives in a service. — TenantAggregateRoot.cs:30
• `TenantEntity` is an aggregate/entity with 1 data propert(ies) but no state-changing behaviour (only data and queries) — the business logic lives in a service. — TenantEntity.cs:10
• `DummyMessage` is an aggregate/entity with 1 data propert(ies) but no state-changing behaviour (only data and queries) — the business logic lives in a service. — DummyMessage.cs:3
• `EchoMessage` is an aggregate/entity with 1 data propert(ies) but no state-changing behaviour (only data and queries) — the business logic lives in a service. — EchoMessage.cs:3
• `EntityMessage` is an aggregate/entity with 1 data propert(ies) but no state-changing behaviour (only data and queries) — the business logic lives in a service. — EntityMessage.cs:5
• `Message` is an aggregate/entity with 8 data propert(ies) but no state-changing behaviour (only data and queries) — the business logic lives in a service. — Message.cs:7
• `LogEvent` is an aggregate/entity with 16 data propert(ies) but no state-changing behaviour (only data and queries) — the business logic lives in a service. — LogEvent.cs:10
• `Command` is an aggregate/entity with 6 data propert(ies) but no state-changing behaviour (only data and queries) — the business logic lives in a service. — Command.cs:8
• `LogTrace` is an aggregate/entity with 28 data propert(ies) but no state-changing behaviour (only data and queries) — the business logic lives in a service. — LogTrace.cs:10

What to do

• Move business rules onto the aggregates/entities they govern so invariants are enforced at the source, not in anemic services.

Other · Domain Modelling — Whether entities protect their state (private/init-only setters) instead of exposing public setters that bypass invariants. Softened when a rehydration framework (Marten/EF) is present.

Method: Roslyn (DDD-gated): public setters on entities detected; score softened when Marten/EF rehydration frameworks present. Deterministic, framework-aware.

Coverage: Population: entities by convention; encapsulation (setter shape) checked exhaustively within the set.

• `EchoEntity` exposes publicly writable state (Text). — EchoEntity.cs:3
• `TenantEntity` exposes publicly writable state (TenantId). — TenantEntity.cs:10
• `DummyMessage` exposes publicly writable state (Data). — DummyMessage.cs:3
• `EchoMessage` exposes publicly writable state (Text). — EchoMessage.cs:3
• `EntityMessage` exposes publicly writable state (Entity). — EntityMessage.cs:5
• `Message` exposes publicly writable state (Id, Identifier, CorrelationId, Origin, Status). — Message.cs:7
• `LogEvent` exposes publicly writable state (Id, Level, Key, Environment, Message, Timestamp, …). — LogEvent.cs:10
• `Command` exposes publicly writable state (Id, CorrelationId, Request, CreatedBy, CreatedDate). — Command.cs:8
• `LogTrace` exposes publicly writable state (Id, Level, Key, Environment, Message, Timestamp, …). — LogTrace.cs:10

What to do

• Make entity setters private/init-only; change state only through methods that enforce the invariants (Marten/EF can bind via constructor or private setters).

Other · Domain Modelling — Whether the domain layer stays free of infrastructure dependencies (EF/Marten/HTTP/ASP.NET) — the clean-architecture dependency rule.

Method: Roslyn (DDD-gated): domain-layer types scanned for infrastructure usage in member SIGNATURES and inside method/accessor BODIES — resolved calls and object-creations into EF/Marten/HTTP/Mongo/Redis/message-bus types (not just a namespace allowlist). Deterministic, symbol-resolved, exhaustive over domain-layer bodies, DDD-native.

Coverage: Domain layer identified by NAMESPACE heuristic; infrastructure then resolved by symbol in member SIGNATURES and method/accessor BODIES — rename the layer and the check evaporates.

Other · Domain Modelling — Whether repositories are per aggregate root (not per child entity) so the root's invariants can't be bypassed.

Method: Roslyn (DDD-gated): repository abstraction detection; repositories over non-aggregate-root entities flagged. Deterministic, DDD-native.

Coverage: Population: repositories + aggregate roots by NAME convention; per-root repository rule checked within the set.

• `LogAnalyticsLogEventRepository` is a repository over `LogEvent`, which is an entity but not an aggregate root. Repositories should be per aggregate ROOT — loading/saving a child entity independently lets callers bypass the root's invariants. Access `LogEvent` through its owning aggregate instead. — LogAnalyticsLogEventRepository.cs:10
• `LogAnalyticsLogTraceRepository` is a repository over `LogTrace`, which is an entity but not an aggregate root. Repositories should be per aggregate ROOT — loading/saving a child entity independently lets callers bypass the root's invariants. Access `LogTrace` through its owning aggregate instead. — LogAnalyticsLogTraceRepository.cs:9
• `MongoLogEventRepository` is a repository over `LogEvent`, which is an entity but not an aggregate root. Repositories should be per aggregate ROOT — loading/saving a child entity independently lets callers bypass the root's invariants. Access `LogEvent` through its owning aggregate instead. — MongoLogEventRepository.cs:7
• `MongoLogTraceRepository` is a repository over `LogTrace`, which is an entity but not an aggregate root. Repositories should be per aggregate ROOT — loading/saving a child entity independently lets callers bypass the root's invariants. Access `LogTrace` through its owning aggregate instead. — MongoLogTraceRepository.cs:7

What to do

• Define repositories per aggregate root; reach child entities through their root so invariants can't be bypassed.

Other · Domain Modelling — Whether clusters of primitives that travel together (a missing value object) are extracted — a low-weight suggestion, LLM-confirmed when configured.

Method: Roslyn (DDD-gated): primitive parameter clusters recurring three or more times across signatures extracted, then confirmed by language model when configured. Advisory, low-weight.

Other · Event-Driven — Whether event handlers stay asynchronous (no blocking remote HTTP/gRPC calls awaited inside a handler).

Method: Roslyn semantic scan (event-driven gated): event-handler bodies scanned for HTTP/gRPC invocations by resolved symbol type, not substring. Deterministic, semantic-resolved.

Other · Event-Driven — Whether commands have a single handler (one owner of the decision) and fan-out is modelled with events.

Method: Roslyn scan (event-driven gated): command-shaped messages identified by convention; handler count per command checked for the exactly-one rule. Deterministic, hard fact.

Other · Event-Driven — Whether events are named in the past tense (a clarity nudge — low weight).

Method: Roslyn scan (event-driven gated): domain and integration events checked for past-tense naming (-ed/-en suffix or irregular set). Naming nudge, low-weight advisory.

• `DomainEventBase` reads as an instruction, not a fact that happened. Events describe something that already occurred — name them in the past tense (e.g. `OrderPlaced`, `PaymentCaptured`) so the ubiquitous language stays clear. (×2) — DomainEventBase.cs:5, DomainEventBase.cs:5
• `EntityDeleteDomainEvent` reads as an instruction, not a fact that happened. Events describe something that already occurred — name them in the past tense (e.g. `OrderPlaced`, `PaymentCaptured`) so the ubiquitous language stays clear. — EntityDeleteDomainEvent.cs:3
• `EntityInsertDomainEvent` reads as an instruction, not a fact that happened. Events describe something that already occurred — name them in the past tense (e.g. `OrderPlaced`, `PaymentCaptured`) so the ubiquitous language stays clear. — EntityInsertDomainEvent.cs:3
• `EntityUpdateDomainEvent` reads as an instruction, not a fact that happened. Events describe something that already occurred — name them in the past tense (e.g. `OrderPlaced`, `PaymentCaptured`) so the ubiquitous language stays clear. — EntityUpdateDomainEvent.cs:3
• `IDomainEvent` reads as an instruction, not a fact that happened. Events describe something that already occurred — name them in the past tense (e.g. `OrderPlaced`, `PaymentCaptured`) so the ubiquitous language stays clear. — IDomainEvent.cs:3

What to do

• Name events in the past tense — they record facts that already happened.

Other · Event-Driven — Whether state changes and message publishes are atomic (a transactional outbox) rather than a crash-unsafe dual write.

Method: Roslyn semantic scan (event-driven gated): event-handler methods scanned for DB-save plus bus-publish without a transactional outbox reference. Deterministic, semantic-resolved.

• `TracesConsoleCommandEventHandler.Handle` writes to the database while `MessagingConsoleCommandEventHandler.Handle` publishes to the message bus in the same command-handling flow, with no outbox referenced on either path. Splitting the persist and the publish across sibling methods (or two collaborating actors) doesn't make them atomic — a crash between the two either loses the message or emits a phantom event. Use the transactional outbox pattern so the message is committed in the same transaction as the state change and dispatched afterwards. — TracesConsoleCommandEventHandler.cs:23

What to do

• Adopt the transactional outbox pattern so DB writes and message publishes commit atomically — no lost or phantom events on a crash.

Other · Readiness — Whether retry-prone mutations (command handlers + message/event consumers) are idempotent so an at-least-once redelivery or client retry doesn't double-apply the effect — heuristic at-risk detection confirmed by language model, advisory.

Method: Roslyn heuristic (any mutation, ungated): command handlers and message/event consumers that mutate persistent state without a visible idempotency guard (exists/dedup check, upsert, idempotency-key/inbox, conditional/versioned write, fixed-value set) flagged as at-risk; each at-risk candidate then confirmed or cleared by a language model as genuinely non-idempotent versus naturally-idempotent. Advisory without a model (heuristic-only, degraded), per-candidate judged with one.

Coverage: Population: retry-prone mutations — command handlers (CQRS write side) + message/event consumers (IConsumer/I*EventHandler) — that mutate persistent state; runs on any repo with mutations, not only event-driven ones. The at-risk subset (no obvious guard) is a HEURISTIC candidate set, each then LLM-JUDGED non-idempotent vs safe; a handler outside those conventions, or a guard the LLM can't confirm, is bounded by the sample. Degrades to heuristic-only when no model is configured.

Other · Code Health — Unreviewed-generation residue: shipped members still throwing NotImplementedException, and placeholder string literals left in non-test, non-generated code. Scored as a quality signature, never as a claim about authorship.

Method: Roslyn syntax scan: NotImplementedException throws and placeholder string literals in non-test, non-generated shipped code. Deterministic, code-shape signature.

• A shipped member still throws NotImplementedException — generated scaffolding that was never completed. Implement it or remove the dead surface. (×21) — CosmosSqlProviderV3.cs:180, LogAnalyticsRepository.cs:95, LogAnalyticsRepository.cs:100, …

What to do

• Finish or delete NotImplementedException stubs and replace placeholder literals before shipping.

Other · Code Health — Unfinished work detected by code SHAPE, not keywords: members that only throw a "not implemented" exception, methods that take inputs and return a constant, async methods that never await, dead `if (false)` / `#if false` branches, and skeleton types most of whose members are holes. A real, objective slice of technical debt.

Method: Roslyn syntax scan: incompleteness by code shape (constant-returning methods, async-never-await, #if false branches, skeleton types), not keyword-gated. Deterministic, code-shape heuristic.

• `GetSecretsWithHttpMessagesAsync` is a shipped member whose whole body throws NotImplementedException — scaffolding that was never completed. Implement it or remove the dead surface. — CachedKeyVaultClient.cs:48
• `GetSecretWithHttpMessagesAsync` is a shipped member whose whole body throws NotImplementedException — scaffolding that was never completed. Implement it or remove the dead surface. — CachedKeyVaultClient.cs:57
• `RenameFileAsync` is a shipped member whose whole body throws NotImplementedException — scaffolding that was never completed. Implement it or remove the dead surface. (×3) — AzureFileShareStorage.cs:141, AzureKeyVaultFileStorage.cs:54, EmbeddedFileStorage.cs:90
• `AzureKeyVaultFileStorage` has 10 unfinished members out of 10 — a scaffolded type that was never implemented. — AzureKeyVaultFileStorage.cs:9
• `CopyFileAsync` is a shipped member whose whole body throws NotImplementedException — scaffolding that was never completed. Implement it or remove the dead surface. (×2) — AzureKeyVaultFileStorage.cs:14, EmbeddedFileStorage.cs:95
• `DeleteFileAsync` is a shipped member whose whole body throws NotImplementedException — scaffolding that was never completed. Implement it or remove the dead surface. (×2) — AzureKeyVaultFileStorage.cs:19, EmbeddedFileStorage.cs:100
• `DeleteFilesAsync` is a shipped member whose whole body throws NotImplementedException — scaffolding that was never completed. Implement it or remove the dead surface. (×2) — AzureKeyVaultFileStorage.cs:24, EmbeddedFileStorage.cs:105
• `Dispose` is a shipped member whose whole body throws NotImplementedException — scaffolding that was never completed. Implement it or remove the dead surface. — AzureKeyVaultFileStorage.cs:29
• `ExistsAsync` is a shipped member whose whole body throws NotImplementedException — scaffolding that was never completed. Implement it or remove the dead surface. — AzureKeyVaultFileStorage.cs:34
• `GetFileInformationAsync` is a shipped member whose whole body throws NotImplementedException — scaffolding that was never completed. Implement it or remove the dead surface. — AzureKeyVaultFileStorage.cs:39
• `GetFileInformationsAsync` is a shipped member whose whole body throws NotImplementedException — scaffolding that was never completed. Implement it or remove the dead surface. — AzureKeyVaultFileStorage.cs:44
• `GetFileStreamAsync` is a shipped member whose whole body throws NotImplementedException — scaffolding that was never completed. Implement it or remove the dead surface. — AzureKeyVaultFileStorage.cs:49
• `SaveFileAsync` is a shipped member whose whole body throws NotImplementedException — scaffolding that was never completed. Implement it or remove the dead surface. (×2) — AzureKeyVaultFileStorage.cs:59, EmbeddedFileStorage.cs:85
• `GetDirectoryContents` is a shipped member whose whole body throws NotImplementedException — scaffolding that was never completed. Implement it or remove the dead surface. — FileStorageProvider.cs:21
• `InMemoryEventStore` has 2 unfinished members out of 4 — a scaffolded type that was never implemented. — InMemoryEventStore.cs:7
• `ReadSnapshotAsync` is a shipped member whose whole body throws NotImplementedException — scaffolding that was never completed. Implement it or remove the dead surface. — InMemoryEventStore.cs:32
• `SaveSnapshotAsync` is a shipped member whose whole body throws NotImplementedException — scaffolding that was never completed. Implement it or remove the dead surface. — InMemoryEventStore.cs:38
• `FindAllAsync` is declared `async` but never awaits anything, so it runs synchronously while pretending to be asynchronous. Drop `async` or do the real async work. — DocumentRepository.cs:85
• `FindOneAsync` is declared `async` but never awaits anything, so it runs synchronously while pretending to be asynchronous. Drop `async` or do the real async work. — DocumentRepository.cs:113
• `WhereAsync` is a shipped member whose whole body throws NotImplementedException — scaffolding that was never completed. Implement it or remove the dead surface. — CosmosSqlProviderV3.cs:171
• `CountAsync` is a shipped member whose whole body throws NotImplementedException — scaffolding that was never completed. Implement it or remove the dead surface. (×3) — LogAnalyticsRepository.cs:93, LogAnalyticsRepository.cs:98, LogAnalyticsRepository.cs:103
• `SqlEventStore` has 4 unfinished members out of 4 — a scaffolded type that was never implemented. — SqlEventStore.cs:8

What to do

• Finish or delete the unfinished stubs (NotImplementedException / empty / constant-returning bodies) — they are dead surface that looks live.
• Clear the softer debt: remove commented-out code and dead branches, re-enable or delete skipped tests, and replace blanket warning suppressions with targeted ones.

Maturity · Maturity — Whether the repo and its projects have a README, and whether it's substantive and current.

Method: Filesystem scan: README presence, word count, and headings for depth; git history for staleness. Exhaustive across root and project dirs, deterministic.

What to do

• Add a 'Testing' section to the root README — how to run the test suite.
• Add a README to the 107 of 109 project(s) that lack one — worth up to 2 pts.

Maturity · Maturity — Whether key decisions (ADRs) and the high-level shape (C4/diagrams) are written down.

Method: Filesystem scan: ADR folder/naming conventions or content, plus Mermaid/PlantUML/C4/architecture.md discovery. Exhaustive, deterministic.

• No Architecture Decision Records found — decisions aren't captured for future maintainers.

What to do

• Start an ADR log (docs/adr/) recording significant decisions and their rationale.

Maturity · Maturity — Whether the repo is organised deliberately — src/test separation and consistent project naming.

Method: Filesystem scan: src/test folder separation and namespace-prefix consistency (majority RootNamespace agreement). Exhaustive across projects, deterministic.

Maturity · Maturity — Whether the README actually describes the code that exists (LLM-judged, advisory).

Method: Judged by language model at low temperature: README accuracy versus actual projects, within a disclosed tolerance. Advisory, not a measured number.

• README advertises a microservices architecture, but the repo is a single project with no service manifests

What to do

• Reconcile the README with reality: README advertises a microservices architecture, but the repo is a single project with no service manifests.

Readiness · Readiness — Whether an automated pipeline builds and tests every change.

Method: Filesystem scan: CI workflow files (.github/workflows, .gitlab-ci.yml, etc.) for build and test stages. Exhaustive, deterministic.

Readiness · Readiness — Whether the code is diagnosable in production — structured logging, tracing/metrics, health checks.

Method: Filesystem/Roslyn scan: structured-logging frameworks (Serilog, NLog), OpenTelemetry, and health-check endpoint patterns. Exhaustive, deterministic.

• Only 87/90 service-like projects use logging (pure contract/DTO projects are excluded — they have nothing to log).

What to do

• Extend structured logging to the remaining service-like projects so the whole executable surface is diagnosable in production.

Readiness · Readiness — Whether SAST, secret/dependency scanning and performance benchmarking are wired in (presence, not runtime).

Method: Filesystem scan: SAST configuration, dependency-update automation, secret scanning, and a benchmark harness or benchmark step — in this repository's own ecosystem. Exhaustive, deterministic.

What to do

• Enable Dependabot/Renovate or a dependency-review gate.
• Add gitleaks/trufflehog in CI to block PRs that introduce committed secrets.

Readiness · Readiness — Whether releases are automated and safely reversible (probes, rolling updates, approval gates) — from manifests/pipeline files, not the live environment.

Method: Filesystem scan: deployment manifests/IaC (K8s YAML, Helm, Terraform) for rolling updates, probes, approval gates, migration hooks. Exhaustive, deterministic.

• Deployment automation exists but no readiness/liveness probes, rolling-update strategy, lifecycle hooks or migration job were evidenced — a bad release is harder to detect and reverse.

What to do

• Add readiness/liveness probes and a rolling-update (or blue/green) strategy so a bad release is caught and rolled back automatically.
• The pipeline declares a deployment environment, but whether required reviewers / protection rules are attached to it lives in repository settings we cannot read — confirm the gate is enforced before production promotion.

Readiness · Readiness — Whether releases are traceable — a maintained changelog and explicit version stamping.

Method: Filesystem scan: changelog file presence and version tags in csproj or git tags. Exhaustive, deterministic.

• No CHANGELOG/HISTORY/RELEASES file — what shipped when isn't easy to reconstruct for support or audit. (Versioning/tagging makes releases traceable, but a changelog records the what.)

What to do

• Keep a changelog (e.g. Keep-a-Changelog) recording what shipped in each release.

Readiness · Readiness — Whether outbound HTTP calls are wrapped in resilience (retry/timeout/circuit-breaker) so a failing dependency doesn't cascade.

Method: Roslyn scan: Polly resilience markers (Retry, CircuitBreaker, Timeout) on outbound HTTP invocations. Computed per type, deterministic.

Readiness · Readiness — Whether EF Core schema changes go through versioned migrations rather than the un-evolvable EnsureCreated().

Method: Roslyn scan: EF Core DbContext for a versioned migrations directory versus bare EnsureCreated usage. Exhaustive per project, deterministic.

Readiness · Performance — Whether the library protects its performance with benchmarks — a benchmark suite, allocation/memory measurement, and (ideally) a CI gate. Presence is credited as a bonus, never a deduction.

Method: Repo + source scan: BenchmarkDotNet referenced (csproj/source), [Benchmark]/[MemoryDiagnoser] attribute counts, and a benchmark step in CI — scored as a bonus ladder (absence is neutral, never a deduction). Deterministic, presence detection.

Readiness · Performance — Whether the code is written to minimise allocations so it doesn't pressure its host's memory manager — buffer/slice views over copies, object pooling, stack or value-type allocation, and buffer writers. Reward-only: credited where present, never penalised where a simpler style is fine.

Method: Production-source scan: density (per 1k LoC) of allocation-aware APIs — Span/Memory, ArrayPool/ObjectPool, stackalloc, ValueTask, value-type structs, IBufferWriter, string.Create, SkipLocalsInit. Reward-only. Deterministic, syntax/text detection.

What to do

• Raise allocation-aware density on the hot paths — currently 4 use(s) across 75,988 production line(s) (~0.1/1k). More Span/Memory, pooling (ArrayPool/ObjectPool), stackalloc and ValueTask on the allocation-heavy paths climbs this toward 10.

Readiness · Performance — Whether asynchronous code keeps its host responsive — a library awaits with ConfigureAwait(false) (so it never captures and stalls the host's context) and avoids sync-over-async blocking (.Wait()/.GetAwaiter().GetResult()) that wastes threads and risks deadlock.

Method: Production-source scan: sync-over-async blocking (.Wait()/.GetAwaiter().GetResult()) counted everywhere, and — for a library with ≥5 awaits — the share of awaits using ConfigureAwait(false). Deterministic, syntax/text detection.

• 20 blocking call(s) on async work (.Wait()/.GetAwaiter().GetResult()) — these waste a thread and can deadlock in a consumer with a synchronization context.

What to do

• Make the call chain async end-to-end and await it — never block on a Task with .Wait()/.GetAwaiter().GetResult() in library code.

Other · Security — Transport security, security headers, secure cookies, input validation, middleware order and crypto hygiene (presence, not runtime).

Method: Roslyn plus filesystem scan: HSTS/security headers, secure cookies, input validation, middleware order, weak crypto (MD5/SHA1/DES); HTTPS-metadata context-aware. Deterministic.

• MD5/SHA1 is broken for security purposes (collision-vulnerable). Use SHA-256+ for content integrity; for password storage, use a KDF (PBKDF2/Argon2/BCrypt). — HashAlgorithm.cs:20
• DES / 3DES / RijndaelManaged-bare is deprecated or broken. Use AES-GCM via `Aes.Create()` with explicit key/iv sizes. — RijndaelSerializer.cs:46
• `RequireHttpsMetadata = false` allows the OIDC discovery doc to be fetched over plain HTTP. Safe for loopback-only fetches (Aspire / on-host); risky for any other path. — NaosExtensions.cs:106
• No Content-Security-Policy / X-Frame-Options / X-Content-Type-Options configuration found — defense in depth, even when a reverse proxy could set them. (−2.0 on this card.)
• No UseHttpsRedirection/UseHsts and no reverse-proxy signal — transport security is unverified at the app layer. (−2.0 on this card.)
• No CookieSecurePolicy/HttpOnly/SameSite configuration found. (−1.5 on this card; skip if the app sets no cookies.)

What to do

• Replace MD5/SHA1 with SHA-256+ for content hashing; switch to a KDF (PBKDF2/Argon2/BCrypt) for password storage.
• Replace DES/3DES (and bare RijndaelManaged) with AES-GCM via `Aes.Create()`.
• Set RequireHttpsMetadata = true in prod (or pin MetadataAddress to a localhost URL the API can hit directly).
• Add security response headers (Content-Security-Policy, X-Frame-Options, X-Content-Type-Options) — defense in depth, even when a reverse proxy could set them.
• Enforce HTTPS at the app layer (UseHttpsRedirection / UseHsts) — only skip this if a reverse proxy demonstrably terminates TLS.
• Set secure cookie flags — CookieSecurePolicy.Always, HttpOnly, and SameSite (Strict/Lax) on auth/session cookies. Skip only if the app sets no cookies.

Other · Code Health — Whether the code avoids sync-over-async (deadlock-prone blocking on tasks) and async void.

Method: Roslyn syntax scan: async methods scanned for .Wait()/.GetAwaiter().GetResult() and async-void outside event handlers. Deterministic, hard fact per invocation.

• Blocking on a Task with `.Wait()`/`.GetAwaiter().GetResult()` can deadlock (and wastes a thread). Make the caller `async` and `await` instead. (×18) — RabbitMQMessageBroker.cs:201, ServiceBusMessageBroker.cs:66, ServiceBusMessageBroker.cs:149, …
• `async void` can't be awaited and its exceptions crash the process instead of propagating. Return `Task` — or, where the delegate contract requires void (timer/event/callback registrations), make this a thin void shim that awaits a Task-returning inner method inside try/catch so exceptions are contained. — JobSchedulerHostedService.cs:70

What to do

• Sync-over-async (deadlock risk)

Other · Code Health — Whether async methods accept a CancellationToken so work can be cancelled (adoption curve).

Method: Roslyn scan: every async method (excluding framework-fixed overrides/Blazor handlers) checked for CancellationToken parameter presence. Deterministic, adoption percentage.

• Only 216/384 async methods accept a CancellationToken, so in-flight work can't be stopped early when the caller gives up — whatever ends it in your host (shutdown signal, timeout, abandoned request, user cancel). Thread a token through the call chain and honour it at each await and loop; where a method genuinely cannot be interrupted, omitting it is a deliberate choice — judge against your hosting model.
• No CancellationToken parameter — this work can't be stopped early once started. (×14) — NaosGenericRepositoryControllerBase.cs:27, NaosGenericRepositoryControllerBase.cs:62, NaosGenericRepositoryControllerBase.cs:86, …

What to do

• Thread a CancellationToken through async methods so work stops promptly on cancellation.

Other · Code Health — Whether exceptions are handled rather than silently swallowed or rethrown with lost stack traces.

Method: Roslyn syntax scan: every catch clause counted; empty catches and bare rethrows flagged. Population is all catch clauses, not estimated. Deterministic, hard fact.

• An empty catch block silently discards the error — failures vanish with no log and no rethrow. Log it, handle it, or don't catch it. (×3) — Expando.cs:174, Expando.cs:204, Expando.cs:234

What to do

• Swallowed exception (empty catch)

Other · Code Health — Whether log calls use message templates (queryable) rather than interpolated strings.

Method: Roslyn syntax scan: every log call-site counted; interpolated-string first-argument violations flagged. Population is all log calls, not estimated. Deterministic.

• Logging an interpolated string (`$"..."`) collapses the event to plain text — you lose the named, queryable properties structured logging exists for. Use a message template with placeholders: `LogInformation("User {UserId} did {Action}", id, action)`. If these calls go through a logging wrapper that only accepts a pre-formatted string, give the wrapper a template+args overload that forwards to the underlying logger, then migrate call sites to it. (×23) — HttpClientBuilderExtensions.cs:53, HttpClientBuilderExtensions.cs:63, NaosReadOnlyGenericRepositoryControllerBase.cs:42, …

What to do

• Interpolated log message defeats structured logging

Other · Code Health — Whether nullable reference types are enabled and not undermined by heavy `!` suppression.

Method: Roslyn compiler-options scan: NullableContextOptions per project; null-forgiving (!) suppression density per 1k syntax nodes. Deterministic, adoption plus suppression penalty.

• 0/4 projects enable <Nullable>enable</Nullable>. NRTs catch a whole class of null-deref bugs at compile time.

What to do

• Enable <Nullable>enable</Nullable> across all projects and resolve warnings rather than suppressing with `!`.