@brunosps00/dev-workflow 1.0.5 → 1.1.0

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

@@ -15,11 +15,11 @@
     |-------|---------|
     | `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-git-discipline` | **SEMPRE** — valida naming de branch (`<tipo>/<escopo>` kebab-case), histórico atomic-commit (cada commit single-intent, mensagem conventional), tempo de vida da branch (flag se >7 dias) e escopo da PR (sugere split se diff > ~400 linhas). Descrição da PR segue summary + test plan, não dump de `git log`. |
-    | `/dw-secure-audit` | **SEMPRE para projetos TS/Python/C#/Rust** — `security-check.md` com status ≠ REJECTED é obrigatório para projetos em linguagem suportada. |
+    | `/dw-secure-audit` | **SEMPRE para projetos TS/Python/C#/Rust** — um `.dw/secure-audit/audit-summary.md` fresco com status ≠ REJECTED é obrigatório para projetos em linguagem suportada. |
 
     <critical>Hard gate 1 (verify): se a sessão atual não tem um VERIFICATION REPORT PASS de `dw-verify` produzido APÓS a última edição/commit, PARAR e invocar `dw-verify` antes de prosseguir. PR é um artefato permanente — exige o maior rigor de verificação.</critical>
 
-    <critical>Hard gate 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-secure-audit` antes de prosseguir. Vulnerabilidades HIGH/CRITICAL NÃO podem chegar ao PR. Para outras linguagens (Go, Java, etc.), este gate é pulado com nota.</critical>
+    <critical>Hard gate 2 (security): para projetos TS/Python/C#/Rust, se `.dw/secure-audit/audit-summary.md` não existir, estiver desatualizado (anterior à última edição) OU tiver status REJECTED, PARAR e invocar `/dw-secure-audit` antes de prosseguir. Findings SECRET e vulnerabilidades HIGH/CRITICAL NÃO podem chegar ao PR. Para outras linguagens (Go, Java, etc.), este gate é pulado com nota.</critical>
 
     ## Uso
 

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

@@ -0,0 +1,136 @@
+<system_instructions>
+Voce e o orquestrador de objetivos duraveis do dev-workflow. Este comando entrega a todos os agentes suportados um contrato estilo Codex `/goal`: um objetivo, checkpoints explicitos, comandos formais, estado persistido e condicao de parada verificavel.
+
+## Quando Usar
+- Use quando um fluxo e maior que um turno normal, mas tem fim claro.
+- Use depois de `/dw-plan` quando implementacao, review, QA e review pos-QA devem rodar como um loop duravel.
+- Use a partir do `/dw-autopilot` depois que a primeira invocacao completou PRD → TechSpec → Tasks.
+- NAO use para backlog solto, listas de tarefas sem relacao ou brainstorming exploratorio.
+
+## Posicao no Pipeline
+**Antecessor:** `/dw-plan` ou fase de plan do `/dw-autopilot` | **Sucessor:** `/dw-commit` + `/dw-generate-pr`
+
+## Modos
+
+| Invocacao | Comportamento |
+|-----------|---------------|
+| `/dw-goal "<objetivo>"` | Cria e executa um objetivo duravel manual. |
+| `/dw-goal --from-autopilot <prd-slug>` | Cria e executa o goal padrao de execucao/qualidade do autopilot para um PRD existente. |
+| `/dw-goal status` | Mostra goal ativo, checkpoint, ultima verificacao e bloqueios. |
+| `/dw-goal pause` | Marca o goal ativo como pausado sem apagar estado. |
+| `/dw-goal resume` | Retoma o goal pausado ou interrompido a partir de `status.json`. |
+| `/dw-goal clear` | Limpa o goal ativo apenas depois de completo, cancelado ou explicitamente substituido. |
+
+## Ponte Nativa com Codex
+
+<critical>`/dw-goal` e portavel. O estado canonico vive em `.dw/goals/` mesmo quando o `/goal` nativo do Codex estiver disponivel.</critical>
+
+A documentacao oficial do Codex trata `/goal` como recurso experimental para objetivo duravel em trabalho longo com condicao de parada verificavel. No Codex CLI ele requer `features.goals`; pode ser definido com `/goal <objective>`, inspecionado com `/goal`, e controlado com `/goal pause`, `/goal resume` ou `/goal clear`.
+
+Quando rodar em Codex:
+- Se existir ferramenta nativa de goal, crie/atualize o goal com um objetivo curto apontando para `.dw/goals/<slug>/goal.md`.
+- Se o slash command interativo `/goal` estiver disponivel e `features.goals` estiver habilitado, use `/goal <objective>` com objetivo abaixo de 4.000 caracteres.
+- Se goals nativos estiverem indisponiveis, continue com o loop portavel em `.dw/goals/`. Nao bloqueie.
+
+Formato do objetivo nativo no Codex:
+
+```text
+Execute o objetivo duravel definido em .dw/goals/<goal-slug>/goal.md ate que sua condicao de parada verificavel seja atingida. Atualize .dw/goals/<goal-slug>/progress.md depois de cada checkpoint.
+```
+
+## Estado Persistente
+
+Crie `.dw/goals/<goal-slug>/` com:
+
+```
+.dw/goals/<goal-slug>/
+├── goal.md
+├── status.json
+└── progress.md
+```
+
+`goal.md` DEVE incluir:
+- Um objetivo.
+- Dentro de escopo / fora de escopo.
+- Artefatos de entrada a ler primeiro.
+- Checkpoints em ordem.
+- Comandos formais `/dw-*` a invocar.
+- Artefatos obrigatorios por checkpoint.
+- Condicao de parada verificavel.
+- Condicoes de bloqueio.
+- Politica de retomada.
+
+`status.json` DEVE usar este formato:
+
+```json
+{
+  "schema_version": "1.0",
+  "slug": "goal-prd-example",
+  "source": "manual",
+  "prd_path": null,
+  "status": "active",
+  "current_checkpoint": "start",
+  "completed_checkpoints": [],
+  "required_artifacts": [],
+  "last_verification": null,
+  "created_at": "2026-05-20T00:00:00Z",
+  "updated_at": "2026-05-20T00:00:00Z"
+}
+```
+
+`progress.md` e append-only. Cada entrada registra checkpoint, comando invocado, resultado, artefatos verificados, bloqueios e proximo checkpoint.
+
+## Goal do Autopilot
+
+Quando invocado como `/dw-goal --from-autopilot <prd-slug>`:
+
+1. Resolva `<prd-slug>` para `.dw/spec/<prd-slug>/`.
+2. Verifique que `prd.md`, `techspec.md`, `tasks.md`, arquivos per-task e `tasks-validation.md` existem.
+3. Crie o slug `autopilot-<prd-slug>`.
+4. Escreva `goal.md` com este objetivo:
+
+```text
+Completar implementacao e validacao de qualidade para .dw/spec/<prd-slug> sem parar ate run, review completo, QA/fix e review completo pos-QA estarem formalmente completos e verificados.
+```
+
+Checkpoints:
+
+| Checkpoint | Comando formal | Evidencia de conclusao |
+|------------|----------------|------------------------|
+| `run` | `/dw-run <prd-path>` | Tasks done, commits de task presentes, run log ou status de tasks atualizado. |
+| `review-before-qa` | `/dw-review <prd-path>` | `<prd-path>/QA/review-consolidated.md` existe e veredicto geral esta aprovado ou aprovado com ressalvas explicitamente nao-bloqueantes. |
+| `qa` | `/dw-qa <prd-path>` | Artefatos obrigatorios de QA existem. |
+| `qa-fix` | `/dw-qa --fix <prd-path>` quando `bugs.md` tem bugs Open | Bugs estao Fixed/Closed ou explicitamente deferidos pelo usuario. |
+| `review-after-qa` | `/dw-review <prd-path>` | Review consolidado existe apos fixes de QA e esta aprovado ou aprovado com ressalvas explicitamente nao-bloqueantes. |
+
+O goal so esta completo quando:
+- Todos os checkpoints acima estao completos ou explicitamente pulados com motivo documentado.
+- Nenhum bug Open de QA permanece, exceto se o usuario aceitou deferir explicitamente.
+- O `/dw-review` final rodou depois do ultimo fix de QA.
+- `status.json` tem `"status": "complete"`.
+
+## Regras de Execucao
+
+<critical>Cada checkpoint que invoca um comando `/dw-*` DEVE invocar o comando formal e seguir as instrucoes completas de `.dw/commands/`. Equivalentes manuais nao contam.</critical>
+
+- Antes de cada checkpoint, anexe uma entrada em `progress.md` e atualize `status.json.current_checkpoint`.
+- Depois de cada checkpoint, verifique artefatos obrigatorios com `ls` ou inspecao equivalente antes de marcar como completo.
+- Se um comando falhar, corrija conforme o loop proprio daquele comando e re-execute.
+- Se o mesmo bloqueio repetir por 3 turnos consecutivos de goal e nenhum progresso significativo for possivel, marque `status: "blocked"` e apresente o bloqueio.
+- Mantenha updates compactos: checkpoint atual, resultado de verificacao, checkpoints restantes, bloqueio se houver.
+
+## Comandos de Status
+
+- `status`: leia `status.json` e as ultimas 10 entradas de `progress.md`; reporte checkpoint atual, completos, ultima verificacao e bloqueios.
+- `pause`: defina `status: "paused"` e anexe o motivo.
+- `resume`: defina `status: "active"` e continue de `current_checkpoint`; nao repita checkpoints completos salvo se artefatos estiverem faltando.
+- `clear`: se completo/cancelado/substituido, marque `status: "cancelled"` ou arquive conforme convencao do projeto. Nao delete evidencias por padrao.
+
+## Anti-patterns
+
+- Nao crie goal com varios objetivos sem relacao.
+- Nao use `/dw-goal` para burlar `/dw-plan`; goals executam um plano definido, nao inventam escopo.
+- Nao marque checkpoint completo sem verificar artefatos.
+- Nao use `/goal` nativo do Codex como unico estado; `.dw/goals/` permanece o contrato cross-agent.
+
+</system_instructions>

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

@@ -17,7 +17,7 @@ Use `/dw-autopilot "desejo"` como gateway pra maior parte do trabalho. Comandos
 
 | Comando | Quando |
 |---------|--------|
-| `/dw-autopilot "desejo"` | Entry point padrão. PRD → TechSpec → Tasks → Run → QA → Review → Commit → PR. Três gates de aprovação. |
+| `/dw-autopilot "desejo"` | Entry point padrão em duas invocações. Primeira roda plan e para; segunda retoma via `/dw-goal`, commit e PR. |
 | `/dw-bugfix "descrição"` | Bug ou error report. Fix cirúrgico ou rota pra PRD. |
 | `/dw-help [palavra-chave]` | Esta tela. Passe palavra-chave pra atalhos. `--advanced` revela comandos internos. |
 
@@ -48,15 +48,15 @@ Use `/dw-autopilot "desejo"` como gateway pra maior parte do trabalho. Comandos
 
 ## Workflow em resumo
 
-`/dw-autopilot "desejo"` roda o pipeline completo (PRD → ... → PR) com 3 gates. Passo a passo:
+`/dw-autopilot "desejo"` roda planejamento primeiro e para. Reinvoque para retomar via `/dw-goal`, commit e PR. Passo a passo:
 
 ```
