YongpengW/NexusStack

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

8 method(s) exceeded the cyclomatic complexity threshold of 15; the worst was EPPlusExtensions.SaveToExcel at 27.

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

What to do

1. Resolve the 1 EPPlusExtensions.SaveToExcel (cyclomatic 27) finding(s) in Cyclomatic Complexity — start with EPPlusExtensions.cs. — One of this dimension's main actionable groups (1 warning-level).
2. Resolve the 1 EPPlusExtensions.SaveToExcel (cyclomatic 26) finding(s) in Cyclomatic Complexity — start with EPPlusExtensions.cs. — One of this dimension's main actionable groups (1 warning-level).
3. Resolve the 1 ApiAsyncExceptionFilter.OnExceptionAsync (cyclomatic 21) finding(s) in Cyclomatic Complexity — start with ApiAsyncExceptionFilter.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.7 / 10 · rule-coverage 100% · ceiling Prevented

19 method(s) exceeded the cognitive complexity threshold of 15; the worst was EPPlusExtensions.SaveToExcel at 81.

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

What to do

1. Resolve the 1 EPPlusExtensions.SaveToExcel (cognitive 81) finding(s) in Cognitive Complexity — start with EPPlusExtensions.cs. — One of this dimension's main actionable groups (1 warning-level).
2. Resolve the 1 EPPlusExtensions.SaveToExcel (cognitive 69) finding(s) in Cognitive Complexity — start with EPPlusExtensions.cs. — One of this dimension's main actionable groups (1 warning-level).
3. Resolve the 1 ApiAsyncExceptionFilter.OnExceptionAsync (cognitive 40) finding(s) in Cognitive Complexity — start with ApiAsyncExceptionFilter.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.8 / 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.9 / 10 · rule-coverage 100% · ceiling Verified

6 duplicated block group(s) detected.

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

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

What to do

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

0 of 40 classes have LCOM4 above 3.

✓ On the Gold path — maintain.

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

No test suite found.

What to do

1. Resolve the 1 No tests found finding(s) in Test Distribution. — One of this dimension's main actionable groups (1 recommendation-level).

Detailed fixes: d9_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 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 appsettings.Staging.json (3), UserSeedData.cs (2). — One of this dimension's main actionable groups (5 issue-level).
2. Enforce Secret Scanning in CI to reach Verified (currently Documented). — Hardens enforcement from Documented toward Prevented — provenance only; does not change the score.

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

1 of 51 packages use a banned license.

What to do

1. Resolve the 1 Banned license finding(s) in License Compliance. — One of this dimension's main actionable groups (1 issue-level).
2. Enforce License Compliance in CI to reach Verified (currently Documented). — Hardens enforcement from Documented toward Verified — provenance only; does not change the score.

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

23 source file(s) have their living knowledge concentrated in one author (≥90% of recent, decayed contribution). The largest is Domain/NexusStack.Core/Services/SystemManagement/FileService.cs.

What to do

1. Resolve the 2 Off-boarding risk finding(s) in Bus Factor. — One of this dimension's main actionable groups (2 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 8.9 / 10 · rule-coverage 100% · ceiling Prevented

16 deducted debt markers + 2 dead symbols across 20689 LoC (0.5/KLoC) → score 8.9.

What to do

1. Resolve the 9 EmptyCatchBlock finding(s) in Explicit Debt — start with EventSubscriber.cs (5), Connection.cs (2), EventPublisher.cs. — One of this dimension's main actionable groups (9 issue-level).
2. Resolve the 1 NoWarnInCsproj finding(s) in Explicit Debt — start with NexusStack.Template.csproj. — One of this dimension's main actionable groups (1 issue-level).
3. Resolve the 6 CommentedOutCode finding(s) in Explicit Debt — start with GlobalSettingService.cs (2), FileService.cs, ServiceBase.cs. — One of this dimension's main actionable groups (6 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 8.7 / 10 · rule-coverage 100% · ceiling Documented

12 projects, 340 source files, 20689 hand-written lines of code (20689 production / 0 test), plus 3377 generated (machine-written code — designer, scaffolded and tool-emitted files — excluded from quality), 46 inter-project edges.

What to do

1. Improve Solution Shape — currently 8.7/10. — 12 projects, 340 source files, 20689 hand-written lines of code (20689 production / 0 test), plus 3377 generated (machine-written code — designer, scaffolded and tool-emitted files — excluded from quality), 46 inter-project edges.

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

