prizmkit 1.1.106 → 1.1.108

package/bundled/dev-pipeline/templates/refactor-bootstrap-prompt.md

@@ -61,9 +61,6 @@ You are the **refactor session orchestrator**. Execute Refactor {{REFACTOR_ID}}:
 
 {{GLOBAL_CONTEXT}}
 
-### Project Conventions
-
-> Read {{PLATFORM_CONVENTIONS}} for project-level coding standards, architecture decisions, and development rules.
 
 ## Refactor Artifacts Directory
 
@@ -78,7 +75,6 @@ You are the **refactor session orchestrator**. Execute Refactor {{REFACTOR_ID}}:
 
 ## Execution Instructions
 
-{{LOG_SIZE_AWARENESS}}
 **YOU are the orchestrator. Execute each phase by spawning the appropriate team agent with run_in_background=false.**
 
 **Agent spawn failure policy (all Agent tool calls)**:
@@ -88,15 +84,7 @@ You are the **refactor session orchestrator**. Execute Refactor {{REFACTOR_ID}}:
 - Any recovery exception must be recorded in the required report or session status so downstream runs know the normal team path was unavailable.
 - Apply the same cap to any re-spawn for report repair or resume prompts; do not burn multiple minutes on identical team/config/lock failures.
 
-## Workflow Checkpoint System
-
-A checkpoint file tracks your progress through this workflow:
-
-**Path**: `{{CHECKPOINT_PATH}}`
-
-**How to use**:
-1. **Before each step**: Read `workflow-checkpoint.json`, verify the previous step has `status: "completed"` or `status: "skipped"`. If not, complete it first.
-2. **After completing a step**: Update the step's `status` to `"completed"` in `workflow-checkpoint.json`.
+{{CHECKPOINT_SYSTEM}}
 
 ### Step 1: Initialize
 
@@ -129,7 +117,7 @@ Run `/prizmkit-plan` with `artifact_dir=.prizmkit/refactor/{{REFACTOR_ID}}/`:
   - Every task ends with "run test suite to verify behavior preserved"
   - Rollback strategy
 
-Resolve any `[NEEDS CLARIFICATION]` markers using the refactor description — do NOT pause for interactive input.
+Resolve uncertain refactor details from the refactor description, existing code, and conservative existing-project patterns.
 
 {{IF_BROWSER_INTERACTION}}
 
@@ -185,7 +173,7 @@ Evidence must cover affected UI render, primary user interactions, behavior-sens
 
 {{END_IF_BROWSER_INTERACTION}}
 
-  7. If the refactor involves multiple files: update durable checkpoints/artifacts at the midpoint, minimize output, and rely on runner continuation if context overflow occurs. In an interactive Claude Code session operated manually outside the headless pipeline, `/compact` may be used as an optional convenience only.
+  7. If the refactor involves multiple files: update durable checkpoints/artifacts at the midpoint, minimize output, and rely on runner continuation if context overflow occurs.
   8. After all tasks complete, run the full test suite one final time
   "
 - **Wait for Dev to return**
@@ -204,7 +192,7 @@ Evidence must cover affected UI render, primary user interactions, behavior-sens
   Prompt: "Read {{REVIEWER_SUBAGENT_PATH}}. For refactor {{REFACTOR_ID}}:
   1. Read `.prizmkit/refactor/{{REFACTOR_ID}}/spec.md` for goals and behavior preservation contracts
   2. Read `.prizmkit/refactor/{{REFACTOR_ID}}/plan.md` for architecture decisions and completed tasks
-  3. Run `/prizmkit-code-review` with artifact_dir=.prizmkit/refactor/{{REFACTOR_ID}}/. The skill runs an internal review-fix loop (Reviewer → filter → Dev fix, max 3 rounds) and writes review-report.md.
+  3. Run `/prizmkit-code-review` with artifact_dir=.prizmkit/refactor/{{REFACTOR_ID}}/. The skill runs an internal review-fix loop (Reviewer → filter → orchestrator fix, max 3 rounds) and writes review-report.md.
   4. Run full test suite and verify ALL tests pass
 
 {{IF_BROWSER_INTERACTION}}
@@ -224,8 +212,8 @@ Evidence must cover affected UI render, primary user interactions, behavior-sens
   ```
   If GATE:MISSING:
   - Do not enter an unbounded report-repair loop and do not repeatedly re-spawn Reviewer.
-  - Perform one bounded status check; retry at most once: inspect the Reviewer output, `review-report.md` path, and any internal Reviewer/Dev spawn messages from `/prizmkit-code-review`.
-  - If the missing report is caused by team/config/lock errors from the Reviewer or internal Reviewer/Dev agent spawn, retry the Reviewer agent at most once only if it appears transient.
+  - Perform one bounded status check; retry at most once: inspect the Reviewer output, `review-report.md` path, and any internal Reviewer agent spawn messages from `/prizmkit-code-review`.
+  - If the missing report is caused by team/config/lock errors from the Reviewer or internal Reviewer agent spawn, retry the Reviewer agent at most once only if it appears transient.
   - If the report is still missing after that single check/retry, write `.prizmkit/refactor/{{REFACTOR_ID}}/failure-log.md` with the spawn/skill error and last observable state, then either perform a safe inline fallback review (spec/plan/diff/tests → write `review-report.md` with `## Verdict`) or stop with a clear recovery failure.
 
 Read `review-report.md` and check the Verdict:

package/bundled/dev-pipeline/templates/sections/checkpoint-system.md

@@ -4,63 +4,29 @@ A checkpoint file tracks your progress through this workflow:
 
 **Path**: `{{CHECKPOINT_PATH}}`
 
-### Rules
-
-1. **Before each skill**: Read `workflow-checkpoint.json`, verify the previous step has `status: "completed"` or `status: "skipped"`. If it is still `"pending"` or `"in_progress"`, you MUST complete it first before moving on.
-
-2. **Starting a skill**: Use the update script to set the current step to `status: "in_progress"`.
-
-3. **After each skill completes**: Use the update script to set the current step to `status: "completed"`.
-
-4. **On failure**: Use the update script to set the step to `status: "failed"` and continue to the next step if possible, or halt and write failure-log.md.
+### Checkpoint Update Helper
 
-5. **On session exit**: The checkpoint file reflects your actual progress. Do NOT manually set future steps to "completed".
-
-### Checkpoint Update Pattern
-
-**IMPORTANT: NEVER hand-write or edit `workflow-checkpoint.json` directly. Always use the update script.**
-
-After completing each skill, run:
+Use this helper to update checkpoint status. Do not hand-edit `workflow-checkpoint.json` directly.
 
 ```bash
-python3 $PIPELINE_DIR/scripts/update-checkpoint.py \
+python3 .prizmkit/dev-pipeline/scripts/update-checkpoint.py \
   --checkpoint-path {{CHECKPOINT_PATH}} \
-  --step <SKILL_NAME> \
-  --status completed
+  --step <step-id-or-skill-name> \
+  --status <in_progress|completed|failed|skipped> \
+  --note "<optional note>"
 ```
 
-For example, after completing `prizmkit-implement`:
-```bash
-python3 $PIPELINE_DIR/scripts/update-checkpoint.py \
-  --checkpoint-path {{CHECKPOINT_PATH}} \
-  --step prizmkit-implement \
-  --status completed
-```
+- Use the step `skill` value such as `prizmkit-implement`, or the step id such as `S04`.
+- Omit `--note` when there is no useful failure or handoff note.
 
-Before starting the next skill:
-```bash
-python3 $PIPELINE_DIR/scripts/update-checkpoint.py \
-  --checkpoint-path {{CHECKPOINT_PATH}} \
-  --step <NEXT_SKILL_NAME> \
-  --status in_progress
-```
+### Rules
 
-On failure:
-```bash
-python3 $PIPELINE_DIR/scripts/update-checkpoint.py \
-  --checkpoint-path {{CHECKPOINT_PATH}} \
-  --step <SKILL_NAME> \
-  --status failed \
-  --note "brief failure reason"
-```
+1. **Before each skill**: Read `workflow-checkpoint.json`, verify the previous step has `status: "completed"` or `status: "skipped"`. If it is still `"pending"` or `"in_progress"`, complete it first before moving on.
 
-The script outputs JSON: `{"ok": true, ...}` on success, `{"ok": false, "error": "..."}` on failure.
+2. **Starting a skill**: Use the checkpoint update helper to mark the current step as `status: "in_progress"`.
 
-### Resume Behavior
+3. **After each skill completes**: Use the checkpoint update helper to mark the current step as `status: "completed"`.
 
-**Checkpoint is the primary source of truth for resume.** On retry sessions:
+4. **On failure**: Use the checkpoint update helper to mark the step as `status: "failed"`, write `failure-log.md` with the reason, and continue only when the workflow rules allow it.
 
-1. Read `workflow-checkpoint.json` — steps already `"completed"` or `"skipped"` are skipped
-2. Start from the first `"pending"` or `"in_progress"` step
-3. If `failure-log.md` exists, read it for diagnostic context (why the previous session failed, what approach to try differently) — but do NOT use it to determine which step to resume from
-4. If `workflow-checkpoint.json` is missing or corrupted, fall back to `failure-log.md` + the resume phase as the legacy mechanism
+5. **On session exit**: The checkpoint file reflects your actual progress. Do NOT manually set future steps to `"completed"`.

package/bundled/dev-pipeline/templates/sections/context-budget-rules.md

@@ -6,18 +6,12 @@ You are running in **headless non-interactive mode** with a FINITE context windo
 
 1. **context-snapshot.md is your single source of truth** — After it is built, ALWAYS read context-snapshot.md instead of re-reading individual source files
 2. **Never re-read your own writes** — After you create/modify a file, do NOT read it back to verify. Trust your write was correct.
