prizmkit 1.1.106 → 1.1.108

package/bundled/dev-pipeline/templates/bootstrap-tier2.md

@@ -52,22 +52,18 @@ You are running in **headless non-interactive mode** with a FINITE context windo
 
 1. **context-snapshot.md is your single source of truth** — After Phase 1 builds it, 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.
+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.
 4. **One task at a time** — In Phase 4 (implement), 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 Phase 1-5. All changes are committed once at the end in Phase 6 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** — Files created by scaffolding tools are boilerplate. Tag them, record in context-snapshot.md, NEVER re-read. Edit directly without reading first.
+7. **Capture test output once** — When running test suites, always use `<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 (BLOCKING)** — Verify dependency versions via registry query before writing them. NEVER guess.
 10. **Build artifact hygiene** — After build/compile, ensure output is in `.gitignore`.
-11. **Anti re-read hard rule (BLOCKING)** — Once you have read a file into context, do NOT read the full file again. 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. Applies to orchestrator AND subagents — subagents re-reading files in context-snapshot.md Section 4 are wasting context.
-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` for exact range. 2 consecutive offset errors → STOP Reading that file. Never guess offsets — `grep -n '<anchor>'` first.
 
 ---
 
-{{LOG_SIZE_AWARENESS}}
----
-
 ## PrizmKit Directory Convention
 
 ```
@@ -100,15 +96,6 @@ If any agent times out:
 ### Phase 0: SKIP (already initialized)
 {{END_IF_INIT_DONE}}
 
-### Phase 0.5: Detect Test Commands
-
-You know this project's tech stack. Identify ALL test commands that apply (e.g., `go test ./...`, `npm test`, `cargo test`, `pytest`, `make test`, etc.). Record them as `TEST_CMDS`. Then record baseline:
-```bash
-($TEST_CMD) 2>&1 | tee /tmp/test-baseline.txt | tail -20
-```
-Save pre-existing failing tests as `BASELINE_FAILURES`.
-
-> **⚠️ Test Output Rule**: Always capture test output to a temp file (`tee /tmp/test-out.txt`). Then grep the file instead of re-running the suite.
 
 ### Phase 1: Build Context Snapshot (you, the orchestrator)
 
@@ -162,20 +149,20 @@ ls .prizmkit/specs/{{FEATURE_SLUG}}/plan.md 2>/dev/null
 
 If either missing, run `/prizmkit-plan` with `artifact_dir=.prizmkit/specs/{{FEATURE_SLUG}}/` to generate missing files:
 - `plan.md`: 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.
 
 ### Phase 3: Analyze — Reviewer Subagent
 
-Spawn Reviewer agent (Agent tool, subagent_type="prizm-dev-team-reviewer", mode="plan", run_in_background=false).
+Spawn Reviewer agent (Agent tool, subagent_type="prizm-dev-team-reviewer", mode="plan", run_in_background=false, isolation=default/no worktree). Do not request worktree isolation; this prevents AI tool-created `.claude/worktrees/...` subagent worktrees. PrizmKit pipeline-managed linked git worktrees under `.prizmkit/state/worktrees/...` are separate and controlled by `USE_WORKTREE`.
 
 Spawn failure cap: for team/config/lock errors, retry at most once for this Reviewer spawn. If the second attempt fails, do not poll for report artifacts; fix/check the plan inline or write `failure-log.md` before stopping for recovery.
 
@@ -204,7 +191,7 @@ If CRITIC:MISSING — skip Phase 3.5 entirely and proceed to Phase 4. Log: "Crit
 
 **If {{CRITIC_COUNT}} = 1 → Single Critic** (skip to CP-2.5 after this):
 
-Spawn Critic agent (Agent tool, subagent_type="prizm-dev-team-critic", mode="plan", run_in_background=false).
+Spawn Critic agent (Agent tool, subagent_type="prizm-dev-team-critic", mode="plan", run_in_background=false, isolation=default/no worktree). Do not request worktree isolation; this prevents AI tool-created `.claude/worktrees/...` subagent worktrees. PrizmKit pipeline-managed linked git worktrees under `.prizmkit/state/worktrees/...` are separate and controlled by `USE_WORKTREE`.
 
 Spawn failure cap: for team/config/lock errors, retry at most once for this Critic spawn. If the second attempt fails, do not poll for challenge reports; perform the plan challenge inline and record the fallback.
 
@@ -212,9 +199,10 @@ Prompt:
 > "Read {{CRITIC_SUBAGENT_PATH}}. For feature {{FEATURE_ID}} (slug: {{FEATURE_SLUG}}):
 > **MODE: Plan Challenge**
 > 1. Read `.prizmkit/specs/{{FEATURE_SLUG}}/context-snapshot.md` FIRST — Section 3 has project context, Section 4 has file manifest.
-> 2. Read `.prizmkit/prizm-docs/root.prizm` and relevant L1/L2 docs for affected modules.
-> 3. Read existing source files in the modules this plan touches.
-> 4. Challenge plan.md against the project's existing architecture, patterns, and style.
+> 2. Use context-snapshot.md as the shared source of truth. Do not create or enter AI tool-created `.claude/worktrees/...` subagent worktrees; use default/no worktree isolation and do not request worktree isolation.
+> 3. PrizmKit pipeline-managed linked git worktrees under `.prizmkit/state/worktrees/...` are a separate runner feature controlled by `USE_WORKTREE`; do not confuse them with AI tool-created `.claude/worktrees/...`.
+> 4. Read additional `.prizmkit/prizm-docs/` or source excerpts only when needed to verify a specific challenge.
+> 5. Challenge plan.md against the project's existing architecture, patterns, and style.
 > Write `.prizmkit/specs/{{FEATURE_SLUG}}/challenge-report.md` with findings (or 'No significant challenges')."
 
 Wait for Critic to return.
@@ -225,15 +213,16 @@ Wait for Critic to return.
 
 **IMPORTANT**: Spawn all 3 Critics in PARALLEL (issue all 3 Agent tool calls in the SAME message turn). Do NOT wait for one before spawning the next.
 
-Spawn Critic-A, Critic-B, Critic-C simultaneously (each with mode="plan", run_in_background=false):
+Spawn Critic-A, Critic-B, Critic-C simultaneously (each with mode="plan", run_in_background=false, isolation=default/no worktree). Do not request worktree isolation; this prevents AI tool-created `.claude/worktrees/...` subagent worktrees. PrizmKit pipeline-managed linked git worktrees under `.prizmkit/state/worktrees/...` are separate and controlled by `USE_WORKTREE`:
 
 Critic-A prompt:
 > "Read {{CRITIC_SUBAGENT_PATH}}. For feature {{FEATURE_ID}} (slug: {{FEATURE_SLUG}}):
 > **MODE: Plan Challenge — Lens: Architecture & Scalability**
 > Focus on: architectural pattern fit, scalability implications, over-engineering risks, component boundary design.
 > 1. Read `.prizmkit/specs/{{FEATURE_SLUG}}/context-snapshot.md` FIRST — Section 3 has TRAPS/RULES, Section 4 has file manifest.
-> 2. Read `.prizmkit/prizm-docs/root.prizm` and relevant L1/L2 docs for affected modules.
-> 3. Read existing source files in the modules this plan touches.
+> 2. Use context-snapshot.md as the shared source of truth. Do not create or enter AI tool-created `.claude/worktrees/...` subagent worktrees; use default/no worktree isolation and do not request worktree isolation.
+> 3. PrizmKit pipeline-managed linked git worktrees under `.prizmkit/state/worktrees/...` are a separate runner feature controlled by `USE_WORKTREE`; do not confuse them with AI tool-created `.claude/worktrees/...`.
+> 4. Read additional `.prizmkit/prizm-docs/` or source excerpts only when needed to verify a specific challenge.
 > 4. Challenge plan.md through your architecture lens.
 > Write `.prizmkit/specs/{{FEATURE_SLUG}}/challenge-report-A.md`."
 
@@ -242,8 +231,9 @@ Critic-B prompt:
 > **MODE: Plan Challenge — Lens: Data Model & Edge Cases**
 > Focus on: data model design fit, entity relationships, edge cases in business logic, missing boundary conditions.
 > 1. Read `.prizmkit/specs/{{FEATURE_SLUG}}/context-snapshot.md` FIRST — Section 3 has TRAPS/RULES, Section 4 has file manifest.
-> 2. Read `.prizmkit/prizm-docs/root.prizm` and relevant L1/L2 docs for affected modules.
-> 3. Read existing source files in the modules this plan touches.
+> 2. Use context-snapshot.md as the shared source of truth. Do not create or enter AI tool-created `.claude/worktrees/...` subagent worktrees; use default/no worktree isolation and do not request worktree isolation.
+> 3. PrizmKit pipeline-managed linked git worktrees under `.prizmkit/state/worktrees/...` are a separate runner feature controlled by `USE_WORKTREE`; do not confuse them with AI tool-created `.claude/worktrees/...`.
+> 4. Read additional `.prizmkit/prizm-docs/` or source excerpts only when needed to verify a specific challenge.
 > 4. Challenge plan.md through your data/edge-case lens.
 > Write `.prizmkit/specs/{{FEATURE_SLUG}}/challenge-report-B.md`."
 
@@ -252,8 +242,9 @@ Critic-C prompt:
 > **MODE: Plan Challenge — Lens: Security & Performance**
 > Focus on: security attack surface, authentication/authorization gaps, performance bottlenecks, resource leaks.
 > 1. Read `.prizmkit/specs/{{FEATURE_SLUG}}/context-snapshot.md` FIRST — Section 3 has TRAPS/RULES, Section 4 has file manifest.
-> 2. Read `.prizmkit/prizm-docs/root.prizm` and relevant L1/L2 docs for affected modules.
-> 3. Read existing source files in the modules this plan touches.
+> 2. Use context-snapshot.md as the shared source of truth. Do not create or enter AI tool-created `.claude/worktrees/...` subagent worktrees; use default/no worktree isolation and do not request worktree isolation.
+> 3. PrizmKit pipeline-managed linked git worktrees under `.prizmkit/state/worktrees/...` are a separate runner feature controlled by `USE_WORKTREE`; do not confuse them with AI tool-created `.claude/worktrees/...`.
+> 4. Read additional `.prizmkit/prizm-docs/` or source excerpts only when needed to verify a specific challenge.
 > 4. Challenge plan.md through your security/performance lens.
 > Write `.prizmkit/specs/{{FEATURE_SLUG}}/challenge-report-C.md`."
 
@@ -280,25 +271,21 @@ 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
 - Creates/updates L2 `.prizm` docs when creating new modules
 - Defers scoped/full test execution until after the code-review loop completes
+- 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
@@ -306,7 +293,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
@@ -316,20 +303,40 @@ 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**:
+### Review — Code Review
+
+Review the completed implementation before the scoped feature test gate runs. Use `artifact_dir=.prizmkit/specs/{{FEATURE_SLUG}}/` so the code-review skill can read spec, plan, context snapshot, implementation log, and current diff artifacts. Do not require or read a prior `/prizmkit-test` report here; test generation and test-fix looping happen in the next phase.
+
+Run `/prizmkit-code-review` with `artifact_dir=.prizmkit/specs/{{FEATURE_SLUG}}/`.
+
+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:
 ```bash
