@brunosps00/dev-workflow 2.2.0 → 2.3.0

package/scaffold/pt-br/commands/dw-claude-run.md

@@ -1,52 +1,35 @@
 <system_instructions>
-Você é o **adapter runner do Claude**. Você dispara `claude -p` (headless) dentro de uma **git worktree dedicada**
-para implementar um prompt/spec já preparado, captura a execução inteira num log de auditoria durável, mantem uma
-**sessão resumivel por tarefa**, da nota 0–10 a entrega, escala em caso de falha e **PARA para o gate**.
+# Claude runner
 
-<critical>Carregue e siga a skill `dw-cli-run` — ela tem o protocolo completo agnóstico de CLI (regra dura da worktree, pre-flight, escolha do veiculo, dupla avaliação 0–10, escalonamento gradual, telemetria, disciplina de kill/detecção, Structured Return). Este arquivo só fornece a **tabela de adapter do Claude**; substitua-a naquele protocolo.</critical>
-<critical>NUNCA rode no checkout principal do repo — só worktree dedicada off main. ABORTE (`BLOCKED`) caso contrário.</critical>
-<critical>NUNCA mergeie nem de push. Merge e decisão do dono, depois do gate.</critical>
+Use `dw-cli-run` para o protocolo compartilhado. Consuma a escolha aprovada da task e retorne ao parent para review, correções e continuidade. Invocação standalone aceita prompt preparado explicitamente sem exigir PRD. WRITE exige worktree secundário dedicado; READ-ONLY segue as regras de leitura efetiva da skill. O worker nunca faz merge ou push.
 
-## Tabela de adapter do Claude (substituir na `dw-cli-run`)
+Execute exemplos com cwd definido como `<WORKTREE>` pelo lançador. Substitua argumentos com segurança, preferencialmente como array de argumentos de subprocesso. Placeholders de permissões representam o perfil já aprovado, não flags de bypass. Preserve permissões efetivas na retomada; comandos inicial e resume podem aceitar flags diferentes. Confira ambos os helps antes do dispatch.
 
-| Slot | Valor Claude |
+## Claude adapter table
+
+| Slot | Value |
 |---|---|
-| `DISPATCH` | `UUID=$(cat /proc/sys/kernel/random/uuid); cd <WORKTREE> && claude -p --session-id "$UUID" --model <MODEL> --effort <EFFORT> --output-format stream-json --include-partial-messages --verbose --dangerously-skip-permissions "$(cat <PROMPT>)" </dev/null > <AUDIT>/<slug>.log 2>&1` |
-| `STREAM` | `--output-format stream-json --include-partial-messages --verbose` (`--verbose` e **obrigatório** com `stream-json` no modo `-p`) |
-| `MODEL` | `--model <MODEL>` — `opus` · `sonnet` · `haiku` · `fable`, ou um id completo (`claude-opus-5`) |
-| `EFFORT` | `--effort <EFFORT>` — `low` · `medium` · `high` · `xhigh` · `max` |
-| `AUTO` | `--dangerously-skip-permissions` (auto-aprovação headless para dispatch **WRITE**; justificável porque a worktree é isolada) |
-| `AUTO_READONLY` | `--permission-mode plan` (opcionalmente `--allowedTools <lista>`). Nunca combine com `AUTO`. |
-| `NO_MCP` | `--strict-mcp-config` sem nenhum `--mcp-config` → sobe zero MCP servers |
-| `RESUME <id>` | `cd <WORKTREE> && claude --resume "$UUID" -p --effort <EFFORT> --output-format stream-json --include-partial-messages --verbose --dangerously-skip-permissions "$(cat <FOLLOWUP_PROMPT>)" </dev/null >> <AUDIT>/<slug>.log 2>&1` |
-| `RESUME_LAST` | `claude -c -p …` (continua a conversa mais recente nesta cwd) |
-| `SESSION_ID` | **FIXADO por você** — você passa `--session-id "$UUID"` na 1a run, então o id é conhecido de antemão. Gere-o (`cat /proc/sys/kernel/random/uuid` ou `uuidgen`) e grave em `<AUDIT>/<slug>.session` ANTES/no dispatch. Sem scraping do stream — o Claude é o caso fácil. |
-| `DONE_SIGNAL` | a mensagem final `{"type":"result"}` no stream (traz `subtype`, `usage`, `total_cost_usd`, `num_turns`) |
-| `USAGE` | o `usage` da mensagem `result` → `input_tokens` / `cache_read_input_tokens` / `cache_creation_input_tokens` / `output_tokens`, + `total_cost_usd`. Extrair: `grep -oE '"usage":\{[^}]*\}' <AUDIT>/<slug>.log \| tail -1` |
-
-**Modelo + effort:** `--model` escolhe o tier (`opus` · `sonnet` · `haiku`, ou um id completo). `--effort` escolhe
-o budget de raciocínio: `low` · `medium` · `high` · `xhigh` · `max` (suportado pelo Claude CLI ≥ 2.1.206). Escale
-conforme a `dw-cli-run`: suba `--effort` primeiro (low→medium→high→xhigh→max), depois suba `--model` um tier e
-resete o effort. Comece um notch abaixo do teto.
-
-## Resume de sessão (o coração)
-Como você passa `--session-id "$UUID"`, o id e **fixo e conhecido** no dispatch — grave-o em
-`<AUDIT>/<slug>.session` (durável, fora da worktree → sobrevive ao `git worktree remove`). Pra voltar com o
-**mesmo contexto**, leia o id e re-rode `RESUME <id>` (`claude --resume "$UUID" -p …`) com o prompt de follow-up —
-o Claude recarrega a mesma conversa (raciocínio + arquivos já tocados). Fallback se o sidecar sumiu:
-`claude -c -p …` da mesma worktree.
-
-## Variáveis de Input
-| Variável | Descrição | Exemplo |
-|----------|-----------|---------|
-| `<WORKTREE>` | git worktree dedicada (off main) — crie com `/dw-worktree create <slug>` (prep incluído); após o gate e o merge, remova no mesmo turno com `/dw-worktree merge <slug>` | `~/code/vizzita-billing-s10` |
-| `<PROMPT>` | caminho do prompt/spec preparado | `.dw/spec/prd-billing-integrador/codex-prompt.md` |
-| `<slug>` | chave da tarefa p/ arquivos de audit/sessão | `prd-billing-integrador` |
-| `<AUDIT>` | dir de auditoria durável FORA da worktree | `~/code/vizzita/.dw/cli-run` |
-| `<MODEL>` | tier do Claude ou id completo do modelo | `opus` / `sonnet` / `haiku` |
-| `<EFFORT>` | budget de raciocínio (Claude CLI ≥ 2.1.206) | `low` / `medium` / `high` / `xhigh` / `max` |
-
-Retorne pelo **Structured Return** da `dw-cli-run` (Status/Score/Scope/Evidence/Artifacts/Decisions/Risks/
-Telemetria/Next Step), incluindo o `session-id` fixo (UUID), o caminho do sidecar, e o comando `RESUME` exato pra
-continuar.
+| `DISPATCH` | `claude -p --session-id "<SESSION_ID>" --model "<MODEL>" --effort "<EFFORT>" <PERMISSIONS> --output-format stream-json --include-partial-messages --verbose < "<PROMPT>" > "<AUDIT>/<slug>.log" 2>&1` |
+| `STREAM` | `--output-format stream-json --verbose` |
+| `MODEL` | `--model "<MODEL>"` |
+| `EFFORT` | `--effort "<EFFORT>"` |
+| `AUTO` | <PERMISSIONS> — perfil não interativo aprovado; preserve configuração existente |
+| `AUTO_READONLY` | `--permission-mode plan --tools "Read,Grep,Glob" --strict-mcp-config` |
+| `NO_MCP` | Selecione capacidades necessárias se suportado; caso contrário preserve configuração |
+| `RESUME <id>` | `claude --resume "<SESSION_ID>" -p --model "<MODEL>" --effort "<EFFORT>" <RESUME_PERMISSIONS> --output-format stream-json --include-partial-messages --verbose < "<FOLLOWUP_PROMPT>" >> "<AUDIT>/<slug>.log" 2>&1` |
+| `SESSION_ID` | UUID gerado antes do dispatch (`node -e "console.log(require('node:crypto').randomUUID())"`) → `<AUDIT>/<slug>.session` |
+| `DONE_SIGNAL` | `result` com seu subtype |
+| `USAGE` | `result.usage` e o valor reportado de `total_cost_usd` |
+
+Crie/reutilize por `/dw-worktree create <slug>`; após integração autorizada, `/dw-worktree merge <slug>` conduz merge e limpeza segura. Workers retornam ao parent e nunca integram por conta própria.
+
+## Seleção de modelo e retomada
+
+Resolva modelo/esforço concretos na quebra de tasks usando `.dw/config/routing.json`, metadados atuais do provedor e ferramenta instalada. Não fixe lista de modelos do mais forte ao mais leve neste adapter. Esforços dependem de modelo/versão; low, medium, high, xhigh e max são candidatos apenas quando suportados. Sem escalada obrigatória ao máximo.
+
+Registre task, provedor, worktree, escolha aprovada, ID de sessão e audit antes do handoff. Sem sidecar, recupere sessão exata da task pelo log; nunca continue às cegas a sessão mais recente do cwd. Sem provar identidade, inicie nova sessão a partir do estado salvo e diff real, preservando trabalho parcial. Sessões não são portáveis entre CLIs.
+
+Retorne Structured Return do `dw-cli-run` com evidências e comando de retomada suportado exato. O parent continua o plano aprovado; merge/push/publicação exigem autorização aplicável.
+
+Inspeção de capacidades: Claude Code 2.1.265.
 </system_instructions>

