prizmkit 1.1.145 → 1.1.147

package/bundled/skills/refactor-planner/references/planning-phases.md

@@ -47,13 +47,31 @@ Offer `Accept`, `Modify`, and `Skip` as selectable options. Re-display modified
 2. **Behavior preservation check**: Every item must have a declared preservation strategy. Flag any item with `manual` strategy and no test coverage.
 3. **Gap detection**: Are there intermediate steps needed between items? Does item A's output match item B's input assumption?
 4. **Cross-module impact**: Do any items affect modules outside the declared scope?
-5. **Headless Execution Readiness**: The refactor pipeline runs each item through an autonomous AI session with NO human interaction. For each item, verify:
-   - **Scope clarity**: Are all affected files explicitly listed? The AI must know exactly where to look.
-   - **Refactoring instructions**: Is the description specific enough to execute without ambiguity?
-     - ❌ "Clean up the utils module" — what exactly should change?
-     - ✅ "Extract validation functions (validateEmail, validatePhone, validateUrl) from src/utils/helpers.ts into src/utils/validation.ts. Update all 12 import sites. Preserve existing function signatures."
-   - **Behavior preservation**: Is it clear what tests to run and what behavior must be preserved?
-   - **Dependency context**: If item depends on earlier refactors, does the description reference what changed?
+5. **Headless Context Completeness Gate**: Review every new or changed item as if the reviewer has never seen the planning conversation. Preserve unchanged historical items. First assess `description` plus `acceptance_criteria` without `user_context`, then answer from the artifact alone:
+   1. What exact problem or outcome is this task responsible for?
+   2. What current architecture exists and what target architecture must replace it?
+   3. Which approach was selected, expressed by meaning rather than an option label?
+   4. What scope boundaries, constraints, and non-goals must be preserved?
+   5. Why is each reference material and target path relevant, and what should be inspected?
+   6. Which integrations, consumers, import paths, and edge cases are affected?
+   7. Which behavior-preservation decisions and completion evidence prove equivalence?
+   8. Does any phrase require an unseen earlier question, recommendation, or option list?
+   9. Do quoted source materials agree with the final task decision?
+
+   Return `NEEDS_FIXES` whenever any answer is missing, ambiguous, or available only in `user_context`. Ask the user for clarification when a relative statement has more than one plausible antecedent; never guess.
+
+   - **Scope clarity**: List all affected files and explain each file or coherent group as purpose-tagged target paths.
+   - **Target architecture**: State concrete module ownership, interfaces, dependency direction, compatibility boundaries, and desired end state.
+   - **Behavior preservation**: State what tests, snapshots, or reproducible checks run and which observable behavior must remain equivalent.
+   - **Dependency context**: State which exact earlier refactor output this item consumes.
+   - **Good**: `Extract validateEmail, validatePhone, and validateUrl from src/utils/helpers.ts into src/utils/validation.ts; update all 12 import sites; preserve signatures and error semantics. src/utils/helpers.ts — inspect current exports and callers before extraction.`
+   - **Bad**: `Clean up the utils module`, `方案B`, `按推荐走`, `use option A`, `same as above`, or `go with your recommendation`.
+   - **Good normalization**: `Selected decision: introduce an auth-owned validation module while retaining existing public imports through compatibility re-exports (original response: "方案B")`.
+   - **Bad material handling**: embed an entire architecture RFC while saying `apply this`.
+   - **Good material handling**: `Auth Architecture RFC §5 — inspect dependency-direction and compatibility requirements`, preserve task-relevant exact excerpts, and move confirmed decisions into the task contract.
+   - Exclude conversational authorization such as `所有问题都按你的推荐处理` when it does not constrain implementation.
+   - `user_context` is supplementary evidence only. If `user_context` were removed, execution and verification must remain unambiguous at matching detail.
+   - Do not add new JSON fields, context objects, schema versions, or pipeline runtime structures.
 
 ### Review Summary Table Format
 
@@ -67,7 +85,7 @@ R-003      | low      | Local readability only    | low        | One file, no AP
 R-004      | medium   | Reduces bounded coupling  | medium     | 2 modules + snapshot check  | OK         | snapshot     | -              | Ready
 ```
 
-If issues found, discuss with user and resolve before proceeding.
+If issues are found, discuss with the user, apply fixes to the draft/source item, and rerun the Headless Context Completeness Gate until every new or changed item returns `PASS` before proceeding.
 
 ---
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "prizmkit",
-  "version": "1.1.145",
+  "version": "1.1.147",
   "description": "Create a new PrizmKit-powered project with clean initialization — no framework dev files, just what you need.",
   "type": "module",
   "bin": {