prizmkit 1.1.0 → 1.1.3

package/bundled/skills/app-planner/assets/app-design-guide.md

@@ -0,0 +1,101 @@
+# App Design Reference Guide
+
+This guide provides structured templates, decision matrices, and decomposition patterns for new application planning. Use during the vision and architecture phases of app-planner sessions.
+
+---
+
+## 1. App Vision Template
+
+Use this template to capture the app vision during the initial planning phase.
+
+```markdown
+# App Vision: [APP_NAME]
+
+## Problem Statement
+[What problem does this app solve?]
+
+## Target Users
+- Primary: [Who are the main users?]
+- Secondary: [Any secondary user types?]
+
+## Core Value Proposition
+[What makes this app valuable? What's the "elevator pitch"?]
+
+## Key Differentiators
+[What sets this apart from existing solutions?]
+```
+
+### Guidance
+
+- **Problem Statement**: Should describe a real pain point in 1-3 sentences. Avoid vague statements like "improve productivity." Be specific about who suffers and why.
+- **Target Users**: Identify at least one primary user persona. Secondary users are optional but useful for prioritization decisions later.
+- **Core Value Proposition**: Should be expressible in one sentence. If it takes a paragraph, the scope is likely too broad.
+- **Key Differentiators**: List 1-3 concrete differentiators. If none exist, reconsider whether the app needs to be built.
+
+---
+
+## 2. Tech Stack Decision Matrix
+
+Use these tables to guide tech stack selection based on project requirements.
+
+### Frontend Frameworks
+
+| Framework | Best For | Ecosystem |
+|-----------|----------|-----------|
+| Next.js 14+ | Full-stack React, SSR, API routes | React ecosystem, Vercel |
+| Nuxt 3 | Full-stack Vue, SSR | Vue ecosystem |
+| SvelteKit | Performance-focused, smaller teams | Svelte ecosystem |
+| Remix | Nested routes, data loading | React ecosystem |
+
+### Backend Frameworks
+
+| Framework | Best For | Language |
+|-----------|----------|----------|
+| Express.js | Flexible, minimal | Node.js/TS |
+| FastAPI | High-perf APIs, Python ML | Python |
+| NestJS | Enterprise, structured | Node.js/TS |
+| Django | Batteries-included, admin | Python |
+| Go (Gin/Echo) | High concurrency | Go |
+
+### Databases
+
+| Database | Best For | Type |
+|----------|----------|------|
+| PostgreSQL | Complex queries, ACID | Relational |
+| MySQL | Read-heavy, simple | Relational |
+| MongoDB | Flexible schema, documents | Document |
+| SQLite | Embedded, prototyping | Relational |
+| Redis | Caching, sessions, pub/sub | Key-Value |
+
+### Design Systems
+
+| System | Best For | Framework |
+|--------|----------|-----------|
+| shadcn/ui | Modern, customizable | React/Next.js |
+| Ant Design | Enterprise, data-heavy | React |
+| Material UI | Google-style, full-featured | React |
+| Vuetify | Material Design for Vue | Vue |
+| Tailwind CSS | Utility-first, any framework | Any |
+
+### Common Service Patterns
+
+| Need | Options |
+|------|---------|
+| Auth | NextAuth.js, Auth0, Clerk, Supabase Auth, custom JWT |
+| Real-time | WebSocket, Socket.io, SSE, Supabase Realtime |
+| File Storage | S3, Cloudflare R2, Supabase Storage |
+| Email | SendGrid, Resend, Postmark |
+| Payments | Stripe, LemonSqueezy |
+| Search | Algolia, Meilisearch, Elasticsearch |
+
+### Selection Heuristics
+
+- If the user has no strong preference, default to **Next.js + PostgreSQL + shadcn/ui + Tailwind CSS** as a general-purpose stack.
+- If the project involves ML/AI backends, prefer **FastAPI** on the backend.
+- If the project requires high concurrency with minimal resource usage, consider **Go**.
+- If rapid prototyping is the goal, consider **SQLite** initially with a migration path to PostgreSQL.
+- Always ask about deployment preferences (Vercel, AWS, self-hosted) as this influences framework choice.
+
+
+
+> **Note**: Feature decomposition patterns (CRUD, SaaS, Social, E-commerce) have been moved to `feature-planner/references/decomposition-patterns.md`. Load that reference during feature decomposition phase.

package/bundled/skills/app-planner/references/frontend-design-guide.md

@@ -2,7 +2,7 @@
 
 > Create distinctive, production-grade frontend interfaces that avoid generic "AI slop" aesthetics.
 
-**App-planner context**: In the planning phase, use this guide to establish **design direction decisions** (aesthetic tone, typography approach, color strategy, layout philosophy). Do NOT produce CSS, code, or implementation artifacts — capture the design direction as decisions in the project instruction file (`CLAUDE.md` / `CODEBUDDY.md`). Downstream implementation skills will consume these decisions when building features.
+**app-planner context**: In the planning phase, use this guide to establish **design direction decisions** (aesthetic tone, typography approach, color strategy, layout philosophy). Do NOT produce CSS, code, or implementation artifacts — capture the design direction as decisions in the project instruction file (`CLAUDE.md` / `CODEBUDDY.md`). Downstream implementation skills will consume these decisions when building features.
 
 Load this guide **only when the feature involves frontend/UI work**. Skip for backend-only or infrastructure features.
 

package/bundled/skills/app-planner/references/project-brief-guide.md

@@ -1,110 +1,79 @@
-# Project Brief — Real-Time Accumulation Guide
+# Project Brief — Checklist Format Guide
 
-> Distill the user's key requirements, design decisions, and project context into a concise `project-brief.md` during interactive planning. This file is injected into every headless `dev-pipeline` session so individual feature builds understand the bigger picture.
+> Capture the user's key product ideas as a simple checklist in `project-brief.md`. Each line is one idea. The dev-pipeline injects this file into every feature session so the AI understands the user's overall product vision.
 
 ## Purpose
 
-When `app-planner` generates 20+ features through conversation, each headless session only sees its own feature description and the tech stack (`global_context`). Cross-feature design decisions, business intent, and user-emphasized details exist only in the chat history and are lost. `project-brief.md` bridges this gap.
+During `app-planner` conversation, the user describes what they want to build. `project-brief.md` distills these into a flat checklist — one idea per line. When `dev-pipeline` builds individual features, each session sees this checklist and understands the bigger picture.
 
 ## Persistence
 
 - **File**: `project-brief.md` at project root (same level as `feature-list.json`)
