Executive summary
nkz-soft/rust-microservice-template scores 51 out of 100 and is rated Adequate, while six of its seven lenses score higher still: Domain Modelling and Performance at 100 and Architecture at 89, all rated Exemplary, and Code Health at 73, Production Readiness at 55 and Maturity at 53, all rated Adequate. Watchdog judged it as a template, sample or demo, meant to be read or copied, so the dimensions about building, releasing and running a product don't apply, and its lenses are rated against a lower bar. The score itself is worked out as for any repository.
The score is lower than those six because the weakest lens counts most, and here that is Security and Compliance, which scores 36 and is rated Weak. Its Supply-chain Provenance & Signing dimension scores 0 out of 10, and until that reaches 4, Security and Compliance can't be rated higher than Adequate. The first actions are to protect endpoints by default-deny: a global authentication guard or middleware with explicit public opt-outs, or a guard on every route, plus named role/permission rules for what an authenticated caller may do and to secure the server's transport: serve TLS itself (`HttpServer::bind_rustls_0_23(addr, config)` in actix-web, `axum_server::bind_rustls(addr, RustlsConfig::from_pem_file(…))`, tonic's `Server::builder().tls_config(ServerTlsConfig::new().identity(…))`, Rocket's `[default.tls]`), or run it behind a TLS-terminating proxy and check `X-Forwarded-Proto`; send `Strict-Transport-Security` once it is HTTPS-only, and if Security and Compliance rose to 70, the score would rise from 51 to about 61.
18 findings are critical: 15 in Static Analysis (SAST) and three in Dependency Vulnerabilities.
Watchdog couldn't measure 20 dimensions in this code, among them Code Coverage, Test Reliability and Navigability, so they are left out of the score. The product code is 2,865 lines, which would take an estimated 0.1 person-years, around €4,600, to rebuild.
Code Health
73
Adequate, capped by Structured logging
Architecture
89 ★
Exemplary
Maturity
53
Adequate, capped by Architecture documentation
Production Readiness
55
Adequate, capped by DR & Backup
Security and Compliance
36
Weak, capped by Supply-chain Provenance & Signing and Access Controls
Domain Modelling
100 ★
Exemplary
Performance
100 ★
Exemplary
How the score is built: what each lens counts for
The lenses don't count equally. The weakest lens counts most, the next weakest a little less, and so on, so a weak area pulls the score down instead of being averaged away. In the bar below, each part's width shows how much that lens counts and its colour shows its rating. Improving the widest part moves the score most, and as that lens improves, it counts for less, because another lens becomes the weakest.
Security and Compliance 36 · counts for 46%Maturity 53 · counts for 25%Production Readiness 55 · counts for 14%Code Health 73 · counts for 8%Architecture 89 · counts for 4%Domain Modelling 100 · counts for 2%Performance 100 · counts for 1%
If Security and Compliance rose from 36 to 70, the lowest score rated Strong, the score would rise from 51 to about 61.
Code composition: what the lines of code are
Product code 67%Tests 33%
New since the last survey: 4 findings
- Dependency Vulnerabilities · REDACTED
- Dependency Vulnerabilities · REDACTED
- Supply-chain Provenance & Signing · REDACTED
- Access Controls · No authorization src/starter/src/lib.rs
Rebuild cost: about €4,600 · Estimate
| Cost to rebuild | €1,500 to €7,700, for 26 to 81 hours of work, about 0.1 person-years for one engineer |
|---|---|
| Difficulty of the problem | Standard, judged from the kind of software and how it is built. Code that solves a harder problem, such as payments or medical bookings, costs more per line to write. |
| Quality factor | ×0.7 at a score of 51. Better code takes more work to write, so the factor is ×1.0 at a score of 70, lower below it and higher above it. |
| Size | Small: 2,865 lines of product code |
Top priorities
1
Protect endpoints by default-deny: a global authentication guard or middleware with explicit public opt-outs, or a guard on every route, plus named role/permission rules for what an authenticated caller may do.
2
Secure the server's transport: serve TLS itself (`HttpServer::bind_rustls_0_23(addr, config)` in actix-web, `axum_server::bind_rustls(addr, RustlsConfig::from_pem_file(…))`, tonic's `Server::builder().tls_config(ServerTlsConfig::new().identity(…))`, Rocket's `[default.tls]`), or run it behind a TLS-terminating proxy and check `X-Forwarded-Proto`; send `Strict-Transport-Security` once it is HTTPS-only.
3
Resolve the 1 REDACTED finding(s) in Static Analysis (SAST) — start with REDACTED.
Diagnosis: what the measurements show together
Where the investment is most exposed
This code would cost about €4,600 to build again, about 0.1 person-years of work. Its weakest lens is Security and Compliance, at 36 (Weak). Security and Compliance is about how well the product is protected, and how it handles personal data. Because the weakest lens counts most in the score, work on Security and Compliance also moves the score most.
If you do one thing first
Protect endpoints by default-deny: a global authentication guard or middleware with explicit public opt-outs, or a guard on every route, plus named role/permission rules for what an authenticated caller may do. Of all the actions in this report, it raises the score most for the work it takes: about 11 points for medium effort. The next survey will show the change in the score.
Architecture — module dependency graph
Architecture: which parts of the code depend on which
| uses → | 1 application.commands | 2 application.dtos | 3 application.queries | 4 application.settings | 5 domain.entity | 6 infrastructure.errors | 7 presentation.api.api_doc | 8 presentation.api.api_health_check | 9 presentation.api.api_metrics | 10 presentation.api.app | 11 starter.main | 12 application.errors | 13 application.handlers | 14 application.repositories | 15 infrastructure.config | 16 presentation.requests | 17 starter | 18 starter.observability | 19 application.services | 20 infrastructure.postgres_repositories | 21 presentation.errors | 22 domain.entities | 23 presentation.config | 24 application.mappers | 25 presentation.responses |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 application.commands | |||||||||||||||||||||||||
| 2 application.dtos | |||||||||||||||||||||||||
| 3 application.queries | |||||||||||||||||||||||||
| 4 application.settings | |||||||||||||||||||||||||
| 5 domain.entity | |||||||||||||||||||||||||
| 6 infrastructure.errors | |||||||||||||||||||||||||
| 7 presentation.api.api_doc | |||||||||||||||||||||||||
| 8 presentation.api.api_health_check | |||||||||||||||||||||||||
| 9 presentation.api.api_metrics | |||||||||||||||||||||||||
| 10 presentation.api.app | |||||||||||||||||||||||||
| 11 starter.main | |||||||||||||||||||||||||
| 12 application.errors | 1 | ||||||||||||||||||||||||
| 13 application.handlers | 3 | 3 | |||||||||||||||||||||||
| 14 application.repositories | 1 | 1 | |||||||||||||||||||||||
| 15 infrastructure.config | 1 | ||||||||||||||||||||||||
| 16 presentation.requests | 2 | ||||||||||||||||||||||||
| 17 starter | 1 | ||||||||||||||||||||||||
| 18 starter.observability | 2 | ||||||||||||||||||||||||
| 19 application.services | 12 | ||||||||||||||||||||||||
| 20 infrastructure.postgres_repositories | 2 | 1 | 2 | 2 | |||||||||||||||||||||
| 21 presentation.errors | 1 | ||||||||||||||||||||||||
| 22 domain.entities | 1 | 1 | |||||||||||||||||||||||
| 23 presentation.config | 1 | 1 | |||||||||||||||||||||||
| 24 application.mappers | 1 | ||||||||||||||||||||||||
| 25 presentation.responses | 1 | 2 |
Uses a module listed above itPart of a loopThe module itself
12→6 application.errors uses infrastructure.errors✕
- Connections
- 1 pair of types, where a type in application.errors uses a type in infrastructure.errors.
- The types involved
application.errors.ApplicationError→infrastructure.errors.Error
- Direction
- application.errors uses infrastructure.errors, so a change to infrastructure.errors can break application.errors, while a change to application.errors can't break infrastructure.errors.
- Position
- Below the diagonal: application.errors uses a module listed above it, which is the healthy direction.
13→1 application.handlers uses application.commands✕
- Connections
- 3 pairs of types, where a type in application.handlers uses a type in application.commands.
- The types involved
application.handlers.CreateToDoItemCommandHandler→application.commands.CreateToDoItemCommandapplication.handlers.DeleteToDoItemCommandHandler→application.commands.DeleteToDoItemCommandapplication.handlers.UpdateToDoItemCommandHandler→application.commands.UpdateToDoItemCommand
- Direction
- application.handlers uses application.commands, so a change to application.commands can break application.handlers, while a change to application.handlers can't break application.commands.
- Position
- Below the diagonal: application.handlers uses a module listed above it, which is the healthy direction.
13→3 application.handlers uses application.queries✕
- Connections
- 3 pairs of types, where a type in application.handlers uses a type in application.queries.
- The types involved
application.handlers.GetAllToDoItemsQueryHandler→application.queries.GetAllToDoItemsQueryapplication.handlers.GetDeletedToDoItemForAuditQueryHandler→application.queries.GetDeletedToDoItemForAuditQueryapplication.handlers.GetToDoItemQueryHandler→application.queries.GetToDoItemQuery
- Direction
- application.handlers uses application.queries, so a change to application.queries can break application.handlers, while a change to application.handlers can't break application.queries.
- Position
- Below the diagonal: application.handlers uses a module listed above it, which is the healthy direction.
14→3 application.repositories uses application.queries✕
- Connections
- 1 pair of types, where a type in application.repositories uses a type in application.queries.
- The types involved
application.repositories.ToDoItemQueryRepository→application.queries.GetAllToDoItemsQuery
- Direction
- application.repositories uses application.queries, so a change to application.queries can break application.repositories, while a change to application.repositories can't break application.queries.
- Position
- Below the diagonal: application.repositories uses a module listed above it, which is the healthy direction.
14→22 application.repositories uses domain.entities part of a loop✕
- Connections
- 1 pair of types, where a type in application.repositories uses a type in domain.entities.
- The types involved
application.repositories.ToDoItemCommandRepository→domain.entities.ToDoItem
- Direction
- application.repositories uses domain.entities, so a change to domain.entities can break application.repositories, while a change to application.repositories can't break domain.entities.
- Position
- Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
15→4 infrastructure.config uses application.settings✕
- Connections
- 1 pair of types, where a type in infrastructure.config uses a type in application.settings.
- The types involved
infrastructure.config.config$module→application.settings.Settings
- Direction
- infrastructure.config uses application.settings, so a change to application.settings can break infrastructure.config, while a change to infrastructure.config can't break application.settings.
- Position
- Below the diagonal: infrastructure.config uses a module listed above it, which is the healthy direction.
16→1 presentation.requests uses application.commands✕
- Connections
- 2 pairs of types, where a type in presentation.requests uses a type in application.commands.
- The types involved
presentation.requests.CreateToDoItemRequest→application.commands.CreateToDoItemCommandpresentation.requests.UpdateToDoItemRequest→application.commands.UpdateToDoItemCommand
- Direction
- presentation.requests uses application.commands, so a change to application.commands can break presentation.requests, while a change to presentation.requests can't break application.commands.
- Position
- Below the diagonal: presentation.requests uses a module listed above it, which is the healthy direction.
17→4 starter uses application.settings✕
- Connections
- 1 pair of types, where a type in starter uses a type in application.settings.
- The types involved
starter.starter$module→application.settings.Settings
- Direction
- starter uses application.settings, so a change to application.settings can break starter, while a change to starter can't break application.settings.
- Position
- Below the diagonal: starter uses a module listed above it, which is the healthy direction.
18→4 starter.observability uses application.settings✕
- Connections
- 2 pairs of types, where a type in starter.observability uses a type in application.settings.
- The types involved
starter.observability.ObservabilityConfig→application.settings.Settingsstarter.observability.observability$module→application.settings.Settings
- Direction
- starter.observability uses application.settings, so a change to application.settings can break starter.observability, while a change to starter.observability can't break application.settings.
- Position
- Below the diagonal: starter.observability uses a module listed above it, which is the healthy direction.
19→13 application.services uses application.handlers✕
- Connections
- 12 pairs of types, where a type in application.services uses a type in application.handlers.
- The types involved
application.services.ToDoItemService→application.handlers.CreateToDoItemCommandHandlerapplication.services.ToDoItemService→application.handlers.DeleteToDoItemCommandHandlerapplication.services.ToDoItemService→application.handlers.GetAllToDoItemsQueryHandlerapplication.services.ToDoItemService→application.handlers.GetDeletedToDoItemForAuditQueryHandlerapplication.services.ToDoItemService→application.handlers.GetToDoItemQueryHandlerapplication.services.ToDoItemService→application.handlers.UpdateToDoItemCommandHandlerapplication.services.ToDoItemServiceBoxed→application.handlers.CreateToDoItemCommandHandlerapplication.services.ToDoItemServiceBoxed→application.handlers.DeleteToDoItemCommandHandlerapplication.services.ToDoItemServiceBoxed→application.handlers.GetAllToDoItemsQueryHandlerapplication.services.ToDoItemServiceBoxed→application.handlers.GetDeletedToDoItemForAuditQueryHandlerapplication.services.ToDoItemServiceBoxed→application.handlers.GetToDoItemQueryHandlerapplication.services.ToDoItemServiceBoxed→application.handlers.UpdateToDoItemCommandHandler
- Direction
- application.services uses application.handlers, so a change to application.handlers can break application.services, while a change to application.services can't break application.handlers.
- Position
- Below the diagonal: application.services uses a module listed above it, which is the healthy direction.
20→3 infrastructure.postgres_repositories uses application.queries✕
- Connections
- 2 pairs of types, where a type in infrastructure.postgres_repositories uses a type in application.queries.
- The types involved
infrastructure.postgres_repositories.PostgresToDoItemRepository→application.queries.GetAllToDoItemsQueryinfrastructure.postgres_repositories.postgres_repositories$module→application.queries.GetAllToDoItemsQuery
- Direction
- infrastructure.postgres_repositories uses application.queries, so a change to application.queries can break infrastructure.postgres_repositories, while a change to infrastructure.postgres_repositories can't break application.queries.
- Position
- Below the diagonal: infrastructure.postgres_repositories uses a module listed above it, which is the healthy direction.
20→6 infrastructure.postgres_repositories uses infrastructure.errors✕
- Connections
- 1 pair of types, where a type in infrastructure.postgres_repositories uses a type in infrastructure.errors.
- The types involved
infrastructure.postgres_repositories.postgres_repositories$module→infrastructure.errors.Error
- Direction
- infrastructure.postgres_repositories uses infrastructure.errors, so a change to infrastructure.errors can break infrastructure.postgres_repositories, while a change to infrastructure.postgres_repositories can't break infrastructure.errors.
- Position
- Below the diagonal: infrastructure.postgres_repositories uses a module listed above it, which is the healthy direction.
20→14 infrastructure.postgres_repositories uses application.repositories✕
- Connections
- 2 pairs of types, where a type in infrastructure.postgres_repositories uses a type in application.repositories.
- The types involved
infrastructure.postgres_repositories.PostgresToDoItemRepository→application.repositories.ToDoItemCommandRepositoryinfrastructure.postgres_repositories.PostgresToDoItemRepository→application.repositories.ToDoItemQueryRepository
- Direction
- infrastructure.postgres_repositories uses application.repositories, so a change to application.repositories can break infrastructure.postgres_repositories, while a change to infrastructure.postgres_repositories can't break application.repositories.
- Position
- Below the diagonal: infrastructure.postgres_repositories uses a module listed above it, which is the healthy direction.
20→22 infrastructure.postgres_repositories uses domain.entities part of a loop✕
- Connections
- 2 pairs of types, where a type in infrastructure.postgres_repositories uses a type in domain.entities.
- The types involved
infrastructure.postgres_repositories.NewDbToDoItem→domain.entities.ToDoIteminfrastructure.postgres_repositories.PostgresToDoItemRepository→domain.entities.ToDoItem
- Direction
- infrastructure.postgres_repositories uses domain.entities, so a change to domain.entities can break infrastructure.postgres_repositories, while a change to infrastructure.postgres_repositories can't break domain.entities.
- Position
- Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
21→12 presentation.errors uses application.errors✕
- Connections
- 1 pair of types, where a type in presentation.errors uses a type in application.errors.
- The types involved
presentation.errors.HttpError→application.errors.ApplicationError
- Direction
- presentation.errors uses application.errors, so a change to application.errors can break presentation.errors, while a change to presentation.errors can't break application.errors.
- Position
- Below the diagonal: presentation.errors uses a module listed above it, which is the healthy direction.
22→5 domain.entities uses domain.entity✕
- Connections
- 1 pair of types, where a type in domain.entities uses a type in domain.entity.
- The types involved
domain.entities.ToDoItem→domain.entity.Entity
- Direction
- domain.entities uses domain.entity, so a change to domain.entity can break domain.entities, while a change to domain.entities can't break domain.entity.
- Position
- Below the diagonal: domain.entities uses a module listed above it, which is the healthy direction.
22→20 domain.entities uses infrastructure.postgres_repositories✕
- Connections
- 1 pair of types, where a type in domain.entities uses a type in infrastructure.postgres_repositories.
- The types involved
domain.entities.ToDoItem→infrastructure.postgres_repositories.DbToDoItem
- Direction
- domain.entities uses infrastructure.postgres_repositories, so a change to infrastructure.postgres_repositories can break domain.entities, while a change to domain.entities can't break infrastructure.postgres_repositories.
- Position
- Below the diagonal: domain.entities uses a module listed above it, which is the healthy direction.
23→6 presentation.config uses infrastructure.errors✕
- Connections
- 1 pair of types, where a type in presentation.config uses a type in infrastructure.errors.
- The types involved
presentation.config.config$module→infrastructure.errors.Error
- Direction
- presentation.config uses infrastructure.errors, so a change to infrastructure.errors can break presentation.config, while a change to presentation.config can't break infrastructure.errors.
- Position
- Below the diagonal: presentation.config uses a module listed above it, which is the healthy direction.
23→21 presentation.config uses presentation.errors✕
- Connections
- 1 pair of types, where a type in presentation.config uses a type in presentation.errors.
- The types involved
presentation.config.config$module→presentation.errors.HttpError
- Direction
- presentation.config uses presentation.errors, so a change to presentation.errors can break presentation.config, while a change to presentation.config can't break presentation.errors.
- Position
- Below the diagonal: presentation.config uses a module listed above it, which is the healthy direction.
24→22 application.mappers uses domain.entities✕
- Connections
- 1 pair of types, where a type in application.mappers uses a type in domain.entities.
- The types involved
application.mappers.ToDoItemMapper→domain.entities.ToDoItem
- Direction
- application.mappers uses domain.entities, so a change to domain.entities can break application.mappers, while a change to application.mappers can't break domain.entities.
- Position
- Below the diagonal: application.mappers uses a module listed above it, which is the healthy direction.
25→3 presentation.responses uses application.queries✕
- Connections
- 1 pair of types, where a type in presentation.responses uses a type in application.queries.
- The types involved
presentation.responses.ToDoItemsPageResponse→application.queries.PaginatedResult
- Direction
- presentation.responses uses application.queries, so a change to application.queries can break presentation.responses, while a change to presentation.responses can't break application.queries.
- Position
- Below the diagonal: presentation.responses uses a module listed above it, which is the healthy direction.
25→22 presentation.responses uses domain.entities✕
- Connections
- 2 pairs of types, where a type in presentation.responses uses a type in domain.entities.
- The types involved
presentation.responses.AuditToDoItemResponse→domain.entities.ToDoItempresentation.responses.ToDoItemResponse→domain.entities.ToDoItem
- Direction
- presentation.responses uses domain.entities, so a change to domain.entities can break presentation.responses, while a change to presentation.responses can't break domain.entities.
- Position
- Below the diagonal: presentation.responses uses a module listed above it, which is the healthy direction.
At a glance — Code Health
The Good
D1 · Rust
Cyclomatic Complexity
10.0
D2 · Rust
Cognitive Complexity
10.0
D3 · Rust
God Classes
10.0
D4 · Rust
Code Duplication
10.0
D17 · Rust
Explicit Debt
10.0
X1 · Repo
Async correctness
10.0
X21 · Repo
Side-effecting pattern guard
10.0
X27 · Repo
Collection changed while being enumerated
10.0
X28 · Repo
Index access outside its own emptiness guard
10.0
X29 · Repo
Per-element action decided by a fixed element
10.0
X30 · Repo
Support guard that admits what it rejects
10.0
The Ugly
At a glance — Architecture
The Good
At a glance — Maturity
The Good
At a glance — Readiness
The Good
D9 · Rust
Test Distribution
10.0
D12 · Rust
Dependency Hygiene
9.1
D13 · Rust
Secret Scanning
10.0
D14 · Rust
License Compliance
10.0
P1 · Repo
CI/CD gates
10.0
P10 · Repo
Library API & versioning
10.0
P2 · Repo
Observability
8.0
P3 · Repo
Security & performance tooling
7.0
P4 · Repo
Deployment & Rollback
8.0
P8 · Repo
Schema migrations
10.0
The Bad
The Ugly
At a glance — Security
The Good
At a glance — Domain Modelling
The Good
At a glance — Performance
Security & Compliance — OWASP Top-10 mapping
| OWASP category | Findings | Severity |
|---|---|---|
| A03:2025 — Software Supply Chain Failures | 26 | High / Critical |
| A05:2025 — Injection | 15 | High / Critical |
| A02:2025 — Security Misconfiguration | 3 | Medium |
Roadmap
First, enforce strict access controls by implementing a global authentication guard with explicit public opt-outs and named role permissions. Second, secure server transport by enabling TLS and sending Strict-Transport-Security headers to ensure HTTPS-only communication. Third, document significant design decisions in a dedicated folder to record dates, situations, and consequences. Fourth, codify disaster recovery and backup procedures in infrastructure as code, clearly defining recovery time and point objectives. Finally, update the README to accurately reflect the current project structure and file locations.
| Do this | Helps | Effort | Dimension |
|---|---|---|---|
| Protect endpoints by default-deny: a global authentication guard or middleware with explicit public opt-outs, or a guard on every route, plus named role/permission rules for what an authenticated caller may do. | +10.7 pts | Medium | Access Controls |
| Secure the server's transport: serve TLS itself (`HttpServer::bind_rustls_0_23(addr, config)` in actix-web, `axum_server::bind_rustls(addr, RustlsConfig::from_pem_file(…))`, tonic's `Server::builder().tls_config(ServerTlsConfig::new().identity(…))`, Rocket's `[default.tls]`), or run it behind a TLS-terminating proxy and check `X-Forwarded-Proto`; send `Strict-Transport-Security` once it is HTTPS-only. | +4.8 pts | Medium | Web-Security Posture |
| Resolve the 1 REDACTED finding(s) in Static Analysis (SAST) — start with REDACTED. | +1.5 pts | Low | Static Analysis (SAST) |
| Resolve the 1 REDACTED finding(s) in Static Analysis (SAST) — start with REDACTED. | +1.5 pts | Low | Static Analysis (SAST) |
| Resolve the 1 High vulnerability finding(s) in Dependency Vulnerabilities — start with REDACTED. | +1.5 pts | Low | Dependency Vulnerabilities |
| Resolve the 2 High CVE finding(s) in Dependency Vulnerabilities — start with REDACTED (2). | +1.5 pts | Low | Dependency Vulnerabilities |
| Resolve the 8 Medium vulnerability finding(s) in Dependency Vulnerabilities — start with REDACTED (8). | +1.5 pts | Low | Dependency Vulnerabilities |
| Resolve the 1 REDACTED finding(s) in Supply-chain Provenance & Signing. | +1.5 pts | Low | Supply-chain Provenance & Signing |
File quality
| File | Score | Band | Worst signal |
|---|---|---|---|
| REDACTED | 0.9 | Slop | Dependency Vulnerabilities: High CVE: REDACTED |
| REDACTED | 2.3 | Mixed | Static Analysis (SAST): High: REDACTED |
| REDACTED | 4.4 | Mixed | Static Analysis (SAST): High: REDACTED |
| REDACTED | 7.2 | Near-clean | Static Analysis (SAST): High: REDACTED |
| REDACTED | 7.2 | Near-clean | IaC & Container Security: Medium IaC: REDACTED |
| REDACTED | 7.9 | Near-clean | IaC & Container Security: Medium IaC: REDACTED |
How the grades work
Critical — 18
A definite problem that already costs you something and drags the score down: a missing authorisation check, a dependency with a known exploit, a build that does not reproduce. Failure here tends to cause failures elsewhere.
Serious — 28
Likely wrong, but not failing yet. It degrades the codebase over a longer horizon and can cause failures elsewhere — not urgent this week, not something to carry for two years either.
Minor — 33
Recorded, with no effect on how the codebase functions. Present so the survey is complete, not because it needs doing.
Could not be resolved — 20
Something this survey could not settle from the outside, and which could be critical or serious. Either a control was required and no positive evidence of it exists in the repository — a backup job that nothing shows was ever restored from proves nothing about restores — or our own analysis could not run over that part of the tree. This is not a clean result. These are excluded from the score rather than awarded a pass, so the number on the cover neither rewards nor penalises them: if you act on this survey without resolving them, you carry that risk yourself. Each one is named under Limitations.
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. 50 of 54 evaluated dimensions are computed purely by tools and static analysis (confidence 1.0); 4 documentation/naming judgement(s) are LLM-assisted and labelled advisory. Overall confidence is 0.9 — 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 — 54 dimensions across the health lenses
D1D2D3D4D5D6D9D12D13D14D15D17D19D21D22D26D28D29D30D31D34D35D36D43AX10AX3AX4AX9C2DM4DM6M1M2M3M4P1P10P2P3P4P5P6P8PF3S1X1X14X15X21X27X28X29X30X4
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, 47 of 79 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 |
| Watchdog duplication detector (in-process) | Code duplication | 1.0.0 | ✓ deterministic |
| Coverage (coverlet / dotnet-coverage) | Line & branch coverage | 10.0.400 | ✓ deterministic |
| NuGet / dotnet | Outdated, vulnerable & deprecated dependencies | 10.0.400 | ✓ deterministic |
| git / LibGit2Sharp | Churn hotspots, knowledge concentration, history | 2.43.0 · 0.31.0 | ✓ deterministic |
| gitleaks · semgrep · trivy · checkov | Secrets in history, SAST, CVEs, IaC & container, PII / GDPR | 1.86.0 · 0.69.3 · 3.2.533 | ✓ 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
- D8 Code Coverage — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. Coverage NOT READ here — but this repository measures it: a coverage step in CI (`cargo llvm-cov`) shows that coverage is collected and tracked in your own CI. The built-in collector has no runner for this ecosystem (.rs), so the analyzer could not read the number — a gap in the analyzer's language coverage, not an unmeasured repo. Not scored. To have the real number read, produce a coverage report in a standard format (lcov — `cargo install cargo-llvm-cov`, then `cargo llvm-cov --lcov --output-path lcov.info`) and commit it — a hosted scan measures a clone of the repository, so a report that exists only in a working tree, a CI runner's or your own, never reaches it; the artefact is commonly gitignored, so `git add -f` that one file (or un-ignore its path) and commit it alongside the code it measures. You can widen what we reach: optional: produce a coverage report in a standard format (lcov — `cargo install cargo-llvm-cov`, then `cargo llvm-cov --lcov --output-path lcov.info`) and commit it — a hosted scan measures a clone of the repository, so a report that exists only in a working tree, a CI runner's or your own, never reaches it; the artefact is commonly gitignored, so `git add -f` that one file (or un-ignore its path) and commit it alongside the code it measures — then the real number is read on the next scan.
- D11 Test Reliability — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. Test source is present (.rs) and this repository declares a Cargo test suite (repository root, 12 test files), but it was not re-run: the analyzer environment could not run it. Not scored — this is a gap in the analyzer's language coverage, not a finding about this repository.
- D16 Bus Factor — not measured this run — This is a true statement about the repository that carries nothing for its owner to act on, so it is reported here rather than as a defect in their code. Single-contributor repository — bus factor is not applicable (1 contributor(s) across 156 commit(s) sampled, automation and bot accounts excluded). Concentration needs a team to concentrate: with one contributor there is nobody to spread the knowledge to, so there is nothing here for the owner to act on.
- D27 Navigability — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. Navigability is taken over call sites whose callee resolved. For C# that population includes calls into referenced assemblies; for this language only calls declared inside the repository count, so the abstention threshold reads the repository's use of its standard library as a resolution failure. That is a limit of this analyzer, not a build problem in this repository.
- D44 Platform End-of-Life — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This dimension reads a project's own statement about the platform it runs on: a TargetFramework in a .NET project file, a .nvmrc or .python-version, a capped requires-python, a Rust toolchain file or Cargo.toml rust-version, a .go-version, .java-version, .ruby-version, .tool-versions or .sdkmanrc, a go.mod go directive, a Maven or Gradle Java level or toolchain, a Gemfile's ruby directive, a mix.exs elixir requirement, a rebar.config minimum_otp_vsn, a pubspec.yaml SDK constraint, a build.sbt scalaVersion, or a framework major pinned by a dependency constraint. This repository carries none of them, so nothing about its platform was established. That is a gap in this analyzer's coverage, NOT a finding that the platform is supported — a language whose runtime is declared elsewhere (Package.swift, a REDACTED) is simply not read here yet.
- AX6 Interface segregation — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check is computed over the public interfaces this run's compilations declare, and none was loaded, so it had nothing to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- AXR1 Runtime accessibility — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. Render strategy: boot via REDACTED (REDACTED). docker build failed (exit 1) — DEPRECATED: The legacy builder is deprecated and will be removed in a future release. Install the buildx component to build images with BuildKit: https://docs.docker.com/go/bui…; runtime evidence skipped.
- GD1 Unfinished & placeholder code — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check reads C# syntax, F#, JavaScript/TypeScript, Dart, Ruby and Scala source only, and no C#, F#, JavaScript/TypeScript, Dart, Ruby or Scala was found, and this repository's Rust is not read yet, so it had nothing of this repository's product to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- IC1 Incompleteness & stubs — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check reads C# syntax, JavaScript/TypeScript, Java, Dart, Ruby and Scala source only, and no C#, JavaScript/TypeScript, Java, Dart, Ruby or Scala was found, and this repository's Rust is not read yet, so it had nothing of this repository's product to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X12 Unreachable branch — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check reads C# syntax, and JavaScript/TypeScript, Python, Dart, Ruby, Scala and Kotlin source only, and no C# was loaded and no JavaScript/TypeScript, Python, Dart, Ruby, Scala or Kotlin was found in this repository, so it had nothing of this repository's product to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X13 Undrained process stream — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check reads C# syntax, and JavaScript/TypeScript, Python, Dart, Ruby, Scala and Kotlin source only, and no C# was loaded and no JavaScript/TypeScript, Python, Dart, Ruby, Scala or Kotlin was found in this repository, so it had nothing of this repository's product to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X16 Unfloored truncation loop — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check reads C# syntax, and JavaScript/TypeScript, Java, PHP, Dart, Ruby, Scala and Kotlin source only, and no C# was loaded and no JavaScript/TypeScript, Java, PHP, Dart, Ruby, Scala or Kotlin was found in this repository, so it had nothing of this repository's product to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X17 Uncapped recursion over a caller-supplied document — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check reads C# syntax, and JavaScript/TypeScript, Python, Dart, Ruby, Scala and Kotlin source only, and no C# was loaded and no JavaScript/TypeScript, Python, Dart, Ruby, Scala or Kotlin was found in this repository, so it had nothing of this repository's product to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X18 Disposal-pattern correctness — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check reads C# syntax, and JavaScript/TypeScript, Java, Kotlin, Dart, Ruby, Scala and PHP source only, and no C# was loaded and no JavaScript/TypeScript, Java, Kotlin, Dart, Ruby, Scala or PHP was found in this repository, so it had nothing of this repository's product to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X19 Unrestored process-global state — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check reads C# syntax, and JavaScript/TypeScript, Java, Kotlin, Python, Dart, Ruby, Scala and PHP source only, and no C# was loaded and no JavaScript/TypeScript, Java, Kotlin, Python, Dart, Ruby, Scala or PHP was found in this repository, so it had nothing of this repository's product to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X22 Contradicted release guard — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check reads C# syntax, and Java, TypeScript/JavaScript, Python, Dart, Ruby, Scala, Kotlin and PHP source only, and no C# was loaded, and this repository's Rust is not read yet, so it had nothing of this repository's product to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X23 Unguarded diagnostic materialisation — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check reads C# syntax, and JavaScript/TypeScript, Java, F#, Python, Dart, Ruby, Scala, Kotlin and PHP source only, and no C# was loaded and no JavaScript/TypeScript, Java, F#, Python, Dart, Ruby, Scala, Kotlin or PHP was found in this repository, so it had nothing of this repository's product to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X24 Document value interpolated into markup unescaped — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check reads C# syntax, and JavaScript/TypeScript, Java, Scala, Ruby and Python source only, and no C# was loaded and no JavaScript/TypeScript, Java, Scala, Ruby or Python was found in this repository, so it had nothing of this repository's product to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X25 Inert configuration knob — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check reads C# syntax, and JavaScript/TypeScript, Java, Kotlin, Scala, PHP, Erlang, Python, Dart and Ruby source only, and no C# was loaded and no JavaScript/TypeScript, Java, Kotlin, Scala, PHP, Erlang, Python, Dart or Ruby was found in this repository, so it had nothing of this repository's product to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X3 Exception handling — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check reads C# syntax, and PHP, Java, Kotlin, Python, Ruby, Scala, Dart, Swift, Erlang, Go and JavaScript/TypeScript source only, and no C# was loaded and no PHP, Java, Kotlin, Python, Ruby, Scala, Dart, Swift, Erlang, Go, JavaScript or TypeScript was found in this repository, so it had nothing of this repository's product to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X5 Nullable reference types — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check reads C# syntax and MSBuild project configuration, TypeScript source and its tsconfig files, Java source and its package and module declarations, PHP source and its PHPStan and Psalm configuration, Dart source and its pubspec language version, Ruby source and its Sorbet and Steep configuration, Scala source and its build's explicit-nulls, WartRemover and Scalafix settings, and Kotlin source only, and no C# was loaded, no TypeScript was found, and this repository's Rust is not read yet, so it had nothing of this repository's product to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
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 — an in-process token-stream comparison over sliding windows, with type-aware normalization — so 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").
- D14 License Compliance: License compatibility is checked against declared package metadata and a policy — mislabelled or missing license metadata, and obligations that depend on how you distribute, are not resolved here.
- 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.
- 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. Its critique rows are drawn from a closed category vocabulary and each row means the same thing in every run, so two scans can be compared row by row; the SET that fires is still a sample, and does not repeat exactly. Measured on one frozen input, six scans at one engine SHA: 2-5 critique rows per scan, 8 distinct rows across the six, 3 of those 8 seen in only one scan. So a D19 row is evidence about the documentation, but a COUNT of D19 rows is not a quantity — never read a change in it as an improvement or a regression.
- 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.
- D22 Internal API Consistency: API-surface coherence is an LLM judgement over a sample of the public surface — consistency of intent across the whole API is approximated, not exhaustively verified.
- 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").
- D30 Dependency Vulnerabilities: CVE matching depends on accurate package/version metadata and on the advisory databases — a vulnerability with no published advisory, or in code not declared as a dependency, is not seen. Coverage needs a RESOLVED graph: an unpinned requirements.txt, or a pom without a resolved build, yields partial coverage rather than a clean verdict. An ecosystem the analyzer cannot scan is reported as unmeasured, never as clean.
- D31 IaC & Container Security: IaC scanning checks Dockerfiles/Terraform/Kubernetes against best-practice rules — it cannot see the live cloud account, runtime configuration, or drift between the committed config and what is actually deployed.
- 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.
- D43 Malicious Dependencies: Only packages some vulnerability database has already NAMED as malicious are seen — a compromise published in the last hours, or never reported at all, is invisible here, and this dimension reading 10 is not evidence that a dependency is trustworthy. There is no typosquat or dependency-confusion analysis: a package nobody has reported is simply absent from the feeds. Coverage is the dependency scan's: an ecosystem that could not be scanned is disclosed as unmeasured, never as clean.
- 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.
- AX9 CQS / query purity: Handlers are found by interface/name convention — a query handler using neither is not seen. Mutation is a resolved write/publish invocation (SaveChanges/repository/bus), so a write hidden behind a hand-rolled wrapper, reflection, or a string-keyed service locator resolves to a non-persistence type and isn't flagged; it detects that a query writes state, not whether the write is a legitimate read-side cache update. Clean means "no resolved write/publish in a query body", not a proof of CQS purity.
- DM4 Rich vs anemic domain model: Behaviour is detected as state mutation inside a method body — a method that enforces an invariant by validating-and-throwing without mutating reads as a query, and mutation delegated through an interface the scan can't resolve isn't credited; entities with zero public properties still drop out of the population. It detects that state changes, not whether the rule is correct.
- DM6 Domain ↔ infrastructure boundary: Infrastructure reached through a hand-rolled wrapper, a domain-named facade, reflection, or a string-keyed service locator resolves to a non-infra type and isn't seen; the body scan is symbol resolution over syntax, not full dataflow. A clean result means "no resolved infra reference in a domain body", not a proof of purity.
- 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".
- P5 DR & Backup: Backup/restore and disaster-recovery readiness is judged from in-repo evidence — a config that exists is not a tested restore, so the absence of positive evidence is reported as "not evidenced", never scored as present.
- 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
0 function(s) exceeded the cyclomatic complexity threshold of 15.
Do you agree with this assessment?
D2 · Cognitive Complexity
0 function(s) exceeded the cognitive complexity threshold of 15.
Do you agree with this assessment?
D3 · God Classes
0 over-large unit(s) detected — types, modules or files that carry too much.
Do you agree with this assessment?
D4 · Code Duplication
0 duplicated block group(s) detected.
Do you agree with this assessment?
D5 · Coupling
5 production modules (Cargo), 0 dependency cycle(s), 0 unstable depended-on module(s). Read from the build's own module declarations; 0 module(s) off the main sequence.
Do you agree with this assessment?
D6 · Cohesion (LCOM4)
0 of 4 classes have LCOM4 above 3.
Do you agree with this assessment?
D9 · Test Distribution
83 test methods: 42 unit, 41 integration, 0 BDD, 0 e2e. The Rust suite contributes 83 `#[test]` function(s) across 12 file(s) declaring at least one; its unit/integration split is Cargo's own — 2 of those file(s) are integration-test targets under a crate's tests/ directory, and the rest are #[test] functions compiled into the crate they test.
Do you agree with this assessment?
D12 · Dependency Hygiene
18 outdated, 0 yanked direct Cargo dependencies. Only DIRECT edges are graded: a transitive crate cannot be moved past what its parent's requirement admits, so reporting one would be advice its owner cannot take. A newer release is reported only where this repository's OWN requirement already admits it, so the remedy is `cargo update` and never a manifest edit — which means a release outside the declared range is deliberately NOT charged, because a written-down constraint is a decision rather than a defect. Note that a bare requirement is a CARET, and for a 0.x crate its ceiling is the minor. Whether any crate is UNMAINTAINED is not graded — crates.io publishes no maintenance status, and release age does not stand in for one. Known CVEs in this dependency graph are D30's question, read from REDACTED there.
Outdated: actix-web
Do you agree with this assessment?
D13 · Secret Scanning
Secret scan ran and found no leaked secrets.
Do you agree with this assessment?
D14 · License Compliance
0 of 492 shipped crate(s) use a banned license. Licences were resolved from crates.io over the crates a consumer compiles — this repository's REDACTED closed over its manifests' `[dependencies]` and `[build-dependencies]`. Crates it asks for ONLY under `[dev-dependencies]` are excluded: they are not compiled by anything that depends on this repository.
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
0 deducted task-comment markers across 2865 LoC (0.0/KLoC) → score 10.0. Task comments only: this repository's language is read without a compiler, so D17's suppression, dead-code and commented-out-code arms did not run and this score counts fewer marker kinds than a .NET repository's would.
Do you agree with this assessment?
D19 · Documentation Quality
The repository's root README is clear and complete for a project that is itself the single document: it states what the project does (a Rust microservice template based on Domain Driven Design), gives credit where due, lists release, license, and workflow badges, and documents a table of contents covering Installation, Spec-Driven Workflow, Architecture, Implementation Details, API Validation, Configuration, Coverage, Deployment, Plan, Technologies - Libraries, and the Usage sections. The README is also well structured with an overview paragraph, prerequisites, installation steps, and shell commands in fenced blocks.
What to do
- Improve Documentation Quality — currently 8.0/10. — The repository's root README is clear and complete for a project that is itself the single document: it states what the project does (a Rust microservice template based on Domain Driven Design), gives credit where due, lists release, license, and workflow badges, and documents a table of contents covering Installation, Spec-Driven Workflow, Architecture, Implementation Details, API Validation, Configuration, Coverage, Deployment, Plan, Technologies - Libraries, and the Usage sections. The README is also well structured with an overview paragraph, prerequisites, installation steps, and shell commands in fenced blocks.
Do you agree with this assessment?
D21 · Naming Consistency
0 naming inconsistencies across 0 sampled symbols.
Do you agree with this assessment?
D22 · Internal API Consistency
4 API inconsistencies across 29 exposed types.
Naming inconsistency between service implementations. One uses 'get_' prefix while the other uses 'create_' prefix for the same logical operation of providing a handler instance.
Type mismatch between property declaration and constructor argument. The property is declared as DateTime, but the constructor accepts String.
Incorrect type assignment for domain properties. 'title' and 'note' are semantically text fields but are typed as DateTime.
Inconsistent parameter naming for the 'deleted_by' identifier. The command uses 'deleted_by' (implying a user/actor ID), but the repository method signature also uses 'deleted_by'. While consistent with each other, the command property is 'deleted_by: DateTime' in the property list but 'deleted_by: Uuid' in the constructor. This is a contradiction within the Command type itself.
What to do
- Resolve the 1 Naming inconsistency between service implementations. One uses 'get_'… finding(s) in Internal API Consistency. — One of this dimension's main actionable groups (1 warning-level).
- Resolve the 1 Type mismatch between property declaration and constructor argument. The… finding(s) in Internal API Consistency. — One of this dimension's main actionable groups (1 warning-level).
- Resolve the 1 Incorrect type assignment for domain properties. 'title' and 'note' are… finding(s) in Internal API Consistency. — One of this dimension's main actionable groups (1 warning-level).
Do you agree with this assessment?
D26 · Project Cohesion
0 of 5 build units (Cargo) 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)
15 finding(s): 0 critical, 15 high, 0 medium, 0 low. 13 unpinned-GitHub-Actions row(s) are reported here but scored by D36 (supply-chain provenance), which measures that posture as `pinned_actions` — one pinning decision is charged once, not once per lens.
REDACTED
REDACTED
REDACTED
What to do
- Resolve the 1 REDACTED finding(s) in Static Analysis (SAST) — start with REDACTED. — One of this dimension's main actionable groups (1 issue-level).
- Resolve the 1 REDACTED finding(s) in Static Analysis (SAST) — start with REDACTED. — One of this dimension's main actionable groups (1 issue-level).
- No action in Static Analysis (SAST) — all 13 REDACTED finding(s) are reported here at file:line but scored by D36 (supply-chain provenance), so none is charged to this dimension. — One of this dimension's main actionable groups (13 issue-level, 0 of them charged here).
Do you agree with this assessment?
D30 · Dependency Vulnerabilities
21 finding(s): 0 critical, 3 high, 18 medium, 0 low.
REDACTED
REDACTED
REDACTED
REDACTED
REDACTED
What to do
- Resolve the 2 High CVE finding(s) in Dependency Vulnerabilities — start with REDACTED (2). — One of this dimension's main actionable groups (2 issue-level).
- Resolve the 1 High vulnerability finding(s) in Dependency Vulnerabilities — start with REDACTED. — One of this dimension's main actionable groups (1 issue-level).
- Resolve the 8 Medium vulnerability finding(s) in Dependency Vulnerabilities — start with REDACTED (8). — One of this dimension's main actionable groups (8 warning-level).
Do you agree with this assessment?
D31 · IaC & Container Security
3 finding(s): 0 critical, 0 high, 2 medium, 1 low.
REDACTED
REDACTED
What to do
- Resolve the 2 Medium IaC finding(s) in IaC & Container Security — start with REDACTED, REDACTED. — One of this dimension's main actionable groups (2 warning-level).
- Resolve the 1 Low IaC finding(s) in IaC & Container Security — start with REDACTED. — One of this dimension's main actionable groups (1 recommendation-level).
Do you agree with this assessment?
D34 · Knowledge Freshness
1 of 13 significant source file(s) are orphaned — their living knowledge has decayed to nothing, so no one currently understands them. The largest is src/starter/src/observability.rs. Counted over 13 of the 31 production source files in this repository: the rest are under the ~2,400-byte size floor this dimension measures over.
Orphaned files with no living knowledge
Orphaned filesrc/starter/src/observability.rs:1
Do you agree with this assessment?
D35 · Change Coupling
No strong hidden change-coupling between production files.
Do you agree with this assessment?
D36 · Supply-chain Provenance & Signing
0/4 supply-chain integrity signals present (provenance, signing, SBOM, pinned actions).
REDACTED
REDACTED
REDACTED
REDACTED
REDACTED
What to do
- Resolve the 1 REDACTED finding(s) in Supply-chain Provenance & Signing. — One of this dimension's main actionable groups (1 warning-level).
- Resolve the 1 REDACTED finding(s) in Supply-chain Provenance & Signing — start with REDACTED. — One of this dimension's main actionable groups (1 warning-level).
- Resolve the 1 REDACTED finding(s) in Supply-chain Provenance & Signing. — One of this dimension's main actionable groups (1 recommendation-level).
Do you agree with this assessment?
D43 · Malicious Dependencies
No dependency in any ecosystem this repository declares is published as malicious.
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?
AX9 · CQS / query purity
Do you agree with this assessment?
C2 · Access Controls
- This repository serves requests — a server (HttpServer::new) (src/starter/src/lib.rs:47) — and no route guard, auth-gate middleware, global guard or imperative check that refuses a caller (401/403, an Unauthorized/Forbidden error) was found: its endpoints may be unprotected. — src/starter/src/lib.rs:47
What to do
- Protect endpoints by default-deny: a global authentication guard or middleware with explicit public opt-outs, or a guard on every route, plus named role/permission rules for what an authenticated caller may do.
Do you agree with this assessment?
DM4 · Rich vs anemic domain model
Do you agree with this assessment?
DM6 · Domain ↔ infrastructure boundary
Do you agree with this assessment?
M1 · Documentation (README)
What to do
- Explain in the README how to run the tests. Add a section called Testing to the README in the repository's top folder, saying how to run the test suite.
- Add a README to the 5 of 5 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 numbered `NNNN-title` documents in any markup this check reads, 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 your significant design decisions. Write one short document per decision, giving its date, the situation, the decision and its consequences, and keep them together with your other design documents. A docs/adr folder with each file named by number and title is the easiest place to find them.
Do you agree with this assessment?
M3 · Folder & project structure
Do you agree with this assessment?
M4 · Documentation accuracy
- README.md changes into `rust-microservice-template/deployment/docker`, but no such folder exists. Checked without a model against the repository: its files and folders, the scripts and dependencies of every package.json, the projects, namespaces, package references and target frameworks of the .NET build, the SDK and Node pins, and the identifiers of every file that is not a document; the documents' own text never counts. A footprint generated at build time, read only by a platform, or living outside this repository is not seen, and this row is then wrong. — README.md:43
- README.md names `plan.md`, but no file or folder `plan.md` exists. Checked without a model against the repository: its files and folders, the scripts and dependencies of every package.json, the projects, namespaces, package references and target frameworks of the .NET build, the SDK and Node pins, and the identifiers of every file that is not a document; the documents' own text never counts. A footprint generated at build time, read only by a platform, or living outside this repository is not seen, and this row is then wrong. — README.md:85
- README.md names `tasks.md`, but no file or folder `tasks.md` exists. Checked without a model against the repository: its files and folders, the scripts and dependencies of every package.json, the projects, namespaces, package references and target frameworks of the .NET build, the SDK and Node pins, and the identifiers of every file that is not a document; the documents' own text never counts. A footprint generated at build time, read only by a platform, or living outside this repository is not seen, and this row is then wrong. — README.md:86
What to do
- Reconcile the README with reality: README.md changes into `rust-microservice-template/deployment/docker`, but no such folder exists; README.md names `plan.md`, but no file or folder `plan.md` exists; README.md names `tasks.md`, but no file or folder `tasks.md` exists.
Do you agree with this assessment?
P1 · CI/CD gates
Do you agree with this assessment?
P10 · Library API & versioning
Do you agree with this assessment?
P2 · Observability
What to do
- Add OpenTelemetry tracing/metrics (opentelemetry with tracing-opentelemetry) so requests are traceable across the system, not just health-probable.
Do you agree with this assessment?
P3 · Security & performance tooling
What to do
- Add gitleaks/trufflehog in CI to block PRs that introduce committed secrets.
Do you agree with this assessment?
P4 · Deployment & Rollback
What to do
- Add an approval/environment gate (required reviewers / protection rules) before production promotion.
Do you agree with this assessment?
P5 · DR & Backup
- A persistence guard (data volume / purge-protection) was found, but no backup, geo-recovery or RTO/RPO controls were evidenced — a volume that survives a container recreate is not a tested restore from catastrophic loss.
What to do
- Codify backups + geo-recovery in IaC and document RTO/RPO and the restore procedure — a persistence guard alone is not disaster recovery.
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?
P8 · Schema migrations
Do you agree with this assessment?
PF3 · Async & latency hygiene
Do you agree with this assessment?
S1 · Web-Security Posture
- This repository starts an HTTP server and nothing in its Rust source or committed `Rocket.toml` secures the transport: no TLS served (actix-web `bind_rustls`/`bind_openssl`, axum-server `bind_rustls` with a `RustlsConfig`, tonic `ServerTlsConfig`, a `TlsAcceptor`, Rocket's `[default.tls]`), no `Strict-Transport-Security` header, no `X-Forwarded-Proto` read from a TLS-terminating proxy — so its traffic may cross the network in clear text. (−2.0 on this card.) The server: `HttpServer::new(` (src/starter/src/lib.rs:47).
- None of the 11 security response headers the OWASP Secure Headers Project recommends (Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options, …) is set on a response this repository's Rust server sends — defense in depth, even when a proxy could set them. (−2.0 on this card.) The server: `HttpServer::new(` (src/starter/src/lib.rs:47).
What to do
- Secure the server's transport: serve TLS itself (`HttpServer::bind_rustls_0_23(addr, config)` in actix-web, `axum_server::bind_rustls(addr, RustlsConfig::from_pem_file(…))`, tonic's `Server::builder().tls_config(ServerTlsConfig::new().identity(…))`, Rocket's `[default.tls]`), or run it behind a TLS-terminating proxy and check `X-Forwarded-Proto`; send `Strict-Transport-Security` once it is HTTPS-only.
- Set security response headers on what the server sends — actix-web's `DefaultHeaders::new().add((header::X_CONTENT_TYPE_OPTIONS, "nosniff"))`, tower-http's `SetResponseHeaderLayer::overriding(…)` on an axum router, or keep Rocket's default `Shield` — with `Content-Security-Policy`, `X-Content-Type-Options` and a frame policy on every response.
Do you agree with this assessment?
X1 · Async correctness
Do you agree with this assessment?
X14 · Bypassable address classification
Do you agree with this assessment?
X15 · Unvalidated length from an untrusted reader
Do you agree with this assessment?
X21 · Side-effecting pattern guard
Do you agree with this assessment?
X27 · Collection changed while being enumerated
Do you agree with this assessment?
X28 · Index access outside its own emptiness guard
Do you agree with this assessment?
X29 · Per-element action decided by a fixed element
Do you agree with this assessment?
X30 · Support guard that admits what it rejects
Do you agree with this assessment?
X4 · Structured logging
- `info!` at line 31 is handed a format string with `{…}` values in it, so tracing records one finished `message` field — the values in it cannot be queried, filtered or aggregated as fields, and every occurrence reads as a different message. Record the values as fields beside a constant message instead: `info!(order_id = %order_id, status = ?status, "order status updated")` (`%` records a value by its `Display`, `?` by its `Debug`, a bare name as itself), which a JSON subscriber, OpenTelemetry or a log store keeps as queryable keys. An error goes in as a field too: `error = %err`. — src/starter/src/lib.rs:31
- `debug!` at line 32 is handed a format string with `{…}` values in it, so tracing records one finished `message` field — the values in it cannot be queried, filtered or aggregated as fields, and every occurrence reads as a different message. Record the values as fields beside a constant message instead: `debug!(order_id = %order_id, status = ?status, "order status updated")` (`%` records a value by its `Display`, `?` by its `Debug`, a bare name as itself), which a JSON subscriber, OpenTelemetry or a log store keeps as queryable keys. An error goes in as a field too: `error = %err`. — src/starter/src/lib.rs:32
What to do
- Interpolated log message defeats structured logging
Do you agree with this assessment?
Reference — by lens
| Lens | Score | Rating | Impact |
|---|---|---|---|
| Code Health | 73% | Adequate — gated by X4 | Capped at Fair by a Critical contributor — resolve it before relying on this lens. |
| Architecture | 89% | Exemplary | Solid. |
| Maturity | 53% | Adequate — gated by M2 | Capped at Fair by a Critical contributor — resolve it before relying on this lens. |
| Readiness | 55% | Adequate — gated by P5 | Capped at Fair by a Critical contributor — resolve it before relying on this lens. |
| Security | 36% | Weak — gated by D36, C2 | Capped at Fair by a Critical contributor — resolve it before relying on this lens. |
| Domain Modelling | 100% | Exemplary | Strongest area. |
| Performance | 100% | Exemplary | Solid. |
Not included — 72 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 — Not applicable: Rust with no dependency-injection crate has no container to hand one lifetime's instance to another — every value is owned by the code that builds it, and the borrow checker rejects a longer-lived value keeping a borrow of a shorter-lived one.
- AX2 Stateful singletons — Not applicable: Rust's compiler refuses unsynchronised shared mutation — a value shared across threads must be Sync — so the race this check looks for cannot be written.
- AX5 Architecture & structure — not assessed — architecture style/structure is computed from a project graph (projects, types, module namespaces) that was not loaded for this repository, because the repository is written in a language this check does not yet model, or because its projects failed to load. This is a gap in the analyzer, not a finding about this repository
- AX6 Interface segregation — not assessed — interface segregation is computed over a type surface that was not loaded for this repository, because the repository is written in a language this check does not yet model, or because its projects failed to load. This is a gap in the analyzer, not a finding about this repository
- AX7 Slice cohesion — not applicable — not a vertical-slice architecture
- AX8 Test isolation — no test/production split to check
- AXB2 Runtime readiness — Advisory — this card reports evidence and never carries a score, so there is nothing missing here.
- AXR1 Runtime accessibility — docker build failed (exit 1) — DEPRECATED: The legacy builder is deprecated and will be removed in a future release. Install the buildx component to build images with BuildKit: https://docs.docker.com/go/bui…; runtime evidence skipped This is a statement about this run, not a statement about your application: nothing here says the surface is inaccessible, only that it was never rendered.
- C1 Data Protection — No personal data detected in a persisted data model — no PII-named field (email, first_name, date_of_birth, phone, …) or stored credential in a Diesel schema, a SeaORM entity, a Diesel or sqlx row struct, or a SQL CREATE TABLE or ALTER TABLE — and no database or data-store crate (sqlx, Diesel, SeaORM, rusqlite, tokio-postgres, MongoDB, …) in the source either, so this repository keeps no data at rest for these controls to protect.
- C3 Audit Trail — No personal data detected in a persisted data model — no PII-named field (email, first_name, date_of_birth, phone, …) or stored credential in a Diesel schema, a SeaORM entity, a Diesel or sqlx row struct, or a SQL CREATE TABLE or ALTER TABLE — and no database or data-store crate (sqlx, Diesel, SeaORM, rusqlite, tokio-postgres, MongoDB, …) in the source either, so this repository keeps no sensitive data whose changes an audit trail would record. If it does (through a store configured outside this repository, for instance), the trail belongs to wherever that data is stored.
- C4 Data Retention — No personal data detected in a persisted data model — no PII-named field (email, first_name, date_of_birth, phone, …) or stored credential in a Diesel schema, a SeaORM entity, a Diesel or sqlx row struct, or a SQL CREATE TABLE or ALTER TABLE — and no database or data-store crate (sqlx, Diesel, SeaORM, rusqlite, tokio-postgres, MongoDB, …) in the source either, so this repository keeps no personal data whose lifetime a retention limit would bound.
- C5 Data-Subject Rights — No personal data detected in a persisted data model — no PII-named field (email, first_name, date_of_birth, phone, …) or stored credential in a Diesel schema, a SeaORM entity, a Diesel or sqlx row struct, or a SQL CREATE TABLE or ALTER TABLE — and no database or data-store crate (sqlx, Diesel, SeaORM, rusqlite, tokio-postgres, MongoDB, …) in the source either, so this repository keeps no personal data for a data subject to erase, export or consent over.
- D10 Test Quality — ~1402 lines of test source are present (.rs) but no test cases reached the test census for this repository — no test root we could resolve declared them, or the files we read declare no cases in a test framework we recognise — so skipped/assertion-free tests couldn't be counted. Not scored — this is a gap in the analyzer, not a finding about this repository.
- D11 Test Reliability — Test reliability not included — the .rs suite was found but not re-run
- D16 Bus Factor — single-contributor repository — bus factor is not applicable
- D18 Solution Shape — D18 scores the shape of a .NET solution; this repository has no .NET solution or project files, so the dimension does not apply.
- D20 ADR Quality — N/A — this repo declares itself a template / kata / sample / demo; a formal ADR log is deferred to a real application built from it.
- D23 Boundary Type-Coupling — No bounded-context organisation was detected either — neither a context-shaped layout, nor 2+ sibling source directories each declaring an aggregate root, nor 2+ projects each declaring an entity of their own. Declaring this codebase's bounded contexts (≥2) would let cross-boundary type coupling be assessed. Declare them in `.codehealth/config.yaml` at the repository root (create it if absent), mapping each context name to the module-path or namespace prefixes that belong to it — e.g. `architecture:` → `contexts:` → `Billing: ["src/billing", "Acme.Billing"]`, `Catalog: ["src/catalog", "Acme.Catalog"]`.
- D24 Comment Value — No inline comments to assess — comment value is not applicable here.
- D25 ADR Conformance — no ADRs to check
- D27 Navigability — D27 counts a call into the standard library or a dependency as unresolved for this repository's language (.rs), so too few call sites counted as resolved to assess navigability. Not scored: this is a gap in the analyzer, not a verdict about this repository.
- D32 Data Compliance (PII/GDPR) — No personal data was found crossing a boundary the PII/GDPR ruleset checks — nothing written to a log or console sink, placed in a URL or query string, or persisted to browser storage. That is a clean result for the LEAK surface only: this ruleset detects personal data escaping, it does not inventory the personal data a repository holds, so it is not evidence that this repository has no personal-data surface. The personal-data map (Appendix C) and the C1-C5 compliance cards are what speak to that.
- 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.
- D39 IL Efficiency — D39 measures the IL emitted by a .NET build; this repository has no .NET solution or project files, so the dimension does not apply.
- 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.
- D44 Platform End-of-Life — Platform end-of-life not assessed — this repository declares no platform this pass reads
- D7 Architectural Integrity — no checkable ADRs, and no project-reference graph for the cycle pass to read — so this dimension makes no claim about dependency cycles in either direction (where this repository's language has an import-cycle lens, cycles are reported there). Architectural integrity not assessed
- D8 Code Coverage — Coverage not included — suite not readable by the collector
- DM1 Aggregate boundaries — this Rust crate declares no domain aggregate (a struct with private state and its own command methods), so DM1's aggregate-boundary read has no population to be taken over
- DM2 Strongly-typed ids — no in-repo typed-id idiom — primitive-obsession recorded as advisory DM8, DM2 not gated
- DM3 Integration-event coupling — no integration events detected — coupling check not applicable
- DM5 Encapsulated state — this Rust crate declares no type implementing a hand-rolled Hash/PartialEq, so DM5's value-identity encapsulation read has no population to be taken over
- DM7 Repository granularity — no repository abstraction detected (e.g. uses a document session)
- ED2 Event/command shape — not scored — deciding whether a command has more than one competing handler requires resolving the call graph, and a call made through an inferred or generic receiver has no resolvable owner in the source. Reported as guidance rather than measured
- 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 lens looks for
- GD1 Unfinished & placeholder code — no source files were read — this check reads C#, F#, JavaScript/TypeScript, Dart, Ruby and Scala, and none was read for this repository's product. That is a limit of the analyzer, not a finding about your code.
- IC1 Incompleteness & stubs — not analysed — these correctness checks read a source model that was not loaded for this repository, because the repository is written in a language this check does not yet model, or because its projects failed to load. This is a gap in the analyzer, not a finding about this repository
- P12 CI test-gate honesty — Reported, not scored — this card publishes what the CI gate does with the test inventory rather than grading it. The findings above are its output.
- P7 Outbound HTTP resilience — no outbound HTTP usage detected — no HTTP client call or construction in the Rust source (service entry point: src/starter/src/main.rs:6 (#[actix_web::main]))
- P9 Domain vs controller coverage — no coverage report found on disk — produce a coverage report in a standard format (lcov — `cargo install cargo-llvm-cov`, then `cargo llvm-cov --lcov --output-path lcov.info`) and commit it — a hosted scan measures a clone of the repository, so a report that exists only in a working tree, a CI runner's or your own, never reaches it; the artefact is commonly gitignored, so `git add -f` that one file (or un-ignore its path) and commit it alongside the code it measures, or wire coverage collection into CI, to enable this cross-layer check
- PF1 Benchmark discipline — Not applicable: no benchmark suite was found. This check searched for `#[bench]`, criterion's `bench_function`/`bench_with_input`, `#[divan::bench]` or `#[library_benchmark]` in any `.rs` file, or criterion, divan, iai or a `[[bench]]` target in a Cargo.toml, and for a `*benchmark*` script that this repository's CI runs. Benchmarks are credited as a bonus, so their absence is neither scored nor deducted.
- PF2 Allocation hygiene — Not applicable: Rust spells out every heap allocation and makes borrowed slices (&[T], &str) its ordinary parameter types, so the allocation-aware style this card rewards elsewhere is the language's baseline rather than a rung to climb.
- X10 Duplicated predicate — Advisory — this card reports evidence and never carries a score, so there is nothing missing here.
- X12 Unreachable branch — not analysed — these correctness checks read a source model that was not loaded for this repository, because the repository is written in a language this check does not yet model, or because its projects failed to load. This is a gap in the analyzer, not a finding about this repository
- X13 Undrained process stream — not analysed — these correctness checks read a source model that was not loaded for this repository, because the repository is written in a language this check does not yet model, or because its projects failed to load. This is a gap in the analyzer, not a finding about this repository
- X16 Unfloored truncation loop — not analysed — these correctness checks read a source model that was not loaded for this repository, because the repository is written in a language this check does not yet model, or because its projects failed to load. This is a gap in the analyzer, not a finding about this repository
- X17 Uncapped recursion over a caller-supplied document — not analysed — these correctness checks read a source model that was not loaded for this repository, because the repository is written in a language this check does not yet model, or because its projects failed to load. This is a gap in the analyzer, not a finding about this repository
- X18 Disposal-pattern correctness — not analysed — these correctness checks read a source model that was not loaded for this repository, because the repository is written in a language this check does not yet model, or because its projects failed to load. This is a gap in the analyzer, not a finding about this repository
- X19 Unrestored process-global state — not analysed — these correctness checks read a source model that was not loaded for this repository, because the repository is written in a language this check does not yet model, or because its projects failed to load. This is a gap in the analyzer, not a finding about this repository
- X2 Cancellation propagation — no C# was loaded; this repository's Rust was read, and no request in it can be cancelled by a caller — a Rust request takes no token: a future is cancelled by dropping it, from outside the call (select!, a timeout, an aborted task), and reqwest, hyper and tonic take none
- X20 Mistyped argument guard — This check asks whether an argument guard reports an EMPTY value as a NULL one, which needs a language that throws a null-specific argument exception — .NET's ArgumentNullException, the JVM's NullPointerException, Dart's ArgumentError.notNull. This repository contains none of those languages: the ones it is written in have a single exception for a bad argument, so there is no pair of exceptions to confuse and nothing here for it to assess. Not a gap in the analyzer and not a finding about your code.
- X22 Contradicted release guard — not analysed — these correctness checks read a source model that was not loaded for this repository, because the repository is written in a language this check does not yet model, or because its projects failed to load. This is a gap in the analyzer, not a finding about this repository
- X23 Unguarded diagnostic materialisation — not analysed — these correctness checks read a source model that was not loaded for this repository, because the repository is written in a language this check does not yet model, or because its projects failed to load. This is a gap in the analyzer, not a finding about this repository
- X24 Document value interpolated into markup unescaped — not analysed — these correctness checks read a source model that was not loaded for this repository, because the repository is written in a language this check does not yet model, or because its projects failed to load. This is a gap in the analyzer, not a finding about this repository
- X25 Inert configuration knob — not analysed — these correctness checks read a source model that was not loaded for this repository, because the repository is written in a language this check does not yet model, or because its projects failed to load. This is a gap in the analyzer, not a finding about this repository
- X26 Unsynchronised callback handoff — Not applicable: this check looks for a collection written by a callback on one thread while the body waiting on it touches it on another, and in this repository's languages no collection is reachable from two threads at once. Rust's compiler refuses the unsynchronised version: a collection shared between a callback's thread and the waiting body must be `Sync`, which a `Vec`, `VecDeque` or `HashMap` is only behind a `Mutex`/`RwLock`, so the race this check looks for cannot be written in safe Rust. Not a gap in the analyzer and not a finding about your code.
- X3 Exception handling — not analysed — these correctness checks read a source model that was not loaded for this repository, because the repository is written in a language this check does not yet model, or because its projects failed to load. This is a gap in the analyzer, not a finding about this repository
- X32 Type resolved by simple name across every loaded assembly — This check is about how a .NET program searches the assemblies loaded into its process for a type, and this repository contains no .NET source, so there is nothing here for it to assess. Not a gap in the analyzer and not a finding about your code.
- X5 Nullable reference types — not analysed — these correctness checks read a source model that was not loaded for this repository, because the repository is written in a language this check does not yet model, or because its projects failed to load. This is a gap in the analyzer, not a finding about this repository
- X6 Hand-rolled structured-format parsing — Advisory — this card reports evidence and never carries a score, so there is nothing missing here.
- X7 Silent fallback defaults — Advisory — this card reports evidence and never carries a score, so there is nothing missing here.
- X9 Subsumed condition operand — Advisory — this card reports evidence and never carries a score, so there is nothing missing here.
Appendix A — Findings (grouped)
Critical — 18 finding(s)
D29 · Static Analysis (SAST)
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
D30 · Dependency Vulnerabilities
- REDACTED
- REDACTED
D29 · Static Analysis (SAST)
- REDACTED
D29 · Static Analysis (SAST)
- REDACTED
D30 · Dependency Vulnerabilities
- REDACTED
Serious — 28 finding(s)
D30 · Dependency Vulnerabilities
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
D30 · Dependency Vulnerabilities
- REDACTED
- REDACTED
- REDACTED
- REDACTED
D30 · Dependency Vulnerabilities
- REDACTED
- REDACTED
- REDACTED
D30 · Dependency Vulnerabilities
- REDACTED
- REDACTED
- REDACTED
D31 · IaC & Container Security
- REDACTED
- REDACTED
C2 · Access Controls
- No authorization src/starter/src/lib.rs:47
D22 · Internal API Consistency
- Naming inconsistency between service implementations. One uses 'get_' prefix while the other uses 'create_' prefix for the same logical operation of providing a handler instance.
D22 · Internal API Consistency
- Type mismatch between property declaration and constructor argument. The property is declared as DateTime, but the constructor accepts String.
D22 · Internal API Consistency
- Incorrect type assignment for domain properties. 'title' and 'note' are semantically text fields but are typed as DateTime.
D22 · Internal API Consistency
- Inconsistent parameter naming for the 'deleted_by' identifier. The command uses 'deleted_by' (implying a user/actor ID), but the repository method signature also uses 'deleted_by'. While consistent with each other, the command property is 'deleted_by: DateTime' in the property list but 'deleted_by: Uuid' in the constructor. This is a contradiction within the Command type itself.
D36 · Supply-chain Provenance & Signing
- REDACTED
D36 · Supply-chain Provenance & Signing
- REDACTED
P5 · DR & Backup
- No DR/backup evidence
Minor — 15 finding(s)
M4 · Documentation accuracy
- README/code drift README.md:43
- README/code drift README.md:85
- README/code drift README.md:86
X4 · Structured logging
- Interpolated log message defeats structured logging src/starter/src/lib.rs:31
- Interpolated log message defeats structured logging src/starter/src/lib.rs:32
D31 · IaC & Container Security
- REDACTED
D34 · Knowledge Freshness
- Orphaned files with no living knowledge
D34 · Knowledge Freshness
- Orphaned file src/starter/src/observability.rs:1
D36 · Supply-chain Provenance & Signing
- REDACTED
D36 · Supply-chain Provenance & Signing
- REDACTED
D36 · Supply-chain Provenance & Signing
- REDACTED
M2 · Architecture documentation
- No ADRs
P6 · Release Hygiene
- No changelog
S1 · Web-Security Posture
- No app-layer HTTPS enforcement detected
S1 · Web-Security Posture
- No security response headers detected
Minor — 18 finding(s)
D12 · Dependency Hygiene
- Outdated: actix-web
- Outdated: anyhow
- Outdated: async-trait
- Outdated: chrono
- Outdated: config
- Outdated: diesel
- Outdated: diesel_migrations
- Outdated: http
- Outdated: metrics
- Outdated: metrics-exporter-prometheus
- Outdated: readonly
- Outdated: reqwest
- Outdated: serde
- Outdated: serde_json
- Outdated: thiserror
- Outdated: tokio
- Outdated: tracing-actix-web
- Outdated: uuid
Appendix B — Reproduction & audit trail
| Dimension | Tool | Version | Command | Findings | Raw output |
|---|---|---|---|---|---|
| D28 · Secrets (history) | gitleaks | — | gitleaks detect --no-banner --config /opt/gitleaks-rules/watchdog-gitleaks.toml --report-format json --report-path /tmp/watchdog-gitleaks-084cc9970c0f486c9837e202f2e1e078/history.json --exit-code 0 --source . | 0 | artifacts/raw/gitleaks-history.json |
| D28 · Secrets (history) | gitleaks | — | gitleaks detect --no-git --no-banner --config /opt/gitleaks-rules/watchdog-gitleaks.toml --report-format json --report-path /tmp/watchdog-gitleaks-084cc9970c0f486c9837e202f2e1e078/tree.json --exit-code 0 --source . | 0 | artifacts/raw/gitleaks-tree.json |
| D29 · Static Analysis (SAST) | semgrep | — | semgrep --config /opt/semgrep-rules/security-audit.yml --config /opt/semgrep-rules/owasp-top-ten.yml --config /opt/semgrep-rules/watchdog-sast.yml --json --quiet --timeout 10 --timeout-threshold 3 --metrics off . | 15 | artifacts/raw/semgrep.json |
| D30 · Dependency Vulnerabilities | osv-scanner | — | osv-scanner --format json --recursive --experimental-disable-plugins transitivedependency/requirements --experimental-disable-plugins dotnet/csproj --experimental-disable-plugins dotnet/nugetcpm . | 21 | artifacts/raw/osv-scanner.json |
| D31 · IaC & Container Security | trivy | — | trivy config --format json --quiet . | 3 | artifacts/raw/trivy-config.json |
| D32 · Data Compliance (PII/GDPR) | semgrep | — | semgrep: not applicable — No personal data was found crossing a boundary the PII/GDPR ruleset checks — nothing written to a log or console sink, placed in a URL or query string, or persisted to browser storage. That is a clean result for the LEAK surface only: this ruleset detects personal data escaping, it does not inventory the personal data a repository holds, so it is not evidence that this repository has no personal-data surface. The personal-data map (Appendix C) and the C1-C5 compliance cards are what speak to that. | 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 | — |
| 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 | — |
| D43 · Malicious Dependencies | osv-scanner | — | osv-scanner --format json --recursive --experimental-disable-plugins transitivedependency/requirements --experimental-disable-plugins dotnet/csproj --experimental-disable-plugins dotnet/nugetcpm . | 0 | artifacts/raw/osv-scanner.json |