-/dw-brainstorm → /dw-plan → /dw-run → /dw-qa → /dw-review → /dw-commit → /dw-generate-pr
+/dw-brainstorm → /dw-plan → /dw-goal → /dw-commit → /dw-generate-pr
 ```
 
 ## Comandos avançados / internos
 
-Passe `--advanced` pra ver internos (`dw-adr`, `dw-intel`, `dw-secure-audit`, `dw-find-skills`, `dw-update`, `dw-subtask-start`, `dw-subtask-complete`, `dw-subtask-resume`) — usualmente invocados por outros comandos.
+Passe `--advanced` pra ver internos (`dw-adr`, `dw-intel`, `dw-secure-audit`, `dw-goal`, `dw-find-skills`, `dw-update`, `dw-subtask-start`, `dw-subtask-complete`, `dw-subtask-resume`) — usualmente invocados por outros comandos.
 ```
 
 ## Modo advanced — flag `--advanced`
@@ -68,13 +68,14 @@ ALSO show:
 
 Auto-invocados por comandos primários mas disponíveis standalone.
 
-## Tier 4 — Hidden (8)
+## Tier 4 — Hidden (9)
 
 | Comando | O que | Invocado por |
 |---------|-------|--------------|
 | `/dw-adr "decisão"` | Registra um ADR em `.dw/spec/<prd>/adrs/`. | `/dw-plan techspec --council`, desvios de constitution |
 | `/dw-intel "pergunta"` | Query de codebase intel; `--build` (re)indexa `.dw/intel/`. | `/dw-plan`, `/dw-review`, `/dw-bugfix` |
 | `/dw-secure-audit` | OWASP + Trivy + lockfile + supply-chain scan. Hard gate. Flags: `--scan-only`, `--plan`, `--execute`. | `/dw-review`, `/dw-generate-pr` |