-3. **Stay focused** — Do NOT explore code unrelated to this feature. No curiosity-driven reads.
-4. **One task at a time** — Complete and test one task before starting the next.
-5. **Minimize tool output** — Never load full command output into context. First capture to a temp file (`cmd 2>&1 | tee /tmp/out.txt | tail -20`), then scan the head/tail to identify relevant fields, and use targeted filtering (`grep`, `sed`, `awk`) to extract only the information needed for the current task. Only read the filtered result — never the raw full output.
-6. **No intermediate commits** — Do NOT run `git add`/`git commit` during implementation phases. All changes are committed once at the end via `/prizmkit-committer`.
-7. **Capture test output once** — When running test suites, always use `($TEST_CMD) 2>&1 | tee /tmp/test-out.txt | tail -20`. Then grep `/tmp/test-out.txt` for details. Never re-run the suite just to apply a different filter.
-8. **Scaffold / generated file awareness (CRITICAL)** — When you run a scaffolding tool or package manager init command (`npm init`, `npx create-*`, `vite create`, `cargo init`, `go mod init`, `rails new`, `django-admin startproject`, `npx shadcn-ui init`, etc.), the output files are **generated boilerplate**. You MUST:
-   - Identify and mentally tag all files created by the tool as "scaffold files"
-   - Record the list of scaffold-generated files in context-snapshot.md under a `### Scaffold Files (do not re-read)` section
-   - **NEVER re-read scaffold files** after initial creation. Their content is standard boilerplate — you already know what they contain from the tool that generated them
-   - If you need to modify a scaffold file, make the edit directly without reading it first (you know the standard template content)
-   - This applies equally to `node_modules/`, `package-lock.json`, generated config files (`tsconfig.json`, `vite.config.ts`, `tailwind.config.js`, `.eslintrc`, etc.) produced by init commands
-   - When passing context to subagents, explicitly tell them which files are scaffold-generated so they skip reading them too
+3. **Never re-read unmodified files** — Once you have read a file into context, do NOT read it again unless it was modified by an Edit/Write operation after your last read. Use `grep -n '<pattern>' <file>` or `sed -n '<start>,<end>p' <file>` for targeted line lookups instead of full-file Read. Before issuing a Read, ask yourself: "Have I read this file before, and has it changed since?" If the answer is "no, it hasn't changed" — do NOT read it. This applies to all files including those summarized in context-snapshot.md Section 4. Subagents (Critic, Reviewer) must receive context-snapshot.md and rely on it rather than independently re-reading the same files the orchestrator already read.
+4. **Stay focused** — Do NOT explore code unrelated to this feature. No curiosity-driven reads.
+5. **One task at a time** — Complete and test one task before starting the next.
+6. **Minimize tool output** — Never load full command output into context. First capture to a temp file (`cmd 2>&1 | tee /tmp/out.txt | tail -20`), then scan the head/tail to identify relevant fields, and use targeted filtering (`grep`, `sed`, `awk`) to extract only the information needed for the current task. Only read the filtered result — never the raw full output.
+7. **No intermediate commits** — Do NOT run `git add`/`git commit` during implementation phases. All changes are committed once at the end via `/prizmkit-committer`.
+8. **Capture test output once** — When running test suites during the post-review gate, capture with `<test-command> 2>&1 | tee /tmp/test-out.txt | tail -20`. Then grep `/tmp/test-out.txt` for details. Never re-run the suite just to apply a different filter.
 9. **Package version verification (HARD CONSTRAINT — BLOCKING)** — Before writing ANY dependency version in `package.json`, `requirements.txt`, `Cargo.toml`, `go.mod`, `Gemfile`, `pyproject.toml`, or any other dependency manifest:
    - You MUST verify the real version exists by querying the package registry first:
      - npm/Node.js: `npm view <package> dist-tags.latest 2>/dev/null`
@@ -32,5 +26,4 @@ You are running in **headless non-interactive mode** with a FINITE context windo
    - **This is a BLOCKING gate**: do NOT run `npm install` / `pip install` / `cargo build` / `go mod tidy` until ALL versions in the manifest have been verified or use open constraints
    - Batch version lookups: query multiple packages in parallel to save time (e.g., run multiple `npm view` commands concurrently)
 10. **Build artifact hygiene** — After any build/compile command (`go build`, `npm run build`, `tsc`, etc.), ensure the output binary, build directory, generated bundle, or cache directory is ignored by git before the commit phase. Never commit compiled binaries, build output, or generated artifacts.
-11. **Anti re-read hard rule (BLOCKING)** — Re-reading the same file is the #1 context burner in long sessions. Once you have read a file into context (directly or via context-snapshot.md Section 4), do NOT read the full file again. Instead use `grep -n '<pattern>' <file>` or `sed -n '<start>,<end>p' <file>` for specific lines. **20-step window**: full Read forbidden within 20 tool calls of last read. **3-strike**: 3 full Reads of same file → report BLOCKED. Never full-file Read a file already summarized in context-snapshot.md Section 4.
-12. **Read offset safety (BLOCKING)** — If Read returns "shorter than offset"/"File is empty"/"Wasted call" — do NOT retry same offset. Run `wc -l <file>` to get real line count, then `sed -n` for exact range. 2 consecutive offset errors → STOP Reading that file. Never guess offsets — `grep -n '<anchor>'` first.
+11. **Read offset safety (BLOCKING)** — If Read returns "shorter than offset"/"File is empty"/"Wasted call" — do NOT retry same offset. Run `wc -l <file>` to get real line count, then `sed -n '<start>,<end>p' <file>` for exact range. 2 consecutive offset errors → STOP Reading that file. Never guess offsets — `grep -n '<anchor>'` first.

package/bundled/dev-pipeline/templates/sections/feature-context.md

