@brunosps00/dev-workflow 2.6.0 → 2.7.0

package/scaffold/pt-br/commands/dw-functional-doc.md

@@ -53,7 +53,7 @@ Funciona melhor com projeto analisado por `/dw-analyze-project`
 
 ## Skills complementares
 
-Quando disponíveis no projeto em `./.agents/skills/`, use estas skills como apoio operacional, sem substituir este comando como fonte de verdade:
+Quando disponíveis no projeto em `./.dw/skills/`, use estas skills como apoio operacional, sem substituir este comando como fonte de verdade:
 
 - `dw-testing-discipline`: apoio para estruturar fluxos E2E (`references/playwright-recipes.md`), padrões de coleta de evidência, e aplicar core rules + hierarquia de seletores em qualquer teste referenciado pelo doc
 - `remotion-best-practices`: apoio obrigatório quando houver vídeo humano final, legendas, composição, transições, FFmpeg ou Remotion

package/scaffold/pt-br/commands/dw-harness-audit.md

@@ -29,7 +29,7 @@ Você é o auditor do harness dev-workflow.
 5. Recomende os 3 principais fixes.
 
 ## Triagem de degradação em runtime (sob demanda)
-O scorecard acima e saúde determinística da **instalação**. Se o problema for o *agente* se comportando mal em runtime (loops, desvio do objetivo, edições alucinadas, raciocínio degradado), o diagnóstico e outro: aponte o usuário para `.agents/skills/dw-debug-protocol/references/agent-degradation.md` (tabela sintoma→causa + recovery ordenado). Apenas informativo — não afeta o scorecard.
+O scorecard acima e saúde determinística da **instalação**. Se o problema for o *agente* se comportando mal em runtime (loops, desvio do objetivo, edições alucinadas, raciocínio degradado), o diagnóstico e outro: aponte o usuário para `.dw/skills/dw-debug-protocol/references/agent-degradation.md` (tabela sintoma→causa + recovery ordenado). Apenas informativo — não afeta o scorecard.
 
 ## Saída
 Retorne um scorecard e não altere arquivos. Para drift de arquivo gerenciado, indique `dev-workflow repair`.

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

@@ -64,7 +64,7 @@ Não recuse responder — devolva a melhor info disponível.
 
 ### 2. Detecção do shape da query
 
-Classifique o `{{QUERY}}` em uma das formas documentadas em `.agents/skills/dw-codebase-intel/references/query-patterns.md`:
+Classifique o `{{QUERY}}` em uma das formas documentadas em `.dw/skills/dw-codebase-intel/references/query-patterns.md`:
 
 - **where-is** — primário: `files.json`, secundário: `apis.json`
 - **what-uses** — primário: `deps.json` (libs) ou `files.json` (símbolos)

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

@@ -23,7 +23,7 @@ Colete sinais apenas do que já está persistido:
 4. **Apresente** os candidatos no chat como lista markdown — id, trigger, action, confidence, evidence. NÃO escreva ainda.
 5. **Pergunte**: "Aprovar quais para armazenar? (ids, ou 'todos', ou 'nenhum'). Algum para promover a principio de constitution?"
 6. Na aprovação:
-   - Grave cada instinct aprovado em `.dw/memory/instincts/<slug>.md` no formato de `.agents/skills/dw-memory/references/instincts.md` (crie ou atualize; nunca duplique um id existente).
+   - Grave cada instinct aprovado em `.dw/memory/instincts/<slug>.md` no formato de `.dw/skills/dw-memory/references/instincts.md` (crie ou atualize; nunca duplique um id existente).
    - Para os que o usuário escolher promover, encaminhe ao fluxo de constitution — proponha um principio `P-NNN` em `severity: info` para o Step 8 do `/dw-analyze-project`. NÃO edite `.dw/constitution.md` direto sem o usuário reconfirmar.
 7. Atualize a confiança de instincts existentes que a nova evidência reconfirme ou contradiga.
 

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

@@ -39,7 +39,7 @@ Você é o líder de bootstrap de workspace do dev-workflow. Sua função é peg
 - One-pager do projeto: `.dw/spec/projects/{{PROJECT_NAME}}.md` (usa `.dw/templates/project-onepager.md`)
 - Relatório final: `.dw/spec/projects/{{PROJECT_NAME}}-bootstrap.md`
 - Rules semeadas: `.dw/rules/index.md` (mínimo, depois substituido/enriquecido por `/dw-analyze-project`)
-- Receitas de compose: `.agents/skills/docker-compose-recipes/services/*.yml`
+- Receitas de compose: `.dw/skills/docker-compose-recipes/services/*.yml`
 
 ## Comportamento Obrigatório — Pipeline
 
@@ -157,7 +157,7 @@ Se fullstack:
 
 #### 3.3 Gerar `docker-compose.dev.yml`
 
-1. Leia `.agents/skills/docker-compose-recipes/SKILL.md` e os `services/<nome>.yml` relevantes.
+1. Leia `.dw/skills/docker-compose-recipes/SKILL.md` e os `services/<nome>.yml` relevantes.
 2. Aplique o algoritmo de merge de `references/compose-composition.md`:
    - Concatene blocos sob `services:`.
    - Agregue volumes nomeados sob `volumes:`.
@@ -300,7 +300,7 @@ monorepo: <pnpm-workspaces|turborepo|nx|none>
 | ... | ... | ... |
 
 ## Servicos Compostos
-<tabela de servicos com porta + URL UI + requisitos de credenciais, vinda de .agents/skills/docker-compose-recipes/>
+<tabela de servicos com porta + URL UI + requisitos de credenciais, vinda de .dw/skills/docker-compose-recipes/>
 
 ## Proximos Passos
 1. `cp .env.example .env`, gere secrets locais unicos e defina todo valor obrigatorio como `POSTGRES_PASSWORD`.

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

@@ -30,7 +30,7 @@ Você é um orquestrador de planejamento que conduz uma ideia pelo pipeline comp
 
 ## Skills Complementares
 
