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

package/templates/.github/skills/sf-feature/SKILL.md

@@ -1,130 +1,130 @@
----
-name: sf-feature
-description: |
-  Pipeline de feature. Cria contexto PRD, chama /sf-extract, para no checkpoint.
-  Trigger: /sf-feature
-author: GustavoMaritan
-version: 1.0.0
-date: 2026-04-08
----
-
-# Skill: /sf-feature
-
-> Orquestrador de feature. Cria contexto PRD, chama `/extract` e para no checkpoint de aprovação.
-
-## Tipo
-Orquestrador (primeira etapa do pipeline de feature)
-
-## Uso
-```
-/sf-feature <nome>
-```
-Exemplo: `/sf-feature feat_cadastro_cliente`
-
-### Convenção de nomes
-- Features: `feat_nome_descritivo`
-- Bugs: `bug_nome_descritivo`
-- Tasks técnicas: `task_nome_descritivo`
-
-## Pré-condições
-
-| # | Validação | Se falhar |
-|---|-----------|-----------|
-| 1 | Argumento `nome` foi informado | Parar → "Informe o nome da feature. Ex: /sf-feature feat_cadastro_cliente" |
-| 2 | `workspace/Input/{nome}/` existe | Parar → "Crie a pasta workspace/Input/{nome}/ e adicione seus insumos" |
-| 3 | Pasta contém pelo menos 1 arquivo (ignorar .gitkeep) | Parar → "Adicione insumos na pasta (aceitos: .md, .txt, .sql, .xml, .html, .json, .csv, .png, .jpg, .pdf — qualquer formato)" |
-| 4 | `docs/` está populado (setup já executado) | Parar → "Execute /sf-setup-projeto antes de criar features" |
-| 5 | `.context.md` não existe ou status é `not_started` | Se existe com status avançado → "Feature já em andamento (status: {status}). Para re-extrair, use /sf-extract {nome}" |
-
-## Passos
-
-### 1. Carregar contexto do projeto
-Ler `docs/` para entender a arquitetura, stack, modelo de dados e convenções existentes. Esse contexto será passado ao `/extract`.
-
-### 2. Criar estrutura
-```
-workspace/Output/{nome}/
-├── .context.md        ← criado agora
-└── (PRD.md será criado pelo /extract)
-```
-
-### 3. Criar `.context.md`
-```yaml
----
-nome: "{nome}"
-tipo: "feature"
-documento: "PRD"
-pm_path: "workspace/Input/{nome}/"
-status: "not_started"
-ultima_skill: "/sf-feature"
-atualizado_em: "{{ISO_DATETIME}}"
----
-```
-
-### 4. Sugerir /sf-discovery (RECOMENDADO)
-
-Antes de extrair, perguntar ao usuário:
-```
-📋 Insumos encontrados em workspace/Input/{nome}/.
-
-Recomendo rodar /sf-discovery antes da extração para:
-  - Análise profunda dos insumos
-  - Identificar gaps e contradições
-  - Validar entendimento com você
-
-Quer rodar /sf-discovery workspace/Input/{nome}/ agora? (s/n)
-  Se SIM → rodar discovery, salvar discovery.md, depois continuar com extract
-  Se NÃO → pular direto para /sf-extract
-```
-
-Se o usuário aceitar:
-- Rodar `/sf-discovery workspace/Input/{nome}/`
-- Aguardar conclusão — discovery.md salvo em `workspace/Output/{nome}/`
-- Continuar para o passo 5
-
-### 5. Chamar `/sf-extract {nome}`
-O `/sf-extract` lê os insumos + discovery.md (se existir), gera o PRD e atualiza status para `extract_done`.
-
-### 6. CHECKPOINT — Parar e informar o usuário
-Mensagem ao usuário:
-```
-✅ PRD gerado em workspace/Output/{nome}/PRD.md
-
-Revise o documento. Quando estiver satisfeito, execute:
-  /sf-design {nome}
-
-Se precisar adicionar mais insumos, coloque na pasta workspace/Input/{nome}/
-e execute:
-  /sf-extract {nome}
-```
-
-**O orquestrador encerra aqui.** O restante do pipeline é responsabilidade do usuário chamar as skills atômicas na ordem:
-1. `/sf-design {nome}` (pergunta aprovação → gera SDD)
-2. `/sf-plan {nome}` (gera tasks + Progresso)
-3. `/sf-dev {nome}` (executa tasks)
-4. `/sf-merge-delta {nome}` (aplica Delta Specs em docs/)
-
-## Saídas diretas desta skill
-- `workspace/Output/{nome}/.context.md`
-- `workspace/Output/{nome}/PRD.md` (via /extract)
-- `workspace/Output/{nome}/.extract-log.md` (via /extract)
-
-## Saídas indiretas (skills subsequentes)
-- `sdd.md` (via /design)
-- `*_tasks.md` + `Progresso.md` (via /plan)
-- `docs/` atualizado (via /sf-merge-delta após /dev)
-
-## Erros
-
-| Erro | Ação |
-|------|------|
-| Nome não informado | Parar, mostrar exemplo de uso |
-| workspace/Input/{nome}/ não existe | Parar, instruir criação |
-| workspace/Input/{nome}/ vazio | Parar, listar formatos aceitos |
-| docs/ não populado | Parar, sugerir /sf-setup-projeto |
-| Pipeline já iniciado | Mostrar status atual, sugerir /sf-extract para re-extração ou skill correspondente ao status |
-
-## Notas
-- Diferente do `/sf-setup-projeto`, pode ser executado **múltiplas vezes** (uma por feature)
-- O contexto de `docs/` é carregado para que o `/extract` gere um PRD coerente com a arquitetura existente
-- Após `/dev`, o `/merge-delta` atualiza `docs/` com as mudanças da feature
+---
+name: sf-feature
+description: |
+  Pipeline de feature. Cria contexto PRD, chama /sf-extract, para no checkpoint.
+  Trigger: /sf-feature
+author: GustavoMaritan
+version: 1.0.0
+date: 2026-04-08
+---
+
+# Skill: /sf-feature
+
+> Orquestrador de feature. Cria contexto PRD, chama `/extract` e para no checkpoint de aprovação.
+
+## Tipo
+Orquestrador (primeira etapa do pipeline de feature)
+
+## Uso
+```
+/sf-feature <nome>
+```
+Exemplo: `/sf-feature feat_cadastro_cliente`
+
+### Convenção de nomes
+- Features: `feat_nome_descritivo`
+- Bugs: `bug_nome_descritivo`
+- Tasks técnicas: `task_nome_descritivo`
+
+## Pré-condições
+
+| # | Validação | Se falhar |
+|---|-----------|-----------|
+| 1 | Argumento `nome` foi informado | Parar → "Informe o nome da feature. Ex: /sf-feature feat_cadastro_cliente" |
+| 2 | `workspace/Input/{nome}/` existe | Parar → "Crie a pasta workspace/Input/{nome}/ e adicione seus insumos" |
+| 3 | Pasta contém pelo menos 1 arquivo (ignorar .gitkeep) | Parar → "Adicione insumos na pasta (aceitos: .md, .txt, .sql, .xml, .html, .json, .csv, .png, .jpg, .pdf — qualquer formato)" |
+| 4 | `docs/` está populado (setup já executado) | Parar → "Execute /sf-setup-projeto antes de criar features" |
+| 5 | `.context.md` não existe ou status é `not_started` | Se existe com status avançado → "Feature já em andamento (status: {status}). Para re-extrair, use /sf-extract {nome}" |
+
+## Passos
+
+### 1. Carregar contexto do projeto
+Ler `docs/` para entender a arquitetura, stack, modelo de dados e convenções existentes. Esse contexto será passado ao `/extract`.
+
+### 2. Criar estrutura
+```
+workspace/Output/{nome}/
+├── .context.md        ← criado agora
+└── (PRD.md será criado pelo /extract)
+```
+
+### 3. Criar `.context.md`
+```yaml
+---
+nome: "{nome}"
+tipo: "feature"
+documento: "PRD"
+pm_path: "workspace/Input/{nome}/"
+status: "not_started"
+ultima_skill: "/sf-feature"
+atualizado_em: "{{ISO_DATETIME}}"
+---
+```
+
+### 4. Sugerir /sf-discovery (RECOMENDADO)
+
+Antes de extrair, perguntar ao usuário:
+```
+📋 Insumos encontrados em workspace/Input/{nome}/.
+
+Recomendo rodar /sf-discovery antes da extração para:
+  - Análise profunda dos insumos
+  - Identificar gaps e contradições
+  - Validar entendimento com você
+
+Quer rodar /sf-discovery workspace/Input/{nome}/ agora? (s/n)
+  Se SIM → rodar discovery, salvar discovery.md, depois continuar com extract
+  Se NÃO → pular direto para /sf-extract
+```
+
+Se o usuário aceitar:
+- Rodar `/sf-discovery workspace/Input/{nome}/`
+- Aguardar conclusão — discovery.md salvo em `workspace/Output/{nome}/`
+- Continuar para o passo 5
+
+### 5. Chamar `/sf-extract {nome}`
+O `/sf-extract` lê os insumos + discovery.md (se existir), gera o PRD e atualiza status para `extract_done`.
+
+### 6. CHECKPOINT — Parar e informar o usuário
+Mensagem ao usuário:
+```
+✅ PRD gerado em workspace/Output/{nome}/PRD.md
+
+Revise o documento. Quando estiver satisfeito, execute:
+  /sf-design {nome}
+
+Se precisar adicionar mais insumos, coloque na pasta workspace/Input/{nome}/
+e execute:
+  /sf-extract {nome}
+```
+
+**O orquestrador encerra aqui.** O restante do pipeline é responsabilidade do usuário chamar as skills atômicas na ordem:
+1. `/sf-design {nome}` (pergunta aprovação → gera SDD)
+2. `/sf-plan {nome}` (gera tasks + Progresso)
+3. `/sf-dev {nome}` (executa tasks)
+4. `/sf-merge-delta {nome}` (aplica Delta Specs em docs/)
+
+## Saídas diretas desta skill
+- `workspace/Output/{nome}/.context.md`
+- `workspace/Output/{nome}/PRD.md` (via /extract)
+- `workspace/Output/{nome}/.extract-log.md` (via /extract)
+
+## Saídas indiretas (skills subsequentes)
+- `sdd.md` (via /design)
+- `specs/{nome}/tasks.md` + `Progresso.md` (via /plan)
+- `docs/` atualizado (via /sf-merge-delta após /dev)
+
+## Erros
+
+| Erro | Ação |
+|------|------|
+| Nome não informado | Parar, mostrar exemplo de uso |
+| workspace/Input/{nome}/ não existe | Parar, instruir criação |
+| workspace/Input/{nome}/ vazio | Parar, listar formatos aceitos |
+| docs/ não populado | Parar, sugerir /sf-setup-projeto |
+| Pipeline já iniciado | Mostrar status atual, sugerir /sf-extract para re-extração ou skill correspondente ao status |
+
+## Notas
+- Diferente do `/sf-setup-projeto`, pode ser executado **múltiplas vezes** (uma por feature)
+- O contexto de `docs/` é carregado para que o `/extract` gere um PRD coerente com a arquitetura existente
+- Após `/dev`, o `/merge-delta` atualiza `docs/` com as mudanças da feature