+| `/dw-goal "<objetivo>"` | Contrato de objetivo duravel com `.dw/goals/`; faz ponte com `/goal` nativo do Codex quando disponivel. | `/dw-autopilot` apos planejamento |
 | `/dw-find-skills "query"` | Busca npx skills ecosystem, valida, instala. | manual ao estender bundle |
 | `/dw-update` | Atualiza dev-workflow pro último release npm com snapshot rollback. | manutenção manual |
 | `/dw-subtask-start "goal"` | Cria um input packet minimo para subagente. | parent antes de delegar |
@@ -89,6 +90,7 @@ Auto-invocados por comandos primários mas disponíveis standalone.
 | `prd`, `spec`, `plan`, `arquitetura`, `techspec`, `tasks` | `/dw-plan` (stage apropriado) |
 | `bug`, `erro`, `quebrado`, `fix` | `/dw-bugfix` |
 | `run`, `executa`, `implementa` | `/dw-run` |
+| `goal`, `objetivo`, `long-running`, `retomar autopilot` | `/dw-goal` ou `/dw-autopilot` se `autopilot-state.json` existir |
 | `review`, `qualidade`, `audit code` | `/dw-review` |
 | `qa`, `test plan`, `e2e` | `/dw-qa` |
 | `commit`, `git` | `/dw-commit` |
@@ -117,10 +119,10 @@ Sem match: surface padrão + nota.
 ## FAQ
 
 **P: Onde começo com uma nova feature?**
-- `/dw-autopilot "o que voce quer"`. Roda PRD → ... → PR com três gates.
+- `/dw-autopilot "o que voce quer"`. Primeira invocacao roda PRD → TechSpec → Tasks e para; segunda invocacao retoma via `/dw-goal`, commit e PR.
 
 **P: Tenho que usar `/dw-autopilot`?**
-- Não. Pipeline granular dá controle a cada step.
+- Não. Pipeline granular dá controle a cada step, com `/dw-goal` quando quiser executar run/review/QA/review como objetivo duravel.
 
 **P: Só quero corrigir um bug.**
 - `/dw-bugfix "<descrição>"`. Tria, 3 perguntas, fixa ou roteia.

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

@@ -50,6 +50,12 @@ Quando agentes do projeto estiverem instalados, use:
 
 Claude Code e OpenCode podem usar agentes nativos. Codex e Copilot usam `.agents/agents/` mais estas instrucoes como fallback.
 
+## Ferramenta de Entrevista Estruturada
+
+<critical>Quando uma ferramenta estruturada de entrevista/input do usuario estiver disponivel, `/dw-plan` DEVE usa-la para as perguntas de clarificacao de PRD e TechSpec. Nao rebaixe para chat comum por conveniencia. Se nenhuma ferramenta desse tipo existir no runtime, faca as mesmas perguntas no chat e registre explicitamente: `Ferramenta de entrevista estruturada indisponivel; usando fallback em chat.`</critical>
+
+A ferramenta e obrigatoria no planejamento porque preserva escolhas explicitas do usuario e impede o agent de responder as proprias perguntas. Cada estagio mantem sua propria cota: PRD exige 7+ perguntas de produto; TechSpec exige 7+ perguntas tecnicas.
+
 ## Constitution Gate
 
 <critical>ANTES de qualquer estágio, cheque `.dw/constitution.md`. Se AUSENTE, copie `templates/constitution-template.md` para `.dw/constitution.md` (defaults severity=info), avise usuário no chat, e SIGA. Se PRESENTE, todo FR (PRD), toda decisão arquitetural (TechSpec) e toda task (Tasks) carrega metadata Constitution Alignment mapeando para princípios relevantes ou declarando desvio.</critical>