-python3 $PIPELINE_DIR/scripts/update-checkpoint.py \
-  --checkpoint-path .prizmkit/specs/{{FEATURE_SLUG}}/workflow-checkpoint.json \
-  --step prizmkit-implement \
-  --status completed
+grep -q "## Verdict" .prizmkit/specs/{{FEATURE_SLUG}}/review-report.md && echo "GATE:PASS" || echo "GATE:MISSING"
 ```
+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 agent spawn messages.
+- If the missing report is caused by 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:
+- `PASS` → proceed to next phase
+- `NEEDS_FIXES` → the skill exhausted its max rounds; log the remaining findings and proceed (do not retry externally)
+
+**CP-3**: Review complete, report written.
 
 ### Scoped Feature Test Gate — PrizmKit Test
 
 Run `/prizmkit-test scope=this-change artifact_dir=.prizmkit/specs/{{FEATURE_SLUG}}/` after review and before commit.
 
-Before invoking the skill, create `.prizmkit/specs/{{FEATURE_SLUG}}/.prizmkit-test-started` so stale reports are ignored.
+Before invoking the skill, create a current-run marker so stale reports are ignored:
+```bash
+mkdir -p .prizmkit/specs/{{FEATURE_SLUG}}
+touch .prizmkit/specs/{{FEATURE_SLUG}}/.prizmkit-test-started
+```
 
 Gate requirements:
 - Generate or update tests only for this feature's changed files, changed public interfaces, and acceptance criteria.
@@ -339,40 +346,6 @@ Gate requirements:
 - Only after a valid `PASS`, write the report path to `.prizmkit/specs/{{FEATURE_SLUG}}/test-report-path.txt` and append a 3-5 bullet `## PrizmKit Test Gate` summary to `context-snapshot.md`.
 - If the report verdict is `NEEDS_FIXES`, fix in-scope implementation/test issues and rerun `/prizmkit-test`. If the report is `BLOCKED`, missing, stale, or for the wrong scope/artifact dir, write `failure-log.md` and stop for recovery.
 
