souz4s/ts-clean-api

This system is a TypeScript/Node.js API service designed to manage user profiles and their associated musical genre preferences. It provides endpoints to create users, retrieve them by email, and update musical genre scores. The architecture follows a layered approach, separating domain logic, data access, and presentation concerns, supported by comprehensive unit and integration tests.

The application now includes a new database infrastructure layer that initializes and manages the Prisma ORM client. This change introduces a singleton-style wrapper that handles connecting to the database, retrieving the client instance, and gracefully disconnecting, providing a centralized way to manage the Prisma client lifecycle within the application.

src/infrastructure/db · high confidence

New protocol interfaces were added to the presentation layer: a generic Controller interface with a handle method returning a Promise of HttpResponse, and an HttpResponse type defining statusCode, message, and body. These are now exported from the protocols index.

src/presentation/protocols · high confidence

A new adapter has been introduced to bridge the application's internal controller layer with the Express.js HTTP server. The \expressRouterAdapter\ function wraps a controller, mapping incoming Express \Request\ and \Response\ objects to the controller's expected format and translating the controller's HTTP response back to the appropriate status code and JSON body. This enables the existing controller logic to be served directly via Express routes.

src/main/adapters · high confidence

New data-layer use cases have been introduced to bridge domain logic with repository protocols. Specifically, DbCreateUser now handles user creation by delegating to CreateUserRepository and returning the generated id. DbGetUserByEmail provides a mechanism to retrieve a user by their email address, returning the user object. Additionally, DbUpdateMusicalGenreScore allows for updating musical genre scores via the corresponding repository. These implementations are collectively exported from the use-cases index.

src/data/use-cases · high confidence

New repository interfaces have been introduced to define the data access layer for user and musical genre score operations. Specifically, the system now includes protocols for creating a user (requiring email, name, and musicalGenreId), retrieving a user by email, and updating a musical genre score. These interfaces standardize the contract for database interactions within the data layer.

src/data/protocols · high confidence

New factory functions have been added to the \src/main/factories/use-cases/db\ directory, providing a consistent way to instantiate database-backed use cases. Specifically, \makeDbCreateUser\ and \makeDbGetUserByEmail\ are now available to create \DbCreateUser\ and \DbGetUserByEmail\ instances respectively, each wired with a \UserRepository\. Additionally, \makeDbUpdateMusicalGenreScore\ has been added to instantiate \DbUpdateMusicalGenreScore\ with a \MusicalGenreRepository\. These changes are exported via the \index.ts\ barrel file.

src/main/factories/use-cases/db · high confidence

New domain use-case interfaces have been introduced to support user and musical genre operations. Specifically, the system now includes interfaces for creating a user (accepting email, name, and musicalGenreId), retrieving a user by email, and updating a musical genre score. These interfaces define the expected parameters and return types for these domain operations, establishing the contract for their implementation.

src/domain/use-cases · high confidence

The application now includes a Prisma setup with a MySQL database schema defining \Users\ and \MusicalGenres\ models. The initial migration creates these tables with string-based IDs and a foreign key relationship. A subsequent migration updates the schema to use integer auto-incrementing IDs for both models, adds creation and update timestamps, and modifies the relationship between users and musical genres. This establishes the foundational data structure for user profiles and their associated musical genre preferences.

prisma · medium confidence

The repository has been initialized with a complete development environment for a TypeScript/Node.js API. This includes configuration files for the TypeScript compiler (tsconfig.json), ESLint with TypeScript support (.eslintrc.json), Prettier (.prettierrc.json), and Jest (jest.config.js). Additionally, the project now includes a MIT License, a README with usage instructions, a commitlint configuration, and standard ignore files (.gitignore, .eslintignore, .prettierignore) to manage the codebase structure.

(repo-wide) · high confidence

Added new domain models for users and musical genres. The UserModel defines a user with an email, name, and musicalGenreId, while the MusicalGenreModel includes an id, name, score, and a list of associated users.

src/domain/models · high confidence

A new HttpHelper class has been introduced in the presentation layer to standardize HTTP response formatting. It provides static methods for common status codes (200, 201, 204, 400, 500), ensuring consistent response structures for successful, created, and error states.

src/presentation/helpers · high confidence

Added new repository implementations for user and musical genre data access. The user repository now supports creating new users and retrieving them by email. The musical genre repository implements logic to update a genre's score based on the number of linked users, returning the updated score in the result.

src/infrastructure/db/repositories · high confidence

The presentation layer now exposes dedicated error classes for handling specific failure modes. InternalServerError is a new class that captures stack traces for server-side issues, while MissingParametersError is introduced to handle cases where required parameters are absent. These changes allow the application to distinguish between internal failures and invalid input more precisely.

src/presentation/errors · high confidence

