spec-first-copilot 0.3.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/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 |
-|------|---------|------|-----------|
-|      |         |      |           |

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

@@ -1,78 +0,0 @@
-# Stack Tecnológica
-
-> Tecnologias escolhidas, versões fixadas, e alternativas descartadas com justificativa.
-
----
-
-<!--
-=============================================================================
-INSTRUÇÕES PARA O AGENTE (não incluir no arquivo gerado)
-=============================================================================
-
-ORIGEM: Gerado pelo /setup-projeto a partir do TRD §2.
-ATUALIZAÇÃO: /merge-delta quando features introduzem novas tecnologias ou mudanças de stack (raro — deve gerar ADR).
-
-COMO GERAR:
-1. Ler TRD §2 (Stack e Tecnologias) — todas decisões de tech
-2. Preencher TODAS as camadas, mesmo que "a definir"
-3. Para cada tecnologia: versão EXATA (não "latest")
-4. Justificativa deve ser técnica, não "é popular"
-5. Alternativas descartadas: documentar POR QUE foram rejeitadas (evita rediscussão)
-
-REGRAS:
-- Versões devem ser fixadas (ex: "18.3.1", não "^18.0.0")
-- Cada biblioteca/pacote precisa de justificativa (evita bloat)
-- Alternativas descartadas previnem que o time rediscuta decisões já tomadas
-- Mudanças de stack DEVEM gerar ADR em ADRs.md
-- Camadas são dinâmicas — adicionar conforme necessidade (mobile, infra, etc.)
-
-=============================================================================
--->
-
-## Stack Principal
-
-| Camada | Tecnologia | Versão | Justificativa |
-|--------|-----------|--------|---------------|
-| Frontend | | | |
-| Backend | | | |
-| Banco de Dados | | | |
-| ORM/Query Builder | | | |
-| Autenticação | | | |
-| Testes | | | |
-| CI/CD | | | |
-
-<!-- Adicionar camadas conforme necessidade: Mobile, Cache, Fila, Monitoramento, etc. -->
-
-## Bibliotecas e Dependências
-
-<!-- Repetir seção para cada camada que tenha dependências relevantes -->
-
-### {{Camada}}
-
-| Pacote | Versão | Para quê | Alternativa descartada |
-|--------|--------|----------|----------------------|
-|        |        |          |                      |
-
-## Alternativas Descartadas
-
-> Decisões já tomadas. Se alguém perguntar "por que não usamos X?", a resposta está aqui.
-
-| Tecnologia escolhida | Alternativa considerada | Por que descartamos | Ref ADR |
-|----------------------|------------------------|---------------------|---------|
-|                      |                        |                     |         |
-
-## Convenções de Versionamento
-
-| Aspecto | Convenção |
-|---------|-----------|
-| Versionamento | <!-- Semver? Pinned? --> |
-| Lock files | <!-- package-lock.json? yarn.lock? --> |
-| Atualização | <!-- Dependabot? Manual? Periodicidade? --> |
-
----
-
-## Changelog
-
-| Data | Feature | Tipo | Descrição |
-|------|---------|------|-----------|
-|      |         |      |           |

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

@@ -1,82 +0,0 @@
-# Visão do Sistema
-
-> C4 Nível 1 — Contexto do sistema: o que é, quem usa, com o que integra, quais restrições existem.
-
----
-
-<!--
-=============================================================================
-INSTRUÇÕES PARA O AGENTE (não incluir no arquivo gerado)
-=============================================================================
-
-ORIGEM: Gerado pelo /setup-projeto a partir do TRD §1.
-ATUALIZAÇÃO: /merge-delta quando features alteram contexto global (novos atores, integrações, restrições).
-
-COMO GERAR:
-1. Ler TRD §1 (Visão do Sistema) — é a fonte primária
-2. Ler TRD §8 (Módulos Planejados) — alimenta o Roadmap
-3. Descrever o sistema em 2-3 frases objetivas (sem jargão de marketing)
-4. Listar TODOS os atores e papéis mencionados nos insumos
-5. Listar TODAS as integrações externas com direção clara
-6. Glossário: termos de domínio que o time precisa compartilhar (DDD ubiquitous language)
-
-REGRAS:
-- Descrição do sistema deve responder: O QUE faz, PARA QUEM, QUAL PROBLEMA resolve
-- Atores devem ter permissões gerais claras (o que pode E o que NÃO pode)
-- Integrações devem ter direção explícita (envia/recebe/ambos)
-- Glossário não é opcional — termos ambíguos geram bugs
-
-=============================================================================
--->
-
-## O que é este sistema?
-
-<!-- Descrição em 2-3 frases. O que ele faz, para quem, qual problema resolve. -->
-
-
-## Usuários e Papéis
-
-| Papel | O que faz | O que NÃO pode fazer | Nível de acesso |
-|-------|-----------|----------------------|-----------------|
-|       |           |                      |                 |
-
-## Integrações Externas
-
-| Sistema/Serviço | Tipo (API/Webhook/Arquivo/Fila) | Direção (Envia/Recebe/Ambos) | Descrição | SLA/Disponibilidade |
-|-----------------|--------------------------------|------------------------------|-----------|---------------------|
-|                 |                                |                              |           |                     |
-
-## Restrições e Premissas
-
-### Restrições técnicas
--
-
-### Restrições de negócio
--
-
-### Premissas
--
-
-## Roadmap de Módulos
-
-> Extraído do TRD §8. Visão de alto nível das funcionalidades planejadas.
-
-| # | Módulo | Prioridade | Dependências | Status |
-|---|--------|-----------|--------------|--------|
-|   |        |           |              | planejado / em desenvolvimento / concluído |
-
-## Glossário
-
-> Termos do domínio usados em todo o projeto. Linguagem ubíqua (DDD).
-
-| Termo | Definição | Exemplo de uso |
-|-------|-----------|----------------|
-|       |           |                |
-
----
-
-## Changelog
-
-| Data | Feature | Tipo | Descrição |
-|------|---------|------|-----------|
-|      |         |      |           |