@@ -73,7 +79,7 @@ Roda em modo padrão OU `plan prd`.
 
 ### Comportamento obrigatório
 
-1. **Perguntas de clarificação (MÍNIMO 7).** Antes de escrever qualquer coisa, faça 7+ perguntas cobrindo: objetivos, usuários-alvo, limites de escopo, métricas de sucesso, estratégia de rollout, pontos de integração, edge cases.
+1. **Perguntas de clarificação (MÍNIMO 7).** Antes de escrever qualquer coisa, use a ferramenta de entrevista estruturada quando disponivel para fazer 7+ perguntas cobrindo: objetivos, usuários-alvo, limites de escopo, métricas de sucesso, estratégia de rollout, pontos de integração, edge cases. Se a ferramenta estiver indisponivel, use fallback em chat e registre o fallback.
 2. **Web search MÍNIMO 3 queries** para padrões de mercado, contexto regulatório, abordagens de competidores quando relevante.
 3. **Constitution alignment.** Cada requisito funcional (FR-N.M) inclui linha `Constitution Alignment: respects P-NNN, P-MMM` OU `no applicable principle: <motivo>`.
 4. **Awareness multi-projeto.** Se feature cruza projetos do workspace, consulte `.dw/rules/integrations.md` e documente escopo na seção "Projetos Impactados".
@@ -97,7 +103,7 @@ Roda em modo padrão (após aprovação do PRD) OU `plan techspec` OU `plan --fr
 ### Comportamento obrigatório
 
 1. **Hard gate: open questions do PRD.** Se `.dw/spec/prd-<feature>/prd.md` tem seção "Open Questions" com itens não resolvidos, PARE e peça pra usuário resolver primeiro.
-2. **Perguntas de clarificação (MÍNIMO 7).** Perguntas técnicas cobrindo: domain placement, data flow, dependências, core interfaces, estratégia de testes, reuse-vs-build, integração multi-projeto se aplicável.
+2. **Perguntas de clarificação (MÍNIMO 7).** Use a ferramenta de entrevista estruturada quando disponivel para fazer perguntas tecnicas cobrindo: domain placement, data flow, dependências, core interfaces, estratégia de testes, reuse-vs-build, integração multi-projeto se aplicável. Se a ferramenta estiver indisponivel, use fallback em chat e registre o fallback.
 3. **Web search MÍNIMO 3 queries** + Context7 MCP para framework/library specifics.
 4. **Source grounding (`dw-source-grounding`).** Toda decisão de framework/library carrega `[source: <url>, version: X.Y, retrieved: YYYY-MM-DD]`.
 5. **Constitution gate.** Cada decisão arquitetural lista `Respects: P-NNN` ou `Deviates: P-NNN — justification: <slug ADR ou racional>`. Desvios de princípios `severity: high/critical` sem ADR → PARE.
@@ -178,7 +184,7 @@ Após plan completo, o diretório do PRD contém:
 
 ## Diretrizes finais
 
-- Cada estágio tem sua própria cota de perguntas de clarificação — não recicle. Estágios diferentes precisam de framing diferente.
+- Cada estágio tem sua própria cota de perguntas de clarificação — não recicle. Estágios diferentes precisam de framing diferente. Use a ferramenta de entrevista estruturada sempre que disponivel.
 - Web search é obrigatório; Context7 MCP para libraries. Sem pular pra "acho que sei a versão mais recente."
 - Constitution gate roda na entrada de cada estágio; defaults são auto-instalados quando ausente (nunca bloqueia).
 - Os três estágios produzem Markdown commitado — esses são os artefatos canônicos de planejamento. Eles evoluem com a feature.

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

@@ -83,7 +83,7 @@ Quando disponíveis em `./.agents/skills/`, invocadas operacionalmente:
 
 1. **Pre-flight**: confirmar que dev server do projeto pode rodar. Confirmar `.dw/spec/<prd>/` tem PRD + TechSpec + tasks.
 2. **Mapear FRs para test plan**: pra cada FR, identificar fluxo user-facing que exercita.
-3. **Dirigir Playwright MCP** (ou fallback pra Playwright local per `dw-testing-discipline/references/playwright-recipes.md`):
+3. **Dirigir Playwright MCP** (se indisponível ou bloqueado — comum no WSL — use o fallback local resiliente `node .dw/scripts/lib/capture-screenshots.mjs`, que escolhe o browser via `.dw/scripts/lib/resolve-browser.mjs`; veja a seção "Browser on WSL" de `dw-testing-discipline/references/playwright-recipes.md`):
    - Happy paths pra cada FR.
    - Edge cases (boundary inputs, falha de rede, erros de validação).
    - Fluxos negativos (ações não autorizadas, input malformado).

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

@@ -56,12 +56,12 @@ Utilize ferramentas de diagnóstico conforme o framework do projeto:
 ## Comportamento Obrigatório
 
 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 screenshot usando `dw-testing-discipline`/playwright-recipes se disponível, rode react-doctor se projeto React.
+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.
 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. Use `dw-testing-discipline/references/playwright-recipes.md` para capturar screenshots em viewport 375px (mobile) e 1440px (desktop).
+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`.
 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

