pan-wizard 3.32.0 → 3.34.0

package/commands/pan/resume.md

@@ -62,22 +62,20 @@ ELSE IF .continue-here.md exists:
   → PRESENT: position, blockers, next action
   → ROUTE to the command that was paused (exec-phase, plan-phase, etc.)
 
-ELSE IF state.md exists AND has status "in_progress":
+ELSE IF state.md exists (its Status is free text — Ready to plan, Ready to execute, In progress, Phase complete, Milestone complete and the like; none says "blocked"):
+  → IF state.md's `### Blockers/Concerns` lists a blocker:
+    → PRESENT the blockers first
+    → OFFER: debug (/pan:debug) or unblock manually
   → FIND incomplete work: plans without summaries, phases mid-execution
   → IF incomplete phase found:
     → PRESENT phase status + what remains
     → OFFER: continue execution (/pan:exec-phase) or verify (/pan:verify-phase)
-  → IF no incomplete work but active milestone:
+  → ELSE IF roadmap phases remain incomplete (`roadmap analyze`):
     → PRESENT milestone progress
-    → OFFER: next unplanned phase (/pan:plan-phase) or audit (/pan:milestone-audit)
-
-ELSE IF state.md exists AND has status "blocked":
-  → PRESENT blockers from state.md
-  → OFFER: debug (/pan:debug) or unblock manually
-
-ELSE IF state.md exists AND has status "completed":
-  → "Current milestone is complete. Run /pan:milestone-done or /pan:milestone-new."
-  → STOP
+    → OFFER: next unplanned phase (/pan:discuss-phase, or /pan:plan-phase when it has a context.md) or audit (/pan:milestone-audit)
+  → ELSE (every roadmap phase complete):
+    → "Current milestone is complete. Run /pan:milestone-audit, then /pan:milestone-done, or /pan:milestone-new."
+    → STOP
 
 ELSE (state.md missing or unreadable):
   → ATTEMPT reconstruction from .planning/ artifacts

package/commands/pan/retro.md

@@ -2,7 +2,7 @@
 name: pan:retro
 group: Milestone Lifecycle
 description: Milestone retrospective — analyze estimation accuracy, verification patterns, and common gaps
-argument-hint: ""
+argument-hint: "[--write-memory] [--max N]"
 allowed-tools:
   - Read
   - Bash
@@ -14,7 +14,7 @@ Analyze completed milestone work to identify process improvement opportunities.
 
 Examines roadmap phases (planned vs completed, gap closures), verification results (pass rates, common gaps), and estimation accuracy. Output guides future planning improvements.
 
-This is a reflection command — **read-only by default**: with no flags it does not modify any files. Passing `--write-memory` (as `/pan:army` does) is the one exception — it appends recurring-pattern entries to agent memory so they persist into the next mission.
+This is a reflection command — **read-only by default**: with no flags it does not modify any files. Passing `--write-memory` is the one exception: it appends recurring-pattern entries to the agent logs in `.planning/memory/`, which `/pan:knowledge` reads. PAN's workflows do not load those logs into agents, so a pattern meant to change the next plan goes into that plan's brief or the project's instructions.
 </objective>
 
 <execution_context>
@@ -24,8 +24,10 @@ This is a reflection command — **read-only by default**: with no flags it does
 <context>
 No arguments required. Operates on the current `.planning/` directory.
 
+Flags: $ARGUMENTS
+
 **Flags:**
-- `--write-memory` — after analysis, append recurring-pattern entries to agent memory (used by `/pan:army`). Without this flag the command is strictly read-only.
+- `--write-memory` — after analysis, append recurring-pattern entries to the agent logs in `.planning/memory/` (stored for `/pan:knowledge`, not loaded into agents). `--max N` caps the planner lessons (default 3). Without `--write-memory` the command is strictly read-only.
 
 The retro command is typically run after `/pan:milestone-done` to reflect on the milestone before starting the next one.
 </context>

package/commands/pan/review-deep.md

