@brunosps00/dev-workflow 0.8.1 → 0.10.0

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`)
+- NAO use para implementar mudancas (use `/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>

package/scaffold/pt-br/commands/dw-map-codebase.md

@@ -0,0 +1,125 @@
+<system_instructions>
+Voce e um orquestrador de inteligencia de codebase. Sua funcao e spawnar o agente `dw-intel-updater` (da skill bundled `dw-codebase-intel`) para ler os arquivos source do projeto e escrever um indice queryable em `.dw/intel/`. Outros comandos do dev-workflow (`/dw-intel`, `/dw-create-prd`, `/dw-create-techspec`, `/dw-code-review`, etc.) leem esse indice em vez de fazer exploracao cara do codebase em cada invocacao.
+
+<critical>Este comando escreve so em `.dw/intel/`. Nunca modifica codigo da aplicacao.</critical>
+<critical>Use o agente `dw-intel-updater` — NAO inline a logica de geracao do intel neste comando. O agente possui o contrato do schema.</critical>
+
+## Quando Usar
+
+- **Primeira analise**: projeto fresco sem `.dw/intel/`. Roda full scan.
+- **Refresh incremental**: depois de uma branch / PR grande aterrissar e arquivos source mudaram. Roda com `--files <paths>` para atualizar so os entries afetados.
+- **Refresh agendado**: a cada 1-4 semanas para manter o indice fresco; a heuristica de defasagem em `/dw-intel` avisa quando >7 dias.
+- **Apos mudancas de dependencia**: `/dw-deps-audit --execute` atualiza lockfiles e pode tocar deps. Re-rode `/dw-map-codebase` depois para refrescar `deps.json`.
+- NAO use para projetos greenfield sem source ainda — `/dw-new-project` ja semeia `.dw/rules/index.md` minimo; nao tem o que mapear.
+
+## Posicao no Pipeline
+
+**Antecessor:** qualquer projeto com source (rode apos `/dw-new-project` para greenfield, ou como primeiro comando em repo brownfield) | **Sucessor:** `/dw-intel "<query>"` para perguntas ad-hoc, ou `/dw-analyze-project` para enriquecer `.dw/rules/` com convencoes/anti-patterns derivados do intel
+
+## Skills Complementares
+
+| Skill | Gatilho |
+|-------|---------|
+| `dw-codebase-intel` | **SEMPRE** — fonte do agente `dw-intel-updater` e dos references (`intel-format.md`, `incremental-update.md`, `query-patterns.md`) |
+
+## Variaveis de Entrada
+
+| Variavel | Descricao | Exemplo |
+|----------|-----------|---------|
+| `{{FOCUS}}` | Opcional. `full` (default sem `--files`), `partial` (quando `--files` setado) | `partial` |
+| `{{FILES}}` | Opcional. Lista space-separated de paths para refrescar (so com `--files`) | `src/auth/index.ts src/routes/auth.ts` |
+| `{{SINCE}}` | Opcional alternativo a `--files`. Git ref para derivar arquivos mudados | `HEAD~5` ou `origin/main` |
+
+## Flags
+
+| Flag | Comportamento |
+|------|---------------|
+| (default) | Full scan se `.dw/intel/` faltando OU `.last-refresh.json` >30 dias; senao pergunta full/skip |
+| `--full` | Forca full scan independente do estado |
+| `--files <a> <b> ...` | Update parcial so para os paths listados |
+| `--since <gitref>` | Update parcial para arquivos mudados desde `<gitref>` (usa `git diff --name-only <gitref>...HEAD`) |
+
+## Localizacao dos Arquivos
+
+- Indice de saida: `.dw/intel/{stack,files,apis,deps}.json` + `.dw/intel/arch.md`
+- Metadados de refresh: `.dw/intel/.last-refresh.json`
+- Fonte da skill: `.agents/skills/dw-codebase-intel/{SKILL.md, agents/intel-updater.md, references/*.md}`
+
+## Comportamento Obrigatorio
+
+### 1. Deteccao de estado
+
+- Cheque `.dw/intel/.last-refresh.json` se existir.
+- Compute estado: greenfield (sem source) → aborta com dica; brownfield sem `.dw/intel/` → primeira analise; com `.dw/intel/` existente → decida path de refresh.
+
+### 2. Selecao de modo
+
+| Condicao | Modo |
+|----------|------|
+| Sem `.dw/intel/` | full |
+| Flag `--full` | full |
+| Flag `--files <list>` | partial com lista explicita |
+| Flag `--since <ref>` | partial com lista derivada de `git diff --name-only <ref>...HEAD` |
+| `.last-refresh.json` >30 dias | prompt usuario: full / partial / skip |
+| Caso contrario | partial desde ultimo refresh, derivado de `git log --name-only --since=<last_refresh_date>` |
+
+### 3. Spawnar `dw-intel-updater`
+
+Construa o spawn prompt do agente. Campos obrigatorios:
+
+- `focus: full` ou `focus: partial --files <paths space-separated>`
+- `project_root: <path absoluto>`
+- Bloco `required_reading:` opcional listando SKILL.md e references (o agente le esses para contexto)
+
+Spawne o agente e aguarde conclusao.
+
+### 4. Verificar saida
+
+Apos o agente retornar:
+
+- Verifique `.dw/intel/{stack,files,apis,deps}.json` existem e parseiam como JSON valido.
+- Verifique `.dw/intel/arch.md` existe.
+- Verifique `.dw/intel/.last-refresh.json` foi escrito e os hashes batem com os arquivos recem-escritos.
+- Se algum falhar, reporte a falha com a saida do agente e aborte com status `MAP-FAILED`.
+
+### 5. Relatar
+
+Imprima resumo tight:
+
+```
+## Mapa do Codebase Refrescado
+
+Modo: full | partial (<N> arquivos)
+Arquivos escritos:
+- .dw/intel/stack.json     (<bytes>) — <N> linguagens, <N> frameworks
+- .dw/intel/files.json     (<bytes>) — <N> entries
+- .dw/intel/apis.json      (<bytes>) — <N> endpoints
+- .dw/intel/deps.json      (<bytes>) — <N> deps (<producao>/<dev>)
+- .dw/intel/arch.md        (<linhas>) — <nome do padrao>
+- .dw/intel/.last-refresh.json
+
+Proximos passos:
+- Consultar o indice:        /dw-intel "<pergunta>"
+- Construir rules legiveis:  /dw-analyze-project
+- Auditar deps:              /dw-deps-audit --scan-only
+```
+
+## Regras Criticas
+
+- <critical>O agente possui o schema. Se schema precisa mudar, atualize o arquivo do agente em `.agents/skills/dw-codebase-intel/` primeiro; este comando so orquestra.</critical>
+- <critical>NUNCA escreva `.dw/intel/` manualmente deste comando — sempre via o agente.</critical>
+- <critical>Escrita atomica: o agente escreve em `.tmp` e renomeia. Se write parcial, o indice anterior fica preservado.</critical>
+- NAO inclua secrets em saida nenhuma. A lista de forbidden-files do agente (`.env*`, `*.key`, `*.pem`, `id_rsa`, etc.) e enforced; se algo vazar, trate como bug CRITICAL.
+
+## Tratamento de Erros
+
+- Agente falha → print stdout/stderr, marca `.dw/intel/` como last-known-good (preservado por atomic write), exit nao-zero.
+- Sem source no escopo → aborta: `"Sem arquivos source detectados (TS/JS/Python/C#/Rust). Rode /dw-new-project primeiro ou cheque o project root."`
+- `git diff --since` falha (nao e git repo, ref ruim) → cai para full scan com aviso.
+- Arquivo source referenciado em `.dw/intel/` ja nao existe → o agente remove o entry no proximo update parcial.
+
+## Inspirado em
+
+`dw-map-codebase` e dev-workflow-native. O padrao de orquestracao (spawn agente, espera, verifica, relata) e as convencoes de escopo de arquivos sao adaptados de [`get-shit-done-cc`](https://github.com/gsd-build/get-shit-done) (`/gsd-map-codebase` + `gsd-intel-updater`) por gsd-build (MIT). Especificos do dev-workflow: escreve em `.dw/intel/` (nao `.planning/intel/`), usa agente unico (intel-updater) em vez de varios mappers paralelos (a analise human-readable vive separada em `/dw-analyze-project`), e integra com `--since <gitref>` para updates parciais git-aware.
+
+</system_instructions>

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

@@ -188,7 +188,7 @@ Adapte o `dev:db:migrate` por ORM (Prisma: `pnpm prisma migrate dev`; Alembic: `
 
 Por stack, anexe ao que `create-*` gerou:
 - `.gitignore` deve excluir `.env`.
-- Inclua `.dw/spec/`, `.planning/` se o usuario tambem usa GSD.
+- O diretorio `.dw/` e preservado entre updates pelo `/dw-update` (rules, spec, intel sao dados do usuario).
 - `.dockerignore`: exclua `.git`, `node_modules`, `.dw`, `.agents`, `tests`, `*.md` (em imagens prod).
 
 #### 3.7 Gerar GitHub Actions CI

package/scaffold/pt-br/commands/dw-redesign-ui.md

@@ -64,17 +64,13 @@ Utilize ferramentas de diagnóstico conforme o framework do projeto:
 7. **VALIDAR**: capture estado depois em AMBAS as resoluções (mobile e desktop), compare antes/depois, verifique acessibilidade (WCAG 2.2 via `ui-ux-pro-max`), rode react-doctor `--diff` se React. Se `webapp-testing` disponível, capture screenshots em viewport 375px (mobile) e 1440px (desktop).
 8. **PERSISTIR CONTRATO**: se o usuário aprovou uma direção, gere `design-contract.md` no diretório do PRD (`.dw/spec/prd-[nome]/design-contract.md`) com: direção aprovada, paleta de cores, par tipográfico, regras de layout, regras de acessibilidade e regras de componentes. Este contrato será lido por `dw-run-task` e `dw-run-plan` para garantir consistência visual.
 
-## Integração GSD
+## Inteligência do Codebase
 
-<critical>Quando o GSD estiver instalado, o registro do design contract em .planning/ e a consulta de .planning/intel/ são OBRIGATÓRIOS.</critical>
+<critical>Se `.dw/intel/` existir, a consulta via `/dw-intel` é OBRIGATÓRIA na fase de auditoria para identificar UI patterns existentes.</critical>
 
-Se o GSD (get-shit-done-cc) estiver instalado no projeto:
-- Após gerar o design contract, registre em `.planning/` para persistência cross-sessão
-- Consulte `.planning/intel/` na fase de auditoria para UI patterns existentes
-
-Se o GSD NÃO estiver instalado:
-- O design contract funciona normalmente (file-based em `.dw/spec/`)
-- Auditoria usa apenas `.dw/rules/` para contexto
+- Fase de auditoria: execute internamente `/dw-intel "componentes UI, padrões de design, convenções de layout"` antes de propor direções de redesign
+- O design contract (`.dw/spec/prd-[nome]/design-contract.md`) é a fonte única de verdade para consistência visual — lido por `/dw-run-task` e `/dw-run-plan` e persiste cross-sessão naturalmente (sem registro separado)
+- Se `.dw/intel/` NÃO existir, caia para `.dw/rules/` e grep direto sobre `apps/web/src/` (ou frontend root equivalente)
 
 ## Formato de Resposta Preferido
 

package/scaffold/pt-br/commands/dw-refactoring-analysis.md

@@ -21,8 +21,9 @@ Pré-requisito: Execute `/dw-analyze-project` primeiro para entender padrões e
 Quando disponíveis no projeto em `./.agents/skills/`, use como suporte analítico sem substituir este comando:
 
 - `dw-review-rigor`: **SEMPRE** — ao catalogar code smells, aplicar de-duplication (mesmo smell em N arquivos = 1 entrada com affected list), severity ordering nos P0-P3, signal-over-volume (máx ~20 findings; manter críticos, podar marginais). Smell com ADR justificatório baixa para `low` no máximo.
+- `dw-simplification`: **SEMPRE** — todo smell flagueado passa pelo filtro Chesterton's Fence (o que o construto FAZ, por que foi adicionado, o que quebra se removido). Smells sem resposta clara para "por que isso está aqui" caem para `info` com nota de investigação, em vez de virarem proposta de refactor. Métricas de complexidade fundamentam severidade (complexidade cognitiva ≥16 ou nesting depth ≥4 = candidato `high`; <10 = `low` no máximo).
 - `security-review`: delegue preocupações de segurança para este skill — não duplique
-- `vercel-react-best-practices`: delegue padrões de performance React/Next.js para este skill
+- `vercel-react-best-practices`: delegue padrões de performance React/Next.js para este skill — ao sinalizar smells de perf, siga `references/perf-discipline.md` (measure → identify → fix → verify → guard) e cite a métrica + ferramenta, não vibes
 
 ## Ferramentas de Análise
 
@@ -31,13 +32,14 @@ Para projetos Angular, use `ng lint` como complemento analítico.
 
 ## 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 "tech debt, decision spaces e dívida técnica conhecida"`
-- Contextualize findings com decisões já documentadas
+<critical>Se `.dw/intel/` existir, a consulta via `/dw-intel` é OBRIGATÓRIA antes de sinalizar oportunidades de refactoring. NÃO pule este passo.</critical>
+- Execute internamente: `/dw-intel "tech debt e decisões técnicas conhecidas"`
+- Contextualize findings com decisões já documentadas em `.dw/rules/`
 - Evite sinalizar como smell algo que é uma decisão intencional registrada
 
-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
 
 ## Variáveis de Entrada
 

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

@@ -313,6 +313,25 @@
 
     <critical>NÃO APROVE requisitos sem evidência concreta no código</critical>
     <critical>ANALISE o código real, não confie apenas nos checkboxes do tasks.md</critical>
-    <critical>Se 100% dos requisitos foram implementados e NÃO há gaps: NÃO entre em plan mode, NÃO crie tasks. Apenas apresente o relatório e ENCERRE.</critical>
-    <critical>Se gaps forem encontrados, entre no loop de fix-review automaticamente. NÃO aguarde instruções do usuário para corrigir gaps. Máximo de 3 ciclos antes de marcar como BLOCKED.</critical>
+    <critical>Se 100% dos requisitos foram implementados e NÃO há gaps: NÃO entre em plan mode, NÃO crie tasks. Apresente o relatório Level 2 e siga para Level 3 (próxima seção).</critical>
+    <critical>Se gaps forem encontrados, entre no loop de fix-review automaticamente. NÃO aguarde instruções do usuário para corrigir gaps. Máximo de 3 ciclos antes de marcar como BLOCKED. Level 3 só roda após o loop chegar em APPROVED no Level 2.</critical>
+
+## Level 3 — Camada de Qualidade (auto-invocada no fim)
+
+Após Level 2 (cobertura do PRD) chegar em APPROVED, **invoque automaticamente `/dw-code-review`** para adicionar a camada formal de qualidade (best practices, SOLID, DRY, complexity, security, convenções). Resolve a expectativa do usuário de que um review único cubra tanto "entregamos tudo?" (Level 2) quanto "o que entregamos está bem feito?" (Level 3).
+
+Pipeline:
+
+1. Após Level 2 APPROVED, rode `/dw-code-review {{PRD_PATH}}` com o mesmo escopo de PRD.
+2. Aguarde `/dw-code-review` produzir veredito (APPROVED / APPROVED WITH CAVEATS / REJECTED).
+3. Escreva resumo consolidado em `{{PRD_PATH}}/QA/review-consolidated.md` referenciando ambos.
+4. Status final combina os dois vereditos:
+   - Level 2 APPROVED + Level 3 APPROVED → consolidado APPROVED
+   - Level 2 APPROVED + Level 3 APPROVED WITH CAVEATS → consolidado APPROVED WITH CAVEATS
+   - Level 2 APPROVED + Level 3 REJECTED → consolidado REJECTED (Level 3 vence)
+
+### Flag para pular Level 3
+
+`/dw-review-implementation --no-code-review` pula Level 3 e emite só Level 2.
+
 </system_instructions>

package/scaffold/pt-br/commands/dw-run-plan.md

@@ -152,36 +152,30 @@ Se uma tarefa FALHAR durante a execução:
 4. Aguardar intervenção manual do usuário
 5. **NÃO** continuar automaticamente para próxima task
 
-## Integração GSD
+## Verificação de Plano + Execução Paralela
 
-<critical>Quando o GSD estiver instalado, a verificação de plano e a execução paralela são OBRIGATÓRIAS, não opcionais. O comando NÃO pode pular estes passos.</critical>
+<critical>Verificação de plano e execução paralela em waves são OBRIGATÓRIAS, não opcionais. Ambas são agora nativas no dev-workflow via skill bundled `dw-execute-phase`.</critical>
 
 ### Verificação de Plano (Pré-Execução)
 
-Se o GSD (get-shit-done-cc) estiver instalado no projeto:
-- Antes de iniciar a execução, delegue para o agente plan-checker do GSD
-- O verificador analisa: dependências cíclicas, viabilidade das tasks, riscos, cobertura dos requisitos do PRD
-- Se FALHAR: apresente os problemas encontrados e sugira correções. Máximo 3 ciclos de correção
-- Se PASSAR: prossiga para a execução
-
-Se o GSD NÃO estiver instalado:
-- Pule a verificação e execute diretamente (comportamento atual)
+Antes de iniciar execução, spawne o **agente plan-checker** de `.agents/skills/dw-execute-phase/agents/plan-checker.md`:
+- O agente plan-checker verifica as 6 dimensões (cobertura de requisitos, completude da task, soundness de dependência, wiring de artefatos, budget de contexto, compliance de constraints)
+- Se REVISE: apresente os issues e sugira correções. Máximo 3 ciclos via `/dw-create-tasks --revise`
+- Se BLOCK: suba o conflito para o usuário, NÃO auto-replan
+- Se PASS: prossiga para execução
 
 ### Execução Paralela (Wave-Based)
 
-Se o GSD (get-shit-done-cc) estiver instalado no projeto:
-- Analise o campo `blockedBy` de cada task para montar o grafo de dependências
-- Agrupe tasks em waves:
-  - Wave 1: tasks sem dependências (podem executar em paralelo)
-  - Wave 2: tasks que dependem de tasks da Wave 1
+Após PASS do plan-checker, spawne o **agente executor** de `.agents/skills/dw-execute-phase/agents/executor.md`:
+- O agente executor analisa o campo `Depends on:` de cada task para montar o grafo de dependências
+- Agrupa tasks em waves:
+  - Wave 1: tasks sem dependências (rodam em paralelo)
+  - Wave 2: tasks que dependem das tasks da Wave 1
   - Wave N: assim por diante
-- Delegue cada wave para o engine de execução paralela do GSD (`/gsd-execute-phase`)
-- Cada task executa em worktree isolado com contexto fresh
-- Resultados são mergeados após a wave completar
-- Se qualquer task de uma wave falhar: pause a wave, reporte, aguarde decisão do usuário
-
-Se o GSD NÃO estiver instalado:
-- Execute sequencialmente como hoje (comportamento atual)
+- Cada wave dispatcha subagentes em paralelo (um por task)
+- Resultados mergeados após a wave completar
+- Se qualquer task em uma wave falha permanentemente (deviation Rule 3): pausa a wave, reporta, aguarda decisão do usuário
+- O executor commita atomicamente por task e escreve `SUMMARY.md` após a wave final
 
 ### Design Contracts
 

package/scaffold/pt-br/commands/dw-run-task.md

@@ -25,15 +25,16 @@ Quando disponíveis no projeto em `./.agents/skills/`, use estas skills como sup
 
 ## 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 de implementação em [área alvo da task]"`
+<critical>Se `.dw/intel/` existir, a consulta via `/dw-intel` é OBRIGATÓRIA antes de codar. NÃO pule este passo.</critical>
+- Execute internamente: `/dw-intel "padrões de implementação em [área alvo da task]"`
 - Siga convenções encontradas para estrutura de arquivos, nomenclatura e tratamento de erros
 
 Se `design-contract.md` existir no diretório do PRD:
 - Leia o contrato e garanta que toda implementação frontend siga as regras de design aprovadas
 
-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 direto se necessário
+- Sugira rodar `/dw-map-codebase` após a task para enriquecer contexto downstream
 
 ## Localização dos Arquivos
 

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

@@ -79,7 +79,9 @@ npx -y @brunosps00/dev-workflow@latest update --lang=$DETECTED_LANG
 O comando `update` sobrescreve arquivos gerenciados e PRESERVA:
 - `.dw/rules/` (rules do usuário)
 - `.dw/spec/` (PRDs e tasks em andamento)
-- `.planning/` (dados do usuário)
+- `.dw/intel/` (índice de codebase do `/dw-map-codebase`)
+
+O comando `update` também roda o passo de migração GSD automaticamente — se o projeto tem `.planning/` legado (de uso prévio do GSD), o conteúdo é migrado para `.dw/intel/`, `.dw/spec/active-session.md`, `.dw/spec/quick/`, etc., e `.planning/` é renomeado para `.planning.gsd-archive-<DATA>/` para inspeção. Os arquivos `.claude/commands/gsd/`, `.claude/agents/gsd-*.md`, `.claude/hooks/gsd-*.js` e `.claude/gsd-file-manifest.json` são removidos durante a migração.
 
 Se o update falhar (erro de rede, permissão, pacote indisponível): reporte o erro ao usuário e PARE. NÃO tente workarounds manuais como copiar arquivos.
 

package/scaffold/pt-br/templates/idea-onepager.md

@@ -22,7 +22,7 @@ Foque no problema, não na solução. Evite entrar em "como implementar".]
 Fontes:
 - PRDs em `.dw/spec/prd-*/prd.md` (features já entregues ou em desenvolvimento)
 - `.dw/rules/index.md` (overview do produto)
-- `.planning/intel/` se GSD estiver instalado
+- `.dw/intel/` (indice queryable — construido por `/dw-map-codebase`, consultado via `/dw-intel`)
 
 Formato:]
 
