Executive summary
zhiyanzhaijie/bestofrs scores 38 out of 100 and is rated Weak, while six of its eight lenses score higher still: Domain Modelling and Performance at 100 and Architecture at 92, all rated Exemplary, Event-Driven at 80, rated Strong, Maturity at 69, rated Adequate, and Security and Compliance at 39, rated Weak.
The score is lower than those six because the weakest lens counts most, and here that is Production Readiness, which scores 27 and is rated Weak. Its Code Coverage dimension scores 0 out of 10, and until that reaches 4, Production Readiness can't be rated higher than Adequate. The first actions are to resolve the 1 No automated tests finding(s) in Code Coverage and to resolve the 1 No tests found finding(s) in Test Distribution, and if Production Readiness rose to 70, the score would rise from 38 to about 46.
24 findings are critical: nine in Static Analysis (SAST), six in IaC & Container Security, five in CQS / query purity, two in Dependency Vulnerabilities, one in Code Coverage and one in Outbox / dual-write.
Watchdog couldn't measure 8 dimensions in this code, among them Documentation Quality, Navigability and Platform End-of-Life, so they are left out of the score. The product code is 20,720 lines, which would take an estimated 0.1 person-years, around €20,000, to rebuild.
Code Health
32
Weak, capped by Type Safety, Cyclomatic Complexity, Exception handling and Structured logging
Architecture
92 ★
Exemplary
Maturity
69
Adequate
Production Readiness
27
Weak, capped by Code Coverage, Test Distribution, Test Coverage and Outbound HTTP resilience
Security and Compliance
39
Weak, capped by Data Protection
Domain Modelling
100 ★
Exemplary
Event-Driven
80
Strong
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.
Production Readiness 27 · counts for 45%Code Health 32 · counts for 25%Security and Compliance 39 · counts for 14%Maturity 69 · counts for 8%Event-Driven 80 · counts for 4%Architecture 92 · counts for 2%Domain Modelling 100 · counts for 1%Performance 100 · counts for 1%
If Production Readiness rose from 27 to 70, the lowest score rated Strong, the score would rise from 38 to about 46.
Code composition: what the lines of code are
Product code 100%
New since the last survey: 7 findings
- Dependency Vulnerabilities · REDACTED
- Change Coupling · Change coupling: admin_layout.rs ↔ root_layout.rs crates/ui/src/root/layouts/admin_layout.rs
- Supply-chain Provenance & Signing · REDACTED
- Data Protection · No data-protection/encryption crates/adapters/migrations/0001_init.sql
- Exception handling · Swallowed exception (empty catch) crates/ui/src/js/dom_bridge.js
- Exception handling · Swallowed exception (empty catch) crates/ui/src/js/dom_bridge.js
- Exception handling · Swallowed exception (empty catch) crates/ui/src/js/chart_bridge.js
Fixed since the last survey: 1 finding
- Documentation (README) · README may be stale
Rebuild cost: about €20,000 · Estimate
| Cost to rebuild | €6,700 to €34,000, for 112 to 356 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 38. 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 | Medium: 20,720 lines of product code |
Top priorities
1
Resolve the 1 No automated tests finding(s) in Code Coverage.
2
Resolve the 1 No tests found finding(s) in Test Distribution.
3
Encrypt sensitive data at rest (encrypt the fields with aes-gcm or chacha20poly1305 before they are written, or open the store encrypted — SQLCipher for rusqlite/sqlx, MongoDB CSFLE) and manage keys in a vault (AWS KMS / Secrets Manager through aws-sdk-kms, GCP KMS / Secret Manager, Azure Key Vault, HashiCorp Vault through vaultrs).
Skip if delegated to infra (Postgres TDE, KMS, etc.).
Diagnosis: what the measurements show together
Where the investment is most exposed
This code would cost about €20,000 to build again, about 0.1 person-years of work. Its weakest lens is Production Readiness, at 27 (Weak). Production Readiness is about whether the product is ready to run in production and to change without breaking. Because the weakest lens counts most in the score, work on Production Readiness also moves the score most.
If you do one thing first
Resolve the 1 No automated tests finding(s) in Code Coverage. Of all the actions in this report, it raises the score most for the work it takes: about 9 points for low effort, because it clears the 1 Code Coverage findings. 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 app.app_error | 2 app.common.pagination | 3 domain.auth.value_object | 4 domain.repo.value_object | 5 ui.components.views.admin.projects.context | 6 ui.components.views.admin.tags.context | 7 ui.root.routes | 8 app.auth.port | 9 app.project.query | 10 app.repo.query | 11 app.snapshot.query | 12 domain.project.entity | 13 domain.snapshot.entity | 14 ui.impls.session.auth | 15 adapters.auth.role_policy | 16 app.project.port | 17 app.snapshot.port | 18 domain.repo.entity | 19 ui.types.projects | 20 adapters.persistence.psql.project_repo | 21 adapters.persistence.psql.snapshot_repo | 22 app.repo.command | 23 app.repo.port | 24 domain.project.event | 25 ui.components.views.admin.projects.edit_panel.project_tab | 26 ui.types.search | 27 adapters.persistence.psql.repo_repo | 28 adapters.persistence.psql.repo_tag_repo | 29 app.project.event_handler | 30 app.snapshot.command | 31 ui.components.layout.user.fuzzy_search | 32 ui.types.finder | 33 ui.types.tags | 34 app.project.command | 35 ui.IO.repos | 36 ui.components.views.admin.projects.edit_panel.repo_tab | 37 ui.types.repos | 38 infra.setup | 39 ui.components.views.home.rank_panel | 40 ui.components.views.repo.list |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 app.app_error | ||||||||||||||||||||||||||||||||||||||||
| 2 app.common.pagination | ||||||||||||||||||||||||||||||||||||||||
| 3 domain.auth.value_object | ||||||||||||||||||||||||||||||||||||||||
| 4 domain.repo.value_object | ||||||||||||||||||||||||||||||||||||||||
| 5 ui.components.views.admin.projects.context | ||||||||||||||||||||||||||||||||||||||||
| 6 ui.components.views.admin.tags.context | ||||||||||||||||||||||||||||||||||||||||
| 7 ui.root.routes | ||||||||||||||||||||||||||||||||||||||||
| 8 app.auth.port | 3 | |||||||||||||||||||||||||||||||||||||||
| 9 app.project.query | 1 | 1 | ||||||||||||||||||||||||||||||||||||||
| 10 app.repo.query | 3 | 1 | 3 | |||||||||||||||||||||||||||||||||||||
| 11 app.snapshot.query | 1 | 1 | ||||||||||||||||||||||||||||||||||||||
| 12 domain.project.entity | 1 | 1 | ||||||||||||||||||||||||||||||||||||||
| 13 domain.snapshot.entity | 1 | 1 | ||||||||||||||||||||||||||||||||||||||
| 14 ui.impls.session.auth | 1 | |||||||||||||||||||||||||||||||||||||||
| 15 adapters.auth.role_policy | 2 | 1 | ||||||||||||||||||||||||||||||||||||||
| 16 app.project.port | 1 | 1 | 1 | |||||||||||||||||||||||||||||||||||||
| 17 app.snapshot.port | 2 | 3 | 1 | 1 | ||||||||||||||||||||||||||||||||||||
| 18 domain.repo.entity | 2 | 1 | 1 | |||||||||||||||||||||||||||||||||||||
| 19 ui.types.projects | 3 | |||||||||||||||||||||||||||||||||||||||
| 20 adapters.persistence.psql.project_repo | 1 | 1 | 1 | 1 | ||||||||||||||||||||||||||||||||||||
| 21 adapters.persistence.psql.snapshot_repo | 1 | 1 | 1 | 3 | ||||||||||||||||||||||||||||||||||||
| 22 app.repo.command | 2 | 1 | ||||||||||||||||||||||||||||||||||||||
| 23 app.repo.port | 4 | 5 | 1 | 1 | ||||||||||||||||||||||||||||||||||||
| 24 domain.project.event | 1 | 1 | ||||||||||||||||||||||||||||||||||||||
| 25 ui.components.views.admin.projects.edit_panel.project_tab | 2 | 1 | 3 | |||||||||||||||||||||||||||||||||||||
| 26 ui.types.search | 1 | 2 | 1 | |||||||||||||||||||||||||||||||||||||
| 27 adapters.persistence.psql.repo_repo | 1 | 1 | 1 | 2 | ||||||||||||||||||||||||||||||||||||
| 28 adapters.persistence.psql.repo_tag_repo | 1 | 2 | 1 | |||||||||||||||||||||||||||||||||||||
| 29 app.project.event_handler | 1 | 2 | ||||||||||||||||||||||||||||||||||||||
| 30 app.snapshot.command | 1 | 1 | 1 | |||||||||||||||||||||||||||||||||||||
| 31 ui.components.layout.user.fuzzy_search | 2 | 1 | 1 | |||||||||||||||||||||||||||||||||||||
| 32 ui.types.finder | 1 | 1 | ||||||||||||||||||||||||||||||||||||||
| 33 ui.types.tags | 1 | 1 | 3 | |||||||||||||||||||||||||||||||||||||
| 34 app.project.command | 1 | 1 | ||||||||||||||||||||||||||||||||||||||
| 35 ui.IO.repos | 1 | 1 | 2 | |||||||||||||||||||||||||||||||||||||
| 36 ui.components.views.admin.projects.edit_panel.repo_tab | 1 | 1 | 2 | |||||||||||||||||||||||||||||||||||||
| 37 ui.types.repos | 1 | 2 | 1 | 1 | 1 | |||||||||||||||||||||||||||||||||||
| 38 infra.setup | 1 | 1 | 1 | 1 | 2 | 1 | ||||||||||||||||||||||||||||||||||
| 39 ui.components.views.home.rank_panel | 1 | 1 | ||||||||||||||||||||||||||||||||||||||
| 40 ui.components.views.repo.list | 1 | 2 | 1 |
Uses a module listed above itPart of a loopThe module itself
8→3 app.auth.port uses domain.auth.value_object✕
- Connections
- 3 pairs of types, where a type in app.auth.port uses a type in domain.auth.value_object.
- The types involved
app.auth.port.ResourceOwner→domain.auth.value_object.UserIdapp.auth.port.RolePolicy→domain.auth.value_object.Roleapp.auth.port.RolePolicy→domain.auth.value_object.UserId
- Direction
- app.auth.port uses domain.auth.value_object, so a change to domain.auth.value_object can break app.auth.port, while a change to app.auth.port can't break domain.auth.value_object.
- Position
- Below the diagonal: app.auth.port uses a module listed above it, which is the healthy direction.
9→2 app.project.query uses app.common.pagination✕
- Connections
- 1 pair of types, where a type in app.project.query uses a type in app.common.pagination.
- The types involved
app.project.query.ProjectQueryHandler→app.common.pagination.Pagination
- Direction
- app.project.query uses app.common.pagination, so a change to app.common.pagination can break app.project.query, while a change to app.project.query can't break app.common.pagination.
- Position
- Below the diagonal: app.project.query uses a module listed above it, which is the healthy direction.
9→4 app.project.query uses domain.repo.value_object✕
- Connections
- 1 pair of types, where a type in app.project.query uses a type in domain.repo.value_object.
- The types involved
app.project.query.ProjectQueryHandler→domain.repo.value_object.RepoId
- Direction
- app.project.query uses domain.repo.value_object, so a change to domain.repo.value_object can break app.project.query, while a change to app.project.query can't break domain.repo.value_object.
- Position
- Below the diagonal: app.project.query uses a module listed above it, which is the healthy direction.
10→2 app.repo.query uses app.common.pagination✕
- Connections
- 3 pairs of types, where a type in app.repo.query uses a type in app.common.pagination.
- The types involved
app.repo.query.RepoQueryHandler→app.common.pagination.Pageapp.repo.query.RepoQueryHandler→app.common.pagination.Paginationapp.repo.query.RepoSearchResult→app.common.pagination.Page
- Direction
- app.repo.query uses app.common.pagination, so a change to app.common.pagination can break app.repo.query, while a change to app.repo.query can't break app.common.pagination.
- Position
- Below the diagonal: app.repo.query uses a module listed above it, which is the healthy direction.
10→4 app.repo.query uses domain.repo.value_object✕
- Connections
- 1 pair of types, where a type in app.repo.query uses a type in domain.repo.value_object.
- The types involved
app.repo.query.RepoQueryHandler→domain.repo.value_object.RepoId
- Direction
- app.repo.query uses domain.repo.value_object, so a change to domain.repo.value_object can break app.repo.query, while a change to app.repo.query can't break domain.repo.value_object.
- Position
- Below the diagonal: app.repo.query uses a module listed above it, which is the healthy direction.
10→23 app.repo.query uses app.repo.port part of a loop✕
- Connections
- 3 pairs of types, where a type in app.repo.query uses a type in app.repo.port.
- The types involved
app.repo.query.LatestPushedRepoCandidatesResult→app.repo.port.GithubLatestPushedRepoInfoapp.repo.query.RepoQueryHandler→app.repo.port.RepoRankMetricapp.repo.query.RepoQueryHandler→app.repo.port.RepoRankQuery
- Direction
- app.repo.query uses app.repo.port, so a change to app.repo.port can break app.repo.query, while a change to app.repo.query can't break app.repo.port.
- 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.
11→2 app.snapshot.query uses app.common.pagination✕
- Connections
- 1 pair of types, where a type in app.snapshot.query uses a type in app.common.pagination.
- The types involved
app.snapshot.query.SnapshotQueryHandler→app.common.pagination.Pagination
- Direction
- app.snapshot.query uses app.common.pagination, so a change to app.common.pagination can break app.snapshot.query, while a change to app.snapshot.query can't break app.common.pagination.
- Position
- Below the diagonal: app.snapshot.query uses a module listed above it, which is the healthy direction.
11→4 app.snapshot.query uses domain.repo.value_object✕
- Connections
- 1 pair of types, where a type in app.snapshot.query uses a type in domain.repo.value_object.
- The types involved
app.snapshot.query.SnapshotQueryHandler→domain.repo.value_object.RepoId
- Direction
- app.snapshot.query uses domain.repo.value_object, so a change to domain.repo.value_object can break app.snapshot.query, while a change to app.snapshot.query can't break domain.repo.value_object.
- Position
- Below the diagonal: app.snapshot.query uses a module listed above it, which is the healthy direction.
12→4 domain.project.entity uses domain.repo.value_object✕
- Connections
- 1 pair of types, where a type in domain.project.entity uses a type in domain.repo.value_object.
- The types involved
domain.project.entity.Project→domain.repo.value_object.RepoId
- Direction
- domain.project.entity uses domain.repo.value_object, so a change to domain.repo.value_object can break domain.project.entity, while a change to domain.project.entity can't break domain.repo.value_object.
- Position
- Below the diagonal: domain.project.entity uses a module listed above it, which is the healthy direction.
12→20 domain.project.entity uses adapters.persistence.psql.project_repo part of a loop✕
- Connections
- 1 pair of types, where a type in domain.project.entity uses a type in adapters.persistence.psql.project_repo.
- The types involved
domain.project.entity.Project→adapters.persistence.psql.project_repo.ProjectDb
- Direction
- domain.project.entity uses adapters.persistence.psql.project_repo, so a change to adapters.persistence.psql.project_repo can break domain.project.entity, while a change to domain.project.entity can't break adapters.persistence.psql.project_repo.
- 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.
13→4 domain.snapshot.entity uses domain.repo.value_object✕
- Connections
- 1 pair of types, where a type in domain.snapshot.entity uses a type in domain.repo.value_object.
- The types involved
domain.snapshot.entity.Snapshot→domain.repo.value_object.RepoId
- Direction
- domain.snapshot.entity uses domain.repo.value_object, so a change to domain.repo.value_object can break domain.snapshot.entity, while a change to domain.snapshot.entity can't break domain.repo.value_object.
- Position
- Below the diagonal: domain.snapshot.entity uses a module listed above it, which is the healthy direction.
13→21 domain.snapshot.entity uses adapters.persistence.psql.snapshot_repo part of a loop✕
- Connections
- 1 pair of types, where a type in domain.snapshot.entity uses a type in adapters.persistence.psql.snapshot_repo.
- The types involved
domain.snapshot.entity.Snapshot→adapters.persistence.psql.snapshot_repo.SnapshotDb
- Direction
- domain.snapshot.entity uses adapters.persistence.psql.snapshot_repo, so a change to adapters.persistence.psql.snapshot_repo can break domain.snapshot.entity, while a change to domain.snapshot.entity can't break adapters.persistence.psql.snapshot_repo.
- 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.
14→3 ui.impls.session.auth uses domain.auth.value_object✕
- Connections
- 1 pair of types, where a type in ui.impls.session.auth uses a type in domain.auth.value_object.
- The types involved
ui.impls.session.auth.SessionAuthUser→domain.auth.value_object.Role
- Direction
- ui.impls.session.auth uses domain.auth.value_object, so a change to domain.auth.value_object can break ui.impls.session.auth, while a change to ui.impls.session.auth can't break domain.auth.value_object.
- Position
- Below the diagonal: ui.impls.session.auth uses a module listed above it, which is the healthy direction.
15→3 adapters.auth.role_policy uses domain.auth.value_object✕
- Connections
- 2 pairs of types, where a type in adapters.auth.role_policy uses a type in domain.auth.value_object.
- The types involved
adapters.auth.role_policy.ConfigRolePolicy→domain.auth.value_object.Roleadapters.auth.role_policy.ConfigRolePolicy→domain.auth.value_object.UserId
- Direction
- adapters.auth.role_policy uses domain.auth.value_object, so a change to domain.auth.value_object can break adapters.auth.role_policy, while a change to adapters.auth.role_policy can't break domain.auth.value_object.
- Position
- Below the diagonal: adapters.auth.role_policy uses a module listed above it, which is the healthy direction.
15→8 adapters.auth.role_policy uses app.auth.port✕
- Connections
- 1 pair of types, where a type in adapters.auth.role_policy uses a type in app.auth.port.
- The types involved
adapters.auth.role_policy.ConfigRolePolicy→app.auth.port.RolePolicy
- Direction
- adapters.auth.role_policy uses app.auth.port, so a change to app.auth.port can break adapters.auth.role_policy, while a change to adapters.auth.role_policy can't break app.auth.port.
- Position
- Below the diagonal: adapters.auth.role_policy uses a module listed above it, which is the healthy direction.
16→2 app.project.port uses app.common.pagination✕
- Connections
- 1 pair of types, where a type in app.project.port uses a type in app.common.pagination.
- The types involved
app.project.port.ProjectRepo→app.common.pagination.Pagination
- Direction
- app.project.port uses app.common.pagination, so a change to app.common.pagination can break app.project.port, while a change to app.project.port can't break app.common.pagination.
- Position
- Below the diagonal: app.project.port uses a module listed above it, which is the healthy direction.
16→4 app.project.port uses domain.repo.value_object✕
- Connections
- 1 pair of types, where a type in app.project.port uses a type in domain.repo.value_object.
- The types involved
app.project.port.ProjectRepo→domain.repo.value_object.RepoId
- Direction
- app.project.port uses domain.repo.value_object, so a change to domain.repo.value_object can break app.project.port, while a change to app.project.port can't break domain.repo.value_object.
- Position
- Below the diagonal: app.project.port uses a module listed above it, which is the healthy direction.
16→12 app.project.port uses domain.project.entity✕
- Connections
- 1 pair of types, where a type in app.project.port uses a type in domain.project.entity.
- The types involved
app.project.port.ProjectRepo→domain.project.entity.Project
- Direction
- app.project.port uses domain.project.entity, so a change to domain.project.entity can break app.project.port, while a change to app.project.port can't break domain.project.entity.
- Position
- Below the diagonal: app.project.port uses a module listed above it, which is the healthy direction.
17→2 app.snapshot.port uses app.common.pagination✕
- Connections
- 2 pairs of types, where a type in app.snapshot.port uses a type in app.common.pagination.
- The types involved
app.snapshot.port.SnapshotDeltaRepo→app.common.pagination.Paginationapp.snapshot.port.SnapshotRepo→app.common.pagination.Pagination
- Direction
- app.snapshot.port uses app.common.pagination, so a change to app.common.pagination can break app.snapshot.port, while a change to app.snapshot.port can't break app.common.pagination.
- Position
- Below the diagonal: app.snapshot.port uses a module listed above it, which is the healthy direction.
17→4 app.snapshot.port uses domain.repo.value_object✕
- Connections
- 3 pairs of types, where a type in app.snapshot.port uses a type in domain.repo.value_object.
- The types involved
app.snapshot.port.SnapshotDelta→domain.repo.value_object.RepoIdapp.snapshot.port.SnapshotDeltaRepo→domain.repo.value_object.RepoIdapp.snapshot.port.SnapshotRepo→domain.repo.value_object.RepoId
- Direction
- app.snapshot.port uses domain.repo.value_object, so a change to domain.repo.value_object can break app.snapshot.port, while a change to app.snapshot.port can't break domain.repo.value_object.
- Position
- Below the diagonal: app.snapshot.port uses a module listed above it, which is the healthy direction.
17→13 app.snapshot.port uses domain.snapshot.entity✕
- Connections
- 1 pair of types, where a type in app.snapshot.port uses a type in domain.snapshot.entity.
- The types involved
app.snapshot.port.SnapshotRepo→domain.snapshot.entity.Snapshot
- Direction
- app.snapshot.port uses domain.snapshot.entity, so a change to domain.snapshot.entity can break app.snapshot.port, while a change to app.snapshot.port can't break domain.snapshot.entity.
- Position
- Below the diagonal: app.snapshot.port uses a module listed above it, which is the healthy direction.
17→21 app.snapshot.port uses adapters.persistence.psql.snapshot_repo part of a loop✕
- Connections
- 1 pair of types, where a type in app.snapshot.port uses a type in adapters.persistence.psql.snapshot_repo.
- The types involved
app.snapshot.port.SnapshotDelta→adapters.persistence.psql.snapshot_repo.SnapshotDeltaDb
- Direction
- app.snapshot.port uses adapters.persistence.psql.snapshot_repo, so a change to adapters.persistence.psql.snapshot_repo can break app.snapshot.port, while a change to app.snapshot.port can't break adapters.persistence.psql.snapshot_repo.
- 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.
18→4 domain.repo.entity uses domain.repo.value_object✕
- Connections
- 2 pairs of types, where a type in domain.repo.entity uses a type in domain.repo.value_object.
- The types involved
domain.repo.entity.Repo→domain.repo.value_object.RepoIddomain.repo.entity.RepoWithTags→domain.repo.value_object.Tag
- Direction
- domain.repo.entity uses domain.repo.value_object, so a change to domain.repo.value_object can break domain.repo.entity, while a change to domain.repo.entity can't break domain.repo.value_object.
- Position
- Below the diagonal: domain.repo.entity uses a module listed above it, which is the healthy direction.
18→12 domain.repo.entity uses domain.project.entity✕
- Connections
- 1 pair of types, where a type in domain.repo.entity uses a type in domain.project.entity.
- The types involved
domain.repo.entity.Repo→domain.project.entity.Project
- Direction
- domain.repo.entity uses domain.project.entity, so a change to domain.project.entity can break domain.repo.entity, while a change to domain.repo.entity can't break domain.project.entity.
- Position
- Below the diagonal: domain.repo.entity uses a module listed above it, which is the healthy direction.
18→27 domain.repo.entity uses adapters.persistence.psql.repo_repo part of a loop✕
- Connections
- 1 pair of types, where a type in domain.repo.entity uses a type in adapters.persistence.psql.repo_repo.
- The types involved
domain.repo.entity.Repo→adapters.persistence.psql.repo_repo.RepoDb
- Direction
- domain.repo.entity uses adapters.persistence.psql.repo_repo, so a change to adapters.persistence.psql.repo_repo can break domain.repo.entity, while a change to domain.repo.entity can't break adapters.persistence.psql.repo_repo.
- 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.
19→12 ui.types.projects uses domain.project.entity✕
- Connections
- 3 pairs of types, where a type in ui.types.projects uses a type in domain.project.entity.
- The types involved
ui.types.projects.ProjectDto→domain.project.entity.Projectui.types.projects.ProjectDto→domain.project.entity.ProjectStatusui.types.projects.ProjectImportItem→domain.project.entity.ProjectStatus
- Direction
- ui.types.projects uses domain.project.entity, so a change to domain.project.entity can break ui.types.projects, while a change to ui.types.projects can't break domain.project.entity.
- Position
- Below the diagonal: ui.types.projects uses a module listed above it, which is the healthy direction.
20→2 adapters.persistence.psql.project_repo uses app.common.pagination✕
- Connections
- 1 pair of types, where a type in adapters.persistence.psql.project_repo uses a type in app.common.pagination.
- The types involved
adapters.persistence.psql.project_repo.PostgresProjectRepo→app.common.pagination.Pagination
- Direction
- adapters.persistence.psql.project_repo uses app.common.pagination, so a change to app.common.pagination can break adapters.persistence.psql.project_repo, while a change to adapters.persistence.psql.project_repo can't break app.common.pagination.
- Position
- Below the diagonal: adapters.persistence.psql.project_repo uses a module listed above it, which is the healthy direction.
20→4 adapters.persistence.psql.project_repo uses domain.repo.value_object✕
- Connections
- 1 pair of types, where a type in adapters.persistence.psql.project_repo uses a type in domain.repo.value_object.
- The types involved
adapters.persistence.psql.project_repo.PostgresProjectRepo→domain.repo.value_object.RepoId
- Direction
- adapters.persistence.psql.project_repo uses domain.repo.value_object, so a change to domain.repo.value_object can break adapters.persistence.psql.project_repo, while a change to adapters.persistence.psql.project_repo can't break domain.repo.value_object.
- Position
- Below the diagonal: adapters.persistence.psql.project_repo uses a module listed above it, which is the healthy direction.
20→12 adapters.persistence.psql.project_repo uses domain.project.entity✕
- Connections
- 1 pair of types, where a type in adapters.persistence.psql.project_repo uses a type in domain.project.entity.
- The types involved
adapters.persistence.psql.project_repo.PostgresProjectRepo→domain.project.entity.Project
- Direction
- adapters.persistence.psql.project_repo uses domain.project.entity, so a change to domain.project.entity can break adapters.persistence.psql.project_repo, while a change to adapters.persistence.psql.project_repo can't break domain.project.entity.
- Position
- Below the diagonal: adapters.persistence.psql.project_repo uses a module listed above it, which is the healthy direction.
20→16 adapters.persistence.psql.project_repo uses app.project.port✕
- Connections
- 1 pair of types, where a type in adapters.persistence.psql.project_repo uses a type in app.project.port.
- The types involved
adapters.persistence.psql.project_repo.PostgresProjectRepo→app.project.port.ProjectRepo
- Direction
- adapters.persistence.psql.project_repo uses app.project.port, so a change to app.project.port can break adapters.persistence.psql.project_repo, while a change to adapters.persistence.psql.project_repo can't break app.project.port.
- Position
- Below the diagonal: adapters.persistence.psql.project_repo uses a module listed above it, which is the healthy direction.
21→2 adapters.persistence.psql.snapshot_repo uses app.common.pagination✕
- Connections
- 1 pair of types, where a type in adapters.persistence.psql.snapshot_repo uses a type in app.common.pagination.
- The types involved
adapters.persistence.psql.snapshot_repo.PostgresSnapshotRepo→app.common.pagination.Pagination
- Direction
- adapters.persistence.psql.snapshot_repo uses app.common.pagination, so a change to app.common.pagination can break adapters.persistence.psql.snapshot_repo, while a change to adapters.persistence.psql.snapshot_repo can't break app.common.pagination.
- Position
- Below the diagonal: adapters.persistence.psql.snapshot_repo uses a module listed above it, which is the healthy direction.
21→4 adapters.persistence.psql.snapshot_repo uses domain.repo.value_object✕
- Connections
- 1 pair of types, where a type in adapters.persistence.psql.snapshot_repo uses a type in domain.repo.value_object.
- The types involved
adapters.persistence.psql.snapshot_repo.PostgresSnapshotRepo→domain.repo.value_object.RepoId
- Direction
- adapters.persistence.psql.snapshot_repo uses domain.repo.value_object, so a change to domain.repo.value_object can break adapters.persistence.psql.snapshot_repo, while a change to adapters.persistence.psql.snapshot_repo can't break domain.repo.value_object.
- Position
- Below the diagonal: adapters.persistence.psql.snapshot_repo uses a module listed above it, which is the healthy direction.
21→13 adapters.persistence.psql.snapshot_repo uses domain.snapshot.entity✕
- Connections
- 1 pair of types, where a type in adapters.persistence.psql.snapshot_repo uses a type in domain.snapshot.entity.
- The types involved
adapters.persistence.psql.snapshot_repo.PostgresSnapshotRepo→domain.snapshot.entity.Snapshot
- Direction
- adapters.persistence.psql.snapshot_repo uses domain.snapshot.entity, so a change to domain.snapshot.entity can break adapters.persistence.psql.snapshot_repo, while a change to adapters.persistence.psql.snapshot_repo can't break domain.snapshot.entity.
- Position
- Below the diagonal: adapters.persistence.psql.snapshot_repo uses a module listed above it, which is the healthy direction.
21→17 adapters.persistence.psql.snapshot_repo uses app.snapshot.port✕
- Connections
- 3 pairs of types, where a type in adapters.persistence.psql.snapshot_repo uses a type in app.snapshot.port.
- The types involved
adapters.persistence.psql.snapshot_repo.PostgresSnapshotRepo→app.snapshot.port.SnapshotDeltaadapters.persistence.psql.snapshot_repo.PostgresSnapshotRepo→app.snapshot.port.SnapshotDeltaRepoadapters.persistence.psql.snapshot_repo.PostgresSnapshotRepo→app.snapshot.port.SnapshotRepo
- Direction
- adapters.persistence.psql.snapshot_repo uses app.snapshot.port, so a change to app.snapshot.port can break adapters.persistence.psql.snapshot_repo, while a change to adapters.persistence.psql.snapshot_repo can't break app.snapshot.port.
- Position
- Below the diagonal: adapters.persistence.psql.snapshot_repo uses a module listed above it, which is the healthy direction.
22→4 app.repo.command uses domain.repo.value_object✕
- Connections
- 2 pairs of types, where a type in app.repo.command uses a type in domain.repo.value_object.
- The types involved
app.repo.command.RepoCommandHandler→domain.repo.value_object.RepoIdapp.repo.command.RepoCommandHandler→domain.repo.value_object.Tag
- Direction
- app.repo.command uses domain.repo.value_object, so a change to domain.repo.value_object can break app.repo.command, while a change to app.repo.command can't break domain.repo.value_object.
- Position
- Below the diagonal: app.repo.command uses a module listed above it, which is the healthy direction.
22→18 app.repo.command uses domain.repo.entity✕
- Connections
- 1 pair of types, where a type in app.repo.command uses a type in domain.repo.entity.
- The types involved
app.repo.command.RepoCommandHandler→domain.repo.entity.Repo
- Direction
- app.repo.command uses domain.repo.entity, so a change to domain.repo.entity can break app.repo.command, while a change to app.repo.command can't break domain.repo.entity.
- Position
- Below the diagonal: app.repo.command uses a module listed above it, which is the healthy direction.
23→2 app.repo.port uses app.common.pagination✕
- Connections
- 4 pairs of types, where a type in app.repo.port uses a type in app.common.pagination.
- The types involved
app.repo.port.RepoListQuery→app.common.pagination.Paginationapp.repo.port.RepoRepo→app.common.pagination.Paginationapp.repo.port.RepoSearchCache→app.common.pagination.Paginationapp.repo.port.RepoTagRepo→app.common.pagination.Pagination
- Direction
- app.repo.port uses app.common.pagination, so a change to app.common.pagination can break app.repo.port, while a change to app.repo.port can't break app.common.pagination.
- Position
- Below the diagonal: app.repo.port uses a module listed above it, which is the healthy direction.
23→4 app.repo.port uses domain.repo.value_object✕
- Connections
- 5 pairs of types, where a type in app.repo.port uses a type in domain.repo.value_object.
- The types involved
app.repo.port.RepoIdentityCandidate→domain.repo.value_object.RepoIdapp.repo.port.RepoIdentityConflict→domain.repo.value_object.RepoIdapp.repo.port.RepoRepo→domain.repo.value_object.RepoIdapp.repo.port.RepoTagRepo→domain.repo.value_object.RepoIdapp.repo.port.RepoTagRepo→domain.repo.value_object.Tag
- Direction
- app.repo.port uses domain.repo.value_object, so a change to domain.repo.value_object can break app.repo.port, while a change to app.repo.port can't break domain.repo.value_object.
- Position
- Below the diagonal: app.repo.port uses a module listed above it, which is the healthy direction.
23→10 app.repo.port uses app.repo.query✕
- Connections
- 1 pair of types, where a type in app.repo.port uses a type in app.repo.query.
- The types involved
app.repo.port.RepoSearchCache→app.repo.query.RepoSearchResult
- Direction
- app.repo.port uses app.repo.query, so a change to app.repo.query can break app.repo.port, while a change to app.repo.port can't break app.repo.query.
- Position
- Below the diagonal: app.repo.port uses a module listed above it, which is the healthy direction.
23→18 app.repo.port uses domain.repo.entity✕
- Connections
- 1 pair of types, where a type in app.repo.port uses a type in domain.repo.entity.
- The types involved
app.repo.port.RepoRepo→domain.repo.entity.Repo
- Direction
- app.repo.port uses domain.repo.entity, so a change to domain.repo.entity can break app.repo.port, while a change to app.repo.port can't break domain.repo.entity.
- Position
- Below the diagonal: app.repo.port uses a module listed above it, which is the healthy direction.
24→12 domain.project.event uses domain.project.entity✕
- Connections
- 1 pair of types, where a type in domain.project.event uses a type in domain.project.entity.
- The types involved
domain.project.event.ProjectUpdated→domain.project.entity.Project
- Direction
- domain.project.event uses domain.project.entity, so a change to domain.project.entity can break domain.project.event, while a change to domain.project.event can't break domain.project.entity.
- Position
- Below the diagonal: domain.project.event uses a module listed above it, which is the healthy direction.
24→18 domain.project.event uses domain.repo.entity✕
- Connections
- 1 pair of types, where a type in domain.project.event uses a type in domain.repo.entity.
- The types involved
domain.project.event.ProjectCreated→domain.repo.entity.Repo
- Direction
- domain.project.event uses domain.repo.entity, so a change to domain.repo.entity can break domain.project.event, while a change to domain.project.event can't break domain.repo.entity.
- Position
- Below the diagonal: domain.project.event uses a module listed above it, which is the healthy direction.
25→5 ui.components.views.admin.projects.edit_panel.project_tab uses ui.components.views.admin.projects.context✕
- Connections
- 2 pairs of types, where a type in ui.components.views.admin.projects.edit_panel.project_tab uses a type in ui.components.views.admin.projects.context.
- The types involved
ui.components.views.admin.projects.edit_panel.project_tab.ProjectFormData→ui.components.views.admin.projects.context.ProjectPanelModeui.components.views.admin.projects.edit_panel.project_tab.ProjectTabProps→ui.components.views.admin.projects.context.ProjectPanelMode
- Direction
- ui.components.views.admin.projects.edit_panel.project_tab uses ui.components.views.admin.projects.context, so a change to ui.components.views.admin.projects.context can break ui.components.views.admin.projects.edit_panel.project_tab, while a change to ui.components.views.admin.projects.edit_panel.project_tab can't break ui.components.views.admin.projects.context.
- Position
- Below the diagonal: ui.components.views.admin.projects.edit_panel.project_tab uses a module listed above it, which is the healthy direction.
25→12 ui.components.views.admin.projects.edit_panel.project_tab uses domain.project.entity✕
- Connections
- 1 pair of types, where a type in ui.components.views.admin.projects.edit_panel.project_tab uses a type in domain.project.entity.
- The types involved
ui.components.views.admin.projects.edit_panel.project_tab.ProjectFormData→domain.project.entity.ProjectStatus
- Direction
- ui.components.views.admin.projects.edit_panel.project_tab uses domain.project.entity, so a change to domain.project.entity can break ui.components.views.admin.projects.edit_panel.project_tab, while a change to ui.components.views.admin.projects.edit_panel.project_tab can't break domain.project.entity.
- Position
- Below the diagonal: ui.components.views.admin.projects.edit_panel.project_tab uses a module listed above it, which is the healthy direction.
25→19 ui.components.views.admin.projects.edit_panel.project_tab uses ui.types.projects✕
- Connections
- 3 pairs of types, where a type in ui.components.views.admin.projects.edit_panel.project_tab uses a type in ui.types.projects.
- The types involved
ui.components.views.admin.projects.edit_panel.project_tab.ProjectFormData→ui.types.projects.ProjectDtoui.components.views.admin.projects.edit_panel.project_tab.ProjectFormData→ui.types.projects.ProjectImportItemui.components.views.admin.projects.edit_panel.project_tab.project_tab$module→ui.types.projects.ImportProjectsResult
- Direction
- ui.components.views.admin.projects.edit_panel.project_tab uses ui.types.projects, so a change to ui.types.projects can break ui.components.views.admin.projects.edit_panel.project_tab, while a change to ui.components.views.admin.projects.edit_panel.project_tab can't break ui.types.projects.
- Position
- Below the diagonal: ui.components.views.admin.projects.edit_panel.project_tab uses a module listed above it, which is the healthy direction.
26→2 ui.types.search uses app.common.pagination✕
- Connections
- 1 pair of types, where a type in ui.types.search uses a type in app.common.pagination.
- The types involved
ui.types.search.SearchResultDto→app.common.pagination.Page
- Direction
- ui.types.search uses app.common.pagination, so a change to app.common.pagination can break ui.types.search, while a change to ui.types.search can't break app.common.pagination.
- Position
- Below the diagonal: ui.types.search uses a module listed above it, which is the healthy direction.
26→10 ui.types.search uses app.repo.query✕
- Connections
- 2 pairs of types, where a type in ui.types.search uses a type in app.repo.query.
- The types involved
ui.types.search.SearchResultDto→app.repo.query.RepoSearchResultui.types.search.SearchTagDto→app.repo.query.RepoSearchTagItem
- Direction
- ui.types.search uses app.repo.query, so a change to app.repo.query can break ui.types.search, while a change to ui.types.search can't break app.repo.query.
- Position
- Below the diagonal: ui.types.search uses a module listed above it, which is the healthy direction.
26→18 ui.types.search uses domain.repo.entity✕
- Connections
- 1 pair of types, where a type in ui.types.search uses a type in domain.repo.entity.
- The types involved
ui.types.search.SearchRepoDto→domain.repo.entity.Repo
- Direction
- ui.types.search uses domain.repo.entity, so a change to domain.repo.entity can break ui.types.search, while a change to ui.types.search can't break domain.repo.entity.
- Position
- Below the diagonal: ui.types.search uses a module listed above it, which is the healthy direction.
27→2 adapters.persistence.psql.repo_repo uses app.common.pagination✕
- Connections
- 1 pair of types, where a type in adapters.persistence.psql.repo_repo uses a type in app.common.pagination.
- The types involved
adapters.persistence.psql.repo_repo.PostgresRepoRepo→app.common.pagination.Pagination
- Direction
- adapters.persistence.psql.repo_repo uses app.common.pagination, so a change to app.common.pagination can break adapters.persistence.psql.repo_repo, while a change to adapters.persistence.psql.repo_repo can't break app.common.pagination.
- Position
- Below the diagonal: adapters.persistence.psql.repo_repo uses a module listed above it, which is the healthy direction.
27→4 adapters.persistence.psql.repo_repo uses domain.repo.value_object✕
- Connections
- 1 pair of types, where a type in adapters.persistence.psql.repo_repo uses a type in domain.repo.value_object.
- The types involved
adapters.persistence.psql.repo_repo.PostgresRepoRepo→domain.repo.value_object.RepoId
- Direction
- adapters.persistence.psql.repo_repo uses domain.repo.value_object, so a change to domain.repo.value_object can break adapters.persistence.psql.repo_repo, while a change to adapters.persistence.psql.repo_repo can't break domain.repo.value_object.
- Position
- Below the diagonal: adapters.persistence.psql.repo_repo uses a module listed above it, which is the healthy direction.
27→18 adapters.persistence.psql.repo_repo uses domain.repo.entity✕
- Connections
- 1 pair of types, where a type in adapters.persistence.psql.repo_repo uses a type in domain.repo.entity.
- The types involved
adapters.persistence.psql.repo_repo.PostgresRepoRepo→domain.repo.entity.Repo
- Direction
- adapters.persistence.psql.repo_repo uses domain.repo.entity, so a change to domain.repo.entity can break adapters.persistence.psql.repo_repo, while a change to adapters.persistence.psql.repo_repo can't break domain.repo.entity.
- Position
- Below the diagonal: adapters.persistence.psql.repo_repo uses a module listed above it, which is the healthy direction.
27→23 adapters.persistence.psql.repo_repo uses app.repo.port✕
- Connections
- 2 pairs of types, where a type in adapters.persistence.psql.repo_repo uses a type in app.repo.port.
- The types involved
adapters.persistence.psql.repo_repo.PostgresRepoRepo→app.repo.port.RepoRankQueryadapters.persistence.psql.repo_repo.PostgresRepoRepo→app.repo.port.RepoRepo
- Direction
- adapters.persistence.psql.repo_repo uses app.repo.port, so a change to app.repo.port can break adapters.persistence.psql.repo_repo, while a change to adapters.persistence.psql.repo_repo can't break app.repo.port.
- Position
- Below the diagonal: adapters.persistence.psql.repo_repo uses a module listed above it, which is the healthy direction.
28→2 adapters.persistence.psql.repo_tag_repo uses app.common.pagination✕
- Connections
- 1 pair of types, where a type in adapters.persistence.psql.repo_tag_repo uses a type in app.common.pagination.
- The types involved
adapters.persistence.psql.repo_tag_repo.PostgresRepoTagRepo→app.common.pagination.Pagination
- Direction
- adapters.persistence.psql.repo_tag_repo uses app.common.pagination, so a change to app.common.pagination can break adapters.persistence.psql.repo_tag_repo, while a change to adapters.persistence.psql.repo_tag_repo can't break app.common.pagination.
- Position
- Below the diagonal: adapters.persistence.psql.repo_tag_repo uses a module listed above it, which is the healthy direction.
28→4 adapters.persistence.psql.repo_tag_repo uses domain.repo.value_object✕
- Connections
- 2 pairs of types, where a type in adapters.persistence.psql.repo_tag_repo uses a type in domain.repo.value_object.
- The types involved
adapters.persistence.psql.repo_tag_repo.PostgresRepoTagRepo→domain.repo.value_object.RepoIdadapters.persistence.psql.repo_tag_repo.PostgresRepoTagRepo→domain.repo.value_object.Tag
- Direction
- adapters.persistence.psql.repo_tag_repo uses domain.repo.value_object, so a change to domain.repo.value_object can break adapters.persistence.psql.repo_tag_repo, while a change to adapters.persistence.psql.repo_tag_repo can't break domain.repo.value_object.
- Position
- Below the diagonal: adapters.persistence.psql.repo_tag_repo uses a module listed above it, which is the healthy direction.
28→23 adapters.persistence.psql.repo_tag_repo uses app.repo.port✕
- Connections
- 1 pair of types, where a type in adapters.persistence.psql.repo_tag_repo uses a type in app.repo.port.
- The types involved
adapters.persistence.psql.repo_tag_repo.PostgresRepoTagRepo→app.repo.port.RepoTagRepo
- Direction
- adapters.persistence.psql.repo_tag_repo uses app.repo.port, so a change to app.repo.port can break adapters.persistence.psql.repo_tag_repo, while a change to adapters.persistence.psql.repo_tag_repo can't break app.repo.port.
- Position
- Below the diagonal: adapters.persistence.psql.repo_tag_repo uses a module listed above it, which is the healthy direction.
29→22 app.project.event_handler uses app.repo.command✕
- Connections
- 1 pair of types, where a type in app.project.event_handler uses a type in app.repo.command.
- The types involved
app.project.event_handler.ProjectEventHandler→app.repo.command.RepoCommandHandler
- Direction
- app.project.event_handler uses app.repo.command, so a change to app.repo.command can break app.project.event_handler, while a change to app.project.event_handler can't break app.repo.command.
- Position
- Below the diagonal: app.project.event_handler uses a module listed above it, which is the healthy direction.
29→24 app.project.event_handler uses domain.project.event✕
- Connections
- 2 pairs of types, where a type in app.project.event_handler uses a type in domain.project.event.
- The types involved
app.project.event_handler.ProjectEventHandler→domain.project.event.ProjectCreatedapp.project.event_handler.ProjectEventHandler→domain.project.event.ProjectUpdated
- Direction
- app.project.event_handler uses domain.project.event, so a change to domain.project.event can break app.project.event_handler, while a change to app.project.event_handler can't break domain.project.event.
- Position
- Below the diagonal: app.project.event_handler uses a module listed above it, which is the healthy direction.
30→9 app.snapshot.command uses app.project.query✕
- Connections
- 1 pair of types, where a type in app.snapshot.command uses a type in app.project.query.
- The types involved
app.snapshot.command.IngestDailySnapshots→app.project.query.ProjectQueryHandler
- Direction
- app.snapshot.command uses app.project.query, so a change to app.project.query can break app.snapshot.command, while a change to app.snapshot.command can't break app.project.query.
- Position
- Below the diagonal: app.snapshot.command uses a module listed above it, which is the healthy direction.
30→13 app.snapshot.command uses domain.snapshot.entity✕
- Connections
- 1 pair of types, where a type in app.snapshot.command uses a type in domain.snapshot.entity.
- The types involved
app.snapshot.command.SnapshotCommandHandler→domain.snapshot.entity.Snapshot
- Direction
- app.snapshot.command uses domain.snapshot.entity, so a change to domain.snapshot.entity can break app.snapshot.command, while a change to app.snapshot.command can't break domain.snapshot.entity.
- Position
- Below the diagonal: app.snapshot.command uses a module listed above it, which is the healthy direction.
30→22 app.snapshot.command uses app.repo.command✕
- Connections
- 1 pair of types, where a type in app.snapshot.command uses a type in app.repo.command.
- The types involved
app.snapshot.command.IngestDailySnapshots→app.repo.command.RepoCommandHandler
- Direction
- app.snapshot.command uses app.repo.command, so a change to app.repo.command can break app.snapshot.command, while a change to app.snapshot.command can't break app.repo.command.
- Position
- Below the diagonal: app.snapshot.command uses a module listed above it, which is the healthy direction.
31→2 ui.components.layout.user.fuzzy_search uses app.common.pagination✕
- Connections
- 2 pairs of types, where a type in ui.components.layout.user.fuzzy_search uses a type in app.common.pagination.
- The types involved
ui.components.layout.user.fuzzy_search.fuzzy_search$module→app.common.pagination.Pageui.components.layout.user.fuzzy_search.fuzzy_search$module→app.common.pagination.Pagination
- Direction
- ui.components.layout.user.fuzzy_search uses app.common.pagination, so a change to app.common.pagination can break ui.components.layout.user.fuzzy_search, while a change to ui.components.layout.user.fuzzy_search can't break app.common.pagination.
- Position
- Below the diagonal: ui.components.layout.user.fuzzy_search uses a module listed above it, which is the healthy direction.
31→7 ui.components.layout.user.fuzzy_search uses ui.root.routes✕
- Connections
- 1 pair of types, where a type in ui.components.layout.user.fuzzy_search uses a type in ui.root.routes.
- The types involved
ui.components.layout.user.fuzzy_search.fuzzy_search$module→ui.root.routes.Route
- Direction
- ui.components.layout.user.fuzzy_search uses ui.root.routes, so a change to ui.root.routes can break ui.components.layout.user.fuzzy_search, while a change to ui.components.layout.user.fuzzy_search can't break ui.root.routes.
- Position
- Below the diagonal: ui.components.layout.user.fuzzy_search uses a module listed above it, which is the healthy direction.
31→26 ui.components.layout.user.fuzzy_search uses ui.types.search✕
- Connections
- 1 pair of types, where a type in ui.components.layout.user.fuzzy_search uses a type in ui.types.search.
- The types involved
ui.components.layout.user.fuzzy_search.fuzzy_search$module→ui.types.search.SearchRepoDto
- Direction
- ui.components.layout.user.fuzzy_search uses ui.types.search, so a change to ui.types.search can break ui.components.layout.user.fuzzy_search, while a change to ui.components.layout.user.fuzzy_search can't break ui.types.search.
- Position
- Below the diagonal: ui.components.layout.user.fuzzy_search uses a module listed above it, which is the healthy direction.
32→10 ui.types.finder uses app.repo.query✕
- Connections
- 1 pair of types, where a type in ui.types.finder uses a type in app.repo.query.
- The types involved
ui.types.finder.LatestPushedRepoQueryResultDto→app.repo.query.LatestPushedRepoCandidatesResult
- Direction
- ui.types.finder uses app.repo.query, so a change to app.repo.query can break ui.types.finder, while a change to ui.types.finder can't break app.repo.query.
- Position
- Below the diagonal: ui.types.finder uses a module listed above it, which is the healthy direction.
32→23 ui.types.finder uses app.repo.port✕
- Connections
- 1 pair of types, where a type in ui.types.finder uses a type in app.repo.port.
- The types involved
ui.types.finder.LatestPushedRepoDto→app.repo.port.GithubLatestPushedRepoInfo
- Direction
- ui.types.finder uses app.repo.port, so a change to app.repo.port can break ui.types.finder, while a change to ui.types.finder can't break app.repo.port.
- Position
- Below the diagonal: ui.types.finder uses a module listed above it, which is the healthy direction.
33→4 ui.types.tags uses domain.repo.value_object✕
- Connections
- 1 pair of types, where a type in ui.types.tags uses a type in domain.repo.value_object.
- The types involved
ui.types.tags.TagDto→domain.repo.value_object.Tag
- Direction
- ui.types.tags uses domain.repo.value_object, so a change to domain.repo.value_object can break ui.types.tags, while a change to ui.types.tags can't break domain.repo.value_object.
- Position
- Below the diagonal: ui.types.tags uses a module listed above it, which is the healthy direction.
33→10 ui.types.tags uses app.repo.query✕
- Connections
- 1 pair of types, where a type in ui.types.tags uses a type in app.repo.query.
- The types involved
ui.types.tags.TagDto→app.repo.query.RepoSearchTagItem
- Direction
- ui.types.tags uses app.repo.query, so a change to app.repo.query can break ui.types.tags, while a change to ui.types.tags can't break app.repo.query.
- Position
- Below the diagonal: ui.types.tags uses a module listed above it, which is the healthy direction.
33→23 ui.types.tags uses app.repo.port✕
- Connections
- 3 pairs of types, where a type in ui.types.tags uses a type in app.repo.port.
- The types involved
ui.types.tags.TagFacetDto→app.repo.port.RepoTagFacetui.types.tags.TagListItemDto→app.repo.port.RepoTagListItemui.types.tags.TagTopRepoDto→app.repo.port.RepoTagTopRepo
- Direction
- ui.types.tags uses app.repo.port, so a change to app.repo.port can break ui.types.tags, while a change to ui.types.tags can't break app.repo.port.
- Position
- Below the diagonal: ui.types.tags uses a module listed above it, which is the healthy direction.
34→12 app.project.command uses domain.project.entity✕
- Connections
- 1 pair of types, where a type in app.project.command uses a type in domain.project.entity.
- The types involved
app.project.command.ImportProjectCommand→domain.project.entity.ProjectStatus
- Direction
- app.project.command uses domain.project.entity, so a change to domain.project.entity can break app.project.command, while a change to app.project.command can't break domain.project.entity.
- Position
- Below the diagonal: app.project.command uses a module listed above it, which is the healthy direction.
34→29 app.project.command uses app.project.event_handler✕
- Connections
- 1 pair of types, where a type in app.project.command uses a type in app.project.event_handler.
- The types involved
app.project.command.ProjectCommandHandler→app.project.event_handler.ProjectEventHandler
- Direction
- app.project.command uses app.project.event_handler, so a change to app.project.event_handler can break app.project.command, while a change to app.project.command can't break app.project.event_handler.
- Position
- Below the diagonal: app.project.command uses a module listed above it, which is the healthy direction.
35→2 ui.IO.repos uses app.common.pagination✕
- Connections
- 1 pair of types, where a type in ui.IO.repos uses a type in app.common.pagination.
- The types involved
ui.IO.repos.repos$module→app.common.pagination.Pagination
- Direction
- ui.IO.repos uses app.common.pagination, so a change to app.common.pagination can break ui.IO.repos, while a change to ui.IO.repos can't break app.common.pagination.
- Position
- Below the diagonal: ui.IO.repos uses a module listed above it, which is the healthy direction.
35→23 ui.IO.repos uses app.repo.port✕
- Connections
- 1 pair of types, where a type in ui.IO.repos uses a type in app.repo.port.
- The types involved
ui.IO.repos.repos$module→app.repo.port.RepoListQuery
- Direction
- ui.IO.repos uses app.repo.port, so a change to app.repo.port can break ui.IO.repos, while a change to ui.IO.repos can't break app.repo.port.
- Position
- Below the diagonal: ui.IO.repos uses a module listed above it, which is the healthy direction.
35→33 ui.IO.repos uses ui.types.tags✕
- Connections
- 2 pairs of types, where a type in ui.IO.repos uses a type in ui.types.tags.
- The types involved
ui.IO.repos.repos$module→ui.types.tags.TagDtoui.IO.repos.repos$module→ui.types.tags.TagImportItem
- Direction
- ui.IO.repos uses ui.types.tags, so a change to ui.types.tags can break ui.IO.repos, while a change to ui.IO.repos can't break ui.types.tags.
- Position
- Below the diagonal: ui.IO.repos uses a module listed above it, which is the healthy direction.
36→5 ui.components.views.admin.projects.edit_panel.repo_tab uses ui.components.views.admin.projects.context✕
- Connections
- 1 pair of types, where a type in ui.components.views.admin.projects.edit_panel.repo_tab uses a type in ui.components.views.admin.projects.context.
- The types involved
ui.components.views.admin.projects.edit_panel.repo_tab.RepoTabProps→ui.components.views.admin.projects.context.ProjectPanelMode
- Direction
- ui.components.views.admin.projects.edit_panel.repo_tab uses ui.components.views.admin.projects.context, so a change to ui.components.views.admin.projects.context can break ui.components.views.admin.projects.edit_panel.repo_tab, while a change to ui.components.views.admin.projects.edit_panel.repo_tab can't break ui.components.views.admin.projects.context.
- Position
- Below the diagonal: ui.components.views.admin.projects.edit_panel.repo_tab uses a module listed above it, which is the healthy direction.
36→19 ui.components.views.admin.projects.edit_panel.repo_tab uses ui.types.projects✕
- Connections
- 1 pair of types, where a type in ui.components.views.admin.projects.edit_panel.repo_tab uses a type in ui.types.projects.
- The types involved
ui.components.views.admin.projects.edit_panel.repo_tab.RepoTabEditModeProps→ui.types.projects.ProjectDto
- Direction
- ui.components.views.admin.projects.edit_panel.repo_tab uses ui.types.projects, so a change to ui.types.projects can break ui.components.views.admin.projects.edit_panel.repo_tab, while a change to ui.components.views.admin.projects.edit_panel.repo_tab can't break ui.types.projects.
- Position
- Below the diagonal: ui.components.views.admin.projects.edit_panel.repo_tab uses a module listed above it, which is the healthy direction.
36→33 ui.components.views.admin.projects.edit_panel.repo_tab uses ui.types.tags✕
- Connections
- 2 pairs of types, where a type in ui.components.views.admin.projects.edit_panel.repo_tab uses a type in ui.types.tags.
- The types involved
ui.components.views.admin.projects.edit_panel.repo_tab.RepoEditorState→ui.types.tags.TagDtoui.components.views.admin.projects.edit_panel.repo_tab.repo_tab$module→ui.types.tags.TagDto
- Direction
- ui.components.views.admin.projects.edit_panel.repo_tab uses ui.types.tags, so a change to ui.types.tags can break ui.components.views.admin.projects.edit_panel.repo_tab, while a change to ui.components.views.admin.projects.edit_panel.repo_tab can't break ui.types.tags.
- Position
- Below the diagonal: ui.components.views.admin.projects.edit_panel.repo_tab uses a module listed above it, which is the healthy direction.
37→12 ui.types.repos uses domain.project.entity✕
- Connections
- 1 pair of types, where a type in ui.types.repos uses a type in domain.project.entity.
- The types involved
ui.types.repos.RepoDto→domain.project.entity.ProjectStatus
- Direction
- ui.types.repos uses domain.project.entity, so a change to domain.project.entity can break ui.types.repos, while a change to ui.types.repos can't break domain.project.entity.
- Position
- Below the diagonal: ui.types.repos uses a module listed above it, which is the healthy direction.
37→18 ui.types.repos uses domain.repo.entity✕
- Connections
- 2 pairs of types, where a type in ui.types.repos uses a type in domain.repo.entity.
- The types involved
ui.types.repos.RepoDto→domain.repo.entity.Repoui.types.repos.RepoDto→domain.repo.entity.RepoWithTags
- Direction
- ui.types.repos uses domain.repo.entity, so a change to domain.repo.entity can break ui.types.repos, while a change to ui.types.repos can't break domain.repo.entity.
- Position
- Below the diagonal: ui.types.repos uses a module listed above it, which is the healthy direction.
37→22 ui.types.repos uses app.repo.command✕
- Connections
- 1 pair of types, where a type in ui.types.repos uses a type in app.repo.command.
- The types involved
ui.types.repos.BulkUpdateRepoTagResultDto→app.repo.command.BulkUpdateRepoTagResult
- Direction
- ui.types.repos uses app.repo.command, so a change to app.repo.command can break ui.types.repos, while a change to ui.types.repos can't break app.repo.command.
- Position
- Below the diagonal: ui.types.repos uses a module listed above it, which is the healthy direction.
37→23 ui.types.repos uses app.repo.port✕
- Connections
- 1 pair of types, where a type in ui.types.repos uses a type in app.repo.port.
- The types involved
ui.types.repos.RepoReadmeDto→app.repo.port.GithubReadme
- Direction
- ui.types.repos uses app.repo.port, so a change to app.repo.port can break ui.types.repos, while a change to ui.types.repos can't break app.repo.port.
- Position
- Below the diagonal: ui.types.repos uses a module listed above it, which is the healthy direction.
37→33 ui.types.repos uses ui.types.tags✕
- Connections
- 1 pair of types, where a type in ui.types.repos uses a type in ui.types.tags.
- The types involved
ui.types.repos.RepoDto→ui.types.tags.TagDto
- Direction
- ui.types.repos uses ui.types.tags, so a change to ui.types.tags can break ui.types.repos, while a change to ui.types.repos can't break ui.types.tags.
- Position
- Below the diagonal: ui.types.repos uses a module listed above it, which is the healthy direction.
38→9 infra.setup uses app.project.query✕
- Connections
- 1 pair of types, where a type in infra.setup uses a type in app.project.query.
- The types involved
infra.setup.ProjectState→app.project.query.ProjectQueryHandler
- Direction
- infra.setup uses app.project.query, so a change to app.project.query can break infra.setup, while a change to infra.setup can't break app.project.query.
- Position
- Below the diagonal: infra.setup uses a module listed above it, which is the healthy direction.
38→10 infra.setup uses app.repo.query✕
- Connections
- 1 pair of types, where a type in infra.setup uses a type in app.repo.query.
- The types involved
infra.setup.RepoState→app.repo.query.RepoQueryHandler
- Direction
- infra.setup uses app.repo.query, so a change to app.repo.query can break infra.setup, while a change to infra.setup can't break app.repo.query.
- Position
- Below the diagonal: infra.setup uses a module listed above it, which is the healthy direction.
38→11 infra.setup uses app.snapshot.query✕
- Connections
- 1 pair of types, where a type in infra.setup uses a type in app.snapshot.query.
- The types involved
infra.setup.SnapshotState→app.snapshot.query.SnapshotQueryHandler
- Direction
- infra.setup uses app.snapshot.query, so a change to app.snapshot.query can break infra.setup, while a change to infra.setup can't break app.snapshot.query.
- Position
- Below the diagonal: infra.setup uses a module listed above it, which is the healthy direction.
38→22 infra.setup uses app.repo.command✕
- Connections
- 1 pair of types, where a type in infra.setup uses a type in app.repo.command.
- The types involved
infra.setup.RepoState→app.repo.command.RepoCommandHandler
- Direction
- infra.setup uses app.repo.command, so a change to app.repo.command can break infra.setup, while a change to infra.setup can't break app.repo.command.
- Position
- Below the diagonal: infra.setup uses a module listed above it, which is the healthy direction.
38→30 infra.setup uses app.snapshot.command✕
- Connections
- 2 pairs of types, where a type in infra.setup uses a type in app.snapshot.command.
- The types involved
infra.setup.AppContainer→app.snapshot.command.IngestDailySnapshotsinfra.setup.SnapshotState→app.snapshot.command.SnapshotCommandHandler
- Direction
- infra.setup uses app.snapshot.command, so a change to app.snapshot.command can break infra.setup, while a change to infra.setup can't break app.snapshot.command.
- Position
- Below the diagonal: infra.setup uses a module listed above it, which is the healthy direction.
38→34 infra.setup uses app.project.command✕
- Connections
- 1 pair of types, where a type in infra.setup uses a type in app.project.command.
- The types involved
infra.setup.ProjectState→app.project.command.ProjectCommandHandler
- Direction
- infra.setup uses app.project.command, so a change to app.project.command can break infra.setup, while a change to infra.setup can't break app.project.command.
- Position
- Below the diagonal: infra.setup uses a module listed above it, which is the healthy direction.
39→7 ui.components.views.home.rank_panel uses ui.root.routes✕
- Connections
- 1 pair of types, where a type in ui.components.views.home.rank_panel uses a type in ui.root.routes.
- The types involved
ui.components.views.home.rank_panel.rank_panel$module→ui.root.routes.Route
- Direction
- ui.components.views.home.rank_panel uses ui.root.routes, so a change to ui.root.routes can break ui.components.views.home.rank_panel, while a change to ui.components.views.home.rank_panel can't break ui.root.routes.
- Position
- Below the diagonal: ui.components.views.home.rank_panel uses a module listed above it, which is the healthy direction.
39→37 ui.components.views.home.rank_panel uses ui.types.repos✕
- Connections
- 1 pair of types, where a type in ui.components.views.home.rank_panel uses a type in ui.types.repos.
- The types involved
ui.components.views.home.rank_panel.rank_panel$module→ui.types.repos.RepoDto
- Direction
- ui.components.views.home.rank_panel uses ui.types.repos, so a change to ui.types.repos can break ui.components.views.home.rank_panel, while a change to ui.components.views.home.rank_panel can't break ui.types.repos.
- Position
- Below the diagonal: ui.components.views.home.rank_panel uses a module listed above it, which is the healthy direction.
40→7 ui.components.views.repo.list uses ui.root.routes✕
- Connections
- 1 pair of types, where a type in ui.components.views.repo.list uses a type in ui.root.routes.
- The types involved
ui.components.views.repo.list.list$module→ui.root.routes.Route
- Direction
- ui.components.views.repo.list uses ui.root.routes, so a change to ui.root.routes can break ui.components.views.repo.list, while a change to ui.components.views.repo.list can't break ui.root.routes.
- Position
- Below the diagonal: ui.components.views.repo.list uses a module listed above it, which is the healthy direction.
40→23 ui.components.views.repo.list uses app.repo.port✕
- Connections
- 2 pairs of types, where a type in ui.components.views.repo.list uses a type in app.repo.port.
- The types involved
ui.components.views.repo.list.list$module→app.repo.port.RepoRankMetricui.components.views.repo.list.list$module→app.repo.port.RepoRankTimeRange
- Direction
- ui.components.views.repo.list uses app.repo.port, so a change to app.repo.port can break ui.components.views.repo.list, while a change to ui.components.views.repo.list can't break app.repo.port.
- Position
- Below the diagonal: ui.components.views.repo.list uses a module listed above it, which is the healthy direction.
40→37 ui.components.views.repo.list uses ui.types.repos✕
- Connections
- 1 pair of types, where a type in ui.components.views.repo.list uses a type in ui.types.repos.
- The types involved
ui.components.views.repo.list.RepoListCachedPage→ui.types.repos.RepoDto
- Direction
- ui.components.views.repo.list uses ui.types.repos, so a change to ui.types.repos can break ui.components.views.repo.list, while a change to ui.components.views.repo.list can't break ui.types.repos.
- Position
- Below the diagonal: ui.components.views.repo.list uses a module listed above it, which is the healthy direction.
At a glance — Code Health
The Good
D1 · Rust
Cyclomatic Complexity
8.7
D2 · Rust
Cognitive Complexity
8.0
D4 · Rust
Code Duplication
8.7
D17 · Rust
Explicit Debt
10.0
R10 · React / TS
Code Duplication
10.0
R3 · React / TS
Large Files
10.0
X1 · Repo
Async correctness
10.0
X12 · Repo
Unreachable branch
10.0
X13 · Repo
Undrained process stream
10.0
X16 · Repo
Unfloored truncation loop
10.0
X18 · Repo
Disposal-pattern correctness
10.0
X19 · Repo
Unrestored process-global state
10.0
X21 · Repo
Side-effecting pattern guard
10.0
X22 · Repo
Contradicted release guard
10.0
X23 · Repo
Unguarded diagnostic materialisation
10.0
X25 · Repo
Inert configuration knob
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 Bad
The Ugly
At a glance — Architecture
The Good
D5 · Rust
Coupling
8.7
D6 · Rust
Cohesion (LCOM4)
10.0
D22 · Rust
Internal API Consistency
7.0
D35 · Rust
Change Coupling
9.7
AX10 · Repo
Code composition
8.7
AX3 · Repo
Project dependency cycles
10.0
AX4 · Repo
Dependency direction
10.0
AX9 · Repo
CQS / query purity
9.8
R9 · React / TS
Circular Imports
10.0
The Bad
At a glance — Maturity
The Good
The Ugly
At a glance — Readiness
The Good
The Ugly
At a glance — Security
The Good
D28 · Rust
Secrets (history)
10.0
D29 · Rust
Static Analysis (SAST)
10.0
D31 · Rust
IaC & Container Security
7.6
D43 · Rust
Malicious Dependencies
10.0
X14 · Repo
Bypassable address classification
10.0
X15 · Repo
Unvalidated length from an untrusted reader
10.0
X17 · Repo
Uncapped recursion over a caller-supplied document
10.0
X24 · Repo
Document value interpolated into markup unescaped
10.0
At a glance — Domain Modelling
The Good
At a glance — Event-Driven
The Good
At a glance — Performance
Security & Compliance — OWASP Top-10 mapping
| OWASP category | Findings | Severity |
|---|---|---|
| A03:2025 — Software Supply Chain Failures | 16 | High / Critical |
| A02:2025 — Security Misconfiguration | 10 | High / Critical |
| A05:2025 — Injection | 9 | High / Critical |
Roadmap
First, resolve the single gaps in automated code coverage and test distribution to ensure existing logic is properly validated. Next, implement encryption for sensitive data at rest and manage keys securely in a vault to strengthen data protection. Finally, introduce TypeScript to the frontend by adding a typecheck step and typing the highest-traffic modules to improve code safety and maintainability.
| Do this | Helps | Effort | Dimension |
|---|---|---|---|
| Resolve the 1 No automated tests finding(s) in Code Coverage. | +8.8 pts | Low | Code Coverage |
| Resolve the 1 No tests found finding(s) in Test Distribution. | +8.8 pts | Low | Test Distribution |
| Encrypt sensitive data at rest (encrypt the fields with aes-gcm or chacha20poly1305 before they are written, or open the store encrypted — SQLCipher for rusqlite/sqlx, MongoDB CSFLE) and manage keys in a vault (AWS KMS / Secrets Manager through aws-sdk-kms, GCP KMS / Secret Manager, Azure Key Vault, HashiCorp Vault through vaultrs). Skip if delegated to infra (Postgres TDE, KMS, etc.). | +3.9 pts | Medium | Data Protection |
| Add tests that import the unreached modules (directly or through their public entry). | +3.4 pts | Medium | Test Coverage |
| Resolve the 1 No ADRs found finding(s) in ADR Quality. | +1.5 pts | Low | ADR Quality |
| Adopt TypeScript for the frontend: add a typecheck step to the build, then either type-check the existing JavaScript in place (`checkJs`/JSDoc types) or convert the highest-traffic modules first — no file is typed today, so this is an adoption, not a clean-up. | +2.6 pts | Medium | Type Safety |
| Break down the listed branch-heavy functions; aim P95 cyclomatic ≤ 5. | +2.6 pts | Medium | Cyclomatic Complexity |
| Swallowed exception (empty catch) | +2.0 pts | Medium | Exception handling |
File quality
| File | Score | Band | Worst signal |
|---|---|---|---|
| REDACTED | 0.9 | Slop | Dependency Vulnerabilities: High CVE: REDACTED |
| REDACTED | 2.0 | Slop | IaC & Container Security: High IaC: REDACTED |
| REDACTED | 2.7 | Slop | IaC & Container Security: High IaC: REDACTED |
| REDACTED | 4.4 | Mixed | Static Analysis (SAST): High: REDACTED |
| crates/ui/src/root/layouts/admin_layout.rs | 7.0 | Mixed | God Classes: FunctionTooLong: ui::root::layouts::admin_layout::AdminLayout |
| crates/ui/src/components/views/repo/list/mod.rs | 7.0 | Mixed | Code Duplication: Duplicated block (13 lines × 2) |
| crates/ui/src/components/layout/user/fuzzy_search/mod.rs | 7.0 | Mixed | Cyclomatic Complexity: ui::components::layout::user::fuzzy_search::FuzzySearch (cyclomatic 28) |
| crates/app/src/project/command.rs | 7.0 | Mixed | Cyclomatic Complexity: ProjectCommandHandler::import_projects (cyclomatic 19) |
| crates/adapters/src/persistence/psql/project_repo.rs | 7.0 | Mixed | Code Duplication: Members sharing a duplicated core (9 members, 50+ identical tokens) |
| crates/adapters/src/persistence/psql/repo_repo.rs | 7.1 | Mixed | Cyclomatic Complexity: PostgresRepoRepo::list_ranked (cyclomatic 16) |
| crates/ui/src/components/views/admin/projects/project_table/mod.rs | 7.1 | Mixed | Cognitive Complexity: ui::components::views::admin::projects::project_table::ProjectTable (cognitive 16) |
| crates/adapters/src/persistence/psql/repo_tag_repo.rs | 7.1 | Mixed | God Classes: ClassTooLong: PostgresRepoTagRepo |
| REDACTED | 7.2 | Mixed | IaC & Container Security: High IaC: REDACTED |
| crates/ui/src/js/dom_bridge.js | 7.4 | Mixed | Cyclomatic Complexity: dom_bridge.rewrite_markdown_links (cyclomatic 19) |
| crates/app/src/repo/query.rs | 7.4 | Mixed | Cyclomatic Complexity: RepoQueryHandler::list_with_tags (cyclomatic 17) |
| crates/ui/src/components/views/admin/projects/edit_panel/project_tab/mod.rs | 7.4 | Mixed | God Classes: FunctionTooLong: ui::components::views::admin::projects::edit_panel::project_tab::ProjectTab |
| crates/ui/src/components/views/admin/tags/edit_panel/group_tab/mod.rs | 7.4 | Mixed | God Classes: FunctionTooLong: ui::components::views::admin::tags::edit_panel::group_tab::GroupTab |
| crates/ui/src/components/views/repo/list/repo_list_handler.rs | 7.4 | Mixed | God Classes: FunctionTooLong: ui::components::views::repo::list::repo_list_handler::RepoListHandler |
| crates/ui/src/IO/projects.rs | 7.4 | Mixed | Code Duplication: Duplicated block (21 lines × 2) |
| crates/ui/src/components/layout/user/gearmap/mod.rs | 7.8 | Mixed | Cyclomatic Complexity: ui::components::layout::user::gearmap::generate_gears (cyclomatic 21) |
How the grades work
Critical — 24
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 — 143
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 — 26
Recorded, with no effect on how the codebase functions. Present so the survey is complete, not because it needs doing.
Could not be resolved — 11
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. 71 of 75 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 — 75 dimensions across the health lenses
D1D2D3D4D5D6D8D9D12D13D14D15D17D20D21D22D26D28D29D30D31D34D35D43AX10AX3AX4AX9C1C2DM4DM5DM6ED4M1M2M3M4P1P10P2P3P4P5P6P7P8PF3R1R10R2R3R4R9S1X1X12X13X14X15X16X17X18X19X21X22X23X24X25X27X28X29X3X30X4
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, 163 of 193 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
- 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-maintainer repository — bus factor is not applicable (2 contributor(s) across 154 commit(s) sampled, automation and bot accounts excluded). One of them holds 98% of the history; the other 1 hold 2% each on average, below the 5% at which there is somebody to hand the work to. That is a single maintainer with drive-by contributors, not a team whose knowledge has concentrated — so the bus factor is not applicable and there is nothing here for the owner to act on.
- D19 Documentation Quality — LLM provider failed — The model provider returned an unusable result, so this LLM-assisted dimension fell back to a measurement gap (confidence 0) rather than a penalty. Re-run with a reachable provider to score it.
- 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 DockerCompose (REDACTED). compose up failed (exit 18 — an image could not be pulled) — web Pulling web Error Get "https://registry-1.docker.io/v2/": Forbidden Error response from daemon: Get "https://registry-1.docker.io/v2/": Forbidden; the earlier `compose pull` step reported: web Pulling web Error Get "https://registry-1.docker.io/v2/": Forbidden Error response from daemon: Get "https://registry-1.docker.io/v2/": Forbidden; the runtime sandbox reaches registries only through the in-fence pull-through mirror, so an image the mirror does not carry cannot be fetched — this is a limit of our sandbox, not of your stack; 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 this repository's Rust is most of its product and 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 this repository's Rust is most of its product and 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.
- P1 CI/CD gates — measured, with a gap in what it reached — Watchdog measured this, but not all of it. What it did not reach is a gap on our side — a collector, parser or image we have not built yet — so the numbers on that dimension cover less than the repository, and the part left out is not evidence that it would have passed. A CI pipeline exists and the word "test" appears, but no explicit test-runner invocation (your stack's test command, or a test job) was matched — so either the gate runs tests through a step this pass could not recognise, or "test" is incidental here (a path, "latest", a reporter). Which of the two it is cannot be settled from this dimension's evidence; the coverage dimensions report whether a suite exists at all. You can widen what we reach: name the test runner explicitly in the pipeline step (your stack's test command, or a job named for the suite) so the gate is unambiguous to a reader and to this pass.
- 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.
- D8 Code Coverage: Coverage is measured by building and running the test suite inside Watchdog's isolated image — the target repo is never modified, and nothing on your systems runs. So coverage exists only when the suite builds and runs within the inline time budget; one that needs external services, can't build, or exceeds the budget yields no coverage (D8 then degrades to not-measured, not a low score). Line coverage also says nothing about assertion quality.
- 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.
- D20 ADR Quality: ADR quality is an LLM read of the decision records present — it cannot know about decisions made and never recorded, and its verdict is sampled and advisory.
- D21 Naming Consistency: Naming quality is an LLM judgement over a bounded sample — it assesses clarity/consistency of the names it sees, not domain-correctness, and is advisory.
- 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
8 method(s) exceeded the cyclomatic complexity threshold of 15; the worst was ui::components::layout::user::fuzzy_search::FuzzySearch at 28.
ui::components::layout::user::fuzzy_search::FuzzySearch (cyclomatic 28) crates/ui/src/components/layout/user/fuzzy_search/mod.rs:469
ProjectCommandHandler::import_projects (cyclomatic 19)crates/app/src/project/command.rs:94
dom_bridge.rewrite_markdown_links (cyclomatic 19)crates/ui/src/js/dom_bridge.js:109
RepoQueryHandler::list_with_tags (cyclomatic 17)crates/app/src/repo/query.rs:166
upsert_chart (cyclomatic 17)crates/ui/src/js/chart_bridge.js:60
What to do
- Bring the 8 bodies over 15 down to 15 or less in Cyclomatic Complexity — start with ui::components::layout::user::fuzzy_search::FuzzySearch (cyclomatic 28), ui::components::layout::user::gearmap::generate_gears (cyclomatic 21), ProjectCommandHandler::import_projects (cyclomatic 19). — This score is capped by its worst body, so a finding fixed alone moves it by almost nothing — the next one down takes its place. Refactoring these 8 together lifts Cyclomatic Complexity from 8.7 to about 10.0/10, projected with the scoring formula itself and assuming each lands exactly at 15.
- Enforce Cyclomatic Complexity in CI to reach Verified (currently Documented). — Hardens enforcement from Documented toward Prevented — provenance only; does not change the score.
Do you agree with this assessment?
D2 · Cognitive Complexity
11 method(s) exceeded the cognitive complexity threshold of 15; the worst was ProjectCommandHandler::import_projects at 44.
ui::components::layout::user::fuzzy_search::FuzzySearch (cognitive 38) crates/ui/src/components/layout/user/fuzzy_search/mod.rs:469
ProjectCommandHandler::import_projects (cognitive 44)crates/app/src/project/command.rs:94
RepoQueryHandler::list_with_tags (cognitive 41)crates/app/src/repo/query.rs:166
dom_bridge.rewrite_markdown_links (cognitive 33)crates/ui/src/js/dom_bridge.js:109
mount_fuzzy_search_hotkey (cognitive 18)crates/ui/src/js/dom_bridge.js:66
What to do
- Bring the 11 bodies over 15 down to 15 or less in Cognitive Complexity — start with ProjectCommandHandler::import_projects (cognitive 44), RepoQueryHandler::list_with_tags (cognitive 41), ui::components::layout::user::fuzzy_search::FuzzySearch (cognitive 38). — This score is capped by its worst body, so a finding fixed alone moves it by almost nothing — the next one down takes its place. Refactoring these 11 together lifts Cognitive Complexity from 8.0 to about 10.0/10, projected with the scoring formula itself and assuming each lands exactly at 15.
- Enforce Cognitive Complexity in CI to reach Verified (currently Documented). — Hardens enforcement from Documented toward Prevented — provenance only; does not change the score.
Do you agree with this assessment?
D3 · God Classes
21 god class(es) detected.
FunctionTooLong: ui::components::views::admin::projects::edit_panel::project_tab::ProjectTab crates/ui/src/components/views/admin/projects/edit_panel/project_tab/mod.rs:143
FileTooLong: icons/mod.rs crates/ui/src/components/icons/mod.rs
MethodTooLong: ProjectCommandHandler.import_projects crates/app/src/project/command.rs:94
ClassTooLong: PostgresRepoTagRepo crates/adapters/src/persistence/psql/repo_tag_repo.rs:51
What to do
- Resolve the 12 FunctionTooLong finding(s) in God Classes — start with mod.rs (9), repo_list_handler.rs, admin_layout.rs. — One of this dimension's main actionable groups (12 warning-level).
- Resolve the 4 FileTooLong finding(s) in God Classes — start with mod.rs (2), component.rs, repo_tag_repo.rs. — One of this dimension's main actionable groups (4 warning-level).
- Resolve the 3 MethodTooLong finding(s) in God Classes — start with command.rs (2), repo_repo.rs. — One of this dimension's main actionable groups (3 warning-level).
- Enforce God Classes in CI to reach Verified (currently Documented). — Hardens enforcement from Documented toward Prevented — provenance only; does not change the score.
Do you agree with this assessment?
D4 · Code Duplication
60 duplicated block group(s) detected. One further row reports members as variants of one another; it aggregates block groups already counted above and is not itself counted.
Duplicated block (11 lines × 2) crates/adapters/src/github.rs:123
Duplicated block (9 lines × 2) crates/adapters/src/persistence/psql/repo_tag_repo.rs:294
Duplicated block (7 lines × 2) crates/adapters/src/persistence/psql/project_repo.rs:89
Duplicated block (12 lines × 2) crates/ui/src/components/layout/user/fuzzy_search/mod.rs:583
Duplicated block (16 lines × 2) crates/ui/src/components/layout/user/fuzzy_search/mod.rs:200
What to do
- Resolve the 8 Duplicated block (11 lines × 2) finding(s) in Code Duplication — start with mod.rs (6), github.rs, command.rs. — One of this dimension's main actionable groups (8 warning-level).
- Resolve the 6 Duplicated block (9 lines × 2) finding(s) in Code Duplication — start with mod.rs (2), repo_tag_repo.rs, language_switcher.rs. — One of this dimension's main actionable groups (6 warning-level).
- Resolve the 5 Duplicated block (7 lines × 2) finding(s) in Code Duplication — start with project_repo.rs (2), component.rs, command.rs. — One of this dimension's main actionable groups (5 warning-level).
- Enforce Code Duplication in CI to reach Verified (currently Documented). — Hardens enforcement from Documented toward Verified — provenance only; does not change the score.
Do you agree with this assessment?
D5 · Coupling
6 production modules (Cargo), 0 dependency cycle(s), 0 unstable depended-on module(s). Read from the build's own module declarations; 1 module(s) off the main sequence, with abstractness counted on 5 of the 6 (the rest declare no modelled class or interface, export only macros, declare types in source no model reads, or have no source directory of their own).
Off the main sequence: domain
What to do
- Resolve the 1 Off the main sequence finding(s) in Coupling. — One of this dimension's main actionable groups (1 warning-level).
- Enforce Coupling in CI to reach Verified (currently Documented). — Hardens enforcement from Documented toward Prevented — provenance only; does not change the score.
Do you agree with this assessment?
D6 · Cohesion (LCOM4)
0 of 27 classes have LCOM4 above 3.
Do you agree with this assessment?
D8 · Code Coverage
No automated tests — no test code was found in this repository.
No automated tests
What to do
- Resolve the 1 No automated tests finding(s) in Code Coverage. — One of this dimension's main actionable groups (1 issue-level).
- Enforce Code Coverage in CI to reach Verified (currently Documented). — Hardens enforcement from Documented toward Verified — provenance only; does not change the score.
Do you agree with this assessment?
D9 · Test Distribution
No test suite found.
No tests found
What to do
- Resolve the 1 No tests found finding(s) in Test Distribution. — One of this dimension's main actionable groups (1 recommendation-level).
Do you agree with this assessment?
D12 · Dependency Hygiene
11 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: anyhow
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 619 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. A further 5 crate(s) in the closure resolve from git, a path or a private registry and publish no licence this pass can read; they are outside this verdict.
Do you agree with this assessment?
D15 · Churn × Complexity Hotspots
Top hotspots: crates/adapters/src/persistence/psql/repo_repo.rs (14×16=224); crates/app/src/repo/query.rs (13×17=221); crates/app/src/project/command.rs (8×19=152)
Hotspot: crates/adapters/src/persistence/psql/repo_repo.rs crates/adapters/src/persistence/psql/repo_repo.rs:370
What to do
- Resolve the 7 Hotspot finding(s) in Churn × Complexity Hotspots — start with mod.rs (2), repo_repo.rs, query.rs. — One of this dimension's main actionable groups (7 warning-level).
Do you agree with this assessment?
D17 · Explicit Debt
0 deducted task-comment markers across 20720 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?
D20 · ADR Quality
No architecture decision records were found.
No ADRs found
What to do
- Resolve the 1 No ADRs found finding(s) in ADR Quality. — One of this dimension's main actionable groups (1 recommendation-level).
Do you agree with this assessment?
D21 · Naming Consistency
0 naming inconsistencies across 0 sampled symbols.
Do you agree with this assessment?
D22 · Internal API Consistency
3 API inconsistencies across a 400-member sample of 191 exposed types.
Inconsistent naming for bulk operations: 'upsert_many' vs 'update_many'. While 'upsert' is used for single items, the bulk variant for Projects uses 'update_many' in the port, whereas Repos use 'upsert_many'. This implies different semantics (insert-or-update vs update-only) or is a naming inconsistency.
Redundant methods for replacing tags: 'replace_tags' and 'replace_tags_by_repo_id' in RepoCommandHandler perform the same logical operation (replacing tags for a repo). One takes arguments directly, the other a command object. This creates confusion about which to use.
Ambiguous naming: 'search_by_key' vs 'search_repo_page_by_key'. It is unclear if 'search_by_key' is a general search that might include tags, or if it is an alias for 'search_repo_page_by_key'. The existence of 'search_tag_page_by_key' suggests 'search_by_key' might be a composite or ambiguous method.
What to do
- Resolve the 1 Inconsistent naming for bulk operations finding(s) in Internal API Consistency. — One of this dimension's main actionable groups (1 warning-level).
- Resolve the 1 Redundant methods for replacing tags finding(s) in Internal API Consistency. — One of this dimension's main actionable groups (1 warning-level).
- Resolve the 1 Ambiguous naming 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
1 of 6 build units (Cargo) flagged as possibly oversized/incoherent.
Split crates/ui
What to do
- Resolve the 1 Split crates/ui finding(s) in Project Cohesion. — One of this dimension's main actionable groups (1 recommendation-level).
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)
9 finding(s): 0 critical, 9 high, 0 medium, 0 low. 9 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. semgrep hit a parse error in 1 file(s) — `.github/ISSUE_TEMPLATE/recommend_repo.yaml` — so no absence of findings in them is evidence of anything, and nothing in them was analysed. Fix the syntax error (or exclude the file deliberately) and re-scan to cover them.
REDACTED
What to do
- No action in Static Analysis (SAST) — all 9 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 (9 issue-level, 0 of them charged here).
Do you agree with this assessment?
D30 · Dependency Vulnerabilities
16 finding(s): 0 critical, 2 high, 13 medium, 1 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 5 Medium advisory (unsound) finding(s) in Dependency Vulnerabilities — start with REDACTED (5). — One of this dimension's main actionable groups (5 warning-level).
- Resolve the 3 Medium advisory (unmaintained) finding(s) in Dependency Vulnerabilities — start with REDACTED (3). — One of this dimension's main actionable groups (3 warning-level).
Do you agree with this assessment?
D31 · IaC & Container Security
10 finding(s): 0 critical, 6 high, 4 medium, 0 low.
REDACTED
REDACTED
What to do
- Resolve the 6 High IaC finding(s) in IaC & Container Security — start with REDACTED (3), REDACTED (2), REDACTED. — One of this dimension's main actionable groups (6 issue-level).
- Resolve the 4 Medium IaC finding(s) in IaC & Container Security — start with REDACTED (2), REDACTED (2). — One of this dimension's main actionable groups (4 warning-level).
Do you agree with this assessment?
D34 · Knowledge Freshness
Every significant source file has living knowledge — recently and meaningfully worked. Counted over 88 of the 269 production source files in this repository: the rest are under the ~2,400-byte size floor this dimension measures over.
Do you agree with this assessment?
D35 · Change Coupling
Strongest change-coupling: footer.rs↔mod.rs 50%; mod.rs↔mod.rs 50%; mod.rs↔mod.rs 50%
Change coupling: footer.rs ↔ mod.rs crates/ui/src/components/layout/user/footer.rs:1
What to do
- Resolve the 4 Change coupling finding(s) in Change Coupling — start with mod.rs (2), footer.rs, admin_layout.rs. — One of this dimension's main actionable groups (4 warning-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, but most of the rest matched no layer vocabulary at all — so this is not yet an anemic-domain finding. The namespace/path convention could not place that code, which makes the composition above a statement about the naming, not about the design. Name the layers (or check that the repository's conventions differ from the ones this check knows) before reading a thin domain into it.
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
- `PostgresRepoTagRepo.list_tags_with_meta` is a read-named query yet it performs a durable write on the read path (a persist to a store/repository). A query must stay side-effect-free so reads are safe to retry, cache, and route to a read replica; move the write into a command. — crates/adapters/src/persistence/psql/repo_tag_repo.rs:385
- `PostgresRepoTagRepo.list_tags_with_meta_by_values` is a read-named query yet it performs a durable write on the read path (a persist to a store/repository). A query must stay side-effect-free so reads are safe to retry, cache, and route to a read replica; move the write into a command. — crates/adapters/src/persistence/psql/repo_tag_repo.rs:476
- `RepoQueryHandler.list_with_tags` is a read-named query yet it performs a durable write on the read path (a persist to a store/repository). A query must stay side-effect-free so reads are safe to retry, cache, and route to a read replica; move the write into a command. — crates/app/src/repo/query.rs:166
- `RepoQueryHandler.list_ranked_with_tags` is a read-named query yet it performs a durable write on the read path (a persist to a store/repository). A query must stay side-effect-free so reads are safe to retry, cache, and route to a read replica; move the write into a command. — crates/app/src/repo/query.rs:293
- `RepoQueryHandler.list_by_label_with_tags` is a read-named query yet it performs a durable write on the read path (a persist to a store/repository). A query must stay side-effect-free so reads are safe to retry, cache, and route to a read replica; move the write into a command. — crates/app/src/repo/query.rs:315
What to do
- Keep query handlers read-only — move the writes/event-publishes into a command handler so reads stay safe to retry, cache, and route to a read replica.
Do you agree with this assessment?
C1 · Data Protection
- No encryption usage (RustCrypto's aes-gcm/chacha20poly1305 encrypting, ring or aws-lc-rs aead sealing, orion, libsodium's secretbox, openssl symm, age, SQLCipher keyed by PRAGMA key, pgcrypto, MongoDB client-side field-level encryption, the OS keyring) was found, and this repository persists personal data in the model cited here — sensitive data at rest may be unprotected. If TDE/KMS/vault is delegated to infrastructure, ignore. — crates/adapters/migrations/0001_init.sql:23
What to do
- Encrypt sensitive data at rest (encrypt the fields with aes-gcm or chacha20poly1305 before they are written, or open the store encrypted — SQLCipher for rusqlite/sqlx, MongoDB CSFLE) and manage keys in a vault (AWS KMS / Secrets Manager through aws-sdk-kms, GCP KMS / Secret Manager, Azure Key Vault, HashiCorp Vault through vaultrs). Skip if delegated to infra (Postgres TDE, KMS, etc.).
- Enforce HTTPS on the server that receives this data: terminate TLS in it (axum-server/actix bind_rustls, tonic ServerTlsConfig, a tokio-rustls acceptor) and send Strict-Transport-Security, or run it behind a TLS-terminating proxy, so data in transit is always encrypted.
Do you agree with this assessment?
C2 · Access Controls
- Only 1 place(s) refuse an unauthorized caller — too few to demonstrate default-deny across handlers.
What to do
- Enforce authorization at every handler — a guard on each route, or a global authentication guard/middleware with explicit public opt-outs, so protected-by-default is demonstrable.
Do you agree with this assessment?
DM4 · Rich vs anemic domain model
Do you agree with this assessment?
DM5 · Encapsulated state
Do you agree with this assessment?
DM6 · Domain ↔ infrastructure boundary
Do you agree with this assessment?
ED4 · Outbox / dual-write
- `RepoQueryHandler.list_with_tags` performs two independent DURABLE writes — a durable state write (`current_repo_ids.insert`, :229) and a second independent durable store write — in one command path with no shared transaction or outbox. A crash between the two leaves the stores diverged (one write committed, the other lost) or emits a phantom record. Wrap both in one transaction, or record the second write in the same store and dispatch it afterwards (a transactional outbox). — crates/app/src/repo/query.rs:166
What to do
- Adopt the transactional outbox pattern so DB writes and message publishes commit atomically — no lost or phantom events on a crash.
Do you agree with this assessment?
M1 · Documentation (README)
What to do
- Add a build/run (quick start) section to the root README — the first thing a newcomer needs.
- 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 6 of 6 project(s) that lack one — worth up to 2 pts.
Do you agree with this assessment?
M2 · Architecture documentation
- No Architecture Decision Records found — no conventional ADR directory, no 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
What to do
- Add `#[cfg(test)] mod tests` blocks beside the code they cover — the attribute keeps them out of the release build, a stronger separation than a folder — reserve `tests/` for black-box integration tests, and run `cargo test` in CI.
Do you agree with this assessment?
M4 · Documentation accuracy
- docs/contribute/contribute_zh-CN.md names `development.toml`, but no file or folder `development.toml` 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. — docs/contribute/contribute_zh-CN.md:24
What to do
- Reconcile the README with reality: docs/contribute/contribute_zh-CN.md names `development.toml`, but no file or folder `development.toml` exists.
Do you agree with this assessment?
P1 · CI/CD gates
- A CI pipeline exists but no build step was matched — changes may merge without the build ever running. A build step may be invoked directly as a command, or declared as a task that a runner named in the pipeline resolves.
What to do
- Run the test suite in CI via an explicit runner step (`cargo test` for the toolchain this pipeline already uses) and gate merges on it.
- Add an explicit build step to your CI pipeline — your stack's own build command, or, if the pipeline delegates to a task runner, a build task that runner executes in CI — so every change is built before merge.
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
- Enable Dependabot/Renovate or a dependency-review gate.
- Add gitleaks/trufflehog in CI to block PRs that introduce committed secrets.
Do you agree with this assessment?
P4 · Deployment & Rollback
- Deployment is orchestrated by compose, but no service declares a `healthcheck:` and nothing pins a previous image to fall back to — the runtime can tell that the container is up, not that it is serving, so a bad release is harder to detect and reverse.
What to do
- Add a `healthcheck:` to the served compose service — probing the endpoint it already answers on where it has one — with `depends_on: condition: service_healthy` on whatever waits for it, and keep the deployed image tag immutable and recorded so rolling back is re-pointing at the previous tag rather than rebuilding.
- Add an approval/environment gate (required reviewers / protection rules) before production promotion.
Do you agree with this assessment?
P5 · DR & Backup
What to do
- Document RTO/RPO and a tested restore procedure (a backup config alone isn't disaster recovery).
- Enable purge protection / soft-delete (and prevent_destroy on critical resources) so data stores can't be lost to an accidental or malicious delete.
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?
P7 · Outbound HTTP resilience
- `reqwest::Client::builder(` makes an outbound HTTP call, and nothing bounds it: no timeout, deadline, retry or circuit breaker is set for it here, and the client has no process-wide default. A slow or failing dependency will hold this service's request, thread or connection until the call gives up on its own — or never, for a client with no default timeout. (×2) — crates/adapters/src/auth/github_oauth.rs:49, crates/adapters/src/github.rs:18
What to do
- Give every client a whole-request bound: `reqwest::Client::builder().timeout(Duration::from_secs(10))` (never `reqwest::get` or `Client::new()`, which have none), ureq's `timeout_global`, or wrap the call in `tokio::time::timeout`; add retry with back-off (`reqwest-retry`'s `RetryTransientMiddleware`, `backoff`) around dependencies that fail.
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?
R1 · Type Safety
- 0 typed · 5 plain JS — the untyped files are crates/ui/src/js/chart_bridge.js, crates/ui/src/js/dom_bridge.js, crates/ui/src/js/scroll_progress.js, crates/ui/src/js/scroll_to_top.js, crates/ui/src/js/theme_bridge.js.
What to do
- Adopt TypeScript for the frontend: add a typecheck step to the build, then either type-check the existing JavaScript in place (`checkJs`/JSDoc types) or convert the highest-traffic modules first — no file is typed today, so this is an adoption, not a clean-up.
Do you agree with this assessment?
R10 · Code Duplication
Do you agree with this assessment?
R2 · Cyclomatic Complexity
- rewrite_markdown_links has cyclomatic complexity 19 and cognitive complexity 33; this row is raised above a cyclomatic bar of 10. The two numbers answer different questions and the gap between them is what decides whether to act: cyclomatic counts the independent arms through the body, cognitive counts what it costs to hold them in your head, so nesting and mixed boolean chains raise it while a flat run of independent arms does not. Cognitive is at or above cyclomatic here, so the branching is nested or entangled rather than laid out side by side — extracting each decision into its own named function is the change that pays. Measured by this repository's own parse of the file, so a body assembled at runtime, or generated, is counted as written rather than as it executes. — crates/ui/src/js/dom_bridge.js:109
- upsert_chart has cyclomatic complexity 17 and cognitive complexity 16; this row is raised above a cyclomatic bar of 10. The two numbers answer different questions and the gap between them is what decides whether to act: cyclomatic counts the independent arms through the body, cognitive counts what it costs to hold them in your head, so nesting and mixed boolean chains raise it while a flat run of independent arms does not. Cognitive sits below cyclomatic here, so much of the count is breadth — arms side by side rather than stacked — and splitting per arm would leave a function per arm; group the work between the checks into named steps instead. Measured by this repository's own parse of the file, so a body assembled at runtime, or generated, is counted as written rather than as it executes. — crates/ui/src/js/chart_bridge.js:60
What to do
- Break down the listed branch-heavy functions; aim P95 cyclomatic ≤ 5.
Do you agree with this assessment?
R3 · Large Files
Do you agree with this assessment?
R4 · Test Coverage
- 0% of 5 production file(s) reachable from 0 test file(s) via the import graph — 'production' here is the RESIDUE: every source file left once tests, tooling, generated output, config, declarations and declaration-only modules, fixture corpora, type fixtures, behaviour-free data modules, re-export barrels, registration/constant data modules and service workers are set aside, so the percentage is taken over a smaller denominator than the workspace's file count
What to do
- Add tests that import the unreached modules (directly or through their public entry).
Do you agree with this assessment?
R9 · Circular Imports
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: `axum::serve(` (crates/ui/src/main.rs:53).
- 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: `axum::serve(` (crates/ui/src/main.rs:53).
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?
X12 · Unreachable branch
Do you agree with this assessment?
X13 · Undrained process stream
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?
X16 · Unfloored truncation loop
Do you agree with this assessment?
X17 · Uncapped recursion over a caller-supplied document
Do you agree with this assessment?
X18 · Disposal-pattern correctness
Do you agree with this assessment?
X19 · Unrestored process-global state
Do you agree with this assessment?
X21 · Side-effecting pattern guard
Do you agree with this assessment?
X22 · Contradicted release guard
Do you agree with this assessment?
X23 · Unguarded diagnostic materialisation
Do you agree with this assessment?
X24 · Document value interpolated into markup unescaped
Do you agree with this assessment?
X25 · Inert configuration knob
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?
X3 · Exception handling
- An empty catch block silently discards the error — failures vanish with no log and no rethrow. Log it, handle it, or don't catch it. (×3) — crates/ui/src/js/dom_bridge.js:126, crates/ui/src/js/dom_bridge.js:139, crates/ui/src/js/chart_bridge.js:36
What to do
- Swallowed exception (empty catch)
Do you agree with this assessment?
X30 · Support guard that admits what it rejects
Do you agree with this assessment?
X4 · Structured logging
- `warn!` at line 17 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: `warn!(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`. — crates/worker/src/main.rs:17
What to do
- Interpolated log message defeats structured logging
Do you agree with this assessment?
Reference — by lens
| Lens | Score | Rating | Impact |
|---|---|---|---|
| Code Health | 32% | Weak — gated by R1, R2, X3, X4 | Capped at Fair by a Critical contributor — resolve it before relying on this lens. |
| Architecture | 92% | Exemplary | Solid. |
| Maturity | 69% | Adequate | Acceptable, with room to improve. |
| Readiness | 27% | Weak — gated by D8, D9, R4, P7 | Capped at Fair by a Critical contributor — resolve it before relying on this lens. |
| Security | 39% | Weak — gated by C1 | Capped at Fair by a Critical contributor — resolve it before relying on this lens. |
| Domain Modelling | 100% | Exemplary | Strongest area. |
| Event-Driven | 80% | Strong | Solid. |
| Performance | 100% | Exemplary | Solid. |
Unscored — 2 check(s) recorded observations but carry no score
- D36 Supply-chain Provenance & Signing — 1 observation(s) recorded · The CI pipeline builds and tests but publishes no released artifact — no package publish, container push, GitHub release or deployment step. Supply-chain provenance, signing and SBOM attest RELEASED artifacts, so there is nothing to attest here. Add them to the release pipeline when this repo starts shipping artifacts (a published package, a container image, a deployed service or a tagged release). Build integrity and workflow-token hygiene are reported below: they describe what the CI runs and the token it runs with, neither of which is affected by whether the pipeline ships an artifact.
- X10 Duplicated predicate — 1 observation(s) recorded · Advisory — this card reports evidence and never carries a score.
Not evidenced — 3 control(s) we could not find positive evidence for
- C3 Audit Trail — Repo shows no audit-logging mechanism (an audit-log table or model — a struct, Diesel table, SeaORM entity or SQL migration table named for it — a SeaORM ActiveModelBehavior hook or database trigger that records each change, or an event-sourced store beside one) for sensitive changes — absence of evidence is not evidence of a working control. Record an audit trail in code (or document where it lives) so this dimension can be scored.
- C4 Data Retention — Repo shows no data-retention / TTL / cleanup mechanism for personal data — absence of evidence is not evidence of a working control. Define retention periods and a purge/cleanup job (or TTL) in code, or document where retention is enforced, so this dimension can be scored.
- C5 Data-Subject Rights — Repo shows no corroborated data-subject-rights mechanism (erasure / export-portability / consent) tied to a subject id or GDPR vocabulary — absence of evidence is not evidence of a working control. Implement erasure, data export/portability and consent tracking over the subject's records.
Not included — 58 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: this repository's JavaScript imports no dependency-injection container and defines no container of its own — nothing that both registers and resolves bindings, and nothing that names two lifetimes — so nothing holds one lifetime's instance while handing out another's; 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. TypeScript/JavaScript runs each process's requests on one event loop, so no two requests write a shared object at the same instant (interleaving across an await is a different defect).
- 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 — compose up failed (exit 18 — an image could not be pulled) — web Pulling web Error Get "https://registry-1.docker.io/v2/": Forbidden Error response from daemon: Get "https://registry-1.docker.io/v2/": Forbidden; the earlier `compose pull` step reported: web Pulling web Error Get "https://registry-1.docker.io/v2/": Forbidden Error response from daemon: Get "https://registry-1.docker.io/v2/": Forbidden; the runtime sandbox reaches registries only through the in-fence pull-through mirror, so an image the mirror does not carry cannot be fetched — this is a limit of our sandbox, not of your stack; 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.
- D10 Test Quality — No tests were found in the analyzed repository to assess for quality.
- D11 Test Reliability — No test suite was found to re-run, so reliability couldn't be assessed. Two searches produced that zero and both came back empty: the classifier that reads the loaded workspace recognised no suite it could run, and a walk of the source on disk — which covers the JS/TS `*.test.*` and `*.spec.*` conventions and probes for a Pester suite — found no test source in any other ecosystem either. Neither search reaches a suite that is missing from the loaded workspace and carries no name either walk recognises, so this is 'no suite found by those two searches', not a verdict that the repository has none.
- D16 Bus Factor — single-maintainer 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.
- D19 Documentation Quality — LLM evaluation failed
- 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
- 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 — the crate defines newtype typed-ids but declares no domain aggregate that could carry an id — so DM2's adoption ratio has no population to be taken over
- DM3 Integration-event coupling — no integration events detected — coupling check not applicable
- 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 — and nothing was matched here. The coverage check applies to any stack, and the automatic-re-run check to any GitHub-Actions workflow, but the checks for excluded tests, skipped tests and sleep-based synchronisation currently recognise only some ecosystems' test-runner idioms, so on a repository built with another stack the zeros below mean 'not checked', not 'clean'.
- 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.
- R11 Import Boundaries — No recognizable feature-sliced/layered src layout — boundary rules not applicable.
- R5 Dependency Freshness — no package-lock.json — dependency freshness not measured (would require an npm lockfile); JS/npm CVEs are scored in D30 (Dependency Vulnerabilities), which answers every ecosystem
- R6 Tooling — no package.json in the repository — test/lint/typecheck wiring is read from package.json scripts (corroborated against CI), so this project's own toolchain isn't measured here
- R7 Dead Code — Not measured — no application, tooling or test entry point was detected, so no file can be shown to be reachable or unreachable. Declare an entry (package.json main/module/exports, src/index.*, or an index.html script) to enable reachability.
- R8 Dependency Hygiene — Not measured — no package.json declares any dependency, so there is nothing to check imports against (imports may resolve through a host runtime rather than node).
- 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.
- 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. TypeScript/JavaScript runs every callback on the one thread that owns its objects: a callback runs only when the body waiting on it has yielded, never alongside it, and a worker thread receives a COPY of what it is sent. A SharedArrayBuffer carries raw bytes, never an Array, Map or Set, so no collection is reachable from two threads at once. Not a gap in the analyzer and not a finding about your code.
- 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 — 24 finding(s)
D29 · Static Analysis (SAST)
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
D31 · IaC & Container Security
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
AX9 · CQS / query purity
- Query writes persistent state on the read path: PostgresRepoTagRepo.list_tags_with_meta crates/adapters/src/persistence/psql/repo_tag_repo.rs:385
- Query writes persistent state on the read path: PostgresRepoTagRepo.list_tags_with_meta_by_values crates/adapters/src/persistence/psql/repo_tag_repo.rs:476
- Query writes persistent state on the read path: RepoQueryHandler.list_with_tags crates/app/src/repo/query.rs:166
- Query writes persistent state on the read path: RepoQueryHandler.list_ranked_with_tags crates/app/src/repo/query.rs:293
- Query writes persistent state on the read path: RepoQueryHandler.list_by_label_with_tags crates/app/src/repo/query.rs:315
D30 · Dependency Vulnerabilities
- REDACTED
- REDACTED
D8 · Code Coverage
- No automated tests
ED4 · Outbox / dual-write
- Dual write (no outbox): RepoQueryHandler.list_with_tags crates/app/src/repo/query.rs:166
Serious — 143 finding(s)
D3 · God Classes
- FunctionTooLong: ui::components::views::admin::projects::edit_panel::project_tab::ProjectTab crates/ui/src/components/views/admin/projects/edit_panel/project_tab/mod.rs:143
- FunctionTooLong: ui::components::layout::user::fuzzy_search::FuzzySearch crates/ui/src/components/layout/user/fuzzy_search/mod.rs:469
- FunctionTooLong: ui::components::views::admin::projects::project_table::ProjectTable crates/ui/src/components/views/admin/projects/project_table/mod.rs:31
- FunctionTooLong: ui::components::views::repo::detail::meta_section::MetaSection crates/ui/src/components/views/repo/detail/meta_section/mod.rs:22
- FunctionTooLong: ui::components::views::admin::tags::edit_panel::base_tab::BaseTab crates/ui/src/components/views/admin/tags/edit_panel/base_tab/mod.rs:20
- FunctionTooLong: ui::components::views::admin::tags::edit_panel::group_tab::GroupTab crates/ui/src/components/views/admin/tags/edit_panel/group_tab/mod.rs:27
- FunctionTooLong: ui::components::views::admin::tags::tag_table::TagTable crates/ui/src/components/views/admin/tags/tag_table/mod.rs:37
- FunctionTooLong: ui::components::views::repo::list::repo_list_handler::RepoListHandler crates/ui/src/components/views/repo/list/repo_list_handler.rs:12
- FunctionTooLong: ui::components::views::admin::projects::edit_panel::repo_tab::RepoTabEditMode crates/ui/src/components/views/admin/projects/edit_panel/repo_tab/mod.rs:79
- FunctionTooLong: ui::root::layouts::admin_layout::AdminLayout crates/ui/src/root/layouts/admin_layout.rs:19
- FunctionTooLong: ui::components::common::grid_wrapper::GridWrapper crates/ui/src/components/common/grid_wrapper.rs:102
- FunctionTooLong: ui::components::views::repo::detail::trend_section::TrendSection crates/ui/src/components/views/repo/detail/trend_section/mod.rs:72
D4 · Code Duplication
- Duplicated block (11 lines × 2) crates/adapters/src/github.rs:123
- Duplicated block (11 lines × 2) crates/app/src/project/command.rs:106
- Duplicated block (11 lines × 2) crates/ui/src/components/views/admin/backup/mod.rs:81
- Duplicated block (11 lines × 2) crates/ui/src/components/views/admin/projects/edit_panel/mod.rs:37
- Duplicated block (11 lines × 2) crates/ui/src/components/views/admin/projects/project_table/mod.rs:154
- Duplicated block (11 lines × 2) crates/ui/src/components/views/admin/tags/edit_panel/group_tab/mod.rs:167
- Duplicated block (11 lines × 2) crates/ui/src/components/views/repo/detail/meta_section/mod.rs:79
- Duplicated block (11 lines × 2) crates/ui/src/components/views/repo/detail/trend_section/delta_content/mod.rs:82
D15 · Churn × Complexity Hotspots
- Hotspot: crates/adapters/src/persistence/psql/repo_repo.rs crates/adapters/src/persistence/psql/repo_repo.rs:370
- Hotspot: crates/app/src/repo/query.rs crates/app/src/repo/query.rs:166
- Hotspot: crates/app/src/project/command.rs crates/app/src/project/command.rs:94
- Hotspot: crates/ui/src/components/layout/user/fuzzy_search/mod.rs crates/ui/src/components/layout/user/fuzzy_search/mod.rs:469
- Hotspot: crates/ui/src/js/chart_bridge.js crates/ui/src/js/chart_bridge.js:60
- Hotspot: crates/ui/src/components/layout/user/gearmap/mod.rs crates/ui/src/components/layout/user/gearmap/mod.rs:66
- Hotspot: crates/ui/src/js/dom_bridge.js crates/ui/src/js/dom_bridge.js:66
D4 · Code Duplication
- Duplicated block (9 lines × 2) crates/adapters/src/persistence/psql/repo_tag_repo.rs:294
- Duplicated block (9 lines × 2) crates/ui/src/components/layout/user/fuzzy_search/mod.rs:549
- Duplicated block (9 lines × 2) crates/ui/src/components/layout/user/language_switcher.rs:50
- Duplicated block (9 lines × 2) crates/ui/src/components/views/admin/finder/mod.rs:110
- Duplicated block (9 lines × 2) crates/ui/src/components/views/admin/projects/edit_panel/project_tab/skeleton.rs:6
- Duplicated block (9 lines × 2) crates/ui/src/components/views/admin/projects/search.rs:15
D30 · Dependency Vulnerabilities
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
D4 · Code Duplication
- Duplicated block (7 lines × 2) crates/adapters/src/persistence/psql/project_repo.rs:89
- Duplicated block (7 lines × 2) crates/adapters/src/persistence/psql/project_repo.rs:198
- Duplicated block (7 lines × 2) crates/ui/src/components/ui/input/component.rs:48
- Duplicated block (7 lines × 2) crates/app/src/snapshot/command.rs:275
- Duplicated block (7 lines × 2) crates/ui/src/components/views/admin/projects/edit_panel/repo_tab/mod.rs:13
D2 · Cognitive Complexity
- ui::components::layout::user::fuzzy_search::FuzzySearch (cognitive 38) crates/ui/src/components/layout/user/fuzzy_search/mod.rs:469
- ui::components::layout::user::gearmap::generate_gears (cognitive 34) crates/ui/src/components/layout/user/gearmap/mod.rs:66
- ui::components::views::admin::projects::project_table::ProjectTable (cognitive 16) crates/ui/src/components/views/admin/projects/project_table/mod.rs:31
- ui::components::views::repo::list::repo_list::RepoListIO (cognitive 16) crates/ui/src/components/views/repo/list/repo_list/mod.rs:18
D3 · God Classes
- FileTooLong: icons/mod.rs crates/ui/src/components/icons/mod.rs
- FileTooLong: sidebar/component.rs crates/ui/src/components/ui/sidebar/component.rs
- FileTooLong: psql/repo_tag_repo.rs crates/adapters/src/persistence/psql/repo_tag_repo.rs
- FileTooLong: fuzzy_search/mod.rs crates/ui/src/components/layout/user/fuzzy_search/mod.rs
D31 · IaC & Container Security
- REDACTED
- REDACTED
- REDACTED
- REDACTED
D35 · Change Coupling
- Change coupling: footer.rs ↔ mod.rs crates/ui/src/components/layout/user/footer.rs:1
- Change coupling: mod.rs ↔ mod.rs crates/ui/src/components/views/home/mod.rs:1
- Change coupling: mod.rs ↔ mod.rs crates/ui/src/components/views/repo/list/mod.rs:1
- Change coupling: admin_layout.rs ↔ root_layout.rs crates/ui/src/root/layouts/admin_layout.rs:1
D4 · Code Duplication
- Duplicated block (12 lines × 2) crates/ui/src/components/layout/user/fuzzy_search/mod.rs:583
- Duplicated block (12 lines × 2) crates/ui/src/components/views/repo/list/repo_list_handler.rs:34
- Duplicated block (12 lines × 2) crates/ui/src/components/layout/user/color_switcher.rs:24
- Duplicated block (12 lines × 2) crates/adapters/src/persistence/psql/repo_repo.rs:517
D3 · God Classes
- MethodTooLong: ProjectCommandHandler.import_projects crates/app/src/project/command.rs:94
- MethodTooLong: PostgresRepoRepo.list_ranked crates/adapters/src/persistence/psql/repo_repo.rs:370
- MethodTooLong: IngestDailySnapshots.execute crates/app/src/snapshot/command.rs:104
D30 · Dependency Vulnerabilities
- REDACTED
- REDACTED
- REDACTED
D30 · Dependency Vulnerabilities
- REDACTED
- REDACTED
- REDACTED
D4 · Code Duplication
- Duplicated block (16 lines × 2) crates/ui/src/components/layout/user/fuzzy_search/mod.rs:200
- Duplicated block (16 lines × 2) crates/ui/src/types/repos.rs:46
- Duplicated block (16 lines × 2) crates/adapters/src/persistence/psql/repo_repo.rs:249
D4 · Code Duplication
- Duplicated block (14 lines × 2) crates/ui/src/components/views/admin/projects/project_table/mod.rs:308
- Duplicated block (14 lines × 2) crates/ui/src/components/views/repo/list/repo_list_handler.rs:104
- Duplicated block (14 lines × 2) crates/ui/src/components/views/repo/detail/chart.rs:74
D4 · Code Duplication
- Duplicated block (10 lines × 2) crates/ui/src/components/views/admin/projects/edit_panel/project_tab/mod.rs:434
- Duplicated block (10 lines × 2) crates/app/src/project/command.rs:51
- Duplicated block (10 lines × 2) crates/ui/src/components/views/admin/projects/project_table/mod.rs:274
D4 · Code Duplication
- Duplicated block (8 lines × 2) crates/adapters/src/persistence/psql/repo_repo.rs:84
- Duplicated block (8 lines × 2) crates/adapters/src/persistence/psql/snapshot_repo.rs:117
- Duplicated block (8 lines × 2) crates/ui/src/components/views/admin/tags/edit_panel/group_tab/mod.rs:183
X3 · Exception handling
- Swallowed exception (empty catch) crates/ui/src/js/dom_bridge.js:126
- Swallowed exception (empty catch) crates/ui/src/js/dom_bridge.js:139
- Swallowed exception (empty catch) crates/ui/src/js/chart_bridge.js:36
D1 · Cyclomatic Complexity
- ui::components::layout::user::fuzzy_search::FuzzySearch (cyclomatic 28) crates/ui/src/components/layout/user/fuzzy_search/mod.rs:469
- ui::components::layout::user::gearmap::generate_gears (cyclomatic 21) crates/ui/src/components/layout/user/gearmap/mod.rs:66
D3 · God Classes
- ClassTooLong: PostgresRepoTagRepo crates/adapters/src/persistence/psql/repo_tag_repo.rs:51
- ClassTooLong: PostgresRepoRepo crates/adapters/src/persistence/psql/repo_repo.rs:52
D30 · Dependency Vulnerabilities
- REDACTED
- REDACTED
D4 · Code Duplication
- Duplicated block (21 lines × 2) crates/ui/src/IO/projects.rs:86
- Duplicated block (21 lines × 2) crates/adapters/src/persistence/psql/project_repo.rs:99
D4 · Code Duplication
- Duplicated block (17 lines × 2) crates/ui/src/components/views/admin/projects/edit_panel/project_tab/mod.rs:164
- Duplicated block (17 lines × 2) crates/ui/src/components/views/tag/tag_list/tag_row/mini_repo_card.rs:53
D4 · Code Duplication
- Duplicated block (15 lines × 2) crates/adapters/src/persistence/psql/snapshot_repo.rs:175
- Duplicated block (15 lines × 2) crates/ui/src/components/layout/user/fuzzy_search/mod.rs:222
D4 · Code Duplication
- Duplicated block (13 lines × 2) crates/ui/src/components/common/repo_avatar.rs:47
- Duplicated block (13 lines × 2) crates/ui/src/components/views/repo/list/mod.rs:18
D4 · Code Duplication
- Duplicated block (10–11 lines × 2) crates/adapters/src/persistence/psql/repo_tag_repo.rs:241
- Duplicated block (10–11 lines × 2) crates/app/src/project/command.rs:168
D4 · Code Duplication
- Duplicated block (5 lines × 2) crates/app/src/project/command.rs:261
- Duplicated block (5 lines × 2) crates/ui/src/components/views/admin/tags/edit_panel/base_tab/mod.rs:182
D4 · Code Duplication
- Duplicated block (10 lines × 3) crates/ui/src/IO/projects.rs:14
- Duplicated block (10 lines × 3) crates/ui/src/IO/repos.rs:346
P7 · Outbound HTTP resilience
- Outbound HTTP without resilience crates/adapters/src/auth/github_oauth.rs:49
- Outbound HTTP without resilience crates/adapters/src/github.rs:18
C1 · Data Protection
- No data-protection/encryption crates/adapters/migrations/0001_init.sql:23
D1 · Cyclomatic Complexity
- ProjectCommandHandler::import_projects (cyclomatic 19) crates/app/src/project/command.rs:94
D1 · Cyclomatic Complexity
- dom_bridge.rewrite_markdown_links (cyclomatic 19) crates/ui/src/js/dom_bridge.js:109
D1 · Cyclomatic Complexity
- RepoQueryHandler::list_with_tags (cyclomatic 17) crates/app/src/repo/query.rs:166
D1 · Cyclomatic Complexity
- upsert_chart (cyclomatic 17) crates/ui/src/js/chart_bridge.js:60
D1 · Cyclomatic Complexity
- PostgresRepoRepo::list_ranked (cyclomatic 16) crates/adapters/src/persistence/psql/repo_repo.rs:370
D2 · Cognitive Complexity
- ProjectCommandHandler::import_projects (cognitive 44) crates/app/src/project/command.rs:94
D2 · Cognitive Complexity
- RepoQueryHandler::list_with_tags (cognitive 41) crates/app/src/repo/query.rs:166
D2 · Cognitive Complexity
- dom_bridge.rewrite_markdown_links (cognitive 33) crates/ui/src/js/dom_bridge.js:109
D2 · Cognitive Complexity
- mount_fuzzy_search_hotkey (cognitive 18) crates/ui/src/js/dom_bridge.js:66
D2 · Cognitive Complexity
- RepoCommandHandler::import_tags (cognitive 17) crates/app/src/repo/command.rs:149
D2 · Cognitive Complexity
- upsert_chart (cognitive 16) crates/ui/src/js/chart_bridge.js:60
D22 · Internal API Consistency
- Inconsistent naming for bulk operations: 'upsert_many' vs 'update_many'. While 'upsert' is used for single items, the bulk variant for Projects uses 'update_many' in the port, whereas Repos use 'upsert_many'. This implies different semantics (insert-or-update vs update-only) or is a naming inconsistency.
D22 · Internal API Consistency
- Redundant methods for replacing tags: 'replace_tags' and 'replace_tags_by_repo_id' in RepoCommandHandler perform the same logical operation (replacing tags for a repo). One takes arguments directly, the other a command object. This creates confusion about which to use.
D22 · Internal API Consistency
- Ambiguous naming: 'search_by_key' vs 'search_repo_page_by_key'. It is unclear if 'search_by_key' is a general search that might include tags, or if it is an alias for 'search_repo_page_by_key'. The existence of 'search_tag_page_by_key' suggests 'search_by_key' might be a composite or ambiguous method.
D36 · Supply-chain Provenance & Signing
- REDACTED
D36 · Supply-chain Provenance & Signing
- REDACTED
D4 · Code Duplication
- Members sharing a duplicated core (9 members, 50+ identical tokens) crates/adapters/src/persistence/psql/project_repo.rs:168
D4 · Code Duplication
- Duplicated block (55 lines × 2) crates/adapters/src/persistence/psql/repo_tag_repo.rs:407
D4 · Code Duplication
- Duplicated block (41–42 lines × 2) crates/ui/src/components/views/admin/projects/project_table/mod.rs:166
D4 · Code Duplication
- Duplicated block (33 lines × 2) crates/ui/src/components/views/admin/projects/search.rs:24
D4 · Code Duplication
- Duplicated block (26 lines × 2) crates/ui/src/IO/repos.rs:170
D4 · Code Duplication
- Duplicated block (16–17 lines × 2) crates/adapters/src/persistence/psql/repo_tag_repo.rs:367
D4 · Code Duplication
- Duplicated block (3–15 lines × 3) crates/app/src/repo/query.rs:277
D4 · Code Duplication
- Duplicated block (12–13 lines × 2) crates/ui/src/IO/projects.rs:72
D4 · Code Duplication
- Duplicated block (8–9 lines × 8) crates/adapters/src/persistence/psql/project_repo.rs:187
D4 · Code Duplication
- Duplicated block (8–9 lines × 2) crates/ui/src/components/views/admin/projects/mod.rs:49
D4 · Code Duplication
- Duplicated block (16 lines × 5) crates/adapters/src/persistence/psql/project_repo.rs:75
D4 · Code Duplication
- Duplicated block (17 lines × 3) crates/adapters/src/persistence/psql/project_repo.rs:177
D5 · Coupling
- Off the main sequence: domain
R1 · Type Safety
- Type Safety
R2 · Cyclomatic Complexity
- Complex function rewrite_markdown_links (cyclomatic 19, cognitive 33) crates/ui/src/js/dom_bridge.js:109
R2 · Cyclomatic Complexity
- Complex function upsert_chart (cyclomatic 17, cognitive 16) crates/ui/src/js/chart_bridge.js:60
R4 · Test Coverage
- Test Coverage
Minor — 15 finding(s)
C2 · Access Controls
- Thin authorization enforcement
D20 · ADR Quality
- No ADRs found
D26 · Project Cohesion
- Split crates/ui
D30 · Dependency Vulnerabilities
- REDACTED
D36 · Supply-chain Provenance & Signing
- REDACTED
D9 · Test Distribution
- No tests found
M2 · Architecture documentation
- No ADRs
M4 · Documentation accuracy
- README/code drift docs/contribute/contribute_zh-CN.md:24
P1 · CI/CD gates
- CI build step not evidenced
P4 · Deployment & Rollback
- No rollback/health safety
P6 · Release Hygiene
- No changelog
S1 · Web-Security Posture
- No app-layer HTTPS enforcement detected
S1 · Web-Security Posture
- No security response headers detected
X10 · Duplicated predicate
- Duplicated predicate crates/ui/src/components/views/repo/list/mod.rs:22
X4 · Structured logging
- Interpolated log message defeats structured logging crates/worker/src/main.rs:17
Minor — 11 finding(s)
D12 · Dependency Hygiene
- Outdated: anyhow
- Outdated: async-trait
- Outdated: chrono
- Outdated: dioxus
- Outdated: futures
- Outdated: redis
- Outdated: redis_pool
- Outdated: serde
- Outdated: serde_json
- Outdated: thiserror
- Outdated: tokio
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-e3834144df424d26a2a615d679ca81ae/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-e3834144df424d26a2a615d679ca81ae/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 . | 9 | 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 . | 16 | artifacts/raw/osv-scanner.json |
| D31 · IaC & Container Security | trivy | — | trivy config --format json --quiet . | 10 | 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 |