spec-first-claude 0.1.0

package/templates/docs/_templates/estrutura/ADRs.template.md

@@ -0,0 +1,91 @@
+# ADRs — Architecture Decision Records
+
+> Registro de decisões arquiteturais com contexto, alternativas e consequências.
+> Cada decisão é imutável após aceita. Novas decisões podem substituir anteriores.
+
+---
+
+<!--
+=============================================================================
+INSTRUÇÕES PARA O AGENTE (não incluir no arquivo gerado)
+=============================================================================
+
+ORIGEM: Criado pelo /setup-projeto com ADRs iniciais (stack, arquitetura base).
+ATUALIZAÇÃO: Novas ADRs adicionadas quando:
+  - /setup-projeto define stack e arquitetura (ADRs iniciais)
+  - /design gera SDD §2 com decisões de design significativas
+  - /merge-delta detecta mudança de stack ou padrão
+  - Usuário toma decisão que impacta arquitetura
+
+COMO GERAR:
+1. Para cada decisão significativa, criar ADR com TODOS os campos
+2. Contexto: POR QUE essa decisão foi necessária (não apenas "precisávamos")
+3. Alternativas: OBRIGATÓRIO listar ao menos 1 alternativa (com motivo da rejeição)
+4. Consequências: o que MUDA por causa da decisão (positivo E negativo)
+
+REGRAS:
+- IDs sequenciais: ADR-001, ADR-002... nunca reutilizar
+- NUNCA editar ADR com status "aceita" — criar nova com "substituída por ADR-XXX"
+- Status "proposta" = ainda em discussão, não implementar até aceitar
+- Toda mudança de stack, banco, framework DEVE ter ADR
+- ADRs são APPEND-ONLY — histórico importa
+
+QUANDO CRIAR ADR:
+- Escolha de tecnologia/framework
+- Mudança de padrão de design
+- Decisão de infra (cloud provider, DB engine)
+- Trade-off significativo (performance vs simplicidade, etc.)
+
+QUANDO NÃO CRIAR ADR:
+- Escolha de nome de variável
+- Implementação seguindo padrão já definido
+- Bug fix
+- Refactor sem mudança de interface
+
+=============================================================================
+-->
+
+## Índice
+
+| ADR | Título | Status | Data |
+|-----|--------|--------|------|
+| ADR-001 | {{Título}} | proposta / aceita / substituída / descartada | |
+
+## Formato
+
+Cada ADR segue este modelo:
+
+```markdown
+### ADR-NNN: Título da Decisão
+- **Status**: proposta | aceita | substituída por ADR-XXX | descartada
+- **Data**: YYYY-MM-DD
+- **Contexto**: Por que essa decisão foi necessária?
+- **Decisão**: O que decidimos?
+- **Alternativas consideradas**:
+  1. Alternativa A — rejeitada porque...
+  2. Alternativa B — rejeitada porque...
+- **Consequências**:
+  - Positivas: ...
+  - Negativas: ...
+  - Riscos: ...
+```
+
+---
+
+## Decisões
+
+### ADR-001: {{Título}}
+- **Status**: aceita
+- **Data**:
+- **Contexto**:
+- **Decisão**:
+- **Alternativas consideradas**:
+  1. —
+- **Consequências**:
+  - Positivas:
+  - Negativas:
+  - Riscos:
+
+---
+
+> **Regra**: ADRs aceitas são imutáveis. Para reverter uma decisão, crie nova ADR com status "substituída por ADR-XXX" na ADR original.

package/templates/docs/_templates/estrutura/API.template.md

