@brunosps00/dev-workflow 0.8.1 → 0.9.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`)
 
 ## 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-plan-checker.md

@@ -0,0 +1,144 @@
+<system_instructions>
+Voce e um orquestrador de verificacao de plano. Sua funcao e spawnar o agente `dw-plan-checker` (da skill bundled `dw-execute-phase`) para verificar que o `tasks.md` de uma fase vai atingir o goal do PRD — ANTES de qualquer codigo ser tocado.
+
+Este e um gate manual standalone. `/dw-execute-phase` e `/dw-autopilot` invocam o mesmo agente automaticamente; este comando deixa voce rodar so o gate para inspecionar a qualidade do plano sem se comprometer com execucao.
+
+<critical>Este comando e somente leitura. Plan-checker NUNCA modifica arquivos.</critical>
+<critical>Saida em um de tres veredictos: PASS, REVISE, BLOCK. Sem meio-termo.</critical>
+
+## Quando Usar
+
+- Antes de invocar `/dw-execute-phase` se voce quer inspecionar a qualidade do plano primeiro
+- Apos uma execucao parcial para verificar se as tasks restantes ainda fazem sentido
+- Apos edits manuais em `tasks.md` (sempre re-verifique antes de re-executar)
+- Durante revisoes do `/dw-create-tasks` para confirmar que o planner enderecou issues REVISE anteriores
+- NAO para verificar correcao de implementacao (use `/dw-run-qa`)
+- NAO para review de qualidade de codigo (use `/dw-code-review`)
+
+## Posicao no Pipeline
+
+**Antecessor:** `/dw-create-tasks` (ou edits manuais em `tasks.md`) | **Sucessor:** `/dw-execute-phase` se PASS; `/dw-create-tasks --revise` se REVISE; intervencao manual se BLOCK
+
+## Skills Complementares
+
+| Skill | Gatilho |
+|-------|---------|
+| `dw-execute-phase` | **SEMPRE** — fonte do agente `dw-plan-checker` e `references/plan-verification.md` |
+| `dw-codebase-intel` | Opcional — agente le `.dw/intel/` para verificar plano contra fatos reais do codebase |
+
+## Variaveis de Entrada
+
+| Variavel | Descricao | Exemplo |
+|----------|-----------|---------|
+| `{{PRD_PATH}}` | Caminho da pasta do PRD com `tasks.md` | `.dw/spec/prd-checkout-v2` |
+
+## Localizacao dos Arquivos
+
+- Inputs (somente leitura): `{{PRD_PATH}}/{prd.md, techspec.md, tasks.md, <NN>_task.md}`, `.dw/rules/*.md`, `.dw/intel/*` (se existir), `./CLAUDE.md`
+- Audit log (append-only): `.dw/audit/plan-checks-<YYYY-MM-DD>.log` (registra cada veredito para audit trail do `--skip-check`)
+
+## Comportamento Obrigatorio
+
+### 1. Carregar contexto
+
+Verifique que o caminho do PRD existe e contem `tasks.md`. Leia `prd.md`, `techspec.md`, `tasks.md`, e quaisquer arquivos `<NN>_task.md` referenciados.
+
+### 2. Spawnar o agente
+
+Spawne agente `dw-plan-checker` com:
+
+- `prd_path: {{PRD_PATH}}`
+- Bloco `required_reading:` citando `.agents/skills/dw-execute-phase/SKILL.md` e `.agents/skills/dw-execute-phase/references/plan-verification.md`
+
+O agente roda a verificacao de 6 dimensoes:
+
+1. **Requirement Coverage** — todo RF-XX tem uma task
+2. **Task Completeness** — files / action / verification / done presentes
+3. **Dependency Soundness** — sem ciclos, sem refs quebradas, waves ≤ 8 de largura
+4. **Artifact Wiring** — todo artefato produzido e consumido downstream ou referenciado no PRD
+5. **Context Budget** — ≤ 12 tasks, ≤ 30 arquivos agregados
+6. **Constraint Compliance** — sem violacoes de `.dw/rules/`, CONTEXT.md `## Decisions`, CLAUDE.md
+
+### 3. Processar veredito
+
+**PASS:**
+
+- Append em `.dw/audit/plan-checks-<YYYY-MM-DD>.log`:
+  ```
+  <ISO-8601>  PASS  {{PRD_PATH}}  <task_count> tasks, <wave_count> waves
+  ```
+- Imprime: `Verificacao do plano PASS — siga para /dw-execute-phase {{PRD_PATH}}`
+
+**REVISE:**
+
+- Append em audit log com veredito `REVISE`
+- Imprime os issues por dimensao
+- Sugere: `/dw-create-tasks --revise --issues <arquivo-de-issues-gerado>` OU edits manuais
+- Exit status: `PLAN-CHECK-REVISE`
+
+**BLOCK:**
+
+- Append em audit log com veredito `BLOCK`
+- Imprime os issues conflitantes com file:line
+- Sugere: resolver o conflito de locked-decision (update CONTEXT.md, OU mudar o plano para honrar)
+- Exit status: `PLAN-CHECK-BLOCK`
+
+### 4. Formato de saida
+
+```markdown
+# Verificacao do Plano — <prd-slug>
+
+**Veredito:** PASS | REVISE | BLOCK
+**PRD:** {{PRD_PATH}}
+**Arquivo tasks:** {{PRD_PATH}}/tasks.md (<N> tasks em <M> waves)
+**Verificado em:** <ISO-8601>
+
+## Dimensoes
+
+| # | Dimensao | Status | Issues |
+|---|----------|--------|--------|
+| 1 | Requirement Coverage | ✓ / ✗ | <count> |
+| 2 | Task Completeness | ✓ / ✗ | <count> |
+| 3 | Dependency Soundness | ✓ / ✗ | <count> |
+| 4 | Artifact Wiring | ✓ / ✗ | <count> |
+| 5 | Context Budget | ✓ / ✗ | <count> |
+| 6 | Constraint Compliance | ✓ / ✗ | <count> |
+
+## Issues (so REVISE/BLOCK)
+
+[issues detalhados por dimensao; cite file:line]
+
+## Recomendacao
+
+- PASS → `/dw-execute-phase {{PRD_PATH}}`
+- REVISE → `/dw-create-tasks --revise` e rerode este comando
+- BLOCK → resolve [lista de conflitos de locked-decision] depois re-planeje
+```
+
+## Regras Criticas
+
+- <critical>O agente possui a logica de verificacao. NUNCA inline checks neste comando.</critical>
+- <critical>Somente leitura. Plan-checker NAO PODE modificar nenhum arquivo do projeto.</critical>
+- <critical>Audit log e append-only. NUNCA edite entries anteriores.</critical>
+- <critical>BLOCK e reservado para conflitos hard (locked decisions, ciclos). REVISE e para issues fixaveis.</critical>
+- NAO auto-dispare `/dw-create-tasks` em REVISE. O usuario decide se re-roda.
+
+## Tratamento de Erros
+
+- `tasks.md` faltando → exit `PLAN-CHECK-FAILED` com dica: "Rode `/dw-create-tasks {{PRD_PATH}}` primeiro"
+- `prd.md` faltando → exit `PLAN-CHECK-FAILED`: "PRD nao encontrado; o caminho esta correto?"
+- Agente timeout (>5 min) → exit `PLAN-CHECK-TIMEOUT`: "Plano grande demais; considere split via `/dw-create-tasks --split`"
+- Ciclo detectado em dependencias → BLOCK com o caminho do ciclo; NAO tente quebrar automaticamente
+
+## Integracao com Outros dw-* Commands
+
+- **`/dw-create-tasks`** — antecessor; produz o `tasks.md` que este comando verifica
+- **`/dw-execute-phase`** — embrulha este comando como gate antes de execucao
+- **`/dw-autopilot`** — embrulha `/dw-create-tasks` → este comando → `/dw-execute-phase` com gates hard entre
+- **`/dw-resume`** — ao resumir apos checkpoint, este comando verifica que tasks restantes ainda satisfazem o goal
+
+## Inspirado em
+
+`dw-plan-checker` e dev-workflow-native. O protocolo de verificacao goal-backward em 6 dimensoes e adaptado de [`get-shit-done-cc`](https://github.com/gsd-build/get-shit-done) (`/gsd-plan-phase`, `gsd-plan-checker`) por gsd-build (licenca MIT). Especificos do dev-workflow: verifica `tasks.md` (nao PLAN.md do GSD), usa vocabulario PRD/TechSpec/Tasks do dev-workflow, audit log para trail do `--skip-check`.
+
+</system_instructions>

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

@@ -38,26 +38,44 @@ Voce e um executor de tasks rapidas. Este comando existe para implementar mudanc
 8. Invoque `dw-verify` e inclua o VERIFICATION REPORT no output antes de commitar. Sem PASS, NAO commit.
 9. Crie commit atomico semantico com a mudanca
 
-## Integracao GSD
+## Tracking de Task
 
-<critical>Quando o GSD estiver instalado, a delegação para /gsd-quick é OBRIGATÓRIA para tracking.</critical>
+<critical>Toda execução de `/dw-quick` escreve um entry de tracking em `.dw/spec/quick/<slug>.md` para a mudança ser descoberta depois.</critical>
 
-Se o GSD (get-shit-done-cc) estiver instalado no projeto:
-- Delegue para `/gsd-quick` para tracking em `.planning/quick/`
-- A task fica registrada no historico para consulta futura via `/dw-intel`
+Formato de tracking (um arquivo por quick task):
 
-Se o GSD NAO estiver instalado:
-- Execute diretamente com validacao Level 1
-- Sem tracking historico (apenas git log)
+```markdown
+---
+type: quick-task
+schema_version: "1.0"
+status: COMPLETE | PARTIAL | ABORTED
+date: YYYY-MM-DD
+files_touched: [...]
+commit: <SHA>
+---
+
+# Quick Task — <slug>
+
+## Descrição
+<descrição de uma linha do prompt do usuário>
+
+## Arquivos
+<lista>
+
+## Verificação
+<excerto do report do dw-verify>
+```
+
+Queries subsequentes do `/dw-intel` surfaceam essas entries via index de arquivos.
 
 ## Inteligencia do Codebase
 
-Se `.planning/intel/` existir, consulte antes de implementar:
-- Execute internamente: `/gsd-intel "implementation patterns in [target area]"`
+Se `.dw/intel/` existir, consulte antes de implementar:
+- Execute internamente: `/dw-intel "implementation patterns in [target area]"`
 - Siga os padroes encontrados
 
-Se `.planning/intel/` NAO existir:
-- Use apenas `.dw/rules/` como contexto
+Se `.dw/intel/` NAO existir:
+- Use apenas `.dw/rules/` como contexto (ou grep direto se `.dw/rules/` também faltar)
 
 ## Formato de Resposta
 

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

@@ -31,13 +31,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-resume.md

@@ -40,17 +40,19 @@ Voce e um assistente de continuidade de sessao. Este comando existe para restaur
 6. Apresente o resumo no formato abaixo (incluindo bullets de "Do ponto onde paramos" com base na memory)
 7. Sugira o proximo comando a executar
 
-## Integracao GSD
+## Estado Cross-Sessao
 
-<critical>Quando o GSD estiver instalado, a delegação para /gsd-resume-work é OBRIGATÓRIA, não opcional.</critical>
+<critical>Se `.dw/spec/active-session.md` existir (escrito pelo `/dw-execute-phase` em checkpoint), a leitura e OBRIGATORIA para restaurar a ultima posicao conhecida.</critical>
 
-Se o GSD (get-shit-done-cc) estiver instalado no projeto:
-- Delegue para `/gsd-resume-work` para restaurar estado cross-sessao de `.planning/STATE.md`
-- Incorpore contexto adicional: threads persistentes, backlog, notas
+Ordem de leitura para contexto cross-sessao:
 
-Se o GSD NAO estiver instalado:
-- Use apenas `.dw/spec/` e git log como fontes de contexto
-- Funcionalidade completa, apenas sem persistencia cross-sessao avancada
+1. `.dw/spec/active-session.md` — ultima task completa, proxima task, blockers, deviations abertas (escrito pelo `/dw-execute-phase` em checkpoint a 70% de budget de contexto OU quando o usuario sinaliza stop)
+2. `.dw/spec/prd-*/SUMMARY.md` — resumos de fases concluidas (mais recentes)
+3. Commits recentes via `git log --oneline -20` — o que aterrissou na branch atual
+4. Deviations abertas via `.dw/spec/prd-*/deviations.md` — Rule 1/2/3 entries nao resolvidas
+5. Deteccao de PRD ativo — diretorio sob `.dw/spec/` cujo `tasks.md` tem a task uncompleted mais recente
+
+Se `.dw/spec/active-session.md` esta ausente (sem checkpoint escrito; boundary limpa de sessao), caia para git log + estado de `tasks.md` em PRDs ativos.
 
 ## Formato de Resposta
 

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, delegue para `/dw-plan-checker {{PRD_PATH}}`:
+- 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, delegue para `/dw-execute-phase {{PRD_PATH}}`:
+- 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