2 naming inconsistencies across 200 sampled symbols.

What to do

1. Resolve the 1 Inconsistent naming for object storage identifiers. 'bucket' and 'key'… finding(s) in Naming Consistency. — One of this dimension's main actionable groups (1 recommendation-level).
2. Resolve the 1 Inconsistent naming for user profile image. Both the DTO and Entity use… finding(s) in Naming Consistency. — One of this dimension's main actionable groups (1 recommendation-level).

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

1 of 12 projects flagged as possibly oversized/incoherent.

What to do

1. Resolve the 1 Split NexusStack.Core 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 9.0 / 10 · rule-coverage 100% · ceiling Documented

91 % of calls cross a namespace and 10 % go through an interface, but 100 % of collaborators are co-located — so a call's collaborators sit together and tracing stays easy. Baseline: medium — clean/modular boundaries expected.

✓ On the Gold path — maintain.

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

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

What to do

1. Resolve the 12 Secret finding(s) in Secrets (history) — start with appsettings.Development.json (4), appsettings.Production.json (3), appsettings.Staging.json (3). — One of this dimension's main actionable groups (12 issue-level).
2. Resolve the 1 Rotate the exposed credentials finding(s) in Secrets (history). — One of this dimension's main actionable groups (1 recommendation-level).

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

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

What to do

1. Resolve the 3 Medium finding(s) in Static Analysis (SAST) — start with LocalFileStorage.cs (2), FileService.cs. — One of this dimension's main actionable groups (3 warning-level).

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

5 vulnerable package(s): 0 critical, 5 high, 0 medium, 0 low.

What to do

1. Resolve the 5 High CVE finding(s) in Dependency Vulnerabilities. — One of this dimension's main actionable groups (5 issue-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 7.4 / 10 · rule-coverage 100% · ceiling Documented

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

What to do

1. Resolve the 4 High IaC finding(s) in IaC & Container Security — start with Dockerfile (4). — One of this dimension's main actionable groups (4 issue-level).
2. Resolve the 12 Medium IaC finding(s) in IaC & Container Security — start with appsettings.Staging.json (6), Dockerfile (4), appsettings.Development.json (2). — One of this dimension's main actionable groups (12 warning-level).
3. Resolve the 3 Low IaC finding(s) in IaC & Container Security — start with Dockerfile (3). — One of this dimension's main actionable groups (3 recommendation-level).

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

3 of 86 significant source file(s) are orphaned — their living knowledge has decayed to nothing, so no one currently understands them. The largest is Host/NexusStack.WebAPI/Controllers/OpenAppConfigController.cs.

✓ On the Gold path — maintain.

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

Strongest change-coupling: EventPublisher.cs↔EventSubscriber.cs 60%

✓ On the Gold path — maintain.

Detailed fixes: d35_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.

• `EventCodeManager` is a singleton (one shared instance) but mutates instance state outside any lock (_eventCodeMapping; e.g. `_eventCodeMapping` at line 15). — EventCodeManager.cs:7

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

• `IQueryRepository<TEntity, TKey>` declares 36 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. — IQueryRepository.cs:15
• `IRedisService` 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. — IRedisService.cs:9

What to do

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

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.

• [AllowAnonymous] (2) outweighs [Authorize] (1) — review whether the open surface is intended.

What to do