@@ -0,0 +1,144 @@
+# Convenções de API
+
+> Padrões globais para todas as APIs do sistema: versionamento, autenticação, paginação, erros.
+
+---
+
+<!--
+=============================================================================
+INSTRUÇÕES PARA O AGENTE (não incluir no arquivo gerado)
+=============================================================================
+
+ORIGEM: Gerado pelo /setup-projeto a partir do TRD §5.
+ATUALIZAÇÃO: /merge-delta quando features adicionam endpoints (Delta Specs do SDD §5 e §11).
+
+COMO GERAR:
+1. Ler TRD §5 (Convenções de API) — padrão geral, versionamento, autenticação
+2. Padrão geral e convenções são FIXOS após setup — definidos uma vez
+3. Catálogo de endpoints é DINÂMICO — cresce a cada feature
+4. Formatos de paginação, filtro e erro são FIXOS — toda API segue
+
+REGRAS:
+- Convenções são LEI — todo SDD §5 (endpoints) deve seguir estes padrões
+- Catálogo de endpoints atualizado a cada merge-delta
+- Mudanças em convenções (raro) devem gerar ADR
+- Rate limiting definido por categoria de endpoint, não individual
+
+=============================================================================
+-->
+
+## Padrão Geral
+
+| Aspecto | Padrão |
+|---------|--------|
+| Estilo | <!-- REST / GraphQL / gRPC --> |
+| Formato | <!-- JSON / Protobuf --> |
+| Versionamento | <!-- /api/v1/ no path? Header? --> |
+| Autenticação | <!-- Bearer JWT? API Key? --> |
+| Content-Type | <!-- application/json --> |
+| Encoding | <!-- UTF-8 --> |
+
+## Convenções de Rotas
+
+| Operação | Método | Rota | Exemplo |
+|----------|--------|------|---------|
+| Listar | GET | `/api/v1/{recurso}` | |
+| Detalhar | GET | `/api/v1/{recurso}/:id` | |
+| Criar | POST | `/api/v1/{recurso}` | |
+| Atualizar completo | PUT | `/api/v1/{recurso}/:id` | |
+| Atualizar parcial | PATCH | `/api/v1/{recurso}/:id` | |
+| Remover/Inativar | DELETE | `/api/v1/{recurso}/:id` | |
+
+### Convenções de nomenclatura
+| Regra | Exemplo |
+|-------|---------|
+| Recursos no plural, kebab-case | `/api/v1/order-items` |
+| Ações não-CRUD como sub-recurso | `/api/v1/users/:id/activate` |
+| Filtros via query params | `/api/v1/users?status=active` |
+| Relações aninhadas (max 2 níveis) | `/api/v1/users/:id/orders` |
+
+## Paginação
+
+```json
+{
+  "data": [],
+  "meta": {
+    "page": 1,
+    "per_page": 20,
+    "total": 0,
+    "total_pages": 0
+  }
+}
+```
+
+Query params: `?page=1&per_page=20&sort=campo&order=asc`
+
+| Parâmetro | Default | Máximo | Descrição |
+|-----------|---------|--------|-----------|
+| `page` | 1 | — | Página atual |
+| `per_page` | 20 | <!-- Ex: 100 --> | Itens por página |
+| `sort` | — | — | Campo para ordenação |
+| `order` | `asc` | — | `asc` ou `desc` |
+
+## Filtros
+
+Query params: `?busca=termo&campo=valor`
+
+| Tipo de filtro | Formato | Exemplo |
+|----------------|---------|---------|
+| Igualdade | `?campo=valor` | `?status=ativo` |
+| Busca textual | `?busca=termo` | `?busca=joao` |
+| Range de data | `?de=YYYY-MM-DD&ate=YYYY-MM-DD` | `?de=2026-01-01&ate=2026-12-31` |
+| Múltiplos valores | `?campo=a,b,c` | `?status=ativo,pendente` |
+
+## Respostas de Erro
+
+```json
+{
+  "error": {
+    "code": "ERROR_CODE",
+    "message": "Mensagem legível para o usuário",
+    "details": [
+      { "field": "campo", "message": "Detalhe do erro" }
+    ]
+  }
+}
+```
+
+### Códigos HTTP
+
+| Código | Quando usar | Exemplo |
+|--------|-------------|---------|
+| 200 | Sucesso (GET, PUT, PATCH) | Recurso retornado/atualizado |
+| 201 | Criado com sucesso (POST) | Recurso criado, retorna o objeto |
+| 204 | Sucesso sem conteúdo (DELETE) | Recurso removido |
+| 400 | Dados inválidos (formato) | JSON malformado |
+| 401 | Não autenticado | Token ausente ou expirado |
+| 403 | Sem permissão | Papel sem acesso ao recurso |
+| 404 | Recurso não encontrado | ID inexistente |
+| 409 | Conflito (duplicidade) | Email já cadastrado |
+| 422 | Validação de negócio falhou | CPF inválido, regra RN-XXX violada |
+| 429 | Rate limit excedido | Muitas requisições |
+| 500 | Erro interno | Bug não tratado |
+
+### Códigos de erro do domínio
+
+| Código | Descrição | HTTP |
+|--------|-----------|------|
+| <!-- Ex: DUPLICATE_EMAIL --> | <!-- Email já cadastrado --> | <!-- 409 --> |
+
+## Catálogo de Endpoints
+
+> Atualizado a cada feature via /merge-delta. Visão consolidada de todas as APIs.
+
+| Método | Rota | Feature | Descrição |
+|--------|------|---------|-----------|
+|        |      |         |           |
+
+---
+
+## Changelog
+
+| Data | Feature | Tipo | Descrição |
+|------|---------|------|-----------|
+|      |         |      |           |