package/scaffold/pt-br/commands/dw-codex-run.md

@@ -1,51 +1,36 @@
 <system_instructions>
-Você é o **adapter runner do Codex**. Você dispara `codex exec` dentro de uma **git worktree dedicada** para
-implementar um prompt/spec já preparado, captura a execução inteira num log de auditoria durável, mantem uma
-**sessão resumivel por tarefa**, da nota 0–10 a entrega, escala em caso de falha e **PARA para o gate**.
+# Codex runner
 
-<critical>Carregue e siga a skill `dw-cli-run` — ela tem o protocolo completo agnóstico de CLI (regra dura da worktree, pre-flight, escolha do veiculo, dupla avaliação 0–10, escalonamento gradual, telemetria, disciplina de kill/detecção, Structured Return). Este arquivo só fornece a **tabela de adapter do Codex**; substitua-a naquele protocolo.</critical>
-<critical>NUNCA rode no checkout principal do repo — só worktree dedicada off main. ABORTE (`BLOCKED`) caso contrário.</critical>
-<critical>NUNCA mergeie nem de push. Merge e decisão do dono, depois do gate.</critical>
+Use `dw-cli-run` para o protocolo compartilhado. Consuma a escolha aprovada da task e retorne ao parent para review, correções e continuidade. Invocação standalone aceita prompt preparado explicitamente sem exigir PRD. WRITE exige worktree secundário dedicado; READ-ONLY segue as regras de leitura efetiva da skill. O worker nunca faz merge ou push.
 
-## Tabela de adapter do Codex (substituir na `dw-cli-run`)
+Execute exemplos com cwd definido como `<WORKTREE>` pelo lançador. Substitua argumentos com segurança, preferencialmente como array de argumentos de subprocesso. Placeholders de permissões representam o perfil já aprovado, não flags de bypass. Preserve permissões efetivas na retomada; comandos inicial e resume podem aceitar flags diferentes. Confira ambos os helps antes do dispatch.
 
-| Slot | Valor Codex |
+## Codex adapter table
+
+| Slot | Value |
 |---|---|
