@brunosps00/dev-workflow 0.8.1 → 0.10.0

package/scaffold/en/commands/dw-review-implementation.md

@@ -318,6 +318,32 @@ git diff <commit> -- path/to/file
 
 <critical>DO NOT APPROVE requirements without concrete evidence in the code</critical>
 <critical>ANALYZE the actual code, do not trust only the checkboxes in tasks.md</critical>
-<critical>If 100% of requirements were implemented and there are NO gaps: DO NOT enter plan mode, DO NOT create tasks, DO NOT dispatch agents. Just present the report and END.</critical>
-<critical>If gaps are found, enter the fix-review loop automatically. Do NOT wait for user instructions to fix gaps. Maximum 3 cycles before marking as BLOCKED.</critical>
+<critical>If 100% of requirements were implemented and there are NO gaps: DO NOT enter plan mode, DO NOT create tasks, DO NOT dispatch agents. Just present the Level 2 report, then proceed to Level 3 (next section).</critical>
+<critical>If gaps are found, enter the fix-review loop automatically. Do NOT wait for user instructions to fix gaps. Maximum 3 cycles before marking as BLOCKED. Level 3 only runs after the loop reaches APPROVED on Level 2.</critical>
+
+## Level 3 — Quality Layer (auto-invoked at the end)
+
+After Level 2 (PRD coverage) reaches APPROVED, **automatically invoke `/dw-code-review`** to add the formal quality layer (best practices, SOLID, DRY, complexity, security, conventions). Addresses the user expectation that a single review covers both "did we deliver everything?" (Level 2) and "is what we delivered well-built?" (Level 3).
+
+Pipeline:
+
+1. After Level 2 APPROVED, run `/dw-code-review {{PRD_PATH}}` with the same PRD scope.
+2. Wait for `/dw-code-review` to produce its verdict (APPROVED / APPROVED WITH CAVEATS / REJECTED).
+3. Write a consolidated summary at `{{PRD_PATH}}/QA/review-consolidated.md` referencing both:
+   - Level 2: `{{PRD_PATH}}/QA/review-coverage.md` (PRD compliance map)
+   - Level 3: `{{PRD_PATH}}/QA/dw-code-review.md` (formal review)
+4. Final status combines both verdicts:
+   - Level 2 APPROVED + Level 3 APPROVED → consolidated APPROVED
+   - Level 2 APPROVED + Level 3 APPROVED WITH CAVEATS → consolidated APPROVED WITH CAVEATS
+   - Level 2 APPROVED + Level 3 REJECTED → consolidated REJECTED (Level 3 wins)
+   - Level 2 REJECTED → never reaches Level 3 (loop fixes coverage first)
+
+### Flag to skip Level 3
+
+If the user runs `/dw-review-implementation --no-code-review`, skip Level 3 and emit only the Level 2 report. Use case: re-running coverage after a small targeted gap fix when a full Level 3 sweep was just done.
+
+### Why this auto-chain exists
+
+`dw-review-implementation` historically returned only Level 2 (coverage). Users expected a single review to also cover quality. Splitting the natural intent into two separate commands created friction. The auto-chain restores the natural "review the implementation" semantics: cover + quality, by default, in one invocation. Standalone `/dw-code-review` remains available for cases where only Level 3 is wanted (e.g., reviewing a cherry-picked refactor branch with no PRD).
+
 </system_instructions>

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, spawn the **plan-checker agent** from `.agents/skills/dw-execute-phase/agents/plan-checker.md`:
+- 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, spawn the **executor agent** from `.agents/skills/dw-execute-phase/agents/executor.md`:
+- 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:]
 
@@ -86,5 +86,5 @@ Ideally 2-4 stories. If it's more than 5, it's probably not MVP.]
 Pick ONE:
 
 - **`/dw-create-prd`** using this one-pager as input — when the direction is clear but we need to detail user stories, acceptance criteria, and hand off to techspec
