@brunosps00/dev-workflow 0.11.0 → 0.15.0

package/scaffold/en/commands/dw-code-review.md

@@ -27,6 +27,7 @@ When available in the project under `./.agents/skills/`, use these skills as ana
 - `dw-simplification`: use when the diff touches dense or twisty code — applies Chesterton's Fence (understand WHY before flagging removal), behavior-preserving refactor protocol (test gate before/after), and complexity metrics (cyclomatic, cognitive, depth, fan-out) so that "simplify this" findings are concrete, not vibes-based.
 - `security-review`: use when auth, authorization, external input, upload, SQL, external integration, secrets, SSRF, XSS, or sensitive surfaces are present
 - `vercel-react-best-practices`: use when the diff touches React/Next.js to review rendering, fetching, bundle, hydration, and performance patterns
+- `dw-llm-eval`: **REQUIRED when the diff touches AI/LLM feature code paths** (chat handlers, RAG, classifiers, agents, prompt templates). The PR must include: (1) reference dataset path under `.dw/eval/datasets/<feature>/`, (2) at least 2 oracle rungs covering the feature, lower rungs FIRST (rung 1-3 before rung 4), (3) judge-calibration evidence if rung 4 is used (Spearman ≥0.80 against humans), (4) eval run results on the touched code path. Missing any of these → **REJECTED**.
 
 ## Codebase Intelligence
 

package/scaffold/en/commands/dw-create-tasks.md

@@ -8,6 +8,12 @@
     ## Pipeline Position
     **Predecessor:** `/dw-create-techspec` | **Successor:** `/dw-run-task` or `/dw-run-plan`
 
+    ## Complementary Skills
+
+    When available in the project under `./.agents/skills/`, use these skills as planning support:
+
+    - `dw-llm-eval`: **REQUIRED when the PRD describes an AI / LLM feature** (chat, RAG, summarization, classifier, agent, tool-use, structured extraction). Add a mandatory "Eval Plan" subtask to one of the generated tasks — the subtask defines (a) the reference dataset path, (b) which oracle rungs (1-5) apply, (c) judge-calibration evidence if rung 4 is used, (d) target metrics per rung. Failing to add an eval-plan subtask for an AI feature is caught by the final consistency check.
+
     ## Prerequisites
 
     The feature you will work on is identified by this slug:

package/scaffold/en/commands/dw-create-techspec.md

@@ -25,7 +25,7 @@
     - `dw-council` (opt-in via `--council`): multi-advisor debate on the primary architectural decision with steel-manning. **DO NOT invoke by default**.
     - `dw-source-grounding` (**ALWAYS**): every framework/library decision must follow Detect → Fetch → Implement → Cite. The techspec emits inline citations `[source: <url>, version: X.Y, retrieved: YYYY-MM-DD]` next to each architectural decision.
     - `vercel-react-best-practices`: use when defining frontend architecture for React/Next.js projects
-    - `ui-ux-pro-max`: use when defining design system decisions, color palettes, typography, and UI style for the TechSpec
+    - `dw-ui-discipline`: use when the TechSpec includes UI sections — enforces the 4-checkpoint hard-gate (brand authorities / surface job / state matrix / scene sentence), the 14 anti-slop patterns, and the WCAG 2.2 AA floor BEFORE design decisions land.
     - `security-review`: use when the feature touches auth, authorization, or sensitive data handling
 
     ## Codebase Intelligence

package/scaffold/en/commands/dw-deps-audit.md

@@ -31,7 +31,7 @@ This command is **distinct** from `/dw-security-check`:
 | `security-review` (`references/supply-chain.md`) | **ALWAYS** when classifying findings — gives OWASP A06 (Vulnerable & Outdated Components) framing for the brainstorm trade-offs |
 | `dw-source-grounding` | **ALWAYS** in the brainstorm phase — each per-package update option (Conservative/Balanced/Bold) cites the official changelog/release notes for the target version: `[source: <url>, version: X.Y, retrieved: YYYY-MM-DD]`. Catches "agent recommends v5 because it sounds modern, but v5 dropped Node 18 support" errors. |
 | `dw-council` | Auto opt-in when ≥3 packages land in tier COMPROMISED — multi-advisor stress-test on remediation order and scope |