@@ -14,8 +14,4 @@ Use this material according to the following priority:
 ### App Global Context
 
 {{GLOBAL_CONTEXT}}
-
-### Project Conventions
-
-> Read {{PLATFORM_CONVENTIONS}} for project-level coding standards and architecture decisions.
 </feature-context>

package/bundled/dev-pipeline/templates/sections/phase-browser-verification-auto.md

@@ -141,10 +141,3 @@ Append results to `context-snapshot.md`:
 If verification fails, log the failure details but continue to commit. Failures do NOT block the commit, but you MUST attempt verification and MUST clean up the dev server.
 
 
-**Checkpoint update**: Run the update script to set step `browser-verification` to `"completed"`:
-```bash
-python3 $PIPELINE_DIR/scripts/update-checkpoint.py \
-  --checkpoint-path {{CHECKPOINT_PATH}} \
-  --step browser-verification \
-  --status completed
-```

package/bundled/dev-pipeline/templates/sections/phase-browser-verification-opencli.md

@@ -121,10 +121,3 @@ Append results to `context-snapshot.md`:
 If verification fails, log the failure details but continue to commit. Failures do NOT block the commit, but you MUST attempt verification and MUST clean up the dev server.
 
 
-**Checkpoint update**: Run the update script to set step `browser-verification` to `"completed"`:
-```bash
-python3 $PIPELINE_DIR/scripts/update-checkpoint.py \
-  --checkpoint-path {{CHECKPOINT_PATH}} \
-  --step browser-verification \
-  --status completed
-```

package/bundled/dev-pipeline/templates/sections/phase-browser-verification.md

@@ -143,10 +143,3 @@ Browser cleanup: confirmed
 If verification fails, log the failure details but continue to commit. Failures do NOT block the commit, but you MUST attempt verification and MUST clean up the dev server.
 
 
-**Checkpoint update**: Run the update script to set step `browser-verification` to `"completed"`:
-```bash
-python3 $PIPELINE_DIR/scripts/update-checkpoint.py \
-  --checkpoint-path {{CHECKPOINT_PATH}} \
-  --step browser-verification \
-  --status completed
-```

package/bundled/dev-pipeline/templates/sections/phase-commit-full.md

@@ -55,20 +55,6 @@ Rules for writing completion notes:
 - If this feature has no downstream dependents, still write the summary (it serves as documentation)
 
 
-**Checkpoint update**: After `/prizmkit-retrospective` completes, run the update script to set step `prizmkit-retrospective` to `"completed"`:
-```bash
-python3 $PIPELINE_DIR/scripts/update-checkpoint.py \
-  --checkpoint-path {{CHECKPOINT_PATH}} \
-  --step prizmkit-retrospective \
-  --status completed
-```
-After `/prizmkit-committer` completes, set step `prizmkit-committer` to `"completed"`:
-```bash
-python3 $PIPELINE_DIR/scripts/update-checkpoint.py \
-  --checkpoint-path {{CHECKPOINT_PATH}} \
-  --step prizmkit-committer \
-  --status completed
-```
 
 ### TERMINAL STOP — Commit Completed
 

package/bundled/dev-pipeline/templates/sections/phase-commit.md

@@ -48,20 +48,6 @@ Rules for writing completion notes:
 - If this feature has no downstream dependents, still write the summary (it serves as documentation)
 
 
-**Checkpoint update**: After `/prizmkit-retrospective` completes, run the update script to set step `prizmkit-retrospective` to `"completed"`:
-```bash
-python3 $PIPELINE_DIR/scripts/update-checkpoint.py \
-  --checkpoint-path {{CHECKPOINT_PATH}} \
-  --step prizmkit-retrospective \
-  --status completed
-```
-After `/prizmkit-committer` completes, set step `prizmkit-committer` to `"completed"`:
-```bash
-python3 $PIPELINE_DIR/scripts/update-checkpoint.py \
-  --checkpoint-path {{CHECKPOINT_PATH}} \
-  --step prizmkit-committer \
-  --status completed
-```
 
 ### TERMINAL STOP — Commit Completed
 

package/bundled/dev-pipeline/templates/sections/phase-context-snapshot-agent-suffix.md

@@ -22,10 +22,3 @@
      - <trap entries extracted from L1/L2 docs>
 
 
-**Checkpoint update**: Run the update script to set step `context-snapshot` to `"completed"`:
-```bash
-python3 $PIPELINE_DIR/scripts/update-checkpoint.py \
-  --checkpoint-path {{CHECKPOINT_PATH}} \
-  --step context-snapshot \
-  --status completed
-```

package/bundled/dev-pipeline/templates/sections/phase-context-snapshot-base.md

@@ -10,5 +10,3 @@ If MISSING — build it now:
 3. Write `.prizmkit/specs/{{FEATURE_SLUG}}/context-snapshot.md`:
    - **Section 1 — Feature Brief**: 2-3 line feature description from Task Contract
    - **Section 2 — Verification Gates**: gate checklist from Task Contract
-   - **Section 3 — Key TRAPS & RULES**: extract only relevant TRAPS/RULES from prizm-docs that apply to files in this scope. Do NOT copy full L0/L1/L2 content.
-   - **Section 4 — File Manifest**: file path, why needed, key interfaces. Format: Files to Modify | Files for Reference tables.

