@brunosps00/dev-workflow 1.0.5 → 1.1.0

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

@@ -0,0 +1,136 @@
+<system_instructions>
+You are the dev-workflow durable goal orchestrator. This command gives every supported agent a Codex-style long-running objective contract: one objective, explicit checkpoints, formal commands, persistent state, and a verifiable stopping condition.
+
+## When to Use
+- Use when a workflow is larger than one normal turn but has a clear finish line.
+- Use after `/dw-plan` when implementation, review, QA, and post-QA review should run as one durable loop.
+- Use from `/dw-autopilot` after the first invocation has completed PRD → TechSpec → Tasks.
+- Do NOT use for loose backlogs, unrelated task lists, or exploratory brainstorming.
+
+## Position in Pipeline
+**Predecessor:** `/dw-plan` or `/dw-autopilot` plan phase | **Successor:** `/dw-commit` + `/dw-generate-pr`
+
+## Modes
+
+| Invocation | Behavior |
+|------------|----------|
+| `/dw-goal "<objective>"` | Create and execute a manual durable goal. |
+| `/dw-goal --from-autopilot <prd-slug>` | Create and execute the standard autopilot execution-quality goal for an existing PRD. |
+| `/dw-goal status` | Show the active goal, checkpoint, last verification, and blockers. |
+| `/dw-goal pause` | Mark the active goal paused without deleting state. |
+| `/dw-goal resume` | Resume the paused or interrupted goal from `status.json`. |
+| `/dw-goal clear` | Clear the active goal only after it is complete, cancelled, or explicitly replaced. |
+
+## Native Codex Bridge
+
+<critical>`/dw-goal` is portable. The canonical state lives in `.dw/goals/` even when Codex native `/goal` is available.</critical>
+
+Official Codex guidance treats `/goal` as an experimental durable objective for long-running work with a verifiable stopping condition. In Codex CLI it requires `features.goals`; it can be set with `/goal <objective>`, inspected with `/goal`, and controlled with `/goal pause`, `/goal resume`, or `/goal clear`.
+
+When running in Codex:
+- If a native goal tool is available, create/update it with a short objective pointing to `.dw/goals/<slug>/goal.md`.
+- If the interactive `/goal` slash command is available and `features.goals` is enabled, use `/goal <objective>` with an objective under 4,000 characters.
+- If native goals are unavailable, continue with the portable `.dw/goals/` loop. Do not block.
+
+Native Codex objective format:
+
+```text
+Execute the durable goal defined in .dw/goals/<goal-slug>/goal.md until its verifiable stopping condition is met. Update .dw/goals/<goal-slug>/progress.md after every checkpoint.
+```
+
+## Persistent State
+
+Create `.dw/goals/<goal-slug>/` with:
+
+```
+.dw/goals/<goal-slug>/
+├── goal.md
+├── status.json
+└── progress.md
+```
+
+`goal.md` MUST include:
+- One objective.
+- In scope / out of scope.
+- Input artifacts to read first.
+- Checkpoints in order.
+- Formal `/dw-*` commands to invoke.
+- Required artifacts per checkpoint.
+- Verifiable stopping condition.
+- Block conditions.
+- Resume policy.
+
+`status.json` MUST use this shape:
+
+```json
+{
+  "schema_version": "1.0",
+  "slug": "goal-prd-example",
+  "source": "manual",
+  "prd_path": null,
+  "status": "active",
+  "current_checkpoint": "start",
+  "completed_checkpoints": [],
+  "required_artifacts": [],
+  "last_verification": null,
+  "created_at": "2026-05-20T00:00:00Z",
+  "updated_at": "2026-05-20T00:00:00Z"
+}
+```
+
+`progress.md` is append-only. Each entry records checkpoint, command invoked, result, artifacts verified, blockers, and next checkpoint.
+
+## Autopilot Goal
+
+When invoked as `/dw-goal --from-autopilot <prd-slug>`:
+
+1. Resolve `<prd-slug>` to `.dw/spec/<prd-slug>/`.
+2. Verify `prd.md`, `techspec.md`, `tasks.md`, per-task files, and `tasks-validation.md` exist.
+3. Create goal slug `autopilot-<prd-slug>`.
+4. Write `goal.md` with this objective:
+
+```text
+Complete implementation and quality validation for .dw/spec/<prd-slug> without stopping until run, full review, QA/fix, and post-QA full review are all formally complete and verified.
+```
+
+Checkpoints:
+
+| Checkpoint | Formal command | Completion evidence |
+|------------|----------------|---------------------|
+| `run` | `/dw-run <prd-path>` | Tasks done, task commits present, run log or task status updated. |
+| `review-before-qa` | `/dw-review <prd-path>` | `<prd-path>/QA/review-consolidated.md` exists and overall verdict is approved or approved with explicit non-blocking caveats. |
+| `qa` | `/dw-qa <prd-path>` | Required QA artifacts exist. |
+| `qa-fix` | `/dw-qa --fix <prd-path>` when `bugs.md` has Open bugs | Bugs are Fixed/Closed or explicitly deferred by user. |
+| `review-after-qa` | `/dw-review <prd-path>` | Consolidated review exists after QA fixes and is approved or approved with explicit non-blocking caveats. |
+
+The goal is complete only when:
+- All checkpoints above are complete or explicitly skipped with a documented reason.
+- No Open QA bug remains unless the user explicitly accepted deferral.
+- The final `/dw-review` ran after the last QA fix.
+- `status.json` has `"status": "complete"`.
+
+## Execution Rules
+
+<critical>Every checkpoint that invokes a `/dw-*` command MUST invoke the formal command and follow its complete `.dw/commands/` instructions. Manual equivalents do not count.</critical>
+
+- Before each checkpoint, append a `progress.md` entry and update `status.json.current_checkpoint`.
+- After each checkpoint, verify required artifacts with `ls` or equivalent inspection before marking complete.
+- If a command fails, fix according to that command's own loop, then re-run it.
+- If the same blocker repeats for 3 consecutive goal turns and no meaningful progress is possible, mark `status: "blocked"` and surface the blocker.
+- Keep progress updates compact: current checkpoint, verification result, remaining checkpoints, blocker if any.
+
+## Status Commands
+
+- `status`: read `status.json` and last 10 entries of `progress.md`; report current checkpoint, completed checkpoints, last verification, and blockers.
+- `pause`: set `status: "paused"` and append why.
+- `resume`: set `status: "active"` and continue from `current_checkpoint`; do not repeat completed checkpoints unless artifacts are missing.
+- `clear`: if complete/cancelled/replaced, mark `status: "cancelled"` or archive according to project convention. Do not delete evidence by default.
+
+## Anti-patterns
+
+- Do not create a goal with multiple unrelated objectives.
+- Do not use `/dw-goal` to bypass `/dw-plan`; goals execute a defined plan, they do not invent scope.
+- Do not mark a checkpoint complete without checking artifacts.
+- Do not use native Codex `/goal` as the only state; `.dw/goals/` remains the cross-agent contract.
+
+</system_instructions>

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