-| `webapp-testing` | Optional — when the project is frontend and the scoped test phase needs Playwright-aware test selection |
+| `dw-testing-discipline` | Optional — when the scoped test phase needs Playwright recipes for frontend projects. core rules + anti-patterns apply to any test added during the audit. |
 
 ## Input Variables
 

package/scaffold/en/commands/dw-fix-qa.md

@@ -20,7 +20,7 @@ When available in the project under `./.agents/skills/`, use these skills as ope
 
 - `dw-debug-protocol`: **ALWAYS** — every bug-shaped finding (failing scenario, not missing feature) flows through the six-step triage. The retest evidence is the step-6 verification artifact; the regression test added in step 5 is what allows `Fixed` status to stick.
 - `dw-verify`: **ALWAYS** — invoked before marking any bug as `Fixed` or `Closed` in `QA/bugs.md`. Without a VERIFICATION REPORT PASS (test + lint + build) **and** retest evidence (screenshot in UI mode OR JSONL log line in API mode), status stays `Reopened` or `Under review`.
-- `webapp-testing`: (UI mode) support for structuring retests, captures, and scripts when complementary to Playwright MCP
+- `dw-testing-discipline`: (UI mode) consult `references/playwright-recipes.md` for retest structures, captures, scripts. Apply core rules + flaky discipline when retesting bug fixes — quarantine and SLOs from the doctrine apply.
 - `vercel-react-best-practices`: (UI mode) use only if the fix affects React/Next.js frontend and there is risk of rendering, hydration, fetching, or performance regression
 - `api-testing-recipes`: **(API mode — ALWAYS)** source of the recipe used at QA time. Re-execute the original `.http`/pytest/supertest/etc. file for the bug's RF; append the retest result to a fresh JSONL log under `QA/logs/api/BUG-NN-retest.log`
 

package/scaffold/en/commands/dw-functional-doc.md

@@ -55,10 +55,10 @@ Works best with project analyzed by `/dw-analyze-project`
 
 When available in the project under `./.agents/skills/`, use these skills as operational support without replacing this command as source of truth:
 
-- `webapp-testing`: support for structuring E2E flows, local retests, and evidence collection
+- `dw-testing-discipline`: support for structuring E2E flows (`references/playwright-recipes.md`), evidence collection patterns, and applying core rules + selector hierarchy to any test the doc references
 - `remotion-best-practices`: mandatory support when there is a final human video, captions, composition, transitions, FFmpeg, or Remotion
 - `humanizer`: mandatory support for reviewing and naturalizing all captions, `.srt` files, descriptive texts, and any human-facing writing before final delivery
-- `ui-ux-pro-max`: use when documenting visual patterns, design system choices, and UI style consistency across screens
+- `dw-ui-discipline`: use when documenting visual patterns — the state matrix and scene sentence become part of each screen's overview section
 
 ## Mandatory Browser Tools
 

package/scaffold/en/commands/dw-help.md

@@ -185,7 +185,7 @@ Skills in `.agents/skills/` that commands above invoke transparently. You don't
 
 | Skill | Invoked by | Role |
 |-------|------------|------|
-| `dw-verify` | run-task, run-plan, fix-qa, bugfix, code-review, generate-pr, quick | Iron Law: no success claim without a PASS VERIFICATION REPORT |
+| `dw-verify` | run-task, run-plan, fix-qa, bugfix, code-review, generate-pr, quick | core rule: no success claim without a PASS VERIFICATION REPORT |
 | `dw-memory` | run-task, run-plan, autopilot, resume, revert-task | Two-tier workflow memory (shared + task-local) with 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` | Multi-advisor debate (3-5 archetypes) with steel-manning, concession tracking, and dissent-preserving synthesis. Opt-in. |
@@ -380,7 +380,7 @@ Commands work across multiple AI tools, all pointing to the same source `.dw/com
 - For comprehensive multi-source analysis, technology comparisons, state-of-the-art reviews, or any topic requiring cited evidence. Not for simple lookups or debugging.
 
 **Q: Does `/dw-redesign-ui` work with Angular?**
