Phongnguyend/Practical.CleanArchitecture

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 9.4 / 10 · rule-coverage 100% · ceiling Prevented

2 method(s) exceeded the cyclomatic complexity threshold of 15; the worst was RabbitMQReceiver.ReceiveAsync at 22.

✓ On the Gold path — maintain.

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 8.8 / 10 · rule-coverage 100% · ceiling Prevented

3 method(s) exceeded the cognitive complexity threshold of 15; the worst was RabbitMQReceiver.ReceiveAsync at 37.

What to do

1. Resolve the 1 RabbitMQReceiver.ReceiveAsync (cognitive 37) finding(s) in Cognitive Complexity — start with RabbitMQReceiver.cs. — One of this dimension's main actionable groups (1 warning-level).
2. Resolve the 1 FileEmbeddingConsumer.ProcessFileAsync (cognitive 29) finding(s) in Cognitive Complexity — start with FileEmbeddingConsumer.cs. — One of this dimension's main actionable groups (1 warning-level).
3. Resolve the 1 ImportConfigurationEntriesFromExcelHandler.ReadAsync (cognitive 18) finding(s) in Cognitive Complexity — start with ImportConfigurationEntriesFromExcelHandler.cs. — One of this dimension's main actionable groups (1 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.7 / 10 · rule-coverage 100% · ceiling Prevented

1 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.8 / 10 · rule-coverage 100% · ceiling Verified

7 duplicated block group(s) detected.

+ 1 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 7.2 / 10 · rule-coverage 100% · ceiling Prevented

19 projects, 0 dependency cycle(s), 3 unstable depended-on project(s).

What to do

1. Resolve the 3 Off the main sequence finding(s) in Coupling. — One of this dimension's main actionable groups (3 warning-level).
2. Resolve the 1 Unstable project ClassifiedAds.BlazorServerSide finding(s) in Coupling. — One of this dimension's main actionable groups (1 warning-level).
3. Resolve the 1 Unstable project ClassifiedAds.BlazorWebAssembly 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.7 / 10 · rule-coverage 100% · ceiling Verified

2 of 72 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 1.0 / 10 · rule-coverage 100% · ceiling Verified

Line coverage 3.6%, branch coverage 0.0%.

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.

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

16 test methods: 16 unit, 0 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 8.5 / 10 · rule-coverage 100% · ceiling Prevented

0 skipped, 3 zero-assertion, 1 mock references across 30 tests.

What to do

1. Resolve the 3 No assertions finding(s) in Test Quality — start with ApplicationTests.cs (2), UserServiceTests.cs. — One of this dimension's main actionable groups (3 warning-level).
2. Enforce Test Quality in CI to reach Verified (currently Documented). — Hardens enforcement from Documented toward Prevented — provenance only; does not change the score.

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

What it measures: Whether the tests pass reliably, with no flakiness.

Method: Suite re-run N times within tiered wall-clock budgets (unit to e2e); tests failing non-deterministically across runs flagged; guarded tests retried when #if guards detected.

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

0 flaky across 1 measured tier(s). unit: measured (0 flaky).

✓ On the Gold path — maintain.

Detailed fixes: d11_recommendation.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 10.0 / 10 · rule-coverage 100% · ceiling Verified

0 outdated, 0 vulnerable, 0 deprecated packages.

✓ On the Gold path — maintain.

Detailed fixes: d12_recommendation.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 0.0 / 10 · rule-coverage 100% · ceiling Prevented

5 secret(s) detected.

What to do

1. Resolve the 5 Leaked secret finding(s) in Secret Scanning — start with UserConfiguration.cs (5). — One of this dimension's main actionable groups (5 issue-level).

Detailed fixes: d13_recommendation.md · top locations in Appendix A, every location in findings.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 115 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: Whether knowledge is concentrated in too few people (the "bus factor").

Method: Living knowledge per author via time-decayed commit attribution (6-month half-life, focus weighting) across largest source files. Deterministic, avoids blame's mechanical-refactor false positives.

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

116 source file(s) have their living knowledge concentrated in one author (≥90% of recent, decayed contribution). The largest is src/Monolith/ClassifiedAds.WebAPI/Controllers/FilesController.cs.

What to do

1. Resolve the 1 Off-boarding risk finding(s) in Bus Factor. — One of this dimension's main actionable groups (1 recommendation-level).

Detailed fixes: d16_recommendation.md · top locations in Appendix A, every location in findings.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 9.2 / 10 · rule-coverage 100% · ceiling Prevented

16 deducted debt markers + 22 dead symbols across 16424 LoC (0.4/KLoC) → score 9.2.

✓ On the Gold path — maintain.

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 8.5 / 10 · rule-coverage 100% · ceiling Documented

19 projects, 498 .cs files, 16668 hand-written lines of code (16424 production / 244 test), 61 inter-project edges.

What to do

1. Resolve the 2 Shell project finding(s) in Solution Shape — start with ClassifiedAds.Persistence.MySQL.csproj, ClassifiedAds.Persistence.PostgreSQL.csproj. — One of this dimension's main actionable groups (2 recommendation-level).
2. Resolve the 1 Monorepo finding(s) in Solution Shape. — One of this dimension's main actionable groups (1 warning-level).
3. Resolve the 1 Analyzed solution does not cover the bulk of the repository finding(s) in Solution Shape. — One of this dimension's main actionable groups (1 warning-level).

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

What it measures: Whether architecture decisions are recorded well (context, decision, consequences).

Method: Per-ADR judgment by language model at low temperature with two-pass stability; confidence is share of ADRs evaluated; enforcement-field presence detected deterministically. Advisory.

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

No architecture decision records were found.

What to do

1. Resolve the 1 No ADRs found finding(s) in ADR Quality. — One of this dimension's main actionable groups (1 recommendation-level).

Detailed fixes: d20_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

1 naming inconsistencies across 200 sampled symbols.

✓ On the Gold path — maintain.

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

What it measures: Whether comments are worth it — explaining WHY (valuable) rather than WHAT (redundant).

Method: Judged by language model at low temperature (0.0-0.1) on deterministically sampled inline comments with surrounding code; findings verified back to sampled comments by substring match. Advisory, sampled.

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

12 valuable / 2 redundant across 73 sampled comments; 2 shown with locations.

What to do

1. Resolve the 2 redundant comment finding(s) in Comment Value — start with Program.cs, RabbitMQReceiver.cs. — One of this dimension's main actionable groups (2 recommendation-level).

Detailed fixes: d24_recommendation.md · top locations in Appendix A, every location in findings.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 8.9 / 10 · rule-coverage 100% · ceiling Documented