@@ -19,7 +19,7 @@ Use `/dw-autopilot "wish"` as the gateway for most feature work. The granular co
 
 | Command | When |
 |---------|------|
-| `/dw-autopilot "wish"` | Default entry point. PRD → TechSpec → Tasks → Run → QA → Review → Commit → PR. Three approval gates. |
+| `/dw-autopilot "wish"` | Default entry point in two invocations. First run plans and stops; second run resumes through `/dw-goal`, commit, and PR. |
 | `/dw-bugfix "description"` | A bug or error report. Surgical fix or PRD route. |
 | `/dw-help [keyword]` | This screen. Pass a keyword for shortcuts. `--advanced` reveals internal commands. |
 
@@ -50,15 +50,15 @@ Use `/dw-autopilot "wish"` as the gateway for most feature work. The granular co
 
 ## Workflow at a glance
 
-`/dw-autopilot "wish"` runs the full pipeline (PRD → ... → PR) with 3 gates. Step-by-step:
+`/dw-autopilot "wish"` runs planning first and stops. Reinvoke it to resume through `/dw-goal`, commit, and PR. Step-by-step:
 
 ```
-/dw-brainstorm → /dw-plan → /dw-run → /dw-qa → /dw-review → /dw-commit → /dw-generate-pr
+/dw-brainstorm → /dw-plan → /dw-goal → /dw-commit → /dw-generate-pr
 ```
 
 ## Advanced / internal commands
 