package/bundled/dev-pipeline/templates/sections/phase-context-snapshot-lite-suffix.md

@@ -10,10 +10,3 @@
      |------|-----------|----------------|
 
 
-**Checkpoint update**: Run the update script to set step `context-snapshot` to `"completed"`:
-```bash
-python3 $PIPELINE_DIR/scripts/update-checkpoint.py \
-  --checkpoint-path {{CHECKPOINT_PATH}} \
-  --step context-snapshot \
-  --status completed
-```

package/bundled/dev-pipeline/templates/sections/phase-critic-plan-full.md

@@ -26,13 +26,18 @@ If CRITIC:MISSING — skip this phase entirely and proceed. Log: "Critic agent n
 | subagent_type | prizm-dev-team-critic |
 | mode | plan |
 | run_in_background | false |
+| isolation | default/no worktree; do not request worktree isolation |
+
+No-worktree boundary: this prevents AI tool-created `.claude/worktrees/...` subagent worktrees. It does not disable PrizmKit pipeline-managed linked git worktrees under `.prizmkit/state/worktrees/...`, which are controlled separately by `USE_WORKTREE`.
 
 **Prompt**:
 > {{AGENT_PROMPT_CRITIC_PLAN_CHALLENGE}}
 
 **If {{CRITIC_COUNT}} = 3 → Multi-Critic Voting** (skip Single Critic above):
 
-Spawn 3 Critic agents in PARALLEL (issue all 3 Agent tool calls in the SAME message turn). Do NOT wait for one before spawning the next. Each with mode="plan", run_in_background=false:
+Spawn 3 Critic agents in PARALLEL (issue all 3 Agent tool calls in the SAME message turn). Do NOT wait for one before spawning the next. Each with mode="plan", run_in_background=false, and default/no worktree isolation; do not request worktree isolation.
+
+No-worktree boundary: default/no worktree isolation prevents AI tool-created `.claude/worktrees/...` subagent worktrees. It does not disable PrizmKit pipeline-managed linked git worktrees under `.prizmkit/state/worktrees/...`, which are controlled separately by `USE_WORKTREE`.
 
 Critic-A prompt (append to base prompt above):
 > "**Focus Lens: Architecture & Scalability.** Prioritize: architectural pattern fit, scalability implications, over-engineering risks, component boundary design.
@@ -54,10 +59,3 @@ After all critics return, read all 3 reports:
 **CP-2.5**: Plan challenges reviewed and resolved.
 
 
-**Checkpoint update**: Run the update script to set step `critic-plan-review` to `"completed"`:
-```bash
-python3 $PIPELINE_DIR/scripts/update-checkpoint.py \
-  --checkpoint-path {{CHECKPOINT_PATH}} \
-  --step critic-plan-review \
-  --status completed
-```

package/bundled/dev-pipeline/templates/sections/phase-critic-plan.md

@@ -12,6 +12,9 @@ If CRITIC:MISSING — skip this phase entirely and proceed. Log: "Critic agent n
 | subagent_type | prizm-dev-team-critic |
 | mode | plan |
 | run_in_background | false |
+| isolation | default/no worktree; do not request worktree isolation |
+
+No-worktree boundary: this prevents AI tool-created `.claude/worktrees/...` subagent worktrees. It does not disable PrizmKit pipeline-managed linked git worktrees under `.prizmkit/state/worktrees/...`, which are controlled separately by `USE_WORKTREE`.
 
 **Prompt**:
 > {{AGENT_PROMPT_CRITIC_PLAN_CHALLENGE}}
@@ -33,10 +36,3 @@ Wait for Critic to return.
 **CP-2.5**: Plan challenges reviewed and resolved.
 
 
-**Checkpoint update**: Run the update script to set step `critic-plan-review` to `"completed"`:
-```bash
-python3 $PIPELINE_DIR/scripts/update-checkpoint.py \
-  --checkpoint-path {{CHECKPOINT_PATH}} \
-  --step critic-plan-review \
-  --status completed
-```

package/bundled/dev-pipeline/templates/sections/phase-implement-agent.md

@@ -11,12 +11,7 @@ grep -c '^\- \[ \]' .prizmkit/specs/{{FEATURE_SLUG}}/plan.md 2>/dev/null || true
 
 **Build artifacts rule**: After any build/compile command, ensure output is in `.gitignore`. Never commit binaries/build output.
 
-**3a.** Detect test commands and record baseline:
-```bash
-($TEST_CMD) 2>&1 | tee /tmp/test-baseline.txt | tail -20
-```
-
-**3b.** Run `/prizmkit-implement` directly — you (the orchestrator) execute the full cycle:
+**3a.** Run `/prizmkit-implement` directly — you (the orchestrator) execute the full cycle:
 - Read plan.md Tasks from `.prizmkit/specs/{{FEATURE_SLUG}}/`
 - Use context-snapshot.md Section 4 File Manifest for targeted reads — do NOT re-read files already summarized there
 - Implements task-by-task, marking each `[x]` immediately
@@ -25,12 +20,12 @@ grep -c '^\- \[ \]' .prizmkit/specs/{{FEATURE_SLUG}}/plan.md 2>/dev/null || true
 - Preserves Reviewer/Critic behavior; only the top-level implementation Dev handoff is removed
 - If plan.md has >5 tasks: update checkpoints after every 3 tasks
 