1 of 19 projects flagged as possibly oversized/incoherent.

What to do

1. Resolve the 1 Split ClassifiedAds.Infrastructure finding(s) in Project Cohesion. — One of this dimension's main actionable groups (1 recommendation-level).

Detailed fixes: d26_recommendation.md · top locations in Appendix A, every location in findings.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 7.4 / 10 · rule-coverage 100% · ceiling Documented

86 % of calls cross a namespace and 20 % go through an interface, but 93 % of collaborators are co-located — so following a call takes several hops. Baseline: medium — clean/modular boundaries expected.

What to do

1. Improve Navigability — currently 7.4/10. — 86 % of calls cross a namespace and 20 % go through an interface, but 93 % of collaborators are co-located — so following a call takes several hops. Baseline: medium — clean/modular boundaries 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 10.0 / 10 · rule-coverage 100% · ceiling Documented

gitleaks scanned the full history AND the current working tree and found no secrets.

✓ On the Gold path — maintain.

Detailed fixes: d28_recommendation.md.

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

Method: Polyglot static analysis via semgrep --config auto across the repo; severity rules (ERROR/WARNING/INFO) map to a 0-10 wide normalizer. 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 10.0 / 10 · rule-coverage 100% · ceiling Documented

semgrep found no security issues.

✓ On the Gold path — maintain.

Detailed fixes: d29_recommendation.md.

What it measures: Whether any dependencies have known published vulnerabilities (CVEs), direct or transitive.

Method: NuGet CVE scan via dotnet list package --vulnerable including transitive; severity tally (Critical/High/Medium/Low) to 0-10 tight normalizer. Exhaustive, deterministic; degrades when absent.

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

27 vulnerable package(s): 0 critical, 7 high, 18 medium, 2 low.

What to do

1. Resolve the 18 Medium CVE finding(s) in Dependency Vulnerabilities. — One of this dimension's main actionable groups (18 warning-level).
2. Resolve the 7 High CVE finding(s) in Dependency Vulnerabilities. — One of this dimension's main actionable groups (7 issue-level).
3. Resolve the 2 Low CVE finding(s) in Dependency Vulnerabilities. — One of this dimension's main actionable groups (2 recommendation-level).

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

What it measures: Whether Dockerfiles / Terraform / Kubernetes config follow security best practices.

Method: IaC/container misconfiguration scan via trivy config (Dockerfile/Terraform/K8s/Helm/CloudFormation); severity rules to 0-10 moderate normalizer. NotApplicable without manifests. Exhaustive, deterministic.

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

1279 finding(s): 2 critical, 229 high, 331 medium, 717 low.

What to do

1. Resolve the 48 High IaC finding(s) in IaC & Container Security — start with Dockerfile (4), auditlog-api.deployment.yaml (3), auditlog-grpc.deployment.yaml (3). — One of this dimension's main actionable groups (48 issue-level).
2. Resolve the 2 Critical IaC finding(s) in IaC & Container Security — start with main.tf (2). — One of this dimension's main actionable groups (2 issue-level).

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

What it measures: Whether JavaScript/npm dependencies have known published vulnerabilities (CVEs) — the npm ecosystem's biggest risk.

Method: JS/npm CVE scan via trivy fs --scanners vuln over JS manifests (package.json/yarn.lock/pnpm-lock/bun.lockb); 0-10 tight normalizer. NotApplicable without JS manifests. Exhaustive, deterministic.

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

No known-vulnerable JS/npm dependencies.

✓ On the Gold path — maintain.

Detailed fixes: d33_recommendation.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 1.4 / 10 · rule-coverage 100% · ceiling Documented

204 of 234 significant source file(s) are orphaned — their living knowledge has decayed to nothing, so no one currently understands them. The largest is src/IdentityServers/OpenIddict/ClassifiedAds.IdentityServer/HostedServices/SeedDataHostedService.cs.

What to do

1. 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 10.0 / 10 · rule-coverage 100% · ceiling Documented

No strong hidden change-coupling between production files.

✓ On the Gold path — maintain.

Detailed fixes: d35_recommendation.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/4 supply-chain integrity signals present (provenance, signing, SBOM, pinned actions).

What to do

1. Resolve the 1 Unpinned build actions finding(s) in Supply-chain Provenance & Signing. — One of this dimension's main actionable groups (1 warning-level).
2. Resolve the 1 No build provenance finding(s) in Supply-chain Provenance & Signing. — One of this dimension's main actionable groups (1 recommendation-level).
3. Resolve the 1 No artifact signing 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.

What it measures: Whether dependencies have known published vulnerabilities (CVEs) per the OSV database — npm and other lockfile ecosystems, parsed natively. Complements D33 (npm via trivy) and D30 (.NET via dotnet).

Method: npm/multi-ecosystem CVE scan via osv-scanner (queries the osv.dev database + parses lockfiles natively: package-lock/yarn/pnpm/bun); severity tally (Critical/High/Medium/Low) to 0-10 tight normalizer (8.0). NotApplicable without a JS lockfile. Additive to D33 (trivy fs); exhaustive + deterministic, DB kept fresh.

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

69 finding(s): 1 critical, 33 high, 27 medium, 8 low.

What to do

1. Resolve the 33 High CVE finding(s) in OSV Dependency Vulnerabilities — start with package-lock.json (33). — One of this dimension's main actionable groups (33 issue-level).
2. Resolve the 16 Medium CVE finding(s) in OSV Dependency Vulnerabilities — start with package-lock.json (16). — One of this dimension's main actionable groups (16 warning-level).
3. Resolve the 1 Critical CVE finding(s) in OSV Dependency Vulnerabilities — start with package-lock.json. — One of this dimension's main actionable groups (1 issue-level).

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

Other · Accessibility — Whether non-text content carries a text alternative — img/area/input[type=image] have alt, a meaningful svg has a title or aria-label, video has a captions track, and object/embed/canvas have a name or fallback content. Static markup readiness, not a WCAG conformance claim.

Method: Static markup-model scan: every img/area/input[type=image] checked for alt, svg[role=img] for a title/aria-label, video for a captions <track>. Components skipped, spreads suppressed. Deterministic, hard fact per element.

• An image with no alt (and no aria-label/aria-labelledby) is unreadable to assistive tech. Add alt — alt="" if it's purely decorative. (×25) — Consent.cshtml:9, Index.cshtml:9, Index.cshtml:9, …

What to do

• Add a text alternative — alt on images (alt="" for purely decorative ones), a title or aria-label on meaningful svg, and a captions <track> on video.

