@brunosps00/dev-workflow 2.1.0 → 2.3.0

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) | `~/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-harness-audit.md

@@ -22,7 +22,9 @@ Você é o auditor do harness dev-workflow.
    - Gates de verificação
    - Gates de segurança
    - Disciplina de contexto
+   - Worktree hygiene
 3. Para retornos estruturados das skills, inspecione `SKILL.md` de skills bundled e exija contrato `## Structured Return` com `Status`, `Evidence`, `Artifacts` e `Next Step`.
+3b. Para worktree hygiene, rode `node .dw/scripts/lib/worktree-gc.mjs list --strict`. Exit 3 (qualquer worktree `REMOVABLE` ou `PRUNABLE`) limita a categoria a 3/10; cite cada sobra com tamanho e veredito e recomende `/dw-worktree clean --apply`. Entradas `KEEP:*` são informativas.
 4. Cite paths ausentes, referências quebradas, arquivos gerenciados stale, e skills sem retorno estruturado.
 5. Recomende os 3 principais fixes.
 

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

@@ -17,11 +17,11 @@ 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. |
 
-## Tier 2 — Pipeline granular (10)
+## Tier 2 — Pipeline granular (11)
 
 | Comando | O que |
 |---------|-------|
@@ -33,10 +33,11 @@ Use `/dw-autopilot "desejo"` como gateway pra maior parte do trabalho. Comandos
 | `/dw-qa` | QA mode-aware (UI / API auto-detect). Flags: `--fix`, `--api`, `--ai`, `--uat`, `--bugfix <slug>`. |
 | `/dw-pause` | Salva estado da sessão, decisões, bloqueios, todos e open loops em `.dw/STATE.md`. |
 | `/dw-resume` | Lê `.dw/STATE.md`, mostra um TLDR e sugere o próximo comando `dw-*`. |
+| `/dw-report [--every <N>m]` | Report carimbado de feito / fazendo / falta a cada 10 minutos enquanto trabalho longo roda; anexado em `.dw/reports/`. `now`, `status`, `stop`. Auto-armado por `/dw-run`, `/dw-autopilot` e pelos runners de CLI. |
 | `/dw-commit` | Commits atômicos Conventional pra trabalho pendente. |
 | `/dw-generate-pr [target]` | Push branch, draft do PR body, abre browser. |
 
-## Tier 3 — Especialidade (12)
+## Tier 3 — Especialidade (13)
 
 | Comando | O que |
 |---------|-------|
@@ -48,6 +49,7 @@ Use `/dw-autopilot "desejo"` como gateway pra maior parte do trabalho. Comandos
 | `/dw-context-budget` | Audita contexto de commands, skills, agentes, instrucoes e MCPs. |
 | `/dw-harness-audit` | Pontua saude da instalacao: wrappers, agentes, MCPs e gates. |
 | `/dw-skill-health` | Audita skills e agentes por bloat, duplicacao e referencias quebradas. |
+| `/dw-worktree <list\|create\|clean\|merge>` | Ciclo de vida de worktrees: cria preparada, lista com vereditos, limpa só o provadamente mergeado (dry-run default), merge ff-only + remoção no mesmo turno. Nunca `--force`. |
 | `/dw-new-project` | Bootstrap por entrevista (stack + infra + docker-compose + CI). |
 | `/dw-dockerize` | Detecta stack, propõe Dockerfile + docker-compose pra dev/prod. |
 | `/dw-install-azure-skills` | Opt-in: skills Azure + Microsoft Learn MCP. Seleção interativa de categorias. |
@@ -99,6 +101,7 @@ Auto-invocados por comandos primários mas disponíveis standalone.
 | `run`, `executa`, `implementa` | `/dw-run` |
 | `goal`, `objetivo`, `long-running`, `retomar autopilot` | `/dw-goal` ou `/dw-autopilot` se `autopilot-state.json` existir |
 | `pausa`, `salvar estado`, `encerrar sessão` | `/dw-pause` |
+| `report`, `progresso`, `me mantém informado`, `status periódico` | `/dw-report [--every <N>m]` |
 | `retomar`, `continuar`, `onde paramos` | `/dw-resume` |
 | `review`, `qualidade`, `audit code` | `/dw-review` |
 | `qa`, `test plan`, `e2e` | `/dw-qa` |
