spec-first-copilot 0.7.0-beta.1 → 0.7.0

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

@@ -1,89 +1,89 @@
----
-nome: "{{NOME}}"
-first_run: {{true|false}}
-prd_existe: {{true|false}}
-trd_existe: {{true|false}}
-prd_aprovado: {{true|false}}
-trd_aprovado: {{true|false}}
-areas_tocadas: []
-input_path: "workspace/Input/{{NOME}}/"
-status: "not_started"
-ultima_skill: ""
-atualizado_em: ""
----
-
-<!--
-=============================================================================
-INSTRUÇÕES PARA O AGENTE (não incluir no arquivo gerado)
-=============================================================================
-
-SCHEMA v4 (mudou de v3):
-- prd_empty REMOVIDO (conceito obsoleto)
-- prd_existe/trd_existe: bool reais (SEM aspas) indicando se /sf-extract gerou cada doc
-- prd_aprovado/trd_aprovado: bool reais (SEM aspas) controlando gate do /sf-design
-
-CAMPOS:
-- nome: identificador livre do scope (ex: app_barbearia, feat_login, infra_k8s)
-- first_run: bool — true se docs/ não existia quando /sf-start foi chamado.
-  IMUTÁVEL após criação.
-- prd_existe: bool — true se /sf-extract gerou PRD.md (insumos tinham produto).
-  false em scopes puro-técnicos.
-- trd_existe: bool — true se /sf-extract gerou TRD.md (insumos tinham técnica).
-  false em scopes puro-produto (raro).
-- prd_aprovado: bool — true após PM aprovar o PRD. Se prd_existe=false, este
-  campo também fica false (não há nada a aprovar).
-- trd_aprovado: bool — true após dev aprovar o TRD. Se trd_existe=false, fica false.
-- areas_tocadas: lista de áreas do TRD que têm GATE=SIM. Preenchido pelo /sf-design.
-  Possíveis: BACK, FRONT, DB, INFRA. Derivado dos GATEs do TRD §2-§5.
-- input_path: caminho relativo da pasta de insumos
-- status: estado atual da pipeline (ver fluxo abaixo)
-- ultima_skill: qual skill alterou este arquivo por último
-- atualizado_em: data/hora ISO da última atualização
-
-FLUXO DE STATUS (v4):
-  not_started
-    ↓ /sf-start cria .context.md
-  discovery_done
-    ↓ /sf-discovery roda (obrigatório no sfw-start)
-  extract_done
-    ↓ /sf-extract gera PRD e/ou TRD
-  prd_approved  ← apenas se prd_existe=true
-    ↓ PM revisa e aprova PRD (skill atualiza prd_aprovado=true)
-  trd_approved  ← apenas se trd_existe=true
-    ↓ dev revisa e aprova TRD (skill atualiza trd_aprovado=true)
-  design_done
-    ↓ /sf-design gera docs/ (first_run) + specs/ (sempre)
-  plan_done
-    ↓ /sf-plan gera tasks
-  dev_in_progress
-    ↓ /sf-dev executa tasks
-  dev_done
-    ↓ /sf-dev finaliza (chama /sf-merge-docs automaticamente)
-  done
-
-Se prd_existe=false: status pula direto de extract_done → trd_approved (sem passar
-por prd_approved). Mesmo vice-versa. Ordem das aprovações dentro do par é irrelevante.
-
-QUEM ATUALIZA:
-- /sf-start: cria arquivo com status=not_started, first_run derivado de docs/
-- /sf-discovery: not_started → discovery_done
-- /sf-extract: discovery_done → extract_done, preenche prd_existe + trd_existe
-- PM aprova: extract_done → prd_approved (atualiza prd_aprovado=true)
-- dev aprova: extract_done|prd_approved → trd_approved (atualiza trd_aprovado=true)
-  (skill futura /approve <doc> ou edição direta do campo + re-rodar /sf-design)
-- /sf-design: (prd_approved + trd_approved) → design_done, preenche areas_tocadas
-  Nota: se só um dos docs existe, o outro aprovado não é exigido.
-- /sf-plan: design_done → plan_done
-- /sf-dev: plan_done → dev_in_progress → dev_done
-- /sf-merge-docs: dev_done → done (aplica PRD+TRD em docs/)
-
-REGRAS:
-- Nunca pular etapas no fluxo de status
-- Nunca editar manualmente — apenas skills atualizam este arquivo
-- Se status não corresponde ao esperado, a skill deve parar e avisar
-- first_run é IMUTÁVEL após criação (representa o estado no bootstrap do scope)
-- prd_existe/trd_existe são IMUTÁVEIS após o /sf-extract (só mudam via re-extração
-  que detecta NOVO conteúdo na outra categoria)
-
-=============================================================================
--->
+---
+nome: "{{NOME}}"
+first_run: {{true|false}}
+prd_existe: {{true|false}}
+trd_existe: {{true|false}}
+prd_aprovado: {{true|false}}
+trd_aprovado: {{true|false}}
+areas_tocadas: []
+input_path: "workspace/Input/{{NOME}}/"
+status: "not_started"
+ultima_skill: ""
+atualizado_em: ""
+---
+
+<!--
+=============================================================================
+INSTRUÇÕES PARA O AGENTE (não incluir no arquivo gerado)
+=============================================================================
+
+SCHEMA v4 (mudou de v3):
+- prd_empty REMOVIDO (conceito obsoleto)
+- prd_existe/trd_existe: bool reais (SEM aspas) indicando se /sf-extract gerou cada doc
+- prd_aprovado/trd_aprovado: bool reais (SEM aspas) controlando gate do /sf-design
+
+CAMPOS:
+- nome: identificador livre do scope (ex: app_barbearia, feat_login, infra_k8s)
+- first_run: bool — true se docs/ não existia quando /sf-start foi chamado.
+  IMUTÁVEL após criação.
+- prd_existe: bool — true se /sf-extract gerou PRD.md (insumos tinham produto).
+  false em scopes puro-técnicos.
+- trd_existe: bool — true se /sf-extract gerou TRD.md (insumos tinham técnica).
+  false em scopes puro-produto (raro).
+- prd_aprovado: bool — true após PM aprovar o PRD. Se prd_existe=false, este
+  campo também fica false (não há nada a aprovar).
+- trd_aprovado: bool — true após dev aprovar o TRD. Se trd_existe=false, fica false.
+- areas_tocadas: lista de áreas do TRD que têm GATE=SIM. Preenchido pelo /sf-design.
+  Possíveis: BACK, FRONT, DB, INFRA. Derivado dos GATEs do TRD §2-§5.
+- input_path: caminho relativo da pasta de insumos
+- status: estado atual da pipeline (ver fluxo abaixo)
+- ultima_skill: qual skill alterou este arquivo por último
+- atualizado_em: data/hora ISO da última atualização
+
+FLUXO DE STATUS (v4):
+  not_started
+    ↓ /sf-start cria .context.md
+  discovery_done
+    ↓ /sf-discovery roda (obrigatório no sfw-start)
+  extract_done
+    ↓ /sf-extract gera PRD e/ou TRD
+  prd_approved  ← apenas se prd_existe=true
+    ↓ PM revisa e aprova PRD (skill atualiza prd_aprovado=true)
+  trd_approved  ← apenas se trd_existe=true
+    ↓ dev revisa e aprova TRD (skill atualiza trd_aprovado=true)
+  design_done
+    ↓ /sf-design gera docs/ (first_run) + specs/ (sempre)
+  plan_done
+    ↓ /sf-plan gera tasks
+  dev_in_progress
+    ↓ /sf-dev executa tasks
+  dev_done
+    ↓ /sf-dev finaliza (chama /sf-merge-docs automaticamente)
+  done
+
+Se prd_existe=false: status pula direto de extract_done → trd_approved (sem passar
+por prd_approved). Mesmo vice-versa. Ordem das aprovações dentro do par é irrelevante.
+
+QUEM ATUALIZA:
+- /sf-start: cria arquivo com status=not_started, first_run derivado de docs/
+- /sf-discovery: not_started → discovery_done
+- /sf-extract: discovery_done → extract_done, preenche prd_existe + trd_existe
+- PM aprova: extract_done → prd_approved (atualiza prd_aprovado=true)
+- dev aprova: extract_done|prd_approved → trd_approved (atualiza trd_aprovado=true)
+  (skill futura /approve <doc> ou edição direta do campo + re-rodar /sf-design)
+- /sf-design: (prd_approved + trd_approved) → design_done, preenche areas_tocadas
+  Nota: se só um dos docs existe, o outro aprovado não é exigido.
+- /sf-plan: design_done → plan_done
+- /sf-dev: plan_done → dev_in_progress → dev_done
+- /sf-merge-docs: dev_done → done (aplica PRD+TRD em docs/)
+
+REGRAS:
+- Nunca pular etapas no fluxo de status
+- Nunca editar manualmente — apenas skills atualizam este arquivo
+- Se status não corresponde ao esperado, a skill deve parar e avisar
+- first_run é IMUTÁVEL após criação (representa o estado no bootstrap do scope)
+- prd_existe/trd_existe são IMUTÁVEIS após o /sf-extract (só mudam via re-extração
+  que detecta NOVO conteúdo na outra categoria)
+
+=============================================================================
+-->

