@brunosps00/dev-workflow 2.0.0 → 2.2.0

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

@@ -93,6 +93,34 @@ Ideally 2-4 stories. If it's more than 5, it's probably not MVP.]
 
 _(schema 1.1 — filled by a `/dw-brainstorm` grill session; consumed by `/dw-plan`, which does NOT re-ask resolved decisions. Leave empty for a non-grilled one-pager.)_
 
+### Decision Map
+
+[Durable Grill tree. This records structure and resume state only; keep the decision outcome, recommendation,
+alternative, and evidence in **Resolved Decisions** below.]
+
+**Frontier:** [comma-separated node IDs with `State: open-ready`, or `none`]
+
+| ID | Decision node | State | Depends on: | Frontier? | Notes |
+|----|---------------|-------|-------------|-----------|-------|
+| D1 | [upstream decision] | resolved | none | no | [structure note; outcome lives in Resolved Decisions] |
+| D2 | [open decision that can be asked next] | open-ready | D1 | yes | [why this is ready] |
+| D3 | [open decision still blocked] | open-blocked | D2 | no | [what blocks it] |
+
+`State` is the source of truth. `Frontier?` and the `**Frontier:**` line are derived from it for
+readability — if they ever disagree with `State`, `State` wins and the derived values are rewritten.
+
+Allowed `State` values:
+- `resolved` — the user settled the node; details live in **Resolved Decisions**.
+- `open-ready` — open and decidable now; this node is in the **Frontier**.
+- `open-blocked` — open but waiting on one or more `Depends on:` nodes.
+
+#### Decision Fog
+
+[Known unresolved areas that are not yet clear enough to phrase as decision nodes. Keep this short; each item
+graduates into **Decision Map** when it becomes a concrete decision.]
+
+- [unknown area] — [why it is not yet formulable as a decision]
+
 ### Resolved Decisions
 
 | Decision | Recommended | Chosen | Alternative rejected | Evidence |

package/scaffold/en/templates/task-template.md

@@ -13,6 +13,7 @@ status: pending
 [Brief task description]
 
 **Functional Requirements covered**: FR-X.Y, FR-X.Z (maximum 2 per task)
+Depends on: none
 
 <requirements>
 [List of mandatory requirements]

package/scaffold/en/templates/tasks-template.md

@@ -19,19 +19,20 @@ feat/prd-[feature-name]
 
 ## Tasks
 
-| Task | Description | FRs | Status | Commit |
-|------|-------------|-----|--------|--------|
-| 1.0 | [Title] | FR-1.1, FR-1.2 | Pending | — |
-| 2.0 | [Title] | FR-2.1 | Pending | — |
-| 3.0 | [Title] | FR-3.1, FR-3.2 | Pending | — |
+| Task | Description | Depends on | FRs | Status | Commit |
+|------|-------------|------------|-----|--------|--------|
+| 1.0 | [Title] | none | FR-1.1, FR-1.2 | Pending | — |
+| 2.0 | [Title] | 1.0 | FR-2.1 | Pending | — |
+| 3.0 | [Title] | 1.0, 2.0 | FR-3.1, FR-3.2 | Pending | — |
 
 `Commit` holds the short SHA written back by `/dw-run` when the task closes (step 6). It is what makes a task's diff findable later — leave `—` until the task commits.
+`Depends on` is the dependency graph consumed by `/dw-run`; write `none` when a task has no dependency.
 
 ## Progress
 
-- [ ] 1.0 Main Task Title
-- [ ] 2.0 Main Task Title
-- [ ] 3.0 Main Task Title
+- [ ] 1.0 Main Task Title        Depends on: none
+- [ ] 2.0 Main Task Title        Depends on: 1.0
+- [ ] 3.0 Main Task Title        Depends on: 1.0, 2.0
 
 ## Workflow
 

package/scaffold/en/templates/triage-needs-info-template.md

@@ -0,0 +1,23 @@
+# Needs Info: <title>
+
+## Blocking Questions
+
+- [ ] <question 1>
+- [ ] <question 2>
+- [ ] <question 3>
+
+## Why This Blocks Triage
+
+<Explain why the missing information prevents category/state confidence or verification.>
+
+## Author Response
+
+<Paste or summarize the author's response. When the author responds, move the triage state from `needs-info` to `needs-triage` and re-run the recommendation step.>
+
+## Requested Evidence
+
+- Reproduction steps:
+- Expected vs actual behavior:
+- Environment or test data:
+- PR diff or branch/ref:
+- Screenshots/logs/traces:

package/scaffold/en/templates/triage-out-of-scope-template.md

@@ -0,0 +1,36 @@
+---
+type: out-of-scope
+schema_version: "1.0"
+concept: "<concept-slug>"
+created_at: "YYYY-MM-DD"
+updated_at: "YYYY-MM-DD"
+---
+
+# Out of Scope: <Concept Name>
+
+## Decision
+
+Rejected on YYYY-MM-DD.
+
+## Reason
+
+<Record the durable reason. Do not write only "wontfix"; explain the product, technical, operational, or policy boundary.>
+
+## Applies To
+
+- <Domain phrasing of requests this decision covers>
+- <Known alternate wording that maps to the same concept>
+
+## Evidence
+
+- Triage record: `.dw/triage/NNN-<slug>.md`
+- Codebase search:
+- Prior decisions:
+
+## Revisit Conditions
+
+<What would need to change for this concept to be reconsidered?>
+
+## History
+
+- YYYY-MM-DD — rejected — <actor> — <reason>