-| `DISPATCH` | `cd <WORKTREE> && codex exec --skip-git-repo-check -m <MODEL> --config model_reasoning_effort="<EFFORT>" --dangerously-bypass-approvals-and-sandbox --json -o <AUDIT>/<slug>.last.md "$(cat <PROMPT>)" </dev/null > <AUDIT>/<slug>.log 2>&1` |
-| `STREAM` | `--json` (eventos JSONL) |
-| `MODEL` | `-m <MODEL>` — `gpt-5.5` · `gpt-5.3-codex` · `gpt-5.4` · `gpt-5.3-codex-spark` · `gpt-5.4-mini` |
-| `EFFORT` | `--config model_reasoning_effort="<EFFORT>"` — `low` · `medium` · `high` · `xhigh` |
-| `AUTO` | `--dangerously-bypass-approvals-and-sandbox` (sem sandbox + sem approvals = full access **com rede**, p/ o CLI rodar o gate; **somente dispatch WRITE**, justificável porque a worktree é isolada). Edição sem gate de rede: `--sandbox workspace-write --full-auto`. |
-| `AUTO_READONLY` | `--sandbox read-only` (sem `--full-auto`). Nunca combine com `AUTO`. |
-| `NO_MCP` | `-c mcp_servers='{}'` → sobe zero MCP servers, preserva auth e o resto do `config.toml`. Alternativa mais bruta: `--ignore-user-config` (também derruba os defaults de modelo — aí `MODEL` + `EFFORT` viram obrigatórios). |
-| `RESUME <id>` | `cd <WORKTREE> && codex exec resume <THREAD_ID> --skip-git-repo-check --dangerously-bypass-approvals-and-sandbox --json "$(cat <FOLLOWUP_PROMPT>)" </dev/null >> <AUDIT>/<slug>.log 2>&1` |
-| `RESUME_LAST` | `codex exec resume --last …` (filtra por cwd = a worktree) |
-| `SESSION_ID` | Codex **não tem flag pra fixar** o id → **capture** o thread id do stream da 1a run: `grep -oE '"thread_id":"[^"]*"' <AUDIT>/<slug>.log \| head -1` (do evento `thread.started`) → grave em `<AUDIT>/<slug>.session`. |
-| `DONE_SIGNAL` | `{"type":"turn.completed"}` no stream log |
-| `USAGE` | `turn.completed.usage` → `input_tokens` / `cached_input_tokens` / `output_tokens` / `reasoning_output_tokens`. Extrair: `grep -oE '"usage":\{[^}]*\}' <AUDIT>/<slug>.log \| tail -1` |
-
-**Modelos (forte→leve):** `gpt-5.5` · `gpt-5.3-codex` · `gpt-5.4` · `gpt-5.3-codex-spark` · `gpt-5.4-mini`.
-**Effort:** `low` · `medium` · `high` · `xhigh`. Comece um degrau abaixo do teto; escale conforme a `dw-cli-run`.
-
-**Relatório detalhado (recomendado):** adicione `--output-schema <schema.json>` exigindo um relatório rico
-(`summary`/`tasks`/`filesChanged`/`gate`/`fenceViolations`/`uncommitted`/`blockers`/`nextSteps`) — não aceite um
-"ok" opaco. O `codex-prompt.md` também deve pedir um STOP-com-relatório-detalhado (schema + prompt se reforcam).
-
-## Resume de sessão (o coração)
-1a run: capture o `thread_id` em `<AUDIT>/<slug>.session` (durável, fora da worktree → sobrevive ao
-`git worktree remove`). Pra voltar com o **mesmo contexto**, leia o id e re-rode `RESUME <id>` com o prompt de
-follow-up — o Codex continua o mesmo thread (raciocínio + arquivos já tocados). Fallback se o sidecar sumiu:
-`codex exec resume --last` da mesma worktree.
-
-## Variáveis de Input
-| Variável | Descrição | Exemplo |
-|----------|-----------|---------|
-| `<WORKTREE>` | git worktree dedicada (off main) — crie com `/dw-worktree create <slug>` (prep incluído); após o gate e o merge, remova no mesmo turno com `/dw-worktree merge <slug>` | `~/code/vizzita-billing-s10` |
-| `<PROMPT>` | caminho do prompt/spec preparado | `.dw/spec/prd-billing-integrador/codex-prompt.md` |
-| `<slug>` | chave da tarefa p/ arquivos de audit/sessão | `prd-billing-integrador` |
-| `<AUDIT>` | dir de auditoria durável FORA da worktree | `~/code/vizzita/.dw/cli-run` |
-
-Retorne pelo **Structured Return** da `dw-cli-run` (Status/Score/Scope/Evidence/Artifacts/Decisions/Risks/
-Telemetria/Next Step), incluindo o `thread_id` capturado, o caminho do sidecar, e o comando `RESUME` exato pra
-continuar. Testado: codex-cli 0.141.0.
+| `DISPATCH` | `codex exec -m "<MODEL>" -c 'model_reasoning_effort="<EFFORT>"' <PERMISSIONS> --json -o "<AUDIT>/<slug>.last.md" - < "<PROMPT>" > "<AUDIT>/<slug>.log" 2>&1` |
+| `STREAM` | `--json` |
+| `MODEL` | `-m "<MODEL>"` |
+| `EFFORT` | `-c 'model_reasoning_effort="<EFFORT>"'` |
+| `AUTO` | <PERMISSIONS> — perfil não interativo aprovado; preserve configuração existente |
+| `AUTO_READONLY` | `--sandbox read-only` |
+| `NO_MCP` | Selecione capacidades necessárias se suportado; caso contrário preserve configuração |
+| `RESUME <id>` | `codex exec resume "<SESSION_ID>" -m "<MODEL>" -c 'model_reasoning_effort="<EFFORT>"' <RESUME_PERMISSIONS> --json - < "<FOLLOWUP_PROMPT>" >> "<AUDIT>/<slug>.log" 2>&1` |
+| `SESSION_ID` | `thread.started.thread_id` → `<AUDIT>/<slug>.session` |
+| `DONE_SIGNAL` | `turn.completed` |
+| `USAGE` | `turn.completed.usage` |
+
+Crie/reutilize por `/dw-worktree create <slug>`; após integração autorizada, `/dw-worktree merge <slug>` conduz merge e limpeza segura. Workers retornam ao parent e nunca integram por conta própria.
+
+## Seleção de modelo e retomada
+
+Resolva modelo/esforço concretos na quebra de tasks usando `.dw/config/routing.json`, metadados atuais do provedor e ferramenta instalada. Não fixe lista de modelos do mais forte ao mais leve neste adapter. Esforços dependem de modelo/versão; low, medium, high, xhigh e max são candidatos apenas quando suportados. Sem escalada obrigatória ao máximo.
+
+Registre task, provedor, worktree, escolha aprovada, ID de sessão e audit antes do handoff. Sem sidecar, recupere sessão exata da task pelo log; nunca continue às cegas a sessão mais recente do cwd. Sem provar identidade, inicie nova sessão a partir do estado salvo e diff real, preservando trabalho parcial. Sessões não são portáveis entre CLIs.
+
+Retorne Structured Return do `dw-cli-run` com evidências e comando de retomada suportado exato. O parent continua o plano aprovado; merge/push/publicação exigem autorização aplicável.
+
+Inspeção de capacidades: codex-cli 0.153.4.
+O help atual de `exec resume` não expõe `--sandbox`; não copie flags iniciais às cegas nem acrescente bypass. Use perfil/configuração aprovado equivalente e suportado; caso contrário bloqueie esse modo de retomada e reconstrua sessão restrita nova. TOML `mcp_servers='{}'` sozinho não prova que entradas MCP herdadas foram desativadas.
 </system_instructions>

package/scaffold/pt-br/commands/dw-context-budget.md

@@ -7,23 +7,15 @@ Você é o auditor de orçamento de contexto do dev-workflow.
 - Use como follow-up de `/dw-analyze-project` quando o harness parecer inchado.
 
 ## Processo
