mindsystem-cc 4.3.0 → 4.4.0

package/mindsystem/references/derive-phase-specification.md

@@ -0,0 +1,147 @@
+# Phase Specification Derivation
+
+Shared algorithm for deriving goal, success criteria, requirements, and pre-work flags from a user's phase description. Used by `add-phase` and `insert-phase`.
+
+## Variables
+
+Set by calling command before loading this reference:
+
+- `{PHASE_ID}` — phase number (integer like `7` or decimal like `06.1`)
+- `{PHASE_MARKER}` — empty for add-phase, `(INSERTED)` for insert-phase
+
+## Input Assessment
+
+Read `.planning/PROJECT.md` for vision and domain context (target audience, project scope).
+
+Proceed directly when the user's description provides enough context to derive a confident specification — clear domain, identifiable user outcomes, enough scope to define 2-5 success criteria.
+
+When scope is ambiguous or domain is unclear, ask targeted clarifying questions before deriving. Keep asking until confident.
+
+Use AskUserQuestion with concrete options derived from PROJECT.md/ROADMAP.md context:
+- header: "Phase Clarification"
+- question: specific ambiguity identified
+- options: 2-4 concrete interpretations plus "Something else"
+
+Examples of when to ask:
+- "Add notifications" → notifications for what? (new content, billing events, system alerts, all of these?)
+- "Fix performance" → which user-facing flow? (page load, search, data export?)
+- "Add settings" → which settings? (account, preferences, integrations?)
+
+Examples of when to proceed directly:
+- "Add dark mode toggle to settings page" → clear scope, clear UI, clear outcome
+- "Add Stripe subscription billing with plan selection" → clear domain, clear integration
+
+## Derivation Algorithm
+
+### 1. Goal Statement
+
+Transform the description into an outcome-focused goal:
+
+- Good: "Users can manage subscription billing without edge-case failures"
+- Good: "Content creators can schedule posts for future publication"
+- Good: "Administrators can monitor system health through a real-time dashboard"
+- Bad: "Fix subscription billing" (task, not outcome)
+- Bad: "Add scheduling feature" (feature label, not user outcome)
+- Bad: "Implement admin dashboard" (implementation task, not user value)
+
+Use existing phase goals from ROADMAP.md as style reference.
+
+### 2. Success Criteria (2-5)
+
+Ask: "What must be TRUE for users when this phase completes?"
+
+- Each criterion must be verifiable by a human using the application
+- Observable user behaviors, not implementation tasks
+- Good: "User sees correct prorated amount when changing plans mid-cycle"
+- Good: "User receives email confirmation within 30 seconds of signup"
+- Good: "Dark mode persists across browser sessions"
+- Bad: "Billing calculation is fixed"
+- Bad: "Email service is integrated"
+- Bad: "CSS variables are used for theming"
+
+### 3. Requirements with REQ-IDs
+
+Create atomic, checkable requirements:
+
+- Follow existing category patterns from REQUIREMENTS.md (e.g., if AUTH-01..AUTH-04 exist, continue with AUTH-05)
+- If the work fits an existing category, reuse that prefix and continue numbering
+- If the work introduces a new domain, create a new category prefix
+- User-centric: "User can X" not "System does Y"
+- Each requirement maps to Phase {PHASE_ID}
+
+The calling command has already extracted existing REQ-ID categories and highest numbers from REQUIREMENTS.md — use that context.
+
+### 4. Pre-work Flags
+
+Analyze the description to determine:
+
+**Discuss**: Default Likely — enumerate 2-4 assumptions or open questions specific
+to the phase. Unlikely only for fully mechanical zero-decision work (version bump,
+rename-only refactor, config-only change, pure deletion/cleanup).
+
+**Design**: Likely when description involves UI work, visual elements, forms,
+dashboards, or multi-screen flows. Unlikely for backend-only, API, infrastructure,
+or established UI patterns.
+
+**Research**: Likely when description mentions external APIs/services, new
+libraries/frameworks, or unclear technical approach. Unlikely for established
+internal patterns or well-documented conventions.
+
+Use binary Likely/Unlikely with parenthetical reason. Include topics/focus only when Likely.
+
+## Presentation & Approval
+
+Present the full specification:
+
+```
+## Phase {PHASE_ID}: {Name} {PHASE_MARKER}
+
+**Goal:** {proposed goal}
+
+**Success Criteria:**
+1. {criterion}
+2. {criterion}
+3. {criterion}
+
+**New Requirements:**
+- [ ] **{CAT}-{NN}**: {description}
+- [ ] **{CAT}-{NN}**: {description}
+
+**Pre-work:** Discuss {L/U} | Design {L/U} | Research {L/U}
+```
+
+Use AskUserQuestion:
+- header: "Phase Specification"
+- question: "Does this capture what Phase {PHASE_ID} should deliver?"
+- options:
+  - "Approve" — Proceed with this specification
+  - "Adjust" — I want to refine the goal, criteria, or requirements
+  - "Add context" — I need to provide more detail first
+
+If "Adjust": Ask what to change, revise, re-present.
+If "Add context": Get additional detail, re-derive, re-present.
+Loop until approved.
+
+## Requirements Update
+
+Update REQUIREMENTS.md with the approved requirements:
+
+1. Append new requirements under the appropriate category section in `## v1 Requirements`:
+   - If category exists: add new requirements after the last requirement in that category
+   - If new category: add new category section after last existing category
+
+2. Update `## Traceability` table — append rows for each new requirement:
+   ```
+   | {REQ-ID} | Phase {PHASE_ID} | Pending |
+   ```
+
+3. Update coverage counts:
+   ```
+   - v1 requirements: {X + new count} total
+   - Mapped to phases: {Y + new count}
+   ```
+
+4. Update `*Last updated:*` footer:
+   ```
+   *Last updated: {date} after Phase {PHASE_ID} addition*
+   ```

