@brunosps00/dev-workflow 2.1.0 → 2.3.0

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

@@ -1,257 +1,36 @@
 <system_instructions>
-Você é o orquestrador de pipeline completo. Este comando recebe um desejo do usuário e conduz o workflow PRD-ao-PR em duas invocações:
+# Orquestrador de implementação contínua
 
-1. **Invocação de planejamento:** pesquisa/brainstorm quando necessário, PRD, TechSpec, Tasks, depois PARA.
-2. **Invocação de execução:** retoma de `autopilot-state.json`, roda `/dw-goal --from-autopilot <prd-slug>`, depois commit e gate de PR.
+`/dw-autopilot "<wish>"` planeja e conduz trabalho aprovado até implementação e validação. `/dw-autopilot --from-prd <slug>` parte de `.dw/spec/<slug>/prd.md`; ausência bloqueia informando o caminho. `/dw-autopilot` sem descrição retoma estado salvo. Não imponha segunda invocação após aprovar tasks. Pedido somente de plano ou modo Plan ativo da plataforma termina no artefato de planejamento.
 
-<critical>A primeira invocação DEVE parar depois que os artefatos de planejamento estiverem completos. Não rode implementação, QA, review, commit ou PR na primeira invocação.</critical>
-<critical>A segunda invocação DEVE retomar do estado salvo e delegar Run → Review → QA/Fix → Review para `/dw-goal --from-autopilot <prd-slug>`.</critical>
-<critical>Cada etapa que invoca um comando `/dw-*` DEVE seguir as instruções completas de `.dw/commands/`. Leia e execute o comando inteiro, não uma versão resumida.</critical>
+## Planejamento
 
-## Quando Usar
-- Use quando quiser ir de uma ideia até um PR com mínima intervenção manual, mas com parada obrigatória após o planejamento.
-- Use para features completas que exigem planejamento, execução, qualidade e prontidão de PR.
-- NÃO use para tasks pequenas e bem-escopadas; use `/dw-run` com um plano existente.
-- NÃO use para bugfix cirúrgico; use `/dw-bugfix`.
-- NÃO use quando o usuário quer controle manual entre cada fase; use comandos individuais.
+1. Inspecione código/regras relevantes e decisões existentes. Use `.dw/intel/` quando útil; pesquise tecnologias/domínios/integrações desconhecidos. Brainstorm só para escolhas pendentes, sem entrevista obrigatória de três opções.
+2. Invoque `/dw-plan` ou estágios relevantes para produzir PRD, TechSpec, tasks e tasks-validation.md. Reutilize respostas e handoffs alinhados. Pergunte lacunas materiais pela ferramenta de entrevista disponível; não repita fatos descobertos.
+3. Na quebra apresente desenvolvimento local/cruzado, modelo/esforço concretos e agentes relevantes por complexidade. Siga `.dw/references/execution-contract.md`, escreva/valide execution-plan.json e obtenha aprovação da mesma matriz de tasks/escolhas. Respeite aprovações de estágios existentes sem repeti-las.
+4. Salve `autopilot-state.json` com `status: plan_complete`, `current_step: goal`, artefatos, caminho das escolhas aprovadas e `next_command: /dw-goal --from-autopilot <slug>`. Em pedido de implementação continue imediatamente. Em pedido somente de plano reporte-o e preserve o ponto de retomada.
 
-## Posição no Pipeline
-**Antecessor:** desejo do usuário | **Sucessor:** `/dw-goal`, `/dw-commit`, `/dw-generate-pr`
+## Execução e entrega
 
-## Skills / Comandos Complementares
+Arme `/dw-report` uma vez (idempotente, pule quando `DW_REPORT_AUTO=off`). Invoque `/dw-goal --from-autopilot <slug>` para conduzir `/dw-run` → `/dw-review` completo → `/dw-qa` aplicável → `/dw-qa --fix` para bugs Open → review pós-QA quando edições ou novos achados invalidarem review anterior. Não substitua review completo por coverage-only. Runners externos retornam ao parent para correções e continuidade, sem encerrar o goal.
 