-- **`/dw-quick`** — when it's an IMPROVES so small that it fits in a single task (up to 3 files, no new endpoint/screen)
+- **`/dw-run-task`** — when it's an IMPROVES so small that it fits in a single task (up to 3 files, no new endpoint/screen) — write a quick PRD first
 - **Stop here** — if any "Open Question" is blocking, stop and resolve with the stakeholder before advancing

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

@@ -26,7 +26,7 @@ Uma etapa que invoca um comando `/dw-xxx` SO e considerada completa quando os ar
 ## Quando Usar
 - Use quando quiser ir de uma ideia ate um PR com minima intervencao manual
 - Use para features completas que passam por todo o pipeline (pesquisa, planejamento, execucao, qualidade)
-- NAO use para mudancas pontuais (use `/dw-quick`)
+- NAO use para tasks pequenas e bem-escopadas — use `/dw-run-task` direto com um PRD curto
 - NAO use para corrigir bugs (use `/dw-bugfix`)
 - NAO use quando quiser controle manual entre cada fase (use os comandos individuais)
 
@@ -56,7 +56,7 @@ O autopilot para APENAS nestes 3 momentos:
 
 ## Retomada de Sessao
 
-Se este comando for invocado para retomar um autopilot interrompido (via `/dw-resume`):
+Se este comando for re-invocado no mesmo PRD apos interrupcao:
 
 <critical>Leia o arquivo `autopilot-state.json` no diretorio do PRD. Pule TODAS as etapas listadas em `completed_steps`. Retome a execucao a partir de `current_step`. Gates ja passados (listados em `gates_passed`) NAO devem ser reapresentados.</critical>
 
@@ -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 os agentes da skill bundled `dw-execute-phase`
 - Cada task segue `/dw-run-task` com validacao Level 1
 
 ### Etapa 9: Review de Implementacao (Loop)