package/mindsystem/references/routing/next-phase-routing.md

@@ -1,6 +1,6 @@
 # Next Phase Routing
 
-Reference for presenting "Next Up" guidance for a phase. Used by progress (current phase), execute-phase (next phase), and verify-work (next phase).
+Reference for presenting "Next Up" guidance for a phase. Used by progress (current phase) and verify-work (next phase).
 
 ## Purpose
 

package/mindsystem/templates/config.json

@@ -8,5 +8,6 @@
   "open_mockups": "auto",
   "browser_verification": {
     "enabled": true
-  }
+  },
+  "multi_plan": false
 }

package/mindsystem/templates/knowledge.md

@@ -66,7 +66,7 @@ Template for `.planning/knowledge/{subsystem}.md` — per-subsystem knowledge fi
 - **Architecture and Design use prose bullets.** Describe how things work, not tables.
 - **Pitfalls use bold titles** for scannability.
 - **Key Files is a flat list.** No nesting, no grouping.
-- **Rewrite semantics, not append.** Each consolidation produces the current state. Superseded decisions get updated. Outdated patterns get removed. The file is always current.
+- **Edit to reflect current state.** Each update produces the current state through targeted edits — update superseded decisions, remove outdated patterns, append new entries. Use `Edit` for existing files, `Write` only for new files. Never replace an entire knowledge file via `Write`.
 
 ## Cross-Reference Pattern
 

package/mindsystem/templates/milestone-archive.md

@@ -10,8 +10,6 @@ This template is used by the complete-milestone workflow to create archive files
 
 **Status:** ✅ SHIPPED {{DATE}}
 **Phases:** {{PHASE_START}}-{{PHASE_END}}
-**Total Plans:** {{TOTAL_PLANS}}
-
 ## Overview
 
 {{MILESTONE_DESCRIPTION}}
@@ -26,13 +24,6 @@ This template is used by the complete-milestone workflow to create archive files
 
 **Goal**: {{PHASE_GOAL}}
 **Depends on**: {{DEPENDS_ON}}
-**Plans**: {{PLAN_COUNT}} plans
-
-Plans:
-
-- [x] {{PHASE}}-01: {{PLAN_DESCRIPTION}}
-- [x] {{PHASE}}-02: {{PLAN_DESCRIPTION}}
-      [... all plans ...]
 
 **Details:**
 {{PHASE_DETAILS_FROM_ROADMAP}}
@@ -43,11 +34,6 @@ Plans:
 
 **Goal**: Fix authentication bypass vulnerability
 **Depends on**: Phase 2
-**Plans**: 1 plan
-
-Plans:
-
-- [x] 02.1-01: Patch auth vulnerability
 
 **Details:**
 {{PHASE_DETAILS_FROM_ROADMAP}}

package/mindsystem/templates/roadmap-milestone.md