-Pass `--advanced` to `/dw-help` to see internal commands (`dw-adr`, `dw-intel`, `dw-secure-audit`, `dw-find-skills`, `dw-update`, `dw-subtask-start`, `dw-subtask-complete`, `dw-subtask-resume`) that are usually invoked by other commands.
+Pass `--advanced` to `/dw-help` to see internal commands (`dw-adr`, `dw-intel`, `dw-secure-audit`, `dw-goal`, `dw-find-skills`, `dw-update`, `dw-subtask-start`, `dw-subtask-complete`, `dw-subtask-resume`) that are usually invoked by other commands.
 ```
 
 ## Advanced mode — `--advanced` flag
@@ -70,13 +70,14 @@ When invoked with `--advanced`, ALSO show:
 
 These are auto-invoked by primary commands but available standalone.
 
-## Tier 4 — Hidden (8)
+## Tier 4 — Hidden (9)
 
 | Command | What | Invoked by |
 |---------|------|------------|
 | `/dw-adr "decision"` | Record an Architecture Decision Record at `.dw/spec/<prd>/adrs/`. | `/dw-plan techspec --council`, deviations from constitution |
 | `/dw-intel "question"` | Query codebase intelligence; `--build` (re)indexes `.dw/intel/`. | `/dw-plan`, `/dw-review`, `/dw-bugfix` |
 | `/dw-secure-audit` | OWASP + Trivy + lockfile + supply-chain scan. Hard gate. Flags: `--scan-only`, `--plan`, `--execute`. | `/dw-review`, `/dw-generate-pr` |
+| `/dw-goal "<objective>"` | Durable objective contract with `.dw/goals/`; bridges to Codex native `/goal` when available. | `/dw-autopilot` after planning |
 | `/dw-find-skills "query"` | Search npx skills ecosystem, vet, install. | manual when extending the bundle |
 | `/dw-update` | Update dev-workflow to latest npm release with rollback snapshot. | manual maintenance |
 | `/dw-subtask-start "goal"` | Create a minimal input packet for a subagent. | parent agent before delegation |
@@ -93,6 +94,7 @@ Match the keyword and suggest:
 | `prd`, `spec`, `plan`, `architecture`, `techspec`, `tasks` | `/dw-plan` (with appropriate stage flag) |
 | `bug`, `error`, `broken`, `fix` | `/dw-bugfix` |
 | `run`, `execute`, `implement` | `/dw-run` |
+| `goal`, `objective`, `long-running`, `resume autopilot` | `/dw-goal` or `/dw-autopilot` if `autopilot-state.json` exists |
 | `review`, `quality`, `audit code` | `/dw-review` |
 | `qa`, `test plan`, `e2e` | `/dw-qa` |
 | `commit`, `git` | `/dw-commit` |
@@ -121,10 +123,10 @@ If no keyword matches, show the default surface and a note: "Keyword `<word>` no
 ## FAQ
 
 **Q: I'm not sure where to start with a new feature.**
-- Use `/dw-autopilot "what you want"`. It runs PRD → TechSpec → Tasks → Run → Review → PR with three approval gates.
+- Use `/dw-autopilot "what you want"`. First invocation runs PRD → TechSpec → Tasks and stops; second invocation resumes through `/dw-goal`, commit, and PR.
 
 **Q: Do I have to use `/dw-autopilot`?**
-- No. The granular pipeline (`/dw-brainstorm` → `/dw-plan` → `/dw-run` → `/dw-qa` → `/dw-review` → `/dw-commit` → `/dw-generate-pr`) gives you control at each step.
+- No. The granular pipeline (`/dw-brainstorm` → `/dw-plan` → `/dw-goal` or `/dw-run`/`/dw-qa`/`/dw-review` → `/dw-commit` → `/dw-generate-pr`) gives you control at each step.
 
 **Q: I just want to fix a bug.**
 - `/dw-bugfix "<bug description>"`. It triages (bug vs feature vs scope), asks 3 questions, then fixes or routes to a PRD if scope is large.

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

@@ -50,6 +50,12 @@ When project agents are installed, use:
 
 Claude Code and OpenCode can use native project agents. Codex and Copilot use `.agents/agents/` plus these instructions as the fallback dispatch contract.
 
+## Structured Interview Tool
+
+<critical>When a structured interview/user-input tool is available, `/dw-plan` MUST use it for PRD and TechSpec clarification questions. Do not downgrade to plain chat merely for convenience. If no such tool exists in the runtime, ask the same questions in chat and explicitly record: `Structured interview tool unavailable; using chat fallback.`</critical>
+
+The tool is mandatory for planning because it preserves explicit user choices and prevents the agent from answering its own questions. Each stage keeps its own quota: PRD requires 7+ product questions; TechSpec requires 7+ technical questions.
+
 ## Constitution Gate
 
 <critical>BEFORE any stage, check `.dw/constitution.md`. If MISSING, copy `templates/constitution-template.md` to `.dw/constitution.md` (severity=info defaults), notify the user in chat, and continue. If PRESENT, every FR (PRD), every architectural decision (TechSpec), and every task (Tasks) carries Constitution Alignment metadata mapping to relevant principles or declaring deviation.</critical>
@@ -73,7 +79,7 @@ Runs when default mode OR `plan prd`.
 
 ### Required behavior
 
-1. **Clarification questions (MINIMUM 7).** Before writing anything, ask 7+ focused questions covering: goals, target users, scope boundaries, success metrics, rollout strategy, integration points, edge cases.
+1. **Clarification questions (MINIMUM 7).** Before writing anything, use the structured interview tool when available to ask 7+ focused questions covering: goals, target users, scope boundaries, success metrics, rollout strategy, integration points, edge cases. If the tool is unavailable, use chat fallback and record that fallback.
 2. **Web search MINIMUM 3 queries** for market patterns, regulatory context, competitor approaches when relevant.
 3. **Constitution alignment.** Each functional requirement (FR-N.M) includes a `Constitution Alignment: respects P-NNN, P-MMM` line OR `no applicable principle: <reason>`.
 4. **Multi-project awareness.** If the feature spans multiple projects in the workspace, consult `.dw/rules/integrations.md` and document scope in the PRD's "Impacted Projects" section.
@@ -97,7 +103,7 @@ Runs when default mode (after PRD approval) OR `plan techspec` OR `plan --from t
 ### Required behavior
 
 1. **Hard gate: PRD open questions.** If `.dw/spec/prd-<feature>/prd.md` has an "Open Questions" section with unresolved items, STOP and ask the user to resolve them first.
-2. **Clarification questions (MINIMUM 7).** Technical questions covering: domain placement, data flow, dependencies, core interfaces, test strategy, reuse-vs-build, multi-project integration if applicable.
+2. **Clarification questions (MINIMUM 7).** Use the structured interview tool when available to ask technical questions covering: domain placement, data flow, dependencies, core interfaces, test strategy, reuse-vs-build, multi-project integration if applicable. If the tool is unavailable, use chat fallback and record that fallback.
 3. **Web search MINIMUM 3 queries** for technical patterns + Context7 MCP for framework/library specifics.
 4. **Source grounding (`dw-source-grounding`).** Every framework/library decision ships with `[source: <url>, version: X.Y, retrieved: YYYY-MM-DD]`.
 5. **Constitution gate.** Each architectural decision lists `Respects: P-NNN` or `Deviates: P-NNN — justification: <ADR slug or rationale>`. Deviations from `severity: high/critical` principles without ADR → STOP.
@@ -178,7 +184,7 @@ After full plan run, the PRD directory contains:
 
 ## Final Guidelines
 
-- Each stage has its own clarification question quota — don't recycle. Different stages need different framing.
+- Each stage has its own clarification question quota — don't recycle. Different stages need different framing. Use the structured interview tool whenever available.
 - Web search is mandatory; Context7 MCP for libraries. No skipping for "I think I know the latest version."
 - Constitution gate runs at every stage entry; defaults are auto-installed when missing (never blocks).
 - All three stages produce committed Markdown — these are the canonical planning artifacts. They evolve with the feature.

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

@@ -83,7 +83,7 @@ When available under `./.agents/skills/`, these are invoked operationally:
 
 1. **Pre-flight**: confirm the project dev server can run. Confirm `.dw/spec/<prd>/` has the PRD + TechSpec + tasks.
 2. **Map FRs to test plan**: for each FR, identify the user-facing flow that exercises it.
-3. **Drive Playwright MCP** (or fallback to local Playwright per `dw-testing-discipline/references/playwright-recipes.md`):
+3. **Drive Playwright MCP** (if unavailable or blocked — common on WSL — fall back to the WSL-resilient local capture `node .dw/scripts/lib/capture-screenshots.mjs`, which picks the browser via `.dw/scripts/lib/resolve-browser.mjs`; see the "Browser on WSL" section of `dw-testing-discipline/references/playwright-recipes.md`):
    - Happy paths for each FR.
    - Edge cases (boundary inputs, network failure, validation errors).
    - Negative flows (unauthorized actions, malformed input).

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

@@ -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 using `dw-testing-discipline`/playwright-recipes if available, run react-doctor if React project.
+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.
 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. Use `dw-testing-discipline/references/playwright-recipes.md` to 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. 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

@@ -44,9 +44,10 @@ When available under `./.agents/skills/`, these are invoked as analytical suppor
 
 - `dw-review-rigor`: **ALWAYS** — applies 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.
 - `dw-verify`: **ALWAYS** — invoked before emitting `APPROVED` or `APPROVED WITH CAVEATS`. Without a VERIFICATION REPORT PASS (test + lint + build), verdict cannot be APPROVED.
-- `dw-secure-audit`: **ALWAYS for TS/Python/C#/Rust projects** — security gate. If the project uses a supported language and a recent `secure-audit.md` is missing OR has REJECTED status, the verdict is **REJECTED** — no exception.
+- `dw-secure-audit` (**Security Gate**): **ALWAYS for TS/Python/C#/Rust projects** — triggered here and the verdict is enforced. If the project's language is supported and a fresh `.dw/secure-audit/audit-summary.md` is missing OR has REJECTED status, the review verdict is **REJECTED** — no exception. The same gate is also a standalone command (`/dw-secure-audit`) and an explicit phase in `/dw-autopilot`. It now adds Semgrep SAST (diff) + gitleaks secrets on top of OWASP/Trivy/SCA.
+- `security-review`: the OWASP diff-level skill the gate uses (injection, authz, secrets, SSRF, crypto — HIGH CONFIDENCE only).
 - `dw-simplification`: use when the diff touches dense or twisty code — applies Chesterton's Fence, behavior-preserving refactor protocol, complexity metrics.
-- `dw-ui-discipline`: use when the diff touches UI — runs the 14 visual-slop patterns + accessibility floor checks.
+- `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-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.
 - `security-review`: use when the diff touches auth, authorization, external input, upload, SQL, secrets, SSRF, XSS, or sensitive surfaces.
@@ -161,9 +162,10 @@ If MISSING > 0, the verdict suggests revisiting `/dw-plan tasks` to scope or `/d
    - Run dw-verify to produce a VERIFICATION REPORT (test + lint + build all GREEN).
    - Without PASS, verdict cannot be APPROVED.
 
-8. **Security Layer (`dw-secure-audit` for TS/Python/C#/Rust):**
-   - Run `/dw-secure-audit` against the PR. Latest scan must be present and not REJECTED.
-   - If language is supported and audit is missing OR REJECTED → verdict **REJECTED**.
+8. **Security Gate (`dw-secure-audit` for TS/Python/C#/Rust):**
+   - Trigger `/dw-secure-audit` against the diff (OWASP + Semgrep SAST + gitleaks + Trivy/SCA + supply-chain). It produces/refreshes `.dw/secure-audit/audit-summary.md`.
+   - Latest scan must be present, fresh (post-last-edit), and not REJECTED. If language is supported and the audit is missing OR REJECTED → review verdict **REJECTED**. SECRET findings always block (no ADR escape).
+   - The same gate is also runnable standalone (`/dw-secure-audit`) and is an explicit phase in `/dw-autopilot`; `/dw-generate-pr` re-enforces the verdict before the PR.
 
 ### Output
 

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

@@ -1,7 +1,13 @@
 <system_instructions>
-You are the security audit orchestrator. Runs OWASP static review + supply-chain CVE/secret/IaC scanning + dependency outdated check + supply-chain compromise detection in one pass. Hard-gates downstream commands when CRITICAL or HIGH findings exist.
+You are the security audit orchestrator — the **Security Gate**. Runs OWASP static review + SAST
+(Semgrep, diff-focused on the generated code) + dedicated secret scanning (gitleaks) + supply-chain
+CVE/secret/IaC scanning (Trivy + native lockfile audit) + supply-chain compromise detection + outdated
+check, in one pass. Hard-gates downstream commands when any blocking finding exists.
 
-Auto-invoked by `/dw-review` and `/dw-generate-pr` for TS/Python/C#/Rust projects. Standalone invocation available for manual audit.
+It is **auto-invoked by `/dw-review` and `/dw-generate-pr`** (for TS/Python/C#/Rust), runs as an **explicit,
+named phase in `/dw-autopilot`** (after review + QA, before commit/PR), and is **runnable standalone** any
+time. `/dw-generate-pr` re-enforces the verdict as a final hard gate. All three keep gating on security —
+the standalone command and the named phase are additive, not a replacement.
 
 ## When to Use
 - Auto-invoked: `/dw-review` and `/dw-generate-pr` for supported languages.
@@ -10,7 +16,7 @@ Auto-invoked by `/dw-review` and `/dw-generate-pr` for TS/Python/C#/Rust project
 - Do NOT use as a substitute for human security review on high-stakes auth/payment code (use `security-review` skill PLUS this).
 
 ## Pipeline Position
-**Predecessor:** any time; auto-invoked by `/dw-review`, `/dw-generate-pr` | **Successor:** `/dw-bugfix` to address findings, or `/dw-commit` if APPROVED
+**Predecessor:** `/dw-review` + `/dw-qa` (the Security Gate runs after they pass) | **Successor:** `/dw-commit` / `/dw-generate-pr` if APPROVED, or `/dw-bugfix` to address findings. Can also run standalone any time.
 
 ## Modes
 
@@ -33,10 +39,20 @@ Auto-invoked by `/dw-review` and `/dw-generate-pr` for TS/Python/C#/Rust project
 
 ## Required Dependencies
 
-- **Trivy** — must be installed (via `npx @brunosps00/dev-workflow install-deps`).
+- **Trivy** — SCA / secrets / IaC (via `npx @brunosps00/dev-workflow install-deps`).
+- **Semgrep** — SAST layer (optional but recommended). If absent, the SAST layer is skipped and noted.
+- **gitleaks** — dedicated secret scan (optional but recommended). If absent, falls back to Trivy secrets.
 - **Context7 MCP** — for framework-version-specific security best practices.
 
-## Three Detection Layers
+All scanners are optional individually: a missing tool degrades that layer and is **reported** in the
+summary (the gate never crashes for a missing scanner), but the missing coverage is visible. Install via
+`npx @brunosps00/dev-workflow install-deps`.
+
+## Detection Layers
+
+**Diff focus (the generated code):** layers that support it scope to the diff against the PR base
+(`git merge-base HEAD origin/main`) so the gate concentrates on the code just written, without noise from
+pre-existing code. A `--full` periodic pass scans the whole tree.
 
 ### Layer 1: OWASP Static Review (via `security-review` skill)
 
@@ -72,6 +88,23 @@ Cross-references the dependency tree against:
 
 Output: `.dw/secure-audit/compromise-findings.md` per affected package: COMPROMISED / suspicious / clean.
 
+### Layer 4: SAST — Semgrep (semantic analysis of generated code)
+
+Deterministic, semantic static analysis of the **diff** (`--baseline-commit`), complementing the human-style
+Layer 1. Pinned rulesets: `p/security-audit`, `p/owasp-top-ten`, `p/secrets` (+ language packs as detected).
+Map Semgrep `ERROR`→HIGH (or CRITICAL for RCE/authn-bypass/SQLi CWEs), `WARNING`→MEDIUM, `INFO`→LOW. Apply
+the **fp-check** reachability discipline before a finding blocks (see `security-review/references/sast.md`).
+
+Output: `.dw/secure-audit/sast-findings.md`. If `semgrep` is absent: skipped + noted in the summary.
+
+### Layer 5: Dedicated secret scan — gitleaks
+
+`gitleaks protect --staged` (uncommitted) or `gitleaks detect --log-opts <base>..HEAD` (branch), `--redact`.
+Authoritative for the diff; complements Trivy secrets (dedupe by `file:line`). **Any hit = REJECTED, no ADR
+exception** — secrets are removed and rotated, not justified. See `security-review/references/secrets.md`.
+
+Output: `.dw/secure-audit/secret-findings.md`. If `gitleaks` is absent: falls back to Trivy secrets + noted.
+
 ### Plus: outdated check
 
 `npm outdated` / `pip list --outdated` / `dotnet list outdated` / `cargo outdated` to identify packages behind by minor or major versions.
@@ -84,9 +117,11 @@ All findings are classified into one of these tiers in `.dw/secure-audit/audit-s
 
 | Tier | Criteria | Block | Suggested Action |
 |------|----------|-------|------------------|
+| **SECRET** | Hardcoded credential/key/token (gitleaks or Trivy), survives allowlist | YES — **no ADR exception** | Remove from code + history, rotate, move to a secret store |
 | **COMPROMISED** | Package known to be malicious in this version range | YES | Immediate remove / pin to safe version |
-| **CRITICAL** | CVE CVSS ≥9.0 OR exploits in the wild OR auth bypass | YES | Update or replace within 24h |
-| **HIGH** | CVE CVSS 7.0–8.9 OR exploitable in current context | YES | Update or replace within 1 week |
+| **CRITICAL** | CVE CVSS ≥9.0 OR exploits in the wild OR auth bypass; OR SAST high-impact CWE (SQLi/RCE/authn-bypass/SSRF/deserialization) reachable | YES | Update/replace or fix within 24h |
+| **HIGH** | CVE CVSS 7.0–8.9 OR exploitable in context; OR Semgrep `ERROR` reachable (fp-check passed) | YES | Update/replace or fix within 1 week |
+| **MEDIUM / LOW** | CVE CVSS <7.0; OR Semgrep `WARNING`/`INFO`; OR unreachable finding downgraded by fp-check | NO (advisory) | Track and fix routinely |
 | **OUTDATED-MAJOR** | ≥1 major version behind (e.g., React 17 → 19) | NO | Plan migration in next quarter |
 | **OUTDATED-MINOR** | Minor/patch behind | NO | Update routinely |
 | **CLEAN** | No findings | NO | — |
@@ -94,19 +129,26 @@ All findings are classified into one of these tiers in `.dw/secure-audit/audit-s
 ## Hard Gates
 
 The verdict is one of:
-- **APPROVED** — no CRITICAL or HIGH or COMPROMISED findings. Verdict file `.dw/secure-audit/audit-summary.md` status: APPROVED.
-- **REJECTED** — ≥1 CRITICAL, HIGH, or COMPROMISED finding without explicit ADR or remediation in flight. Verdict file status: REJECTED.
+- **APPROVED** — no SECRET, COMPROMISED, CRITICAL, or HIGH findings. Verdict file `.dw/secure-audit/audit-summary.md` status: APPROVED. (MEDIUM/LOW/outdated may be present as advisory.)
+- **REJECTED** — ≥1 SECRET (always), or ≥1 COMPROMISED/CRITICAL/HIGH without explicit ADR or remediation in flight. Verdict file status: REJECTED.
+
+**Rigoroso threshold:** SECRET and COMPROMISED always block. CRITICAL/HIGH (CVE or reachable SAST) block unless an ADR justifies acceptance. MEDIUM/LOW and outdated are advisory. A SECRET is the one tier with **no ADR escape** — rotate, don't justify.
 
 **`/dw-review` and `/dw-generate-pr` enforce:** if the project's language is supported AND the most recent `.dw/secure-audit/audit-summary.md` is missing OR REJECTED, those commands themselves return REJECTED. No exception. No bypass flag.
 
 ## Mode 1: Default (`/dw-secure-audit`)
 
 1. **Detect stack**: check for package.json / requirements.txt / *.csproj / Cargo.toml.
-2. **Run all three layers in parallel** (where possible):
-   - OWASP static (via `security-review` skill).
+2. **Run all detection layers in parallel** (where possible):
+   - OWASP static (via `security-review` skill) — diff-focused.
+   - SAST — Semgrep on the diff (`--baseline-commit`).
+   - Dedicated secret scan — gitleaks on the diff.
    - Trivy + lockfile audit.
    - Supply-chain compromise check.
 3. **Run outdated check.**
+   **fp-check:** before finalizing, run reachability validation on each blocking SAST/OWASP finding
+   (see `security-review` SKILL.md); downgrade provably-unreachable ones to advisory with a logged reason.
+   Secrets are exempt from downgrade.
 4. **Aggregate findings** per classification tier.
 5. **Write summary** at `.dw/secure-audit/audit-summary.md`:
 
@@ -118,14 +160,26 @@ The verdict is one of:
 ## Tier Summary
 | Tier | Count | Detail |
 |------|-------|--------|
+| SECRET | N | <list> |
 | COMPROMISED | N | <list> |
 | CRITICAL | N | <list> |
 | HIGH | N | <list> |
+| MEDIUM/LOW (advisory) | N | <list> |
 | OUTDATED-MAJOR | N | <list> |
 | OUTDATED-MINOR | N | <list> |
 
+## Scanners
+| Layer | Tool | Status |
+|-------|------|--------|
+| OWASP | security-review | run |
+| SAST | semgrep | run / skipped (not installed) |
+| Secrets | gitleaks | run / fallback to trivy (not installed) |
+| SCA/IaC | trivy | run |
+
 ## Layer reports
 - OWASP findings: `owasp-findings.md`
+- SAST findings: `sast-findings.md`
+- Secret findings: `secret-findings.md`
 - Trivy findings: `trivy-findings.md`
 - Lockfile findings: `lockfile-findings.md`
 - Compromise findings: `compromise-findings.md`
@@ -164,7 +218,7 @@ For each user-approved remediation:
 ## Mode 4: CI mode (`/dw-secure-audit --scan-only`)
 
 Minimal output:
-- Runs all three layers.
+- Runs all detection layers.
 - Writes findings to disk.
 - Exits with code 0 if APPROVED, 1 if REJECTED.
 - No remediation planning.
@@ -182,8 +236,9 @@ For pre-merge CI gates.
 ## Constitution Gate
 
 <critical>
-- A CRITICAL or COMPROMISED finding without an ADR justifying explicit acceptance → verdict cannot be APPROVED.
-- Constitution principle violations (security-related principles like P-009 server-side auth, P-010 secrets-in-repo) escalate findings — a `severity: info` principle violation surfaced here becomes a HIGH classification.
+- A SECRET finding → verdict cannot be APPROVED, EVER (no ADR escape). Rotate and remove.
+- A CRITICAL/HIGH/COMPROMISED finding (CVE or reachable SAST) without an ADR justifying explicit acceptance → verdict cannot be APPROVED.
+- Constitution principle violations (security principles like P-009 server-side auth, P-010 secrets-in-repo, P-011 no high-severity SAST) escalate findings — a `severity: info` principle violation surfaced here becomes a HIGH classification.
 </critical>
 
 ## Anti-patterns
@@ -198,8 +253,10 @@ For pre-merge CI gates.
 
 ```
 .dw/secure-audit/
-├── audit-summary.md           # verdict + tier summary
+├── audit-summary.md           # verdict + tier summary + scanner status
 ├── owasp-findings.md          # Layer 1
+├── sast-findings.md           # Layer 4 (Semgrep)
+├── secret-findings.md         # Layer 5 (gitleaks, redacted)
 ├── trivy-findings.md          # Layer 2 (SCA + secrets + IaC)
 ├── lockfile-findings.md       # Layer 2 (native auditor)
 ├── compromise-findings.md     # Layer 3

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

@@ -80,12 +80,17 @@ 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 `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.
+**Enforcement:** `dw-review` and the `dw-secure-audit` Security Gate 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)
+**P-010 — Secrets never enter the repository** (severity: high)
 **Rule:** No API keys, passwords, signing keys, tokens, or production endpoints checked into source. `.env.example` documents shape only.
 **Why:** Repository history is permanent. A secret committed once is leaked even if reverted next commit.
-**Enforcement:** `dw-security-check` runs Trivy + secret scanners on the diff.
+**Enforcement:** the `dw-secure-audit` Security Gate runs gitleaks + Trivy secret scanners on the diff. Any hit blocks — with **no ADR exception** (rotate, don't justify).
+
+**P-011 — No high-severity SAST finding ships unreviewed** (severity: high)
+**Rule:** Generated/changed code must pass the SAST layer (Semgrep) of the Security Gate. A reachable high-severity finding (SQLi, command/code injection, SSRF, insecure deserialization, authn bypass) blocks unless an ADR justifies acceptance.
+**Why:** AI-generated code reproduces insecure patterns at scale; deterministic SAST on the diff catches what review by reading misses.
+**Enforcement:** `dw-secure-audit` runs Semgrep on the diff (`--baseline-commit`); findings survive an fp-check reachability validation before blocking.
 
 ---
 

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

@@ -0,0 +1,17 @@
+// Functional-doc flow module. Driven by .dw/scripts/functional-doc/run-playwright-flow.mjs
+// through the Playwright Node API, so video is captured with page.screencast (works both
+// for a launched browser and over connectOverCDP). No imports are needed here — the runner
+// injects page, context, expect, baseURL and the step()/shot() helpers.
+
+export default async function flow({ page, expect, baseURL, step, shot }) {
+  await step("Open target route", async () => {
+    await page.goto(`${baseURL}{{routePath}}`);
+    await expect(page).toHaveURL(new RegExp("{{routeRegex}}"));
+  });
+
+{{testSteps}}
+
+  await step("Record final context", async () => {
+    await expect(page.locator("body")).toBeVisible();
+  });
+}

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

@@ -13,7 +13,7 @@ Antes de escolher um comando da Trigger Map, dimensione o escopo real da mudanç
 |---------|----------------|-------------|
 | **Pequeno** | ≤3 arquivos, sem migration, sem novo endpoint, descritível em uma frase. Exemplos: typo, log message, config de uma linha, bump de dependência, version pin. | Faça inline. Nenhum comando `dw-*`. |
 | **Médio** | Feature ou bug claro, <10 tasks numeradas esperadas, único componente ou serviço, sem decisões arquiteturais. Exemplos: adicionar campo de form com validação, corrigir regressão em módulo conhecido, ligar novo endpoint num handler existente. | `/dw-bugfix` (bugs) ou `/dw-plan` (features) — direto, não via `/dw-autopilot`. |
-| **Grande** | Feature multi-componente, ≥10 tasks esperadas, toca múltiplos módulos, tem superfície UX user-visible E backend. Exemplos: adicionar nova entidade end-to-end (model + migration + API + UI), introduzir integração de terceiro, redesenhar fluxo. | `/dw-autopilot "<wish>"` — pipeline completo PRD → TechSpec → Tasks → Run → QA → Review → Commit → PR com três gates. |
+| **Grande** | Feature multi-componente, ≥10 tasks esperadas, toca múltiplos módulos, tem superfície UX user-visible E backend. Exemplos: adicionar nova entidade end-to-end (model + migration + API + UI), introduzir integração de terceiro, redesenhar fluxo. | `/dw-autopilot "<wish>"` — primeira invocação planeja e para; segunda invocação retoma via `/dw-goal` para Run → Review → QA/Fix → Review, depois Commit → PR. |
 | **Complexo** | Domínio novo, requisitos ambíguos, decisão arquitetural exigida, superfície regulatória ou de compliance, ou escopo que cruza múltiplos PRDs. Exemplos: introduzir event sourcing, reconstruir auth, multi-tenancy, nova linha de produto. | `/dw-brainstorm "<ideia>"` primeiro (auto-dispatch de modos research/council), depois `/dw-plan --council` para a etapa de techspec rodar o debate multi-advisor. |
 
 **Safety valve:** se você começou em Pequeno ou Médio mas o trabalho revela que é Grande de fato (a listagem inline passa de 5 passos, ou `/dw-bugfix` dispara seu `Step 5.0`), PARE e escale. Não existe flag para bypass. Escalar é o desfecho correto.
@@ -26,6 +26,7 @@ Antes de escolher um comando da Trigger Map, dimensione o escopo real da mudanç
 |------------------------------------------------|--------------|
 | "Implementa X" / "Cria Y" / "Adiciona feature Z" / "Preciso de..." | `/dw-autopilot "X"` |
 | "Autopilota esse PRD" / "Leva esse PRD pra PR" / continua escalação de bugfix autonomamente | `/dw-autopilot --from-prd <slug>` (PRD existente em `.dw/spec/<slug>/`) |
+| "Retoma autopilot" / "continua depois do plan" / `autopilot-state.json` tem `status: plan_complete` | `/dw-autopilot` (ou `/dw-goal --from-autopilot <slug>` se o usuário pedir especificamente a etapa de goal) |
 | Erro colado / "X está quebrado" / "Bug em Y" / screenshot de teste falhando | `/dw-bugfix "X"` |
 | "Planeja essa feature" / "Escreve PRD + techspec + tasks" | `/dw-plan "X"` |
 | "Escreve PRD pra X" / "Especifica Y" | `/dw-plan prd "X"` |
@@ -33,6 +34,7 @@ Antes de escolher um comando da Trigger Map, dimensione o escopo real da mudanç
 | "Quebra em tasks" | `/dw-plan tasks` |
 | "Roda essa task" (com ID da task) | `/dw-run <ID>` |
 | "Roda todas as tasks pendentes" / "Executa o plano" | `/dw-run` |
+| "Roda isso como goal" / "objetivo durável" / "long-running objective" | `/dw-goal "<objetivo>"` |
 | "Continue de onde parei" | `/dw-run --resume` |
 | "Pausa o trabalho" / "Encerra a sessão" / "Salva onde paramos" | `/dw-pause` |
 | "Retoma" / "Onde paramos?" / "Volta de onde parei" | `/dw-resume` |
@@ -63,7 +65,7 @@ Antes de escolher um comando da Trigger Map, dimensione o escopo real da mudanç
 | "Instala skills Azure" / "Configura MCP do Microsoft docs" / "Adiciona expertise Azure" / "Vou trabalhar com Azure" | `/dw-install-azure-skills` |
 | "Instala skills AWS" / "Configura MCP da AWS" / "Adiciona expertise AWS" / "Vou trabalhar com AWS" | `/dw-install-aws-skills` |
 
-**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.
+**Prioridade:** na dúvida entre dois comandos, `/dw-autopilot` é o default mais seguro pra qualquer pedido de feature não-trivial. Se um autopilot planejado já parou com `status: plan_complete`, retome em vez de iniciar novo plano; a fase de execução pertence ao `/dw-goal`.
 
 ## Hard Gates (os comandos enforçam — não burle)
 
@@ -131,12 +133,12 @@ Skills são protocolos compactos primeiro. Leia o `SKILL.md` de entrada e carreg
 ## Referência de Workflow
 
 ```
-/dw-autopilot "wish"  ────►  Roda pipeline completo automaticamente
-                              (3 gates: PRD approval, Tasks approval, PR confirmação)
+/dw-autopilot "wish"  ────►  Primeira invocação planeja: PRD → TechSpec → Tasks → STOP
+/dw-autopilot         ────►  Segunda invocação retoma: /dw-goal → Commit → PR
 
   --- OU passo a passo ---
 
-/dw-brainstorm ─► /dw-plan ─► /dw-run ─► /dw-qa ─► /dw-review ─► /dw-commit ─► /dw-generate-pr
+/dw-brainstorm ─► /dw-plan ─► /dw-goal ─► /dw-commit ─► /dw-generate-pr
 ```
 
 Lista completa e ajuda contextual: `/dw-help`.

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

@@ -767,6 +767,27 @@ Se após as heurísticas nada cruzar a barra (codebase pequeno, churn baixo, sem
 
 **Cadência de refresh:** usuários re-rodam `/dw-analyze-project` quando rules ficam desatualizadas. O Passo 9 atualiza seções auto mantendo entradas preservadas. Não existe comando separado só de refresh.
 
+### Passo 10: Autoridade de design (DESIGN.md) — só projetos frontend
+
+Rode quando um frontend for detectado (React/Vue/Angular/Svelte/Tailwind/CSS), para que a grounding
+question 1 do `dw-ui-discipline` ("de onde vêm as decisões de design?") tenha uma autoridade do projeto
+para seguir. Isso fecha o loop que hoje a grounding apenas *lê*.
+
+1. **Cheque uma autoridade existente primeiro.** Se `DESIGN.md`, `BRAND.md` ou `STYLE_GUIDE.md` já existe
+   na raiz do projeto (ou do módulo frontend), NÃO sobrescreva — registre a localização e pare.
+2. **Detecte design tokens** em ordem de prioridade: `theme`/`@theme` do Tailwind (cores, fontFamily,
+   spacing, radius), CSS custom properties em `globals.css`/`theme.css`/`tokens.css`, theme exports de
+   MUI/Chakra, `components.json` do shadcn, theme do Storybook. Leia os valores reais — não invente.
+3. **Se houver tokens:** sintetize `DESIGN.md` na raiz do frontend capturando o que o projeto JÁ usa —
+   paleta (com os valores hex/oklch reais e nomes dos tokens), tipografia (famílias, escala, pesos),
+   escala de spacing/radius e convenções de componente observadas. Inicie com:
+   `> Gerado por /dw-analyze-project a partir de tokens existentes em <data>. Cure antes de tratar como canon.`
+4. **Se não houver tokens:** NÃO fabrique paleta. Recomende bootstrap a partir de
+   `dw-ui-discipline/references/curated-defaults.md` e registre essa recomendação no índice de rules.
+5. Referencie o novo `DESIGN.md` a partir de `.dw/rules/<módulo-frontend>.md` para os comandos downstream acharem.
+
+Este passo é aditivo e reversível; nunca edita código de componente, só documenta o que existe.
+
 ## Checklist de Qualidade
 
 - [ ] Estrutura do repositório escaneada
@@ -797,6 +818,7 @@ Se após as heurísticas nada cruzar a barra (codebase pequeno, churn baixo, sem
 - [ ] Convenções de teste documentadas (framework, padrões, cobertura)
 - [ ] Step 8 (constitution) oferecido e resolvido (A/B/C)
 - [ ] Step 9 (mapa de concerns) apresentou candidatos, aguardou aprovação, escreveu `.dw/rules/concerns.md` (ou anotou que não há sinais)
+- [ ] Passo 10 (autoridade de design) rodou para projetos frontend: autoridade existente respeitada, ou `DESIGN.md` gerado a partir de tokens reais, ou bootstrap via curated-defaults recomendado
 - [ ] Blocos com marker preserved em concerns.md mantidos verbatim no refresh
 
 ## Exemplo de Uso