@brunosps00/dev-workflow 0.8.1 → 0.9.0

package/scaffold/en/commands/dw-quick.md

@@ -38,26 +38,44 @@ You are a quick task executor. This command exists to implement one-off changes
 8. Invoke `dw-verify` and include the VERIFICATION REPORT in the output before committing. Without PASS, DO NOT commit.
 9. Create atomic semantic commit with the change
 
-## GSD Integration
+## Task Tracking
 
-<critical>When GSD is installed, delegation to /gsd-quick is MANDATORY for tracking.</critical>
+<critical>Every `/dw-quick` execution writes a tracking entry to `.dw/spec/quick/<slug>.md` so the change is discoverable later.</critical>
 
-If GSD (get-shit-done-cc) is installed in the project:
-- Delegate to `/gsd-quick` for tracking in `.planning/quick/`
-- The task is registered in history for future lookup via `/dw-intel`
+Tracking format (single file per quick task):
 
-If GSD is NOT installed:
-- Execute directly with Level 1 validation
-- No history tracking (only 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>
+
+## Description
+<one-line description from the user's prompt>
+
+## Files
+<list>
+
+## Verification
+<dw-verify report excerpt>
+```
+
+Subsequent `/dw-intel` queries surface these via the file index.
 
 ## Codebase Intelligence
 
-If `.planning/intel/` exists, query before implementing:
-- Internally run: `/gsd-intel "implementation patterns in [target area]"`
+If `.dw/intel/` exists, query before implementing:
+- Internally run: `/dw-intel "implementation patterns in [target area]"`
 - Follow the patterns found
 
-If `.planning/intel/` does NOT exist:
-- Use only `.dw/rules/` as context
+If `.dw/intel/` does NOT exist:
+- Use only `.dw/rules/` as context (or grep directly if `.dw/rules/` is also absent)
 
 ## Response Format
 

package/scaffold/en/commands/dw-redesign-ui.md

@@ -64,17 +64,13 @@ Use diagnostic tools based on the project's framework:
 7. **VALIDATE**: capture after-state in BOTH resolutions (mobile and desktop), compare before/after, verify accessibility (WCAG 2.2 via `ui-ux-pro-max`), run react-doctor `--diff` if React. If `webapp-testing` is available, capture screenshots at 375px viewport (mobile) and 1440px viewport (desktop).
 8. **PERSIST CONTRACT**: if the user approved a direction, generate `design-contract.md` in the PRD directory (`.dw/spec/prd-[name]/design-contract.md`) with: approved direction, color palette, typography pairing, layout rules, accessibility rules, and component rules. This contract will be read by `dw-run-task` and `dw-run-plan` to ensure visual consistency.
 
-## GSD Integration
+## Codebase Intelligence
 
-<critical>When GSD is installed, registering the design contract in .planning/ and querying .planning/intel/ are MANDATORY.</critical>
+<critical>If `.dw/intel/` exists, querying it via `/dw-intel` is MANDATORY in the audit phase to surface existing UI patterns.</critical>
 
-If GSD (get-shit-done-cc) is installed in the project:
-- After generating the design contract, register in `.planning/` for cross-session persistence
-- Query `.planning/intel/` in the audit phase for existing UI patterns
-
-If GSD is NOT installed:
-- The design contract works normally (file-based in `.dw/spec/`)
-- Audit uses only `.dw/rules/` for context
+- Audit phase: internally run `/dw-intel "UI components, design patterns, layout conventions"` before proposing redesign directions
+- The design contract (`.dw/spec/prd-[name]/design-contract.md`) is the single source of truth for visual consistency — it's read by `/dw-run-task` and `/dw-run-plan` and persists across sessions naturally (no separate registration needed)
+- If `.dw/intel/` does NOT exist, fall back to `.dw/rules/` and direct grep over `apps/web/src/` (or equivalent frontend root)
 
 ## Preferred Response Format
 

package/scaffold/en/commands/dw-refactoring-analysis.md

@@ -31,13 +31,14 @@ For Angular projects, use `ng lint` as an analytical complement.
 
 ## Codebase Intelligence
 
-<critical>If `.planning/intel/` exists, querying it is MANDATORY before writing requirements. Do NOT skip this step.</critical>
-- Internally run: `/gsd-intel "tech debt, decision spaces, and known technical debt"`
-- Contextualize findings with already documented decisions
+<critical>If `.dw/intel/` exists, querying it via `/dw-intel` is MANDATORY before flagging refactoring opportunities. Do NOT skip this step.</critical>
+- Internally run: `/dw-intel "tech debt and known technical decisions"`
+- Contextualize findings with documented decisions in `.dw/rules/`
 - Avoid flagging as a smell something that is an intentional recorded decision
 
-If `.planning/intel/` does NOT exist:
-- Use `.dw/rules/` as context (current behavior)
+If `.dw/intel/` does NOT exist:
+- Use `.dw/rules/` as context, falling back to grep
+- Suggest running `/dw-map-codebase` to enrich downstream context
 
 ## Input Variables
 

package/scaffold/en/commands/dw-resume.md

@@ -40,17 +40,19 @@ You are a session continuity assistant. This command exists to restore context f
 6. Present the summary in the format below (including a "From where we left off" bullet list based on memory)
 7. Suggest the next command to execute
 
-## GSD Integration
+## Cross-Session State
 
-<critical>When GSD is installed, delegation to /gsd-resume-work is MANDATORY, not optional.</critical>
+<critical>If `.dw/spec/active-session.md` exists (written by `/dw-execute-phase` at checkpoint), reading it is MANDATORY to restore the last-known position.</critical>
 
-If GSD (get-shit-done-cc) is installed in the project:
-- Delegate to `/gsd-resume-work` for cross-session state restoration from `.planning/STATE.md`
-- Incorporate additional context: persistent threads, backlog, notes
+Read order for cross-session context:
 
-If GSD is NOT installed:
-- Use only `.dw/spec/` and git log as context sources
-- Full functionality, just without advanced cross-session persistence
+1. `.dw/spec/active-session.md` — last completed task, next task, blockers, open deviations (written by `/dw-execute-phase` when it checkpoints at 70% context budget OR when the user signals stop)
+2. `.dw/spec/prd-*/SUMMARY.md` — completed phase summaries (most recent ones)
+3. Latest commits via `git log --oneline -20` — what landed on the current branch
+4. Open deviations via `.dw/spec/prd-*/deviations.md` — any unresolved Rule 1/2/3 entries
+5. Active PRD detection — the directory under `.dw/spec/` whose `tasks.md` has the most recent uncompleted task
+
+If `.dw/spec/active-session.md` is absent (no checkpoint was written; clean session boundary), fall back to git log + `tasks.md` state across active PRDs.
 
 ## Response Format
 

package/scaffold/en/commands/dw-run-plan.md

@@ -159,36 +159,30 @@ If a task FAILS during execution:
 4. Wait for manual intervention from the user
 5. **DO NOT** automatically continue to the next task
 
-## GSD Integration
+## Plan Verification + Parallel Execution
 
-<critical>When GSD is installed, plan verification and parallel execution are MANDATORY, not optional. The command MUST NOT skip these steps.</critical>
+<critical>Plan verification and wave-based parallel execution are MANDATORY, not optional. Both are now native to dev-workflow via the `dw-execute-phase` bundled skill.</critical>
 
 ### Plan Verification (Pre-Execution)
 
-If GSD (get-shit-done-cc) is installed in the project:
-- Before starting execution, delegate to GSD's plan-checker agent
-- The verifier analyzes: cyclic dependencies, task viability, risks, PRD requirements coverage
-- If FAIL: present issues found and suggest fixes. Maximum 3 correction cycles
+Before starting execution, delegate to `/dw-plan-checker {{PRD_PATH}}`:
+- The plan-checker agent verifies the 6 dimensions (requirement coverage, task completeness, dependency soundness, artifact wiring, context budget, constraint compliance)
+- If REVISE: present issues found and suggest fixes. Maximum 3 correction cycles via `/dw-create-tasks --revise`
+- If BLOCK: surface conflict to user, do NOT auto-replan
 - If PASS: proceed to execution
 
-If GSD is NOT installed:
-- Skip verification and execute directly (current behavior)
-
 ### Parallel Execution (Wave-Based)
 
-If GSD (get-shit-done-cc) is installed in the project:
-- Analyze each task's `blockedBy` field to build the dependency graph
-- Group tasks into waves:
-  - Wave 1: tasks with no dependencies (can run in parallel)
+After plan-checker PASS, delegate to `/dw-execute-phase {{PRD_PATH}}`:
+- The executor agent analyzes each task's `Depends on:` field to build the dependency graph
+- Groups tasks into waves:
+  - Wave 1: tasks with no dependencies (run in parallel)
   - Wave 2: tasks that depend on Wave 1 tasks
   - Wave N: and so on
-- Delegate each wave to GSD's parallel execution engine (`/gsd-execute-phase`)
-- Each task runs in an isolated worktree with fresh context
-- Results are merged after the wave completes
-- If any task in a wave fails: pause the wave, report, await user decision
-
-If GSD is NOT installed:
-- Execute sequentially as today (current behavior)
+- Each wave dispatches subagents in parallel (one per task)
+- Results merged after the wave completes
+- If any task in a wave fails permanently (Rule 3 deviation): pause the wave, report, await user decision
+- The executor commits atomically per task and writes `SUMMARY.md` after the final wave
 
 ### Design Contracts
 

package/scaffold/en/commands/dw-run-task.md

@@ -25,15 +25,16 @@ When available in the project at `./.agents/skills/`, use these skills as specia
 
 ## Codebase Intelligence
 
-<critical>If `.planning/intel/` exists, querying it is MANDATORY before writing requirements. Do NOT skip this step.</critical>
-- Internally run: `/gsd-intel "implementation patterns in [task target area]"`
+<critical>If `.dw/intel/` exists, querying it via `/dw-intel` is MANDATORY before writing code. Do NOT skip this step.</critical>
+- Internally run: `/dw-intel "implementation patterns in [task target area]"`
 - Follow conventions found for file structure, naming, and error handling
 
 If `design-contract.md` exists in the PRD directory:
 - Read the contract and ensure all frontend implementation follows the approved design rules
 
-If `.planning/intel/` does NOT exist:
-- Use `.dw/rules/` as context (current behavior)
+If `.dw/intel/` does NOT exist:
+- Use `.dw/rules/` as context, falling back to direct grep
+- Suggest running `/dw-map-codebase` after the task to enrich downstream context
 
 ## File Locations
 

package/scaffold/en/commands/dw-update.md

@@ -78,7 +78,9 @@ npx -y @brunosps00/dev-workflow@latest update --lang=$DETECTED_LANG
 The `update` command overwrites managed files and PRESERVES:
 - `.dw/rules/` (user rules)
 - `.dw/spec/` (in-progress PRDs and tasks)
-- `.planning/` (user data)
+- `.dw/intel/` (codebase index from `/dw-map-codebase`)
+
+The `update` command also runs the GSD migration step automatically — if a project has legacy `.planning/` (from prior GSD usage), the contents are migrated to `.dw/intel/`, `.dw/spec/active-session.md`, `.dw/spec/quick/`, etc., and `.planning/` is renamed to `.planning.gsd-archive-<DATE>/` for inspection. The `.claude/commands/gsd/`, `.claude/agents/gsd-*.md`, `.claude/hooks/gsd-*.js`, and `.claude/gsd-file-manifest.json` files are removed during the migration.
 
 If the update fails (network error, permission, package unavailable): report the error to the user and STOP. Do NOT attempt manual workarounds like copying files by hand.
 

package/scaffold/en/templates/idea-onepager.md

@@ -22,7 +22,7 @@ Focus on the problem, not the solution. Avoid jumping into "how to implement".]
 Sources:
 - PRDs in `.dw/spec/prd-*/prd.md` (features already delivered or in development)
 - `.dw/rules/index.md` (product overview)
-- `.planning/intel/` if GSD is installed
+- `.dw/intel/` (queryable index — built by `/dw-map-codebase`, queried via `/dw-intel`)
 
 Format:]
 

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-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.