@@ -18,12 +18,6 @@ Template for reorganizing `ROADMAP.md` after first milestone ships. Collapse com
 
 ### Phase 1: [Name]
 **Goal**: [What this phase delivers]
-**Plans**: 3 plans
-
-Plans:
-- [x] 01-01: [Brief description]
-- [x] 01-02: [Brief description]
-- [x] 01-03: [Brief description]
 
 [... remaining phases ...]
 
@@ -36,11 +30,6 @@ Plans:
 #### Phase 5: [Name]
 **Goal**: [What this phase delivers]
 **Depends on**: Phase 4
-**Plans**: 2 plans
-
-Plans:
-- [ ] 05-01: [Brief description]
-- [ ] 05-02: [Brief description]
 
 [... remaining phases ...]
 
@@ -52,11 +41,11 @@ Plans:
 
 ## Progress
 
-| Phase | Milestone | Plans Complete | Status | Completed |
-|-------|-----------|----------------|--------|-----------|
-| 1. Foundation | MVP | 3/3 | Complete | YYYY-MM-DD |
-| 2. Features | MVP | 2/2 | Complete | YYYY-MM-DD |
-| 5. Security | Security & Polish | 0/2 | Not started | - |
+| Phase | Milestone | Status | Completed |
+|-------|-----------|--------|-----------|
+| 1. Foundation | MVP | Complete | YYYY-MM-DD |
+| 2. Features | MVP | Complete | YYYY-MM-DD |
+| 5. Security | Security & Polish | Not started | - |
 ```
 
 **Notes:**

package/mindsystem/templates/roadmap.md

@@ -52,12 +52,6 @@ Decimal phases appear between their surrounding integers in numeric order.
 **Discuss**: Unlikely (mechanical setup, zero design decisions)
 **Design**: Unlikely (backend only)
 **Research**: Unlikely (established patterns)
-**Plans**: [Number of plans, e.g., "3 plans" or "TBD"]
-
-Plans:
-- [ ] 01-01: [Brief description of first plan]
-- [ ] 01-02: [Brief description of second plan]
-- [ ] 01-03: [Brief description of third plan]
 
 ### Phase 2: [Name]
 **Goal**: [What this phase delivers]
@@ -72,21 +66,18 @@ Plans:
 **Design focus**: [What to design]
 **Research**: Likely (new integration)
 **Research topics**: [What needs investigating]
-**Plans**: [Number of plans]
-
-Plans:
-- [ ] 02-01: [Brief description]
-- [ ] 02-02: [Brief description]
 
 ### Phase 2.1: Critical Fix (INSERTED)
-**Goal**: [Urgent work inserted between phases]
+**Goal**: [Outcome-focused goal derived during insertion]
 **Depends on**: Phase 2
+**Requirements**: [REQ-05, REQ-06]
 **Success Criteria** (what must be TRUE):
-  1. [What the fix achieves]
-**Plans**: 1 plan
-
-Plans:
-- [ ] 02.1-01: [Description]
+  1. [Observable behavior from user perspective]
+  2. [Observable behavior from user perspective]
+**Discuss**: Likely (assumes X, unclear if Y)
+**Discuss topics**: [What to clarify]
+**Design**: Unlikely (backend fix)
+**Research**: Unlikely (known patterns)
 
 ### Phase 3: [Name]
 **Goal**: [What this phase delivers]
@@ -101,11 +92,6 @@ Plans:
 **Design**: Unlikely (API only)
 **Research**: Likely (external API)
 **Research topics**: [What needs investigating]
-**Plans**: [Number of plans]
-
-Plans:
-- [ ] 03-01: [Brief description]
-- [ ] 03-02: [Brief description]
 
 ### Phase 4: [Name]
 **Goal**: [What this phase delivers]
@@ -118,22 +104,18 @@ Plans:
 **Discuss topics**: [Priority rules, batch vs individual, error recovery]
 **Design**: Unlikely (backend only)
 **Research**: Unlikely (internal patterns)
-**Plans**: [Number of plans]
-
-Plans:
-- [ ] 04-01: [Brief description]
 
 ## Progress
 
 **Execution Order:**
 Phases execute in numeric order: 2 → 2.1 → 2.2 → 3 → 3.1 → 4
 
-| Phase | Plans Complete | Status | Completed |
-|-------|----------------|--------|-----------|
-| 1. [Name] | 0/3 | Not started | - |
-| 2. [Name] | 0/2 | Not started | - |
-| 3. [Name] | 0/2 | Not started | - |
-| 4. [Name] | 0/1 | Not started | - |
+| Phase | Status | Completed |
+|-------|--------|-----------|
+| 1. [Name] | Not started | - |
+| 2. [Name] | Not started | - |
+| 3. [Name] | Not started | - |
+| 4. [Name] | Not started | - |
 ```
 
 <guidelines>
@@ -145,11 +127,9 @@ Phases execute in numeric order: 2 → 2.1 → 2.2 → 3 → 3.1 → 4
 **Initial planning:**
 - Phase count derived from actual work (not a target number)
 - Each phase delivers something coherent
-- Phases can have 1+ plans (split by orchestrator judgment — multiple subsystems, context budget, vertical slices)
 - Plans use naming: {phase}-{plan}-PLAN.md (e.g., 01-02-PLAN.md)
 - No time estimates (this isn't enterprise PM)
 - Progress table updated by execute workflow
-- Plan count can be "TBD" initially, refined during planning
 
 **Success criteria:**
 - 2-5 observable behaviors per phase (from user's perspective)

package/mindsystem/workflows/adhoc.md

@@ -87,7 +87,7 @@ Governing principle: each question must save more context than it costs. A quest
   - Looks right
   - Some corrections (let me clarify)
   - Let me reframe the task
-- Additional questions (conditional): Only when exploration surfaced genuine behavioral ambiguity the user must resolve. Frame with implementation context discovered during exploration. Typically 1-2 for focused work, 3-4 for multi-area work.
+- Additional questions (conditional): Only when exploration surfaced genuine behavioral ambiguity the user must resolve. Frame with implementation context discovered during exploration. Continue until scope is unambiguous — focused work may need one question; multi-area work may need several.
 
 **What NOT to ask** (Claude determines these from exploration):
 - Technical approach or patterns

package/mindsystem/workflows/complete-milestone.md

@@ -345,7 +345,6 @@ Extract completed milestone details and create archive file.
    - {{DATE}} — Today's date
    - {{PHASE_START}} — First phase number in milestone
    - {{PHASE_END}} — Last phase number in milestone
-   - {{TOTAL_PLANS}} — Count of all plans in milestone
    - {{MILESTONE_DESCRIPTION}} — From ROADMAP.md overview
    - {{PHASES_SECTION}} — Full phase details extracted
    - {{DECISIONS_FROM_PROJECT}} — Key decisions from PROJECT.md

package/mindsystem/workflows/discuss-phase.md

@@ -208,9 +208,9 @@ Present brief product analysis, then use AskUserQuestion:
 - question: "How do you imagine this working?"
 - options: 2-3 interpretations based on phase description, requirements, and industry context + "Let me describe it"
 
-**2. Follow the thread (2-4 rounds typical):**
+**2. Follow the thread:**
 
-Follow the user's thread. Each round: apply product lens to the topic they raised, then AskUserQuestion with 2-3 interpretations + escape hatch. Use multiSelect for priority/essential questions. Stop when vision is clear — don't over-question.
+Follow the user's thread. Each round: apply product lens to the topic they raised, then AskUserQuestion with 2-3 interpretations + escape hatch. Use multiSelect for priority/essential questions. Continue until you could write a CONTEXT.md that plan-phase can act on without clarifying questions — that's the downstream test. Don't ask about edge cases when core behaviors are still undefined; depth over breadth.
 
 **3. Decision gate:**
 

package/mindsystem/workflows/doctor-fixes.md

@@ -315,7 +315,7 @@ Spawn a `general-purpose` subagent (Task tool) with the following structured pro
 > - Preserve rationale when visible in code comments or config. Do not fabricate reasons.
 > - Do not fabricate specific numbers (limits, thresholds, counts) — read from source or omit.
 > - Omit empty sections. No Design section if subsystem has no UI.
-> - Rewrite semantics — if existing knowledge files exist, merge by producing current state.
+> - Edit to reflect current state — use `Edit` for existing knowledge files (targeted changes), `Write` only for new files.
 > - Cross-reference between subsystems where relevant: "(see api subsystem)".
 > - Decisions table: 5-10 words per cell. Source column: `"existing"` for source code mode, artifact reference for artifact mode.
 > - Key files must reference actual paths verified to exist.

package/mindsystem/workflows/execute-phase.md

@@ -298,12 +298,12 @@ ms-tools browser-check
 
 **If exit 0 (READY):**
 
-Ensure `$PHASE_DIR/*-SUMMARY.md` files are available (needed for checklist derivation — may already be in context from wave reports).
+Ensure `$PHASE_DIR/*-SUMMARY.md` files are available (needed for journey derivation — may already be in context from wave reports).
 
 Read `~/.claude/mindsystem/references/browser-verification.md` and follow its sections in order:
 1. **Auth Flow** — establish browser authentication
-2. **Derive Browser Checklist** — transform SUMMARYs into visual checklist items
-3. **Spawn** — launch verifier with derived checklist
+2. **Derive User Journeys** — transform SUMMARYs into user journeys
+3. **Spawn** — launch verifier with derived journeys
 4. **Post-Verifier Handling** — route by report status
 
 **If exit 1 (MISSING_DEPS):**
@@ -539,24 +539,24 @@ All {Y} plans finished. Phase goal verified.
 
 **Then present "Also available" based on milestone status:**
 
-**If more phases remain:**
+**If more phases remain AND skip context applies:**
 
-Read `~/.claude/mindsystem/references/routing/next-phase-routing.md` to determine the most appropriate command for the next phase (discuss/design/research/plan based on pre-work flags). Present concisely under "Also available":
+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:
 
 ```markdown
 ---
-
-**Phase {Z+1}: {Name}** — {Goal}
-{If pre-work flagged: brief note about recommendations}
-
 **Also available:**
-- `/ms:{suggested} {Z+1}` — {reason from routing}
-- `/ms:plan-phase {Z+1}` — skip pre-work, plan directly
-
+- `/ms:{suggested} {Z+1}` — skip verify, start Phase {Z+1}: {Name}
 ---
 ```
 
-Include the pre-work recommendations table from the routing reference if any pre-work is flagged as "Likely".
+**If more phases remain but skip context does NOT apply:** No "Also available" — verify-work is the sole suggestion.
+
+Do NOT present pre-work recommendation tables or multiple cross-phase alternatives. Cross-phase routing belongs to verify-work and progress.
 
 **If milestone complete:**
 

package/mindsystem/workflows/plan-phase.md

@@ -22,13 +22,15 @@ Decimal phases enable urgent work insertion without renumbering:
 </required_reading>
 
 <purpose>
-Create executable phase prompts (PLAN.md files) optimized for parallel execution.
+Create executable phase prompts (PLAN.md files) from task breakdown.
 
 **Two-stage workflow:**
-1. **Main context:** Task identification + grouping proposal (steps 1-9) - collaborative, keeps user in loop
+1. **Main context:** Task identification + grouping (steps 1-9) - collaborative, keeps user in loop
 2. **Subagent (ms-plan-writer):** Plan writing (structural validation, PLAN.md files, risk scoring) - autonomous, heavy lifting
 
-PLAN.md IS the prompt that Claude executes. Plans are grouped into execution waves based on dependencies - independent plans run in parallel, dependent plans wait for predecessors.
+**Default: single plan per phase.** All tasks go into Plan 01, Wave 1. No dependency analysis or user confirmation needed. This is optimal for 1M context windows where phases already scope work tightly.
+
+**Multi-plan mode** (`multi_plan: true` in config): Restores full multi-plan breakdown with dependency analysis, wave grouping, budget estimation, and user confirmation. Enable for phases with genuinely independent work streams that benefit from parallel subagent execution.
 </purpose>
 
 <planning_principles>
@@ -298,7 +300,17 @@ Format: numbered list with task name, key files, dependency hint, and `[TDD]` fl
 </step>
 
 <step name="propose_grouping">
-**Propose plan boundaries before handing off to the plan-writer.**
+**Determine plan boundaries before handing off to the plan-writer.**
+
+```bash
+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.
+
+**If `true` — multi-plan mode:**
 
 After presenting the task list, analyze dependencies and propose how tasks should group into plans. This is a collaborative planning decision — the user sees it and can adjust.
 
@@ -337,7 +349,7 @@ Tasks: {task_ids} — {brief rationale}
 <step name="discover_skills">
 **Identify relevant project skills for this phase.**
 
-After the user confirms the plan structure, check if project skills could improve plan quality.
+After plan structure is determined, check if project skills could improve plan quality.
 
 **Scan:** Review the skill list in your system-reminder. Match skills against:
 - The phase's technology stack (Flutter, React, Node.js, etc.)
@@ -541,6 +553,33 @@ Show plan paths, wait for user response:
 </step>
 
 <step name="offer_next">
+
+**Single plan mode** (default):
+
+```
+Phase {X} planned: 1 plan
+
+---
+
+## Next Up
+
+**Phase {X}: [Phase Name]**
+
+`/ms:execute-phase {X}`
+
+<sub>`/clear` first - fresh context window</sub>
+
+---
+
+**Also available:**
+- Review/adjust plan before executing
+- View plan: `cat .planning/phases/XX-name/XX-01-PLAN.md`
+
+---
+```
+
+**Multi-plan mode:**
+
 ```
 Phase {X} planned: {N} plan(s) in {M} wave(s)
 
@@ -604,7 +643,7 @@ Phase planning complete when:
 - [ ] Mandatory discovery completed (Level 0-3)
 - [ ] Prior decisions, issues, concerns synthesized
 - [ ] Tasks identified with needs/creates dependencies
-- [ ] Plan grouping proposed and presented to user
+- [ ] Plan grouping determined (auto-grouped or user-confirmed)
 - [ ] Task list + proposed grouping + confirmed skills 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

package/mindsystem/workflows/transition.md

@@ -97,7 +97,6 @@ Update the file:
 
 - Mark current phase: `[x] Complete`
 - Add completion date
-- Update plan count to final (e.g., "3/3 plans complete")
 - Update Progress table
 - Keep next phase as `[ ] Not started`
 
@@ -112,11 +111,11 @@ Update the file:
 
 ## Progress
 
-| Phase             | Plans Complete | Status      | Completed  |
-| ----------------- | -------------- | ----------- | ---------- |
-| 1. Foundation     | 3/3            | Complete    | 2025-01-15 |
-| 2. Authentication | 0/2            | Not started | -          |
-| 3. Core Features  | 0/1            | Not started | -          |
+| Phase             | Status      | Completed  |
+| ----------------- | ----------- | ---------- |
+| 1. Foundation     | Complete    | 2025-01-15 |
+| 2. Authentication | Not started | -          |
+| 3. Core Features  | Not started | -          |
 ```
 
 </step>
@@ -442,7 +441,6 @@ Respect user judgment — they know if work matters.
 
 **If marking complete with incomplete plans:**
 
-- Update ROADMAP: "2/3 plans complete" (not "3/3")
 - Note in transition message which plans were skipped
 
 </partial_completion>
@@ -453,7 +451,7 @@ Transition is complete when:
 
 - [ ] Current phase plan summaries verified (all exist or user chose to skip)
 - [ ] Any stale handoffs deleted
-- [ ] ROADMAP.md updated with completion status and plan count
+- [ ] ROADMAP.md updated with completion status
 - [ ] PROJECT.md evolved (requirements, decisions, description if needed)
 - [ ] STATE.md updated (position, project reference, context, session)
 - [ ] Progress table updated

package/mindsystem/workflows/verify-work.md

@@ -365,24 +365,21 @@ This knowledge informs investigation (where to look, known pitfalls) and any sub
 3. Check git log for recent changes to relevant files
 ```
 
-**2. Determine if cause is found:**
+**2. Report finding and act:**
 
-**If cause found AND fix is simple (single file, straightforward change):**
-- Propose fix in plain language:
-  ```
-  Found the issue. In `ErrorBanner.tsx` line 42, the error message is
-  hardcoded to "Something went wrong" instead of using the actual error
-  from the API response.
+State the root cause and the fix in plain language before applying. This lets the user capture the lesson in persistent instructions or catch a wrong direction before reviewing the diff. No confirmation needed — go straight to fixing.
 
-  I'll change it to use `error.message` from props.
+Format:
+```
+{Root cause — what the code does wrong and why, 1-2 sentences}
 
-  Apply this fix?
-  ```
-- Present options: [Yes / Let me see the code first / Different approach]
-- If approved: Go to `apply_fix`
+Fix: {what the fix changes, 1-2 sentences}
+```
+
+**If fix is simple (single file, straightforward change):**
+- Go to `apply_fix` immediately
 
-**If cause found BUT fix is complex (multiple files, architectural):**
-- Report finding
+**If fix is complex (multiple files, architectural):**
 - Spawn ms-verify-fixer subagent (go to `escalate_to_fixer`)
 
 **If cause NOT found after 2-3 checks:**

package/package.json

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