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

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/.github/templates/specs/brief.template.md

@@ -0,0 +1,47 @@
+# Brief — {{NOME}}
+
+> Projeção estruturada do SDD para consumo do agent coder.
+> Gerado automaticamente pelo /sf-design a partir do SDD em `workspace/Output/{{NOME}}/sdd.md`.
+
+---
+
+<!--
+=============================================================================
+INSTRUÇÕES PARA O AGENTE (não incluir no arquivo gerado)
+=============================================================================
+
+ORIGEM: /sf-design — projeção do SDD §1 Visão geral + §2 Decisões + §10 Fora do escopo.
+ATUALIZAÇÃO: Sempre regenerado junto com o SDD. NUNCA editado manualmente.
+
+REGRA DE OURO: Se algo aqui diverge do SDD, o SDD vence. Re-rode /sf-design.
+
+O brief é o "por quê" + "o quê" destilado. Sem narrativa longa — bullets objetivos.
+O coder lê o brief pra contexto, mas não deriva código daqui.
+Contratos ficam em contracts.md. Cenários ficam em scenarios.md.
+
+=============================================================================
+-->
+
+## Problema
+
+<!-- 2-3 frases. O que está faltando/quebrado que essa feature resolve. -->
+
+## Solução
+
+<!-- High level: como estamos resolvendo. Não é design técnico. -->
+
+## Escopo
+
+### Dentro
+-
+
+### Fora
+-
+
+## Decisões principais
+
+<!-- Mini-ADRs inline — cada decisão com justificativa em 1 linha. -->
+
+| # | Decisão | Justificativa |
+|---|---------|---------------|
+| 1 |         |               |

package/templates/.github/templates/specs/contracts.template.md

@@ -0,0 +1,82 @@
+# Contracts — {{NOME}}
+
+> Projeção estruturada do SDD para consumo do agent coder.
+> Gerado automaticamente pelo /sf-design a partir do SDD em `workspace/Output/{{NOME}}/sdd.md`.
+
+---
+
+<!--
+=============================================================================
+INSTRUÇÕES PARA O AGENTE (não incluir no arquivo gerado)
+=============================================================================
+
+ORIGEM: /sf-design — projeção do SDD §3 Modelo de dados + §4 Regras/validações
+        + §5 Endpoints API + §8 Integrações externas.
+ATUALIZAÇÃO: Sempre regenerado junto com o SDD. NUNCA editado manualmente.
+
+REGRA DE OURO: Se algo aqui diverge do SDD, o SDD vence. Re-rode /sf-design.
+
+O contracts.md é o "o que construir" — contratos executáveis.
+Tipos exatos do banco (não "string"). Request/response JSON completos.
+Regras de negócio com RN-NNN e enforcement points.
+
+=============================================================================
+-->
+
+## Dados
+
+<!-- Entidades, tabelas, campos, constraints, índices.
+Tipos EXATOS do banco escolhido (varchar(255), não "string"). -->
+
+### {{tabela}}
+
+| Coluna | Tipo | Nullable | Default | Constraint |
+|--------|------|----------|---------|------------|
+|        |      |          |         |            |
+
+**Relações:**
+- `campo_id` → `tabela_ref(id)` ON DELETE ...
+
+**Índices:**
+- `idx_nome` em `(colunas)` — justificativa
+
+## API
+
+<!-- Endpoints com contratos JSON completos. -->
+
+### {{método}} {{rota}}
+
+**Auth**: <!-- Bearer / público / role -->
+**Rate limit**: <!-- categoria -->
+
+**Request:**
+```json
+{}
+```
+
+**Response 200:**
+```json
+{}
+```
+
+**Errors:**
+| Status | Code | Quando |
+|--------|------|--------|
+| 400 | | |
+| 422 | | |
+
+## Integrações externas
+
+<!-- Sistemas terceiros que essa feature consome/notifica. -->
+
+| Sistema | Direção | Protocolo | Timeout | Retry | Fallback |
+|---------|---------|-----------|---------|-------|----------|
+|         |         |           |         |       |          |
+
+## Regras de negócio
+
+<!-- RN-NNN com ponto de enforcement (DB constraint, service, middleware, etc). -->
+
+| ID | Regra | Enforcement | Error code |
+|----|-------|-------------|------------|
+| RN-001 |  |  |  |

package/templates/.github/templates/specs/scenarios.template.md