-Quando disponíveis em `./.agents/skills/`, use como suporte:
+Quando disponíveis em `./.dw/skills/`, use como suporte:
 
 - `dw-source-grounding`: **SEMPRE** no estágio TechSpec — toda decisão de framework/library cita docs oficiais com versão + data.
 - `dw-ui-discipline`: **OBRIGATÓRIO** quando PRD tem superfícies de UI — roda as 4 grounding questions antes do design visual entrar no TechSpec.
@@ -169,7 +169,7 @@ Roda em modo padrão (após aprovação do TechSpec) OU `plan tasks`.
 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>`.
-6. **Subtask LLM-eval (quando aplicável):** se PRD tem feature AI, uma task deve incluir Eval Plan subtask (reference dataset path, oracle rungs, judge calibration, target metrics).
+6. **Subtask LLM-eval (quando aplicável):** se PRD tem feature AI, uma task deve incluir Eval Plan subtask (reference dataset path, oracle rungs, judge calibration, target metrics), ordenada antes das subtasks de implementação: spec do comportamento (quando / faz / não deve / continua funcionando), casos, e uma run baseline no código atual em que os casos do comportamento novo falham.
 7. **Declaração de dependência:** cada task lista explicitamente de quais tasks anteriores depende. Escreva o campo como `Depends on: none` ou `Depends on: 1.0, 2.0` em `tasks.md` e em cada `<N>_task.md`. Validação rejeita ciclos.
 8. **Outputs:**
    - Summary: `.dw/spec/prd-<feature-slug>/tasks.md`

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

@@ -48,14 +48,14 @@ Compute `<target>` UMA VEZ no início; substitua onde aparecer `<target>` abaixo
 
 ## Skills Complementares
 
-Quando disponíveis em `./.agents/skills/`, invocadas operacionalmente:
+Quando disponíveis em `./.dw/skills/`, invocadas operacionalmente:
 
 - `dw-testing-discipline`: **(modo UI — SEMPRE)** — core rules e 25 anti-patterns valem pra todo teste QA. `references/playwright-recipes.md` pra patterns táticos. `references/three-workflow-patterns.md` pra escolher modo de verificação (UI / network / perf). `references/security-boundary.md` pra fluxos que cruzam auth.
 - `api-testing-recipes`: **(modo API — SEMPRE)** — snippets validados pra `.http`, pytest+httpx, supertest, WebApplicationFactory, reqwest. Compõe per-FR test files em `QA/scripts/api/` e logs JSONL em `QA/logs/api/`.
-- `dw-llm-eval`: **(modo AI — quando invocado com `--ai`)** — roda reference dataset contra implementação atual. Computa precision@k / faithfulness / outcome accuracy. Loga JSONL em `QA/logs/ai/<feature>-<date>.jsonl`. Alerta em regressão >10% vs run anterior.
+- `dw-llm-eval`: **(modo AI — quando invocado com `--ai`)** — roda reference dataset contra implementação atual. Computa precision@k / faithfulness / outcome accuracy. Loga JSONL em `QA/logs/ai/<feature>-<date>.jsonl`. Lista flips pass → fail por caso vs run anterior (cada um é bug) e alerta em regressão >10% de métrica.
 - `dw-debug-protocol`: **(em modo `--fix` — SEMPRE)** — six-step triage (Reproduzir → Localizar → Reduzir → Fix Root Cause → Guardar → Verify End-to-End) pra cada bug detectado. Stop-the-line discipline; root-cause sobre symptom; regression test no mesmo commit atômico.
 - `vercel-react-best-practices`: (modo UI) quando risco de regressão React/Next.js suspeitado.
-- `dw-ui-discipline`: (modo UI) ao validar consistência de design — anti-slop catalog + WCAG accessibility floor.
+- `dw-ui-discipline`: (modo UI) ao validar consistência de design — anti-slop catalog + WCAG accessibility floor, mais o passe de content stress de `references/content-stress.md`.
 - `dw-chaos-engineering`: **(só por nome)** — passagem adversarial sobre uma mudança cujos testes normais já passam. Peça depois do QA verde, quando resiliência importa mais que cobertura; escreve só testes, roda local e tem teto de 3 rodadas. Nunca é invocada sozinha.
 - `dw-verify`: **(em modo `--fix` — SEMPRE)** — antes de marcar bug como `Fixed` ou `Closed`, requer VERIFICATION REPORT PASS (test + lint + build) E evidência de reteste (screenshot em UI, JSONL log em API, eval-run delta em AI).
 
@@ -92,7 +92,8 @@ Leia a baseline de qualidade/TechSpec do módulo afetado. Reutilize evidência v
    - Fluxos negativos (ações não autorizadas, input malformado).
    - Regressions (smoke check em surfaces adjacentes).
    - WCAG 2.2 accessibility per `dw-ui-discipline/references/accessibility-floor.md`.
-4. **Capturar evidência**: screenshots em 375px mobile + 1440px desktop, console logs, network HARs.
+   - Content stress per `dw-ui-discipline/references/content-stress.md` em toda surface que renderiza dado de usuário ou de API: mapear os campos renderizados e seus limites, montar uma fixture de pior caso realista (mais vazio, um item e 1.000+ linhas), injetá-la na fronteira de dados — fixtures/mocks do próprio projeto, ou `page.route()` no teste; nunca editando o componente — e checar na largura real do container, em 320px, com zoom de 200% e em dark mode/RTL quando o produto suporta. Cada quebra vai para `bugs.md` com o mapeamento de severidade da reference (Broken → high, Ugly → medium, Fragile → low). Comportamento de plataforma mobile (hover preso, zoom em input, safe areas) não reproduz em emulação: liste em `qa-report.md` como pendente de aparelho real em vez de marcar como aprovado.
+4. **Capturar evidência**: screenshots em 375px mobile + 1440px desktop, console logs, network HARs; no passe de content stress, screenshots da fixture de pior caso em 320px e com zoom de 200%.
 5. **Detectar páginas stub/placeholder**: qualquer página com "TODO" ou conteúdo dummy óbvio → flagar como bug.
 6. **Escrever `qa-report.md`**: test plan, execution log, refs de evidência, contagem de bugs por severity.
 7. **Escrever `bugs.md`**: uma entrada por bug com severity, repro steps, link de evidência, status (`Open`).
@@ -117,7 +118,7 @@ Leia a baseline de qualidade/TechSpec do módulo afetado. Reutilize evidência v
    - Agent: outcome assertion + trajectory match (per parâmetro `--ai-mode` ou config da feature).
    - Classification: exact match accuracy.
 3. Logar JSONL em `QA/logs/ai/<feature>-<date>.jsonl`.
-4. Comparar com JSONL da run anterior — alertar em regressão >10% em qualquer métrica.
+4. Comparar com o JSONL da run anterior caso a caso: listar todo caso que virou pass → fail e registrar cada um como bug, seja qual for a média. Depois alertar em regressão >10% em qualquer métrica. Rodar também o split `holdout` e reportar separado do `dev`.
 5. Anexar seção modo-AI em `qa-report.md`.
 
 ## Modo 1.5: UAT Interativo (`/dw-qa --uat`)

package/scaffold/pt-br/commands/dw-redesign-ui.md

@@ -38,7 +38,7 @@ digraph redesign_decision {
 
 ## Skills Complementares
 
-Quando disponíveis no projeto em `./.agents/skills/`, use para guiar o redesign:
+Quando disponíveis no projeto em `./.dw/skills/`, use para guiar o redesign:
 
 - `dw-ui-discipline`: **OBRIGATÓRIO** — roda o hard-gate de 4 checkpoints (brand authorities OU curated defaults; surface job sentence; state matrix completa; scene sentence) ANTES de qualquer proposta. Os 14 anti-slop patterns são checados contra cada direção. O WCAG 2.2 AA floor é não-negociável no step de validate.
 - `vercel-react-best-practices`: use quando o projeto for React/Next.js para padrões de performance e implementação
@@ -58,10 +58,10 @@ Utilize ferramentas de diagnóstico conforme o framework do projeto:
 1. Identifique o alvo: página, componente ou rota que será redesenhada.
 2. **AUDITAR**: leia a implementação atual, identifique stack CSS (Tailwind, CSS Modules, styled-components, etc.), capture o screenshot do estado-antes (Playwright MCP, ou `node .dw/scripts/lib/capture-screenshots.mjs` como fallback resiliente no WSL), rode react-doctor se projeto React.
 3. Faça 3 a 5 perguntas sobre objetivos do redesign: direção de estilo, constraints de marca, inspirações, público-alvo, dispositivos prioritários.
-4. **PROPOR**: apresente 2 a 3 direções de design depois de passar pelo hard-gate de `dw-ui-discipline` (brand authorities ou curated defaults; surface job sentence; state matrix enumerada; scene sentence). Cada direção lista paleta de cores, par tipográfico, estilo de layout e racional. Self-check de cada direção contra os 14 anti-slop patterns. Para CADA direção, descreva explicitamente o layout mobile (<=768px) e o layout desktop (>=1024px), incluindo como os elementos se reorganizam, empilham ou escondem entre breakpoints.
+4. **PROPOR**: apresente 2 a 3 direções de design depois de passar pelo hard-gate de `dw-ui-discipline` (brand authorities ou curated defaults; surface job sentence; state matrix enumerada; scene sentence). As direções precisam divergir num eixo nomeado — layout, densidade, personalidade, motion ou modelo de interação — e recebem o nome da direção ("Quiet", "Editorial", "Dense"), nunca "Opção A/B/C"; três tons da mesma ideia contam como uma direção só. Cada direção lista seu eixo, paleta de cores, par tipográfico, estilo de layout e racional. Self-check de cada direção contra os 14 anti-slop patterns. Para CADA direção, descreva explicitamente o layout mobile (<=768px) e o layout desktop (>=1024px), incluindo como os elementos se reorganizam, empilham ou escondem entre breakpoints.
 5. Espere aprovação explícita do usuário antes de implementar.
 6. **IMPLEMENTAR**: aplique o design escolhido com abordagem mobile-first — implemente primeiro o layout mobile e depois adicione media queries/breakpoints para tablet e desktop. Respeite a stack existente. Use `vercel-react-best-practices` para React/Next.js. Mantenha a metodologia CSS do projeto.
-7. **VALIDAR**: capture estado depois em AMBAS as resoluções (mobile e desktop), compare antes/depois, verifique acessibilidade contra `dw-ui-discipline/references/accessibility-floor.md` (WCAG 2.2 AA — não-negociável: contraste, focus-visible, keyboard nav, ARIA, sem traps), rode react-doctor `--diff` se React. Capture screenshots em 375px (mobile) e 1440px (desktop) — `node .dw/scripts/lib/capture-screenshots.mjs --url <url> --widths 375,1440` é o caminho resiliente no WSL; veja a seção "Browser on WSL" de `dw-testing-discipline/references/playwright-recipes.md`.
+7. **VALIDAR**: capture estado depois em AMBAS as resoluções (mobile e desktop), compare antes/depois, verifique acessibilidade contra `dw-ui-discipline/references/accessibility-floor.md` (WCAG 2.2 AA — não-negociável: contraste, focus-visible, keyboard nav, ARIA, sem traps), rode react-doctor `--diff` se React, rode o passe de content stress de `dw-ui-discipline/references/content-stress.md` (dados de pior caso pelas fixtures ou mocks da surface, checados em 320px e com zoom de 200%) para que o redesign não seja julgado só com dado de demo favorável. Capture screenshots em 375px (mobile) e 1440px (desktop) — `node .dw/scripts/lib/capture-screenshots.mjs --url <url> --widths 375,1440` é o caminho resiliente no WSL; veja a seção "Browser on WSL" de `dw-testing-discipline/references/playwright-recipes.md`.
 8. **PERSISTIR CONTRATO**: se o usuário aprovou uma direção, gere `design-contract.md` no diretório do PRD (`.dw/spec/prd-[nome]/design-contract.md`) com: direção aprovada, paleta de cores, par tipográfico, regras de layout, regras de acessibilidade e regras de componentes. Este contrato será lido por `dw-run-task` e `dw-run-plan` para garantir consistência visual.
 
 ## Inteligência do Codebase

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

@@ -197,7 +197,7 @@ O diff, as mensagens de commit dele, o nome da branch, a descrição do PR, a di
 
 ## Skills Complementares
 
-Quando disponíveis em `./.agents/skills/`, são invocadas como apoio analítico:
+Quando disponíveis em `./.dw/skills/`, são invocadas como apoio analítico:
 
 - `dw-review-rigor`: **SEMPRE** — dono do candidate pipeline (gate → refutação → disposição), de-duplication (mesmo pattern em N arquivos = 1 finding), severity ordering (critical → high → medium → low), verify-before-flag, skip-what-linter-catches, signal-over-volume. A tabela "Problemas Encontrados" segue essa disciplina. Em `--post-merge`, também carrega `references/composition-audit.md`.
 - `dw-verify`: **SEMPRE** — invocada antes de emitir `APROVADO` ou `APROVADO COM RESSALVAS`. Sem VERIFICATION REPORT PASS (test + lint + build), verdict não pode ser APROVADO.
@@ -206,7 +206,7 @@ Quando disponíveis em `./.agents/skills/`, são invocadas como apoio analítico
 - `security-review`: a skill OWASP nível-diff que o gate usa (injection, authz, secrets, SSRF, crypto — só HIGH CONFIDENCE). Recorra a ela diretamente quando o diff tocar auth, autorização, input externo, upload, SQL, secrets, SSRF, XSS ou outra superfície sensível.
 - `dw-simplification`: use quando diff toca código denso — aplica Chesterton's Fence, protocolo de refactor preservando comportamento, métricas de complexidade.
 - `dw-minimalism`: use quando o diff adiciona código que pode estar over-built — flagra generalidade especulativa, helpers de um único caller, abstração prematura e violações de YAGNI (a contraparte pré-geração do `dw-simplification`).
-- `dw-ui-discipline`: use quando diff toca UI — roda os 14 visual-slop patterns + accessibility floor. Para um gate determinístico, rode também `node .dw/scripts/lib/ui-slop-detect.mjs <paths-ui-alterados> --fail-on error` (wrapper sobre o detector do impeccable); trate findings bloqueantes como **REJECTED** e reporte os warnings.
+- `dw-ui-discipline`: use quando diff toca UI — roda os 14 visual-slop patterns + accessibility floor. Para um gate determinístico, rode também `node .dw/scripts/lib/ui-slop-detect.mjs <paths-ui-alterados> --fail-on error` (wrapper sobre o detector do impeccable); trate findings bloqueantes como **REJECTED** e reporte os warnings. Quando o diff adiciona ou muda motion (`transition`, `animation`, `@keyframes`, props de biblioteca de animação), cheque contra os gatilhos de escalonamento de `references/motion.md` §9; quando renderiza dado de usuário ou de API, cheque os sinais estáticos de `references/content-stress.md`. Ambos geram candidatos para o `dw-review-rigor`, nas severidades que essas references definem.
 - `dw-testing-discipline`: use quando diff toca testes — aplica catálogo de 25 anti-patterns + 6 agent guardrails (quando testes foram agent-authored).
 - `dw-llm-eval`: **OBRIGATÓRIO quando diff toca código de feature AI/LLM**. Reference dataset + ≥2 oracle rungs + judge calibration (se rung 4 usado) + eval run results DEVEM estar no PR. Faltando → REPROVADO.
 - `vercel-react-best-practices`: use quando diff toca React/Next.js.

package/scaffold/pt-br/commands/dw-skill-health.md

@@ -7,7 +7,7 @@ Você é o auditor de saúde de skills e agentes do dev-workflow.
 - Use antes de promover um aprendizado para skill reutilizavel.
 
 ## Processo
-1. Leia `scaffold/skill-registry.json` ao auditar o repo dev-workflow, ou `.dw/skill-registry.json` + `.agents/skills/` em projetos consumidores.
+1. Leia `scaffold/skill-registry.json` ao auditar o repo dev-workflow, ou `.dw/skill-registry.json` + as skills bundled instaladas em `.dw/skills/` em projetos consumidores. Skills em `.claude/skills/`, `.agents/skills/` e nos demais índices de agente são wrappers de comando ou do próprio usuário; uma skill do dev-workflow encontrada lá é cópia legada que o `update` remove.
 2. Agrupe skills por `kind`: `protocol`, `domain-pack`, `recipe-pack`, `asset-pack`.
 3. Valide que toda skill tem trigger, output esperado, owner, load policy e limite de contexto.
 4. Valide que todo `SKILL.md` bundled tem contrato `## Structured Return` com `Status`, `Scope`, `Evidence`, `Artifacts`, `Decisions`, `Risks` e `Next Step`.