Other · Accessibility — Whether form controls have a programmatic label (an associated label, aria-label or aria-labelledby), buttons have text, links have an accessible name, fieldsets have a non-empty legend, known UI-library field components carry a label prop, and a placeholder isn't used as the only label. Static markup readiness, not a WCAG conformance claim.

Method: Static markup-model scan: inputs/selects/textareas checked for an associated label[for]/wrapping label/aria-label/aria-labelledby (per document), buttons for accessible text, fieldsets for a legend; placeholder-only labelling flagged. Deterministic, hard fact per control.

• This control has only a placeholder — a placeholder is not a label (it vanishes on input and many AT ignore it). Add a <label for>, a wrapping <label>, or aria-label. (×3) — Consent.cshtml:74, Index.cshtml:71, Index.cshtml:104
• A link with no text, aria-label or labelled child (e.g. an icon-only link) has no accessible name, so assistive tech can't say where it goes. Add visible text or an aria-label. (×12) — Consent.cshtml:89, Index.cshtml:98, Index.cshtml:131, …
• This control has no associated label. Add a <label for> / wrapping <label> / aria-label / aria-labelledby so assistive tech can name it. (×10) — Index.cshtml:25, Secrets.cshtml:51, Secrets.cshtml:51, …

What to do

• Give every control a programmatic label (a <label for> / wrapping <label> / aria-label) and every button text — a placeholder is not a label.

Other · Accessibility — Whether pages declare a language (well-formed BCP-47) and a non-empty title, expose exactly one main landmark and a sane heading order with non-empty headings, keep zoom enabled, title their iframes, give data tables header cells, and avoid meta-refresh. Static markup readiness, not a WCAG conformance claim.

Method: Static markup-model scan: html lang, document <title>, a main landmark and heading order on full documents only, plus zoom-disabling viewports, untitled iframes and meta-refresh anywhere. Deterministic, per structural checkpoint.

• Skipping heading levels breaks the document outline assistive tech relies on. Don't jump levels — increase by at most one. (×13) — ExternalLogin.cshtml:6, ForgotPassword.cshtml:6, Login.cshtml:11, …
• A <table> with data cells but no <th> gives assistive technology no way to associate cells with their headers. Mark the header row/column cells as <th> (with a scope). — ExternalLogins.cshtml:9
• An iframe with no title (or an empty one) is announced only as "frame". Add a non-empty title describing its content, or an aria-label. — LoggedOut.cshtml:20
• The page declares no language, so assistive tech can't pick the right pronunciation. Add lang (e.g. lang="en"). (×2) — Callback.cshtml:0, Challenge.cshtml:0
• A page with no <title> gives no name in the tab, history or screen-reader page list. Add a descriptive <title> in <head>. (×2) — Callback.cshtml:0, Challenge.cshtml:0
• No <main> (or role="main") means no "skip to content" target and a weaker landmark map. Wrap the primary content in <main>. (×2) — Callback.cshtml:0, Challenge.cshtml:0
• An empty heading appears in the document outline announced with no text. Give the heading text, or remove it if it's decorative. (×4) — Index.cshtml:39, Index.cshtml:51, Index.cshtml:63, …

What to do

• Declare <html lang>, a document <title> and a <main> landmark, keep headings in order, leave zoom enabled, title iframes and drop meta-refresh.