-1. Estime tokens de `CLAUDE.md`, `AGENTS.md`, `.dw/commands/*.md`, `.agents/skills/*/SKILL.md`, `.agents/agents/*.md`, `.claude/agents/*.md`, `.opencode/agent/*.md`, `.github/agents/*.agent.md`, `.dw/subtasks/pending/*/HANDOFF.md` e `.claude/settings.json`.
-2. Estime prosa como `palavras * 1.3`; JSON/schema como `chars / 4`.
-3. Aponte:
-   - commands acima de 20KB,
-   - `SKILL.md` acima de 12KB,
-   - agentes acima de 8KB,
-   - agentes sem `output_budget_words` no `.dw/agent-registry.json` ou registry do scaffold,
-   - média de handoffs pendentes acima de 1200 palavras,
-   - agentes Copilot acima de 30k chars,
-   - mais de 10 MCP servers,
-   - nomes duplicados entre pastas de plataforma,
-   - agentes Claude/OpenCode com campos de tools ou permissions incompativeis com o provider.
-4. Recomende as 5 maiores economias com caminhos concretos.
+1. Separe três categorias: instruções permanentes do host ativo; metadados de descoberta (nomes/descrições de skills e comandos); e corpos de comandos/skills, referências e handoffs sob demanda. Inventário em disco não é consumo simultâneo de contexto. Conte só superfícies do host ativo; cópias entre plataformas não são duplicação de contexto por si só.
+2. Identifique estimativas de prosa (`palavras * 1.3`, schema `chars / 4`) como estimativas, não tokens medidos. Reporte categorias separadamente e carregamentos observados só quando houver telemetria.
+3. Confira budgets do projeto: bloco gerenciado instalado ≤6000 bytes por idioma; entrypoints de skills ≤8000 bytes; descrições ≤250 caracteres. Commands acima de 20KB e agentes acima de 8KB são sinais para revisão, não prova de carregamento. Confira gatilhos sobrepostos, referências incondicionais, links quebrados e metadados incompatíveis.
+4. Neste repositório `npm run validate` aplica budgets e referências roteadas via `lib/instruction-health.js`. Em consumidor inspecione arquivos instalados; não exija código-fonte do pacote no projeto.
+5. Reporte economias concretas prioritárias. Audite candidatos em `.dw/config/routing.json` contra informação atual do provedor, sinalizando escolhas antigas sem sobrescrever configuração do usuário.
 
 ## Parte B — Gasto em runtime (custo real de token)
 
-O overhead estático (acima) é o que o harness *carrega*; esta parte é o que as sessões de fato *custam*. Reporte a partir de `.dw/metrics/costs.jsonl` (append pelo hook `session-cost` de SessionEnd — uma linha por sessão com uso de tokens por modelo + USD estimado):
+O inventário acima estima contexto potencial; esta parte reporta uso observado nas sessões. Reporte a partir de `.dw/metrics/costs.jsonl` (append pelo hook `session-cost` de SessionEnd — uma linha por sessão com uso de tokens por modelo + USD estimado):
 
 1. Leia `.dw/metrics/costs.jsonl` se existir. Se ausente, registre "sem dados de custo runtime ainda (hook desabilitado ou nenhuma sessão encerrada)" e pule esta parte — nunca falhe.
 2. Deduplique por `session_id` (a linha mais recente por sessão vence).

package/scaffold/pt-br/commands/dw-copilot-run.md

@@ -1,49 +1,35 @@
 <system_instructions>
-Você é o **adapter runner do Copilot**. Você dispara o GitHub Copilot CLI (`copilot -p`) dentro de uma **git
-worktree dedicada** para implementar um prompt/spec já preparado, captura a execução inteira num log de auditoria
-durável, mantem uma **sessão resumivel por tarefa**, da nota 0–10 a entrega, escala em caso de falha e **PARA para
-o gate**.
+# Copilot runner
 
-<critical>Carregue e siga a skill `dw-cli-run` — ela tem o protocolo completo agnóstico de CLI (regra dura da worktree, pre-flight, escolha do veiculo, dupla avaliação 0–10, escalonamento gradual, telemetria, disciplina de kill/detecção, Structured Return). Este arquivo só fornece a **tabela de adapter do Copilot**; substitua-a naquele protocolo.</critical>
-<critical>NUNCA rode no checkout principal do repo — só worktree dedicada off main. ABORTE (`BLOCKED`) caso contrário.</critical>
-<critical>NUNCA mergeie nem de push. Merge e decisão do dono, depois do gate.</critical>
+Use `dw-cli-run` para o protocolo compartilhado. Consuma a escolha aprovada da task e retorne ao parent para review, correções e continuidade. Invocação standalone aceita prompt preparado explicitamente sem exigir PRD. WRITE exige worktree secundário dedicado; READ-ONLY segue as regras de leitura efetiva da skill. O worker nunca faz merge ou push.
 
-## Tabela de adapter do Copilot (substituir na `dw-cli-run`)
+Execute exemplos com cwd definido como `<WORKTREE>` pelo lançador. Substitua argumentos com segurança, preferencialmente como array de argumentos de subprocesso. Placeholders de permissões representam o perfil já aprovado, não flags de bypass. Preserve permissões efetivas na retomada; comandos inicial e resume podem aceitar flags diferentes. Confira ambos os helps antes do dispatch.
 
-| Slot | Valor Copilot |
+## Copilot adapter table
+
+| Slot | Value |
 |---|---|
