spec-first-copilot 0.6.0-beta.4 → 0.6.0-beta.6

package/templates/.github/templates/feature/sdd.template.md

@@ -4,6 +4,12 @@
 > Gerado pelo `/design` a partir do PRD (se existir) + chunks tech do `/extract`.
 > O Coder lê APENAS este documento + `specs/{{NOME}}/` e seu task específica.
 > Se não está aqui, não será implementado.
+>
+> **Sobre o tamanho do template**: o SDD tem 12 seções para cobrir o range completo
+> (app simples → sistema distribuído com 5 serviços). Escopo pequeno preenche 3-4
+> seções e marca as outras como "N/A" ou "não se aplica" — isso é **esperado**.
+> Áreas não tocadas (§4-§7) usam `GATE: NÃO` e ficam vazias. Não inflar conteúdo
+> pra preencher seção vazia — "N/A" é resposta válida.
 
 ---
 
@@ -12,8 +18,8 @@
 | Campo | Valor |
 |-------|-------|
 | Scope | `{{NOME}}` |
-| PRD | `workspace/Output/{{NOME}}/PRD.md` — `empty: {{true|false}}` |
-| First-run | `{{true|false}}` — true quando `docs/` não existia antes desta execução |
+| PRD | `workspace/Output/{{NOME}}/PRD.md` — `empty: {{true\|false}}` (sem aspas, bool) |
+| First-run | `{{true\|false}}` — true quando `docs/` não existia antes desta execução |
 | Áreas tocadas | `[BACK?, FRONT?, DB?, INFRA?]` |
 | Status | `rascunho` → `em revisão` → `aprovado` → `em dev` → `concluído` |
 | Autor | `/design` |
@@ -507,12 +513,13 @@ Then {{resultado esperado}}
 
 ## 12. Ambiguidades Pendentes
 
-> ⚠️ **BLOQUEANTE** — `/design` não conclui com ambiguidades abertas.
-> Analyzer consultou `docs/` antes de listar — itens aqui são genuínos.
+> ⚠️ **BLOQUEANTE** — `/plan` não conclui com ambiguidades abertas.
+> Architect consultou `docs/` antes de listar — itens aqui são genuínos.
+> IDs começam em `AMB-NNN`, continuando a sequência iniciada no PRD §14 (se houver).
 
-| # | Pergunta | Contexto | Consultei `docs/`? | Resposta |
-|---|----------|----------|--------------------|-----------|
-| 1 | | | sim / não / docs ausente | (aguardando) |
+| ID | Pergunta | Contexto | Consultei `docs/`? | Resposta |
+|----|----------|----------|--------------------|-----------|
+| AMB-001 | | | sim / não / docs ausente | (aguardando) |
 
 ---
 

package/templates/.github/templates/global/progresso_global.template.md

@@ -18,7 +18,7 @@ COMO ATUALIZAR:
 - Ao concluir feature (/merge-docs) → status "concluído" ou "done"
 
 ÁREAS SÃO DINÂMICAS:
-- Colunas de área mudam conforme o projeto (BANCO, BACK, FRONT, DOC, INFRA, MOBILE...)
+- Colunas de área mudam conforme o projeto (DB, BACK, FRONT, DOC, INFRA, MOBILE...)
 - Cada feature pode ter áreas diferentes
 - Usar "—" quando uma feature não tem tasks naquela área
 
@@ -35,7 +35,7 @@ STATUS USA O VALOR DO .context.md:
 | 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 |
+| 1 | setup_projeto | plan_done | DB: 0/7 | BACK: 0/10 | FRONT: 0/3 | DOC: 0/8 | 2026-04-08 |
 | 2 | feat_cadastro_cliente | extract_done | — | — | — | — | 2026-04-09 |
 -->
 

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

@@ -1,7 +1,7 @@
 # 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`.
+> Contexto da feature para o coder: por quê, o quê e onde.
+> Gerado pelo /design a partir do SDD. NUNCA editado manualmente.
 
 ---
 
@@ -10,25 +10,37 @@
 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.
+ORIGEM: /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.
+REGRA DE OURO: Se algo aqui diverge do SDD, o SDD vence. Re-rode /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.
+O brief é o "por quê + o quê + onde" destilado. O coder lê ANTES de abrir contracts.md.
+Sem narrativa longa — bullets objetivos. Código NÃO é derivado daqui.
+
+SOBRE "Serviços tocados":
+- Listar os repos de projetos.yaml que esta feature modifica
+- Incluir a área (BACK/FRONT/DB/INFRA) por serviço
+- Se first-run (setup), listar todos os repos que serão CRIADOS
 
 =============================================================================
 -->
 
 ## Problema
 