package/templates/docs/_templates/estrutura/Arquitetura.template.md

@@ -0,0 +1,82 @@
+# Arquitetura
+
+> C4 Níveis 2-3 — Containers, componentes, comunicação e padrões adotados.
+
+---
+
+<!--
+=============================================================================
+INSTRUÇÕES PARA O AGENTE (não incluir no arquivo gerado)
+=============================================================================
+
+ORIGEM: Gerado pelo /setup-projeto a partir do TRD §3.
+ATUALIZAÇÃO: /merge-delta quando features adicionam containers, componentes significativos ou novos padrões.
+
+COMO GERAR:
+1. Ler TRD §3 (Arquitetura) — containers, padrões de comunicação, padrões de design
+2. Ler Stack.md — tecnologias já definidas para cada container
+3. Criar diagrama textual C4 Nível 2 (containers e suas conexões)
+4. Para cada container: listar componentes internos (C4 Nível 3)
+5. Documentar padrões de comunicação (sync/async, protocolos)
+6. Documentar padrões de design com justificativa
+
+REGRAS:
+- Diagrama deve mostrar TODOS os containers e suas conexões
+- Cada container deve ter: tecnologia, responsabilidade, porta
+- Padrões de design precisam de justificativa (não apenas nome)
+- Se o sistema usa filas/eventos: documentar tópicos e consumers
+- Componentes são internos ao container — não confundir com containers
+
+=============================================================================
+-->
+
+## Diagrama de Containers (C4 Nível 2)
+
+```
+<!-- Representação textual dos containers e suas conexões -->
+<!-- Usar formato: [Container] --protocolo--> [Container] -->
+```
+
+## Containers
+
+| Container | Tecnologia | Responsabilidade | Porta | Comunicação |
+|-----------|-----------|-----------------|-------|-------------|
+|           |           |                 |       |             |
+
+## Componentes Principais (C4 Nível 3)
+
+<!-- Repetir esta seção para cada container que tenha componentes internos relevantes -->
+
+### {{Container}}
+
+| Componente | Responsabilidade | Dependências internas | Dependências externas |
+|------------|-----------------|----------------------|----------------------|
+|            |                 |                      |                      |
+
+## Padrões de Comunicação
+
+### Síncrona (request/response)
+
+| De | Para | Protocolo | Formato | Observações |
+|----|------|-----------|---------|-------------|
+|    |      |           |         |             |
+
+### Assíncrona (eventos/filas)
+
+| Produtor | Tópico/Fila | Consumer | Formato | Garantia |
+|----------|-------------|----------|---------|----------|
+|          |             |          |         | at-least-once / exactly-once |
+
+## Padrões de Design Adotados
+
+| Padrão | Onde é usado | Justificativa | Ref ADR |
+|--------|-------------|---------------|---------|
+|        |             |               |         |
+
+---
+
+## Changelog
+
+| Data | Feature | Tipo | Descrição |
+|------|---------|------|-----------|
+|      |         |      |           |

package/templates/docs/_templates/estrutura/Infraestrutura.template.md

