@brunosps00/dev-workflow 2.5.0 → 2.7.0

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

@@ -48,14 +48,14 @@ Compute `<target>` ONCE at the start; substitute it wherever you see `<target>`
 
 ## Complementary Skills
 
-When available under `./.agents/skills/`, these are invoked operationally:
+When available under `./.dw/skills/`, these are invoked operationally:
 
 - `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.
 - `api-testing-recipes`: **(API mode — ALWAYS)** — validated snippets for `.http`, pytest+httpx, supertest, WebApplicationFactory, reqwest. Composes per-FR test files in `QA/scripts/api/` and JSONL logs in `QA/logs/api/`.
-- `dw-llm-eval`: **(AI mode — when invoked with `--ai`)** — runs reference dataset against current implementation. Computes precision@k / faithfulness / outcome accuracy. Logs JSONL to `QA/logs/ai/<feature>-<date>.jsonl`. Alerts on >10% metric regression vs prior run.
+- `dw-llm-eval`: **(AI mode — when invoked with `--ai`)** — runs reference dataset against current implementation. Computes precision@k / faithfulness / outcome accuracy. Logs JSONL to `QA/logs/ai/<feature>-<date>.jsonl`. Lists per-case pass → fail flips vs prior run (each is a bug) and alerts on >10% metric regression.
 - `dw-debug-protocol`: **(in `--fix` mode — ALWAYS)** — six-step triage (Reproduce → Localize → Reduce → Fix Root Cause → Guard → Verify End-to-End) for each detected bug. Stop-the-line discipline; root-cause over symptom; regression test in same atomic commit.
 - `vercel-react-best-practices`: (UI mode) when React/Next.js regression risk is suspected.
-- `dw-ui-discipline`: (UI mode) when validating design consistency — anti-slop catalog + WCAG accessibility floor check.
+- `dw-ui-discipline`: (UI mode) when validating design consistency — anti-slop catalog + WCAG accessibility floor check, plus the content-stress pass in `references/content-stress.md`.
 - `dw-chaos-engineering`: **(by name only)** — adversarial pass over a change whose normal tests already pass. Ask for it after QA is green when resilience matters more than coverage; it writes tests only, runs locally, and caps at 3 rounds. Never auto-invoked.
 - `dw-verify`: **(in `--fix` mode — ALWAYS)** — before marking any bug `Fixed` or `Closed`, requires VERIFICATION REPORT PASS (test + lint + build) AND retest evidence (screenshot in UI mode, JSONL log in API mode, eval-run delta in AI mode).
 
@@ -92,7 +92,8 @@ Read the affected module's quality baseline/TechSpec. Reuse valid required-check
    - Negative flows (unauthorized actions, malformed input).
    - Regressions (smoke check on adjacent surfaces).
    - WCAG 2.2 accessibility check per `dw-ui-discipline/references/accessibility-floor.md`.
-4. **Capture evidence**: screenshots at 375px mobile + 1440px desktop, console logs, network HARs.
+   - Content stress per `dw-ui-discipline/references/content-stress.md` for every surface that renders user or API data: map the rendered fields and their limits, build a realistic worst-case fixture (plus empty, one and 1,000+ rows), inject it at the data boundary — the project's own fixtures/mocks, or `page.route()` in the test; never by editing the component — and check it at the real container width, 320px, 200% zoom, and dark mode/RTL when the product supports them. Each break goes to `bugs.md` with the reference's severity mapping (Broken → high, Ugly → medium, Fragile → low). Mobile-platform behaviour (sticky hover, input zoom, safe areas) does not reproduce in emulation: list it in `qa-report.md` as needing a real device instead of marking it passed.
+4. **Capture evidence**: screenshots at 375px mobile + 1440px desktop, console logs, network HARs; for the content-stress pass, screenshots of the worst-case fixture at 320px and at 200% zoom.
 5. **Detect stub/placeholder pages**: any page that looks "TODO" or has obvious dummy content → flag as a bug.
 6. **Write `qa-report.md`**: test plan, execution log, evidence references, bug count by severity.
 7. **Write `bugs.md`**: one entry per bug found, with severity, repro steps, evidence link, status (`Open`).
@@ -117,7 +118,7 @@ Read the affected module's quality baseline/TechSpec. Reuse valid required-check
    - Agent: outcome assertion + trajectory match (per `--ai-mode` parameter or feature config).
    - Classification: exact match accuracy.
 3. Log JSONL to `QA/logs/ai/<feature>-<date>.jsonl`.
-4. Compare to prior run's JSONL — alert on >10% regression in any metric.
+4. Compare to the prior run's JSONL case by case: list every case that flipped pass → fail and file each one as a bug, whatever the averages say. Then alert on >10% regression in any metric. Run the `holdout` split too and report it apart from `dev`.
 5. Append AI-mode section to `qa-report.md`.
 
 ## Mode 1.5: Interactive UAT (`/dw-qa --uat`)

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

@@ -38,7 +38,7 @@ digraph redesign_decision {
 
 ## Complementary Skills
 
-When available in the project under `./.agents/skills/`, use these to guide the redesign:
+When available in the project under `./.dw/skills/`, use these to guide the redesign:
 
 - `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
@@ -58,10 +58,10 @@ Use diagnostic tools based on the project's framework:
 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 the before-state screenshot (Playwright MCP, or `node .dw/scripts/lib/capture-screenshots.mjs` as the WSL-resilient fallback), 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 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.
