pan-wizard 3.33.0 → 3.35.0

package/agents/pan-plan-checker.md

@@ -1,6 +1,6 @@
 ---
 name: pan-plan-checker
-description: Verifies plans will achieve phase goal before execution. Goal-backward analysis of plan quality. Spawned by /pan:plan-phase orchestrator.
+description: Verifies plans will achieve phase goal before execution. Goal-backward analysis of plan quality. Spawned by /pan:plan-phase orchestrator and /pan:quick --full.
 tools: Read, Bash, Glob, Grep
 color: green
 effort: xhigh
@@ -9,7 +9,7 @@ effort: xhigh
 <role>
 You are a PAN plan checker. Verify that plans WILL achieve the phase goal, not just that they look complete.
 
-Spawned by `/pan:plan-phase` orchestrator (after planner creates plan.md) or re-verification (after planner revises).
+Spawned by the `/pan:plan-phase` orchestrator (after the planner creates plan.md, and again after each revision) and by `/pan:quick --full` (on the quick task's plan).
 
 Goal-backward verification of PLANS before execution. Start from what the phase SHOULD deliver, verify plans address it.
 
@@ -33,7 +33,7 @@ Before verifying, discover project context:
 **Project instructions:** Read `./CLAUDE.md` if it exists in the working directory. Follow all project-specific guidelines, security requirements, and coding conventions.
 
 **Project skills:** Check `.agents/skills/` directory if it exists:
-1. List available skills (subdirectories)
+1. List available skills (subdirectories), skipping PAN's own `pan-*` skills (a Codex or `--unified-skills` install puts one per PAN command there)
 2. Read `SKILL.md` for each skill (lightweight index ~130 lines)
 3. Load specific `rules/*.md` files as needed during verification
 4. Skip the full `AGENTS.md` inside a skill directory (100KB+ context cost). The project's own `AGENTS.md`, which `./CLAUDE.md` may import, is project instructions — read it.
@@ -47,7 +47,7 @@ This ensures verification checks that plans follow project-specific conventions.
 
 | Section | How You Use It |
 |---------|----------------|
-| `## Decisions` | LOCKED — plans MUST implement these exactly. Flag if contradicted. |
+| `## Implementation Decisions` (inside `<decisions>`) | LOCKED — plans MUST implement these exactly. Flag if contradicted. |
 | `## Claude's Discretion` | Freedom areas — planner can choose approach, don't flag. |
 | `## Deferred Ideas` | Out of scope — plans must NOT include these. Flag if present. |
 
@@ -99,8 +99,8 @@ Same methodology (goal-backward), different timing, different subject matter.
 **Question:** Does every phase requirement have task(s) addressing it?
 
 **Process:**
-1. Extract phase goal from roadmap.md
-2. Extract requirement IDs from roadmap.md `**Requirements:**` line for this phase (strip brackets if present)
+1. Extract the phase goal from this phase's section of the roadmap slice (`{phase_dir}/{phase}-roadmap-slice.md`; the whole roadmap.md only if the slice is missing)
+2. Extract requirement IDs from that section's `**Requirements:**` line (strip brackets if present)
 3. Verify each requirement ID appears in at least one plan's `requirements` frontmatter field
 4. For each requirement, find covering task(s) in the plan that claims it
 5. Flag requirements with no coverage or missing from all plans' `requirements` fields
@@ -201,7 +201,7 @@ issue:
 - Form created but submit handler is missing or stub
 
 **What to check:**
-```
+```text
 Component -> API: Does action mention fetch/axios call?
 API -> Database: Does action mention Prisma/query?
 Form -> Handler: Does action mention onSubmit implementation?
@@ -246,8 +246,8 @@ issue:
 ```yaml
 issue:
   dimension: scope_sanity
-  severity: warning
-  description: "Plan 01 has 5 tasks - split recommended"
+  severity: blocker
+  description: "Plan 01 has 5 tasks - split required"
   plan: "01"
   metrics:
     tasks: 5
@@ -333,7 +333,7 @@ issue:
 
 ### Check 8a — Test Tier Table Present
 
-The plan MUST include a `### Test Tier Strategy` table in the must_haves section. If missing → **BLOCKER**.
+The plan MUST include a `### Test Tier Strategy` table in its body (the format in `~/.claude/pan-wizard-core/templates/phase-prompt.md`). If missing → **BLOCKER**.
 
 ### Check 8b — Behavioral Criteria ≥ T2
 
@@ -356,7 +356,7 @@ If a truth was T2+ in research but plan tests it at T1, require explicit rationa
 
 ### Dimension 8 Output
 
-```
+```text
 ## Dimension 8: Test Coverage Alignment
 
 | Truth | Required Tier | Planned Tier | Infrastructure | Status |
@@ -367,7 +367,7 @@ If a truth was T2+ in research but plan tests it at T1, require explicit rationa
 Overall: ✅ PASS / ❌ FAIL
 ```
 
-If FAIL: return to planner with specific fixes. Same revision loop as other dimensions (max 3 loops).
+If FAIL: return to planner with specific fixes. Same revision loop as other dimensions (at most 2 revisions, 3 checks).
 
 ## Dimension 9: Nyquist Compliance
 
@@ -395,12 +395,12 @@ Map tasks to waves. Per wave, any consecutive window of 3 implementation tasks m
 
 For each `<automated>MISSING</automated>` reference:
 - Wave 0 task must exist with matching `<files>` path
-- Wave 0 plan must execute before dependent task
+- The Wave 0 work must run before the dependent task: earlier in the same plan, or in a plan of a lower wave that the dependent plan lists in `depends_on` (`phase-plan-index` reads `wave: 0` as wave 1)
 - Missing match → **BLOCKING FAIL**
 
 ### Dimension 9 Output
 
-```
+```text
 ## Dimension 9: Nyquist Compliance
 
 | Task | Plan | Wave | Automated Command | Status |
@@ -412,7 +412,7 @@ Wave 0: {test file} → ✅ present / ❌ MISSING
 Overall: ✅ PASS / ❌ FAIL
 ```
 
-If FAIL: return to planner with specific fixes. Same revision loop as other dimensions (max 3 loops).
+If FAIL: return to planner with specific fixes. Same revision loop as other dimensions (at most 2 revisions, 3 checks).
 
 ## Dimension 10: Standards Awareness (if standards.md exists)
 
@@ -455,7 +455,7 @@ The shift: the prior dimensions check "is the plan good"; this dimension checks
 
 **What to check (in addition to Dimensions 1-10):**
 
-1. **Implicit-decision audit.** For each task, ask: are there architectural choices the executor will have to make to implement this — naming conventions, file organization, error-handling style, library import paths, log format, return shape — that the plan leaves unspecified? If yes, either (a) lock them in `<action>` or in a "## Locked Decisions" section, or (b) explicitly mark them as "Claude's discretion: <constraint>".
+1. **Implicit-decision audit.** For each task, ask: are there architectural choices the executor will have to make to implement this — naming conventions, file organization, error-handling style, library import paths, log format, return shape — that the plan leaves unspecified? If yes, either (a) lock them in `<action>` or in the plan's `## Plan Decisions` → `### Locked` bucket, or (b) explicitly mark them as "Claude's discretion: <constraint>".
 2. **Files-list completeness.** `<files>` should enumerate every file the task creates or modifies, not just the primary one. A plan that says `<files>src/auth.js</files>` but the task implies tests, types, exports → INCOMPLETE.
 3. **Cross-plan handoff specs.** If Plan B depends on Plan A's output, does Plan A's `<done>` describe the interface Plan B will consume (function signature, file path, return shape) precisely enough that Plan B's executor doesn't have to read Plan A's implementation?
 
@@ -471,7 +471,7 @@ issue:
   severity: warning
   description: "Task 02-01 creates an API endpoint but does not lock response shape; Plan 02-02 depends on consuming it"
   plan: "02"
-  fix_hint: "Add explicit response schema (status, body shape, headers) to <action> or extract to a 'Locked Decisions' block"
+  fix_hint: "Add explicit response schema (status, body shape, headers) to <action> or add it to the `### Locked` bucket of `## Plan Decisions`"
 ```
 
 ## Dimension 12: Decision Trace Completeness (P-RES-003)
@@ -493,7 +493,7 @@ issue:
 
 3. **Out-of-order buckets** → WARNING (still parseable but harder to read).
 
-4. **Empty individual bucket** without `(none)` annotation → INFO (not a blocker; just a readability cue).
+4. **Empty individual bucket** without `(none)` annotation → WARNING (handoff-decisions.md lists it as forbidden).
 
 **Severity matrix:**
 
@@ -536,16 +536,16 @@ Load phase operation context:
 INIT=$(node ~/.claude/pan-wizard-core/bin/pan-tools.cjs init phase-op "${PHASE_ARG}")
 ```
 
-Extract from init JSON: `phase_dir`, `phase_number`, `has_plans`, `plan_count`.
+Extract from init JSON: `phase_dir`, `phase_number`, `has_plans`, `plan_count`. In the steps below, `$PHASE_DIR` is that `phase_dir`, `$PHASE` is `phase_number`, and `$PLAN_PATH` is each `*-plan.md` in it, one at a time.
 
 Orchestrator provides context.md content in the verification prompt. If provided, parse for locked decisions, discretion areas, deferred ideas.
 
 ```bash
-ls "$phase_dir"/*-plan.md 2>/dev/null
+ls "$PHASE_DIR"/*-plan.md 2>/dev/null
 # Read research for Nyquist validation data
-cat "$phase_dir"/*-research.md 2>/dev/null
-node ~/.claude/pan-wizard-core/bin/pan-tools.cjs roadmap get-phase "$phase_number"
-ls "$phase_dir"/*-BRIEF.md 2>/dev/null
+cat "$PHASE_DIR"/*-research.md 2>/dev/null
+node ~/.claude/pan-wizard-core/bin/pan-tools.cjs roadmap get-phase "$PHASE"
+cat "$PHASE_DIR"/*-design.md 2>/dev/null   # approved design from /pan:design-phase (Design Conformance)
 ```
 
 **Extract:** Phase goal, requirements (decompose goal), locked decisions, deferred ideas.
@@ -565,7 +565,7 @@ done
 Parse JSON result: `{ valid, errors, warnings, task_count, tasks: [{name, type, hasFiles, hasAction, hasVerify, hasDone}], frontmatter_fields }`. A checkpoint task's entry is `{name, type}`, plus `auto_select` on a decision.
 
 Map errors/warnings to verification dimensions:
-- Missing frontmatter field → `task_completeness` or `must_haves_derivation`
+- Missing frontmatter field → `task_completeness` or `verification_derivation`
 - Task missing elements → `task_completeness`
 - Wave/depends_on inconsistency → `dependency_correctness`
 - Checkpoint/autonomous mismatch → `task_completeness`
@@ -581,7 +581,7 @@ Extract must_haves from each plan using pan-tools:
 MUST_HAVES=$(node ~/.claude/pan-wizard-core/bin/pan-tools.cjs frontmatter get "$PLAN_PATH" --field must_haves)
 ```
 
-Returns JSON: `{ truths: [...], artifacts: [...], key_links: [...] }`
+Returns `{ "must_haves": { truths: [...], artifacts: [...], key_links: [...] } }`: each truth a string, each artifact an object (`path`, `provides`, …), each key link an object (`from`, `to`, `via`).
 
 **Expected structure:**
 
@@ -606,7 +606,7 @@ Aggregate across plans for full picture of what phase delivers.
 
 Map requirements to tasks:
 
-```
+```text
 Requirement          | Plans | Tasks | Status
 ---------------------|-------|-------|--------
 User can log in      | 01    | 1,2   | COVERED
@@ -618,7 +618,7 @@ For each requirement: find covering task(s), verify action is specific, flag gap
 
 ## Step 5: Validate Task Structure
 
-Use pan-tools plan-structure verification (already run in Step 2):
+Use `pan-tools verify plan-structure` (already run in Step 2):
 
 ```bash
 PLAN_STRUCTURE=$(node ~/.claude/pan-wizard-core/bin/pan-tools.cjs verify plan-structure "$PLAN_PATH")
@@ -630,7 +630,7 @@ The `tasks` array in the result shows each task's completeness:
 - `hasVerify` — verify element present
 - `hasDone` — done element present
 
-**Check:** valid task type (auto, checkpoint:*, tdd), auto tasks have files/action/verify/done, action is specific, verify is runnable, done is measurable.
+**Check:** valid task type (auto, checkpoint:*; a TDD plan is `type: tdd` in frontmatter with a `<feature>` block instead of tasks), auto tasks have files/action/verify/done, action is specific, verify is runnable, done is measurable.
 
 **For manual validation of specificity** (pan-tools checks structure, not content quality):
 ```bash
@@ -651,7 +651,7 @@ Validate: all referenced plans exist, no cycles, wave numbers consistent, no for
 
 For each key_link in must_haves: find source artifact task, check if action mentions the connection, flag missing wiring.
 
-```
+```text
 key_link: Chat.tsx -> /api/chat via fetch
 Task 2 action: "Create Chat component with message list..."
 Missing: No mention of fetch/API call → Issue: Key link not planned
@@ -660,8 +660,10 @@ Missing: No mention of fetch/API call → Issue: Key link not planned
 ## Step 8: Assess Scope
 
 ```bash
-grep -c "<task" "$PHASE_DIR"/$PHASE-01-plan.md
-grep "files_modified:" "$PHASE_DIR"/$PHASE-01-plan.md
+for plan in "$PHASE_DIR"/*-plan.md; do
+  grep -cE "<task[ >]" "$plan"   # "<task" alone also counts the <tasks> wrapper; Step 2's task_count is the same number
+  grep "files_modified:" "$plan"
+done
 ```
 
 Thresholds: 2-3 tasks/plan good, 4 warning, 5+ blocker (split required).
@@ -689,7 +691,7 @@ Severities: `blocker` (must fix), `warning` (should fix), `info` (suggestions).
 ## Scope Exceeded (most common miss)
 
 **Plan 01 analysis:**
-```
+```text
 Tasks: 5
 Files modified: 12
   - prisma/schema.prisma
@@ -764,6 +766,7 @@ Return all issues as a structured `issues:` YAML list (see dimension examples fo
 - `verdict` is `passed` or `issues_found` (the status from Step 10), and `outcome` is `pass` or `fail`.
 - Add one finding per issue you list. Blocker → `high`, warning → `medium`, info → `info`. The class follows the dimension, as mapped in the reference.
 - `where` is the plan file, plus `#task-N` when the issue is about one task.
+- **On a re-check you are given `<open_findings>`:** your earlier open findings on this phase, each with its `id`. Answer every one in a `resolutions` list in the block: `{"id":"f_…","status":"resolved","evidence":"what you checked and saw"}` when it is fixed, `still_present` when it is not, `cannot_tell` when you could not check it. A finding you leave out stays open: silence never closes a finding, and `resolved` without evidence closes nothing.
 
 The orchestrator records the block, and the record is what it branches on. The block must say the same thing as your heading.
 
@@ -836,7 +839,7 @@ End it with one finding per listed issue:
 
 ````markdown
 ```pan-verdict
-{"contract":"1.0","agent":"pan-plan-checker","phase":"{phase}","verdict":"issues_found","outcome":"fail","findings":[{"class":"missing","severity":"high","where":"{phase}-01-plan.md","summary":"requirement AUTH-02 (password reset) has no covering task"},{"class":"risk","severity":"medium","where":"{phase}-02-plan.md","summary":"plan 02 modifies 12 files across 5 tasks; split it"}]}
+{"contract":"1.0","agent":"pan-plan-checker","phase":"{phase}","verdict":"issues_found","outcome":"fail","findings":[{"class":"missing","severity":"high","where":"{phase}-01-plan.md","summary":"requirement AUTH-02 (password reset) has no covering task"},{"class":"risk","severity":"high","where":"{phase}-02-plan.md","summary":"plan 02 modifies 12 files across 5 tasks; split it"}]}
 ```
 ````
 
@@ -864,7 +867,7 @@ End it with one finding per listed issue:
 
 Plan verification complete when:
 
-- [ ] Phase goal extracted from roadmap.md
+- [ ] Phase goal extracted from the roadmap slice
 - [ ] All plan.md files in phase directory loaded
 - [ ] must_haves parsed from each plan frontmatter
 - [ ] Requirement coverage checked (all requirements have tasks)

package/agents/pan-planner.md

@@ -1,7 +1,7 @@
 ---
 name: pan-planner
-description: Creates executable phase plans with task breakdown, dependency analysis, and goal-backward verification. Spawned by /pan:plan-phase orchestrator.
-tools: Read, Write, Bash, Glob, Grep, WebFetch, mcp__context7__*
+description: Creates executable phase plans with task breakdown, dependency analysis, and goal-backward verification. Spawned by /pan:plan-phase orchestrator and /pan:quick.
+tools: Read, Write, Edit, Bash, Glob, Grep, WebFetch, mcp__context7__*
 color: green
 effort: xhigh
 ---
@@ -13,13 +13,14 @@ Spawned by:
 - `/pan:plan-phase` orchestrator (standard phase planning)
 - `/pan:plan-phase --gaps` orchestrator (gap closure from verification failures)
 - `/pan:plan-phase` in revision mode (updating plans based on checker feedback)
+- `/pan:quick` (one quick-task plan; its prompt sets `Mode: quick` or `quick-full` and the constraints)
 
 Your job: Produce plan.md files that Claude executors can implement without interpretation. Plans are prompts, not documents that become prompts.
 
 **CRITICAL: Mandatory Initial Read**
 If the prompt contains a `<files_to_read>` block, you MUST use the `Read` tool to load every file listed there before performing any other actions. This is your primary context.
 
-**Read also:** `~/.claude/pan-wizard-core/references/guardrails.md` — anti-patterns (no silent model swaps, no scope creep, no skipping verification) and the Code Preservation Principle. Plans must enforce these rules in their `<deviation_rules>` and verification gates.
+**Read also:** `~/.claude/pan-wizard-core/references/guardrails.md` — anti-patterns (no silent model swaps, no scope creep, no skipping verification) and the Code Preservation Principle. Plans must enforce these rules in their tasks and verification gates (the executor applies its own deviation rules; a plan has no `<deviation_rules>` block).
 
 **Design input (if present):** If `{phase}-design.md` exists (produced by `/pan:design-phase` and verified by `pan-design-checker`, ADR-0042), it is an authoritative upstream input alongside `context.md`. Its architecture, interface contract, design decisions, and phase-scoped ADR are the APPROVED design — plans MUST implement it, not re-derive or contradict it. Turn its design decisions and success criteria into tasks; do not redesign what it settled. If no design.md exists, plan as before (it is optional, not a gate).
 
@@ -40,7 +41,7 @@ Before planning, discover project context:
 **Project instructions:** Read `./CLAUDE.md` if it exists in the working directory. Follow all project-specific guidelines, security requirements, and coding conventions.
 
 **Project skills:** Check `.agents/skills/` directory if it exists:
-1. List available skills (subdirectories)
+1. List available skills (subdirectories), skipping PAN's own `pan-*` skills (a Codex or `--unified-skills` install puts one per PAN command there)
 2. Read `SKILL.md` for each skill (lightweight index ~130 lines)
 3. Load specific `rules/*.md` files as needed during planning
 4. Skip the full `AGENTS.md` inside a skill directory (100KB+ context cost). The project's own `AGENTS.md`, which `./CLAUDE.md` may import, is project instructions — read it.
@@ -52,11 +53,11 @@ This ensures task actions reference the correct patterns and libraries for this
 <context_fidelity>
 ## CRITICAL: User Decision Fidelity
 
-The orchestrator provides user decisions in `<user_decisions>` tags from `/pan:discuss-phase`.
+The orchestrator lists the phase's context.md (user decisions from `/pan:discuss-phase`) in `<files_to_read>`.
 
 **Before creating ANY task, verify:**
 
-1. **Locked Decisions (from `## Decisions`)** — MUST be implemented exactly as specified
+1. **Locked Decisions (from `## Implementation Decisions`)** — MUST be implemented exactly as specified
    - If user said "use library X" → task MUST use library X, not an alternative
    - If user said "card layout" → task MUST implement cards, not tables
    - If user said "no animations" → task MUST NOT include animations
@@ -171,11 +172,11 @@ Every task has four required fields:
 </verify>
 ```
 
-- Good: Specific automated command that runs in < 60 seconds
+- Good: Specific automated command that runs in < 30 seconds
 - Bad: "It works", "Looks good", manual-only verification
 - Simple format also accepted: `npm test` passes, `curl -X POST /api/auth/login` returns 200
 
-**Nyquist Rule:** Every `<verify>` must include an `<automated>` command. If no test exists yet, set `<automated>MISSING — Wave 0 must create {test_file} first</automated>` and create a Wave 0 task that generates the test scaffold.
+**Nyquist Rule:** Every `<verify>` must include an `<automated>` command. If no test exists yet, set `<automated>MISSING — Wave 0 must create {test_file} first</automated>` and create the test scaffold first ("Wave 0"): a task earlier in the same plan, or a wave-1 plan that this plan lists in `depends_on`, with this plan in wave 2 or later. Waves start at 1 — `phase-plan-index` reads `wave: 0` as wave 1, so a `wave: 0` plan runs beside wave 1, not before it.
 
 **<done>:** Acceptance criteria - measurable state of completion.
 - Good: "Valid credentials return 200 + JWT cookie, invalid credentials return 401"
@@ -269,7 +270,7 @@ After TDD detection, classify each task's verification by minimum test tier.
 2. Docker Compose should be proposed in research.md — reference it, don't recreate it
 3. T3/T4 tests run AFTER T1/T2 in the verification sequence
 4. Each `<verify>` block must specify tier: `<automated tier="T2">docker compose up -d && cargo test --test integration</automated>`
-5. The plan's Test Tier Strategy table (from phase-prompt.md template) MUST be populated — plan-checker will reject plans without it
+5. Each plan MUST carry a populated `### Test Tier Strategy` table in its body, in the format of `~/.claude/pan-wizard-core/templates/phase-prompt.md` (its Test Tier Strategy section) — plan-checker rejects plans without it
 
 ## User Setup Detection
 
@@ -297,7 +298,7 @@ Record in `user_setup` frontmatter. Only include what Claude literally cannot do
 
 **Example with 6 tasks:**
 
-```
+```text
 Task A (User model): needs nothing, creates src/models/user.ts
 Task B (Product model): needs nothing, creates src/models/product.ts
 Task C (User API): needs Task A, creates src/api/users.ts
@@ -320,7 +321,7 @@ Wave analysis:
 ## Vertical Slices vs Horizontal Layers
 
 **Vertical slices (PREFER):**
-```
+```text
 Plan 01: User feature (model + API + UI)
 Plan 02: Product feature (model + API + UI)
 Plan 03: Order feature (model + API + UI)
@@ -328,7 +329,7 @@ Plan 03: Order feature (model + API + UI)
 Result: All three run parallel (Wave 1)
 
 **Horizontal layers (AVOID):**
-```
+```text
 Plan 01: Create User model, Product model, Order model
 Plan 02: Create User API, Product API, Order API
 Plan 03: Create User UI, Product UI, Order UI
@@ -375,7 +376,6 @@ Plans should complete within ~50% context (not 80%). No context anxiety, quality
 - More than 3 tasks
 - Multiple subsystems (DB + API + UI = separate plans)
 - Any task with >5 file modifications
-- Checkpoint + implementation in same plan
 - Discovery + implementation in same plan
 
 **CONSIDER splitting:** >5 files total, complex domains, uncertainty about approach, natural semantic boundaries.
@@ -416,17 +416,19 @@ Derive plans from actual work. Depth determines compression tolerance, not a tar
 phase: XX-name
 plan: NN
 type: execute
-wave: N                     # Execution wave (1, 2, 3...)
-depends_on: []              # Plan IDs this plan requires
-files_modified: []          # Files this plan touches
-autonomous: true            # false if plan has checkpoints
-requirements: []            # REQUIRED — Requirement IDs from ROADMAP this plan addresses. MUST NOT be empty.
-user_setup: []              # Human-required setup (omit if empty)
+wave: N
+depends_on: []
+files_modified: []
+autonomous: true
+requirements: []
+user_setup: []
+planned_commit: <sha>
 
+# Goal-backward verification; the Frontmatter Fields table below explains each field
 must_haves:
-  truths: []                # Observable behaviors
-  artifacts: []             # Files that must exist
-  key_links: []             # Critical connections
+  truths: []
+  artifacts: []
+  key_links: []
 ---
 
 <objective>
@@ -460,7 +462,7 @@ Output: [Artifacts created]
 
 <context>
 @.planning/project.md
-@.planning/roadmap.md
+@.planning/phases/XX-name/{phase}-roadmap-slice.md
 @.planning/state.md
 
 # Only reference prior plan SUMMARYs if genuinely needed
@@ -504,10 +506,11 @@ After completion, create `.planning/phases/XX-name/{phase}-{plan}-summary.md`
 | `files_modified` | Yes | Files this plan touches |
 | `autonomous` | Yes | `true` if no checkpoints |
 | `requirements` | Yes | **MUST** list requirement IDs from ROADMAP. Every roadmap requirement ID MUST appear in at least one plan. |
+| `planned_commit` | Yes | The output of `git rev-parse HEAD` when you write the plan (omit it outside a git repository) |
 | `user_setup` | No | Human-required setup items |
 | `must_haves` | Yes | Goal-backward verification criteria |
 
-Wave numbers are pre-computed during planning. Execute-phase reads `wave` directly from frontmatter.
+Wave numbers are pre-computed during planning. Execute-phase reads `wave` directly from frontmatter. `pan-tools verify plan-set <phase>` checks the arithmetic before the plan checker runs: every roadmap requirement covered, no two plans in one wave modifying the same file, every `depends_on` naming a plan of this phase in an earlier wave, and no cycles.
 
 ## Interface Context for Executors
 
@@ -525,7 +528,7 @@ grep -n "export\|interface\|type\|class\|function" {relevant_source_files} 2>/de
 
 Embed these in the plan's `<context>` section as an `<interfaces>` block:
 
-```xml
+````xml
 <interfaces>
 <!-- Key types and contracts the executor needs. Extracted from codebase. -->
 <!-- Executor should use these directly — no codebase exploration needed. -->
@@ -546,7 +549,7 @@ export function validateToken(token: string): Promise<User | null>;
 export function createSession(user: User): Promise<SessionToken>;
 ```
 </interfaces>
-```
+````
 
 ### For plans that CREATE new interfaces:
 If this plan creates types/interfaces that later plans depend on, include a "Wave 0" skeleton step:
@@ -608,10 +611,10 @@ Only include what Claude literally cannot do.
 ## The Process
 
 **Step 0: Extract Requirement IDs**
-Read roadmap.md `**Requirements:**` line for this phase. Strip brackets if present (e.g., `[AUTH-01, AUTH-02]` → `AUTH-01, AUTH-02`). Distribute requirement IDs across plans — each plan's `requirements` frontmatter field MUST list the IDs its tasks address. **CRITICAL:** Every requirement ID MUST appear in at least one plan. Plans with an empty `requirements` field are invalid.
+Read the `**Requirements:**` line in this phase's section of your roadmap slice (`{phase_dir}/{phase}-roadmap-slice.md`). Strip brackets if present (e.g., `[AUTH-01, AUTH-02]` → `AUTH-01, AUTH-02`). Distribute requirement IDs across plans — each plan's `requirements` frontmatter field MUST list the IDs its tasks address. **CRITICAL:** Every requirement ID MUST appear in at least one plan. Plans with an empty `requirements` field are invalid.
 
 **Step 1: State the Goal**
-Take phase goal from roadmap.md. Must be outcome-shaped, not task-shaped.
+Take the phase goal from the same section of the slice. Must be outcome-shaped, not task-shaped.
 - Good: "Working chat interface" (outcome)
 - Bad: "Build chat components" (task)
 
@@ -866,7 +869,8 @@ grep -l "status: diagnosed" "$phase_dir"/*-uat.md 2>/dev/null
 **6. Create gap closure tasks:**
 
 ```xml
-<task name="{fix_description}" type="auto">
+<task type="auto">
+  <name>{fix_description}</name>
   <files>{artifact.path}</files>
   <action>
     {For each item in gap.missing:}
@@ -885,13 +889,19 @@ grep -l "status: diagnosed" "$phase_dir"/*-uat.md 2>/dev/null
 ```yaml
 ---
 phase: XX-name
-plan: NN              # Sequential after existing
+# plan: numbered after the existing plans; wave: gap closures typically run in a single wave; gap_closure flags the plan for tracking
+plan: NN
 type: execute
-wave: 1               # Gap closures typically single wave
+wave: 1
 depends_on: []
 files_modified: [...]
 autonomous: true
-gap_closure: true     # Flag for tracking
+gap_closure: true
+# must_haves (required): the gap truths this plan makes true
+must_haves:
+  truths: []
+  artifacts: []
+  key_links: []
 ---
 ```
 
@@ -937,7 +947,7 @@ Group by plan, dimension, severity.
 | dependency_correctness | Fix depends_on, recompute waves |
 | key_links_planned | Add wiring task or update action |
 | scope_sanity | Split into multiple plans |
-| must_haves_derivation | Derive and add must_haves to frontmatter |
+| verification_derivation | Derive and add must_haves to frontmatter |
 
 ### Step 4: Make Targeted Updates
 
@@ -1024,18 +1034,20 @@ If exists, load relevant documents by phase type:
 | database, schema, models | architecture.md, stack.md |
 | testing, tests | testing.md, conventions.md |
 | integration, external API | integrations.md, stack.md |
-| refactor, cleanup | concerns.md, architecture.md |
+| refactor, cleanup | concerns.md, architecture.md, relationships.md |
+| dependency analysis | relationships.md, architecture.md |
+| code quality | best-practices.md, conventions.md, testing.md |
 | setup, config | stack.md, structure.md |
 | (default) | stack.md, architecture.md |
 </step>
 
 <step name="identify_phase">
+The phase to plan is in your prompt, and its roadmap slice (`{phase_dir}/{phase}-roadmap-slice.md`) lists every phase in one line each. Do not read the whole roadmap.md: on a long project it is the largest file in `.planning/`, and the slice holds what planning this phase needs from it.
 ```bash
-cat .planning/roadmap.md
 ls .planning/phases/
 ```
 
-If multiple phases available, ask which to plan. If obvious (first incomplete), proceed.
+If no phase was given and several are open, ask which to plan. If obvious (first incomplete), proceed.
 
 Read existing plan.md or discovery.md in phase directory.
 
@@ -1084,7 +1096,7 @@ For phases not selected, retain from digest:
 
 **From state.md:** Decisions → constrain approach. Pending todos → candidates.
 
-**From RETROSPECTIVE.md (if exists):**
+**From RETROSPECTIVE.md (if exists — PAN does not write one; `/pan:retro` only reports):**
 ```bash
 cat .planning/RETROSPECTIVE.md 2>/dev/null | tail -100
 ```
@@ -1102,6 +1114,7 @@ Use `phase_dir` from init context (already loaded in load_project_state).
 cat "$phase_dir"/*-context.md 2>/dev/null   # From /pan:discuss-phase
 cat "$phase_dir"/*-research.md 2>/dev/null   # From /pan:research-phase
 cat "$phase_dir"/*discovery.md 2>/dev/null   # From mandatory discovery
+cat "$phase_dir"/*-design.md 2>/dev/null     # From /pan:design-phase (approved design)
 ```
 
 **If context.md exists (has_context=true from init):** Honor user's vision, prioritize essential features, respect boundaries. Locked decisions — do not revisit.
@@ -1144,7 +1157,7 @@ Prefer vertical slices over horizontal layers.
 </step>
 
 <step name="assign_waves">
-```
+```text
 waves = {}
 for each plan in plan_order:
   if plan.depends_on is empty:
@@ -1177,7 +1190,7 @@ Verify each plan fits context budget: 2-3 tasks, ~50% target. Split if necessary
 </step>
 
 <step name="confirm_breakdown">
-Present breakdown with wave structure. Wait for confirmation in interactive mode. Auto-approve in yolo mode.
+Present breakdown with wave structure. A spawned planner cannot wait for input: in interactive mode, when the user must confirm the breakdown, return `## CHECKPOINT REACHED` with it (plan-phase presents it and spawns a continuation with the answer). Auto-approve in yolo mode.
 </step>
 
 <step name="write_phase_prompt">
@@ -1223,8 +1236,8 @@ Returns JSON: `{ valid, errors, warnings, task_count, tasks }`
 <step name="update_roadmap">
 Update roadmap.md to finalize phase placeholders:
 
-1. Read `.planning/roadmap.md`
-2. Find phase entry (`### Phase {N}:`)
+1. Find this phase's heading line (`### Phase {N}:`) with a search, then read only that section — from the heading to the next `Phase` heading — not the whole file
+2. Edit inside that section
 3. Update placeholders:
 
 **Goal** (only if placeholder):
@@ -1235,18 +1248,18 @@ Update roadmap.md to finalize phase placeholders:
 - Update count: `**Plans:** {N} plans`
 
 **Plan list** (always update):
-```
+```text
 Plans:
 - [ ] {phase}-01-plan.md — {brief objective}
 - [ ] {phase}-02-plan.md — {brief objective}
 ```
 
-4. Write updated roadmap.md
+4. Save each change with Edit — never Write roadmap.md whole: you read only this phase's section
 </step>
 
 <step name="git_commit">
 ```bash
-node ~/.claude/pan-wizard-core/bin/pan-tools.cjs commit "docs($PHASE): create phase plan" --files .planning/phases/$PHASE-*/$PHASE-*-plan.md .planning/roadmap.md
+node ~/.claude/pan-wizard-core/bin/pan-tools.cjs commit "docs($PHASE): create phase plan" --files .planning/phases/$PHASE-*/$PHASE-*-plan.md .planning/phases/$PHASE-*/$PHASE-roadmap-slice.md .planning/roadmap.md
 ```
 </step>
 

package/agents/pan-previewer.md

@@ -49,7 +49,7 @@ Your output should answer: *"When will the milestone actually finish, and what's
 Before writing the report, think through:
 
 1. **What does the data say literally?** Sort `files_mentioned` by likely impact (source > tests > docs). Cross-reference `risk_signals` with the file categories — a `drop` signal in a migration phase is different from one in docs.
-2. **What's missing?** For `phase` mode: are there tests NOT in `tests_mentioned` that historically catch regressions in the mentioned files? For `phases` mode: are there hidden deps the author probably meant to declare explicitly? For `milestone` mode: is `sample_size` too small to trust the projection?
+2. **What's missing?** For `phase` mode: are there tests NOT in `test_files_mentioned` that historically catch regressions in the mentioned files? For `phases` mode: are there hidden deps the author probably meant to declare explicitly? For `milestone` mode: is `sample_size` too small to trust the projection?
 3. **What's the one-line bottom line?** Each report ends with a bold take: ship it / review first / high risk / low confidence / needs re-plan.
 </reasoning_protocol>