package/templates/.github/templates/feature/extract-log.template.md

@@ -1,49 +1,49 @@
-# Extract Log — {{NOME}}
-
-<!--
-=============================================================================
-INSTRUÇÕES PARA O AGENTE (não incluir no arquivo gerado)
-=============================================================================
-
-QUANDO USAR: Criado pelo /sf-extract na primeira extração. Atualizado em re-extrações.
-QUEM GERA: Tech-Analyzer + Produto-Analyzer (Opus) ao final da extração.
-
-COMO GERAR:
-1. Cada extração gera uma nova seção com timestamp
-2. Para cada arquivo processado registrar: nome, hash SHA-256 (8 chars),
-   classificação, status, destino (PRD e/ou TRD + seções específicas)
-3. Classificação: contexto de re-extração (NOVO, MODIFICADO, INALTERADO)
-4. Status: resultado da leitura (extraído, parcial, não identificado)
-5. Destino: onde a informação do arquivo foi para
-   - Formato: `PRD §N` ou `TRD §N.M` (múltiplos separados por vírgula)
-   - Se arquivo tem info de produto E técnica, aparece em ambos
-   - Se arquivo foi puro-técnico: só TRD §N
-   - Se arquivo foi puro-produto: só PRD §N
-
-REGRAS:
-- Hashes são SHA-256 truncados em 8 caracteres
-- Arquivo .gitkeep é sempre ignorado
-- Arquivos INALTERADOS aparecem no log mas com Destino "—"
-- Append-only: nunca remover extrações anteriores do log
-
-CLASSIFICAÇÕES POSSÍVEIS:
-- NOVO: arquivo não existia no log anterior
-- MODIFICADO: hash diferente do log anterior
-- INALTERADO: hash igual ao log anterior
-- NÃO IDENTIFICADO: Reader não conseguiu extrair conteúdo (binário, corrompido)
-- PARCIAL: Reader extraiu algo mas com limitações (imagem sem OCR, PDF escaneado)
-
-MUDANÇA v3 → v4:
-- v3 tinha coluna "Tech chunks" separada (produto/tech/both) pra /sf-design consumir
-- v4 elimina essa categorização — tudo técnico vai direto pro TRD (já
-  estruturado), e /sf-design lê TRD + PRD em vez de chunks brutos.
-- Resultado: extract-log mais enxuto, zero lógica de categorização residual.
-
-=============================================================================
--->
-
-## Extração 1 — {{ISO_DATETIME}}
-
-| Arquivo | Hash | Classificação | Status | Destino |
-|---------|------|---------------|--------|---------|
-| `{{arquivo}}` | {{hash_8}} | NOVO | extraído | PRD §1, §5 + TRD §1.1, §2.1 |
+# Extract Log — {{NOME}}
+
+<!--
+=============================================================================
+INSTRUÇÕES PARA O AGENTE (não incluir no arquivo gerado)
+=============================================================================
+
+QUANDO USAR: Criado pelo /sf-extract na primeira extração. Atualizado em re-extrações.
+QUEM GERA: Tech-Analyzer + Produto-Analyzer (Opus) ao final da extração.
+
+COMO GERAR:
+1. Cada extração gera uma nova seção com timestamp
+2. Para cada arquivo processado registrar: nome, hash SHA-256 (8 chars),
+   classificação, status, destino (PRD e/ou TRD + seções específicas)
+3. Classificação: contexto de re-extração (NOVO, MODIFICADO, INALTERADO)
+4. Status: resultado da leitura (extraído, parcial, não identificado)
+5. Destino: onde a informação do arquivo foi para
+   - Formato: `PRD §N` ou `TRD §N.M` (múltiplos separados por vírgula)
+   - Se arquivo tem info de produto E técnica, aparece em ambos
+   - Se arquivo foi puro-técnico: só TRD §N
+   - Se arquivo foi puro-produto: só PRD §N
+
+REGRAS:
+- Hashes são SHA-256 truncados em 8 caracteres
+- Arquivo .gitkeep é sempre ignorado
+- Arquivos INALTERADOS aparecem no log mas com Destino "—"
+- Append-only: nunca remover extrações anteriores do log
+
+CLASSIFICAÇÕES POSSÍVEIS:
+- NOVO: arquivo não existia no log anterior
+- MODIFICADO: hash diferente do log anterior
+- INALTERADO: hash igual ao log anterior
+- NÃO IDENTIFICADO: Reader não conseguiu extrair conteúdo (binário, corrompido)
+- PARCIAL: Reader extraiu algo mas com limitações (imagem sem OCR, PDF escaneado)
+
+MUDANÇA v3 → v4:
+- v3 tinha coluna "Tech chunks" separada (produto/tech/both) pra /sf-design consumir
+- v4 elimina essa categorização — tudo técnico vai direto pro TRD (já
+  estruturado), e /sf-design lê TRD + PRD em vez de chunks brutos.
+- Resultado: extract-log mais enxuto, zero lógica de categorização residual.
+
+=============================================================================
+-->
+
+## Extração 1 — {{ISO_DATETIME}}
+
+| Arquivo | Hash | Classificação | Status | Destino |
+|---------|------|---------------|--------|---------|
+| `{{arquivo}}` | {{hash_8}} | NOVO | extraído | PRD §1, §5 + TRD §1.1, §2.1 |

