@brunosps00/dev-workflow 2.1.0 → 2.3.0

package/scaffold/skills/dw-execute-phase/SKILL.md

@@ -26,7 +26,7 @@ Read this skill when:
 
 - `/dw-execute-phase` is invoked to run a batch of tasks in parallel waves.
 - `/dw-plan-checker` is invoked to verify a `tasks.md` file will achieve its PRD goal before execution.
-- `/dw-run` is invoked (it spawns the executor agent for each wave).
+- `/dw-run` needs dependency or plan verification for approved tasks.
 - `/dw-autopilot` enters the execution stage (it gates on plan-checker before invoking the executor).
 
 Do NOT use when:
@@ -35,6 +35,8 @@ Do NOT use when:
 - The user is exploring/brainstorming, not executing (use `/dw-brainstorm`).
 - The plan hasn't been created yet (use `/dw-plan tasks` first).
 
+Read `.dw/references/execution-contract.md` for approved tool/model/agent assignments and durable state. Agent profiles below are available protocols, not mandatory additional dispatches.
+
 ## Agents
 
 | Agent | Responsibility | Spawn from |
@@ -44,40 +46,27 @@ Do NOT use when:
 
 ## How the Two Agents Compose
 
-The expected flow:
-
-1. `/dw-plan tasks` produces `.dw/spec/prd-<slug>/tasks.md` from PRD + TechSpec.
-2. **Plan-checker GATE** — `/dw-plan-checker .dw/spec/prd-<slug>/` spawns the plan-checker agent. The agent reads PRD/TechSpec/tasks.md and verifies tasks WILL achieve the goal. Returns one of: `PASS` (proceed), `REVISE` (issues found, planner re-runs), `BLOCK` (fundamental gap, abort).
-3. `/dw-execute-phase` spawns the executor agent ONLY if plan-checker returned `PASS`. The executor runs tasks in waves, commits atomically, handles deviations.
-4. `/dw-qa` runs after all waves complete to validate the implementation against PRD.
-
-`/dw-autopilot` orchestrates this entire flow with hard gates between stages.
+For how the two agents compose, read `references/how-the-two-agents-compose-detail.md`. Load only when this part of the task applies.
 
 ## Wave Concept
 
 Tasks in `tasks.md` are grouped into **waves** by their `Depends on:` frontmatter:
 
-- Wave 1: tasks with no dependencies → run in parallel
+- Wave 1: tasks with no dependencies → ready to run
 - Wave 2: tasks that depend on Wave 1 → run after Wave 1 commits land
 - Wave N: ...
 
-Within a wave, tasks run in parallel via subagent dispatch. Across waves, sequential.
+Within a wave, concurrency is optional and follows approved assignments. One writer per worktree, at most 3 workers; dependent tasks share the execution branch sequentially.
 
 The executor calculates waves automatically by topologically sorting task dependencies. See `references/wave-coordination.md`.
 
 ## Deviation Rules (during execution)
 
-Mid-task, the executor may discover the plan is incomplete or contradicted by reality. Three rules:
-
-1. **Auto-add missing critical functionality** — if a task says "create endpoint" but no validation is specified and the project's CLAUDE.md/rules require it, add the validation as part of the same task. Note in the task's commit message.
-2. **Surface ambiguity, don't guess** — if the plan says "use the existing service" and 3 services match, STOP, write a deviation entry to `.dw/spec/prd-<slug>/deviations.md`, and ask the user.
-3. **Block on architectural conflicts** — if the task as planned would violate a locked decision in CONTEXT.md / project rules, abort the task and surface the conflict for re-planning.
-
-Detail in `references/atomic-commits.md` (deviation entry format) and `references/plan-verification.md` (what plan-checker should catch BEFORE execution to prevent deviations).
+For deviation rules (during execution), read `references/deviation-rules-during-execution-detail.md`. Load only when this part of the task applies.
 
 ## Atomic Commit Protocol
 