@@ -0,0 +1,104 @@
+# Infraestrutura
+
+> Ambientes, deploy, CI/CD, variáveis de ambiente, domínios e estratégia de rollback.
+
+---
+
+<!--
+=============================================================================
+INSTRUÇÕES PARA O AGENTE (não incluir no arquivo gerado)
+=============================================================================
+
+ORIGEM: Gerado pelo /setup-projeto a partir do TRD §6.
+ATUALIZAÇÃO: /merge-delta quando features adicionam variáveis de ambiente, serviços ou mudam infra.
+
+COMO GERAR:
+1. Ler TRD §6 (Infraestrutura) — ambientes, deploy, CI/CD
+2. Listar TODOS os ambientes com URLs e propósitos
+3. Pipeline CI/CD deve ser concreto (passos reais, não genéricos)
+4. Variáveis de ambiente: NUNCA colocar valores reais (só exemplos)
+5. Estratégia de rollback é OBRIGATÓRIA
+
+REGRAS:
+- Variáveis de ambiente com valores reais NÃO vão pro repositório
+- Cada variável precisa de descrição (não só o nome)
+- Pipeline CI/CD deve ter passos claros e ferramentas definidas
+- Rollback strategy obrigatória — "como voltar se der errado?"
+- Novas variáveis adicionadas via merge-delta devem entrar na tabela
+
+=============================================================================
+-->
+
+## Ambientes
+
+| Ambiente | URL | Banco | Propósito | Branch |
+|----------|-----|-------|-----------|--------|
+| Local | `localhost:{{PORT}}` | local | Desenvolvimento | qualquer |
+| Staging | | | Testes e homologação | develop |
+| Produção | | | Usuários finais | main |
+
+## Deploy
+
+### Estratégia
+
+| Aspecto | Decisão |
+|---------|---------|
+| Plataforma | <!-- Docker? Serverless? VPS? Cloud provider? --> |
+| Orquestração | <!-- Kubernetes? ECS? PM2? --> |
+| Build | <!-- Docker multi-stage? Build nativo? --> |
+| Estratégia de deploy | <!-- Rolling? Blue-green? Canary? --> |
+
+### Pipeline CI/CD
+
+```
+push → lint → test → build → deploy(staging) → aprovação → deploy(prod)
+```
+
+| Etapa | Ferramenta | Trigger | Timeout |
+|-------|-----------|---------|---------|
+| Lint | <!-- eslint, ruff --> | push | |
+| Testes | <!-- jest, pytest --> | push | |
+| Build | <!-- docker build --> | push em main/develop | |
+| Deploy staging | <!-- CD tool --> | push em develop | |
+| Deploy produção | <!-- CD tool --> | aprovação manual | |
+
+### Rollback
+
+| Cenário | Procedimento | Responsável |
+|---------|-------------|-------------|
+| Bug em produção | <!-- Reverter deploy? Hotfix? --> | |
+| Migration com erro | <!-- Rollback da migration? --> | |
+| Serviço externo fora | <!-- Fallback? Circuit breaker? --> | |
+
+## Variáveis de Ambiente
+
+> NUNCA colocar valores reais aqui. Apenas nomes, descrição e exemplos.
+
+| Variável | Ambientes | Obrigatória | Descrição | Exemplo |
+|----------|-----------|-------------|-----------|---------|
+| `DATABASE_URL` | todos | sim | Conexão com banco | `postgres://user:pass@host:5432/db` |
+| `JWT_SECRET` | todos | sim | Chave de assinatura JWT | `sua-chave-secreta-aqui` |
+| `NODE_ENV` | todos | sim | Ambiente atual | `development` / `production` |
+
+## Domínios e DNS
+
+| Domínio | Aponta para | Certificado | Gerenciado por |
+|---------|-------------|-------------|----------------|
+|         |             | <!-- Let's Encrypt? AWS ACM? --> | |
+
+## Monitoramento e Observabilidade
+
+| Aspecto | Ferramenta | O que monitora |
+|---------|-----------|----------------|
+| Logs | <!-- Ex: CloudWatch, Datadog --> | |
+| APM | <!-- Ex: New Relic, Sentry --> | |
+| Uptime | <!-- Ex: Pingdom, UptimeRobot --> | |
+| Alertas | <!-- Ex: PagerDuty, Slack --> | |
+
+---
+
+## Changelog
+
+| Data | Feature | Tipo | Descrição |
+|------|---------|------|-----------|
+|      |         |      |           |

package/templates/docs/_templates/estrutura/Modelo_Dados.template.md

@@ -0,0 +1,99 @@
+# Modelo de Dados
+
+> Schema completo, relações, índices, convenções de nomenclatura e estratégia de migrations.
+
+---
+
+<!--
+=============================================================================
+INSTRUÇÕES PARA O AGENTE (não incluir no arquivo gerado)
+=============================================================================
+
+ORIGEM: Gerado pelo /setup-projeto a partir do TRD §4.
+ATUALIZAÇÃO: /merge-delta a cada feature que adiciona/altera tabelas (Delta Specs do SDD §3 e §11).
+
+COMO GERAR:
+1. Ler TRD §4 (Modelo de Dados Base) — tabelas iniciais, convenções
+2. Gerar diagrama ER textual com TODAS as relações
+3. Para cada tabela: campos com tipos EXATOS (varchar(255), não "string")
+4. Convenções de nomenclatura são FIXAS após setup — não mudam por feature
+5. Estratégia de migrations deve ser concreta (ferramenta, naming, rollback)
+
+REGRAS:
+- Tipos devem ser do banco escolhido (PostgreSQL, MySQL, etc.), não genéricos
+- Toda FK deve ter ON DELETE/ON UPDATE definido
+- Índices precisam de justificativa (query que justifica)
+- Convenções definidas aqui são LEI — SDDs e tasks seguem à risca
+- Diagrama ER deve ser atualizado a cada merge-delta
+
+=============================================================================
+-->
+
+## Diagrama ER
+
+```
+<!-- Representação textual do ER -->
+<!-- Formato: [tabela_a] 1---N [tabela_b] (campo_fk) -->
+```
+
+## Convenções de Nomenclatura
+
+| Elemento | Convenção | Exemplo |
+|----------|-----------|---------|
+| Tabelas | snake_case, plural | `clientes`, `pedidos` |
+| Colunas | snake_case | `nome_completo`, `criado_em` |
+| PKs | `id` (UUID ou SERIAL) | `id UUID PRIMARY KEY DEFAULT gen_random_uuid()` |
+| FKs | `{tabela_singular}_id` | `cliente_id`, `cidade_id` |
+| Índices | `idx_{tabela}_{colunas}` | `idx_clientes_cpf` |
+| Unique | `uq_{tabela}_{colunas}` | `uq_clientes_email` |
+| Timestamps | `criado_em`, `atualizado_em` | `TIMESTAMPTZ NOT NULL DEFAULT now()` |
+| Soft delete | `ativo` (boolean) | `ativo BOOLEAN DEFAULT true` |
+| Auditoria | `criado_por`, `atualizado_por` | `UUID REFERENCES usuarios(id)` |
+
+## Catálogo de Tabelas
+
+<!-- Repetir bloco para cada tabela -->
+
+### {{tabela}}
+
+> Descrição breve da tabela.
+
+| Coluna | Tipo | Nullable | Default | Constraint | Descrição |
+|--------|------|----------|---------|------------|-----------|
+|        |      |          |         |            |           |
+
+**Relações:**
+- `campo_id` → `tabela_ref(id)` — ON DELETE CASCADE / SET NULL / RESTRICT
+
+**Índices:**
+
+| Nome | Colunas | Tipo | Justificativa |
+|------|---------|------|---------------|
+|      |         | btree / unique / gin | <!-- Qual query justifica este índice? --> |
+
+## Estratégia de Migrations
+
+| Aspecto | Convenção |
+|---------|-----------|
+| Ferramenta | <!-- Ex: knex, prisma, flyway, alembic --> |
+| Nomenclatura | <!-- Ex: 001_create_tabela.sql, YYYYMMDD_descricao --> |
+| Rollback | <!-- Toda migration TEM rollback? Testado como? --> |
+| Execução | <!-- Sequencial? Transacional? --> |
+| Dados existentes | <!-- Como lidar com migrations em tabelas com dados? --> |
+
+## Regras Globais de Dados
+
+| Regra | Descrição |
+|-------|-----------|
+| Soft delete | <!-- Todas as tabelas usam? Quais exceções? --> |
+| Auditoria | <!-- criado_por/atualizado_por em todas? --> |
+| Timestamps | <!-- criado_em/atualizado_em obrigatórios? --> |
+| Encoding | <!-- UTF-8? Collation? --> |
+
+---
+
+## Changelog
+
+| Data | Feature | Tipo | Descrição |
+|------|---------|------|-----------|
+|      |         |      |           |

package/templates/docs/_templates/estrutura/Seguranca.template.md