@@ -0,0 +1,79 @@
+# Scenarios — {{NOME}}
+
+> Projeção estruturada do SDD para consumo do agent coder e reviewer.
+> Gerado automaticamente pelo /sf-design a partir do SDD em `workspace/Output/{{NOME}}/sdd.md`.
+
+---
+
+<!--
+=============================================================================
+INSTRUÇÕES PARA O AGENTE (não incluir no arquivo gerado)
+=============================================================================
+
+ORIGEM: /sf-design — projeção do SDD §6 Componentes/telas + §7 Fluxos de dados
+        + §9 Estratégia de testes + Critérios de aceite.
+ATUALIZAÇÃO: Sempre regenerado junto com o SDD. NUNCA editado manualmente.
+
+REGRA DE OURO: Se algo aqui diverge do SDD, o SDD vence. Re-rode /sf-design.
+
+O scenarios.md é o "como validar que funciona" — Given/When/Then testáveis,
+fluxos usuário→front→back, estados de UI (loading/empty/error/success).
+
+O REVIEWER usa este arquivo pra validar critérios de aceite após implementação.
+Cada CA-NNN deve ser mapeável a um teste executável.
+
+=============================================================================
+-->
+
+## Fluxos principais
+
+<!-- Sequências usuário → front → back → resposta. Caminhos de erro inclusos. -->
+
+### Fluxo: {{nome}}
+
+```
+usuário → [ação] → front → [request] → back → [validação+persistência] → resposta
+```
+
+**Caminhos de erro:**
+- Erro X → resposta Y
+- Timeout → retry / fallback
+
+## UI / Componentes
+
+<!-- Telas e componentes principais com seus estados. -->
+
+### {{componente}}
+
+| Estado | Gatilho | Visual |
+|--------|---------|--------|
+| loading | | |
+| empty | | |
+| error | | |
+| success | | |
+
+## Critérios de Aceite
+
+<!-- Given/When/Then. Cada CA deve ser mapeável a um teste. -->
+
+### CA-001: {{título curto}}
+
+- **Given**: estado inicial
+- **When**: ação
+- **Then**: resultado esperado
+- **Teste**: `tipo` — `arquivo_de_teste.ext`
+
+### CA-002: {{título curto}}
+
+- **Given**:
+- **When**:
+- **Then**:
+- **Teste**:
+
+## Estratégia de testes
+
+| Nível | Framework | O que testa | Onde rodam |
+|-------|-----------|-------------|------------|
+| Unit | | lógica isolada | por task |
+| Integration | | entre componentes | por fase |
+| E2E | | CAs completos | por feature |

package/templates/.github/templates/specs/tasks.template.md

@@ -0,0 +1,61 @@
+# Tasks — {{NOME}}
+
+> Plano de implementação único. Todas as tasks em uma tabela com coluna Área.
+> Gerado pelo /sf-plan a partir do SDD + docs/specs/{{NOME}}/.
+
+---
+
+<!--
+=============================================================================
+INSTRUÇÕES PARA O AGENTE (não incluir no arquivo gerado)
+=============================================================================
+
+ORIGEM: /sf-plan — deriva de sdd.md + contracts.md + scenarios.md
+ATUALIZAÇÃO: /sf-plan re-roda se SDD/contracts/scenarios mudarem.
+
+STATUS vive em workspace/Output/{{NOME}}/Progresso.md — NÃO aqui.
+Tasks são só a definição do que precisa ser feito, não o estado.
+
+CAMPOS OBRIGATÓRIOS:
+- ID: {ÁREA}-NNN sequencial por área (BANCO-001, BACK-001, FRONT-001, INFRA-001)
+- Área: BANCO | BACK | FRONT | INFRA | DOC
+- Fase: número da fase de entrega (entregáveis contínuos)
+- Tamanho: S (≤2h) | M (meio dia) | L (1-2 dias)
+- Título: ação no imperativo ("Criar tabela clientes")
+- Repo: nome do serviço no projetos.yaml (api, web, worker...)
+- Arquivos: caminhos que a task vai criar/modificar (relativos ao repo)
+- Depende de: outros IDs — cross-area OK
+- Ref spec: seção do SDD que define essa task
+- Ref CA: ID do critério de aceite em scenarios.md (se aplica)
+
+REGRAS:
+- IDs estáveis — nunca renumerar após commit
+- Depends_on cross-area é OK (BACK-001 depende de BANCO-001)
+- Toda task deve ter pelo menos 1 teste (unit + optional integration)
+- Tarefas da mesma fase/área rodam em sequência, fases são sequenciais
+
+=============================================================================
+-->
+
+## Tasks
+
+| ID | Área | Fase | Tam | Título | Repo | Arquivos | Depende de | Ref spec | Ref CA |
+|----|------|------|-----|--------|------|----------|-----------|----------|--------|
+| BANCO-001 | BANCO | 1 | S | | | | — | SDD §3.1 | — |
+| BACK-001 | BACK | 1 | M | | | | BANCO-001 | SDD §5.1 | CA-001 |
+
+## Regras por área
+
+<!-- Convenções específicas extraídas do SDD + docs/ (architecture, domain, conventions). -->
+
+### BANCO
+-
+
+### BACK
+-
+
+### FRONT
+-
+
+### INFRA
+-

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 |
-|------|---------|------|-----------|
-|      |         |      |           |