mindsystem-cc 3.10.0 → 3.11.0

package/mindsystem/workflows/complete-milestone.md

@@ -26,11 +26,12 @@ When a milestone completes, this workflow:
 2. Cleans up phase artifacts (PLAN, CONTEXT, RESEARCH, DESIGN files deleted)
 3. Extracts full milestone details to `.planning/milestones/v[X.Y]-ROADMAP.md`
 4. Archives requirements to `.planning/milestones/v[X.Y]-REQUIREMENTS.md`
-5. Updates ROADMAP.md to replace milestone details with one-line summary
-6. Deletes REQUIREMENTS.md (fresh one created for next milestone)
-7. Extracts learnings into `.planning/LEARNINGS.md` (curated one-line patterns with source refs)
-8. Performs full PROJECT.md evolution review
-9. Routes to `/ms:new-milestone` for next milestone
+5. Archives milestone context to `.planning/milestones/v[X.Y]-CONTEXT.md`
+6. Updates ROADMAP.md to replace milestone details with one-line summary
+7. Deletes REQUIREMENTS.md (fresh one created for next milestone)
+8. Extracts learnings into `.planning/LEARNINGS.md` (curated one-line patterns with source refs)
+9. Performs full PROJECT.md evolution review
+10. Routes to `/ms:new-milestone` for next milestone
 
 **Context Efficiency:**
 
@@ -645,7 +646,7 @@ Archive requirements and prepare for fresh requirements in next milestone.
    ✅ REQUIREMENTS.md deleted (fresh one needed for next milestone)
    ```
 
-**Important:** The next milestone workflow starts with `/ms:define-requirements` to create a fresh REQUIREMENTS.md. PROJECT.md's Validated section carries the cumulative record across milestones.
+**Important:** The next milestone workflow starts with `/ms:create-roadmap` to create a fresh REQUIREMENTS.md. PROJECT.md's Validated section carries the cumulative record across milestones.
 
 </step>
 
@@ -667,6 +668,23 @@ Confirm:
 
 </step>
 
+<step name="archive_context">
+
+Archive the milestone context file (if it exists):
+
+```bash
+[ -f .planning/MILESTONE-CONTEXT.md ] && mv .planning/MILESTONE-CONTEXT.md .planning/milestones/v[X.Y]-CONTEXT.md
+```
+
+If archived:
+```
+✅ Context archived to milestones/v[X.Y]-CONTEXT.md
+```
+
+(Skip silently if no context file exists)
+
+</step>
+
 <step name="update_state">
 
 Update STATE.md to reflect milestone completion.
@@ -743,6 +761,7 @@ git add .planning/milestones/v[X.Y]-DECISIONS.md
 git add .planning/milestones/v[X.Y]-ROADMAP.md
 git add .planning/milestones/v[X.Y]-REQUIREMENTS.md
 git add .planning/milestones/v[X.Y]-MILESTONE-AUDIT.md 2>/dev/null || true
+git add .planning/milestones/v[X.Y]-CONTEXT.md 2>/dev/null || true
 
 # Stage learnings (may not exist if no learnings found)
 git add .planning/LEARNINGS.md 2>/dev/null || true
@@ -818,8 +837,7 @@ Tag: v[X.Y]
 **Next milestone flow:**
 1. `/ms:new-milestone` — discover what to build, update PROJECT.md with goals
 2. `/ms:research-project` — (optional) research ecosystem
-3. `/ms:define-requirements` — scope what to build
-4. `/ms:create-roadmap` — plan how to build it
+3. `/ms:create-roadmap` — define requirements and plan how to build it
 
 ---
 ```
@@ -882,6 +900,7 @@ Milestone completion is successful when:
 - [ ] STATE.md updated with fresh project reference
 - [ ] Git tag created (v[X.Y])
 - [ ] Milestone commit made (includes archive files and deletion)
+- [ ] Context archive created if MILESTONE-CONTEXT.md existed
 - [ ] User knows next steps (starting with /ms:new-milestone)
 
 </success_criteria>

package/mindsystem/workflows/execute-phase.md

@@ -3,7 +3,7 @@ Execute all plans in a phase using wave-based parallel execution. Orchestrator s
 </purpose>
 
 <core_principle>