-### Phase 5: Review — Reviewer Subagent
-
-Spawn Reviewer subagent (Agent tool, subagent_type="prizm-dev-team-reviewer", run_in_background=false).
-
-Spawn failure cap: for team/config/lock errors, retry at most once for this Reviewer spawn. If the second attempt fails, do not poll for `review-report.md`; write `failure-log.md` with the spawn error and last observable state before stopping or performing an inline fallback.
-
-Prompt:
-> "Read {{REVIEWER_SUBAGENT_PATH}}. For feature {{FEATURE_ID}} (slug: {{FEATURE_SLUG}}):
-> 1. Read `.prizmkit/specs/{{FEATURE_SLUG}}/spec.md` for goals and acceptance criteria
-> 2. Read `.prizmkit/specs/{{FEATURE_SLUG}}/plan.md` for architecture decisions and completed tasks
-> 3. Read `.prizmkit/specs/{{FEATURE_SLUG}}/test-report-path.txt`, then read the referenced `/prizmkit-test` report. Review generated/updated tests, `In-Scope Failures`, `Baseline Failures`, `Out of Scope Gaps`, boundary coverage if present, and the report verdict.
-> 4. Run /prizmkit-code-review with artifact_dir=.prizmkit/specs/{{FEATURE_SLUG}}/. The skill runs an internal review-fix loop (Reviewer → filter → Dev fix, max 3 rounds) and writes review-report.md.
-> 5. Do NOT run test suites — the Orchestrator already ran prizmkit-test. Focus on code review and fix strategy.
-> Report: verdict (PASS/NEEDS_FIXES), number of rounds, findings fixed/rejected."
-
-Wait for Reviewer to return.
-
-**Gate Check — Review Report**:
-After Reviewer agent returns, verify the review report was written:
-```bash
-grep -q "## Verdict" .prizmkit/specs/{{FEATURE_SLUG}}/review-report.md && echo "GATE:PASS" || echo "GATE:MISSING"
-```
-If GATE:MISSING:
-- Do not re-spawn Reviewer or re-run `/prizmkit-code-review` in an unbounded report-repair loop.
-- Perform one bounded status check; retry at most once: inspect Reviewer output, code-review skill output, `review-report.md` path, and any Reviewer/Dev spawn messages.
-- If the missing report is caused by team/config/lock errors from Reviewer or the internal code-review loop, write `failure-log.md` with the spawn/skill error and last observable state.
-- If the report is still missing after that single check/retry, either perform a safe inline fallback review and write `review-report.md` with `## Verdict`, or stop with a clear recovery failure.
-
-Read `review-report.md` and check the Verdict:
-- `PASS` → proceed to next phase
-- `NEEDS_FIXES` → the skill exhausted its max rounds; log the remaining findings and proceed
-
-**CP-3**: Review complete.
-
 {{IF_BROWSER_INTERACTION}}
 ### Phase 5.5: Browser Verification — MANDATORY
 

