ai-unified-process/aiup-nestjs
AI Unified Process service and API layers - NestJS services, REST controllers, and their tests
Implements the REST API layer of a use case (UC-XXX) in a NestJS application: thin @Controller classes on top of the service layer, class-validator request DTOs under a global ValidationPipe, plain response types that never leak a database row, one exception filter mapping domain errors to RFC 9457 Problem Details, a status code per alternative flow, and paging. Takes the base path and contract style from the API contract section of docs/architecture/stack.md, builds an operation the use case's **API:** line links in an agreed OpenAPI contract exactly as written, and holds no business rule the service does not enforce. Use when the user asks to "build the REST API", "create an endpoint", "expose the use case over HTTP", "add a controller", or mentions NestJS controllers, DTOs, class-validator, ValidationPipe, exception filters, or a JSON contract for a separate client such as Next.js. Normally run by /use-case-implement after the service layer; it can also be run directly.
Writes the REST API tests of a use case (UC-XXX) in a NestJS application with Vitest and Supertest: status codes, Location headers, the JSON contract, the error bodies, and — as the integration layer of a REST service or behind a client-side UI such as Next.js — every business rule's allowed and rejected request at the boundary, booting the whole application against a real PostgreSQL database in Testcontainers, nothing mocked. Checks the Vitest transformer that decorator metadata needs, and that the test application has the ValidationPipe and exception filter the real one has. Files are test/UC-XXX-<slug>.e2e-spec.ts with describe('UC-XXX: …'). Use when the user asks to "test the REST API", "test the controller", "test the endpoint", "write API tests", "write an e2e test", "check the status codes", or mentions Supertest, Testcontainers, or NestJS API tests. Normally run by /use-case-test as the integration layer; it can also be run directly. Browser tests are the E2E layer.
Implements the service layer of a use case (UC-XXX) in a NestJS application: @Injectable service classes in the feature folder, the business rules with UC-XXX BR-YYY markers, domain errors for every rejection the API or UI turns into a message, and writes that span repositories in one transaction through the repository. Calls the persistence layer only through the repository its Handover names, imports no Drizzle and no HTTP type, and detects the API app root and ESM/NodeNext, where every relative import ends in .js. Use when the user asks to "implement the service layer", "write the business logic", "enforce the business rules", "create a NestJS service", or mentions providers, @Injectable services, domain errors, or a feature module's service in a project that combines layer plugins. Normally run by /use-case-implement after the persistence layer; it can also be run directly. The controller is /nest-rest.
Writes the service layer tests of a use case (UC-XXX) in a NestJS application with Vitest: every business rule with its allowed and its rejected case, every alternative flow the service decides, and the main success scenario, called on the real service against a real PostgreSQL database in Testcontainers, nothing mocked in the call chain. Checks the Vitest transformer that decorator metadata needs, and owns the shared test setup and the per-use-case seed test/data/uc<id>-<slug>.ts. Files are test/UC-XXX-<slug>.service-spec.ts. Use when the user asks to "test the service layer", "test the business rules", "write service tests", or mentions NestJS testing, Vitest, Testcontainers, domain errors, or business rule tests for a NestJS use case. Run by /use-case-test as the integration layer of a use case offered through the service alone, or when the service layer is named; below a REST entry layer the API tests cover the service. Can also be run directly.