@@ -247,21 +248,13 @@ 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`) e dos agentes bundled de execucao de fase (plan-checker + executor em `.agents/skills/dw-execute-phase/agents/`). Tudo bundled, sem dependencias externas. Veja as skills bundled `dw-codebase-intel` e `dw-execute-phase` em `.agents/skills/` para detalhes.
 
 ## Persistencia de Estado
 
-<critical>O autopilot DEVE salvar seu estado apos cada etapa completada para permitir retomada via `/dw-resume` em caso de interrupcao.</critical>
+<critical>O autopilot DEVE salvar seu estado apos cada etapa completada para permitir re-invocacao no mesmo PRD em caso de interrupcao.</critical>
 
 Salve o arquivo `.dw/spec/prd-[nome]/autopilot-state.json` com o seguinte formato:
 
@@ -293,7 +286,7 @@ Salve o arquivo `.dw/spec/prd-[nome]/autopilot-state.json` com o seguinte format
 
 - Atualize `current_step`, `completed_steps` e `step_artifacts` ANTES de iniciar a proxima etapa
 - Uma etapa SO vai para `completed_steps` apos verificar que seus artefatos existem no disco
-- Se a sessao cair, o `/dw-resume` lera este arquivo e continuara da etapa correta — e revalidara os artefatos antes de confiar em `completed_steps`
+- Se a sessao cair, re-invoque `/dw-autopilot` no mesmo PRD; o comando le `autopilot-state.json` e continua da etapa correta, revalidando artefatos antes de confiar em `completed_steps`
 - Ao finalizar o pipeline (apos commit ou PR), remova o arquivo ou marque `"status": "completed"`
 
 <critical>Apos CADA etapa completada, exiba o bloco de progresso atualizado ao usuario. Isso e OBRIGATORIO — o usuario DEVE ver o que foi feito e o que vem a seguir. Se uma etapa foi pulada, o motivo DEVE aparecer no bloco de progresso.</critical>

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.
@@ -109,7 +109,7 @@ Use este comando quando o usuario quiser:
 - lista curta e executavel
 - se apropriado, sugira qual comando usar em seguida:
   - `/dw-create-prd` (principal sucessor; aceita one-pager como input reduzindo perguntas de clarificação)
-  - `/dw-quick` (se é IMPROVES pequeno que cabe em task única, ≤3 arquivos)
+  - `/dw-run-task` (se é IMPROVES pequeno que cabe em task única com um PRD curto)
   - `/dw-create-techspec`
   - `/dw-create-tasks`
   - `/dw-bugfix`

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

@@ -15,6 +15,7 @@
 
     Quando disponíveis no projeto em `./.agents/skills/`, use estas skills como suporte contextual sem substituir este comando:
 
+    - `dw-debug-protocol`: **SEMPRE** — conduz o bug pelo six-step triage (Reproduzir → Localizar → Reduzir → Fix Root Cause → Guardar → Verificar End-to-End). Stop-the-line discipline; root-cause sobre symptom; regression test commitado no mesmo commit atômico. Bugs não-reprodutíveis seguem o sub-protocolo instrument-first — sem fix por palpite a não ser com acknowledgement explícito.
     - `dw-verify`: **SEMPRE** — em modo Direto, invocada antes do commit da correção. O VERIFICATION REPORT deve mostrar que o sintoma original do bug não se reproduz mais (não apenas que os testes passam).
     - `vercel-react-best-practices`: use quando o bug afeta React/Next.js e há suspeita de problemas de render, hidratação, fetching, waterfall, bundle ou re-render
     - `webapp-testing`: use quando a correção requer fluxo E2E/reteste reproduzível em uma web app

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

@@ -24,18 +24,20 @@ Quando disponíveis no projeto em `./.agents/skills/`, use estas skills como apo
 - `dw-review-rigor`: **SEMPRE** — aplica de-duplication (mesmo pattern em N arquivos = 1 finding), severity ordering (critical → high → medium → low), verify-before-flag, skip-what-linter-catches, e signal-over-volume. A tabela "Problemas Encontrados" do relatório segue essa disciplina.
 - `dw-verify`: **SEMPRE** — invocada antes de emitir verdict `APROVADO` ou `APROVADO COM RESSALVAS`. Sem VERIFICATION REPORT PASS (test + lint + build), o verdict não pode sair como APROVADO.
 - `/dw-security-check`: **SEMPRE para projetos TS/Python/C#/Rust** — invocado como step 6.7 (Camada de Segurança) antes de emitir verdict. Se o projeto usa linguagem suportada e `security-check.md` não existe OU tem status REJECTED, o verdict é **REPROVADO** — sem exceção.
+- `dw-simplification`: use quando o diff toca código denso ou tortuoso — aplica Chesterton's Fence (entender POR QUÊ antes de propor remoção), protocolo de refactor preservando comportamento (test gate antes/depois) e métricas de complexidade (ciclomática, cognitiva, depth, fan-out) para que findings de "simplifique isso" sejam concretos, não opinativos.
 - `security-review`: use quando auth, autorização, input externo, upload, SQL, integração externa, secrets, SSRF, XSS ou superfícies sensíveis estiverem presentes
 - `vercel-react-best-practices`: use quando o diff tocar React/Next.js para revisar padrões de renderização, fetching, bundle, hidratação e performance
 
 ## 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-commit.md

@@ -9,6 +9,12 @@
     ## Posição no Pipeline
     **Antecessor:** `/dw-run-task` ou `/dw-bugfix` | **Sucessor:** `/dw-generate-pr`
 
+    ## Skills Complementares
+
+    Quando disponíveis no projeto em `./.agents/skills/`, use estas skills como suporte operacional sem substituir este comando:
+
+    - `dw-git-discipline`: **SEMPRE** — aplica atomic commits (uma intenção lógica por commit; refactor separado de feature), formato Conventional Commits, lint+tests+build verdes ANTES do commit e proíbe pular hooks (`--no-verify`) ou amend de commits já empurrados. Em mudanças mistas, separa via `git add -p`.
+
     ## Variáveis de Entrada
 
     | Variável | Descrição | Exemplo |

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

@@ -23,18 +23,21 @@
     Quando disponíveis no projeto em `./.agents/skills/`, use como apoio:
 
     - `dw-council` (opt-in via `--council`): debate multi-advisor da decisão arquitetural principal com steel-manning. **NÃO invocar por padrão**.
+    - `dw-source-grounding` (**SEMPRE**): cada decisão de framework/library segue Detect → Fetch → Implement → Cite. O techspec emite citações inline `[source: <url>, version: X.Y, retrieved: YYYY-MM-DD]` ao lado de cada decisão arquitetural.
     - `vercel-react-best-practices`: use quando definir arquitetura frontend para projetos React/Next.js
     - `ui-ux-pro-max`: use quando definir decisões de design system, paletas de cores, tipografia e estilo UI no TechSpec
     - `security-review`: use quando a feature tocar auth, autorização ou manipulação de dados sensíveis
 
     ## 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
+    - Quando o techspec define endpoints de API, consulte TAMBÉM `dw-codebase-intel/references/api-design-discipline.md` (Hyrum's Law, contract-first, error semantics, boundary validation, versionamento) — o novo endpoint deve seguir convenções já presentes em `apis.json`, e não impor "best practices" externas que conflitem com os padrões existentes.
 
-    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-deep-research.md

@@ -5,6 +5,12 @@ Você é um assistente de pesquisa avançada capaz de conduzir investigações p
 <critical>NUNCA fabrique citações - se não encontrar fonte, diga explicitamente</critical>
 <critical>A bibliografia DEVE conter TODAS as citações usadas no corpo do relatório, sem abreviações ou ranges</critical>
 
+## Skills Complementares
+
+| Skill | Gatilho |
+|-------|---------|
+| `dw-source-grounding` | **SEMPRE** — aplica o protocolo Detect → Fetch → Implement → Cite com hierarquia estrita de fontes (docs oficiais versionadas > changelogs > web standards > compat tables; Stack Overflow / blogs / training data são só descoberta). Cada finding termina com `[source: <url>, version: X.Y, retrieved: YYYY-MM-DD]`; a bibliografia e construida a partir dessas citacoes. |
+
 ## Quando Usar
 - Use para análise abrangente multi-fonte, comparações de tecnologia ou revisões do estado da arte que exigem evidências citadas
 - NÃO use para buscas simples, debugging ou perguntas que podem ser respondidas com 1-2 buscas

package/scaffold/pt-br/commands/dw-deps-audit.md

@@ -29,6 +29,7 @@ Este comando e **distinto** do `/dw-security-check`:
 | `dw-verify` | **SEMPRE** — toda fase emite VERIFICATION REPORT (comandos rodados, exit codes, artefatos) antes da proxima fase comecar |
 | `dw-review-rigor` | **SEMPRE** — aplica deduplicacao (mesmo advisory em N pacotes = 1 finding com lista afetada), severity ordering, e signal-over-volume na lista OUTDATED-MINOR |
 | `security-review` (`references/supply-chain.md`) | **SEMPRE** ao classificar findings — da o framing OWASP A06 (Vulnerable & Outdated Components) para os trade-offs do brainstorm |
+| `dw-source-grounding` | **SEMPRE** na fase de brainstorm — cada opcao de update por pacote (Conservadora/Balanceada/Ousada) cita o changelog/release notes oficial da versao alvo: `[source: <url>, version: X.Y, retrieved: YYYY-MM-DD]`. Previne "agent recomenda v5 porque parece moderno, mas v5 dropou Node 18". |
 | `dw-council` | Opt-in automatico quando >=3 pacotes caem em tier COMPROMISED — stress-test multi-conselheiro sobre ordem e escopo de remediacao |
 | `webapp-testing` | Opcional — quando o projeto e frontend e a fase de testes escopados precisa de selecao Playwright-aware |
 

package/scaffold/pt-br/commands/dw-find-skills.md

@@ -15,7 +15,7 @@ Voce e um assistente de descoberta de skills neste workspace. Sua funcao e ajuda
 
 ## Posicao no Pipeline
 
-**Predecessor:** qualquer pergunta exploratoria | **Sucessor:** nenhum (fluxo independente). Se nao achar skill, caia para `/dw-brainstorm` (explorar ideias) ou `/dw-quick` (mudanca pequena one-off) quando aplicavel.
+**Predecessor:** qualquer pergunta exploratoria | **Sucessor:** nenhum (fluxo independente). Se nao achar skill, caia para `/dw-brainstorm` (explorar ideias) ou `/dw-run-task` (mudanca pequena one-off) quando aplicavel.
 
 ## Skills Complementares
 
@@ -81,7 +81,7 @@ Catalogo: https://skills.sh/
    - Reconheca que nao houve match, sem inventar
    - Ofereca ajudar direto com capacidades gerais
    - Sugira `/dw-brainstorm` se o usuario quer explorar antes de construir
-   - Sugira `/dw-quick` se cabe em uma mudanca pequena (<= 3 arquivos, sem PRD)
+   - Sugira `/dw-run-task` se cabe em uma mudanca pequena (<= 3 arquivos, sem PRD)
    - Mencione `npx skills init <nome>` como caminho para criar a skill que falta
 
 ## Categorias Comuns
@@ -128,7 +128,7 @@ Pesquisei skills sobre "<query>" e nao achei match forte
 
 Posso ajudar direto. Ou:
   /dw-brainstorm "<sua ideia>"     — explorar abordagens antes
-  /dw-quick "<mudanca pequena>"    — se cabe em uma task curta
+  /dw-run-task "<mudanca pequena>" — se cabe em uma task curta (escreva PRD curto antes)
   npx skills init <nome>           — criar voce mesmo se vale a pena reutilizar
 ```
 
