prizmkit 1.1.93 → 1.1.95

package/bundled/VERSION.json

@@ -1,5 +1,5 @@
 {
-  "frameworkVersion": "1.1.93",
-  "bundledAt": "2026-07-02T17:03:22.377Z",
-  "bundledFrom": "dc86f56"
+  "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/lib/heartbeat.sh

@@ -44,7 +44,6 @@ start_heartbeat() {
         local prev_max_size=0
         local prev_child_activity_signature=""
         local prev_progress_signature=""
-        local prev_error_loop_signature=""
         local stale_seconds=0
         local stale_reason="stale_session"
         while kill -0 "$cli_pid" 2>/dev/null; do
@@ -197,64 +196,24 @@ PY
                 fi
             fi
 
-            # Check for error-loop: agent is actively producing output but results are
-            # all read-offset errors or wasted calls. This is a stuck agent that appears
-            # "active" by log growth but is accomplishing nothing. Only a newly advancing
-            # error signature counts; stale historical errors must not turn later normal
-            # output into a stale kill.
-            local error_loop_detected=false
-            local error_loop_signature=""
-            if [[ $effective_stale_kill_threshold -gt 0 && $growth -gt 0 && -f "$progress_json" ]]; then
-                local error_loop_flag
-                error_loop_flag=$(python3 - "$progress_json" <<'PY' 2>/dev/null || true
-import json, sys
-try:
-    with open(sys.argv[1], encoding="utf-8") as fh:
-        progress = json.load(fh)
-except Exception:
-    raise SystemExit(0)
-errors = progress.get("errors", [])
-if isinstance(errors, list) and len(errors) >= 5:
-    recent = errors[-5:]
-    if all(isinstance(e, dict) and e.get("type") in ("read_offset_overflow", "wasted_call") for e in recent):
-        print(json.dumps(recent, sort_keys=True, separators=(",", ":")))
-PY
-                )
-                if [[ -n "$error_loop_flag" ]]; then
-                    error_loop_signature="$error_loop_flag"
-                    if [[ -n "$prev_error_loop_signature" && "$error_loop_signature" != "$prev_error_loop_signature" ]]; then
-                        error_loop_detected=true
-                    fi
-                fi
-            fi
-            prev_error_loop_signature="$error_loop_signature"
-
             # Track progress staleness. Parent sessions can sit in a wait/polling
             # tool while child transcripts or structured progress counters keep
             # advancing, so both child activity and progress.json state changes
-            # count as progress. Error loops bypass normal growth-as-progress
-            # because the log is only growing with repeated failed reads or wasted
-            # calls.
+            # count as progress.
             #
             # When the main session log has been truncated (e.g. by subagent stdout
             # redirection severing the file descriptor), use structured progress and
             # child activity as the primary progress signals — the parent process is
             # still running and children may still be producing output.
-            if [[ "$error_loop_detected" == "true" ]]; then
-                stale_reason="error_loop"
-                stale_seconds=$effective_stale_kill_threshold
-            elif [[ "$log_truncated" == "true" ]]; then
-                stale_reason="stale_session"
+            if [[ "$log_truncated" == "true" ]]; then
                 if [[ $progress_advanced -gt 0 || $child_growth -gt 0 ]]; then
                     stale_seconds=0
                 else
                     stale_seconds=$((stale_seconds + heartbeat_interval))
                 fi
             elif [[ $growth -le 0 && $child_growth -eq 0 && $progress_advanced -eq 0 ]]; then
-                stale_reason="stale_session"
                 stale_seconds=$((stale_seconds + heartbeat_interval))
             else
-                stale_reason="stale_session"
                 stale_seconds=0
             fi
 
@@ -338,13 +297,8 @@ PY
             # stale window to surface stuck agents promptly.
             if [[ $effective_stale_kill_threshold -gt 0 && $stale_seconds -ge $effective_stale_kill_threshold ]]; then
                 local stale_mins=$((stale_seconds / 60))
-                if [[ "$stale_reason" == "error_loop" ]]; then
-                    echo -e "  ${RED}[HEARTBEAT]${NC} ${mins}m${secs}s | log: ${size_display} | ${RED}STALE-KILL: repeated read-offset/wasted-call error loop (threshold: ${effective_stale_kill_threshold}s)${NC}"
-                    echo -e "  ${RED}[HEARTBEAT]${NC} Killing AI CLI process $cli_pid (error loop)..."
-                else
-                    echo -e "  ${RED}[HEARTBEAT]${NC} ${mins}m${secs}s | log: ${size_display} | ${RED}STALE-KILL: no progress for ${stale_mins}m (threshold: ${effective_stale_kill_threshold}s)${NC}"
-                    echo -e "  ${RED}[HEARTBEAT]${NC} Killing AI CLI process $cli_pid (stale session)..."
-                fi
+                echo -e "  ${RED}[HEARTBEAT]${NC} ${mins}m${secs}s | log: ${size_display} | ${RED}STALE-KILL: no progress for ${stale_mins}m (threshold: ${effective_stale_kill_threshold}s)${NC}"
+                echo -e "  ${RED}[HEARTBEAT]${NC} Killing AI CLI process $cli_pid (stale session)..."
                 # Write the marker before killing. Some CLIs exit quickly, and the
                 # parent runner may stop this heartbeat process immediately after
                 # wait(1) returns.

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

@@ -132,23 +132,9 @@ 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
-)
-        if [[ "$stale_kill_reason" == "error_loop" ]]; then
-            log_warn "Session was killed by heartbeat monitor due to repeated read-offset/wasted-call errors"
-        else
-            log_warn "Session was stale-killed by heartbeat monitor (no progress for too long)"
-        fi
+        log_warn "Session was stale-killed by heartbeat monitor (no progress for too long)"
     fi
 
     local was_infra_error=false
@@ -179,11 +165,7 @@ PY
         log_warn "Infrastructure errors are retried without consuming code retry budget"
         session_status="infra_error"
     elif [[ "$was_stale_killed" == true ]]; then
-        if [[ "$stale_kill_reason" == "error_loop" ]]; then
-            log_warn "Session killed due to repeated read-offset/wasted-call error loop"
-        else
-            log_warn "Session stale-killed (no progress for ${STALE_KILL_THRESHOLD}s)"
-        fi
+        log_warn "Session stale-killed (no progress for ${STALE_KILL_THRESHOLD}s)"
         log_warn "Stale-killed sessions are treated as failed; dev branch is preserved for inspection"
         session_status="crashed"
     elif [[ $exit_code -ne 0 ]]; then

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

@@ -143,23 +143,9 @@ 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
-)
-        if [[ "$stale_kill_reason" == "error_loop" ]]; then
-            log_warn "Session was killed by heartbeat monitor due to repeated read-offset/wasted-call errors"
-        else
-            log_warn "Session was stale-killed by heartbeat monitor (no progress for too long)"
-        fi
+        log_warn "Session was stale-killed by heartbeat monitor (no progress for too long)"
     fi
 
     local was_infra_error=false
@@ -213,11 +199,7 @@ PY
         log_warn "Infrastructure errors are retried without consuming code retry budget"
         session_status="infra_error"
     elif [[ "$was_stale_killed" == true ]]; then
-        if [[ "$stale_kill_reason" == "error_loop" ]]; then
-            log_warn "Session killed due to repeated read-offset/wasted-call error loop"
-        else
-            log_warn "Session stale-killed (no progress for ${STALE_KILL_THRESHOLD}s)"
-        fi
+        log_warn "Session stale-killed (no progress for ${STALE_KILL_THRESHOLD}s)"
         log_warn "Heartbeat-killed sessions are treated as failed; dev branch is preserved for inspection"
         session_status="crashed"
     elif [[ $exit_code -ne 0 ]]; then

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

@@ -133,23 +133,9 @@ 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
-)
-        if [[ "$stale_kill_reason" == "error_loop" ]]; then
-            log_warn "Session was killed by heartbeat monitor due to repeated read-offset/wasted-call errors"
-        else
-            log_warn "Session was stale-killed by heartbeat monitor (no progress for too long)"
-        fi
+        log_warn "Session was stale-killed by heartbeat monitor (no progress for too long)"
     fi
 
     local was_infra_error=false
@@ -180,11 +166,7 @@ PY
         log_warn "Infrastructure errors are retried without consuming code retry budget"
         session_status="infra_error"
     elif [[ "$was_stale_killed" == true ]]; then
-        if [[ "$stale_kill_reason" == "error_loop" ]]; then
-            log_warn "Session killed due to repeated read-offset/wasted-call error loop"
-        else
-            log_warn "Session stale-killed (no progress for ${STALE_KILL_THRESHOLD}s)"
-        fi
+        log_warn "Session stale-killed (no progress for ${STALE_KILL_THRESHOLD}s)"
         log_warn "Stale-killed sessions are treated as failed; dev branch is preserved for inspection"
         session_status="crashed"
     elif [[ $exit_code -ne 0 ]]; then