package/scaffold/en/templates/triage-record-template.md

@@ -0,0 +1,88 @@
+---
+type: triage-record
+schema_version: "1.0"
+id: "NNN-<slug>"
+category: "bug | enhancement"
+state: "needs-triage | needs-info | ready-for-work | needs-human | wontfix"
+created_at: "YYYY-MM-DD"
+updated_at: "YYYY-MM-DD"
+---
+
+# Triage: <title>
+
+## Source
+
+| Field | Value |
+|-------|-------|
+| Source Type | paste / file / github-issue / github-pr / other |
+| Source Ref | <path, URL, issue number, PR number, or pasted-session marker> |
+| Author | <name or unknown> |
+| Reported At | <date or unknown> |
+| Retrieved By | local / gh / pasted / owner-provided |
+
+## Intake Summary
+
+<Short summary of the request in domain language.>
+
+## Classification
+
+| Field | Value |
+|-------|-------|
+| Category | bug / enhancement |
+| State | needs-triage / needs-info / ready-for-work / needs-human / wontfix |
+| Domain Concept | <concept slug and human name> |
+| Disposition Reason | <why this state was chosen> |
+
+## Codebase Checks
+
+### Redundancy Search
+
+| Area Searched | Query / Concept | Result |
+|---------------|-----------------|--------|
+| `.dw/domain/**` | <concept> | <match / no match / missing> |
+| `.dw/spec/**` | <concept> | <match / no match / missing> |
+| `.dw/bugfixes/**` | <concept> | <match / no match / missing> |
+| `.dw/rules/**` | <concept> | <match / no match / missing> |
+| Code / tests / docs | <concept> | <match / no match> |
+
+### Prior Rejection Search
+
+| Record | Similarity | Decision |
+|--------|------------|----------|
+| `.dw/out-of-scope/<concept>.md` | <why similar> | applies / does not apply / reopened |
+
+## Verification
+
+| Field | Value |
+|-------|-------|
+| Verification Status | confirmed / failed-to-reproduce / insufficient-detail |
+| Verification Method | reproduce steps / PR diff review / relevant tests / product inventory check |
+| Commands Run | <commands or n/a> |
+| Files Inspected | <paths> |
+| Evidence | <what was observed> |
+
+## Needs Info
+
+<!-- If state is needs-info, paste the body from triage-needs-info-template.md here. Otherwise write "n/a". -->
+
+n/a
+
+## Routing
+
+| Condition | Route |
+|-----------|-------|
+| ready-for-work + bug | `/dw-bugfix` |
+| ready-for-work + enhancement | `/dw-plan prd` |
+| malformed request | `/dw-brainstorm --mode=grill` |
+| needs-human | owner action |
+| wontfix | no downstream work |
+
+Selected route: <route or n/a>
+
+## Out-of-Scope Link
+
+<If rejected, link `.dw/out-of-scope/<concept>.md`. If already implemented, link the implementation and state that no out-of-scope record was written.>
+
+## History
+
+- YYYY-MM-DD — needs-triage -> <state> — <actor> — <reason>

package/scaffold/pt-br/agent-instructions.md

@@ -37,6 +37,8 @@ Antes de escolher um comando da Trigger Map, dimensione o escopo real da mudanç
 | "Roda isso como goal" / "objetivo durável" / "long-running objective" | `/dw-goal "<objetivo>"` |
 | "Continue de onde parei" | `/dw-run --resume` |
 | "Pausa o trabalho" / "Encerra a sessão" / "Salva onde paramos" | `/dw-pause` |
+| "Report de N em N minutos" / "Me mantém informado enquanto isso roda" / "Quero status periódico" | `/dw-report [--every <N>m]` |
+| "Cria uma worktree pra X" / "Limpa as worktrees" / "Mergeia a worktree X" / "Quantas worktrees sobraram?" | `/dw-worktree create <slug>` / `/dw-worktree clean --apply` / `/dw-worktree merge <slug>` / `/dw-worktree list` |
 | "Retoma" / "Onde paramos?" / "Volta de onde parei" | `/dw-resume` |
 | "QA dessa feature" / "Roda o test plan" | `/dw-qa` |
 | "Corrige os bugs do QA" | `/dw-qa --fix` |

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

@@ -1,130 +1,130 @@
 <system_instructions>
-Voce e o orquestrador de pipeline completo. Este comando recebe um desejo do usuario e conduz o workflow PRD-ao-PR em duas invocacoes:
+Você é o orquestrador de pipeline completo. Este comando recebe um desejo do usuário e conduz o workflow PRD-ao-PR em duas invocações:
 
-1. **Invocacao de planejamento:** pesquisa/brainstorm quando necessario, PRD, TechSpec, Tasks, depois PARA.
-2. **Invocacao de execucao:** retoma de `autopilot-state.json`, roda `/dw-goal --from-autopilot <prd-slug>`, depois commit e gate de PR.
+1. **Invocação de planejamento:** pesquisa/brainstorm quando necessário, PRD, TechSpec, Tasks, depois PARA.
+2. **Invocação de execução:** retoma de `autopilot-state.json`, roda `/dw-goal --from-autopilot <prd-slug>`, depois commit e gate de PR.
 
-<critical>A primeira invocacao DEVE parar depois que os artefatos de planejamento estiverem completos. Nao rode implementacao, QA, review, commit ou PR na primeira invocacao.</critical>
-<critical>A segunda invocacao DEVE retomar do estado salvo e delegar Run → Review → QA/Fix → Review para `/dw-goal --from-autopilot <prd-slug>`.</critical>
-<critical>Cada etapa que invoca um comando `/dw-*` DEVE seguir as instrucoes completas de `.dw/commands/`. Leia e execute o comando inteiro, nao uma versao resumida.</critical>
+<critical>A primeira invocação DEVE parar depois que os artefatos de planejamento estiverem completos. Não rode implementação, QA, review, commit ou PR na primeira invocação.</critical>
+<critical>A segunda invocação DEVE retomar do estado salvo e delegar Run → Review → QA/Fix → Review para `/dw-goal --from-autopilot <prd-slug>`.</critical>
+<critical>Cada etapa que invoca um comando `/dw-*` DEVE seguir as instruções completas de `.dw/commands/`. Leia e execute o comando inteiro, não uma versão resumida.</critical>
 
 ## Quando Usar
-- Use quando quiser ir de uma ideia ate um PR com minima intervencao manual, mas com parada obrigatoria apos o planejamento.
-- Use para features completas que exigem planejamento, execucao, qualidade e prontidao de PR.
-- NAO use para tasks pequenas e bem-escopadas; use `/dw-run` com um plano existente.
-- NAO use para bugfix cirurgico; use `/dw-bugfix`.
-- NAO use quando o usuario quer controle manual entre cada fase; use comandos individuais.
+- Use quando quiser ir de uma ideia até um PR com mínima intervenção manual, mas com parada obrigatória após o planejamento.
+- Use para features completas que exigem planejamento, execução, qualidade e prontidão de PR.
+- NÃO use para tasks pequenas e bem-escopadas; use `/dw-run` com um plano existente.
+- NÃO use para bugfix cirúrgico; use `/dw-bugfix`.
+- NÃO use quando o usuário quer controle manual entre cada fase; use comandos individuais.
 
-## Posicao no Pipeline
-**Antecessor:** desejo do usuario | **Sucessor:** `/dw-goal`, `/dw-commit`, `/dw-generate-pr`
+## Posição no Pipeline
+**Antecessor:** desejo do usuário | **Sucessor:** `/dw-goal`, `/dw-commit`, `/dw-generate-pr`
 
 ## Skills / Comandos Complementares
 
 | Skill ou comando | Gatilho |
 |------------------|---------|
-| `dw-memory` | SEMPRE — preserva decisoes entre planejamento, goal de execucao, QA, review e PR. |
-| `dw-verify` | SEMPRE — invocado por gates e comandos downstream antes de claims de aprovacao/commit/PR. |
-| `/dw-goal` | SEMPRE na segunda invocacao — objetivo duravel de execucao/qualidade. |
+| `dw-memory` | SEMPRE — preserva decisões entre planejamento, goal de execução, QA, review e PR. |
+| `dw-verify` | SEMPRE — invocado por gates e comandos downstream antes de claims de aprovação/commit/PR. |
+| `/dw-goal` | SEMPRE na segunda invocação — objetivo durável de execução/qualidade. |
 
-## Variaveis de Entrada
+## Variáveis de Entrada
 
-| Variavel | Descricao | Exemplo |
+| Variável | Descrição | Exemplo |
 |----------|-----------|---------|
-| `{{WISH}}` | Descricao do que o usuario quer construir no modo padrao. | `"preferencias de notificacao push"` |
-| `{{PRD_SLUG}}` | Slug de PRD existente quando `--from-prd` e usado. | `prd-bugfix-stripe-webhook-retry` |
-| `{{MODE}}` | Flag opcional de invocacao. | `--from-prd <slug>` |
+| `{{WISH}}` | Descrição do que o usuário quer construir no modo padrão. | `"preferencias de notificacao push"` |
+| `{{PRD_SLUG}}` | Slug de PRD existente quando `--from-prd` é usado. | `prd-bugfix-stripe-webhook-retry` |
+| `{{MODE}}` | Flag opcional de invocação. | `--from-prd <slug>` |
 
-## Modos de Invocacao
+## Modos de Invocação
 
-| Invocacao | Comportamento |
+| Invocação | Comportamento |
 |-----------|---------------|
-| `/dw-autopilot "<wish>"` | Invocacao de planejamento do zero. Roda Inteligencia do Codebase → Pesquisa opcional → Brainstorm → PRD → TechSpec → Tasks, salva estado e para. |
-| `/dw-autopilot --from-prd <slug>` | Invocacao de planejamento a partir de PRD existente. Comeca em aprovacao do PRD, depois TechSpec → Tasks, salva estado e para. |
-| `/dw-autopilot` em PRD com `autopilot-state.json status=plan_complete` | Invocacao de execucao. Roda `/dw-goal --from-autopilot <slug>`, depois commit e gate de PR. |
+| `/dw-autopilot "<wish>"` | Invocação de planejamento do zero. Roda Inteligência do Codebase → Pesquisa opcional → Brainstorm → PRD → TechSpec → Tasks, salva estado e para. |
+| `/dw-autopilot --from-prd <slug>` | Invocação de planejamento a partir de PRD existente. Começa em aprovação do PRD, depois TechSpec → Tasks, salva estado e para. |
+| `/dw-autopilot` em PRD com `autopilot-state.json status=plan_complete` | Invocação de execução. Roda `/dw-goal --from-autopilot <slug>`, depois commit e gate de PR. |
 
-## Pontos de Pausa Obrigatorios
+## Pontos de Pausa Obrigatórios
 
 Autopilot pausa em:
 
-1. **Aprovacao do PRD** antes do TechSpec.
-2. **Aprovacao das Tasks** antes de marcar planejamento completo.
-3. **Parada obrigatoria de planejamento** depois que Tasks forem aprovadas e estado salvo.
-4. **Gate de PR** depois que o goal de execucao e commit completarem.
+1. **Aprovação do PRD** antes do TechSpec.
+2. **Aprovação das Tasks** antes de marcar planejamento completo.
+3. **Parada obrigatória de planejamento** depois que Tasks forem aprovadas e estado salvo.
+4. **Gate de PR** depois que o goal de execução e commit completarem.
 
 Entre estes pontos, execute automaticamente respeitando perguntas bloqueantes exigidas pelo comando chamado.
 
-## Retomada de Sessao
+## Retomada de Sessão
 
 Se este comando for re-invocado no mesmo PRD:
 
-<critical>Leia `.dw/spec/<prd-slug>/autopilot-state.json` primeiro. Se `status` for `plan_complete`, nao repita planejamento. Inicie a invocacao de execucao chamando formalmente `/dw-goal --from-autopilot <prd-slug>`.</critical>
+<critical>Leia `.dw/spec/<prd-slug>/autopilot-state.json` primeiro. Se `status` for `plan_complete`, não repita planejamento. Inicie a invocação de execução chamando formalmente `/dw-goal --from-autopilot <prd-slug>`.</critical>
 
 Significados de estado:
 
-| Status | Acao |
+| Status | Ação |
 |--------|------|
-| estado ausente | Iniciar invocacao de planejamento normal. |
+| estado ausente | Iniciar invocação de planejamento normal. |
 | `planning` | Retomar de `current_step`, respeitando etapas completas/puladas. |
-| `plan_complete` | Iniciar invocacao de execucao via `/dw-goal --from-autopilot <prd-slug>`. |
+| `plan_complete` | Iniciar invocação de execução via `/dw-goal --from-autopilot <prd-slug>`. |
 | `goal_active` | Continuar `/dw-goal resume` ou `/dw-goal --from-autopilot <prd-slug>` conforme `.dw/goals/autopilot-<prd-slug>/status.json`. |
 | `goal_complete` | Continuar para commit e gate de PR. |
-| `completed` | Reportar que ja foi concluido e mostrar resumo de PR/commit se disponivel. |
+| `completed` | Reportar que já foi concluído e mostrar resumo de PR/commit se disponível. |
 
-## Invocacao de Planejamento
+## Invocação de Planejamento
 
-### Etapa 0: Resolver modo de invocacao
+### Etapa 0: Resolver modo de invocação
 
 1. Se `--from-prd <slug>` aparece:
    - Resolva para `.dw/spec/<slug>/`.
-   - Verifique que `prd.md` existe; senao PARE com: `Alvo de --from-prd .dw/spec/<slug>/prd.md nao encontrado. Rode /dw-plan prd ou corrija o slug.`
+   - Verifique que `prd.md` existe; senão PARE com: `Alvo de --from-prd .dw/spec/<slug>/prd.md nao encontrado. Rode /dw-plan prd ou corrija o slug.`
    - Crie ou atualize `autopilot-state.json` com `mode: "from-prd"`, `status: "planning"`, `skipped_steps: [1,2,3,4]`, e `skip_reasons["1-4"] = "from-prd-mode"`.
-   - Pule para aprovacao do PRD usando o PRD existente.
-2. Caso contrario:
+   - Pule para aprovação do PRD usando o PRD existente.
+2. Caso contrário:
    - Crie ou atualize `autopilot-state.json` com `mode: "autopilot"`, `status: "planning"`, wish original e `current_step: 1`.
 
-### Etapa 1: Inteligencia do Codebase
+### Etapa 1: Inteligência do Codebase
 
 <critical>Se `.dw/intel/` existir, consulte via `/dw-intel` antes de planejar. Caia para `.dw/rules/` e grep direto se ausente.</critical>
 
-- Identifique stack, padroes existentes, features relacionadas e restricoes do projeto.
-- Se `.dw/intel/` estiver ausente, sugira `/dw-intel --build` para contexto futuro mais rico, mas continue com `.dw/rules/` e inspecao direta.
+- Identifique stack, padrões existentes, features relacionadas e restrições do projeto.
+- Se `.dw/intel/` estiver ausente, sugira `/dw-intel --build` para contexto futuro mais rico, mas continue com `.dw/rules/` e inspeção direta.
 
 ### Etapa 2: Pesquisa (Condicional)
 
-Rode `/dw-brainstorm --research` quando a feature envolver tecnologia nova, dominio desconhecido, APIs externas, regulacao ou arquitetura de alto impacto. Caso contrario, pule e registre o motivo em `skip_reasons`.
+Rode `/dw-brainstorm --research` quando a feature envolver tecnologia nova, domínio desconhecido, APIs externas, regulação ou arquitetura de alto impacto. Caso contrário, pule e registre o motivo em `skip_reasons`.
 
 ### Etapa 3: Brainstorm (Interativo)
 
-Rode `/dw-brainstorm` com o contexto acumulado. Apresente tres direcoes e espere o usuario escolher uma antes de continuar.
+Rode `/dw-brainstorm` com o contexto acumulado. Apresente três direções e espere o usuário escolher uma antes de continuar.
 
 ### Etapa 4: PRD
 
 Rode `/dw-plan prd` usando findings de brainstorm/research.
 
-<critical>O estagio PRD deve usar a ferramenta de entrevista estruturada quando disponivel. Se indisponivel, faca as perguntas obrigatorias no chat e registre o fallback. O usuario deve responder; nao infira respostas.</critical>
+<critical>O estágio PRD deve usar a ferramenta de entrevista estruturada quando disponível. Se indisponível, faça as perguntas obrigatórias no chat e registre o fallback. O usuário deve responder; não infira respostas.</critical>
 
-Depois que `prd.md` existir, apresente resumo do PRD e aguarde aprovacao explicita. Se o usuario pedir edits, atualize e reapresente.
+Depois que `prd.md` existir, apresente resumo do PRD e aguarde aprovação explícita. Se o usuário pedir edits, atualize e reapresente.
 
 ### Etapa 5: TechSpec
 
 Rode `/dw-plan techspec` a partir do PRD aprovado.
 
-<critical>O estagio TechSpec deve usar a ferramenta de entrevista estruturada quando disponivel. Se indisponivel, faca as perguntas obrigatorias no chat e registre o fallback. O usuario deve responder; nao infira respostas.</critical>
+<critical>O estágio TechSpec deve usar a ferramenta de entrevista estruturada quando disponível. Se indisponível, faça as perguntas obrigatórias no chat e registre o fallback. O usuário deve responder; não infira respostas.</critical>
 
-Depois que `techspec.md` existir, apresente resumo do TechSpec e aguarde aprovacao explicita.
+Depois que `techspec.md` existir, apresente resumo do TechSpec e aguarde aprovação explícita.
 
 ### Etapa 6: Tasks
 
 Rode `/dw-plan tasks` a partir de PRD + TechSpec. Verifique:
 - `tasks.md` existe.
 - arquivos per-task existem.
-- `tasks-validation.md` existe e passou ou tem override explicito do usuario.
+- `tasks-validation.md` existe e passou ou tem override explícito do usuário.
 
-### Etapa 7: Aprovacao das Tasks e Parada Obrigatoria
+### Etapa 7: Aprovação das Tasks e Parada Obrigatória
 
-Apresente resumo das tasks, dependencias e esforco total. Aguarde aprovacao explicita.
+Apresente resumo das tasks, dependências e esforço total. Aguarde aprovação explícita.
 
-Apos aprovacao:
+Após aprovação:
 
 1. Salve `.dw/spec/<prd-slug>/autopilot-state.json` com:
 
@@ -137,11 +137,13 @@ Apos aprovacao:
 ```
 
 2. Inclua `completed_steps` para todas as etapas de planejamento completas e `step_artifacts` para `prd.md`, `techspec.md`, `tasks.md`, arquivos per-task e `tasks-validation.md`.
-3. PARE e diga ao usuario que a fase de planejamento esta completa. Nao rode implementacao nesta invocacao.
+3. PARE e diga ao usuário que a fase de planejamento está completa. Não rode implementação nesta invocação.
 
-## Invocacao de Execucao
+## Invocação de Execução
 
-### Etapa 8: Goal Duravel de Execucao
+### Etapa 8: Goal Durável de Execução
+
+Primeiro arme o loop de progresso: invoque `/dw-report` (contrato de auto-arme — idempotente, pulado quando `DW_REPORT_AUTO=off`). Ele reporta feito / fazendo / falta a cada 10 minutos ao longo do goal, do Security Gate, do commit e do PR, e se desarma sozinho com um report final no gate de PR.
 
 Quando `autopilot-state.json status=plan_complete`, invoque formalmente:
 
@@ -149,50 +151,50 @@ Quando `autopilot-state.json status=plan_complete`, invoque formalmente:
 /dw-goal --from-autopilot <prd-slug>
 ```
 
-O goal e dono desta sequencia:
+O goal é dono desta sequência:
 
 1. `/dw-run <prd-path>`
-2. `/dw-review <prd-path>` (review completo: cobertura, qualidade, convencoes, constitution, verify)
+2. `/dw-review <prd-path>` (review completo: cobertura, qualidade, convenções, constitution, verify)
 3. `/dw-qa <prd-path>`
 4. `/dw-qa --fix <prd-path>` se QA encontrou bugs Open
-5. `/dw-review <prd-path>` novamente apos QA/fixes
+5. `/dw-review <prd-path>` novamente após QA/fixes
 6. **Security Gate** — o `/dw-review` pós-QA (passo 5) aciona o `/dw-secure-audit`, produzindo um `.dw/secure-audit/audit-summary.md` fresco. Este passo **garante** que o verdict é APROVADO: se ausente/desatualizado/REPROVADO, rode `/dw-secure-audit <prd-path>` standalone, depois volte pro `/dw-bugfix` por finding e re-cheque. Findings SECRET sempre bloqueiam (sem escape de ADR). Não force um segundo scan completo quando já existe um summary APROVADO fresco.
 
-<critical>Nao substitua os reviews do goal por `/dw-review --coverage-only`. O goal de qualidade do autopilot exige `/dw-review` completo antes do QA e depois dos fixes de QA.</critical>
+<critical>Não substitua os reviews do goal por `/dw-review --coverage-only`. O goal de qualidade do autopilot exige `/dw-review` completo antes do QA e depois dos fixes de QA.</critical>
 
-Depois que `/dw-goal` completar, verifique que `.dw/goals/autopilot-<prd-slug>/status.json` tem `status: "complete"`, entao defina `autopilot-state.json status: "goal_complete"`.
+Depois que `/dw-goal` completar, verifique que `.dw/goals/autopilot-<prd-slug>/status.json` tem `status: "complete"`, então defina `autopilot-state.json status: "goal_complete"`.
 
 ### Etapa 9: Fechar Loop de Bugfix (Condicional)
 
-Se `mode == "from-prd"` e o slug do PRD casar com `prd-bugfix-*`, feche o indice de bugfix antes do commit:
-- Encontre `.dw/bugfixes/*/escalated.md` que referencia o slug do PRD.
-- Se `SUMMARY.md` estiver ausente, escreva usando evidencias disponiveis de PRD, TechSpec, QA e diff com `.dw/templates/bugfix-summary-template.md`.
-- Nunca fabrique evidencia de verificacao.
+Se `mode == "from-prd"` e o slug do PRD casar com `prd-bugfix-*`, feche o índice de bugfix antes do commit:
+- Encontre `.dw/bugfixes/*/escalated.md` que referência o slug do PRD.
+- Se `SUMMARY.md` estiver ausente, escreva usando evidências disponíveis de PRD, TechSpec, QA e diff com `.dw/templates/bugfix-summary-template.md`.
+- Nunca fabrique evidência de verificação.
 - Registre artefatos em `autopilot-state.json`.
 
 ### Etapa 10: Auditoria Pre-Commit
 
 Antes de `/dw-commit`, verifique:
-- `.dw/goals/autopilot-<prd-slug>/status.json` esta completo.
-- `<prd-path>/QA/review-consolidated.md` existe a partir do review final pos-QA.
+- `.dw/goals/autopilot-<prd-slug>/status.json` está completo.
+- `<prd-path>/QA/review-consolidated.md` existe a partir do review final pós-QA.
 - `<prd-path>/QA/qa-report.md` e `<prd-path>/QA/bugs.md` existem.
-- **Security Gate passou:** `.dw/secure-audit/audit-summary.md` existe, esta fresco (pos-ultima-edicao) e status APROVADO. Se ausente/desatualizado/REPROVADO → PARE (nao commite).
+- **Security Gate passou:** `.dw/secure-audit/audit-summary.md` existe, está fresco (pós-última-edição) e status APROVADO. Se ausente/desatualizado/REPROVADO → PARE (não commite).
 - `autopilot-state.json` registra artefatos de planejamento e o goal completo.
 
-Se algo estiver faltando, PARE e re-execute o comando formal ausente. Nao faca commit parcial.
+Se algo estiver faltando, PARE e re-execute o comando formal ausente. Não faça commit parcial.
 
 ### Etapa 11: Commit
 
-Rode `/dw-commit` automaticamente. Nao aguarde aprovacao depois que o goal estiver completo.
+Rode `/dw-commit` automaticamente. Não aguarde aprovação depois que o goal estiver completo.
 
 ### Etapa 12: Gate de Pull Request
 
 Pergunte: **"Commits realizados. Deseja gerar o Pull Request?"**
 
 - SIM: rode `/dw-generate-pr`.
-- NAO: informe que os commits estao prontos e o PR pode ser gerado depois.
+- NÃO: informe que os commits estão prontos e o PR pode ser gerado depois.
 