-**3c. Focused checks only (no test gate here)**:
+**3b. Focused checks only (no test gate here)**:
 - During implementation, do not run mandatory periodic or full-suite tests.
 - If a tiny targeted check is needed to understand a local failure, run only the smallest relevant command and capture output to `/tmp/test-out.txt`.
 - The scoped feature test gate runs after code review; do not declare implementation success based on an early full-suite run.
 
-**3d. Verification Gate Self-Check (BLOCKING — before declaring implement done)**:
+**3c. Verification Gate Self-Check (BLOCKING — before declaring implement done)**:
 For each Verification Gate from the Task Contract, write one evidence line to Implementation Log:
 ```
 ### Gate Evidence
@@ -38,7 +33,7 @@ For each Verification Gate from the Task Contract, write one evidence line to Im
 - [ ] G3: <gate text> — BLOCKED: <reason>  ← no evidence = BLOCKED, not success
 ```
 
-**3e.** Append `## Implementation Log` (with Gate Evidence) to `context-snapshot.md`:
+**3d.** Append `## Implementation Log` (with Gate Evidence) to `context-snapshot.md`:
 - files changed/created
 - key decisions
 - deviations from plan
@@ -48,10 +43,3 @@ For each Verification Gate from the Task Contract, write one evidence line to Im
 
 **CP-2**: All tasks `[x]`, Implementation Log written with Gate Evidence, and blocked gates documented in `failure-log.md`. Test execution is deferred until after code review.
 
-**Checkpoint update**:
-```bash
-python3 $PIPELINE_DIR/scripts/update-checkpoint.py \
-  --checkpoint-path {{CHECKPOINT_PATH}} \
-  --step prizmkit-implement \
-  --status completed
-```

package/bundled/dev-pipeline/templates/sections/phase-implement-full.md

@@ -11,13 +11,7 @@ grep -c '^\- \[ \]' .prizmkit/specs/{{FEATURE_SLUG}}/plan.md 2>/dev/null || true
 
 **Build artifacts rule**: After any build/compile command, ensure output is in `.gitignore`. Never commit binaries/build output.
 
-**3a.** Detect test commands and record baseline:
-```bash
-($TEST_CMD) 2>&1 | tee /tmp/test-baseline.txt | tail -20
-```
-Save pre-existing failing tests as `BASELINE_FAILURES`.
-
-**3b.** Run `/prizmkit-implement` directly — you (the orchestrator) execute the full cycle:
+**3a.** Run `/prizmkit-implement` directly — you (the orchestrator) execute the full cycle:
 - Read plan.md Tasks from `.prizmkit/specs/{{FEATURE_SLUG}}/`
 - Use context-snapshot.md Section 4 File Manifest for targeted reads — do NOT re-read files already summarized there
 - Implements task-by-task, marking each `[x]` immediately
@@ -26,12 +20,12 @@ Save pre-existing failing tests as `BASELINE_FAILURES`.
 - Preserves Reviewer/Critic behavior; only the top-level implementation Dev handoff is removed
 - If plan.md has >5 tasks: update checkpoints after every 3 tasks
 
-**3c. Focused checks only (no test gate here)**:
+**3b. Focused checks only (no test gate here)**:
 - During implementation, do not run mandatory periodic or full-suite tests.
 - If a tiny targeted check is needed to understand a local failure, run only the smallest relevant command and capture output to `/tmp/test-out.txt`.
 - The scoped feature test gate runs after code review; do not declare implementation success based on an early full-suite run.
 
-**3d. Verification Gate Self-Check (BLOCKING — before declaring implement done)**:
+**3c. Verification Gate Self-Check (BLOCKING — before declaring implement done)**:
 For each Verification Gate from the Task Contract, write one evidence line to Implementation Log:
 ```
 ### Gate Evidence
@@ -39,7 +33,7 @@ For each Verification Gate from the Task Contract, write one evidence line to Im
 - [ ] G3: <gate text> — BLOCKED: <reason>  ← no evidence = BLOCKED, not success
 ```
 
-**3e.** Append `## Implementation Log` (with Gate Evidence) to `context-snapshot.md`:
+**3d.** Append `## Implementation Log` (with Gate Evidence) to `context-snapshot.md`:
 - files changed/created
 - key decisions
 - deviations from plan
@@ -49,10 +43,3 @@ For each Verification Gate from the Task Contract, write one evidence line to Im
 
 **CP-2**: All tasks `[x]`, Implementation Log written with Gate Evidence, and blocked gates documented in `failure-log.md`. Test execution is deferred until after code review.
 
-**Checkpoint update**:
-```bash
-python3 $PIPELINE_DIR/scripts/update-checkpoint.py \
-  --checkpoint-path {{CHECKPOINT_PATH}} \
-  --step prizmkit-implement \
-  --status completed
-```

package/bundled/dev-pipeline/templates/sections/phase-implement-lite.md

@@ -21,10 +21,3 @@
 **CP-2**: Implementation may proceed only when all tasks are `[x]` and blocked gates are documented in `failure-log.md`. Test execution is deferred until after code review.
 
 