@@ -54,7 +54,7 @@ Runs the normal exec → reviewer pipeline, then runs this command's process inl
 /pan:focus-exec --deep-review
 ```
 
-Per-item deep review during focus campaigns. Useful for high-stakes batches.
+Per-item deep review during focus campaigns: focus-exec runs the hardener and meta-reviewer on the item's changed files and merges them under the item's id (`review-deep merge <item-id>` with no `--reviewer-file`), since an item has no phase or first-pass review. Useful for high-stakes batches.
 
 </invocation_modes>
 
@@ -67,7 +67,7 @@ Per-item deep review during focus campaigns. Useful for high-stakes batches.
    - Agent writes its findings to the output path, returns confirmation.
 
 3. **Spawn pan-meta-reviewer**:
-   - Prompt includes: `<files_to_read>` with both reviewer.md AND hardener.md (and representative diff snippets); `<output_path>` = `.planning/reviews/<N>/meta.md`.
+   - Prompt includes: `<files_to_read>` with both `{directory}/{phase_number}-review.md` AND `.planning/reviews/<N>/hardener.md` (and representative diff snippets); `<output_path>` = `.planning/reviews/<N>/meta.md`.
    - Agent reads both first-pass reports, identifies missed patterns, disputes overstated severities, writes to output path.
 
 4. **Merge** — call:
@@ -87,13 +87,13 @@ Per-item deep review during focus campaigns. Useful for high-stakes batches.
 
 | Verdict | Meaning | Action |
 |---------|---------|--------|
-| `ok` | No findings at any severity | Merge freely |
-| `ok_with_minor` | Only low/info findings | Merge with noted follow-ups |
+| `ok` | No findings, or info findings only | Merge freely |
+| `ok_with_minor` | Only low findings (info alone gives `ok`) | Merge with noted follow-ups |
 | `fix_before_merge` | Medium findings present | Fix or document before merge |
 | `review_required` | High findings present | Human sign-off required |
 | `block` | At least one critical | Do not merge |
 
-Verdict is driven by the highest-severity finding across all three sources. Meta-reviewer disputes can downgrade severity on specific findings but don't change the headline verdict — the merger trusts the consensus of the explicit severity labels.
+Verdict is driven by the highest-severity finding across all three sources. Meta-reviewer disputes are listed in the conflict table but change no severity, so they never lower the headline verdict; the meta-reviewer's own findings count toward it like the other two sources'.
 
 </verdict_semantics>
 
@@ -111,18 +111,18 @@ Verdict is driven by the highest-severity finding across all three sources. Meta
 
 | Runtime | hardener | meta-reviewer | merge |
 |---------|----------|---------------|-------|
-| Claude Code | Full, thinking enabled (6000/4000 budget) | Full | Full |
+| Claude Code | Full; reasoning depth from the agent's `effort:` frontmatter | Full | Full |
 | OpenCode | Prose "think step-by-step" preamble substitutes for thinking | Same | Full (runtime-agnostic CLI) |
 | Gemini | Same | Same | Full |
-| Codex | Same | Same | Full |
-| Copilot | Same | Same | Full |
+| Codex | Native — `effort:` becomes the agent TOML's `model_reasoning_effort` | Same | Full |
+| Copilot | Prose "think step-by-step" preamble, as on OpenCode | Same | Full |
 
-The merger CLI (`pan-tools review-deep merge`) is pure Node.js and works identically across runtimes. Only the *quality* of the hardener and meta-reviewer outputs varies with model capability — an Opus-class model with extended thinking produces the richest findings.
+The merger CLI (`pan-tools review-deep merge`) is pure Node.js and works identically across runtimes. Only the *quality* of the hardener and meta-reviewer outputs varies with model capability.
 
 </runtime_compatibility>
 
 <calibration_note>
 
-Deep review is opt-in for a reason: it costs roughly 3× a normal review (hardener + meta + merge adds two agent spawns per phase). Use it for high-stakes phases, not every phase. `--deep-review` gating by phase tags is a v3.4 candidate enhancement.
+Deep review is opt-in for a reason: it costs roughly 3× a normal review (hardener + meta + merge adds two agent spawns per phase). Use it for high-stakes phases, not every phase.
 
 </calibration_note>

package/commands/pan/settings.md

@@ -15,7 +15,7 @@ Interactive configuration of PAN workflow agents and model profile via multi-que
 Routes to the settings workflow which handles:
 - Config existence ensuring
 - Current settings reading and parsing
-- Interactive 5-question prompt (model, research, plan_check, verifier, branching)
+- Interactive multi-question prompt (model profile, research, plan_check, verifier, auto_advance, nyquist_validation, branching strategy, routing strategy)
 - Config merging and writing
 - Confirmation display with quick command references
 </objective>

package/commands/pan/todo-add.md

@@ -13,7 +13,7 @@ allowed-tools:
 <objective>
 Capture an idea, task, or issue that surfaces during a PAN session as a structured todo for later work.
 
-Routes to the add-todo workflow which handles:
+Routes to the todo-add workflow which handles:
 - Directory structure creation
 - Content extraction from arguments or conversation
 - Area inference from file paths
@@ -34,7 +34,7 @@ State is resolved in-workflow via `init todos` and targeted reads.
 </context>
 
 <process>
-**Follow the add-todo workflow** from `@~/.claude/pan-wizard-core/workflows/todo-add.md`.
+**Follow the todo-add workflow** from `@~/.claude/pan-wizard-core/workflows/todo-add.md`.
 
 The workflow handles all logic including:
 1. Directory ensuring

package/commands/pan/todo-check.md

@@ -13,7 +13,7 @@ allowed-tools:
 <objective>
 List all pending todos, allow selection, load full context for the selected todo, and route to appropriate action.
 
-Routes to the check-todos workflow which handles:
+Routes to the todo-check workflow which handles:
 - Todo counting and listing with area filtering
 - Interactive selection with full context loading
 - Roadmap correlation checking
@@ -32,7 +32,7 @@ Todo state and roadmap correlation are loaded in-workflow using `init todos` and
 </context>
 
 <process>
-**Follow the check-todos workflow** from `@~/.claude/pan-wizard-core/workflows/todo-check.md`.
+**Follow the todo-check workflow** from `@~/.claude/pan-wizard-core/workflows/todo-check.md`.
 
 The workflow handles all logic including:
 1. Todo existence checking

package/commands/pan/verify-phase.md

@@ -74,17 +74,6 @@ After initial verification of each requirement:
 This prevents premature FAIL verdicts from incomplete investigation.
 </reflexion_loop>
 
-<cache_priming>
-**Before the verifier agent runs**, prime the prompt cache once. The verifier reads project.md / requirements.md / roadmap.md every run; caching avoids ~15-50K input tokens per invocation.
-
-Run once:
-```
-pan-tools cache prime --summary
-```
-
-See [plan-phase.md](plan-phase.md) or [exec-phase.md](exec-phase.md) for the full explanation. No-op on non-Claude runtimes.
-</cache_priming>
-
 <process>
 Execute the verify-phase workflow from @~/.claude/pan-wizard-core/workflows/verify-phase.md end-to-end.
 Preserve all workflow gates (the test-suite gate, the truth/artifact/wiring checks, status determination, the verification report).

package/commands/pan/what-if.md

@@ -56,7 +56,7 @@ If worktree creation fails (not a git repo, dirty tree blocking, etc.), abort wi
 
 ### Stage 2 — Spawn pan-counterfactual
 
-Spawn the agent with its working directory set to `worktree_path`. Prompt includes:
+Spawn the agent. A spawn cannot set its working directory — it starts in the main project — so the prompt's `<worktree_path>` is where it must work. Prompt includes:
 - `<files_to_read>` — the phase plan, any existing summary, the main project's `CLAUDE.md` so the agent understands conventions.
 - `<scenario>` — the user's scenario text verbatim.
 - `<worktree_path>` — so the agent knows the safe boundary.
@@ -69,7 +69,7 @@ The agent explores, then returns a JSON payload with `{summary, differences, rec
 Run (from main tree, NOT worktree):
 
 ```
-pan-tools whatif report <phase> "<scenario>" --comparison '<agent-json>'
+pan-tools whatif report <phase> "<scenario>" --comparison "$(cat <comparison-json-file>)"
 ```
 
 This writes `.planning/counterfactuals/<phase>-<slug>.md`. The file belongs to the main tree and survives worktree cleanup.