package/bundled/dev-pipeline/templates/bootstrap-tier3.md

@@ -52,22 +52,18 @@ You are running in **headless non-interactive mode** with a FINITE context windo
 
 1. **context-snapshot.md is your single source of truth** — After Phase 1-2 builds it, 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.
+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.
 4. **One task at a time** — In Phase 4 (implement), 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 Phase 1-5. All changes are committed once at the end in Phase 6 via `/prizmkit-committer`.
 7. **Batch independent operations** — Issue multiple independent `Write`/`Read` calls in a single message turn when they have no dependencies. Combine multiple `mkdir -p` into one command. Never run `npm test` twice just to apply a different grep filter — capture output to `/tmp/test-out.txt` once and grep the file.
-8. **Scaffold / generated file awareness** — Files created by scaffolding tools are boilerplate. Tag them, record in context-snapshot.md, NEVER re-read. Edit directly without reading first.
 9. **Package version verification (BLOCKING)** — Verify dependency versions via registry query before writing them. NEVER guess.
 10. **Build artifact hygiene** — After build/compile, ensure output is in `.gitignore`.
-11. **Anti re-read hard rule (BLOCKING)** — Once you have read a file into context, do NOT read the full file again. 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. Applies to orchestrator AND subagents.
-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` for exact range. 2 consecutive offset errors → STOP Reading that file. Never guess offsets — `grep -n '<anchor>'` first.
 
 ---
 
-{{LOG_SIZE_AWARENESS}}
----
-
 ## PrizmKit Directory Convention
 
 ```