-**Checkpoint update**: Run the update script to set step `prizmkit-implement` to `"completed"`:
-```bash
-python3 $PIPELINE_DIR/scripts/update-checkpoint.py \
-  --checkpoint-path {{CHECKPOINT_PATH}} \
-  --step prizmkit-implement \
-  --status completed
-```

package/bundled/dev-pipeline/templates/sections/phase-plan-agent.md

@@ -6,22 +6,15 @@ ls .prizmkit/specs/{{FEATURE_SLUG}}/plan.md 2>/dev/null
 
 If missing, run `/prizmkit-plan` with `artifact_dir=.prizmkit/specs/{{FEATURE_SLUG}}/` to generate `plan.md`:
 - The plan.md should include: architecture — components, interfaces, data flow, files to create/modify, testing approach, and a Tasks section with `[ ]` checkboxes ordered by dependency.
-- Resolve any `[NEEDS CLARIFICATION]` markers using the feature description — do NOT pause for interactive input.
+- Resolve uncertain requirements from the feature description, existing code, and conservative existing-project patterns.
 
 **Database Design Gate** (if feature involves data persistence — new tables, schema changes, new entities):
 Before proceeding past CP-1, verify:
 1. Plan.md Data Model section references existing schema/model files (scan for `*.prisma`, `*.sql`, `migrations/`, `models/`, `*.entity.*` files; read them if not already in context-snapshot)
 2. All new tables/fields follow existing naming conventions, ID strategy, timestamp patterns, and constraint style
-3. No `[NEEDS CLARIFICATION]` remains in Data Model section — resolve by reading existing code and making a conservative choice that matches existing patterns. Document the resolution in plan.md.
+3. No unresolved data model uncertainty remains in the Data Model section — resolve by reading existing code and making a conservative choice that matches existing patterns. Document the resolution in plan.md.
 4. If a DB design decision genuinely cannot be resolved from existing code alone, document the assumption made and flag it in the Implementation Log for user review.
 
 **CP-1**: plan.md exists with Tasks section.
 
 
-**Checkpoint update**: Run the update script to set step `prizmkit-plan` to `"completed"`:
-```bash
-python3 $PIPELINE_DIR/scripts/update-checkpoint.py \
-  --checkpoint-path {{CHECKPOINT_PATH}} \
-  --step prizmkit-plan \
-  --status completed
-```

package/bundled/dev-pipeline/templates/sections/phase-plan-lite.md

@@ -7,7 +7,7 @@ ls .prizmkit/specs/{{FEATURE_SLUG}}/ 2>/dev/null
 If plan.md missing, run `/prizmkit-plan` with `artifact_dir=.prizmkit/specs/{{FEATURE_SLUG}}/`:
 - Pass the Objective and Verification Gates from the Task Contract as input
 - The plan.md should include: key components, data flow, files to create/modify, and a Tasks section with `[ ]` checkboxes (each task = one implementable unit). Keep under 80 lines.
-- Resolve any `[NEEDS CLARIFICATION]` markers using the feature description — do NOT pause for interactive input.
+- Resolve uncertain requirements from the feature description, existing code, and conservative existing-project patterns.
 
 **Database Design Gate** (if feature involves data persistence — new tables, schema changes, new entities):
 Before proceeding past CP-1:
@@ -18,10 +18,3 @@ Before proceeding past CP-1:
 **CP-1**: plan.md exists with Tasks section.
 
 
-**Checkpoint update**: Run the update script to set step `prizmkit-plan` to `"completed"`:
-```bash
-python3 $PIPELINE_DIR/scripts/update-checkpoint.py \
-  --checkpoint-path {{CHECKPOINT_PATH}} \
-  --step prizmkit-plan \
-  --status completed
-```

package/bundled/dev-pipeline/templates/sections/phase-prizmkit-test.md

@@ -1,12 +1,12 @@
 ### Scoped Feature Test Gate — PrizmKit Test
 
-**Goal**: After code review completes, generate and verify tests for this feature's changed scope without embedding the full gate implementation in this prompt.
+**Goal**: After code review completes, generate and verify tests for this feature's changed scope through the `/prizmkit-test` skill.
 
-Create a start marker immediately before invoking the skill so the gate can reject stale reports from older sessions:
+Create a current-run marker immediately before invoking the skill:
 
 ```bash
-python3 "$PIPELINE_DIR/scripts/prizmkit-test-gate.py" start \
-  --feature-slug "{{FEATURE_SLUG}}"
+mkdir -p .prizmkit/specs/{{FEATURE_SLUG}}
+touch .prizmkit/specs/{{FEATURE_SLUG}}/.prizmkit-test-started
 ```
 
 Run `/prizmkit-test` with the feature artifact directory:
@@ -23,17 +23,16 @@ Rules:
 - If failures are baseline or unrelated to this feature, document them in the report and continue only when no in-scope failure remains unexplained.
 
 **Gate Check — Test Report**:
-After `/prizmkit-test` returns, run the gate script to locate the newest current-run report, validate scope/freshness/boundary coverage, write `test-report-path.txt`, and mark the `prizmkit-test` checkpoint completed only on `GATE:PASS`:
-
-```bash
-python3 "$PIPELINE_DIR/scripts/prizmkit-test-gate.py" check \
-  --feature-slug "{{FEATURE_SLUG}}" \
-  --artifact-dir ".prizmkit/specs/{{FEATURE_SLUG}}/" \
-  --checkpoint-path "{{CHECKPOINT_PATH}}"
-```
+After `/prizmkit-test` returns, read `.prizmkit/specs/{{FEATURE_SLUG}}/test-report-path.txt` if it exists; otherwise locate the newest `.prizmkit/test/*/test-report.md` created by the current test run. Accept the report only when it states:
+- `Scope` mode is `this-change`
+- `Artifact Dir` matches `.prizmkit/specs/{{FEATURE_SLUG}}/`
+- `Verdict` is `PASS`
+- `Boundary Matrix` is present
+- `Boundary Completion Gate` is present and reports `Boundary-missing: 0`, `Happy-path-only: 0`, and `Completion gate passed: yes`
+- `Boundary Validation` is present and reports `Validator result: passed`
 
 Gate outcomes:
-- `GATE:PASS` → append the report path and a 3-5 bullet summary to `context-snapshot.md` under `## PrizmKit Test Gate`, then proceed to the next checkpoint step. The gate script already wrote `test-report-path.txt` and marked `prizmkit-test` completed.
-- `GATE:FAIL` with `NEEDS_FIXES` → read the report's `In-Scope Failures`, fix the feature implementation or generated tests within this feature scope, rerun `/prizmkit-test`, and repeat the gate check. Do not proceed to retrospective/commit while the verdict is not `PASS`.
-- `GATE:FAIL` with `BLOCKED`, wrong mode, wrong artifact dir, unreadable report, stale scope, boundary failure, validator failure, or checkpoint update failure → write `.prizmkit/specs/{{FEATURE_SLUG}}/failure-log.md` with the scoped test failure and stop for recovery.
-- `GATE:MISSING` → perform one bounded status check: inspect `/prizmkit-test` output and `.prizmkit/test/` for a report directory. If no current-run report exists, write `failure-log.md` and stop for recovery.
+- `PASS` → ensure `.prizmkit/specs/{{FEATURE_SLUG}}/test-report-path.txt` points to the accepted report, append the report path and a 3-5 bullet summary to `context-snapshot.md` under `## PrizmKit Test Gate`, then proceed.
+- `NEEDS_FIXES` → read the report's `In-Scope Failures`, fix the feature implementation or generated tests within this feature scope, rerun `/prizmkit-test`, and repeat the gate check. Do not proceed to retrospective/commit while the verdict is not `PASS`.
+- `BLOCKED`, wrong mode, wrong artifact dir, unreadable report, stale scope, or boundary failure → write `.prizmkit/specs/{{FEATURE_SLUG}}/failure-log.md` with the scoped test failure and stop for recovery.
+- Missing report → perform one bounded status check: inspect `/prizmkit-test` output and `.prizmkit/test/` for a report directory. If no current-run report exists, write `failure-log.md` and stop for recovery.

package/bundled/dev-pipeline/templates/sections/phase-review-agent.md

@@ -4,7 +4,7 @@ Review the completed implementation before the scoped feature test gate runs. Us
 
 Run `/prizmkit-code-review` with `artifact_dir=.prizmkit/specs/{{FEATURE_SLUG}}/`.
 
-The skill runs an internal review-fix loop (Reviewer Agent → filter → Dev Agent fix, max 3 rounds) and writes `review-report.md` to the artifact directory.
+The skill runs an internal review-fix loop (Reviewer Agent → filter → orchestrator fix, max 3 rounds) and writes `review-report.md` to the artifact directory.
 
 **Gate Check — Review Report**:
 After `/prizmkit-code-review` returns, verify the review report:
@@ -13,8 +13,8 @@ grep -q "## Verdict" .prizmkit/specs/{{FEATURE_SLUG}}/review-report.md && echo "
 ```
 If GATE:MISSING:
 - Do not re-run `/prizmkit-code-review` in an unbounded report-repair loop.
-- Perform one bounded status check; retry at most once: inspect the skill output, `review-report.md` path, and any Reviewer/Dev spawn messages.
-- If the missing report is caused by team/config/lock errors from the internal Reviewer/Dev agent spawn, retry `/prizmkit-code-review` at most once only if it appears transient.
+- Perform one bounded status check; retry at most once: inspect the skill output, `review-report.md` path, and any Reviewer agent spawn messages.
+- If the missing report is caused by team/config/lock errors from the Reviewer agent spawn or review skill error, retry `/prizmkit-code-review` at most once only if it appears transient.
 - If the report is still missing after that single check/retry, write `failure-log.md` with the spawn/skill error and last observable state, then either perform a safe inline fallback review (spec/plan/diff/tests → write `review-report.md` with `## Verdict`) or stop with a clear recovery failure.
 
 Read `review-report.md` and check the Verdict:
@@ -24,10 +24,3 @@ Read `review-report.md` and check the Verdict:
 **CP-3**: Review complete, report written.
 
 
-**Checkpoint update**: Run the update script to set step `prizmkit-code-review` to `"completed"`:
-```bash
-python3 $PIPELINE_DIR/scripts/update-checkpoint.py \
-  --checkpoint-path {{CHECKPOINT_PATH}} \
-  --step prizmkit-code-review \
-  --status completed
-```