spec-first-copilot 0.5.0-beta.17 → 0.5.0-beta.19

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "spec-first-copilot",
-  "version": "0.5.0-beta.17",
+  "version": "0.5.0-beta.19",
   "description": "Spec-first workflow kit for GitHub Copilot — AI-driven development with specs, not guesswork",
   "bin": {
     "spec-first-copilot": "bin/cli.js"

package/templates/.github/copilot-instructions.md

@@ -20,12 +20,13 @@
 
 ### 2. Validar acesso a todas skills
 
-Verificar que TODAS as 11 skills estão acessíveis:
+Verificar que TODAS as 12 skills estão acessíveis:
 
 | Skill | Caminho |
 |-------|---------|
 | `/sf-mcp` | `.github/skills/sf-mcp/SKILL.md` |
 | `/sf-load` | `.github/skills/sf-load/SKILL.md` |
+| `/sf-publish` | `.github/skills/sf-publish/SKILL.md` |
 | `/sf-new-project` | `.github/skills/sf-new-project/SKILL.md` |
 | `/sf-feature` | `.github/skills/sf-feature/SKILL.md` |
 | `/sf-extract` | `.github/skills/sf-extract/SKILL.md` |
@@ -98,7 +99,8 @@ Nenhum código é escrito sem especificação aprovada (SDD).
 | Skill | Tipo | O que faz |
 |-------|------|-----------|
 | `/sf-mcp <provider>` | Setup | Configura backend externo interativamente. Cria .mcp.json + sfw.config.yml + ajusta .gitignore |
-| `/sf-load <nome>` | Utilitária | Puxa insumos do backend (Confluence/filesystem) para workspace/Input/{nome}/. Incremental |
+| `/sf-load <nome> \| --all` | Utilitária | Puxa Input + Output do backend. Incremental |
+| `/sf-publish <nome> <tipo>` | Utilitária | Publica artefato (PRD/TRD/SDD/Progresso) nos output.targets[]. Chamado auto por extract/design/plan |
 | `/sf-new-project <nome>` | Orquestrador | Bootstrap técnico: cria .context.md tipo TRD, chama /sf-extract, para no checkpoint |
 | `/sf-feature <nome>` | Orquestrador | Feature: cria .context.md tipo PRD, chama /sf-extract, para no checkpoint |
 | `/sf-extract <nome>` | Atômica | Lê workspace/Input/{nome}/ → gera PRD ou TRD. Re-executável para novos insumos |

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

@@ -1,209 +1,132 @@
----
-name: sf-design
-description: |
-  Design técnico. Gera SDD a partir do PRD/TRD aprovado.
-  Trigger: /sf-design
-author: GustavoMaritan
-version: 1.0.0
-date: 2026-04-08
----
-
-# Skill: /sf-design
-
-> Skill atômica de design técnico. Lê PRD/TRD aprovado e gera SDD.
-> Responsável pelo checkpoint de aprovação do documento de extração.
-
-## Tipo
-Atômica — Single-agent
-
-## Uso
-```
-/sf-design <nome>
-```
-Exemplo: `/sf-design feat_cadastro_cliente`
-
----
-
-## Agente
-
-| Campo | Valor |
-|-------|-------|
-| **Papel** | Arquiteto de software — transforma requisitos aprovados em especificação técnica implementável |
-| **Modelo** | Opus |
-| **Comportamento** | Técnico e preciso. Gera contratos completos (JSON schemas, SQL DDL, componentes com estados). Toda decisão tem justificativa. Se o PRD/TRD tem gaps, não inventa — para e reporta. |
-
----
-
-## Pré-condições
-
-| # | Validação | Se falhar |
-|---|-----------|-----------|
-| 1 | Argumento `nome` foi informado | Parar → "Informe o nome. Ex: /sf-design feat_cadastro_cliente" |
-| 2 | `workspace/Output/{nome}/.context.md` existe | Parar → "Execute /sf-feature {nome} ou /sf-setup-projeto primeiro" |
-| 3 | Status é `extract_done` ou `approved` | Se anterior → "Execute /sf-extract primeiro". Se posterior → "SDD já foi gerado (status: {status})" |
-| 4 | PRD.md ou TRD.md existe na pasta | Parar → "Documento de extração não encontrado. Execute /sf-extract {nome}" |
-| 5 | `docs/` está populado (para features) | Parar → "Execute /sf-setup-projeto primeiro" (não aplica para tipo=setup) |
-
-## Passos
-
-### 1. Checkpoint de aprovação
-Se status é `extract_done` (não `approved`):
-```
-Pergunta ao usuário:
-  "O {PRD/TRD} em workspace/Output/{nome}/ foi revisado e está aprovado? (s/n)"
-
-  Se SIM → atualizar .context.md status: approved → continuar
-  Se NÃO → parar → "Revise o documento e chame /sf-design {nome} quando estiver pronto"
-```
-
-### 2. Verificar ambiguidades
-Ler seção de ambiguidades do PRD (§13) ou TRD (§9):
-- Se há perguntas sem resposta → **PARAR**
-- Listar as ambiguidades pendentes
-- Instruir: "Responda as ambiguidades no documento e chame /sf-design {nome} novamente"
-
-### 3. Gerar docs/ (APENAS para setup)
-
-> Este passo só executa quando tipo=setup. Para features, docs/ já existe.
-
-Ler TRD e gerar os 5 docs de `docs/` usando os templates correspondentes:
-
-| Doc gerado | Fontes (TRD) | Template |
-|-----------|--------------|---------|
-| architecture.md | §3 Arquitetura + §2 Stack + §6 Infra (ambientes, deploy, CI/CD, rollback) | `.github/templates/estrutura/architecture.template.md` |
-| domain.md | §1 Visão + §4 Modelo de Dados | `.github/templates/estrutura/domain.template.md` |
-| conventions.md | §7 Segurança + §6 Infra (env vars, domínios, monitoramento) + §5 API (códigos de erro de domínio) + §2 Stack (alternativas, versionamento) | `.github/templates/estrutura/conventions.template.md` |
-| apiContracts.md | §5 API (padrão geral, rotas, paginação, filtros, erros, catálogo) | `.github/templates/estrutura/apiContracts.template.md` |
-| decisions.md | SDD §2 Decisões (após gerar) + decisões iniciais de stack/arquitetura | `.github/templates/estrutura/decisions.template.md` |
-
-Regras:
-- Ler template → preencher TODAS seções com dados do TRD
-- Remover bloco `<!-- INSTRUÇÕES -->` do doc gerado
-- Changelog inicia vazio (primeira geração)
-- Se TRD não tem dados pra uma seção → marcar "A definir"
-- decisions.md é gerado APÓS o SDD (usa §2 Decisões de Design como ponto de partida)
-- TRD §8 Módulos NÃO vira doc de Estrutura — vai para backlog faseado
-
-### 3b. Gerar `projetos.yaml` (APENAS para setup)
-
-> Mapeia a arquitetura do TRD §3 para repositórios independentes.
-> Cada serviço = 1 repo. Os repos serão criados/clonados pelo /sf-dev (INFRA-001).
-
-Ler TRD §3 (Arquitetura) e §6 (Infra) para identificar os serviços:
-
-1. Identificar serviços separados (api, worker, web, mobile, etc.)
-2. Perguntar ao usuário:
-   - Organização/usuário do GitHub (ex: `empresa`)
-   - Nome base do projeto (ex: `meu-projeto`)
-   - Se algum repo já existe (para clonar em vez de criar)
-3. Gerar `projetos.yaml` na raiz usando template `projetos.template.yaml`
-4. Mapear áreas de task para repos:
-   - BACK → api (ou worker, se separado)
-   - BANCO → api (se usa EF migrations) ou repo próprio
-   - FRONT → web
-   - MOBILE → mobile
-   - INFRA → todos (cross-repo)
-5. Validar: cada área DEVE mapear para exatamente 1 repo
-
-**Regra**: Se o TRD indica API e Worker como serviços separados, DEVEM ser repos separados.
-Nunca juntar serviços que o TRD definiu como distintos.
-
-### 4. Carregar contexto
-- Ler PRD.md ou TRD.md completo (conforme `.context.md`)
-- Ler `docs/` completo (agora já populado, mesmo no setup)
-- Ler `.github/rules.md` (convenções de desenvolvimento)
-- Carregar template `.github/templates/feature/sdd.template.md`
-
-### 5. Gerar SDD
-Produzir `sdd.md` com as 11 seções obrigatórias:
-
-| Seção | Conteúdo | Fonte principal |
-|-------|----------|-----------------|
-| §1 Visão geral | O que, escopo, premissas | PRD §1 / TRD §1 |
-| §2 Decisões de design | Mini-ADRs com justificativa | Arquitetura + análise do agente |
-| §3 Modelo de dados | Entidades com tipos exatos, constraints, migrations | PRD §3 + domain.md |
-| §4 Regras e validações | Ref PRD §5 RN-NNN, mensagens de erro | PRD §5 + §6 |
-| §5 Endpoints API | Contratos completos: request/response JSON, status codes | PRD §4 + apiContracts.md |
-| §6 Componentes e telas | Estados (loading/empty/error), componentes, comportamentos | PRD §7 |
-| §7 Fluxos de dados | Sequências usuário→front→back, caminhos de erro | PRD §4 + §9 |
-| §8 Integrações externas | Protocolo, timeout, retry, fallback | PRD §8 |
-| §9 Estratégia de testes | Framework, estrutura, CAs mapeados a testes | PRD §4 + §10 |
-| §10 Fora do escopo | Lista explícita do que NÃO será feito | PRD §12 |
-| §11 Delta Specs | ADDED/MODIFIED/REMOVED para merge em docs/ | Análise do agente |
-
-**Regras de geração:**
-1. SDD deve ser **auto-contido** — o coder lê APENAS o SDD + task, nunca PRD/PM
-2. Toda regra/entidade referencia seção do PRD/TRD (rastreabilidade)
-3. Seções não aplicáveis marcadas `N/A — [motivo]` (ex: §6 em setup sem UI)
-4. Contratos de API com JSON schema completo (request, response, erros)
-5. Modelo de dados com tipos exatos, não genéricos (varchar(255), não "string")
-6. Critérios de aceite testáveis — Given/When/Then, não frases vagas
-7. Delta Specs sempre preenchida, mesmo que vazia (ADDED: nenhum)
-
-### 6. Complementar decisions.md (setup — complemento do passo 3)
-Após gerar SDD §2, popular `decisions.md` com as decisões iniciais de arquitetura
-(stack principal, padrões de design, trade-offs significativos).
-
-### 7. Projetar SDD em `specs/{nome}/` (sempre)
-
-Após gerar/atualizar o SDD, criar/sobrescrever os 4 arquivos de spec estruturado
-em `specs/{nome}/` como **projeções do SDD** pro coder consumir:
-
-| Arquivo | Projeção de |
-|---------|-------------|
-| `brief.md` | SDD §1 Visão + §2 Decisões + §10 Fora do escopo |
-| `contracts.md` | SDD §3 Modelo de dados + §4 Regras/validações + §5 Endpoints + §8 Integrações |
-| `scenarios.md` | SDD §6 Componentes/telas + §7 Fluxos + §9 Estratégia de testes + Critérios de aceite |
-| `tasks.md` | (stub vazio — será preenchido pelo /sf-plan) |
-
-**Regras:**
-- Os 4 arquivos são **projeções regeneráveis** — re-rodar /sf-design sobrescreve
-- NÃO editar direto em `specs/` — fonte de verdade é o SDD em `workspace/Output/`
-- Templates em `.github/templates/specs/` (brief/contracts/scenarios/tasks)
-- Coders e Reviewer leem daqui, NUNCA do SDD direto
-- Se o SDD tem seções N/A, refletir N/A nas projeções também
-
-**Criação:**
-- Criar diretório `specs/{nome}/` se não existir
-- Para cada arquivo, ler template correspondente → preencher com projeção do SDD → remover bloco `<!-- INSTRUÇÕES -->`
-- `tasks.md` é apenas stub na saída do /sf-design — o /sf-plan preenche
-
-### 8. Atualizar `.context.md`
-```yaml
-status: "design_done"
-ultima_skill: "/sf-design"
-atualizado_em: "{{ISO_DATETIME}}"
-```
-
----
-
-## Saídas
-
-| Arquivo | Descrição |
-|---------|-----------|
-| `workspace/Output/{nome}/sdd.md` | Especificação técnica narrativa (para humano) |
-| `specs/{nome}/brief.md` | Projeção do SDD — Problema/Solução/Escopo (para agent) |
-| `specs/{nome}/contracts.md` | Projeção do SDD — Dados, API, Integrações, Regras (para agent) |
-| `specs/{nome}/scenarios.md` | Projeção do SDD — Fluxos, UI, CAs (para agent) |
-| `specs/{nome}/tasks.md` | Stub — preenchido pelo /sf-plan |
-| `projetos.yaml` | (setup) Manifesto de repos — mapeamento serviço → repo → áreas |
-| `docs/*.md` | (setup) 5 docs globais preenchidos do TRD (architecture, domain, conventions, apiContracts, decisions) |
-| `.context.md` | Atualizado: `approved` → `design_done` |
-
-## Pós-condições
-- SDD (humano, em `workspace/Output/`) é fonte única narrativa
-- `specs/{nome}/` é projeção estruturada pro agent — nunca editado manualmente
-- Coder/Reviewer leem exclusivamente `specs/{nome}/`, não o SDD
-- Rastreabilidade: specs → SDD → PRD/TRD → insumos
-
-## Erros
-
-| Erro | Ação |
-|------|------|
-| Nome não informado | Parar, mostrar exemplo |
-| Status anterior a extract_done | Parar, sugerir /sf-extract |
-| Status posterior a approved | Informar que SDD já foi gerado |
-| Ambiguidades pendentes no PRD/TRD | Parar, listar ambiguidades |
-| PRD/TRD não encontrado | Parar, sugerir /sf-extract |
-| docs/ vazio (em features) | Parar, sugerir /sf-setup-projeto |
-| Informação insuficiente no PRD/TRD para gerar seção | NÃO inventar — marcar seção como incompleta, reportar ao usuário |
+# /sf-design $ARGUMENTS
+
+Skill atômica de design. Lê PRD/TRD aprovado e gera SDD.
+$ARGUMENTS = nome (ex: setup_projeto, feat_cadastro_cliente)
+
+## Agente: Architect (Opus)
+Técnico e preciso. Gera contratos completos. Toda decisão tem justificativa.
+
+## Pré-condições
+
+| # | Validação | Se falhar |
+|---|-----------|-----------|
+| 1 | $ARGUMENTS informado | Parar |
+| 2 | `.context.md` existe com status `extract_done` ou `approved` | Se anterior → "/sf-extract primeiro". Se posterior → "SDD já gerado" |
+| 3 | PRD.md ou TRD.md existe | Parar → "/sf-extract primeiro" |
+| 4 | `docs/` populado (para features) | Parar → "/setup-projeto primeiro" (não aplica para tipo=setup) |
+
+## Passos
+
+### 1. Checkpoint de aprovação
+Se status é `extract_done`:
+- Perguntar: "O PRD/TRD foi revisado e está aprovado? (s/n)"
+- Se SIM → atualizar .context.md para `approved` → continuar
+- Se NÃO → parar
+
+### 2. Verificar ambiguidades
+- Ler seção de ambiguidades (§13 PRD / §9 TRD)
+- Se há perguntas sem resposta → PARAR, listar pendentes
+
+### 3. Gerar docs/ (APENAS para setup)
+
+> Este passo só executa quando tipo=setup. Para features, docs/ já existe.
+
+Ler TRD e gerar os 5 docs de `docs/` usando os templates correspondentes:
+
+| Doc gerado | Fontes (TRD) | Template |
+|-----------|--------------|---------|
+| architecture.md | §3 Arquitetura + §2 Stack + §6 Infra (ambientes, deploy, CI/CD, rollback) | `.claude/templates/estrutura/architecture.template.md` |
+| domain.md | §1 Visão + §4 Modelo de Dados | `.claude/templates/estrutura/domain.template.md` |
+| conventions.md | §7 Segurança + §6 Infra (env vars, domínios, monitoramento) + §5 API (códigos de erro de domínio) + §2 Stack (alternativas, versionamento) | `.claude/templates/estrutura/conventions.template.md` |
+| apiContracts.md | §5 API (padrão geral, rotas, paginação, filtros, erros, catálogo) | `.claude/templates/estrutura/apiContracts.template.md` |
+| decisions.md | SDD §2 Decisões (após gerar) + decisões iniciais de stack/arquitetura | `.claude/templates/estrutura/decisions.template.md` |
+
+Regras:
+- Ler template → preencher TODAS seções com dados do TRD
+- Remover bloco `<!-- INSTRUÇÕES -->` do doc gerado
+- Changelog inicia vazio (primeira geração)
+- Se TRD não tem dados pra uma seção → marcar "A definir"
+- decisions.md é gerado APÓS o SDD (usa §2 Decisões de Design como ponto de partida)
+- TRD §8 Módulos NÃO vira doc de Estrutura — vai para backlog faseado
+
+### 3b. Gerar `projetos.yaml` (APENAS para setup)
+
+Mapeia a arquitetura do TRD §3 para repositórios independentes.
+Cada serviço = 1 repo. Os repos serão criados/clonados pelo /sf-dev (INFRA-001).
+
+1. Identificar serviços separados no TRD §3 (api, worker, web, mobile, etc.)
+2. Perguntar ao usuário:
+   - Organização/usuário do GitHub (ex: `empresa`)
+   - Nome base do projeto (ex: `meu-projeto`)
+   - Se algum repo já existe (para clonar em vez de criar)
+3. Gerar `projetos.yaml` na raiz usando template `projetos.template.yaml`
+4. Mapear áreas de task para repos:
+   - BACK → api (ou worker, se separado)
+   - BANCO → api (se usa EF migrations) ou repo próprio
+   - FRONT → web
+   - MOBILE → mobile
+   - INFRA → todos (cross-repo)
+5. Validar: cada área DEVE mapear para exatamente 1 repo
+
+**Regra**: Se o TRD indica API e Worker como serviços separados, DEVEM ser repos separados.
+Nunca juntar serviços que o TRD definiu como distintos.
+
+### 4. Carregar contexto
+- PRD.md ou TRD.md completo
+- `docs/` (agora já populado, mesmo no setup)
+- `.claude/rules.md`
+- Template `sdd.template.md`
+
+### 5. Gerar SDD
+11 seções obrigatórias (usar template). Para cada seção:
+- §1 Visão geral — escopo claro
+- §2 Decisões de design — mini-ADRs com justificativa
+- §3 Modelo de dados — tipos EXATOS, constraints, índices
+- §4 Regras e validações — ref PRD §N RN-NNN, mensagens de erro
+- §5 Endpoints API — contratos JSON completos, erros com códigos
+- §6 Componentes e telas — estados (loading/empty/error/success)
+- §7 Fluxos de dados — sequências front→back
+- §8 Integrações externas — timeout, retry, fallback
+- §9 Estratégia de testes — framework, estrutura, CAs mapeados
+- §10 Fora do escopo — lista explícita
+- §11 Delta Specs — ADDED/MODIFIED/REMOVED
+
+**Setup**: §4-§8 podem ser N/A (normal).
+**Feature**: todas seções aplicáveis preenchidas.
+
+### 6. Complementar decisions.md (setup — complemento do passo 3)
+Após gerar SDD §2, popular `decisions.md` com as decisões iniciais de arquitetura.
+
+### 7. Projetar SDD em `specs/{nome}/` (sempre)
+
+Após gerar/atualizar o SDD, criar/sobrescrever os 4 arquivos em `specs/{nome}/`
+como projeções do SDD pro agent consumir:
+
+| Arquivo | Projeção de |
+|---------|-------------|
+| `brief.md` | SDD §1 + §2 + §10 |
+| `contracts.md` | SDD §3 + §4 + §5 + §8 |
+| `scenarios.md` | SDD §6 + §7 + §9 + CAs |
+| `tasks.md` | stub (preenchido pelo /sf-plan) |
+
+Regras:
+- São projeções REGENERÁVEIS — ao re-rodar /sf-design, sobrescreve
+- NUNCA editar direto em specs/ — SDD é a fonte
+- Templates em `.claude/templates/specs/`
+- Coders e Reviewer leem daqui, NUNCA do SDD direto
+
+### 8. Atualizar `.context.md`
+```yaml
+status: "design_done"
+ultima_skill: "/sf-design"
+atualizado_em: "{{ISO_DATETIME}}"
+```
+
+### 9. Publicar SDD no(s) backend(s)
+
+Se existe `sfw.config.yml` com `output.targets[]` ativo:
+- Executar `/sf-publish $ARGUMENTS SDD`
+- O `/sf-publish` respeita o `mode` (auto/manual/off) de cada target
+- Se não existe `sfw.config.yml` → pular silenciosamente
+
+Ver `.github/skills/sf-publish.md`.

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

@@ -1,211 +1,94 @@
----
-name: sf-extract
-description: |
-  Extração de insumos. Lê workspace/Input/ e gera PRD ou TRD estruturado.
-  Trigger: /sf-extract
-author: GustavoMaritan
-version: 1.0.0
-date: 2026-04-08
----
+# /sf-extract $ARGUMENTS
 
-# Skill: /sf-extract
+Skill atômica de extração. Lê insumos brutos do PM/ e gera PRD ou TRD.
+$ARGUMENTS = nome (ex: setup_projeto, feat_cadastro_cliente)
 
-> Skill atômica de extração. Lê insumos brutos do PM/ e gera PRD ou TRD.
-> Chamada via orquestrador (/feature, /sf-setup-projeto) ou diretamente para re-extração.
+## Multi-agent
 
-## Tipo
-Atômica — Multi-agent
-
-## Uso
-```
-/sf-extract <nome>
-```
-Exemplo: `/sf-extract feat_cadastro_cliente`
-
----
-
-## Agentes
-
-| Agente | Papel | Modelo | Input | Output |
-|--------|-------|--------|-------|--------|
-| **Reader** | Lê e cataloga 1 arquivo de insumo | Sonnet | 1 arquivo bruto + formato esperado | Resumo estruturado por seção do template |
-| **Analyzer** | Cruza fontes, detecta gaps, gera documento final | Opus | Outputs de todos os Readers + template + contexto do projeto | PRD/TRD completo + extract-log |
-
-### Orquestração
-```
-1. Ler .context.md e .extract-log.md (se existir)
-2. Ler discovery.md (se existir) — análise profunda prévia dos insumos
-3. Inventariar arquivos em workspace/Input/{nome}/ → filtrar NOVOS e MODIFICADOS
-4. Spawn 1 Reader por arquivo NOVO/MODIFICADO (paralelo)
-5. Aguardar todos os Readers
-6. Spawn Analyzer com:
-   - Outputs concatenados dos Readers
-   - discovery.md (se existir) — mapa do sistema pré-validado
-   - PRD/TRD existente (se re-extração)
-   - Template (PRD.template.md ou TRD.template.md)
-   - docs/ (contexto do projeto)
-7. Analyzer gera documento final + extract-log
-8. Atualizar .context.md → status: extract_done
-```
-
-> **Se discovery.md existir**: O Analyzer usa o mapa do sistema, perguntas já respondidas
-> e pontos críticos como contexto enriquecido. Resultado: menos ambiguidades, melhor estruturação.
-> **Se não existir**: O Analyzer trabalha normalmente com os outputs dos Readers.
-
-### Agent: Reader (Sonnet)
-
-**Papel**: Especialista em leitura e catalogação de um único arquivo de insumo.
-
-**Comportamento**:
-- Lê 1 arquivo por vez
-- Extrai informações seguindo as categorias do template alvo
-- Não interpreta, não infere — apenas cataloga o que encontra
-- Marca cada informação com a seção do template onde se encaixa
-
-**Formatos e o que extrair:**
-
-| Formato | Extensões | O que extrair |
-|---------|-----------|---------------|
-| Texto/Requisitos | `.md`, `.txt` | Requisitos, regras de negócio, contexto, restrições |
-| Banco de dados | `.sql` | Entidades, campos, tipos, constraints, índices, relações |
-| Protótipos | `.html` | Telas, campos (`data-field`), ações (`data-action`), validações (`data-validation`), rotas (`data-route`), permissões (`data-permission`), estados (`data-state`) |
-| Diagramas | `.xml` (drawio), `.json` | Fluxos, decisões, atores, sequências |
-| Planilhas | `.csv` | Dados tabulares, mapeamentos, configurações |
-| Imagens | `.png`, `.jpg`, `.pdf` | Wireframes, mockups, fluxogramas (análise visual) |
-| Outros | qualquer | Extrair o que for relevante — nunca ignorar um arquivo |
-
-**Output do Reader** (por arquivo):
-```markdown
-## Reader Output: {nome_arquivo}
-- Hash: {sha256_8chars}
-- Formato: {tipo}
-- Status: extraído | parcial | não identificado
-
-### Seções alimentadas:
-- §1 Contexto: ...
-- §3 Entidades: ...
-- §5 Regras: RN-XXX: "descrição"
-- §13 Ambiguidades: "campo X definido mas sem tipo especificado"
-```
-
-**Quando o Reader NÃO consegue extrair conteúdo:**
-- Status: `não identificado` — arquivo binário desconhecido, corrompido, ou sem conteúdo relevante
-- Status: `parcial` — conseguiu extrair algo mas o formato limita (ex: imagem sem OCR, PDF escaneado)
-- O Reader NUNCA ignora o arquivo — sempre registra no output com o status
-- O Analyzer inclui arquivo não identificado no extract-log com classificação `NÃO IDENTIFICADO`
-- O Analyzer gera ambiguidade: "Arquivo {nome} não pôde ser processado — verifique conteúdo e formato"
-
-### Agent: Analyzer (Opus)
-
-**Papel**: Especialista em análise cruzada, detecção de gaps e geração de documento estruturado.
-
-**Comportamento**:
-- Nunca assume — se não está explícito nos insumos, vira pergunta bloqueante
-- Busca contradições ativamente entre fontes diferentes
-- Rastreia tudo — cada informação aponta para o arquivo fonte
-- Prefere estrutura a narrativa — tabelas e listas, nunca texto livre
-- Pessimista construtivo — melhor uma ambiguidade a mais do que uma regra inventada
-
-**Responsabilidades**:
-1. Consolidar outputs dos Readers em visão unificada
-2. Detectar contradições entre fontes → gerar ambiguidade com os dois arquivos citados
-3. Detectar gaps — seções do template sem informação → gerar ambiguidade
-4. **Validar Checklist de Temas Críticos** (ver abaixo) — temas ausentes viram ambiguidades obrigatórias
-5. Nunca inferir regra de negócio — se não está explícito, é ambiguidade
-6. Manter IDs estáveis (RN-001 nunca renumera, novos continuam sequência)
-7. Gerar rastreabilidade completa (§14 PRD / §10 TRD)
-8. Na re-extração: merge ADITIVO com documento existente, marcar seções atualizadas
-
-### Checklist de Temas Críticos (Analyzer)
-
-Após consolidar os Readers, o Analyzer DEVE verificar se os insumos cobrem os temas abaixo.
-Se um tema **não foi mencionado em nenhum insumo**, gera **ambiguidade obrigatória** pedindo ao usuário.
-
-#### Para TRD (setup):
-
-| # | Tema | O que verificar | Se ausente |
-|---|------|-----------------|------------|
-| 1 | **Autenticação** | Qual mecanismo? JWT, OAuth, API Key, Session? | Ambiguidade: "Nenhum mecanismo de autenticação definido nos insumos" |
-| 2 | **Autorização / Roles** | Quais perfis? RBAC, ABAC? Quem acessa o quê? | Ambiguidade: "Perfis de acesso e regras de autorização não definidos" |
-| 3 | **Separação de serviços** | É monolito, microserviços, modular? API e Worker são separados? | Ambiguidade: "Arquitetura de serviços não definida (monolito vs separados)" |
-| 4 | **Ambientes** | Dev, staging, prod? Docker? CI/CD? | Ambiguidade: "Estratégia de ambientes e deploy não definida" |
-| 5 | **Dados sensíveis** | PII, LGPD, criptografia, masking? | Ambiguidade: "Tratamento de dados sensíveis / LGPD não mencionado" |
-
-#### Para PRD (feature):
-
-| # | Tema | O que verificar | Se ausente |
-|---|------|-----------------|------------|
-| 1 | **Autenticação requerida** | Feature exige login? Quais endpoints são públicos vs autenticados? | Ambiguidade: "Não definido quais operações exigem autenticação" |
-| 2 | **Permissões / Roles** | Quais perfis podem executar cada ação? | Ambiguidade: "Não definido quais perfis têm acesso a cada operação" |
-| 3 | **Validações de entrada** | Regras de validação dos campos? Limites? Formatos? | Ambiguidade: "Validações de entrada não detalhadas" |
-| 4 | **Tratamento de erros** | O que acontece quando dá errado? Mensagens ao usuário? | Ambiguidade: "Cenários de erro e mensagens ao usuário não definidos" |
-| 5 | **Impacto em dados existentes** | A feature altera dados existentes? Migração necessária? | Ambiguidade: "Impacto em dados existentes não avaliado" |
-
-> **Regra**: O Analyzer NÃO inventa respostas para esses temas. Se não está nos insumos, PERGUNTA.
-> Esses temas são os mais comuns de serem esquecidos pelo usuário e os mais caros de corrigir depois.
-
----
+| Agente | Modelo | Papel |
+|--------|--------|-------|
+| **Reader** (1 por arquivo) | Sonnet | Lê e cataloga 1 arquivo. Não interpreta, apenas cataloga |
+| **Analyzer** | Opus | Cruza fontes, detecta gaps/contradições, gera documento final |
 
 ## Pré-condições
 
 | # | Validação | Se falhar |
 |---|-----------|-----------|
-| 1 | Argumento `nome` foi informado | Parar → "Informe o nome. Ex: /sf-extract feat_cadastro_cliente" |
-| 2 | `workspace/Input/{nome}/` existe e contém pelo menos 1 arquivo (ignorar .gitkeep) | Parar → "Pasta de insumos vazia ou inexistente" |
-| 3 | `workspace/Output/{nome}/.context.md` existe | Parar → "Execute /sf-feature {nome} ou /sf-setup-projeto primeiro" |
-| 4 | Status em `.context.md` é `not_started` ou `extract_done` | Se `approved` ou posterior → "Extração já aprovada. Para re-extrair, o status será revertido para extract_done" |
+| 1 | $ARGUMENTS informado | Parar → "Informe o nome" |
+| 2 | `workspace/Input/$ARGUMENTS/` existe com arquivos | Parar → "Pasta vazia ou inexistente" |
+| 3 | `.context.md` existe | Parar → "Execute /feature ou /setup-projeto primeiro" |
+| 4 | Status é `not_started` ou `extract_done` | Se posterior → "Extração já aprovada" |
 
-## Passos detalhados
+## Passos
 
 ### 1. Ler contexto
-- Ler `.context.md` → identificar `tipo` (feature ou setup) e `documento` (PRD ou TRD)
-- Ler `docs/` se existir (contexto para extração coerente)
-- Selecionar template: `tipo=feature` → `PRD.template.md` | `tipo=setup` → `TRD.template.md`
-
-### 2. Inventariar e classificar insumos
-Ler todos os arquivos em `workspace/Input/{nome}/`. Para cada arquivo, calcular hash (SHA-256 truncado 8 chars).
-
-Se `.extract-log.md` existir, classificar:
-
-| Classificação | Critério | Ação |
-|---------------|----------|------|
-| **NOVO** | Arquivo não existe no log | Processar |
-| **MODIFICADO** | Hash diferente do log | Reprocessar |
-| **INALTERADO** | Hash igual ao log | Pular |
-
-Se `.extract-log.md` não existir: todos são NOVOS.
-
-### 3. Spawn Readers (paralelo)
-Para cada arquivo NOVO ou MODIFICADO, disparar 1 Reader (Sonnet):
-- Input: arquivo bruto + seções do template alvo
-- Output: resumo estruturado por seção
-
-Arquivos INALTERADOS: pular — informação já está no PRD/TRD existente.
-
-### 4. Spawn Analyzer (sequencial)
-Após todos Readers concluírem, disparar Analyzer (Opus) com:
-- Todos os outputs dos Readers
-- PRD/TRD existente (se re-extração — para merge aditivo)
-- Template correspondente
-- `docs/` como contexto
-
-### 5. Gerar/atualizar documento
-
-**Primeira extração:**
-- Analyzer gera PRD.md ou TRD.md completo a partir do template
-
-**Re-extração:**
-- Merge ADITIVO com o documento existente (nunca remove info de arquivos inalterados)
-- Seções afetadas recebem marcador:
-  ```
-  <!-- ATUALIZADO: re-extração {{ISO_DATE}} — arquivos: {lista} -->
-  ```
-- Novas regras de negócio continuam sequência de IDs existentes
-
-### 6. Gerar roadmap de produto faseado (APENAS no setup)
+- `.context.md` → tipo (feature/setup) e documento (PRD/TRD)
+- `discovery.md` (se existir) → análise profunda prévia dos insumos
+- `docs/` se existir
+- Template: tipo=feature → `PRD.template.md` | tipo=setup → `TRD.template.md`
+
+> Se `discovery.md` existir: usar mapa do sistema e perguntas já respondidas como contexto
+> enriquecido. Resultado: menos ambiguidades, melhor estruturação.
+
+### 2. Inventariar insumos
+Para cada arquivo em `workspace/Input/$ARGUMENTS/` (ignorar .gitkeep):
+- Calcular hash SHA-256 (primeiros 8 chars)
+- Se `.extract-log.md` existe → classificar: NOVO / MODIFICADO / INALTERADO
+- Se não existe → todos são NOVOS
+
+### 3. Processar (simulando Reader por arquivo)
+Para cada arquivo NOVO ou MODIFICADO:
+
+| Formato | O que extrair |
+|---------|---------------|
+| .md, .txt | Requisitos, regras, contexto, restrições |
+| .sql | Entidades, campos, tipos, constraints, índices |
+| .html | Telas, campos, ações, validações, rotas, permissões |
+| .xml, .json | Fluxos, decisões, configurações |
+| .csv | Dados tabulares, mapeamentos |
+| .png, .jpg, .pdf | Análise visual (wireframes, mockups) |
+| Não identificado | Registrar como NÃO IDENTIFICADO, gerar ambiguidade |
+
+### 4. Gerar documento (simulando Analyzer)
+- Consolidar todas informações por seção do template
+- Detectar contradições entre fontes → ambiguidade
+- Detectar gaps (seções sem info) → ambiguidade
+- **Validar Checklist de Temas Críticos** (ver abaixo) — temas ausentes viram ambiguidades obrigatórias
+- Nunca inferir regra de negócio — se não explícito, é ambiguidade
+- IDs estáveis: RN-001 nunca renumera, novos continuam sequência
+- Rastreabilidade: cada info aponta pro arquivo fonte
+
+#### Checklist de Temas Críticos
+
+Após consolidar os Readers, verificar se os insumos cobrem os temas abaixo.
+Se um tema **não foi mencionado em nenhum insumo**, gera **ambiguidade obrigatória**.
+
+**Para TRD (setup):**
+
+| # | Tema | Se ausente |
+|---|------|------------|
+| 1 | **Autenticação** (JWT, OAuth, API Key, Session?) | Ambiguidade: "Nenhum mecanismo de autenticação definido" |
+| 2 | **Autorização / Roles** (perfis, RBAC, ABAC, quem acessa o quê) | Ambiguidade: "Perfis de acesso e regras de autorização não definidos" |
+| 3 | **Separação de serviços** (monolito, microserviços, API vs Worker) | Ambiguidade: "Arquitetura de serviços não definida" |
+| 4 | **Ambientes** (dev, staging, prod, Docker, CI/CD) | Ambiguidade: "Estratégia de ambientes e deploy não definida" |
+| 5 | **Dados sensíveis** (PII, LGPD, criptografia, masking) | Ambiguidade: "Tratamento de dados sensíveis / LGPD não mencionado" |
+
+**Para PRD (feature):**
+
+| # | Tema | Se ausente |
+|---|------|------------|
+| 1 | **Autenticação requerida** (quais endpoints públicos vs autenticados?) | Ambiguidade: "Não definido quais operações exigem autenticação" |
+| 2 | **Permissões / Roles** (quais perfis podem executar cada ação?) | Ambiguidade: "Não definido quais perfis têm acesso a cada operação" |
+| 3 | **Validações de entrada** (regras, limites, formatos) | Ambiguidade: "Validações de entrada não detalhadas" |
+| 4 | **Tratamento de erros** (cenários de falha, mensagens) | Ambiguidade: "Cenários de erro e mensagens ao usuário não definidos" |
+| 5 | **Impacto em dados existentes** (migração necessária?) | Ambiguidade: "Impacto em dados existentes não avaliado" |
+
+> O Analyzer NÃO inventa respostas — se não está nos insumos, PERGUNTA.
+
+### 5. Gerar roadmap de produto faseado (APENAS no setup)
 Quando tipo=setup, o Analyzer encontra informações que não são infraestrutura
 (regras de negócio, jornadas, telas, fluxos). Em vez de descartar, organizar em
-`backlog_extraido.md` como **roadmap faseado** com entregáveis incrementais:
+`backlog_extraido.md` como **roadmap faseado** com entregáveis incrementais.
 
 O Analyzer deve:
 1. Identificar funcionalidades, entidades, regras de negócio, jornadas, telas
@@ -223,62 +106,41 @@ Este arquivo:
 - Serve como roadmap quando o usuário for criar `/feature`
 - O /sf-extract da feature usa as fases como referência para o PRD
 
-### 7. Gerar/atualizar `.extract-log.md`
-
+### 6. Gerar `.extract-log.md`
 ```markdown
-# Extract Log — {nome}
-
-## Extração 1 — {{ISO_DATETIME}}
-| Arquivo | Hash | Classificação | Seções alimentadas |
-|---------|------|---------------|-------------------|
-| requisitos.txt | a1b2c3d4 | NOVO | §1, §5, §9 |
-| modelagem.sql | e5f6g7h8 | NOVO | §3, §6 |
+# Extract Log — $ARGUMENTS
 
-## Extração 2 — {{ISO_DATETIME}}
-| Arquivo | Hash | Classificação | Seções alimentadas |
-|---------|------|---------------|-------------------|
-| novas_regras.md | m3n4o5p6 | NOVO | §5, §9 |
-| modelagem.sql | q7r8s9t0 | MODIFICADO | §3 |
-| requisitos.txt | a1b2c3d4 | INALTERADO | — |
+## Extração N — {{ISO_DATETIME}}
+| Arquivo | Hash | Classificação | Status | Seções alimentadas |
+|---------|------|---------------|--------|--------------------|
 ```
 
-### 7. Atualizar `.context.md`
+### 6. Atualizar `.context.md`
 ```yaml
 status: "extract_done"
 ultima_skill: "/sf-extract"
 atualizado_em: "{{ISO_DATETIME}}"
 ```
 
----
+### 7. Publicar artefato no(s) backend(s)
 
-## Saídas
+Se existe `sfw.config.yml` com `output.targets[]` ativo:
+- Executar `/sf-publish $ARGUMENTS TRD` (setup) ou `/sf-publish $ARGUMENTS PRD` (feature)
+- O `/sf-publish` respeita o `mode` (auto/manual/off) de cada target
+- Se não existe `sfw.config.yml` → pular silenciosamente (projeto 100% local)
 
-| Arquivo | Descrição |
-|---------|-----------|
-| `PRD.md` ou `TRD.md` | Documento de extração com todas as seções preenchidas |
-| `.extract-log.md` | Registro de arquivos processados com hashes e classificação |
-| `.context.md` | Atualizado com status `extract_done` |
+Ver `.github/skills/sf-publish.md`.
 
-## Pós-condições
-- Documento gerado com rastreabilidade completa
-- Ambiguidades listadas na seção correspondente — bloqueiam avanço no `/design`
-- Usuário deve revisar antes de chamar `/design`
+## Re-extração
+- Merge ADITIVO com documento existente (nunca remove info de inalterados)
+- Seções afetadas marcadas com `<!-- ATUALIZADO: re-extração -->`
+- Novos IDs continuam sequência
 
 ## Erros
-
 | Erro | Ação |
 |------|------|
-| PM/{nome}/ vazio | Parar, listar formatos aceitos |
-| .context.md não existe | Parar, sugerir /sf-feature ou /sf-setup-projeto |
-| Nenhum arquivo novo/modificado | Informar "Nenhuma alteração detectada desde a última extração" |
-| Formato não reconhecido | Processar mesmo assim, extrair o que for possível, avisar no log |
-| Conteúdo não identificado | Registrar como NÃO IDENTIFICADO no extract-log, gerar ambiguidade pedindo ao usuário verificar o arquivo |
-| Extração parcial | Registrar como PARCIAL no extract-log, extrair o que for possível, avisar quais seções ficaram incompletas |
-| Contradição entre arquivos | Analyzer gera ambiguidade citando os dois arquivos e a contradição |
-
-## Notas
-- O `/extract` é a ÚNICA skill que lê `workspace/Input/` — nenhuma outra skill acessa insumos brutos
-- Na re-extração, o merge é ADITIVO — nunca remove informação de arquivos inalterados
-- Para recomeçar do zero: apagar PRD/TRD e .extract-log.md manualmente
-- Readers são stateless — não conhecem outros arquivos, apenas o seu
-- Analyzer é quem tem visão global e detecta contradições cross-arquivo
+| Pasta vazia | Parar, listar formatos aceitos |
+| .context.md não existe | Parar, sugerir /feature ou /setup-projeto |
+| Nenhum arquivo novo/modificado | Informar "Nenhuma alteração detectada" |
+| Arquivo não identificado | Registrar no log, gerar ambiguidade |
+| Contradição entre arquivos | Gerar ambiguidade citando os dois |

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

@@ -71,9 +71,29 @@ function loadScope(pageId, targetDir):
   collectAllPages(pageId, allPages)
 
   para cada page em allPages:
-    content = mcp__atlassian__confluence_get_page(page_id=page.id, convert_to_markdown=true)
+    // IMPORTANTE: SEMPRE pedir markdown, NUNCA storage format (HTML)
+    result = mcp__atlassian__confluence_get_page(page_id=page.id, convert_to_markdown=true)
+    content = result.content (ou result.body — depende da resposta do MCP)
+
+    // LIMPEZA OBRIGATÓRIA — Confluence pode vazar HTML mesmo com convert_to_markdown
+    // Se o conteúdo contém tags HTML (<p>, <div>, <span>, <table>, etc.):
+    //   1. Remover tags de metadata: <p local-id="...">, <ri:...>, <ac:...>
+    //   2. Converter tags semânticas pra markdown:
+    //      <h1> → #, <h2> → ##, <h3> → ###
+    //      <strong>/<b> → **texto**
+    //      <em>/<i> → *texto*
+    //      <a href="url"> → [texto](url)
+    //      <ul>/<li> → - item
+    //      <ol>/<li> → 1. item
+    //      <code> → `código`
+    //      <pre> → ```bloco```
+    //      <table>/<tr>/<td> → tabela markdown
+    //   3. Remover tags restantes sem equivalente markdown (strip tags, manter texto)
+    //   4. Limpar linhas vazias excessivas
+    // O arquivo salvo DEVE ser markdown limpo, sem nenhuma tag HTML.
+
     filename = sanitize(page.title) + ".md"
-    salvar content em {targetDir}/{filename}
+    salvar content LIMPO em {targetDir}/{filename}
     registrar no load-log
 
   // Attachments de CADA page

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

@@ -1,180 +1,104 @@
----
-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 |
+# /sf-plan $ARGUMENTS
+
+Skill atômica de planejamento. Lê SDD + specs/{nome}/ e gera `specs/{nome}/tasks.md` (arquivo único) + `workspace/Output/{nome}/Progresso.md`.
+$ARGUMENTS = nome (ex: setup_projeto, feat_cadastro_cliente)
+
+## Agente: Planner (Opus)
+Metódico e exaustivo. Cada task auto-contida. Prioriza ordem correta.
+
+## Pré-condições
+
+| # | Validação | Se falhar |
+|---|-----------|-----------|
+| 1 | $ARGUMENTS informado | Parar |
+| 2 | `.context.md` com status `design_done` | Se anterior → "/sf-design primeiro". Se posterior → "Tasks já geradas" |
+| 3 | `workspace/Output/{nome}/sdd.md` existe | Parar → "/sf-design primeiro" |
+| 4 | `specs/{nome}/contracts.md` e `scenarios.md` existem (projeções) | Parar → "/sf-design não gerou projeções — re-rode" |
+
+## Passos
+
+### 1. Ler contexto
+- `workspace/Output/{nome}/sdd.md` completo (fonte humana)
+- `specs/{nome}/contracts.md` e `scenarios.md` (projeções já geradas pelo /sf-design)
+- `projetos.yaml` + `docs/` (architecture, domain, conventions) + `.claude/rules.md`
+- Template `.claude/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 `/sf-dev` pode rodar por fase: `/sf-dev feat_nome --fase 1`
+
+### 3. Identificar áreas (por fase)
+
+| Seção SDD | Área |
+|-----------|------|
+| §3 Modelo de dados | BANCO |
+| §5 Endpoints API | BACK |
+| §6 Componentes/Telas | FRONT |
+| §8 Integrações | INFRA |
+| Outras | MOBILE, DEVOPS, etc. conforme 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ó criar as que o SDD exige.
+
+**Área INFRA obrigatória no setup:**
+```
+- [ ] INFRA-001: Validar e configurar ambiente local [M]
+- [ ] INFRA-002: Criar docker-compose.yml + Dockerfiles [M]
+- [ ] INFRA-003: Hello world — subir stack completa e validar [M]
+```
+INFRA-001 é a PRIMEIRA task do setup. INFRA-003 é a ÚLTIMA (validação final).
+
+### 4. Gerar `specs/{nome}/tasks.md` (arquivo único)
+
+Gerar UM arquivo só em `specs/{nome}/tasks.md` com tabela única de todas as tasks, coluna `Área` diferencia.
+
+```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/... | — | SDD §3.1 | — |
+| BACK-001 | BACK | 1 | M | Endpoint POST /clientes | api | src/Api/... | BANCO-001 | SDD §5.1 | CA-001 |
+```
+
+Regras:
+- Cada task é atômica — coder lê `specs/{nome}/` + task, nada mais
+- **Repo obrigatório** — consultar `projetos.yaml`. Caminhos relativos ao repo
+- Área é COLUNA, não arquivo (BANCO, BACK, FRONT, INFRA, DOC, MOBILE...)
+- Tamanhos: S (<30min), M (30min-2h), L (2h+). L → avaliar se quebra em M+S
+- IDs sequenciais por área, nunca reutilizar
+- Dependências cross-area permitidas
+- `Ref spec`: seção do SDD (ex: `SDD §3.1`)
+- `Ref CA`: ID do critério em `specs/{nome}/scenarios.md` ou `—`
+- Ordenar tabela por Fase → Área → ID (visual)
+
+### 5. Gerar `workspace/Output/{nome}/Progresso.md` (tracking)
+Progresso.md fica em **workspace/Output** (user tracking, não spec).
+- Resumo Área × Fase com contagem (derivado de `tasks.md`)
+- Ordem de execução com paralelismos
+- Checklist pós-conclusão
+
+**Regra**: status vive SÓ em Progresso.md. `tasks.md` é o plano imutável.
+
+### 6. Atualizar progresso global + `.context.md`
+```yaml
+status: "plan_done"
+ultima_skill: "/sf-plan"
+```
+
+### 7. Publicar Progresso no(s) backend(s)
+
+Se existe `sfw.config.yml` com `output.targets[]` ativo:
+- Executar `/sf-publish $ARGUMENTS Progresso`
+- O `/sf-publish` respeita o `mode` (auto/manual/off) de cada target
+- Se não existe `sfw.config.yml` → pular silenciosamente
+- **Nota**: `tasks.md`, `specs/`, `docs/`, `projetos.yaml` são LOCAL ONLY — nunca publicados
+
+Ver `.github/skills/sf-publish.md`.
+
+## Saídas
+- `specs/{nome}/tasks.md` — tabela única
+- `workspace/Output/{nome}/Progresso.md` — tracking
+- `workspace/Output/progresso.md` (global) — atualizado

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

@@ -0,0 +1,144 @@
+# /sf-publish <nome> <tipo>
+
+Publica um artefato gerado localmente no(s) backend(s) configurado(s) como `output.targets[]` no `sfw.config.yml`.
+
+## Argumentos
+
+- `<nome>` = scope do artefato (ex: `app_barbearia`, `feat_login`)
+- `<tipo>` = tipo do artefato: `PRD` | `TRD` | `SDD` | `Progresso`
+
+## Quando é chamado
+
+Automaticamente pelos commands:
+- `/sf-extract` → publica `TRD` ou `PRD` no fim
+- `/sf-design` → publica `SDD` no fim
+- `/sf-plan` → publica `Progresso` no fim
+
+Manualmente: quando o usuário quer re-publicar um artefato após editar local.
+
+## Modo (`mode` no sfw.config.yml)
+
+| Mode | Comportamento |
+|------|---------------|
+| `auto` | Publica sem perguntar (default) |
+| `manual` | Gera artefato local, pergunta "Publicar no {target.name}? (s/n)" |
+| `off` | Ignora o target completamente |
+
+## Pré-condições
+
+| # | Validação | Se falhar |
+|---|-----------|-----------|
+| 1 | `sfw.config.yml` existe | Parar → "Sem sfw.config.yml, publish desabilitado. Artefato local está em workspace/Output/{nome}/{tipo}.md" |
+| 2 | Tipo está na `publishes` do target | Pular target, informar |
+| 3 | Arquivo local existe em `workspace/Output/{nome}/{tipo}.md` (ou .lower) | Parar → "Arquivo não encontrado" |
+
+## Execução
+
+### 1. Carregar configuração
+
+- Ler `sfw.config.yml`
+- Para cada target em `output.targets[]`:
+  - Verificar `mode` (se `off` → pular)
+  - Verificar `publishes` inclui `<tipo>` (se não → pular)
+  - Se `mode: manual` → perguntar ao usuário
+
+### 2. Ler artefato local
+
+Ler `workspace/Output/{nome}/{arquivo}` onde arquivo depende do tipo:
+- `TRD` → `TRD.md`
+- `PRD` → `PRD.md`
+- `SDD` → `sdd.md`
+- `Progresso` → `Progresso.md`
+
+### 3. Aplicar naming
+
+Usar templates do `naming` no `sfw.config.yml`:
+- `containerTitle = applyNaming(naming.output_container, {scope: nome})`
+  - Ex: `"out_app_barbearia"`
+- `artifactTitle = applyNaming(naming.output_artifact, {scope: nome, type: tipo})`
+  - Ex: `"app_barbearia - TRD"`
+
+### 4. Para cada target ativo — publicar
+
+**Confluence**:
+
+1. Listar filhos de `target.config.parent_page_id` (Output)
+2. Buscar container pelo `containerTitle`:
+   - **Não existe** → `mcp__atlassian__confluence_create_page` como filho de Output
+   - **Existe** → pegar `container.id`
+3. Listar filhos do container
+4. Buscar artefato pelo `artifactTitle`:
+   - **Não existe** → `mcp__atlassian__confluence_create_page` com `content=markdown local`
+   - **Existe** → precisa atualizar (próximo passo)
+
+### 5. Conflict detection (update)
+
+Se artefato existe no backend:
+
+1. Ler `.ai/sf-publish-log.md` pra pegar a última `version` publicada desse artefato
+2. Chamar `mcp__atlassian__confluence_get_page(page_id=artifact.id)` → pega `currentVersion`
+3. **Se `currentVersion != lastPublishedVersion`** → DRIFT detectado
+   - Alguém editou no Confluence depois do último publish
+   - Mostrar ao usuário:
+     ```
+     CONFLITO: "{artifactTitle}" foi editada no Confluence desde o último publish.
+
+     Última version publicada por nós: {last}
+     Version atual no Confluence: {current}
+
+     Opções:
+       1. Sobrescrever (perde edição manual)
+       2. Abortar (edita local depois)
+       3. Ver diff
+     ```
+   - Esperar decisão
+4. Se sem drift → `mcp__atlassian__confluence_update_page(page_id, content)`
+5. Ler nova `version` retornada
+
+### 6. Registrar em `.ai/sf-publish-log.md`
+
+Formato append-only:
+
+```markdown
+## Publish: {nome} {tipo} — {ISO_DATETIME}
+
+| Target | Container | Artifact ID | Version | Status |
+|--------|-----------|-------------|---------|--------|
+| confluence-mirror | out_app_barbearia (393220) | 393238 | 3 | UPDATED |
+```
+
+Status: `CREATED`, `UPDATED`, `SKIPPED` (se INALTERADO), `CONFLICT` (se drift não resolvido)
+
+### 7. Informar o usuário
+
+```
+Publicado: {nome} {tipo}
+
+  confluence-mirror: app_barbearia - TRD (v3) — UPDATED
+
+Link: https://empresa.atlassian.net/wiki/spaces/ST/pages/393238
+```
+
+## Erros
+
+| Erro | Ação |
+|------|------|
+| `sfw.config.yml` não existe | Skippa todos os targets, só salva local |
+| Target MCP não disponível | Avisar, pular target |
+| Sem permissão de escrita | Avisar, pular target |
+| Conflict não resolvido | Não publicar, salvar como CONFLICT no log |
+| Container Output não existe | Criar automaticamente como filho de `output.parent_page_id` |
+
+## Notas
+
+- O `/sf-publish` é **idempotente** pra content sem mudanças — detecta hash igual e marca `SKIPPED`
+- `naming.output_container` e `naming.output_artifact` são aplicados em TODOS os targets
+- Cada target pode ter `publishes: []` diferente (permite segmentar: Confluence recebe 4 artefatos, filesystem recebe todos)
+- `.ai/sf-publish-log.md` é essencial pro conflict detection funcionar
+- Nunca publica tasks.md, docs/, specs/, projetos.yaml — esses são LOCAL ONLY
+
+## Referências
+
+- Adapter interface: `.github/adapters/interface.md`
+- Confluence adapter: `.github/adapters/confluence.md`
+- Naming engine: `.github/adapters/naming.md`