@brunosps00/dev-workflow 0.8.0 → 0.9.0

package/scaffold/pt-br/commands/dw-analyze-project.md

@@ -218,19 +218,14 @@ Para cada projeto/módulo detectado, identificar:
 Quando React for detectado, execute `npx react-doctor@latest --verbose` e inclua o health score nas rules geradas como métrica baseline.
 Para projetos Angular, execute `ng lint` e documente warnings como baseline.
 
-<critical>Se o GSD estiver instalado, a execução do /gsd-map-codebase é OBRIGATÓRIA. O comando NÃO pode ser considerado completo sem executar TODOS os passos aplicáveis, incluindo a geração do índice em .planning/intel/.</critical>
+<critical>A execução do /dw-map-codebase para gerar o índice queryable em .dw/intel/ é OBRIGATÓRIA. O comando NÃO pode ser considerado completo sem ela.</critical>
 
-#### Inteligência do Codebase (GSD)
+#### Inteligência do Codebase (nativo)
 
-Se o GSD (get-shit-done-cc) estiver instalado no projeto:
-- Após gerar as rules em `.dw/rules/`, delegue para `/gsd-map-codebase` para criar índice rico em `.planning/intel/`
-- O índice inclui: architectural assumptions, decision spaces, behavioral references, UI patterns
-- O índice é incremental — re-executar adiciona ao existente, não substitui
-- Outros comandos dw-* podem consultar o índice via `/gsd-intel` internamente
-
-Se o GSD NÃO estiver instalado:
-- Gere apenas `.dw/rules/` (comportamento atual)
-- Sugira: "Para inteligência queryable do codebase, instale GSD via `npx dev-workflow install-deps`"
+Após gerar as rules em `.dw/rules/`, delegue para `/dw-map-codebase` para criar o índice queryable em `.dw/intel/`:
+- O índice inclui: stack (`stack.json`), grafo de arquivos (`files.json`), superfície de API (`apis.json`), dependências (`deps.json`), overview de arquitetura (`arch.md`)
+- O índice é incremental — `/dw-map-codebase --files <list>` atualiza só os entries tocados; full scan só quando preciso
+- Outros comandos dw-* consultam o índice via `/dw-intel` (veja a skill bundled `dw-codebase-intel` para schemas)
 
 ### Passo 4: Ler Arquivos Fonte Representativos (Obrigatório)
 

package/scaffold/pt-br/commands/dw-autopilot.md

@@ -68,10 +68,11 @@ Se este comando for invocado para retomar um autopilot interrompido (via `/dw-re
 
 ### Etapa 1: Inteligencia do Codebase
 
-<critical>Se `.planning/intel/` existir, a consulta e OBRIGATORIA antes de iniciar.</critical>
+<critical>Se `.dw/intel/` existir, a consulta via `/dw-intel` e OBRIGATORIA antes de iniciar. Cai para `.dw/rules/` e grep direto se ausente.</critical>
 
-- Consulte `.planning/intel/` via `/gsd-intel` (se disponivel) ou `.dw/rules/` para entender o contexto do projeto
+- Consulte `.dw/intel/` via `/dw-intel` para entender o contexto do projeto
 - Identifique: stack tecnologica, padroes existentes, features relacionadas
+- Se `.dw/intel/` esta ausente, sugira rodar `/dw-map-codebase` primeiro para contexto downstream mais rico
 
 ### Etapa 2: Pesquisa (Condicional)
 
@@ -148,7 +149,7 @@ Avalie se as tasks envolvem frontend:
 ### Etapa 8: Execucao
 
 Execute `/dw-run-plan` com o path do PRD.
-- Siga TODAS as instrucoes do comando, incluindo integracao GSD (verificacao de plano, execucao paralela)
+- Siga TODAS as instrucoes do comando, incluindo o gate nativo do plan-checker (PASS obrigatorio) e execucao paralela em waves via `/dw-execute-phase`
 - Cada task segue `/dw-run-task` com validacao Level 1
 
 ### Etapa 9: Review de Implementacao (Loop)
@@ -247,17 +248,9 @@ Pergunte ao usuario: **"Commits realizados. Deseja gerar o Pull Request?"**
 - **SIM**: execute `/dw-generate-pr` com o branch alvo
 - **NAO**: informe que os commits estao prontos e o usuario pode gerar o PR manualmente depois
 
-## Integracao GSD
+## Engine Nativo
 
-<critical>Quando o GSD estiver instalado, TODAS as integracoes GSD de cada comando individual DEVEM ser executadas. O autopilot nao e desculpa para pular passos do GSD.</critical>
-
-Se o GSD (get-shit-done-cc) estiver instalado:
-- Etapa 1: use `/gsd-intel` para consulta
-- Etapa 8: use verificacao de plano + execucao paralela
-- Todos os comandos: sigam suas secoes GSD individuais
-
-Se o GSD NAO estiver instalado:
-- Todos os comandos funcionam normalmente sem GSD
+O autopilot depende de infraestrutura dev-workflow-native para inteligencia de codebase (`/dw-map-codebase` + `/dw-intel`), verificacao de plano (`/dw-plan-checker`), e execucao paralela (`/dw-execute-phase`). Os quatro vem bundled e nao precisam de dependencias externas. Veja as skills bundled `dw-codebase-intel` e `dw-execute-phase` em `.agents/skills/` para detalhes.
 
 ## Persistencia de Estado
 

package/scaffold/pt-br/commands/dw-brainstorm.md

@@ -65,7 +65,7 @@ Use este comando quando o usuario quiser:
 2. **Reformule como "How Might We"**: transforme a ideia bruta em `How might we [verbo] para [usuário] de forma que [resultado]?`. Isso tira o time de "solution mode" prematuro.
 3. **Product Inventory (obrigatório se o produto existe)**:
    - Se `.dw/spec/prd-*/` tem PRDs OU `.dw/rules/index.md` existe, leia esses artefatos para mapear o **inventário de features do produto atual** (nível de produto, não de código).
-   - Fontes a consultar: `.dw/spec/prd-*/prd.md` (seções Overview / Main Features / User Stories), `.dw/rules/index.md` e `.dw/rules/<modulo>.md`, `.planning/intel/` se existir.
+   - Fontes a consultar: `.dw/spec/prd-*/prd.md` (seções Overview / Main Features / User Stories), `.dw/rules/index.md` e `.dw/rules/<modulo>.md`, `.dw/intel/` se existir (queryable via `/dw-intel`).
    - Produza um **Feature Inventory curto (5-12 bullets)** antes de divergir: "o produto hoje faz X, Y, Z".
    - Se o projeto é greenfield (sem PRDs nem rules), registre: "Feature Inventory: greenfield — nenhum artefato de produto ainda".
 4. Se faltar contexto essencial para o usuário (problema, persona, valor esperado), faça perguntas curtas e objetivas antes de expandir.

package/scaffold/pt-br/commands/dw-code-review.md

@@ -29,13 +29,14 @@ Quando disponíveis no projeto em `./.agents/skills/`, use estas skills como apo
 
 ## Inteligência do Codebase
 
-<critical>Se `.planning/intel/` existir, a consulta é OBRIGATÓRIA antes de redigir os requisitos. NÃO pule este passo.</critical>
-- Execute internamente: `/gsd-intel "convenções, anti-patterns e decision spaces documentados"`
+<critical>Se `.dw/intel/` existir, a consulta via `/dw-intel` é OBRIGATÓRIA antes do review. NÃO pule este passo.</critical>
+- Execute internamente: `/dw-intel "convenções e anti-patterns documentados"`
 - Priorize findings que violem convenções documentadas
-- Verifique se decisões arquiteturais questionáveis são intencionais (documentadas como decision spaces)
+- Verifique se decisões arquiteturais questionáveis são intencionais (documentadas em `.dw/rules/`)
 
-Se `.planning/intel/` NÃO existir:
-- Use `.dw/rules/` como contexto (comportamento atual)
+Se `.dw/intel/` NÃO existir:
+- Use `.dw/rules/` como contexto, caindo para grep
+- Sugira rodar `/dw-map-codebase` após o review para enriquecer contexto downstream
 
 ## Variáveis de Entrada
 

package/scaffold/pt-br/commands/dw-create-prd.md

@@ -42,12 +42,13 @@
 
     ## Inteligência do Codebase
 
-    <critical>Se `.planning/intel/` existir, a consulta é OBRIGATÓRIA antes de redigir os requisitos. NÃO pule este passo.</critical>
-    - Execute internamente: `/gsd-intel "features existentes no domínio de [tópico do PRD]"`
+    <critical>Se `.dw/intel/` existir, a consulta via `/dw-intel` é OBRIGATÓRIA antes de redigir os requisitos. NÃO pule este passo.</critical>
+    - Execute internamente: `/dw-intel "features existentes no domínio de [tópico do PRD]"`
     - Use os findings para evitar duplicar funcionalidade existente e referenciar padrões já estabelecidos
 
-    Se `.planning/intel/` NÃO existir:
-    - Use `.dw/rules/` como contexto (comportamento atual)
+    Se `.dw/intel/` NÃO existir:
+    - Use `.dw/rules/` como contexto, caindo para grep
+    - Sugira rodar `/dw-map-codebase` para enriquecer contexto downstream
 
     ## Features Multi-Projeto
 

package/scaffold/pt-br/commands/dw-create-techspec.md

@@ -29,12 +29,13 @@
 
     ## Inteligência do Codebase
 
-    <critical>Se `.planning/intel/` existir, a consulta é OBRIGATÓRIA antes de redigir os requisitos. NÃO pule este passo.</critical>
-    - Execute internamente: `/gsd-intel "padrões arquiteturais e decisões técnicas do projeto"`
+    <critical>Se `.dw/intel/` existir, a consulta via `/dw-intel` é OBRIGATÓRIA antes de redigir o techspec. NÃO pule este passo.</critical>
+    - Execute internamente: `/dw-intel "padrões arquiteturais e decisões técnicas do projeto"`
     - Alinhe propostas com padrões existentes; sinalize desvios explicitamente
 
-    Se `.planning/intel/` NÃO existir:
-    - Use `.dw/rules/` como contexto (comportamento atual)
+    Se `.dw/intel/` NÃO existir:
+    - Use `.dw/rules/` como contexto, caindo para grep
+    - Sugira rodar `/dw-map-codebase` para enriquecer contexto downstream
 
     ## Fluxograma de Decisão Multi-Projeto
 

package/scaffold/pt-br/commands/dw-execute-phase.md

@@ -0,0 +1,149 @@
+<system_instructions>
+Voce e um orquestrador de execucao de fase. Sua funcao e spawnar o agente `dw-executor` (da skill bundled `dw-execute-phase`) para executar cada task em `.dw/spec/prd-<slug>/tasks.md` em waves, com um commit atomico por task. Antes de spawnar o executor, voce DEVE gatear no agente `dw-plan-checker` — execucao nao comeca ate o plan-checker retornar PASS.
+
+<critical>NUNCA execute sem PASS do plan-checker. O gate nao e negociavel. Se plan-checker retorna REVISE ou BLOCK, aborte e suba o veredito.</critical>
+<critical>Um commit por task. O executor enforca isso; nao bypasse.</critical>
+<critical>Deviation Rule 3 (conflito arquitetural) aborta a execucao. Nao auto-retry.</critical>
+
+## Quando Usar
+
+- Apos `/dw-create-tasks` produzir `tasks.md` e voce quer executar a fase inteira
+- Quando `/dw-autopilot` chega no estagio de execucao
+- Apos resolver issues REVISE de uma rodada anterior do plan-checker
+- NAO para mudancas single-task (use `/dw-run-task`)
+- NAO para scaffolding greenfield (use `/dw-new-project`)
+
+## Posicao no Pipeline
+
+**Antecessor:** `/dw-create-tasks` (e opcionalmente `/dw-plan-checker` rodado manualmente antes) | **Sucessor:** `/dw-run-qa` para validar contra PRD, depois `/dw-code-review` e `/dw-generate-pr`
+
+## Skills Complementares
+
+| Skill | Gatilho |
+|-------|---------|
+| `dw-execute-phase` | **SEMPRE** — fonte dos agentes `dw-executor` e `dw-plan-checker` e references (`wave-coordination.md`, `plan-verification.md`, `atomic-commits.md`) |
+| `dw-codebase-intel` | Opcional — executor le `.dw/intel/` para fatos do codebase durante implementacao |
+| `dw-verify` | **SEMPRE** — VERIFICATION REPORT apos cada fase concluir (test + lint + build PASS) |
+
+## Variaveis de Entrada
+
+| Variavel | Descricao | Exemplo |
+|----------|-----------|---------|
+| `{{PRD_PATH}}` | Caminho da pasta do PRD com `tasks.md` | `.dw/spec/prd-checkout-v2` |
+| `{{START_FROM}}` | Opcional. Resume da task NN (default 01) | `04` |
+| `{{MODE}}` | Opcional. `full` (default), `wave-only N`, `up-to-task NN` | `full` |
+
+## Flags
+
+| Flag | Comportamento |
+|------|---------------|
+| (default) | Roda todas as waves ate completar com gate plan-checker |
+| `--skip-check` | PERIGOSO — pula gate plan-checker. So permitido se plan-checker rodou ha <30 min e retornou PASS (audit log do verifier). |
+| `--dry-run` | Roda so plan-checker; nao spawna executor. |
+| `--from <NN>` | Resume da task NN (pula tasks anteriores). Use com `/dw-resume`. |
+
+## Localizacao dos Arquivos
+
+- PRD: `{{PRD_PATH}}/prd.md`
+- TechSpec: `{{PRD_PATH}}/techspec.md`
+- Tasks: `{{PRD_PATH}}/tasks.md` (o plano sendo executado)
+- Detalhe por task: `{{PRD_PATH}}/<NN>_task.md`
+- Log de deviations: `{{PRD_PATH}}/deviations.md`
+- Resumo da fase (saida): `{{PRD_PATH}}/SUMMARY.md`
+- Sessao ativa (checkpoint): `{{PRD_PATH}}/active-session.md`
+- Fonte da skill: `.agents/skills/dw-execute-phase/{SKILL.md, agents/*.md, references/*.md}`
+
+## Comportamento Obrigatorio
+
+### Stage 1 — Gate plan-checker
+
+Spawne agente `dw-plan-checker` com o caminho do PRD. O agente roda a verificacao de 6 dimensoes (requirement coverage, task completeness, dependency soundness, artifact wiring, context budget, constraint compliance).
+
+Tres veredictos possiveis:
+
+- **PASS** → segue para Stage 2
+- **REVISE** → aborta. Imprime os issues. Sugere re-rodar `/dw-create-tasks` com os issues como input. Exit status: `PHASE-REVISE-NEEDED`.
+- **BLOCK** → aborta. Imprime issues com citacoes file:line. Exit status: `PHASE-BLOCKED`. Usuario tem que resolver manualmente antes de re-rodar.
+
+Se `--skip-check` for passada E existir PASS recente do plan-checker no audit log (em <30 min), pula Stage 1. Caso contrario, rejeita a flag.
+
+### Stage 2 — Dispatch do executor
+
+Spawne agente `dw-executor` com:
+
+- `prd_path: {{PRD_PATH}}`
+- `start_from: {{START_FROM}}` (default `01`)
+- `mode: {{MODE}}` (default `full`)
+- Bloco `required_reading:` citando `SKILL.md`, `agents/executor.md`, `references/wave-coordination.md`, `references/atomic-commits.md`
+
+O executor:
+
+1. Computa waves a partir dos campos `Depends on:`
+2. Para cada wave, dispatcha subagentes em paralelo (um por task)
+3. Cada subagente implementa + verifica + commita atomicamente
+4. Marca `[x]` em `tasks.md` apos cada task commitar
+5. Escreve `SUMMARY.md` apos a wave final
+6. Checkpoint em `active-session.md` se budget de contexto chega a 70%
+
+### Stage 3 — Verificacao
+
+Apos executor retornar, rode skill `dw-verify`: test + lint + build do projeto inteiro tem que PASSAR.
+
+Se verificacao falha → status `PHASE-VERIFICATION-FAILED`. A fase commitou codigo (atomico por task) mas o estado agregado tem issues. Suba para o usuario — provavelmente precisa `/dw-fix-qa` em seguida.
+
+### Stage 4 — Relatorio
+
+Imprime:
+
+```
+## Execucao da Fase Concluida
+
+PRD: {{PRD_PATH}}
+Status: <COMPLETE | PARTIAL | CHECKPOINT>
+Tasks: <N> total, <N> commitadas, <N> deviations
+Waves: <N> (largura max: <N>)
+Duracao: <minutos>
+Commit final: <SHA>
+
+VERIFICATION REPORT:
+- Lint: PASS/FAIL
+- Tests: PASS/FAIL
+- Build: PASS/FAIL
+
+Proximos passos:
+- Rode /dw-run-qa para validar contra criterios de aceitacao do PRD
+- Rode /dw-code-review para o review formal Nivel 3
+- Depois /dw-generate-pr para shippar
+```
+
+## Regras Criticas
+
+- <critical>PASS do plan-checker e gate hard. NUNCA execute sem ele (exceto com `--skip-check` E PASS prio fresco).</critical>
+- <critical>O executor possui o formato de commit. NUNCA post-processe commits deste comando.</critical>
+- <critical>Deviations Rule 3 (conflitos arquiteturais) abortam a fase. Nao auto-retry.</critical>
+- <critical>Checkpoint > push-through. Se o executor faz checkpoint, NAO auto-restart; deixe o usuario invocar `/dw-resume`.</critical>
+- NAO faca push pro remote. `/dw-generate-pr` cuida do push.
+- NAO pule dimensoes no plan-checker via flags. Plan-checker e nao-negociavel.
+
+## Tratamento de Erros
+
+- Plan-checker retorna BLOCK → exit `PHASE-BLOCKED`, suba issues, sem auto-replan
+- Executor retorna `EXEC-BLOCKED` (Rule 3 deviation) → exit `PHASE-BLOCKED`, a deviation esta em `deviations.md`
+- Executor retorna `EXEC-PARTIAL` → algumas tasks commitadas, recuperavel via `/dw-resume`
+- Executor retorna `CHECKPOINT` → budget de contexto exausto, `/dw-resume` para continuar
+- Plan-checker timeout (>5 min) → exit status `PLAN-CHECK-TIMEOUT`, sugere reduzir tamanho da fase
+
+## Integracao com Outros dw-* Commands
+
+- **`/dw-create-tasks`** — antecessor; produz o `tasks.md` que este comando executa
+- **`/dw-plan-checker`** — invocacao manual do gate (este comando bundles ele)
+- **`/dw-resume`** — restaura de `active-session.md` apos CHECKPOINT
+- **`/dw-run-task`** — roda uma task unica; `/dw-execute-phase` roda a fase inteira
+- **`/dw-run-plan`** — comando antigo; v0.9.0 transforma em alias para este (ambos chamam os mesmos agentes)
+- **`/dw-run-qa`** — sucessor; valida fase implementada contra PRD
+
+## Inspirado em
+
+`dw-execute-phase` e dev-workflow-native. O padrao two-stage gate-then-execute, o dispatch wave-based parallel, atomic-commit-per-task, deviation handling, e checkpoint protocol sao adaptados de [`get-shit-done-cc`](https://github.com/gsd-build/get-shit-done) (`/gsd-execute-phase`, `gsd-executor`, `gsd-plan-checker`) por gsd-build (licenca MIT). Especificos do dev-workflow: escreve em `.dw/spec/prd-<slug>/` (nao `.planning/<phase>/`), usa hierarquia PRD/TechSpec/Tasks do dev-workflow, integra com skills `dw-verify` e `dw-codebase-intel`.
+
+</system_instructions>

package/scaffold/pt-br/commands/dw-fix-qa.md

@@ -2,8 +2,9 @@
 Você é um assistente IA especializado em correção de bugs pós-QA com reteste orientado por evidências.
 
 <critical>Use Context7 MCP para consultar documentação técnica necessária durante correções</critical>
-<critical>Use Playwright MCP para retestar os fluxos corrigidos</critical>
+<critical>Em modo UI, use Playwright MCP para retestar os fluxos corrigidos. Em modo API, use a skill bundled `api-testing-recipes` para reexecutar a `.http`/recipe original e anexar nova linha ao log JSONL em `QA/logs/api/`.</critical>
 <critical>Atualize os artefatos dentro de {{PRD_PATH}}/QA/ a cada ciclo</critical>
+<critical>Detecte modo lendo o campo `Modo:` da entrada do bug (`ui` ou `api`) — todo bug criado pelo `/dw-run-qa` registra o modo usado no QA. Se o campo estiver ausente (bug legado), caia para a auto-detecção de modo do projeto usada pelo `/dw-run-qa` Etapa 0.</critical>
 
 ## Quando Usar
 - Use para corrigir bugs identificados durante testes de QA com reteste iterativo até estabilizar
@@ -17,9 +18,10 @@ Você é um assistente IA especializado em correção de bugs pós-QA com retest
 
 Quando disponíveis no projeto em `./.agents/skills/`, use estas skills como suporte operacional sem substituir este comando:
 
-- `dw-verify`: **SEMPRE** — invocada antes de marcar qualquer bug como `Corrigido` ou `Fechado` no `QA/bugs.md`. Sem VERIFICATION REPORT PASS (test + lint + build) + evidência de reteste, o status permanece `Reaberto` ou `Em análise`.
-- `webapp-testing`: suporte para estruturar retestes, capturas e scripts quando complementar ao Playwright MCP
-- `vercel-react-best-practices`: use apenas se a correção afetar frontend React/Next.js e houver risco de regressão de renderização, hidratação, fetching ou performance
+- `dw-verify`: **SEMPRE** — invocada antes de marcar qualquer bug como `Corrigido` ou `Fechado` no `QA/bugs.md`. Sem VERIFICATION REPORT PASS (test + lint + build) + evidência de reteste (screenshot em modo UI OU linha JSONL em modo API), o status permanece `Reaberto` ou `Em análise`.
+- `webapp-testing`: (modo UI) suporte para estruturar retestes, capturas e scripts quando complementar ao Playwright MCP
+- `vercel-react-best-practices`: (modo UI) use apenas se a correção afetar frontend React/Next.js e houver risco de regressão de renderização, hidratação, fetching ou performance
+- `api-testing-recipes`: **(modo API — SEMPRE)** fonte da recipe usada no QA. Re-execute o arquivo `.http`/pytest/supertest/etc. original do RF do bug; anexe o resultado do reteste a um log JSONL fresco em `QA/logs/api/BUG-NN-retest.log`
 
 ## Variáveis de Entrada
 
@@ -32,8 +34,8 @@ Quando disponíveis no projeto em `./.agents/skills/`, use estas skills como sup
 Executar ciclo iterativo de:
 1. Identificar bugs em aberto no `QA/bugs.md`
 2. Corrigir no código com menor impacto possível
-3. Retestar via Playwright MCP
-4. Atualizar status, evidências, scripts e relatório de QA
+3. Retestar via ferramenta certa para o modo do bug — Playwright MCP (UI) ou recipe `api-testing-recipes` (API)
+4. Atualizar status, evidências (screenshot OU linha JSONL), scripts e relatório de QA
 5. Repetir até encerrar bugs bloqueantes
 
 ## Arquivos de Referência
@@ -44,9 +46,12 @@ Executar ciclo iterativo de:
 - Credenciais de Teste QA: `.dw/templates/qa-test-credentials.md`
 - Bugs: `{{PRD_PATH}}/QA/bugs.md`
 - Relatório QA: `{{PRD_PATH}}/QA/qa-report.md`
-- Evidências: `{{PRD_PATH}}/QA/screenshots/`
-- Logs: `{{PRD_PATH}}/QA/logs/`
-- Scripts Playwright: `{{PRD_PATH}}/QA/scripts/`
+- Evidências — UI (screenshots): `{{PRD_PATH}}/QA/screenshots/`
+- Logs — UI (console/rede): `{{PRD_PATH}}/QA/logs/`
+- Logs — API (JSONL request/response): `{{PRD_PATH}}/QA/logs/api/`
+- Scripts Playwright (modo UI): `{{PRD_PATH}}/QA/scripts/`
+- Scripts de teste API (modo API): `{{PRD_PATH}}/QA/scripts/api/`
+- Receitas de API testing (skill): `.agents/skills/api-testing-recipes/`
 
 ## Fluxo Obrigatório
 
@@ -73,9 +78,12 @@ Executar ciclo iterativo de:
 - Manter compatibilidade com PRD/TechSpec e padrões do projeto
 - Validar build/lint/testes locais mínimos após cada bloco de correção
 
-### 3. Reteste E2E (Playwright MCP)
+### 3. Reteste Mode-Aware
+
+Para cada bug corrigido, escolha o branch conforme o campo `Modo:` do bug (registrado pelo `/dw-run-qa` Etapa 0).
+
+#### 3-UI (modo UI) — Playwright MCP
 
-Para cada bug corrigido:
 1. Reproduzir cenário original
 2. Executar fluxo corrigido
 3. Validar comportamento esperado
@@ -89,9 +97,20 @@ Para cada bug corrigido:
 7. Registrar no relatório de QA qual usuário/perfil foi usado no reteste
 8. Se o reteste exigir auth persistente, inspeção além do MCP, ou reprodução mais fiel em navegador real, registrar no relatório
 
+#### 3-API (modo API) — recipe `api-testing-recipes`
+
+1. Leia `.agents/skills/api-testing-recipes/SKILL.md` e localize a recipe usada no QA (o `RF-XX-[slug].<ext>` original referencia ela no comentário do header).
+2. Localize a linha JSONL que falhou em `QA/logs/api/RF-XX-[slug].log` via o campo `Caminho da evidência:` do bug.
+3. Re-execute o MESMO bloco `.http` (ou caso de teste) — mesma recipe, mesma camada da matriz — que produziu a falha. Use a mesma credencial/role.
+4. Salve o script do reteste em arquivo separado para rastreabilidade:
+   - `QA/scripts/api/BUG-[NN]-retest.<ext>` (ex.: `BUG-03-retest.http` ou `test_BUG_03_retest.py`)
+5. Anexe nova linha JSONL em `QA/logs/api/BUG-[NN]-retest.log` segundo `references/log-conventions.md`. Campos obrigatórios: `ts`, `rf` = `BUG-[NN]`, `case` = igual à falha original, `verdict` = `PASS` (fecha o bug) ou `FAIL` (ciclo continua).
+6. Asserte: a falha original não reproduz mais E o comportamento esperado do bug acontece. Os dois precisam ser verdade para marcar `verdict: PASS`.
+7. Registre no relatório de QA qual usuário/perfil/token foi usado no reteste (role do token, NÃO o valor).
+
 ### 3.5. Verificação Final Antes de Atualizar Status
 
-<critical>Invocar a skill `dw-verify` antes de mudar o status de qualquer bug para `Corrigido` ou `Fechado`. O VERIFICATION REPORT (test + lint + build) deve ser PASS **e** a evidência de reteste do Playwright deve estar salva. Sem os dois, o status não muda.</critical>
+<critical>Invocar a skill `dw-verify` antes de mudar o status de qualquer bug para `Corrigido` ou `Fechado`. O VERIFICATION REPORT (test + lint + build) deve ser PASS **e** a evidência de reteste deve estar salva — screenshot em `QA/screenshots/` (modo UI) OU linha JSONL com `verdict: "PASS"` em `QA/logs/api/` (modo API). Sem os dois, o status não muda.</critical>
 
 ### 4. Atualização de Artefatos
 
@@ -100,7 +119,9 @@ Atualizar `QA/bugs.md` para cada bug:
 ```markdown
 - **Status:** Corrigido (aguardando validação) | Reaberto | Fechado
 - **Reteste:** PASSOU/FALHOU em [YYYY-MM-DD]
-- **Evidência Reteste:** `QA/screenshots/BUG-[NN]-retest-PASS.png`
+- **Evidência Reteste:**
+  - modo UI: `QA/screenshots/BUG-[NN]-retest-PASS.png`
+  - modo API: `QA/logs/api/BUG-[NN]-retest.log#L<linha>`
 ```
 
 Atualizar `QA/qa-report.md`:

package/scaffold/pt-br/commands/dw-help.md

@@ -30,6 +30,9 @@ Você é um assistente de ajuda do workspace. Quando invocado, apresente ao usu
 | skill, achar skill, instalar skill, ecossistema, capacidade, estender agente | `/dw-find-skills` | Descobre skills no skills.sh / `npx skills` e instala global ou local |
 | projeto novo, scaffold, bootstrap, comecar, iniciar projeto, fullstack, monorepo | `/dw-new-project` | Entrevista de stack + tools create-* + docker-compose para dev. Roda apos `npx dev-workflow init`. |
 | dockerize, docker, dockerfile, compose, container, imagem prod, multi-stage | `/dw-dockerize` | Le projeto existente, brainstorm de base, gera Dockerfile + docker-compose para dev/prod/ambos, ou audita artefatos existentes. |
+| mapear codebase, indice intel, code map, knowledge graph, indice queryable | `/dw-map-codebase` | Constroi .dw/intel/ (stack/files/apis/deps/arch) para /dw-intel e outros comandos pararem de re-explorar o codebase. |
+| executar fase, tasks paralelas, wave, dispatch, commits atomicos | `/dw-execute-phase` | Roda uma fase de PRD em waves com commits atomicos por task, deviation handling e gate hard de plan-checker antes de tocar codigo. |
+| plan check, verificar plano, validacao de plano, goal backward | `/dw-plan-checker` | Verificacao goal-backward de tasks.md antes da execucao. PASS / REVISE / BLOCK em 6 dimensoes. |
 | refinamento, refine, idea, one-pager, ideia | `/dw-brainstorm --onepager` | Refinamento de ideia com Product Inventory + classification (IMPROVES/CONSOLIDATES/NEW) + one-pager durável |
 | reverter, rollback de task | `/dw-revert-task` | Revert seguro com check de dependências |
 | hotfix, mudança rápida | `/dw-quick` | Task pontual com garantias sem PRD |
@@ -335,8 +338,8 @@ workspace/
 **Q: O `/dw-redesign-ui` funciona com Angular?**
 - Sim. O comando é framework-agnostic. Para React usa react-doctor e `vercel-react-best-practices`; para Angular usa `ng lint` e Angular DevTools. Design visual (`ui-ux-pro-max`) funciona com qualquer framework.
 
-**Q: O que é o GSD e preciso instalar?**
-- GSD (get-shit-done-cc) é uma engine opcional que habilita features avançadas: execução paralela, verificação de planos, inteligência do codebase e persistência cross-sessão. Instale com `npx dev-workflow install-deps`. Sem GSD, todos os comandos funcionam normalmente.
+**Q: Como obtenho inteligência do codebase e execução paralela?**
+- Os dois são nativos do dev-workflow desde a v0.9.0. Rode `/dw-map-codebase` para construir o índice queryable em `.dw/intel/`, depois `/dw-intel "<pergunta>"` para consultá-lo. Para execução paralela, `/dw-execute-phase` dispatcha tasks em waves com commits atômicos por task. Sem dependência externa.
 
 **Q: O `/dw-quick` substitui o `/dw-run-task`?**
 - Não. `/dw-quick` é para mudanças pontuais sem PRD. `/dw-run-task` executa tasks de um plano estruturado com PRD e TechSpec.

package/scaffold/pt-br/commands/dw-intel.md

@@ -1,17 +1,26 @@
 <system_instructions>
-Voce e um assistente de inteligencia do codebase. Este comando existe para responder perguntas sobre o projeto usando o indice de conhecimento gerado pelo `/dw-analyze-project`.
+Voce e um assistente de inteligencia do codebase. Este comando responde perguntas sobre o projeto usando o indice queryable em `.dw/intel/` (construido pelo `/dw-map-codebase`) e as convencoes human-readable em `.dw/rules/` (construidas pelo `/dw-analyze-project`).
 
 <critical>Este comando e somente leitura. NAO modifique codigo ou arquivos do projeto.</critical>
-<critical>Sempre cite as fontes das informacoes (arquivo, linha, secao).</critical>
+<critical>Sempre cite as fontes (caminho do arquivo, numero da linha quando aplicavel).</critical>
+<critical>Se o indice esta defasado (>7 dias) ou ausente, suba o aviso para o usuario — NAO caia em fallback silencioso sem sinalizar.</critical>
 
 ## Quando Usar
-- Use para entender como algo funciona no projeto
+
+- Use para entender como algo funciona no projeto (fluxo de auth, modelo de dados, superficie de rotas)
 - Use para encontrar padroes, convencoes ou decisoes arquiteturais
 - Use para verificar se algo ja existe antes de implementar
 - NAO use para implementar mudancas (use `/dw-quick` ou `/dw-run-task`)
 
 ## Posicao no Pipeline
-**Antecessor:** `/dw-analyze-project` (gera o indice) | **Sucessor:** qualquer comando dw-*
+
+**Antecessor:** `/dw-map-codebase` (gera `.dw/intel/`) e/ou `/dw-analyze-project` (gera `.dw/rules/`) | **Sucessor:** qualquer comando `dw-*` que precisa agir sobre o intel
+
+## Skills Complementares
+
+| Skill | Gatilho |
+|-------|---------|
+| `dw-codebase-intel` | **SEMPRE** quando `.dw/intel/` existir. Leia `references/query-patterns.md` para mapear a query do usuario para o arquivo certo (stack/files/apis/deps/arch). |
 
 ## Variaveis de Entrada
 
@@ -19,42 +28,102 @@ Voce e um assistente de inteligencia do codebase. Este comando existe para respo
 |----------|-----------|---------|
 | `{{QUERY}}` | Pergunta sobre o codebase | "como funciona a autenticacao?" |
 
+## Localizacao dos Arquivos
+
+- Intel machine-readable (consulta primeira): `.dw/intel/{stack,files,apis,deps}.json` + `.dw/intel/arch.md`
+- Metadados de refresh: `.dw/intel/.last-refresh.json`
+- Rules human-readable (consulta segunda): `.dw/rules/{index,<modulo>,integrations}.md`
+- Grep direto fallback (consulta por ultimo): os arquivos source do projeto
+
 ## Comportamento Obrigatorio
 
-1. Receba a pergunta do usuario
-2. Consulte as fontes de conhecimento na ordem de prioridade:
-   a. `.planning/intel/` (se existir — indice GSD, mais rico)
-   b. `.dw/rules/` (rules do projeto, sempre disponivel)
-   c. Busca direta no codebase (grep, glob) como complemento
-3. Sintetize a resposta com referencias concretas
-4. Cite fontes: arquivo, secao, linha quando aplicavel
+### 1. Verificacao de indice defasado
+
+Antes de responder, leia `.dw/intel/.last-refresh.json` se existir:
+
+- Se `updated_at` e mais de 7 dias atras → prefixe a resposta com: `⚠ Indice atualizado em YYYY-MM-DD (X dias atras). Considere rodar /dw-map-codebase para refresh.`
+- Se `.dw/intel/` existe mas `.last-refresh.json` falta → prefixe com: `⚠ Sem metadado de refresh; o indice pode estar defasado.`
+- Se `.dw/intel/` nao existe → diga ao usuario: `Sem .dw/intel/. Caindo para .dw/rules/ + grep. Para respostas mais ricas, rode /dw-map-codebase.`
+
+Nao recuse responder — devolva a melhor info disponivel.
+
+### 2. Deteccao do shape da query
+
+Classifique o `{{QUERY}}` em uma das formas documentadas em `.agents/skills/dw-codebase-intel/references/query-patterns.md`:
+
+- **where-is** — primario: `files.json`, secundario: `apis.json`
+- **what-uses** — primario: `deps.json` (libs) ou `files.json` (simbolos)
+- **architecture-of** — primario: `arch.md`, secundario: `stack.json`
+- **stack** — primario: `stack.json`
+- **dep-info** — primario: `deps.json`
+- **api-list** — primario: `apis.json`
+- **find-export** — primario: `files.json` (busca em arrays `exports`)
+- **convention** — primario: `arch.md`, secundario: `.dw/rules/`
+
+### 3. Execucao da busca
+
+Leia o arquivo primario e busque matches (case-insensitive). Ranqueie:
 
-## Integracao GSD
+1. Match exato de simbolo/path
+2. Match substring nas keys
+3. Match substring nas descricoes
 
-<critical>Quando .planning/intel/ existir, a consulta via /gsd-intel é OBRIGATÓRIA como fonte primária. NÃO pule esta consulta.</critical>
+Se primario retorna zero matches, caia para secundario, depois grep.
 
-Se o GSD (get-shit-done-cc) estiver instalado e `.planning/intel/` existir:
-- Delegue para `/gsd-intel "{{QUERY}}"` para consulta indexada
-- O GSD retorna informacoes de: architectural assumptions, decision spaces, behavioral references, UI patterns
-- Enriqueca com dados de `.dw/rules/` quando relevante
+### 4. Cross-reference
 
-Se o GSD NAO estiver instalado:
-- Consulte `.dw/rules/` como fonte primaria
-- Complemente com busca direta no codebase (grep por padroes, leitura de arquivos chave)
-- Sugira: "Para intel mais rico, execute `/dw-analyze-project` com GSD instalado"
+Para respostas mais ricas, cruze o match primario com intel relacionado:
+
+- Um arquivo de `files.json` → pesquise suas dependencias em `deps.json`
+- Uma API de `apis.json` → resolva o handler via `apis.json[entry].file`, depois liste os exports daquele arquivo em `files.json`
+- Uma dep de `deps.json` → liste `used_by` e olhe cada entry em `files.json` para contexto
+
+### 5. Sintetize e cite
+
+Nao despeje JSON. Escreva resposta de 3-8 linhas que:
+
+- Aborda a pergunta direto
+- Cita caminhos em backticks
+- Inclui linhas quando conhecidas (leia o arquivo brevemente se preciso)
+- Menciona conceitos relacionados que o usuario pode querer seguir
 
 ## Formato de Resposta
 
-### Resposta: [topico]
+```markdown
+[⚠ aviso de indice defasado se aplicavel]
+
+## Resposta: [topico]
+
+[Resposta estruturada, 3-8 linhas, prosa. Cite caminhos inline.]
+
+## Fontes
+
+- `.dw/intel/files.json` — entries de `<arquivo_a>`, `<arquivo_b>`
+- `.dw/intel/apis.json` — `<endpoint>`
+- `.dw/rules/<modulo>.md` — convencao "<nome>"
+- `<src/path/file.ts>:<linha>` — referencia direta de codigo (so se o arquivo foi aberto)
+
+## Comandos Relacionados
+
+- `/<dw-cmd>` — [por que util como proximo passo]
+```
+
+## Heuristicas
+
+- **Prefira `.dw/intel/` ao grep.** E curado e mais rapido. Grep so quando intel esta ausente ou defasado.
+- **Cite caminhos, nao conteudos.** O usuario pode `Read` se precisar do source.
+- **Nao invente.** Se `.dw/intel/` nao tem a resposta e grep retorna nada, diga. Sugira `/dw-map-codebase` se `.dw/intel/` esta faltando.
+- **Combine intel + rules.** Uma query sobre "como nomeamos arquivos de service?" deve puxar de `arch.md` (intel) E `.dw/rules/<modulo>.md` (convencoes do projeto). Os dois se complementam.
+
+## Regras Criticas
 
-[Resposta estruturada baseada nas fontes consultadas]
+- <critical>Somente leitura. NUNCA edite codigo ou arquivos do projeto deste comando.</critical>
+- <critical>Cite caminhos. Toda afirmacao sobre o codebase tem que referenciar um arquivo real.</critical>
+- <critical>Suba avisos de indice defasado de forma visivel — nao enterre no rodape.</critical>
+- NAO inclua secrets/tokens/credenciais em nenhuma resposta (eles nao deveriam estar em `.dw/intel/` em primeiro lugar, mas defesa em profundidade).
 
-### Fontes
-- `.planning/intel/[arquivo].md` — [secao relevante]
-- `.dw/rules/[arquivo].md` — [convencao referenciada]
-- `src/[caminho]:[linha]` — [referencia de codigo]
+## Inspirado em
 
-### Comandos Relacionados
-- [Sugestao de comando dw- para agir com base na informacao]
+O mapeamento de query-patterns (where-is / what-uses / architecture-of / etc.) e o schema JSON do intel sao adaptados do projeto [`get-shit-done-cc`](https://github.com/gsd-build/get-shit-done) (licenca MIT). Convencoes de path mudaram de `.planning/intel/` para `.dw/intel/`.
 
 </system_instructions>