@@ -98,19 +94,6 @@ If any agent times out:
 - **CP-0**: Verify `.prizmkit/prizm-docs/root.prizm`, `.prizmkit/config.json` exist
 {{END_IF_INIT_NEEDED}}
 {{IF_INIT_DONE}}
-### Phase 0: Record Test Baseline & Detect Test Commands
-
-**Step 1 — Detect test commands**: You know this project's tech stack. Identify ALL test commands that apply (e.g., `go test ./...`, `npm test`, `cargo test`, `pytest`, `make test`, etc.). Record them as `TEST_CMDS`.
-
-**Step 2 — Record pre-existing failure baseline**:
-```bash
-# Run each test command, capture output
-($TEST_CMD) 2>&1 | tee /tmp/test-baseline.txt | tail -20
-```
-Save the list of **pre-existing failing tests** (if any) as `BASELINE_FAILURES`. These are known failures that existed before this session — Dev must NOT be blamed for them, but must list them in COMPLETION_SIGNAL.
-
-> **⚠️ Test Output Rule**: Always capture test output to a temp file (`tee /tmp/test-out.txt`). Then grep the file instead of re-running the suite.
-{{END_IF_INIT_DONE}}
 
 ### Step 1: Initialize
 
@@ -182,7 +165,7 @@ If `EXISTING_CODE` is non-empty: your spec/plan/tasks must reflect this existing
 ls .prizmkit/specs/{{FEATURE_SLUG}}/spec.md .prizmkit/specs/{{FEATURE_SLUG}}/plan.md 2>/dev/null
 ```
 
-- spec.md missing: Run `/prizmkit-plan` → generate spec.md. Resolve any `[NEEDS CLARIFICATION]` markers using the feature description — do NOT pause for interactive input.
+- spec.md missing: Run `/prizmkit-plan` → generate spec.md. Resolve uncertain requirements from the feature description, existing code, and conservative existing-project patterns.
 - plan.md missing: Run `/prizmkit-plan` → generate plan.md (architecture, components, interface design, data model, testing strategy, risk assessment, and Tasks section with `[ ]` checkboxes)
 
 > All files go under `.prizmkit/specs/{{FEATURE_SLUG}}/`. Confirm each with `ls` after writing.
@@ -191,14 +174,14 @@ ls .prizmkit/specs/{{FEATURE_SLUG}}/spec.md .prizmkit/specs/{{FEATURE_SLUG}}/pla
 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**: Both spec.md and plan.md exist.
 
 ### Phase 3: Analyze — Reviewer Agent
 
-Spawn Reviewer agent (Agent tool, subagent_type="prizm-dev-team-reviewer", mode="plan", run_in_background=false).
+Spawn Reviewer agent (Agent tool, subagent_type="prizm-dev-team-reviewer", mode="plan", run_in_background=false, isolation=default/no worktree). Do not request worktree isolation; this prevents AI tool-created `.claude/worktrees/...` subagent worktrees. PrizmKit pipeline-managed linked git worktrees under `.prizmkit/state/worktrees/...` are separate and controlled by `USE_WORKTREE`.
 
 Spawn failure cap: for team/config/lock errors, retry at most once for this Reviewer spawn. If the second attempt fails, do not poll for report artifacts; fix/check the plan inline or write `failure-log.md` before stopping for recovery.
 
@@ -227,7 +210,7 @@ If CRITIC:MISSING — skip Phase 3.5 entirely and proceed to Phase 4. Log: "Crit
 
 **If {{CRITIC_COUNT}} = 1 → Single Critic** (skip to CP-2.5 after this):
 
-Spawn Critic agent (Agent tool, subagent_type="prizm-dev-team-critic", mode="plan", run_in_background=false).
+Spawn Critic agent (Agent tool, subagent_type="prizm-dev-team-critic", mode="plan", run_in_background=false, isolation=default/no worktree). Do not request worktree isolation; this prevents AI tool-created `.claude/worktrees/...` subagent worktrees. PrizmKit pipeline-managed linked git worktrees under `.prizmkit/state/worktrees/...` are separate and controlled by `USE_WORKTREE`.
 
 Spawn failure cap: for team/config/lock errors, retry at most once for this Critic spawn. If the second attempt fails, do not poll for challenge reports; perform the plan challenge inline and record the fallback.
 
@@ -235,16 +218,17 @@ Prompt:
 > "Read {{CRITIC_SUBAGENT_PATH}}. For feature {{FEATURE_ID}} (slug: {{FEATURE_SLUG}}):
 > **MODE: Plan Challenge**
 > 1. Read `.prizmkit/specs/{{FEATURE_SLUG}}/context-snapshot.md` FIRST — Section 3 has TRAPS/RULES, Section 4 has file manifest.
-> 2. Read `.prizmkit/prizm-docs/root.prizm` and relevant L1/L2 docs for affected modules.
-> 3. Read existing source files in the modules this plan touches.
-> 4. Challenge plan.md against the project's existing architecture, patterns, and style.
+> 2. Use context-snapshot.md as the shared source of truth. Do not create or enter AI tool-created `.claude/worktrees/...` subagent worktrees; use default/no worktree isolation and do not request worktree isolation.
+> 3. PrizmKit pipeline-managed linked git worktrees under `.prizmkit/state/worktrees/...` are a separate runner feature controlled by `USE_WORKTREE`; do not confuse them with AI tool-created `.claude/worktrees/...`.
+> 4. Read additional `.prizmkit/prizm-docs/` or source excerpts only when needed to verify a specific challenge.
+> 5. Challenge plan.md against the project's existing architecture, patterns, and style.
 > Write `.prizmkit/specs/{{FEATURE_SLUG}}/challenge-report.md` with findings (or 'No significant challenges')."
 
 **If {{CRITIC_COUNT}} = 3 → Multi-Critic Voting** (skip Single Critic above):
 
 **IMPORTANT**: Spawn all 3 Critics in PARALLEL (issue all 3 Agent tool calls in the SAME message turn). Do NOT wait for one before spawning the next.
 
-Spawn Critic-A, Critic-B, Critic-C simultaneously (each with mode="plan", run_in_background=false):
+Spawn Critic-A, Critic-B, Critic-C simultaneously (each with mode="plan", run_in_background=false, isolation=default/no worktree). Do not request worktree isolation; this prevents AI tool-created `.claude/worktrees/...` subagent worktrees. PrizmKit pipeline-managed linked git worktrees under `.prizmkit/state/worktrees/...` are separate and controlled 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.
@@ -281,26 +265,21 @@ 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
 - Creates/updates L2 `.prizm` docs when creating new modules
 - Defers scoped/full test execution until after the code-review loop completes
+- 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
@@ -308,7 +287,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
@@ -318,20 +297,40 @@ 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**:
+### Review — Code Review
+
+Review the completed implementation before the scoped feature test gate runs. Use `artifact_dir=.prizmkit/specs/{{FEATURE_SLUG}}/` so the code-review skill can read spec, plan, context snapshot, implementation log, and current diff artifacts. Do not require or read a prior `/prizmkit-test` report here; test generation and test-fix looping happen in the next phase.
+
+Run `/prizmkit-code-review` with `artifact_dir=.prizmkit/specs/{{FEATURE_SLUG}}/`.
+
+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:
 ```bash