package/templates/.github/skills/sf-plan/SKILL.md

@@ -1,178 +1,180 @@
----
-name: sf-plan
-description: |
-  Planejamento. Gera tasks por fase de entrega e área.
-  Trigger: /sf-plan
-author: GustavoMaritan
-version: 1.0.0
-date: 2026-04-08
----
-
-# Skill: /sf-plan
-
-> Skill atômica de planejamento. Lê SDD e gera tasks por área + Progresso.
-
-## Tipo
-Atômica — Single-agent
-
-## Uso
-```
-/sf-plan <nome>
-```
-Exemplo: `/sf-plan feat_cadastro_cliente`
-
----
-
-## Agente
-
-| Campo | Valor |
-|-------|-------|
-| **Papel** | Planejador técnico — decompõe especificação em tasks atômicas, ordenadas e com dependências explícitas |
-| **Modelo** | Opus |
-| **Comportamento** | Metódico e exaustivo. Cada task deve ser auto-contida (coder lê SDD §N + task, nada mais). Prioriza ordem de execução correta sobre paralelismo. Nunca cria task sem referência ao SDD. |
-
----
-
-## Pré-condições
-
-| # | Validação | Se falhar |
-|---|-----------|-----------|
-| 1 | Argumento `nome` foi informado | Parar → "Informe o nome. Ex: /sf-plan feat_cadastro_cliente" |
-| 2 | `workspace/Output/{nome}/.context.md` existe com status `design_done` | Se anterior → "Execute /sf-design {nome} primeiro". Se posterior → "Tasks já foram geradas (status: {status})" |
-| 3 | `sdd.md` existe na pasta | Parar → "SDD não encontrado. Execute /sf-design {nome}" |
-
-## Passos
-
-### 1. Ler contexto
-- Ler `.context.md` → validar status
-- Ler `sdd.md` completo
-- Ler `projetos.yaml` (manifesto de repos — mapeamento área → repo)
-- Ler `docs/` (Stack, Arquitetura — para convenções por área)
-- Ler `.github/rules.md` (padrões de código, commit, branch)
-- Carregar template `.github/templates/feature/tasks.template.md`
-
-### 2. Identificar fases de entrega
-Ler PRD §11 (Fases de Entrega) — cada fase vira um agrupamento de tasks:
-- Fases são sequenciais: Fase 2 depende de Fase 1 concluída
-- Cada fase tem entregável e critério de done
-- O `/dev` pode rodar por fase: `/sf-dev feat_nome --fase 1`
-
-### 3. Identificar áreas afetadas (por fase)
-Para cada fase de entrega, mapear seções do SDD para áreas de tasks:
-
-| Seção do SDD | Área | Condição |
-|-------------|------|----------|
-| §3 Modelo de dados | BANCO | Se há entidades/migrations |
-| §5 Endpoints API | BACK | Se há endpoints definidos |
-| §6 Componentes e telas | FRONT | Se há UI especificada |
-| §8 Integrações externas | INFRA | Se há infra/serviços externos |
-| Outras | MOBILE, DEVOPS, etc. | Conforme necessidade do SDD |
-
-> **Nota**: Área DOC NÃO existe mais no setup. docs/ é gerado pelo /sf-design (passo 3).
-> DOC só aparece em features se houver necessidade explícita de documentação adicional.
-
-Áreas são **dinâmicas** — só cria o que o SDD exige. Não criar área vazia.
-
-**Área INFRA obrigatória no setup:**
-Sempre gerar estas tasks no setup (antes de qualquer código):
-```
-- [ ] INFRA-001: Validar e configurar ambiente local [M]
-  (detectar OS, instalar Docker/.NET/Node, verificar portas)
-- [ ] INFRA-002: Criar docker-compose.yml + Dockerfiles [M]
-- [ ] INFRA-003: Hello world — subir stack completa e validar [M]
-  (docker compose up, migrations, health check, frontend carrega)
-```
-INFRA-001 é a PRIMEIRA task executada no /sf-dev do setup (antes de BANCO, BACK, FRONT).
-INFRA-003 é a ÚLTIMA task (após tudo, como validação final).
-Setup só é `done` quando INFRA-003 passa.
-
-### 4. Gerar tasks por fase × área
-Para cada área identificada, gerar `{area}_tasks.md`.
-Tasks são agrupadas por **fase de entrega** (do PRD §11), não só por fase técnica.
-
-**Estrutura de cada task:**
-```markdown
-- [ ] **AREA-NNN**: Título descritivo [Tamanho]
-  - Fase: {{N}} — {{Nome da fase de entrega}}
-  - Repo: `{{nome_repo}}` (de projetos.yaml)
-  - Arquivos: `caminho/do/arquivo.ext` (relativo à raiz do repo)
-  - SDD: §N.N — Referência específica
-  - Depende: AREA-NNN (ou — se não depende)
-```
-
-**Regras de decomposição:**
-1. Cada task é **atômica** — implementável sem consultar nada além de SDD §N + task
-2. **Repo obrigatório** — consultar `projetos.yaml` para mapear área → repo. Caminhos de arquivo são relativos à raiz do repo
-3. Tamanhos realistas: **S** (<30min), **M** (30min-2h), **L** (2h+)
-4. Se uma task é L, avaliar se pode ser quebrada em M+S
-5. IDs sequenciais por área: BANCO-001, BANCO-002, BACK-001, BACK-002
-6. IDs nunca reutilizados — se uma task for removida, o ID é aposentado
-7. Dependências explícitas — inclusive cross-area (FRONT-004 depende BACK-003)
-8. Prioridades por fase: **P1** (bloqueia outros), **P2** (importante), **P3** (nice-to-have)
-
-**Organização em fases (sequenciais dentro da área):**
-
-| Área | Fases típicas (adaptar ao SDD) |
-|------|-------------------------------|
-| BANCO | Schema/Migrations → Índices/Constraints → Seeds |
-| BACK | Setup/Config → DTOs/Validações → Repository/Service → Controller → Testes |
-| FRONT | Setup/Rotas → Componentes base → Telas → Integração API → Polish/UX |
-| INFRA | Provisioning → Config → Deploy → Monitoramento |
-| DOC | Gerar docs/ a partir do TRD |
-
-### 5. Gerar `Progresso.md`
-Usando template `.github/templates/feature/Progresso.template.md`:
-
-- Resumo por Área × Fase com contagem de tasks
-- Status por fase: ⬜ pendente | 🔄 em andamento | ✅ concluída
-- **Ordem de execução** com paralelismos:
-  ```
-  1. BANCO Fase 1 (Schema) — primeiro sempre
-  2. BANCO Fase 2 + BACK Fase 1 — podem paralelizar
-  3. BACK Fase 2-3 — sequencial
-  4. FRONT Fase 1-2 — pode iniciar após BACK Fase 3
-  ...
-  ```
-- Totais por área e geral
-- Checklist pós-conclusão (merge delta, atualizar progresso global, napkin)
-
-### 6. Atualizar progresso global
-Adicionar entrada em `workspace/Output/progresso.md`:
-
-```markdown
-| {nome} | plan_done | BANCO: 0/N | BACK: 0/N | FRONT: 0/N |
-```
-
-### 7. Atualizar `.context.md`
-```yaml
-status: "plan_done"
-ultima_skill: "/sf-plan"
-atualizado_em: "{{ISO_DATETIME}}"
-```
-
----
-
-## Saídas
-
-| Arquivo | Descrição |
-|---------|-----------|
-| `{area}_tasks.md` | 1 arquivo por área (dinâmico: banco_tasks.md, back_tasks.md, etc.) |
-| `Progresso.md` | Dashboard da feature com ordem de execução |
-| `progresso.md` (global) | Atualizado com nova feature |
-| `.context.md` | Atualizado com status `plan_done` |
-
-## Pós-condições
-- Cada task é auto-contida com referência ao SDD
-- Dependências resolvíveis (não há ciclos)
-- Ordem de execução definida no Progresso.md
-- Feature pronta para `/dev`
-
-## Erros
-
-| Erro | Ação |
-|------|------|
-| Nome não informado | Parar, mostrar exemplo |
-| Status não é design_done | Parar, sugerir skill correspondente |
-| SDD não encontrado | Parar, sugerir /sf-design |
-| SDD com seções vazias obrigatórias | Parar, listar o que falta — sugerir voltar ao /sf-design |
-| Dependência circular detectada | Parar, reportar o ciclo e sugerir reorganização |
+---
+name: sf-plan
+description: |
+  Planejamento. Gera tasks por fase de entrega e área.
+  Trigger: /sf-plan
+author: GustavoMaritan
+version: 1.0.0
+date: 2026-04-08
+---
+
+# Skill: /sf-plan
+
+> Skill atômica de planejamento. Lê SDD e gera `specs/{nome}/tasks.md` (arquivo único) + `workspace/Output/{nome}/Progresso.md`.
+
+## Tipo
+Atômica — Single-agent
+
+## Uso
+```
+/sf-plan <nome>
+```
+Exemplo: `/sf-plan feat_cadastro_cliente`
+
+---
+
+## Agente
+
+| Campo | Valor |
+|-------|-------|
+| **Papel** | Planejador técnico — decompõe especificação em tasks atômicas, ordenadas e com dependências explícitas |
+| **Modelo** | Opus |
+| **Comportamento** | Metódico e exaustivo. Cada task deve ser auto-contida (coder lê SDD §N + task, nada mais). Prioriza ordem de execução correta sobre paralelismo. Nunca cria task sem referência ao SDD. |
+
+---
+
+## Pré-condições
+
+| # | Validação | Se falhar |
+|---|-----------|-----------|
+| 1 | Argumento `nome` foi informado | Parar → "Informe o nome. Ex: /sf-plan feat_cadastro_cliente" |
+| 2 | `workspace/Output/{nome}/.context.md` existe com status `design_done` | Se anterior → "Execute /sf-design {nome} primeiro". Se posterior → "Tasks já foram geradas (status: {status})" |
+| 3 | `sdd.md` existe na pasta | Parar → "SDD não encontrado. Execute /sf-design {nome}" |
+
+## Passos
+
+### 1. Ler contexto
+- Ler `.context.md` → validar status
+- Ler `workspace/Output/{nome}/sdd.md` completo
+- Ler `specs/{nome}/contracts.md` e `scenarios.md` (projeções já geradas pelo /sf-design)
+- Ler `projetos.yaml` (manifesto de repos — mapeamento área → repo)
+- Ler `docs/` (architecture, domain, conventions — para convenções por área)
+- Ler `.github/rules.md` (padrões de código, commit, branch)
+- Carregar template `.github/templates/specs/tasks.template.md`
+
+### 2. Identificar fases de entrega
+Ler PRD §11 (Fases de Entrega) — cada fase vira um agrupamento de tasks:
+- Fases são sequenciais: Fase 2 depende de Fase 1 concluída
+- Cada fase tem entregável e critério de done
+- O `/dev` pode rodar por fase: `/sf-dev feat_nome --fase 1`
+
+### 3. Identificar áreas afetadas (por fase)
+Para cada fase de entrega, mapear seções do SDD para áreas de tasks:
+
+| Seção do SDD | Área | Condição |
+|-------------|------|----------|
+| §3 Modelo de dados | BANCO | Se há entidades/migrations |
+| §5 Endpoints API | BACK | Se há endpoints definidos |
+| §6 Componentes e telas | FRONT | Se há UI especificada |
+| §8 Integrações externas | INFRA | Se há infra/serviços externos |
+| Outras | MOBILE, DEVOPS, etc. | Conforme necessidade do SDD |
+
+> **Nota**: Área DOC NÃO existe mais no setup. docs/ é gerado pelo /sf-design (passo 3).
+> DOC só aparece em features se houver necessidade explícita de documentação adicional.
+
+Áreas são **dinâmicas** — só cria o que o SDD exige. Não criar área vazia.
+
+**Área INFRA obrigatória no setup:**
+Sempre gerar estas tasks no setup (antes de qualquer código):
+```
+- [ ] INFRA-001: Validar e configurar ambiente local [M]
+  (detectar OS, instalar Docker/.NET/Node, verificar portas)
+- [ ] INFRA-002: Criar docker-compose.yml + Dockerfiles [M]
+- [ ] INFRA-003: Hello world — subir stack completa e validar [M]
+  (docker compose up, migrations, health check, frontend carrega)
+```
+INFRA-001 é a PRIMEIRA task executada no /sf-dev do setup (antes de BANCO, BACK, FRONT).
+INFRA-003 é a ÚLTIMA task (após tudo, como validação final).
+Setup só é `done` quando INFRA-003 passa.
+
+### 4. Gerar `specs/{nome}/tasks.md` (arquivo único)
+
+Gerar UM arquivo só em `specs/{nome}/tasks.md` contendo **todas as tasks**
+em uma tabela única com coluna `Área`. Agrupadas por fase de entrega (PRD §11).
+
+**Tabela única:**
+
+```markdown
+| ID | Área | Fase | Tam | Título | Repo | Arquivos | Depende de | Ref spec | Ref CA |
+|----|------|------|-----|--------|------|----------|-----------|----------|--------|
+| BANCO-001 | BANCO | 1 | S | Migration clientes | api | src/Migrations/001_clientes.cs | — | SDD §3.1 | — |
+| BACK-001 | BACK | 1 | M | Endpoint POST /clientes | api | src/Api/Controllers/... | BANCO-001 | SDD §5.1 | CA-001 |
+| FRONT-001 | FRONT | 2 | M | Tela cadastro | web | src/pages/clientes/new.tsx | BACK-001 | SDD §6.1 | CA-002 |
+```
+
+**Regras de decomposição:**
+1. Cada task é **atômica** — implementável sem consultar nada além de `specs/{nome}/` + `rules.md`
+2. **Repo obrigatório** — consultar `projetos.yaml` para mapear área → repo. Caminhos de arquivo são relativos à raiz do repo
+3. **Área** é uma coluna, não mais um arquivo. Valores: BANCO, BACK, FRONT, INFRA, DOC, MOBILE, etc.
+4. Tamanhos realistas: **S** (<30min), **M** (30min-2h), **L** (2h+)
+5. Se uma task é L, avaliar se pode ser quebrada em M+S
+6. IDs sequenciais **por área**: BANCO-001, BANCO-002, BACK-001, BACK-002
+7. IDs nunca reutilizados — se uma task for removida, o ID é aposentado
+8. Dependências explícitas — inclusive cross-area (FRONT-001 depende BACK-001)
+9. `Ref spec`: referência a seção do SDD (fonte humana) — ex: `SDD §3.1`
+10. `Ref CA`: ID do critério de aceite em `specs/{nome}/scenarios.md` (CA-001, CA-002...) — pode ser `—`
+
+**Organização lógica dentro da tabela:**
+- Ordenar por Fase → Área → ID
+- Dependências garantem ordem de execução; a ordenação na tabela é só visual
+
+### 5. Gerar `workspace/Output/{nome}/Progresso.md` (tracking)
+
+`Progresso.md` fica em **workspace/Output** (é user tracking, não spec).
+Usando template `.github/templates/feature/Progresso.template.md`:
+
+- Resumo por Área × Fase com contagem de tasks (derivado de `specs/{nome}/tasks.md`)
+- Status por fase: ⬜ pendente | 🔄 em andamento | ✅ concluída
+- **Ordem de execução** com paralelismos:
+  ```
+  1. BANCO Fase 1 — primeiro sempre
+  2. BANCO Fase 2 + BACK Fase 1 — podem paralelizar
+  3. FRONT após BACK Fase 2
+  ...
+  ```
+- Totais por área e geral
+- Checklist pós-conclusão (merge delta, atualizar progresso global, napkin)
+
+**Regra**: status vive SÓ em Progresso.md. `specs/{nome}/tasks.md` é o plano imutável (até re-planejar).
+
+### 6. Atualizar progresso global
+Adicionar entrada em `workspace/Output/progresso.md`:
+
+```markdown
+| {nome} | plan_done | BANCO: 0/N | BACK: 0/N | FRONT: 0/N |
+```
+
+### 7. Atualizar `.context.md`
+```yaml
+status: "plan_done"
+ultima_skill: "/sf-plan"
+atualizado_em: "{{ISO_DATETIME}}"
+```
+
+---
+
+## Saídas
+
+| Arquivo | Descrição |
+|---------|-----------|
+| `specs/{nome}/tasks.md` | Tabela única de tasks com coluna Área |
+| `workspace/Output/{nome}/Progresso.md` | Dashboard da feature com ordem de execução (tracking) |
+| `workspace/Output/progresso.md` (global) | Atualizado com nova feature |
+| `.context.md` | Atualizado com status `plan_done` |
+
+## Pós-condições
+- `specs/{nome}/tasks.md` é único arquivo de plano — coder lê daqui
+- Cada task é auto-contida com referência a `specs/{nome}/` (não ao SDD direto)
+- Dependências resolvíveis (não há ciclos)
+- Ordem de execução definida em `Progresso.md`
+- Feature pronta para `/sf-dev`
+
+## Erros
+
+| Erro | Ação |
+|------|------|
+| Nome não informado | Parar, mostrar exemplo |
+| Status não é design_done | Parar, sugerir skill correspondente |
+| SDD não encontrado | Parar, sugerir /sf-design |
+| SDD com seções vazias obrigatórias | Parar, listar o que falta — sugerir voltar ao /sf-design |
+| Dependência circular detectada | Parar, reportar o ciclo e sugerir reorganização |