Other · Accessibility — Whether interactive behaviour is keyboard-reachable — no click handler on a non-interactive element lacking a role, tabindex and key handler, no positive tabindex, no href-less anchor, no placeholder-href (#/javascript) link acting as a button. Static markup readiness, not a WCAG conformance claim.

Method: Static markup-model scan: click handlers on non-interactive elements lacking role+tabindex+key handler, positive tabindex values, and href-less anchors. Components skipped, spreads suppressed. Deterministic, hard fact per element.

• An <a> with no href, role or tabindex isn't focusable or keyboard-activatable. Give it a real href, or use a <button> for an action. (×14) — ConfirmDialog.razor:18, Pagination.razor:2, Pagination.razor:3, …
• An <a href="#"> (or javascript:) with a click handler is a button dressed as a link — it announces the wrong role and stops working without JS. Use a <button> for an action. (×5) — Edit.razor:50, Edit.razor:104, Edit.razor:108, …
• A click handler on a plain element isn't keyboard-operable. Use a <button>, or add role + tabindex="0" + a key handler. (×6) — NavMenu.razor:8, NavMenu.razor:17, Star.tsx:8, …

What to do

• Make custom controls keyboard-operable (role + tabindex + key handler), drop positive tabindex, and give anchors a real href.

Other · Accessibility — Whether ARIA is used correctly — valid non-abstract roles, the ARIA state a role requires, valid (non-misspelled) aria-* attribute names, in-enum values for token-typed aria-* attributes, and no aria-hidden on (or wrapping) a focusable element. Static markup readiness, not a WCAG conformance claim.

Method: Static markup-model scan: role values checked against the WAI-ARIA role set (abstract/invalid flagged), required ARIA state for a role, and aria-hidden on a focusable element. Deterministic, role/attribute level.

• aria-hidden="true" here hides the subtree from assistive tech, but a focusable descendant stays in the tab order — a keyboard user can land on a control screen readers can't see. Add inert, take the descendants out of the tab order (tabindex="-1"), or drop aria-hidden. (×2) — Secrets.cshtml:156, Secrets.cshtml:156

What to do

• Use valid, non-abstract roles, supply the ARIA state each role requires, and never put aria-hidden on a focusable element.

Other · Accessibility — Whether focus outlines aren't removed without a replacement, motion respects prefers-reduced-motion, and literal CSS colour pairs meet contrast — PARTIAL: inline styles, in-repo <style> blocks, in-repo .css files, var() tokens, Tailwind neutral utilities and CSS-in-JS literals are read (hex/rgb/hsl/named), never computed/runtime/external-CDN colour. Static markup readiness, not a WCAG conformance claim.

Method: Static markup/CSS scan: inline outline:none/0, literal inline colour/background contrast against the 4.5:1 AA floor, and <style>-block animation without a prefers-reduced-motion guard. Deterministic but PARTIAL — only inline styles and in-repo CSS literals are visible.

• A CSS rule's foreground/background colour pair falls below the 4.5:1 WCAG AA minimum for normal text. Darken or lighten one of them. (×4) — app.css:0, site.css:0, bootstrap.css:0, …

What to do

• Keep a visible focus style (don't remove the outline without a replacement), guard animation with prefers-reduced-motion, and raise low-contrast colour pairs to at least 4.5:1.

Other · Accessibility — Whether accessibility is ENFORCED in the toolchain — an a11y linter (eslint-plugin-jsx-a11y / vuejs-accessibility) configured, and axe/pa11y/Lighthouse wired into tests or CI — on the Documented→Verified→Prevented ladder.

Method: Repo config/CI scan: an a11y linter (eslint-plugin-jsx-a11y / vuejs-accessibility) configured, and axe/pa11y/Lighthouse in tests or CI, graded on the Documented→Verified→Prevented rungs. Deterministic, presence/rung detection.

• No accessibility enforcement found — no a11y linter (eslint-plugin-jsx-a11y / vuejs-accessibility) and no axe/pa11y/Lighthouse in tests or CI. Start with the linter to catch issues at author time.

What to do

• Enforce accessibility in the toolchain: add eslint-plugin-jsx-a11y (or vuejs-accessibility), assert with jest-axe / playwright-axe in tests, then gate axe/pa11y/Lighthouse in CI.

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.

What to do

• The domain core is a small share of production code — check that business logic isn't leaking into the application/infrastructure layers (a thin domain is the anemic-domain smell).

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.

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.

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.

• `IUser` declares 18 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. — IUser.cs:3
• `IEmailMessage` declares 18 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. — IEmailNotification.cs:11

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.

Other · Security — Whether sensitive data is encrypted at rest and in transit and keys are vaulted.

Method: Roslyn plus filesystem scan: encryption presence (EF ColumnEncryption, key-vault references, HTTPS enforcement) and key-derivation KDF detection. Deterministic.

What to do

• Strengthen data-at-rest protection: vault your keys (Azure Key Vault / AWS KMS / IDataProtector key ring) and encrypt the most sensitive columns (EF HasConversion encryption or provider-native column encryption) — partial coverage still leaves gaps.

Other · Security — Whether access is authorized by default — [Authorize]/policies 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 · Security — Whether changes to sensitive data are recorded (who, what, when) for compliance + incident response.

Method: Roslyn scan: audit-trail mechanism graded (SaveChanges interceptor/immutable AuditLog/[Audited] strong; bare IAuditable/AddAuditing weak). Deterministic.

• An audit mechanism is present, but the trail is not yet complete — missing: an EF SaveChanges interceptor (or equivalent write-side hook), [Audited] per-entity coverage.

What to do

• Back the audit convention with a structural mechanism: an EF SaveChanges interceptor (or equivalent) writing every sensitive change to an immutable audit log, and apply [Audited] to the entities that need a who-changed-what trail.

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.

• `FileEntryEmbedding` references the aggregate root `FileEntry` directly (via `FileEntry`) — hold its `FileEntryId` instead. — FileEntryEmbedding.cs:20
• `FileEntryText` references the aggregate root `FileEntry` directly (via `FileEntry`) — hold its `FileEntryId` instead. — FileEntryText.cs:11
• `ProductEmbedding` references the aggregate root `Product` directly (via `Product`) — hold its `ProductId` instead. — ProductEmbedding.cs:16
• `User` references the aggregate root `UserLogin` directly (via `UserLogins`) — hold its `UserLoginId` instead. — User.cs:46
• `UserLogin` references the aggregate root `User` directly (via `User`) — hold its `UserId` instead. — UserLogin.cs:15

What to do

• Reference other aggregates by their strongly-typed id, never by object reference, so each aggregate stays an independent consistency boundary.

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.

• `AuditLogEntry.UserId` is a raw `Guid` — give it a strongly-typed id (`readonly record struct UserId { Guid Value }`). — AuditLogEntry.cs:7
• `AuditLogEntry.ObjectId` is a raw `String` — give it a strongly-typed id (`readonly record struct ObjectId { String Value }`). — AuditLogEntry.cs:11
• `ConfigurationEntry.Key` is a raw `String` — give it a strongly-typed id (`readonly record struct Key { String Value }`). — ConfigurationEntry.cs:7
• `EmailMessageBase.CopyFromId` is a raw `Guid` — give it a strongly-typed id (`readonly record struct CopyFromId { Guid Value }`). — EmailMessage.cs:42
• `EmailMessageAttachment.EmailMessageId` is a raw `Guid` — give it a strongly-typed id (`readonly record struct EmailMessageId { Guid Value }`). — EmailMessageAttachment.cs:7
• `EmailMessageAttachment.FileEntryId` is a raw `Guid` — give it a strongly-typed id (`readonly record struct FileEntryId { Guid Value }`). — EmailMessageAttachment.cs:9
• `FileEntry.EncryptionKey` is a raw `String` — give it a strongly-typed id (`readonly record struct EncryptionKey { String Value }`). — FileEntry.cs:22
• `DeletedFileEntry.FileEntryId` is a raw `Guid` — give it a strongly-typed id (`readonly record struct FileEntryId { Guid Value }`). — FileEntry.cs:37
• `FileEntryEmbedding.FileEntryId` is a raw `Guid` — give it a strongly-typed id (`readonly record struct FileEntryId { Guid Value }`). — FileEntryEmbedding.cs:18
• `FileEntryText.FileEntryId` is a raw `Guid` — give it a strongly-typed id (`readonly record struct FileEntryId { Guid Value }`). — FileEntryText.cs:9
• `OutboxMessageBase.TriggeredById` is a raw `Guid` — give it a strongly-typed id (`readonly record struct TriggeredById { Guid Value }`). — OutboxMessage.cs:17
• `OutboxMessageBase.ObjectId` is a raw `String` — give it a strongly-typed id (`readonly record struct ObjectId { String Value }`). — OutboxMessage.cs:19
• `OutboxMessageBase.ActivityId` is a raw `String` — give it a strongly-typed id (`readonly record struct ActivityId { String Value }`). — OutboxMessage.cs:25
• `PasswordHistory.UserId` is a raw `Guid` — give it a strongly-typed id (`readonly record struct UserId { Guid Value }`). — PasswordHistory.cs:7
• `ProductEmbedding.ProductId` is a raw `Guid` — give it a strongly-typed id (`readonly record struct ProductId { Guid Value }`). — ProductEmbedding.cs:14
• `SmsMessageBase.CopyFromId` is a raw `Guid` — give it a strongly-typed id (`readonly record struct CopyFromId { Guid Value }`). — SmsMessage.cs:32
• `User.Auth0UserId` is a raw `String` — give it a strongly-typed id (`readonly record struct Auth0UserId { String Value }`). — User.cs:36
• `User.AzureAdB2CUserId` is a raw `String` — give it a strongly-typed id (`readonly record struct AzureAdB2CUserId { String Value }`). — User.cs:38
• `UserLogin.UserId` is a raw `Guid` — give it a strongly-typed id (`readonly record struct UserId { Guid Value }`). — UserLogin.cs:7
• `UserLogin.ProviderKey` is a raw `String` — give it a strongly-typed id (`readonly record struct ProviderKey { String Value }`). — UserLogin.cs:11
• `UserRole.UserId` is a raw `Guid` — give it a strongly-typed id (`readonly record struct UserId { Guid Value }`). — UserRole.cs:7
• `UserRole.RoleId` is a raw `Guid` — give it a strongly-typed id (`readonly record struct RoleId { Guid Value }`). — UserRole.cs:9
• `UserToken.UserId` is a raw `Guid` — give it a strongly-typed id (`readonly record struct UserId { Guid Value }`). — UserToken.cs:7

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.

• `AuditLogEntry` is an aggregate/entity with 4 data propert(ies) but no state-changing behaviour (only data and queries) — the business logic lives in a service. — AuditLogEntry.cs:5
• `ConfigurationEntry` is an aggregate/entity with 4 data propert(ies) but no state-changing behaviour (only data and queries) — the business logic lives in a service. — ConfigurationEntry.cs:5
• `CustomMigrationHistory` 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. — CustomMigrationHistory.cs:5
• `EmailMessage` 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. — EmailMessage.cs:7
• `EmailMessageBase` is an aggregate/entity with 13 data propert(ies) but no state-changing behaviour (only data and queries) — the business logic lives in a service. — EmailMessage.cs:16
• `EmailMessageAttachment` is an aggregate/entity with 5 data propert(ies) but no state-changing behaviour (only data and queries) — the business logic lives in a service. — EmailMessageAttachment.cs:5
• `EmbeddingCacheEntry` is an aggregate/entity with 7 data propert(ies) but no state-changing behaviour (only data and queries) — the business logic lives in a service. — EmbeddingCacheEntry.cs:5
• `FileEntry` is an aggregate/entity with 13 data propert(ies) but no state-changing behaviour (only data and queries) — the business logic lives in a service. — FileEntry.cs:6
• `DeletedFileEntry` 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. — FileEntry.cs:35
• `FileEntryEmbedding` is an aggregate/entity with 7 data propert(ies) but no state-changing behaviour (only data and queries) — the business logic lives in a service. — FileEntryEmbedding.cs:6
• `FileEntryText` is an aggregate/entity with 3 data propert(ies) but no state-changing behaviour (only data and queries) — the business logic lives in a service. — FileEntryText.cs:5
• `LocalizationEntry` is an aggregate/entity with 4 data propert(ies) but no state-changing behaviour (only data and queries) — the business logic lives in a service. — LocalizationEntry.cs:5
• `OutboxMessageBase` is an aggregate/entity with 7 data propert(ies) but no state-changing behaviour (only data and queries) — the business logic lives in a service. — OutboxMessage.cs:13
• `PasswordHistory` is an aggregate/entity with 3 data propert(ies) but no state-changing behaviour (only data and queries) — the business logic lives in a service. — PasswordHistory.cs:5
• `Product` is an aggregate/entity with 3 data propert(ies) but no state-changing behaviour (only data and queries) — the business logic lives in a service. — Product.cs:5
• `ProductEmbedding` is an aggregate/entity with 5 data propert(ies) but no state-changing behaviour (only data and queries) — the business logic lives in a service. — ProductEmbedding.cs:6
• `Role` is an aggregate/entity with 5 data propert(ies) but no state-changing behaviour (only data and queries) — the business logic lives in a service. — Role.cs:6
• `RoleClaim` is an aggregate/entity with 3 data propert(ies) but no state-changing behaviour (only data and queries) — the business logic lives in a service. — RoleClaim.cs:5
• `SmsMessageBase` is an aggregate/entity with 9 data propert(ies) but no state-changing behaviour (only data and queries) — the business logic lives in a service. — SmsMessage.cs:14
• `User` is an aggregate/entity with 21 data propert(ies) but no state-changing behaviour (only data and queries) — the business logic lives in a service. — User.cs:6
• `UserClaim` is an aggregate/entity with 3 data propert(ies) but no state-changing behaviour (only data and queries) — the business logic lives in a service. — UserClaim.cs:5
• `UserLogin` is an aggregate/entity with 5 data propert(ies) but no state-changing behaviour (only data and queries) — the business logic lives in a service. — UserLogin.cs:5
• `UserRole` is an aggregate/entity with 4 data propert(ies) but no state-changing behaviour (only data and queries) — the business logic lives in a service. — UserRole.cs:5
• `UserToken` is an aggregate/entity with 4 data propert(ies) but no state-changing behaviour (only data and queries) — the business logic lives in a service. — UserToken.cs:5

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.

• `AuditLogEntry` exposes public setter(s) (UserId, Action, ObjectId, Log). — AuditLogEntry.cs:5
• `ConfigurationEntry` exposes public setter(s) (Key, Value, Description, IsSensitive). — ConfigurationEntry.cs:5
• `CustomMigrationHistory` exposes public setter(s) (MigrationName). — CustomMigrationHistory.cs:5
• `EmailMessage` exposes public setter(s) (EmailMessageAttachments). — EmailMessage.cs:7
• `EmailMessageBase` exposes public setter(s) (From, Tos, CCs, BCCs, Subject, Body, …). — EmailMessage.cs:16
• `EmailMessageAttachment` exposes public setter(s) (EmailMessageId, FileEntryId, Name, EmailMessage, FileEntry). — EmailMessageAttachment.cs:5
• `EmbeddingCacheEntry` exposes public setter(s) (Text, Provider, Model, Embedding, InputTokenCount, OutputTokenCount, …). — EmbeddingCacheEntry.cs:5
• `FileEntry` exposes public setter(s) (Name, Description, Size, UploadedTime, FileName, FileLocation, …). — FileEntry.cs:6
• `DeletedFileEntry` exposes public setter(s) (FileEntryId). — FileEntry.cs:35
• `FileEntryEmbedding` exposes public setter(s) (ChunkName, ChunkLocation, ShortText, Embedding, TokenDetails, FileEntryId, …). — FileEntryEmbedding.cs:6
• `FileEntryText` exposes public setter(s) (TextLocation, FileEntryId, FileEntry). — FileEntryText.cs:5
• `LocalizationEntry` exposes public setter(s) (Name, Value, Culture, Description). — LocalizationEntry.cs:5
• `OutboxMessageBase` exposes public setter(s) (EventType, TriggeredById, ObjectId, Payload, Published, ActivityId, …). — OutboxMessage.cs:13
• `PasswordHistory` exposes public setter(s) (UserId, PasswordHash, User). — PasswordHistory.cs:5
• `Product` exposes public setter(s) (Code, Name, Description). — Product.cs:5
• `ProductEmbedding` exposes public setter(s) (Text, Embedding, TokenDetails, ProductId, Product). — ProductEmbedding.cs:6
• `Role` exposes public setter(s) (Name, NormalizedName, ConcurrencyStamp, Claims, UserRoles). — Role.cs:6
• `RoleClaim` exposes public setter(s) (Type, Value, Role). — RoleClaim.cs:5
• `SmsMessageBase` exposes public setter(s) (Message, PhoneNumber, AttemptCount, MaxAttemptCount, NextAttemptDateTime, ExpiredDateTime, …). — SmsMessage.cs:14
• `User` exposes public setter(s) (UserName, NormalizedUserName, Email, NormalizedEmail, EmailConfirmed, PasswordHash, …). — User.cs:6
• `UserClaim` exposes public setter(s) (Type, Value, User). — UserClaim.cs:5
• `UserLogin` exposes public setter(s) (UserId, LoginProvider, ProviderKey, ProviderDisplayName, User). — UserLogin.cs:5
• `UserRole` exposes public setter(s) (UserId, RoleId, User, Role). — UserRole.cs:5
• `UserToken` exposes public setter(s) (UserId, LoginProvider, TokenName, TokenValue). — UserToken.cs:5

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

• `WebhookConsumer.HandleAsync` makes a synchronous remote call (an HTTP call) while handling an event. The handler now depends, in real time, on another service being up and fast — the opposite of why you went event-driven. Publish a follow-up message (or use the outbox) instead of calling out and awaiting a response inside the handler. (×6) — WebhookConsumer.cs:33, WebhookConsumer.cs:39, WebhookConsumer.cs:45, …

What to do

• Remove synchronous remote calls from message handlers — react by publishing further messages, so services stay temporally decoupled.

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.

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.

• `SendEmailMessagesCommandHandler.HandleAsync` writes to the database AND publishes to the message bus in the same flow, with no outbox referenced in this path. These two writes aren't atomic — a crash between them either loses the message (DB committed, publish failed) or emits a phantom event (publish succeeded, DB rolled back). Use the transactional outbox pattern (e.g. MassTransit's EF/Marten outbox) so the message is committed in the same transaction as the state change and dispatched afterwards. — SendEmailMessagesCommand.cs:40
• `PublishOutboxMessagesCommandHandler.HandleAsync` writes to the database AND publishes to the message bus in the same flow, with no outbox referenced in this path. These two writes aren't atomic — a crash between them either loses the message (DB committed, publish failed) or emits a phantom event (publish succeeded, DB rolled back). Use the transactional outbox pattern (e.g. MassTransit's EF/Marten outbox) so the message is committed in the same transaction as the state change and dispatched afterwards. — PublishOutboxMessagesCommand.cs:36
• `SendSmsMessagesCommandHandler.HandleAsync` writes to the database AND publishes to the message bus in the same flow, with no outbox referenced in this path. These two writes aren't atomic — a crash between them either loses the message (DB committed, publish failed) or emits a phantom event (publish succeeded, DB rolled back). Use the transactional outbox pattern (e.g. MassTransit's EF/Marten outbox) so the message is committed in the same transaction as the state change and dispatched afterwards. — SendSmsMessagesCommand.cs:40

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.