package/templates/.github/templates/feature/projetos.template.yaml

@@ -1,79 +1,79 @@
-# projetos.yaml — Manifesto de Repositórios
-#
-# =============================================================================
-# INSTRUÇÕES PARA O AGENTE
-# =============================================================================
-#
-# QUANDO CRIAR: Gerado pelo /sf-design em first-run (quando docs/ ainda não existia).
-# QUEM GERA: Agent Architect (Opus), baseado no SDD §3.2 Arquitetura e §3.4 Infra.
-#
-# COMO GERAR:
-# 1. Ler SDD §3.2 Arquitetura → identificar quais serviços existem (api, worker, web, etc.)
-# 2. Para cada serviço, definir: nome do repo, path local, áreas de task, stack
-# 3. A stack DEVE vir do SDD §3.1 (Stack) — não inventar, não copiar exemplo
-# 4. Se o repo já existe no GitHub, marcar existing: true
-# 5. Se é novo, marcar existing: false (será criado pelo /sf-dev INFRA-001)
-#
-# REGRAS:
-# - Todo serviço identificado no SDD §3.2 DEVE ter uma entrada
-# - O campo `areas` define quais prefixos de task escrevem nesse repo
-# - Uma área NÃO pode pertencer a dois repos (mapeamento 1:1)
-# - DB pode ir junto com api (se usa ORM com migrations no mesmo repo) ou separado
-# - O campo `stack` DEVE ser consistente com SDD §3.1 + docs/architecture.md
-# - O `org` é a organização/user do GitHub
-#
-# EXEMPLOS DE STACK (apenas referência — usar a REAL do SDD):
-# - Backend: ".NET 8", "Node.js 20 + Express", "Python 3.12 + FastAPI", "Go 1.22"
-# - Frontend: "React 18 + Vite", "Next.js 15", "Vue 3 + Nuxt", "Angular 17"
-# - Mobile: "React Native", "Flutter", "Swift / Kotlin nativo"
-# =============================================================================
-
-# Organização/usuário no GitHub
-org: "{{GITHUB_ORG}}"
-
-# Nome base do projeto (usado como prefixo dos repos)
-project: "{{PROJECT_NAME}}"
-
-# Repositórios — preencher conforme serviços do SDD §3.2
-repos:
-  # API backend (exemplo — adaptar stack ao SDD real do projeto)
-  api:
-    repo: "{{GITHUB_ORG}}/{{PROJECT_NAME}}-api"
-    path: "projetos/api"
-    existing: false                # true = clonar existente; false = criar novo
-    areas: [BACK, DB]              # áreas de task que escrevem aqui (1:1 por área)
-    stack: "{{STACK_BACKEND}}"     # do SDD §3.1 (ex: "Node.js 20 + Express")
-    branch_prefix: "feature/"
-
-  # Worker / jobs assíncronos (descomentar se SDD §3.2 define)
-  # worker:
-  #   repo: "{{GITHUB_ORG}}/{{PROJECT_NAME}}-worker"
-  #   path: "projetos/worker"
-  #   existing: false
-  #   areas: [BACK]                # ou criar área WORKER dedicada se preferir
-  #   stack: "{{STACK_WORKER}}"
-  #   branch_prefix: "feature/"
-
-  # Frontend web (descomentar se SDD §3.2 define)
-  # web:
-  #   repo: "{{GITHUB_ORG}}/{{PROJECT_NAME}}-web"
-  #   path: "projetos/web"
-  #   existing: false
-  #   areas: [FRONT]
-  #   stack: "{{STACK_FRONTEND}}"
-  #   branch_prefix: "feature/"
-
-  # App mobile (descomentar se SDD §3.2 define)
-  # mobile:
-  #   repo: "{{GITHUB_ORG}}/{{PROJECT_NAME}}-mobile"
-  #   path: "projetos/mobile"
-  #   existing: false
-  #   areas: [MOBILE]
-  #   stack: "{{STACK_MOBILE}}"
-  #   branch_prefix: "feature/"
-
-# Notas:
-# - projetos/ está no .gitignore do projeto-base (contém repos independentes)
-# - Cada repo tem seu próprio .git, CI/CD, e deploy
-# - O projeto-base é o "cérebro" — specs, docs, pipeline
-# - Os repos em projetos/ são o "corpo" — código implementado
+# projetos.yaml — Manifesto de Repositórios
+#
+# =============================================================================
+# INSTRUÇÕES PARA O AGENTE
+# =============================================================================
+#
+# QUANDO CRIAR: Gerado pelo /sf-design em first-run (quando docs/ ainda não existia).
+# QUEM GERA: Agent Architect (Opus), baseado no TRD §1.2 Arquitetura e §5 §Área-Infra.
+#
+# COMO GERAR:
+# 1. Ler TRD §1.2 Arquitetura → identificar quais serviços existem (api, worker, web, etc.)
+# 2. Para cada serviço, definir: nome do repo, path local, áreas de task, stack
+# 3. A stack DEVE vir do TRD §1.1 (Stack) — não inventar, não copiar exemplo
+# 4. Se o repo já existe no GitHub, marcar existing: true
+# 5. Se é novo, marcar existing: false (será criado pelo /sf-dev INFRA-001)
+#
+# REGRAS:
+# - Todo serviço identificado no TRD §1.2 DEVE ter uma entrada
+# - O campo `areas` define quais prefixos de task escrevem nesse repo
+# - Uma área NÃO pode pertencer a dois repos (mapeamento 1:1)
+# - DB pode ir junto com api (se usa ORM com migrations no mesmo repo) ou separado
+# - O campo `stack` DEVE ser consistente com TRD §1.1 + docs/architecture.md
+# - O `org` é a organização/user do GitHub
+#
+# EXEMPLOS DE STACK (apenas referência — usar a REAL do TRD):
+# - Backend: ".NET 8", "Node.js 20 + Express", "Python 3.12 + FastAPI", "Go 1.22"
+# - Frontend: "React 18 + Vite", "Next.js 15", "Vue 3 + Nuxt", "Angular 17"
+# - Mobile: "React Native", "Flutter", "Swift / Kotlin nativo"
+# =============================================================================
+
+# Organização/usuário no GitHub
+org: "{{GITHUB_ORG}}"
+
+# Nome base do projeto (usado como prefixo dos repos)
+project: "{{PROJECT_NAME}}"
+
+# Repositórios — preencher conforme serviços do TRD §1.2
+repos:
+  # API backend (exemplo — adaptar stack ao TRD real do projeto)
+  api:
+    repo: "{{GITHUB_ORG}}/{{PROJECT_NAME}}-api"
+    path: "projetos/api"
+    existing: false                # true = clonar existente; false = criar novo
+    areas: [BACK, DB]              # áreas de task que escrevem aqui (1:1 por área)
+    stack: "{{STACK_BACKEND}}"     # do TRD §1.1 (ex: "Node.js 20 + Express")
+    branch_prefix: "feature/"
+
+  # Worker / jobs assíncronos (descomentar se TRD §1.2 define)
+  # worker:
+  #   repo: "{{GITHUB_ORG}}/{{PROJECT_NAME}}-worker"
+  #   path: "projetos/worker"
+  #   existing: false
+  #   areas: [BACK]                # ou criar área WORKER dedicada se preferir
+  #   stack: "{{STACK_WORKER}}"
+  #   branch_prefix: "feature/"
+
+  # Frontend web (descomentar se TRD §1.2 define)
+  # web:
+  #   repo: "{{GITHUB_ORG}}/{{PROJECT_NAME}}-web"
+  #   path: "projetos/web"
+  #   existing: false
+  #   areas: [FRONT]
+  #   stack: "{{STACK_FRONTEND}}"
+  #   branch_prefix: "feature/"
+
+  # App mobile (descomentar se TRD §1.2 define)
+  # mobile:
+  #   repo: "{{GITHUB_ORG}}/{{PROJECT_NAME}}-mobile"
+  #   path: "projetos/mobile"
+  #   existing: false
+  #   areas: [MOBILE]
+  #   stack: "{{STACK_MOBILE}}"
+  #   branch_prefix: "feature/"
+
+# Notas:
+# - projetos/ está no .gitignore do projeto-base (contém repos independentes)
+# - Cada repo tem seu próprio .git, CI/CD, e deploy
+# - O projeto-base é o "cérebro" — specs, docs, pipeline
+# - Os repos em projetos/ são o "corpo" — código implementado

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