-<!-- 2-3 frases. O que está faltando/quebrado que essa feature resolve. -->
+<!-- 2-3 frases. O que está faltando ou quebrado que esta feature resolve. -->
 
 ## Solução
 
-<!-- High level: como estamos resolvendo. Não é design técnico. -->
+<!-- High level: como estamos resolvendo. Sem design técnico — isso está em contracts.md. -->
+
+## Serviços tocados
+
+<!-- Quais repos (de projetos.yaml) esta feature toca e em quais áreas. -->
+
+| Repo | Áreas | Tipo de mudança |
+|------|-------|-----------------|
+|      |       | nova funcionalidade / alteração / infra |
 
 ## Escopo
 
@@ -40,7 +52,7 @@ Contratos ficam em contracts.md. Cenários ficam em scenarios.md.
 
 ## Decisões principais
 
-<!-- Mini-ADRs inline — cada decisão com justificativa em 1 linha. -->
+<!-- Mini-ADRs inline — só decisões específicas desta feature, não as globais de docs/decisions.md. -->
 
 | # | Decisão | Justificativa |
 |---|---------|---------------|

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

@@ -1,7 +1,7 @@
 # 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`.
+> Contratos executáveis da feature: modelo de dados, API, integrações e regras de negócio.
+> Gerado pelo /design a partir do SDD. NUNCA editado manualmente.
 
 ---
 
@@ -10,73 +10,132 @@
 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.
+ORIGEM: /design — projeção do SDD §Área-DB (dados) + §Área-Backend (endpoints/regras)
+        + §Área-* (integrações externas). Complementa (não repete) docs/apiContracts.md.
 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.
+REGRA DE OURO: Se algo aqui diverge do SDD, o SDD vence. Re-rode /design.
+
+DISTINÇÃO CRÍTICA (3 camadas):
+- Camada 1 — Schema de DADOS: estrutura do banco (tabela, coluna, tipo, constraint DB)
+  → vira migration SQL
+  → seção "Dados"
+- Camada 2 — VALIDAÇÃO DE ENTRADA: restrição de formato/tipo do request
+  → verificada ANTES da lógica de negócio, no DTO/model via anotações
+  → ex: "email é string, obrigatório, formato válido, max 255 chars"
+  → seção "Validações de Entrada"
+- Camada 3 — REGRA DE NEGÓCIO: invariante do domínio, envolve estado
+  → verificada NO SERVIÇO, pós-schema pós-validação
+  → ex: "email não pode estar cadastrado em outra conta ativa"
+  → seção "Regras de Negócio"
+
+Essas três camadas não se sobrepõem. Regras em uma camada não aparecem na outra.
+
+CONVENÇÕES GLOBAIS: NÃO duplicar aqui o que já está em docs/apiContracts.md
+(paginação, HTTP codes genéricos, formato de erro, convenções de rota). Apenas referenciar.
+Colocar aqui apenas o que é ESPECÍFICO desta feature.
+
+PARA CODERS:
+- Campos de dados: tipos EXATOS do banco (varchar(255), não "string")
+- Requests/responses JSON: completos, com todos os campos nomeados
+- Regras de negócio: RN-NNN com enforcement point explícito
+- Integrações: timeout + retry + fallback obrigatórios
 
 =============================================================================
 -->
 
 ## Dados
 
-<!-- Entidades, tabelas, campos, constraints, índices.
-Tipos EXATOS do banco escolhido (varchar(255), não "string"). -->
+<!-- Entidades tocadas por esta feature. Dois casos:
+A) Tabela nova → usar subseção "Tabelas novas"
+B) Alteração em tabela existente → usar subseção "Alterações"
+Se nenhum dos dois: omitir seção Dados inteira. -->
+
+### Tabelas novas
+
+#### {{tabela}}
 
-### {{tabela}}
+> {{descrição em 1 linha}}
 
-| Coluna | Tipo | Nullable | Default | Constraint |
-|--------|------|----------|---------|------------|
-|        |      |          |         |            |
+| Coluna | Tipo | Nullable | Default | Constraint | Descrição |
+|--------|------|----------|---------|------------|-----------|
+|        |      |          |         |            |           |
 
 **Relações:**
