spec-first-copilot 0.4.0 → 0.5.0-beta.0

package/templates/{docs/_templates → .github/templates}/feature/tasks.template.md

@@ -1,115 +1,115 @@
-# Tasks — {{AREA}} — {{FEATURE}}
-
-> Checklist de implementação organizado por **fases** e **prioridade**.
-> O Coder consulta o `sdd.md` para detalhes técnicos.
-> Este arquivo define O QUE fazer, EM QUE ORDEM, e ONDE.
-
----
-
-## Meta
-
-| Campo | Valor |
-|-------|-------|
-| Feature | `{{FEATURE}}` |
-| Área | {{AREA}} |
-| SDD | [`sdd.md`](./sdd.md) {{SDD_SECTIONS}} |
-| Total de tasks | {{TOTAL}} |
-| Depende de | {{AREA_DEPENDENCIES}} |
-
----
-
-<!--
-=============================================================================
-INSTRUÇÕES PARA O AGENTE (não incluir no arquivo gerado)
-=============================================================================
-
-COMO GERAR ESTE ARQUIVO:
-
-1. Ler o SDD completo da feature
-2. Identificar TODAS as áreas afetadas (banco, back, front, mobile, infra...)
-3. Para CADA área, gerar um arquivo `{area}_tasks.md` usando este template
-4. Áreas são DINÂMICAS — determinadas pelo SDD, não pré-definidas
-
-COMO DEFINIR FASES:
-
-- Agrupar tasks por etapa lógica de implementação
-- Fases são SEQUENCIAIS dentro da área (Fase 2 depende de Fase 1)
-- Usar prioridade P1/P2/P3 por fase
-- Nomear fases de forma descritiva (não só "Fase 1")
-- Exemplos de fases por área:
-  
-  BANCO:     Setup → Schema → Índices → Seeds
-  BACKEND:   Setup → DTOs/Validações → Repository/Service → Controller → Testes
-  FRONTEND:  Setup/Rotas → Componentes → Telas → Polish
-  MOBILE:    Setup → Navegação → Telas → Offline → Push
-  INFRA:     Provisão → Config → Deploy → Monitoramento
-
-COMO ESCREVER CADA TASK:
-
-- Formato checklist: `- [ ] **ID**: Título [Tamanho]`
-- ID: {PREFIXO}-{NNN} sequencial (BANCO-001, BACK-001, FRONT-001, MOBILE-001...)
-- Título: verbo no infinitivo + o que fazer
-- Tamanho: S (< 30min), M (30min-2h), L (2h+)
-- Fase: número da fase de entrega (do PRD §11) — OBRIGATÓRIO
-- Repo: nome do repo (de projetos.yaml) — OBRIGATÓRIO
-- Arquivos: EXATAMENTE quais files criar ou alterar (caminhos RELATIVOS ao repo)
-- SDD: seção específica (§3.1, §5 POST /rota, §6 Tela X)
-- Depende: IDs de tasks (mesma área ou cross-area)
-
-REGRAS:
-
-- Task deve ser AUTOCONTIDA: Coder lê SDD + esta task, nada mais
-- NÃO duplicar conteúdo do SDD — apenas referenciar seções
-- NÃO incluir status — vive só no Progresso.md
-- Depende cross-area é permitido (FRONT-004 depende de BACK-009)
-- "Regras desta área" = convenções específicas extraídas do SDD e docs/Estrutura
-
-=============================================================================
--->
-
-## Fase 1 — {{FASE_NOME}} [{{PRIORIDADE}}]
-
-> {{FASE_CONTEXTO — 1 linha explicando o propósito da fase}}
-<!-- Opcional: "Depende de: Área X Fase Y concluída" -->
-
-- [ ] **{{PREFIXO}}-001**: {{Título descritivo}} [{{S|M|L}}]
-  - Fase: {{N}} — {{Nome fase de entrega}}
-  - Repo: `{{repo_name}}`
-  - Arquivos: `{{caminho/arquivo.ext}}`
-  - SDD: {{§N seção específica}}
-  - Depende: {{ID ou —}}
-
-- [ ] **{{PREFIXO}}-002**: {{Título descritivo}} [{{S|M|L}}]
-  - Fase: {{N}} — {{Nome fase de entrega}}
-  - Repo: `{{repo_name}}`
-  - Arquivos: `{{caminho/arquivo1.ext}}`, `{{caminho/arquivo2.ext}}`
-  - SDD: {{§N.M subseção}}
-  - Depende: {{PREFIXO}}-001
-
----
-
-## Fase 2 — {{FASE_NOME}} [{{PRIORIDADE}}]
-
-> {{FASE_CONTEXTO}}
-
-- [ ] **{{PREFIXO}}-003**: {{Título}} [{{S|M|L}}]
-  - Fase: {{N}} — {{Nome fase de entrega}}
-  - Repo: `{{repo_name}}`
-  - Arquivos: `{{caminho/}}`
-  - SDD: {{§N}}
-  - Depende: {{PREFIXO}}-001, {{OUTRA_AREA}}-001
-
-<!-- Repetir fases conforme necessário -->
-
----
-
-## Regras desta área
-
-<!-- Extraídas do SDD e docs/Estrutura/ — específicas para esta área -->
-1. {{Regra 1}}
-2. {{Regra 2}}
-
----
-
-> **Legenda tamanho**: S = < 30min · M = 30min-2h · L = 2h+
-> **Legenda prioridade**: P1 = bloqueia outras áreas · P2 = importante · P3 = nice-to-have
+# Tasks — {{AREA}} — {{FEATURE}}
+
+> Checklist de implementação organizado por **fases** e **prioridade**.
+> O Coder consulta o `sdd.md` para detalhes técnicos.
+> Este arquivo define O QUE fazer, EM QUE ORDEM, e ONDE.
+
+---
+
+## Meta
+
+| Campo | Valor |
+|-------|-------|
+| Feature | `{{FEATURE}}` |
+| Área | {{AREA}} |
+| SDD | [`sdd.md`](./sdd.md) {{SDD_SECTIONS}} |
+| Total de tasks | {{TOTAL}} |
+| Depende de | {{AREA_DEPENDENCIES}} |
+
+---
+
+<!--
+=============================================================================
+INSTRUÇÕES PARA O AGENTE (não incluir no arquivo gerado)
+=============================================================================
+
+COMO GERAR ESTE ARQUIVO:
+
+1. Ler o SDD completo da feature
+2. Identificar TODAS as áreas afetadas (banco, back, front, mobile, infra...)
+3. Para CADA área, gerar um arquivo `{area}_tasks.md` usando este template
+4. Áreas são DINÂMICAS — determinadas pelo SDD, não pré-definidas
+
+COMO DEFINIR FASES:
+
+- Agrupar tasks por etapa lógica de implementação
+- Fases são SEQUENCIAIS dentro da área (Fase 2 depende de Fase 1)
+- Usar prioridade P1/P2/P3 por fase
+- Nomear fases de forma descritiva (não só "Fase 1")
+- Exemplos de fases por área:
+  
+  BANCO:     Setup → Schema → Índices → Seeds
+  BACKEND:   Setup → DTOs/Validações → Repository/Service → Controller → Testes
+  FRONTEND:  Setup/Rotas → Componentes → Telas → Polish
+  MOBILE:    Setup → Navegação → Telas → Offline → Push
+  INFRA:     Provisão → Config → Deploy → Monitoramento
+
+COMO ESCREVER CADA TASK:
+
+- Formato checklist: `- [ ] **ID**: Título [Tamanho]`
+- ID: {PREFIXO}-{NNN} sequencial (BANCO-001, BACK-001, FRONT-001, MOBILE-001...)
+- Título: verbo no infinitivo + o que fazer
+- Tamanho: S (< 30min), M (30min-2h), L (2h+)
+- Fase: número da fase de entrega (do PRD §11) — OBRIGATÓRIO
+- Repo: nome do repo (de projetos.yaml) — OBRIGATÓRIO
+- Arquivos: EXATAMENTE quais files criar ou alterar (caminhos RELATIVOS ao repo)
+- SDD: seção específica (§3.1, §5 POST /rota, §6 Tela X)
+- Depende: IDs de tasks (mesma área ou cross-area)
+
+REGRAS:
+
+- Task deve ser AUTOCONTIDA: Coder lê SDD + esta task, nada mais
+- NÃO duplicar conteúdo do SDD — apenas referenciar seções
+- NÃO incluir status — vive só no Progresso.md
+- Depende cross-area é permitido (FRONT-004 depende de BACK-009)
+- "Regras desta área" = convenções específicas extraídas do SDD e docs
+
+=============================================================================
+-->
+
+## Fase 1 — {{FASE_NOME}} [{{PRIORIDADE}}]
+
+> {{FASE_CONTEXTO — 1 linha explicando o propósito da fase}}
+<!-- Opcional: "Depende de: Área X Fase Y concluída" -->
+
+- [ ] **{{PREFIXO}}-001**: {{Título descritivo}} [{{S|M|L}}]
+  - Fase: {{N}} — {{Nome fase de entrega}}
+  - Repo: `{{repo_name}}`
+  - Arquivos: `{{caminho/arquivo.ext}}`
+  - SDD: {{§N seção específica}}
+  - Depende: {{ID ou —}}
+
+- [ ] **{{PREFIXO}}-002**: {{Título descritivo}} [{{S|M|L}}]
+  - Fase: {{N}} — {{Nome fase de entrega}}
+  - Repo: `{{repo_name}}`
+  - Arquivos: `{{caminho/arquivo1.ext}}`, `{{caminho/arquivo2.ext}}`
+  - SDD: {{§N.M subseção}}
+  - Depende: {{PREFIXO}}-001
+
+---
+
+## Fase 2 — {{FASE_NOME}} [{{PRIORIDADE}}]
+
+> {{FASE_CONTEXTO}}
+
+- [ ] **{{PREFIXO}}-003**: {{Título}} [{{S|M|L}}]
+  - Fase: {{N}} — {{Nome fase de entrega}}
+  - Repo: `{{repo_name}}`
+  - Arquivos: `{{caminho/}}`
+  - SDD: {{§N}}
+  - Depende: {{PREFIXO}}-001, {{OUTRA_AREA}}-001
+
+<!-- Repetir fases conforme necessário -->
+
+---
+
+## Regras desta área
+
+<!-- Extraídas do SDD e docs/ — específicas para esta área -->
+1. {{Regra 1}}
+2. {{Regra 2}}
+
+---
+
+> **Legenda tamanho**: S = < 30min · M = 30min-2h · L = 2h+
+> **Legenda prioridade**: P1 = bloqueia outras áreas · P2 = importante · P3 = nice-to-have

