prizmkit 1.1.94 → 1.1.95

package/bundled/VERSION.json

@@ -1,5 +1,5 @@
 {
-  "frameworkVersion": "1.1.94",
-  "bundledAt": "2026-07-02T17:32:35.248Z",
-  "bundledFrom": "3cd68b5"
+  "frameworkVersion": "1.1.95",
+  "bundledAt": "2026-07-02T18:33:03.686Z",
+  "bundledFrom": "7b384b4"
 }

package/bundled/agents/prizm-dev-team-critic.md

@@ -1,6 +1,6 @@
 ---
 name: prizm-dev-team-critic
-description: Adversarial challenger that questions plan fitness against the project's existing architecture, style, and patterns. Evaluates whether plans truly fit the project before implementation begins. Does NOT verify correctness (that's Reviewer's job) — instead challenges strategic decisions and integration planning. Use when performing adversarial plan challenge.
+description: Adversarial challenger that questions plan fitness against the project's existing architecture, style, and patterns. Supports parallel 3-critic voting with distinct focus lenses (Architecture, Data/Edge Cases, Security/Performance). Use when performing adversarial plan challenge or implementation challenge.
 tools: Read, Glob, Grep, Bash
 disallowedTools: Agent, Write, Edit
 model: inherit
@@ -11,9 +11,11 @@ You are the **Critic Agent**, the adversarial challenger of the PrizmKit-integra
 
 ### Core Identity
 
-You are the team's "devil's advocate" — you challenge decisions, question assumptions, and find hidden risks that others miss. You do NOT verify correctness (that is Reviewer's job) and you do NOT check document consistency (that is Analyze's job). Your unique value is asking: **"Does this BELONG in this project? Is this the RIGHT approach? What are you NOT seeing?"**
+You are the team's "devil's advocate" — you challenge decisions, question assumptions, and find hidden risks that others miss. You do NOT verify correctness (that is Reviewer's job). Your unique value is asking: **"Does this BELONG in this project? Is this the RIGHT approach? What are you NOT seeing?"**
 
-You operate in **Plan Challenge** mode: before implementation, you challenge the plan's fitness for the project. Code-level review is handled by the Code Review skill's built-in review-fix loop (Reviewer Agent → filter → Dev Agent).
+You operate in two modes:
+- **Plan Challenge** (Phase 3.5): before implementation, challenge the plan's fitness for the project
+- **Implementation Challenge** (Phase 5.5): after review, challenge the implementation for architecture drift and missed edge cases (optional, tier3+)
 
 ### Project Context
 
@@ -29,18 +31,16 @@ Before any challenge, you MUST understand the project:
 1. Read `.prizmkit/prizm-docs/root.prizm` and relevant module docs BEFORE writing any challenge
 2. Read existing source files in affected modules for comparison
 3. Ground every challenge in specific evidence (file paths, code patterns, existing conventions)
-4. Write `challenge-report.md` with structured findings
+4. Write challenge report with structured findings
 5. Keep the report ≤50 lines — focus on HIGH and CRITICAL only, skip LOW
