Executive summary
Read through the Production lens — the standard calibration. *Green* means good enough to run in production. The score is absolute and comparable across repos.
lucasg/Dependencies carries serious gaps (49%). Several issues below can materially affect correctness, security, or the cost of changing it — and propagate to everything that depends on it.
It is strongest in Security (100%) — its security and compliance posture is in good shape. Architecture (97%) is solid too.
The area that most needs attention is Readiness (35%) — releases are harder to depend on — versioning, release notes and dependency hygiene are thin, so consumers can't easily tell what changed or trust an upgrade. Maturity (43%) is the next concern — onboarding is slow — key decisions and the architecture aren't written down, so contributors have to reverse-engineer the intent.
Leadership focus, highest impact first: 1 No tests found finding(s) in Test Distribution (Test Distribution); Nothing pauses a release for a human (Deployment & Rollback); Keep a changelog (e.g. Keep-a-Changelog) recording what shipped… (Release Hygiene).
For scale: Small (~13,276 production lines); rebuilding it from scratch would take roughly ~0.2 person-years (~1 engineer). Approximate, ±~30%.
It builds on a genuinely strong Security foundation (100%); the priorities above are the highest-leverage way to bring the rest up to that level.
Code Health
66%
Adequate · gated by X3
Architecture
97% ★
Exemplary
Maturity
43%
Weak · gated by D34, M2
Readiness
35%
Weak · gated by D9, P3
Security
100% ★
Exemplary
How the score is built — each lens's share of the headline
Width is the lens's weight in the worst-heaviest fold (the weakest area pulls hardest); colour is that lens's own band. A lens fixes the score in proportion to its width.
Readiness 35% · 47% weightMaturity 43% · 26% weightCode Health 66% · 14% weightArchitecture 97% · 8% weightSecurity 100% · 4% weight
Raise Readiness 35 → 70 (the Healthy floor) ⇒ headline 49 → ~60.
Code composition — where the lines go
Business logic 36%Plumbing 59%Tests 2%Generated 2%
Rebuild cost & value ~ Modeled — €7,400–€38,000
| Cost to rebuild | €7,400–€38,000 |
| Domain complexity | Standard |
| Quality factor | 0.7× (at 49% quality) |
| Size & shape | Small · 40% boilerplate · 23% straight-line · 38% branching logic |
This codebase represents roughly ~0.2 person-years of build effort (about ~€23,000 to rebuild). Its weakest lens is Readiness at 35% — the part of that asset most exposed by the findings below.
Top priorities
1
Resolve the 1 No tests found finding(s) in Test Distribution.
2
Resolve the 3 Largest orphaned file finding(s) in Knowledge Freshness — start with DependencyWindow.xaml.cs, Program.cs, SxsManifest.cs.
3
Resolve the 1 No ADRs found finding(s) in ADR Quality.
Diagnosis — what's actually going on
Value concentrated against a weak lens
This is a Small asset (~0.2 person-years to rebuild), and its weakest lens is Readiness at 35%. The operational and business risk on an asset this size concentrates there — that's where remediation buys the most protection.
Highest-leverage move
Of everything flagged, the best return on effort is: Resolve the 1 No tests found finding(s) in Test Distribution. The rest can wait behind it.
Architecture — module dependency graph
Architecture — module dependency matrix
At a glance — Code Health
The Good
D1 · .NET / C#
Cyclomatic Complexity
9.0
D2 · .NET / C#
Cognitive Complexity
8.0
D3 · .NET / C#
God Classes
9.7
D4 · .NET / C#
Code Duplication
10.0
D17 · .NET / C#
Explicit Debt
8.8
D18 · .NET / C#
Solution Shape
10.0
GD1 · Repo
Unfinished & placeholder code
9.8
IC1 · Repo
Incompleteness & stubs
10.0
X1 · Repo
Async correctness
10.0
X4 · Repo
Structured logging
10.0
At a glance — Architecture
The Good
D5 · .NET / C#
Coupling
7.3
D6 · .NET / C#
Cohesion (LCOM4)
8.8
D26 · .NET / C#
Project Cohesion
10.0
D35 · .NET / C#
Change Coupling
10.0
AX10 · Repo
Code composition
10.0
AX3 · Repo
Project dependency cycles
10.0
AX4 · Repo
Dependency direction
10.0
AX5 · Repo
Architecture & structure
10.0
AX6 · Repo
Interface segregation
10.0
At a glance — Maturity
The Good
The Ugly
At a glance — Readiness
The Good
At a glance — Security
Roadmap
First, address the single missing test case to improve test coverage. Next, implement a draft release or manual gate to prevent bad builds from reaching users. Then, maintain a changelog to track what ships in each release. After that, create architecture decision records to document significant design choices. Finally, add OpenTelemetry tracing and health-check endpoints to enhance observability.
| Do this | Helps | Effort | Dimension |
|---|---|---|---|
| Resolve the 1 No tests found finding(s) in Test Distribution. | +14.5 pts | Low | Test Distribution |
| Resolve the 3 Largest orphaned file finding(s) in Knowledge Freshness — start with DependencyWindow.xaml.cs, Program.cs, SxsManifest.cs. | +8.1 pts | Low | Knowledge Freshness |
| Resolve the 1 No ADRs found finding(s) in ADR Quality. | +7.5 pts | Low | ADR Quality |
| Nothing pauses a release for a human: publish as a draft release (or gate the release job on a protected tag/manual dispatch) so a bad build can be stopped before users can download it. | +12.5 pts | Medium | Deployment & Rollback |
| Keep a changelog (e.g. Keep-a-Changelog) recording what shipped in each release. | +12.5 pts | Medium | Release Hygiene |
| 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). | +10.7 pts | Medium | Architecture documentation |
| Consider OpenTelemetry tracing/metrics and a health-check endpoint for operability. | +9.5 pts | Medium | Observability |
| Group production code under src/ (or split deliberately, e.g. backend/ + frontend/) so production and tooling code aren't mixed at the root. | +8.5 pts | Medium | Folder & project structure |
File quality
| File | Score | Band | Worst signal |
|---|---|---|---|
| DependenciesLib/SxsManifest.cs | 6.0 | Mixed | Explicit Debt: TodoComment |
| DependenciesGui/DependencyWindow.xaml.cs | 6.0 | Mixed | Explicit Debt: TodoComment |
| DependenciesLib/BinaryCache.cs | 6.0 | Mixed | Explicit Debt: TodoComment |
| DependenciesGui/MainWindow.xaml.cs | 6.0 | Mixed | Explicit Debt: TodoComment |
| DependenciesGui/Models/ModuleInfo.cs | 6.1 | Mixed | Explicit Debt: EmptyCatchBlock |
| DependenciesLib/FindPeModule.cs | 7.3 | Mixed | Explicit Debt: TodoComment |
| DependenciesGui/About.xaml.cs | 7.6 | Mixed | Explicit Debt: EmptyCatchBlock |
| DependenciesGui/DependencyCustomListView.xaml.cs | 7.6 | Mixed | Explicit Debt: EmptyCatchBlock |
| DependenciesGui/DependencyExportList.xaml.cs | 7.6 | Mixed | Explicit Debt: EmptyCatchBlock |
| DependenciesGui/DependencyImportList.xaml.cs | 7.6 | Mixed | Explicit Debt: EmptyCatchBlock |
| DependenciesGui/Models/PeExport.cs | 7.6 | Mixed | Explicit Debt: EmptyCatchBlock |
| DependenciesGui/Models/PeImport.cs | 7.6 | Mixed | Explicit Debt: EmptyCatchBlock |
| DependenciesGui/DependencyModuleList.xaml.cs | 8.2 | Near-clean | Explicit Debt: TodoComment |
| third_party/Dragablz/Dragablz/StackOrganiser.cs | 8.5 | Near-clean | Cognitive Complexity: StackOrganiser.Measure (cognitive 23) |
| third_party/Dragablz/Dragablz/TabablzControl.cs | 8.5 | Near-clean | Cognitive Complexity: TabablzControl.ReceiveDrag (cognitive 20) |
| DependenciesGui/GridViewSort.cs | 8.5 | Near-clean | Cognitive Complexity: GridViewSort.ColumnHeader_Click (cognitive 17) |
| third_party/Dragablz/Dragablz/DragablzItemsControl.cs | 8.5 | Near-clean | Cohesion (LCOM4): Low cohesion: DragablzItemsControl (LCOM4 5) |
| third_party/phnt/README.md | 9.5 | Near-clean | Documentation Quality: The phnt header collection README is a short 'This collection of Native API header files has been maintained since 2009...' entry with no usage example and only PHNT_VERSION defines; it does not explain how to use the headers or what symbols are exposed. |
Methodology & how to trust this report
Watchdog is a deep, periodic assessment — run each sprint, monthly, or quarterly, taking the time to go wider and deeper than a quick check and surfacing in one coherent report what you'd otherwise piece together from a dozen separate tools. It scores deterministically: the same commit yields the same score, every run. 38 of 40 evaluated dimensions are computed purely by tools and static analysis (confidence 1.0); 2 documentation/naming judgement(s) are LLM-assisted and labelled advisory. Overall confidence is 0.5 — the weighted average across measured dimensions; it falls as more of the score leans on LLM-assisted judgement and rises when it's fully tool-backed.
What we checked — 40 dimensions across the health lenses
D1D2D3D4D5D6D9D12D13D15D17D18D19D20D21D26D28D29D34D35AX10AX3AX4AX5AX6GD1IC1M1M2M3M4P1P2P3P4P6X1X2X3X4
How to trust any code-health report — three questions
- Can you open the finding? Real findings cite a repo-relative file and line you can open at the cited line — never an absolute scratch path. Here, 48 of 61 do; the remainder are repo-wide signals — a dimension-level measurement, not a single line.
- Is there a tool behind the number? Every score below names the method that produced it — Roslyn, git, a scanner, or (for a handful of documentation/naming dimensions) an LLM labelled sampled · advisory — not a narrative.
- Does re-running give the same result? Run it again on the same commit and the score — and this report, byte for byte — is identical. A report whose numbers move between runs is describing the run, not the code.
Tools & methods
| Method | Backs | Version | Evaluator |
|---|---|---|---|
| Roslyn static analysis | Complexity, cohesion, coupling, dead code, API surface, layering | 5.3.0 | ✓ deterministic |
| Native secret scanner | Hardcoded secrets / credentials | 1.0.0 | ✓ deterministic |
| jscpd | Code duplication | — | ✓ deterministic |
| Coverage (coverlet / dotnet-coverage) | Line & branch coverage | 10.0.302 | ✓ deterministic |
| NuGet / dotnet | Outdated, vulnerable & deprecated dependencies | 10.0.302 | ✓ deterministic |
| git / LibGit2Sharp | Churn hotspots, knowledge concentration, history | 2.43.0 · 0.31.0 | ✓ deterministic |
| gitleaks · semgrep · trivy | Secrets in history, SAST, CVEs, IaC & container, PII / GDPR | 1.86.0 · 0.69.3 | ✓ deterministic |
| LLM (sampled · advisory) | Documentation quality, ADR conformance, naming — sampled over a bounded sample; advisory, never a deterministic measurement | Local LLM | ◐ LLM · sampled · advisory |
Run transparency — what happened this run
- D24 Comment Value — LLM provider failed — The model provider returned an unusable result, so this LLM-assisted dimension fell back to a measurement gap (confidence 0) rather than a penalty. Re-run with a reachable provider to score it.
Limitations & what we did not check
Watchdog assesses the repository exactly as committed, and only the repository. By design it does not reach outside the source tree: the live cloud account, the running CI/CD pipeline, the host's branch-protection and approval rules, the production configuration, or a restore actually exercised against a backup are all out of scope. That boundary is a feature, not a gap — a repo-relative, deterministic scan re-runs identically on any commit and every finding opens at a real file and line, where a live audit can neither be reproduced nor traced. The visible consequence is that controls which leave no in-repo evidence are reported as "not evidenced" and excluded from the score rather than awarded a number a static scan cannot justify.
Per-dimension blind spots
- D1 Cyclomatic Complexity: Cyclomatic complexity counts branches statically — it cannot tell an essential decision tree from accidental tangle, nor see complexity that lives in data or configuration (large switch-case token tables, DSL lexers/parsers, data-as-code rule tables) rather than control flow: a tokenizer's many single-character cases read as high complexity though each branch is trivial.
- D2 Cognitive Complexity: Cognitive-complexity heuristics approximate how hard code is to follow; genuine domain difficulty and well-named intent that eases reading are not captured.
- D3 God Classes: "God class" is sized by members and responsibilities visible in the type — a deliberately broad facade over a coherent subsystem can read the same as an accidental grab-bag. For front-end JS the file-length check is cohesion-aware (a single-responsibility module — one class/IIFE — earns a 3× threshold), but cohesion is approximated from top-level declarations, not true dependency structure.
- D4 Code Duplication: Duplication is token-similarity (jscpd) — it finds copy-paste, not semantic duplication expressed differently. Committed machine-written code (scaffolded migrations, designer/codegen output, protobuf/OpenAPI stubs, model snapshots) is EXCLUDED — its repetition is the tool's, not the team's — so the score reflects hand-written duplication only.
- D5 Coupling: Coupling is measured between projects/assemblies — runtime coupling through DI, reflection, messaging or shared databases is invisible to a static reference graph.
- D6 Cohesion (LCOM4): LCOM4 cohesion is syntactic — it infers connectivity from which methods touch which fields/methods by name, not from real runtime behaviour or intent.
- D9 Test Distribution: The test-pyramid shape is inferred from project/folder naming and references, with a single test host bucketed per-file by its path tier and content signals — a suite that names tiers unconventionally and gives no per-file signal can still be mis-bucketed.
- D12 Dependency Hygiene: Dependency health reads manifests and lockfiles — a vulnerability in a vendored/copied dependency, or risk from how a dependency is actually used, is outside this view.
- D13 Secret Scanning: Secret detection is signature- and entropy-based on the current tree — a secret that does not match a known pattern, or one already rotated, will not be flagged (a clean scan is "nothing matched", not "no secrets exist").
- D15 Churn × Complexity Hotspots: Churn hotspots come from git history — a freshly imported or squashed repository has no churn signal, and recent rewrites can mask a historically risky file.
- D17 Explicit Debt: Acknowledged-debt signals (TODO/FIXME, suppressions, dead code) are textual — undocumented debt that nobody marked, and debt that lives in design rather than annotations, is invisible. Committed machine-written code (scaffolded migrations, designer/codegen output, generated stubs) is excluded — it is never the team's dead code to delete.
- D18 Solution Shape: Build integrity reflects whether the solution compiled in this environment — a build that needs a private feed, a specific SDK, or a generated file absent from the repo can read as broken when it is merely unreproducible here.
- D19 Documentation Quality: Documentation quality is judged by an LLM over a bounded sample of docs — it reads what is written, not whether the docs match the running system, and it is advisory, not a measurement.
- D20 ADR Quality: ADR quality is an LLM read of the decision records present — it cannot know about decisions made and never recorded, and its verdict is sampled and advisory.
- D21 Naming Consistency: Naming quality is an LLM judgement over a bounded sample — it assesses clarity/consistency of the names it sees, not domain-correctness, and is advisory.
- D26 Project Cohesion: Project focus is sized from members/namespaces per project — a project that is broad by deliberate design reads the same as one that has sprawled.
- D28 Secrets (history): Secret-history scanning sweeps the git log for known patterns — a secret that predates the available history, or never matched a signature, is not found (clean means "nothing matched in the history we can see").
- D29 Static Analysis (SAST): SAST findings are pattern-based (semgrep) — it finds classes of bug it has rules for; logic flaws, auth/authorization gaps and issues needing runtime context are out of reach (and clean means "no rule matched").
- D34 Knowledge Freshness: Freshness is decayed commit RECENCY, not comprehension — code read often but rarely committed reads as orphaned, and stable code that genuinely needs no changes is penalised the same as forgotten code; bot/squash commits distort it like the bus factor.
- D35 Change Coupling: Change coupling is co-change in COMMITS — files split across separate commits, or coupled only through a shared config/build step, read as uncoupled, and a sweeping commit (rename/format) is excluded so it doesn't couple everything. It shows that files change together, not WHY: a high coupling can be a healthy cohesive pair as readily as a hidden leak.
- AX10 Code composition: Role is inferred from namespace/folder convention, not semantics — a domain concept living in a folder named "Services" reads as application, and the split is lines-of-code, not business value. The business-logic-share score is a SOFT, FLOORED signal: it contributes to the Architecture lens but is floored at the Critical gate, so an infrastructure-heavy design (a gateway, an ETL, a driver) is legitimately low without being nuked to zero.
- M4 Documentation accuracy: Onboarding quality is an LLM read of the docs/setup present — it cannot run the onboarding or measure how long a real new joiner takes; the verdict is sampled and advisory.
- P4 Deployment & Rollback: Approval/branch-protection rules live in repository settings the scan cannot see — only their in-repo evidence (config files, workflows) is checked, so a control enforced purely in the host's settings reads as "not evidenced".
- P6 Release Hygiene: Rollback/observability controls are inferred from repo artefacts (pipelines, dashboards-as-code) — controls configured in external tooling, with no in-repo trace, cannot be credited.
The LLM boundary
Dimensions
D1 · Cyclomatic Complexity
3 method(s) exceeded the cyclomatic complexity threshold of 15; the worst was SxsManifest.ExtractDependenciesFromSxsElement at 30.
SxsManifest.ExtractDependenciesFromSxsElement (cyclomatic 30)DependenciesLib/SxsManifest.cs:121
DependencyWindow.ProcessClrImports (cyclomatic 16)DependenciesGui/DependencyWindow.xaml.cs:768
DependencyWindow.ConstructDependencyTree (cyclomatic 16)DependenciesGui/DependencyWindow.xaml.cs:975
Do you agree with this assessment?
D2 · Cognitive Complexity
8 method(s) exceeded the cognitive complexity threshold of 15; the worst was SxsManifest.ExtractDependenciesFromSxsElement at 53.
SxsManifest.ExtractDependenciesFromSxsElement (cognitive 53)DependenciesLib/SxsManifest.cs:121
DependencyWindow.ProcessClrImports (cognitive 42)DependenciesGui/DependencyWindow.xaml.cs:768
DependencyWindow.ConstructDependencyTree (cognitive 41)DependenciesGui/DependencyWindow.xaml.cs:975
StackOrganiser.Measure (cognitive 23)third_party/Dragablz/Dragablz/StackOrganiser.cs:219
TabablzControl.ReceiveDrag (cognitive 20)third_party/Dragablz/Dragablz/TabablzControl.cs:1301
What to do
- Resolve the 1 SxsManifest.ExtractDependenciesFromSxsElement (cognitive 53) finding(s) in Cognitive Complexity — start with SxsManifest.cs. — One of this dimension's main actionable groups (1 warning-level).
- Resolve the 1 DependencyWindow.ProcessClrImports (cognitive 42) finding(s) in Cognitive Complexity — start with DependencyWindow.xaml.cs. — One of this dimension's main actionable groups (1 warning-level).
- Resolve the 1 DependencyWindow.ConstructDependencyTree (cognitive 41) finding(s) in Cognitive Complexity — start with DependencyWindow.xaml.cs. — One of this dimension's main actionable groups (1 warning-level).
- Enforce Cognitive Complexity in CI to reach Verified (currently Documented). — Hardens enforcement from Documented toward Prevented — provenance only; does not change the score.
Do you agree with this assessment?
D3 · God Classes
2 god class(es) detected.
FileTooLong: DependenciesGui/DependencyWindow.xaml.csDependenciesGui/DependencyWindow.xaml.cs:0
ClassTooLong: DependencyWindowDependenciesGui/DependencyWindow.xaml.cs:0
Do you agree with this assessment?
D4 · Code Duplication
1 duplicated block group(s) detected.
Duplicated block (23 lines × 3)DependenciesGui/Models/ModuleInfo.cs:449
Do you agree with this assessment?
D5 · Coupling
6 projects, 0 dependency cycle(s), 0 unstable depended-on project(s).
Off the main sequence: Dragablz.net45
What to do
- Resolve the 2 Off the main sequence finding(s) in Coupling. — One of this dimension's main actionable groups (2 warning-level).
- Enforce Coupling in CI to reach Verified (currently Documented). — Hardens enforcement from Documented toward Prevented — provenance only; does not change the score.
Do you agree with this assessment?
D6 · Cohesion (LCOM4)
3 of 31 classes have LCOM4 above 3.
Low cohesion: DragablzItemsControl (LCOM4 5) third_party/Dragablz/Dragablz/DragablzItemsControl.cs:17
What to do
- Resolve the 3 Low cohesion finding(s) in Cohesion (LCOM4) — start with DragablzItemsControl.cs, DependencyWindow.xaml.cs, MainWindow.xaml.cs. — One of this dimension's main actionable groups (3 warning-level).
- Enforce Cohesion (LCOM4) in CI to reach Verified (currently Documented). — Hardens enforcement from Documented toward Verified — provenance only; does not change the score.
Do you agree with this assessment?
D9 · Test Distribution
No test suite found.
No tests found
What to do
- Resolve the 1 No tests found finding(s) in Test Distribution. — One of this dimension's main actionable groups (1 recommendation-level).
Do you agree with this assessment?
D12 · Dependency Hygiene
0 outdated, 0 vulnerable, 0 deprecated packages.
Do you agree with this assessment?
D13 · Secret Scanning
Secret scan ran and found no leaked secrets.
Do you agree with this assessment?
D15 · Churn × Complexity Hotspots
No churn × complexity hotspots in the window.
Do you agree with this assessment?
D17 · Explicit Debt
23 deducted debt markers + 0 dead symbols across 13243 LoC (0.6/KLoC) → score 8.8.
EmptyCatchBlock DependenciesGui/About.xaml.cs:76
TodoComment DependenciesGui/DependencyModuleList.xaml.cs:94
CommentedOutCode DependenciesGui/MainWindow.xaml.cs:217
What to do
- Resolve the 7 EmptyCatchBlock finding(s) in Explicit Debt — start with About.xaml.cs, DependencyCustomListView.xaml.cs, DependencyExportList.xaml.cs. — One of this dimension's main actionable groups (7 issue-level).
- Resolve the 14 TodoComment finding(s) in Explicit Debt — start with DependencyWindow.xaml.cs (5), SxsManifest.cs (4), FindPeModule.cs (2). — One of this dimension's main actionable groups (14 warning-level).
- Resolve the 2 CommentedOutCode finding(s) in Explicit Debt — start with MainWindow.xaml.cs, SxsManifest.cs. — One of this dimension's main actionable groups (2 warning-level).
- Enforce Explicit Debt in CI to reach Verified (currently Documented). — Hardens enforcement from Documented toward Prevented — provenance only; does not change the score.
Do you agree with this assessment?
D18 · Solution Shape
6 projects, 33 source files, 13551 hand-written lines of code (13243 production / 308 test), plus 274 generated (machine-written code — designer, scaffolded and tool-emitted files — excluded from quality), 4 inter-project edges.
Do you agree with this assessment?
D19 · Documentation Quality
The open-source Dependencies project has clear, well-structured documentation (download links, release notes, usage example) and a third-party phnt header collection README. The native-libs demumble and llvm-demangle projects are thin single-file docs with no outline sections named but the body is clipped by the scanner, so completeness cannot be flagged. All four README files present; coverage is low (XML-doc 26/387 for DependenciesGui) but the visible documentation is strong.
The phnt header collection README is a short 'This collection of Native API header files has been maintained since 2009...' entry with no usage example and only PHNT_VERSION defines; it does not explain how to use the headers or what symbols are exposed.third_party/phnt/README.md
XML-doc coverage: DependenciesGui DependenciesGui/DependenciesGui.csproj
What to do
- Resolve the 1 The phnt header collection README is a short 'This collection of Native… finding(s) in Documentation Quality — start with README.md. — One of this dimension's main actionable groups (1 recommendation-level).
Do you agree with this assessment?
D20 · ADR Quality
No architecture decision records were found.
No ADRs found
What to do
- Resolve the 1 No ADRs found finding(s) in ADR Quality. — One of this dimension's main actionable groups (1 recommendation-level).
Do you agree with this assessment?
D21 · Naming Consistency
2 naming inconsistencies across 200 sampled symbols.
Inconsistent naming for file path properties: some use 'Filepath' (camelCase) while others use 'ModuleFilePath' (PascalCase) or 'ModuleName' (different concept). Specifically, 'Filepath' vs 'ModuleFilePath' represents a naming inconsistency for the same or similar concept (file path).
Inconsistent naming for dependency-related concepts: 'PeDependencyItem' vs 'PeDependencies'. One is singular, the other plural, suggesting the same or related concepts are named differently.
What to do
- Resolve the 1 Inconsistent naming for file path properties finding(s) in Naming Consistency. — One of this dimension's main actionable groups (1 recommendation-level).
- Resolve the 1 Inconsistent naming for dependency-related concepts finding(s) in Naming Consistency. — One of this dimension's main actionable groups (1 recommendation-level).
Do you agree with this assessment?
D26 · Project Cohesion
0 of 6 projects flagged as possibly oversized/incoherent.
Do you agree with this assessment?
D28 · Secrets (history)
gitleaks scanned the full history AND the current working tree and found no secrets.
Do you agree with this assessment?
D29 · Static Analysis (SAST)
semgrep found no security issues.
Do you agree with this assessment?
D34 · Knowledge Freshness
20 of 20 significant source file(s) are orphaned — their living knowledge has decayed to nothing, so no one currently understands them. The largest is DependenciesGui/DependencyWindow.xaml.cs.
Largest orphaned file DependenciesGui/DependencyWindow.xaml.cs
Dormant codebase
What to do
- Resolve the 3 Largest orphaned file finding(s) in Knowledge Freshness — start with DependencyWindow.xaml.cs, Program.cs, SxsManifest.cs. — One of this dimension's main actionable groups (3 recommendation-level).
- Resolve the 1 Dormant codebase finding(s) in Knowledge Freshness. — One of this dimension's main actionable groups (1 recommendation-level).
Do you agree with this assessment?
D35 · Change Coupling
No strong hidden change-coupling between production files.
Do you agree with this assessment?
Frontend & cross-cutting dimensions
AX10 · Code composition
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).
Do you agree with this assessment?
AX3 · Project dependency cycles
Do you agree with this assessment?
AX4 · Dependency direction
Do you agree with this assessment?
AX5 · Architecture & structure
Do you agree with this assessment?
AX6 · Interface segregation
Do you agree with this assessment?
GD1 · Unfinished & placeholder code
- A shipped member still throws NotImplementedException — generated scaffolding that was never completed. Implement it or remove the dead surface. (×5) — Shell32IconExtractor.cs:130, Shell32IconExtractor.cs:169, MainWindow.xaml.cs:384, …
What to do
- Finish or delete NotImplementedException stubs and replace placeholder literals before shipping.
Do you agree with this assessment?
IC1 · Incompleteness & stubs
- A line of code has been commented out rather than removed — dead weight that rots and confuses. Delete it (version control remembers). (×29) — Program.cs:119, Program.cs:120, Program.cs:421, …
What to do
- 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.
Do you agree with this assessment?
M1 · Documentation (README)
What to do
- 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 6 of 6 project(s) that lack one — worth up to 2 pts.
Do you agree with this assessment?
M2 · Architecture documentation
- 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.
- No C4/PlantUML/Mermaid diagram or architecture.md — the high-level shape isn't documented.
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).
- Add a C4 context/container diagram (Structurizr, PlantUML or Mermaid) or an architecture.md overview.
Do you agree with this assessment?
M3 · Folder & project structure
- 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'.
- Only 3/6 projects share a common root namespace — the code's module identity is inconsistent.
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.
- Adopt a consistent root-namespace convention (a shared prefix, e.g. Acme.*); short project-file/directory names are fine as long as the RootNamespace is uniform.
Do you agree with this assessment?
M4 · Documentation accuracy
Do you agree with this assessment?
P1 · CI/CD gates
Do you agree with this assessment?
P2 · Observability
What to do
- Consider OpenTelemetry tracing/metrics and a health-check endpoint for operability.
Do you agree with this assessment?
P3 · Security & performance tooling
- No static application security testing detected. For this repository's stack, add CodeQL's csharp pack (it analyses VB.NET too), or a security analyzer package (or `semgrep --config=auto`, which runs on any language) as a CI step.
What to do
- Add a SAST step to CI running what this repository's stack ships: CodeQL's csharp pack (it analyses VB.NET too), or a security analyzer package — or `semgrep --config=auto`, which runs on any language — so a security regression fails the build instead of landing.
- Enable Dependabot/Renovate or a dependency-review gate.
- Add gitleaks/trufflehog in CI to block PRs that introduce committed secrets.
Do you agree with this assessment?
P4 · Deployment & Rollback
What to do
- Nothing pauses a release for a human: publish as a draft release (or gate the release job on a protected tag/manual dispatch) so a bad build can be stopped before users can download it.
Do you agree with this assessment?
P6 · Release Hygiene
- No CHANGELOG/HISTORY/RELEASES file — what shipped when isn't easy to reconstruct for support or audit. (Versioning/tagging makes releases traceable, but a changelog records the what.)
What to do
- Keep a changelog (e.g. Keep-a-Changelog) recording what shipped in each release.
Do you agree with this assessment?
X1 · Async correctness
Do you agree with this assessment?
X2 · Cancellation propagation
- Only 0/2 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. (×2) — About.xaml.cs:36, About.xaml.cs:51
What to do
- Thread a CancellationToken through async methods so work stops promptly on cancellation.
Do you agree with this assessment?
X3 · Exception handling
- 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. (×7) — About.xaml.cs:76, DependencyCustomListView.xaml.cs:88, DependencyExportList.xaml.cs:64, …
- `throw rex;` resets the exception's stack trace to this line, hiding where it really came from. Use a bare `throw;` to preserve the original stack. — Program.cs:547
What to do
- Swallowed exception (empty catch)
Do you agree with this assessment?
X4 · Structured logging
Do you agree with this assessment?
Reference — by lens
| Lens | Score | Rating | Impact |
|---|---|---|---|
| Code Health | 66% | Adequate — gated by X3 | Capped at Fair by a Critical contributor — resolve it before relying on this lens. |
| Architecture | 97% | Exemplary | Solid. |
| Maturity | 43% | Weak — gated by D34, M2 | Capped at Fair by a Critical contributor — resolve it before relying on this lens. |
| Readiness | 35% | Weak — gated by D9, P3 | Capped at Fair by a Critical contributor — resolve it before relying on this lens. |
| Security | 100% | Exemplary | Strongest area. |
Not included — 56 check(s) not relevant to this codebase
- AC1 Text alternatives — No web markup found — accessibility is not applicable to this repository.
- AC2 Forms & labels — No web markup found — accessibility is not applicable to this repository.
- AC3 Page structure — No web markup found — accessibility is not applicable to this repository.
- AC4 Keyboard semantics — No web markup found — accessibility is not applicable to this repository.
- AC5 ARIA correctness — No web markup found — accessibility is not applicable to this repository.
- AC6 Visual & motion safety — No web markup found — accessibility is not applicable to this repository.
- AC7 A11y enforcement — No web markup found — accessibility is not applicable to this repository.
- AX1 Captive dependencies — no DI registrations detected
- AX2 Stateful singletons — no singleton implementations detected
- AX7 Slice cohesion — not applicable — not a vertical-slice architecture
- AX8 Test isolation — no test/production split to check
- AX9 CQS / query purity — no CQRS query handlers detected — query purity is not applicable to this codebase
- C1 Data Protection — No personal data detected in the analyzed source — no PII-typed entity/column names (Email, FirstName, DateOfBirth, …), no ASP.NET Identity / user-account model, and no stored user credentials. GDPR data-protection controls are therefore N/A here. If this is intentional, record the no-PII posture in an ADR; if the app does process personal data, name those fields conventionally so this dimension activates.
- C2 Access Controls — No access-control surface detected in the analyzed source — no web/app surface to authorize (no HTTP API or web-UI project) and no authorization code at all (no [Authorize]/policies, no imperative guard methods). Access control is therefore N/A here — this is a library/CLI, which is authorized by its CALLER, not by itself. If this codebase grows request handlers, the dimension reactivates and a default-deny posture is expected then.
- C3 Audit Trail — No personal data detected in the analyzed source — no PII-typed entity/column names (Email, FirstName, DateOfBirth, …), no ASP.NET Identity / user-account model, and no stored user credentials. GDPR data-protection controls are therefore N/A here. If this is intentional, record the no-PII posture in an ADR; if the app does process personal data, name those fields conventionally so this dimension activates.
- C4 Data Retention — No personal data detected in the analyzed source — no PII-typed entity/column names (Email, FirstName, DateOfBirth, …), no ASP.NET Identity / user-account model, and no stored user credentials. GDPR data-protection controls are therefore N/A here. If this is intentional, record the no-PII posture in an ADR; if the app does process personal data, name those fields conventionally so this dimension activates.
- C5 Data-Subject Rights — No personal data detected in the analyzed source — no PII-typed entity/column names (Email, FirstName, DateOfBirth, …), no ASP.NET Identity / user-account model, and no stored user credentials. GDPR data-protection controls are therefore N/A here. If this is intentional, record the no-PII posture in an ADR; if the app does process personal data, name those fields conventionally so this dimension activates.
- D10 Test Quality — ~308 lines of test code exist on disk but weren't loaded from the analyzed solution (excluded from the .sln, or co-located/using a test attribute not loaded here), so test quality couldn't be assessed. Include the tests in the analyzed solution to enable this check.
- D11 Test Reliability — Test reliability not measured — no test run produced results
- D14 License Compliance — license scan produced no result — the tool ran but its JSON output could not be parsed; the offline NuGet fallback resolved nothing
- D16 Bus Factor — dormant codebase — no living knowledge left to concentrate
- D22 Internal API Consistency — No exposed public API
- D23 Boundary Type-Coupling — Bounded contexts not declared
- D24 Comment Value — LLM evaluation failed
- D25 ADR Conformance — no ADRs to check
- D27 Navigability — symbol resolution incomplete — navigability not assessed
- D30 Dependency Vulnerabilities — the solution did not restore on the analyzer's .NET SDK (an SDK/target-framework/restore mismatch, common for an older codebase), so there was no restored dependency graph to scan for NuGet CVEs — excluded rather than scored; re-run on an SDK that can restore this solution
- D31 IaC & Container Security — No Infrastructure-as-Code or container manifests found (Dockerfile, Terraform, Kubernetes/Helm, CloudFormation); nothing to scan.
- D32 Data Compliance (PII/GDPR) — No PII/GDPR-handling patterns detected (p/gdpr ruleset) — no data-compliance surface to assess.
- D33 JS/npm Dependency Vulnerabilities — No JS/npm manifest or lockfile found outside build output (package.json, package-lock.json, yarn.lock, pnpm-lock.yaml, bun.lockb); no JS dependencies to scan.
- D36 Supply-chain Provenance & Signing — No CI/build pipeline found (.github/.forgejo/.gitea workflows, .gitlab-ci.yml, azure-pipelines*.yml, .pipelines/, .vsts-ci/, Jenkinsfile, .circleci); there is no build to attest provenance for.
- D37 Vulnerability-disclosure Policy — No vulnerability-disclosure policy file found (SECURITY.md/.markdown/.rst/.txt at root or under .github/.forgejo/.gitea/docs, .well-known/security.txt). A coordinated-disclosure policy may live off-repo, so this is not evidenced rather than failed.
- D38 OSV Dependency Vulnerabilities — No supported non-.NET dependency lockfile found outside build output (npm package-lock/yarn/pnpm/bun, Go go.mod, Rust Cargo.lock, Maven pom.xml, Gradle lockfiles, Python requirements.txt/poetry.lock/Pipfile.lock/pdm.lock, PHP composer.lock, Ruby Gemfile.lock, Elixir mix.lock, Dart pubspec.lock, Swift Package.resolved); nothing for OSV to scan. A NuGet-only repo stays NotApplicable — .NET CVEs are D30's domain.
- D39 IL Efficiency — No first-party assembly was produced by the build.
- D40 Network Egress Confinement — No Kubernetes/orchestration workloads found in the repository manifests; network egress policy is a cluster-native control that may live at the platform/firewall layer, so there is nothing to assess here.
- D41 Kernel & Syscall Confinement — No Kubernetes/orchestration workloads found in the repository manifests; seccomp/AppArmor/SELinux confinement is a workload-level control, so there is nothing to assess here.
- D42 Runtime Threat Enforcement — No Kubernetes/orchestration workloads found in the repository manifests; runtime threat-detection and admission-control policy are cluster-level controls, so there is nothing to assess here.
- D7 Architectural Integrity — no checkable ADRs and no dependency cycles — architectural integrity not assessed
- D8 Code Coverage — Coverage not measured
- DM1 Domain Modelling — not scored — this repository shows none of the 3 signals this check looks for
- ED1 Event-Driven — not scored — this repository shows none of the 3 signals this check looks for
- ED5 Idempotency — no mutating command handlers or message consumers detected — idempotency check not applicable
- ES1 Event Sourcing — not scored — this repository shows none of the 3 signals this check looks for
- P12 CI test-gate honesty — Reported, not scored — and nothing was matched here. The coverage check applies to any stack, but the checks for excluded tests, skipped tests and sleep-based synchronisation currently recognise only some ecosystems' test-runner idioms, so on a repository built with another stack the zeros below mean 'not checked', not 'clean'.
- P5 DR & Backup — not evidenced — repo shows no backup/RTO/RPO controls; absence of evidence is not evidence of a working control
- P7 Outbound HTTP resilience — not applicable — this isn't a service/API/worker
- P8 Schema migrations — no EF Core usage detected
- P9 Domain vs controller coverage — no coverage report found on disk — produce a coverage report in a standard format (Cobertura — `dotnet test --collect:"XPlat Code Coverage"` with a `coverlet.collector` PackageReference) into the repo working tree before the scan — a CI step is the usual place, since the artefact is commonly gitignored, or wire coverage collection into CI, to enable this cross-layer check
- PF1 Benchmark discipline — Performance is assessed only for perf-relevant repos — a packaged library, one that ships benchmarks, or one already using allocation-aware APIs. This repo isn't one, so the Performance lens is not applicable and is excluded from the score.
- PF2 Allocation hygiene — Performance is assessed only for perf-relevant repos — a packaged library, one that ships benchmarks, or one already using allocation-aware APIs. This repo isn't one, so the Performance lens is not applicable and is excluded from the score.
- PF3 Async & latency hygiene — Performance is assessed only for perf-relevant repos — a packaged library, one that ships benchmarks, or one already using allocation-aware APIs. This repo isn't one, so the Performance lens is not applicable and is excluded from the score.
- S1 Web-Security Posture — No web surface detected in the analyzed source — no HTTP API or web-UI project (no controllers/minimal-API endpoints, no Razor/Blazor views) and no web middleware (HTTPS redirection, HSTS, security headers, cookies). Transport security, security headers, secure cookies, CSRF/input-validation and middleware-order controls are therefore N/A here — this is a library/CLI/worker, not a web app. Crypto hygiene was still checked and found nothing to flag. If this codebase becomes web-facing, the dimension reactivates automatically.
- SC1 Supply-chain hygiene — Advisory — this card reports evidence and never carries a score, so there is nothing missing here.
- X5 Nullable reference types — no NRT-eligible projects
- X6 Hand-rolled structured-format parsing — Reported, not scored — this card publishes what it found rather than grading it. Its content is the findings and the key metric above.
- X7 Silent fallback defaults — Reported, not scored — this card publishes what it found rather than grading it. Its content is the findings and the key metric above.
Appendix A — Findings (grouped)
Issue — 7 finding(s)
D17 · Explicit Debt
- EmptyCatchBlock DependenciesGui/About.xaml.cs:76
- EmptyCatchBlock DependenciesGui/DependencyCustomListView.xaml.cs:88
- EmptyCatchBlock DependenciesGui/DependencyExportList.xaml.cs:64
- EmptyCatchBlock DependenciesGui/DependencyImportList.xaml.cs:83
- EmptyCatchBlock DependenciesGui/Models/ModuleInfo.cs:466
- EmptyCatchBlock DependenciesGui/Models/PeExport.cs:166
- EmptyCatchBlock DependenciesGui/Models/PeImport.cs:195
Warning — 39 finding(s)
D17 · Explicit Debt
- TodoComment DependenciesGui/DependencyModuleList.xaml.cs:94
- TodoComment DependenciesGui/DependencyWindow.xaml.cs:581
- TodoComment DependenciesGui/DependencyWindow.xaml.cs:721
- TodoComment DependenciesGui/DependencyWindow.xaml.cs:1135
- TodoComment DependenciesGui/DependencyWindow.xaml.cs:1182
- TodoComment DependenciesGui/DependencyWindow.xaml.cs:1320
- TodoComment DependenciesGui/MainWindow.xaml.cs:114
- TodoComment DependenciesLib/BinaryCache.cs:415
- TodoComment DependenciesLib/FindPeModule.cs:139
- TodoComment DependenciesLib/FindPeModule.cs:195
- TodoComment DependenciesLib/SxsManifest.cs:58
- TodoComment DependenciesLib/SxsManifest.cs:163
- TodoComment DependenciesLib/SxsManifest.cs:307
- TodoComment DependenciesLib/SxsManifest.cs:315
D6 · Cohesion (LCOM4)
- Low cohesion: DragablzItemsControl (LCOM4 5) third_party/Dragablz/Dragablz/DragablzItemsControl.cs:17
- Low cohesion: DependencyWindow (LCOM4 4) DependenciesGui/DependencyWindow.xaml.cs:513
- Low cohesion: MainWindow (LCOM4 4) DependenciesGui/MainWindow.xaml.cs:83
D17 · Explicit Debt
- CommentedOutCode DependenciesGui/MainWindow.xaml.cs:217
- CommentedOutCode DependenciesLib/SxsManifest.cs:59
D5 · Coupling
- Off the main sequence: Dragablz.net45
- Off the main sequence: DependenciesLib
D1 · Cyclomatic Complexity
- SxsManifest.ExtractDependenciesFromSxsElement (cyclomatic 30) DependenciesLib/SxsManifest.cs:121
D1 · Cyclomatic Complexity
- DependencyWindow.ProcessClrImports (cyclomatic 16) DependenciesGui/DependencyWindow.xaml.cs:768
D1 · Cyclomatic Complexity
- DependencyWindow.ConstructDependencyTree (cyclomatic 16) DependenciesGui/DependencyWindow.xaml.cs:975
D11 · Test Reliability
- Test reliability not measured — no test run produced results
D16 · Bus Factor
- dormant codebase — no living knowledge left to concentrate
D2 · Cognitive Complexity
- SxsManifest.ExtractDependenciesFromSxsElement (cognitive 53) DependenciesLib/SxsManifest.cs:121
D2 · Cognitive Complexity
- DependencyWindow.ProcessClrImports (cognitive 42) DependenciesGui/DependencyWindow.xaml.cs:768
D2 · Cognitive Complexity
- DependencyWindow.ConstructDependencyTree (cognitive 41) DependenciesGui/DependencyWindow.xaml.cs:975
D2 · Cognitive Complexity
- StackOrganiser.Measure (cognitive 23) third_party/Dragablz/Dragablz/StackOrganiser.cs:219
D2 · Cognitive Complexity
- TabablzControl.ReceiveDrag (cognitive 20) third_party/Dragablz/Dragablz/TabablzControl.cs:1301
D2 · Cognitive Complexity
- BinaryCache.LookupImports (cognitive 19) DependenciesLib/BinaryCache.cs:187
D2 · Cognitive Complexity
- GridViewSort.ColumnHeader_Click (cognitive 17) DependenciesGui/GridViewSort.cs:177
D2 · Cognitive Complexity
- BinaryCache.LookupImport (cognitive 17) DependenciesLib/BinaryCache.cs:150
D24 · Comment Value
- LLM evaluation failed
D3 · God Classes
- FileTooLong: DependenciesGui/DependencyWindow.xaml.cs DependenciesGui/DependencyWindow.xaml.cs:0
D3 · God Classes
- ClassTooLong: DependencyWindow DependenciesGui/DependencyWindow.xaml.cs:0
D4 · Code Duplication
- Duplicated block (23 lines × 3) DependenciesGui/Models/ModuleInfo.cs:449
D8 · Code Coverage
- Coverage not measured
Recommendation — 10 finding(s)
D34 · Knowledge Freshness
- Largest orphaned file DependenciesGui/DependencyWindow.xaml.cs
- Largest orphaned file Dependencies/Program.cs
- Largest orphaned file DependenciesLib/SxsManifest.cs
D19 · Documentation Quality
- The phnt header collection README is a short 'This collection of Native API header files has been maintained since 2009...' entry with no usage example and only PHNT_VERSION defines; it does not explain how to use the headers or what symbols are exposed. third_party/phnt/README.md
D20 · ADR Quality
- No ADRs found
D21 · Naming Consistency
- Inconsistent naming for file path properties: some use 'Filepath' (camelCase) while others use 'ModuleFilePath' (PascalCase) or 'ModuleName' (different concept). Specifically, 'Filepath' vs 'ModuleFilePath' represents a naming inconsistency for the same or similar concept (file path).
D21 · Naming Consistency
- Inconsistent naming for dependency-related concepts: 'PeDependencyItem' vs 'PeDependencies'. One is singular, the other plural, suggesting the same or related concepts are named differently.
D23 · Boundary Type-Coupling
- Bounded contexts not declared
D34 · Knowledge Freshness
- Dormant codebase
D9 · Test Distribution
- No tests found
Info — 5 finding(s)
D19 · Documentation Quality
- XML-doc coverage: DependenciesGui DependenciesGui/DependenciesGui.csproj
- XML-doc coverage: Dependencies Dependencies/Dependencies.csproj
- XML-doc coverage: Dragablz.net45 third_party/Dragablz/Dragablz/Dragablz.net45.csproj
- XML-doc coverage: DependenciesLib DependenciesLib/DependenciesLib.csproj
D22 · Internal API Consistency
- No exposed public API
Appendix B — Reproduction & audit trail
| Dimension | Tool | Version | Command | Findings | Raw output |
|---|---|---|---|---|---|
| D28 · Secrets (history) | gitleaks | — | gitleaks detect --no-banner --report-format json --report-path /dev/stdout --exit-code 0 --source . | 0 | artifacts/raw/gitleaks-history.json |
| D29 · Static Analysis (SAST) | semgrep | — | semgrep --config /opt/semgrep-rules/security-audit.yml --config /opt/semgrep-rules/owasp-top-ten.yml --json --quiet --timeout 0 --metrics off . | 0 | artifacts/raw/semgrep.json |
| D30 · Dependency Vulnerabilities | dotnet | — | dotnet: not applicable — the solution did not restore on the analyzer's .NET SDK (an SDK/target-framework/restore mismatch, common for an older codebase), so there was no restored dependency graph to scan for NuGet CVEs — excluded rather than scored; re-run on an SDK that can restore this solution | 0 | — |
| D31 · IaC & Container Security | trivy | — | trivy: not applicable — No Infrastructure-as-Code or container manifests found (Dockerfile, Terraform, Kubernetes/Helm, CloudFormation); nothing to scan. | 0 | — |
| D32 · Data Compliance (PII/GDPR) | semgrep | — | semgrep: not applicable — No PII/GDPR-handling patterns detected (p/gdpr ruleset) — no data-compliance surface to assess. | 0 | — |
| D33 · JS/npm Dependency Vulnerabilities | trivy | — | trivy: not applicable — No JS/npm manifest or lockfile found outside build output (package.json, package-lock.json, yarn.lock, pnpm-lock.yaml, bun.lockb); no JS dependencies to scan. | 0 | — |
| D36 · Supply-chain Provenance & Signing | provenance | — | provenance: not applicable — No CI/build pipeline found (.github/.forgejo/.gitea workflows, .gitlab-ci.yml, azure-pipelines*.yml, .pipelines/, .vsts-ci/, Jenkinsfile, .circleci); there is no build to attest provenance for. | 0 | — |
| D37 · Vulnerability-disclosure Policy | disclosure | — | disclosure: not applicable — No vulnerability-disclosure policy file found (SECURITY.md/.markdown/.rst/.txt at root or under .github/.forgejo/.gitea/docs, .well-known/security.txt). A coordinated-disclosure policy may live off-repo, so this is not evidenced rather than failed. | 0 | — |
| D38 · OSV Dependency Vulnerabilities | osv-scanner | — | osv-scanner: not applicable — No supported non-.NET dependency lockfile found outside build output (npm package-lock/yarn/pnpm/bun, Go go.mod, Rust Cargo.lock, Maven pom.xml, Gradle lockfiles, Python requirements.txt/poetry.lock/Pipfile.lock/pdm.lock, PHP composer.lock, Ruby Gemfile.lock, Elixir mix.lock, Dart pubspec.lock, Swift Package.resolved); nothing for OSV to scan. A NuGet-only repo stays NotApplicable — .NET CVEs are D30's domain. | 0 | — |
| D40 · Network Egress Confinement | runtime-hardening | — | runtime-hardening: not applicable — No Kubernetes/orchestration workloads found in the repository manifests; network egress policy is a cluster-native control that may live at the platform/firewall layer, so there is nothing to assess here. | 0 | — |
| D41 · Kernel & Syscall Confinement | runtime-hardening | — | runtime-hardening: not applicable — No Kubernetes/orchestration workloads found in the repository manifests; seccomp/AppArmor/SELinux confinement is a workload-level control, so there is nothing to assess here. | 0 | — |
| D42 · Runtime Threat Enforcement | runtime-hardening | — | runtime-hardening: not applicable — No Kubernetes/orchestration workloads found in the repository manifests; runtime threat-detection and admission-control policy are cluster-level controls, so there is nothing to assess here. | 0 | — |