• Review the [AllowAnonymous] surface — keep anonymous endpoints deliberate and documented so the open surface stays intentional.

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 immutable audit-log / audit-trail type to write to, [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 · Security — Whether data has a defined lifetime — retention periods, TTLs, cleanup jobs (storage limitation).

Method: Roslyn scan: retention/TTL configuration presence in schema; CascadeDelete detected but not scored as retention control. Deterministic, gated by PII presence.

• A retention mechanism is present, but the data-lifecycle is not yet complete — missing: a documented retention period / data-expiry.

What to do

• Complete the data-lifecycle story: an expiry limit (a declared maximum age for the stored data — a retention-age setting, or a store-level TTL where your storage offers one), a scheduled purge/cleanup job that enforces it, and a documented retention period covering the personal data.

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 · 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. (×15) — AliyunFileStorage.cs:137, AliyunFileStorage.cs:142, AliyunFileStorage.cs:147, …

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.

• `ProcessAsync` is declared `async` but never awaits anything, so it runs synchronously while pretending to be asynchronous. Drop `async` or do the real async work. — FirstDayOfMonthSchedule.cs:28
• `GetFilesByIds` is a shipped member whose whole body throws NotImplementedException — scaffolding that was never completed. Implement it or remove the dead surface. — FileService.cs:69
• `UploadAsync` is a shipped member whose whole body throws NotImplementedException — scaffolding that was never completed. Implement it or remove the dead surface. (×2) — FileService.cs:233, LocalFileStorage.cs:92
• `UploadFromUrlAsync` is a shipped member whose whole body throws NotImplementedException — scaffolding that was never completed. Implement it or remove the dead surface. — FileService.cs:238
• `GetSettingListAsync` is declared `async` but never awaits anything, so it runs synchronously while pretending to be asynchronous. Drop `async` or do the real async work. — GlobalSettingService.cs:73
• `GetSingleSettingForApiAsync` is declared `async` but never awaits anything, so it runs synchronously while pretending to be asynchronous. Drop `async` or do the real async work. — GlobalSettingService.cs:88
• `GetDefaltSettingAsync` is declared `async` but never awaits anything, so it runs synchronously while pretending to be asynchronous. Drop `async` or do the real async work. — GlobalSettingService.cs:96
• `CreatePdfInvoice` is declared `async` but never awaits anything, so it runs synchronously while pretending to be asynchronous. Drop `async` or do the real async work. — PDFHelper.cs:65
• `HealthTips` is declared `async` but never awaits anything, so it runs synchronously while pretending to be asynchronous. Drop `async` or do the real async work. — HealthController.cs:18
• `GetListAsync` is declared `async` but never awaits anything, so it runs synchronously while pretending to be asynchronous. Drop `async` or do the real async work. — OperationLogController.cs:23
• `export` is declared `async` but never awaits anything, so it runs synchronously while pretending to be asynchronous. Drop `async` or do the real async work. — OperationLogController.cs:81
• `UploadAsync` is declared `async` but never awaits anything, so it runs synchronously while pretending to be asynchronous. Drop `async` or do the real async work. (×2) — AliyunFileStorage.cs:22, AliyunFileStorage.cs:150
• `GetAsync` is a shipped member whose whole body throws NotImplementedException — scaffolding that was never completed. Implement it or remove the dead surface. — AliyunFileStorage.cs:134
• `GetStorageBaseDirectory` is a shipped member whose whole body throws NotImplementedException — scaffolding that was never completed. Implement it or remove the dead surface. — AliyunFileStorage.cs:140
• `GetAbsolutePath` is a shipped member whose whole body throws NotImplementedException — scaffolding that was never completed. Implement it or remove the dead surface. — AliyunFileStorage.cs:145
• `UploadConfigAsync` is declared `async` but never awaits anything, so it runs synchronously while pretending to be asynchronous. Drop `async` or do the real async work. — AliyunFileStorage.cs:192
• `LocalFileStorage` has 8 unfinished members out of 15 — a scaffolded type that was never implemented. — LocalFileStorage.cs:16
• `GetConfigFile` is a shipped member whose whole body throws NotImplementedException — scaffolding that was never completed. Implement it or remove the dead surface. — LocalFileStorage.cs:46
• `DoesObjectExist` is a shipped member whose whole body throws NotImplementedException — scaffolding that was never completed. Implement it or remove the dead surface. — LocalFileStorage.cs:97
• `DeleteObject` is a shipped member whose whole body throws NotImplementedException — scaffolding that was never completed. Implement it or remove the dead surface. — LocalFileStorage.cs:102
• `UploadConfigAsync` is a shipped member whose whole body throws NotImplementedException — scaffolding that was never completed. Implement it or remove the dead surface. — LocalFileStorage.cs:107
• `GeneratePresignedConfigUri` is a shipped member whose whole body throws NotImplementedException — scaffolding that was never completed. Implement it or remove the dead surface. — LocalFileStorage.cs:112
• `GetDownloadCenterUri` is a shipped member whose whole body throws NotImplementedException — scaffolding that was never completed. Implement it or remove the dead surface. — LocalFileStorage.cs:122
• `GetDownloadCenterFile` is a shipped member whose whole body throws NotImplementedException — scaffolding that was never completed. Implement it or remove the dead surface. — LocalFileStorage.cs:127
• A line of code has been commented out rather than removed — dead weight that rots and confuses. Delete it (version control remembers). (×4) — ScheduleTaskMapping.cs:17, ServiceCollectionExtensions.cs:60, ServiceCollectionExtensions.cs:143, …

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 build/run (quick start) section to the root README — the first thing a newcomer needs.
• Add a 'Testing' section to the root README — how to run the test suite.
• Add an 'Architecture' / 'How it works' section to the root README — the high-level shape.
• Add a README to the 12 of 12 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 — no conventional ADR directory, no `NNNN-title.md` documents and nothing ADR-shaped by content. Design rationale recorded elsewhere (a design-notes tree, a mailing list, pull-request discussion) is not visible to this check and is not re-findable per decision, so a future maintainer cannot ask why one choice was made and get an answer.

What to do

• Record significant decisions one document per decision — dated, stating the context, the decision and its consequences — and keep them together wherever your design docs already live (a conventional `docs/adr/` tree with `NNNN-title.md` names is the most discoverable form).

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.

• Production code isn't grouped under a src/ folder — it's spread across several top-level directories, so there's no one place that says 'this is the product'.
• No test surface was found — there are no tests here to separate from production code, so the folder question hasn't been reached yet.

What to do

• Group production code under src/ (or split deliberately, e.g. backend/ + frontend/) so production and tooling code aren't mixed at the root.
• Start a test surface where your build system looks for one (tests/, test/, spec/, or your ecosystem's test source set) — the separation follows from putting the first tests in the right place.

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 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 6/11 service-like projects use logging (pure contract/DTO projects are excluded — they have nothing to log). Of those 11, 4 ship a process this repository operates; the rest are libraries their consumer hosts, where the logging decision belongs to the host.

What to do

• Extend structured logging across the projects you operate, and give the library ones a diagnostics seam instead — an `EventSource`/`ActivitySource` the host can subscribe to, or an optional logger on your options object — rather than taking a logging dependency on your consumers' behalf.
• Consider OpenTelemetry tracing/metrics and a health-check endpoint for operability.

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

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 constructed here, and both are collision-broken. If this digest protects anything — a signature, an integrity or tamper check, a credential, or any value an attacker can influence — that is a real weakness: use SHA-256+ for content integrity, or a KDF (PBKDF2/Argon2/BCrypt) for password storage. If it only derives a non-security identifier (a cache key, a file or mutex name), collision resistance carries no security consequence here; make that intent explicit instead — a non-cryptographic hash such as `System.IO.Hashing.XxHash64`/`Crc32` says it in code — since the algorithm alone cannot distinguish the two uses. — EncryptionHelp.cs:34
• 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.)

What to do

• Review each MD5/SHA1 use by what it protects: replace it with SHA-256+ (or a KDF for passwords) where the digest is security-relevant, and switch it to a non-cryptographic hash (`System.IO.Hashing.XxHash64`/`Crc32`) where it only derives an identifier such as a cache key or a mutex name.
• 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.

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). Prefer awaiting it: make the caller `async` and `await` instead. Where a synchronous entry point must stay — a public sync API you cannot break, or a process entry point that must not return until the work finishes — the block belongs in ONE documented bridge and never inside code that is already async; and where it already is that bridge, give the wait a TIMEOUT so a hung task fails the call instead of hanging the process. (×4) — DynamicProxyConfigProvider.cs:66, EventPublisher.cs:34, EventSubscriber.cs:51, …

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 33/149 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. (×25) — LocalFileStorage.cs:20, VideoHelper.cs:23, VideoHelper.cs:53, …

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) — StringExtensions.cs:207, Connection.cs:56, EventSubscriber.cs:305
• An empty catch block silently discards the error — failures vanish with no log and no rethrow. On a teardown path letting it propagate is not an option (throwing out of `Dispose()` masks the failure already in flight and abandons the rest of the cleanup), so make the swallow deliberate instead: narrow the catch to the exception this release can actually raise, and record it through whatever this codebase already uses to report problems — or, if it truly cannot matter, say why in a comment on the catch. (×6) — Connection.cs:156, EventPublisher.cs:290, EventSubscriber.cs:80, …

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. (×21) — NotificationEventHandler.cs:41, ExecuteSeedDataService.cs:123, ExecuteSeedDataService.cs:132, …

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.1 `!` suppressions per 1k syntax nodes — 17 suppression(s) across the 113432 syntax node(s) in code where nullable warnings are ENABLED, which is the only code a `!` can suppress anything in (a `!` under `#nullable disable` is inert and is not counted, and its file's nodes are not in the denominator). 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 `!`.