-Marque `autopilot-state.json status: "completed"` apos commit, e inclua link do PR se gerado.
+Marque `autopilot-state.json status: "completed"` após commit, e inclua link do PR se gerado.
 
 ## Persistencia de Estado
 
@@ -218,7 +220,7 @@ Marque `autopilot-state.json status: "completed"` apos commit, e inclua link do
 }
 ```
 
-Atualize estado depois de cada etapa completa ou pulada. Uma etapa so esta completa depois que artefatos obrigatorios existem.
+Atualize estado depois de cada etapa completa ou pulada. Uma etapa só está completa depois que artefatos obrigatórios existem.
 
 ## Formato de Progresso
 
@@ -236,7 +238,7 @@ Reporte progresso depois de cada etapa:
 ===================================================
 ```
 
-Durante a invocacao de execucao:
+Durante a invocação de execução:
 
 ```text
 === AUTOPILOT =====================================
@@ -248,10 +250,10 @@ Durante a invocacao de execucao:
 
 ## Anti-patterns
 
-- Nao continue para implementacao durante a primeira invocacao.
-- Nao pule `/dw-goal` durante a segunda invocacao.
-- Nao substitua `/dw-review` completo por review mais estreito no goal de execucao.
-- Nao marque estado completo a partir de validacao manual.
-- Nao reexecute planejamento quando `status=plan_complete`; retome o goal.
+- Não continue para implementação durante a primeira invocação.
+- Não pule `/dw-goal` durante a segunda invocação.
+- Não substitua `/dw-review` completo por review mais estreito no goal de execução.
+- Não marque estado completo a partir de validação manual.
+- Não reexecute planejamento quando `status=plan_complete`; retome o goal.
 
 </system_instructions>

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

@@ -181,7 +181,7 @@ Ao final, sempre deixe o usuario em uma destas situacoes:
 - com perguntas melhores para decidir
 - com um proximo comando do workspace para seguir
 - com o one-pager em `.dw/spec/ideas/<slug>.md` (se modo **onepager** disparou)
-- com o relatório de research em `~/Documents/<Tópico>_Research_<data>/` (se modo **research** disparou)
+- com o relatório de research em `.dw/spec/<prd-slug>/research/<topic-slug>-<YYYYMMDD>/research.md` quando houver PRD ativa, `.dw/spec/ideas/<idea-slug>-research-<YYYYMMDD>/research.md` quando houver one-pager de ideia ativo, ou `.dw/spec/research/<topic-slug>-<YYYYMMDD>/research.md` para research avulso (se modo **research** disparou)
 - com o plano de refactor em `<target>/refactor-plan.md` (se modo **refactor-audit** disparou)
 - com entradas de glossário canônico em `.dw/domain/**` e um one-pager de ideia alinhado (se **grill** rodou com autorização)
 - com um protótipo throwaway rodável + template de verdict (se modo **prototype** disparou)
@@ -237,7 +237,7 @@ Skill complementar **`dw-source-grounding`**: **SEMPRE** — aplica protocolo De
 
 ### Output
 
-Salvo em `~/Documents/<Tópico>_Research_<YYYYMMDD>/`. Seções obrigatórias:
+Salve `research.md` dentro do repo: `.dw/spec/<prd-slug>/research/<topic-slug>-<YYYYMMDD>/research.md` quando houver PRD ativa, `.dw/spec/ideas/<idea-slug>-research-<YYYYMMDD>/research.md` quando houver one-pager de ideia ativo, ou `.dw/spec/research/<topic-slug>-<YYYYMMDD>/research.md` para research avulso. Seções obrigatórias:
 1. Sumário Executivo (200-400 palavras)
 2. Introdução (escopo, metodologia, premissas)
 3. Análise Principal (4-8 achados, 600-2000 palavras cada, todos citados)
@@ -365,10 +365,12 @@ Quando esses sinais aparecem no auto-dispatch, **recomende** Grill em uma linha
 
 ### A sessão (após autorização)
 
-1. **Construa a árvore de decisão primeiro.** Antes da primeira pergunta, inspecione os fatos do projeto —
-   PRDs/TechSpecs atuais, `.dw/rules/`, `.dw/intel/` (via `/dw-intel`), `.dw/constitution.md`, `.dw/domain/**` e
-   git recente — e monte uma árvore de decisão **ordenada por dependências** (nunca pergunte uma decisão
-   downstream antes do seu bloqueador).
+1. **Retome ou construa a árvore de decisão primeiro.** Antes da primeira pergunta, leia o one-pager ativo em
+   busca de um **Decision Map** existente. Se houver, retome pelo grafo `Depends on:`, valores de `State`,
+   **Frontier** explícita e `Decision Fog`; não re-pergunte nós já `resolved`. Se não houver mapa, inspecione os
+   fatos do projeto — PRDs/TechSpecs atuais, `.dw/rules/`, `.dw/intel/` (via `/dw-intel`), `.dw/constitution.md`,
+   `.dw/domain/**` e git recente — e monte uma árvore de decisão **ordenada por dependências** (nunca pergunte
+   uma decisão downstream antes do seu bloqueador).
 2. **Pergunte exatamente uma decisão não-resolvida por interação e espere.** Cada pergunta inclui: evidência
    quando disponível (com fonte), a resposta recomendada, uma rationale curta, e uma alternativa/trade-off
    significativa. Siga `dw-grilling` (`references/interview-loop.md`, `references/decision-tree.md`).
@@ -405,9 +407,10 @@ lê e linka `.dw/domain/**` e deve preservá-lo, nunca regenerá-lo.
 
 ### Handoff alinhado — o one-pager de ideia (schema `1.1`)
 
-Grill estende `.dw/spec/ideas/<slug>.md` para o schema `1.1`, adicionando: **Resolved Decisions** (cada uma com a
-resposta recomendada, a escolha do usuário e a alternativa rejeitada), **Evidence** (fatos descobertos com fontes),
-**Canonical Vocabulary** (links para `.dw/domain/**`), **Remaining Decisions** e **Alignment State**.
+Grill estende `.dw/spec/ideas/<slug>.md` para o schema `1.1`, adicionando: **Decision Map** (nós, `Depends on:`,
+`State`, **Frontier** explícita e `Decision Fog` para futuros nós ainda nebulosos), **Resolved Decisions** (cada
+uma com a resposta recomendada, a escolha do usuário e a alternativa rejeitada), **Evidence** (fatos descobertos
+com fontes), **Canonical Vocabulary** (links para `.dw/domain/**`), **Remaining Decisions** e **Alignment State**.
 
 Defina `status: aligned` **só quando todas** valem: cada branch de dependência resolvida, contradições
 glossário/código fechadas, nenhuma decisão bloqueante aberta, E o usuário **confirma explicitamente** o shared

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

@@ -38,7 +38,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-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. Para bugs não triviais, ou depois que a primeira tentativa de fix falhar, o Passo 1 precisa estabelecer um loop de feedback red-capable antes de teorizar. 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
     - `dw-testing-discipline`: use quando a correção requer fluxo E2E/reteste reproduzível em web app — `references/playwright-recipes.md` pra recipes, core rules + 6 agent guardrails pra qualquer teste que o fix adicione, flaky-discipline se o bug aparece de forma intermitente.
@@ -208,6 +208,7 @@
     - Stack traces
     - Arquivos modificados recentemente
     - Se o bug for relacionado a UI ou depender de fluxo no navegador, complemente a coleta com `dw-testing-discipline` (playwright-recipes + three-workflow-patterns pra escolher o modo certo de verificação)
+    - Para bugs não triviais, ou quando a primeira tentativa de fix falhou, construa o loop de feedback red-capable do `dw-debug-protocol` antes de propor uma causa: um comando/artefato de loop, suficientemente determinístico, rápido, executável pelo agente e com vermelho observado. Se nenhum loop executável pelo agente for possível, registre as tentativas e peça ao usuário o artefato/acesso ausente com o template HITL de `references/six-step-triage.md`.
 
     ### 3. Perguntas de Clarificação (OBRIGATÓRIO - EXATAMENTE 3)
 
@@ -322,7 +323,7 @@
     1. Descubra o próximo `NNN` (ver seção Localização dos Arquivos).
     2. Crie `.dw/bugfixes/NNN-<slug>/` se ainda não foi criado no passo 5.0.
     3. Escreva `TASK.md` com a triagem, clarificações, causa raiz e plano aprovado como executado (use `.dw/templates/bugfix-template.md` como base).
-    4. Escreva `fix-report.md` com o VERIFICATION REPORT verbatim do `dw-verify` mais o trace antes/depois da reprodução.
+    4. Escreva `fix-report.md` com o VERIFICATION REPORT verbatim do `dw-verify` mais o trace antes/depois da reprodução. O relatório DEVE incluir `Loop command before fix` e `Loop command after fix` (ou o bloqueio HITL exato, tentativas feitas e artefato/acesso solicitado quando nenhum loop foi possível).
     5. Escreva `SUMMARY.md` usando `.dw/templates/bugfix-summary-template.md`. Preencha slug, data, status `Fixed`, severidade, related_concerns (do passo 1.5), Sintoma (verbatim), Causa Raiz (uma frase), Resolução (2-4 bullets), Arquivos Tocados, Verificação, Relacionado, Followups.
     6. Se o fix tocou uma concern listada em `.dw/rules/concerns.md`, anexe uma linha à coluna `Last incident` da row daquela concern (ou adicione uma row nova sob Histórico de Bugs Conhecidos) — preserve entradas escritas a mão entre `<!-- preserved:start -->`.
     7. Reporte os paths dos três arquivos no chat antes do passo de commit.
@@ -431,6 +432,7 @@
     - [ ] **Máximo 5 arquivos afetados**
     - [ ] **Sem migrations**
     - [ ] **Tarefa de teste incluída (framework correto do projeto)**
+    - [ ] **Loop de bug não trivial registrado: comando antes do fix + comando depois do fix, ou bloqueio HITL com tentativas + artefato/acesso solicitado**
     - [ ] Aguardando aprovação antes de executar
     - [ ] **`.dw/bugfixes/NNN-<slug>/{TASK,fix-report,SUMMARY}.md` escritos após verify PASS**