@brunosps00/dev-workflow 0.10.0 → 0.13.0

package/scaffold/pt-br/agent-instructions.md

@@ -0,0 +1,68 @@
+<!-- dev-workflow:start -->
+# dev-workflow — Instruções para Agente de IA
+
+Este projeto usa [`@brunosps00/dev-workflow`](https://www.npmjs.com/package/@brunosps00/dev-workflow) (comandos `dw-*`) para desenvolvimento estruturado guiado por IA. Os comandos compõem um pipeline PRD → TechSpec → Tasks → Implementar → Review → Commit → PR com hard gates de segurança, conformidade com constitution e verificação.
+
+**Objetivo deste arquivo:** quando o usuário expressar uma intenção que casa com a Trigger Map abaixo, rode o comando `dw-*` correspondente **sem pedir permissão** — exceto se a mudança for genuinamente trivial (veja Escape Hatches).
+
+## Trigger Map
+
+| Intenção do usuário (literal ou parafraseada) | Auto-trigger |
+|------------------------------------------------|--------------|
+| "Implementa X" / "Cria Y" / "Adiciona feature Z" / "Preciso de..." | `/dw-autopilot "X"` |
+| Erro colado / "X está quebrado" / "Bug em Y" / screenshot de teste falhando | `/dw-bugfix "X"` |
+| "Roda essa task" (com ID da task) | `/dw-run-task <ID>` |
+| "Roda todas as tasks pendentes" / "Executa o plano" | `/dw-run-plan` |
+| "Revisa meu PR" / "Checa qualidade do código" / "Tá pronto pra subir?" | `/dw-code-review` |
+| "Hora de commitar" / mudanças validadas e prontas | `/dw-commit` |
+| "Abre um PR" / "Sobe isso" | `/dw-generate-pr` |
+| "Escreve PRD pra X" / "Especifica Y" | `/dw-create-prd` |
+| "Desenha a arquitetura" / "Faz o techspec" | `/dw-create-techspec` |
+| "Quebra em tasks" | `/dw-create-tasks` |
+| "Onde está X?" / "O que usa Y?" / "Como Z é estruturado?" | `/dw-intel "<pergunta>"` |
+| "Audita nossas dependências" / "Estamos atrasados em pacotes?" | `/dw-deps-audit` |
+| "Scan de vulnerabilidades" / "Check de segurança" | `/dw-security-check` |
+| "QA dessa feature" / "Roda o test plan" | `/dw-run-qa` |
+| "Corrige os bugs do QA" | `/dw-fix-qa` |
+
+**Prioridade:** na dúvida entre dois comandos, `/dw-autopilot` é o default mais seguro pra qualquer pedido de feature não-trivial — ele compõe os demais.
+
+## Hard Gates (os comandos enforçam — não burle)
+
+- **`.dw/constitution.md`**: princípios com `severity: high` ou `critical` bloqueiam PRs / techspecs sem um ADR justificando o desvio. Constitution ausente? Os comandos auto-instalam defaults em `severity: info` (não-bloqueante) e seguem — ausência nunca bloqueia.
+- **`.dw/spec/<prd>/tasks-validation.md`**: auto-gerado no fim do `/dw-create-tasks`. Qualquer dimensão FAIL bloqueia approval do usuário até resolver ou override explícito.
+- **Verification**: `/dw-generate-pr` exige `dw-verify` PASS fresco (testes + lint + build) depois do último edit.
+- **Segurança**: projetos TS / Python / C# / Rust precisam passar `/dw-security-check` (Trivy + OWASP + lockfile audit) antes do PR abrir.
+
+## Escape Hatches — NÃO auto-trigger
+
+Quando qualquer destes se aplica, responda direto e **não** invoque comando `dw-*`:
+
+- Correção de uma linha: typo, rename, sort de imports, ajuste de comentário.
+- Exploração pura: "como isso funciona?", "me mostra X", "explica Y".
+- Preferência estética: "prefiro esse estilo" — aplica, não roda pipeline.
+- Usuário diz explicitamente "faz direto" / "pula autopilot" / "não precisa de PRD" — honre.
+- A conversa já está dentro de um fluxo `dw-*` (você já está executando tasks; não inicie pipeline novo).
+
+## Referência de Workflow
+
+```
+/dw-autopilot "wish"  ────►  Roda pipeline completo automaticamente
+                              (3 gates: PRD approval, Tasks approval, PR confirmação)
+
+  --- OU passo a passo ---
+
+/dw-brainstorm ─► /dw-create-prd ─► /dw-create-techspec ─► /dw-create-tasks
+                                                              │
+                                                              ▼
+/dw-commit + /dw-generate-pr ◄──── /dw-code-review ◄──── /dw-run-plan
+```
+
+Lista completa e ajuda contextual: `/dw-help`.
+
+## Editando esta seção
+
+Este bloco vive entre os marcadores `<!-- dev-workflow:start -->` e `<!-- dev-workflow:end -->`. Qualquer coisa que você escrever **fora** dos marcadores em `CLAUDE.md` / `AGENTS.md` é preservada a cada `dev-workflow update`. Tudo **dentro** é regenerado do pacote — seus edits dentro do bloco serão sobrescritos.
+
+Para customizar a trigger map permanentemente, copie o conteúdo pra fora dos marcadores (ou pra arquivo separado tipo `.dw/agent-instructions-custom.md`) e edite lá.
+<!-- dev-workflow:end -->

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

@@ -645,6 +645,67 @@ packages/auth → packages/db
 - Crie o diretório .dw/rules/ se não existir
 </critical>
 
+### Step 8: Constitution Generation (Opcional, mas Recomendado)
+
+Após escrever `.dw/rules/`, oferecer gerar `.dw/constitution.md` — os princípios declarativos que o time quer ver enforçados em PRDs, TechSpecs e Code Reviews.
+
+**Diferença vs `.dw/rules/`:**
+- `.dw/rules/` é **analítico** — o que o código É (padrões observados, anti-patterns, convenções).
+- `.dw/constitution.md` é **declarativo** — o que o código DEVE SER (regras às quais o time se compromete).
+
+**Comportamento:**
+
+Se `.dw/constitution.md` já existir, imprimir "Constituição já existe em `.dw/constitution.md` — pulando (edite manualmente se quiser atualizar)" e encerrar.
+
+Caso contrário, apresentar 3 opções no chat (use a UI de pergunta preferida quando disponível; caso contrário texto puro):
+
+```
+Uma constitution ajudaria PRDs/TechSpecs/PRs a permanecerem alinhados aos padrões.
+Três opções:
+
+  A) Sintetizar dos padrões observados (recomendado)
+     Leio `.dw/rules/` e proponho 5–8 princípios fundamentados no código real,
+     cada um com `Why:` ligado a evidência e `severity: info` (não bloqueia).
+     Você revisa e aprova antes de qualquer escrita.
+
+  B) Instalar template de defaults
+     Copia `templates/constitution-template.md` para `.dw/constitution.md` com
+     5 princípios canônicos (Qualidade, Testes, UX, Performance, Segurança)
+     pré-preenchidos em `severity: info`. Você customiza manualmente.
+
+  C) Pular
+     Sem constitution. Comandos downstream operam sem o gate.
+     Você pode rodar este step novamente re-executando `/dw-analyze-project`.
+```
+
+**Opção A — Sintetizar:**
+
+1. Ler `.dw/rules/index.md` + cada `.dw/rules/{module}.md`.
+2. Propor 5–8 princípios. Cada um deve:
+   - Ter ID único `P-NNN`.
+   - Mapear para uma observação em `.dw/rules/` (citar o arquivo + seção).
+   - Começar em `severity: info` (nunca propor `high`/`critical` automaticamente — isso é decisão do time).
+   - Seguir formato: `**P-NNN — <nome>** (severity: info): <regra>. **Why:** <fundamentar em evidência>. **Enforcement:** <como checar>.`
+3. **Mostrar os princípios propostos no chat como lista markdown** (não escreva o arquivo ainda). Incluir a citação de evidência para cada um.
+4. Perguntar: "Edita algum antes de eu gravar? Responda com os IDs para descartar/editar, ou 'aprovar' para escrever como está."
+5. Após aprovação (com edits aplicados), gravar em `.dw/constitution.md` usando a mesma estrutura de `templates/constitution-template.md`.
+6. Setar frontmatter `mode: custom` e `last_updated: <data ISO de hoje>`.
+
+**Opção B — Defaults:**
+
+1. Localizar `templates/constitution-template.md` (projeto-local em `.dw/templates/constitution-template.md`, com fallback para scaffold bundled).
+2. Copiar para `.dw/constitution.md` literalmente. Setar frontmatter `mode: defaults`.
+3. Imprimir: "Constituição defaults instalada em `.dw/constitution.md`. Todos os 10 princípios começam em `severity: info` — reportam mas não bloqueiam. Edite o arquivo para customizar, depois promova severities para `high`/`critical` quando confiar."
+
+**Opção C — Pular:**
+
+1. Nada a fazer.
+2. Imprimir: "Pulado. PRD/TechSpec/CodeReview rodarão sem o constitution gate. Re-rode `/dw-analyze-project` mais tarde se quiser habilitar."
+
+**Em qualquer opção:**
+- Nunca escrever `.dw/constitution.md` sem aprovação explícita (opção A) ou escolha explícita (opções B/C).
+- Constitution é commitada ao repositório como qualquer outro artefato do projeto — nunca gitignored.
+
 ## Checklist de Qualidade
 
 - [ ] Estrutura do repositório escaneada

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

@@ -141,7 +141,7 @@ Apresente ao usuario:
 ### Etapa 7: Design Contract (Condicional)
 
 Avalie se as tasks envolvem frontend:
-- **SIM** (execute `/dw-redesign-ui`): se houver tasks com componentes visuais E a skill `ui-ux-pro-max` estiver disponivel
+- **SIM** (execute `/dw-redesign-ui`): se houver tasks com componentes visuais E a skill `dw-ui-discipline` estiver disponivel
   - Gere o design contract em `.dw/spec/prd-[nome]/design-contract.md`
   - Apresente um resumo do design contract ao usuario (paleta, tipografia, layout mobile/desktop) como checkpoint visual antes de prosseguir
 - **NAO** (pule para etapa 8): tasks puramente backend/infra

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

@@ -41,7 +41,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
+- `dw-ui-discipline`: use quando o brainstorm envolver frontend ou direção de UI — o hard-gate (scene sentence, surface job) é forcing function generativa durante ideação, não só check de review
 - `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

@@ -18,7 +18,7 @@
     - `dw-debug-protocol`: **SEMPRE** — conduz o bug pelo six-step triage (Reproduzir → Localizar → Reduzir → Fix Root Cause → Guardar → Verificar End-to-End). Stop-the-line discipline; root-cause sobre symptom; regression test commitado no mesmo commit atômico. Bugs não-reprodutíveis seguem o sub-protocolo instrument-first — sem fix por palpite a não ser com acknowledgement explícito.
     - `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
+    - `dw-testing-discipline`: use quando a correção requer fluxo E2E/reteste reproduzível em web app — `references/playwright-recipes.md` pra recipes, Iron Laws + 7 AI Gates pra qualquer teste que o fix adicione, flaky-discipline se o bug aparece de forma intermitente.
     - `security-review`: use quando a causa raiz toca auth, autorização, input externo, upload, secrets, SQL, XSS, SSRF ou outras superfícies sensíveis
 
     ## Variáveis de Entrada
@@ -153,7 +153,7 @@
     - Mensagens de erro relacionadas
     - Stack traces
     - Arquivos modificados recentemente
-    - Se o bug for relacionado a UI ou depender de fluxo no navegador, complemente a coleta com `webapp-testing`
+    - Se o bug for relacionado a UI ou depender de fluxo no navegador, complemente a coleta com `dw-testing-discipline` (playwright-recipes + three-workflow-patterns pra escolher o modo certo de verificação)
 
     ### 3. Perguntas de Clarificação (OBRIGATÓRIO - EXATAMENTE 3)
 
@@ -180,7 +180,7 @@
     - **Causa Provável**: Baseado nas evidências
     - **Arquivos Afetados**: Lista de arquivos a modificar
     - **Impacto**: Outros componentes que podem ser afetados
-    - **Skills utilizadas**: registre explicitamente se a análise usou `vercel-react-best-practices`, `webapp-testing` ou `security-review`
+    - **Skills utilizadas**: registre explicitamente se a análise usou `vercel-react-best-practices`, `dw-testing-discipline` ou `security-review`
 
     ### 4.1 Checkpoint de Escopo (OBRIGATÓRIO)
 

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

@@ -159,6 +159,34 @@ Para cada projeto impactado, verificar rules específicas em `.dw/rules/`:
 - [ ] Chamadas de API usam utilitários fetch do projeto
 - [ ] UI segue o design system do projeto
 
+### 4.1. Constitution Compliance (Obrigatório quando `.dw/constitution.md` existe)
+
+<critical>**Auto-create se ausente**: se `.dw/constitution.md` NÃO existir, copie `templates/constitution-template.md` (project-local `.dw/templates/constitution-template.md` primeiro, com fallback para scaffold bundled) literalmente com frontmatter `mode: defaults`. Imprimir no chat: "Constituição defaults instalada em `.dw/constitution.md` (todos os princípios em `severity: info` — reportam mas não bloqueiam este review). Seguindo." Depois prossiga.</critical>
+
+Para cada princípio em `.dw/constitution.md`, verificar o diff por violações:
+
+1. **Parsear princípios**: ler cada entrada `**P-NNN — <nome>** (severity: <S>)`; capturar `P-NNN`, `severity` e descrição de `Enforcement`.
+2. **Aplicar enforcement**: para cada princípio, rodar a checagem de enforcement contra o diff (grep, inspeção de arquivo ou pattern match conforme a linha Enforcement).
+3. **Classificar violações**:
+   - Princípio `severity: info` → adicione linha à tabela "Issues Found" com severity `low`. **Não bloqueia** o verdict.
+   - Princípio `severity: high` → adicione linha com severity `critical`. **Bloqueia** o verdict como `REJECTED` EXCETO se um ADR no `adrs/` do mesmo PRD documenta o desvio (busque `Deviates: P-NNN` no corpo de qualquer ADR).
+   - Princípio `severity: critical` → adicione linha com severity `critical` E exigir que o ADR tenha campo `Approved by:` não-vazio. Campo ausente = ainda `REJECTED`.
+4. **Sem skip silencioso**: se o diff for grande demais para analisar todos os princípios, reportar quais foram checados e quais foram pulados por escopo.
+
+**Formato de saída no relatório:**
+
+```markdown
+## Constitution Compliance
+
+| Princípio | Severity | Status | Evidência | ADR escape |
+|-----------|----------|--------|-----------|------------|
+| P-001 — Sem `any` casts | info | VIOLATED | src/foo.ts:42 | n/a |
+| P-009 — Auth server-side | high | VIOLATED | src/api/order.ts:18 sem auth middleware | none → BLOQUEIA |
+| P-010 — Secrets no repo | critical | PASS | — | — |
+```
+
+Se houver violação `high`/`critical` sem ADR escape: adicionar à linha de verdict "REPROVADO — violação(ões) de constitution sem ADR (ver seção Constitution Compliance)".
+
 ### 5. Análise de Qualidade de Código (Obrigatório)
 
 | Aspecto | Verificação |

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

@@ -50,6 +50,22 @@
     - Use `.dw/rules/` como contexto, caindo para grep
     - Sugira rodar `/dw-map-codebase` para enriquecer contexto downstream
 
+    ## Constitution Gate
+
+    <critical>ANTES das clarification questions, cheque `.dw/constitution.md`:
+
+    **Se AUSENTE**: copie `templates/constitution-template.md` (project-local em `.dw/templates/constitution-template.md`, com fallback para scaffold bundled) literalmente para `.dw/constitution.md`. Setar frontmatter `mode: defaults` e `last_updated` para data ISO de hoje. Imprimir no chat:
+
+    > "Notei que `.dw/constitution.md` estava ausente. Instalei defaults em `.dw/constitution.md` (10 princípios canônicos, todos em `severity: info` — reportam mas não bloqueiam). Pode customizar a qualquer momento — ou re-rodar `/dw-analyze-project` para versão sob medida. Seguindo com o PRD."
+
+    Depois prossiga normalmente, tratando o arquivo recém-criado como a constitution.
+
+    **Se PRESENTE**: leia antes de redigir requisitos. Cada FR no PRD DEVE incluir linha "Constitution Alignment" mapeando para ≥1 princípio relevante (`Respects: P-001, P-009`) OU declarando explicitamente "no applicable principle" com motivo em uma linha. Sem alignment = FR está incompleto.
+
+    **Regras de severity** (aplicadas pelos comandos downstream, não enforçadas aqui):
+    - Violações `severity: info` → reportadas, nunca bloqueiam.
+    - Violações `severity: high` / `critical` → bloqueiam em `dw-create-techspec` e `dw-code-review` exceto se ADR justificar.</critical>
+
     ## Features Multi-Projeto
 
     Muitas funcionalidades podem envolver mais de um projeto no workspace.

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

@@ -149,5 +149,47 @@
     3. /dw-generate-pr [branch-alvo] quando todas tasks concluídas
     ```
 
+    ## Final Consistency Check (Auto-invocado antes da aprovação do usuário)
+
+    <critical>ANTES de apresentar tasks ao usuário, rode um check de consistência em 5 dimensões. Isto é mandatório; não pule mesmo se confiante de que as tasks estão limpas.</critical>
+
+    Rode estes 5 checks contra o conjunto PRD + TechSpec + tasks gerado:
+
+    1. **Cobertura de RF** — cada RF numerada no PRD mapeia para ≥1 task. RFs órfãs (PRD tem; nenhuma task cobre) são FAIL.
+    2. **Grounding das tasks** — cada task gerada referencia ≥1 RF em seu corpo (`Cobre: RF-N.M`). Tasks sem referência a RF sinalizam scope creep.
+    3. **Cobertura de teste** — cada RF com comportamento user-facing (UI, endpoint de API, mutação de dado) tem ≥1 task que adiciona teste (subtask contendo "test", "spec", "e2e" ou equivalente).
+    4. **Grafo de dependências** — dependências entre tasks (X.0 → Y.0 declarado como "Depende de") formam DAG. Sem ciclos. Ordem topológica válida.
+    5. **Alinhamento com constitution** (só se `.dw/constitution.md` existir) — cada task lista `Constitution: respects P-NNN, P-MMM` OU `Constitution: deviates P-NNN — ADR planejado: <slug>` OU `Constitution: n/a — motivo: <one-liner>`. Linha ausente = FAIL.
+
+    Escreva findings em `.dw/spec/prd-[nome-funcionalidade]/tasks-validation.md` com esta estrutura exata:
+
+    ```markdown
+    # Relatório de Validação de Tasks
+
+    Gerado por /dw-create-tasks em YYYY-MM-DD.
+
+    | Dimensão | Status | Findings |
+    |----------|--------|----------|
+    | 1. Cobertura de RF | PASS / FAIL | <lista de RFs órfãs ou "todas RFs cobertas"> |
+    | 2. Grounding de tasks | PASS / FAIL | <lista de tasks sem RF ou "todas tasks referenciam RFs"> |
+    | 3. Cobertura de teste | PASS / FAIL | <RFs sem testes ou "todas RFs user-facing cobertas"> |
+    | 4. Grafo de dependências | PASS / FAIL | <ciclos ou "DAG válido"> |
+    | 5. Alinhamento constitution | PASS / FAIL / N/A | <tasks não-alinhadas ou "todas alinhadas" ou "sem constitution"> |
+
+    ## Findings Detalhados
+
+    <uma seção por dimensão FAIL com fixes concretos; vazio se tudo PASS>
+    ```
+
+    **Comportamento do gate:**
+
+    - **Todas as 5 dimensões PASS (ou N/A)** → apresente tasks ao usuário normalmente e peça aprovação.
+    - **Qualquer dimensão FAIL** → PARE. Mostre a tabela no chat como markdown (NÃO esconda no arquivo de validação; o usuário precisa ver antes de aprovar). Depois pergunte ao usuário:
+      - "(a) Quer que eu conserte as tasks automaticamente?" → regenerar tasks afetadas, re-rodar o check.
+      - "(b) Vai editar tasks.md manualmente?" → aguardar usuário sinalizar conclusão, re-rodar o check.
+      - "(c) Override e seguir mesmo com FAIL?" → exigir mensagem de override explícita ("override: aceito o gap porque <motivo>"). Persistir o override em `tasks-validation.md` para auditabilidade.
+
+    O arquivo `tasks-validation.md` é commitado junto com `tasks.md`. Comandos downstream (`/dw-run-plan`, `/dw-code-review`, `/dw-review-implementation`) podem referenciá-lo.
+
     Após completar a análise e gerar todos os arquivos necessários, apresente os resultados ao usuário e aguarde confirmação para prosseguir com a implementação.
 </system_instructions>

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

@@ -25,7 +25,7 @@
     - `dw-council` (opt-in via `--council`): debate multi-advisor da decisão arquitetural principal com steel-manning. **NÃO invocar por padrão**.
     - `dw-source-grounding` (**SEMPRE**): cada decisão de framework/library segue Detect → Fetch → Implement → Cite. O techspec emite citações inline `[source: <url>, version: X.Y, retrieved: YYYY-MM-DD]` ao lado de cada decisão arquitetural.
     - `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
+    - `dw-ui-discipline`: use quando o TechSpec inclui seções de UI — enforça o hard-gate de 4 checkpoints (brand authorities / surface job / state matrix / scene sentence), os 14 anti-slop patterns e o WCAG 2.2 AA floor ANTES das decisões de design.
     - `security-review`: use quando a feature tocar auth, autorização ou manipulação de dados sensíveis
 
     ## Inteligência do Codebase
@@ -39,6 +39,23 @@
     - Use `.dw/rules/` como contexto, caindo para grep
     - Sugira rodar `/dw-map-codebase` para enriquecer contexto downstream
 
+    ## Constitution Gate
+
+    <critical>ANTES de redigir decisões arquiteturais, cheque `.dw/constitution.md`:
+
+    **Se AUSENTE**: copie `templates/constitution-template.md` (project-local em `.dw/templates/constitution-template.md`, com fallback para scaffold bundled) literalmente para `.dw/constitution.md`. Setar frontmatter `mode: defaults`. Imprimir no chat: "Constituição defaults instalada em `.dw/constitution.md` (severity: info — não bloqueia este techspec). Seguindo." Depois prossiga.
+
+    **Se PRESENTE**: leia. Toda escolha de framework / library / arquitetura no techspec DEVE carregar uma de:
+    - `Respects: P-NNN` — a decisão honra ativamente o(s) princípio(s) nomeado(s).
+    - `Deviates: P-NNN — justification: <slug do ADR ou racional em uma linha>` — a decisão se afasta intencionalmente do princípio.
+
+    **Gate graduado por severity:**
+    - Desvio de princípio `severity: info` → apenas registra, nunca bloqueia.
+    - Desvio de princípio `severity: high` sem ADR linkado (`.dw/spec/<prd>/adrs/adr-NNN.md`) → BLOQUEIA o techspec. Instrua o usuário a revisar a decisão OU criar ADR via `/dw-adr` documentando o trade-off.
+    - Desvio de princípio `severity: critical` → BLOQUEIA o techspec com mesma exigência de ADR, adicionalmente exigindo acknowledgment de reviewer no campo `Approved by` do ADR.
+
+    Sem exceções para `high`/`critical` sem ADR. Se o usuário resistir, aponte para `/dw-adr` — esse é o escape hatch por design.</critical>
+
     ## Fluxograma de Decisão Multi-Projeto
 
     ```dot

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

@@ -31,7 +31,7 @@ Este comando e **distinto** do `/dw-security-check`:
 | `security-review` (`references/supply-chain.md`) | **SEMPRE** ao classificar findings — da o framing OWASP A06 (Vulnerable & Outdated Components) para os trade-offs do brainstorm |
 | `dw-source-grounding` | **SEMPRE** na fase de brainstorm — cada opcao de update por pacote (Conservadora/Balanceada/Ousada) cita o changelog/release notes oficial da versao alvo: `[source: <url>, version: X.Y, retrieved: YYYY-MM-DD]`. Previne "agent recomenda v5 porque parece moderno, mas v5 dropou Node 18". |
 | `dw-council` | Opt-in automatico quando >=3 pacotes caem em tier COMPROMISED — stress-test multi-conselheiro sobre ordem e escopo de remediacao |
-| `webapp-testing` | Opcional — quando o projeto e frontend e a fase de testes escopados precisa de selecao Playwright-aware |
+| `dw-testing-discipline` | Opcional — quando a fase de testes escopados precisa de recipes Playwright pra projetos frontend. Iron Laws + anti-patterns valem pra qualquer teste adicionado durante o audit. |
 
 ## Variaveis de Entrada
 

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

@@ -20,7 +20,7 @@ Quando disponíveis no projeto em `./.agents/skills/`, use estas skills como sup
 
 - `dw-debug-protocol`: **SEMPRE** — todo finding bug-shaped (cenário falhando, não feature ausente) passa pelo six-step triage. A evidência de reteste é o artefato da etapa 6 (verify); o regression test da etapa 5 é o que sustenta o status `Corrigido`.
 - `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 (screenshot em modo UI OU linha JSONL em modo API), o status permanece `Reaberto` ou `Em análise`.
-- `webapp-testing`: (modo UI) suporte para estruturar retestes, capturas e scripts quando complementar ao Playwright MCP
+- `dw-testing-discipline`: (modo UI) consulte `references/playwright-recipes.md` para estruturas de reteste, capturas, scripts. Aplique Iron Laws + flaky discipline ao retestar fixes — quarantine e SLOs da doutrina valem aqui.
 - `vercel-react-best-practices`: (modo UI) 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
 - `api-testing-recipes`: **(modo API — SEMPRE)** fonte da recipe usada no QA. Re-execute o arquivo `.http`/pytest/supertest/etc. original do RF do bug; anexe o resultado do reteste a um log JSONL fresco em `QA/logs/api/BUG-NN-retest.log`
 

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

@@ -55,10 +55,10 @@ Funciona melhor com projeto analisado por `/dw-analyze-project`
 
 Quando disponíveis no projeto em `./.agents/skills/`, use estas skills como apoio operacional, sem substituir este comando como fonte de verdade:
 
-- `webapp-testing`: apoio para estruturar fluxos E2E, retestes locais e coleta de evidências
+- `dw-testing-discipline`: apoio para estruturar fluxos E2E (`references/playwright-recipes.md`), padrões de coleta de evidência, e aplicar Iron Laws + hierarquia de seletores em qualquer teste referenciado pelo doc
 - `remotion-best-practices`: apoio obrigatório quando houver vídeo humano final, legendas, composição, transições, FFmpeg ou Remotion
 - `humanizer`: apoio obrigatório para revisar e naturalizar todas as legendas, captions `.srt`, textos descritivos e qualquer redação voltada a leitura humana antes da entrega final
-- `ui-ux-pro-max`: use quando documentar padrões visuais, escolhas de design system e consistência de estilo UI entre telas
+- `dw-ui-discipline`: use ao documentar padrões visuais — state matrix e scene sentence viram parte da seção de overview de cada tela
 
 ## Ferramentas obrigatórias para browser
 

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

@@ -319,7 +319,7 @@ workspace/
 - Sim, é recomendado para projetos novos. Ele gera as rules em `.dw/rules/` que todos os outros comandos utilizam.
 
 **Q: O `/dw-redesign-ui` funciona com Angular?**
-- Sim. O comando é framework-agnostic. Para React usa react-doctor e `vercel-react-best-practices`; para Angular usa `ng lint` e Angular DevTools. Design visual (`ui-ux-pro-max`) funciona com qualquer framework.
+- Sim. O comando é framework-agnostic. Para React usa react-doctor e `vercel-react-best-practices`; para Angular usa `ng lint` e Angular DevTools. Disciplina de UI (`dw-ui-discipline`) funciona com qualquer framework — enforça o hard-gate, anti-slop catalog e WCAG floor independente do stack.
 
 **Q: Como obtenho inteligência do codebase e execução paralela?**
 - Os dois são nativos do dev-workflow. Rode `/dw-map-codebase` para construir o índice queryable em `.dw/intel/`, depois `/dw-intel "<pergunta>"` para consultá-lo. Para execução paralela, `/dw-run-plan` invoca os agentes bundled de execução de fase (executor + plan-checker) diretamente para dispatcha tasks em waves com commits atômicos por task. Sem dependência externa.

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

@@ -40,9 +40,9 @@ digraph redesign_decision {
 
 Quando disponíveis no projeto em `./.agents/skills/`, use para guiar o redesign:
 
-- `ui-ux-pro-max`: **OBRIGATÓRIO** — use para todas as decisões de design (paleta de cores, tipografia, estilo visual, layout, acessibilidade WCAG)
+- `dw-ui-discipline`: **OBRIGATÓRIO** — roda o hard-gate de 4 checkpoints (brand authorities OU curated defaults; surface job sentence; state matrix completa; scene sentence) ANTES de qualquer proposta. Os 14 anti-slop patterns são checados contra cada direção. O WCAG 2.2 AA floor é não-negociável no step de validate.
 - `vercel-react-best-practices`: use quando o projeto for React/Next.js para padrões de performance e implementação
-- `webapp-testing`: use para capturar screenshots antes/depois e validação visual com Playwright
+- `dw-testing-discipline`: consulte `references/playwright-recipes.md` para captura de screenshots antes/depois e validação visual. Iron Laws + hierarquia de seletores valem pra qualquer teste gerado junto com o redesign.
 - `security-review`: use se o redesign tocar flows de autenticação ou formulários sensíveis
 
 ## Ferramentas de Análise
@@ -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 se `webapp-testing` 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 screenshot usando `dw-testing-discipline`/playwright-recipes se disponível, 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 usando `ui-ux-pro-max` — cada uma com paleta de cores, par tipográfico, estilo de layout e racional. Para CADA direção, descreva explicitamente o layout mobile (<=768px) e o layout desktop (>=1024px), incluindo como os elementos se reorganizam, empilham ou escondem entre breakpoints.
+4. **PROPOR**: apresente 2 a 3 direções de design depois de passar pelo hard-gate de `dw-ui-discipline` (brand authorities ou curated defaults; surface job sentence; state matrix enumerada; scene sentence). 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 (WCAG 2.2 via `ui-ux-pro-max`), rode react-doctor `--diff` se React. Se `webapp-testing` disponível, capture 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. Use `dw-testing-discipline/references/playwright-recipes.md` para capturar screenshots em viewport 375px (mobile) e 1440px (desktop).
 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
@@ -82,8 +82,8 @@ Utilize ferramentas de diagnóstico conforme o framework do projeto:
 
 ### 2. Proposta de Design
 - 2 a 3 direções com racional visual
-- Paleta de cores (via `ui-ux-pro-max`)
-- Par tipográfico (via `ui-ux-pro-max`)
+- Paleta de cores (de brand authority OU `dw-ui-discipline/references/curated-defaults.md`)
+- Par tipográfico (mesma fonte)
 - Padrão de layout
 - Nível de esforço por direção
 

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

@@ -20,9 +20,9 @@ Você é um assistente IA especializado em Quality Assurance. Sua tarefa é vali
 
 Quando disponíveis no projeto em `./.agents/skills/`, use estas skills como apoio operacional sem substituir este comando:
 
-- `webapp-testing`: (modo UI) apoio para estruturar fluxos de teste, retestes, screenshots e logs quando complementar ao Playwright MCP
+- `dw-testing-discipline`: (modo UI) **SEMPRE** — Iron Laws e 25 anti-patterns valem pra todo teste de QA autorado. `references/playwright-recipes.md` pra patterns táticos. `references/three-workflow-patterns.md` pra escolher o modo certo (UI / network / perf). `references/security-boundary.md` pra qualquer fluxo que cruza boundary de auth.
 - `vercel-react-best-practices`: (modo UI) use apenas se o frontend sob teste for React/Next.js e houver indicação de regressão relacionada a renderização, fetching, hidratação ou performance percebida
-- `ui-ux-pro-max`: (modo UI) use quando validar consistência de design, paletas de cores, tipografia, espaçamento e hierarquia visual contra padrões da indústria
+- `dw-ui-discipline`: (modo UI) use ao validar consistência de design — o catálogo anti-slop e o floor de acessibilidade WCAG são checados como parte da evidência de QA
 - `api-testing-recipes`: **(modo API — SEMPRE)** snippets validados para `.http`, pytest+httpx, supertest, WebApplicationFactory, reqwest. Compõe um arquivo de teste por RF em `QA/scripts/api/` e logs JSONL em `QA/logs/api/` segundo seus references
 
 ## Ferramentas de Análise
@@ -149,7 +149,7 @@ Se NENHUMA credencial for encontrada, PARE e pergunte ao usuário antes de conti
 - Verificar se a aplicação está rodando em localhost
 - Usar `browser_navigate` do Playwright MCP para acessar a aplicação
 - Confirmar que a página carregou corretamente com `browser_snapshot`
-- Se sessão persistente, import de auth, inspeção de rede além do MCP ou reprodução browser-first forem necessários, complementar com `webapp-testing`
+- Se sessão persistente, import de auth, inspeção de rede além do MCP ou reprodução browser-first forem necessários, complementar com `dw-testing-discipline/references/playwright-recipes.md`
 
 ### 3. Verificação de Páginas do Menu (Somente modo UI — Obrigatório, Executar ANTES dos testes de RF)
 
@@ -222,7 +222,7 @@ Para cada requisito funcional do PRD:
 8. Marcar como PASSOU ou FALHOU
 9. Salvar o script Playwright do fluxo em `{{PRD_PATH}}/QA/scripts/` com nome padronizado: `RF-XX-[slug].spec.ts` (ou `.js`)
 10. Registrar no relatório quais credenciais (usuário/perfil) foram usadas em cada fluxo sensível a permissões
-11. Quando o fluxo MCP ficar instável ou insuficiente para evidência operacional, complementar com `webapp-testing`, registrando isso explicitamente no relatório
+11. Quando o fluxo MCP ficar instável ou insuficiente para evidência operacional, complementar com `dw-testing-discipline/references/playwright-recipes.md`, registrando isso explicitamente no relatório
 
 <critical>Não basta validar apenas o caminho feliz. Cada requisito deve ser exercitado contra seus estados de borda e suas regressões mais prováveis</critical>
 <critical>Se um requisito não puder ser completamente validado via E2E, o QA deve ser marcado como REJEITADO ou BLOQUEADO, nunca APROVADO</critical>

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

@@ -21,7 +21,7 @@ Quando disponíveis no projeto em `./.agents/skills/`, use estas skills como sup
 | `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 |
+| `dw-testing-discipline` | Task precisa de testes (qualquer layer) — aplica Iron Laws, 7 AI Gates, catálogo de anti-patterns. Use `references/playwright-recipes.md` quando a task tem frontend interativo precisando de validação E2E. |
 
 ## Inteligência do Codebase
 
@@ -93,7 +93,7 @@ Após fornecer o resumo e abordagem, **comece imediatamente** a implementar a ta
 - Seguir padrões estabelecidos do projeto
 - Garantir que todos os requisitos sejam atendidos
 - **Rodar testes**: use o comando de teste do projeto
-- Se houver frontend interativo, valide também o comportamento real com `webapp-testing` quando isso reduzir o risco de regressão invisível nos testes unitários
+- Se houver frontend interativo, valide também o comportamento real usando `dw-testing-discipline/references/playwright-recipes.md` quando isso reduzir o risco de regressão invisível nos testes unitários
 
 **VOCÊ DEVE** iniciar a implementação logo após o processo acima.
 

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

@@ -0,0 +1,111 @@
+---
+schema_version: "1.0"
+generated_by: dev-workflow
+last_updated: YYYY-MM-DD
+mode: defaults | custom
+---
+
+# Constituição do Projeto
+
+> Princípios declarativos que este time escolheu seguir. PRDs, TechSpecs e Code Reviews leem este arquivo como hard gate. Qualquer coisa que viole um princípio com `severity: critical` ou `high` é bloqueada — exceto quando justificada por um ADR explícito.
+
+## Como este arquivo funciona
+
+- **Cada princípio tem um ID (`P-NNN`), severity, regra, `Why` e `Enforcement`.**
+- **Escala de severity:** `info` (apenas reporta, nunca bloqueia) → `high` (bloqueia PR sem ADR) → `critical` (bloqueia PR sem ADR + exige aprovação de reviewer).
+- **Edite à vontade.** Este arquivo é seu para evoluir. Promova princípios de `info` para `high` quando confiar que o projeto cumpre.
+- **Escape via ADR.** Um PR que viola princípio `high`/`critical` é desbloqueado quando um ADR na mesma feature documenta o desvio e o trade-off.
+- **Versão analítica regenerável** a qualquer momento via `/dw-analyze-project` (oferece sintetizar princípios a partir dos padrões observados no código).
+
+---
+
+## Qualidade de Código
+
+**P-001 — Sem `any` / `unknown` em TypeScript sem justificativa** (severity: info)
+**Regra:** Código de produção não pode usar `as any`, `as unknown` ou `// @ts-ignore` sem comentário inline `// @ts-ignore — motivo: <X>` nomeando a restrição.
+**Why:** Escapes silenciosos do tipo vazam bugs de runtime que o type system existia para pegar. Cada escape é um contrato que o type system para de garantir.
+**Enforcement:** `dw-code-review` greppa o diff por `as any`/`@ts-ignore`/`@ts-expect-error` sem comentário-razão correspondente.
+
+**P-002 — Funções devem ser testáveis isoladamente** (severity: info)
+**Regra:** Função que toca rede, filesystem, banco de dados ou system clock deve receber a dependência como parâmetro (ou via factory) em vez de importar diretamente.
+**Why:** Código que constrói suas próprias dependências não pode ser testado sem setup de integração. Testes ficam lentos, são pulados, e bugs vão pra produção.
+**Enforcement:** `dw-code-review` flagueia funções importando `fs`, `axios`, `prisma`, `Date.now`, etc., diretamente em módulos de business logic.
+
+---
+
+## Padrões de Teste
+
+**P-003 — Todo bug fix carrega um regression test** (severity: info)
+**Regra:** Commit com tipo `fix:` deve adicionar ou modificar pelo menos um teste que teria pego o bug antes do fix.
+**Why:** Sem o teste, o bug volta na próxima vez que alguém refatora a área. O fix se deteriora.
+**Enforcement:** `dw-code-review` verifica se commits `fix:` incluem diff em paths `**/*test*` ou `**/*spec*`.
+
+**P-004 — Testes devem ser determinísticos** (severity: info)
+**Regra:** Sem `sleep`-based waits, sem comparações de relógio real, sem chamadas a serviços live em unit tests. Mockar em boundaries.
+**Why:** Testes flaky treinam o time a ignorar falhas. A próxima falha real passa despercebida.
+**Enforcement:** `dw-code-review` greppa testes por `setTimeout`, chamadas reais de fetch/axios, e `Date.now()` sem `vi.useFakeTimers()`/`jest.useFakeTimers()`.
+
+---
+
+## Consistência de UX
+
+**P-005 — Strings user-facing vivem em fonte única** (severity: info)
+**Regra:** Toda copy visível (labels, mensagens de erro, empty states) passa por um módulo centralizado de i18n / strings — não inline em componentes.
+**Why:** Strings inline driftam no tom, quebram esforços de i18n e causam duplicatas da mesma mensagem em variações sutis.
+**Enforcement:** `dw-code-review` flagueia text nodes JSX e mensagens de erro declarados dentro de componentes em vez de importados de `src/strings/`, `src/i18n/`, ou equivalente.
+
+**P-006 — Estados de loading + empty + error são obrigatórios em qualquer UI que busca dados** (severity: info)
+**Regra:** Componente ou página que faz fetch deve renderizar explicitamente loading, empty e error — não só o happy path.
+**Why:** Experiências "só com spinner" e estados de erro silencioso são a #1 fonte de bugs reportados por usuários.
+**Enforcement:** `dw-review-implementation` verifica componentes de data-fetching pelos três estados em JSX ou equivalente.
+
+---
+
+## Performance
+
+**P-007 — Mudanças de performance carregam medição** (severity: info)
+**Regra:** Qualquer commit que afirme melhorar performance deve incluir a métrica, a ferramenta e os números antes/depois no body do commit OU no techspec.
+**Why:** Sem medição, "otimização" de performance é palpite — e geralmente errado (ver `dw-simplification` + `perf-discipline.md`).
+**Enforcement:** `dw-code-review` verifica commits `perf:` por números antes/depois; flagueia se ausente.
+
+**P-008 — Queries N+1 são flagueadas em code review** (severity: info)
+**Regra:** Loops ou operações em lista que disparam chamadas DB/HTTP por item devem batchar (ex: `IN (...)`, `findMany`, DataLoader) ou ser explicitamente justificadas.
+**Why:** Padrões N+1 escalam linearmente com tamanho dos dados e silenciosamente degradam até que a carga de produção revele.
+**Enforcement:** `dw-code-review` e `dw-refactoring-analysis` detectam padrões await-em-loop contra módulos de repository / API client.
+
+---
+
+## Segurança
+
+**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.
+
+**P-010 — Secrets nunca entram no repositório** (severity: info)
+**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.
+
+---
+
+## Princípios Customizados
+
+> Adicione princípios específicos do seu time abaixo. Mesmo formato: `**P-NNN — <nome>** (severity: info|high|critical): <regra>. **Why:** <motivo>. **Enforcement:** <como>.`
+
+<!-- Exemplo:
+**P-100 — Todo cálculo financeiro usa Decimal, nunca Number** (severity: critical)
+**Regra:** Valores monetários devem usar tipos `Decimal` / `BigDecimal` end-to-end. Sem `parseFloat`, sem aritmética com `Number`.
+**Why:** Erros de arredondamento IEEE 754 acumulam centavos perdidos em milhões de transações; ambientes auditados exigem aritmética exata.
+**Enforcement:** `dw-code-review` greppa por `Number(`/`parseFloat(` em qualquer arquivo sob `src/billing/`, `src/payments/`, `src/finance/`.
+-->
+
+---
+
+## Como evoluir este arquivo
+
+1. **Viva em `info` por pelo menos um release-ciclo.** Observe quão frequentemente cada princípio é violado organicamente; o dado te diz se vale promover.
+2. **Promova para `high` quando violações forem raras e o time concordar.** PRs que violarem princípio `high` agora precisam de ADR.
+3. **Promova para `critical` os princípios que protegem usuários / dados / compliance.** Trate-os como load-bearing; o escape via ADR exige aprovação de reviewer, não só opt-out do autor.
+4. **Demote ou remova princípios que não ganharam seu peso.** Constitution é ferramenta, não museu.
+5. **Re-rode `/dw-analyze-project`** quando o codebase mudar substancialmente (nova stack, refactor grande); ele pode propor updates fundamentados em observação fresca.

package/scaffold/skills/dw-council/SKILL.md

@@ -22,7 +22,7 @@ A real embedded subagent workflow — not inline roleplay. Each archetype is dis
 
 - Low-stakes or obviously-reversible decisions (a council is expensive; reserve for meaningful debates)
 - Decisions already covered by an existing ADR
-- When a single specialized skill suffices (e.g., `security-review` for auth concerns, `ui-ux-pro-max` for visual direction)
+- When a single specialized skill suffices (e.g., `security-review` for auth concerns, `dw-ui-discipline` for visual direction)
 
 ## Required Inputs