@@ -117,6 +120,7 @@ Auto-invocados por comandos primários mas disponíveis standalone.
 | `design.md`, `autoridade de design`, `mapa de concerns` | `/dw-analyze-project` (também listado como ação pós-update quando ausente) |
 | `subagent`, `subtask`, `handoff`, `delegate`, `delegar` | `/dw-subtask-start` ou `/dw-subtask-resume` |
 | `skills`, `skill health`, `bloat` | `/dw-skill-health` |
+| `worktree`, `worktrees`, `disco`, `mergear worktree`, `limpar worktrees` | `/dw-worktree list` / `create <slug>` / `clean --apply` / `merge <slug>` |
 | `analyze`, `rules`, `convenções` | `/dw-analyze-project` |
 | `constitution`, `princípios` | `/dw-analyze-project` (Step 8) |
 | `oportunidades de seguranca`, `ideias de hardening`, `melhorar seguranca` | `/dw-opportunities "security"` |
@@ -137,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-pause.md

@@ -29,6 +29,7 @@ Você é um agent de session-handoff. Seu trabalho e consolidar o estado mental
 Leia o contexto da conversa e identifique, **sem inventar**:
 
 - **Pontas soltas (Open Loops)**: tarefas/trabalho iniciados mas não finalizados (ex: "PRD `prd-foo` está no estágio TechSpec, aguardando aprovação"; "Task 3 do `prd-bar` falhando no lint")
+- **Worktrees sobrando**: rode `node .dw/scripts/lib/worktree-gc.mjs list`. Toda entrada `REMOVABLE` é um open loop pra fechar **agora** com `/dw-worktree clean --apply` — não algo pra registrar; entradas `KEEP:*` vão em Open Loops com veredito e motivo.
 - **Decisões tomadas**: escolhas acordadas entre usuário e agent durante a sessão que afetam trabalho futuro
 - **Bloqueios encontrados**: o que parou o avanço (esperando input, tooling quebrado, lacuna de conhecimento)
 - **Todos mencionados de passagem** que ainda não tem PRD ou task

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