-The orchestrator's job is coordination, not execution. Each subagent loads the full execute-plan context itself. Orchestrator discovers plans, analyzes dependencies, groups into waves, spawns agents, handles checkpoints, collects results.
+The orchestrator's job is coordination, not execution. Each subagent loads the full execute-plan context itself. Orchestrator discovers plans, analyzes dependencies, groups into waves, spawns agents, collects results.
 </core_principle>
 
 <required_reading>
@@ -68,13 +68,11 @@ ls -1 "$PHASE_DIR"/*-SUMMARY.md 2>/dev/null | sort
 
 For each plan, read frontmatter to extract:
 - `wave: N` - Execution wave (pre-computed)
-- `autonomous: true/false` - Whether plan has checkpoints
 
 Build plan inventory:
 - Plan path
 - Plan ID (e.g., "03-01")
 - Wave number
-- Autonomous flag
 - Completion status (SUMMARY exists = complete)
 
 Skip completed plans. If all complete, report "Phase already executed" and exit.
@@ -87,8 +85,7 @@ Read `wave` from each plan's frontmatter and group by wave number:
 # For each plan, extract wave from frontmatter
 for plan in $PHASE_DIR/*-PLAN.md; do
   wave=$(grep "^wave:" "$plan" | cut -d: -f2 | tr -d ' ')
-  autonomous=$(grep "^autonomous:" "$plan" | cut -d: -f2 | tr -d ' ')
-  echo "$plan:$wave:$autonomous"
+  echo "$plan:$wave"
 done
 ```
 
@@ -113,7 +110,7 @@ Report wave structure with context:
 |------|-------|----------------|
 | 1 | 01-01, 01-02 | {from plan objectives} |
 | 2 | 01-03 | {from plan objectives} |
-| 3 | 01-04 [checkpoint] | {from plan objectives} |
+| 3 | 01-04 | {from plan objectives} |
 
 ```
 
@@ -150,36 +147,40 @@ Execute each wave in sequence. Autonomous plans within a wave run in parallel.
    - Bad: "Executing terrain generation plan"
    - Good: "Procedural terrain generator using Perlin noise — creates height maps, biome zones, and collision meshes. Required before vehicle physics can interact with ground."
 
-2. **Spawn all autonomous agents in wave simultaneously:**
+2. **Spawn executor agents:**
 
-   Use Task tool with multiple parallel calls. Each agent gets prompt from subagent-task-prompt template:
+   Pass paths only — executors read files themselves with their fresh 200k context.
+   This keeps orchestrator context lean (~10-15%).
 
    ```
-   <objective>
-   Execute plan {plan_number} of phase {phase_number}-{phase_name}.
-
-   Commit each task atomically. Create SUMMARY.md. Update STATE.md.
-   </objective>
-
-   <execution_context>
-   @~/.claude/mindsystem/workflows/execute-plan.md
-   @~/.claude/mindsystem/templates/summary.md
-   @~/.claude/mindsystem/references/checkpoints.md
-   @~/.claude/mindsystem/references/tdd.md
-   </execution_context>
-
-   <context>
-   Plan: @{plan_path}
-   Project state: @.planning/STATE.md
-   Config: @.planning/config.json (if exists)
-   </context>
-
-   <success_criteria>
-   - [ ] All tasks executed
-   - [ ] Each task committed individually
-   - [ ] SUMMARY.md created in plan directory
-   - [ ] STATE.md updated with position and decisions
-   </success_criteria>
+   Task(
+     subagent_type="ms-executor",
+     prompt="
+       <objective>
+       Execute plan {plan_number} of phase {phase_number}-{phase_name}.
+       Commit each task atomically. Create SUMMARY.md. Update STATE.md.
+       </objective>
+
+       <execution_context>
+       @~/.claude/mindsystem/workflows/execute-plan.md
+       @~/.claude/mindsystem/templates/summary.md
+       @~/.claude/mindsystem/references/tdd.md
+       </execution_context>
+
+       <context>
+       Plan: @{plan_path}
+       Project state: @.planning/STATE.md
+       Config: @.planning/config.json (if exists)
+       </context>
+
+       <success_criteria>
+       - [ ] All tasks executed
+       - [ ] Each task committed individually
+       - [ ] SUMMARY.md created in plan directory
+       - [ ] STATE.md updated with position and decisions
+       </success_criteria>
+     "
+   )
    ```
 
 2. **Wait for all agents in wave to complete:**
@@ -223,93 +224,8 @@ Execute each wave in sequence. Autonomous plans within a wave run in parallel.
    - If continue: proceed to next wave (dependent plans may also fail)
    - If stop: exit with partial completion report
 
-5. **Execute checkpoint plans between waves:**
-
-   See `<checkpoint_handling>` for details.
-
-6. **Proceed to next wave**
-
-</step>
-
-<step name="checkpoint_handling">
-Plans with `autonomous: false` require user interaction.
-
-**Detection:** Check `autonomous` field in frontmatter.
-
-**Execution flow for checkpoint plans:**
-
-1. **Spawn agent for checkpoint plan:**
-   ```
-   Task(prompt="{subagent-task-prompt}", subagent_type="general-purpose")
-   ```
-
-2. **Agent runs until checkpoint:**
-   - Executes auto tasks normally
-   - Reaches checkpoint task (e.g., `type="checkpoint:human-verify"`) or auth gate
-   - Agent returns with structured checkpoint (see checkpoint-return.md template)
-
-3. **Agent return includes (structured format):**
-   - Completed Tasks table with commit hashes and files
-   - Current task name and blocker
-   - Checkpoint type and details for user
-   - What's awaited from user
-
-4. **Orchestrator presents checkpoint to user:**
-
-   Extract and display the "Checkpoint Details" and "Awaiting" sections from agent return:
-   ```
-   ## Checkpoint: [Type]
-
-   **Plan:** 03-03 Dashboard Layout
-   **Progress:** 2/3 tasks complete
-
-   [Checkpoint Details section from agent return]
-
-   [Awaiting section from agent return]
-   ```
-
-5. **User responds:**
-   - "approved" / "done" → spawn continuation agent
-   - Description of issues → spawn continuation agent with feedback
-   - Decision selection → spawn continuation agent with choice
-
-6. **Spawn continuation agent (NOT resume):**
-
-   Use the continuation-prompt.md template:
-   ```
-   Task(
-     prompt=filled_continuation_template,
-     subagent_type="general-purpose"
-   )
-   ```
+5. **Proceed to next wave**
 
-   Fill template with:
-   - `{completed_tasks_table}`: From agent's checkpoint return
-   - `{resume_task_number}`: Current task from checkpoint
-   - `{resume_task_name}`: Current task name from checkpoint
-   - `{user_response}`: What user provided
-   - `{resume_instructions}`: Based on checkpoint type (see continuation-prompt.md)
-
-7. **Continuation agent executes:**
-   - Verifies previous commits exist
-   - Continues from resume point
-   - May hit another checkpoint (repeat from step 4)
-   - Or completes plan
-
-8. **Repeat until plan completes or user stops**
-
-**Why fresh agent instead of resume:**
-Resume relies on Claude Code's internal serialization which breaks with parallel tool calls.
-Fresh agents with explicit state are more reliable and maintain full context.
-
-**Checkpoint in parallel context:**
-If a plan in a parallel wave has a checkpoint:
-- Spawn as normal
-- Agent pauses at checkpoint and returns with structured state
-- Other parallel agents may complete while waiting
-- Present checkpoint to user
-- Spawn continuation agent with user response
-- Wait for all agents to finish before next wave
 </step>
 
 <step name="aggregate_results">
@@ -612,10 +528,6 @@ Each subagent: Fresh 200k context
 - Stop execution
 - Report for manual investigation
 
-**Checkpoint fails to resolve:**
-- User can't approve or provides repeated issues
-- Ask: "Skip this plan?" or "Abort phase execution?"
-- Record partial progress in STATE.md
 </failure_handling>
 
 <resumption>
@@ -632,5 +544,4 @@ If phase execution was interrupted (context limit, user exit, error):
 **STATE.md tracks:**
 - Last completed plan
 - Current wave
-- Any pending checkpoints
 </resumption>