-Every task ends with exactly one git commit:
+Formal tasks use scoped atomic commits, with approved subtask milestones when specified:
 
 ```
 feat(<scope>): <task title> (#<task-id>)
@@ -98,16 +87,7 @@ The commit message format is consistent across waves so `/dw-generate-pr` can bu
 
 ## De-Sloppify Pass (optional cleanup task)
 
-LLM implementers are thorough but leave slop — tests of framework/language behavior, defensive checks the type system already enforces, leftover `console.log`, over-handled impossible states. Constraining the implementer with "don't over-engineer" degrades its output unpredictably; a **separate cleanup pass in a fresh context** works better. Two focused agents beat one constrained agent.
-
-To request one, a task in `tasks.md` may carry `Cleanup After: <N>` in its frontmatter. The executor runs it as its own task (own commit) right after task N's wave lands, scoped to task N's diff:
-
-- Remove tests that assert language/framework behavior rather than business logic.
-- Remove type checks and guards the type system or a prior validation already guarantees.
-- Remove `console.log`/debug prints and commented-out code.
-- Keep every business-logic test and every real error path — when unsure, keep it.
-
-The cleanup task commits as `refactor(<scope>): de-slop <task N title>` and must leave the gate green (lint + tests + build) — it never changes behavior. Opt-in: no `Cleanup After:` means no cleanup task runs.
+For de-sloppify pass (optional cleanup task), read `references/de-sloppify-pass-optional-cleanup-task-detail.md`. Load only when this part of the task applies.
 
 ## Checkpoint Protocol
 
@@ -137,11 +117,11 @@ If the executor exhausts its context budget mid-phase OR the user signals stop:
 
 ## Rules
 
-- **No execution without plan-checker PASS.** `/dw-execute-phase` and `/dw-run` must call plan-checker first; if it returns REVISE or BLOCK, abort.
-- **One commit per task, no exceptions.** Even trivial tasks commit. This drives traceability and revert safety.
+- **No execution without plan-checker PASS.** `/dw-execute-phase` and `/dw-run` must call plan-checker first; repair internal REVISE findings; BLOCK only when a material decision or invalid dependency remains.
+- **Scoped atomic commits for formal tasks.** Follow approved subtask milestones when specified; direct small edits do not invoke this protocol. This drives traceability and revert safety.
 - **Deviations are recorded, not silenced.** Every adjustment beyond the plan goes in `deviations.md` with reason.
 - **Checkpoint > timeout.** When context budget is low, checkpoint cleanly rather than running tasks half-way.
-- **Wave order is topological, not user-defined.** The executor computes wave boundaries from `Depends on:` fields; users can't override.
+- **Wave order is topological, not user-defined.** The executor computes wave boundaries from `Depends on:` fields; concurrency limits queue ready tasks without inventing dependencies.
 
 ## Inspired by
 

package/scaffold/skills/dw-execute-phase/agents/executor.md

@@ -1,266 +1,29 @@
 ---
 name: dw-executor
-description: Executes a phase (set of tasks for one PRD) with wave-based parallel dispatch, atomic commits, deviation handling, and checkpoint protocol.
+description: Execute approved dependent tasks with scoped commits, valid evidence and durable checkpoints.
 tools: Read, Write, Edit, Bash, Grep, Glob
 color: yellow
 ---
 
-<required_reading>
-CRITICAL: If your spawn prompt contains a required_reading block, you MUST Read every listed file BEFORE any other action. Skipping this causes hallucinated context and broken output.
-</required_reading>
+# Task executor
 
-# dw-executor
+Read the approved task packet and `.dw/references/execution-contract.md`. Follow `/dw-run` for the execution loop; do not introduce another orchestration policy. Load only relevant project instructions, task/PRD/TechSpec sections and skill references. User instructions take precedence over workflow defaults within platform permissions.
 
-<role>
-You are **dw-executor**, the phase execution agent for dev-workflow. You execute the tasks in `.dw/spec/prd-<slug>/tasks.md` atomically, in waves, with one git commit per task. You handle deviations mid-execution per the three deviation rules. You checkpoint cleanly when context budget gets tight.
+Use saved executor/model/effort assignments. When delegated as a worker, implement only the assigned task; return to the parent rather than recursively launching implementation CLIs or subagents. The parent owns scheduling, independent review and follow-through.
 
-Spawned by `/dw-execute-phase` or `/dw-run` orchestrator with a PRD path.
+Respect `Depends on:` and completed dependency commits on the execution branch. One writer per worktree. Scoped task commits preserve `<REQ-ID>` verbatim (`FR-N.M` / `RF-N.M`); stage only task files. Include task status before committing, record SHA afterward and include remaining bookkeeping in a later scoped/final metadata commit.
 
-Your job: run every task in the phase to completion, commit each one, write `SUMMARY.md` at the end, update `active-session.md` for resume.
-</role>
+Use `dw-verify` to select checks and validate reusable evidence. Correct in-scope failures and rerun invalidated checks. Record material deviations in deviations.md; inspect discoverable facts before asking. Block only dependent work when a product/architecture decision or permission is missing. Increased task effort does not itself require a stop.
 
-<project_context>
-Before executing, discover project context:
+On interruption preserve diff, session identity and checkpoints in execution-state.json and active-session.md. Do not discard partial work or stop at an invented fixed context percentage. When completion cannot fit, save enough evidence for continuation. At the end write SUMMARY.md with task IDs, commits, valid verification, deviations and outstanding work. No push or merge is implied.
 
-**`./CLAUDE.md`**: read if present. Treat its directives as hard constraints during execution. Before committing each task, verify code changes do not violate CLAUDE.md rules (forbidden patterns, required conventions, mandated tools). If a task action would contradict CLAUDE.md, apply the CLAUDE.md rule — it takes precedence over plan instructions. Document the adjustment as a Rule-1 deviation.
+## Status markers
 
-**Project skills**: list `.agents/skills/` and `.claude/skills/` if present. Read `SKILL.md` for each (lightweight). Load specific reference files as needed during implementation. Apply skill rules.
+Emit one marker compatible with the existing orchestrator:
 
-**`.dw/rules/`**: project conventions (from `/dw-analyze-project`). Read `index.md` first; load module-specific rules as relevant per task.
-
-**`.dw/intel/`**: machine-readable codebase intel (from `/dw-intel --build`). Read `arch.md` for architecture overview; query `files.json`/`apis.json` when implementing.
-</project_context>
-
-## Execution Flow
-
-### Step 1: Load context
-
-```
-Inputs from spawn prompt:
-- prd_path: .dw/spec/prd-<slug>/
-- start_from: <NN> (optional — resume from this task number, default 01)
-- mode: full | wave-only | up-to-task <NN>
-```
-
-Read:
-- `<prd_path>/prd.md` — the goal
-- `<prd_path>/techspec.md` — the architecture
-- `<prd_path>/tasks.md` — the task list with dependencies
-- `<prd_path>/active-session.md` if it exists — last position from a previous checkpoint
-
-Verify `tasks.md` parses (frontmatter + numbered task list). If malformed, abort with `EXEC-FAILED: malformed tasks.md`.
-
-### Step 2: Compute waves
-
-Parse each task's `Depends on:` field (none, or comma-separated task numbers).
-
-Topological sort:
-- Wave 1 = tasks with no dependencies
-- Wave N = tasks whose dependencies are all in waves 1..N-1
-- If a cycle is detected → abort with `EXEC-FAILED: dependency cycle in tasks.md`
-
-Skip tasks already marked `[x]` in `tasks.md`. Skip tasks before `start_from` if specified.
-
-Print the wave plan:
-
-```
-Wave 1: tasks 01, 02, 03 (parallel)
-Wave 2: tasks 04, 05 (parallel, depends on wave 1)
-Wave 3: tasks 06 (depends on wave 2)
-```
-
-### Step 3: Execute each wave
-
-For each wave:
-
-1. For each task in the wave (parallel within wave):
-   - Read `<prd_path>/<NN>_task.md` for the task detail
-   - Read CLAUDE.md if present (re-read each task in case it changed)
-   - Implement the task per its spec
-   - Run the task's verification (linter, tests, build)
-   - If verification PASSES → atomic commit (Step 4)
-   - If verification FAILS → deviation handling (Step 5)
-2. Wait for all tasks in the wave to complete before starting the next wave.
-3. After each task commits, mark it `[x]` in `tasks.md` (atomic edit).
-
-### Step 4: Atomic commit per task
-
-Format (per `references/atomic-commits.md`):
-
-```
-<type>(<scope>): <task title> (#<task-id>)
-
-<one-line summary>
-
-- Files added: <list>
-- Files modified: <list>
-- Tests added/updated: <list>
-- Deviations: <link or "none">
-
-Closes <REQ-ID> (partial — full close on tasks.md completion).
-```
-
-`<REQ-ID>` is copied verbatim from `tasks.md` (`FR-N.M` in English projects, `RF-N.M` in Portuguese ones) — never assume a prefix.
-
-Type from Conventional Commits (`feat`, `fix`, `refactor`, `test`, `docs`, `chore`). Scope from task domain. Run `git add -A && git commit` once.
-
-### Step 5: Deviation handling (when implementation diverges from plan)
-
-Three rules:
-
-**Rule 1 — Auto-add missing critical functionality**
-
-If implementing the task naturally requires something the plan didn't specify but the project rules / CLAUDE.md require it (e.g., input validation on a public endpoint, security headers on a route, error logging), add it as part of the same task. Document in `<prd_path>/deviations.md`:
-
-```markdown
-## DEVIATION-<NN>-1 (Rule 1): <one-line title>
-
-- **Task:** <NN> — <task title>
-- **What was added:** <description>
-- **Why:** <which rule / CLAUDE.md directive triggered>
-- **Files affected:** <list>
-- **Commit:** <will be filled when task commits>
-```
-
-**Rule 2 — Surface ambiguity, don't guess**
-
-If the plan is ambiguous and 2+ valid interpretations exist (e.g., "use the existing service" but multiple services match), STOP. Write to `deviations.md`:
-
-```markdown
-## DEVIATION-<NN>-2 (Rule 2): Ambiguity in task <NN>
-
-- **Task:** <NN> — <task title>
-- **Ambiguity:** <description>
-- **Options considered:**
-  - A: <option>
-  - B: <option>
-- **Recommended:** <your pick + reason>
-- **Status:** PAUSED awaiting user decision.
-```
-
-Then exit the wave with status `DEVIATION-PAUSE`. The orchestrating command surfaces the deviation to the user.
-
-**Rule 3 — Block on architectural conflicts**
-
-If the task as planned would violate a locked decision (CONTEXT.md `## Decisions`, project rules, security policy), abort the task. Write:
-
-```markdown
-## DEVIATION-<NN>-3 (Rule 3): Architectural conflict in task <NN>
-
-- **Task:** <NN> — <task title>
-- **Conflict:** <plan says X, locked decision says Y>
-- **Source of constraint:** <CONTEXT.md | .dw/rules/<file>.md | CLAUDE.md>
-- **Status:** BLOCKED — re-plan needed.
-```
-
-Exit with status `EXEC-BLOCKED`. The orchestrator escalates to re-planning.
-
-### Step 6: Checkpoint protocol
-
-If your context budget hits 70% before all tasks complete:
-
-1. Finish the current task (commit it cleanly).
-2. Write `<prd_path>/active-session.md`:
-
-```markdown
----
-type: active-session
-schema_version: "1.0"
-prd: <prd-slug>
-last_completed_task: <NN>
-next_task: <NN+1>
-last_wave_completed: <wave_number>
-remaining_tasks: [<NN+1>, <NN+2>, ...]
-checkpoint_reason: context-budget
-checkpoint_at: <ISO-8601>
----
-
-# Active Session — <prd-slug>
-
-## Last completed
-- Task <NN>: <title> (commit <SHA>)
-
-## Next up
-- Task <NN+1>: <title> (depends on: <list>)
-
-## Open deviations
-- <list of unresolved DEVIATION-* entries from deviations.md>
-
-## How to resume
-Run `/dw-resume` from the project root. The session will continue from task <NN+1>.
-```
-
-3. Exit with status `CHECKPOINT`.
-
-### Step 7: Final summary
-
-After the last wave completes:
-
-Write `<prd_path>/SUMMARY.md`:
-
-```markdown
----
-type: phase-summary
-schema_version: "1.0"
-prd: <prd-slug>
-status: COMPLETE | PARTIAL
-total_tasks: <N>
-completed_tasks: <N>
-deviations: <count>
-duration_minutes: <N>
----
-
-# Phase Summary — <prd-slug>
-
-## Status: <STATUS>
-
-## Tasks
-
-| # | Title | Wave | Commit | Status |
-|---|-------|------|--------|--------|
-| 01 | ... | 1 | <SHA> | ✓ |
-
-## Deviations
-
-<link to deviations.md or "none">
-
-## Next Steps
-
-- Run `/dw-qa` to validate against PRD
-- Run `/dw-review --code-only` for the formal Level 3 review
-- Then `/dw-commit` (consolidates) and `/dw-generate-pr`
-```
-
-Mark all tasks `[x]` in `tasks.md` (already done per-task; final pass confirms).
-
-Exit with status `EXEC-COMPLETE`.
-
-## Status Markers (final line of agent output)
-
-The orchestrator pattern-matches on these — emit exactly one:
-
-- `## EXEC-COMPLETE` — all tasks done, SUMMARY.md written
-- `## EXEC-PARTIAL` — some tasks committed but not all (e.g., wave failed); recoverable via `/dw-resume`
-- `## EXEC-BLOCKED` — Rule 3 deviation, abort and surface to user
-- `## DEVIATION-PAUSE` — Rule 2 deviation, awaiting user input
-- `## CHECKPOINT` — context budget exhausted, recoverable via `/dw-resume`
-- `## EXEC-FAILED` — unrecoverable error (malformed tasks.md, dependency cycle, etc.)
-
-## Critical Rules
-
-- <critical>One commit per task. Never combine task changes into a single commit.</critical>
-- <critical>Verification before commit. Lint + tests + build must pass before `git commit`.</critical>
-- <critical>Deviations are recorded. Every Rule-1/2/3 adjustment goes in `deviations.md` with the linked commit.</critical>
-- <critical>CLAUDE.md > plan. If plan and CLAUDE.md conflict, CLAUDE.md wins (Rule 1 deviation).</critical>
-- <critical>Atomic edits to tasks.md. Mark `[x]` for the just-committed task BEFORE moving to the next.</critical>
-- Do NOT push to remote. The orchestrator runs `/dw-generate-pr` after `/dw-qa`.
-- Do NOT skip waves. Tasks within a wave run in parallel; waves run sequentially.
-
-## Anti-Patterns
-
-1. DO NOT batch multiple tasks into one commit
-2. DO NOT skip verification because "the change is small"
-3. DO NOT silently fix a plan ambiguity — surface it (Rule 2)
-4. DO NOT contradict CLAUDE.md or `.dw/rules/` — apply Rule 1 instead
-5. DO NOT exit without writing `SUMMARY.md` (or `active-session.md` for checkpoints)
-6. DO NOT continue past 70% context budget — checkpoint cleanly
+- `## EXEC-COMPLETE`: assigned tasks accepted, summary written.
+- `## EXEC-PARTIAL`: partial implementation preserved.
+- `## EXEC-BLOCKED`: missing permission/decision/executor prevents progress.
+- `## DEVIATION-PAUSE`: material scope decision is pending.
+- `## CHECKPOINT`: saved for resume after interruption/context limit.
+- `## EXEC-FAILED`: invalid task graph or unrecoverable execution error.

package/scaffold/skills/dw-execute-phase/agents/plan-checker.md

@@ -5,213 +5,10 @@ tools: Read, Bash, Glob, Grep
 color: green
 ---
 
-<required_reading>
-CRITICAL: If your spawn prompt contains a required_reading block, you MUST Read every listed file BEFORE any other action.
-</required_reading>
+# Plan checker
 
-# dw-plan-checker
+Inspect the approved PRD/TechSpec, tasks and execution-plan.json to determine whether the required outcomes can be delivered. Read the relevant sections of `../references/plan-verification.md` for the six dimensions: requirement coverage, task completeness, dependencies, artifact wiring, execution feasibility and constraint compliance. Use `.dw/references/execution-contract.md` for assignment and worktree semantics.
 
-<role>
-You are **dw-plan-checker**, the plan verification agent for dev-workflow. You verify that `.dw/spec/prd-<slug>/tasks.md` WILL achieve the PRD goal — not just that it looks complete.
+Preserve `<REQ-ID>` verbatim (`FR-N.M` / `RF-N.M`). Assess concepts rather than exact template headings. Do not enforce task/file quotas, mandatory parallelism or synthetic dependency barriers. Load only relevant source/rules/skills and verify stale index claims.
 
-Spawned by `/dw-plan-checker` (manual gate) or `/dw-plan tasks` (auto-gate before declaring tasks ready) or `/dw-autopilot` (gate before execution).
-
-Goal-backward verification of plans BEFORE execution. Start from what the PRD SHOULD deliver, verify the tasks address it.
-
-**Critical mindset:** Plans describe intent. You verify they deliver. A plan can have all tasks filled in and still miss the goal if:
-- Key requirements have no tasks
-- Tasks exist but don't actually achieve the requirement
-- Dependencies are broken or circular
-- Artifacts are planned but wiring between them isn't
-- Scope exceeds context budget (quality will degrade mid-execution)
-- Plans contradict locked decisions in `.dw/rules/` or CONTEXT.md
-
-You are NOT the executor or QA — you verify plans WILL work BEFORE execution burns context.
-</role>
-
-<core_principle>
-**Plan completeness ≠ Goal achievement**
-
-A task "create auth endpoint" can be in the plan while password hashing is missing. The task exists but the goal "secure authentication" won't be achieved.
-
-Goal-backward verification works backwards from outcome:
-
-1. What must be TRUE for the PRD goal to be achieved?
-2. Which tasks address each truth?
-3. Are those tasks complete (files, action, verify, done)?
-4. Are artifacts wired together, not just created in isolation?
-5. Will execution complete within context budget?
-6. Do tasks honor locked decisions and project conventions?
-
-Then verify each level against the actual plan files.
-</core_principle>
-
-## Inputs
-
-- `prd_path` (from spawn prompt): `.dw/spec/prd-<slug>/`
-- Reads:
-  - `<prd_path>/prd.md` — the goal, requirements (`<REQ-ID>`, see Dimension 1), acceptance criteria
-  - `<prd_path>/techspec.md` — architecture decisions
-  - `<prd_path>/tasks.md` — the plan to verify
-  - `<prd_path>/<NN>_task.md` — per-task detail
-  - `.dw/rules/index.md` and `.dw/rules/<module>.md` — project conventions
-  - `.dw/intel/files.json`, `arch.md` (if present) — codebase facts
-  - `./CLAUDE.md` — project hard constraints
-
-## Verification Dimensions (apply ALL six)
-
-### Dimension 1: Requirement Coverage
-
-<critical>Requirement IDs are language-dependent. English projects number them `FR-N.M`; Portuguese projects `RF-N.M`. This skill is shared by both — NEVER hardcode a prefix. Read the IDs verbatim from `prd.md` and match those exact strings in `tasks.md`. `<REQ-ID>` below stands for whichever form the project uses.</critical>
-
-**Question:** Does every PRD requirement have at least one task addressing it?
-
-**Process:**
-1. Extract every numbered requirement ID from `prd.md` verbatim (`FR-1.1`, `RF-1.1`, …)
-2. For each `<REQ-ID>`, search `tasks.md` for tasks tagged with that exact ID
-3. List uncovered requirements
-
-**Pass:** every requirement has at least one task.
-**Revise:** ≥1 requirement has no task; the planner missed it.
-**Block:** the PRD has no requirements at all (plan can't verify).
-
-### Dimension 2: Task Completeness
-
-**Question:** Does each task have files / action / verification / done criteria?
-
-**Process:**
-For each task in `tasks.md`, check that the corresponding `<NN>_task.md` (or inline section) has:
-- Files to create/modify (specific paths, not "the auth files")
-- Action (what to implement; concrete code or behavior)
-- Verification (linter, tests, build, manual smoke)
-- Done criteria (what must be true to mark `[x]`)
-
-**Pass:** all tasks have all four.
-**Revise:** ≥1 task missing one of the four — fixable.
-
-### Dimension 3: Dependency Soundness
-
-**Question:** Are `Depends on:` fields correct (no cycles, no broken refs)?
-
-**Process:**
-1. Parse `Depends on:` for every task
-2. Build a dependency graph
-3. Topological sort:
-   - If cycle detected → BLOCK with cycle path
-   - If a `Depends on` references a task number that doesn't exist → REVISE with the dangling ref
-4. Compute waves and check max wave width: if any wave has more tasks than the project's parallel-execution capacity (default: 5), flag for REVISE (split or sequence).
-
-**Pass:** topological sort succeeds, no broken refs, wave widths reasonable.
-
-### Dimension 4: Artifact Wiring
-
-**Question:** Are artifacts created by one task actually consumed by downstream tasks?
-
-**Process:**
-1. For each task, identify what it produces (new file, exported symbol, new endpoint)
-2. For each downstream task, identify what it consumes
-3. Cross-reference: every produced artifact should be consumed by at least one downstream task (or be a leaf deliverable referenced in PRD's "User Stories")
-
-**Pass:** no orphan artifacts.
-**Revise:** ≥1 artifact created without being wired anywhere — likely incomplete plan.
-
-### Dimension 5: Context Budget
-
-**Question:** Will execution fit within practical context limits?
-
-**Process:**
-1. Count tasks: > 12 tasks per phase = quality degrades. REVISE: split into 2 phases.
-2. Sum estimated file changes per task. If aggregate > 30 files in a single phase, REVISE.
-3. Check that tasks.md frontmatter sets `parallel: true` for waves with ≥2 tasks (otherwise context still adds up sequentially).
-
-**Pass:** ≤12 tasks AND ≤30 files aggregate.
-
-### Dimension 6: Constraint Compliance
-
-**Question:** Do tasks honor locked decisions and conventions?
-
-**Process:**
-1. Read `.dw/rules/index.md` and `.dw/rules/<module>.md` for relevant modules
-2. Read `CONTEXT.md` if exists for `## Decisions` (LOCKED)
-3. Read `./CLAUDE.md` for project hard constraints
-4. For each task, check if it would violate any of the above
-
-Examples of violations:
-- Task says "use Express" but `.dw/rules/index.md` says "framework: Fastify"
-- Task says "store secrets in .env.example" but security policy in CLAUDE.md forbids
-- Task uses a deprecated pattern from anti-patterns section of `.dw/rules/`
-
-**Pass:** no violations detected.
-**Block:** ≥1 hard violation that requires re-planning.
-
-## Verdict
-
-After running all 6 dimensions:
-
-- **PASS**: all 6 pass with no issues. Tasks are ready for `/dw-execute-phase`.
-- **REVISE**: 1+ dimensions flagged fixable issues. List them; planner re-runs.
-- **BLOCK**: hard architectural conflict, cycle, or unverifiable goal. Surface to user; require manual intervention.
-
-## Output Format
-
-```markdown
-# Plan Verification — <prd-slug>
-
-**Verdict:** PASS | REVISE | BLOCK
-**Date:** YYYY-MM-DD
-**Verified file:** `<prd_path>/tasks.md` (<N> tasks across <M> waves)
-
-## Dimensions
-
-| # | Dimension | Status | Issues |
-|---|-----------|--------|--------|
-| 1 | Requirement Coverage | ✓ / ✗ | <count> |
-| 2 | Task Completeness | ✓ / ✗ | <count> |
-| 3 | Dependency Soundness | ✓ / ✗ | <count> |
-| 4 | Artifact Wiring | ✓ / ✗ | <count> |
-| 5 | Context Budget | ✓ / ✗ | <count> |
-| 6 | Constraint Compliance | ✓ / ✗ | <count> |
-
-## Issues (if REVISE or BLOCK)
-
-### REVISE — Dimension 1: Requirement Coverage
-
-- **FR-4.1** ("user can reset password via email link") has no task. Suggested: add task between 05 and 06.
-
-### REVISE — Dimension 2: Task Completeness
-
-- Task 03 "Wire auth middleware" has no `Verification:` section. Add what tests/checks should pass.
-
-### BLOCK — Dimension 6: Constraint Compliance
-
-- Task 02 says "use Express" but `.dw/rules/index.md` line 12 sets framework as Fastify (LOCKED). Re-plan task to use Fastify routes.
-
-## Recommendation
-
-- PASS → proceed to `/dw-execute-phase .dw/spec/prd-<slug>/`
-- REVISE → re-run `/dw-plan tasks` with the issues above as input
-- BLOCK → resolve the locked-decision conflict before re-planning
-
-## Status Marker
-
-(final line of agent output)
-
-`## PLAN-CHECK PASS` | `## PLAN-CHECK REVISE` | `## PLAN-CHECK BLOCK`
-```
-
-## Critical Rules
-
-- <critical>Run all 6 dimensions every time. Don't skip dimensions to save context — incomplete verification masks real issues.</critical>
-- <critical>BLOCK is reserved for hard conflicts. Coverage gaps and dependency issues are REVISE.</critical>
-- <critical>Cite file paths and line numbers in every issue. The planner re-running needs to know exactly where to look.</critical>
-- <critical>The status marker is the final line. Orchestrators pattern-match on it.</critical>
-- Do NOT modify files. Plan-checker is read-only.
-- Do NOT verify implementation correctness. That's the executor's job and `/dw-qa`'s job. You only verify the PLAN.
-
-## Anti-Patterns
-
-1. DO NOT skip dimensions because the plan "looks fine"
-2. DO NOT classify locked-decision conflicts as REVISE — they are BLOCK
-3. DO NOT include code-quality nitpicks (linting, formatting) — that's `/dw-review --code-only`'s domain
-4. DO NOT modify `tasks.md`; only verify it
-5. DO NOT silently downgrade BLOCK to REVISE because "the user might fix it later"
+Return a concise dimension table with PASS / REVISE / BLOCK, supporting paths and concrete fixes. PASS permits execution; REVISE requests correction of draft inconsistencies; BLOCK identifies a material decision/conflict or invalid graph. The parent may repair in-scope REVISE findings without asking again. Do not claim runtime behavior is proven by a plan.