mindsystem-cc 4.4.2 → 4.5.0

package/mindsystem/templates/config.json

@@ -1,5 +1,11 @@
 {
   "subsystems": [],
+  "skills": {
+    "discuss": [],
+    "design": [],
+    "research": [],
+    "plan": []
+  },
   "code_review": {
     "adhoc": null,
     "phase": null,

package/mindsystem/templates/design.md

@@ -13,7 +13,7 @@ Template for `.planning/phases/XX-name/{phase}-DESIGN.md` - captures visual/UX d
 
 **Designed:** [date]
 **Platform:** [web / mobile / both]
-**Aesthetic source:** [project UI skill / codebase analysis / fresh design]
+**Aesthetic source:** [project design skill / codebase extraction / fresh design]
 
 ## Design Direction
 

package/mindsystem/workflows/adhoc.md

@@ -100,6 +100,35 @@ Governing principle: each question must save more context than it costs. A quest
 **On corrections:** Absorb user feedback and proceed to planning. Do not re-present the full briefing.
 </step>
 
+<step name="select_and_load_skills">
+**Select from all configured skills.**
+
+```bash
+DISCUSS_SKILLS=$(ms-tools config-get skills.discuss --default "[]")
+DESIGN_SKILLS=$(ms-tools config-get skills.design --default "[]")
+RESEARCH_SKILLS=$(ms-tools config-get skills.research --default "[]")
+PLAN_SKILLS=$(ms-tools config-get skills.plan --default "[]")
+```
+
+Combine all arrays and deduplicate into a single list.
+
+**If no skills configured across any phase:** Continue silently — adhoc is a fast path.
+
+**If skills exist:** Analyze the task description and exploration findings against each unique skill. For each skill, assess whether it's relevant to the work at hand based on:
+- Work description keywords and domain
+- Subsystem(s) involved
+- Types of files affected (from exploration step)
+
+Present via AskUserQuestion with `multiSelect: true`:
+- header: "Skills"
+- question: "Which skills should inform this work?"
+- Each unique skill as an option, append "(recommended)" to skills judged relevant
+- Include "None — skip skill loading" option
+- Free-text field for unlisted skills
+
+**After selection:** Invoke selected skills via the Skill tool. Extract relevant implementation conventions for the adhoc planner — include as `<skill_context>` in the prompt sent to ms-adhoc-planner.
+</step>
+
 <step name="spawn_plan_writer">
 Create per-execution subdirectory:
 
@@ -153,6 +182,40 @@ Provide in the prompt:
 The executor reads the plan, executes tasks with atomic commits, creates SUMMARY.md, and returns completion report.
 </step>
 
+<step name="browser_verification">
+Run browser verification prerequisites check:
+
+```bash
+ms-tools browser-check
+```
+
+**If exit 0 (READY):**
+
+Ensure `${exec_dir}/adhoc-01-SUMMARY.md` is available (needed for journey derivation — may already be in context from executor report).
+
+Read `~/.claude/mindsystem/references/browser-verification.md` and follow its sections in order:
+1. **Auth Flow** — establish browser authentication
+2. **Derive User Journeys** — transform SUMMARY into user journeys (single file: `${exec_dir}/adhoc-01-SUMMARY.md`)
+3. **Spawn** — launch ms-browser-verifier with derived journeys, screenshots directory: `${exec_dir}/screenshots`
+4. **Post-Verifier Handling** — route by report status
+
+**If exit 1 (MISSING_DEPS):**
+
+Parse output for missing items. Use AskUserQuestion:
+- header: "Browser verification"
+- question: "Browser verification prerequisites are missing. How to proceed?"
+- options:
+  - "Install missing dependencies" — follow install instructions from output
+  - "Skip browser verification" — proceed to code_review
+
+If user installs: re-run `ms-tools browser-check`.
+If user skips: proceed to code_review.
+
+**If exit 2 (SKIP):**
+
+Proceed silently to code_review.
+</step>
+
 <step name="code_review">
 Read code review agent from config:
 

package/mindsystem/workflows/discuss-phase.md

@@ -76,6 +76,18 @@ cat .planning/knowledge/{subsystem}.md 2>/dev/null
 **If no knowledge files exist:** Skip silently (normal for first phase).
 </step>
 
+<step name="load_skills">
+**Load configured skills for discussion context.**
+
+```bash
+DISCUSS_SKILLS=$(ms-tools config-get skills.discuss --default "[]")
+```
+
+**If skills configured:** Invoke each via the Skill tool. Skill content informs product analysis, assumption generation, and collaborative questioning throughout the discussion.
+
+**If no skills configured:** Continue silently. Discuss-phase works well without skills — they're an enhancement, not a requirement.
+</step>
+
 <step name="check_existing">
 Check if CONTEXT.md already exists for this phase:
 

package/mindsystem/workflows/doctor-fixes.md

@@ -350,4 +350,75 @@ EOF
 Replace `{phase summaries|source code analysis}` with the appropriate phrase based on detected mode.
 </step>
 
+<step name="fix_roadmap_format">
+**Only if Roadmap Format failed.**
+
+Fix missing or malformed pre-work flags (Discuss/Design/Research) in incomplete phases.
+
+1. Read `.planning/ROADMAP.md` and `.planning/PROJECT.md`.
+
+2. For each incomplete phase with flag issues (from doctor-scan output), determine the correct pre-work flags by applying roadmapper principles:
+
+   **Discussion** — Default Likely. Unlikely only when ALL of: fully mechanical (zero design decisions), zero ambiguity in scope or approach (version bump, rename-only refactor, config-only change, pure deletion/cleanup). When Likely, enumerate 2-4 phase-specific assumptions or open questions in the parenthetical reason.
+
+   **Design** — Likely when ANY of: significant new UI work, novel interactions, visual success criteria, cross-platform UI. Unlikely when ALL of: no UI work, backend/API only, infrastructure/testing/deployment, exclusively established UI patterns.
+
+   **Research** — Likely when ANY of: external APIs/services, new libraries/frameworks, unresolved architectural decisions, unclear technical approach. Unlikely when ALL of: established internal patterns, CRUD with known stack, well-documented conventions.
+
+   Use the phase's Goal, Success Criteria, Requirements, and project context from PROJECT.md to make these assessments.
+
+3. Present proposed flags per phase:
+
+   ```
+   ## Roadmap Format Fixes
+
+   ### Phase 8: Week Navigation
+   Current: Only **Research** flag present
+   Proposed:
+     **Discuss**: Likely (assumes carryover model unclear, week boundary behavior unspecified)
+     **Discuss topics**: carryover rules, week start day preference
+     **Design**: Likely (new navigation UI, week transition flow)
+     **Design focus**: week picker, carryover modal
+     **Research**: Likely (carryover) ← already present, keeping as-is
+
+   ### Phase 9: Visual Polish
+   Current: Only **Research** flag present
+   Proposed:
+     **Discuss**: Likely (JARVIS aesthetic interpretation ambiguous, typography priorities unclear)
+     **Discuss topics**: aesthetic reference points, typography hierarchy
+     **Design**: Likely (significant visual redesign)
+     **Design focus**: color palette, component styling, typography system
+     **Research**: Unlikely (established patterns) ← updating from current
+   ```
+
+4. Use AskUserQuestion:
+   - header: "Roadmap format fixes"
+   - question: "These pre-work flags were derived from phase goals and project context. Apply?"
+   - options:
+     - "Apply all" — update ROADMAP.md with all proposed flags
+     - "Review each" — iterate per phase
+     - "Skip" — leave as-is
+
+5. Apply accepted changes using Edit tool. Insert flags in the standard order within each phase section:
+   - After `**Success Criteria**` block (and any existing plan lines)
+   - Before `Plans:` or next phase header
+   - Standard format: `**Flag**: Likely/Unlikely (reason)` with detail lines for Likely flags
+   - Preserve any existing valid flags — only add missing or fix malformed ones
+
+6. Commit:
+
+```bash
+git add .planning/ROADMAP.md
+```
+
+```bash
+git commit -m "$(cat <<'EOF'
+chore(doctor): fix roadmap pre-work flags
+
+Added missing Discuss/Design/Research flags to incomplete phases.
+EOF
+)"
+```
+</step>
+
 </process>

package/mindsystem/workflows/execute-phase.md

@@ -120,6 +120,23 @@ Report wave structure with context:
 The "What it builds" column comes from skimming plan names/objectives. Keep it brief (3-8 words).
 </step>
 
+<step name="load_skill_reminders">
+**Load plan skills and distill reminders for executors.**
+
+```bash
+PLAN_SKILLS=$(ms-tools config-get skills.plan --default "[]")
+```
+
+**If skills configured:** Invoke each via the Skill tool. Distill to a concise `<skill_reminders>` block — 5-10 bullet points of key conventions that an executor should keep in mind while implementing. Focus on:
+- Patterns to follow (naming, structure, API usage)
+- Critical anti-patterns to avoid
+- Quality signals specific to this domain
+
+Plans were already written with skill context, so these reminders are a safety net for executor autonomous decisions (deviations, verification, edge cases).
+
+**If no skills configured:** Skip. No reminders to inject.
+</step>
+
 <step name="execute_waves">
 Execute each wave in sequence. Autonomous plans within a wave run in parallel.
 
@@ -158,7 +175,7 @@ Execute each wave in sequence. Autonomous plans within a wave run in parallel.
    ```
    Task(
      subagent_type="ms-executor",
-     prompt="Execute plan at {plan_path}\n\nPlan: @{plan_path}\nProject state: @.planning/STATE.md"
+     prompt="Execute plan at {plan_path}\n\nPlan: @{plan_path}\nProject state: @.planning/STATE.md\n\n<skill_reminders>\n{distilled bullet points, or omit block if none}\n</skill_reminders>"
    )
    ```
 
@@ -541,11 +558,7 @@ All {Y} plans finished. Phase goal verified.
 
 **If more phases remain AND skip context applies:**
 
-Determine the next phase's primary suggestion inline — do NOT read next-phase-routing.md:
-- From ROADMAP.md (already in context), get Phase {Z+1} pre-work flags
-- Check: CONTEXT.md exists? DESIGN.md? RESEARCH.md? in next phase dir
-- Priority: discuss (if Likely + no CONTEXT.md) > design (if Likely + no DESIGN.md) > research (if Likely + no RESEARCH.md) > plan-phase
-- Present ONE "Also available" entry:
+Run `ms-tools prework-status {Z+1}` and use the Suggested line for the "Also available" entry:
 
 ```markdown
 ---

package/mindsystem/workflows/execute-plan.md

@@ -28,7 +28,7 @@ cat .planning/STATE.md 2>/dev/null
 <step name="load_plan">
 Read the plan file provided in your prompt context.
 
-Parse inline metadata from header: `**Subsystem:**`, `**Type:**`, and `**Skills:**` values.
+Parse inline metadata from header: `**Subsystem:**` and `**Type:**` values.
 
 Parse plan sections:
 - Context (files to read, @-references)
@@ -43,12 +43,6 @@ Parse plan sections:
 **If `**Type:** tdd`:** Read `~/.claude/mindsystem/references/tdd-execution.md` for RED-GREEN-REFACTOR execution flow.
 </step>
 
-<step name="load_skills">
-**If `**Skills:**` is present in plan metadata:** Invoke each listed skill via the Skill tool before proceeding. These were confirmed by the user during planning — load them without further confirmation.
-
-**If `**Skills:**` is absent:** Proceed without loading skills. Skill discovery happens during `/ms:plan-phase` — absence means no skills were relevant.
-</step>
-
 <step name="execute">
 Record start time: `PLAN_START_TIME=$(date -u +"%Y-%m-%dT%H:%M:%SZ"); PLAN_START_EPOCH=$(date +%s)`
 

package/mindsystem/workflows/mockup-generation.md

@@ -91,7 +91,7 @@ Spawn 3 ms-mockup-designer agents IN PARALLEL, each receiving:
 - `<design_direction>` — one of the 3 directions from `derive_directions` (name, philosophy, concrete choices)
 - `<platform>` — `mobile` or `web` from `determine_platform`
 - `<feature_grounding>` — screen/feature identified in `identify_primary_screen`
-- `<existing_aesthetic>` — from project UI skill (`SKILL.md` with design tokens) if exists, else scan codebase theme/style files for colors and fonts. If greenfield, state "No existing aesthetic."
+- `<existing_aesthetic>` — pass through from orchestrator as-is
 - `<mockup_template>` — HTML scaffold from `read_template`
 - Output path: `.planning/phases/{phase}-{slug}/mockups/variant-a.html` (b, c for others)
 

package/mindsystem/workflows/plan-phase.md

@@ -39,12 +39,6 @@ Create executable phase prompts (PLAN.md files) from task breakdown.
 **Vertical slices over horizontal layers:** Group by feature (User: model + API + UI) not by type (all models → all APIs → all UIs).
 
 **Explicit dependencies:** EXECUTION-ORDER.md centralizes dependency and parallelism tracking. Plans with no dependencies = parallel candidates.
-
-**Secure by design:** Assume hostile input on every boundary. Validate, parameterize, authenticate, fail closed.
-
-**Performance by design:** Assume production load, not demo conditions. Plan for efficient data access, appropriate caching, minimal round trips.
-
-**Observable by design:** Plan to debug your own work. Include meaningful error messages, appropriate logging, and clear failure states.
 </planning_principles>
 
 <process>
@@ -246,26 +240,9 @@ For each potential task, ask:
 - **Verify hint**: How to prove it worked
 - **Done hint**: Acceptance criteria
 
-**TDD detection:** For each potential task, evaluate TDD fit:
-
-TDD candidates (create dedicated TDD plans):
-- Business logic with defined inputs/outputs
-- API endpoints with request/response contracts
-- Data transformations, parsing, formatting
-- Validation rules and constraints
-- Algorithms with testable behavior
-- State machines and workflows
-
-Standard tasks (remain in standard plans):
-- UI layout, styling, visual components
-- Configuration changes
-- Glue code connecting existing components
-- One-off scripts and migrations
-- Simple CRUD with no business logic
-
-**Heuristic:** Can you write `expect(fn(input)).toBe(output)` before writing `fn`?
-→ Yes: Mark as tdd_candidate=true
-→ No: Standard task
+**TDD detection:** Can you write `expect(fn(input)).toBe(output)` before writing `fn`?
+→ Yes (business logic, validation, data transforms, algorithms): tdd_candidate=true
+→ No (UI layout, config, glue code, simple CRUD): standard task
 
 **If any tasks were marked tdd_candidate=true:** Read `~/.claude/mindsystem/references/tdd.md` for TDD plan structure guidance.
 
@@ -297,6 +274,11 @@ Format: numbered list with task name, key files, dependency hint, and `[TDD]` fl
 
 **Retain full task details internally.** For each task, maintain in your analysis: id, name, type, needs, creates, tdd_candidate, action_hint, verify_hint, done_hint. These are needed for the handoff step — they just don't need to be displayed.
 </output_format>
+
+**Task quality check:** If you can't specify Files + Action + Verify + Done, the task is too vague.
+
+**Good:** "Create POST /api/auth/login endpoint with bcrypt validation"
+**Bad:** "Set up authentication" / "Make it secure" / "Handle edge cases"
 </step>
 
 <step name="propose_grouping">
@@ -308,7 +290,7 @@ MULTI_PLAN=$(ms-tools config-get multi_plan --default "false")
 
 **If `false` (default) — single plan mode:**
 
-All tasks go into Plan 01, Wave 1. No dependency analysis, clustering, or budget estimation. No AskUserQuestion. Proceed directly to discover_skills.
+All tasks go into Plan 01, Wave 1. No dependency analysis, clustering, or budget estimation. No AskUserQuestion. Proceed directly to load_skills.
 
 **If `true` — multi-plan mode:**
 
@@ -342,28 +324,34 @@ Tasks: {task_ids} — {brief rationale}
 - question: "Does this plan structure look good?"
 - Options: "Looks good, proceed", "Adjust grouping"
 
-**"Looks good, proceed":** Continue to discover_skills.
+**"Looks good, proceed":** Continue to load_skills.
 **"Adjust grouping":** User describes changes in free-text. Apply adjustments, re-present, and confirm again.
 </step>
 
-<step name="discover_skills">
-**Identify relevant project skills for this phase.**
+<step name="load_skills">
+**Load configured skills for planning.**
 
-After plan structure is determined, check if project skills could improve plan quality.
+```bash
+PLAN_SKILLS=$(ms-tools config-get skills.plan --default "[]")
+```
 
-**Scan:** Review the skill list in your system-reminder. Match skills against:
-- The phase's technology stack (Flutter, React, Node.js, etc.)
-- The domain of the tasks identified (UI patterns, API design, state management, etc.)
-- Keywords from RESEARCH.md or CONTEXT.md if they exist
+**If skills configured (non-empty array):** Invoke each via the Skill tool. These provide implementation conventions, code patterns, and framework best practices that must influence the resulting plans.
 
-**If matches found:** Present via AskUserQuestion with `multiSelect: true`:
-- Each matching skill is one option (label: skill name, description: what it provides)
-- Always include a "None — skip skill loading" option
-- User selects which to load, skips, or types a skill name in the free-text field
+After loading, extract implementation-relevant content:
+- Code patterns and conventions (naming, structure, architecture rules)
+- Framework-specific best practices (routing patterns, state management, data fetching)
+- Anti-patterns to avoid
+- Quality criteria specific to the domain
 
-**If no matches:** Skip silently — no need to ask the user.
+Distill into a `<skill_context>` block (aim for high signal density — conventions that change what code looks like, not general advice). This block will be passed to the plan-writer.
 
-**Store result:** Keep the confirmed skill names (may be empty) for the handoff step.
+**If no skills configured:**
+
+```
+Tip: Configuring plan skills in /ms:config can improve plan quality — conventions get encoded directly into plans. Run /ms:config to set them up.
+```
+
+Non-blocking. Continue with empty `<skill_context>`.
 </step>
 
 <step name="handoff_to_writer">
@@ -389,6 +377,7 @@ Assemble handoff payload:
 </proposed_grouping>
 
 <phase_context>
+  <!-- Extract phase_goal from ROADMAP.md line after "Phase N:" and REQ-IDs from "Requirements:" field -->
   <phase_number>{PHASE}</phase_number>
   <phase_name>{PHASE_NAME}</phase_name>
   <phase_dir>.planning/phases/{PHASE}-{PHASE_NAME}</phase_dir>
@@ -416,9 +405,9 @@ Assemble handoff payload:
   {list of services detected in task breakdown}
 </external_services>
 
-<confirmed_skills>
-  {comma-separated skill names confirmed by user, or "none"}
-</confirmed_skills>
+<skill_context>
+{Distilled implementation conventions from loaded skills. Code patterns, framework best practices, anti-patterns, quality criteria. Omit if no skills loaded.}
+</skill_context>
 
 <learnings>
   <!-- Flat list from read_project_history step 6. Omit if no matches found. -->
@@ -498,20 +487,13 @@ Extract:
 
 **Present via AskUserQuestion based on tier from subagent:**
 
-**Skip tier (0-39):**
-- header: "Plan Verification"
-- question: "Risk Score: {score}/100 — Low risk\n\nPlans look straightforward. Verification optional."
-- Options: "Skip verification" (first), "Verify plans"
-
-**Optional tier (40-69):**
-- header: "Plan Verification"
-- question: "Risk Score: {score}/100 — Moderate complexity\n\nTop factors:\n- {factor_1}\n- {factor_2}\n\nVerification recommended but optional."
-- Options: "Verify plans" (first), "Skip verification", "Review plans manually"
+| Tier | Score | Default option | Message |
+|------|-------|----------------|---------|
+| Skip | 0-39 | "Skip verification" | "Low risk. Verification optional." |
+| Optional | 40-69 | "Verify plans" | "Moderate complexity. Verification recommended." |
+| Verify | 70-100 | "Verify plans (Recommended)" | "Higher complexity. Verification strongly recommended." |
 
-**Verify tier (70-100):**
-- header: "Plan Verification Recommended"
-- question: "Risk Score: {score}/100 — Higher complexity\n\nTop factors:\n- {factor_1}\n- {factor_2}\n- {factor_3}\n\nVerification strongly recommended."
-- Options: "Verify plans (Recommended)" (first), "Skip verification", "Review plans manually"
+Include top risk factors for Optional/Verify tiers. Optional/Verify tiers also offer "Review plans manually".
 
 **Handle response:**
 
@@ -615,23 +597,8 @@ Wave 2: {plan-03}
 
 </process>
 
-<task_quality>
-**Good tasks:** Specific files, actions, verification
-- "Add User model to Prisma schema with email, passwordHash, createdAt"
-- "Create POST /api/auth/login endpoint with bcrypt validation"
-
-**Bad tasks:** Vague, not actionable
-- "Set up authentication" / "Make it secure" / "Handle edge cases"
-
-If you can't specify Files + Action + Verify + Done, the task is too vague.
-
-**TDD candidates get dedicated plans.** If "Create price calculator with discount rules" warrants TDD, mark as tdd_candidate=true. Refer to `~/.claude/mindsystem/references/tdd.md` (loaded during task breakdown) for TDD criteria.
-</task_quality>
-
 <anti_patterns>
 - No story points or hour estimates
-- No team assignments
-- No acceptance criteria committees
 - No sub-sub-sub tasks
 - **No reflexive sequential chaining** (Plan 02 depends on 01 "just because")
 Tasks are instructions for Claude, not Jira tickets.
@@ -639,15 +606,12 @@ Tasks are instructions for Claude, not Jira tickets.
 
 <success_criteria>
 Phase planning complete when:
-- [ ] STATE.md read, project history absorbed
-- [ ] Mandatory discovery completed (Level 0-3)
 - [ ] Prior decisions, issues, concerns synthesized
 - [ ] Tasks identified with needs/creates dependencies
 - [ ] Plan grouping determined (auto-grouped or user-confirmed)
-- [ ] Task list + proposed grouping + confirmed skills handed off to ms-plan-writer
+- [ ] Task list + proposed grouping + skill context handed off to ms-plan-writer
 - [ ] PLAN files + EXECUTION-ORDER.md created (pure markdown, Must-Haves, follows proposed grouping)
 - [ ] Plans committed with maximized wave parallelism
-- [ ] Risk assessment presented (score + top factors)
-- [ ] User chose verify/skip (or verified if chosen)
+- [ ] Risk assessment presented and user decision captured (verify/skip)
 - [ ] User knows next steps and wave structure
 </success_criteria>

package/mindsystem/workflows/verify-work.md

@@ -376,14 +376,13 @@ Format:
 Fix: {what the fix changes, 1-2 sentences}
 ```
 
-**If fix is simple (single file, straightforward change):**
-- Go to `apply_fix` immediately
-
-**If fix is complex (multiple files, architectural):**
-- Spawn ms-verify-fixer subagent (go to `escalate_to_fixer`)
+Go to `apply_fix`.
 
 **If cause NOT found after 2-3 checks:**
-- Escalate to fixer subagent (go to `escalate_to_fixer`)
+- Present options via AskUserQuestion:
+  1. Try different approach — Investigate from another angle
+  2. Skip as assumption — Log and move on
+  3. Manual investigation — You'll look into this yourself
 </step>
 
 <step name="apply_fix">
@@ -423,74 +422,6 @@ Fix applied. Please re-test: {specific instruction}
 Go to `handle_retest`.
 </step>
 
-<step name="escalate_to_fixer">
-**Spawn fixer subagent for complex issue:**
-
-**1. Stash mocks (if active):**
-`ms-tools uat-stash-mocks $PHASE_NUMBER`
-
-**2. Spawn ms-verify-fixer:**
-```
-Task(
-  prompt="""
-You are a Mindsystem verify-fixer. Investigate this issue, find the root cause, implement a fix, and commit it.
-
-## Issue
-
-**Test:** {test_name}
-**Expected:** {expected_behavior}
-**Actual:** {user_reported_behavior}
-**Severity:** {inferred_severity}
-
-## Context
-
-**Phase:** {phase_name}
-**Mock state active:** {mock_type or "none"}
-**Relevant files (suspected):** {file_list}
-
-## What was already checked
-
-{lightweight_investigation_results}
-
-## Knowledge Context
-
-{loaded_knowledge_content or "No knowledge files loaded for this session."}
-
-## Your task
-
-1. Investigate to find root cause
-2. Implement minimal fix
-3. Commit with message: fix({phase}-uat): {description}
-4. Return FIX COMPLETE or INVESTIGATION INCONCLUSIVE
-
-Mocks are stashed — working tree is clean.
-""",
-  subagent_type="ms-verify-fixer",
-  description="Fix: {test_name}"
-)
-```
-
-**3. Handle fixer return:**
-
-**If FIX COMPLETE:**
-- Record fix via ms-tools (same as `apply_fix` step 4: `uat-update --test N` + `--append-fix`)
-- Restore mocks: `ms-tools uat-pop-mocks $PHASE_NUMBER`
-- Request re-test
-
-**If INVESTIGATION INCONCLUSIVE:**
-- Restore mocks: `ms-tools uat-pop-mocks $PHASE_NUMBER`
-- Present options:
-  ```
-  Investigation didn't find root cause.
-
-  Options:
-  1. Try different approach — I'll investigate from another angle
-  2. Skip as assumption — Log and move on
-  3. Manual investigation — You'll look into this yourself
-  ```
-- Handle response accordingly
-</step>
-
 <step name="handle_retest">
 **Handle re-test result:**
 
@@ -515,12 +446,12 @@ ms-tools uat-update $PHASE_NUMBER --test N retry_count=1
 
   Options:
   1. Try different approach — Investigate from scratch
-  2. Escalate to subagent — Fresh context might help
-  3. Skip as assumption — Log and move on
+  2. Skip as assumption — Log and move on
+  3. Manual investigation — You'll look into this yourself
   ```
 - "Try different" → Reset investigation, try again
-- "Escalate" → Go to `escalate_to_fixer`
 - "Skip" → Mark as skipped assumption
+- "Manual" → Mark as skipped, user will investigate
 
 **If New issue:**
 - Mark original as pass

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "mindsystem-cc",
-  "version": "4.4.2",
+  "version": "4.5.0",
   "description": "The engineer's meta-prompting system for Claude Code.",
   "bin": {
     "mindsystem-cc": "bin/install.js"