Executive summary
alexleboucher/docker-express-postgres-boilerplate scores 52 out of 100, but it is rated At risk while a critical security finding is open; the score itself is unchanged. Watchdog judged it as a template, sample or demo, meant to be read or copied, so the dimensions about building, releasing and running a product don't apply, and its lenses are rated against a lower bar. The score itself is worked out as for any repository.
The weakest lens counts most in the score, and here that is Production Readiness, which scores 43 and is rated Adequate. Its Security & performance tooling 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 strengthen data-at-rest protection: vault your keys (AWS KMS / Secrets Manager, Azure Key Vault, GCP KMS / Secret Manager, HashiCorp Vault) and encrypt the most sensitive columns (typeorm-encrypted, prisma-field-encryption, mongoose-field-encryption or MongoDB CSFLE) — partial coverage still leaves gaps and to resolve the 5 Deprecated finding(s) in Dependency Hygiene, and if Production Readiness rose to 70, the score would rise from 52 to about 57.
33 findings are critical: 16 in Dependency Vulnerabilities, 16 in Static Analysis (SAST) and one in IaC & Container Security.
Watchdog couldn't measure 6 dimensions in this code, among them Navigability, Web-Security Posture and Cancellation propagation, so they are left out of the score. The product code is 1,452 lines, which would take an estimated 0.1 person-years, around €3,500, to rebuild.
Code Health
97 ★
Exemplary
Architecture
69
Strong
Maturity
55
Adequate, capped by Architecture documentation
Production Readiness
43
Adequate, capped by Security & performance tooling and DR & Backup
Security and Compliance
45
Weak, capped by Dependency Vulnerabilities and Data Protection
Domain Modelling
100 ★
Exemplary
Performance
100 ★
Exemplary
How the score is built: what each lens counts for
The lenses don't count equally. The weakest lens counts most, the next weakest a little less, and so on, so a weak area pulls the score down instead of being averaged away. In the bar below, each part's width shows how much that lens counts and its colour shows its rating. Improving the widest part moves the score most, and as that lens improves, it counts for less, because another lens becomes the weakest.
Production Readiness 43 · counts for 46%Security and Compliance 45 · counts for 25%Maturity 55 · counts for 14%Architecture 69 · counts for 8%Code Health 97 · counts for 4%Domain Modelling 100 · counts for 2%Performance 100 · counts for 1%
If Production Readiness rose from 43 to 70, the lowest score rated Strong, the score would rise from 52 to about 57.
Code composition: what the lines of code are
Product code 55%Tests 45%
New since the last survey: 8 findings
- Dependency Hygiene · Deprecated: @types/bcryptjs REDACTED
- Dependency Vulnerabilities · REDACTED
- Dependency Vulnerabilities · REDACTED
- Supply-chain Provenance & Signing · REDACTED
- Supply-chain Provenance & Signing · REDACTED
- Supply-chain Provenance & Signing · REDACTED
- Dependency Hygiene · Unused dependency 'tsconfig-paths'
- Dependency Hygiene · Unused dependency 'tslib'
Fixed since the last survey: 2 findings
- Dependency Vulnerabilities · Medium CVE: REDACTED REDACTED
- Supply-chain Provenance & Signing REDACTED
Rebuild cost: about €3,500 · Estimate
| Cost to rebuild | €1,200 to €5,800, for 19 to 61 hours of work, about 0.1 person-years for one engineer |
|---|---|
| Difficulty of the problem | High, 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 52. 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 | Very small: 1,452 lines of product code |
Top priorities
1
Strengthen data-at-rest protection: vault your keys (AWS KMS / Secrets Manager, Azure Key Vault, GCP KMS / Secret Manager, HashiCorp Vault) and encrypt the most sensitive columns (typeorm-encrypted, prisma-field-encryption, mongoose-field-encryption or MongoDB CSFLE) — partial coverage still leaves gaps.
2
Resolve the 5 Deprecated finding(s) in Dependency Hygiene — start with REDACTED (5).
3
Add a SAST step to CI running what this repository's stack ships: CodeQL's javascript-typescript pack, `semgrep --config=p/typescript`, or eslint-plugin-security — so a security regression fails the build instead of landing.
Diagnosis: what the measurements show together
If you do one thing first
Strengthen data-at-rest protection: vault your keys (AWS KMS / Secrets Manager, Azure Key Vault, GCP KMS / Secret Manager, HashiCorp Vault) and encrypt the most sensitive columns (typeorm-encrypted, prisma-field-encryption, mongoose-field-encryption or MongoDB CSFLE) — partial coverage still leaves gaps. Of all the actions in this report, it raises the score most for the work it takes: about 5 points for medium effort. The next survey will show the change in the score.
Architecture: which parts of the code depend on which
| uses → | 1 app.http-error | 2 app.request-handlers.request-handler_interface | 3 app.routers.base-router | 4 container.container | 5 core.id.id-generator_interface | 6 core.logger.logger_interface | 7 core.time.time_interface | 8 core.use-case.use-case_interface | 9 domain.models.user | 10 domain.services.auth.authenticator_interface | 11 domain.services.security.encryptor_interface | 12 tests.helpers.user-helpers | 13 app.middlewares.current-user-middleware | 14 app.middlewares.error-middleware | 15 app.request-handlers.auth.commands.login-request-handler | 16 app.request-handlers.auth.queries.authenticated-request-handler | 17 app.request-handlers.health.queries.health-request-handler | 18 app.request-handlers.users.commands.create-user-request-handler | 19 app.routers.api-router | 20 app.routers.auth-router | 21 app.routers.health-router | 22 app.routers.users-router | 23 container.core | 24 container.core.container | 25 container.middlewares | 26 container.middlewares.container | 27 container.repositories | 28 container.repositories.container | 29 container.request-handlers | 30 container.request-handlers.container | 31 container.routers | 32 container.routers.container | 33 domain.repositories.user-repository_interface | 34 domain.use-cases.auth.get-current-user-use-case | 35 domain.use-cases.auth.login-use-case | 36 tests.helpers.test-environment | 37 domain.use-cases.user.create-user-use-case | 38 infra.auth.authenticator.jwt-authenticator | 39 infra.database.repositories.user-repository | 40 tests.helpers |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 app.http-error | ||||||||||||||||||||||||||||||||||||||||
| 2 app.request-handlers.request-handler_interface | ||||||||||||||||||||||||||||||||||||||||
| 3 app.routers.base-router | ||||||||||||||||||||||||||||||||||||||||
| 4 container.container | ||||||||||||||||||||||||||||||||||||||||
| 5 core.id.id-generator_interface | ||||||||||||||||||||||||||||||||||||||||
| 6 core.logger.logger_interface | ||||||||||||||||||||||||||||||||||||||||
| 7 core.time.time_interface | ||||||||||||||||||||||||||||||||||||||||
| 8 core.use-case.use-case_interface | ||||||||||||||||||||||||||||||||||||||||
| 9 domain.models.user | ||||||||||||||||||||||||||||||||||||||||
| 10 domain.services.auth.authenticator_interface | ||||||||||||||||||||||||||||||||||||||||
| 11 domain.services.security.encryptor_interface | ||||||||||||||||||||||||||||||||||||||||
| 12 tests.helpers.user-helpers | ||||||||||||||||||||||||||||||||||||||||
| 13 app.middlewares.current-user-middleware | 1 | |||||||||||||||||||||||||||||||||||||||
| 14 app.middlewares.error-middleware | 1 | 1 | ||||||||||||||||||||||||||||||||||||||
| 15 app.request-handlers.auth.commands.login-request-handler | 1 | 1 | ||||||||||||||||||||||||||||||||||||||
| 16 app.request-handlers.auth.queries.authenticated-request-handler | 1 | |||||||||||||||||||||||||||||||||||||||
| 17 app.request-handlers.health.queries.health-request-handler | 1 | |||||||||||||||||||||||||||||||||||||||
| 18 app.request-handlers.users.commands.create-user-request-handler | 1 | 1 | ||||||||||||||||||||||||||||||||||||||
| 19 app.routers.api-router | 1 | |||||||||||||||||||||||||||||||||||||||
| 20 app.routers.auth-router | 1 | 1 | ||||||||||||||||||||||||||||||||||||||
| 21 app.routers.health-router | 1 | 1 | ||||||||||||||||||||||||||||||||||||||
| 22 app.routers.users-router | 1 | 1 | ||||||||||||||||||||||||||||||||||||||
| 23 container.core | 1 | |||||||||||||||||||||||||||||||||||||||
| 24 container.core.container | 1 | |||||||||||||||||||||||||||||||||||||||
| 25 container.middlewares | 1 | |||||||||||||||||||||||||||||||||||||||
| 26 container.middlewares.container | 1 | |||||||||||||||||||||||||||||||||||||||
| 27 container.repositories | 1 | |||||||||||||||||||||||||||||||||||||||
| 28 container.repositories.container | 1 | |||||||||||||||||||||||||||||||||||||||
| 29 container.request-handlers | 1 | |||||||||||||||||||||||||||||||||||||||
| 30 container.request-handlers.container | 1 | |||||||||||||||||||||||||||||||||||||||
| 31 container.routers | 1 | |||||||||||||||||||||||||||||||||||||||
| 32 container.routers.container | 1 | |||||||||||||||||||||||||||||||||||||||
| 33 domain.repositories.user-repository_interface | 1 | |||||||||||||||||||||||||||||||||||||||
| 34 domain.use-cases.auth.get-current-user-use-case | 1 | 1 | ||||||||||||||||||||||||||||||||||||||
| 35 domain.use-cases.auth.login-use-case | 1 | 1 | ||||||||||||||||||||||||||||||||||||||
| 36 tests.helpers.test-environment | 1 | |||||||||||||||||||||||||||||||||||||||
| 37 domain.use-cases.user.create-user-use-case | 1 | 1 | 1 | 1 | 1 | |||||||||||||||||||||||||||||||||||
| 38 infra.auth.authenticator.jwt-authenticator | 3 | 1 | ||||||||||||||||||||||||||||||||||||||
| 39 infra.database.repositories.user-repository | 1 | 1 | 1 | |||||||||||||||||||||||||||||||||||||
| 40 tests.helpers | 1 | 2 |
Uses a module listed above itPart of a loopThe module itself
13→8 app.middlewares.current-user-middleware uses core.use-case.use-case_interface✕
- Connections
- 1 pair of types, where a type in app.middlewares.current-user-middleware uses a type in core.use-case.use-case_interface.
- The types involved
src.app.middlewares.current-user-middleware.CurrentUserMiddleware→src.core.use-case.use-case_interface.IUseCase
- Direction
- app.middlewares.current-user-middleware uses core.use-case.use-case_interface, so a change to core.use-case.use-case_interface can break app.middlewares.current-user-middleware, while a change to app.middlewares.current-user-middleware can't break core.use-case.use-case_interface.
- Position
- Below the diagonal: app.middlewares.current-user-middleware uses a module listed above it, which is the healthy direction.
14→1 app.middlewares.error-middleware uses app.http-error✕
- Connections
- 1 pair of types, where a type in app.middlewares.error-middleware uses a type in app.http-error.
- The types involved
src.app.middlewares.error-middleware.ErrorMiddleware→src.app.http-error.HttpError
- Direction
- app.middlewares.error-middleware uses app.http-error, so a change to app.http-error can break app.middlewares.error-middleware, while a change to app.middlewares.error-middleware can't break app.http-error.
- Position
- Below the diagonal: app.middlewares.error-middleware uses a module listed above it, which is the healthy direction.
14→6 app.middlewares.error-middleware uses core.logger.logger_interface✕
- Connections
- 1 pair of types, where a type in app.middlewares.error-middleware uses a type in core.logger.logger_interface.
- The types involved
src.app.middlewares.error-middleware.ErrorMiddleware→src.core.logger.logger_interface.ILogger
- Direction
- app.middlewares.error-middleware uses core.logger.logger_interface, so a change to core.logger.logger_interface can break app.middlewares.error-middleware, while a change to app.middlewares.error-middleware can't break core.logger.logger_interface.
- Position
- Below the diagonal: app.middlewares.error-middleware uses a module listed above it, which is the healthy direction.
15→2 app.request-handlers.auth.commands.login-request-handler uses app.request-handlers.request-handler_interface✕
- Connections
- 1 pair of types, where a type in app.request-handlers.auth.commands.login-request-handler uses a type in app.request-handlers.request-handler_interface.
- The types involved
src.app.request-handlers.auth.commands.login-request-handler.LoginRequestHandler→src.app.request-handlers.request-handler_interface.IRequestHandler
- Direction
- app.request-handlers.auth.commands.login-request-handler uses app.request-handlers.request-handler_interface, so a change to app.request-handlers.request-handler_interface can break app.request-handlers.auth.commands.login-request-handler, while a change to app.request-handlers.auth.commands.login-request-handler can't break app.request-handlers.request-handler_interface.
- Position
- Below the diagonal: app.request-handlers.auth.commands.login-request-handler uses a module listed above it, which is the healthy direction.
15→8 app.request-handlers.auth.commands.login-request-handler uses core.use-case.use-case_interface✕
- Connections
- 1 pair of types, where a type in app.request-handlers.auth.commands.login-request-handler uses a type in core.use-case.use-case_interface.
- The types involved
src.app.request-handlers.auth.commands.login-request-handler.LoginRequestHandler→src.core.use-case.use-case_interface.IUseCase
- Direction
- app.request-handlers.auth.commands.login-request-handler uses core.use-case.use-case_interface, so a change to core.use-case.use-case_interface can break app.request-handlers.auth.commands.login-request-handler, while a change to app.request-handlers.auth.commands.login-request-handler can't break core.use-case.use-case_interface.
- Position
- Below the diagonal: app.request-handlers.auth.commands.login-request-handler uses a module listed above it, which is the healthy direction.
16→2 app.request-handlers.auth.queries.authenticated-request-handler uses app.request-handlers.request-handler_interface✕
- Connections
- 1 pair of types, where a type in app.request-handlers.auth.queries.authenticated-request-handler uses a type in app.request-handlers.request-handler_interface.
- The types involved
src.app.request-handlers.auth.queries.authenticated-request-handler.AuthenticatedRequestHandler→src.app.request-handlers.request-handler_interface.IRequestHandler
- Direction
- app.request-handlers.auth.queries.authenticated-request-handler uses app.request-handlers.request-handler_interface, so a change to app.request-handlers.request-handler_interface can break app.request-handlers.auth.queries.authenticated-request-handler, while a change to app.request-handlers.auth.queries.authenticated-request-handler can't break app.request-handlers.request-handler_interface.
- Position
- Below the diagonal: app.request-handlers.auth.queries.authenticated-request-handler uses a module listed above it, which is the healthy direction.
17→2 app.request-handlers.health.queries.health-request-handler uses app.request-handlers.request-handler_interface✕
- Connections
- 1 pair of types, where a type in app.request-handlers.health.queries.health-request-handler uses a type in app.request-handlers.request-handler_interface.
- The types involved
src.app.request-handlers.health.queries.health-request-handler.HealthRequestHandler→src.app.request-handlers.request-handler_interface.IRequestHandler
- Direction
- app.request-handlers.health.queries.health-request-handler uses app.request-handlers.request-handler_interface, so a change to app.request-handlers.request-handler_interface can break app.request-handlers.health.queries.health-request-handler, while a change to app.request-handlers.health.queries.health-request-handler can't break app.request-handlers.request-handler_interface.
- Position
- Below the diagonal: app.request-handlers.health.queries.health-request-handler uses a module listed above it, which is the healthy direction.
18→2 app.request-handlers.users.commands.create-user-request-handler uses app.request-handlers.request-handler_interface✕
- Connections
- 1 pair of types, where a type in app.request-handlers.users.commands.create-user-request-handler uses a type in app.request-handlers.request-handler_interface.
- The types involved
src.app.request-handlers.users.commands.create-user-request-handler.CreateUserRequestHandler→src.app.request-handlers.request-handler_interface.IRequestHandler
- Direction
- app.request-handlers.users.commands.create-user-request-handler uses app.request-handlers.request-handler_interface, so a change to app.request-handlers.request-handler_interface can break app.request-handlers.users.commands.create-user-request-handler, while a change to app.request-handlers.users.commands.create-user-request-handler can't break app.request-handlers.request-handler_interface.
- Position
- Below the diagonal: app.request-handlers.users.commands.create-user-request-handler uses a module listed above it, which is the healthy direction.
18→8 app.request-handlers.users.commands.create-user-request-handler uses core.use-case.use-case_interface✕
- Connections
- 1 pair of types, where a type in app.request-handlers.users.commands.create-user-request-handler uses a type in core.use-case.use-case_interface.
- The types involved
src.app.request-handlers.users.commands.create-user-request-handler.CreateUserRequestHandler→src.core.use-case.use-case_interface.IUseCase
- Direction
- app.request-handlers.users.commands.create-user-request-handler uses core.use-case.use-case_interface, so a change to core.use-case.use-case_interface can break app.request-handlers.users.commands.create-user-request-handler, while a change to app.request-handlers.users.commands.create-user-request-handler can't break core.use-case.use-case_interface.
- Position
- Below the diagonal: app.request-handlers.users.commands.create-user-request-handler uses a module listed above it, which is the healthy direction.
19→3 app.routers.api-router uses app.routers.base-router✕
- Connections
- 1 pair of types, where a type in app.routers.api-router uses a type in app.routers.base-router.
- The types involved
src.app.routers.api-router.ApiRouter→src.app.routers.base-router.BaseRouter
- Direction
- app.routers.api-router uses app.routers.base-router, so a change to app.routers.base-router can break app.routers.api-router, while a change to app.routers.api-router can't break app.routers.base-router.
- Position
- Below the diagonal: app.routers.api-router uses a module listed above it, which is the healthy direction.
20→2 app.routers.auth-router uses app.request-handlers.request-handler_interface✕
- Connections
- 1 pair of types, where a type in app.routers.auth-router uses a type in app.request-handlers.request-handler_interface.
- The types involved
src.app.routers.auth-router.AuthRouter→src.app.request-handlers.request-handler_interface.IRequestHandler
- Direction
- app.routers.auth-router uses app.request-handlers.request-handler_interface, so a change to app.request-handlers.request-handler_interface can break app.routers.auth-router, while a change to app.routers.auth-router can't break app.request-handlers.request-handler_interface.
- Position
- Below the diagonal: app.routers.auth-router uses a module listed above it, which is the healthy direction.
20→3 app.routers.auth-router uses app.routers.base-router✕
- Connections
- 1 pair of types, where a type in app.routers.auth-router uses a type in app.routers.base-router.
- The types involved
src.app.routers.auth-router.AuthRouter→src.app.routers.base-router.BaseRouter
- Direction
- app.routers.auth-router uses app.routers.base-router, so a change to app.routers.base-router can break app.routers.auth-router, while a change to app.routers.auth-router can't break app.routers.base-router.
- Position
- Below the diagonal: app.routers.auth-router uses a module listed above it, which is the healthy direction.
21→2 app.routers.health-router uses app.request-handlers.request-handler_interface✕
- Connections
- 1 pair of types, where a type in app.routers.health-router uses a type in app.request-handlers.request-handler_interface.
- The types involved
src.app.routers.health-router.HealthRouter→src.app.request-handlers.request-handler_interface.IRequestHandler
- Direction
- app.routers.health-router uses app.request-handlers.request-handler_interface, so a change to app.request-handlers.request-handler_interface can break app.routers.health-router, while a change to app.routers.health-router can't break app.request-handlers.request-handler_interface.
- Position
- Below the diagonal: app.routers.health-router uses a module listed above it, which is the healthy direction.
21→3 app.routers.health-router uses app.routers.base-router✕
- Connections
- 1 pair of types, where a type in app.routers.health-router uses a type in app.routers.base-router.
- The types involved
src.app.routers.health-router.HealthRouter→src.app.routers.base-router.BaseRouter
- Direction
- app.routers.health-router uses app.routers.base-router, so a change to app.routers.base-router can break app.routers.health-router, while a change to app.routers.health-router can't break app.routers.base-router.
- Position
- Below the diagonal: app.routers.health-router uses a module listed above it, which is the healthy direction.
22→2 app.routers.users-router uses app.request-handlers.request-handler_interface✕
- Connections
- 1 pair of types, where a type in app.routers.users-router uses a type in app.request-handlers.request-handler_interface.
- The types involved
src.app.routers.users-router.UsersRouter→src.app.request-handlers.request-handler_interface.IRequestHandler
- Direction
- app.routers.users-router uses app.request-handlers.request-handler_interface, so a change to app.request-handlers.request-handler_interface can break app.routers.users-router, while a change to app.routers.users-router can't break app.request-handlers.request-handler_interface.
- Position
- Below the diagonal: app.routers.users-router uses a module listed above it, which is the healthy direction.
22→3 app.routers.users-router uses app.routers.base-router✕
- Connections
- 1 pair of types, where a type in app.routers.users-router uses a type in app.routers.base-router.
- The types involved
src.app.routers.users-router.UsersRouter→src.app.routers.base-router.BaseRouter
- Direction
- app.routers.users-router uses app.routers.base-router, so a change to app.routers.base-router can break app.routers.users-router, while a change to app.routers.users-router can't break app.routers.base-router.
- Position
- Below the diagonal: app.routers.users-router uses a module listed above it, which is the healthy direction.
23→4 container.core uses container.container✕
- Connections
- 1 pair of types, where a type in container.core uses a type in container.container.
- The types involved
src.container.core.container→src.container.container.ContainerBuilder
- Direction
- container.core uses container.container, so a change to container.container can break container.core, while a change to container.core can't break container.container.
- Position
- Below the diagonal: container.core uses a module listed above it, which is the healthy direction.
24→4 container.core.container uses container.container✕
- Connections
- 1 pair of types, where a type in container.core.container uses a type in container.container.
- The types involved
src.container.core.container.CoreContainerBuilder→src.container.container.ContainerBuilder
- Direction
- container.core.container uses container.container, so a change to container.container can break container.core.container, while a change to container.core.container can't break container.container.
- Position
- Below the diagonal: container.core.container uses a module listed above it, which is the healthy direction.
25→4 container.middlewares uses container.container✕
- Connections
- 1 pair of types, where a type in container.middlewares uses a type in container.container.
- The types involved
src.container.middlewares.container→src.container.container.ContainerBuilder
- Direction
- container.middlewares uses container.container, so a change to container.container can break container.middlewares, while a change to container.middlewares can't break container.container.
- Position
- Below the diagonal: container.middlewares uses a module listed above it, which is the healthy direction.
26→4 container.middlewares.container uses container.container✕
- Connections
- 1 pair of types, where a type in container.middlewares.container uses a type in container.container.
- The types involved
src.container.middlewares.container.MiddlewaresContainerBuilder→src.container.container.ContainerBuilder
- Direction
- container.middlewares.container uses container.container, so a change to container.container can break container.middlewares.container, while a change to container.middlewares.container can't break container.container.
- Position
- Below the diagonal: container.middlewares.container uses a module listed above it, which is the healthy direction.
27→4 container.repositories uses container.container✕
- Connections
- 1 pair of types, where a type in container.repositories uses a type in container.container.
- The types involved
src.container.repositories.container→src.container.container.ContainerBuilder
- Direction
- container.repositories uses container.container, so a change to container.container can break container.repositories, while a change to container.repositories can't break container.container.
- Position
- Below the diagonal: container.repositories uses a module listed above it, which is the healthy direction.
28→4 container.repositories.container uses container.container✕
- Connections
- 1 pair of types, where a type in container.repositories.container uses a type in container.container.
- The types involved
src.container.repositories.container.RepositoriesContainerBuilder→src.container.container.ContainerBuilder
- Direction
- container.repositories.container uses container.container, so a change to container.container can break container.repositories.container, while a change to container.repositories.container can't break container.container.
- Position
- Below the diagonal: container.repositories.container uses a module listed above it, which is the healthy direction.
29→4 container.request-handlers uses container.container✕
- Connections
- 1 pair of types, where a type in container.request-handlers uses a type in container.container.
- The types involved
src.container.request-handlers.container→src.container.container.ContainerBuilder
- Direction
- container.request-handlers uses container.container, so a change to container.container can break container.request-handlers, while a change to container.request-handlers can't break container.container.
- Position
- Below the diagonal: container.request-handlers uses a module listed above it, which is the healthy direction.
30→4 container.request-handlers.container uses container.container✕
- Connections
- 1 pair of types, where a type in container.request-handlers.container uses a type in container.container.
- The types involved
src.container.request-handlers.container.RequestHandlersContainerBuilder→src.container.container.ContainerBuilder
- Direction
- container.request-handlers.container uses container.container, so a change to container.container can break container.request-handlers.container, while a change to container.request-handlers.container can't break container.container.
- Position
- Below the diagonal: container.request-handlers.container uses a module listed above it, which is the healthy direction.
31→4 container.routers uses container.container✕
- Connections
- 1 pair of types, where a type in container.routers uses a type in container.container.
- The types involved
src.container.routers.container→src.container.container.ContainerBuilder
- Direction
- container.routers uses container.container, so a change to container.container can break container.routers, while a change to container.routers can't break container.container.
- Position
- Below the diagonal: container.routers uses a module listed above it, which is the healthy direction.
32→4 container.routers.container uses container.container✕
- Connections
- 1 pair of types, where a type in container.routers.container uses a type in container.container.
- The types involved
src.container.routers.container.RoutersContainerBuilder→src.container.container.ContainerBuilder
- Direction
- container.routers.container uses container.container, so a change to container.container can break container.routers.container, while a change to container.routers.container can't break container.container.
- Position
- Below the diagonal: container.routers.container uses a module listed above it, which is the healthy direction.
33→9 domain.repositories.user-repository_interface uses domain.models.user✕
- Connections
- 1 pair of types, where a type in domain.repositories.user-repository_interface uses a type in domain.models.user.
- The types involved
src.domain.repositories.user-repository_interface.IUserRepository→src.domain.models.user.User
- Direction
- domain.repositories.user-repository_interface uses domain.models.user, so a change to domain.models.user can break domain.repositories.user-repository_interface, while a change to domain.repositories.user-repository_interface can't break domain.models.user.
- Position
- Below the diagonal: domain.repositories.user-repository_interface uses a module listed above it, which is the healthy direction.
34→8 domain.use-cases.auth.get-current-user-use-case uses core.use-case.use-case_interface✕
- Connections
- 1 pair of types, where a type in domain.use-cases.auth.get-current-user-use-case uses a type in core.use-case.use-case_interface.
- The types involved
src.domain.use-cases.auth.get-current-user-use-case.GetCurrentUserUseCase→src.core.use-case.use-case_interface.IUseCase
- Direction
- domain.use-cases.auth.get-current-user-use-case uses core.use-case.use-case_interface, so a change to core.use-case.use-case_interface can break domain.use-cases.auth.get-current-user-use-case, while a change to domain.use-cases.auth.get-current-user-use-case can't break core.use-case.use-case_interface.
- Position
- Below the diagonal: domain.use-cases.auth.get-current-user-use-case uses a module listed above it, which is the healthy direction.
34→10 domain.use-cases.auth.get-current-user-use-case uses domain.services.auth.authenticator_interface✕
- Connections
- 1 pair of types, where a type in domain.use-cases.auth.get-current-user-use-case uses a type in domain.services.auth.authenticator_interface.
- The types involved
src.domain.use-cases.auth.get-current-user-use-case.GetCurrentUserUseCase→src.domain.services.auth.authenticator_interface.IAuthenticator
- Direction
- domain.use-cases.auth.get-current-user-use-case uses domain.services.auth.authenticator_interface, so a change to domain.services.auth.authenticator_interface can break domain.use-cases.auth.get-current-user-use-case, while a change to domain.use-cases.auth.get-current-user-use-case can't break domain.services.auth.authenticator_interface.
- Position
- Below the diagonal: domain.use-cases.auth.get-current-user-use-case uses a module listed above it, which is the healthy direction.
35→8 domain.use-cases.auth.login-use-case uses core.use-case.use-case_interface✕
- Connections
- 1 pair of types, where a type in domain.use-cases.auth.login-use-case uses a type in core.use-case.use-case_interface.
- The types involved
src.domain.use-cases.auth.login-use-case.LoginUseCase→src.core.use-case.use-case_interface.IUseCase
- Direction
- domain.use-cases.auth.login-use-case uses core.use-case.use-case_interface, so a change to core.use-case.use-case_interface can break domain.use-cases.auth.login-use-case, while a change to domain.use-cases.auth.login-use-case can't break core.use-case.use-case_interface.
- Position
- Below the diagonal: domain.use-cases.auth.login-use-case uses a module listed above it, which is the healthy direction.
35→10 domain.use-cases.auth.login-use-case uses domain.services.auth.authenticator_interface✕
- Connections
- 1 pair of types, where a type in domain.use-cases.auth.login-use-case uses a type in domain.services.auth.authenticator_interface.
- The types involved
src.domain.use-cases.auth.login-use-case.LoginUseCase→src.domain.services.auth.authenticator_interface.IAuthenticator
- Direction
- domain.use-cases.auth.login-use-case uses domain.services.auth.authenticator_interface, so a change to domain.services.auth.authenticator_interface can break domain.use-cases.auth.login-use-case, while a change to domain.use-cases.auth.login-use-case can't break domain.services.auth.authenticator_interface.
- Position
- Below the diagonal: domain.use-cases.auth.login-use-case uses a module listed above it, which is the healthy direction.
36→12 tests.helpers.test-environment uses tests.helpers.user-helpers✕
- Connections
- 1 pair of types, where a type in tests.helpers.test-environment uses a type in tests.helpers.user-helpers.
- The types involved
src.tests.helpers.test-environment.TestEnvironment→src.tests.helpers.user-helpers.CreateTestUserOptions
- Direction
- tests.helpers.test-environment uses tests.helpers.user-helpers, so a change to tests.helpers.user-helpers can break tests.helpers.test-environment, while a change to tests.helpers.test-environment can't break tests.helpers.user-helpers.
- Position
- Below the diagonal: tests.helpers.test-environment uses a module listed above it, which is the healthy direction.
37→5 domain.use-cases.user.create-user-use-case uses core.id.id-generator_interface✕
- Connections
- 1 pair of types, where a type in domain.use-cases.user.create-user-use-case uses a type in core.id.id-generator_interface.
- The types involved
src.domain.use-cases.user.create-user-use-case.CreateUserUseCase→src.core.id.id-generator_interface.IIDGenerator
- Direction
- domain.use-cases.user.create-user-use-case uses core.id.id-generator_interface, so a change to core.id.id-generator_interface can break domain.use-cases.user.create-user-use-case, while a change to domain.use-cases.user.create-user-use-case can't break core.id.id-generator_interface.
- Position
- Below the diagonal: domain.use-cases.user.create-user-use-case uses a module listed above it, which is the healthy direction.
37→7 domain.use-cases.user.create-user-use-case uses core.time.time_interface✕
- Connections
- 1 pair of types, where a type in domain.use-cases.user.create-user-use-case uses a type in core.time.time_interface.
- The types involved
src.domain.use-cases.user.create-user-use-case.CreateUserUseCase→src.core.time.time_interface.ITime
- Direction
- domain.use-cases.user.create-user-use-case uses core.time.time_interface, so a change to core.time.time_interface can break domain.use-cases.user.create-user-use-case, while a change to domain.use-cases.user.create-user-use-case can't break core.time.time_interface.
- Position
- Below the diagonal: domain.use-cases.user.create-user-use-case uses a module listed above it, which is the healthy direction.
37→8 domain.use-cases.user.create-user-use-case uses core.use-case.use-case_interface✕
- Connections
- 1 pair of types, where a type in domain.use-cases.user.create-user-use-case uses a type in core.use-case.use-case_interface.
- The types involved
src.domain.use-cases.user.create-user-use-case.CreateUserUseCase→src.core.use-case.use-case_interface.IUseCase
- Direction
- domain.use-cases.user.create-user-use-case uses core.use-case.use-case_interface, so a change to core.use-case.use-case_interface can break domain.use-cases.user.create-user-use-case, while a change to domain.use-cases.user.create-user-use-case can't break core.use-case.use-case_interface.
- Position
- Below the diagonal: domain.use-cases.user.create-user-use-case uses a module listed above it, which is the healthy direction.
37→11 domain.use-cases.user.create-user-use-case uses domain.services.security.encryptor_interface✕
- Connections
- 1 pair of types, where a type in domain.use-cases.user.create-user-use-case uses a type in domain.services.security.encryptor_interface.
- The types involved
src.domain.use-cases.user.create-user-use-case.CreateUserUseCase→src.domain.services.security.encryptor_interface.IEncryptor
- Direction
- domain.use-cases.user.create-user-use-case uses domain.services.security.encryptor_interface, so a change to domain.services.security.encryptor_interface can break domain.use-cases.user.create-user-use-case, while a change to domain.use-cases.user.create-user-use-case can't break domain.services.security.encryptor_interface.
- Position
- Below the diagonal: domain.use-cases.user.create-user-use-case uses a module listed above it, which is the healthy direction.
37→33 domain.use-cases.user.create-user-use-case uses domain.repositories.user-repository_interface✕
- Connections
- 1 pair of types, where a type in domain.use-cases.user.create-user-use-case uses a type in domain.repositories.user-repository_interface.
- The types involved
src.domain.use-cases.user.create-user-use-case.CreateUserUseCase→src.domain.repositories.user-repository_interface.IUserRepository
- Direction
- domain.use-cases.user.create-user-use-case uses domain.repositories.user-repository_interface, so a change to domain.repositories.user-repository_interface can break domain.use-cases.user.create-user-use-case, while a change to domain.use-cases.user.create-user-use-case can't break domain.repositories.user-repository_interface.
- Position
- Below the diagonal: domain.use-cases.user.create-user-use-case uses a module listed above it, which is the healthy direction.
38→10 infra.auth.authenticator.jwt-authenticator uses domain.services.auth.authenticator_interface✕
- Connections
- 3 pairs of types, where a type in infra.auth.authenticator.jwt-authenticator uses a type in domain.services.auth.authenticator_interface.
- The types involved
src.infra.auth.authenticator.jwt-authenticator.JwtAuthenticator→src.domain.services.auth.authenticator_interface.AuthenticateResponsesrc.infra.auth.authenticator.jwt-authenticator.JwtAuthenticator→src.domain.services.auth.authenticator_interface.GetAuthenticatedUserResponsesrc.infra.auth.authenticator.jwt-authenticator.JwtAuthenticator→src.domain.services.auth.authenticator_interface.IAuthenticator
- Direction
- infra.auth.authenticator.jwt-authenticator uses domain.services.auth.authenticator_interface, so a change to domain.services.auth.authenticator_interface can break infra.auth.authenticator.jwt-authenticator, while a change to infra.auth.authenticator.jwt-authenticator can't break domain.services.auth.authenticator_interface.
- Position
- Below the diagonal: infra.auth.authenticator.jwt-authenticator uses a module listed above it, which is the healthy direction.
38→33 infra.auth.authenticator.jwt-authenticator uses domain.repositories.user-repository_interface✕
- Connections
- 1 pair of types, where a type in infra.auth.authenticator.jwt-authenticator uses a type in domain.repositories.user-repository_interface.
- The types involved
src.infra.auth.authenticator.jwt-authenticator.JwtAuthenticator→src.domain.repositories.user-repository_interface.IUserRepository
- Direction
- infra.auth.authenticator.jwt-authenticator uses domain.repositories.user-repository_interface, so a change to domain.repositories.user-repository_interface can break infra.auth.authenticator.jwt-authenticator, while a change to infra.auth.authenticator.jwt-authenticator can't break domain.repositories.user-repository_interface.
- Position
- Below the diagonal: infra.auth.authenticator.jwt-authenticator uses a module listed above it, which is the healthy direction.
39→9 infra.database.repositories.user-repository uses domain.models.user✕
- Connections
- 1 pair of types, where a type in infra.database.repositories.user-repository uses a type in domain.models.user.
- The types involved
src.infra.database.repositories.user-repository.UserRepository→src.domain.models.user.User
- Direction
- infra.database.repositories.user-repository uses domain.models.user, so a change to domain.models.user can break infra.database.repositories.user-repository, while a change to infra.database.repositories.user-repository can't break domain.models.user.
- Position
- Below the diagonal: infra.database.repositories.user-repository uses a module listed above it, which is the healthy direction.
39→11 infra.database.repositories.user-repository uses domain.services.security.encryptor_interface✕
- Connections
- 1 pair of types, where a type in infra.database.repositories.user-repository uses a type in domain.services.security.encryptor_interface.
- The types involved
src.infra.database.repositories.user-repository.UserRepository→src.domain.services.security.encryptor_interface.IEncryptor
- Direction
- infra.database.repositories.user-repository uses domain.services.security.encryptor_interface, so a change to domain.services.security.encryptor_interface can break infra.database.repositories.user-repository, while a change to infra.database.repositories.user-repository can't break domain.services.security.encryptor_interface.
- Position
- Below the diagonal: infra.database.repositories.user-repository uses a module listed above it, which is the healthy direction.
39→33 infra.database.repositories.user-repository uses domain.repositories.user-repository_interface✕
- Connections
- 1 pair of types, where a type in infra.database.repositories.user-repository uses a type in domain.repositories.user-repository_interface.
- The types involved
src.infra.database.repositories.user-repository.UserRepository→src.domain.repositories.user-repository_interface.IUserRepository
- Direction
- infra.database.repositories.user-repository uses domain.repositories.user-repository_interface, so a change to domain.repositories.user-repository_interface can break infra.database.repositories.user-repository, while a change to infra.database.repositories.user-repository can't break domain.repositories.user-repository_interface.
- Position
- Below the diagonal: infra.database.repositories.user-repository uses a module listed above it, which is the healthy direction.
40→12 tests.helpers uses tests.helpers.user-helpers✕
- Connections
- 1 pair of types, where a type in tests.helpers uses a type in tests.helpers.user-helpers.
- The types involved
src.tests.helpers.user-helpers→src.tests.helpers.user-helpers.CreateTestUserOptions
- Direction
- tests.helpers uses tests.helpers.user-helpers, so a change to tests.helpers.user-helpers can break tests.helpers, while a change to tests.helpers can't break tests.helpers.user-helpers.
- Position
- Below the diagonal: tests.helpers uses a module listed above it, which is the healthy direction.
40→36 tests.helpers uses tests.helpers.test-environment✕
- Connections
- 2 pairs of types, where a type in tests.helpers uses a type in tests.helpers.test-environment.
- The types involved
src.tests.helpers.test-helpers→src.tests.helpers.test-environment.TestEnvironmentsrc.tests.helpers.user-helpers→src.tests.helpers.test-environment.TestEnvironment
- Direction
- tests.helpers uses tests.helpers.test-environment, so a change to tests.helpers.test-environment can break tests.helpers, while a change to tests.helpers can't break tests.helpers.test-environment.
- Position
- Below the diagonal: tests.helpers uses a module listed above it, which is the healthy direction.
At a glance — Code Health
The Good
D1 · TypeScript
Cyclomatic Complexity
10.0
D2 · TypeScript
Cognitive Complexity
10.0
D3 · TypeScript
God Classes
10.0
D17 · TypeScript
Explicit Debt
10.0
GD1 · Repo
Unfinished & placeholder code
10.0
IC1 · Repo
Incompleteness & stubs
10.0
R1 · React / TS
Type Safety
10.0
R10 · React / TS
Code Duplication
9.0
R2 · React / TS
Cyclomatic Complexity
10.0
R3 · React / TS
Large Files
10.0
R7 · React / TS
Dead Code
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
X28 · Repo
Index access outside its own emptiness guard
10.0
X29 · Repo
Per-element action decided by a fixed element
10.0
X3 · Repo
Exception handling
10.0
X30 · Repo
Support guard that admits what it rejects
10.0
X5 · Repo
Nullable reference types
10.0
At a glance — Architecture
The Good
D6 · TypeScript
Cohesion (LCOM4)
10.0
D26 · TypeScript
Project Cohesion
10.0
D35 · TypeScript
Change Coupling
10.0
AX10 · Repo
Code composition
8.0
AX3 · Repo
Project dependency cycles
10.0
AX4 · Repo
Dependency direction
10.0
AX5 · Repo
Architecture & structure
10.0
AX6 · Repo
Interface segregation
10.0
R11 · React / TS
Import Boundaries
10.0
R9 · React / TS
Circular Imports
10.0
At a glance — Maturity
The Good
At a glance — Readiness
The Good
D8 · TypeScript
Code Coverage
9.8
D9 · TypeScript
Test Distribution
8.9
D10 · TypeScript
Test Quality
10.0
D11 · TypeScript
Test Reliability
10.0
D12 · TypeScript
Dependency Hygiene
9.2
D13 · TypeScript
Secret Scanning
10.0
D14 · TypeScript
License Compliance
10.0
P1 · Repo
CI/CD gates
10.0
P2 · Repo
Observability
8.0
P4 · Repo
Deployment & Rollback
8.0
P8 · Repo
Schema migrations
10.0
P9 · Repo
Domain vs controller coverage
9.5
R4 · React / TS
Test Coverage
9.6
R6 · React / TS
Tooling
10.0
R8 · React / TS
Dependency Hygiene
9.0
The Bad
At a glance — Security
The Good
D28 · TypeScript
Secrets (history)
10.0
D31 · TypeScript
IaC & Container Security
9.1
D43 · TypeScript
Malicious Dependencies
10.0
D44 · TypeScript
Platform End-of-Life
10.0
C2 · Repo
Access Controls
7.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 — Performance
Security & Compliance — OWASP Top-10 mapping
| OWASP category | Findings | Severity |
|---|---|---|
| A03:2025 — Software Supply Chain Failures | 24 | High / Critical |
| A05:2025 — Injection | 20 | High / Critical |
| A02:2025 — Security Misconfiguration | 7 | High / Critical |
Roadmap
First, strengthen data protection by fully encrypting sensitive columns and securely vaulting keys to eliminate coverage gaps. Next, integrate static analysis into the CI pipeline to block security regressions and immediately resolve high-severity dependency vulnerabilities. Finally, codify disaster recovery procedures in infrastructure-as-code and document key architectural decisions to ensure long-term maintainability and resilience.
| Do this | Helps | Effort | Dimension |
|---|---|---|---|
| Strengthen data-at-rest protection: vault your keys (AWS KMS / Secrets Manager, Azure Key Vault, GCP KMS / Secret Manager, HashiCorp Vault) and encrypt the most sensitive columns (typeorm-encrypted, prisma-field-encryption, mongoose-field-encryption or MongoDB CSFLE) — partial coverage still leaves gaps. | +5.2 pts | Medium | Data Protection |
| Resolve the 5 Deprecated finding(s) in Dependency Hygiene — start with REDACTED (5). | +2.2 pts | Low | Dependency Hygiene |
| Add a SAST step to CI running what this repository's stack ships: CodeQL's javascript-typescript pack, `semgrep --config=p/typescript`, or eslint-plugin-security — so a security regression fails the build instead of landing. | +3.9 pts | Medium | Security & performance tooling |
| Codify backups + geo-recovery in IaC and document RTO/RPO and the restore procedure — a persistence guard alone is not disaster recovery. | +3.9 pts | Medium | DR & Backup |
| Resolve the 14 High CVE finding(s) in Dependency Vulnerabilities — start with REDACTED (14). | +2.4 pts | Medium | Dependency Vulnerabilities |
| 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. | +2.4 pts | Medium | Architecture documentation |
| Improve Documentation Quality — currently 7.0/10. | +2.0 pts | Medium | Documentation Quality |
| Name the access rules — roles/permissions declared once (a @Roles/@Permissions decorator with its guard, a CASL ability, a casbin model, or Supabase CREATE POLICY) and consulted where access is checked, so the rule set is reviewable and testable on its own. | +1.9 pts | Medium | Access Controls |
File quality
| File | Score | Band | Worst signal |
|---|---|---|---|
| REDACTED | 0.0 | Slop | Dependency Vulnerabilities: Critical CVE: REDACTED |
| REDACTED | 1.3 | Slop | Static Analysis (SAST): High: REDACTED |
| REDACTED | 1.4 | Slop | Static Analysis (SAST): High: REDACTED |
| REDACTED | 1.4 | Slop | Static Analysis (SAST): High: REDACTED |
| REDACTED | 3.4 | Mixed | IaC & Container Security: High IaC: REDACTED |
| REDACTED | 6.3 | Near-clean | IaC & Container Security: Medium IaC: REDACTED |
| REDACTED | 6.4 | Near-clean | Dependency Vulnerabilities: Medium CVE: REDACTED |
| src/app/server.ts | 8.5 | Near-clean | Code Coverage: Low coverage: src/app/server.ts |
| src/app/routers/api-router.ts | 8.5 | Near-clean | Code Coverage: Low coverage: src/app/routers/api-router.ts |
| src/app/routers/base-router.ts | 8.5 | Near-clean | Code Coverage: Low coverage: src/app/routers/base-router.ts |
| src/container/repositories/container.ts | 8.5 | Near-clean | Code Coverage: Low coverage: src/container/repositories/container.ts |
| src/container/services/container.ts | 8.5 | Near-clean | Code Coverage: Low coverage: src/container/services/container.ts |
| src/infra/auth/authenticator/jwt-authenticator.ts | 8.5 | Near-clean | Code Coverage: Low coverage: src/infra/auth/authenticator/jwt-authenticator.ts |
| src/infra/logger/console-logger.ts | 8.5 | Near-clean | Code Coverage: Low coverage: src/infra/logger/console-logger.ts |
| src/tests/unit/app/middlewares/error-middleware.test.ts | 9.3 | Near-clean | Test Quality: Mock-dominated test: Send BadRequest error if ZodError is thrown |
How the grades work
Critical — 33
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 — 36
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 — 34
Recorded, with no effect on how the codebase functions. Present so the survey is complete, not because it needs doing.
Could not be resolved — 9
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. 74 of 77 evaluated dimensions are computed purely by tools and static analysis (confidence 1.0); 3 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 — 77 dimensions across the health lenses
D1D2D3D6D8D9D10D11D12D13D14D15D17D19D21D26D28D29D30D31D34D35D43D44AX10AX3AX4AX5AX6C1C2DM6DM9GD1IC1M1M2M3M4P1P2P3P4P5P6P8P9PF3R1R10R11R2R3R4R6R7R8R9X1X12X13X14X15X16X17X18X19X21X22X23X24X25X28X29X3X30X5
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, 87 of 103 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 (4 contributor(s) across 102 commit(s) sampled, automation and bot accounts excluded). One of them holds 93% of the history; the other 3 hold 2.3% 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.
- D22 Internal API Consistency — 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. This repository's source is written only in languages whose packages are published through a manifest, and no manifest in the tree makes a publication act: either there is no package manifest of any ecosystem (no REDACTED, pyproject.toml, setup.py, gemspec, Cargo.toml, pom.xml, build.gradle, composer.json, pubspec.yaml or mix.exs), or every one present declares in its package manager's own terms that it is not published (an npm package marked "private": true, a Cargo package with publish = false, a pubspec with publish_to: none, a Composer "project", a Poetry project with package-mode = false, or the "Private :: Do Not Upload" classifier). With no publication act there is no intentionally-exposed surface for API consistency to be judged over.
- 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.
- D32 Data Compliance (PII/GDPR) — 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. `src/core/lang/brand.ts` produced a parse error, so every rule in this engine's `gdpr.yml` was absent there. That absence is NOT a clean result: these rules detect personal data crossing a boundary into a log sink, a URL or browser storage, and a file that was never parsed cannot report any of the three. The rest of the tree analysed normally and its rows above stand; only these files are unaccounted for. You can widen what we reach: fix the syntax error (or exclude the file deliberately) and re-scan to cover it.
- AX1 Captive dependencies — 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 Microsoft.Extensions.DependencyInjection registrations in C# and Spring beans in Java/Kotlin only, and this repository's container is InversifyJS, whose lifetimes are not modelled 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.
- 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 15 — the compose project is invalid) — time="2026-10-21T22:44:46Z" level=warning msg="The \"DB_PORT\" variable is not set. Defaulting to a blank string." time="2026-10-21T22:44:46Z" level=warning msg="The \"DB_PASSWORD\" variable is not set. Defaulting to a blank string." time="2026-10-21T22:44:46Z" level=warning msg="The \"TEST_DB_NAME\" variable is not set. Defaulting to a blank string." no port specified: :<empty>; runtime evidence skipped.
- DM9 Scattered domain decisions — 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. Arm two tells a construction that PRODUCES a measurement from one that merely passes it along, and this repository's frontend does not compute that fact. A measurement built independently in two places would not appear above.
- S1 Web-Security Posture — 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. 56 JavaScript/TypeScript file(s) were read for weak hashes and ciphers, key material fixed in the source, disabled certificate validation and obsolete TLS versions, and none was found. The server controls this dimension also scores were not assessed, so no score is given.
- X2 Cancellation propagation — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check reads C# syntax, and JavaScript/TypeScript, Go, PHP, Dart, Kotlin, Ruby, Scala, Java, Python and Rust source only, and no C# was loaded, and no named async function in this repository's JavaScript/TypeScript, nor any Go, PHP or Dart function or Kotlin suspend function, makes a request that can be cancelled (fetch, axios, ky, ofetch; net/http, net.Dial; amphp; Dio; Ktor, OkHttp), so there is nothing to judge, 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.
- X4 Structured logging — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check reads C# syntax, and JavaScript/TypeScript, Java, Kotlin, Python, PHP, Dart, Ruby, Scala and Rust source only, and no C# was loaded, and this repository's JavaScript/TypeScript, Python and PHP log through no library that carries a message's values as fields (pino, winston, bunyan, tslog, LogTape, roarr; Python's logging, structlog; PHP's PSR-3 loggers), so its log calls cannot be judged, 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.
- 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.
- D10 Test Quality: Assertion density is structural — it cannot tell a meaningful behavioural assertion from a trivial one, only that an assertion is present.
- D11 Test Reliability: Flakiness is inferred from history/markers — Watchdog runs the suite once (for coverage), not the repeated runs under varied conditions that reveal nondeterminism, so a flaky test never recorded as failing is invisible here.
- D12 Dependency Hygiene: Dependency health reads manifests and lockfiles — a vulnerability in a vendored/copied dependency, or risk from how a dependency is actually used, is outside this view.
- D13 Secret Scanning: Secret detection is signature- and entropy-based on the current tree — a secret that does not match a known pattern, or one already rotated, will not be flagged (a clean scan is "nothing matched", not "no secrets exist").
- D14 License Compliance: License compatibility is checked against declared package metadata and a policy — mislabelled or missing license metadata, and obligations that depend on how you distribute, are not resolved here.
- D15 Churn × Complexity Hotspots: Churn hotspots come from git history — a freshly imported or squashed repository has no churn signal, and recent rewrites can mask a historically risky file.
- D17 Explicit Debt: Acknowledged-debt signals (TODO/FIXME, suppressions, dead code) are textual — undocumented debt that nobody marked, and debt that lives in design rather than annotations, is invisible. Committed machine-written code (scaffolded migrations, designer/codegen output, generated stubs) is excluded — it is never the team's dead code to delete.
- D19 Documentation Quality: Documentation quality is judged by an LLM over a bounded sample of docs — it reads what is written, not whether the docs match the running system, and it is advisory, not a measurement. Its critique rows are drawn from a closed category vocabulary and each row means the same thing in every run, so two scans can be compared row by row; the SET that fires is still a sample, and does not repeat exactly. Measured on one frozen input, six scans at one engine SHA: 2-5 critique rows per scan, 8 distinct rows across the six, 3 of those 8 seen in only one scan. So a D19 row is evidence about the documentation, but a COUNT of D19 rows is not a quantity — never read a change in it as an improvement or a regression.
- D21 Naming Consistency: Naming quality is an LLM judgement over a bounded sample — it assesses clarity/consistency of the names it sees, not domain-correctness, and is advisory.
- 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.
- D44 Platform End-of-Life: The support table is FROZEN, so it goes out of date by losing RECALL: a release that ended support after the table was written is missed until the table is refreshed, and this dimension reading 10 is not evidence that a platform is current. Only platforms the repository DECLARES in a place this pass reads are seen — a runtime named only in a REDACTED (D31's subject), in a CI workflow (D29's), or in a file this pass does not parse (go.mod, a Gemfile ruby directive) is invisible here, which is why a repository declaring none of them abstains rather than scoring. Only frameworks with a PUBLISHED support policy are tracked: React, Flask and Express publish none, so their age cannot be judged and their absence from a report is not a statement that they are supported.
- 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.
- DM6 Domain ↔ infrastructure boundary: Infrastructure reached through a hand-rolled wrapper, a domain-named facade, reflection, or a string-keyed service locator resolves to a non-infra type and isn't seen; the body scan is symbol resolution over syntax, not full dataflow. A clean result means "no resolved infra reference in a domain body", not a proof of purity.
- M4 Documentation accuracy: Onboarding quality is an LLM read of the docs/setup present — it cannot run the onboarding or measure how long a real new joiner takes; the verdict is sampled and advisory.
- P4 Deployment & Rollback: Approval/branch-protection rules live in repository settings the scan cannot see — only their in-repo evidence (config files, workflows) is checked, so a control enforced purely in the host's settings reads as "not evidenced".
- P5 DR & Backup: Backup/restore and disaster-recovery readiness is judged from in-repo evidence — a config that exists is not a tested restore, so the absence of positive evidence is reported as "not evidenced", never scored as present.
- P6 Release Hygiene: Rollback/observability controls are inferred from repo artefacts (pipelines, dashboards-as-code) — controls configured in external tooling, with no in-repo trace, cannot be credited.
The LLM boundary
Dimensions
D1 · Cyclomatic Complexity
0 method(s) exceeded the cyclomatic complexity threshold of 15.
Do you agree with this assessment?
D2 · Cognitive Complexity
0 method(s) exceeded the cognitive complexity threshold of 15.
Do you agree with this assessment?
D3 · God Classes
0 god class(es) detected.
Do you agree with this assessment?
D6 · Cohesion (LCOM4)
0 of 12 classes have LCOM4 above 3.
Do you agree with this assessment?
D8 · Code Coverage
Line coverage 75.0% — 7 file(s) below 50%. Measured from the JavaScript/TypeScript suite (jest via `yarn install --frozen-lockfile --ignore-scripts` in the repository root).
Low coverage: src/app/server.ts src/app/server.ts:1
What to do
- Resolve the 7 Low coverage finding(s) in Code Coverage — start with container.ts (2), server.ts, api-router.ts. — One of this dimension's main actionable groups (7 warning-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
70 test methods: 64 unit, 0 integration, 0 BDD, 6 e2e. The JavaScript/TypeScript suite contributes 70 `it`/`test` case(s) across 17 test file(s) declaring at least one; its tier split is read from package names and paths only.
What to do
- Improve Test Distribution — currently 8.9/10. — 70 test methods: 64 unit, 0 integration, 0 BDD, 6 e2e. The JavaScript/TypeScript suite contributes 70 `it`/`test` case(s) across 17 test file(s) declaring at least one; its tier split is read from package names and paths only.
Do you agree with this assessment?
D10 · Test Quality
0 skipped, 0 zero-assertion, no mocking-framework packages referenced (hand-written doubles or no mocking) across 70 tests.
Mock-dominated test: Send BadRequest error if ZodError is thrown src/tests/unit/app/middlewares/error-middleware.test.ts:9
Do you agree with this assessment?
D11 · Test Reliability
0 flaky across 1 measured tier(s). JavaScript/TypeScript (jest via `yarn install --frozen-lockfile --ignore-scripts` in the repository root (70 tests)): measured (0 flaky).
Do you agree with this assessment?
D12 · Dependency Hygiene
7 outdated direct production npm dependency(ies) of 14 graded, 0 pinning defect(s), across 1 REDACTED (1 of them the product) and 1 committed lockfile(s). Development dependencies are deliberately not graded for currency: that grade is about what SHIPS. 1 direct dependency(ies) — production, development or optional — are marked DEPRECATED by their publisher (the registry's per-version mark, or the lockfile's copy of it when the registry could not be asked); deprecated transitive packages are listed but not charged. Whether any is UNMAINTAINED is not graded — the registry publishes no maintenance status, and release age does not stand in for one. Whether any is UNUSED is not graded either: that is a source question, and the frontend dependency lens (R8) answers it in this same run. Known CVEs in this dependency graph are D30's question, read from the manifest there.
Deprecated: @types/bcryptjsREDACTED:46
Deprecated: @ungap/structured-clone REDACTED:1399
Outdated (npm): dotenv
What to do
- Resolve the 5 Deprecated finding(s) in Dependency Hygiene — start with REDACTED (5). — One of this dimension's main actionable groups (5 recommendation-level).
- Resolve the 1 Deprecated finding(s) in Dependency Hygiene — start with REDACTED. — One of this dimension's main actionable groups (1 warning-level).
- Enforce Dependency Hygiene 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?
D13 · Secret Scanning
Secret scan ran and found no leaked secrets.
Do you agree with this assessment?
D14 · License Compliance
0 of 14 shipped npm package(s) use a banned license. Licences were resolved from registry.npmjs.org over the 14 production dependency(ies) this repository's committed lockfile resolves, across 1 product REDACTED manifest(s). Its 25 `devDependencies` declaration(s) are excluded: a consumer installs none of them. ★ DEPTH: this is the DIRECT production set the lockfile resolves, NOT the transitive closure — only one of the four lock dialects this pass reads states a full graph, so a banned licence pulled in only by a dependency's OWN dependencies is outside this verdict, exactly as the JVM arm's declaration-site verdict is. ★ Each licence is the one the registry publishes for the package's CURRENT release rather than for the pinned version, which is the same caveat the Hex and RubyGems arms carry. This repository publishes itself under MIT, which is its own choice and is not judged here.
Do you agree with this assessment?
D15 · Churn × Complexity Hotspots
No churn × complexity hotspots in the window.
Do you agree with this assessment?
D17 · Explicit Debt
0 deducted task-comment markers across 1452 LoC (0.0/KLoC) → score 10.0. Task comments only: this repository's language is read without a compiler, so D17's suppression, dead-code and commented-out-code arms did not run and this score counts fewer marker kinds than a .NET repository's would.
Do you agree with this assessment?
D19 · Documentation Quality
The repository's root README is clear and well structured: it opens with an expressive cover image and a one-line description of the project (a modern TypeScript boilerplate for scalable REST APIs), then states its main goal before diving into an overview that lists features such as Docker containerization, PostgreSQL database connection, JWT authentication, centralized error handling, Clean Architecture principles, and ends with a StackShare badge. The document is clipped mid-outline at 'Running migrations manually' (Step 5) by the scanner, so any unshown sections in the outline are not flagged; it is clear from what appears that the README covers installation, usage, contribution guidance, and licensing.
What to do
- Improve Documentation Quality — currently 7.0/10. — The repository's root README is clear and well structured: it opens with an expressive cover image and a one-line description of the project (a modern TypeScript boilerplate for scalable REST APIs), then states its main goal before diving into an overview that lists features such as Docker containerization, PostgreSQL database connection, JWT authentication, centralized error handling, Clean Architecture principles, and ends with a StackShare badge. The document is clipped mid-outline at 'Running migrations manually' (Step 5) by the scanner, so any unshown sections in the outline are not flagged; it is clear from what appears that the README covers installation, usage, contribution guidance, and licensing.
Do you agree with this assessment?
D21 · Naming Consistency
0 naming inconsistencies across 0 sampled symbols.
Do you agree with this assessment?
D26 · Project Cohesion
0 of 1 build units (npm) flagged as possibly oversized/incoherent.
Do you agree with this assessment?
D28 · Secrets (history)
gitleaks scanned the full history AND the current working tree and found no secrets.
Do you agree with this assessment?
D29 · Static Analysis (SAST)
20 finding(s): 0 critical, 16 high, 4 medium, 0 low. 14 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) — `src/core/lang/brand.ts` (line 1) — so no absence of findings in the named regions is evidence of anything; rows reported elsewhere in those files are real. Fix the syntax error (or exclude the file deliberately) and re-scan to cover them.
REDACTED
REDACTED
REDACTED
REDACTED
What to do
- Resolve the 2 REDACTED finding(s) in Static Analysis (SAST) — start with REDACTED, REDACTED. — One of this dimension's main actionable groups (2 issue-level).
- Resolve the 2 REDACTED finding(s) in Static Analysis (SAST) — start with REDACTED (2). — One of this dimension's main actionable groups (2 warning-level).
- No action in Static Analysis (SAST) — all 14 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 (14 issue-level, 0 of them charged here).
Do you agree with this assessment?
D30 · Dependency Vulnerabilities
24 finding(s): 2 critical, 14 high, 5 medium, 3 low.
REDACTED
REDACTED
REDACTED
REDACTED
REDACTED
What to do
- Resolve the 14 High CVE finding(s) in Dependency Vulnerabilities — start with REDACTED (14). — One of this dimension's main actionable groups (14 issue-level).
- Resolve the 2 Critical CVE finding(s) in Dependency Vulnerabilities — start with REDACTED (2). — One of this dimension's main actionable groups (2 issue-level).
- Resolve the 4 Medium CVE finding(s) in Dependency Vulnerabilities — start with REDACTED (3), REDACTED. — One of this dimension's main actionable groups (4 warning-level).
Do you agree with this assessment?
D31 · IaC & Container Security
7 finding(s): 0 critical, 1 high, 5 medium, 1 low.
REDACTED
REDACTED
REDACTED
What to do
- Resolve the 1 High IaC finding(s) in IaC & Container Security — start with REDACTED. — One of this dimension's main actionable groups (1 issue-level).
- Resolve the 5 Medium IaC finding(s) in IaC & Container Security — start with REDACTED (3), REDACTED (2). — One of this dimension's main actionable groups (5 warning-level).
- Resolve the 1 Low IaC finding(s) in IaC & Container Security — start with REDACTED. — One of this dimension's main actionable groups (1 recommendation-level).
Do you agree with this assessment?
D34 · Knowledge Freshness
Every significant source file has living knowledge — recently and meaningfully worked. Counted over 4 of the 59 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
No strong hidden change-coupling between production files.
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?
D44 · Platform End-of-Life
0 end-of-life runtime(s) and 0 end-of-life framework(s), read from 0 platform declaration(s) and 14 dependency declaration(s). This dimension reads what the repository says about ITSELF — a pinned target framework, a version file, a capped requires-python, a Rust toolchain pin, a framework major a constraint cannot move off. A FLOOR is deliberately never charged: `requires-python = ">=3.8"` states what the package SUPPORTS, not what it runs on, and a well-maintained library declares exactly that while running its own CI on a current release. The end-of-life facts are FROZEN and dated, so this dimension needs no network and answers identically inside a closed scan fence; as the table ages it loses recall and never precision, because a statement about support that ended in the past cannot become false. The OS layer of a container image is D31's question and the toolchain a CI workflow installs is D29's; this row is neither.
Do you agree with this assessment?
Frontend & cross-cutting dimensions
AX10 · Code composition
Do you agree with this assessment?
AX3 · Project dependency cycles
Do you agree with this assessment?
AX4 · Dependency direction
Do you agree with this assessment?
AX5 · Architecture & structure
Do you agree with this assessment?
AX6 · Interface segregation
Do you agree with this assessment?
C1 · Data Protection
What to do
- Strengthen data-at-rest protection: vault your keys (AWS KMS / Secrets Manager, Azure Key Vault, GCP KMS / Secret Manager, HashiCorp Vault) and encrypt the most sensitive columns (typeorm-encrypted, prisma-field-encryption, mongoose-field-encryption or MongoDB CSFLE) — partial coverage still leaves gaps.
- Enforce HTTPS (serve through https.createServer / NestJS httpsOptions, or redirect plain HTTP with express-sslify behind your TLS terminator) so data in transit is always encrypted.
Do you agree with this assessment?
C2 · Access Controls
- Authorization IS enforced here (by route guards, auth middleware or checks that refuse a caller) — this is NOT a claim that endpoints are unprotected. What's missing is a NAMED rule set: who may do what is encoded inline where it is checked, so the rules can't be listed, reviewed or tested apart from the code that applies them. Recommendation, not a defect.
What to do
- Name the access rules — roles/permissions declared once (a @Roles/@Permissions decorator with its guard, a CASL ability, a casbin model, or Supabase CREATE POLICY) and consulted where access is checked, so the rule set is reviewable and testable on its own.
Do you agree with this assessment?
DM6 · Domain ↔ infrastructure boundary
Do you agree with this assessment?
DM9 · Scattered domain decisions
Do you agree with this assessment?
GD1 · Unfinished & placeholder code
Do you agree with this assessment?
IC1 · Incompleteness & stubs
Do you agree with this assessment?
M1 · Documentation (README)
Do you agree with this assessment?
M2 · Architecture documentation
- No Architecture Decision Records found — no conventional ADR directory, no numbered `NNNN-title` documents in any markup this check reads, and nothing ADR-shaped by content. Design rationale recorded elsewhere (a design-notes tree, a mailing list, pull-request discussion) is not visible to this check and is not re-findable per decision, so a future maintainer cannot ask why one choice was made and get an answer.
What to do
- Record your significant design decisions. Write one short document per decision, giving its date, the situation, the decision and its consequences, and keep them together with your other design documents. A docs/adr folder with each file named by number and title is the easiest place to find them.
Do you agree with this assessment?
M3 · Folder & project structure
Do you agree with this assessment?
M4 · Documentation accuracy
- CONTRIBUTING.md links to `LICENSE.txt`, but `LICENSE.txt` does not exist. Checked without a model against the repository: its files and folders, the scripts and dependencies of every REDACTED, 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. — CONTRIBUTING.md:45
- README.md documents the environment variable `ISSUE_TEMPLATE`, but no code, script or configuration file names it. Checked without a model against the repository: its files and folders, the scripts and dependencies of every REDACTED, the projects, namespaces, package references and target frameworks of the .NET build, the SDK and Node pins, and the identifiers of every file that is not a document; the documents' own text never counts. A footprint generated at build time, read only by a platform, or living outside this repository is not seen, and this row is then wrong. — README.md:534
- README.md documents the environment variable `CODE_OF_CONDUCT`, but no code, script or configuration file names it. Checked without a model against the repository: its files and folders, the scripts and dependencies of every REDACTED, the projects, namespaces, package references and target frameworks of the .NET build, the SDK and Node pins, and the identifiers of every file that is not a document; the documents' own text never counts. A footprint generated at build time, read only by a platform, or living outside this repository is not seen, and this row is then wrong. — README.md:552
What to do
- Reconcile the README with reality: CONTRIBUTING.md links to `LICENSE.txt`, but `LICENSE.txt` does not exist; README.md documents the environment variable `ISSUE_TEMPLATE`, but no code, script or configuration file names it; README.md documents the environment variable `CODE_OF_CONDUCT`, but no code, script or configuration file names it.
Do you agree with this assessment?
P1 · CI/CD gates
Do you agree with this assessment?
P2 · Observability
- `src/infra/logger/console-logger.ts` reports through `console.*` at line 10 although other files in its module log through a logger. Console lines carry no level, fields or correlation and never reach the log pipeline. — src/infra/logger/console-logger.ts:10
- `src/infra/logger/console-logger.ts` reports through `console.*` at line 12 although other files in its module log through a logger. Console lines carry no level, fields or correlation and never reach the log pipeline. — src/infra/logger/console-logger.ts:12
- `src/infra/logger/console-logger.ts` reports through `console.*` at line 18 although other files in its module log through a logger. Console lines carry no level, fields or correlation and never reach the log pipeline. — src/infra/logger/console-logger.ts:18
- `src/infra/logger/console-logger.ts` reports through `console.*` at line 20 although other files in its module log through a logger. Console lines carry no level, fields or correlation and never reach the log pipeline. — src/infra/logger/console-logger.ts:20
- `src/infra/logger/console-logger.ts` reports through `console.*` at line 26 although other files in its module log through a logger. Console lines carry no level, fields or correlation and never reach the log pipeline. — src/infra/logger/console-logger.ts:26
- `src/infra/logger/console-logger.ts` reports through `console.*` at line 28 although other files in its module log through a logger. Console lines carry no level, fields or correlation and never reach the log pipeline. — src/infra/logger/console-logger.ts:28
- `src/infra/logger/console-logger.ts` reports through `console.*` at line 34 although other files in its module log through a logger. Console lines carry no level, fields or correlation and never reach the log pipeline. — src/infra/logger/console-logger.ts:34
- `src/infra/logger/console-logger.ts` reports through `console.*` at line 36 although other files in its module log through a logger. Console lines carry no level, fields or correlation and never reach the log pipeline. — src/infra/logger/console-logger.ts:36
What to do
- Route service-code `console.*` output through the module's structured logger (with named fields), so delivery outcomes and failures reach the log pipeline with a level.
- Add OpenTelemetry tracing/metrics (@opentelemetry/sdk-node) so requests are traceable across the system, not just health-probable.
Do you agree with this assessment?
P3 · Security & performance tooling
- No static application security testing detected. For this repository's stack, add CodeQL's javascript-typescript pack, `semgrep --config=p/typescript`, or eslint-plugin-security as a CI step. What was searched, so you can tell an absence from a miss: the 5990 CI workflow file(s) in this repository, and the scanner and linter configuration checked in beside them. A scan that runs outside CI, one configured in your forge's web UI rather than in a committed file, or a tool whose name is none of those this check carries, is not seen — if that is your case the row is wrong, and saying so is more useful than adding a second scanner.
What to do
- Add a SAST step to CI running what this repository's stack ships: CodeQL's javascript-typescript pack, `semgrep --config=p/typescript`, or eslint-plugin-security — so a security regression fails the build instead of landing.
- Enable Dependabot/Renovate or a dependency-review gate.
- Add gitleaks/trufflehog in CI to block PRs that introduce committed secrets.
Do you agree with this assessment?
P4 · Deployment & Rollback
What to do
- Add an approval/environment gate (required reviewers / protection rules) before production promotion.
Do you agree with this assessment?
P5 · DR & Backup
- A persistence guard (data volume / purge-protection) was found, but no backup, geo-recovery or RTO/RPO controls were evidenced — a volume that survives a container recreate is not a tested restore from catastrophic loss.
What to do
- Codify backups + geo-recovery in IaC and document RTO/RPO and the restore procedure — a persistence guard alone is not disaster recovery.
Do you agree with this assessment?
P6 · Release Hygiene
- No CHANGELOG/HISTORY/RELEASES file — what shipped when isn't easy to reconstruct for support or audit. (Versioning/tagging makes releases traceable, but a changelog records the what.)
What to do
- Keep a changelog (e.g. Keep-a-Changelog) recording what shipped in each release.
Do you agree with this assessment?
P8 · Schema migrations
Do you agree with this assessment?
P9 · Domain vs controller coverage
What to do
- Raise domain coverage toward 100% — cover the remaining aggregates / value objects / domain services where the business invariants and costly bugs live.
Do you agree with this assessment?
PF3 · Async & latency hygiene
Do you agree with this assessment?
R1 · Type Safety
Do you agree with this assessment?
R10 · Code Duplication
- 9 duplicated blocks under src/container/ have copies in at least two of the sibling directories core, middlewares, repositories, request-handlers, routers, services (+1 more sibling(s) not listed) — 2 of them are reported below, and 7 are counted here but not reported individually: those copies match on shape but no longer clear R10's bar for an individually reported row — either they kept neither their own names nor their values, or what was copied is too small to stand on its own (it reports near-exact duplication only, and only of substantial extent). What this row states is the concentration, which the detector measured over all 9 and which does not depend on how exactly each block's copies still match. That concentration is one structural fact, not 9 local ones: the siblings replicate behaviour none of them owns, which is the shape of a missing shared module — a common library every sibling imports — rather than 9 separate extractions. Check first whether the siblings are deliberately standalone deliverables (scaffold templates, demo apps that must stay copy-pasteable); where they are, the duplication is the design and the per-block rows are the ones to act on. — src/container/middlewares/container.ts:9
- src/container/middlewares/container.ts:9 · src/container/request-handlers/container.ts:9 — the 2 copies are spread across 2 directories, so the shared home is a decision rather than an obvious spot: check first whether one of them already owns this behaviour, and otherwise put the extracted module somewhere all of the sites already reach rather than making one of them depend on another. — src/container/middlewares/container.ts:9
- src/app/routers/health-router.ts:7 · src/app/routers/users-router.ts:7 — the 2 copies are spread across 2 files, and each CITED SPAN is a SPECIALISATION DECLARATION — a type whose `extends` clause names a base and whose body hands that base its own values through `super(…)`. The shared module this dimension usually asks you to extract already exists: it is that base, every one of these sites already reaches it, and the `super(…)` call this row matched on is where each site passes its differences in. So do not read this as an extract-a-helper row — there is no missing helper, and what is left at each site is the declaration of one distinct specialisation, which cannot be deleted without deleting the thing it declares. Read what actually differs between the spans, because two different answers follow. Where the sites differ only in the values they hand the base — a type argument, a service, an alias, a cache — the repetition is a TEMPLATE, and the only moves that collapse it are to generate these declarations from the set they enumerate or to replace the repeated construction with one factory each site calls with its own values; where that set is the point, each site pinning one distinct thing, the repetition IS the enumeration and there is nothing to remove. Where instead a span carries logic OUTSIDE the delegation that is the same at every site, that logic is the part to move, and its home is the base type rather than a new module. Reported because the copies still drift apart the first time only one of them is edited. — src/app/routers/health-router.ts:7
- src/container/core/container.ts:9 · src/container/middlewares/container.ts:6 · src/container/repositories/container.ts:3 · src/container/request-handlers/container.ts:6 · +3 more site(s) not listed — the 7 copies are spread across 7 files, and the SHAPE of this repetition could not be determined. It is not a run of declarations, a listing, a declaration header, a type body or a slice through a construct — and it was not measured as a run of executable statements either, so this row cannot tell you whether a function can stand where these lines are. Read the two spans before acting, because the move is opposite in the two cases. Where they are statements, the ordinary answer holds: give the shared part one home and call it from each site. Where they turn out to be declarations, a literal's entries, or the cases of an enumeration, there is no call site to call anything from, and collapsing them would delete what each copy pins — a shared base type, a generated set, or one exported constant each site refers to is the move instead, and sometimes the honest answer is that there is nothing to extract at all. Reported because the copies drift apart the first time only one of them is edited, which is true whichever of those they are. — src/container/core/container.ts:9
- src/container/services/container.ts:68 · src/infra/database/config/drizzle.config.ts:5 — the two spans are one implementation copied and then locally edited — 69 tokens are still identical, in the same order in both files, with only local edits between them. The copies have already begun to drift, which is this row's finding: an edit made to one and not the other changes behaviour silently. Diff the two spans first to learn what genuinely differs, then extract the shared core into one module both sites use, passing the differences in as parameters — or, if one copy exists only because the other could not be imported from its context, make one of them the single source the other is generated or re-exported from. If one copy is no longer reachable, delete it rather than letting it shadow the live one. — src/container/services/container.ts:68
What to do
- Act on each finding's own remediation rather than one rule: the move depends on what recurs. Where the copies are executable blocks, give the shared part one home and call it from each site; where they are declarations, a listing, a specialisation already delegating to its base, or one shape repeated per entity, there is no call site and the move is a shared type, a generated set or a factory — sometimes there is nothing to extract.
Do you agree with this assessment?
R11 · Import Boundaries
Do you agree with this assessment?
R2 · Cyclomatic Complexity
Do you agree with this assessment?
R3 · Large Files
Do you agree with this assessment?
R4 · Test Coverage
- No test imports this module directly or transitively. Import reachability cannot see a test that executes a file by path instead of importing it, nor one that drives it through a running browser by navigating to a URL — if neither does, no test reaches this one. (×2) — src/domain/models/request-user.ts:1, src/app/index.ts:1
What to do
- Add tests that import the unreached modules (directly or through their public entry).
Do you agree with this assessment?
R6 · Tooling
Do you agree with this assessment?
R7 · Dead Code
Do you agree with this assessment?
R8 · Dependency Hygiene
- Declared in the root REDACTED but never imported anywhere in that package or its workspace members — no static import reaches it. Usually that is dead weight and attack surface, but two shapes are indistinguishable from source and are NOT dead: an optional or native peer that another dependency loads dynamically at runtime, and a package a build, docs or test step installs and invokes separately. Confirm which of the three this is before removing it. (×2)
What to do
- Remove unused dependencies, declare unlisted imports explicitly, and demote type-/test-only packages to devDependencies.
Do you agree with this assessment?
R9 · Circular Imports
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?
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
Do you agree with this assessment?
X30 · Support guard that admits what it rejects
Do you agree with this assessment?
X5 · Nullable reference types
Do you agree with this assessment?
Reference — by lens
| Lens | Score | Rating | Impact |
|---|---|---|---|
| Code Health | 97% | Exemplary | Solid. |
| Architecture | 69% | Strong | Solid. |
| Maturity | 55% | Adequate — gated by M2 | Capped at Fair by a Critical contributor — resolve it before relying on this lens. |
| Readiness | 43% | Adequate — gated by P3, P5 | Capped at Fair by a Critical contributor — resolve it before relying on this lens. |
| Security | 45% | Weak — gated by D30, C1 | Capped at Fair by a Critical contributor — resolve it before relying on this lens. |
| Domain Modelling | 100% | Exemplary | Strongest area. |
| Performance | 100% | Exemplary | Solid. |
Unscored — 2 check(s) recorded observations but carry no score
- D36 Supply-chain Provenance & Signing — 3 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.
- P12 CI test-gate honesty — 1 observation(s) recorded · Reported, not scored — this card publishes what the CI gate does with the test inventory rather than grading it. The findings above are its output.
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, an ORM write hook that records changes — a TypeORM/MikroORM subscriber, a Sequelize or Mongoose hook, Prisma middleware — or a change-history plugin such as mongoose-history or sequelize-paper-trail) 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 — 57 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 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
- AX2 Stateful singletons — Not applicable: 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).
- AX7 Slice cohesion — not applicable — not a vertical-slice architecture
- AX8 Test isolation — no test/production split to check
- AX9 CQS / query purity — no CQRS query handlers detected — query purity is not applicable to this codebase
- 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 15 — the compose project is invalid) — time="2026-10-21T22:44:46Z" level=warning msg="The \"DB_PORT\" variable is not set. Defaulting to a blank string." time="2026-10-21T22:44:46Z" level=warning msg="The \"DB_PASSWORD\" variable is not set. Defaulting to a blank string." time="2026-10-21T22:44:46Z" level=warning msg="The \"TEST_DB_NAME\" variable is not set. Defaulting to a blank string." no port specified: :<empty>; 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.
- 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.
- D20 ADR Quality — N/A — this repo declares itself a template / kata / sample / demo; a formal ADR log is deferred to a real application built from it.
- D22 Internal API Consistency — No intentionally-exposed public API to evaluate for consistency.
- 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 (.ts), 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) — 1 file(s) were not parsed by semgrep — the PII/GDPR ruleset never ran over them
- 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.
- D4 Code Duplication — This repository's production source (.ts) is not read by D4's token comparison, which compares .NET source: duplication in it is measured by R10 Code Duplication, the frontend lens's card running the same clone algorithm over the JS/TS token stream. Not scored here — read the R10 card for this repository's duplication.
- 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.
- D5 Coupling — Not applicable — this npm build ships 1 production module(s), so there is no coupling BETWEEN modules to measure. (Its test and non-production modules are not part of the shipped graph.)
- 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 — not applicable: no DDD domain layer was detected (no aggregate, entity or value-object structure), so there is no domain model for this card to grade
- DM10 One transaction, one aggregate — not applicable: no DDD domain layer was detected (no aggregate, entity or value-object structure), so there is no domain model for this card to grade
- DM2 Strongly-typed ids — not applicable: no DDD domain layer was detected (no aggregate, entity or value-object structure), so there is no domain model for this card to grade
- DM3 Integration-event coupling — not applicable: no DDD domain layer was detected (no aggregate, entity or value-object structure), so there is no domain model for this card to grade
- DM4 Rich vs anemic model — not applicable: no DDD domain layer was detected (no aggregate, entity or value-object structure), so there is no domain model for this card to grade
- DM5 Encapsulated state — not applicable: no DDD domain layer was detected (no aggregate, entity or value-object structure), so there is no domain model for this card to grade
- DM7 Repository granularity — not applicable: no DDD domain layer was detected (no aggregate, entity or value-object structure), so there is no domain model for this card to grade
- ED1 Event-Driven — not scored — this repository shows only 1 of the 3 signals this lens looks for (4 CQRS handler(s))
- ED5 Idempotency — 4 mutating command handler(s)/consumer(s) detected and 4 handler method(s) walked, but no persistent write was recognised in any of them — idempotency not assessed
- ES1 Event Sourcing — not scored — this repository shows none of the 3 signals this lens looks for
- P7 Outbound HTTP resilience — no outbound HTTP usage detected — no HTTP client call or construction in the JavaScript/TypeScript source (service entry point: src/app/server.ts:22 (express()))
- PF1 Benchmark discipline — Not applicable: no benchmark suite was found. This check searched for tinybench, mitata, benchmark.js, benny or vitest `bench(...)` calls in files that import them (or `*.bench.*` files), or one of those in a REDACTED, 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: TypeScript/JavaScript runs on a garbage-collected runtime that gives a program no allocation-control idiom to choose on a hot path — no pools, stack allocation or value types — so allocation awareness is not something this code can be rated on.
- R5 Dependency Freshness — uses a yarn lockfile — dependency freshness not measured here; JS/npm CVEs are scored in D30 (Dependency Vulnerabilities), which answers every ecosystem
- S1 Web-Security Posture — Not assessed: 56 JavaScript/TypeScript file(s) were read for weak hashes and ciphers, key material fixed in the source, disabled TLS certificate validation and obsolete TLS versions, and none was found. That half of the dimension is clean, but it is not scored on its own: a C# repository with the same clean reading is scored on its server controls as well, or is N/A for having no web surface, and neither can be decided here. The server controls — HTTPS enforcement, HSTS, cookie flags, input validation — are NOT assessed for JavaScript/TypeScript: each is scored as an absence, an absence is only reportable over the production HTTP server, and in this ecosystem the file that opens the port is build output or a framework launcher rather than a file in the source tree. Their absence here is not a finding about this repository.
- SC1 Supply-chain hygiene — Advisory — this card reports evidence and never carries a score, so there is nothing missing here.
- X10 Duplicated predicate — Advisory — this card reports evidence and never carries a score, so there is nothing missing here.
- X2 Cancellation propagation — 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
- 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. 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.
- X27 Collection changed while being enumerated — Not applicable: this check looks for a loop whose body adds to or removes from the very collection the loop is walking, invalidating the enumerator it holds, and in this repository's languages that cannot happen. JavaScript and TypeScript have no iterator that a change can invalidate: an `Array` is walked by index against its live length, and a `Map` or `Set` by the ECMAScript specification's live entry list, so a body that adds to, removes from or empties what it walks raises nothing — every loop form (`for…of`, `for…in`, `forEach`, `map`, `filter`, `reduce`, `entries()`) on every built-in collection (`Array`, `Map`, `Set`, plain objects, `URLSearchParams`, `Headers`, `FormData`) runs to completion. Such a loop can still skip an element or never end, which is a different defect and not the one this check asks about. 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.
- X4 Structured logging — 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 — 33 finding(s)
D29 · Static Analysis (SAST)
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
D30 · Dependency Vulnerabilities
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
D29 · Static Analysis (SAST)
- REDACTED
- REDACTED
D30 · Dependency Vulnerabilities
- REDACTED
- REDACTED
D31 · IaC & Container Security
- REDACTED
Serious — 36 finding(s)
D8 · Code Coverage
- Low coverage: src/app/server.ts src/app/server.ts:1
- Low coverage: src/app/routers/api-router.ts src/app/routers/api-router.ts:1
- Low coverage: src/app/routers/base-router.ts src/app/routers/base-router.ts:1
- Low coverage: src/container/repositories/container.ts src/container/repositories/container.ts:1
- Low coverage: src/container/services/container.ts src/container/services/container.ts:1
- Low coverage: src/infra/auth/authenticator/jwt-authenticator.ts src/infra/auth/authenticator/jwt-authenticator.ts:1
- Low coverage: src/infra/logger/console-logger.ts src/infra/logger/console-logger.ts:1
D31 · IaC & Container Security
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
D30 · Dependency Vulnerabilities
- REDACTED
- REDACTED
- REDACTED
- REDACTED
D36 · Supply-chain Provenance & Signing
- REDACTED
- REDACTED
- REDACTED
D29 · Static Analysis (SAST)
- REDACTED
- REDACTED
D29 · Static Analysis (SAST)
- REDACTED
- REDACTED
R4 · Test Coverage
- No test reaches this file src/domain/models/request-user.ts:1
- No test reaches this file src/app/index.ts:1
D12 · Dependency Hygiene
- Deprecated: @types/bcryptjs REDACTED:46
D30 · Dependency Vulnerabilities
- REDACTED
P12 · CI test-gate honesty
- Coverage collected but not gated
P5 · DR & Backup
- No DR/backup evidence
R10 · Code Duplication
- Duplication concentrated across 7 sibling directories (9 clone groups) src/container/middlewares/container.ts:9
R10 · Code Duplication
- Duplicated block (33 lines × 2 locations) src/container/middlewares/container.ts:9
R10 · Code Duplication
- Duplicated block (11 lines × 2 locations) src/app/routers/health-router.ts:7
R10 · Code Duplication
- Duplicated block (11 lines × 7 locations) src/container/core/container.ts:9
R10 · Code Duplication
- Duplicated block with local edits (5 matched lines × 2 locations) src/container/services/container.ts:68
R8 · Dependency Hygiene
- Unused dependency 'tsconfig-paths'
R8 · Dependency Hygiene
- Unused dependency 'tslib'
Minor — 27 finding(s)
P2 · Observability
- Console output used as the logging channel src/infra/logger/console-logger.ts:10
- Console output used as the logging channel src/infra/logger/console-logger.ts:12
- Console output used as the logging channel src/infra/logger/console-logger.ts:18
- Console output used as the logging channel src/infra/logger/console-logger.ts:20
- Console output used as the logging channel src/infra/logger/console-logger.ts:26
- Console output used as the logging channel src/infra/logger/console-logger.ts:28
- Console output used as the logging channel src/infra/logger/console-logger.ts:34
- Console output used as the logging channel src/infra/logger/console-logger.ts:36
D12 · Dependency Hygiene
- Deprecated: @ungap/structured-clone REDACTED:1399
- Deprecated: glob REDACTED:2782
- Deprecated: glob REDACTED:2794
- Deprecated: inflight REDACTED:2941
- Deprecated: lodash.isequal REDACTED:3640
D30 · Dependency Vulnerabilities
- REDACTED
- REDACTED
- REDACTED
M4 · Documentation accuracy
- README/code drift CONTRIBUTING.md:45
- README/code drift README.md:534
- README/code drift README.md:552
D10 · Test Quality
- Mock-dominated test: Send BadRequest error if ZodError is thrown src/tests/unit/app/middlewares/error-middleware.test.ts:9
- Mock-dominated test: Send InternalServerError error if unknown error is thrown src/tests/unit/app/middlewares/error-middleware.test.ts:28
C2 · Access Controls
- No named authorization policies
D31 · IaC & Container Security
- REDACTED
D36 · Supply-chain Provenance & Signing
- REDACTED
M2 · Architecture documentation
- No ADRs
P3 · Security & performance tooling
- No SAST
P6 · Release Hygiene
- No changelog
Minor — 7 finding(s)
D12 · Dependency Hygiene
- Outdated (npm): dotenv
- Outdated (npm): express
- Outdated (npm): helmet
- Outdated (npm): inversify
- Outdated (npm): morgan
- Outdated (npm): pg
- Outdated (npm): zod
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-6dabb7a2a7134fee93f235c0ef79d653/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-6dabb7a2a7134fee93f235c0ef79d653/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 . | 20 | artifacts/raw/semgrep.json |
| D30 · Dependency Vulnerabilities | trivy | — | trivy fs --scanners vuln --format json --quiet --severity CRITICAL,HIGH,MEDIUM,LOW --skip-dirs **/bin/** --skip-dirs **/obj/** . --skip-db-update | 24 | artifacts/raw/trivy-fs.json |
| D31 · IaC & Container Security | trivy | — | trivy config --format json --quiet . | 7 | 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. semgrep could not parse 1 file(s) — `src/core/lang/brand.ts` — so the PII/GDPR sweep did not cover the unparsed regions of them; rows reported elsewhere in those files are real. | 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 | trivy | — | trivy fs --scanners vuln --format json --quiet --severity CRITICAL,HIGH,MEDIUM,LOW --skip-dirs **/bin/** --skip-dirs **/obj/** . --skip-db-update | 0 | artifacts/raw/trivy-fs.json |