-- `campo_id` → `tabela_ref(id)` ON DELETE ...
+- `campo_id` → `tabela_ref(id)` ON DELETE RESTRICT / CASCADE / SET NULL
 
 **Índices:**
-- `idx_nome` em `(colunas)` — justificativa
+- `idx_{{tabela}}_{{campo}}` em `(campo)` — justificativa (qual query usa)
+
+### Alterações em tabelas existentes
+
+<!-- Uma subseção por tabela alterada. Listar apenas o que MUDA. -->
+
+#### {{tabela_existente}}
+
+| Operação | Coluna / Índice | Detalhe |
+|----------|-----------------|---------|
+| ADD COLUMN | `nome_coluna` | tipo + constraint + default |
+| ALTER COLUMN | `nome_coluna` | o que muda (tipo, nullable, default) |
+| DROP COLUMN | `nome_coluna` | justificativa + impacto em dados |
+| ADD INDEX | `idx_nome` | colunas + justificativa |
+| ADD FK | `campo_id` | referência + ON DELETE |
+
+## Validações de Entrada (schema)
+
+<!-- Restrições de formato/tipo verificadas ANTES da lógica de negócio.
+Viram anotações/atributos de validação no DTO/model de request.
+NÃO são regras de negócio (que consultam estado). Se não há endpoint, omitir. -->
+
+| Endpoint | Campo | Tipo | Obrigatório | Restrição de formato | Mensagem de erro |
+|----------|-------|------|-------------|----------------------|------------------|
+|          |       |      |             |                      |                  |
 
 ## API
 
-<!-- Endpoints com contratos JSON completos. -->
+<!-- Convenções globais (rota, paginação, HTTP codes, formato de erro): ver docs/apiContracts.md.
+Documentar aqui apenas contratos ESPECÍFICOS desta feature.
+Se feature backend sem HTTP exposto (worker/job) ou frontend-only: omitir seção. -->
 
-### {{método}} {{rota}}
+### {{MÉTODO}} {{rota}}
 
-**Auth**: <!-- Bearer / público / role -->
-**Rate limit**: <!-- categoria -->
+**Auth**: <!-- Bearer / público / papel mínimo exigido -->
+**Rate limit**: <!-- categoria (ver docs/conventions.md) -->
 
 **Request:**
 ```json
-{}
+{
+}
 ```
 
 **Response 200:**
 ```json
-{}
+{
+}
 ```
 
-**Errors:**
-| Status | Code | Quando |
-|--------|------|--------|
-| 400 | | |
-| 422 | | |
+**Erros específicos desta feature:**
+| Status | Código de domínio | Quando |
+|--------|------------------|--------|
+| 422 | | RN-NNN violada |
+| 409 | | |
 
-## Integrações externas
+## Integrações Externas
 
-<!-- Sistemas terceiros que essa feature consome/notifica. -->
+<!-- Sistemas terceiros que esta feature consome ou notifica.
+Se não houver: omitir seção. -->
 
 | Sistema | Direção | Protocolo | Timeout | Retry | Fallback |
 |---------|---------|-----------|---------|-------|----------|
 |         |         |           |         |       |          |
 
-## Regras de negócio
+## Regras de Negócio
 
-<!-- RN-NNN com ponto de enforcement (DB constraint, service, middleware, etc). -->
+<!-- Invariantes do domínio que envolvem estado (banco, cache, contexto).
+Distintas de validação de entrada — estas são executadas no serviço, pós-schema.
+Enforcement point = onde a regra é verificada no código (service, middleware, DB constraint). -->
 
-| ID | Regra | Enforcement | Error code |
-|----|-------|-------------|------------|
-| RN-001 |  |  |  |
+| ID | Regra | Enforcement point | Código de erro |
+|----|-------|------------------|----------------|
+| RN-001 | | service / db constraint / middleware | |
+| RN-002 | | | |

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

@@ -1,7 +1,7 @@
 # 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`.
+> Critérios de aceite + fluxos + estados de UI. Fonte de verdade para o Reviewer.
+> Gerado pelo /design a partir do SDD. NUNCA editado manualmente.
 
 ---
 
@@ -10,70 +10,108 @@
 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.