-python3 $PIPELINE_DIR/scripts/update-checkpoint.py \
-  --checkpoint-path .prizmkit/specs/{{FEATURE_SLUG}}/workflow-checkpoint.json \
-  --step prizmkit-implement \
-  --status completed
+grep -q "## Verdict" .prizmkit/specs/{{FEATURE_SLUG}}/review-report.md && echo "GATE:PASS" || echo "GATE:MISSING"
 ```
+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 agent spawn messages.
+- If the missing report is caused by 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:
+- `PASS` → proceed to next phase
+- `NEEDS_FIXES` → the skill exhausted its max rounds; log the remaining findings and proceed (do not retry externally)
 
+**CP-3**: Review complete, report written.
 
 ### Scoped Feature Test Gate — PrizmKit Test
 
 Run `/prizmkit-test scope=this-change artifact_dir=.prizmkit/specs/{{FEATURE_SLUG}}/` after review and before commit.
 
-Before invoking the skill, create `.prizmkit/specs/{{FEATURE_SLUG}}/.prizmkit-test-started` so stale reports are ignored.
+Before invoking the skill, create a current-run marker so stale reports are ignored:
+```bash
+mkdir -p .prizmkit/specs/{{FEATURE_SLUG}}
+touch .prizmkit/specs/{{FEATURE_SLUG}}/.prizmkit-test-started
+```
 
 Gate requirements:
 - Generate or update tests only for this feature's changed files, changed public interfaces, and acceptance criteria.
@@ -341,40 +340,6 @@ Gate requirements:
 - Only after a valid `PASS`, write the report path to `.prizmkit/specs/{{FEATURE_SLUG}}/test-report-path.txt` and append a 3-5 bullet `## PrizmKit Test Gate` summary to `context-snapshot.md`.
 - If the report verdict is `NEEDS_FIXES`, fix in-scope implementation/test issues and rerun `/prizmkit-test`. If the report is `BLOCKED`, missing, stale, or for the wrong scope/artifact dir, write `failure-log.md` and stop for recovery.
 