@@ -86,5 +86,5 @@ Idealmente 2-4 stories. Se são mais de 5, provavelmente não é MVP.]
 Escolha UM:
 
 - **`/dw-create-prd`** com este one-pager como input — quando a direção está clara mas precisamos detalhar user stories, acceptance criteria e passar ao techspec
-- **`/dw-quick`** — quando é um IMPROVES tão pequeno que cabe em task única (até 3 arquivos, sem novo endpoint/tela)
+- **`/dw-run-task`** — quando é um IMPROVES tão pequeno que cabe em task única (até 3 arquivos, sem novo endpoint/tela) — escreva um PRD curto antes
 - **Parar aqui** — se alguma "Open Question" é bloqueante, parar e resolver com stakeholder antes de avançar

package/scaffold/skills/dw-codebase-intel/SKILL.md

@@ -0,0 +1,102 @@
+---
+name: dw-codebase-intel
+description: Codebase intelligence for dev-workflow. The intel-updater agent maintains a queryable index in .dw/intel/ (stack.json, files.json, apis.json, deps.json, arch.md) that other commands read instead of doing expensive codebase exploration. Used by /dw-intel and /dw-map-codebase. Adapted from get-shit-done-cc (MIT).
+allowed-tools:
+  - Read
+  - Write
+  - Bash
+  - Glob
+  - Grep
+---
+
+# dw-codebase-intel
+
+Bundled skill that gives dev-workflow native **codebase intelligence** — a queryable knowledge base of the project's stack, file graph, API surface, dependencies, and architecture. Other commands (`/dw-create-prd`, `/dw-create-techspec`, `/dw-code-review`, `/dw-refactoring-analysis`, `/dw-brainstorm`, etc.) read from this index instead of re-exploring the codebase on every invocation.
+
+## Why a skill (not inline)
+
+- Each agent is independently maintainable and reusable.
+- The format of `.dw/intel/` is a contract that downstream commands depend on; codifying it in references makes drift visible.
+- Other commands invoke these agents through the skill, not by duplicating the logic.
+
+## When to Use
+
+Read this skill when:
+
+- `/dw-map-codebase` is invoked (full or partial codebase analysis).
+- `/dw-intel "<query>"` is invoked (query existing intel).
+- `/dw-analyze-project` runs after first commit and wants to enrich `.dw/rules/` with structural facts from `.dw/intel/`.
+- Any other `dw-*` command wants to look up "where is X used", "what frameworks are in this stack", "what's the architecture pattern" without re-scanning files.
+
+Do NOT use when:
+
+- The user is asking a runtime question (use logs / running app).
+- The intel is fresh (`.dw/intel/.last-refresh.json` is current and the user did not ask for a refresh).
+- The project is greenfield with no source files yet — in that case, fall back to `.dw/rules/` seeded by `/dw-new-project`.
+
+## Files in `.dw/intel/`
+
+The intel directory is the contract. Every file is machine-parseable and references real file paths.
+
+| File | Purpose | Format |
+|------|---------|--------|
+| `stack.json` | Languages, frameworks, build/test tooling, package manager | JSON |
+| `files.json` | File graph: per-file imports/exports/type | JSON |
+| `apis.json` | API surface: routes, methods, params, source file | JSON |
+| `deps.json` | Dependencies: version, type, used_by, invocation | JSON |
+| `arch.md` | Human-readable architecture overview + key components + data flow | Markdown |
+| `.last-refresh.json` | Timestamps + content hashes for incremental detection | JSON |
+
+Schemas are documented in `references/intel-format.md`.
+
+## Agents
+
+| Agent | Responsibility | Spawn from |
+|-------|----------------|------------|
+| `agents/intel-updater.md` | Reads source files, writes structured intel to `.dw/intel/`. Supports `full` or `partial --files <paths>` updates. | `/dw-map-codebase` |
+
+This skill ships ONE agent — `intel-updater` — which produces machine-readable JSON for `/dw-intel` queries. Human-readable architecture analysis (per-module conventions, anti-patterns, code smells) lives in `.dw/rules/` and is generated by `/dw-analyze-project`. The two are complementary: `.dw/intel/` answers "what's in this codebase right now?" and `.dw/rules/` answers "how should we write code here?".
+
+## How to Compose (the typical flow)
+
+1. **`/dw-map-codebase`** is invoked.
+2. The command spawns `intel-updater` with `focus: full` (first run) or `focus: partial --files <paths>` (incremental).
+3. The agent reads source files (using Glob/Read/Grep; no Bash file listing for cross-platform safety) and writes the 5 intel files.
+4. The agent writes `.last-refresh.json` with timestamps + hashes for incremental change detection on the next run.
+5. `/dw-map-codebase` reports completion and invites the user to query via `/dw-intel "<question>"`.
+
+For human-readable analysis (architecture overview, module conventions, anti-patterns), run `/dw-analyze-project` after `/dw-map-codebase` — it reads `.dw/intel/` as input and produces `.dw/rules/`.
+
+## How `/dw-intel` Reads This
+
+`/dw-intel "auth flow"` does:
+
+1. Check `.dw/intel/.last-refresh.json` — is the index fresh (within last 7 days)? If stale, suggest re-running `/dw-map-codebase`.
+2. Search `apis.json` for matching paths/descriptions.
+3. Search `files.json` for matching exports.
+4. Search `arch.md` (full-text) for the keyword.
+5. Cross-reference with `deps.json` if the query is about a library.
+6. Return a structured answer with file paths cited.
+
+If no `.dw/intel/` exists at all, `/dw-intel` falls back to `.dw/rules/` (seeded by `/dw-new-project` or `/dw-analyze-project`) and direct grep over the codebase.
+
+## Rules
+
+- **Always cite file paths.** Every claim in intel must reference an actual file location.
+- **Current state only.** No temporal language ("recently added", "will change"). The index reflects what's there NOW.
+- **Evidence-based.** Read actual files. Never guess from filenames or directory structures.
+- **Cross-platform**: use Glob/Read/Grep; never Bash `ls`/`find`/`cat` (those break on Windows).
+- **Forbidden files**: never read `.env*` (except `.env.example`/`.env.template`), `*.key`, `*.pem`, `*.pfx`, `*.p12`, `*.keystore`, `*.jks`, `id_rsa`, `id_ed25519`, or files matching `*credential*`/`*secret*` in name. Skip silently if encountered.
+- **Excluded directories**: `node_modules/`, `.git/`, `dist/`, `build/`, `.dw/` (planning docs, not project code).
+- **Output budget**: `files.json` ≤2K tokens, `apis.json` ≤1.5K, `deps.json` ≤1K, `stack.json` ≤500, `arch.md` ≤1.5K. For large repos, prioritize coverage of key files over exhaustive listing.
+
+## References
+
+- `references/intel-format.md` — schema for each `.dw/intel/` file with examples.
+- `references/incremental-update.md` — how partial updates work (which files to re-read, how to merge with existing entries).
+- `references/query-patterns.md` — how `/dw-intel` answers different question shapes (where-is, what-uses, architecture-of, dependency-of).
+- `references/api-design-discipline.md` — Hyrum's Law, contract-first design, error semantics, boundary validation, versioning. Use when intel feeds techspec authoring (`/dw-create-techspec`) for endpoints — design must respect existing project conventions surfaced in `apis.json`. Adapted from [`addyosmani/agent-skills/api-design`](https://github.com/addyosmani/agent-skills/tree/main/api-design) (MIT).
+
+## Inspired by
+
+Adapted from [`get-shit-done-cc`](https://github.com/gsd-build/get-shit-done) (`gsd-intel-updater`) by gsd-build (MIT license). Core schemas (`files.json`, `apis.json`, `deps.json`, `stack.json`, `arch.md`) and incremental update protocol preserved. Path conventions changed from `.planning/intel/` to `.dw/intel/`. CLI tooling (`gsd-sdk query intel.*`) replaced by agent-driven inline operations (no separate runtime). The companion `gsd-codebase-mapper` agent (human-readable analysis docs) was NOT ported — its scope overlaps with the existing `/dw-analyze-project` command which writes to `.dw/rules/`.