-| `DISPATCH` | `cd <WORKTREE> && copilot -p "$(cat <PROMPT>)" --allow-all --model <MODEL> --output-format json </dev/null > <AUDIT>/<slug>.log 2>&1` |
-| `STREAM` | `--output-format json` (registros JSONL) |
-| `AUTO` | `--allow-all` (auto-aprovação de todo uso de tool/comando; justificável porque a worktree é isolada). Somente leitura/análise: tire-o e deixe negar no prompt, ou escope com `--allow-tool`/`--deny-tool`. |
-| `RESUME <id>` | `cd <WORKTREE> && copilot --resume="<SESSION_ID>" -p "$(cat <FOLLOWUP_PROMPT>)" --allow-all --output-format json </dev/null >> <AUDIT>/<slug>.log 2>&1` (também: `--connect=<SESSION_ID>`) |
-| `RESUME_LAST` | `copilot --continue -p …` (continua a sessão mais recente nesta cwd) |
-| `SESSION_ID` | O `--resume`/`--session-id` do Copilot **RESUMEM** uma sessão existente (não fixam uma nova) → **capture** o id da 1a run: varra o stream/log pelo registro do session id, ou leia o dir mais novo em `~/.copilot/logs` / `~/.copilot/history-session-state`. Grave em `<AUDIT>/<slug>.session`. **Confirme o campo exato do id no smoke test.** |
-| `DONE_SIGNAL` | o registro JSON final do stream (fim de turno) |
-| `USAGE` | o uso de tokens do registro final (confirme os nomes exatos dos campos no smoke test) |
-
-**Modelo:** `--model` escolhe a engine (ex.: `claude-sonnet-4.5`, `gpt-5`). O Copilot não tem flag numérica de
-effort; mapeie "escalonamento" para o tier do modelo. Comece um tier abaixo do teto; escale conforme a `dw-cli-run`.
-
-## Resume de sessão (o coração)
-O Copilot não deixa fixar o id, então na 1a run **capture** o session id (do stream/log ou `~/.copilot/logs`) e
-grave em `<AUDIT>/<slug>.session` (durável, fora da worktree → sobrevive ao `git worktree remove`). Pra voltar com
-o **mesmo contexto**, leia o id e re-rode `RESUME <id>` (`copilot --resume="<id>" -p …` ou `--connect=<id>`) com o
-prompt de follow-up — o Copilot recarrega a mesma sessão. Fallback se o sidecar sumiu: `copilot --continue -p …`
-da mesma worktree.
-
-> **Confirmações no smoke test (conforme o plano):** o campo exato do session-id no JSONL, os nomes dos campos de
-> usage, e que `--resume=<id>` de fato continua o mesmo contexto — verifique numa worktree descartavel antes de
-> confiar, e atualize esta tabela com o que achar.
-
-## Variáveis de Input
-| Variável | Descrição | Exemplo |
-|----------|-----------|---------|
-| `<WORKTREE>` | git worktree dedicada (off main) — crie com `/dw-worktree create <slug>` (prep incluído); após o gate e o merge, remova no mesmo turno com `/dw-worktree merge <slug>` | `~/code/vizzita-billing-s10` |
-| `<PROMPT>` | caminho do prompt/spec preparado | `.dw/spec/prd-billing-integrador/codex-prompt.md` |
-| `<slug>` | chave da tarefa p/ arquivos de audit/sessão | `prd-billing-integrador` |
-| `<AUDIT>` | dir de auditoria durável FORA da worktree | `~/code/vizzita/.dw/cli-run` |
-
-Retorne pelo **Structured Return** da `dw-cli-run` (Status/Score/Scope/Evidence/Artifacts/Decisions/Risks/
-Telemetria/Next Step), incluindo o `session-id` capturado, o caminho do sidecar, e o comando `RESUME` exato pra
-continuar.
+| `DISPATCH` | `copilot -p "<PROMPT_TEXT>" --model "<MODEL>" <PERMISSIONS> --output-format json > "<AUDIT>/<slug>.log" 2>&1` |
+| `STREAM` | `--output-format json` (confira a CLI instalada) |
+| `MODEL` | `--model "<MODEL>"` |
+| `EFFORT` | Use `default` quando não houver flag de esforço; nunca invente uma flag |
+| `AUTO` | <PERMISSIONS> — perfil não interativo aprovado; preserve configuração existente |
+| `AUTO_READONLY` | Resolva controles efetivos de leitura pelo help instalado; bloqueie READ-ONLY se indisponíveis |
+| `NO_MCP` | Selecione capacidades necessárias se suportado; caso contrário preserve configuração |
+| `RESUME <id>` | `copilot --resume="<SESSION_ID>" -p "<FOLLOWUP_TEXT>" --model "<MODEL>" <RESUME_PERMISSIONS> --output-format json >> "<AUDIT>/<slug>.log" 2>&1` |
+| `SESSION_ID` | Capture ID exato do stream desta task; valide schema de eventos da CLI instalada → `<AUDIT>/<slug>.session` |
+| `DONE_SIGNAL` | Registro terminal do provedor mais saída do processo e relatório inspecionado |
+| `USAGE` | Somente campos de uso reportados; desconhecido se ausentes |
+
+Crie/reutilize por `/dw-worktree create <slug>`; após integração autorizada, `/dw-worktree merge <slug>` conduz merge e limpeza segura. Workers retornam ao parent e nunca integram por conta própria.
+
+## Seleção de modelo e retomada
+
+Resolva modelo/esforço concretos na quebra de tasks usando `.dw/config/routing.json`, metadados atuais do provedor e ferramenta instalada. Não fixe lista de modelos do mais forte ao mais leve neste adapter. Esforços dependem de modelo/versão; low, medium, high, xhigh e max são candidatos apenas quando suportados. Sem escalada obrigatória ao máximo.
+
+Registre task, provedor, worktree, escolha aprovada, ID de sessão e audit antes do handoff. Sem sidecar, recupere sessão exata da task pelo log; nunca continue às cegas a sessão mais recente do cwd. Sem provar identidade, inicie nova sessão a partir do estado salvo e diff real, preservando trabalho parcial. Sessões não são portáveis entre CLIs.
+
+Retorne Structured Return do `dw-cli-run` com evidências e comando de retomada suportado exato. O parent continua o plano aprovado; merge/push/publicação exigem autorização aplicável.
+
+Inspeção de capacidades: Copilot adapter requires installed-version capability validation.
 </system_instructions>

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

@@ -13,11 +13,11 @@
 
     | 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-verify` | **SEMPRE** — invocada antes do `git push`. Sem VERIFICATION REPORT PASS válido para insumos, ambiente e escopo atuais, 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-secure-audit` | **SEMPRE para projetos TS/Python/C#/Rust** — um `.dw/secure-audit/audit-summary.md` fresco 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>
+    <critical>Hard gate 1 (verify): use `dw-verify` para confirmar evidência válida dos insumos, ambiente e escopo atuais antes de push/PR. Reutilize evidência equivalente; execute checks exigidos ausentes/invalidados. Outra sessão ou commit só de bookkeeping não invalida checks.</critical>
 
     <critical>Hard gate 2 (security): para projetos TS/Python/C#/Rust, se `.dw/secure-audit/audit-summary.md` não existir, estiver desatualizado (anterior à última edição) OU tiver status REJECTED, PARAR e invocar `/dw-secure-audit` antes de prosseguir. Findings SECRET e vulnerabilidades HIGH/CRITICAL NÃO podem chegar ao PR. Para outras linguagens (Go, Java, etc.), este gate é pulado com nota.</critical>
 

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

@@ -4,7 +4,7 @@ Você é o orquestrador de objetivos duráveis do dev-workflow. Este comando ent
 ## Quando Usar
 - Use quando um fluxo é maior que um turno normal, mas tem fim claro.
 - Use depois de `/dw-plan` quando implementação, review, QA e review pós-QA devem rodar como um loop durável.
-- Use a partir do `/dw-autopilot` depois que a primeira invocação completou PRD → TechSpec → Tasks.
+- Use a partir do `/dw-autopilot` depois que o plano PRD → TechSpec → Tasks foi aprovado.
 - NÃO use para backlog solto, listas de tarefas sem relação ou brainstorming exploratório.
 
 ## Posição no Pipeline
