@brunosps00/dev-workflow 1.0.0 → 1.0.2

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

@@ -706,6 +706,67 @@ Três opções:
 - Nunca escrever `.dw/constitution.md` sem aprovação explícita (opção A) ou escolha explícita (opções B/C).
 - Constitution é commitada ao repositório como qualquer outro artefato do projeto — nunca gitignored.
 
+### Step 9: Geração do Mapa de Concerns (Risk Map)
+
+Depois do passo de constitution, gerar `.dw/rules/concerns.md` — o **mapa de riscos** do projeto. Enquanto `.dw/rules/` descreve como o código É e `.dw/constitution.md` descreve o que ele DEVE SER, o mapa de concerns responde uma terceira pergunta: **onde é perigoso mexer?**
+
+**Diferença dos outros dois:**
+- `.dw/rules/*.md` — analítico (padrões observados).
+- `.dw/constitution.md` — declarativo (princípios comprometidos).
+- `.dw/rules/concerns.md` — risco operacional (fragilidade load-bearing, hot spots, código hostil).
+
+**Comportamento:**
+
+Se `.dw/rules/concerns.md` já existir com entradas escritas a mão entre `<!-- preserved:start -->` e `<!-- preserved:end -->`, preserve essas entradas. Atualize as seções auto-geradas (dados de churn de Hot Spots, Histórico de Bugs Conhecidos a partir de `.dw/bugfixes/`).
+
+Caso contrário (primeira execução), construa o arquivo do zero usando `.dw/templates/concerns-template.md` como base.
+
+**Dados a coletar:**
+
+1. **Hot Spots — análise de churn.** Para cada módulo descoberto no Passo 5, compute a contagem de commits tocando arquivos do módulo nos últimos 90 dias (`git log --since="90 days ago" --name-only -- <module-path> | wc -l`). Módulos no top 20% por churn são candidatos. Cruze com `.dw/bugfixes/` (próximo item) — módulos que também aparecem lá são Hot Spots confirmados; o resto fica como "churn alto — verificar com o time."
+
+2. **Histórico de Bugs Conhecidos — agregação de bugfixes.** Se `.dw/bugfixes/` existir, escaneie todo `SUMMARY.md` dentro. Para cada um, parseie a tabela `Arquivos Tocados`; agregue paths de arquivos pelo módulo top-level (ex: `src/auth/session.ts` -> `src/auth/`). Qualquer módulo com `>= 2` fixes históricos entra na seção Histórico de Bugs Conhecidos com contagem e slugs recentes.
+
+3. **Integrações Frágeis.** Procure padrões delatores no código e config:
+   - Clientes SDK externos com scaffolding de retry/backoff (sugere falhas anteriores).
+   - Comentários como `// FIXME: vendor retorna 200 com body vazio às vezes`, `// HACK: workaround para API legada`, `// TODO: tratar edge case do vendor X`.
+   - Loops de retry artesanais ao redor de fetch/axios/HTTP clients.
+   - Diretório `.dw/incidents/` — todo postmortem de incidente que nomeie um sistema externo entra aqui.
+   Liste esses candidatos. Não fabrique — apenas o que você observar.
+
+4. **Código Hostil.** Heurísticas para código que precisa de entendimento completo antes de modificar:
+   - Regex literais com mais de 80 caracteres sem comentário explicativo.
+   - Funções acima de 100 linhas com complexidade ciclomática que resiste à leitura rápida (heurística aproximada: muitos `if`/`switch`/loops aninhados).
+   - Código manual de transação/locking fora da camada idiomática de um ORM.
+   - Serializadores/parsers custom (ex: JSON, CSV, formatos binários escritos a mão) sem arquivo de teste correspondente.
+   Sinalize candidatos e deixe o usuário confirmar.
+
+5. **Tech Debt — Reconhecida.** Escaneie README, CONTRIBUTING, docs/, e comentários no código por marcadores `TODO`, `FIXME`, `XXX`, `HACK`, `DEPRECATED` com mais de 90 dias (use `git blame` para datar). Agrupe por área. Apresente como candidatos; o usuário decide quais merecem reconhecimento (alguns são comentários velhos, alguns são debt real).
+
+**Procedimento:**
+
+1. **Mostre os candidatos no chat primeiro** (NÃO escreva o arquivo ainda). Formate como tabela markdown por seção com contagem e a evidência mais forte para cada entrada. Limite cada seção a 10 entradas — se mais, liste "+N mais (peça expansão)" e deixe o usuário pedir.
+
+2. Pergunte: "Aprovar como está, descartar entradas específicas (passe os labels das linhas), ou pular esse passo inteiro?" Aguarde resposta explícita.
+
+3. Em caso de aprovação, escreva `.dw/rules/concerns.md` usando `.dw/templates/concerns-template.md`. Preencha:
+   - Frontmatter `last_refreshed: <data ISO de hoje>`.
+   - Tabela de Hot Spots.
+   - Tabela de Integrações Frágeis.
+   - Tabela de Código Hostil.
+   - Tabela de Histórico de Bugs Conhecidos.
+   - Tabela de Tech Debt — Reconhecida.
+
+4. Se existia um bloco `<!-- preserved:start --> ... <!-- preserved:end -->` numa versão anterior, anexe-o de volta ao final do arquivo (as entradas curadas a mão pelo time).
+
+5. Imprima: "Escrito `.dw/rules/concerns.md`. Carregado on-demand por `/dw-plan`, `/dw-run` e `/dw-bugfix` quando o alvo deles tocar uma área listada. Nunca bloqueia — informa, sinaliza e sugere ADR para desvios."
+
+**Caso especial — nenhum sinal encontrado:**
+
+Se após as heurísticas nada cruzar a barra (codebase pequeno, churn baixo, sem incidents, sem histórico de bugfix), escreva um `concerns.md` mínimo com todas as seções vazias (apenas headers) e uma nota: "Nenhum sinal de risco no momento. Re-execute depois que o projeto acumular mais histórico."
+
+**Cadência de refresh:** usuários re-rodam `/dw-analyze-project` quando rules ficam desatualizadas. O Passo 9 atualiza seções auto mantendo entradas preservadas. Não existe comando separado só de refresh.
+
 ## Checklist de Qualidade
 
 - [ ] Estrutura do repositório escaneada
@@ -734,6 +795,9 @@ Três opções:
 - [ ] Exemplos de código reais incluídos
 - [ ] Nenhum secret exposto
 - [ ] Convenções de teste documentadas (framework, padrões, cobertura)
+- [ ] Step 8 (constitution) oferecido e resolvido (A/B/C)
+- [ ] Step 9 (mapa de concerns) apresentou candidatos, aguardou aprovação, escreveu `.dw/rules/concerns.md` (ou anotou que não há sinais)
+- [ ] Blocos com marker preserved em concerns.md mantidos verbatim no refresh
 
 ## Exemplo de Uso
 

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

@@ -44,13 +44,22 @@ Uma etapa que invoca um comando `/dw-xxx` SO e considerada completa quando os ar
 
 | Variavel | Descricao | Exemplo |
 |----------|-----------|---------|
-| `{{WISH}}` | Descricao do que o usuario quer construir | "sistema de notificacoes push com preferencias por canal" |
+| `{{WISH}}` | Descricao do que o usuario quer construir (modo padrao) | "sistema de notificacoes push com preferencias por canal" |
+| `{{PRD_SLUG}}` | Slug do PRD existente para autopilotar a partir dele (quando `--from-prd` e usado) | `prd-bugfix-stripe-webhook-retry` |
+| `{{MODE}}` | Flag opcional de invocacao | `--from-prd <slug>` |
+
+## Modos de Invocacao
+
+| Invocacao | Comportamento |
+|-----------|---------------|
+| `/dw-autopilot "<wish>"` | **Padrao.** Pipeline completo do zero: Codebase Intelligence → Pesquisa → Brainstorm → PRD → TechSpec → Tasks → Run → QA → Review → Commit → PR. |
+| `/dw-autopilot --from-prd <slug>` | **Modo retomada-a-partir-do-PRD.** Pula Etapas 1–4 (Intel, Pesquisa, Brainstorm, PRD). Comeca no GATE 1 (apresenta o PRD existente para aprovacao), depois segue por TechSpec → Tasks → Run → QA → Review → Commit → PR. Usado quando `/dw-bugfix` escalou via seu safety valve e escreveu um PRD em `.dw/spec/<slug>/`, ou quando o usuario redigiu um PRD a mao antes e quer o resto automatizado. |
 
 ## Gates de Aprovacao
 
 O autopilot para APENAS nestes 3 momentos:
 
-1. **GATE 1 — PRD**: Apresenta o PRD gerado e aguarda aprovacao do usuario antes de gerar techspec/tasks
+1. **GATE 1 — PRD**: Apresenta o PRD gerado (modo padrao) ou o PRD existente (modo --from-prd) e aguarda aprovacao do usuario antes de gerar techspec/tasks
 2. **GATE 2 — Tasks**: Apresenta a lista de tasks e aguarda aprovacao antes de iniciar a execucao
 3. **GATE 3 — PR**: Apos commit automatico, pergunta se o usuario quer gerar o Pull Request
 
@@ -66,6 +75,22 @@ Se este comando for re-invocado no mesmo PRD apos interrupcao:
 
 ## Pipeline Completo
 
+### Etapa 0: Resolver modo de invocacao (PRIMEIRA acao obrigatoria)
+
+Antes da Etapa 1, decida qual modo esta em efeito:
+
+1. **Se `--from-prd <slug>` aparece na invocacao:**
+   - Resolva `{{PRD_SLUG}}` para `.dw/spec/<slug>/`.
+   - Verifique que o diretorio existe e contem `prd.md`. Se algum faltar, PARE e reporte: `Alvo de --from-prd .dw/spec/<slug>/prd.md nao encontrado. Rode /dw-plan prd ou corrija o slug.`
+   - Cheque se algum `.dw/bugfixes/*/escalated.md` referencia esse slug. Se sim, anote no bloco de progresso: `Retomando de escalacao de bugfix: <NNN-bugfix-slug> → <slug>`.
+   - Defina `mode: "from-prd"` em `autopilot-state.json` e `skipped_steps: [1, 2, 3, 4]` com `skip_reason: "from-prd-mode"`.
+   - Pule direto para o **GATE 1** (aprovacao do PRD) usando o `prd.md` existente.
+
+2. **Caso contrario (modo padrao):**
+   - Defina `mode: "autopilot"` e prossiga para Etapa 1 normalmente.
+
+<critical>Em modo `--from-prd`, as Etapas 1–4 DEVEM ser marcadas como `skipped_steps` com `skip_reason: "from-prd-mode"`. A auditoria de pre-commit (Etapa 14) DEVE honrar isso — etapa pulada nao e o mesmo que etapa faltando.</critical>
+
 ### Etapa 1: Inteligencia do Codebase
 
 <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>
@@ -104,12 +129,15 @@ Execute `/dw-plan prd` usando os findings do brainstorm.
 
 ### ═══ GATE 1: Aprovacao do PRD ═══
 
+**Em modo padrao:** o PRD acabou de ser escrito na Etapa 4.
+**Em modo `--from-prd`:** o PRD ja existia em disco antes deste run de autopilot comecar (tipicamente redigido por `/dw-bugfix --analise` ou por uma escalacao via safety valve, ou editado a mao).
+
 Apresente ao usuario:
 - Resumo dos requisitos funcionais
-- Decisoes tomadas automaticamente
+- Decisoes tomadas automaticamente (modo padrao) OU nota de origem: "PRD redigido por escalacao do /dw-bugfix em <data>" / "PRD ja existia em disco" (modo --from-prd)
 - Questoes em aberto (se houver)
 
-**Aguarde aprovacao explicita.** Se o usuario pedir mudancas, ajuste e reapresente.
+**Aguarde aprovacao explicita.** Se o usuario pedir mudancas, ajuste e reapresente. Em modo `--from-prd`, edits vao direto para o `.dw/spec/<slug>/prd.md` existente — nao existe rascunho separado.
 
 ### Etapa 5: TechSpec (Interativo — 7+ Perguntas)
 
@@ -216,6 +244,34 @@ Execute `/dw-review --coverage-only` novamente para confirmar que as correcoes d
 Execute `/dw-review --code-only` (Level 3) para review formal.
 - Gere relatorio persistido
 
+### Etapa 13.5: Fechar o loop do bugfix (Condicional)
+
+<critical>Esta etapa roda apenas quando `mode == "from-prd"` E o `prd_path` casa com `.dw/spec/prd-bugfix-*`. Caso contrário pule com `skip_reason: "nao e escalacao de bugfix"`.</critical>
+
+Quando o autopilot está terminando um bugfix que foi escalado por `/dw-bugfix`, a entrada de índice em `.dw/bugfixes/NNN-<slug>/` ainda tem apenas `TASK.md` e `escalated.md` — nenhum `SUMMARY.md` foi escrito porque o fluxo cirúrgico do bugfix nunca chegou ao step 5.5 (o fluxo spec-driven fez o trabalho no lugar). Sem `SUMMARY.md`, o `/dw-intel --build` pula este bugfix para sempre, e queries `bugfix-history` nunca trazem a lição aprendida.
+
+Esta etapa fecha esse loop **antes** da Etapa 14 (Commit) para o SUMMARY cair no mesmo commit do fix.
+
+**Procedimento:**
+
+1. **Encontre a entrada de índice.** Glob em `.dw/bugfixes/*/escalated.md`. Para cada um, leia o conteúdo de uma linha e cheque se referencia o slug do PRD atual (ex: `→ see .dw/spec/prd-bugfix-stripe-webhook-retry/` casa com o PRD ativo `prd-bugfix-stripe-webhook-retry`). O match é o diretório-alvo `NNN-<slug>/`.
+2. **Se nenhum match for encontrado:** o índice de bugfix não espera write-back. Pule silenciosamente e continue para Etapa 14.
+3. **Se `SUMMARY.md` já existir no diretório:** não sobrescreva. Continue para Etapa 14 — humano ou run anterior já fechou o loop.
+4. **Caso contrário, escreva `SUMMARY.md`** usando `.dw/templates/bugfix-summary-template.md`. Origem dos campos:
+   - **Sintoma (verbatim):** seção `Sintoma` de `<prd_path>/prd.md`, ou o primeiro parágrafo do `TASK.md` original se o PRD não carregar.
+   - **Causa Raiz:** seção Causa Raiz do `TASK.md` original.
+   - **Resolução (2–4 bullets):** destilada das decisões em `<prd_path>/techspec.md` + resumo de `git diff <base>...HEAD --stat`.
+   - **Arquivos Tocados:** parseado de `git diff <base>...HEAD --name-only` (exclua paths em `.dw/`). Se >5 arquivos, é esperado para bugfix escalado — liste todos e adicione nota "escalado de bugfix por causa do escopo".
+   - **Verificação:** aponte para `<prd_path>/QA/qa-report.md` e o relatório verify referenciado na saída de sessão da Etapa 9.
+   - **Relacionado — Concerns tocados:** copie das entradas correspondentes em `.dw/rules/concerns.md` se alguma row referenciar módulos em Arquivos Tocados.
+   - **Frontmatter:** `slug: NNN-<slug>`, `created: <data ISO de hoje>`, `status: Fixed`, `severity: <inferida da prioridade do PRD ou Medium default>`, `related_concerns: [lista de cima]`.
+5. **Anexe uma linha final** ao `escalated.md`: `Closed by /dw-autopilot --from-prd on <YYYY-MM-DD>; SUMMARY.md written.` Preserve a linha original da escalação acima.
+6. **Registre o artefato** em `autopilot-state.json` `step_artifacts["13.5"] = [".dw/bugfixes/NNN-<slug>/SUMMARY.md", ".dw/bugfixes/NNN-<slug>/escalated.md"]`.
+
+<critical>NUNCA fabrique evidência de verificação. Se o QA report estiver vazio ou o diff vazio, não invente arquivos em Arquivos Tocados. Escreva as seções do SUMMARY.md que tenham embasamento e marque o resto como `_(não disponível — veja <prd_path>/QA/ para detalhes)_`.</critical>
+
+Após esta etapa, o bugfix se torna visível para `/dw-intel "bugfix history in <module>"` na próxima run de `/dw-intel --build`.
+
 ### Etapa 14: Commit
 
 <critical>AUDITORIA PRE-COMMIT OBRIGATORIA — execute ANTES de invocar `/dw-commit`:
@@ -230,7 +286,7 @@ Rode `ls` em cada caminho abaixo e confirme existencia. Se QUALQUER um faltar, N
 - Evidencia do ultimo `/dw-review --coverage-only` com matriz RF-by-RF (output da sessao ou referencia em `autopilot-state.json`)
 
 Verifique tambem `autopilot-state.json`:
-- Toda etapa de 1 a 13 que NAO esta em `skipped_steps` deve estar em `completed_steps`
+- Toda etapa de 1 a 13 (e 13.5 quando em modo `--from-prd` contra um PRD `prd-bugfix-*`) que NAO esta em `skipped_steps` deve estar em `completed_steps`
 - Cada etapa completada deve ter seus artefatos listados em `step_artifacts`
 
 Se faltar qualquer artefato ou etapa: PARE imediatamente. Reporte ao usuario: `Etapa N nao produziu artefato X — re-executando /dw-[comando]`. Re-execute o comando. Verifique novamente. Soh entao prossiga para `/dw-commit`.
@@ -263,9 +319,11 @@ Salve o arquivo `.dw/spec/prd-[nome]/autopilot-state.json` com o seguinte format
   "mode": "autopilot",
   "wish": "descricao original do usuario",
   "prd_path": ".dw/spec/prd-[nome]",
+  "from_prd_slug": null,
   "current_step": 8,
   "completed_steps": [1, 2, 3, 4, 5, 6, 7],
   "skipped_steps": [2],
+  "skip_reasons": {"2": "dominio ja mapeado em .dw/rules/auth.md"},
   "gates_passed": ["prd", "tasks"],
   "step_artifacts": {
     "9": ["review-matrix-shown-in-session"],
@@ -288,6 +346,7 @@ Salve o arquivo `.dw/spec/prd-[nome]/autopilot-state.json` com o seguinte format
 - Uma etapa SO vai para `completed_steps` apos verificar que seus artefatos existem no disco
 - 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"`
+- Em modo `--from-prd`, defina `from_prd_slug: "<slug>"`, `mode: "from-prd"` e inclua as etapas 1–4 em `skipped_steps` com `skip_reason: "from-prd-mode"` — e isso que a auditoria de pre-commit checa (Etapa 14 verifica que toda etapa NAO listada em `skipped_steps` esta em `completed_steps`)
 
 <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

@@ -11,14 +11,34 @@ Você é um facilitador de brainstorming para o workspace atual. Este comando ex
 ## Posição no Pipeline
 **Antecessor:** (ideia do usuário) | **Sucessor:** `/dw-plan prd`
 
-## Flags
+## Como este comando funciona (auto-dispatch, não switchboard de flags)
 
-- **(padrão)**: brainstorm normal com 3-7 opções (conservadora, equilibrada, ousada) e trade-offs. Se o produto tem PRDs ou rules, **Product Inventory** é produzido automaticamente e cada opção recebe tag de classificação.
-- **`--onepager`**: ao final do brainstorm, gera one-pager durável em `.dw/spec/ideas/<slug>.md` (usando `.dw/templates/idea-onepager.md`) com Feature Inventory + Classification & Rationale + MVP Scope + Not Doing + Assumptions. Use quando quiser artefato persistido antes de seguir para `/dw-plan prd`.
-- **`--council`**: após o brainstorm normal, invoca a skill `dw-council` para stress-test das top 2-3 opções através de 3-5 archetypes (pragmatic-engineer, architect-advisor, security-advocate, product-mind, devils-advocate). Útil quando a escolha é de alto impacto e há genuine dissent entre caminhos.
-- **`--research`**: modo de research multi-source. Pipeline: scope → plan → retrieve (sources paralelos) → triangulate → outline-refine → synthesize → critique → refine → report. Output: documento citado. Use pra state-of-the-art reviews, comparações de tech, regulatory landscape mapping. Sub-modos: `quick` (3 fases, 2-5min), `standard` (default, 6 fases, 5-10min), `deep` (8 fases, 10-20min), `ultradeep` (8+ fases, 20-45min).
-- **`--refactor`**: modo catálogo de code smells. Audita um diretório-alvo ou escopo de PRD por smells usando taxonomia de Martin Fowler (bloaters, change preventers, dispensables, couplers, complexidade condicional, violações DRY). Mapeia cada smell pra técnica de refactoring com sketches before/after. Plano severity-ordered P0-P3. Output: documento de oportunidades de refactor.
-- Flags combináveis onde faz sentido: `--onepager --council` produz one-pager após debate. `--research --onepager` salva research como one-pager durável. `--refactor --onepager` salva plano de refactor como one-pager. `--research --refactor` NÃO suportado (escolha um — surfaces de ideação diferentes).
+`/dw-brainstorm` roda **FULL** por padrão. Abre com uma fase de **Signal Reading** que inspeciona o pedido do usuário, o estado do projeto (PRDs, rules, intel, commits recentes) e a conversa até agora, e então **dispara um ou mais modos internos**. O usuário não escolhe o modo — o comando escolhe.
+
+Modos internos (o dispatcher seleciona 1+):
+
+| Modo | Dispara automaticamente quando |
+|------|--------------------------------|
+| **option-matrix** (default sempre ativo) | Surface padrão: 3-7 opções (conservadora / equilibrada / ousada) com tags `[IMPROVES] / [CONSOLIDATES] / [NEW]`. Sempre roda salvo override explícito. |
+| **grill** | Vocabulário está instável — termos do usuário divergem de `.dw/rules/` / `.dw/constitution.md`, ou dois sinônimos competem na mesma conversa, ou alguém propõe um nome que conflita com o glossário. |
+| **prototype** | Usuário pergunta "esse modelo de estado faz sentido?" / "como isso deveria parecer?" sem resposta clara; ou o próximo passo razoável é RODAR código, não escrever palavras. |
+| **council** | Duas ou mais abordagens competem sem vencedor óbvio; ou o consenso se forma rápido demais (sinal de false-consensus). |
+| **research** | A pergunta depende de state-of-the-art externo ("qual é a best practice atual para X", comparações multi-fonte, landscape regulatório ou de framework). |
+| **refactor-audit** | Usuário aponta um diretório ou descreve uma área como "bagunçada", "precisa de limpeza", "tech debt"; ou pede health-check trimestral. |
+| **onepager** | A conversa convergiu o suficiente para merecer um artefato durável (`.dw/spec/ideas/<slug>.md`); ou o usuário sinaliza que vai chamar `/dw-plan prd` em seguida. |
+
+Modos podem encadear numa sessão — grill pode revelar uma pergunta de design que o dispatcher manda para prototype; refactor-audit pode produzir findings que o dispatcher manda para council pra stress-test.
+
+### Overrides opcionais (raramente necessários)
+
+- **`--mode=<nome>`** — força um dispatch específico e pula Signal Reading. Nomes: `option-matrix`, `grill`, `prototype`, `council`, `research`, `refactor-audit`, `onepager`. Combine com `+` para encadear explicitamente: `--mode=grill+onepager`.
+- **`--quiet`** — pula Signal Reading inteiramente e roda apenas `option-matrix` como facilitador mínimo.
+
+Power users que já sabem o que querem podem passar `--mode=`. Todo mundo mais ganha auto-dispatch por padrão — o comando lê a situação e age.
+
+### Nota de migração (transitória)
+
+Invocações antigas com flags (`--onepager`, `--council`, `--research`, `--refactor`, `--grill`, `--prototype`) continuam aceitas por um ciclo minor e mapeiam para o `--mode=` equivalente. Código novo deve usar `--mode=` ou confiar no auto-dispatch.
 
 ## Fluxograma de Decisão: Brainstorm vs PRD Direto
 
@@ -42,15 +62,16 @@ digraph brainstorm_decision {
 
 Quando disponíveis no projeto em `./.agents/skills/`, use para enriquecer a ideação:
 
-- `dw-council` (opt-in via `--council`): stress-test multi-advisor das opções mais promissoras com steel-manning obrigatório e concession tracking. **NÃO invocar por padrão** — só quando a flag está presente ou quando surge consenso rápido demais (sinal de false consensus).
-- `dw-ui-discipline`: use quando o brainstorm envolver frontend ou direção de UI — o hard-gate (scene sentence, surface job) é forcing function generativa durante ideação, não só check de review
-- `vercel-react-best-practices`: use quando explorar arquitetura React/Next.js ou trade-offs de performance
-- `security-review`: use quando o brainstorm tocar auth, manipulação de dados ou features sensíveis à segurança
+- `dw-council`: invocada pelo modo **council** do dispatcher — stress-test multi-advisor das opções mais promissoras com steel-manning obrigatório e concession tracking. O dispatcher dispara quando 2+ caminhos empatam OU consenso se forma rápido demais (sinal de false-consensus). Não roda em todo brainstorm — só quando os sinais justificam.
+- `dw-simplification`: invocada pelo modo **refactor-audit** — aplica Chesterton's Fence + métricas de complexidade + a nova referência **deep-modules** (deletion test, locality, leverage, interface depth) em todo smell flagueado.
+- `dw-ui-discipline`: use quando o brainstorm envolver frontend ou direção de UI — o hard-gate (scene sentence, surface job) é forcing function generativa durante ideação, não só check de review. Também usado pelo branch UI do modo **prototype**.
+- `vercel-react-best-practices`: use quando explorar arquitetura React/Next.js ou trade-offs de performance.
+- `security-review`: use quando o brainstorm tocar auth, manipulação de dados ou features sensíveis à segurança.
 
 ## Referência do Template
 
 - Template da matriz de brainstorm: `.dw/templates/brainstorm-matrix.md` (relativo ao workspace root)
-- Template do one-pager durável: `.dw/templates/idea-onepager.md` (usado com flag `--onepager`)
+- Template do one-pager durável: `.dw/templates/idea-onepager.md` (usado pelo modo **onepager**)
 
 Use este comando quando o usuario quiser:
 - gerar ideias para produto, UX, arquitetura ou automacao
@@ -63,6 +84,19 @@ Use este comando quando o usuario quiser:
 
 <critical>O brainstorm é fase **nível de produto**, não técnica. NÃO entre em arquitetura, stack, endpoints, schemas. Isso é trabalho do techspec. Aqui trabalhamos jornada do usuário, valor, features e fronteiras.</critical>
 
+### 0. Signal Reading (sempre primeiro, exceto com `--quiet` ou `--mode=` explícito)
+
+Antes de produzir qualquer output, **leia a situação**:
+
+1. Inspecione `.dw/spec/prd-*/`, `.dw/rules/`, `.dw/constitution.md`, `.dw/intel/` se existirem. Anote vocabulário atual e PRDs recentes.
+2. Inspecione git recente (`git log --oneline -20`) pra detectar trabalho em andamento.
+3. Releia o pedido do usuário contra a tabela de Auto-Dispatch no topo desse arquivo. Casa sinais com modos.
+4. Decida o dispatch: **option-matrix** sempre roda salvo override que pule. Outros modos (grill, prototype, council, research, refactor-audit, onepager) disparam **aditivamente** quando seus sinais estão presentes.
+5. Diga ao usuário em uma linha curta qual o dispatch decidido: ex. "Dispatch: option-matrix + onepager (PRD está um passo à frente)" ou "Dispatch: grill (vocabulário instável no PRD atual)". Não esconda — surface antes de rodar.
+6. Depois, execute os modos nessa ordem (quando encadeados): grill → research → option-matrix → council → refactor-audit → prototype → onepager. Pule modos fora do dispatch.
+
+### Fluxo padrão (modo option-matrix)
+
 1. Comece resumindo o problema em 1 a 3 frases.
 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)**:
@@ -80,7 +114,7 @@ Use este comando quando o usuario quiser:
    - nível de esforço aproximado
 7. Sempre que fizer sentido, inclua alternativas conservadora, equilibrada e ousada.
 8. Feche com recomendação pragmática e próximos passos claros.
-9. **Se a flag `--onepager` estiver presente**: ao final, gerar `.dw/spec/ideas/<slug>.md` usando `.dw/templates/idea-onepager.md`, preenchendo Feature Inventory, Classification & Rationale, Recommended Direction (linguagem de produto), MVP Scope (user stories), Not Doing, Key Assumptions e Open Questions. Apresentar path ao usuário ao final.
+9. **Se o dispatcher selecionou o modo `onepager`** (auto-dispara quando a conversa converge ou usuário sinaliza que vai pra `/dw-plan prd`): ao final, gerar `.dw/spec/ideas/<slug>.md` usando `.dw/templates/idea-onepager.md`, preenchendo Feature Inventory, Classification & Rationale, Recommended Direction (linguagem de produto), MVP Scope (user stories), Not Doing, Key Assumptions e Open Questions. Apresentar path ao usuário ao final.
 
 ## Formato de resposta preferido
 
@@ -104,7 +138,7 @@ Use este comando quando o usuario quiser:
 - recomende 1 ou 2 caminhos
 - diga por que eles vencem no contexto atual
 
-### 6. One-pager (se `--onepager`)
+### 6. One-pager (se modo `onepager` disparou)
 - path do arquivo criado em `.dw/spec/ideas/<slug>.md`
 
 ### 7. Próximos passos
@@ -141,13 +175,15 @@ Ao final, sempre deixe o usuario em uma destas situacoes:
 - com uma recomendacao clara (incluindo classificação IMPROVES/CONSOLIDATES/NEW)
 - com perguntas melhores para decidir
 - com um proximo comando do workspace para seguir
-- com o one-pager em `.dw/spec/ideas/<slug>.md` (se `--onepager` foi usado)
-- com o relatório de research em `~/Documents/<Tópico>_Research_<data>/` (se `--research`)
-- com o plano de refactor em `<target>/refactor-plan.md` (se `--refactor`)
+- 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 plano de refactor em `<target>/refactor-plan.md` (se modo **refactor-audit** disparou)
+- com entradas de glossário sharpened em `.dw/rules/` (se modo **grill** disparou)
+- com um protótipo throwaway rodável + template de verdict (se modo **prototype** disparou)
 
-## Modo: `--research` (research multi-fonte)
+## Modo: research (research multi-fonte)
 
-Ativado pela flag `--research`. Substitui o brainstorm padrão por um pipeline estruturado de research que produz documento citado com claims verificados.
+Dispara quando a pergunta depende de state-of-the-art externo (comparações multi-fonte, framework/regulatory landscape, decisões precisando de evidência citada). Override: `--mode=research`. Substitui o option-matrix padrão por um pipeline estruturado de research que produz documento citado com claims verificados.
 
 <critical>Cada afirmação factual DEVE ser citada imediatamente com [N] na mesma frase</critical>
 <critical>NUNCA fabrique citações — se não encontrar fonte, diga explicitamente</critical>
@@ -165,7 +201,7 @@ Ativado pela flag `--research`. Substitui o brainstorm padrão por um pipeline e
 ```
 Seleção
 ├── Exploração inicial → quick (3 fases, 2-5 min)
-├── Research padrão → standard (6 fases, 5-10 min) [DEFAULT pra --research]
+├── Research padrão → standard (6 fases, 5-10 min) [DEFAULT pra research]
 ├── Decisão crítica → deep (8 fases, 10-20 min)
 └── Review abrangente → ultradeep (8+ fases, 20-45 min)
 ```
@@ -216,9 +252,9 @@ Tamanhos-alvo: quick 2-4k palavras; standard 4-8k; deep 8-15k; ultradeep 15-20k+
 - Rotular especulação explicitamente.
 - Admitir incerteza: "Sem fontes encontradas para X."
 
-## Modo: `--refactor` (catálogo de code smells)
+## Modo: refactor-audit (catálogo de code smells + deep-modules)
 
-Ativado pela flag `--refactor`. Audita uma área-alvo do codebase por oportunidades de refactoring usando taxonomia de smells de Martin Fowler.
+Dispara quando o usuário aponta um diretório ou descreve uma área como "bagunçada" / "precisa de limpeza" / "tech debt", ou pede health-check trimestral. Override: `--mode=refactor-audit`. Audita a área-alvo por oportunidades de refactoring usando a taxonomia de smells de Martin Fowler combinada com a análise deep-modules (deletion test, locality, leverage, interface depth) embutida na skill `dw-simplification`.
 
 <critical>FAÇA EXATAMENTE 3 PERGUNTAS DE CLARIFICAÇÃO ANTES DE INICIAR ANÁLISE</critical>
 
@@ -292,6 +328,111 @@ Salvo em `<target>/refactor-plan.md`:
 - Propor refactors sem teste ou não-testáveis → alto risco, não shippa.
 - Ignorar decisões arquiteturais documentadas em `.dw/rules/` → flagar design intencional como smell.
 
+## Modo: grill (domain-grilling)
+
+Dispara quando o vocabulário está instável — termos do usuário divergem de `.dw/rules/` / `.dw/constitution.md`, dois sinônimos competem, ou alguém propõe um nome que conflita com o glossário. Override: `--mode=grill`. Substitui o option-matrix por um **stress-test estilo entrevista** do plan/PRD contra o vocabulário do projeto. Cada rodada sharpens um pedaço. Atualiza `.dw/rules/` (ou `.dw/constitution.md`) inline conforme termos cristalizam — nunca adia pra "depois da conversa".
+
+<critical>Pergunte UMA pergunta de cada vez. Espere a resposta. Não despeje 5 perguntas e torça pelo melhor.</critical>
+
+### Quando usar grill mode
+
+- Antes de `/dw-plan prd` quando o domínio parece instável ou o time usa termos competindo.
+- Depois de `/dw-plan prd` quando reviewers flagam linguagem ambígua no PRD.
+- Durante discussão de arquitetura quando "módulo", "serviço", "componente" são usados de forma intercambiável e precisa fixar o termo canônico.
+- Quando alguém propõe um nome que não combina com o glossário existente do projeto.
+
+### Disciplinas durante a sessão
+
+1. **Desafie contra o glossário.** Leia `.dw/rules/index.md` + `.dw/rules/<modulo>.md` + `.dw/constitution.md`. Flague conflitos de terminologia no instante em que o usuário usa um termo que diverge do que já está documentado.
+
+2. **Sharpen linguagem vaga.** Quando o usuário disser "a coisa do user" ou "aquele lance de pedidos", proponha um termo canônico preciso. Não finja que entendeu — empurre de volta.
+
+3. **Discuta cenários concretos.** Force precisão com edge cases específicos: "O que acontece com a Order no estado X quando o evento Y chega durante o retry Z?" Respostas vagas voltam como mais perguntas.
+
+4. **Cross-reference o código.** Quando o usuário afirmar um comportamento, olhe rápido no codebase pra confirmar. Surface contradições: "Você disse que a API retorna `OrderId` mas `src/api/orders.ts:42` retorna `{ order_id, status }`." Não argumente em generalidades.
+
+5. **Atualize `.dw/rules/` inline.** Quando um termo cristaliza, escreva no arquivo de rules apropriado no mesmo turn da conversa. Lazy file creation: se o arquivo não existir, crie. Formato segue a disciplina de glossário do projeto (ver `.dw/rules/index.md`).
+
+6. **Pule detalhe de implementação no glossário.** `.dw/rules/` e `.dw/constitution.md` descrevem vocabulário e princípios — não implementação. "Order: pedido de um cliente para comprar itens, em um destes estados: pending, paid, shipped, delivered, refunded" é bom. "Order: uma classe TypeScript em `src/orders/`" é vazamento de implementação.
+
+### Disciplina de criação de ADR
+
+Só proponha um ADR via `/dw-adr` quando **todos os três** valem:
+
+| Critério | Teste |
+|----------|-------|
+| **Difícil de reverter** | Se mudarmos em 6 meses, custa >1 semana de trabalho? |
+| **Surpreendente sem contexto** | Um novo contribuinte chegaria razoavelmente a uma decisão diferente? |
+| **Trade-off real** | Havia uma alternativa real considerada e descartada? |
+
+Se algum falta, pule o ADR. Não ADR toda decisão casual — vira ruído na pasta de ADRs.
+
+### Output
+
+O modo grill produz:
+- **`.dw/rules/<modulo>.md` ou `.dw/constitution.md` atualizado** com termos cristalizados.
+- **PRD / TechSpec atualizado** se grill rodou no meio do planejamento (termos alinhados com o glossário).
+- **`.dw/spec/<prd>/adrs/adr-NNN.md` opcional** se os critérios acima valem.
+- **NÃO** produz option matrix ou recomendação (esse é o option-matrix; grill é só sharpening). Se o dispatcher encadeou grill+option-matrix, o option matrix roda em fase separada.
+
+### Quando a disciplina dobra
+
+- **Projeto greenfield sem `.dw/rules/`**: grille mesmo assim; a conversa produz as PRIMEIRAS entradas em `.dw/rules/index.md`. Isso é o valor.
+- **Discordância cosmética de terminologia** ("usamos `userId` ou `user_id`?"): pule grill mode; use ADR de convenção de código ou seção Naming em `.dw/rules/index.md`.
+
+## Modo: prototype (protótipo descartável)
+
+Dispara quando o usuário pergunta "esse modelo de estado faz sentido?" / "como isso deveria parecer?" sem resposta clara — i.e., o próximo passo razoável é RODAR código, não escrever palavras. Override: `--mode=prototype`. Constrói um **protótipo descartável que responde a uma única pergunta**. A pergunta decide a forma — escolha um branch.
+
+<critical>O protótipo é descartável desde o dia um. Não polir. Não adicionar testes. Não extrair abstrações. O ponto é APRENDER algo rápido e depois DELETAR ou absorver.</critical>
+
+### Escolha um branch
+
+| Pergunta do usuário | Branch |
+|---------------------|--------|
+| "Esse modelo de state/logic faz sentido?" | **LOGIC** — terminal app interativo que empurra a máquina de estado por edge cases difíceis de raciocinar no papel. |
+| "Como isso deveria parecer?" | **UI** — várias variações radicalmente diferentes de UI num único route, toggleable por search param e bottom bar flutuante. |
+
+Se a pergunta é ambígua, pergunte ao usuário. Se não puder alcançar: default pelo contexto (módulo backend → LOGIC; página/componente → UI) e declare a suposição no topo do protótipo.
+
+### Regras (valem para os dois branches)
+
+1. **Descartável desde o dia um, claramente marcado.** Coloque o protótipo perto do módulo/página que ele está prototipando (pra contexto) mas nomeie pra que um leitor casual veja que é protótipo (`prototype-<slug>.ts`, `prototype-route.tsx`, etc.).
+
+2. **Um comando pra rodar.** Qualquer que seja o task runner do projeto — `pnpm <nome>`, `python <path>`, `bun <path>`, etc. O usuário tem que rodar sem pensar.
+
+3. **Sem persistência por padrão.** Estado vive em memória. Persistência é o que o protótipo está VERIFICANDO, não algo do qual depende. Se a pergunta envolve banco, use um DB scratch ou arquivo local com nome claro `PROTOTYPE — wipe me`.
+
+4. **Pule o polish.** Sem testes, sem error handling além do mínimo pro protótipo rodar, sem abstrações.
+
+5. **Surface o estado.** Depois de cada ação (LOGIC) ou troca de variante (UI), imprima ou renderize o estado relevante completo pro usuário ver o que mudou.
+
+6. **Delete ou absorva quando terminar.** Quando o protótipo respondeu sua pergunta, ou delete ou dobre a decisão validada em código real. Não deixe apodrecendo no repo.
+
+### Quando terminar
+
+A **resposta** é a única coisa que vale guardar. Capture duravelmente:
+- Commit message fechando o protótipo: "removed prototype X; decided <resposta> based on <observação>"
+- Ou um ADR (se os critérios do grill valem)
+- Ou `.dw/spec/<prd>/NOTES.md` se mid-PRD
+- Ou comentário em issue se user-driven
+
+Se o usuário não está por perto, deixe um placeholder `PROTOTYPE VERDICT: <pending>` pro próximo pass preencher antes da deleção.
+
+### Output
+
+O modo prototype produz:
+- **Arquivo(s) de código descartável** na localização apropriada.
+- Um `NOTES.md` ao lado do protótipo com a PERGUNTA que está respondendo.
+- Depois do usuário rodar e responder a pergunta, instruções pra remover o protótipo + capturar o verdict.
+
+### Anti-patterns
+
+- Construir protótipo que é feature disfarçada — código production-quality, testes, deploy config. Isso não é protótipo; é primeiro draft.
+- Deixar o protótipo no repo "por via das dúvidas" — seis meses depois é load-bearing.
+- Não capturar o verdict — protótipo respondeu a pergunta e a resposta evaporou.
+- Múltiplos protótipos empilhados — escolha uma pergunta, responda, mova.
+
 ## Inspired by
 
 O padrão de codebase-grounded idea refinement é inspirado em [`addyosmani/agent-skills@idea-refine`](https://skills.sh/addyosmani/agent-skills/idea-refine) (Addy Osmani, Google — 1.4K+ installs). Adaptações para o dev-workflow:
@@ -301,6 +442,8 @@ O padrão de codebase-grounded idea refinement é inspirado em [`addyosmani/agen
 - Output em `.dw/spec/ideas/<slug>.md` (irmão de `prd-<slug>/`) em vez de `docs/ideas/` — mantém a convenção de paths do dev-workflow.
 - Integração com o pipeline existente: `/dw-plan prd` aceita o one-pager como input, reduzindo perguntas de clarificação.
 
-Crédito: Addy Osmani e o padrão `idea-refine`.
+Os modos **grill** e **prototype** são adaptados de [`mattpocock/skills/grill-with-docs`](https://github.com/mattpocock/skills/tree/main/grill-with-docs) e [`mattpocock/skills/prototype`](https://github.com/mattpocock/skills/tree/main/prototype) (Matt Pocock, MIT). Adaptação dev-workflow: integrados como modos INTERNOS auto-dispatchados em vez de skills separadas, paths rebaseados em `.dw/rules/` + `.dw/spec/<prd>/`, criação de ADR gated no teste 3-critérios (difícil de reverter + surpreendente + trade-off real).
+
+Crédito: Addy Osmani (idea-refine) e Matt Pocock (grill-with-docs, prototype).
 
 </system_instructions>