-| Skill ou comando | Gatilho |
-|------------------|---------|
-| `dw-memory` | SEMPRE — preserva decisões entre planejamento, goal de execução, QA, review e PR. |
-| `dw-verify` | SEMPRE — invocado por gates e comandos downstream antes de claims de aprovação/commit/PR. |
-| `/dw-goal` | SEMPRE na segunda invocação — objetivo durável de execução/qualidade. |
+Use `dw-memory` para decisões duráveis e `dw-verify` para evidência válida. Security Gate continua obrigatório quando aplicável: `/dw-secure-audit` produz `.dw/secure-audit/audit-summary.md`; evidência ausente/inválida é refeita e achados bloqueantes corrigidos. SECRET findings sempre bloqueiam (sem escape por ADR). Reutilize scan válido em outro checkpoint.
 
-## Variáveis de Entrada
+Goal conclui apenas com critérios atendidos, artefatos exigidos de review/QA e checks válidos, sem achado bloqueante pendente. Para `prd-bugfix-*` escalado, localize `.dw/bugfixes/*/escalated.md` original, produza SUMMARY.md ausente com evidências e feche o índice.
 
-| Variável | Descrição | Exemplo |
-|----------|-----------|---------|
-| `{{WISH}}` | Descrição do que o usuário quer construir no modo padrão. | `"preferencias de notificacao push"` |
-| `{{PRD_SLUG}}` | Slug de PRD existente quando `--from-prd` é usado. | `prd-bugfix-stripe-webhook-retry` |
-| `{{MODE}}` | Flag opcional de invocação. | `--from-prd <slug>` |
+Inspecione commits com escopo e bookkeeping restante; `/dw-commit` faz commit final autorizado quando necessário. Não crie commits vazios nem exija commit extra para trabalho já commitado. Prepare branch/worktree validado e resumo de entrega. Merge, push e publicação de PR seguem só autorização existente. Se faltar autorização final, apresente resultado concreto e peça apenas essa ação; não repita permissão já concedida.
 
-## Modos de Invocação
+## Estado durável
 
-| Invocação | Comportamento |
-|-----------|---------------|
-| `/dw-autopilot "<wish>"` | Invocação de planejamento do zero. Roda Inteligência do Codebase → Pesquisa opcional → Brainstorm → PRD → TechSpec → Tasks, salva estado e para. |
-| `/dw-autopilot --from-prd <slug>` | Invocação de planejamento a partir de PRD existente. Começa em aprovação do PRD, depois TechSpec → Tasks, salva estado e para. |
-| `/dw-autopilot` em PRD com `autopilot-state.json status=plan_complete` | Invocação de execução. Roda `/dw-goal --from-autopilot <slug>`, depois commit e gate de PR. |
+Preserve campos de `autopilot-state.json`: mode, wish, prd_path, from_prd_slug, current_step, completed_steps, skipped_steps, skip_reasons, gates_passed, step_artifacts, goal_slug, next_command, started_at, last_updated. Acrescente caminhos `execution_plan` e `execution_state`. Registre evidência, não só existência de arquivo, antes de concluir etapa.
 