• `Commands.PublishOutboxMessagesCommandHandler.HandleAsync` mutates persistent state (a database save) with no idempotency guard, and the model confirms a re-run would double-apply it. A retry or at-least-once redelivery means it can run twice — add an exists/dedup check, an upsert, an idempotency-key/inbox, or a versioned write. — PublishOutboxMessagesCommand.cs:36

What to do

• Make retry-prone mutations idempotent — guard each write with an exists/dedup check, an upsert, an idempotency-key/inbox, or a versioned write, so a re-run doesn't double-apply.

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. (×12) — RoleStore.cs:25, RoleStore.cs:30, RoleStore.cs:35, …

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.

• `RoleStore` has 10 unfinished members out of 11 — a scaffolded type that was never implemented. — RoleStore.cs:10
• `CreateAsync` is a shipped member whose whole body throws NotImplementedException — scaffolding that was never completed. Implement it or remove the dead surface. — RoleStore.cs:23
• `DeleteAsync` is a shipped member whose whole body throws NotImplementedException — scaffolding that was never completed. Implement it or remove the dead surface. — RoleStore.cs:28
• `FindByIdAsync` is a shipped member whose whole body throws NotImplementedException — scaffolding that was never completed. Implement it or remove the dead surface. — RoleStore.cs:33
• `FindByNameAsync` is a shipped member whose whole body throws NotImplementedException — scaffolding that was never completed. Implement it or remove the dead surface. — RoleStore.cs:38
• `GetNormalizedRoleNameAsync` is a shipped member whose whole body throws NotImplementedException — scaffolding that was never completed. Implement it or remove the dead surface. — RoleStore.cs:43
• `GetRoleIdAsync` is a shipped member whose whole body throws NotImplementedException — scaffolding that was never completed. Implement it or remove the dead surface. — RoleStore.cs:48
• `GetRoleNameAsync` is a shipped member whose whole body throws NotImplementedException — scaffolding that was never completed. Implement it or remove the dead surface. — RoleStore.cs:53
• `SetNormalizedRoleNameAsync` is a shipped member whose whole body throws NotImplementedException — scaffolding that was never completed. Implement it or remove the dead surface. — RoleStore.cs:58
• `SetRoleNameAsync` is a shipped member whose whole body throws NotImplementedException — scaffolding that was never completed. Implement it or remove the dead surface. — RoleStore.cs:63
• `UpdateAsync` is a shipped member whose whole body throws NotImplementedException — scaffolding that was never completed. Implement it or remove the dead surface. — RoleStore.cs:68
• `GetAllStrings` is a shipped member whose whole body throws NotImplementedException — scaffolding that was never completed. Implement it or remove the dead surface. (×2) — DefaultStringLocalizer.cs:26, SqlServerStringLocalizer.cs:36
• `SendAsync` looks like it should compute a result but its body just returns a constant — a placeholder return that was never filled in. (×4) — FakeSender.cs:9, FakeEmailNotification.cs:9, FakeSmsNotification.cs:9, …
• `FakeStorageManager` has 3 unfinished members out of 5 — a scaffolded type that was never implemented. — FakeStorageManager.cs:9
• `DeleteAsync` looks like it should compute a result but its body just returns a constant — a placeholder return that was never filled in. — FakeStorageManager.cs:17
• `ArchiveAsync` looks like it should compute a result but its body just returns a constant — a placeholder return that was never filled in. — FakeStorageManager.cs:27
• `UnArchiveAsync` looks like it should compute a result but its body just returns a constant — a placeholder return that was never filled in. — FakeStorageManager.cs:32
• `OnAuthorization` takes parameters but its body is empty — it accepts inputs and does nothing. Either implement it or remove it. — CustomAuthorizationFilter.cs:7
• `OnException` takes parameters but its body is empty — it accepts inputs and does nothing. Either implement it or remove it. — CustomExceptionFilter.cs:7
• `RefreshToken` has an empty body — confirm it's an intentional no-op and not an unfinished method. — TokenManager.cs:30
• A line of code has been commented out rather than removed — dead weight that rots and confuses. Delete it (version control remembers). (×4) — IdentityServiceCollectionExtensions.cs:88, IdentityServiceCollectionExtensions.cs:89, LocalizationServiceCollectionExtensions.cs:47, …

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.

