@brunosps00/dev-workflow 0.4.7 → 0.6.0

package/scaffold/en/templates/techspec-template.md

@@ -1,3 +1,9 @@
+---
+type: techspec
+schema_version: "1.0"
+status: draft
+---
+
 # Technical Specification Template
 
 ## Executive Summary
@@ -121,3 +127,9 @@ type ServiceName interface {
 ### Relevant Files
 
 [List relevant project files here]
+
+## Related ADRs
+
+[List architectural ADRs that constrain or inform this techspec. Leave empty if none. Use `/dw-adr` during execution to record new decisions.
+
+- `adrs/adr-NNN.md` — [short title]]

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

@@ -0,0 +1,117 @@
+<system_instructions>
+Você é um registrador de decisões arquiteturais. Sua função é criar um **Architecture Decision Record (ADR)** que documente uma decisão técnica importante feita durante a fase atual do PRD.
+
+## Quando Usar
+- Use quando uma decisão arquitetural ou de design foi tomada e precisa ser registrada para referência futura (escolha de biblioteca, padrão de comunicação, tradeoff de performance, restrição imposta por compliance, etc.)
+- Use durante `/dw-create-techspec` ou `/dw-run-task` quando a justificativa da decisão não cabe no techspec nem no task file
+- NÃO use para decisões triviais ou reversíveis sem custo (escolha de nome de variável, ordem de import)
+- NÃO use para registrar bugs ou incidents (use `/dw-bugfix` ou notas operacionais)
+
+## Posição no Pipeline
+**Antecessor:** qualquer ponto do pipeline após `/dw-create-prd` | **Sucessor:** continua o fluxo anterior (techspec, task, review)
+
+O ADR é **aditivo**: ele não substitui nenhuma etapa do pipeline. Qualquer command existente pode invocar `/dw-adr` quando uma decisão não-trivial precisar de registro permanente.
+
+## Variáveis de Entrada
+
+| Variável | Descrição | Exemplo |
+|----------|-----------|---------|
+| `{{PRD_PATH}}` | Caminho da pasta do PRD ativo | `.dw/spec/prd-minha-feature` |
+| `{{TITLE}}` | Título curto da decisão (imperativo) | "Usar PostgreSQL ao invés de MongoDB" |
+
+Se `{{PRD_PATH}}` não for fornecido, pergunte ao usuário qual PRD está ativo (leia `.dw/spec/` e liste). Se `{{TITLE}}` não for fornecido, pergunte.
+
+## Localização dos Arquivos
+
+- Diretório de ADRs: `{{PRD_PATH}}/adrs/`
+- Arquivo novo: `{{PRD_PATH}}/adrs/adr-NNN.md` (NNN zero-padded para 3 dígitos)
+- Template: `.dw/templates/adr-template.md`
+
+## Fluxo de Trabalho
+
+### 1. Descobrir o próximo número
+- Liste os arquivos em `{{PRD_PATH}}/adrs/` (crie o diretório se não existir)
+- O próximo número é `max(existentes) + 1`, ou `1` se vazio
+
+### 2. Coletar contexto (perguntas mínimas)
+
+Pergunte ao usuário **4 perguntas objetivas**, uma por vez:
+
+1. **Contexto**: qual problema ou força motivadora levou a esta decisão? (1-3 frases)
+2. **Decisão**: qual é a decisão tomada? (1 frase acionável, começa com verbo)
+3. **Alternativas consideradas**: quais outras opções foram avaliadas e por que não foram escolhidas? (mínimo 2)
+4. **Consequências**: quais são os tradeoffs positivos e negativos desta decisão? (explicite os negativos — sem painting rosy)
+
+### 3. Escrever o arquivo ADR
+
+Use `.dw/templates/adr-template.md` como base. Campos obrigatórios:
+
+```yaml
+---
+id: NNN
+status: Proposed | Accepted | Deprecated | Superseded
+title: [título do ADR]
+date: YYYY-MM-DD
+prd: [slug do PRD]
+schema_version: "1.0"
+---
+
+# ADR-NNN: [Título]
+
+## Status
+[Proposed | Accepted | Deprecated | Superseded by ADR-XXX]
+
+## Context
+[Contexto e forças motivadoras]
+
+## Decision
+[A decisão tomada]
+
+## Alternatives Considered
+1. **[Alternativa 1]** — [por que não foi escolhida]
+2. **[Alternativa 2]** — [por que não foi escolhida]
+
+## Consequences
+### Positivas
+- [consequência positiva 1]
+
+### Negativas
+- [consequência negativa / tradeoff aceito]
+
+## Related
+- PRD: `.dw/spec/prd-[nome]/prd.md`
+- TechSpec: `.dw/spec/prd-[nome]/techspec.md` (se aplicável)
+- Tasks afetadas: [lista, se aplicável]
+```
+
+### 4. Atualizar referências cruzadas
+
+Se o ADR for criado **durante** a execução de um PRD, adicionar uma linha na seção "Related ADRs" dos artefatos relacionados:
+- `prd.md`, `techspec.md`, ou `[N]_task.md`, conforme o escopo da decisão
+
+Se a seção "Related ADRs" não existir no arquivo, adicioná-la ao final.
+
+### 5. Reportar
+
+Apresente ao usuário:
+- Caminho do ADR criado
+- Artefatos atualizados com referência cruzada
+- Status inicial (geralmente `Accepted` para decisões já tomadas, `Proposed` para decisões ainda abertas)
+
+## Comportamento Obrigatório
+
+<critical>NUNCA sobrescreva um ADR existente. Cada ADR é imutável — se a decisão muda, crie um novo ADR com status `Supersedes ADR-NNN` e marque o antigo como `Superseded by ADR-XXX`.</critical>
+
+<critical>NUNCA pinte o tradeoff como "só positivo". A seção Consequências Negativas é obrigatória — se não houver nenhum custo, a decisão não precisa de ADR.</critical>
+
+## Inspired by
+
+Este command é inspirado no padrão de ADRs de `/tmp/compozy/.agents/skills/cy-create-adr/` do projeto [Compozy](https://github.com/compozy/compozy). Adaptações para dev-workflow:
+
+- Paths são `.dw/spec/<prd>/adrs/` ao invés de `.compozy/tasks/<name>/adrs/`
+- 4 perguntas mínimas em vez do fluxo interativo mais longo (alinhado com o estilo conciso de outros commands dw-*)
+- Integração explícita com `schema_version` dos templates v1.0
+
+Credit: Compozy project.
+
+</system_instructions>

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

@@ -33,6 +33,13 @@ Uma etapa que invoca um comando `/dw-xxx` SO e considerada completa quando os ar
 ## 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 |

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,9 @@ 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.
+- `/dw-security-check`: **SEMPRE para projetos TS/Python/C#/Rust** — invocado como step 6.7 (Camada de Segurança) antes de emitir verdict. Se o projeto usa linguagem suportada e `security-check.md` não existe OU tem status REJECTED, o verdict é **REPROVADO** — sem exceção.
 - `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 +183,31 @@ 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>
+
+### 6.7. Camada de Segurança (Obrigatório para projetos TS/Python/C#/Rust)
+
+<critical>Para projetos em TypeScript/JavaScript, Python, C# ou Rust que tiveram código modificado no diff, invocar `/dw-security-check` com o mesmo `{{PRD_PATH}}`. Sem `security-check.md` presente no PRD OU com status diferente de CLEAN/PASSED WITH OBSERVATIONS, o verdict é **REPROVADO** — sem exceção.</critical>
+
+- Se `/dw-security-check` retornar **REJECTED**: verdict automático **REPROVADO**. Incluir na seção "Problemas Encontrados" do relatório final os findings CRITICAL/HIGH do security-check com severity apropriada.
+- Se retornar **PASSED WITH OBSERVATIONS**: pode seguir para APROVADO COM RESSALVAS, listando as observations medium/low como ressalvas.
+- Se retornar **CLEAN**: prossegue normalmente para o verdict baseado nos demais critérios.
+- Projetos em linguagens não suportadas pelo security-check (Go, Java, PHP, Ruby etc.) → pular este step com nota visível no relatório de code-review.
+
 ### 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,17 @@
     ## 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. |
+    | `/dw-security-check` | **SEMPRE para projetos TS/Python/C#/Rust** — `security-check.md` com status ≠ REJECTED é obrigatório para projetos em linguagem suportada. |
+
+    <critical>Hard gate 1 (verify): se a sessão atual não tem um VERIFICATION REPORT PASS de `dw-verify` produzido APÓS a última edição/commit, PARAR e invocar `dw-verify` antes de prosseguir. PR é um artefato permanente — exige o maior rigor de verificação.</critical>
+
+    <critical>Hard gate 2 (security): para projetos TS/Python/C#/Rust, se `{{PRD_PATH}}/security-check.md` não existir OU tiver status REJECTED, PARAR e invocar `/dw-security-check` antes de prosseguir. Vulnerabilidades HIGH/CRITICAL NÃO podem chegar ao PR. Para outras linguagens (Go, Java, etc.), este gate é pulado com nota.</critical>
+
     ## Uso
 
     ```

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

@@ -11,7 +11,27 @@ 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 |
+| security, segurança, vulnerabilidade, owasp, trivy, cve | `/dw-security-check` | Check multi-camada rígido (OWASP estático + Trivy SCA/IaC + audit nativo) para TS/Python/C#/Rust |
+| 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 |
 
 ---
 
@@ -116,6 +136,7 @@ Este workspace utiliza um sistema de comandos AI que automatiza o ciclo completo
 | `/dw-review-implementation` | Compara PRD vs código (FRs, endpoints, tasks) | Path do PRD | Relatório de gaps |
 | `/dw-code-review` | Code review formal (qualidade, rules, testes) | Path do PRD | `code-review.md` |
 | `/dw-refactoring-analysis` | Auditoria de code smells e oportunidades de refatoração (catálogo Fowler) | Path do PRD | `refactoring-analysis.md` |
+| `/dw-security-check` | Check de segurança rígido (OWASP estático + Trivy SCA/IaC + audit nativo) para TS/Python/C#/Rust | Path do PRD ou código | `security-check.md` |
 
 ### Versionamento
 
@@ -123,13 +144,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-update` | Atualiza o dev-workflow para a versão mais recente no npm sem sair do agente | (nenhum) | Arquivos gerenciados atualizados |
+| `/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,13 @@
 
     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 |
+    | `/dw-security-check` | **SEMPRE para projetos TS/Python/C#/Rust com diff que toca código** — os findings viram uma categoria "Security Gaps" no ciclo interativo de correções. Se status REJECTED, os gaps são bloqueantes. |
+
     ## Variáveis de Entrada
 
     | Variável | Descrição | Exemplo |
@@ -36,6 +43,16 @@
     2. Especificações técnicas da TechSpec
     3. Tasks definidas no tasks.md
     4. Código efetivamente implementado (via git diff/status)
+    5. **Segurança do código implementado** (via `/dw-security-check` para projetos TS/Python/C#/Rust)
+
+    ## Camada de Segurança (Obrigatório para projetos TS/Python/C#/Rust)
+
+    <critical>Se o projeto usa TypeScript, Python, C# ou Rust e o diff toca código (não apenas docs), INVOCAR `/dw-security-check {{PRD_PATH}}` antes de listar gaps. O status e findings retornados alimentam a seção "Security Gaps" do relatório de Nível 2.</critical>
+
+    - Status **REJECTED** do security-check → os findings CRITICAL/HIGH viram gaps **bloqueantes** no ciclo interativo de correções (equivalente a gap de funcionalidade crítica não implementada)
+    - Status **PASSED WITH OBSERVATIONS** → os findings MEDIUM/LOW viram recomendações no ciclo
+    - Status **CLEAN** → seção "Security Gaps: Nenhum" no relatório
+    - Projeto em linguagem não suportada → nota no relatório indicando que a camada de segurança foi pulada
 
     ## Arquivos a Ler (Obrigatório)