@@ -59,6 +59,28 @@ Declare a janela antes de qualquer julgamento: conte as linhas instrumentadas
 
 Recomende rebaixar só quando TUDO valer: coorte invocável por modelo; ao menos 20 sessões instrumentadas ou 30 dias de janela; zero referências; sem sinal de artefato; comando owner alcançável. Abaixo disso, mostre as contagens e diga que a janela é curta demais para concluir. Remover skill bundled do pacote é entrada append-only em `lib/removed-bundled-skills.js` — este comando propõe, nunca remove e nunca deleta arquivo.
 
+### Comandos — quais entradas merecem lugar no índice
+
+Todo comando `dw-*` instalado é uma entrada no índice de skills de cada agente, e índice lotado piora a escolha que o modelo faz ali. Linhas com o objeto `commands` registram quais comandos a sessão carregou: uma leitura de `.dw/commands/<nome>.md` (todo wrapper faz uma) ou uma chamada da ferramenta Skill nomeando o comando. As regras das skills valem sem mudança: chave `commands` ausente é falta de telemetria, a janela é contada só pelas linhas que trazem `commands`, e a contagem mede carregamento, não sucesso. O hook lê só transcripts do Claude Code; quando o projeto também roda Codex, Copilot ou OpenCode, diga que essas sessões não entram na conta.
+
+Mostre uma tabela: comando, sessões que o carregaram, referências. Depois, para cada família de comandos com o mesmo propósito, mostre as contagens dos membros lado a lado:
+
+| Família | Membros |
+|---|---|
+| Handoff de subagente | `dw-subtask-start`, `dw-subtask-complete`, `dw-subtask-resume` |
+| Runners externos | `dw-codex-run`, `dw-claude-run`, `dw-copilot-run` |
+| Instaladores de skills de nuvem | `dw-install-aws-skills`, `dw-install-azure-skills` |
+| Auditorias de instalação e contexto | `dw-skill-health`, `dw-harness-audit`, `dw-context-budget` |
+| Checkpoint de sessão | `dw-pause`, `dw-resume` |
+
+Classifique cada família:
+
+- `CANDIDATA A FUSÃO` — a janela tem ao menos 20 sessões instrumentadas ou 30 dias, e a família inteira foi carregada em menos de 5% delas, ou algum membro nunca foi carregado enquanto outro foi. Um comando com modos custaria menos entradas no índice.
+- `MANTER SEPARADOS` — dois ou mais membros foram carregados, cada um, em ao menos 5 sessões: os nomes distintos estão em uso, e fundir troca um hábito medido por um índice menor.
+- `CEDO DEMAIS` — abaixo do limiar da janela. Mostre as contagens e diga isso.
+
+Comandos fora de família seguem a redação das skills: comando invocável por modelo com zero carregamentos numa janela longa o bastante é `CANDIDATO A OCIOSO`, nunca "não usado". Fusão ou remoção no pacote é decisão de produto registrada append-only em `lib/removed-commands.js` (o update então remove os wrappers antigos); este comando propõe, nunca renomeia, remove ou edita comandos. Ao auditar o próprio repositório dev-workflow não há telemetria local: reporte `SEM TELEMETRIA`, a menos que o mantenedor forneça os `costs.jsonl` de projetos consumidores, e agregue esses por projeto antes de somar.
+
 ## Saída
 
 Quando `.dw/config/routing-defaults.json` existir, compare seus candidatos atuais com o `.dw/config/routing.json` do proprietário. Relate diferenças relevantes e valide modelos/capacidades propostos antes da adoção. Valores diferentes podem ser intencionais; não os trate como falha de migração nem sobrescreva automaticamente. Atribuições de tarefas aprovadas têm precedência sobre ambos os arquivos de candidatos.
