Skip to content

Feature Template

Copy this template to docs/api/rest/<feature>.md (or the relevant section) when adding a new feature. Fill every section with real content; delete sections that genuinely don't apply. Follow the conventions in ../contributing.md.

# <Feature Name>

## Overview

What the feature is, who uses it, and why it exists. One or two paragraphs.

## Purpose

The business/technical goal. What problem does it solve, and what does success
look like?

## Architecture

Where this feature lives in the codebase and how it connects to existing pieces:

- `src/application/use-cases/<feature>/` — commands/queries
- `src/domain/entities/<feature>/` — domain entities (if new models)
- `src/interfaces/http/routes/v<N>/<feature>/` — routes
- `src/infrastructure/...` — implementations
- Prisma models: `User`, `Program`, `Cycle` … (link [database/schema](../database/schema.md))

```mermaid
flowchart LR
    Client --> Route["route"]
    Route --> UC["use case"]
    UC --> R["repository"]
    R --> DB[(PostgreSQL)]
```

Flow

Step-by-step happy-path flow (numbered list or sequence diagram).

Examples

  • Request/response examples for the main operations.
  • Any payloads, IDs, or edge cases worth showing.

Best Practices

Feature-specific gotchas: authorization checks, caching, idempotency, queue usage, rate limits, pagination.

---

## Checklist before opening the doc PR

- [ ] No business logic described as living in controllers
- [ ] New Prisma models have matching domain entities
- [ ] Authorization/ownership documented
- [ ] Tests referenced or added
- [ ] Links are relative and resolve
- [ ] Mermaid diagrams render