-## Pontos de Pausa Obrigatórios
-
-Autopilot pausa em:
-
-1. **Aprovação do PRD** antes do TechSpec.
-2. **Aprovação das Tasks** antes de marcar planejamento completo.
-3. **Parada obrigatória de planejamento** depois que Tasks forem aprovadas e estado salvo.
-4. **Gate de PR** depois que o goal de execução e commit completarem.
-
-Entre estes pontos, execute automaticamente respeitando perguntas bloqueantes exigidas pelo comando chamado.
-
-## Retomada de Sessão
-
-Se este comando for re-invocado no mesmo PRD:
-
-<critical>Leia `.dw/spec/<prd-slug>/autopilot-state.json` primeiro. Se `status` for `plan_complete`, não repita planejamento. Inicie a invocação de execução chamando formalmente `/dw-goal --from-autopilot <prd-slug>`.</critical>
-
-Significados de estado:
-
-| Status | Ação |
-|--------|------|
-| estado ausente | Iniciar invocação de planejamento normal. |
-| `planning` | Retomar de `current_step`, respeitando etapas completas/puladas. |
-| `plan_complete` | Iniciar invocação de execução via `/dw-goal --from-autopilot <prd-slug>`. |
-| `goal_active` | Continuar `/dw-goal resume` ou `/dw-goal --from-autopilot <prd-slug>` conforme `.dw/goals/autopilot-<prd-slug>/status.json`. |
-| `goal_complete` | Continuar para commit e gate de PR. |
-| `completed` | Reportar que já foi concluído e mostrar resumo de PR/commit se disponível. |
-
-## Invocação de Planejamento
-
-### Etapa 0: Resolver modo de invocação
-
-1. Se `--from-prd <slug>` aparece:
-   - Resolva para `.dw/spec/<slug>/`.
-   - Verifique que `prd.md` existe; senão PARE com: `Alvo de --from-prd .dw/spec/<slug>/prd.md nao encontrado. Rode /dw-plan prd ou corrija o slug.`
-   - Crie ou atualize `autopilot-state.json` com `mode: "from-prd"`, `status: "planning"`, `skipped_steps: [1,2,3,4]`, e `skip_reasons["1-4"] = "from-prd-mode"`.
-   - Pule para aprovação do PRD usando o PRD existente.
-2. Caso contrário:
-   - Crie ou atualize `autopilot-state.json` com `mode: "autopilot"`, `status: "planning"`, wish original e `current_step: 1`.
-
-### Etapa 1: Inteligência do Codebase
-
-<critical>Se `.dw/intel/` existir, consulte via `/dw-intel` antes de planejar. Caia para `.dw/rules/` e grep direto se ausente.</critical>
-
-- Identifique stack, padrões existentes, features relacionadas e restrições do projeto.
-- Se `.dw/intel/` estiver ausente, sugira `/dw-intel --build` para contexto futuro mais rico, mas continue com `.dw/rules/` e inspeção direta.
-
-### Etapa 2: Pesquisa (Condicional)
-
-Rode `/dw-brainstorm --research` quando a feature envolver tecnologia nova, domínio desconhecido, APIs externas, regulação ou arquitetura de alto impacto. Caso contrário, pule e registre o motivo em `skip_reasons`.
-
-### Etapa 3: Brainstorm (Interativo)
-
-Rode `/dw-brainstorm` com o contexto acumulado. Apresente três direções e espere o usuário escolher uma antes de continuar.
-
-### Etapa 4: PRD
-
-Rode `/dw-plan prd` usando findings de brainstorm/research.
-
-<critical>O estágio PRD deve usar a ferramenta de entrevista estruturada quando disponível. Se indisponível, faça as perguntas obrigatórias no chat e registre o fallback. O usuário deve responder; não infira respostas.</critical>
-
-Depois que `prd.md` existir, apresente resumo do PRD e aguarde aprovação explícita. Se o usuário pedir edits, atualize e reapresente.
-
-### Etapa 5: TechSpec
-
-Rode `/dw-plan techspec` a partir do PRD aprovado.
-
-<critical>O estágio TechSpec deve usar a ferramenta de entrevista estruturada quando disponível. Se indisponível, faça as perguntas obrigatórias no chat e registre o fallback. O usuário deve responder; não infira respostas.</critical>
-
-Depois que `techspec.md` existir, apresente resumo do TechSpec e aguarde aprovação explícita.
-
-### Etapa 6: Tasks
-
-Rode `/dw-plan tasks` a partir de PRD + TechSpec. Verifique:
-- `tasks.md` existe.
-- arquivos per-task existem.
-- `tasks-validation.md` existe e passou ou tem override explícito do usuário.
-
-### Etapa 7: Aprovação das Tasks e Parada Obrigatória
-
-Apresente resumo das tasks, dependências e esforço total. Aguarde aprovação explícita.
-
-Após aprovação:
-
-1. Salve `.dw/spec/<prd-slug>/autopilot-state.json` com:
-
-```json
-{
-  "status": "plan_complete",
-  "current_step": "goal",
-  "next_command": "/dw-goal --from-autopilot <prd-slug>"
-}
-```
-
-2. Inclua `completed_steps` para todas as etapas de planejamento completas e `step_artifacts` para `prd.md`, `techspec.md`, `tasks.md`, arquivos per-task e `tasks-validation.md`.
-3. PARE e diga ao usuário que a fase de planejamento está completa. Não rode implementação nesta invocação.
-
-## Invocação de Execução
-
-### Etapa 8: Goal Durável de Execução
-
-Quando `autopilot-state.json status=plan_complete`, invoque formalmente:
-
-```text
-/dw-goal --from-autopilot <prd-slug>
-```
-
-O goal é dono desta sequência:
-
-1. `/dw-run <prd-path>`
-2. `/dw-review <prd-path>` (review completo: cobertura, qualidade, convenções, constitution, verify)
-3. `/dw-qa <prd-path>`
-4. `/dw-qa --fix <prd-path>` se QA encontrou bugs Open
-5. `/dw-review <prd-path>` novamente após QA/fixes
-6. **Security Gate** — o `/dw-review` pós-QA (passo 5) aciona o `/dw-secure-audit`, produzindo um `.dw/secure-audit/audit-summary.md` fresco. Este passo **garante** que o verdict é APROVADO: se ausente/desatualizado/REPROVADO, rode `/dw-secure-audit <prd-path>` standalone, depois volte pro `/dw-bugfix` por finding e re-cheque. Findings SECRET sempre bloqueiam (sem escape de ADR). Não force um segundo scan completo quando já existe um summary APROVADO fresco.
-
-<critical>Não substitua os reviews do goal por `/dw-review --coverage-only`. O goal de qualidade do autopilot exige `/dw-review` completo antes do QA e depois dos fixes de QA.</critical>
-
-Depois que `/dw-goal` completar, verifique que `.dw/goals/autopilot-<prd-slug>/status.json` tem `status: "complete"`, então defina `autopilot-state.json status: "goal_complete"`.
-
-### Etapa 9: Fechar Loop de Bugfix (Condicional)
-
-Se `mode == "from-prd"` e o slug do PRD casar com `prd-bugfix-*`, feche o índice de bugfix antes do commit:
-- Encontre `.dw/bugfixes/*/escalated.md` que referência o slug do PRD.
-- Se `SUMMARY.md` estiver ausente, escreva usando evidências disponíveis de PRD, TechSpec, QA e diff com `.dw/templates/bugfix-summary-template.md`.
-- Nunca fabrique evidência de verificação.
-- Registre artefatos em `autopilot-state.json`.
-
-### Etapa 10: Auditoria Pre-Commit
-
-Antes de `/dw-commit`, verifique:
-- `.dw/goals/autopilot-<prd-slug>/status.json` está completo.
-- `<prd-path>/QA/review-consolidated.md` existe a partir do review final pós-QA.
-- `<prd-path>/QA/qa-report.md` e `<prd-path>/QA/bugs.md` existem.
-- **Security Gate passou:** `.dw/secure-audit/audit-summary.md` existe, está fresco (pós-última-edição) e status APROVADO. Se ausente/desatualizado/REPROVADO → PARE (não commite).
-- `autopilot-state.json` registra artefatos de planejamento e o goal completo.
-
-Se algo estiver faltando, PARE e re-execute o comando formal ausente. Não faça commit parcial.
-
-### Etapa 11: Commit
-
-Rode `/dw-commit` automaticamente. Não aguarde aprovação depois que o goal estiver completo.
-
-### Etapa 12: Gate de Pull Request
-
-Pergunte: **"Commits realizados. Deseja gerar o Pull Request?"**
-
-- SIM: rode `/dw-generate-pr`.
-- NÃO: informe que os commits estão prontos e o PR pode ser gerado depois.
-
-Marque `autopilot-state.json status: "completed"` após commit, e inclua link do PR se gerado.
-
-## Persistencia de Estado
-
-`autopilot-state.json` deve incluir:
-
-```json
-{
-  "mode": "autopilot",
-  "status": "planning",
-  "wish": "descricao original do usuario",
-  "prd_path": ".dw/spec/prd-name",
-  "from_prd_slug": null,
-  "current_step": 1,
-  "completed_steps": [],
-  "skipped_steps": [],
-  "skip_reasons": {},
-  "gates_passed": [],
-  "step_artifacts": {},
-  "goal_slug": null,
-  "next_command": null,
-  "started_at": "2026-05-20T00:00:00Z",
-  "last_updated": "2026-05-20T00:00:00Z"
-}
-```
-
-Atualize estado depois de cada etapa completa ou pulada. Uma etapa só está completa depois que artefatos obrigatórios existem.
-
-## Formato de Progresso
-
-Reporte progresso depois de cada etapa:
-
-```text
-=== AUTOPILOT =====================================
-  OK [1] Inteligencia do Codebase
-  OK [2] Pesquisa (pulada — dominio conhecido)
-  OK [3] Brainstorm
-  OK [4] PRD
-  OK [5] TechSpec
-  OK [6] Tasks
-  STOP [PLAN COMPLETE] Proximo: /dw-goal --from-autopilot prd-name
-===================================================
-```
-
-Durante a invocação de execução:
-
-```text
-=== AUTOPILOT =====================================
-  OK [PLAN] Ja completo
-  RUN [GOAL] /dw-goal --from-autopilot prd-name
-  NEXT [COMMIT] apos goal status=complete
-===================================================
-```
-
-## Anti-patterns
-
-- Não continue para implementação durante a primeira invocação.
-- Não pule `/dw-goal` durante a segunda invocação.
-- Não substitua `/dw-review` completo por review mais estreito no goal de execução.
-- Não marque estado completo a partir de validação manual.
-- Não reexecute planejamento quando `status=plan_complete`; retome o goal.
+| status | Ação de retomada |
+|---|---|
+| ausente / planning | Continue apenas planejamento pendente; preserve decisões resolvidas. |
+| plan_complete | Execute plano aprovado por `/dw-goal --from-autopilot <slug>` quando implementação for solicitada. |
+| goal_active | `/dw-goal resume` com estado salvo de task/executor. |
+| goal_complete | Prepare entrega e ações restantes autorizadas de commit/publicação. |
+| completed | Reporte entrega validada e links/branch; publicação pode aguardar autorização. |
 
+Atualize estado após cada checkpoint. Reporte task atual, evidência e restante de forma compacta. Preserve checkpoints em pausa ou bloqueio real; corrija falhas recuperáveis no escopo e continue.
 </system_instructions>

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

@@ -247,51 +247,25 @@
     | Pergunta | Se SIM |
     |----------|--------|
     | Precisa de migration/alteração de schema? | Redirecionar para PRD |
-    | Afeta mais de 5 arquivos? | Redirecionar para PRD |
+    | Escopo de arquivos maior? | Reavalie organização e risco real; sem parada automática |
     | Requer novo endpoint? | Redirecionar para PRD |
     | Muda contrato de API existente? | Redirecionar para PRD |
     | Afeta múltiplos projetos? | Redirecionar para PRD |
-    | Estimativa > 2 horas de implementação? | Redirecionar para PRD |
+    | Estimativa maior de implementação? | Reorganize/checkpoint dentro do escopo aprovado |
 
-    ### 5.0. Safety Valve (OBRIGATÓRIO antes do passo 5)
+    ### 5.0. Safety Valve (antes da implementação)
 
-    <critical>
-    ANTES de desenhar a lista numerada do passo 5, esboce inline os passos que pretende escrever.
-    Se esse esboço revelar **mais de 5 tasks numeradas distintas**, OU **qualquer dependência cross-file que obrigue ordem específica de execução**, OU **uma task que requeira rodar migration / refactor / novo endpoint / alteração de contrato de API**, então o escopo do bugfix foi SUBESTIMADO e você DEVE escalar.
-    </critical>
-
-    **Por que isso existe:** a triagem do passo 0 pega problemas de escopo a partir da descrição do sintoma. O checkpoint 4.1 pega depois da análise de causa raiz. Esta válvula pega o caso que sobra — quando o fix em si, uma vez listado, revela mais complexidade do que triagem e RCA previram. NÃO existe flag de bypass. Escalar é o desfecho correto.
-
-    **Procedimento de escalação:**
-
-    1. Aloque `NNN` para `.dw/bugfixes/NNN-<slug>/`. Escreva `TASK.md` com a triagem, clarificações, causa raiz e plano que seria executado.
-    2. Crie `.dw/spec/prd-bugfix-<slug>/` e escreva `prd.md` lá (use `.dw/templates/bugfix-template.md`). Este é o path que `/dw-plan` espera.
-    3. Escreva `.dw/bugfixes/NNN-<slug>/escalated.md` com: `Escalated to /dw-plan on <YYYY-MM-DD> — reason: <qual critério da válvula disparou> → see .dw/spec/prd-bugfix-<slug>/`.
-    4. Reporte ao usuário:
-
-    ```
-    ## Escopo maior que bugfix
-
-    Listando o fix produziu [N] tasks / [deps cross-file] / [tipo de mudança proibida].
-    Pelo safety valve, isso não é mais um bugfix cirúrgico.
-
-    Índice do bugfix preservado em `.dw/bugfixes/NNN-<slug>/{TASK.md, escalated.md}`.
-    PRD criado em `.dw/spec/prd-bugfix-<slug>/prd.md`.
-
-    Próximo — escolha um:
-      - Cadeia manual: `/dw-plan techspec prd-bugfix-<slug>` → `/dw-plan tasks prd-bugfix-<slug>` → `/dw-run` → `/dw-qa` → `/dw-review` → `/dw-commit` → `/dw-generate-pr`.
-      - Entregar pro autopilot: `/dw-autopilot --from-prd prd-bugfix-<slug>` — roda a fase de planejamento a partir do PRD existente, para depois de Tasks, e uma invocacao posterior retoma via `/dw-goal`.
-    ```
+    Inspecione o fix proposto por mudanças materiais de escopo ou arquitetura. Quantidade de tasks/arquivos, dependências de ordem e estimativas maiores sinalizam organização, não bloqueio automático. Refactor necessário para corrigir comportamento aprovado pode permanecer no escopo. Contrato novo de produto, migration sensível ou decisão arquitetural pendente exige proposta concreta antes de implementar trabalho dependente.
 
-    5. Pare este comando. Não avance para o passo 5. O usuário (ou autopilot) invoca `/dw-plan` ou `/dw-autopilot --from-prd` em seguida.
+    Quando precisar de plano estruturado, preserve `.dw/bugfixes/NNN-<slug>/TASK.md`, crie `.dw/spec/prd-bugfix-<slug>/prd.md` pelo template de bugfix e registre referência em `escalated.md`. Continue por `/dw-plan` ou `/dw-autopilot --from-prd prd-bugfix-<slug>` conforme intenção existente. A quebra propõe executor/modelo/agentes; após aprovação continue na mesma invocação. Não peça autorização novamente para organizar fix já autorizado. Pedido somente de análise termina no relatório.
 
-    **Se a válvula NÃO disparar:** Continue para o passo 5.
+    Sem nova decisão material nem necessidade de plano estruturado, continue no passo 5.
 
     ### 5. Propor Tarefas Numeradas (Obrigatório)
 
     <critical>
     Liste TODAS as tarefas necessárias, numeradas sequencialmente.
-    Aguarde aprovação antes de executar.
+    Use aprovação existente do mesmo escopo; pergunte só decisões materiais novas antes de executar.
     </critical>
 
     **Formato:**
@@ -364,8 +338,8 @@
 
     Opção B (entregar pro autopilot):
     1. Rode: `/dw-autopilot --from-prd prd-bugfix-<slug>`
-    2. Autopilot roda aprovacao do PRD, TechSpec e Tasks, depois para com `status: plan_complete`.
-    3. Uma invocacao posterior do autopilot retoma via `/dw-goal --from-autopilot prd-bugfix-<slug>` para Run, Review completo, QA/Fix e Review completo pos-QA antes de commit/PR.
+    2. Autopilot roda aprovacao do PRD, TechSpec e Tasks, registra `status: plan_complete` e continua após aprovação das tasks/escolhas de execução.
+    3. A mesma invocação do autopilot retoma via `/dw-goal --from-autopilot prd-bugfix-<slug>` para Run, Review completo, QA/Fix e Review completo pos-QA antes de commit/PR.
 
     O índice do bugfix continua queryable via `/dw-intel "bugfix history in <module>"`. Downstream `/dw-review --bugfix <slug>` e `/dw-qa --bugfix <slug>` ainda apontam para `.dw/bugfixes/NNN-<slug>/` quando quiser uma revisão focada apenas no patch cirúrgico final.
     ```

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