@@ -70,6 +92,7 @@ Inclua:
 - Issues de registry/schema.
 - Cobertura de retorno estruturado, incluindo qualquer skill sem contrato ou vocabulario de status.
 - Evidência de uso: a janela declarada, as tabelas por coorte e toda candidata a ociosa com sua frase de janela. Sem telemetria, diga isso em vez de pontuar.
+- Uso de comandos: a tabela por comando e a classificação de cada família (`CANDIDATA A FUSÃO`, `MANTER SEPARADOS`, `CEDO DEMAIS`).
 - Top 3 fixes.
 
 Marcador final: `## SKILL-HEALTH COMPLETE`

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

@@ -24,15 +24,16 @@ Antes de sobrescrever arquivos gerenciados, crie um snapshot:
 ```bash
 SNAPSHOT_DIR=".dw/.backup/$(date -u +%Y%m%dT%H%M%SZ)"
 mkdir -p "$SNAPSHOT_DIR"
-cp -r .dw/commands .dw/templates .dw/references .dw/scripts "$SNAPSHOT_DIR/" 2>/dev/null
+cp -r .dw/commands .dw/templates .dw/references .dw/scripts .dw/skills "$SNAPSHOT_DIR/" 2>/dev/null
 # agents/skills (bundled) tambem fazem parte do update
 [ -d .agents/skills ] && cp -r .agents/skills "$SNAPSHOT_DIR/agents-skills" 2>/dev/null
 # .claude/settings.json agora e mutado pelo update (MCPs + hooks + statusLine)
 [ -f .claude/settings.json ] && mkdir -p "$SNAPSHOT_DIR/claude" && cp .claude/settings.json "$SNAPSHOT_DIR/claude/settings.json" 2>/dev/null
+[ -f .dw/install-state.json ] && cp .dw/install-state.json "$SNAPSHOT_DIR/install-state.json" 2>/dev/null
 echo "Snapshot salvo em $SNAPSHOT_DIR"
 ```
 
-Manter apenas os 3 snapshots mais recentes (remover os mais antigos) para evitar acumulo.
+Manter apenas os 3 snapshots mais recentes em `.dw/.backup/` (remover os mais antigos) para evitar acumulo. `.dw/.migrated/` não é snapshot: nunca remova.
 
 ### 1. Registrar Versão Atual (Obrigatório)
 
@@ -86,7 +87,13 @@ O comando `update` sobrescreve arquivos gerenciados e PRESERVA:
 
 O comando `update` também roda o passo de migração GSD automaticamente — se o projeto tem `.planning/` legado (de uso prévio do GSD), o conteúdo é migrado para `.dw/intel/`, `.dw/spec/active-session.md`, `.dw/spec/quick/`, etc., e `.planning/` é renomeado para `.planning.gsd-archive-<DATA>/` para inspeção. Os arquivos `.claude/commands/gsd/`, `.claude/agents/gsd-*.md`, `.claude/hooks/gsd-*.js` e `.claude/gsd-file-manifest.json` são removidos durante a migração.
 
-Se o update falhar (erro de rede, permissão, pacote indisponível): reporte o erro ao usuário e PARE. NÃO tente workarounds manuais como copiar arquivos.
+O CLI nunca apaga o que aposenta: move para `.dw/.migrated/<timestamp>/`, mantendo o caminho relativo, e imprime o destino. Isso acontece só depois que as skills novas estão em `.dw/skills/`, então um update interrompido deixa as cópias antigas no lugar. O que ele aposenta, e como decide:
+
+- **Cópias legadas de skills bundled** em `.agents/skills/` (`[moved]`): só quando a cópia é do dev-workflow. Skill homônima que não é sai como `[kept]` e fica intocada.
+- **Skills removidas em releases anteriores** (`[v<N>]`) e **fontes de comandos removidos** (`[legacy]`): casadas por nome, então uma skill homônima de outra origem também é movida — é o move que torna isso recuperável.
+- **Wrappers `dw-*` órfãos** (`[orphan]`): `dw-` é o namespace deste pacote; uma skill do usuário chamada `dw-*` é movida, não perdida.
+
+Se o update falhar (erro de rede, permissão, pacote indisponível): reporte o erro ao usuário e PARE. NÃO tente workarounds manuais como copiar arquivos. Passe ao usuário o caminho do snapshot do passo 0 e as duas saídas: rodar o update de novo depois de resolver a causa (ele é idempotente), ou `/dw-update --rollback`.
 
 ### 4. Capturar Nova Versão
 
@@ -96,7 +103,7 @@ node -e 'const s = JSON.parse(require("node:fs").readFileSync(".dw/install-state
 
 ### Checks de compatibilidade do upgrade
 
-Leia o `.dw/commands/dw-update.md` atualizado após o CLI terminar. Use `.dw/install-state.json` e o output `Installed version` do CLI para a diferença de versões: um pacote executado por `npx` não precisa ser resolvível pelo `node_modules` do consumidor. Estado novo ausente ou inválido é falha de verificação; não declare sucesso do update.
+Leia o `.dw/commands/dw-update.md` atualizado após o CLI terminar. Use `.dw/install-state.json` e o output `Installed version` do CLI para a diferença de versões: um pacote executado por `npx` não precisa ser resolvível pelo `node_modules` do consumidor. Estado novo ausente ou inválido é falha de verificação; não declare sucesso do update. A versão lida no passo 4 tem de ser igual ao lado direito da linha `Installed version: <antiga> -> <nova>` do CLI; se essa linha faltar, ou as versões diferirem, o CLI não terminou e o update falhou.
 
 Em um upgrade de versão anterior à 2.3.0 (ou versão legada desconhecida):
 
@@ -116,6 +123,7 @@ Apresente ao usuário:
 - Resumo do que o output do `update` mostrou (arquivos copiados, wrappers gerados, MCPs configurados)
 - As `Post-update agent actions` impressas pelo CLI
 - Quaisquer avisos ou erros
+- Toda linha `[moved]`, `[v<N>]`, `[orphan]`, `[legacy]` ou `[kept]` do `Skill migration`, o caminho `.dw/.migrated/<timestamp>/` e todo arquivo marcado `was not installed by dev-workflow` (adição do próprio time: ofereça trazê-lo de volta numa skill do time, nunca em `.dw/skills/`, que o update sobrescreve)
 
 ### 6. Executar Ações de Agente Pós-Update (Obrigatório)
 
@@ -144,19 +152,28 @@ Se invocado com `--rollback`:
 1. Listar snapshots em `.dw/.backup/`
 2. Se nenhum existir: PARAR e reportar "Nenhum snapshot disponível"
 3. Se mais de um existir: perguntar ao usuário qual restaurar (padrão: mais recente)
-4. Confirmar com o usuário: "Restaurar snapshot `<path>`? Isso SOBRESCREVE `.dw/commands/`, `.dw/templates/`, `.dw/references/`, `.dw/scripts/`, `.agents/skills/` e `.claude/settings.json`. Prosseguir? [s/N]"
+4. Confirmar com o usuário: "Restaurar snapshot `<path>`? Isso SUBSTITUI `.dw/commands/`, `.dw/templates/`, `.dw/references/`, `.dw/scripts/` e `.dw/skills/` pelas cópias do snapshot (quando ele as tem), copia o `.agents/skills/` do snapshot por cima do atual sem remover outras entradas, e restaura `.claude/settings.json` e `.dw/install-state.json`. `.dw/templates/overrides/` nunca é tocado. Prosseguir? [s/N]"
 5. Somente após `s`: copiar de volta
 
 ```bash
-cp -r "$SNAPSHOT_DIR/commands"   .dw/
-cp -r "$SNAPSHOT_DIR/templates"  .dw/
-cp -r "$SNAPSHOT_DIR/references" .dw/ 2>/dev/null
-cp -r "$SNAPSHOT_DIR/scripts"    .dw/ 2>/dev/null
-[ -d "$SNAPSHOT_DIR/agents-skills" ] && cp -r "$SNAPSHOT_DIR/agents-skills" .agents/skills 2>/dev/null
+SNAPSHOT_DIR=".dw/.backup/<timestamp-escolhido>"   # o snapshot confirmado no passo 4
+[ -d "$SNAPSHOT_DIR" ] || { echo "Snapshot não encontrado: $SNAPSHOT_DIR"; exit 1; }
+# Pastas gerenciadas de .dw são substituídas, para não sobrar arquivo da release mais nova.
+for d in commands references scripts skills; do
+  [ -d "$SNAPSHOT_DIR/$d" ] && rm -rf ".dw/$d" && cp -r "$SNAPSHOT_DIR/$d" .dw/
+done
+# .dw/templates/overrides/ é do dono: restaure os templates gerenciados em volta dele, nunca o remova.
+if [ -d "$SNAPSHOT_DIR/templates" ]; then
+  find .dw/templates -mindepth 1 -maxdepth 1 ! -name overrides -exec rm -rf {} +
+  for f in "$SNAPSHOT_DIR/templates"/*; do [ "$(basename "$f")" = overrides ] || cp -r "$f" .dw/templates/; done
+fi
+# .agents/skills é compartilhada com as skills do próprio usuário: mescla, nunca substitui.
+[ -d "$SNAPSHOT_DIR/agents-skills" ] && mkdir -p .agents/skills && cp -r "$SNAPSHOT_DIR/agents-skills/." .agents/skills/ 2>/dev/null
 [ -f "$SNAPSHOT_DIR/claude/settings.json" ] && cp "$SNAPSHOT_DIR/claude/settings.json" .claude/settings.json 2>/dev/null
+[ -f "$SNAPSHOT_DIR/install-state.json" ] && cp "$SNAPSHOT_DIR/install-state.json" .dw/install-state.json 2>/dev/null
 ```
 
-6. Reportar: snapshot restaurado, versão provavelmente recuperada (ler de `.dw/commands/dw-help.md` ou metadata se houver)
+6. Reportar: snapshot restaurado, e a versão do `.dw/install-state.json` restaurado (ou "unknown" quando o snapshot é anterior a ele). Snapshot de antes da 2.7.0 não tem `skills/`: `.dw/skills/` fica como estava, o que é inofensivo (comandos antigos leem `.agents/skills/`), e o próximo update aposenta de novo as cópias restauradas em `.agents/skills/`.
 
 ## Opções Avançadas
 

package/scaffold/pt-br/references/invariants.md

@@ -81,6 +81,11 @@ Este piso é estreito de propósito. Algo genuinamente destrutivo que não estej
 isso — aplique o mesmo critério: se a ação destrói trabalho sem segunda cópia, reescreve história
 compartilhada ou move uma credencial, pare e pergunte. Uma confirmação a mais custa uma mensagem.
 
+O mesmo vale para as pastas de skills que os agentes compartilham — `.agents/skills/`, `.claude/skills/`,
+`.codex/skills/`: elas guardam também skills do usuário e de outras ferramentas. Fora do `update`/`uninstall`
+do próprio CLI, liste o que removeria e pergunte por entrada; mova o aprovado para `.dw/.migrated/<timestamp>/`,
+nunca `rm`.
+
 ## Atribuição
 
 O modelo de duas camadas — um piso que regra de projeto só pode apertar, nunca afrouxar — foi adaptado do

package/scaffold/pt-br/templates/project-onepager.md

@@ -80,7 +80,7 @@ services: []
 │   └── api/                      (criado por `pnpm dlx @nestjs/cli` ou scaffold escolhido)
 ├── packages/
 │   └── shared/                   (criado pelo /dw-new-project)
-├── docker-compose.dev.yml        (composto a partir de .agents/skills/docker-compose-recipes/)
+├── docker-compose.dev.yml        (composto a partir de .dw/skills/docker-compose-recipes/)
 ├── .env.example                  (consolidado dos servicos selecionados)
 ├── .gitignore                    (por stack)
 ├── .dockerignore                 (por stack)

package/scaffold/scripts/hooks/session-cost.mjs

@@ -12,9 +12,12 @@
  * USD is a best-effort ESTIMATE from a local price table — tokens are exact.
  *
  * The same pass also counts which skills the session's tool calls referenced,
- * emitted as `skills` on the row. `/dw-skill-health` reads it as usage evidence.
- * An absent `skills` key means the row predates this instrumentation; `{}` means
- * the session was observed and nothing fired — those are different facts.
+ * emitted as `skills` on the row, and which dev-workflow commands it loaded
+ * (a read of `.dw/commands/<name>.md`, which every command wrapper performs, or a
+ * Skill-tool call naming a command), emitted as `commands`. `/dw-skill-health`
+ * reads both as usage evidence. An absent key means the row predates that
+ * instrumentation; `{}` means the session was observed and nothing fired —
+ * those are different facts.
  *
  * Contract: reads the SessionEnd payload as JSON on stdin. Fails SAFE — any
  * error exits 0 without writing, so a hook bug never disrupts the session.
@@ -70,7 +73,7 @@ function knownSkills() {
       return false;
     }
   };
