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

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

@@ -1,7 +1,7 @@
 ---
 name: sf-extract
 description: |
-  Extração de insumos. Lê docs/PM/ e gera PRD ou TRD estruturado.
+  Extração de insumos. Lê workspace/Input/ e gera PRD ou TRD estruturado.
   Trigger: /sf-extract
 author: GustavoMaritan
 version: 1.0.0
@@ -35,7 +35,7 @@ Exemplo: `/sf-extract feat_cadastro_cliente`
 ```
 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 docs/PM/{nome}/ → filtrar NOVOS e MODIFICADOS
+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:
@@ -43,7 +43,7 @@ Exemplo: `/sf-extract feat_cadastro_cliente`
    - 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/Estrutura/ (contexto do projeto)
+   - docs/ (contexto do projeto)
 7. Analyzer gera documento final + extract-log
 8. Atualizar .context.md → status: extract_done
 ```
@@ -151,19 +151,19 @@ Se um tema **não foi mencionado em nenhum insumo**, gera **ambiguidade obrigat
 | # | Validação | Se falhar |
 |---|-----------|-----------|
 | 1 | Argumento `nome` foi informado | Parar → "Informe o nome. Ex: /sf-extract feat_cadastro_cliente" |
-| 2 | `docs/PM/{nome}/` existe e contém pelo menos 1 arquivo (ignorar .gitkeep) | Parar → "Pasta de insumos vazia ou inexistente" |
-| 3 | `docs/Desenvolvimento/{nome}/.context.md` existe | Parar → "Execute /sf-feature {nome} ou /sf-setup-projeto primeiro" |
+| 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" |
 
 ## Passos detalhados
 
 ### 1. Ler contexto
 - Ler `.context.md` → identificar `tipo` (feature ou setup) e `documento` (PRD ou TRD)
-- Ler `docs/Estrutura/` se existir (contexto para extração coerente)
+- 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 `docs/PM/{nome}/`. Para cada arquivo, calcular hash (SHA-256 truncado 8 chars).
+Ler todos os arquivos em `workspace/Input/{nome}/`. Para cada arquivo, calcular hash (SHA-256 truncado 8 chars).
 
 Se `.extract-log.md` existir, classificar:
 
@@ -187,7 +187,7 @@ 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/Estrutura/` como contexto
+- `docs/` como contexto
 
 ### 5. Gerar/atualizar documento
 
@@ -277,7 +277,7 @@ atualizado_em: "{{ISO_DATETIME}}"
 | Contradição entre arquivos | Analyzer gera ambiguidade citando os dois arquivos e a contradição |
 
 ## Notas
-- O `/extract` é a ÚNICA skill que lê `docs/PM/` — nenhuma outra skill acessa insumos brutos
+- 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

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

@@ -31,19 +31,19 @@ Exemplo: `/sf-feature feat_cadastro_cliente`
 | # | Validação | Se falhar |
 |---|-----------|-----------|
 | 1 | Argumento `nome` foi informado | Parar → "Informe o nome da feature. Ex: /sf-feature feat_cadastro_cliente" |
-| 2 | `docs/PM/{nome}/` existe | Parar → "Crie a pasta docs/PM/{nome}/ e adicione seus insumos" |
+| 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/Estrutura/` está populado (setup já executado) | Parar → "Execute /sf-setup-projeto antes de criar features" |
+| 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/Estrutura/` para entender a arquitetura, stack, modelo de dados e convenções existentes. Esse contexto será passado ao `/extract`.
+Ler `docs/` para entender a arquitetura, stack, modelo de dados e convenções existentes. Esse contexto será passado ao `/extract`.
 
 ### 2. Criar estrutura
 ```
-docs/Desenvolvimento/{nome}/
+workspace/Output/{nome}/
 ├── .context.md        ← criado agora
 └── (PRD.md será criado pelo /extract)
 ```
@@ -54,7 +54,7 @@ docs/Desenvolvimento/{nome}/
 nome: "{nome}"
 tipo: "feature"
 documento: "PRD"
-pm_path: "docs/PM/{nome}/"
+pm_path: "workspace/Input/{nome}/"
 status: "not_started"
 ultima_skill: "/sf-feature"
 atualizado_em: "{{ISO_DATETIME}}"
@@ -65,21 +65,21 @@ atualizado_em: "{{ISO_DATETIME}}"
 
 Antes de extrair, perguntar ao usuário:
 ```
-📋 Insumos encontrados em docs/PM/{nome}/.
+📋 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 docs/PM/{nome}/ agora? (s/n)
+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 docs/PM/{nome}/`
-- Aguardar conclusão — discovery.md salvo em `docs/Desenvolvimento/{nome}/`
+- 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}`
@@ -88,12 +88,12 @@ O `/sf-extract` lê os insumos + discovery.md (se existir), gera o PRD e atualiz
 ### 6. CHECKPOINT — Parar e informar o usuário
 Mensagem ao usuário:
 ```
-✅ PRD gerado em docs/Desenvolvimento/{nome}/PRD.md
+✅ 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 docs/PM/{nome}/
+Se precisar adicionar mais insumos, coloque na pasta workspace/Input/{nome}/
 e execute:
   /sf-extract {nome}
 ```
@@ -102,29 +102,29 @@ e execute:
 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/Estrutura/)
+4. `/sf-merge-delta {nome}` (aplica Delta Specs em docs/)
 
 ## Saídas diretas desta skill
-- `docs/Desenvolvimento/{nome}/.context.md`
-- `docs/Desenvolvimento/{nome}/PRD.md` (via /extract)
-- `docs/Desenvolvimento/{nome}/.extract-log.md` (via /extract)
+- `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/Estrutura/` atualizado (via /sf-merge-delta após /dev)
+- `docs/` atualizado (via /sf-merge-delta após /dev)
 
 ## Erros
 
 | Erro | Ação |
 |------|------|
 | Nome não informado | Parar, mostrar exemplo de uso |
-| PM/{nome}/ não existe | Parar, instruir criação |
-| PM/{nome}/ vazio | Parar, listar formatos aceitos |
-| Estrutura/ não populado | Parar, sugerir /sf-setup-projeto |
+| 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/Estrutura/` é carregado para que o `/extract` gere um PRD coerente com a arquitetura existente
-- Após `/dev`, o `/merge-delta` atualiza `docs/Estrutura/` com as mudanças da 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-merge-delta/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: sf-merge-delta
 description: |
-  Delta Specs. Aplica mudanças do SDD em docs/Estrutura/.
+  Delta Specs. Aplica mudanças do SDD em docs/.
   Trigger: /sf-merge-delta
 author: GustavoMaritan
 version: 1.0.0
@@ -10,7 +10,7 @@ date: 2026-04-08
 
 # Skill: /sf-merge-delta
 
-> Skill atômica pós-dev. Aplica Delta Specs do SDD em docs/Estrutura/.
+> Skill atômica pós-dev. Aplica Delta Specs do SDD em docs/.
 > Última etapa do pipeline de feature — não se aplica a setup.
 
 ## Tipo
@@ -40,9 +40,9 @@ Exemplo: `/sf-merge-delta feat_cadastro_cliente`
 |---|-----------|-----------|
 | 1 | Argumento `nome` foi informado | Parar → "Informe o nome. Ex: /sf-merge-delta feat_cadastro_cliente" |
 | 2 | `.context.md` existe com status `dev_done` | Se anterior → "Execute /sf-dev {nome} primeiro" |
-| 3 | `.context.md` tipo é `feature` (não `setup`) | Parar → "Setup não usa merge-delta — docs/Estrutura/ foi criado diretamente pelo /sf-dev" |
+| 3 | `.context.md` tipo é `feature` (não `setup`) | Parar → "Setup não usa merge-delta — docs/ foi criado diretamente pelo /sf-dev" |
 | 4 | `sdd.md` existe com §11 Delta Specs preenchida | Parar → "Delta Specs não encontrada no SDD" |
-| 5 | `docs/Estrutura/` está populado | Parar → "docs/Estrutura/ vazio — execute /sf-setup-projeto primeiro" |
+| 5 | `docs/` está populado | Parar → "docs/ vazio — execute /sf-setup-projeto primeiro" |
 
 ## Passos
 
@@ -56,17 +56,20 @@ Ler `sdd.md` §11 e classificar cada delta:
 | **REMOVED** | Elemento removido do sistema | Endpoint DELETE /api/v1/legacy removido |
 
 ### 2. Mapear deltas para docs alvo
-Cada delta afeta um ou mais docs em `docs/Estrutura/`:
+Cada delta afeta um ou mais docs em `docs/`:
 
 | Elemento | Doc alvo |
 |----------|----------|
-| Tabelas, colunas, índices | `Modelo_Dados.md` |
-| Endpoints, contratos | `API.md` |
-| Decisões de arquitetura | `Arquitetura.md` + `ADRs.md` |
-| Mudanças de infra | `Infraestrutura.md` |
-| Mudanças de segurança | `Seguranca.md` |
-| Mudanças de stack | `Stack.md` |
-| Mudanças de visão/escopo | `Visao.md` |
+| Tabelas, colunas, índices, entidades | `domain.md` |
+| Visão/escopo, atores, integrações externas, glossário | `domain.md` |
+| Endpoints, rotas, contratos, paginação, filtros | `apiContracts.md` |
+| Containers, componentes, ambientes, deploy, stack | `architecture.md` |
+| Decisões arquiteturais | `decisions.md` (+ padrão aplicado em `architecture.md` se couber) |
+| Autenticação, autorização, roles, permissões | `conventions.md` |
+| CORS, rate limiting, LGPD, auditoria | `conventions.md` |
+| Variáveis de ambiente, domínios, monitoramento | `conventions.md` |
+| Códigos de erro do domínio | `conventions.md` |
+| Alternativas tecnológicas descartadas | `conventions.md` |
 
 ### 3. Aplicar cada delta
 Para cada delta, no doc alvo:
@@ -103,14 +106,14 @@ Após todas alterações:
 
 ### 5. Atualizar status
 - `.context.md` → status: `done`
-- `docs/Desenvolvimento/progresso.md` → feature marcada como concluída
+- `workspace/Output/progresso.md` → feature marcada como concluída
 - Informar ao usuário:
   ```
-  ✅ Delta Specs aplicadas em docs/Estrutura/
+  ✅ Delta Specs aplicadas em docs/
   
   Docs atualizados:
-  - Modelo_Dados.md — ADDED: tabelas clientes, clientes_enderecos
-  - API.md — ADDED: endpoints POST/GET /api/v1/clientes
+  - domain.md — ADDED: tabelas clientes, clientes_enderecos
+  - apiContracts.md — ADDED: endpoints POST/GET /api/v1/clientes
   
   Feature {nome} concluída.
   ```
@@ -121,12 +124,12 @@ Após todas alterações:
 
 | Arquivo | Descrição |
 |---------|-----------|
-| `docs/Estrutura/*.md` | Docs globais atualizados com deltas da feature |
+| `docs/*.md` | Docs globais atualizados com deltas da feature |
 | `progresso.md` (global) | Feature marcada como concluída |
 | `.context.md` | Status: `done` |
 
 ## Pós-condições
-- `docs/Estrutura/` reflete o estado real do sistema
+- `docs/` reflete o estado real do sistema
 - Cada mudança rastreável: changelog → feature → SDD → PRD → insumo
 - Feature completamente concluída
 

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

@@ -38,7 +38,7 @@ Exemplo: `/sf-plan feat_cadastro_cliente`
 | # | Validação | Se falhar |
 |---|-----------|-----------|
 | 1 | Argumento `nome` foi informado | Parar → "Informe o nome. Ex: /sf-plan feat_cadastro_cliente" |
-| 2 | `docs/Desenvolvimento/{nome}/.context.md` existe com status `design_done` | Se anterior → "Execute /sf-design {nome} primeiro". Se posterior → "Tasks já foram geradas (status: {status})" |
+| 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
@@ -47,9 +47,9 @@ Exemplo: `/sf-plan feat_cadastro_cliente`
 - Ler `.context.md` → validar status
 - Ler `sdd.md` completo
 - Ler `projetos.yaml` (manifesto de repos — mapeamento área → repo)
-- Ler `docs/Estrutura/` (Stack, Arquitetura — para convenções por área)
-- Ler `docs/Desenvolvimento/rules.md` (padrões de código, commit, branch)
-- Carregar template `docs/_templates/feature/tasks.template.md`
+- 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:
@@ -68,7 +68,7 @@ Para cada fase de entrega, mapear seções do SDD para áreas de tasks:
 | §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/Estrutura/ é gerado pelo /sf-design (passo 3).
+> **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.
@@ -118,10 +118,10 @@ Tasks são agrupadas por **fase de entrega** (do PRD §11), não só por fase t
 | 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/Estrutura/ a partir do TRD |
+| DOC | Gerar docs/ a partir do TRD |
 
 ### 5. Gerar `Progresso.md`
-Usando template `docs/_templates/feature/Progresso.template.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
@@ -137,7 +137,7 @@ Usando template `docs/_templates/feature/Progresso.template.md`:
 - Checklist pós-conclusão (merge delta, atualizar progresso global, napkin)
 
 ### 6. Atualizar progresso global
-Adicionar entrada em `docs/Desenvolvimento/progresso.md`:
+Adicionar entrada em `workspace/Output/progresso.md`:
 
 ```markdown
 | {nome} | plan_done | BANCO: 0/N | BACK: 0/N | FRONT: 0/N |

package/templates/.github/skills/{sf-pausar → sf-session-finish}/SKILL.md

@@ -1,14 +1,14 @@
 ---
-name: sf-pausar
+name: sf-session-finish
 description: |
   Encerrar sessão. Salva estado, atualiza napkin, gera retomada.md.
-  Trigger: /sf-pausar
+  Trigger: /sf-session-finish
 author: GustavoMaritan
 version: 1.0.0
 date: 2026-04-08
 ---
 
-# Skill: /sf-pausar
+# Skill: /sf-session-finish
 
 > Encerra a sessão de trabalho de forma organizada.
 > Consolida estado, atualiza memória, gera ponto de retomada para a próxima sessão.
@@ -18,7 +18,7 @@ Utilitária — roda a qualquer momento
 
 ## Uso
 ```
-/sf-pausar
+/sf-session-finish
 ```
 
 ---
@@ -27,7 +27,7 @@ Utilitária — roda a qualquer momento
 
 ### 1. Levantar estado atual de cada feature/setup
 
-Para cada `.context.md` em `docs/Desenvolvimento/*/`:
+Para cada `.context.md` em `workspace/Output/*/`:
 - Ler status atual
 - Ler Progresso.md (se existir) → % concluído, fase atual
 - Identificar tasks em andamento (`- [ ]` com dependências resolvidas)
@@ -55,12 +55,12 @@ Adicionar/atualizar seção `## Sessão Atual` com:
 
 ### 4. Gerar resumo de retomada
 
-Criar/atualizar `docs/Desenvolvimento/retomada.md`:
+Criar/atualizar `workspace/Output/retomada.md`:
 
 ```markdown
 # Ponto de Retomada — {{DATA}}
 
-> Gerado pelo /sf-pausar. Leia este arquivo ao iniciar a próxima sessão.
+> Gerado pelo /sf-session-finish. Leia este arquivo ao iniciar a próxima sessão.
 
 ## Estado geral
 
@@ -96,7 +96,7 @@ Criar/atualizar `docs/Desenvolvimento/retomada.md`:
 ```
 ✅ Sessão encerrada. Estado salvo em:
   - `.ai/memory/napkin.md` — memória atualizada
-  - `docs/Desenvolvimento/retomada.md` — ponto de retomada
+  - `workspace/Output/retomada.md` — ponto de retomada
 
 Para retomar na próxima sessão:
   1. Ler retomada.md
@@ -110,11 +110,11 @@ Para retomar na próxima sessão:
 | Arquivo | Descrição |
 |---------|-----------|
 | `.ai/memory/napkin.md` | Sessão atual atualizada |
-| `docs/Desenvolvimento/retomada.md` | Ponto de retomada com estado completo |
+| `workspace/Output/retomada.md` | Ponto de retomada com estado completo |
 
 ## Notas
 
 - Não modifica .context.md (o status da pipeline não muda ao pausar)
 - Não faz commit automático — se tem working tree sujo, avisa mas não força
 - Pode ser chamada a qualquer momento, não só no final do dia
-- O arquivo `retomada.md` é sobrescrito a cada /sf-pausar (é ponto atual, não histórico)
+- O arquivo `retomada.md` é sobrescrito a cada /sf-session-finish (é ponto atual, não histórico)

package/templates/.github/skills/sf-setup-projeto/SKILL.md

@@ -25,16 +25,16 @@ Orquestrador (primeira etapa do pipeline)
 
 | # | Validação | Se falhar |
 |---|-----------|-----------|
-| 1 | `docs/PM/setup_projeto/` existe | Parar → "Crie a pasta docs/PM/setup_projeto/ e adicione seus insumos" |
+| 1 | `workspace/Input/setup_projeto/` existe | Parar → "Crie a pasta workspace/Input/setup_projeto/ e adicione seus insumos" |
 | 2 | 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)" |
-| 3 | `docs/Estrutura/` está vazio ou contém apenas templates vazios | Parar → "Setup já foi executado. Use /sf-feature para novas funcionalidades" |
-| 4 | `docs/Desenvolvimento/setup_projeto/.context.md` não existe ou status é `not_started` | Parar → "Setup já está em andamento. Verifique o status em .context.md" |
+| 3 | `docs/` está vazio ou contém apenas templates vazios | Parar → "Setup já foi executado. Use /sf-feature para novas funcionalidades" |
+| 4 | `workspace/Output/setup_projeto/.context.md` não existe ou status é `not_started` | Parar → "Setup já está em andamento. Verifique o status em .context.md" |
 
 ## Passos
 
 ### 1. Criar estrutura
 ```
-docs/Desenvolvimento/setup_projeto/
+workspace/Output/setup_projeto/
 ├── .context.md        ← criado agora
 └── (TRD.md será criado pelo /extract)
 ```
@@ -45,7 +45,7 @@ docs/Desenvolvimento/setup_projeto/
 nome: "setup_projeto"
 tipo: "setup"
 documento: "TRD"
-pm_path: "docs/PM/setup_projeto/"
+pm_path: "workspace/Input/setup_projeto/"
 status: "not_started"
 ultima_skill: "/sf-setup-projeto"
 atualizado_em: "{{ISO_DATETIME}}"
@@ -56,21 +56,21 @@ atualizado_em: "{{ISO_DATETIME}}"
 
 Antes de extrair, perguntar ao usuário:
 ```
-📋 Insumos encontrados em docs/PM/setup_projeto/.
+📋 Insumos encontrados em workspace/Input/setup_projeto/.
 
 Recomendo rodar /sf-discovery antes da extração para:
   - Análise profunda dos insumos (parseia drawio, XML, SQL completo)
   - Identificar gaps e contradições antes de estruturar
   - Validar entendimento com você (mapa do sistema)
 
-Quer rodar /sf-discovery docs/PM/setup_projeto/ agora? (s/n)
+Quer rodar /sf-discovery workspace/Input/setup_projeto/ agora? (s/n)
   Se SIM → rodar discovery, salvar discovery.md, depois continuar com extract
   Se NÃO → pular direto para /sf-extract (ok para insumos simples)
 ```
 
 Se o usuário aceitar:
-- Rodar `/sf-discovery docs/PM/setup_projeto/`
-- Aguardar conclusão — discovery.md salvo em `docs/Desenvolvimento/setup_projeto/`
+- Rodar `/sf-discovery workspace/Input/setup_projeto/`
+- Aguardar conclusão — discovery.md salvo em `workspace/Output/setup_projeto/`
 - Continuar para o passo 4
 
 ### 4. Chamar `/sf-extract setup_projeto`
@@ -79,30 +79,30 @@ O `/sf-extract` lê os insumos + discovery.md (se existir), gera o TRD e atualiz
 ### 5. CHECKPOINT — Parar e informar o usuário
 Mensagem ao usuário:
 ```
-✅ TRD gerado em docs/Desenvolvimento/setup_projeto/TRD.md
+✅ TRD gerado em workspace/Output/setup_projeto/TRD.md
 
 Revise o documento. Quando estiver satisfeito, execute:
   /sf-design setup_projeto
 
-Se precisar adicionar mais insumos, coloque na pasta docs/PM/setup_projeto/
+Se precisar adicionar mais insumos, coloque na pasta workspace/Input/setup_projeto/
 e execute:
   /sf-extract setup_projeto
 ```
 
 **O orquestrador encerra aqui.** O restante do pipeline é responsabilidade do usuário chamar as skills atômicas na ordem:
-1. `/sf-design setup_projeto` (pergunta aprovação → gera SDD + docs/Estrutura/ + projetos.yaml)
+1. `/sf-design setup_projeto` (pergunta aprovação → gera SDD + docs/ + projetos.yaml)
 2. `/sf-plan setup_projeto` (gera tasks com campo Repo por task)
 3. `/sf-dev setup_projeto` (INFRA-001 cria/clona repos em projetos/, executa tasks nos repos corretos)
 
 ## Saídas diretas desta skill
-- `docs/Desenvolvimento/setup_projeto/.context.md`
-- `docs/Desenvolvimento/setup_projeto/TRD.md` (via /extract)
-- `docs/Desenvolvimento/setup_projeto/.extract-log.md` (via /extract)
+- `workspace/Output/setup_projeto/.context.md`
+- `workspace/Output/setup_projeto/TRD.md` (via /extract)
+- `workspace/Output/setup_projeto/.extract-log.md` (via /extract)
 
 ## Saídas indiretas (skills subsequentes)
 - `sdd.md` (via /design)
 - `projetos.yaml` (via /sf-design — manifesto de repos)
-- `docs/Estrutura/` populado (via /design)
+- `docs/` populado (via /design)
 - `*_tasks.md` + `Progresso.md` (via /plan)
 - `projetos/` com repos criados/clonados (via /sf-dev INFRA-001)
 
@@ -110,14 +110,14 @@ e execute:
 
 | Erro | Ação |
 |------|------|
-| PM/setup_projeto/ não existe | Parar, instruir criação |
-| PM/setup_projeto/ vazio | Parar, listar formatos aceitos |
-| Estrutura/ já populado | Parar, sugerir /sf-feature |
+| workspace/Input/setup_projeto/ não existe | Parar, instruir criação |
+| workspace/Input/setup_projeto/ vazio | Parar, listar formatos aceitos |
+| docs/ já populado | Parar, sugerir /sf-feature |
 | Pipeline já iniciado | Parar, mostrar status atual do .context.md |
 
 ## Notas
 - Esta skill roda **uma única vez** por projeto
-- docs/Estrutura/ é gerado pelo /sf-design (passo 3), não por tasks DOC
+- docs/ é gerado pelo /sf-design (passo 3), não por tasks DOC
 - `projetos.yaml` é gerado pelo /sf-design (passo 3b) — mapeia serviços para repos
 - Repos são criados/clonados pelo /sf-dev (INFRA-001) dentro de `projetos/`
 - O `/merge-delta` NÃO se aplica ao setup (é criação, não atualização)

package/templates/{docs/_templates/estrutura/API.template.md → .github/templates/estrutura/apiContracts.template.md}

@@ -1,6 +1,8 @@
-# Convenções de API
+# Contratos de API
 
-> Padrões globais para todas as APIs do sistema: versionamento, autenticação, paginação, erros.
+> Padrões de endpoint, convenções de rotas, paginação, filtros, respostas de erro
+> e catálogo global. Contratos HTTP do sistema.
+> Autenticação detalhada e códigos de erro do domínio vivem em conventions.md.
 
 ---
 
@@ -9,20 +11,27 @@
 INSTRUÇÕES PARA O AGENTE (não incluir no arquivo gerado)
 =============================================================================
 
-ORIGEM: Gerado pelo /setup-projeto a partir do TRD §5.
-ATUALIZAÇÃO: /merge-delta quando features adicionam endpoints (Delta Specs do SDD §5 e §11).
+ORIGEM: Gerado pelo /setup-projeto a partir do TRD §5 (API).
+ATUALIZAÇÃO: /merge-delta quando features adicionam endpoints
+(Delta Specs do SDD §5 e §11).
 
 COMO GERAR:
-1. Ler TRD §5 (Convenções de API) — padrão geral, versionamento, autenticação
+1. Ler TRD §5 (Convenções de API) — padrão geral, versionamento
 2. Padrão geral e convenções são FIXOS após setup — definidos uma vez
-3. Catálogo de endpoints é DINÂMICO — cresce a cada feature
-4. Formatos de paginação, filtro e erro são FIXOS — toda API segue
+3. Catálogo de endpoints é DINÂMICO — cresce a cada feature via merge-delta
+4. Formatos de paginação, filtro e resposta de erro são FIXOS
+
+O QUE NÃO VAI AQUI:
+- Autenticação detalhada (hash, refresh, fluxo) → conventions.md
+- Autorização, roles, matriz de permissões → conventions.md
+- Códigos de erro do domínio → conventions.md
+- Rate limiting → conventions.md
+- CORS → conventions.md
 
 REGRAS:
-- Convenções são LEI — todo SDD §5 (endpoints) deve seguir estes padrões
-- Catálogo de endpoints atualizado a cada merge-delta
-- Mudanças em convenções (raro) devem gerar ADR
-- Rate limiting definido por categoria de endpoint, não individual
+- Convenções são LEI — todo SDD §5 (endpoints) deve seguir
+- Catálogo atualizado a cada merge-delta
+- Mudanças em convenções (raro) devem gerar registro em decisions.md
 
 =============================================================================
 -->
@@ -34,10 +43,11 @@ REGRAS:
 | Estilo | <!-- REST / GraphQL / gRPC --> |
 | Formato | <!-- JSON / Protobuf --> |
 | Versionamento | <!-- /api/v1/ no path? Header? --> |
-| Autenticação | <!-- Bearer JWT? API Key? --> |
 | Content-Type | <!-- application/json --> |
 | Encoding | <!-- UTF-8 --> |
 
+> **Autenticação**: definida em [conventions.md → Autenticação](./conventions.md#autenticação).
+
 ## Convenções de Rotas
 
 | Operação | Método | Rota | Exemplo |
@@ -50,6 +60,7 @@ REGRAS:
 | Remover/Inativar | DELETE | `/api/v1/{recurso}/:id` | |
 
 ### Convenções de nomenclatura
+
 | Regra | Exemplo |
 |-------|---------|
 | Recursos no plural, kebab-case | `/api/v1/order-items` |
@@ -121,11 +132,7 @@ Query params: `?busca=termo&campo=valor`
 | 429 | Rate limit excedido | Muitas requisições |
 | 500 | Erro interno | Bug não tratado |
 
-### Códigos de erro do domínio
-
-| Código | Descrição | HTTP |
-|--------|-----------|------|
-| <!-- Ex: DUPLICATE_EMAIL --> | <!-- Email já cadastrado --> | <!-- 409 --> |
+> **Códigos de erro do domínio**: definidos em [conventions.md → Códigos de Erro do Domínio](./conventions.md#códigos-de-erro-do-domínio).
 
 ## Catálogo de Endpoints