@@ -0,0 +1,138 @@
+# Segurança
+
+> Autenticação, autorização, CORS, rate limiting, LGPD, auditoria e proteção de dados.
+
+---
+
+<!--
+=============================================================================
+INSTRUÇÕES PARA O AGENTE (não incluir no arquivo gerado)
+=============================================================================
+
+ORIGEM: Gerado pelo /setup-projeto a partir do TRD §7.
+ATUALIZAÇÃO: /merge-delta quando features adicionam permissões, dados pessoais ou políticas.
+
+COMO GERAR:
+1. Ler TRD §7 (Segurança) — autenticação, autorização, CORS, LGPD
+2. Autenticação: método, expiração, hash, refresh strategy
+3. Autorização: papéis e matriz de permissões (RBAC/ABAC)
+4. LGPD: mapear TODOS dados pessoais com base legal
+5. Auditoria: definir O QUE é logado, ONDE e POR QUANTO TEMPO
+
+REGRAS:
+- Matriz de permissões é DINÂMICA — cresce a cada feature (via merge-delta)
+- Dados pessoais da LGPD precisam de base legal ESPECÍFICA
+- Nunca armazenar senhas em texto plano (hash obrigatório)
+- Secrets nunca no código — sempre variáveis de ambiente
+- Rate limiting obrigatório em endpoints públicos (login, registro)
+- Auditoria obrigatória para operações destrutivas (delete, update de dados sensíveis)
+
+=============================================================================
+-->
+
+## Autenticação
+
+| Aspecto | Implementação |
+|---------|--------------|
+| Método | <!-- JWT? Session? OAuth2? --> |
+| Expiração access token | <!-- Ex: 15min --> |
+| Refresh token | <!-- Existe? Expiração? Rotação? --> |
+| Hash de senha | <!-- bcrypt rounds? argon2? --> |
+| Header | <!-- Authorization: Bearer {token} --> |
+| Armazenamento (client) | <!-- httpOnly cookie? localStorage? --> |
+
+### Fluxo de autenticação
+
+```
+<!-- Descrever o fluxo: login → token → refresh → logout -->
+```
+
+## Autorização
+
+### Modelo
+
+| Aspecto | Decisão |
+|---------|---------|
+| Tipo | <!-- RBAC / ABAC / RBAC + ABAC --> |
+| Onde é verificado | <!-- Middleware? Decorator? Service? --> |
+| Granularidade | <!-- Por rota? Por recurso? Por campo? --> |
+
+### Papéis
+
+| Papel | Descrição | Herda de |
+|-------|-----------|----------|
+|       |           | <!-- Hierarquia: admin herda de user? --> |
+
+### Matriz de Permissões
+
+> Atualizada a cada feature via /merge-delta.
+
+| Recurso | Ação | {{role_1}} | {{role_2}} | {{role_N}} |
+|---------|------|------------|------------|------------|
+|         | criar | | | |
+|         | ler | | | |
+|         | editar | | | |
+|         | deletar | | | |
+
+## CORS
+
+| Aspecto | Configuração |
+|---------|-------------|
+| Allowed Origins | <!-- Configurável por ambiente --> |
+| Allowed Methods | `GET, POST, PUT, PATCH, DELETE` |
+| Allowed Headers | `Authorization, Content-Type` |
+| Credentials | <!-- true/false --> |
+| Max Age | <!-- Preflight cache em segundos --> |
+
+## Rate Limiting
+
+| Categoria | Limite | Janela | Resposta |
+|-----------|--------|--------|----------|
+| Login/Registro | <!-- Ex: 5 req --> | <!-- Ex: 15min --> | 429 + Retry-After |
+| API autenticada | <!-- Ex: 100 req --> | <!-- Ex: 1min --> | 429 + Retry-After |
+| API pública | <!-- Ex: 30 req --> | <!-- Ex: 1min --> | 429 + Retry-After |
+| Upload | <!-- Ex: 10 req --> | <!-- Ex: 1h --> | 429 + Retry-After |
+
+## LGPD / Privacidade
+
+### Dados pessoais coletados
+
+| Dado | Base legal | Finalidade | Retenção | Criptografado? |
+|------|-----------|------------|----------|----------------|
+|      | <!-- Consentimento / Contrato / Legítimo interesse / Obrigação legal --> | | | |
+
+### Direitos do titular
+
+| Direito | Implementação | Endpoint/Fluxo |
+|---------|--------------|----------------|
+| Acesso aos dados | | <!-- Como o usuário acessa? --> |
+| Correção | | |
+| Exclusão (right to be forgotten) | | <!-- Soft delete? Hard delete? Anonimização? --> |
+| Portabilidade | | <!-- Formato de exportação? --> |
+| Revogação de consentimento | | |
+
+## Auditoria
+
+| O que é logado | Quando | Onde armazena | Retenção |
+|----------------|--------|---------------|----------|
+| Login/Logout | sempre | | |
+| Alteração de dados sensíveis | sempre | | |
+| Operações destrutivas (DELETE) | sempre | | |
+| Falhas de autenticação | sempre | | |
+| Mudanças de permissão | sempre | | |
+
+## Proteção de Dados em Trânsito e Repouso
+
+| Aspecto | Implementação |
+|---------|--------------|
+| TLS | <!-- Versão mínima? --> |
+| Dados sensíveis em repouso | <!-- Criptografia? Quais campos? --> |
+| Backup | <!-- Criptografado? Frequência? --> |
+
+---
+
+## Changelog
+
+| Data | Feature | Tipo | Descrição |
+|------|---------|------|-----------|
+|      |         |      |           |