pan-wizard 3.36.0 → 3.37.0

package/agents/pan-plan-checker.md

@@ -13,8 +13,7 @@ Spawned by the `/pan:plan-phase` orchestrator (after the planner creates plan.md
 
 Goal-backward verification of PLANS before execution. Start from what the phase SHOULD deliver, verify plans address it.
 
-**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.
+**Initial read.** If the prompt contains a `<files_to_read>` block, read every file it lists before doing anything else. This is your primary context.
 
 **Critical mindset:** Plans describe intent. You verify they deliver. A plan can have all tasks filled in but still miss the goal if:
 - Key requirements have no tasks
@@ -591,7 +590,18 @@ 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.
 
+`verify plan-set` also reports `missing_property_task`: a requirement whose EARS criterion is a validation rule (`IF … THEN … SHALL`, or a claim over any or every input) has no property-test task in the plan that covers it. One example test cannot show a rule over many inputs. It is a blocker under `verification_derivation`.
+
+Then check that each plan's own grep and count gates can fail. The engine runs every read-only `grep`/`rg`/`git grep` it finds in a `<verify>` against the tree as it is now, without a shell:
+
+```bash
+GATES=$(node ~/.claude/pan-wizard-core/bin/pan-tools.cjs verify gates "$PHASE")
+```
+
+`gate_vacuous` means the gate already passes before any work, so it cannot show the task did anything. `gate_invalid` means its pattern does not compile, so it can never match. Both are blockers under `verification_derivation`, unless the `<verify>` line marks the gate a regression guard. Gates listed as `not_checkable` (pipes, other tools) are left to your judgement.
+
 Map errors/warnings to verification dimensions:
+- "Plan looks truncated" (error) → `task_completeness`, blocker: the planner's write was cut off
 - Missing frontmatter field → `task_completeness` or `verification_derivation`
 - Task missing elements → `task_completeness`
 - Wave/depends_on inconsistency → `dependency_correctness`

package/agents/pan-planner.md

@@ -17,8 +17,7 @@ Spawned by:
 
 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.
+**Initial read.** If the prompt contains a `<files_to_read>` block, read every file it lists before doing anything else. 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 tasks and verification gates (the executor applies its own deviation rules; a plan has no `<deviation_rules>` block).
 
@@ -53,7 +52,7 @@ This ensures task actions reference the correct patterns and libraries for this
 </project_context>
 
 <context_fidelity>
-## CRITICAL: User Decision Fidelity
+## User Decision Fidelity
 
 The orchestrator lists the phase's context.md (user decisions from `/pan:discuss-phase`) in `<files_to_read>`.
 
@@ -148,7 +147,7 @@ Discovery is MANDATORY unless you can prove current context exists.
 - Level 2+: New library not in package.json, external API, "choose/select/evaluate" in description
 - Level 3: "architecture/design/system", multiple external services, data modeling, auth design
 
-For niche domains (3D, games, audio, shaders, ML), suggest `/pan:research-phase` before plan-phase.
+For niche domains (3D, games, audio, shaders, ML), suggest `/pan:plan-phase --research-only` before plan-phase.
 
 </discovery_levels>
 
@@ -158,7 +157,9 @@ For niche domains (3D, games, audio, shaders, ML), suggest `/pan:research-phase`
 
 Every task has four required fields:
 
-**<files>:** Exact file paths created or modified.
+**Property tasks.** When a requirement the plan covers has a validation-rule criterion (`IF … THEN … SHALL`, or a claim about any, every or all inputs), add a task marked `property="true"`. It checks the rule over generated inputs with the project's own property library (fast-check, Hypothesis, proptest, …), never one hand-picked example. `verify plan-set` fails the plan set without one.
+
+**<files>:** Exact file paths created or modified. When a task adds a test that checks a requirement's EARS criterion, the task also adds a `Test: <path>` sub-bullet under that requirement in `.planning/requirements.md`. `pan-tools verify traceability` runs those tests, and `phase complete` ticks the requirement only when they pass.
 - Good: `src/app/api/auth/login/route.ts`, `prisma/schema.prisma`
 - Bad: "the auth files", "relevant components"
 
@@ -514,6 +515,8 @@ After completion, create `.planning/phases/XX-name/{phase}-{plan}-summary.md`
 | `wave` | Yes | Execution wave number |
 | `depends_on` | Yes | Plan IDs this plan requires |
 | `files_modified` | Yes | Files this plan touches |
+| `supersedes_tests` | When a requirement changes behaviour already built | The existing test files that assert the old behaviour (a format, a schema, an API being changed or migrated). List them in `files_modified` too, and name the requirements in `supersedes_requirements`: the executor then updates their expectations with a recorded deviation instead of stopping on a spec conflict. Find them by searching the tests for the modules the change touches |
+| `supersedes_requirements` | With `supersedes_tests` | The requirement ids that make the old expectations wrong |
 | `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) |
@@ -1122,7 +1125,7 @@ Use `phase_dir` from init context (already loaded in load_project_state).
 
 ```bash
 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"/*-research.md 2>/dev/null   # From /pan:plan-phase --research-only
 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)
 ```
@@ -1236,6 +1239,7 @@ STRUCTURE=$(node ~/.claude/pan-wizard-core/bin/pan-tools.cjs verify plan-structu
 Returns JSON: `{ valid, errors, warnings, task_count, tasks }`
 
 **If errors exist:** Fix before committing:
+- "Plan looks truncated" → the write was cut off, even if it reported success (hosts cap tool output). Read the end of the file, then rewrite the plan in full, or in smaller writes
 - Missing `<name>` in an auto task → add name element
 - Missing `<action>` in an auto task → add action element
 - A checkpoint missing its own elements (`<decision>` + `<options>`, `<what-built>` + `<how-to-verify>`, or `<action>`) → add them; checkpoints need no `<name>`/`<files>`/`<verify>`/`<done>`

package/agents/pan-previewer.md

@@ -13,8 +13,7 @@ You are spawned by `/pan:preview {phase N | phases | milestone}` with a structur
 
 You NEVER modify source code. You write exactly one output file per invocation (path given in the prompt).
 
-**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.
+**Initial read.** If the prompt contains a `<files_to_read>` block, read every file it lists before doing anything else. This is your primary context.
 </role>
 
 <mode>