@brunosps00/dev-workflow 2.2.0 → 2.3.0

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.

package/scaffold/skills/dw-execute-phase/references/atomic-commits.md

@@ -1,6 +1,6 @@
-# Atomic commits — one commit per task, no exceptions
+# Scoped atomic commits
 
-Every task in a phase commits exactly once. This drives traceability (a task's diff is `git show <sha>`), revert safety (`git revert <sha>` undoes one task without affecting others), and PR clarity (`/dw-generate-pr` builds a clean changelog from the per-task commits).
+Formal tasks use atomic commits, with approved subtask milestones and final bookkeeping where specified. This drives traceability (a task's diff is `git show <sha>`), revert safety (`git revert <sha>` undoes one task without affecting others), and PR clarity (`/dw-generate-pr` builds a clean changelog from the per-task commits).
 
 ## Commit message format
 
@@ -80,17 +80,7 @@ Closes FR-7.2 (partial — full close on tasks.md completion).
 
 ## Verification before commit
 
-The executor MUST run, in order:
-
-1. **Linter** — project's lint command (`pnpm lint`, `ruff check`, `dotnet format --verify-no-changes`, `cargo clippy`).
-2. **Tests** — at minimum the tests touched by this task. Full suite if practical.
-3. **Build** — typecheck/compile (`pnpm tsc --noEmit`, `mypy`, `dotnet build`, `cargo check`).
-
-All three must pass. If any fails:
-- If the failure is in a test the task added → fix and retry (1 retry, then deviation)
-- If the failure is in unrelated code → deviation Rule 2 (ambiguity: does this task own the regression?)
-
-The executor does NOT commit unverified code. Period.
+Use `dw-verify`: complete applicable project-required checks and acceptance criteria. Reuse evidence only for equivalent inputs, environment and scope. After failure diagnose and fix in scope, rerun affected checks, and complete invalidated required gates. Do not invent lint/build scripts or repeat checks solely because a commit is next.
 
 ## Edit vs Write
 
@@ -102,13 +92,13 @@ When implementing the task:
 | Changing 1-30 lines | Replacing a file completely |
 | You have line context (the file is in your context) | The file is small and a Write is cleaner than 5 Edits |
 
-Never use `cat <<'EOF' > file` heredocs from Bash to create files. Always use Write tool.
+Use available file-editing tools safely; preserve content outside the task scope.
 
 ## Multi-file tasks
 
 If a task touches 5+ files, that's still one commit. Stage all files (`git add <list>`) then `git commit`. The body's `Files added:` / `Files modified:` lists must include every file.
 
-If a task should logically be split into separate commits (e.g., "create schema then wire it"), that's a sign the planner under-decomposed. The executor flags as Rule 2 deviation, not silently split.
+Use approved subtask commit milestones when specified. Propose only material changes to the intended task boundaries.
 
 ## Commit signing
 
@@ -121,7 +111,7 @@ If `git config commit.gpgsign true` is set, signing is on by default — let it
 - OS junk (`.DS_Store`, `Thumbs.db`)
 - Unrelated changes accidentally in the working tree (executor should `git status` before adding to confirm only the task's files)
 
-If unrelated changes are present, deviation Rule 2: pause and ask — the executor doesn't know if those are user's WIP or expected from a prior task.
+Preserve unrelated changes and stage only scoped files. Ask only when they conflict with the task or ownership cannot be determined; unrelated WIP alone is not a blocker.
 
 ## Deviation entry format (referenced from commits)
 
@@ -142,6 +132,6 @@ If unrelated changes are present, deviation Rule 2: pause and ask — the execut
 
 The plan-checker reads `deviations.md` from the previous run when re-verifying after revision — patterns of recurring Rule 1 deviations indicate the planner is missing a project convention that should be in `.dw/rules/`.
 
-## Final phase commit (handled by `/dw-commit`, not executor)
+## Final bookkeeping
 
-After all per-task commits, `/dw-generate-pr` (NOT the executor) reads them and builds the PR body. The executor never makes a "wrap-up" commit. If the phase needs a final commit (e.g., updating CHANGELOG.md), that should be the LAST task in `tasks.md` — atomic like every other.
+Record task status with the implementation, then store the resulting SHA in tasks.md/run-log. Include leftover bookkeeping in the next scoped commit or a final metadata commit through `/dw-commit`. Do not amend automatically, create empty commits, or change version/CHANGELOG without maintainer authorization. PR generation uses these commits; it is a separately authorized action.

package/scaffold/skills/dw-execute-phase/references/de-sloppify-pass-optional-cleanup-task-detail.md

@@ -0,0 +1,12 @@
+## 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.

package/scaffold/skills/dw-execute-phase/references/deviation-rules-during-execution-detail.md

@@ -0,0 +1,8 @@
+# Deviations during execution
+
+Record material adjustments in deviations.md with task, reason, affected files and outcome.
+
+- Complete functionality needed to satisfy the approved requirements and applicable project constraints; do not broaden product scope.
+- Resolve discoverable ambiguity by inspecting code and previous decisions. Ask only when materially different product/architecture choices remain; block dependent work while continuing independent authorized work.
+- A conflict with a locked architectural decision requires the project's ADR/decision process. Do not silently override it.
+- Repair internal plan inconsistencies and split/reorder work within approved scope; larger estimates alone do not require approval.

package/scaffold/skills/dw-execute-phase/references/how-the-two-agents-compose-detail.md

@@ -0,0 +1,7 @@
+# Composing plan checks and execution
+
+`/dw-plan tasks` produces the task artifacts and execution assignments. Check requirement coverage, completeness, dependencies, artifact wiring, feasibility and constraints using the plan-checker protocol. The parent can perform this check locally or delegate to an approved independent reviewer; it is not a mandatory extra agent layer.
+
+After PASS, `/dw-run` executes the approved assignments in dependency order. Repair in-scope REVISE findings and recheck; surface material BLOCK decisions. Use executor profiles only when delegation helps and is available. Workers do not recursively dispatch implementation agents.
+
+After tasks, inspect/reuse a valid full review, run applicable QA, correct in-scope defects and repeat checks/review only when invalidated. `/dw-autopilot` continues this approved implementation flow without a forced second invocation. Planning-only requests end with the requested plan.