-### Phase 5: Review — Reviewer Agent
-
-Spawn Reviewer agent (Agent tool, subagent_type="prizm-dev-team-reviewer", run_in_background=false).
-
-Spawn failure cap: for team/config/lock errors, retry at most once for this Reviewer spawn. If the second attempt fails, do not poll for `review-report.md`; write `failure-log.md` with the spawn error and last observable state before stopping or performing an inline fallback.
-
-Prompt:
-> "Read {{REVIEWER_SUBAGENT_PATH}}. For feature {{FEATURE_ID}} (slug: {{FEATURE_SLUG}}):
-> 1. Read `.prizmkit/specs/{{FEATURE_SLUG}}/spec.md` for goals and acceptance criteria
-> 2. Read `.prizmkit/specs/{{FEATURE_SLUG}}/plan.md` for architecture decisions and completed tasks
-> 3. Read `.prizmkit/specs/{{FEATURE_SLUG}}/test-report-path.txt`, then read the referenced `/prizmkit-test` report. Review generated/updated tests, `In-Scope Failures`, `Baseline Failures`, `Out of Scope Gaps`, boundary coverage if present, and the report verdict.
-> 4. Run /prizmkit-code-review with artifact_dir=.prizmkit/specs/{{FEATURE_SLUG}}/. The skill runs an internal review-fix loop (Reviewer → filter → Dev fix, max 3 rounds) and writes review-report.md.
-> 5. Do NOT run test suites — the Orchestrator already ran prizmkit-test. Focus on code review and fix strategy.
-> Report: verdict (PASS/NEEDS_FIXES), number of rounds, findings fixed/rejected."
-
-Wait for Reviewer to return.
-
-**Gate Check — Review Report**:
-After Reviewer agent returns, verify the review report was written:
-```bash
-grep -q "## Verdict" .prizmkit/specs/{{FEATURE_SLUG}}/review-report.md && echo "GATE:PASS" || echo "GATE:MISSING"
-```
-If GATE:MISSING:
-- Do not re-spawn Reviewer or re-run `/prizmkit-code-review` in an unbounded report-repair loop.
-- Perform one bounded status check; retry at most once: inspect Reviewer output, code-review skill output, `review-report.md` path, and any Reviewer/Dev spawn messages.
-- If the missing report is caused by team/config/lock errors from Reviewer or the internal code-review loop, write `failure-log.md` with the spawn/skill error and last observable state.
-- If the report is still missing after that single check/retry, either perform a safe inline fallback review and write `review-report.md` with `## Verdict`, or stop with a clear recovery failure.
-
-Read `review-report.md` and check the Verdict:
-- `PASS` → proceed to next phase
-- `NEEDS_FIXES` → the skill exhausted its max rounds; log the remaining findings and proceed
-
-**CP-3**: Review complete.
-
 {{IF_BROWSER_INTERACTION}}
 ### Phase 5.5: Browser Verification — MANDATORY
 

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