-- **Format**: Markdown with fixed sections, bullet-point style
+- **Format**: Checklist — one idea per line, `[ ]` for pending, `[x]` for completed
 - **Size limit**: 500 words max (injected into every session's context window)
 - **Consumed by**: `dev-pipeline/scripts/generate-bootstrap-prompt.py` → `{{PROJECT_BRIEF}}` placeholder
 
-## Accumulation Trigger
-
-After each meaningful user response (skip acknowledgments, yes/no confirmations, or meta-conversation), evaluate whether the response contains:
-
-- Business/product intent or vision
-- Technical constraints or preferences
-- Cross-feature design decisions (e.g., "all APIs use JWT", "use Material Design 3")
-- Specific implementation preferences or details the user emphasized
-
-If yes → update the relevant section in `project-brief.md`.
-
-## File Template
+## File Format
 
 ```markdown
 # Project Brief
 
-## Vision
-- [What the project is, who it's for, core value proposition]
-
-## Core Constraints
-- [Technical constraints, business constraints, immutable decisions]
-
-## Design Decisions
-- [Cross-feature decisions: API style, auth method, state management, etc.]
-
-## Key Requirements
-- [Details and preferences the user specifically emphasized]
+[x] 表示构想已在某个 feature 中实现完成
+
+--------
+
+[ ] B2B SaaS 餐饮库存管理平台，面向中小连锁餐厅 (5-50 家门店)
+[ ] 核心价值：通过预测性订货减少 30% 食物浪费
+[ ] 必须支持 iPad Safari 离线模式，厨房平板 WiFi 不稳定
+[ ] 后端可部署到客户自有云（多租户但可自托管）
+[ ] RESTful API + JWT 认证，不用 GraphQL
+[ ] 使用 Supabase (PostgreSQL) 作为数据库和认证
+[ ] TailwindCSS + shadcn/ui 统一前端组件
+[ ] 所有金额用整数（分）存储，避免浮点精度问题
+[ ] Dashboard 在 3G 网络下 2 秒内加载
+[ ] 供应商集成 API 支持 webhook 回调
+[ ] 用户端中文界面，管理后台英文界面
 ```
 
-## Update Rules
-
-- **First update**: Create the file with all four sections. Populate whichever sections have content; leave others with a single placeholder bullet `- (to be determined)`.
-- **Subsequent updates**: Use Edit tool to update only the changed section — do not rewrite the entire file.
-- Keep each bullet to **one sentence** — no paragraphs.
-- Total file size **must not exceed 500 words**. If approaching the limit, merge or condense existing bullets.
-- Language: match the user's language (Chinese or English).
-- Content is append/modify only — never delete bullets unless the user explicitly requests it.
-
-## Checkpoint
-
-Verified at **CP-AP-5.3**: Before CP-AP-6 (`feature-list.json` generation), `project-brief.md` must exist with the Vision section plus at least one other populated section (not placeholder bullets).
+## Format Rules
 
-## How the Pipeline Uses It
+1. **First line**: `# Project Brief`
+2. **Second line**: `[x] 表示构想已在某个 feature 中实现完成` — fixed legend
+3. **Third line**: `--------` — separator
+4. **Remaining lines**: One idea per line, each starting with `[ ]`
+5. Each line is **one sentence** — no paragraphs, no sub-bullets
+6. Language: match the user's language (Chinese or English)
 
-`generate-bootstrap-prompt.py` reads `project-brief.md` and injects its content into the `{{PROJECT_BRIEF}}` section of every bootstrap prompt (tier1/tier2/tier3). The section appears between Acceptance Criteria and Dependencies, with this framing:
+## How app-planner Writes It
 
-> "Distilled summary of the project's key requirements and design decisions, captured during planning. When your feature implementation touches any of these key points, ensure alignment."
+During interactive conversation, after each meaningful user response (skip acknowledgments, yes/no):
+- Evaluate whether the response contains a product idea, constraint, design decision, or technical preference
+- If yes → append a new `[ ]` line to `project-brief.md`
+- Keep each line concise — one idea, one sentence
+- Merge or condense if approaching 500-word limit
 
-If the file does not exist, the placeholder is replaced with `(No project brief available)` — the pipeline runs normally without it.
+**First write**: Create the file with the header, legend, separator, and initial ideas.
+**Subsequent writes**: Append new `[ ]` lines only — do not rewrite existing lines.
 
-## Examples
+## How the Pipeline Marks Completion
 
-### Minimal Brief (early in conversation)
+When a feature session in `dev-pipeline` completes and its implementation addresses one or more ideas from the checklist:
+1. Change `[ ]` to `[x]` for that idea
+2. Append 1-2 key directory/file paths after the idea text, showing where it was implemented
 
-```markdown
-# Project Brief
-
-## Vision
-- B2B SaaS platform for restaurant inventory management, targeting small-to-medium restaurant chains
+Example of a completed item:
+```
+[x] RESTful API + JWT 认证，不用 GraphQL → src/middleware/auth.ts, src/routes/api/
+```
 
-## Core Constraints
-- (to be determined)
+## Checkpoint
 
-## Design Decisions
-- (to be determined)
+Verified at **CP-AP-4**: Before handoff to `feature-planner`, `project-brief.md` must exist with at least 3 ideas listed.
 
-## Key Requirements
-- Must support offline mode for kitchen tablets with unreliable WiFi
-```
+## How the Pipeline Uses It
 
-### Mature Brief (after several rounds of discussion)
+`generate-bootstrap-prompt.py` reads `project-brief.md` and injects its content into the `{{PROJECT_BRIEF}}` section of every bootstrap prompt (tier1/tier2/tier3). The framing:
 
-```markdown
-# Project Brief
+> "Product ideas checklist from planning. Lines marked [x] are already implemented. When your feature touches any [ ] item, ensure alignment. After implementation, mark relevant items [x] and append the key file paths."
 
-## Vision
-- B2B SaaS platform for restaurant inventory management, targeting small-to-medium restaurant chains (5-50 locations)
-- Core value: reduce food waste by 30% through predictive ordering
-
-## Core Constraints
-- Must work on iPad Safari (no native app)
-- Backend must be deployable to customer's own cloud (multi-tenant but self-hostable)
-- Budget: MVP in 4 weeks
-
-## Design Decisions
-- RESTful API with JWT auth; no GraphQL
-- Use Supabase for auth + database (PostgreSQL)
-- TailwindCSS + shadcn/ui for all frontend components
-- All monetary values stored as integers (cents) to avoid floating point
-
-## Key Requirements
-- Dashboard must load in under 2 seconds on 3G connection
-- Supplier integration API must support webhook callbacks
-- All user-facing text in Simplified Chinese; admin panel in English
-```
+If the file does not exist, the placeholder is replaced with `(No project brief available)`.

package/bundled/skills/bug-fix-workflow/SKILL.md

@@ -148,7 +148,7 @@ Ask the user: "Is this summary accurate? Any details to add?"
 
 **Goal**: Locate affected code, identify root cause, classify severity.
 
-> **Reference**: This phase incorporates the logic of `prizmkit-tool-error-triage`. Classify error into: Runtime / Network / Auth / Data / Resource / Logic / Config / External. Check `.prizm-docs/` TRAPS for known patterns first. If a TRAPS match is found, use documented solution and reference the specific `.prizm-docs/` entry. If no match, trace the call chain from the stack frame to identify root cause from first principles.
+> **Triage**: Classify error into: Runtime / Network / Auth / Data / Resource / Logic / Config / External. Check `.prizm-docs/` TRAPS for known patterns first. If a TRAPS match is found, use documented solution and reference the specific `.prizm-docs/` entry. If no match, trace the call chain from the stack frame to identify root cause from first principles.
 
 1. **Read project context**: `.prizm-docs/root.prizm` → relevant L1/L2 docs for affected modules
 2. **Locate affected code**: read the files mentioned in the error/stack trace or identified during diagnosis
@@ -171,7 +171,7 @@ Ask the user: "Is this summary accurate? Any details to add?"
 
 **Goal**: Create a failing test that proves the bug exists.
 
-> **Reference**: This phase incorporates the logic of `prizmkit-tool-bug-reproducer`. For API bugs: generate curl/HTTP request sequence with assertions. For UI bugs: generate step-by-step interaction guide. For logic bugs: generate unit test (arrange/act/assert). For data bugs: generate seed data + query sequence. The reproduction must FAIL with current behavior and be designed to PASS after the fix is applied — making it a regression guard.
+> **Reproduce**: For API bugs: generate curl/HTTP request sequence with assertions. For UI bugs: generate step-by-step interaction guide. For logic bugs: generate unit test (arrange/act/assert). For data bugs: generate seed data + query sequence. The reproduction must FAIL with current behavior and be designed to PASS after the fix is applied — making it a regression guard.
 
 1. **Write a reproduction test** that demonstrates the bug:
    - Name: `<module>.test.ts` → add a test case named `should handle <bug scenario>`

package/bundled/skills/bug-planner/SKILL.md

@@ -6,7 +6,7 @@ description: "Interactive bug planning that produces bug-fix-list.json for the B
 
 # Bug Planner
 
-Interactive skill that collects bug information from various input formats and generates a standardized `bug-fix-list.json` for the Bug Fix Pipeline. This is the bug-fix counterpart to `app-planner` (which generates `feature-list.json`).
+Interactive skill that collects bug information from various input formats and generates a standardized `bug-fix-list.json` for the Bug Fix Pipeline. This is the bug-fix counterpart to `feature-planner` (which generates `feature-list.json`).
 
 ## When to Use
 
@@ -19,7 +19,7 @@ User says:
 **Do NOT use when:**
 - User wants to start fixing bugs now (use `bugfix-pipeline-launcher`)
 - User wants to fix a single bug interactively (use `bug-fix-workflow`)
-- User wants to plan features (use `app-planner`)
+- User wants to plan features (use `feature-planner`)
 
 ## Intent Routing
 
@@ -37,7 +37,7 @@ This skill handles multiple operations. Determine the user's intent and execute
 
 ## Operation: Interactive Planning
 
-Launch the interactive bug planning process through 4 phases.
+Launch the interactive bug planning process through 5 phases.
 
 ### Phase 1: Project Context
 
@@ -119,6 +119,35 @@ ALERT: Error rate spike: 500 errors/min on /api/login endpoint
 
 **Per-bug clarification** — if the bug's root cause, reproduction steps, expected behavior, or scope is unclear from the provided information, ask focused questions one at a time (cite the unclear point, give a recommended answer with rationale) until the bug is fully understood. Do not finalize a bug entry with ambiguous details. No limit on the number of questions per bug.
 
+**Per-bug confirmation (mandatory)** — after extracting and clarifying each bug, present a structured summary for user review using this template:
+
+```
+┌─ Bug Confirmation: B-NNN ─────────────────────────────
+│ Title:       <auto-suggested title>
+│ Description: <expected vs actual behavior>
+│ Severity:    <auto-classified> | Verification: <type>
+│
+│ Reproduction: <steps if available, or "not provided">
+│ Affected:     <module/feature or "unknown">
+│
+│ ✅ Acceptance Criteria (fix verified when):
+│   1. <criterion — specific enough for automated pipeline to verify>
+│   2. <criterion>
+│
+│ ⚠️ Open Questions:
+│   - <any unclear points, or "None">
+└────────────────────────────────────────────────────────
+```
+
+Then ask three confirmation questions:
+1. "描述是否准确？是否需要修改？" / "Is the description accurate? Any corrections?"
+2. "是否需要补充更多细节？（复现步骤、环境信息、相关代码位置等）" / "Need to add more details? (reproduction steps, environment, related code locations, etc.)"
+3. "验证条件是否具体到 pipeline 可以自主判断修复成功？" / "Are the acceptance criteria specific enough that the pipeline can autonomously verify the fix?"
+
+The acceptance criteria are critical — they directly determine how the bugfix pipeline judges success or failure. Vague criteria like "login works" lead to shallow fixes; prefer specific, verifiable conditions like "POST /api/login with valid credentials returns 200 and a JWT token in the response body."
+
+Only finalize the bug entry after user confirms all three points.
+
 **Multiple bugs per session**: After each bug, ask "Any more bugs to add? (yes/no)"
 
 ### Phase 3: Prioritization & Review
@@ -134,7 +163,41 @@ ALERT: Error rate spike: 500 errors/min on /api/login endpoint
 3. **Ask for adjustments**: "Want to reorder priorities, change severity, or remove any bugs?"
 4. **Detect potential duplicates**: If two bugs have similar error messages or affected modules, warn user
 
-### Phase 4: Generate & Validate
+### Phase 4: Pre-Generation Completeness Review
+
+Before generating `bug-fix-list.json`, perform a holistic scan across all collected bugs. The bugfix pipeline runs autonomously — any ambiguity left here becomes a wrong assumption later.
+
+**Step 1 — Description adequacy scan**: For each bug, check:
+- Description clearly states **expected** vs **actual** behavior (not just "X doesn't work")
+- Reproduction path is specific enough for the pipeline AI to locate the relevant code
+- If the bug involves user interaction, the trigger action is described (not just the symptom)
+
+**Step 2 — Acceptance criteria specificity check**: For each bug, verify each acceptance criterion passes the "pipeline autonomy test" — could an AI session, without asking a human, determine whether this criterion is met? Flag criteria that are subjective ("works correctly"), lack measurable conditions ("performs better"), or don't specify the verification method.
+
+**Step 3 — Cross-bug analysis**: Check for:
+- **Root cause overlap**: Multiple bugs in the same module may share a root cause — flag for user to confirm whether they should be merged or kept separate
+- **Missing dependencies**: If fixing B-002 requires B-001 to be fixed first, flag the dependency
+- **Scope gaps**: If bugs describe symptoms but the underlying cause likely affects more areas, suggest additional bugs
+
+**Step 4 — Present review table**: Display the completeness assessment using this template:
+
+```
+┌─ Completeness Review ─────────────────────────────────────────────────
+│ Bug    │ Description │ Criteria   │ Reproducible │ Notes
+│ B-001  │ ✓ Clear     │ ✓ Specific │ ✓ Yes        │ —
+│ B-002  │ ⚠ Vague     │ ⚠ Subjective│ ✓ Yes       │ "encoding works" → needs specific test case
+│ B-003  │ ✓ Clear     │ ⚠ No metric│ ⚠ No steps  │ needs perf threshold + reproduction steps
+└────────────────────────────────────────────────────────────────────────
+```
+
+For any ⚠ items, ask targeted questions to fill gaps. Iterate until the user confirms all bugs are adequately described. Present bilingual prompt:
+
+> "以上是完整性审查结果。标记 ⚠ 的项目需要补充，是否逐一补充？还是先跳过，之后再完善？"
+> "Above is the completeness review. Items marked ⚠ need more detail. Address them now, or proceed and refine later?"
+
+Only proceed to Phase 5 after user confirms.
+
+### Phase 5: Generate & Validate
 
 1. **Generate `bug-fix-list.json`**: Conform to `dev-pipeline/templates/bug-fix-list-schema.json`
 2. **Validate against schema**: Run the validation script:
@@ -254,7 +317,7 @@ After `bug-fix-list.json` is generated, the user can:
 2. **Background daemon**: `./dev-pipeline/launch-bugfix-daemon.sh start bug-fix-list.json`
 3. **Foreground run**: `./dev-pipeline/run-bugfix.sh run bug-fix-list.json`
 4. **Fix single bug interactively**: invoke `bug-fix-workflow` in current session
-5. **Retry a failed bug**: `./dev-pipeline/retry-bug.sh B-001`
+5. **Retry a failed bug**: `./dev-pipeline/retry-bugfix.sh B-001`
 
 ## Error Handling
 

package/bundled/skills/bug-planner/scripts/validate-bug-list.py

@@ -21,6 +21,7 @@ VALID_SOURCE_TYPES = {"stack_trace", "user_report", "failed_test", "log_pattern"
 VALID_VERIFICATION_TYPES = {"automated", "manual", "hybrid"}
 VALID_STATUSES = {"pending", "in_progress", "fixed", "failed", "skipped", "needs_info"}
 BUG_ID_PATTERN = re.compile(r"^B-\d{3}$")
+SCHEMA_VERSION = "dev-pipeline-bug-fix-list-v1"
 
 
 def validate(bug_list_path, feature_list_path=None):
@@ -51,8 +52,8 @@ def validate(bug_list_path, feature_list_path=None):
     # Top-level required fields
     if "$schema" not in data:
         errors.append("Missing required field: $schema")
-    elif data["$schema"] != "dev-pipeline-bug-fix-list-v1":
-        errors.append(f"Invalid $schema: expected 'dev-pipeline-bug-fix-list-v1', got '{data['$schema']}'")
+    elif data["$schema"] != SCHEMA_VERSION:
+        errors.append(f"Invalid $schema: expected '{SCHEMA_VERSION}', got '{data['$schema']}'")
 
     if not data.get("project_name"):
         errors.append("Missing or empty required field: project_name")

package/bundled/skills/bugfix-pipeline-launcher/SKILL.md

@@ -41,7 +41,7 @@ Three execution modes are available. The user chooses one before configuring oth
 **Do NOT use this skill when:**
 - User wants to plan/collect bugs (use `bug-planner` instead)
 - User wants to fix a single bug interactively in current session (use `bug-fix-workflow`)
-- User wants to launch the feature pipeline (use `dev-pipeline-launcher`)
+- User wants to launch the feature pipeline (use `feature-pipeline-launcher`)
 
 ### Prerequisites
 
@@ -142,6 +142,20 @@ Detect user intent from their message, then follow the corresponding workflow:
    | Verbose: On | `VERBOSE=1` |
    | Max retries: N | `MAX_RETRIES=N` |
    | Timeout: value | `SESSION_TIMEOUT=<seconds>` |
+   | Model override | `MODEL=<model-name>` |
+
+   **Advanced environment variables** (not exposed in interactive menu, pass via `--env`):
+
+   | Variable | Default | Purpose |
+   |----------|---------|---------|
+   | `MODEL` | (none) | AI model override (e.g. `claude-opus-4.6`) |
+   | `AUTO_PUSH` | `0` | Auto-push to remote after successful bug fix (`1` to enable) |
+   | `DEV_BRANCH` | auto-generated | Custom dev branch name (default: `bugfix/pipeline-{run_id}`) |
+   | `HEARTBEAT_INTERVAL` | `30` | Heartbeat log interval in seconds |
+   | `HEARTBEAT_STALE_THRESHOLD` | `600` | Max seconds without heartbeat before marking stale |
+   | `LOG_CLEANUP_ENABLED` | `1` | Run periodic log cleanup (`0` to disable) |
+   | `LOG_RETENTION_DAYS` | `14` | Delete logs older than N days |
+   | `LOG_MAX_TOTAL_MB` | `1024` | Keep total logs under N MB via oldest-first cleanup |
 
    ⚠️ STOP HERE and wait for user response before continuing to step 6.
 
@@ -190,7 +204,7 @@ Detect user intent from their message, then follow the corresponding workflow:
    **If foreground**: Pipeline runs to completion in the terminal. After it finishes:
    - Summarize results: total bugs, fixed, failed, skipped
    - If all fixed: each bug session has already run `prizmkit-retrospective` (structural sync) internally. Ask user what's next.
-   - If some failed: show failed bug IDs and suggest `retry-bug.sh <B-XXX>` or `reset-bug.sh <B-XXX> --clean --run`
+   - If some failed: show failed bug IDs and suggest `retry-bugfix.sh <B-XXX>` or `reset-bug.sh <B-XXX> --clean --run`
 
    **If background daemon**:
    1. Verify launch:
@@ -281,14 +295,14 @@ Detect user intent from their message, then follow the corresponding workflow:
 When user says "retry B-001":
 
 ```bash
-dev-pipeline/retry-bug.sh B-001 bug-fix-list.json
+dev-pipeline/retry-bugfix.sh B-001 bug-fix-list.json
 ```
 
-**Note:** `retry-bug.sh` automatically cleans bug artifacts and resets status before retrying. This is equivalent to `reset-feature.sh --clean --run` in the feature pipeline. No separate reset command is needed.
+**Note:** `retry-bugfix.sh` automatically cleans bug artifacts and resets status before retrying. This is equivalent to `reset-feature.sh --clean --run` in the feature pipeline. No separate reset command is needed.
 
 Environment variables (optional):
 ```bash
-SESSION_TIMEOUT=3600 dev-pipeline/retry-bug.sh B-001 bug-fix-list.json
+SESSION_TIMEOUT=3600 dev-pipeline/retry-bugfix.sh B-001 bug-fix-list.json
 ```
 
 ### Error Handling