@@ -28,7 +28,7 @@ Você é o orquestrador de objetivos duráveis do dev-workflow. Este comando ent
 A documentação oficial do Codex trata `/goal` como recurso experimental para objetivo durável em trabalho longo com condição de parada verificável. No Codex CLI ele requer `features.goals`; pode ser definido com `/goal <objective>`, inspecionado com `/goal`, e controlado com `/goal pause`, `/goal resume` ou `/goal clear`.
 
 Quando rodar em Codex:
-- Se existir ferramenta nativa de goal, crie/atualize o goal com um objetivo curto apontando para `.dw/goals/<slug>/goal.md`.
+- Use ferramenta nativa de goal somente quando explicitamente solicitada e permitida pelo contrato real da ferramenta; workflow portátil não implica autorização nativa.
 - Se o slash command interativo `/goal` estiver disponível e `features.goals` estiver habilitado, use `/goal <objective>` com objetivo abaixo de 4.000 caracteres.
 - Se goals nativos estiverem indisponíveis, continue com o loop portável em `.dw/goals/`. Não bloqueie.
 
@@ -101,12 +101,12 @@ Checkpoints:
 | `review-before-qa` | `/dw-review <prd-path>` | `<prd-path>/QA/review-consolidated.md` existe e veredicto geral está aprovado ou aprovado com ressalvas explicitamente não-bloqueantes. |
 | `qa` | `/dw-qa <prd-path>` | Artefatos obrigatórios de QA existem. |
 | `qa-fix` | `/dw-qa --fix <prd-path>` quando `bugs.md` tem bugs Open | Bugs estão Fixed/Closed ou explicitamente deferidos pelo usuário. |
-| `review-after-qa` | `/dw-review <prd-path>` | Review consolidado existe após fixes de QA e está aprovado ou aprovado com ressalvas explicitamente não-bloqueantes. |
+| `review-after-qa` | `/dw-review <prd-path>` quando edições/achados de QA invalidarem review | Review atual aprovado ou com ressalvas explicitamente não bloqueantes; QA sem mudanças reutiliza review válido. |
 
 O goal só está completo quando:
 - Todos os checkpoints acima estão completos ou explicitamente pulados com motivo documentado.
 - Nenhum bug Open de QA permanece, exceto se o usuário aceitou deferir explicitamente.
-- O `/dw-review` final rodou depois do último fix de QA.
+- O `/dw-review` completo final cobre a implementação atual. Repita após edições ou achados novos de QA; reutilize quando QA não invalidar nada.
 - `status.json` tem `"status": "complete"`.
 
 ## Regras de Execução
@@ -123,7 +123,7 @@ O goal só está completo quando:
 
 - `status`: leia `status.json` e as últimas 10 entradas de `progress.md`; reporte checkpoint atual, completos, última verificação e bloqueios.
 - `pause`: defina `status: "paused"` e anexe o motivo.
-- `resume`: defina `status: "active"` e continue de `current_checkpoint`; não repita checkpoints completos salvo se artefatos estiverem faltando.
+- `resume`: defina `status: "active"` e continue de `current_checkpoint`; não repita checkpoints completos salvo artefatos ausentes ou evidência invalidada.
 - `clear`: se completo/cancelado/substituido, marque `status: "cancelled"` ou arquive conforme convencao do projeto. Não delete evidências por padrão.
 
 ## Anti-patterns
@@ -133,4 +133,10 @@ O goal só está completo quando:
 - Não marque checkpoint completo sem verificar artefatos.
 - Não use `/goal` nativo do Codex como único estado; `.dw/goals/` permanece o contrato cross-agent.
 
+## Estado de execução aprovado
+
+Leia `.dw/references/execution-contract.md`. Consuma escolhas aprovadas por task e preserve `execution-state.json` nos checkpoints. Retorno de runner volta ao parent para review, correções e próximas tasks. Não repita review completo final do `/dw-run` quando já cobrir a implementação inalterada: valide evidência e registre checkpoint reutilizado. QA condicional/inaplicável exige motivo registrado, não artefatos inventados. Conclua verificando aceitação/evidência antes de marcar status complete; o campo status não prova conclusão.
+
+Retomada preserva checkpoints concluídos salvo evidência inválida ou artefatos ausentes. Separe entrega de autorização para merge/push/publicação. Preserve trabalho parcial em bloqueio/pausa e nunca troque executor silenciosamente.
+
 </system_instructions>

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

@@ -17,7 +17,7 @@ Use `/dw-autopilot "desejo"` como gateway pra maior parte do trabalho. Comandos
 
 | Comando | Quando |
 |---------|--------|
-| `/dw-autopilot "desejo"` | Entry point padrão em duas invocações. Primeira roda plan e para; segunda retoma via `/dw-goal`, Security Gate, commit e PR. |
+| `/dw-autopilot "ideia"` | Planeja e aprova escolhas de execução, depois continua por implementação, review e validação. |
 | `/dw-bugfix "descrição"` | Bug ou error report. Fix cirúrgico ou rota pra PRD. |
 | `/dw-help [palavra-chave]` | Esta tela. Passe palavra-chave pra atalhos. `--advanced` revela comandos internos. |
 
@@ -141,7 +141,7 @@ Sem match: surface padrão + nota.
 ## FAQ
 
 **P: Onde começo com uma nova feature?**
-- `/dw-autopilot "o que voce quer"`. Primeira invocacao roda PRD → TechSpec → Tasks e para; segunda invocacao retoma via `/dw-goal`, Security Gate, commit e PR.
+- Use `/dw-autopilot "o que você quer"`; aprove a matriz de tasks/executores e continue até entrega validada. Publicação segue autorização existente.
 
 **P: Tenho que usar `/dw-autopilot`?**
 - Não. Pipeline granular dá controle a cada step, com `/dw-goal` quando quiser executar run/review/QA/review como objetivo duravel, seguido por `/dw-secure-audit`, `/dw-commit` e `/dw-generate-pr`.

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

@@ -44,6 +44,8 @@ Quando disponíveis em `./.agents/skills/`, use como suporte:
 
 ## Agent Dispatch
 
+Use estes papéis só quando delegação delimitada ajudar a task; podem ser realizados localmente. Não dispare todos os agentes nem sobrescreva modelos herdados automaticamente.
+
 Quando agentes do projeto estiverem instalados, use:
 
 - `dw-code-explorer` antes de TechSpec e Tasks para rastrear fluxos existentes e padroes reutilizaveis.