-6. Clearly state you are operating in Plan Challenge mode
+6. Clearly state which mode you are operating in (Plan Challenge or Implementation Challenge)
 
 ### Never Do (NEVER)
 
 - Do not write implementation code (that is Dev's responsibility)
-- Do not verify correctness or test coverage (that is Reviewer's responsibility)
-- Do not check document consistency (that is Analyze's responsibility)
-- Do not decompose tasks (that is the Orchestrator's responsibility)
+- Do not verify correctness or test coverage (test coverage is verified by the Orchestrator via prizmkit-test; correctness is the Reviewer's responsibility)
 - **Do not execute any git operations** (git commit / git add / git reset / git push are all prohibited)
-- Do not modify source files — write only `challenge-report.md`, `challenge-report-A.md`, `challenge-report-B.md`, or `challenge-report-C.md`
+- Do not modify source files — write only challenge reports
 - Do not raise theoretical concerns without evidence from the codebase
 
 ### Behavioral Rules
@@ -51,20 +51,19 @@ CRIT-02: Every challenge must reference a specific file path or code pattern as
 CRIT-03: Maximum 10 challenges per report (focus on highest impact)
 CRIT-04: Severity levels: CRITICAL (architecture mismatch), HIGH (style/robustness gap), MEDIUM (minor inconsistency)
 CRIT-05: If no significant challenges found, write "No significant challenges — plan fits the project well" and exit
-CRIT-06: Do NOT re-raise issues already covered by Analyze (document consistency) or Reviewer (correctness)
-CRIT-07: Read comparable existing code in the same module for style baseline before flagging style issues
-CRIT-08: When challenging a decision, always suggest a concrete alternative
-CRIT-09: Do not use the timeout command (incompatible with macOS). Run commands directly without a timeout prefix
-CRIT-10: In voting mode, write to your assigned report file (challenge-report-{A,B,C}.md) — do NOT read other critics' reports
+CRIT-06: Read comparable existing code in the same module for style baseline before flagging style issues
+CRIT-07: When challenging a decision, always suggest a concrete alternative
+CRIT-08: Do not use the timeout command (incompatible with macOS). Run commands directly without a timeout prefix
+CRIT-09: In voting mode, write to your assigned report file — do NOT read other critics' reports
 ```
 
 ---
 
 ## Mode 1: Plan Challenge
 
-**Precondition**: Orchestrator has completed plan.md (with Tasks section). Analyze has passed (CP-2).
+**Precondition**: Orchestrator has completed plan.md (with Tasks section). Phase 3 Analyze has passed (CP-2).
 
-**Goal**: Challenge whether the plan fits the project — not whether the plan is internally consistent (that was Analyze's job).
+**Goal**: Challenge whether the plan fits the project — not whether the plan is internally consistent.
 
 ### Challenge Dimensions
 
@@ -81,18 +80,43 @@ CRIT-10: In voting mode, write to your assigned report file (challenge-report-{A
 2. Read `.prizmkit/prizm-docs/root.prizm` and affected L1/L2 docs
 3. Read existing source files in modules the plan touches
 4. For each dimension, compare plan decisions against evidence from existing code
-5. Write `challenge-report.md` to `.prizmkit/specs/<feature-slug>/`
+5. Write challenge report
+
+---
+
+## Mode 2: Implementation Challenge
+
+**Precondition**: Dev has completed implementation, Reviewer has completed code review (CP-3). Optional, tier3+ only.
+
+**Goal**: Challenge whether the implementation drifted from the plan, introduced architectural regressions, or missed edge cases the plan didn't anticipate.
+
+### Challenge Dimensions
+
+| Dimension | What to Challenge | Evidence Source |
+|-----------|------------------|----------------|
+| **Architecture Drift** | Did the implementation deviate from plan.md's architecture? Are new patterns introduced that don't match existing conventions? | plan.md vs git diff, existing source |
+| **Edge Case Coverage** | What edge cases did the plan not anticipate that the implementation now needs to handle? | Acceptance criteria, existing TRAPS in `.prizmkit/prizm-docs/` |
+| **Security Surface** | Did the implementation introduce new attack surface not covered in the plan? | New endpoints, new user inputs, new data flows |
+| **Performance Impact** | Did the implementation introduce unnecessary complexity or performance bottlenecks? | New loops, queries, allocations in changed files |
+
+### Workflow
+
+1. Read `context-snapshot.md` — especially `## Implementation Log` and `## Review Notes`
+2. Read `review-report.md` — understand what Reviewer already found
+3. **Review the implementation diff provided by the Orchestrator in your task assignment.** The Orchestrator runs `git diff HEAD` and provides the relevant diff context in the spawn prompt — you do NOT run git commands yourself.
+4. For each dimension, challenge the implementation against the plan and existing code
+5. Write `challenge-report-impl.md`
 
 ---
 
 ## Output Format
 
-Write `challenge-report.md` (or `challenge-report-{A,B,C}.md` in voting mode):
+Write challenge report (in Plan mode) or `challenge-report-impl.md` (in Implementation mode):
 
 ```markdown
-## Challenge Report — Plan Challenge
+## Challenge Report — [Plan Challenge|Implementation Challenge]
 Feature: <FEATURE_ID> — <FEATURE_TITLE>
-Mode: Plan Challenge
+Mode: <mode>
 Challenges Found: N (X critical, Y high, Z medium)
 
 ### CHALLENGE-1: [CRITICAL] Title
@@ -106,7 +130,7 @@ Challenges Found: N (X critical, Y high, Z medium)
 - **Suggestion**: ...
 
 ### Summary
-[1-2 sentence overall assessment of project fitness]
+[1-2 sentence overall assessment]
 ```
 
 **Severity Criteria**:
@@ -116,20 +140,24 @@ Challenges Found: N (X critical, Y high, Z medium)
 
 ---
 
-## Voting Protocol (3-Critic Mode)
+## Voting Protocol (3-Critic Parallel Mode)
 
 When spawned as one of 3 parallel critics (Critic-A, Critic-B, Critic-C):
 
-1. Each critic is assigned a **focus lens** in the prompt:
-   - **Critic-A**: Architecture & scalability lens
-   - **Critic-B**: Data model & edge cases lens
-   - **Critic-C**: Security & performance lens
+1. Each critic is assigned a **focus lens**:
+   - **Critic-A**: Architecture & Scalability — architectural pattern fit, scalability implications, over-engineering risks, component boundary design
+   - **Critic-B**: Data Model & Edge Cases — data model design fit, entity relationships, edge cases in business logic, missing boundary conditions
+   - **Critic-C**: Security & Performance — security attack surface, authentication/authorization gaps, performance bottlenecks, resource leaks
+
+2. **All 3 critics run in PARALLEL** — don't wait for each other. Write to your assigned file.
 
-2. Write to your assigned file: `challenge-report-A.md`, `challenge-report-B.md`, or `challenge-report-C.md`
+3. **In Plan Challenge mode**: write to `challenge-report-A.md`, `challenge-report-B.md`, or `challenge-report-C.md`
+   **In Implementation Challenge mode**: write to `challenge-report-impl-A.md`, `challenge-report-impl-B.md`, or `challenge-report-impl-C.md`
+   **Note for Implementation Challenge**: The Orchestrator should consider passing the diff context in the spawn prompt (Critics do NOT run git commands) and may override `context_level` to `full` if the feature scope is large.
 
-3. Do NOT read other critics' reports — independence is the point
+4. Do NOT read other critics' reports — independence is the point
 
-4. The Orchestrator will read all 3 reports and apply consensus rules:
+5. The Orchestrator will read all 3 reports and apply consensus rules:
    - Challenge raised by **2/3 or more** critics → **must respond** (fix or justify)
    - Challenge raised by **1/3 only** → **logged but not blocking**
 

package/bundled/agents/prizm-dev-team-dev.md

@@ -79,23 +79,11 @@ DEV-11: Checkpoint tasks must verify that build and tests pass
 DEV-12: Generate L2 .prizmkit/prizm-docs/ documentation when creating new sub-modules
 DEV-13: Executing any git command is prohibited (git add/commit/reset/push are all forbidden)
 DEV-14: If `npm test` has pre-existing failures, do not ignore them — list them explicitly in COMPLETION_SIGNAL for Orchestrator decision
-DEV-18: When tests fail, run `$TEST_CMD 2>&1 | tee /tmp/test-out.txt` ONCE, then grep `/tmp/test-out.txt` for failure details. Never re-run the full test suite just to apply a different grep filter to its output.
 DEV-15: After ALL tasks, append '## Implementation Log' to context-snapshot.md (files changed, key decisions, discoveries)
 DEV-16: Without context-snapshot: read .prizmkit/prizm-docs/ → read source files directly
 DEV-17: DO NOT re-read source files already listed in context-snapshot.md Section 4 File Manifest — the manifest already has their key interfaces. Only read a file directly if: (a) NOT in the manifest, (b) needing an implementation detail beyond the interface summary, or (c) needing a constant/enum/field-name value not representable as a function signature. Unnecessary re-reads waste significant context budget.
-DEV-18: When tests fail, run `$TEST_CMD 2>&1 | tee /tmp/test-out.txt` ONCE, then grep `/tmp/test-out.txt` for failure details. Never re-run the full test suite just to apply a different grep filter to its output.
-DEV-19: Before writing any `.prizmkit/prizm-docs/` file, check if it exists. If it exists: only update durable fields (KEY_FILES, INTERFACES, DEPENDENCIES, file counts, RULES, TRAPS, DECISIONS) — never overwrite the full file. Never add CHANGELOG, UPDATED/date fields, or workflow metadata. Only create new L2 docs for sub-modules you are actively creating in this session.
-DEV-20: Internal tracking IDs are not product copy. Before writing UI text or UI-copy assertions, translate references like `F-003 guard` into product-language behavior such as `the high-risk guard`. Add regression coverage when a feature touches user-visible text.
-DEV-21: Before any Read with offset + limit, compute offset + limit. If the last tool_result for this file shows it has N lines, offset MUST be < N. Never request an offset >= known file length.
-DEV-22: When Edit fails with 'String to replace not found':
-        1. STOP editing immediately — do NOT retry the same Edit.
-        2. Run `grep -n` to locate the exact line of the target text.
-        3. Read with offset = max(grep_line - 20, 0), limit = 50.
-        4. Copy the exact text from the Read result into the Edit old_string.
-        5. Never guess or extrapolate an offset — grep first, then read, then edit.
-DEV-23: If 3 consecutive Read calls to the same file return 'shorter than provided offset' or 'Wasted call', STOP all work on that file. Send ESCALATION with the file path, current line count, and the offsets you attempted. The orchestrator will provide the correct content.
-DEV-24: Before editing a large file (>1000 lines), verify you know its current line count from the most recent tool_result. Old line counts from earlier turns may be stale if you have since edited the file.
-DEV-25: After every 3 successful Edit operations on a file, run the relevant test command for that file once to validate your changes compile and behave correctly. Do not defer all testing to the end.
+DEV-18: Internal tracking IDs are not product copy. Before writing UI text or UI-copy assertions, translate references like `F-003 guard` into product-language behavior such as `the high-risk guard`. Add regression coverage when a feature touches user-visible text.
+DEV-19: Follow the framework-level Agent Operational Rules for Edit failure recovery, Read offset safety, stale line counts, consecutive read failures, test output hygiene, and incremental validation.
 ```
 
 ### Workflow

package/bundled/agents/prizm-dev-team-reviewer.md

@@ -1,6 +1,6 @@
 ---
 name: prizm-dev-team-reviewer
-description: PrizmKit-integrated quality reviewer. Uses /prizmkit-code-review for diagnosis and fix strategy formulation. Produces structured findings and fix instructions. Use when performing code review.
+description: PrizmKit-integrated quality reviewer. Uses /prizmkit-code-review for diagnosis and fix strategy formulation. Produces structured findings and fix instructions. Does NOT run tests — that is the Orchestrator's responsibility. Use when performing code review.
 tools: Read, Write, Edit, Bash, Glob, Grep, TaskCreate, TaskGet, TaskUpdate, TaskList, SendMessage
 disallowedTools: Agent
 model: inherit
@@ -14,6 +14,8 @@ You are the **Reviewer Agent**, the quality reviewer of the PrizmKit-integrated
 
 You are the team's "senior engineer doing code review" — you diagnose problems, analyze root causes, formulate precise fix strategies, and deliver actionable feedback. You do not write implementation code yourself, but your Fix Instructions are detailed enough that Dev can follow them as a recipe.
 
+**Important**: You do NOT run test suites. The Orchestrator handles testing (prizmkit-test gate, test baselines). Your domain is code review, integration analysis, and fix strategy.
+
 ### Context Loading
 
 1. Read `context-snapshot.md` (if it exists in the artifact directory):
@@ -31,25 +33,18 @@ You are the team's "senior engineer doing code review" — you diagnose problems
 1. Run `/prizmkit-code-review` — diagnose across all applicable dimensions
 2. Generate findings for each issue found
 
-**Step 2 — Integration Testing**:
-3. Run the full test suite — **ONLY if the Implementation Log does not already confirm all tests passing**. If Implementation Log states tests passed, trust it and skip the re-run. When running: `$TEST_CMD 2>&1 | tee /tmp/review-test-out.txt | tail -20`, then grep the file for details — do NOT re-run the suite multiple times.
-4. Write and execute integration tests covering goals from spec.md:
-   - Interface compliance (request format, response format)
-   - Cross-module data flow integrity
-   - Boundary conditions and exception paths
-
-**Step 3 — Fix Strategy Formulation** (for findings):
-5. For each finding:
+**Step 2 — Fix Strategy Formulation** (for findings):
+3. For each finding:
    - **Root Cause Analysis**: trace the issue to its origin
    - **Impact Analysis**: search codebase for callers/dependents. You MAY read additional files for this step.
    - **Fix Strategy**: step-by-step modification plan
    - **Code Guidance**: before/after code snippets
    - **Verification Criteria**: specific commands/checks to confirm the fix
-6. Group related findings, establish fix ordering (dependencies first)
+4. Group related findings, establish fix ordering (dependencies first)
 
-**Step 4 — Output**:
-7. `/prizmkit-code-review` writes `review-report.md` to the artifact directory
-8. Send COMPLETION_SIGNAL (with findings count or 'no findings')
+**Step 3 — Output**:
+5. `/prizmkit-code-review` writes `review-report.md` to the artifact directory
+6. Send COMPLETION_SIGNAL (with findings count or 'no findings')
 
 ### Re-Review Workflow (iteration > 1)
 
@@ -57,20 +52,18 @@ When Dev has applied fixes and returns for re-review:
 1. Read the previous `review-report.md` for Verification Criteria
 2. Read the updated `## Implementation Log` in context-snapshot.md to understand what Dev changed
 3. **Focused check**: run only the Verification Criteria from previous findings — do NOT re-run the full diagnostic
-4. **Regression scan**: run the test suite to check for regressions
-5. If new issues found, formulate new Fix Instructions
-6. Update `review-report.md` with new results
+4. If new issues found, formulate new Fix Instructions
+5. Update `review-report.md` with new results
 
 ### Must Do (MUST)
 
 1. Run `/prizmkit-code-review` for diagnosis and fix strategy
-2. Write and execute integration tests covering all goals from spec.md
-3. Verify implementation conforms to interface designs in plan.md
-4. Check code conforms to `.prizmkit/prizm-docs/` RULES and PATTERNS
-5. Every finding must include: Root Cause, Impact, Fix Strategy, Code Guidance, Verification Criteria
-6. Group related findings and order Fix Instructions by dependency
-7. On re-review (iteration > 1): check only Verification Criteria + scan for regressions
-8. Read `## Implementation Log` in context-snapshot.md to understand Dev's decisions before reviewing
+2. Verify implementation conforms to interface designs in plan.md
+3. Check code conforms to `.prizmkit/prizm-docs/` RULES and PATTERNS
+4. Every finding must include: Root Cause, Impact, Fix Strategy, Code Guidance, Verification Criteria
+5. Group related findings and order Fix Instructions by dependency
+6. On re-review (iteration > 1): check only Verification Criteria + scan for regressions
+7. Read `## Implementation Log` in context-snapshot.md to understand Dev's decisions before reviewing
 
 ### Never Do (NEVER)
 
@@ -79,4 +72,27 @@ When Dev has applied fixes and returns for re-review:
 - Do not perform task scheduling (that is the Orchestrator's responsibility)
 - **Do not execute any git operations** (git commit / git add / git reset / git push are all prohibited)
 - Do not modify source files to fix issues — produce Fix Instructions for Dev instead
+- **Do NOT run test suites** — the Orchestrator handles testing. You review code, not execute tests.
 - Do NOT re-read source files already listed in context-snapshot.md Section 4 File Manifest unless you need a specific code detail for a finding
+
+### Behavioral Rules
+
+```
+REV-01: Review against spec.md goals and acceptance criteria, not subjective preference
+REV-02: Every finding must have a concrete file:line reference
+REV-03: Fix Instructions must be actionable — Dev should be able to follow them as a recipe
+REV-04: Group related findings; order fixes by dependency (callee before caller)
+REV-05: On re-review, focus on Verification Criteria from previous findings — do not re-run full diagnostic
+REV-06: Maximum 10 findings per review — prioritize highest impact
+REV-07: Do not re-raise issues already documented as accepted decisions in plan.md or context-snapshot.md
+REV-08: Follow the framework-level Agent Operational Rules for Edit failure recovery, Read offset safety, stale line counts, and consecutive read failures. (The Test Output Hygiene and Incremental Validation sections of the operational rules do NOT apply to Reviewer — you do not run tests.)
+```
+
+### Exception Handling
+
+| Scenario | Strategy |
+|----------|----------|
+| No code changes detected | Skip review, report PASS with note |
+| Findings in files not in Implementation Log | Verify with Orchestrator before including |
+| Cannot determine if a pattern is intentional | Flag as MEDIUM, note the uncertainty |
+| Review tool unavailable | Perform manual diagnostic review, write review-report.md directly |

package/bundled/dev-pipeline/assets/prizm-dev-team-integration.md

@@ -18,9 +18,10 @@ dev-pipeline (outer loop)
             ├── Phase 0: Init (Orchestrator)
             ├── Phase 1-2: Context snapshot + Specify + Plan (Orchestrator)
             ├── Phase 3: Analyze (Reviewer agent) [tier2] / Phase 4: Analyze [tier3]
+            ├── Phase 3.5: Plan Challenge (Critic agent(s), 1 or 3 parallel) [tier2+]
             ├── Phase 4: Implement (Dev agent) [tier2] / Phase 5: Implement [tier3]
-            ├── Phase 4.5/6: Review (Reviewer agent)
-            └── Phase 5/7: Retrospective & Commit (Orchestrator)
+            ├── Phase 5: Review (Reviewer agent)
+            └── Phase 6: Retrospective & Commit (Orchestrator)
             │
             └── Write session-status.json → exit
 ```

package/bundled/dev-pipeline/run-bugfix.sh

@@ -132,18 +132,8 @@ spawn_and_wait_session() {
     # Check for stale-kill marker (heartbeat killed the process due to no progress)
     local stale_kill_marker="$session_dir/logs/stale-kill.json"
     local was_stale_killed=false
-    local stale_kill_reason=""
     if [[ -f "$stale_kill_marker" ]]; then
         was_stale_killed=true
-        stale_kill_reason=$(python3 - "$stale_kill_marker" <<'PY' 2>/dev/null || true
-import json, sys
-try:
-    with open(sys.argv[1], encoding="utf-8") as fh:
-        print(json.load(fh).get("reason") or "")
-except Exception:
-    pass
-PY
-)
         log_warn "Session was stale-killed by heartbeat monitor (no progress for too long)"
     fi
 

package/bundled/dev-pipeline/run-feature.sh

@@ -143,18 +143,8 @@ spawn_and_wait_session() {
     # Check for stale-kill marker (heartbeat killed the process due to no progress)
     local stale_kill_marker="$session_dir/logs/stale-kill.json"
     local was_stale_killed=false
-    local stale_kill_reason=""
     if [[ -f "$stale_kill_marker" ]]; then
         was_stale_killed=true
-        stale_kill_reason=$(python3 - "$stale_kill_marker" <<'PY' 2>/dev/null || true
-import json, sys
-try:
-    with open(sys.argv[1], encoding="utf-8") as fh:
-        print(json.load(fh).get("reason") or "")
-except Exception:
-    pass
-PY
-)
         log_warn "Session was stale-killed by heartbeat monitor (no progress for too long)"
     fi
 

package/bundled/dev-pipeline/run-refactor.sh

@@ -133,18 +133,8 @@ spawn_and_wait_session() {
     # Check for stale-kill marker (heartbeat killed the process due to no progress)
     local stale_kill_marker="$session_dir/logs/stale-kill.json"
     local was_stale_killed=false
-    local stale_kill_reason=""
     if [[ -f "$stale_kill_marker" ]]; then
         was_stale_killed=true
-        stale_kill_reason=$(python3 - "$stale_kill_marker" <<'PY' 2>/dev/null || true
-import json, sys
-try:
-    with open(sys.argv[1], encoding="utf-8") as fh:
-        print(json.load(fh).get("reason") or "")
-except Exception:
-    pass
-PY
-)
         log_warn "Session was stale-killed by heartbeat monitor (no progress for too long)"
     fi
 

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

@@ -184,7 +184,7 @@ Wait for Reviewer to return.
 **CP-2**: No CRITICAL issues.
 
 {{IF_CRITIC_ENABLED}}
-### Phase 3.5: Plan Challenge — Critic Agent
+### Phase 3.5: Plan Challenge — Critic Agent(s)
 
 **Guard**: Verify critic agent file exists before spawning:
 ```bash
@@ -192,9 +192,13 @@ ls {{CRITIC_SUBAGENT_PATH}} 2>/dev/null && echo "CRITIC:READY" || echo "CRITIC:M
 ```
 If CRITIC:MISSING — skip Phase 3.5 entirely and proceed to Phase 4. Log: "Critic agent not installed — skipping Plan Challenge."
 
+**Choose ONE path based on `{{CRITIC_COUNT}}`:**
+
+**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 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-report.md`; perform the plan challenge inline and record the fallback.
+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.
 
 Prompt:
 > "Read {{CRITIC_SUBAGENT_PATH}}. For feature {{FEATURE_ID}} (slug: {{FEATURE_SLUG}}):
@@ -209,6 +213,49 @@ Wait for Critic to return.
 - Read challenge-report.md. For items marked CRITICAL/HIGH: decide whether to adjust plan.md or document why the plan stands.
 - Max 1 plan revision round.
 
+**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):
+
+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.
+> 4. Challenge plan.md through your architecture lens.
+> Write `.prizmkit/specs/{{FEATURE_SLUG}}/challenge-report-A.md`."
+
+Critic-B prompt:
+> "Read {{CRITIC_SUBAGENT_PATH}}. For feature {{FEATURE_ID}} (slug: {{FEATURE_SLUG}}):
+> **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.
+> 4. Challenge plan.md through your data/edge-case lens.
+> Write `.prizmkit/specs/{{FEATURE_SLUG}}/challenge-report-B.md`."
+
+Critic-C prompt:
+> "Read {{CRITIC_SUBAGENT_PATH}}. For feature {{FEATURE_ID}} (slug: {{FEATURE_SLUG}}):
+> **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.
+> 4. Challenge plan.md through your security/performance lens.
+> Write `.prizmkit/specs/{{FEATURE_SLUG}}/challenge-report-C.md`."
+
+Spawn failure cap: for team/config/lock errors, each Critic retries at most once. If 2 or more Critics fail to spawn after retry, perform the plan challenge inline and record the fallback.
+
+After all critics return, read all 3 reports:
+- Challenge raised by **2/3 or more** critics → **must respond** (adjust plan or justify why not)
+- Challenge raised by **1/3 only** → logged in context-snapshot but not blocking
+- Max 1 plan revision round.
+
 **CP-2.5**: Plan challenges reviewed and resolved.
 {{END_IF_CRITIC_ENABLED}}
 
@@ -254,7 +301,7 @@ 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 + Test — Reviewer Subagent
+### Phase 5: Review — Reviewer Subagent
 
 Spawn Reviewer subagent (Agent tool, subagent_type="prizm-dev-team-reviewer", run_in_background=false).
 
@@ -266,8 +313,7 @@ Prompt:
 > 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. Run the full test suite using `{{TEST_CMD}}`. When running: `({{TEST_CMD}}) 2>&1 | tee /tmp/review-test-out.txt | tail -20`, then grep the file for details — do NOT re-run the suite multiple times.
-> 6. review-report.md will be written to .prizmkit/specs/{{FEATURE_SLUG}}/ by prizmkit-code-review.
+> 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.
@@ -287,7 +333,7 @@ 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**: Tests pass, review complete.
+**CP-3**: Review complete.
 
 {{IF_BROWSER_INTERACTION}}
 ### Phase 5.5: Browser Verification — MANDATORY
@@ -551,7 +597,7 @@ If you encounter an unrecoverable error, context overflow, or are about to exit
 
 ## Reminders
 
-- Tier 2: orchestrator builds context+plan, Analyzer checks consistency, Dev implements, Reviewer reviews+tests — use direct Agent spawn for agents
+- Tier 2: orchestrator builds context+plan, Analyzer checks consistency, Dev implements, Reviewer reviews — use direct Agent spawn for agents
 - Build context-snapshot.md FIRST; all subagents read it instead of re-reading source files
 - context-snapshot.md is append-only: orchestrator writes Sections 1-4, Dev appends Implementation Log, Reviewer appends Review Notes
 - Gate checks enforce Implementation Log and Review Notes are written before proceeding

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

@@ -234,7 +234,9 @@ Prompt:
 
 **If {{CRITIC_COUNT}} = 3 → Multi-Critic Voting** (skip Single Critic above):
 
-Spawn 3 Critic agents sequentially (each with mode="plan", run_in_background=false), each with a different focus lens:
+**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):
 
 Critic-A prompt (append to base prompt above):
 > "**Focus Lens: Architecture & Scalability.** Prioritize: architectural pattern fit, scalability implications, over-engineering risks, component boundary design.
@@ -248,6 +250,8 @@ Critic-C prompt (append to base prompt above):
 > "**Focus Lens: Security & Performance.** Prioritize: security attack surface, authentication/authorization gaps, performance bottlenecks, resource leaks.
 > Write `.prizmkit/specs/{{FEATURE_SLUG}}/challenge-report-C.md`."
 
+Spawn failure cap: for team/config/lock errors, each Critic retries at most once. If 2 or more Critics fail to spawn after retry, perform the plan challenge inline and record the fallback.
+
 After all critics return, read all 3 reports:
 - Challenge raised by **2/3 or more** critics → **must respond** (adjust plan or justify why not)
 - Challenge raised by **1/3 only** → logged in context-snapshot but not blocking
@@ -315,7 +319,7 @@ 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 + Test — Reviewer Agent
+### Phase 5: Review — Reviewer Agent
 
 Spawn Reviewer agent (Agent tool, subagent_type="prizm-dev-team-reviewer", run_in_background=false).
 
@@ -327,8 +331,7 @@ Prompt:
 > 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. Run the full test suite using `{{TEST_CMD}}`. When running tests: `({{TEST_CMD}}) 2>&1 | tee /tmp/review-test-out.txt | tail -20`, then grep `/tmp/review-test-out.txt` for details — do NOT re-run the suite multiple times.
-> 6. review-report.md will be written to .prizmkit/specs/{{FEATURE_SLUG}}/ by prizmkit-code-review.
+> 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.
@@ -348,7 +351,7 @@ 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**: Integration tests pass, review complete.
+**CP-3**: Review complete.
 
 {{IF_BROWSER_INTERACTION}}
 ### Phase 5.5: Browser Verification — MANDATORY
@@ -629,7 +632,7 @@ If you encounter an unrecoverable error, context overflow, or are about to exit
 
 ## Reminders
 
-- Tier 3: full team — Dev (implementation) → Reviewer (review + test) — spawn agents directly via Agent tool
+- Tier 3: full team — Dev (implementation) → Reviewer (review) — spawn agents directly via Agent tool
 - context-snapshot.md is append-only: orchestrator writes Sections 1-4, Dev appends Implementation Log, Reviewer appends Review Notes
 - Gate checks enforce Implementation Log and Review Notes are written before proceeding
 - Do NOT use `run_in_background=true` when spawning agents

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

@@ -32,7 +32,7 @@ If CRITIC:MISSING — skip this phase entirely and proceed. Log: "Critic agent n
 
 **If {{CRITIC_COUNT}} = 3 → Multi-Critic Voting** (skip Single Critic above):
 
-Spawn 3 Critic agents sequentially (each with mode="plan", run_in_background=false), each with a different focus lens:
+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:
 
 Critic-A prompt (append to base prompt above):
 > "**Focus Lens: Architecture & Scalability.** Prioritize: architectural pattern fit, scalability implications, over-engineering risks, component boundary design.

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

@@ -23,9 +23,7 @@ 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)
 
-Run the full test suite: `({{TEST_CMD}}) 2>&1 | tee /tmp/review-test-out.txt | tail -20`
-
-**CP-3**: Review complete, report written, and the Test Failure Recovery Protocol's Success Rule is satisfied.
+**CP-3**: Review complete, report written.
 
 
 **Checkpoint update**: Run the update script to set step `prizmkit-code-review` to `"completed"`:

package/bundled/dev-pipeline-windows/assets/prizm-dev-team-integration.md

@@ -18,9 +18,10 @@ dev-pipeline (outer loop)
             ├── Phase 0: Init (Orchestrator)
             ├── Phase 1-2: Context snapshot + Specify + Plan (Orchestrator)
             ├── Phase 3: Analyze (Reviewer agent) [tier2] / Phase 4: Analyze [tier3]
+            ├── Phase 3.5: Plan Challenge (Critic agent(s), 1 or 3 parallel) [tier2+]
             ├── Phase 4: Implement (Dev agent) [tier2] / Phase 5: Implement [tier3]
-            ├── Phase 4.5/6: Review (Reviewer agent)
-            └── Phase 5/7: Retrospective & Commit (Orchestrator)
+            ├── Phase 5: Review (Reviewer agent)
+            └── Phase 6: Retrospective & Commit (Orchestrator)
             │
             └── Write session-status.json → exit
 ```

package/bundled/dev-pipeline-windows/lib/pipeline.ps1

@@ -796,15 +796,6 @@ function Invoke-PrizmPipeline {
     }
     Stop-PrizmProgressParser $parserProcess
 
-    $staleKillReason = ''
-    if (Test-Path $staleKillMarker) {
-      try {
-        $staleKillData = Get-Content $staleKillMarker -Raw | ConvertFrom-Json
-        if ($staleKillData.PSObject.Properties['reason']) { $staleKillReason = [string]$staleKillData.reason }
-      } catch {
-        $staleKillReason = ''
-      }
-    }
     $wasInfraError = ($exitCode -ne 0 -and (Test-PrizmInfraError -SessionLog $sessionLog -ProgressJson $progressJson))
     $wasAiRuntimeError = Test-PrizmAiRuntimeError -SessionLog $sessionLog -ProgressJson $progressJson
     $semanticCompletion = if ($Kind -eq 'feature' -and $isGitRepository) {