• 111 code files changed in the last 6 months but the README was not touched — it may no longer reflect the system.

What to do

• Add a README to the 19 of 19 project(s) that lack one — worth up to 2 pts.
• Review the README against recent changes; refresh the parts that drifted.

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.
• No C4/PlantUML/Mermaid diagram or architecture.md — the high-level shape isn't documented.

What to do

• Start an ADR log (docs/adr/) recording significant decisions and their rationale.
• Add a C4 context/container diagram (Structurizr, PlantUML or Mermaid) or an architecture.md overview.

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.

• Test projects aren't grouped under a tests/ folder — the test surface isn't separable from production code at a glance.

What to do

• Group test projects under tests/ (or test/, spec/) so the test surface is discoverable and CI can scope it.

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.

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.

• A CI pipeline exists and the word "test" appears, but no explicit test-runner invocation (dotnet test / npm test / pytest / a test job) was matched — the gate may be running tests, or "test" may be incidental (a path, "latest", a reporter). Make the test step explicit so the gate is unambiguous.

What to do

• Run the test suite in CI via an explicit runner step (e.g. `dotnet test`) and gate merges on it.

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 8/13 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/Roslyn scan: CodeQL, Dependabot, secret-scanning, and BenchmarkDotNet presence in pipelines and projects. Exhaustive, deterministic.