@@ -44,9 +44,10 @@ Quando disponíveis em `./.agents/skills/`, são invocadas como apoio analítico
 
 - `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, signal-over-volume. A tabela "Problemas Encontrados" segue essa disciplina.
 - `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.
-- `dw-secure-audit`: **SEMPRE para projetos TS/Python/C#/Rust** — security gate. Se projeto usa linguagem suportada e `secure-audit.md` recente está ausente OU REJECTED, verdict é **REPROVADO** — sem exceção.
+- `dw-secure-audit` (**Security Gate**): **SEMPRE para projetos TS/Python/C#/Rust** — acionado aqui e o verdict é enforced. Se a linguagem é suportada e `.dw/secure-audit/audit-summary.md` fresco está ausente OU REPROVADO, o verdict do review é **REPROVADO** — sem exceção. O mesmo gate também é comando standalone (`/dw-secure-audit`) e fase explícita no `/dw-autopilot`. Agora soma Semgrep SAST (diff) + gitleaks secrets sobre OWASP/Trivy/SCA.
+- `security-review`: a skill OWASP nível-diff que o gate usa (injection, authz, secrets, SSRF, crypto — só HIGH CONFIDENCE).
 - `dw-simplification`: use quando diff toca código denso — aplica Chesterton's Fence, protocolo de refactor preservando comportamento, métricas de complexidade.
-- `dw-ui-discipline`: use quando diff toca UI — roda os 14 visual-slop patterns + accessibility floor.
+- `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-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.
 - `security-review`: use quando diff toca auth, autorização, input externo, upload, SQL, secrets, SSRF, XSS ou superfícies sensíveis.
@@ -161,9 +162,10 @@ Se FALTANDO > 0, o veredicto sugere revisitar `/dw-plan tasks` pra escopar ou `/
    - Rodar dw-verify pra produzir VERIFICATION REPORT (test + lint + build GREEN).
    - Sem PASS, verdict não pode ser APROVADO.
 