@@ -150,7 +150,7 @@ Posso ajudar direto. Ou:
 `dw-find-skills` porta a skill `find-skills` (do bundle superpowers do Claude, `~/.agents/skills/find-skills/SKILL.md`) para um comando do workflow `dw-*` — assim toda plataforma suportada (Claude Code, Codex, Copilot, OpenCode) ganha a mesma porta de descoberta. Adaptacoes para o dev-workflow:
 
 - Integracao com o pipeline: `/dw-help <keyword>` roteia para ca quando bate em `skill`/`find skill`/`install skill`/`extend agent`.
-- Fallback para `/dw-brainstorm` ou `/dw-quick` quando nao acha skill — mantem o usuario dentro do workflow ao inves de despeja-lo de maos vazias.
+- Fallback para `/dw-brainstorm` ou `/dw-run-task` quando nao acha skill — mantem o usuario dentro do workflow ao inves de despeja-lo de maos vazias.
 - Pergunta explicita de escopo (`-g` vs local) antes de instalar, em vez de assumir global.
 
 Credito: skill `find-skills` do ecossistema superpowers do Claude e o projeto `npx skills` / [skills.sh](https://skills.sh/).

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

@@ -18,6 +18,7 @@ Você é um assistente IA especializado em correção de bugs pós-QA com retest
 
 Quando disponíveis no projeto em `./.agents/skills/`, use estas skills como suporte operacional sem substituir este comando:
 
+- `dw-debug-protocol`: **SEMPRE** — todo finding bug-shaped (cenário falhando, não feature ausente) passa pelo six-step triage. A evidência de reteste é o artefato da etapa 6 (verify); o regression test da etapa 5 é o que sustenta o status `Corrigido`.
 - `dw-verify`: **SEMPRE** — invocada antes de marcar qualquer bug como `Corrigido` ou `Fechado` no `QA/bugs.md`. Sem VERIFICATION REPORT PASS (test + lint + build) + evidência de reteste (screenshot em modo UI OU linha JSONL em modo API), o status permanece `Reaberto` ou `Em análise`.
 - `webapp-testing`: (modo UI) suporte para estruturar retestes, capturas e scripts quando complementar ao Playwright MCP
 - `vercel-react-best-practices`: (modo UI) use apenas se a correção afetar frontend React/Next.js e houver risco de regressão de renderização, hidratação, fetching ou performance

package/scaffold/pt-br/commands/dw-generate-pr.md

@@ -14,6 +14,7 @@
     | Skill | Gatilho |
     |-------|---------|
     | `dw-verify` | **SEMPRE** — invocada antes do `git push`. Sem VERIFICATION REPORT PASS na sessão após a última edição de código, o PR **NÃO** pode ser criado. |
+    | `dw-git-discipline` | **SEMPRE** — valida naming de branch (`<tipo>/<escopo>` kebab-case), histórico atomic-commit (cada commit single-intent, mensagem conventional), tempo de vida da branch (flag se >7 dias) e escopo da PR (sugere split se diff > ~400 linhas). Descrição da PR segue summary + test plan, não dump de `git log`. |
     | `/dw-security-check` | **SEMPRE para projetos TS/Python/C#/Rust** — `security-check.md` com status ≠ REJECTED é obrigatório para projetos em linguagem suportada. |
 
     <critical>Hard gate 1 (verify): se a sessão atual não tem um VERIFICATION REPORT PASS de `dw-verify` produzido APÓS a última edição/commit, PARAR e invocar `dw-verify` antes de prosseguir. PR é um artefato permanente — exige o maior rigor de verificação.</critical>

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

@@ -23,7 +23,6 @@ Você é um assistente de ajuda do workspace. Quando invocado, apresente ao usu
 | qa, teste visual, playwright | `/dw-run-qa` | QA E2E com browser automation |
 | refactor, smell, fowler | `/dw-refactoring-analysis` | Auditoria de code smells priorizada |
 | design, ui, redesign | `/dw-redesign-ui` | Auditoria + propostas + implementação visual |
-| decisão, adr, arquitetura | `/dw-adr` | Registrar Architecture Decision Record |
 | debate, council, stress-test, opiniões | `/dw-brainstorm --council` ou `/dw-create-techspec --council` | Invoca `dw-council` para debate multi-advisor |
 | security, segurança, vulnerabilidade, owasp, trivy, cve | `/dw-security-check` | Check multi-camada rígido (OWASP estático + Trivy SCA/IaC + audit nativo) para TS/Python/C#/Rust |
 | supply chain, outdated, comprometido, pacote malicioso, atualizar deps, npm audit, pip-audit | `/dw-deps-audit` | Detecta + classifica + plano de update por pacote com QA escopada. Vai além do `/dw-security-check` adicionando remediação. |
@@ -32,8 +31,6 @@ Você é um assistente de ajuda do workspace. Quando invocado, apresente ao usu
 | 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. |
 | 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 |
-| retomar, onde parei | `/dw-resume` | Restaura contexto da sessão anterior |
 | pesquisa, research | `/dw-deep-research` | Pesquisa multi-fonte com citações |
 | ideia, brainstorm | `/dw-brainstorm` | Ideação estruturada com trade-offs |
 | atualizar dev-workflow | `/dw-update` | Atualiza para versão npm mais recente |
@@ -114,9 +111,6 @@ Este workspace utiliza um sistema de comandos AI que automatiza o ciclo completo
 | `/dw-bugfix` | Analisa e corrige bugs (triagem bug vs feature) | Target + descrição | Fix + commit OU PRD (se feature) |
 | `/dw-fix-qa` | Corrige bugs documentados no QA e retesta com evidências | Path do PRD | Código + `QA/bugs.md` + `QA/qa-report.md` atualizados |
 | `/dw-redesign-ui` | Audita, propõe e implementa redesign visual de páginas/componentes | Página/componente alvo | Brief de redesign + código |
-| `/dw-quick` | Executa task pontual com garantias do workflow sem PRD | Descrição da mudança | Código + commit |
-| `/dw-resume` | Restaura contexto da sessão e sugere próximo passo | (nenhum) | Resumo + sugestão |
-| `/dw-intel` | Consulta inteligência do codebase sobre padrões e arquitetura | Pergunta | Resposta com fontes |
 | `/dw-autopilot` | Orquestrador completo: de um desejo até o PR com mínima intervenção | Descrição do desejo | PRD + código + commits + PR |
 
 ### Análise e Pesquisa
@@ -151,11 +145,15 @@ Este workspace utiliza um sistema de comandos AI que automatiza o ciclo completo
 | `/dw-generate-pr` | Push + cria PR + copia body + abre URL | Branch alvo | PR no GitHub |
 | `/dw-revert-task` | Reverte com segurança os commits de uma task específica (check de dependências + confirmação) | Path do PRD + número da task | Commits revertidos + `tasks.md` atualizado |
 
-### Decisões Arquiteturais
+### Comandos internos (usados por outros dw-* commands; raramente invocados direto)
 
-| Comando | O que faz | Input | Output |
-|---------|-----------|-------|--------|
-| `/dw-adr` | Registra um Architecture Decision Record (ADR) para decisão não-trivial durante o PRD | Path do PRD + título | `.dw/spec/<prd>/adrs/adr-NNN.md` + cross-refs atualizadas |
+| Comando | O que faz | Tipicamente invocado por |
+|---------|-----------|--------------------------|
+| `/dw-adr` | Registra Architecture Decision Record durante execução do PRD | `/dw-create-techspec`, `/dw-run-task` quando surge decisão não-trivial |
+| `/dw-intel` | Consulta o índice do codebase em `.dw/intel/` | `/dw-create-prd`, `/dw-create-techspec`, `/dw-code-review` etc. |
+| `/dw-map-codebase` | Constroi/refresca o índice queryable em `.dw/intel/` | `/dw-analyze-project` (auto-roda após geração de rules) |
+
+Esses ficam expostos como slash commands para uso manual ocasional (ex.: registrar ADR rapidamente mid-sessão, consultas ad-hoc no codebase) mas a maioria dos usuários nunca invoca direto — eles são chamados pelos comandos high-level acima.
 
 ### Utilitários
 
@@ -242,16 +240,6 @@ Inspiradas em skills do projeto [Compozy](https://github.com/compozy/compozy) (`
 /dw-autopilot "descrição do que quer construir"    # Pesquisa → PRD → Tasks → Código → QA → PR
 ```
 
-### Task Rápida
-```bash
-/dw-quick "descrição da mudança"                   # Implementa + valida + commit
-```
-
-### Retomar Sessão
-```bash
-/dw-resume                                         # Restaura contexto + sugere próximo passo
-```
-
 ### Consultar Codebase
 ```bash
 /dw-intel "como funciona X neste projeto?"         # Resposta com fontes
@@ -284,9 +272,7 @@ workspace/
 │   │   ├── dw-review-implementation.md
 │   │   ├── dw-deep-research.md
 │   │   ├── dw-intel.md
-│   │   ├── dw-quick.md
 │   │   ├── dw-redesign-ui.md
-│   │   ├── dw-resume.md
 │   │   ├── dw-bugfix.md
 │   │   ├── dw-fix-qa.md
 │   │   ├── dw-commit.md
@@ -335,11 +321,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: 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.
+**Q: Como obtenho inteligência do codebase e execução paralela?**
+- Os dois são nativos do dev-workflow. Rode `/dw-map-codebase` para construir o índice queryable em `.dw/intel/`, depois `/dw-intel "<pergunta>"` para consultá-lo. Para execução paralela, `/dw-run-plan` invoca os agentes bundled de execução de fase (executor + plan-checker) diretamente para dispatcha tasks em waves com commits atômicos por task. Sem dependência externa.
 
 **Q: O `/dw-autopilot` substitui todos os outros comandos?**
 - Não. Ele orquestra os comandos existentes em sequência. Você ainda pode usar cada comando individualmente para controle manual. O autopilot é para quando quer ir do desejo ao PR com mínima intervenção.