@@ -0,0 +1,169 @@
+<system_instructions>
+Você é o loop de report de progresso. Enquanto há trabalho longo rodando nesta sessão, você emite um report detalhado e carimbado com data e hora numa cadência fixa (default a cada 10 minutos) dizendo **o que já foi feito, o que está sendo feito agora e o que ainda falta** — sem o usuário precisar perguntar "e aí?". Cada report vai pro chat E é anexado num log diário em `.dw/reports/`. O loop se desarma sozinho quando o trabalho termina.
+
+## Quando Usar
+- Use quando o usuário disser "report de N em N minutos", "me mantém informado enquanto isso roda", "quero status periódico", "quero saber onde estamos a cada 10 minutos".
+- Auto-armado por `/dw-run` (modos todas-as-tasks e `--resume`), por `/dw-autopilot` (invocação de execução) e pelos adapters `dw-cli-run` (`/dw-codex-run`, `/dw-claude-run`, `/dw-copilot-run`) quando disparam trabalho longo. O auto-arme é idempotente e pode ser desligado com `DW_REPORT_AUTO=off`.
+- NÃO use como substituto de `/dw-pause` (handoff de estado mental) nem de `/dw-goal status` (estado do contrato de goal). Isto é um heartbeat sobre trabalho em andamento, não estado durável do projeto.
+- NÃO use pra fazer polling de uma task em background que o harness já notifica — o loop reporta *em volta* dessas notificações; nunca as substitui.
+
+## Posição no Pipeline
+**Predecessor:** qualquer comando de longa duração (`/dw-run`, `/dw-autopilot`, `/dw-goal`, `/dw-codex-run`, builds, deploys) | **Sucessor:** nenhum — o loop termina com um report final; `/dw-pause` pode consumir o log do dia.
+
+## Modos
+
+| Invocação | Comportamento |
+|-----------|---------------|
+| `/dw-report` | Arma o loop na cadência default (**10 minutos**). Se já estiver armado, imprime o estado atual e não faz mais nada. |
+| `/dw-report --every <N>m` | Arma (ou re-arma) o loop em `N` minutos (`5m`, `10m`, `15m`, `30m`; `--every 600s` também é aceito). Mínimo `1m`. |
+| `/dw-report now` | Emite um report imediatamente, sem mexer na cadência. Funciona armado ou não. |
+| `/dw-report status` | Mostra se o loop está armado, a cadência, quando foi armado, a hora do último report, quantos reports foram emitidos e o caminho do log. |
+| `/dw-report stop` | Desarma. Emite um report final antes se houver progresso não reportado. |
+
+## Entradas
+
+| Variável | Descrição | Exemplo |
+|----------|-----------|---------|
+| `{{EVERY}}` | Cadência. Opcional; default `10m`. | `--every 5m` |
+| `DW_REPORT_AUTO` | Env var. `off` desliga o auto-arme vindo de outros comandos (o `/dw-report` manual continua funcionando). | `DW_REPORT_AUTO=off` |
+| `DW_REPORT_BELL` | Env var. Comando shell opcional executado logo antes de cada report ser escrito (som local, notificação de desktop etc.). Silencioso quando não definido. | `DW_REPORT_BELL="paplay /usr/share/sounds/freedesktop/stereo/message.oga"` |
+
+`report.bell` em `.dw/config.json` é o equivalente em arquivo de `DW_REPORT_BELL` (a env var vence). Como o bell é específico da máquina, prefira a env var a commitar isso.
+
+## Estado e Artefatos
+
+```
+.dw/reports/
+├── .gitignore        # ????-??-??.md e .active.json são locais da máquina (criado pelo init/update)
+├── .active.json      # estado do loop — existe só enquanto armado
+└── YYYY-MM-DD.md     # log diário append-only; uma entrada por report emitido
+```
+
+Schema do `.active.json`:
+
+```json
+{
+  "schema_version": "1.0",
+  "armed_at": "2026-08-24 15:10:02",
+  "every_seconds": 600,
+  "vehicle": "wakeup | background-bash",
+  "armed_by": "user | dw-run | dw-autopilot | dw-cli-run",
+  "seq": 3,
+  "last_report_at": "2026-08-24 15:40:12",
+  "last_state": "working | blocked | finished"
+}
+```
+
+Timestamps são **reais** — sempre obtidos de `date '+%Y-%m-%d %H:%M:%S'`, nunca estimados.
+
+## Veículo — como o loop se mantém vivo
+
+<critical>A thread principal nunca dorme em foreground. Escolha UM veículo, registre em `.active.json`, e nunca afirme "loop armado" sem que esse veículo esteja de fato agendado.</critical>
+
+1. **Wakeup nativo (PREFERIDO — Claude Code).** Use a facilidade de despertar agendado do harness (o mesmo mecanismo do `/loop` em modo self-paced): depois de cada tick, agende o próximo despertar em `every_seconds`. Passe `noop: true` num tick silencioso e `noop: false` num tick que reportou. O `reason` é `dw-report tick every <N>m`. O loop morre com a sessão — sem órfão.
+2. **Timer shell em background (FALLBACK — Codex, Copilot, OpenCode, ou qualquer harness sem wakeups).** Rode, em background, `sleep <every_seconds>; date '+%Y-%m-%d %H:%M:%S'`. Quando a notificação de conclusão chegar, execute o tick e inicie o próximo timer. Um timer por vez; nunca encadeie sleeps em foreground.
+3. **Nunca um cron de sistema.** Cron não sabe quando o trabalho acabou e continua disparando (e tocando o bell) por dias. Se o harness só oferecer agendamento estilo cron, use-o mas trate `/dw-report stop` e a regra de auto-desarme como limpeza obrigatória.
+
+Se o trabalho trocar de veículo no meio (ex.: a sessão foi retomada em outro lugar), `/dw-report status` precisa dizer isso honestamente: `armado no arquivo de estado, mas nenhum wake-up está agendado nesta sessão — rode /dw-report pra re-armar`.
+
+## Protocolo do Tick (a cada disparo)
+
+1. **Timestamp.** `date '+%Y-%m-%d %H:%M:%S'`.
+2. **Avaliar a partir da sessão.** A fonte de verdade é o trabalho da própria sessão — o que você fez, o que iniciou, o que voltou. Use checagens observáveis e baratas como evidência, não como arqueologia: `git log --oneline` desde o último report, `git status --short | wc -l`, o tail de um log ou stream que esta sessão iniciou, o número de passos concluídos num stream de CLI (`grep -c '"type":"item.completed"' <stream>.jsonl`), a última notificação de uma task em background. NÃO saia minerando `.dw/spec/`, `.dw/goals/` ou `STATE.md` pra reconstruir história da qual você não participou.
+3. **Classificar o momento.**
+   - **working** — algo está em andamento (um comando, um subagente, um workflow, uma execução de CLI, um build, um deploy) ou você está implementando ativamente.
+   - **blocked** — nada está rodando porque o trabalho espera o usuário (uma decisão, uma aprovação, uma credencial).
+   - **finished** — o trabalho pra o qual o loop foi armado está completo (ou falhou terminalmente) e nada mais está na fila.
+4. **Decidir se fala.**
+   - `working` → **REPORTA**. Sempre. Mesmo quando nada mudou desde o último tick ("build ainda no passo 6/9, ~4 min restantes" é um report válido e esperado).
+   - `blocked` → reporta **uma vez** quando o estado muda pra blocked (isso é novidade); depois, em todo tick em que nada mudou, **fica em silêncio**: nenhuma linha no chat, nenhuma entrada no log, nenhum bell. A checagem acontece; o output não.
+   - `finished` → **REPORT FINAL imediatamente** (não espere a cadência quando notar a conclusão fora de um tick), depois **desarma**: apaga `.active.json`, cancela o wake-up/timer pendente e diz isso no report final.
+5. **Bell (opcional).** Se `DW_REPORT_BELL` (ou `report.bell`) estiver definido, execute *antes* de escrever. Nunca num tick silencioso.
+6. **Escrever.** O report vai pro chat e é anexado literalmente em `.dw/reports/YYYY-MM-DD.md` (crie o arquivo com o cabeçalho `# Reports — YYYY-MM-DD` se não existir). Atualize `.active.json` (`seq`, `last_report_at`, `last_state`).
+7. **Re-armar** o veículo — a menos que o passo 4 tenha desarmado o loop.
+
+## Formato do Report — acumulado com delta destacado
+
+O usuário pediu report **detalhado**. Detalhado significa: todo item carrega evidência, todo item em andamento carrega um número de progresso mensurável, e a lista do que falta vem ordenada com o próximo marco primeiro.
+
+```markdown
+📊 Report — 2026-08-24 15:40:12 (#3 · every 10m · armado 15:10)
+
+## ✅ Feito (acumulado)
+- ➕ Task 3/7 — parser de importação trata campos entre aspas — `src/import/parser.ts`, commit `a1b2c3d`, 14 testes verdes
+- ➕ Task 2/7 — validação de schema CSV — commit `9f8e7d6`, `npm test` 41/41
+- Task 1/7 — fixtures de importação — commit `1234abc`
+
+## 🔄 Fazendo
+- Task 4/7 — endpoint de upsert em lote — 6 arquivos tocados, último comando `npm test -- import` (rodando há 1m40s); stream do codex: 23 passos concluídos, último `command_execution: pnpm build`
+
+## ⏳ Falta
+1. Task 5/7 — download do relatório de erros (próximo marco, depende da Task 4)
+2. Task 6/7 — ligação da UI
+3. Task 7/7 — E2E do caminho feliz
+4. Review Level 2 + QA + security gate
+
+## ⚠️ Bloqueios / decisões necessárias
+- nenhum
+```
+
+Regras:
+- **`➕` marca itens concluídos desde o report anterior.** Itens mais antigos ficam na lista sem o marcador, então cada report é autocontido e ainda mostra o ritmo.
+- **Evidência ou não aconteceu:** um caminho de arquivo, um SHA de commit, uma contagem de testes, uma linha de log. "Implementei X" sem evidência não é permitido.
+- **Progresso mensurável no Fazendo:** um contador de passos, uma contagem de arquivos, um comando rodando com o tempo decorrido, uma porcentagem vinda de uma linha de progresso real. Nunca um "em andamento" pelado.
+- **Falta é ordenado:** o próximo marco primeiro, depois o resto; inclua os gates do pipeline que ainda estão pela frente (review, QA, security audit, commit, PR) quando se aplicarem.
+- **Seção de bloqueios só quando há algo a dizer** — senão escreva `- nenhum` ou omita.
+- **Contadores do cabeçalho são reais:** `#n` é o `seq`, a cadência e a hora de arme vêm de `.active.json`.
+- Quando o loop foi armado por outro comando, o primeiro report diz isso: `armado por /dw-run (todas as tasks pendentes)`.
+
+### Report final
+
+Mesma forma, com o cabeçalho `📊 FINAL Report — <timestamp> (#n · loop desarmado)`, uma linha explícita de desfecho sob Feito (`Desfecho: todas as 7 tasks commitadas, review APROVADO` ou `Desfecho: FALHOU na task 4 — ver bloqueios`), e `Falta` listando o que o usuário ainda precisa fazer à mão (abrir o PR, aprovar o gate, mergear).
+
+### Saída no chat para arm / status / stop
+
+```
+📊 Report loop armado — every 10m · veículo: wakeup · log: .dw/reports/2026-08-24.md
+Primeiro report em ~15:20. Silencioso enquanto bloqueado; report final + auto-desarme quando o trabalho terminar. Pare com /dw-report stop.
+```
+
+```
+📊 Report loop — ARMADO · every 10m · desde 15:10 · 3 reports · último 15:40 · estado: working · log: .dw/reports/2026-08-24.md
+```
+
+```
+📊 Report loop — NÃO armado. Arme com /dw-report [--every <N>m].
+```
+
+## Disciplina de Cadência
+
+<critical>A cadência é do usuário, não sua. Nunca estique o intervalo pra "esperar o build terminar" ou "evitar ruído" — um report que diz "nada mudou, ~X min restantes" é o produto enquanto há trabalho rodando. Mude o intervalo apenas por instrução explícita do usuário (`--every`).</critical>
+
+<critical>Nunca afirme que o loop está ativo sem um wake-up agendado ou um timer em background vivo. `/dw-report status` lê `.active.json` E checa o veículo; se discordarem, diga.</critical>
+
+<critical>Silêncio é só pro estado blocked/ocioso. Estado working sempre reporta; a transição pra blocked reporta uma vez; a conclusão reporta imediatamente.</critical>
+
+## Contrato de Auto-arme (para os comandos que chamam este)
+
+Quando `/dw-run` (Modo 2 / Modo 3), `/dw-autopilot` (invocação de execução) ou um adapter `dw-cli-run` inicia trabalho longo, ele invoca `/dw-report` **antes** de despachar:
+
+- **Idempotente:** se `.dw/reports/.active.json` existe e o veículo está vivo, não faz nada (mantém a cadência existente). Se o arquivo existe mas o veículo morreu, re-arma e avisa.
+- **Respeita o opt-out:** se `DW_REPORT_AUTO=off`, pula em silêncio (uma linha na saída do chamador: `report loop: auto-arme desligado por DW_REPORT_AUTO`).
+- **Registra o chamador:** `armed_by` em `.active.json`, ecoado no primeiro report.
+- **Termina com o trabalho do chamador:** a conclusão do chamador (todas as tasks feitas + review final, goal completo + gate de PR, execução de CLI gateada) é o estado `finished` — report final, depois desarme. O chamador não precisa chamar `/dw-report stop`.
+- **Nunca bloqueia o chamador:** armar custa uma chamada de tool; se o veículo não estiver disponível, o chamador segue e imprime `report loop: nenhum veículo de wake-up disponível neste harness — rode /dw-report manualmente se quiser um timer em background`.
+
+## Anti-patterns
+- Reportar "em andamento" sem número, comando ou arquivo.
+- Inventar timestamp, SHA de commit ou contagem de testes.
+- Emitir linhas `idle` / `sem novidades` enquanto nada roda — é exatamente o ruído que este loop existe pra evitar.
+- Esticar ou pular um tick enquanto há trabalho rodando.
+- Deixar um cron de sistema pra trás depois que o trabalho acabou.
+- Ler `.dw/spec/` ou `.dw/goals/` pra narrar trabalho que esta sessão não fez.
+- Tocar o bell num tick silencioso.
+
+## Structured Return
+
+Depois de armar, parar ou a cada report, o status do próprio comando é totalmente descrito pela linha no chat mais `.dw/reports/.active.json`. Outros comandos só precisam saber: **armed (bool), every_seconds, seq, last_state**.
+
+</system_instructions>

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):**