+ORIGEM: /design — projeção do SDD §Área-Backend (fluxos/validações) + §Área-Frontend
+        (telas/componentes) + §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.
+REGRA DE OURO: Se algo aqui diverge do SDD, o SDD vence. Re-rode /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).
+TERMINOLOGIA (dois níveis de pré-condição):
+- PRÉ-CONDIÇÕES GLOBAIS (seção no topo): estado que aplica a TODOS os cenários abaixo.
+  Ex: "sistema populado com seed", "usuário X existe em papel Y".
+- PRÉ-CONDIÇÃO DO CA (dentro do CA): estado ADICIONAL específico daquele CA.
+  Ex: "produto com estoque = 0" em CA que testa venda sem estoque.
 
-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.
+REGRAS DE PREENCHIMENTO:
+- 1 CA = 1 regra de negócio testável (não agrupar múltiplas regras num CA)
+- Cada CA DEVE ter um teste mapeado — sem teste = CA inválido
+- Fluxos de erro têm seção própria — não esconder em "Caminhos de erro" do happy path
+- Cada linha de "Fluxos de Erro" referencia o CA correspondente (coluna Ref CA)
+- Feature sem frontend: seção UI/Componentes = "N/A — backend-only"
+- Pré-condição = estado do banco/sistema, não input do usuário (input fica no When)
+- Estratégia de testes NÃO redefine frameworks — referencia docs/architecture.md
+
+PARA O REVIEWER:
+- Validar que cada CA-NNN tem teste executável correspondente
+- Usar esta tabela de estados como checklist de UI
+- Fluxos de erro são obrigatórios no happy path test suite (não opcionais)
 
 =============================================================================
 -->
 
-## Fluxos principais
+## Pré-condições Globais
+
+<!-- Estado do sistema ANTES de executar os cenários abaixo. Aplicam a TODOS.
+Exemplos: quais registros precisam existir no banco, qual papel está autenticado,
+quais flags de feature estão ativas. Se não houver: "Estado limpo — sem pré-condições." -->
+
+| Condição | Valor esperado |
+|----------|---------------|
+|          |               |
+
+## Fluxos — Happy Path
 
-<!-- Sequências usuário → front → back → resposta. Caminhos de erro inclusos. -->
+<!-- 1 fluxo por entregável principal. Formato linear: quem faz o quê e qual resultado.
+Nível suficiente para coder implementar e reviewer validar — sem narrativa extra. -->
 
 ### Fluxo: {{nome}}
 
-```
-usuário → [ação] → front → [request] → back → [validação+persistência] → resposta
-```
+| Passo | Ator | Ação / Request | Resultado / Response |
+|-------|------|---------------|----------------------|
+| 1 | | | |
+| 2 | | | |
 
-**Caminhos de erro:**
-- Erro X → resposta Y
-- Timeout → retry / fallback
+## Fluxos — Erro e Edge Cases
+
+<!-- Desvios do happy path. Cada linha = 1 scenario testável.
+Não omitir: são obrigatórios nos testes de integração.
+Ref CA aponta pro CA detalhado abaixo que cobre este erro. -->
+
+| Cenário | Pré-condição | Ação | Resposta esperada | HTTP / Código | Ref CA |
+|---------|-------------|------|-------------------|---------------|--------|
+|         |             |      |                   |               |        |
 
 ## UI / Componentes
 
-<!-- Telas e componentes principais com seus estados. -->
+<!-- Se backend-only: escrever "N/A — feature sem frontend." e pular esta seção. -->
 
 ### {{componente}}
 
-| Estado | Gatilho | Visual |
-|--------|---------|--------|
-| loading | | |
-| empty | | |
-| error | | |
-| success | | |
+| Estado | Gatilho | O que exibe | Dado / Mensagem |
+|--------|---------|-------------|-----------------|
+| loading | | skeleton / spinner | — |
+| empty | | | |
+| error | | mensagem de erro | código ou texto |
+| success | | | |
 
 ## Critérios de Aceite
 
-<!-- Given/When/Then. Cada CA deve ser mapeável a um teste. -->
+<!-- 1 CA = 1 regra de negócio testável. Given/When/Then em 1 linha cada.
+Pré-condição = estado do sistema ADICIONAL às pré-condições globais (não repetir). -->
 
-### CA-001: {{título curto}}
+### CA-001: {{título da regra — imperativo curto}}
 
-- **Given**: estado inicial
-- **When**: ação
-- **Then**: resultado esperado
-- **Teste**: `tipo` — `arquivo_de_teste.ext`
+- **Pré-condição**: <!-- estado adicional às globais. Ex: "produto com estoque = 0" -->
+- **Given**: <!-- contexto do ator -->
+- **When**: <!-- ação executada -->
+- **Then**: <!-- resultado observável e verificável -->
+- **Teste**: `unit|integration|e2e` — `caminho/do/arquivo_test.ext`
 