• <NuGetAudit>false</NuGetAudit> in MSBuild suppresses NuGet's vulnerability audit project-wide. — Directory.Build.props:4

What to do

• Enable Dependabot/Renovate or a dependency-review gate.

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.
• Add an approval/environment gate (required reviewers / protection rules) before production promotion.

Readiness · Readiness — Whether disaster recovery is planned and codified — backups, geo-recovery, RTO/RPO, persistence guarantees — from IaC + container manifests + docs, never the live cloud.

Method: Filesystem scan: disaster recovery, backup, geo-recovery, RTO/RPO, persistence guarantees from IaC, manifests, and docs. Exhaustive, deterministic, never a live environment.

What to do

• Document RTO/RPO and a tested restore procedure (a backup config alone isn't disaster recovery).

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 · Readiness — Whether test coverage concentrates on the domain (business rules) rather than the trivial web/controller layer — a focus check a generic tool can't make.

Method: Roslyn plus test-execution analysis: domain-layer versus trivial web/controller coverage ratio. Computed metric, deterministic.

• Domain coverage is 8% — the layer carrying the business rules is under-tested.

What to do

• Raise unit-test coverage of the domain (aggregates, value objects, domain services) — that's where correctness matters most.

Readiness · Performance — Whether the library protects its performance with benchmarks — a BenchmarkDotNet suite, an allocation MemoryDiagnoser, 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.

• No BenchmarkDotNet suite was found. For a performance-sensitive library, a benchmark guards against silent regressions — but it's a bonus here, not a deduction.

What to do

• Add a BenchmarkDotNet project for the hot paths (with [MemoryDiagnoser] to track allocations), and run it in CI to catch regressions.

Readiness · Performance — Whether the code is written to minimise allocations so it doesn't pressure its host's GC — Span/Memory, pooling (ArrayPool/ObjectPool), stackalloc, ValueTask, value-type structs 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 9 use(s) across 16,855 production line(s) (~0.5/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.

• 3 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.

React / JS · Code Health — How much of the frontend is typed TypeScript vs untyped JavaScript.

Method: Frontend file inventory: the share of typed TypeScript vs untyped JavaScript across the source tree. Deterministic, exhaustive over frontend files.

What to do

• Migrate the remaining .js/.jsx files to TypeScript.

React / JS · Code Health — Copy-pasted token-identical blocks across the frontend (the D4 clone algorithm over JS/TS tokens, D-386).

Method: Copy-pasted token-identical blocks across the frontend (the D4 clone algorithm run over JS/TS tokens). Deterministic.

• src/UIs/bff/reactjs/src/containers/Products/actions.tsx:8 · src/UIs/bff/reactjs/src/containers/Products/actions.tsx:36 · src/UIs/bff/reactjs/src/containers/Products/actions.tsx:56 · src/UIs/bff/reactjs/src/containers/Products/actions.tsx:80 — actions.tsx:8
• src/UIs/bff/reactjs/src/containers/Products/ListProducts/ListProducts.tsx:287 · src/UIs/nextjs/src/containers/Products/ListProducts/ListProducts.tsx:359 · src/UIs/reactjs/src/containers/Products/ListProducts/ListProducts.tsx:287 — ListProducts.tsx:287
• src/UIs/bff/reactjs/src/containers/Products/actions.tsx:93 · src/UIs/bff/reactjs/src/containers/Settings/actions.tsx:93 · src/UIs/bff/reactjs/src/containers/Users/actions.tsx:93 · src/UIs/reactjs/src/containers/Products/actions.tsx:93 — actions.tsx:93
• src/UIs/bff/reactjs/src/containers/Users/ViewUser/ViewUser.tsx:377 · src/UIs/nextjs/src/containers/Users/ViewUser/ViewUser.tsx:457 · src/UIs/reactjs/src/containers/Users/ViewUser/ViewUser.tsx:377 — ViewUser.tsx:377
• src/UIs/vuejs/src/views/files/Edit.vue:137 · src/UIs/vuejs/src/views/files/List.vue:108 — Edit.vue:137
• src/UIs/angular/src/app/products/add-product/add-product.guard.ts:4 · src/UIs/angular/src/app/products/edit-product/edit-product.guard.ts:4 — add-product.guard.ts:4
• src/UIs/bff/reactjs/src/containers/Settings/ListConfigurationEntries/ListConfigurationEntries.tsx:31 · src/UIs/nextjs/src/containers/Settings/ListConfigurationEntries/ListConfigurationEntries.tsx:51 · src/UIs/reactjs/src/containers/Settings/ListConfigurationEntries/ListConfigurationEntries.tsx:31 — ListConfigurationEntries.tsx:31
• src/UIs/bff/reactjs/src/containers/Users/ViewUser/ViewUser.tsx:30 · src/UIs/nextjs/src/containers/Users/ViewUser/ViewUser.tsx:32 · src/UIs/reactjs/src/containers/Users/ViewUser/ViewUser.tsx:30 — ViewUser.tsx:30

What to do

• Extract the duplicated blocks into shared functions/components.

React / JS · Architecture — Conformance to the detected frontend architecture layout (feature-sliced / layered src) plus cross-package deep-import rules (D-386).

Method: Conformance to the detected frontend layout (feature-sliced / layered src) plus cross-package deep-import rules, over the module graph. Deterministic.

React / JS · Code Health — Per-function cyclomatic/cognitive complexity from the token-level function scanner (D-386) — real branching, not a regex heuristic.

Method: Per-function cyclomatic/cognitive complexity from a token-level function scanner (real branching, not a regex heuristic), computed over every frontend function. Deterministic.

• Branch-heavy code is where defects cluster — extract decisions into smaller functions. (×8) — reducer.tsx:79, reducer.tsx:79, ViewUser.tsx:10, …

What to do

• Break down the listed branch-heavy functions; aim P95 cyclomatic ≤ 5.

React / JS · Code Health — How many components/modules exceed the large-file threshold.

Method: Components/modules exceeding the large-file threshold, counted exhaustively across the frontend source tree. Deterministic.

What to do

• Split the oversized components into smaller, focused ones.

React / JS · Readiness — Static test reachability (D-386): the share of production files reachable from any test via the import graph — measured without running anything.

Method: Static test reachability: the share of production files reachable from any test via the import graph — measured without running anything. Deterministic.

• No test imports this module directly or transitively — its behavior is unverified. (×8) — ViewUser.tsx, ListConfigurationEntries.tsx, ListProducts.tsx, …

What to do

• Add tests that import the unreached modules (directly or through their public entry).

React / JS · Readiness — How outdated the npm dependencies are (a maturity signal). JS/npm CVEs are scored separately in D33 (JS/npm Dependency Vulnerabilities).

Method: npm dependency staleness from manifest/registry metadata (a maturity signal; JS/npm CVEs are scored separately in D33). Deterministic.

What to do

• Bump outdated dependencies to current versions to limit upgrade debt.

React / JS · Readiness — Whether the project wires up test, lint and typecheck — detected from each package.json script's COMMAND (eslint / tsc / vitest / jest / playwright), not just its name, and corroborated against CI-workflow invocations so a tool run only in CI still counts.

Method: package.json scanned for test/lint/typecheck script wiring. Deterministic presence check.

• test ✗ · lint ✓ · typecheck ✗

What to do

• Add the missing tooling (eslint, tsc) as package.json scripts and run them in CI.

React / JS · Code Health — Files unreachable from every application/tooling/test entry point, and exports nothing imports (module-graph reachability, D-386).

Method: Dead code: files unreachable from every application/tooling/test entry point plus exports nothing imports, via module-graph reachability. Deterministic, exhaustive over the import graph.

• Unreachable from the 4 application, 24 tooling and 4 test entry point(s) detected in this repo. Gate removals on your build/type-check — an undetected custom entry would make these reachable.
• no import path from any entry point (4 application, 24 tooling, 4 test roots considered) (×7) — ViewUser.tsx, ListConfigurationEntries.tsx, ListProducts.tsx, …

What to do

• Delete the dead files and unused exports — every line is maintenance cost and rebuild-estimate inflation with zero runtime value.

React / JS · Readiness — npm dependency truthfulness (D-386): unused dependencies, imports not declared anywhere, and type-/test-only packages shipped as production deps.

Method: npm dependency truthfulness: unused dependencies, imports declared nowhere, and type-/test-only packages shipped as production deps — from the manifest + import graph. Deterministic.

• Declared in src/UIs/angular/package.json but never imported anywhere in that package or its workspace members — dead weight and attack surface. Verify against build tooling before removing. (×3)
• Only test files import it — move it to devDependencies. — App.test.js:2

What to do

• Remove unused dependencies, declare unlisted imports explicitly, and demote type-/test-only packages to devDependencies.

React / JS · Architecture — Import cycles in the module graph (D-386) — files that can only be understood and changed together.

Method: Import cycles in the module graph, detected exhaustively over JS/TS imports (the same cycle detection as the .NET coupling dimension). Deterministic.

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.

• Password-hash field compared with `==` — use a constant-time compare to avoid timing oracles (CryptographicOperations.FixedTimeEquals). — UserStore.cs:145
• No CookieSecurePolicy/HttpOnly/SameSite configuration found. (−1.5 on this card; skip if the app sets no cookies.)

What to do

• Compare password hashes with `CryptographicOperations.FixedTimeEquals` (constant time, no timing oracle).
• 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. (×3) — HashiCorpVaultConfigurationProvider.cs:34, SignalRNotification.cs:30, PuppeteerSharpCollectionExtensions.cs:13
• `async void` can't be awaited and its exceptions crash the process instead of propagating. Return `Task` unless this is a top-level event handler. (×7) — List.cs:67, List.cs:71, List.cs:61, …

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 124/293 async methods accept a CancellationToken, so requests can't be cancelled cleanly under load or on client disconnect. In Blazor Server circuits and other short-write hosts, omitting it can be an accepted convention — judge against your hosting model.
• No CancellationToken parameter — work can't be cancelled cleanly on disconnect/shutdown. (×25) — DatabaseRetryDecoratorBase.cs:32, SyncUsersCommand.cs:34, SyncUsersCommand.cs:78, …

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.

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)`. (×19) — ErrorCatchingInterceptor.cs:89, LoggingInterceptor.cs:34, LoggingInterceptor.cs:61, …

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.

• 3/15 projects enable <Nullable>enable</Nullable>. NRTs catch a whole class of null-deref bugs at compile time.
• ~0.0 `!` suppressions per 1k syntax nodes — each one tells the compiler to trust you about null, suppressing the very safety NRTs provide.

What to do

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