@@ -92,7 +94,7 @@ Para cada estágio: monte a matriz, marque cada dimensão `coberta` (fato descob
 
 ## Inteligência do Codebase
 
-<critical>Se `.dw/intel/` existir, consulte via `/dw-intel` antes de cada estágio. OBRIGATÓRIO no estágio TechSpec.</critical>
+Consulte `.dw/intel/` quando ajudar a localizar padrões atuais; inspecione código relevante e confira atualização do índice. Reutilize evidências entre estágios.
 - Estágio PRD: `/dw-intel "features existentes no domínio <tópico>"` para evitar duplicação.
 - Estágio TechSpec: `/dw-intel "padrões arquiteturais, convenções de API, decisões técnicas"` para alinhar com a forma existente do projeto.
 - Estágio Tasks: `/dw-intel "padrões de teste, build pipeline, deployment cadence"` para dimensionamento acurado.
@@ -141,8 +143,9 @@ Roda em modo padrão (após aprovação do PRD) OU `plan techspec` OU `plan --fr
 5. **Constitution gate.** Cada decisão arquitetural lista `Respects: P-NNN` ou `Deviates: P-NNN — justification: <slug ADR ou racional>`. Desvios de princípios `severity: high/critical` sem ADR → PARE.
 6. **API design discipline.** Ao definir endpoints, consulte `dw-codebase-intel/references/api-design-discipline.md` (Hyrum's Law, error semantics, versionamento).
 7. **Seções de UI** (quando feature tem UI): as 4 grounding questions do `dw-ui-discipline` precisam estar respondidas no techspec; state matrix + scene sentence obrigatórios.
+   - Para fluxo de dados, dependências ou ferramentas de frontend, leia `dw-ui-discipline/references/frontend-engineering.md` no local das skills instaladas. Reutilize a baseline de qualidade do módulo; acrescente apenas decisões afetadas de `.dw/templates/frontend-quality-template.md`. Separe checks obrigatórios existentes de controles consultivos/propostos. Inclua a configuração aceita e sua validação na decomposição de tarefas e matriz de execução.
 8. **Seção Branch name:** `feat/prd-<feature-slug>`.
-9. **Seção Testing strategy:** tests-per-method, mock setup, coverage targets (80% services, 70% controllers), E2E flows explícitos.
+9. **Seção Testing strategy:** cobertura de comportamentos/riscos, menores camadas eficazes, suítes existentes, mocks justificados e E2E aplicáveis. Valem limites exigidos pelo projeto; sem percentual universal.
 10. **Output:** `.dw/spec/prd-<feature-slug>/techspec.md` (mesmo dir do PRD).
 
 ### Opcional: flag `--council`
@@ -162,7 +165,7 @@ Roda em modo padrão (após aprovação do TechSpec) OU `plan tasks`.
 ### Comportamento obrigatório
 
 1. **Instrução de branch:** inclua criação de `feat/prd-<feature-slug>` no resumo de tasks.
-2. **Decompor** PRD + TechSpec em tasks. Target ~6 tasks por feature. **NUNCA exceder 2 FRs por task.**
+2. **Decompor** PRD + TechSpec em tasks. Use fatias coerentes e verificáveis independentemente; preserve cobertura de requisitos sem cota fixa de tasks ou FRs.
 3. **Cobertura end-to-end:** todo fluxo user-facing tem subtasks backend + frontend + UI funcional quando aplicável.
 4. **Test placement (`dw-testing-discipline`):** toda subtask que adiciona teste nomeia seu invariant per placement doctrine. Owning layer especificado.
 5. **Constitution alignment:** toda task lista `Constitution: respects P-NNN` ou `Constitution: deviates P-NNN — ADR planejado: <slug>` ou `Constitution: n/a — motivo: <one-liner>`.
@@ -172,20 +175,24 @@ Roda em modo padrão (após aprovação do TechSpec) OU `plan tasks`.
    - Summary: `.dw/spec/prd-<feature-slug>/tasks.md`
    - Per-task: `.dw/spec/prd-<feature-slug>/<N>_task.md`
 
-### Final Consistency Check (auto-invocado antes da aprovação)
+### Matriz de execução de tasks
+
+No Estágio 3 leia `.dw/references/execution-contract.md`. Proponha desenvolvimento local ou cruzado por task, escolhendo modelo, esforço e agentes instalados conforme complexidade e risco reais. Use templates schema 1.1 e `execution-plan.json`, valide com `node .dw/scripts/lib/workflow-contract.mjs validate <plan.json>` e confira IDs/dependências contra tasks.md. Apresente escolhas justificadas para aprovação; nunca troque de provedor silenciosamente ao executar. Planos legados schema 1.0 continuam válidos e executam localmente por padrão.
+
+## Final Consistency Check (auto-invocado antes da aprovação)
 
 Roda check em 5 dimensões, escreve `.dw/spec/prd-<feature-slug>/tasks-validation.md`:
 
 1. **Cobertura FR:** todo FR numerado mapeia para ≥1 task.
 2. **Grounding de task:** toda task referencia ≥1 FR.
-3. **Cobertura de teste:** todo FR user-facing tem ≥1 task que adiciona teste.
+3. **Cobertura de teste:** todo FR user-facing tem verificação significativa, reutilizando testes existentes quando suficientes.
 4. **Grafo de dependência:** ordem topológica válida, sem ciclos.
 5. **Constitution alignment:** toda task tem linha de alignment (só se `.dw/constitution.md` existir).
 
-Qualquer FAIL → PARE. Mostre a tabela no chat. Três opções: auto-fix (regenerar tasks afetadas), edit manual, override explícito com motivo.
+Corrija falhas internas de consistência e reexecute o check. Pergunte só decisões materiais ausentes ou override explícito com motivo; não peça permissão para corrigir o rascunho.
 
 ### Checkpoint
-Apresente resumo de tasks.md + lista per-task. Usuário aprova pra liberar `/dw-run`.
+Apresente tasks.md e matriz de execução (local/cruzada, modelo, esforço, agentes e fallbacks aprovados). A aprovação autoriza essas escolhas. Em pedido de implementação continue por `/dw-run` ou `/dw-goal` chamador; pedido somente de plano termina no plano aprovado.
 
 ## Resumo de Arquivos de Output
 

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

@@ -81,6 +81,8 @@ Quando disponíveis em `./.agents/skills/`, invocadas operacionalmente:
 
 ### Comportamento — modo UI
 
+Leia a baseline de qualidade/TechSpec do módulo afetado. Reutilize evidência válida dos checks obrigatórios via `dw-verify`; separe comportamento no navegador, validação de contrato e relatórios diagnósticos. Quando lógica crítica ou assertions fracas justificarem análise de mutação, leia `dw-testing-discipline/references/mutation-testing.md`. Não introduza um limite de score nem instale nova suíte para edições de UI sem relação. Registre diagnósticos indisponíveis/não executados e findings investigados em `qa-report.md`.
+
 1. **Pre-flight**: confirmar que dev server do projeto pode rodar. Confirmar `.dw/spec/<prd>/` tem PRD + TechSpec + tasks.
 2. **Mapear FRs para test plan**: pra cada FR, identificar fluxo user-facing que exercita.
 3. **Dirigir Playwright MCP** (se indisponível ou bloqueado — comum no WSL — use o fallback local resiliente `node .dw/scripts/lib/capture-screenshots.mjs`, que escolhe o browser via `.dw/scripts/lib/resolve-browser.mjs`; veja a seção "Browser on WSL" de `dw-testing-discipline/references/playwright-recipes.md`):

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

@@ -14,9 +14,9 @@ Você é um agent de retomada de sessão. Seu trabalho é ler `.dw/STATE.md`, se
 
 ## Workflow
 
-### 1. Ler STATE.md
-- Se `.dw/STATE.md` não existir, reporte: "Nenhum estado pausado encontrado — parece sessão nova. Rode `/dw-help` para próximos passos." Pare aqui.
-- Se `STATE.md` existir mas toda seção for `_nenhum_`, reporte: "STATE.md vazio — nada a retomar. Me diga o que você quer fazer."
+### 1. Localizar estado
+- Leia `.dw/STATE.md` quando existir. Se ausente/vazio, inspecione `.dw/goals/*/status.json`, `.dw/spec/*/execution-state.json` e `active-session.md`.
+- Use target explícito ou workflow ativo único; pergunte só se restarem múltiplos candidatos. Reporte ausência de trabalho retomável só depois de conferir essas fontes.
 
 ### 2. Cross-reference com disco
 Verifique que o estado ainda bate com o filesystem:
@@ -63,13 +63,9 @@ Baseado no TLDR, roteie para um comando concreto. Use estas heuristicas:
 | Bloqueio esperando input externo | Sugerir que o usuário resolva o bloqueio primeiro |
 | Só Todos e Decisões, sem trabalho ativo | Perguntar o que começar |
 
-Formule a sugestão como pergunta, não como ordem:
 
-```
-Quer que eu rode <comando sugerido>?
-- sim → rodo
-- nao, <outra intencao> → me diga o que prefere
-```
+Pedido de continuar executa o próximo passo identificado com autorização existente e escolhas salvas. Pergunta somente de status recebe resumo e sugestão sem execução.
+
 
 ### 5. Atualizar frontmatter do STATE.md
 
@@ -77,7 +73,7 @@ Setar `last_resumed` para a data de hoje (YYYY-MM-DD). Não modificar conteúdo
 
 ## Comportamento Obrigatório
 
-<critical>NUNCA auto-execute o comando sugerido. `/dw-resume` só propoe; o usuário confirma antes de qualquer `/dw-run`, `/dw-plan` ou `/dw-bugfix`.</critical>
+<critical>Respeite intenção: retome trabalho autorizado no pedido de continuar; reporte apenas em pergunta de status. Leia `.dw/references/execution-contract.md` para recuperação de escolhas/sessão e invalidação de evidência.</critical>
 
 <critical>NUNCA fabrique resultados de stale-detection. Se você não rodou `ls`, não reporte que o arquivo existe ou não.</critical>
 
@@ -85,6 +81,6 @@ Setar `last_resumed` para a data de hoje (YYYY-MM-DD). Não modificar conteúdo
 
 ## Inspirado em
 
-Este comando adapta o pattern de session-handoff de [`tech-leads-club/agent-skills/tlc-spec-driven`](https://github.com/tech-leads-club/agent-skills/tree/main/packages/skills-catalog/skills/(development)/tlc-spec-driven) (CC-BY-4.0, Felipe Rodrigues). Adaptações: heuristicas de routing mapeiam conteúdo do STATE.md para comandos `dw-*` específicos; cross-reference com `.dw/spec/` e `.dw/bugfixes/` para detectar staleness; nunca auto-executa.
+Este comando adapta o pattern de session-handoff de [`tech-leads-club/agent-skills/tlc-spec-driven`](https://github.com/tech-leads-club/agent-skills/tree/main/packages/skills-catalog/skills/(development)/tlc-spec-driven) (CC-BY-4.0, Felipe Rodrigues). Adaptações: heuristicas de routing mapeiam conteúdo do STATE.md para comandos `dw-*` específicos; cross-reference com `.dw/spec/` e `.dw/bugfixes/` para detectar staleness; continua conforme intenção e autorização de retomada.
 
 </system_instructions>

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

@@ -173,10 +173,11 @@ Se FALTANDO > 0, o veredicto sugere revisitar `/dw-plan tasks` pra escopar ou `/
    - Complexidade ciclomática / cognitiva (com thresholds `dw-simplification`).
    - Violações DRY (apenas com impacto significativo — não dedup prematuro).
    - Code smells (taxonomia Fowler).
+   - Para mudanças em fluxo de dados, dependências ou ferramentas de qualidade do frontend, leia `dw-ui-discipline/references/frontend-engineering.md` e a baseline de qualidade/TechSpec do módulo. Inspecione geração/validação de API, limites de imports, regras de negócio duplicadas, código inalcançável e novas exclusões abrangentes. Execute checks adotados via `dw-verify`; ferramenta opcional ausente é proposta, não reprovação automática. Investigue mutantes sobreviventes quando a análise estiver no escopo; não aprove apenas por score. Relate mudanças na obrigatoriedade do CI separadamente dos resultados locais.
 
 5. **Execução de testes:**
-   - Rodar comando de teste do projeto.
-   - Verificar coverage targets do TechSpec (80% services, 70% controllers).
+   - Use `dw-verify` para inspecionar evidência válida; rode checks exigidos ausentes/invalidados.
+   - Verificar estratégia aprovada e limites exigidos pelo projeto; sem percentual universal de cobertura.
 
 6. **Aplicar `dw-review-rigor`:**
    - De-duplicar findings.
@@ -184,7 +185,7 @@ Se FALTANDO > 0, o veredicto sugere revisitar `/dw-plan tasks` pra escopar ou `/
    - Verificar intent antes de flagar (linter já pega alguns — não repete).
 
 7. **Verificação final (`dw-verify`):**
-   - Rodar dw-verify pra produzir VERIFICATION REPORT (test + lint + build GREEN).
+   - Use dw-verify para produzir VERIFICATION REPORT dos checks obrigatórios aplicáveis, reutilizando evidência equivalente.
    - Sem PASS, verdict não pode ser APROVADO.
 
 8. **Security Gate (`dw-secure-audit` para TS/Python/C#/Rust):**