@@ -1,57 +1,59 @@
-# Progresso Geral
-
-> Visão consolidada de todas as features, bugs e tarefas do projeto.
-> Atualizado automaticamente ao final de cada `/sf-plan` e `/sf-dev`.
-
----
-
-<!--
-=============================================================================
-INSTRUÇÕES PARA O AGENTE (não incluir no arquivo gerado na primeira vez)
-=============================================================================
-
-QUANDO USAR: Criado pelo /sf-plan do primeiro setup ou feature. Atualizado por cada /sf-plan e /sf-dev.
-
-COMO ATUALIZAR:
-- Ao criar nova feature (/sf-plan) → adicionar linha na tabela com contadores zerados
-- Ao concluir tasks (/sf-dev) → atualizar contadores
-- Ao concluir feature (/sf-merge-docs) → status "concluído" ou "done"
-
-ÁREAS SÃO DINÂMICAS:
-- 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
-
-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 | DB: 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 gerado (pode ser empty), aguardando aprovação |
-| `approved` | Documento aprovado |
-| `design_done` | SDD gerado |
-| `plan_done` | Tasks geradas, pronto para /sf-dev |
-| `dev_in_progress` | /sf-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 `/sf-plan` e `/sf-dev`.
+
+---
+
+<!--
+=============================================================================
+INSTRUÇÕES PARA O AGENTE (não incluir no arquivo gerado na primeira vez)
+=============================================================================
+
+QUANDO USAR: Criado pelo /sf-plan do primeiro setup ou feature. Atualizado por cada /sf-plan e /sf-dev.
+
+COMO ATUALIZAR:
+- Ao criar nova feature (/sf-plan) → adicionar linha na tabela com contadores zerados
+- Ao concluir tasks (/sf-dev) → atualizar contadores
+- Ao concluir feature (/sf-merge-docs) → status "concluído" ou "done"
+
+ÁREAS SÃO DINÂMICAS:
+- 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
+
+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 | DB: 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 /sf-discovery |
+| `discovery_done` | Análise dos insumos feita, aguardando /sf-extract |
+| `extract_done` | PRD e/ou TRD gerado(s), aguardando aprovações |
+| `prd_approved` | PM aprovou PRD |
+| `trd_approved` | dev aprovou TRD (ambas aprovações = pode chamar /sf-design) |
+| `design_done` | `specs/{nome}/` gerado (+ `docs/` em first-run) |
+| `plan_done` | Tasks geradas, pronto para /sf-dev |
+| `dev_in_progress` | /sf-dev em execução |
+| `dev_done` | Todas tasks concluídas |
+| `done` | docs/ atualizado via /sf-merge-docs |
+
+---
+
+> **Atualização**: Cada skill atualiza este arquivo ao criar ou concluir features.