@@ -40,20 +40,17 @@ You are the **bug fix session agent**. Fix Bug {{BUG_ID}}: "{{BUG_TITLE}}".
 
 {{GLOBAL_CONTEXT}}
 
-### Project Conventions
-
-> Read {{PLATFORM_CONVENTIONS}} for project-level coding standards, architecture decisions, and development rules.
 
 ## ⚠️ Context Budget Rules (CRITICAL)
 
 0. **NON-INTERACTIVE MODE** — NEVER ask for confirmation. Proceed autonomously.
 1. **context-snapshot.md is your single source of truth** — After it is built, read context-snapshot.md instead of re-reading individual source files.
 2. **Never re-read your own writes** — Trust your write was correct.
-3. **Stay focused** — Do NOT explore code unrelated to this bug.
+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 after your last read. Use `grep -n` or `sed -n` for targeted lookups instead of full-file Read. Before issuing a Read, ask: "Have I read this file before, and has it changed since?" If no — do NOT read it. Subagents must rely on context-snapshot.md rather than re-reading files the orchestrator already read.
+4. **Stay focused** — Do NOT explore code unrelated to this bug.
 4. **Minimize tool output** — Capture to temp file, scan head/tail, filter with grep/sed/awk. Never load full output.
 5. **No intermediate commits** — All changes committed once at the end via `/prizmkit-committer`.
 
-{{LOG_SIZE_AWARENESS}}
 ## Bug Fix Artifacts Directory
 
 ```
@@ -64,16 +61,7 @@ You are the **bug fix session agent**. Fix Bug {{BUG_ID}}: "{{BUG_TITLE}}".
 └── fix-report.md        ← Final bug resolution report
 ```
 
-## Workflow Checkpoint System
-
-**Path**: `{{CHECKPOINT_PATH}}`
-
-**Rules**:
-1. **Before each step**: Read `workflow-checkpoint.json`, verify the previous step is `"completed"`. If not, complete it first.
-2. **Starting a step**: Update to `status: "in_progress"`.
-3. **After step completes**: Update to `status: "completed"`.
-4. **On failure**: Set to `status: "failed"` and continue if possible.
-5. **On resume**: Skip `"completed"` steps. Start from first `"pending"` or `"in_progress"` step.
+{{CHECKPOINT_SYSTEM}}
 
 ---
 
@@ -138,7 +126,7 @@ Run `/prizmkit-plan` with `artifact_dir=.prizmkit/bugfix/{{BUG_ID}}/`:
 - The spec.md should capture: root cause, impact scope, behavior that must be preserved
 - The plan.md Tasks section **MUST start with a reproduction test task** — a test that FAILS with current code (RED state), proving the bug exists
 - Subsequent tasks implement the minimal fix to make the test pass (GREEN state)
-- Resolve any `[NEEDS CLARIFICATION]` markers autonomously — do NOT pause
+- Resolve uncertain fix details autonomously from the bug report, failing behavior, existing code, and conservative existing-project patterns.
 
 {{IF_BROWSER_INTERACTION}}
 - **Browser Verification**: If the bug is UI-reproducible, plan.md should reference the Browser Verification Protocol above instead of redefining browser steps.
@@ -192,7 +180,7 @@ After implement completes, verify:
 If `FAST_PATH=true` (≤ 2 tasks, obvious root cause), skip this phase entirely.
 
 Run `/prizmkit-code-review` with `artifact_dir=.prizmkit/bugfix/{{BUG_ID}}/`:
-- The skill runs an internal review-fix loop (Reviewer → filter → Dev fix, max 3 rounds) and writes `review-report.md`
+- The skill runs an internal review-fix loop (Reviewer → filter → orchestrator fix, max 3 rounds) and writes `review-report.md`
 - `review-report.md` must contain `## Verdict`
 
 **Gate Check — Review Report**: