@brunosps00/dev-workflow 0.4.5 → 0.5.0

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

@@ -5,6 +5,24 @@ Voce e um orquestrador de pipeline completo. Este comando recebe um desejo do us
 <critical>Os UNICOS momentos de pausa sao os 3 gates definidos abaixo. Entre os gates, execute tudo automaticamente sem pedir confirmacao.</critical>
 <critical>Cada etapa DEVE seguir as instrucoes completas do comando correspondente em `.dw/commands/`. Leia e execute o comando inteiro, nao uma versao resumida.</critical>
 
+<critical>EXECUCAO FORMAL OBRIGATORIA — LEIA ANTES DE COMECAR:
+Uma etapa que invoca um comando `/dw-xxx` SO e considerada completa quando os artefatos produzidos pelo comando existem no disco. Validacoes manuais (rodar testes, abrir o Playwright, revisar o codigo a olho, gerar um qa-report curto a mao) NAO substituem a execucao formal do comando.
+- ANTES de cada etapa: anuncie ao usuario `→ Invocando /dw-[nome] — executando instrucoes completas`.
+- DURANTE: siga as instrucoes do arquivo `.dw/commands/[nome].md` integralmente, sem resumir nem substituir.
+- DEPOIS: rode `ls` nos caminhos de artefato listados na propria etapa e confirme existencia antes de atualizar `autopilot-state.json`. Se faltar qualquer artefato, a etapa NAO rodou — re-execute o comando formalmente.</critical>
+
+<critical>RACIOCINIOS PROIBIDOS — se voce pensar qualquer uma destas frases, PARE e execute o comando formalmente:
+| Pensamento | Realidade |
+|------------|-----------|
+| "Ja rodei os testes manualmente" | O comando produz artefatos estruturados. Rode o comando. |
+| "Validei via Playwright ad-hoc" | `/dw-run-qa` exige matriz por RF, bugs.md, screenshots, scripts, logs, checklist. Rode o comando. |
+| "A implementacao esta obviamente correta" | `/dw-review-implementation` exige matriz de compliance por RF/endpoint/task. Rode o comando. |
+| "Validacao manual forte ja basta" | NAO. Equivalencia tecnica NAO substitui a execucao formal. |
+| "Ja conferi build e lint, e suficiente" | Build/lint NAO substituem review nem QA. Rode os comandos. |
+| "Gerei um qa-report.md resumido a mao" | Um arquivo solto NAO e execucao de `/dw-run-qa`. A arvore `QA/` completa e obrigatoria. |
+| "O autopilot ja avancou, nao preciso voltar" | Se o artefato nao existe, a etapa nao rodou. Volte e execute. |
+| "Corrigi bugs no caminho, entao o QA ja esta ok" | Corrigir bugs nao substitui rodar o QA formal. Rode `/dw-run-qa`. |</critical>
+
 ## Quando Usar
 - Use quando quiser ir de uma ideia ate um PR com minima intervencao manual
 - Use para features completas que passam por todo o pipeline (pesquisa, planejamento, execucao, qualidade)
@@ -15,6 +33,13 @@ Voce e um orquestrador de pipeline completo. Este comando recebe um desejo do us
 ## Posicao no Pipeline
 **Antecessor:** (desejo do usuario) | **Sucessor:** (merge do PR)
 
+## Skills Complementares
+
+| Skill | Gatilho |
+|-------|---------|
+| `dw-memory` | **SEMPRE** — thread de memory atravessa todas as fases (brainstorm -> PRD -> techspec -> tasks -> execucao -> QA -> review -> PR). Decisoes de um gate alimentam o contexto do proximo. |
+| `dw-verify` | **SEMPRE** — invocada em cada gate (PRD, Tasks, PR) antes de pedir aprovacao do usuario; e antes do commit final + push. |
+
 ## Variaveis de Entrada
 
 | Variavel | Descricao | Exemplo |
@@ -143,12 +168,27 @@ Execute `/dw-review-implementation` para verificar PRD compliance (Level 2).
 - Maximo 3 ciclos de correcao
 - NAO avance para QA ate que o review passe
 
+<critical>Artefatos obrigatorios desta etapa (verifique ANTES de marcar como completa):
+- Output formatado com matriz de compliance exibido ao usuario na propria sessao
+- Veredicto explicito (PASS / GAP / FAIL) para CADA RF do PRD, CADA endpoint da TechSpec e CADA task
+- Se houver gaps: commits de correcao antes de re-executar o review
+Um review textual curto, um "parece ok" ou conclusao "implementacao correta" SEM a matriz estruturada RF-by-RF NAO conta. Uma revisao mental ou a olho NAO conta. Se a matriz nao apareceu no output, o comando nao rodou — re-execute.</critical>
+
 ### Etapa 10: QA Visual
 
 Execute `/dw-run-qa` com Playwright MCP.
 - Teste happy paths, edge cases, fluxos negativos, acessibilidade
 - Documente bugs com screenshots
 
+<critical>Artefatos obrigatorios desta etapa (rode `ls` em CADA caminho ANTES de marcar como completa):
+- `{{PRD_PATH}}/QA/qa-report.md` — existe e contem secao por RF com PASS/FAIL
+- `{{PRD_PATH}}/QA/bugs.md` — existe (pode ser vazio se sem bugs, mas o arquivo deve existir)
+- `{{PRD_PATH}}/QA/checklist.md` — existe e esta coberto integralmente
+- `{{PRD_PATH}}/QA/screenshots/` — diretorio existe e contem pelo menos 1 PNG por RF testado (formato `RF-XX-[slug]-PASS.png` ou `-FAIL.png`)
+- `{{PRD_PATH}}/QA/scripts/` — diretorio existe e contem scripts Playwright `.spec.ts`/`.spec.js` por RF
+- `{{PRD_PATH}}/QA/logs/` — diretorio existe com logs de console/rede capturados
+Rodar Playwright ad-hoc, tirar algumas screenshots soltas ou escrever um qa-report.md curto a mao NAO substitui esta estrutura. Se qualquer artefato estiver ausente ou incompleto, o comando NAO rodou — invoque `/dw-run-qa` formalmente e siga o fluxo dele ate o fim.</critical>
+
 ### Etapa 11: Fix QA (Condicional)
 
 Se o QA encontrou bugs:
@@ -168,6 +208,8 @@ Execute `/dw-review-implementation` novamente para confirmar que as correcoes do
 - Se encontrar gaps: corrija e re-execute
 - Maximo 3 ciclos
 
+<critical>Artefatos obrigatorios (mesmas regras da Etapa 9): matriz RF-by-RF explicita no output. Sem matriz = comando nao rodou = re-execute.</critical>
+
 ### Etapa 13: Code Review
 
 Execute `/dw-code-review` (Level 3) para review formal.
@@ -175,6 +217,25 @@ Execute `/dw-code-review` (Level 3) para review formal.
 
 ### Etapa 14: Commit
 
+<critical>AUDITORIA PRE-COMMIT OBRIGATORIA — execute ANTES de invocar `/dw-commit`:
+
+Rode `ls` em cada caminho abaixo e confirme existencia. Se QUALQUER um faltar, NAO faca commit:
+- `{{PRD_PATH}}/QA/qa-report.md`
+- `{{PRD_PATH}}/QA/bugs.md`
+- `{{PRD_PATH}}/QA/checklist.md`
+- `{{PRD_PATH}}/QA/screenshots/` (nao vazio)
+- `{{PRD_PATH}}/QA/scripts/` (nao vazio com arquivos `.spec.*`)
+- `{{PRD_PATH}}/QA/logs/`
+- Evidencia do ultimo `/dw-review-implementation` com matriz RF-by-RF (output da sessao ou referencia em `autopilot-state.json`)
+
+Verifique tambem `autopilot-state.json`:
+- Toda etapa de 1 a 13 que NAO esta em `skipped_steps` deve estar em `completed_steps`
+- Cada etapa completada deve ter seus artefatos listados em `step_artifacts`
+
+Se faltar qualquer artefato ou etapa: PARE imediatamente. Reporte ao usuario: `Etapa N nao produziu artefato X — re-executando /dw-[comando]`. Re-execute o comando. Verifique novamente. Soh entao prossiga para `/dw-commit`.
+
+NAO faca commit parcial. NAO justifique a falta com validacao manual. NAO marque etapa como completa sem o artefato formal.</critical>
+
 Execute `/dw-commit` automaticamente.
 - Commits semanticos seguindo Conventional Commits
 - NAO aguarde aprovacao
@@ -213,13 +274,26 @@ Salve o arquivo `.dw/spec/prd-[nome]/autopilot-state.json` com o seguinte format
   "completed_steps": [1, 2, 3, 4, 5, 6, 7],
   "skipped_steps": [2],
   "gates_passed": ["prd", "tasks"],
+  "step_artifacts": {
+    "9": ["review-matrix-shown-in-session"],
+    "10": [
+      ".dw/spec/prd-[nome]/QA/qa-report.md",
+      ".dw/spec/prd-[nome]/QA/bugs.md",
+      ".dw/spec/prd-[nome]/QA/checklist.md",
+      ".dw/spec/prd-[nome]/QA/screenshots/",
+      ".dw/spec/prd-[nome]/QA/scripts/",
+      ".dw/spec/prd-[nome]/QA/logs/"
+    ],
+    "12": ["review-matrix-post-qa-shown-in-session"]
+  },
   "started_at": "2026-04-10T14:30:00Z",
   "last_updated": "2026-04-10T15:45:00Z"
 }
 ```
 
-- Atualize `current_step` e `completed_steps` ANTES de iniciar cada etapa
-- Se a sessao cair, o `/dw-resume` lera este arquivo e continuara da etapa correta
+- Atualize `current_step`, `completed_steps` e `step_artifacts` ANTES de iniciar a proxima etapa
+- Uma etapa SO vai para `completed_steps` apos verificar que seus artefatos existem no disco
+- Se a sessao cair, o `/dw-resume` lera este arquivo e continuara da etapa correta — e revalidara os artefatos antes de confiar em `completed_steps`
 - Ao finalizar o pipeline (apos commit ou PR), remova o arquivo ou marque `"status": "completed"`
 
 <critical>Apos CADA etapa completada, exiba o bloco de progresso atualizado ao usuario. Isso e OBRIGATORIO — o usuario DEVE ver o que foi feito e o que vem a seguir. Se uma etapa foi pulada, o motivo DEVE aparecer no bloco de progresso.</critical>

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

@@ -11,6 +11,11 @@ Você é um facilitador de brainstorming para o workspace atual. Este comando ex
 ## Posição no Pipeline
 **Antecessor:** (ideia do usuário) | **Sucessor:** `/dw-create-prd`
 
+## Flags
+
+- **(padrão)**: brainstorm normal com 3-7 opções (conservadora, equilibrada, ousada) e trade-offs
+- **`--council`**: após o brainstorm normal, invoca a skill `dw-council` para stress-test das top 2-3 opções através de 3-5 archetypes (pragmatic-engineer, architect-advisor, security-advocate, product-mind, devils-advocate). Útil quando a escolha é de alto impacto e há genuine dissent entre caminhos.
+
 ## Fluxograma de Decisão: Brainstorm vs PRD Direto
 
 ```dot
@@ -33,6 +38,7 @@ digraph brainstorm_decision {
 
 Quando disponíveis no projeto em `./.agents/skills/`, use para enriquecer a ideação:
 
+- `dw-council` (opt-in via `--council`): stress-test multi-advisor das opções mais promissoras com steel-manning obrigatório e concession tracking. **NÃO invocar por padrão** — só quando a flag está presente ou quando surge consenso rápido demais (sinal de false consensus).
 - `ui-ux-pro-max`: use quando o brainstorm envolver frontend, direção de estilo UI, escolhas de design system ou exploração de identidade visual
 - `vercel-react-best-practices`: use quando explorar arquitetura React/Next.js ou trade-offs de performance
 - `security-review`: use quando o brainstorm tocar auth, manipulação de dados ou features sensíveis à segurança

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

@@ -15,6 +15,7 @@
 
     Quando disponíveis no projeto em `./.agents/skills/`, use estas skills como suporte contextual sem substituir este comando:
 
+    - `dw-verify`: **SEMPRE** — em modo Direto, invocada antes do commit da correção. O VERIFICATION REPORT deve mostrar que o sintoma original do bug não se reproduz mais (não apenas que os testes passam).
     - `vercel-react-best-practices`: use quando o bug afeta React/Next.js e há suspeita de problemas de render, hidratação, fetching, waterfall, bundle ou re-render
     - `webapp-testing`: use quando a correção requer fluxo E2E/reteste reproduzível em uma web app
     - `security-review`: use quando a causa raiz toca auth, autorização, input externo, upload, secrets, SQL, XSS, SSRF ou outras superfícies sensíveis
@@ -219,6 +220,14 @@
     - `ajustar` - me diga o que modificar no plano
     ```
 
+    ### 5.5. Verificação Final (Modo Direto — obrigatório antes do commit)
+
+    <critical>Após aplicar as tarefas aprovadas em modo Direto, invocar `dw-verify` antes do commit. O VERIFICATION REPORT deve mostrar:
+    1. O comando de verificação do projeto (test + lint + build) com exit 0.
+    2. Reprodução do sintoma original: o cenário que disparava o bug já NÃO dispara mais.
+    
+    Sem PASS nos dois, NÃO commit. Reportar o que falhou e retomar da etapa 4 (análise de causa raiz).</critical>
+
     ### 6. Gerar Documento Bugfix (Modo Análise)
 
     <critical>

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

@@ -21,6 +21,8 @@ Normalmente invocado antes de criar PR via `/dw-generate-pr`
 
 Quando disponíveis no projeto em `./.agents/skills/`, use estas skills como apoio analítico sem substituir este comando:
 
+- `dw-review-rigor`: **SEMPRE** — aplica de-duplication (mesmo pattern em N arquivos = 1 finding), severity ordering (critical → high → medium → low), verify-before-flag, skip-what-linter-catches, e signal-over-volume. A tabela "Problemas Encontrados" do relatório segue essa disciplina.
+- `dw-verify`: **SEMPRE** — invocada antes de emitir verdict `APROVADO` ou `APROVADO COM RESSALVAS`. Sem VERIFICATION REPORT PASS (test + lint + build), o verdict não pode sair como APROVADO.
 - `security-review`: use quando auth, autorização, input externo, upload, SQL, integração externa, secrets, SSRF, XSS ou superfícies sensíveis estiverem presentes
 - `vercel-react-best-practices`: use quando o diff tocar React/Next.js para revisar padrões de renderização, fetching, bundle, hidratação e performance
 
@@ -180,6 +182,22 @@ Verificar:
 
 <critical>O REVIEW NÃO PODE SER APROVADO SE ALGUM TESTE FALHAR</critical>
 
+### 6.5. Aplicar `dw-review-rigor` (Obrigatório)
+
+Antes de escrever a tabela "Problemas Encontrados" do relatório, invocar a skill `dw-review-rigor` e aplicar as cinco regras:
+
+1. **De-duplicação**: se o mesmo padrão aparece em N arquivos, emitir 1 finding com a lista de arquivos afetados — nunca N findings idênticos.
+2. **Severity ordering**: apresentar sempre na ordem critical → high → medium → low (não por arquivo).
+3. **Verify intent before flagging**: checar comentários adjacentes, ADRs em `.dw/spec/*/adrs/`, cobertura de testes, regras em `.dw/rules/`. Não flaggar o que tem justificativa documentada.
+4. **Skip what linter catches**: rodar o linter do projeto primeiro; nada que ele já reporta vira finding.
+5. **Signal over volume**: máximo ~8 findings precisos são mais úteis que 30 marginais. Manter todos os critical/high; podar medium/low para os mais impactantes.
+
+Se houver reviews anteriores em `{{PRD_PATH}}/reviews/` ou `{{PRD_PATH}}/dw-code-review.md` (round anterior), ler e emitir **apenas findings NOVOS** — não re-flaggar itens já tratados.
+
+### 6.6. Verificação Final (Obrigatório antes do verdict)
+
+<critical>Invocar `dw-verify` e incluir o VERIFICATION REPORT no início do relatório. Sem PASS, o verdict só pode ser `REPROVADO` — nunca `APROVADO` ou `APROVADO COM RESSALVAS`.</critical>
+
 ### 7. Gerar Relatório de Code Review (Obrigatório)
 
 Salvar em `{{PRD_PATH}}/dw-code-review.md`:

package/scaffold/pt-br/commands/dw-create-tasks.md

@@ -42,10 +42,22 @@
     - Organizar sequenciamento
     - Incluir testes unitários como subtarefas de cada task
 
+    3.5. **Verificação de Dependências Circulares (Pré-flight)**
+    - Antes de escrever qualquer arquivo, monte o grafo de dependências (campo `blockedBy` ou "Depende de" entre tasks)
+    - Detecte ciclos: se a task A depende de B e B depende (direta ou transitivamente) de A, há ciclo
+    - Se houver ciclo: **NÃO escreva os arquivos**. Apresente o ciclo ao usuário e peça reestruturação (ex: extrair responsabilidade comum, inverter dependência, mesclar tasks)
+    - Se não houver ciclo: prossiga
+
     4. **Gerar Arquivos de Tarefas Individuais**
     - Criar arquivo para cada tarefa principal
     - Detalhar subtarefas e critérios de sucesso
     - Incluir testes unitários obrigatórios
+    - **Enriquecimento codebase-aware (Opcional mas recomendado)**: para tasks que tocam áreas conhecidas do codebase, dispatche um Agent Explore em paralelo (um por task ou um por área) para preencher:
+      - "Arquivos Relevantes": paths e razão pela qual são relevantes para a task
+      - "Arquivos Dependentes": paths que podem precisar mudar em cascata
+      - "Regras Aplicáveis": links para `.dw/rules/*.md` que restringem a task
+      - "ADRs Relacionados": arquivos em `.dw/spec/<prd>/adrs/` que constrangem decisões
+      Esse enriquecimento é aditivo: não bloqueia a geração das tasks, apenas aumenta a qualidade do contexto que a `dw-run-task` recebe depois.
 
     ## Diretrizes de Criação de Tarefas
 

package/scaffold/pt-br/commands/dw-create-techspec.md

@@ -13,10 +13,16 @@
     ## Posição no Pipeline
     **Antecessor:** `/dw-create-prd` | **Sucessor:** `/dw-create-tasks`
 
+    ## Flags
+
+    - **(padrão)**: gera techspec normal a partir do PRD
+    - **`--council`**: antes de finalizar o techspec, invoca a skill `dw-council` sobre a decisão arquitetural principal (ex: monólito vs microserviços, SQL vs NoSQL, lib X vs Y). O output do council vira uma seção "Debate Arquitetural" no techspec, e decisões firmes viram ADR via `/dw-adr`. Útil quando o techspec introduz uma escolha estrutural de alto impacto.
+
     ## Skills Complementares
 
     Quando disponíveis no projeto em `./.agents/skills/`, use como apoio:
 
+    - `dw-council` (opt-in via `--council`): debate multi-advisor da decisão arquitetural principal com steel-manning. **NÃO invocar por padrão**.
     - `vercel-react-best-practices`: use quando definir arquitetura frontend para projetos React/Next.js
     - `ui-ux-pro-max`: use quando definir decisões de design system, paletas de cores, tipografia e estilo UI no TechSpec
     - `security-review`: use quando a feature tocar auth, autorização ou manipulação de dados sensíveis
@@ -94,6 +100,8 @@
     - Revisar padrões do projeto em `{{RULES_PATH}}`
     - Confirmar que o PRD existe em `{{PRD_PATH}}` ou `.dw/spec/prd-[nome-funcionalidade]/prd.md`
 
+    <critical>Hard gate: se o PRD tiver seção "Questões em Aberto" / "Open Questions" com itens não resolvidos, PARAR. Apresentar as questões ao usuário e pedir que sejam resolvidas antes de escrever o techspec. Um techspec construído sobre requisitos indefinidos gera retrabalho garantido.</critical>
+
     ## Fluxo de Trabalho
 
     ### 1. Analisar PRD (Obrigatório)

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

@@ -17,6 +17,7 @@ Você é um assistente IA especializado em correção de bugs pós-QA com retest
 
 Quando disponíveis no projeto em `./.agents/skills/`, use estas skills como suporte operacional sem substituir este comando:
 
+- `dw-verify`: **SEMPRE** — invocada antes de marcar qualquer bug como `Corrigido` ou `Fechado` no `QA/bugs.md`. Sem VERIFICATION REPORT PASS (test + lint + build) + evidência de reteste, o status permanece `Reaberto` ou `Em análise`.
 - `webapp-testing`: suporte para estruturar retestes, capturas e scripts quando complementar ao Playwright MCP
 - `vercel-react-best-practices`: use apenas se a correção afetar frontend React/Next.js e houver risco de regressão de renderização, hidratação, fetching ou performance
 
@@ -88,6 +89,10 @@ Para cada bug corrigido:
 7. Registrar no relatório de QA qual usuário/perfil foi usado no reteste
 8. Se o reteste exigir auth persistente, inspeção além do MCP, ou reprodução mais fiel em navegador real, registrar no relatório
 
+### 3.5. Verificação Final Antes de Atualizar Status
+
+<critical>Invocar a skill `dw-verify` antes de mudar o status de qualquer bug para `Corrigido` ou `Fechado`. O VERIFICATION REPORT (test + lint + build) deve ser PASS **e** a evidência de reteste do Playwright deve estar salva. Sem os dois, o status não muda.</critical>
+
 ### 4. Atualização de Artefatos
 
 Atualizar `QA/bugs.md` para cada bug:

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

@@ -9,6 +9,14 @@
     ## Posição no Pipeline
     **Antecessor:** `/dw-code-review` ou `/dw-commit` | **Sucessor:** (merge)
 
+    ## Skills Complementares
+
+    | 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. |
+
+    <critical>Hard gate: 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>
+
     ## Uso
 
     ```

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

@@ -11,7 +11,26 @@ Você é um assistente de ajuda do workspace. Quando invocado, apresente ao usu
 ## Comportamento
 
 - Se invocado sem argumentos (`/dw-help`): mostre o guia completo abaixo
-- Se invocado com argumento (`/dw-help dw-create-prd`): mostre apenas a seção detalhada daquele comando
+- Se invocado com argumento correspondente a um comando (`/dw-help dw-create-prd`): mostre apenas a seção detalhada daquele comando
+- Se invocado com **keyword que não é nome de comando** (`/dw-help bug`, `/dw-help review`, `/dw-help design`): faça lookup contextual — identifique o(s) comando(s) mais relevante(s) pela keyword e apresente cada um com 1-2 linhas de justificativa ("para bug, use `/dw-bugfix` porque..."). Use a tabela de mapeamento abaixo.
+
+### Mapeamento contextual (keyword → comando sugerido)
+
+| Keyword(s) | Comando sugerido | Justificativa |
+|------------|------------------|---------------|
+| bug, erro, falha, problema | `/dw-bugfix` | Triagem automática bug vs feature + correção |
+| review, revisão, qualidade | `/dw-code-review` | Review formal Nível 3 com relatório |
+| qa, teste visual, playwright | `/dw-run-qa` | QA E2E com browser automation |
+| refactor, smell, fowler | `/dw-refactoring-analysis` | Auditoria de code smells priorizada |
+| design, ui, redesign | `/dw-redesign-ui` | Auditoria + propostas + implementação visual |
+| decisão, adr, arquitetura | `/dw-adr` | Registrar Architecture Decision Record |
+| debate, council, stress-test, opiniões | `/dw-brainstorm --council` ou `/dw-create-techspec --council` | Invoca `dw-council` para debate multi-advisor |
+| reverter, rollback de task | `/dw-revert-task` | Revert seguro com check de dependências |
+| hotfix, mudança rápida | `/dw-quick` | Task pontual com garantias sem PRD |
+| retomar, onde parei | `/dw-resume` | Restaura contexto da sessão anterior |
+| pesquisa, research | `/dw-deep-research` | Pesquisa multi-fonte com citações |
+| ideia, brainstorm | `/dw-brainstorm` | Ideação estruturada com trade-offs |
+| atualizar dev-workflow | `/dw-update` | Atualiza para versão npm mais recente |
 
 ---
 
@@ -123,12 +142,33 @@ Este workspace utiliza um sistema de comandos AI que automatiza o ciclo completo
 |---------|-----------|-------|--------|
 | `/dw-commit` | Commit semântico (Conventional Commits) | - | Commit |
 | `/dw-generate-pr` | Push + cria PR + copia body + abre URL | Branch alvo | PR no GitHub |
+| `/dw-revert-task` | Reverte com segurança os commits de uma task específica (check de dependências + confirmação) | Path do PRD + número da task | Commits revertidos + `tasks.md` atualizado |
+
+### Decisões Arquiteturais
+
+| Comando | O que faz | Input | Output |
+|---------|-----------|-------|--------|
+| `/dw-adr` | Registra um Architecture Decision Record (ADR) para decisão não-trivial durante o PRD | Path do PRD + título | `.dw/spec/<prd>/adrs/adr-NNN.md` + cross-refs atualizadas |
 
 ### Utilitários
 
 | Comando | O que faz | Input | Output |
 |---------|-----------|-------|--------|
-| `/dw-help` | Este guia de comandos | (opcional) comando | Este documento |
+| `/dw-help` | Este guia de comandos (suporta lookup por keyword: `/dw-help bug`) | (opcional) comando ou keyword | Este documento ou seção filtrada |
+| `/dw-update` | Atualiza o dev-workflow para a versão mais recente no npm sem sair do agente (suporta `--rollback`) | (nenhum) ou `--rollback` | Arquivos gerenciados atualizados ou restaurados |
+
+### Bundled Skills (invocadas internamente — não são commands)
+
+Skills em `.agents/skills/` que os commands acima invocam transparentemente. Você não as chama diretamente.
+
+| Skill | Invocada por | Papel |
+|-------|--------------|-------|
+| `dw-verify` | run-task, run-plan, fix-qa, bugfix, code-review, generate-pr, quick | Iron Law: nenhuma claim de sucesso sem VERIFICATION REPORT PASS |
+| `dw-memory` | run-task, run-plan, autopilot, resume, revert-task | Memory de workflow em dois níveis (shared + task-local) com promotion test |
+| `dw-review-rigor` | code-review, review-implementation, refactoring-analysis | De-duplication, severity ordering, verify-intent-before-flag, signal-over-volume |
+| `dw-council` | brainstorm `--council`, create-techspec `--council` | Debate multi-advisor (3-5 archetypes) com steel-manning, concession tracking e synthesis que preserva dissent. Opt-in. |
+
+Inspiradas em skills do projeto [Compozy](https://github.com/compozy/compozy) (`cy-final-verify`, `cy-workflow-memory`, `cy-review-round`).
 
 ## Fluxos Comuns
 

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

@@ -13,6 +13,12 @@ Voce e um executor de tasks rapidas. Este comando existe para implementar mudanc
 ## Posicao no Pipeline
 **Antecessor:** (necessidade pontual do usuario) | **Sucessor:** `/dw-commit` (automatico)
 
+## Skills Complementares
+
+| Skill | Gatilho |
+|-------|---------|
+| `dw-verify` | **SEMPRE** — invocada antes do commit. Mesmo mudancas pequenas exigem VERIFICATION REPORT PASS (test + lint minimos) antes de commit atomico. |
+
 ## Variaveis de Entrada
 
 | Variavel | Descricao | Exemplo |
@@ -27,7 +33,8 @@ Voce e um executor de tasks rapidas. Este comando existe para implementar mudanc
 4. Implemente a mudanca seguindo convencoes do projeto
 5. Execute testes existentes relevantes (unit, integration)
 6. Execute lint se configurado no projeto
-7. Crie commit atomico semantico com a mudanca
+7. Invoque `dw-verify` e inclua o VERIFICATION REPORT no output antes de commitar. Sem PASS, NAO commit.
+8. Crie commit atomico semantico com a mudanca
 
 ## Integracao GSD
 

package/scaffold/pt-br/commands/dw-refactoring-analysis.md

@@ -20,6 +20,7 @@ Pré-requisito: Execute `/dw-analyze-project` primeiro para entender padrões e
 
 Quando disponíveis no projeto em `./.agents/skills/`, use como suporte analítico sem substituir este comando:
 
+- `dw-review-rigor`: **SEMPRE** — ao catalogar code smells, aplicar de-duplication (mesmo smell em N arquivos = 1 entrada com affected list), severity ordering nos P0-P3, signal-over-volume (máx ~20 findings; manter críticos, podar marginais). Smell com ADR justificatório baixa para `low` no máximo.
 - `security-review`: delegue preocupações de segurança para este skill — não duplique
 - `vercel-react-best-practices`: delegue padrões de performance React/Next.js para este skill
 

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

@@ -11,6 +11,12 @@ Voce e um assistente de continuidade de sessao. Este comando existe para restaur
 ## Posicao no Pipeline
 **Antecessor:** (inicio de sessao) | **Sucessor:** qualquer comando dw-*
 
+## Skills Complementares
+
+| Skill | Gatilho |
+|-------|---------|
+| `dw-memory` | **SEMPRE** — para cada PRD ativo identificado, ler `.dw/spec/<prd>/MEMORY.md` (shared) para reconstituir constraints, decisoes e handoff notes da sessao anterior. Incluir no resumo apresentado ao usuario. |
+
 ## Comportamento Obrigatorio
 
 <critical>ANTES de qualquer analise, verifique se existe um autopilot interrompido. Procure por `autopilot-state.json` em TODOS os diretorios dentro de `.dw/spec/`. Se encontrar um com status diferente de "completed", a retomada do autopilot tem PRIORIDADE sobre qualquer outra sugestao.</critical>
@@ -29,9 +35,10 @@ Voce e um assistente de continuidade de sessao. Este comando existe para restaur
 1. Leia `.dw/spec/` e identifique PRDs com tasks pendentes (checkboxes `- [ ]` em tasks.md)
 2. Leia `git log --oneline -10` para identificar o ultimo trabalho realizado
 3. Identifique a branch ativa e se ha mudancas nao commitadas
-4. Cruze: ultimo PRD ativo, ultima task completada, proxima task pendente
-5. Apresente o resumo no formato abaixo
-6. Sugira o proximo comando a executar
+4. **Invoque `dw-memory`**: para o PRD ativo, leia `.dw/spec/<prd>/MEMORY.md` e a memory da proxima task pendente (`tasks/<N>_memory.md` se existir). Extraia decisoes durables, constraints cross-task e handoff notes.
+5. Cruze: ultimo PRD ativo, ultima task completada, proxima task pendente, contexto de memory
+6. Apresente o resumo no formato abaixo (incluindo bullets de "Do ponto onde paramos" com base na memory)
+7. Sugira o proximo comando a executar
 
 ## Integracao GSD
 

package/scaffold/pt-br/commands/dw-revert-task.md

@@ -0,0 +1,114 @@
+<system_instructions>
+Você é um revertedor seguro de tasks. Sua função é reverter os commits de uma task específica criados por `/dw-run-task`, protegendo contra revert destrutivo se tasks subsequentes dependem dela.
+
+<critical>Este é um command destrutivo em potencial (altera o git history da branch ativa). SEMPRE apresente o plano e peça confirmação do usuário ANTES de executar qualquer `git revert`.</critical>
+
+## Quando Usar
+- Use para desfazer uma task específica que foi implementada e commitada mas precisa ser revertida (mudança de requisitos, erro de implementação não capturado pela validação, decisão revista)
+- NÃO use para desfazer múltiplas tasks simultaneamente (reverta uma de cada vez)
+- NÃO use se a task já foi pushada para remote e mergeada em main (nesse caso é necessário PR de revert)
+
+## Posição no Pipeline
+**Antecessor:** `/dw-run-task` ou `/dw-run-plan` que criou os commits da task | **Sucessor:** re-execução da task ou mudança de plano
+
+## Variáveis de Entrada
+
+| Variável | Descrição | Exemplo |
+|----------|-----------|---------|
+| `{{PRD_PATH}}` | Caminho do PRD ativo | `.dw/spec/prd-minha-feature` |
+| `{{TASK_NUMBER}}` | Número da task a reverter | `3` (para task 3.0) |
+
+## Fluxo de Trabalho
+
+### 1. Identificar commits da task
+
+- Ler `{{PRD_PATH}}/tasks.md` e `{{PRD_PATH}}/{{TASK_NUMBER}}_task.md`
+- Identificar commits relacionados à task via:
+  - `git log --grep="task {{TASK_NUMBER}}"` ou
+  - `git log --grep="Task {{TASK_NUMBER}}"` ou
+  - Intersecção manual: commits na branch entre o último commit da task {{TASK_NUMBER - 1}} e o commit marcador da task {{TASK_NUMBER}} no tasks.md
+- Listar hashes e mensagens ao usuário
+
+### 2. Verificação de Dependências (Obrigatória)
+
+<critical>Antes de propor o revert, verificar se tasks subsequentes dependem dos artefatos desta task.</critical>
+
+- Ler `tasks.md` e identificar tasks com `{{TASK_NUMBER}}` no campo `blockedBy` ou na seção "Depende de"
+- Para cada task dependente:
+  - Verificar se já foi executada (checkbox `- [x]`)
+  - Se SIM: revert dessa task cascataria — PARAR e apresentar conflito ao usuário
+  - Se NÃO: ok, a task pendente pode ser re-executada após o revert
+
+### 3. Apresentar Plano
+
+Apresente ao usuário:
+
+```
+PLANO DE REVERT — Task {{TASK_NUMBER}}
+
+Commits a serem revertidos (em ordem reversa):
+  - <hash_N> <mensagem>
+  - <hash_N-1> <mensagem>
+  ...
+
+Tasks dependentes afetadas:
+  - Task X.Y (pendente, pode ser re-executada após o revert)
+  - [OU: ⚠️ Task X.Y já executada — conflito, PARAR]
+
+Artefatos a atualizar após o revert:
+  - {{PRD_PATH}}/tasks.md (remarcar task {{TASK_NUMBER}} como pendente)
+  - {{PRD_PATH}}/tasks/{{TASK_NUMBER}}_memory.md (adicionar nota "revertida em YYYY-MM-DD")
+
+Prosseguir? [s/N]
+```
+
+Aguarde confirmação explícita.
+
+### 4. Executar Revert
+
+Somente após `s`/`sim`/`yes`:
+
+```bash
+# Para cada commit, em ordem reversa:
+git revert --no-edit <hash>
+```
+
+Se houver conflitos durante o revert: PARAR, reportar os conflitos e aguardar resolução manual do usuário. NÃO force.
+
+### 5. Atualizar Artefatos
+
+Após revert bem-sucedido:
+- Em `tasks.md`: mudar `- [x]` para `- [ ]` na linha da task {{TASK_NUMBER}}
+- Em `tasks/{{TASK_NUMBER}}_memory.md`: adicionar bloco:
+  ```
+  ## Revert em YYYY-MM-DD
+  - Motivo: [preencher com o motivo fornecido pelo usuário]
+  - Commits revertidos: [hashes]
+  ```
+- Invocar `dw-memory` para promover a nota ao `MEMORY.md` se for cross-task relevante
+
+### 6. Reportar
+
+- Lista de commits revertidos (e os commits de revert criados)
+- Status dos artefatos atualizados
+- Sugestão do próximo passo (`/dw-run-task {{TASK_NUMBER}}` para re-executar, ou `/dw-create-tasks` se o escopo mudou)
+
+## Comportamento Obrigatório
+
+<critical>NUNCA use `git reset --hard` ou `git rebase -i` como alternativa ao revert. Revert preserva história e é seguro em branches compartilhadas.</critical>
+
+<critical>NUNCA force o revert se tasks dependentes já foram executadas. Nesse caso, apresente o conflito e peça decisão do usuário (reverter também as dependentes ou cancelar).</critical>
+
+<critical>NUNCA prossiga sem confirmação explícita `s`/`sim`/`yes` do usuário.</critical>
+
+## Skills Complementares
+
+| Skill | Gatilho |
+|-------|---------|
+| `dw-memory` | **SEMPRE** — ao atualizar memory da task com a nota de revert, aplicar promotion test para decidir se vai para shared `MEMORY.md` |
+
+## Inspired by
+
+Compozy não tem command análogo. Este é um padrão próprio do dev-workflow, motivado pelo gap identificado durante a análise: "se uma task falha/precisa ser revertida após commit, não há mecanismo seguro para reverter só ela".
+
+</system_instructions>

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

@@ -23,6 +23,12 @@
 
     Este comando é chamado automaticamente pelo `/dw-run-plan` ao final de todas as tasks, mas também pode ser executado manualmente.
 
+    ## Skills Complementares
+
+    | Skill | Gatilho |
+    |-------|---------|
+    | `dw-review-rigor` | **SEMPRE** — ao listar gaps entre PRD/TechSpec e código, aplicar de-duplication (mesmo gap em N módulos = 1 entrada), severity ordering e verify-intent-before-flag |
+
     ## Variáveis de Entrada
 
     | Variável | Descrição | Exemplo |

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

@@ -9,6 +9,13 @@ Você é um assistente especializado em execução sequencial de planos de desen
 ## Posição no Pipeline
 **Antecessor:** `/dw-create-tasks` | **Sucessor:** `/dw-code-review` e depois `/dw-generate-pr`
 
+## Skills Complementares
+
+| Skill | Gatilho |
+|-------|---------|
+| `dw-memory` | **SEMPRE** — lê `MEMORY.md` antes de iniciar e aplica promotion test + compaction entre tasks |
+| `dw-verify` | **SEMPRE** — invocada antes da Revisão Final Nível 2 e antes do "Plano Completo" |
+
 ## Objetivo
 
 Executar TODAS as tarefas pendentes de um projeto de forma sequencial e automática, marcando cada uma como concluída após a implementação bem-sucedida (cada task já inclui validação Nível 1), e realizando uma **revisão final Nível 2 (PRD compliance) com ciclo de correções**.
@@ -62,10 +69,19 @@ Para cada tarefa pendente (em ordem sequencial):
    - Se houver erros, reportar e PAUSAR para correção manual
    - Se bem-sucedido, continuar para próxima task
 
+5. **Compaction de memory entre tasks**
+   - Invocar `dw-memory` com flag de compaction em `MEMORY.md` a cada 3 tasks concluídas (ou quando o arquivo exceder ~150 linhas)
+   - Garantir que a próxima task leia um `MEMORY.md` enxuto e atualizado
+
 ### 3. Revisão Final Completa
 
 Quando todas as tarefas estiverem concluídas:
 
+0. **Verificação Final (Obrigatório antes do Nível 2)**
+   - Invocar `dw-verify` com o comando de verificação do projeto (test + lint + build, ou gate command documentado)
+   - Só prosseguir com o Nível 2 se o VERIFICATION REPORT for PASS
+   - Se FAIL: corrigir root cause, re-verificar e só então abrir a revisão de PRD compliance
+
 1. **Executar Revisão Geral**
    - Seguir `.dw/commands/dw-review-implementation.md` para TODAS as tasks
    - Gerar relatório completo de gaps e recomendações
@@ -99,7 +115,9 @@ Quando todas as tarefas estiverem concluídas:
      - Não haver mais recomendações, OU
      - Usuário decidir que pendências restantes são aceitáveis
 
-4. **Relatório Final**
+4. **Relatório Final (após dw-verify PASS final)**
+
+   <critical>Antes de declarar "PLANO COMPLETO" ou "COMPLETO COM PENDÊNCIAS", invocar `dw-verify` uma última vez após a última correção. Sem PASS, não emita o relatório final.</critical>
 
    ```
    RELATÓRIO FINAL DO PLANO

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

@@ -18,6 +18,8 @@ Quando disponíveis no projeto em `./.agents/skills/`, use estas skills como sup
 
 | Skill | Gatilho |
 |-------|---------|
+| `dw-verify` | **SEMPRE** — invocada antes do commit para produzir Verification Report com evidence fresca |
+| `dw-memory` | **SEMPRE** — lê memory da workflow no início e atualiza ao final da task (promotion test) |
 | `vercel-react-best-practices` | Task envolve renderização React, hidratação, data fetching, bundle, cache ou performance |
 | `webapp-testing` | Task tem frontend interativo que necessita validação E2E em navegador real |
 
@@ -51,6 +53,7 @@ Se `.planning/intel/` NÃO existir:
 - Revisar o contexto do PRD
 - Verificar requisitos da spec técnica (incluindo estratégia de testes)
 - Entender dependências de tarefas anteriores
+- **Invocar `dw-memory`**: ler `.dw/spec/prd-[nome]/MEMORY.md` (shared) e `.dw/spec/prd-[nome]/tasks/[num]_memory.md` (task-local, criar se ausente) — decisões, constraints e handoff notes de tasks anteriores são contexto obrigatório
 
 ### 2. Análise da Tarefa
 Analise considerando:
@@ -169,9 +172,19 @@ Formato no tasks.md (adicionar após marcar a task como concluída):
 - **Se FALHA**: Corrija os problemas e re-execute a validação
 - **NÃO gere relatório em arquivo** - apenas output no terminal
 
+## Verificação Final (Obrigatório antes do commit)
+
+<critical>Invocar a skill `dw-verify` antes de qualquer alegação de "task completa". Produzir um VERIFICATION REPORT com o comando de verificação real do projeto (test + lint + build) e exit code 0. Sem report PASS, NÃO prossiga para o commit.</critical>
+
+## Atualização de Memory (Obrigatório antes do commit)
+
+Invocar `dw-memory` para:
+- Atualizar `tasks/[num]_memory.md` com arquivos tocados, decisões não-óbvias e handoff notes
+- Aplicar o **promotion test** (próxima task precisa? durável? não óbvio do repo?) e promover apenas o que passar para `MEMORY.md`
+
 ## Commit Automático (Obrigatório)
 
-Ao final da task (após validação Nível 1 passar), **sempre** fazer commit (sem push):
+Ao final da task (após validação Nível 1 + dw-verify PASS + dw-memory atualizado), **sempre** fazer commit (sem push):
 
 ```bash
 git status