-  for (const base of ['.agents/skills', '.claude/skills']) {
+  for (const base of ['.dw/skills', '.agents/skills', '.claude/skills']) {
     const root = join(PROJECT_ROOT, base);
     if (!isDir(root)) continue;
     let top;
@@ -103,8 +106,29 @@ function knownSkills() {
 }
 
 // Matches a skills/ path inside a tool call's input, capturing at most two
-// segments so a grouped `group/skill` is preserved.
-const SKILL_PATH = /(?:\.agents|\.claude)\/skills\/([A-Za-z0-9._-]+(?:\/[A-Za-z0-9._-]+)?)\//g;
+// segments so a grouped `group/skill` is preserved. `.dw/skills/` is where the
+// bundled skills live; `.agents/` and `.claude/` hold wrappers, external and
+// legacy copies.
+const SKILL_PATH = /(?:\.dw|\.agents|\.claude)\/skills\/([A-Za-z0-9._-]+(?:\/[A-Za-z0-9._-]+)?)\//g;
+
+// Matches the canonical command file every wrapper tells the agent to read.
+const COMMAND_PATH = /\.dw\/commands\/([A-Za-z0-9._-]+)\.md/g;
+
+// Commands this project has installed: the names usage counting may emit under
+// `commands`. Their wrappers also sit under `.claude/skills/` and
+// `.agents/skills/`, so knownSkills() sees the same names; a command name is
+// always counted as a command, never as a skill.
+function knownCommands() {
+  const names = new Set();
+  try {
+    for (const file of readdirSync(join(DW_DIR, 'commands'))) {
+      if (file.endsWith('.md')) names.add(file.slice(0, -3));
+    }
+  } catch {
+    /* no installed commands — nothing to count */
+  }
+  return names;
+}
 
 // Count skill references in ONE assistant message.
 //
@@ -113,17 +137,22 @@ const SKILL_PATH = /(?:\.agents|\.claude)\/skills\/([A-Za-z0-9._-]+(?:\/[A-Za-z0
 // `tool_result` that returned the CONTENTS of a SKILL.md (those cite other
 // skills) and a user prompt that merely names one — both would report a skill as
 // fired when it never was. What this measures is loading, not obedience.
-function countSkillUses(msg, known, out) {
+function countSkillUses(msg, known, out, commands = new Set(), commandOut = {}) {
   const content = msg && msg.content;
   if (!Array.isArray(content)) return;
   for (const block of content) {
     if (!block || block.type !== 'tool_use' || !block.input) continue;
-    // One tool call is one reference per skill, however many times its input
-    // names that skill. A grep over three files under the same skill directory
-    // is one load, not three.
+    // One tool call is one reference per skill or command, however many times
+    // its input names it. A grep over three files under the same skill
+    // directory is one load, not three.
     const seen = new Set();
-    if (block.name === 'Skill' && typeof block.input.skill === 'string' && known.has(block.input.skill)) {
-      seen.add(block.input.skill);
+    const seenCommands = new Set();
+    const note = (name) => {
+      if (commands.has(name)) seenCommands.add(name);
+      else if (known.has(name)) seen.add(name);
+    };
+    if (block.name === 'Skill' && typeof block.input.skill === 'string') {
+      note(block.input.skill);
     }
     let serialized;
     try {
@@ -136,24 +165,29 @@ function countSkillUses(msg, known, out) {
       let match;
       while ((match = SKILL_PATH.exec(serialized)) !== null) {
         const full = match[1];
-        const name = known.has(full) ? full : full.split('/')[0];
-        if (known.has(name)) seen.add(name);
+        note(known.has(full) ? full : full.split('/')[0]);
+      }
+      COMMAND_PATH.lastIndex = 0;
+      while ((match = COMMAND_PATH.exec(serialized)) !== null) {
+        if (commands.has(match[1])) seenCommands.add(match[1]);
       }
     }
     for (const name of seen) out[name] = (out[name] || 0) + 1;
+    for (const name of seenCommands) commandOut[name] = (commandOut[name] || 0) + 1;
   }
 }
 
 // Sum per-turn usage from the transcript, grouped by model, and count which
 // skills the session's tool calls referenced.
-function tallyTranscript(transcriptPath, known) {
+function tallyTranscript(transcriptPath, known, commands = new Set()) {
   const byModel = {};
   const skills = {};
+  const commandUses = {};
   let raw;
   try {
     raw = readFileSync(transcriptPath, 'utf-8');
   } catch {
-    return { byModel, skills };
+    return { byModel, skills, commands: commandUses };
   }
   for (const line of raw.split('\n')) {
     if (!line.trim()) continue;
@@ -166,7 +200,7 @@ function tallyTranscript(transcriptPath, known) {
     if (obj.type !== 'assistant') continue;
     const msg = obj && obj.message;
     try {
-      countSkillUses(msg, known, skills);
+      countSkillUses(msg, known, skills, commands, commandUses);
     } catch {
       /* usage evidence is best-effort — never let it break cost tracking */
     }
@@ -179,7 +213,7 @@ function tallyTranscript(transcriptPath, known) {
     m.cache_write += u.cache_creation_input_tokens || 0;
     m.cache_read += u.cache_read_input_tokens || 0;
   }
-  return { byModel, skills };
+  return { byModel, skills, commands: commandUses };
 }
 
 async function main() {
@@ -198,7 +232,13 @@ async function main() {
   } catch {
     known = new Set();
   }
-  const { byModel, skills } = tallyTranscript(transcriptPath, known);
+  let installedCommands;
+  try {
+    installedCommands = knownCommands();
+  } catch {
+    installedCommands = new Set();
+  }
+  const { byModel, skills, commands } = tallyTranscript(transcriptPath, known, installedCommands);
   const modelNames = Object.keys(byModel);
   if (modelNames.length === 0) return process.exit(0); // nothing to record
 
@@ -223,9 +263,10 @@ async function main() {
     total_usd: Number(totalUsd.toFixed(4)),
     total_tokens: totalTokens,
     models,
-    // Always emitted, even empty: `{}` records an observed session with no skill
-    // reference, while an absent key marks a row written before this existed.
+    // Always emitted, even empty: `{}` records an observed session with no
+    // reference, while an absent key marks a row written before that existed.
     skills,
+    commands,
   };
 
   try {

package/scaffold/skills/docker-compose-recipes/references/compose-composition.md

@@ -37,7 +37,7 @@ This file describes how `/dw-new-project` and `/dw-dockerize` merge the standalo
 
 ```yaml
 # Generated by /dw-new-project on YYYY-MM-DD
-# Edit freely. Recipes live in .agents/skills/docker-compose-recipes/
+# Edit freely. Recipes live in .dw/skills/docker-compose-recipes/
 
 services:
   # --- storage tier ---

package/scaffold/skills/dw-llm-eval/SKILL.md

@@ -52,7 +52,9 @@ Structure:
 └── runs/<YYYY-MM-DD>.jsonl  # results of each eval run
 ```
 
-See `references/reference-dataset.md` for case-design principles, sampling from production, and when to expand the set.
+Eval-first: run a baseline on the current code before the change; new-behavior cases must fail there. Compare runs case by case: a case that passed and now fails blocks, whatever the average says. Never tune against the `holdout` split.
+
+See `references/reference-dataset.md` for case design, baseline, holdout, per-case drift and when to expand the set.
 
 ## Consistency (run-to-run stability)
 

package/scaffold/skills/dw-llm-eval/references/integration-with-dev-workflow-commands-detail.md

@@ -1,6 +1,6 @@
 ## Integration with dev-workflow commands
 
-- `/dw-plan tasks`: when the PRD has an AI feature requirement, an eval-plan subtask is mandatory. The task references this skill's oracle ladder.
+- `/dw-plan tasks`: when the PRD has an AI feature requirement, an eval-plan subtask is mandatory, ordered before the implementation subtasks: behavior spec, cases, baseline run (`references/reference-dataset.md` "Baseline before the change"). The task references this skill's oracle ladder.
 - `/dw-review --code-only`: AI feature PRs require a reference dataset + ≥2 oracle rungs (lower rungs FIRST). The constitution gate also applies — if the project has principles about AI feature reliability, they're enforced here.
-- `/dw-qa --ai`: new mode (when this skill is bundled) — runs the reference dataset against the current implementation, logs to `QA/logs/ai/<feature>-<date>.jsonl`, computes precision@k / faithfulness / outcome accuracy per the feature type.
+- `/dw-qa --ai`: new mode (when this skill is bundled) — runs the reference dataset against the current implementation, logs to `QA/logs/ai/<feature>-<date>.jsonl`, computes precision@k / faithfulness / outcome accuracy per the feature type, and lists per-case flips against the prior run.
 - `/dw-bugfix` when the bug is an AI failure mode (hallucination, tool misuse, classification error): adds the failing case to the reference dataset BEFORE fixing — the case is now a regression test forever.