package/templates/{docs/_templates → .github/templates}/global/progresso_global.template.md

@@ -1,57 +1,57 @@
-# Progresso Geral
-
-> Visão consolidada de todas as features, bugs e tarefas do projeto.
-> Atualizado automaticamente ao final de cada `/plan` e `/dev`.
-
----
-
-<!--
-=============================================================================
-INSTRUÇÕES PARA O AGENTE (não incluir no arquivo gerado na primeira vez)
-=============================================================================
-
-QUANDO USAR: Criado pelo /plan do primeiro setup ou feature. Atualizado por cada /plan e /dev.
-
-COMO ATUALIZAR:
-- Ao criar nova feature (/plan) → adicionar linha na tabela com contadores zerados
-- Ao concluir tasks (/dev) → atualizar contadores
-- Ao concluir feature (/merge-delta) → status "concluído" ou "done"
-
-ÁREAS SÃO DINÂMICAS:
-- Colunas de área mudam conforme o projeto (BANCO, BACK, FRONT, DOC, INFRA, MOBILE...)
-- Cada feature pode ter áreas diferentes
-- Usar "—" quando uma feature não tem tasks naquela área
-
-STATUS USA O VALOR DO .context.md:
-- not_started, extract_done, approved, design_done, plan_done, dev_in_progress, dev_done, done
-
-=============================================================================
--->
-
-## Resumo
-
-| # | Feature | Status | {{AREA_1}} | {{AREA_2}} | {{AREA_N}} | Última atualização |
-|---|---------|--------|------------|------------|------------|-------------------|
-| 1 | {{NOME}} | {{status}} | 0/N | 0/N | 0/N | {{data}} |
-
-<!-- Exemplo preenchido:
-| 1 | setup_projeto | plan_done | BANCO: 0/7 | BACK: 0/10 | FRONT: 0/3 | DOC: 0/8 | 2026-04-08 |
-| 2 | feat_cadastro_cliente | extract_done | — | — | — | — | 2026-04-09 |
--->
-
-## Legenda de Status
-
-| Status | Significado |
-|--------|-------------|
-| `not_started` | Pipeline iniciado, aguardando extração |
-| `extract_done` | PRD/TRD gerado, aguardando aprovação |
-| `approved` | Documento aprovado |
-| `design_done` | SDD gerado |
-| `plan_done` | Tasks geradas, pronto para /dev |
-| `dev_in_progress` | /dev em execução |
-| `dev_done` | Todas tasks concluídas |
-| `done` | Delta specs mergeadas (features) ou docs gerados (setup) |
-
----
-
-> **Atualização**: Cada skill atualiza este arquivo ao criar ou concluir features.
+# Progresso Geral
+
+> Visão consolidada de todas as features, bugs e tarefas do projeto.
+> Atualizado automaticamente ao final de cada `/plan` e `/dev`.
+
+---
+
+<!--
+=============================================================================
+INSTRUÇÕES PARA O AGENTE (não incluir no arquivo gerado na primeira vez)
+=============================================================================
+
+QUANDO USAR: Criado pelo /plan do primeiro setup ou feature. Atualizado por cada /plan e /dev.
+
+COMO ATUALIZAR:
+- Ao criar nova feature (/plan) → adicionar linha na tabela com contadores zerados
+- Ao concluir tasks (/dev) → atualizar contadores
+- Ao concluir feature (/merge-delta) → status "concluído" ou "done"
+
+ÁREAS SÃO DINÂMICAS:
+- Colunas de área mudam conforme o projeto (BANCO, BACK, FRONT, DOC, INFRA, MOBILE...)
+- Cada feature pode ter áreas diferentes
+- Usar "—" quando uma feature não tem tasks naquela área
+
+STATUS USA O VALOR DO .context.md:
+- not_started, extract_done, approved, design_done, plan_done, dev_in_progress, dev_done, done
+
+=============================================================================
+-->
+
+## Resumo
+
+| # | Feature | Status | {{AREA_1}} | {{AREA_2}} | {{AREA_N}} | Última atualização |
+|---|---------|--------|------------|------------|------------|-------------------|
+| 1 | {{NOME}} | {{status}} | 0/N | 0/N | 0/N | {{data}} |
+
+<!-- Exemplo preenchido:
+| 1 | setup_projeto | plan_done | BANCO: 0/7 | BACK: 0/10 | FRONT: 0/3 | DOC: 0/8 | 2026-04-08 |
+| 2 | feat_cadastro_cliente | extract_done | — | — | — | — | 2026-04-09 |
+-->
+
+## Legenda de Status
+
+| Status | Significado |
+|--------|-------------|
+| `not_started` | Pipeline iniciado, aguardando extração |
+| `extract_done` | PRD/TRD gerado, aguardando aprovação |
+| `approved` | Documento aprovado |
+| `design_done` | SDD gerado |
+| `plan_done` | Tasks geradas, pronto para /dev |
+| `dev_in_progress` | /dev em execução |
+| `dev_done` | Todas tasks concluídas |
+| `done` | Delta specs mergeadas (features) ou docs gerados (setup) |
+
+---
+
+> **Atualização**: Cada skill atualiza este arquivo ao criar ou concluir features.

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

@@ -1,82 +0,0 @@
-# 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

@@ -1,104 +0,0 @@
-# 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

@@ -1,99 +0,0 @@
-# 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 |
-|------|---------|------|-----------|
-|      |         |      |           |