-- Yes. The command is framework-agnostic. For React it uses react-doctor and `vercel-react-best-practices`; for Angular it uses `ng lint` and Angular DevTools. Visual design (`ui-ux-pro-max`) works with any framework.
+- Yes. The command is framework-agnostic. For React it uses react-doctor and `vercel-react-best-practices`; for Angular it uses `ng lint` and Angular DevTools. UI discipline (`dw-ui-discipline`) works with any framework — enforces the hard-gate, anti-slop catalog, and WCAG floor regardless of stack.
 
 **Q: How do I get codebase intelligence and parallel execution?**
 - Both are native to dev-workflow. Run `/dw-map-codebase` to build the queryable index in `.dw/intel/`, then `/dw-intel "<question>"` to query it. For parallel execution, `/dw-run-plan` invokes the bundled phase-execution agents (executor + plan-checker) directly to dispatch tasks in waves with atomic commits per task. No external dependency needed.

package/scaffold/en/commands/dw-redesign-ui.md

@@ -40,9 +40,9 @@ digraph redesign_decision {
 
 When available in the project under `./.agents/skills/`, use these to guide the redesign:
 
-- `ui-ux-pro-max`: **REQUIRED** — use for all design decisions (color palette, typography, visual style, layout, WCAG accessibility)
+- `dw-ui-discipline`: **REQUIRED** — runs the 4-checkpoint hard-gate (brand authorities OR curated defaults; surface job sentence; complete state matrix; scene sentence) BEFORE any design proposal. The 14 anti-slop patterns are checked against each proposed direction. The WCAG 2.2 AA floor is non-negotiable at the validate step.
 - `vercel-react-best-practices`: use when the project is React/Next.js for performance and implementation patterns
-- `webapp-testing`: use to capture before/after screenshots and visual validation with Playwright
+- `dw-testing-discipline`: consult `references/playwright-recipes.md` for before/after screenshot capture and visual validation. core rules + selector hierarchy apply to any tests generated alongside the redesign.
 - `security-review`: use if the redesign touches authentication flows or sensitive forms
 
 ## Analysis Tools
@@ -56,12 +56,12 @@ Use diagnostic tools based on the project's framework:
 ## Required Behavior
 
 1. Identify the target: page, component, or route to be redesigned.
-2. **AUDIT**: read the current implementation, identify the CSS stack (Tailwind, CSS Modules, styled-components, etc.), capture screenshot if `webapp-testing` is available, run react-doctor if React project.
+2. **AUDIT**: read the current implementation, identify the CSS stack (Tailwind, CSS Modules, styled-components, etc.), capture screenshot using `dw-testing-discipline`/playwright-recipes if available, run react-doctor if React project.
 3. Ask 3 to 5 questions about redesign goals: style direction, brand constraints, inspirations, target audience, priority devices.
-4. **PROPOSE**: present 2 to 3 design directions using `ui-ux-pro-max` — each with color palette, typography pairing, layout style, and rationale. For EACH direction, explicitly describe the mobile layout (<=768px) and desktop layout (>=1024px), including how elements reorganize, stack, or hide between breakpoints.
+4. **PROPOSE**: present 2 to 3 design directions after passing the `dw-ui-discipline` hard-gate (brand authorities or curated defaults selected; surface job sentence written; state matrix enumerated; scene sentence written). Each direction lists color palette, typography pairing, layout style, and rationale. Self-check each direction against the 14 anti-slop patterns. For EACH direction, explicitly describe the mobile layout (<=768px) and desktop layout (>=1024px), including how elements reorganize, stack, or hide between breakpoints.
 5. Wait for explicit user approval before implementing.
 6. **IMPLEMENT**: apply the chosen design with a mobile-first approach — implement the mobile layout first, then add media queries/breakpoints for tablet and desktop. Respect the existing stack. Use `vercel-react-best-practices` for React/Next.js. Maintain the project's CSS methodology.
-7. **VALIDATE**: capture after-state in BOTH resolutions (mobile and desktop), compare before/after, verify accessibility (WCAG 2.2 via `ui-ux-pro-max`), run react-doctor `--diff` if React. If `webapp-testing` is available, capture screenshots at 375px viewport (mobile) and 1440px viewport (desktop).
+7. **VALIDATE**: capture after-state in BOTH resolutions (mobile and desktop), compare before/after, verify accessibility against `dw-ui-discipline/references/accessibility-floor.md` (WCAG 2.2 AA — non-negotiable: contrast, focus-visible, keyboard nav, ARIA, no traps), run react-doctor `--diff` if React. Use `dw-testing-discipline/references/playwright-recipes.md` to capture screenshots at 375px viewport (mobile) and 1440px viewport (desktop).
 8. **PERSIST CONTRACT**: if the user approved a direction, generate `design-contract.md` in the PRD directory (`.dw/spec/prd-[name]/design-contract.md`) with: approved direction, color palette, typography pairing, layout rules, accessibility rules, and component rules. This contract will be read by `dw-run-task` and `dw-run-plan` to ensure visual consistency.
 
 ## Codebase Intelligence
@@ -82,8 +82,8 @@ Use diagnostic tools based on the project's framework:
 
 ### 2. Design Proposal
 - 2 to 3 directions with visual rationale
-- Color palette (via `ui-ux-pro-max`)
-- Typography pairing (via `ui-ux-pro-max`)
+- Color palette (from brand authority OR `dw-ui-discipline/references/curated-defaults.md`)
+- Typography pairing (same source)
 - Layout pattern
 - Effort level per direction
 

package/scaffold/en/commands/dw-run-qa.md

@@ -20,10 +20,11 @@ You are an AI assistant specialized in Quality Assurance. Your task is to valida
 
 When available in the project under `./.agents/skills/`, use these skills as operational support without replacing this command:
 
-- `webapp-testing`: (UI mode) support for structuring test flows, retests, screenshots, and logs when complementary to Playwright MCP
+- `dw-testing-discipline`: (UI mode) **ALWAYS** — core rules and 25 anti-patterns apply to every QA test authored. `references/playwright-recipes.md` for tactical patterns. `references/three-workflow-patterns.md` to pick the right verification mode (UI / network / perf). `references/security-boundary.md` for any flow that crosses an auth boundary.
 - `vercel-react-best-practices`: (UI mode) use only if the frontend under test is React/Next.js and there is indication of regression related to rendering, fetching, hydration, or perceived performance
-- `ui-ux-pro-max`: (UI mode) use when validating design consistency, color palettes, typography, spacing, and visual hierarchy against industry standards
+- `dw-ui-discipline`: (UI mode) use when validating design consistency — the anti-slop catalog and WCAG accessibility floor are checked as part of QA evidence
 - `api-testing-recipes`: **(API mode — ALWAYS)** validated snippets for `.http`, pytest+httpx, supertest, WebApplicationFactory, reqwest. Composes per-RF test files in `QA/scripts/api/` and JSONL logs in `QA/logs/api/` per its references
+- `dw-llm-eval`: **(AI mode — when invoked with `--ai`)** runs the reference dataset at `.dw/eval/datasets/<feature>/` against the current implementation. Computes precision@k / faithfulness / outcome accuracy per the feature type. Logs results as JSONL to `QA/logs/ai/<feature>-<date>.jsonl`. Compares against the prior run to detect regression; alerts when any metric drops >10% from baseline.
 
 ## Analysis Tools
 
@@ -149,7 +150,7 @@ If NO credentials are found, STOP and ask the user before continuing. Do NOT gue
 - Verify the application is running on localhost
 - Use `browser_navigate` from Playwright MCP to access the application
 - Confirm the page loaded correctly with `browser_snapshot`
-- If persistent session, auth import, or network inspection beyond MCP is needed, complement with `webapp-testing`
+- If persistent session, auth import, or network inspection beyond MCP is needed, complement with `dw-testing-discipline/references/playwright-recipes.md`
 
 ### 3. Menu Page Verification (UI mode only -- Required, Execute BEFORE RF tests)
 
@@ -222,7 +223,7 @@ For each functional requirement from the PRD:
 8. Mark as PASSED or FAILED
 9. Save the Playwright flow script in `{{PRD_PATH}}/QA/scripts/` with standardized name: `RF-XX-[slug].spec.ts` (or `.js`)
 10. Record in the report which credentials (user/profile) were used in each permission-sensitive flow
-11. When the MCP flow becomes unstable or insufficient for operational evidence, complement with `webapp-testing`, recording this explicitly in the report
+11. When the MCP flow becomes unstable or insufficient for operational evidence, complement with `dw-testing-discipline/references/playwright-recipes.md`, recording this explicitly in the report
 
 <critical>It is not enough to validate only the happy path. Each requirement must be exercised against its boundary states and most likely regressions</critical>
 <critical>If a requirement cannot be fully validated via E2E, QA must be marked as REJECTED or BLOCKED, never APPROVED</critical>

package/scaffold/en/commands/dw-run-task.md

@@ -21,7 +21,7 @@ When available in the project at `./.agents/skills/`, use these skills as specia
 | `dw-verify` | **ALWAYS** — invoked before the commit to produce a Verification Report with fresh evidence |
 | `dw-memory` | **ALWAYS** — reads workflow memory at task start and updates it at task end (promotion test) |
 | `vercel-react-best-practices` | Task touches React rendering, hydration, data fetching, bundle, cache, or performance |
-| `webapp-testing` | Task has interactive frontend needing E2E validation in a real browser |
+| `dw-testing-discipline` | Task needs tests (any layer) — applies core rules, 6 agent guardrails, anti-patterns catalog. Use `references/playwright-recipes.md` when the task has interactive frontend needing E2E validation. |
 
 ## Codebase Intelligence
 
@@ -93,7 +93,7 @@ After providing the summary and approach, **begin implementation immediately**:
 - Follow established project patterns
 - Ensure all requirements are met
 - **Run tests**: use the project's test command
-- If there is interactive frontend, also validate real behavior with `webapp-testing` when doing so reduces the risk of invisible regression in unit tests
+- If there is interactive frontend, also validate real behavior using `dw-testing-discipline/references/playwright-recipes.md` when doing so reduces the risk of invisible regression in unit tests
 
 **YOU MUST** start the implementation right after the process above.
 

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

@@ -79,7 +79,7 @@ mode: defaults | custom
 
 **P-009 — Server-side authorization on every state-changing endpoint** (severity: info)
 **Rule:** Any endpoint that creates, updates, or deletes data must verify caller authorization on the server. UI-level gating (hidden buttons, disabled forms) is not security.
-**Why:** Browsers are untrusted (see `webapp-testing/security-boundary.md`). UI gating is convenience; only server checks protect data.
+**Why:** Browsers are untrusted (see `dw-testing-discipline/references/security-boundary.md`). UI gating is convenience; only server checks protect data.
 **Enforcement:** `dw-code-review` and `dw-security-check` require an explicit auth check (decorator, middleware, or in-handler assertion) on POST/PUT/PATCH/DELETE routes.
 
 **P-010 — Secrets never enter the repository** (severity: info)

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-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,8 @@
     - `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, core rules + 6 agent guardrails pra qualquer teste que o fix adicione, flaky-discipline se o bug aparece de forma intermitente.
+    - `dw-incident-response`: use quando o bug tem severidade `critical` E afeta produção E foi detectado por alerta/user-report (ou seja, o bug É um incident, não item de backlog). Dispara o workflow de 5 fases (triage → investigation → resolution → communication → postmortem) com saída estruturada em `.dw/incidents/`. As correções rodam via `/dw-bugfix` durante a fase de resolution.
     - `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 +154,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 +181,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

@@ -27,6 +27,7 @@ Quando disponíveis no projeto em `./.agents/skills/`, use estas skills como apo
 - `dw-simplification`: use quando o diff toca código denso ou tortuoso — aplica Chesterton's Fence (entender POR QUÊ antes de propor remoção), protocolo de refactor preservando comportamento (test gate antes/depois) e métricas de complexidade (ciclomática, cognitiva, depth, fan-out) para que findings de "simplifique isso" sejam concretos, não opinativos.
 - `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
+- `dw-llm-eval`: **OBRIGATÓRIO quando o diff toca código de feature AI/LLM** (handlers de chat, RAG, classifiers, agentes, templates de prompt). O PR deve incluir: (1) caminho do reference dataset em `.dw/eval/datasets/<feature>/`, (2) no mínimo 2 oracle rungs cobrindo a feature, rungs mais baixos PRIMEIRO (rung 1-3 antes de rung 4), (3) evidência de calibração do juiz se rung 4 for usado (Spearman ≥0.80 vs humanos), (4) resultados de eval run no path tocado. Faltando algum → **REPROVADO**.
 
 ## Inteligência do Codebase
 

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

@@ -8,6 +8,12 @@
     ## Posição no Pipeline
     **Antecessor:** `/dw-create-techspec` | **Sucessor:** `/dw-run-task` ou `/dw-run-plan`
 
+    ## Skills Complementares
+
+    Quando disponíveis no projeto em `./.agents/skills/`, use estas skills como apoio de planejamento:
+
+    - `dw-llm-eval`: **OBRIGATÓRIO quando o PRD descreve uma feature AI / LLM** (chat, RAG, summarização, classifier, agente, tool-use, extração estruturada). Adicione uma subtask "Plano de Avaliação" obrigatória em uma das tasks geradas — a subtask define (a) caminho do reference dataset, (b) quais oracle rungs (1-5) se aplicam, (c) evidência de calibração do juiz se rung 4 for usado, (d) métricas-alvo por rung. Não adicionar subtask de eval-plan pra feature AI é pego pelo final consistency check.
+
     ## Pré-requisitos
 
     A funcionalidade em que você trabalhará é identificada por este slug:

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

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. core rules + 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 core rules + 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 core rules + hierarquia de seletores em qualquer teste referenciado pelo doc
 - `remotion-best-practices`: apoio obrigatório quando houver vídeo humano final, legendas, composição, transições, FFmpeg ou Remotion
 - `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

@@ -168,7 +168,7 @@ Skills em `.agents/skills/` que os commands acima invocam transparentemente. Voc
 
 | 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-verify` | run-task, run-plan, fix-qa, bugfix, code-review, generate-pr, quick | core rule: 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. |
@@ -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. core rules + 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,10 +20,11 @@ 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** — core rules 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
+- `dw-llm-eval`: **(modo AI — quando invocado com `--ai`)** roda o reference dataset em `.dw/eval/datasets/<feature>/` contra a implementação atual. Computa precision@k / faithfulness / outcome accuracy conforme tipo da feature. Loga resultados como JSONL em `QA/logs/ai/<feature>-<date>.jsonl`. Compara contra a run anterior pra detectar regressão; alerta quando qualquer métrica cai >10% do baseline.
 
 ## Ferramentas de Análise
 
@@ -149,7 +150,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 +223,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 core rules, 6 agent guardrails, 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

@@ -79,7 +79,7 @@ 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 `webapp-testing/security-boundary.md`). Gating em UI é conveniência; só checks server-side protegem dado.
+**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)

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