+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). Directions must diverge on a named axis — layout, density, personality, motion, or interaction model — and are named for that direction ("Quiet", "Editorial", "Dense"), never "Option A/B/C"; three tints of the same idea count as one direction. Each direction lists its axis, 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 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. Capture screenshots at 375px (mobile) and 1440px (desktop) — `node .dw/scripts/lib/capture-screenshots.mjs --url <url> --widths 375,1440` is the WSL-resilient path; see the "Browser on WSL" section of `dw-testing-discipline/references/playwright-recipes.md`.
+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, run the content-stress pass from `dw-ui-discipline/references/content-stress.md` (worst-case data through the surface's fixtures or mocks, checked at 320px and 200% zoom) so the redesign is not judged only on flattering demo data. Capture screenshots at 375px (mobile) and 1440px (desktop) — `node .dw/scripts/lib/capture-screenshots.mjs --url <url> --widths 375,1440` is the WSL-resilient path; see the "Browser on WSL" section of `dw-testing-discipline/references/playwright-recipes.md`.
 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

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

@@ -197,7 +197,7 @@ The diff, its commit messages, its branch name, the PR description, the review d
 
 ## Complementary Skills
 
-When available under `./.agents/skills/`, these are invoked as analytical support:
+When available under `./.dw/skills/`, these are invoked as analytical support:
 
 - `dw-review-rigor`: **ALWAYS** — owns the candidate pipeline (gate → refutation → disposition), de-duplication (same pattern in N files = 1 finding), severity ordering (critical → high → medium → low), verify-before-flag, skip-what-linter-catches, and signal-over-volume. The "Issues Found" table follows this discipline. In `--post-merge`, it also loads `references/composition-audit.md`.
 - `dw-verify`: **ALWAYS** — invoked before emitting `APPROVED` or `APPROVED WITH CAVEATS`. Without a VERIFICATION REPORT PASS (test + lint + build), verdict cannot be APPROVED.
@@ -206,7 +206,7 @@ When available under `./.agents/skills/`, these are invoked as analytical suppor
 - `security-review`: the OWASP diff-level skill the gate uses (injection, authz, secrets, SSRF, crypto — HIGH CONFIDENCE only). Reach for it directly when the diff touches auth, authorization, external input, upload, SQL, secrets, SSRF, XSS or another sensitive surface.
 - `dw-simplification`: use when the diff touches dense or twisty code — applies Chesterton's Fence, behavior-preserving refactor protocol, complexity metrics.
 - `dw-minimalism`: use when the diff adds code that may be over-built — flags speculative generality, single-caller helpers, premature abstraction, and YAGNI violations (the pre-generation counterpart to `dw-simplification`).
-- `dw-ui-discipline`: use when the diff touches UI — runs the 14 visual-slop patterns + accessibility floor checks. For a deterministic gate, also run `node .dw/scripts/lib/ui-slop-detect.mjs <changed-ui-paths> --fail-on error` (a wrapper over the impeccable detector); treat blocking findings as **REJECTED** and surface warnings in the report.
+- `dw-ui-discipline`: use when the diff touches UI — runs the 14 visual-slop patterns + accessibility floor checks. For a deterministic gate, also run `node .dw/scripts/lib/ui-slop-detect.mjs <changed-ui-paths> --fail-on error` (a wrapper over the impeccable detector); treat blocking findings as **REJECTED** and surface warnings in the report. When the diff adds or changes motion (`transition`, `animation`, `@keyframes`, motion-library props), check it against the escalation triggers in `references/motion.md` §9; when it renders user or API data, check the static signals in `references/content-stress.md`. Both produce candidates for `dw-review-rigor`, at the severities those references set.
 - `dw-testing-discipline`: use when the diff touches tests — applies the 25 anti-patterns catalog + 6 agent guardrails (when tests were agent-authored).
 - `dw-llm-eval`: **REQUIRED when the diff touches AI/LLM feature code paths**. Reference dataset + ≥2 oracle rungs + judge calibration (if rung 4 used) + eval run results MUST be in the PR. Missing → REJECTED.
 - `vercel-react-best-practices`: use when the diff touches React/Next.js.

package/scaffold/en/commands/dw-skill-health.md

@@ -7,7 +7,7 @@ You are the dev-workflow skill and agent health auditor.
 - Use before promoting a learned pattern into a reusable skill.
 
 ## Process
-1. Read `scaffold/skill-registry.json` when auditing the dev-workflow repo, or `.dw/skill-registry.json` + installed `.agents/skills/` in consumer projects.
+1. Read `scaffold/skill-registry.json` when auditing the dev-workflow repo, or `.dw/skill-registry.json` + the bundled skills installed in `.dw/skills/` in consumer projects. Skills under `.claude/skills/`, `.agents/skills/` and the other agent indexes are command wrappers or the user's own; a dev-workflow skill found there is a legacy copy that `update` removes.
 2. Group skills by `kind`: `protocol`, `domain-pack`, `recipe-pack`, `asset-pack`.
 3. Validate every skill has a trigger, expected output, owner, load policy, and context limit.
 4. Validate every bundled `SKILL.md` has a `## Structured Return` contract with `Status`, `Scope`, `Evidence`, `Artifacts`, `Decisions`, `Risks`, and `Next Step`.
@@ -59,6 +59,28 @@ Declare the window before any judgement: count the instrumented rows — those c
 
 Recommend demotion only when ALL hold: model-invocable cohort; at least 20 instrumented sessions or 30 days of window; zero references; no artifact signal; owner command reachable. Below that, print the counts and say the window is too short to conclude. Removing a bundled skill from the package is an append-only entry in `lib/removed-bundled-skills.js` — this command proposes, it never removes and never deletes files.
 
+### Commands — which entries earn their place in the index
+
+Every installed `dw-*` command is one entry in each agent's skill index, and a crowded index degrades the choice the model makes there. Rows carrying a `commands` object record which commands the session loaded: a read of `.dw/commands/<name>.md` (every wrapper performs one) or a Skill-tool call naming the command. The skill rules apply unchanged: an absent `commands` key is no telemetry, the window is counted only from rows carrying `commands`, and the count measures loading, not success. The hook parses Claude Code transcripts only; when the project also runs Codex, Copilot or OpenCode, say that their sessions are not in the count.
+
+Print one table: command, sessions that loaded it, references. Then, for each family of commands that share a purpose, print the members' counts side by side:
+
+| Family | Members |
+|---|---|
+| Subagent handoff | `dw-subtask-start`, `dw-subtask-complete`, `dw-subtask-resume` |
+| External runners | `dw-codex-run`, `dw-claude-run`, `dw-copilot-run` |
+| Cloud skill installers | `dw-install-aws-skills`, `dw-install-azure-skills` |
+| Install and context audits | `dw-skill-health`, `dw-harness-audit`, `dw-context-budget` |
+| Session checkpoint | `dw-pause`, `dw-resume` |
+
+Classify each family:
+
+- `MERGE CANDIDATE` — the window holds at least 20 instrumented sessions or 30 days, and the whole family was loaded in fewer than 5% of them, or some member was never loaded while another was. One command with modes would cost the index fewer entries.
+- `KEEP SEPARATE` — two or more members were each loaded in at least 5 sessions: the distinct names are in use, and merging them trades a measured habit for a smaller index.
+- `TOO EARLY` — below the window threshold. Print the counts and say so.
+
+Commands outside any family follow the skill wording: a model-invocable command with zero loads over a long enough window is an `IDLE CANDIDATE`, never "unused". A merge or removal in the package is a product decision recorded append-only in `lib/removed-commands.js` (the update then removes the old wrappers); this command proposes, it never renames, removes or edits commands. When auditing the dev-workflow repository itself there is no local telemetry: report `NO TELEMETRY` unless the maintainer supplies `costs.jsonl` files from consumer projects, and aggregate those per project before adding them up.
+
 ## Output
 
 When `.dw/config/routing-defaults.json` exists, compare its current candidates with the owner's `.dw/config/routing.json`. Report relevant differences and validate proposed models/capabilities before adoption. Different values can be intentional; do not treat them as failed migration or overwrite them automatically. Approved task assignments take precedence over either candidate file.
@@ -70,6 +92,7 @@ Include:
 - Registry/schema issues.
 - Structured-return coverage, including any skill missing the contract or status vocabulary.
 - Usage evidence: the declared window, the per-cohort tables, and every idle candidate with its window sentence. When telemetry is missing, say so instead of scoring.
+- Command usage: the per-command table and each family's classification (`MERGE CANDIDATE`, `KEEP SEPARATE`, `TOO EARLY`).
 - Top 3 fixes.
 
 Final marker: `## SKILL-HEALTH COMPLETE`

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

@@ -24,14 +24,15 @@ Before overwriting managed files, create a snapshot:
 ```bash
 SNAPSHOT_DIR=".dw/.backup/$(date -u +%Y%m%dT%H%M%SZ)"
 mkdir -p "$SNAPSHOT_DIR"
-cp -r .dw/commands .dw/templates .dw/references .dw/scripts "$SNAPSHOT_DIR/" 2>/dev/null
+cp -r .dw/commands .dw/templates .dw/references .dw/scripts .dw/skills "$SNAPSHOT_DIR/" 2>/dev/null
 [ -d .agents/skills ] && cp -r .agents/skills "$SNAPSHOT_DIR/agents-skills" 2>/dev/null
 # .claude/settings.json is now mutated by update (MCPs + hooks + statusLine)
 [ -f .claude/settings.json ] && mkdir -p "$SNAPSHOT_DIR/claude" && cp .claude/settings.json "$SNAPSHOT_DIR/claude/settings.json" 2>/dev/null
+[ -f .dw/install-state.json ] && cp .dw/install-state.json "$SNAPSHOT_DIR/install-state.json" 2>/dev/null
 echo "Snapshot saved to $SNAPSHOT_DIR"
 ```
 
-Keep only the 3 most recent snapshots (remove older ones) to avoid buildup.
+Keep only the 3 most recent snapshots in `.dw/.backup/` (remove older ones) to avoid buildup. `.dw/.migrated/` is not a snapshot: never prune it.
 
 ### 1. Record Current Version (Required)
 
@@ -85,7 +86,13 @@ The `update` command overwrites managed files and PRESERVES:
 
 The `update` command also runs the GSD migration step automatically — if a project has legacy `.planning/` (from prior GSD usage), the contents are migrated to `.dw/intel/`, `.dw/spec/active-session.md`, `.dw/spec/quick/`, etc., and `.planning/` is renamed to `.planning.gsd-archive-<DATE>/` for inspection. The `.claude/commands/gsd/`, `.claude/agents/gsd-*.md`, `.claude/hooks/gsd-*.js`, and `.claude/gsd-file-manifest.json` files are removed during the migration.
 
-If the update fails (network error, permission, package unavailable): report the error to the user and STOP. Do NOT attempt manual workarounds like copying files by hand.
+The CLI never deletes what it retires: it moves it to `.dw/.migrated/<timestamp>/`, keeping the relative path, and prints the destination. It does this only after the new skills are in `.dw/skills/`, so an interrupted update leaves the old copies in place. What it retires, and how it decides:
+
+- **Legacy bundled-skill copies** under `.agents/skills/` (`[moved]`): only when the copy is dev-workflow's. A same-named skill that is not is printed as `[kept]` and left alone.
+- **Skills removed in past releases** (`[v<N>]`) and **removed command sources** (`[legacy]`): matched by name, so a same-named skill from elsewhere is moved too — the move is what makes that recoverable.
+- **Orphan `dw-*` wrappers** (`[orphan]`): `dw-` is this package's namespace; a user skill named `dw-*` is moved, not lost.
+
+If the update fails (network error, permission, package unavailable): report the error to the user and STOP. Do NOT attempt manual workarounds like copying files by hand. Give the user the snapshot path from step 0 and the two ways out: re-run the update once the cause is fixed (it is idempotent), or `/dw-update --rollback`.
 
 ### 4. Capture New Version
 
@@ -95,7 +102,7 @@ node -e 'const s = JSON.parse(require("node:fs").readFileSync(".dw/install-state
 
 ### Upgrade compatibility checks
 
-Read the refreshed `.dw/commands/dw-update.md` after the CLI completes. Use `.dw/install-state.json` and the CLI's `Installed version` output for the version delta: an `npx` package need not be resolvable from the consumer's `node_modules`. A missing or invalid new install state is a failed verification; do not claim the update succeeded.
+Read the refreshed `.dw/commands/dw-update.md` after the CLI completes. Use `.dw/install-state.json` and the CLI's `Installed version` output for the version delta: an `npx` package need not be resolvable from the consumer's `node_modules`. A missing or invalid new install state is a failed verification; do not claim the update succeeded. The version read in step 4 must equal the right-hand side of the CLI's `Installed version: <old> -> <new>` line; if that line is missing, or the versions differ, the CLI did not finish and the update failed.
 
 For an upgrade from before 2.3.0 (or an unknown legacy version):
 
@@ -115,6 +122,7 @@ Present to the user:
 - Summary of what the `update` output showed (files copied, wrappers generated, MCPs configured)
 - The `Post-update agent actions` printed by the CLI
 - Any warnings or errors
+- Every `[moved]`, `[v<N>]`, `[orphan]`, `[legacy]` or `[kept]` line from `Skill migration`, the `.dw/.migrated/<timestamp>/` path, and any file flagged `was not installed by dev-workflow` (the team's own addition: offer to bring it back into a skill of their own, never into `.dw/skills/`, which update overwrites)
 
 ### 6. Run Post-Update Agent Actions (Required)
 
@@ -143,19 +151,28 @@ If invoked with `--rollback`:
 1. List snapshots in `.dw/.backup/`
 2. If none exist: STOP and report "No snapshot available"
 3. If more than one exists: ask the user which to restore (default: most recent)
-4. Confirm with the user: "Restore snapshot `<path>`? This OVERWRITES `.dw/commands/`, `.dw/templates/`, `.dw/references/`, `.dw/scripts/`, `.agents/skills/`, and `.claude/settings.json`. Proceed? [y/N]"
+4. Confirm with the user: "Restore snapshot `<path>`? This REPLACES `.dw/commands/`, `.dw/templates/`, `.dw/references/`, `.dw/scripts/` and `.dw/skills/` with the snapshot's copies (when the snapshot has them), copies the snapshot's `.agents/skills/` back over the current one without removing other entries, and restores `.claude/settings.json` and `.dw/install-state.json`. `.dw/templates/overrides/` is never touched. Proceed? [y/N]"
 5. Only after `y`: copy back
 
 ```bash
-cp -r "$SNAPSHOT_DIR/commands"   .dw/
-cp -r "$SNAPSHOT_DIR/templates"  .dw/
-cp -r "$SNAPSHOT_DIR/references" .dw/ 2>/dev/null
-cp -r "$SNAPSHOT_DIR/scripts"    .dw/ 2>/dev/null
-[ -d "$SNAPSHOT_DIR/agents-skills" ] && cp -r "$SNAPSHOT_DIR/agents-skills" .agents/skills 2>/dev/null
+SNAPSHOT_DIR=".dw/.backup/<chosen-timestamp>"   # the snapshot confirmed in step 4
+[ -d "$SNAPSHOT_DIR" ] || { echo "Snapshot not found: $SNAPSHOT_DIR"; exit 1; }
+# Managed .dw folders are replaced, so files added by the newer release do not linger.
+for d in commands references scripts skills; do
+  [ -d "$SNAPSHOT_DIR/$d" ] && rm -rf ".dw/$d" && cp -r "$SNAPSHOT_DIR/$d" .dw/
+done
+# .dw/templates/overrides/ is the owner's: restore the managed templates around it, never remove it.
+if [ -d "$SNAPSHOT_DIR/templates" ]; then
+  find .dw/templates -mindepth 1 -maxdepth 1 ! -name overrides -exec rm -rf {} +
+  for f in "$SNAPSHOT_DIR/templates"/*; do [ "$(basename "$f")" = overrides ] || cp -r "$f" .dw/templates/; done
+fi
+# .agents/skills is shared with the user's own skills: merge, never replace.
+[ -d "$SNAPSHOT_DIR/agents-skills" ] && mkdir -p .agents/skills && cp -r "$SNAPSHOT_DIR/agents-skills/." .agents/skills/ 2>/dev/null
 [ -f "$SNAPSHOT_DIR/claude/settings.json" ] && cp "$SNAPSHOT_DIR/claude/settings.json" .claude/settings.json 2>/dev/null
+[ -f "$SNAPSHOT_DIR/install-state.json" ] && cp "$SNAPSHOT_DIR/install-state.json" .dw/install-state.json 2>/dev/null
 ```
 
-6. Report: snapshot restored, version likely recovered (read from `.dw/commands/dw-help.md` or metadata if present)
+6. Report: snapshot restored, and the version from the restored `.dw/install-state.json` (or "unknown" when the snapshot predates it). A snapshot taken before 2.7.0 has no `skills/`: `.dw/skills/` then stays as it was, which is harmless (older commands read `.agents/skills/`), and the next update retires the restored `.agents/skills/` copies again.
 
 ## Advanced Options
 

package/scaffold/en/references/invariants.md

@@ -50,8 +50,9 @@ it is the boundary working. An agent that cannot destroy work cannot be talked i
 
 **How this is enforced:** partly by `.dw/scripts/hooks/git-guardrails.mjs`, a `PreToolUse` hook that denies
 these patterns on Bash. The hook is **one implementation, not the source of the rule**, and it has two
-known limits: it only covers Bash under Claude Code, and it **fails open** — a parse error or a runtime
-fault allows the command through. So the rule binds even where the hook does not run.
+known limits: it only covers Bash under Claude Code and Codex (Codex runs it only once the project and the
+hook are trusted), and it **fails open** — a parse error or a runtime fault allows the command through. So
+the rule binds even where the hook does not run.
 
 Two operations are deliberately left out of the hook and live only here: `rebase` and `commit --amend`.
 Both are routine on unpushed work, and a command line cannot tell pushed from unpushed. Denying them would
@@ -80,6 +81,10 @@ This floor is narrow by design. Something genuinely destructive that is not list
 apply the same standard: if the action destroys work with no second copy, rewrites shared history, or moves
 a credential, stop and ask. An extra confirmation costs a message.
 
+The same holds for the skill folders agents share — `.agents/skills/`, `.claude/skills/`, `.codex/skills/`:
+they hold the user's and other tools' skills too. Outside the CLI's own `update`/`uninstall`, list what
+you would remove and ask per entry; move what is approved to `.dw/.migrated/<timestamp>/`, never `rm` it.
+
 ## Attribution
 
 The two-layer model — a floor that project rules may only tighten, never loosen — is adapted from the

package/scaffold/en/templates/project-onepager.md

@@ -80,7 +80,7 @@ services: []
 │   └── api/                      (created by `pnpm dlx @nestjs/cli` or selected scaffold)
 ├── packages/
 │   └── shared/                   (created by /dw-new-project)
-├── docker-compose.dev.yml        (composed from .agents/skills/docker-compose-recipes/)
+├── docker-compose.dev.yml        (composed from .dw/skills/docker-compose-recipes/)
 ├── .env.example                  (consolidated from selected services)
 ├── .gitignore                    (per stack)
 ├── .dockerignore                 (per stack)

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

@@ -27,7 +27,7 @@ Na quebra de tasks, proponha desenvolvimento local ou cruzado e modelo, esforço
 
 Claude pode delegar implementação por `/dw-codex-run`; Codex pode usar `/dw-claude-run`. O parent conduz review, correções e continuidade. Agentes locais herdam o modelo da sessão salvo override aprovado na task. Delegue trabalho independente e delimitado quando melhorar qualidade ou tempo; mantenha trabalho pequeno ou acoplado local. Máximo de 3 workers por fluxo e nunca escritores simultâneos no mesmo worktree.
 
-Leia primeiro arquivos relevantes. Use `.dw/intel/` ou code-explorer quando ajudar em fluxos amplos ou desconhecidos, conferindo o índice contra o código atual. Carregue entrypoints de skills somente para tasks correspondentes e referências somente para o modo escolhido. Subagentes recebem um pacote compacto e retornam evidências e decisões, não logs completos.
+Leia primeiro arquivos relevantes. Use `.dw/intel/` ou code-explorer quando ajudar em fluxos amplos ou desconhecidos, conferindo o índice contra o código atual. Carregue entrypoints de skills somente para tasks correspondentes e referências somente para o modo escolhido. As skills do dev-workflow ficam em `.dw/skills/<nome>/`; quando um comando nomear uma, leia de lá. `.agents/skills/` e `.claude/skills/` também guardam skills do usuário e de outras ferramentas: fora do `update`, não apague nada ali sem listar e perguntar antes. Subagentes recebem um pacote compacto e retornam evidências e decisões, não logs completos.
 
 ## Conclusão e limites
 

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

@@ -61,7 +61,7 @@ digraph brainstorm_decision {
 
 ## Skills Complementares
 
-Quando disponíveis no projeto em `./.agents/skills/`, use para enriquecer a ideação:
+Quando disponíveis no projeto em `./.dw/skills/`, use para enriquecer a ideação:
 
 - `dw-council`: invocada pelo modo **council** do dispatcher — stress-test multi-advisor das opções mais promissoras com steel-manning obrigatório e concession tracking. O dispatcher dispara quando 2+ caminhos empatam OU consenso se forma rápido demais (sinal de false-consensus). Não roda em todo brainstorm — só quando os sinais justificam.
 - `dw-simplification`: invocada pelo modo **refactor-audit** — aplica Chesterton's Fence + métricas de complexidade + a nova referência **deep-modules** (deletion test, locality, leverage, interface depth) em todo smell flagueado.
@@ -345,7 +345,7 @@ entre turns e escreve arquivos. Por ser stateful e mutante, começa **só com in
 
 <critical>Pergunte exatamente UMA decisão não-resolvida por interação, e espere. Nunca despeje uma lista de perguntas.</critical>
 
-Grill é movido por duas skills internas (lidas por path em `./.agents/skills/`, nunca exportadas):
+Grill é movido por duas skills internas (lidas por path em `./.dw/skills/`, nunca exportadas):
 - **`dw-grilling`** — o motor de entrevista em árvore de decisão (ordenação por dependência, uma decisão por
   turn, uma resposta recomendada para cada pergunta, fatos descobertos em vez de perguntados, o gate de
   shared-understanding).

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

@@ -36,7 +36,7 @@
 
     ## Skills Complementares
 
-    Quando disponíveis no projeto em `./.agents/skills/`, use estas skills como suporte contextual sem substituir este comando:
+    Quando disponíveis no projeto em `./.dw/skills/`, use estas skills como suporte contextual sem substituir este comando:
 
     - `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. Para bugs não triviais, ou depois que a primeira tentativa de fix falhar, o Passo 1 precisa estabelecer um loop de feedback red-capable antes de teorizar. 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).

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

@@ -11,7 +11,7 @@
 
     ## Skills Complementares
 
-    Quando disponíveis no projeto em `./.agents/skills/`, use estas skills como suporte operacional sem substituir este comando:
+    Quando disponíveis no projeto em `./.dw/skills/`, use estas skills como suporte operacional sem substituir este comando:
 
     - `dw-git-discipline`: **SEMPRE** — aplica atomic commits (uma intenção lógica por commit; refactor separado de feature), formato Conventional Commits, lint+tests+build verdes ANTES do commit e proíbe pular hooks (`--no-verify`) ou amend de commits já empurrados. Em mudanças mistas, separa via `git add -p`.
 

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

@@ -44,7 +44,7 @@ Este comando e **complementar** ao `/dw-new-project`:
 - Relatório: `.dw/audit/dockerize-<YYYY-MM-DD>.md` (escopo PRD: `.dw/spec/prd-<slug>/dockerize.md`)
 - Artefatos dev gerados: `<SCOPE>/docker-compose.dev.yml`, `<SCOPE>/Dockerfile.dev`, `<SCOPE>/.dockerignore`
 - Artefatos prod gerados: `<SCOPE>/Dockerfile`, `<SCOPE>/docker-compose.prod.yml` (opcional), `<SCOPE>/.dockerignore`
-- Fonte das receitas: `.agents/skills/docker-compose-recipes/services/*.yml`
+- Fonte das receitas: `.dw/skills/docker-compose-recipes/services/*.yml`
 
 ## Comportamento Obrigatório — Pipeline
 
@@ -163,7 +163,7 @@ Sem aprovação: escreve relatório (Fase 3 com `status: PLANNED`) e para.
 #### 2.1 Artefatos `--dev`
 
 **`docker-compose.dev.yml`**:
-- Componha blocos de `.agents/skills/docker-compose-recipes/services/*.yml` segundo `references/compose-composition.md`.
+- Componha blocos de `.dw/skills/docker-compose-recipes/services/*.yml` segundo `references/compose-composition.md`.
 - Adicione service(s) do app no fim: `build: { context: ., dockerfile: Dockerfile.dev }`, `volumes` para hot reload (bind mount do source, anonymous volume para `node_modules`/`__pycache__`), `env_file: .env`, `depends_on` com `condition: service_healthy` segundo `references/healthcheck-patterns.md`.
 - Preserve a tag da imagem de cada recipe (NÃO converta nenhuma para digest — digest congela a base e nunca alcanca um rebuild de segurança), as vars de credencial obrigatórias e os binds em `127.0.0.1`. As portas loopback mantem intencionalmente a topologia `apps no host` funcionando.
 - Header: `# Generated by /dw-dockerize on YYYY-MM-DD`.

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

@@ -53,7 +53,7 @@ Funciona melhor com projeto analisado por `/dw-analyze-project`
 
 ## Skills complementares
 
-Quando disponíveis no projeto em `./.agents/skills/`, use estas skills como apoio operacional, sem substituir este comando como fonte de verdade:
+Quando disponíveis no projeto em `./.dw/skills/`, use estas skills como apoio operacional, sem substituir este comando como fonte de verdade:
 
 - `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

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

@@ -29,7 +29,7 @@ Você é o auditor do harness dev-workflow.
 5. Recomende os 3 principais fixes.
 
 ## Triagem de degradação em runtime (sob demanda)
-O scorecard acima e saúde determinística da **instalação**. Se o problema for o *agente* se comportando mal em runtime (loops, desvio do objetivo, edições alucinadas, raciocínio degradado), o diagnóstico e outro: aponte o usuário para `.agents/skills/dw-debug-protocol/references/agent-degradation.md` (tabela sintoma→causa + recovery ordenado). Apenas informativo — não afeta o scorecard.
+O scorecard acima e saúde determinística da **instalação**. Se o problema for o *agente* se comportando mal em runtime (loops, desvio do objetivo, edições alucinadas, raciocínio degradado), o diagnóstico e outro: aponte o usuário para `.dw/skills/dw-debug-protocol/references/agent-degradation.md` (tabela sintoma→causa + recovery ordenado). Apenas informativo — não afeta o scorecard.
 
 ## Saída
 Retorne um scorecard e não altere arquivos. Para drift de arquivo gerenciado, indique `dev-workflow repair`.

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

@@ -64,7 +64,7 @@ Não recuse responder — devolva a melhor info disponível.
 
 ### 2. Detecção do shape da query
 
-Classifique o `{{QUERY}}` em uma das formas documentadas em `.agents/skills/dw-codebase-intel/references/query-patterns.md`:
+Classifique o `{{QUERY}}` em uma das formas documentadas em `.dw/skills/dw-codebase-intel/references/query-patterns.md`:
 
 - **where-is** — primário: `files.json`, secundário: `apis.json`
 - **what-uses** — primário: `deps.json` (libs) ou `files.json` (símbolos)

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

@@ -23,7 +23,7 @@ Colete sinais apenas do que já está persistido:
 4. **Apresente** os candidatos no chat como lista markdown — id, trigger, action, confidence, evidence. NÃO escreva ainda.
 5. **Pergunte**: "Aprovar quais para armazenar? (ids, ou 'todos', ou 'nenhum'). Algum para promover a principio de constitution?"
 6. Na aprovação:
-   - Grave cada instinct aprovado em `.dw/memory/instincts/<slug>.md` no formato de `.agents/skills/dw-memory/references/instincts.md` (crie ou atualize; nunca duplique um id existente).
+   - Grave cada instinct aprovado em `.dw/memory/instincts/<slug>.md` no formato de `.dw/skills/dw-memory/references/instincts.md` (crie ou atualize; nunca duplique um id existente).
    - Para os que o usuário escolher promover, encaminhe ao fluxo de constitution — proponha um principio `P-NNN` em `severity: info` para o Step 8 do `/dw-analyze-project`. NÃO edite `.dw/constitution.md` direto sem o usuário reconfirmar.
 7. Atualize a confiança de instincts existentes que a nova evidência reconfirme ou contradiga.
 

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

@@ -39,7 +39,7 @@ Você é o líder de bootstrap de workspace do dev-workflow. Sua função é peg
 - One-pager do projeto: `.dw/spec/projects/{{PROJECT_NAME}}.md` (usa `.dw/templates/project-onepager.md`)
 - Relatório final: `.dw/spec/projects/{{PROJECT_NAME}}-bootstrap.md`
 - Rules semeadas: `.dw/rules/index.md` (mínimo, depois substituido/enriquecido por `/dw-analyze-project`)
-- Receitas de compose: `.agents/skills/docker-compose-recipes/services/*.yml`
+- Receitas de compose: `.dw/skills/docker-compose-recipes/services/*.yml`
 
 ## Comportamento Obrigatório — Pipeline
 
@@ -157,7 +157,7 @@ Se fullstack:
 
 #### 3.3 Gerar `docker-compose.dev.yml`
 
-1. Leia `.agents/skills/docker-compose-recipes/SKILL.md` e os `services/<nome>.yml` relevantes.
+1. Leia `.dw/skills/docker-compose-recipes/SKILL.md` e os `services/<nome>.yml` relevantes.
 2. Aplique o algoritmo de merge de `references/compose-composition.md`:
    - Concatene blocos sob `services:`.
    - Agregue volumes nomeados sob `volumes:`.
@@ -300,7 +300,7 @@ monorepo: <pnpm-workspaces|turborepo|nx|none>
 | ... | ... | ... |
 
 ## Servicos Compostos
-<tabela de servicos com porta + URL UI + requisitos de credenciais, vinda de .agents/skills/docker-compose-recipes/>
+<tabela de servicos com porta + URL UI + requisitos de credenciais, vinda de .dw/skills/docker-compose-recipes/>
 
 ## Proximos Passos
 1. `cp .env.example .env`, gere secrets locais unicos e defina todo valor obrigatorio como `POSTGRES_PASSWORD`.

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

@@ -30,7 +30,7 @@ Você é um orquestrador de planejamento que conduz uma ideia pelo pipeline comp
 
 ## Skills Complementares
 
-Quando disponíveis em `./.agents/skills/`, use como suporte:
+Quando disponíveis em `./.dw/skills/`, use como suporte:
 
 - `dw-source-grounding`: **SEMPRE** no estágio TechSpec — toda decisão de framework/library cita docs oficiais com versão + data.
 - `dw-ui-discipline`: **OBRIGATÓRIO** quando PRD tem superfícies de UI — roda as 4 grounding questions antes do design visual entrar no TechSpec.
@@ -169,7 +169,7 @@ Roda em modo padrão (após aprovação do TechSpec) OU `plan tasks`.
 3. **Cobertura end-to-end:** todo fluxo user-facing tem subtasks backend + frontend + UI funcional quando aplicável.
 4. **Test placement (`dw-testing-discipline`):** toda subtask que adiciona teste nomeia seu invariant per placement doctrine. Owning layer especificado.
 5. **Constitution alignment:** toda task lista `Constitution: respects P-NNN` ou `Constitution: deviates P-NNN — ADR planejado: <slug>` ou `Constitution: n/a — motivo: <one-liner>`.
-6. **Subtask LLM-eval (quando aplicável):** se PRD tem feature AI, uma task deve incluir Eval Plan subtask (reference dataset path, oracle rungs, judge calibration, target metrics).
+6. **Subtask LLM-eval (quando aplicável):** se PRD tem feature AI, uma task deve incluir Eval Plan subtask (reference dataset path, oracle rungs, judge calibration, target metrics), ordenada antes das subtasks de implementação: spec do comportamento (quando / faz / não deve / continua funcionando), casos, e uma run baseline no código atual em que os casos do comportamento novo falham.
 7. **Declaração de dependência:** cada task lista explicitamente de quais tasks anteriores depende. Escreva o campo como `Depends on: none` ou `Depends on: 1.0, 2.0` em `tasks.md` e em cada `<N>_task.md`. Validação rejeita ciclos.
 8. **Outputs:**
    - Summary: `.dw/spec/prd-<feature-slug>/tasks.md`

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

@@ -48,14 +48,14 @@ Compute `<target>` UMA VEZ no início; substitua onde aparecer `<target>` abaixo
 
 ## Skills Complementares
 
-Quando disponíveis em `./.agents/skills/`, invocadas operacionalmente:
+Quando disponíveis em `./.dw/skills/`, invocadas operacionalmente:
 
 - `dw-testing-discipline`: **(modo UI — SEMPRE)** — core rules e 25 anti-patterns valem pra todo teste QA. `references/playwright-recipes.md` pra patterns táticos. `references/three-workflow-patterns.md` pra escolher modo de verificação (UI / network / perf). `references/security-boundary.md` pra fluxos que cruzam auth.
 - `api-testing-recipes`: **(modo API — SEMPRE)** — snippets validados pra `.http`, pytest+httpx, supertest, WebApplicationFactory, reqwest. Compõe per-FR test files em `QA/scripts/api/` e logs JSONL em `QA/logs/api/`.
-- `dw-llm-eval`: **(modo AI — quando invocado com `--ai`)** — roda reference dataset contra implementação atual. Computa precision@k / faithfulness / outcome accuracy. Loga JSONL em `QA/logs/ai/<feature>-<date>.jsonl`. Alerta em regressão >10% vs run anterior.
+- `dw-llm-eval`: **(modo AI — quando invocado com `--ai`)** — roda reference dataset contra implementação atual. Computa precision@k / faithfulness / outcome accuracy. Loga JSONL em `QA/logs/ai/<feature>-<date>.jsonl`. Lista flips pass → fail por caso vs run anterior (cada um é bug) e alerta em regressão >10% de métrica.
 - `dw-debug-protocol`: **(em modo `--fix` — SEMPRE)** — six-step triage (Reproduzir → Localizar → Reduzir → Fix Root Cause → Guardar → Verify End-to-End) pra cada bug detectado. Stop-the-line discipline; root-cause sobre symptom; regression test no mesmo commit atômico.
 - `vercel-react-best-practices`: (modo UI) quando risco de regressão React/Next.js suspeitado.
-- `dw-ui-discipline`: (modo UI) ao validar consistência de design — anti-slop catalog + WCAG accessibility floor.
+- `dw-ui-discipline`: (modo UI) ao validar consistência de design — anti-slop catalog + WCAG accessibility floor, mais o passe de content stress de `references/content-stress.md`.
 - `dw-chaos-engineering`: **(só por nome)** — passagem adversarial sobre uma mudança cujos testes normais já passam. Peça depois do QA verde, quando resiliência importa mais que cobertura; escreve só testes, roda local e tem teto de 3 rodadas. Nunca é invocada sozinha.
 - `dw-verify`: **(em modo `--fix` — SEMPRE)** — antes de marcar bug como `Fixed` ou `Closed`, requer VERIFICATION REPORT PASS (test + lint + build) E evidência de reteste (screenshot em UI, JSONL log em API, eval-run delta em AI).
 
@@ -92,7 +92,8 @@ Leia a baseline de qualidade/TechSpec do módulo afetado. Reutilize evidência v
    - Fluxos negativos (ações não autorizadas, input malformado).
    - Regressions (smoke check em surfaces adjacentes).
    - WCAG 2.2 accessibility per `dw-ui-discipline/references/accessibility-floor.md`.
-4. **Capturar evidência**: screenshots em 375px mobile + 1440px desktop, console logs, network HARs.
+   - Content stress per `dw-ui-discipline/references/content-stress.md` em toda surface que renderiza dado de usuário ou de API: mapear os campos renderizados e seus limites, montar uma fixture de pior caso realista (mais vazio, um item e 1.000+ linhas), injetá-la na fronteira de dados — fixtures/mocks do próprio projeto, ou `page.route()` no teste; nunca editando o componente — e checar na largura real do container, em 320px, com zoom de 200% e em dark mode/RTL quando o produto suporta. Cada quebra vai para `bugs.md` com o mapeamento de severidade da reference (Broken → high, Ugly → medium, Fragile → low). Comportamento de plataforma mobile (hover preso, zoom em input, safe areas) não reproduz em emulação: liste em `qa-report.md` como pendente de aparelho real em vez de marcar como aprovado.
+4. **Capturar evidência**: screenshots em 375px mobile + 1440px desktop, console logs, network HARs; no passe de content stress, screenshots da fixture de pior caso em 320px e com zoom de 200%.
 5. **Detectar páginas stub/placeholder**: qualquer página com "TODO" ou conteúdo dummy óbvio → flagar como bug.
 6. **Escrever `qa-report.md`**: test plan, execution log, refs de evidência, contagem de bugs por severity.
 7. **Escrever `bugs.md`**: uma entrada por bug com severity, repro steps, link de evidência, status (`Open`).
@@ -117,7 +118,7 @@ Leia a baseline de qualidade/TechSpec do módulo afetado. Reutilize evidência v
    - Agent: outcome assertion + trajectory match (per parâmetro `--ai-mode` ou config da feature).
    - Classification: exact match accuracy.
 3. Logar JSONL em `QA/logs/ai/<feature>-<date>.jsonl`.
-4. Comparar com JSONL da run anterior — alertar em regressão >10% em qualquer métrica.
+4. Comparar com o JSONL da run anterior caso a caso: listar todo caso que virou pass → fail e registrar cada um como bug, seja qual for a média. Depois alertar em regressão >10% em qualquer métrica. Rodar também o split `holdout` e reportar separado do `dev`.
 5. Anexar seção modo-AI em `qa-report.md`.
 
 ## Modo 1.5: UAT Interativo (`/dw-qa --uat`)

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

@@ -38,7 +38,7 @@ digraph redesign_decision {
 
 ## Skills Complementares
 
-Quando disponíveis no projeto em `./.agents/skills/`, use para guiar o redesign:
+Quando disponíveis no projeto em `./.dw/skills/`, use para guiar o redesign:
 
 - `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
@@ -58,10 +58,10 @@ Utilize ferramentas de diagnóstico conforme o framework do projeto:
 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 o screenshot do estado-antes (Playwright MCP, ou `node .dw/scripts/lib/capture-screenshots.mjs` como fallback resiliente no WSL), rode react-doctor se projeto React.
 3. Faça 3 a 5 perguntas sobre objetivos do redesign: direção de estilo, constraints de marca, inspirações, público-alvo, dispositivos prioritários.
-4. **PROPOR**: apresente 2 a 3 direções de design depois de passar pelo hard-gate de `dw-ui-discipline` (brand authorities ou curated defaults; surface job sentence; state matrix enumerada; scene sentence). Cada direção lista paleta de cores, par tipográfico, estilo de layout e racional. Self-check de cada direção contra os 14 anti-slop patterns. Para CADA direção, descreva explicitamente o layout mobile (<=768px) e o layout desktop (>=1024px), incluindo como os elementos se reorganizam, empilham ou escondem entre breakpoints.
+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). As direções precisam divergir num eixo nomeado — layout, densidade, personalidade, motion ou modelo de interação — e recebem o nome da direção ("Quiet", "Editorial", "Dense"), nunca "Opção A/B/C"; três tons da mesma ideia contam como uma direção só. Cada direção lista seu eixo, paleta de cores, par tipográfico, estilo de layout e racional. Self-check de cada direção contra os 14 anti-slop patterns. Para CADA direção, descreva explicitamente o layout mobile (<=768px) e o layout desktop (>=1024px), incluindo como os elementos se reorganizam, empilham ou escondem entre breakpoints.
 5. Espere aprovação explícita do usuário antes de implementar.
 6. **IMPLEMENTAR**: aplique o design escolhido com abordagem mobile-first — implemente primeiro o layout mobile e depois adicione media queries/breakpoints para tablet e desktop. Respeite a stack existente. Use `vercel-react-best-practices` para React/Next.js. Mantenha a metodologia CSS do projeto.
-7. **VALIDAR**: capture estado depois em AMBAS as resoluções (mobile e desktop), compare antes/depois, verifique acessibilidade contra `dw-ui-discipline/references/accessibility-floor.md` (WCAG 2.2 AA — não-negociável: contraste, focus-visible, keyboard nav, ARIA, sem traps), rode react-doctor `--diff` se React. Capture screenshots em 375px (mobile) e 1440px (desktop) — `node .dw/scripts/lib/capture-screenshots.mjs --url <url> --widths 375,1440` é o caminho resiliente no WSL; veja a seção "Browser on WSL" de `dw-testing-discipline/references/playwright-recipes.md`.
+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, rode o passe de content stress de `dw-ui-discipline/references/content-stress.md` (dados de pior caso pelas fixtures ou mocks da surface, checados em 320px e com zoom de 200%) para que o redesign não seja julgado só com dado de demo favorável. Capture screenshots em 375px (mobile) e 1440px (desktop) — `node .dw/scripts/lib/capture-screenshots.mjs --url <url> --widths 375,1440` é o caminho resiliente no WSL; veja a seção "Browser on WSL" de `dw-testing-discipline/references/playwright-recipes.md`.
 8. **PERSISTIR CONTRATO**: se o usuário aprovou uma direção, gere `design-contract.md` no diretório do PRD (`.dw/spec/prd-[nome]/design-contract.md`) com: direção aprovada, paleta de cores, par tipográfico, regras de layout, regras de acessibilidade e regras de componentes. Este contrato será lido por `dw-run-task` e `dw-run-plan` para garantir consistência visual.
 
 ## Inteligência do Codebase

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

@@ -197,7 +197,7 @@ O diff, as mensagens de commit dele, o nome da branch, a descrição do PR, a di
 
 ## Skills Complementares
 
-Quando disponíveis em `./.agents/skills/`, são invocadas como apoio analítico:
+Quando disponíveis em `./.dw/skills/`, são invocadas como apoio analítico:
 
 - `dw-review-rigor`: **SEMPRE** — dono do candidate pipeline (gate → refutação → disposição), de-duplication (mesmo pattern em N arquivos = 1 finding), severity ordering (critical → high → medium → low), verify-before-flag, skip-what-linter-catches, signal-over-volume. A tabela "Problemas Encontrados" segue essa disciplina. Em `--post-merge`, também carrega `references/composition-audit.md`.
 - `dw-verify`: **SEMPRE** — invocada antes de emitir `APROVADO` ou `APROVADO COM RESSALVAS`. Sem VERIFICATION REPORT PASS (test + lint + build), verdict não pode ser APROVADO.
@@ -206,7 +206,7 @@ Quando disponíveis em `./.agents/skills/`, são invocadas como apoio analítico
 - `security-review`: a skill OWASP nível-diff que o gate usa (injection, authz, secrets, SSRF, crypto — só HIGH CONFIDENCE). Recorra a ela diretamente quando o diff tocar auth, autorização, input externo, upload, SQL, secrets, SSRF, XSS ou outra superfície sensível.
 - `dw-simplification`: use quando diff toca código denso — aplica Chesterton's Fence, protocolo de refactor preservando comportamento, métricas de complexidade.
 - `dw-minimalism`: use quando o diff adiciona código que pode estar over-built — flagra generalidade especulativa, helpers de um único caller, abstração prematura e violações de YAGNI (a contraparte pré-geração do `dw-simplification`).
-- `dw-ui-discipline`: use quando diff toca UI — roda os 14 visual-slop patterns + accessibility floor. Para um gate determinístico, rode também `node .dw/scripts/lib/ui-slop-detect.mjs <paths-ui-alterados> --fail-on error` (wrapper sobre o detector do impeccable); trate findings bloqueantes como **REJECTED** e reporte os warnings.
+- `dw-ui-discipline`: use quando diff toca UI — roda os 14 visual-slop patterns + accessibility floor. Para um gate determinístico, rode também `node .dw/scripts/lib/ui-slop-detect.mjs <paths-ui-alterados> --fail-on error` (wrapper sobre o detector do impeccable); trate findings bloqueantes como **REJECTED** e reporte os warnings. Quando o diff adiciona ou muda motion (`transition`, `animation`, `@keyframes`, props de biblioteca de animação), cheque contra os gatilhos de escalonamento de `references/motion.md` §9; quando renderiza dado de usuário ou de API, cheque os sinais estáticos de `references/content-stress.md`. Ambos geram candidatos para o `dw-review-rigor`, nas severidades que essas references definem.
 - `dw-testing-discipline`: use quando diff toca testes — aplica catálogo de 25 anti-patterns + 6 agent guardrails (quando testes foram agent-authored).
 - `dw-llm-eval`: **OBRIGATÓRIO quando diff toca código de feature AI/LLM**. Reference dataset + ≥2 oracle rungs + judge calibration (se rung 4 usado) + eval run results DEVEM estar no PR. Faltando → REPROVADO.
 - `vercel-react-best-practices`: use quando diff toca React/Next.js.

package/scaffold/pt-br/commands/dw-skill-health.md

@@ -7,7 +7,7 @@ Você é o auditor de saúde de skills e agentes do dev-workflow.
 - Use antes de promover um aprendizado para skill reutilizavel.
 
 ## Processo
-1. Leia `scaffold/skill-registry.json` ao auditar o repo dev-workflow, ou `.dw/skill-registry.json` + `.agents/skills/` em projetos consumidores.
+1. Leia `scaffold/skill-registry.json` ao auditar o repo dev-workflow, ou `.dw/skill-registry.json` + as skills bundled instaladas em `.dw/skills/` em projetos consumidores. Skills em `.claude/skills/`, `.agents/skills/` e nos demais índices de agente são wrappers de comando ou do próprio usuário; uma skill do dev-workflow encontrada lá é cópia legada que o `update` remove.
 2. Agrupe skills por `kind`: `protocol`, `domain-pack`, `recipe-pack`, `asset-pack`.
 3. Valide que toda skill tem trigger, output esperado, owner, load policy e limite de contexto.
 4. Valide que todo `SKILL.md` bundled tem contrato `## Structured Return` com `Status`, `Scope`, `Evidence`, `Artifacts`, `Decisions`, `Risks` e `Next Step`.
@@ -59,6 +59,28 @@ Declare a janela antes de qualquer julgamento: conte as linhas instrumentadas
 
 Recomende rebaixar só quando TUDO valer: coorte invocável por modelo; ao menos 20 sessões instrumentadas ou 30 dias de janela; zero referências; sem sinal de artefato; comando owner alcançável. Abaixo disso, mostre as contagens e diga que a janela é curta demais para concluir. Remover skill bundled do pacote é entrada append-only em `lib/removed-bundled-skills.js` — este comando propõe, nunca remove e nunca deleta arquivo.
 
+### Comandos — quais entradas merecem lugar no índice
+
+Todo comando `dw-*` instalado é uma entrada no índice de skills de cada agente, e índice lotado piora a escolha que o modelo faz ali. Linhas com o objeto `commands` registram quais comandos a sessão carregou: uma leitura de `.dw/commands/<nome>.md` (todo wrapper faz uma) ou uma chamada da ferramenta Skill nomeando o comando. As regras das skills valem sem mudança: chave `commands` ausente é falta de telemetria, a janela é contada só pelas linhas que trazem `commands`, e a contagem mede carregamento, não sucesso. O hook lê só transcripts do Claude Code; quando o projeto também roda Codex, Copilot ou OpenCode, diga que essas sessões não entram na conta.
+
+Mostre uma tabela: comando, sessões que o carregaram, referências. Depois, para cada família de comandos com o mesmo propósito, mostre as contagens dos membros lado a lado:
+
+| Família | Membros |
+|---|---|
+| Handoff de subagente | `dw-subtask-start`, `dw-subtask-complete`, `dw-subtask-resume` |
+| Runners externos | `dw-codex-run`, `dw-claude-run`, `dw-copilot-run` |
+| Instaladores de skills de nuvem | `dw-install-aws-skills`, `dw-install-azure-skills` |
+| Auditorias de instalação e contexto | `dw-skill-health`, `dw-harness-audit`, `dw-context-budget` |
+| Checkpoint de sessão | `dw-pause`, `dw-resume` |
+
+Classifique cada família:
+
+- `CANDIDATA A FUSÃO` — a janela tem ao menos 20 sessões instrumentadas ou 30 dias, e a família inteira foi carregada em menos de 5% delas, ou algum membro nunca foi carregado enquanto outro foi. Um comando com modos custaria menos entradas no índice.
+- `MANTER SEPARADOS` — dois ou mais membros foram carregados, cada um, em ao menos 5 sessões: os nomes distintos estão em uso, e fundir troca um hábito medido por um índice menor.
+- `CEDO DEMAIS` — abaixo do limiar da janela. Mostre as contagens e diga isso.
+
+Comandos fora de família seguem a redação das skills: comando invocável por modelo com zero carregamentos numa janela longa o bastante é `CANDIDATO A OCIOSO`, nunca "não usado". Fusão ou remoção no pacote é decisão de produto registrada append-only em `lib/removed-commands.js` (o update então remove os wrappers antigos); este comando propõe, nunca renomeia, remove ou edita comandos. Ao auditar o próprio repositório dev-workflow não há telemetria local: reporte `SEM TELEMETRIA`, a menos que o mantenedor forneça os `costs.jsonl` de projetos consumidores, e agregue esses por projeto antes de somar.
+
 ## Saída
 
 Quando `.dw/config/routing-defaults.json` existir, compare seus candidatos atuais com o `.dw/config/routing.json` do proprietário. Relate diferenças relevantes e valide modelos/capacidades propostos antes da adoção. Valores diferentes podem ser intencionais; não os trate como falha de migração nem sobrescreva automaticamente. Atribuições de tarefas aprovadas têm precedência sobre ambos os arquivos de candidatos.
@@ -70,6 +92,7 @@ Inclua:
 - Issues de registry/schema.
 - Cobertura de retorno estruturado, incluindo qualquer skill sem contrato ou vocabulario de status.
 - Evidência de uso: a janela declarada, as tabelas por coorte e toda candidata a ociosa com sua frase de janela. Sem telemetria, diga isso em vez de pontuar.
+- Uso de comandos: a tabela por comando e a classificação de cada família (`CANDIDATA A FUSÃO`, `MANTER SEPARADOS`, `CEDO DEMAIS`).
 - Top 3 fixes.
 
 Marcador final: `## SKILL-HEALTH COMPLETE`