-### CA-002: {{título curto}}
+### CA-002: {{título}}
 
+- **Pré-condição**:
 - **Given**:
 - **When**:
 - **Then**:
 - **Teste**:
 
-## Estratégia de testes
+## Estratégia de Testes
+
+<!-- NÃO redefinir frameworks — usar os definidos em docs/architecture.md.
+Descrever escopo e cobertura esperada para esta feature. -->
 
-| Nível | Framework | O que testa | Onde rodam |
-|-------|-----------|-------------|------------|
-| Unit | | lógica isolada | por task |
-| Integration | | entre componentes | por fase |
-| E2E | | CAs completos | por feature |
+| Nível | Escopo nesta feature | Quando roda | Responsável |
+|-------|----------------------|-------------|-------------|
+| Unit | lógica de negócio isolada (serviços, validadores) | por task | coder |
+| Integration | fluxo request → DB → response | por fase | coder |
+| E2E | CAs críticos end-to-end | por feature | coder (escreve) + reviewer (valida) |

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

@@ -1,61 +1,63 @@
-# Tasks — {{NOME}}
-
-> Plano de implementação único. Todas as tasks em uma tabela com coluna Área.
-> Gerado pelo /sf-plan a partir do SDD + 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
--
+# Tasks — {{NOME}}
+
+> Plano de implementação: todas as tasks em tabela única com coluna Área.
+> Gerado pelo /plan a partir do SDD + specs/{{NOME}}/. NUNCA editado manualmente.
+
+---
+
+<!--
+=============================================================================
+INSTRUÇÕES PARA O AGENTE (não incluir no arquivo gerado)
+=============================================================================
+
+ORIGEM: /plan — deriva de sdd.md + contracts.md + scenarios.md
+ATUALIZAÇÃO: /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 atual.
+
+CAMPOS OBRIGATÓRIOS (toda task):
+- ID:       {ÁREA}-NNN sequencial por área (DB-001, BACK-001, FRONT-001, INFRA-001)
+- Área:     derivada do SDD — dinâmica, não fixa. Só as áreas que esta feature toca.
+- Fase:     número da fase de entrega (do PRD §11). 1 fase = 1 entregável = 1 PR.
+            Em bootstrap (PRD empty): toda task vai pra Fase 1 (setup inicial).
+- Tam:      S (≤2h) | M (≤4h) | L (≤2 dias)
+- Título:   verbo imperativo + objeto ("Criar migration tabela pedidos")
+- Repo:     nome do serviço em projetos.yaml (api, web, worker...)
+- Arquivos: paths relativos ao repo que serão criados/modificados
+- Depende:  IDs de tasks que precisam estar concluídas antes. Cross-área OK.
+- Ref SDD:  seção do SDD que originou a task (ex: "§4.2", "§Área-BACK"). Obrigatório.
+- Ref CA:   ID do CA em scenarios.md que esta task satisfaz. Opcional
+            (INFRA/DOC costumam não ter; BACK/FRONT normalmente têm).
+
+PARA TASKS TAMANHO L:
+- Preencher bloco "Done When — {TASK-ID}" logo abaixo da tabela
+- L sugere: considerar dividir em 2 tasks M (INVEST: Small)
+- Reviewer usa "Done When" como checklist antes de aprovar
+
+REGRAS:
+- IDs estáveis — nunca renumerar após commit
+- Toda task com Ref CA deve ter teste correspondente (unit ou integration)
+- Mesma fase = podem rodar em paralelo dentro da área
+- Fases são SEQUENCIAIS entre si
+- Áreas são dinâmicas — preencher apenas as tocadas pela feature
+
+=============================================================================
+-->
+
+## Tasks
+
+| ID | Área | Fase | Tam | Título | Repo | Arquivos | Depende de | Ref SDD | Ref CA |
+|----|------|------|-----|--------|------|----------|-----------|---------|--------|
+|    |      |      |     |        |      |          | —         |         | —      |
+
+## Done When — Tasks L
+
+<!-- 1 bloco por task L. Remover esta seção inteira se não houver tasks L.
+3-5 bullets verificáveis. Cada bullet deve ser observável objetivamente. -->
+
+### {TASK-ID}
+
+- [ ] 
+- [ ] 
+- [ ]