Added three new controllers to the presentation layer: CreateUserController, which handles user creation and returns HTTP 201 on success; GetUserByEmailController, which retrieves a user by email and returns HTTP 204 (No Content) if the user is not found; and UpdateMusicalGenreScoreController, which updates a user's musical genre score. These controllers expose the corresponding domain use cases via HTTP endpoints.

src/presentation/controllers · high confidence

New factory functions have been introduced to instantiate controllers for creating users, retrieving users by email, and updating musical genre scores. These changes provide a centralized way to obtain these specific controller instances, supporting the application's dependency injection and controller wiring.

src/main/factories · high confidence

New route files were added to expose endpoints for updating musical genre scores and managing user data. The musical genre routes now support a PUT request to /musicalGenres to update scores, while the user routes provide POST /users for creation and GET /users/:email to retrieve users by email address.

src/main/routes · high confidence

A new pre-commit hook has been added to the .husky directory, which automatically runs lint-staged on staged files before each commit. This ensures that code quality checks are performed automatically during the commit process.

.husky · high confidence

The application's core configuration has been extracted into dedicated modules. Environment variables (such as the server port) are now managed in a separate config file. The main Express application setup, including CORS and JSON parsing middleware, is encapsulated in a new app configuration. Additionally, the central router is configured to mount user and musical genre route handlers, with these route handlers being explicitly exported for use.

src/main/config · medium confidence

The server initialization logic, including the Prisma database connection and Express app listener setup, has been extracted into a new \src/main/server.ts\ module. This change centralizes the application startup sequence, making the main entry point cleaner and the server configuration more explicit.

src/main · high confidence

Added test mocks for user and musical genre domain objects; Added test mocks for user and musical genre repositories; Added test mocks for user and musical genre use cases; Added unit tests for database use cases; Added unit tests for user and musical genre score controllers.

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

• CAI 55 → 56 (+0.5)
• Rubric changed (rubric-2026.08.19 → rubric-2026.09.15) — scores are not directly comparable.

• Code Health 91 → 100 (+9.4)
• Architecture 69 → 69 (+0.0)
• Maturity 59 → 59 (+0.0)
• Readiness 40 → 42 (+1.7)
• Security 75 → 80 (+5.0)

• Coverage not included — suite not readable by the collector
• Critical CVE: [GHSA redacted] (package-lock.json)
• Dependency hygiene not measured — dependency manifest found but not parsed for hygiene
• High CVE: [GHSA redacted] (package-lock.json)
• High CVE: [GHSA redacted] (package-lock.json)
• High CVE: [GHSA redacted] (package-lock.json)
• High CVE: [GHSA redacted] (package-lock.json)
• High CVE: [GHSA redacted] (package-lock.json)
• High CVE: [GHSA redacted] (package-lock.json)
• High CVE: [GHSA redacted] (package-lock.json)
• High CVE: [GHSA redacted] (package-lock.json)
• High CVE: [GHSA redacted] (package-lock.json)
• High CVE: [GHSA redacted] (package-lock.json)
• High CVE: [GHSA redacted] (package-lock.json)
• High CVE: [GHSA redacted] (package-lock.json)
• High CVE: [GHSA redacted] (package-lock.json)
• High CVE: [GHSA redacted] (package-lock.json)
• High CVE: [GHSA redacted] (package-lock.json)
• High CVE: [GHSA redacted] (package-lock.json)
• High CVE: [GHSA redacted] (package-lock.json)
• …and 17 more

• Critical CVE: [GHSA redacted] (package-lock.json)
• Documentation: no installation or build instructions (README.md)
• High CVE: [GHSA redacted] (package-lock.json)
• High CVE: [GHSA redacted] (package-lock.json)
• High CVE: [GHSA redacted] (package-lock.json)
• High CVE: [GHSA redacted] (package-lock.json)
• High CVE: [GHSA redacted] (package-lock.json)
• High CVE: [GHSA redacted] (package-lock.json)
• High CVE: [GHSA redacted] (package-lock.json)
• High CVE: [GHSA redacted] (package-lock.json)
• High CVE: [GHSA redacted] (package-lock.json)
• High CVE: [GHSA redacted] (package-lock.json)
• High CVE: [GHSA redacted] (package-lock.json)
• High CVE: [GHSA redacted] (package-lock.json)
• High CVE: [GHSA redacted] (package-lock.json)
• High CVE: [GHSA redacted] (package-lock.json)
• High CVE: [GHSA redacted] (package-lock.json)
• High CVE: [GHSA redacted] (package-lock.json)
• High CVE: [GHSA redacted] (package-lock.json)
• High CVE: [GHSA redacted] (package-lock.json)
• …and 18 more

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

souz4s/ts-clean-api was measured the same way every project in this corpus was: the same rubric, at a pinned commit, with the result published in full. Point a surveyor at a repository you know and see whether you agree with it.