-8. **Security Layer (`dw-secure-audit` para TS/Python/C#/Rust):**
-   - Rodar `/dw-secure-audit` contra o PR. Scan mais recente deve estar presente e não REPROVADO.
-   - Se linguagem suportada e audit faltando OU REPROVADO → verdict **REPROVADO**.
+8. **Security Gate (`dw-secure-audit` para TS/Python/C#/Rust):**
+   - Acione `/dw-secure-audit` contra o diff (OWASP + Semgrep SAST + gitleaks + Trivy/SCA + supply-chain). Ele produz/atualiza `.dw/secure-audit/audit-summary.md`.
+   - Scan mais recente deve estar presente, fresco (pós-última-edição) e não REPROVADO. Se linguagem suportada e audit ausente OU REPROVADO → verdict do review **REPROVADO**. Findings SECRET sempre bloqueiam (sem escape de ADR).
+   - O mesmo gate também roda standalone (`/dw-secure-audit`) e é fase explícita no `/dw-autopilot`; `/dw-generate-pr` re-enforça o verdict antes do PR.
 
 ### Output
 

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

@@ -1,7 +1,13 @@
 <system_instructions>
-Você é o orquestrador de security audit. Roda OWASP static review + supply-chain CVE/secret/IaC scanning + outdated check + supply-chain compromise detection em uma passada. Hard-gates comandos downstream quando há findings CRITICAL ou HIGH.
+Você é o orquestrador de security audit — o **Security Gate**. Roda OWASP static review + SAST (Semgrep,
+focado no diff do código gerado) + secret scan dedicado (gitleaks) + supply-chain CVE/secret/IaC (Trivy +
+native lockfile audit) + supply-chain compromise detection + outdated check, em uma passada. Hard-gates
+comandos downstream quando há qualquer finding bloqueante.
 
-Auto-invocado por `/dw-review` e `/dw-generate-pr` em projetos TS/Python/C#/Rust. Invocação standalone disponível pra audit manual.
+É **auto-invocado por `/dw-review` e `/dw-generate-pr`** (em TS/Python/C#/Rust), roda como **fase explícita e
+nomeada no `/dw-autopilot`** (após review + QA, antes de commit/PR), e é **executável standalone** a qualquer
+momento. O `/dw-generate-pr` re-enforça o verdict como hard gate final. Os três continuam gating em segurança
+— o comando standalone e a fase nomeada são aditivos, não substituem.
 
 ## Quando Usar
 - Auto-invocado: `/dw-review` e `/dw-generate-pr` em linguagens suportadas.
@@ -10,7 +16,7 @@ Auto-invocado por `/dw-review` e `/dw-generate-pr` em projetos TS/Python/C#/Rust
 - NÃO use como substituto pra review humano em código auth/payment de alto risco (use skill `security-review` JUNTO com este).
 
 ## Posição no Pipeline
-**Antecessor:** qualquer momento; auto-invocado por `/dw-review`, `/dw-generate-pr` | **Sucessor:** `/dw-bugfix` pra atacar findings, ou `/dw-commit` se APROVADO
+**Antecessor:** `/dw-review` + `/dw-qa` (o Security Gate roda depois deles passarem) | **Sucessor:** `/dw-commit` / `/dw-generate-pr` se APROVADO, ou `/dw-bugfix` pra atacar findings. Também roda standalone a qualquer momento.
 
 ## Modos
 
@@ -33,10 +39,20 @@ Auto-invocado por `/dw-review` e `/dw-generate-pr` em projetos TS/Python/C#/Rust
 
 ## Dependências Necessárias
 
-- **Trivy** — deve estar instalado (via `npx @brunosps00/dev-workflow install-deps`).
+- **Trivy** — SCA / secrets / IaC (via `npx @brunosps00/dev-workflow install-deps`).
+- **Semgrep** — camada SAST (opcional mas recomendado). Se ausente, a camada SAST é pulada e anotada.
+- **gitleaks** — secret scan dedicado (opcional mas recomendado). Se ausente, cai pro Trivy secrets.
 - **Context7 MCP** — pra best practices específicas de versão.
 
-## Três Camadas de Detecção
+Todos os scanners são opcionais individualmente: uma tool ausente degrada aquela camada e é **reportada**
+no summary (o gate nunca quebra por falta de scanner), mas a cobertura faltante fica visível. Instale via
+`npx @brunosps00/dev-workflow install-deps`.
+
+## Camadas de Detecção
+
+**Foco no diff (código gerado):** camadas que suportam isso focam no diff contra a base do PR
+(`git merge-base HEAD origin/main`), concentrando o gate no código recém-escrito, sem ruído do código
+pré-existente. Um pass periódico `--full` varre a árvore inteira.
 
 ### Camada 1: OWASP Static Review (via skill `security-review`)
 
@@ -72,6 +88,23 @@ Cruza dependency tree contra:
 
 Output: `.dw/secure-audit/compromise-findings.md` por pacote afetado: COMPROMISED / suspicious / clean.
 
+### Camada 4: SAST — Semgrep (análise semântica do código gerado)
+
+Análise estática semântica e determinística do **diff** (`--baseline-commit`), complementando a Camada 1.
+Rulesets fixados: `p/security-audit`, `p/owasp-top-ten`, `p/secrets` (+ packs de linguagem detectados).
+Mapeie Semgrep `ERROR`→HIGH (ou CRITICAL pra CWEs RCE/authn-bypass/SQLi), `WARNING`→MEDIUM, `INFO`→LOW.
+Aplique a disciplina **fp-check** (reachability) antes de um finding bloquear (ver `security-review/references/sast.md`).
+
+Output: `.dw/secure-audit/sast-findings.md`. Se `semgrep` ausente: pulado + anotado no summary.
+
+### Camada 5: Secret scan dedicado — gitleaks
+
+`gitleaks protect --staged` (não-commitado) ou `gitleaks detect --log-opts <base>..HEAD` (branch), `--redact`.
+Autoritativo no diff; complementa Trivy secrets (dedupe por `file:line`). **Qualquer hit = REPROVADO, sem
+exceção de ADR** — secrets são removidos e rotacionados, não justificados. Ver `security-review/references/secrets.md`.
+
+Output: `.dw/secure-audit/secret-findings.md`. Se `gitleaks` ausente: cai pro Trivy secrets + anotado.
+
 ### Plus: outdated check
 
 `npm outdated` / `pip list --outdated` / `dotnet list outdated` / `cargo outdated` pra identificar pacotes atrás em minor ou major.
@@ -84,9 +117,11 @@ Todos os findings são classificados num desses tiers em `.dw/secure-audit/audit
 
 | Tier | Critério | Bloqueia | Ação Sugerida |
 |------|----------|----------|---------------|
+| **SECRET** | Credencial/chave/token hardcoded (gitleaks ou Trivy), sobrevive ao allowlist | SIM — **sem exceção de ADR** | Remover do código + histórico, rotacionar, mover pra secret store |
 | **COMPROMISED** | Pacote conhecido como malicioso nessa faixa de versão | SIM | Remover imediato / pin pra versão segura |
-| **CRITICAL** | CVE CVSS ≥9.0 OU exploit ativo OU auth bypass | SIM | Update ou substituir em 24h |
-| **HIGH** | CVE CVSS 7.0–8.9 OU exploitável no contexto atual | SIM | Update ou substituir em 1 semana |
+| **CRITICAL** | CVE CVSS ≥9.0 OU exploit ativo OU auth bypass; OU SAST de CWE alto-impacto (SQLi/RCE/authn-bypass/SSRF/deserialization) alcançável | SIM | Update/substituir ou corrigir em 24h |
+| **HIGH** | CVE CVSS 7.0–8.9 OU exploitável no contexto; OU Semgrep `ERROR` alcançável (fp-check passou) | SIM | Update/substituir ou corrigir em 1 semana |
+| **MEDIUM / LOW** | CVE CVSS <7.0; OU Semgrep `WARNING`/`INFO`; OU finding inalcançável rebaixado pelo fp-check | NÃO (advisory) | Rastrear e corrigir rotineiramente |
 | **OUTDATED-MAJOR** | ≥1 major version atrás (ex: React 17 → 19) | NÃO | Planejar migração próximo trimestre |
 | **OUTDATED-MINOR** | Minor/patch atrás | NÃO | Update rotineiro |
 | **CLEAN** | Sem findings | NÃO | — |
@@ -94,19 +129,26 @@ Todos os findings são classificados num desses tiers em `.dw/secure-audit/audit
 ## Hard Gates
 
 Verdict é um de:
-- **APROVADO** — sem CRITICAL, HIGH ou COMPROMISED. Arquivo verdict `.dw/secure-audit/audit-summary.md` status: APROVADO.
-- **REPROVADO** — ≥1 CRITICAL, HIGH ou COMPROMISED sem ADR explícito ou remediação em andamento. Status: REPROVADO.
+- **APROVADO** — sem SECRET, COMPROMISED, CRITICAL ou HIGH. Arquivo verdict `.dw/secure-audit/audit-summary.md` status: APROVADO. (MEDIUM/LOW/outdated podem aparecer como advisory.)
+- **REPROVADO** — ≥1 SECRET (sempre), ou ≥1 COMPROMISED/CRITICAL/HIGH sem ADR explícito ou remediação em andamento. Status: REPROVADO.
+
+**Limiar Rigoroso:** SECRET e COMPROMISED sempre bloqueiam. CRITICAL/HIGH (CVE ou SAST alcançável) bloqueiam salvo ADR justificando aceitação. MEDIUM/LOW e outdated são advisory. SECRET é o único tier **sem escape via ADR** — rotacione, não justifique.
 
 **`/dw-review` e `/dw-generate-pr` enforçam:** se linguagem do projeto é suportada E `.dw/secure-audit/audit-summary.md` mais recente está faltando OU REPROVADO, esses comandos retornam REPROVADO. Sem exceção. Sem flag bypass.
 
 ## Modo 1: Default (`/dw-secure-audit`)
 
 1. **Detectar stack**: checar package.json / requirements.txt / *.csproj / Cargo.toml.
-2. **Rodar todas as três camadas em paralelo** (onde possível):
-   - OWASP static (via skill `security-review`).
+2. **Rodar todas as camadas de detecção em paralelo** (onde possível):
+   - OWASP static (via skill `security-review`) — focado no diff.
+   - SAST — Semgrep no diff (`--baseline-commit`).
+   - Secret scan dedicado — gitleaks no diff.
    - Trivy + lockfile audit.
    - Supply-chain compromise check.
 3. **Rodar outdated check.**
+   **fp-check:** antes de finalizar, rode validação de reachability em cada finding SAST/OWASP bloqueante
+   (ver `security-review` SKILL.md); rebaixe os comprovadamente inalcançáveis pra advisory com razão logada.
+   Secrets são isentos de rebaixamento.
 4. **Agregar findings** por tier.
 5. **Escrever summary** em `.dw/secure-audit/audit-summary.md`:
 
@@ -118,14 +160,26 @@ Verdict é um de:
 ## Resumo por Tier
 | Tier | Contagem | Detalhe |
 |------|----------|---------|
+| SECRET | N | <lista> |
 | COMPROMISED | N | <lista> |
 | CRITICAL | N | <lista> |
 | HIGH | N | <lista> |
+| MEDIUM/LOW (advisory) | N | <lista> |
 | OUTDATED-MAJOR | N | <lista> |
 | OUTDATED-MINOR | N | <lista> |
 
+## Scanners
+| Camada | Tool | Status |
+|--------|------|--------|
+| OWASP | security-review | rodou |
+| SAST | semgrep | rodou / pulado (não instalado) |
+| Secrets | gitleaks | rodou / fallback trivy (não instalado) |
+| SCA/IaC | trivy | rodou |
+
 ## Relatórios das camadas
 - OWASP: `owasp-findings.md`
+- SAST: `sast-findings.md`
+- Secrets: `secret-findings.md`
 - Trivy: `trivy-findings.md`
 - Lockfile: `lockfile-findings.md`
 - Compromise: `compromise-findings.md`
@@ -164,7 +218,7 @@ Pra cada remediação aprovada:
 ## Modo 4: CI (`/dw-secure-audit --scan-only`)
 
 Output mínimo:
-- Roda todas as três camadas.
+- Roda todas as camadas de detecção.
 - Escreve findings em disco.
 - Exit code 0 se APROVADO, 1 se REPROVADO.
 - Sem planejamento.
@@ -182,8 +236,9 @@ Pra gates pre-merge em CI.
 ## Constitution Gate
 
 <critical>
-- CRITICAL ou COMPROMISED finding sem ADR justificando aceitação explícita → verdict não pode ser APROVADO.
-- Violações de princípios de constitution security-related (P-009 server-side auth, P-010 secrets-in-repo) escalonam findings — violação de princípio `severity: info` surface aqui vira HIGH.
+- Finding SECRET → verdict NUNCA pode ser APROVADO (sem escape via ADR). Rotacione e remova.
+- Finding CRITICAL/HIGH/COMPROMISED (CVE ou SAST alcançável) sem ADR justificando aceitação explícita → verdict não pode ser APROVADO.
+- Violações de princípios de constitution security-related (P-009 server-side auth, P-010 secrets-in-repo, P-011 sem SAST high-severity) escalonam findings — violação de princípio `severity: info` surface aqui vira HIGH.
 </critical>
 
 ## Anti-patterns
@@ -198,8 +253,10 @@ Pra gates pre-merge em CI.
 
 ```
 .dw/secure-audit/
-├── audit-summary.md           # verdict + resumo de tiers
+├── audit-summary.md           # verdict + resumo de tiers + status dos scanners
 ├── owasp-findings.md          # Camada 1
+├── sast-findings.md           # Camada 4 (Semgrep)
+├── secret-findings.md         # Camada 5 (gitleaks, redacted)
 ├── trivy-findings.md          # Camada 2 (SCA + secrets + IaC)
 ├── lockfile-findings.md       # Camada 2 (native auditor)
 ├── compromise-findings.md     # Camada 3

package/scaffold/pt-br/templates/constitution-template.md

@@ -80,12 +80,17 @@ mode: defaults | custom
 **P-009 — Authorization server-side em todo endpoint que altera estado** (severity: info)
 **Regra:** Endpoint que cria, atualiza ou deleta dado deve verificar autorização do caller no servidor. Gating em UI (botões escondidos, formulários disabled) não é segurança.
 **Why:** Browsers são untrusted (ver `dw-testing-discipline/references/security-boundary.md`). Gating em UI é conveniência; só checks server-side protegem dado.
-**Enforcement:** `dw-code-review` e `dw-security-check` exigem check de auth explícito (decorator, middleware ou assertion in-handler) em rotas POST/PUT/PATCH/DELETE.
+**Enforcement:** `dw-review` e o Security Gate `dw-secure-audit` exigem check de auth explícito (decorator, middleware ou assertion in-handler) em rotas POST/PUT/PATCH/DELETE.
 
-**P-010 — Secrets nunca entram no repositório** (severity: info)
+**P-010 — Secrets nunca entram no repositório** (severity: high)
 **Regra:** Nenhuma API key, password, signing key, token ou endpoint de produção commitado em source. `.env.example` documenta forma apenas.
 **Why:** Histórico de repositório é permanente. Um secret commitado uma vez está vazado mesmo que revertido no commit seguinte.
-**Enforcement:** `dw-security-check` roda Trivy + secret scanners no diff.
+**Enforcement:** o Security Gate `dw-secure-audit` roda gitleaks + Trivy no diff. Qualquer hit bloqueia — **sem exceção de ADR** (rotacione, não justifique).
+
+**P-011 — Nenhum finding SAST high-severity passa sem revisão** (severity: high)
+**Regra:** Código gerado/alterado deve passar na camada SAST (Semgrep) do Security Gate. Um finding high-severity alcançável (SQLi, command/code injection, SSRF, deserialization insegura, authn bypass) bloqueia salvo ADR justificando aceitação.
+**Why:** Código gerado por IA reproduz padrões inseguros em escala; SAST determinístico no diff pega o que o review por leitura perde.
+**Enforcement:** `dw-secure-audit` roda Semgrep no diff (`--baseline-commit`); findings sobrevivem a uma validação fp-check de reachability antes de bloquear.
 
 ---
 

package/scaffold/pt-br/templates/functional-doc/playwright.flow.mjs.tpl

@@ -0,0 +1,17 @@
+// Módulo de fluxo do functional-doc. Executado por .dw/scripts/functional-doc/run-playwright-flow.mjs
+// através da API Node do Playwright, para que o vídeo seja gravado com page.screencast (funciona tanto
+// com browser lançado quanto via connectOverCDP). Não precisa de imports aqui — o runner injeta
+// page, context, expect, baseURL e os helpers step()/shot().
+
+export default async function flow({ page, expect, baseURL, step, shot }) {
+  await step("Abrir rota alvo", async () => {
+    await page.goto(`${baseURL}{{routePath}}`);
+    await expect(page).toHaveURL(new RegExp("{{routeRegex}}"));
+  });
+
+{{testSteps}}
+
+  await step("Registrar contexto final", async () => {
+    await expect(page.locator("body")).toBeVisible();
+  });
+}

package/scaffold/scripts/cdp-relay/Cargo.toml

@@ -0,0 +1,16 @@
+[package]
+name = "cdp-relay"
+version = "0.1.0"
+edition = "2021"
+description = "Tiny TCP forwarder so WSL can reach a Windows browser's CDP debug port in NAT mode. Built on Windows by dev-workflow; no runtime dependency."
+
+[[bin]]
+name = "cdp-relay"
+path = "src/main.rs"
+
+[profile.release]
+opt-level = "z"
+lto = true
+strip = true
+panic = "abort"
+codegen-units = 1

package/scaffold/scripts/cdp-relay/src/main.rs

@@ -0,0 +1,49 @@
+//! cdp-relay — a tiny TCP forwarder.
+//!
+//! Listens on 0.0.0.0:<listen> and forwards every connection to 127.0.0.1:<target>.
+//! dev-workflow runs this on the Windows side so WSL (NAT networking) can reach a Windows
+//! browser's CDP remote-debugging port, which Chromium binds to loopback only. std-only:
+//! no crates, no runtime — a single static .exe built with the user's Windows `cargo`.
+
+use std::env;
+use std::io;
+use std::net::{Shutdown, TcpListener, TcpStream};
+use std::thread;
+
+fn pump(mut from: TcpStream, mut to: TcpStream) {
+    let _ = io::copy(&mut from, &mut to);
+    // Signal EOF to the peer so the other direction can finish cleanly.
+    let _ = to.shutdown(Shutdown::Write);
+}
+
+fn handle(client: TcpStream, target_port: u16) -> io::Result<()> {
+    client.set_nodelay(true).ok();
+    let upstream = TcpStream::connect(("127.0.0.1", target_port))?;
+    upstream.set_nodelay(true).ok();
+
+    let client_rx = client.try_clone()?;
+    let upstream_rx = upstream.try_clone()?;
+    // client -> upstream
+    thread::spawn(move || pump(client, upstream));
+    // upstream -> client
+    thread::spawn(move || pump(upstream_rx, client_rx));
+    Ok(())
+}
+
+fn main() {
+    let args: Vec<String> = env::args().collect();
+    if args.len() < 3 {
+        eprintln!("usage: cdp-relay <listen_port> <target_port>");
+        std::process::exit(2);
+    }
+    let listen_port: u16 = args[1].parse().expect("invalid listen port");
+    let target_port: u16 = args[2].parse().expect("invalid target port");
+
+    let listener = TcpListener::bind(("0.0.0.0", listen_port)).expect("bind failed");
+    for stream in listener.incoming() {
+        if let Ok(client) = stream {
+            // One connection failing must not take down the relay.
+            let _ = handle(client, target_port);
+        }
+    }
+}