mindsystem-cc 3.21.0 → 3.22.0

package/README.md

@@ -272,7 +272,7 @@ Replace `<N>` with the phase number you're working on.
 - `.planning/milestones/mvp/` — archived milestone (ROADMAP, REQUIREMENTS, DECISIONS, research)
 - Active docs stay lean; full detail lives in the version folder
 
-**Tip:** Milestone review can be **report-only** (e.g., Flutter structural review) so you stay in control. Create a quality phase, or accept tech debt explicitly — your call.
+**Tip:** Milestone review can be **report-only** so you stay in control. Create a quality phase, or accept tech debt explicitly — your call.
 
 ---
 
@@ -312,17 +312,9 @@ After `/ms:execute-phase` (and optionally `/ms:audit-milestone`), Mindsystem run
 
 | Value                     | What it does                                                   |
 | ------------------------- | -------------------------------------------------------------- |
-| `null`                    | Use the default (stack-aware when available)                   |
-| `"ms-code-simplifier"`    | Generic reviewer — improves clarity and maintainability        |
-| `"ms-flutter-simplifier"` | Flutter/Dart-specific — strong widget and Riverpod conventions |
-| `"ms-flutter-reviewer"`   | Flutter structural analysis (report-only, no code changes)     |
-| `"skip"`                  | Disable review for that level                                  |
-
-**Flutter-specific tools (built-in):**
-
-- **`ms-flutter-simplifier`** — pragmatic refactors that preserve behavior
-- **`ms-flutter-reviewer`** — milestone-level structural audit with actionable report (you control the fixes)
-- **`flutter-senior-review` skill** — domain principles that raise review quality beyond generic lint advice
+| `null`                 | No reviewer (default)                                       |
+| `"ms-code-simplifier"` | Generic reviewer — improves clarity and maintainability      |
+| `"skip"`               | Disable review for that level                                |
 
 ---
 

package/agents/ms-plan-checker.md

@@ -186,34 +186,38 @@ issue:
 **Question:** Will plans complete within context budget?
 
 **Process:**
-1. Count `### ` subsections (changes) per plan
-2. Count files from `**Files:**` lines per plan
-3. Check against thresholds
+1. For each `### ` subsection (change), classify its weight:
+   - **Light (5%):** Config changes, localization keys, renaming, simple field additions, pattern-copying with parameter substitution
+   - **Medium (10%):** CRUD endpoints, pattern-following implementations, widget extraction, single-file refactoring
+   - **Heavy (20%):** Complex business logic, novel state management, architecture changes, multi-file integrations
+2. Sum estimated budget per plan (target: 25-45%)
+3. Check structural signals
 
-**Thresholds:**
-| Metric | Target | Warning | Blocker |
-|--------|--------|---------|---------|
-| Changes/plan | 2-3 | 4 | 5+ |
-| Files/plan | 5-8 | 10 | 15+ |
-| Total context | ~50% | ~70% | 80%+ |
+**Thresholds (warning-level only — scope never produces blockers):**
+| Metric | Target | Warning |
+|--------|--------|---------|
+| Estimated budget/plan | 25-45% | >50% |
+| Files per single change | 1-3 | 8+ |
+
+**Raw change count is NOT a threshold.** A plan with 8 lightweight, formulaic changes (~40% budget) is healthier than a plan with 3 heavy, novel changes (~60%). Assess complexity and budget, not count.
 
 **Red flags:**
-- Plan with 5+ changes (quality degrades)
-- Plan with 15+ file modifications
-- Single change with 10+ files
-- Complex work (auth, payments) crammed into one plan
+- Estimated plan budget >50% (quality will degrade)
+- Single change with 10+ file modifications
+- Multiple unrelated subsystems crammed into one plan
+- Novel/complex work appearing late in a long change sequence (context fatigue risks lower attention)
 
 **Example issue:**
 ```yaml
 issue:
   dimension: scope_sanity
   severity: warning
-  description: "Plan 01 has 5 changes - split recommended"
+  description: "Plan 01 estimated at ~55% budget - 3 heavy changes with novel state management"
   plan: "01"
   metrics:
-    changes: 5
-    files: 12
-  fix_hint: "Split into 2 plans: foundation (01) and integration (02)"
+    estimated_budget: "55%"
+    heavy_changes: 3
+  fix_hint: "Move change 3 (complex state machine) to a separate plan"
 ```
 
 ## Dimension 6: Verification Derivation
@@ -301,7 +305,7 @@ PHASE_DIR=$(ls -d .planning/phases/${PADDED_PHASE}-* .planning/phases/${PHASE_AR
 ls "$PHASE_DIR"/*-PLAN.md 2>/dev/null
 
 # Get phase goal from ROADMAP
-grep -A 10 "Phase ${PHASE_NUM}" .planning/ROADMAP.md | head -15
+grep -A 10 "Phase ${PADDED_PHASE}" .planning/ROADMAP.md | head -15
 
 # Get phase brief if exists
 ls "$PHASE_DIR"/*-BRIEF.md 2>/dev/null
@@ -342,12 +346,12 @@ Run Dimensions 1-7 from `<verification_dimensions>` against the loaded plans. Bu
 - Missing requirement coverage
 - Missing required change fields
 - Circular dependencies or file conflicts in same wave
-- Scope > 5 changes per plan
 
 **warning** - Should fix, execution may work
-- Scope 4 tasks (borderline)
+- Estimated plan budget >50%
 - Implementation-focused truths
 - Minor wiring missing
+- Novel/complex changes appearing late in change sequence
 
 **info** - Suggestions for improvement
 - Could split for better parallelization
@@ -369,8 +373,8 @@ issues:
   - plan: "01"
     dimension: "scope_sanity"
     severity: "warning"
-    description: "Plan has 4 changes - consider splitting"
-    fix_hint: "Split into foundation + integration plans"
+    description: "Plan estimated at ~50% budget - heavy changes may cause degradation"
+    fix_hint: "Consider splitting complex changes into separate plan"
 
   - plan: null
     dimension: "requirement_coverage"
@@ -462,14 +466,10 @@ issues:
 
 <anti_patterns>
 
-**DO NOT check code existence.** That's ms-verifier's job after execution. You verify plans, not codebase.
-
-**DO NOT run the application.** This is static plan analysis. No `npm start`, no `curl` to running server.
+**DO NOT check the codebase.** You verify plans describe what to build — checking code existence is ms-verifier's job after execution. No `npm start`, no `curl`, no runtime verification.
 
 **DO NOT accept vague changes.** "Implement auth" is not specific enough. Changes need concrete files, implementation details, verification.
 
-**DO NOT verify implementation details.** Check that plans describe what to build, not that code exists.
-
 **DO NOT trust change titles alone.** Read the implementation details, Files lines, verification entries. A well-named change can be empty.
 
 </anti_patterns>
@@ -478,11 +478,11 @@ issues:
 
 Plan verification complete when:
 
-- [ ] Key links checked (wiring planned between artifacts, not just creation)
-- [ ] Scope assessed per plan (changes, files within thresholds)
+- [ ] Context compliance checked (if CONTEXT.md: locked decisions implemented, deferred ideas excluded)
 - [ ] Must-Haves are user-observable truths, not implementation details
+- [ ] Key links checked (wiring planned between artifacts, not just creation)
 - [ ] EXECUTION-ORDER.md validated (no missing plans, no file conflicts in same wave)
-- [ ] Context compliance checked (if CONTEXT.md: locked decisions implemented, deferred ideas excluded)
+- [ ] Scope assessed per plan (estimated budget within thresholds)
 - [ ] Structured issues returned to orchestrator
 
 </success_criteria>

package/agents/ms-plan-writer.md

@@ -91,7 +91,7 @@ The orchestrator provides structured XML:
 </proposed_grouping>
 
 <confirmed_skills>
-  flutter-code-quality, flutter-code-simplification
+  project-skill-a, project-skill-b
 </confirmed_skills>
 
 <learnings>

package/agents/ms-product-researcher.md

@@ -7,7 +7,7 @@ color: cyan
 ---
 
 <input>
-You receive: `<product_context>` (Who It's For, Core Value, How It's Different), `<phase_requirements>` (phase goal + mapped requirements), `<research_focus>` (specific product questions to investigate).
+You receive: `<current_date>` (YYYY-MM), `<product_context>` (Who It's For, Core Value, How It's Different), `<phase_requirements>` (phase goal + mapped requirements), `<research_focus>` (specific product questions to investigate).
 </input>
 
 <role>
@@ -31,7 +31,9 @@ You are a Mindsystem product researcher. Deliver prescriptive, audience-grounded
 | Industry best practices | WebSearch | Current standards |
 | Product comparisons | WebSearch | Side-by-side analysis |
 
-**Include current year** in search queries for freshness.
+**Search freshness:** Use `<current_date>` to keep results current, but apply year strings selectively:
+- **Add year** to trend/best-practice queries where listicle freshness matters: `"payment terminal UX best practices 2026"`
+- **Omit year** from product-specific queries where it narrows results unhelpfully: `"Square Terminal cashier workflow features"` (Square's docs don't mention the year)
 
 **Budget:** 5-8 searches max. Prioritize breadth over depth — the user needs a landscape, not a dissertation.
 </tool_strategy>

package/agents/ms-verifier.md

@@ -19,13 +19,7 @@ Your job: Goal-backward verification. Start from what the phase SHOULD deliver,
 
 A task "create chat component" can be marked complete when the component is a placeholder. The task was done — a file was created — but the goal "working chat interface" was not achieved.
 
-Goal-backward verification starts from the outcome and works backwards:
-
-1. What must be TRUE for the goal to be achieved?
-2. What must EXIST for those truths to hold?
-3. What must be WIRED for those artifacts to function?
-
-Then verify each level against the actual codebase.
+Goal-backward verification starts from the outcome and works backwards — verify each level against the actual codebase.
 </core_principle>
 
 <verification_process>
@@ -205,7 +199,7 @@ Identify the project's tech stack from file extensions and project structure. Fo
 If REQUIREMENTS.md exists and has requirements mapped to this phase:
 
 ```bash
-grep -E "Phase ${PHASE_NUM}" .planning/REQUIREMENTS.md 2>/dev/null
+grep -E "^| ${PHASE_NUM}" .planning/REQUIREMENTS.md 2>/dev/null
 ```
 
 For each requirement:
@@ -226,7 +220,7 @@ Identify files modified in this phase from PLAN.md `**Files:**` lines or git his
 
 ```bash
 # Extract files from PLAN.md (trustworthy source)
-grep "^\*\*Files:\*\*" "$PHASE_DIR"/*-PLAN.md | sed 's/.*`\([^`]*\)`.*/\1/' | sort -u
+grep -oE '`[^`]+`' "$PHASE_DIR"/*-PLAN.md | grep -v "PLAN.md" | tr -d '`' | sort -u
 ```
 
 Scan each file for anti-patterns: `TODO/FIXME/XXX/HACK` comments, placeholder content (`coming soon`, `will be here`), empty implementations (`return null`, `return {}`, `=> {}`), console.log-only handlers.
@@ -237,44 +231,16 @@ Categorize findings:
 - ⚠️ Warning: Indicates incomplete (TODO comments, console.log)
 - ℹ️ Info: Notable but not problematic
 
-## Step 8: Identify Human Verification Needs
-
-Some things can't be verified programmatically:
-
-**Always needs human:**
-
-- Visual appearance (does it look right?)
-- User flow completion (can you do the full task?)
-- Real-time behavior (WebSocket, SSE updates)
-- External service integration (payments, email)
-- Performance feel (does it feel fast?)
-- Error message clarity
-
-**Needs human if uncertain:**
-
-- Complex wiring that grep can't trace
-- Dynamic behavior depending on state
-- Edge cases and error states
-
-**Format for human verification:**
-
-```markdown
-### 1. {Test Name}
-
-**Test:** {What to do}
-**Expected:** {What should happen}
-**Why human:** {Why can't verify programmatically}
-```
-
-## Step 9: Determine Overall Status
+## Step 8: Determine Overall Status
 
 **Status: passed**
 
-- All truths VERIFIED
+- All truths VERIFIED or UNCERTAIN
 - All artifacts pass level 1-3
 - All key links WIRED
 - No blocker anti-patterns
-- (Human verification items are OK — will be prompted)
+
+UNCERTAIN truths count toward passed — they are structurally present but need functional confirmation through UAT.
 
 **Status: gaps_found**
 
@@ -283,64 +249,19 @@ Some things can't be verified programmatically:
 - OR one or more key links NOT_WIRED
 - OR blocker anti-patterns found
 
-**Status: human_needed**
-
-- All automated checks pass
-- BUT items flagged for human verification
-- Can't determine goal achievement without human
-
 **Calculate score:**
 
 ```
 score = (verified_truths / total_truths)
 ```
 
-## Step 10: Structure Gap Output (If Gaps Found)
+## Step 9: Structure Gap Output (If Gaps Found)
 
-When gaps are found, structure them for consumption by `/ms:plan-phase --gaps`.
+When gaps are found, structure them in YAML frontmatter for consumption by `/ms:plan-phase --gaps`. Use the `gaps:` format shown in the VERIFICATION.md template below.
 
-**Output structured gaps in YAML frontmatter:**
+**Gap fields:** `truth` (observable truth that failed), `status` (failed | partial), `reason` (why it failed), `artifacts` (files with issues), `missing` (specific things to add/fix).
 
-```yaml
----
-phase: XX-name
-verified: YYYY-MM-DDTHH:MM:SSZ
-status: gaps_found
-score: N/M must-haves verified
-gaps:
-  - truth: "User can see existing messages"
-    status: failed
-    reason: "Chat.tsx exists but doesn't fetch from API"
-    artifacts:
-      - path: "src/components/Chat.tsx"
-        issue: "No useEffect with fetch call"
-    missing:
-      - "API call in useEffect to /api/chat"
-      - "State for storing fetched messages"
-      - "Render messages array in JSX"
-  - truth: "User can send a message"
-    status: failed
-    reason: "Form exists but onSubmit is stub"
-    artifacts:
-      - path: "src/components/Chat.tsx"
-        issue: "onSubmit only calls preventDefault()"
-    missing:
-      - "POST request to /api/chat"
-      - "Add new message to state after success"
----
-```
-
-**Gap structure:**
-
-- `truth`: The observable truth that failed verification
-- `status`: failed | partial
-- `reason`: Brief explanation of why it failed
-- `artifacts`: Which files have issues and what's wrong
-- `missing`: Specific things that need to be added/fixed
-
-The planner (`/ms:plan-phase --gaps`) reads this gap analysis and creates appropriate plans.
-
-**Group related gaps by concern** when possible — if multiple truths fail because of the same root cause (e.g., "Chat component is a stub"), note this in the reason to help the planner create focused plans.
+**Group related gaps by concern** when possible — if multiple truths fail because of the same root cause, note this in the reason to help the planner create focused plans.
 
 </verification_process>
 
@@ -354,8 +275,9 @@ Create `.planning/phases/{phase_dir}/{phase}-VERIFICATION.md` with:
 ---
 phase: XX-name
 verified: YYYY-MM-DDTHH:MM:SSZ
-status: passed | gaps_found | human_needed
+status: passed | gaps_found
 score: N/M must-haves verified
+uncertain: N # Count of UNCERTAIN truths + NEEDS HUMAN requirements (0 if none)
 re_verification: # Only include if previous VERIFICATION.md existed
   previous_status: gaps_found
   previous_score: 2/5
@@ -373,10 +295,6 @@ gaps: # Only include if status: gaps_found
     missing:
       - "Specific thing to add/fix"
       - "Another specific thing"
-human_verification: # Only include if status: human_needed
-  - test: "What to do"
-    expected: "What should happen"
-    why_human: "Why can't verify programmatically"
 ---
 
 # Phase {X}: {Name} Verification Report
@@ -418,10 +336,6 @@ human_verification: # Only include if status: human_needed
 | File | Line | Pattern | Severity | Impact |
 | ---- | ---- | ------- | -------- | ------ |
 
-### Human Verification Required
-
-{Items needing human testing — detailed format for user}
-
 ### Gaps Summary
 
 {Narrative summary of what's missing and why}
@@ -441,13 +355,23 @@ Return with:
 ```markdown
 ## Verification Complete
 
-**Status:** {passed | gaps_found | human_needed}
+**Status:** {passed | gaps_found}
 **Score:** {N}/{M} must-haves verified
 **Report:** .planning/phases/{phase_dir}/{phase}-VERIFICATION.md
 
-{If passed:}
+{If passed AND uncertain == 0:}
 All must-haves verified. Phase goal achieved. Ready to proceed.
 
+{If passed AND uncertain > 0:}
+All must-haves verified. Phase goal achieved.
+
+### Items Not Verified Programmatically
+
+{N} items could not be confirmed by structural checks alone:
+1. **{Truth/Requirement}** — {why uncertain}
+
+Consider `/ms:verify-work {phase}` to validate these through UAT.
+
 {If gaps_found:}
 
 ### Gaps Found
@@ -460,19 +384,6 @@ All must-haves verified. Phase goal achieved. Ready to proceed.
    - Missing: {what needs to be added}
 
 Structured gaps in VERIFICATION.md frontmatter for `/ms:plan-phase --gaps`.
-
-{If human_needed:}
-
-### Human Verification Required
-
-{N} items need human testing:
-
-1. **{Test name}** — {what to do}
-   - Expected: {what should happen}
-2. **{Test name}** — {what to do}
-   - Expected: {what should happen}
-
-Automated checks passed. Awaiting human verification.
 ```
 
 </output>
@@ -487,8 +398,6 @@ Automated checks passed. Awaiting human verification.
 
 **Structure gaps in YAML frontmatter.** The planner (`/ms:plan-phase --gaps`) creates plans from your analysis.
 
-**DO flag for human verification when uncertain.** If you can't verify programmatically (visual, real-time, external service), say so explicitly.
-
 **DO keep verification fast.** Use grep/file checks, not running the app. Goal is structural verification, not functional testing.
 
 **DO NOT commit.** Create VERIFICATION.md but leave committing to the orchestrator.
@@ -501,7 +410,6 @@ Automated checks passed. Awaiting human verification.
 - [ ] Key links verified — not just artifact existence; this is where stubs hide
 - [ ] Artifacts checked at all three levels (exists → substantive → wired)
 - [ ] SUMMARY.md claims verified against actual code, not trusted
-- [ ] Human verification items identified for what can't be checked programmatically
 - [ ] Re-verification: focus on previously-failed items, regression-check passed items
 - [ ] Results returned to orchestrator — NOT committed
 </success_criteria>

package/commands/ms/add-phase.md

@@ -197,10 +197,9 @@ After the "Next Up" section, add:
 </step>
 
 <step name="update_last_command">
-Update `.planning/STATE.md` Last Command field:
-- Find line starting with `Last Command:` in Current Position section
-- Replace with: `Last Command: ms:add-phase $ARGUMENTS | YYYY-MM-DD HH:MM`
-- If line doesn't exist, add it after `Status:` line
+```bash
+ms-tools set-last-command "ms:add-phase $ARGUMENTS"
+```
 </step>
 
 </process>

package/commands/ms/add-todo.md

@@ -190,10 +190,9 @@ Would you like to:
 </step>
 
 <step name="update_last_command">
-Update `.planning/STATE.md` Last Command field:
-- Find line starting with `Last Command:` in Current Position section
-- Replace with: `Last Command: ms:add-todo $ARGUMENTS | YYYY-MM-DD HH:MM`
-- If line doesn't exist, add it after `Status:` line
+```bash
+ms-tools set-last-command "ms:add-todo $ARGUMENTS"
+```
 </step>
 
 </process>

package/commands/ms/adhoc.md

@@ -79,10 +79,9 @@ Report what was done, show commit hash, file paths, and patch file path.
 </step>
 
 <step name="update_last_command">
-Update `.planning/STATE.md` Last Command field:
-- Find line starting with `Last Command:` in Current Position section
-- Replace with: `Last Command: ms:adhoc $ARGUMENTS | YYYY-MM-DD HH:MM`
-- If line doesn't exist, add it after `Status:` line
+```bash
+ms-tools set-last-command "ms:adhoc $ARGUMENTS"
+```
 </step>
 
 </process>

package/commands/ms/audit-milestone.md

@@ -199,7 +199,8 @@ Report: "Milestone code review skipped (config: skip)"
 Proceed to next steps.
 
 **If CODE_REVIEW = empty/null:**
-Use default: `CODE_REVIEW="ms-flutter-reviewer"`
+Report: "No milestone reviewer configured. Run `/ms:config` to set one."
+Skip code review step (proceed to next steps).
 
 ### Step 8.1: Get Changed Files
 
@@ -223,7 +224,7 @@ AGENT_MODE=$(grep -A10 '^---' ~/.claude/agents/${CODE_REVIEW}.md | grep 'mode:'
 
 ### Path A: Analysis-Only Reviewers (mode: analyze-only)
 
-For agents with `mode: analyze-only` (e.g., `ms-flutter-reviewer`):
+For agents with `mode: analyze-only` (e.g., a report-only reviewer):
 
 **A1. Spawn reviewer with read-only tools:**
 
@@ -341,7 +342,7 @@ Findings are already tracked in `.planning/TECH-DEBT.md` via Step 8.5. Continue
 
 ### Path B: Simplifier Agents (default)
 
-For agents without `mode: analyze-only` (e.g., `ms-code-simplifier`, `ms-flutter-code-quality`):
+For agents without `mode: analyze-only` (e.g., `ms-code-simplifier`):
 
 **B1. Spawn code review agent:**
 

package/commands/ms/complete-milestone.md

@@ -71,6 +71,7 @@ Output: Milestone archived (roadmap + requirements), PROJECT.md evolved.
 1. **Verify readiness and gather stats:**
 
    ```bash
+   # ms-tools is on PATH — invoke directly, not as a script path
    ms-tools gather-milestone-stats $PHASE_START $PHASE_END
    ```
 
@@ -130,8 +131,7 @@ Output: Milestone archived (roadmap + requirements), PROJECT.md evolved.
 11. **Offer next steps:**
     - `/ms:new-milestone` — discover goals and update PROJECT.md
 
-12. **Update last command:**
-    - Format: `Last Command: ms:complete-milestone $ARGUMENTS | YYYY-MM-DD HH:MM`
+12. **Update last command:** `ms-tools set-last-command "ms:complete-milestone $ARGUMENTS"`
 
 </process>
 

package/commands/ms/config.md

@@ -1,6 +1,6 @@
 ---
 name: ms:config
-description: Configure Mindsystem preferences — code reviewers, gitignore, git remote
+description: Configure Mindsystem preferences — code reviewers, mockups, gitignore, git remote
 allowed-tools:
   - Read
   - Write
@@ -12,7 +12,7 @@ allowed-tools:
 
 Configure Mindsystem preferences for the current project.
 
-Manages code reviewer agents, .gitignore patterns for `.planning/` artifacts, and git remote setup. Run anytime to reconfigure — idempotent.
+Manages code reviewer agents, mockup preferences, .gitignore patterns for `.planning/` artifacts, and git remote setup. Run anytime to reconfigure — idempotent.
 
 </objective>
 
@@ -67,18 +67,13 @@ If "Create with gh CLI":
 
 Show current code_review values from config.json (if loaded).
 
-**If PROJECT.md or STACK.md exists:** Detect tech stack and suggest appropriate reviewers:
-
-- **Flutter/Dart:** adhoc=`ms-flutter-code-quality`, phase=`ms-flutter-code-quality`, milestone=`ms-flutter-reviewer`
-- **All others:** adhoc=`ms-code-simplifier`, phase=`ms-code-simplifier`, milestone=null
-
-**If no PROJECT.md or STACK.md:** Warn: "No PROJECT.md found — can't suggest reviewers based on tech stack. Run `/ms:new-project` first, or pick manually."
+**Default reviewers:** adhoc=`ms-code-simplifier`, phase=`ms-code-simplifier`, milestone=null
 
 Use AskUserQuestion:
 - header: "Code review"
 - question: "Which code reviewer configuration do you want?"
 - options:
-  - "[Suggested based on stack]" — e.g., "Flutter reviewers (ms-flutter-code-quality)" (Recommended)
+  - "Default (ms-code-simplifier)" — Generic reviewer for adhoc and phase tiers (Recommended)
   - "Skip code review" — Disable review for all tiers
   - "Custom" — I'll specify reviewers manually
 
@@ -113,6 +108,36 @@ If no selections: skip gitignore changes.
 
 </step>
 
+<step name="mockup_preferences">
+
+Read current value:
+
+```bash
+CURRENT=$(cat .planning/config.json 2>/dev/null | jq -r '.open_mockups // "auto"')
+echo "Current open_mockups: $CURRENT"
+```
+
+Use AskUserQuestion:
+- header: "Mockups"
+- question: "How should mockup comparisons open after generation?"
+- options:
+  - "Auto-open (Recommended)" — Open comparison.html in browser automatically
+  - "Ask first" — Prompt before opening
+  - "Don't open" — Display path only, never auto-open
+
+Map selection to config value:
+- "Auto-open" → `"auto"`
+- "Ask first" → `"ask"`
+- "Don't open" → `"off"`
+
+Update config.json with selected value via jq:
+
+```bash
+jq --arg v "$VALUE" '.open_mockups = $v' .planning/config.json > .planning/config.tmp && mv .planning/config.tmp .planning/config.json
+```
+
+</step>
+
 <step name="validation_summary">
 
 Show final config state:
@@ -121,6 +146,7 @@ Show final config state:
 Configuration updated:
 
 - Code reviewers: [adhoc / phase / milestone values]
+- Mockup open: [auto / ask / off]
 - Gitignore: [patterns added, or "no changes"]
 - Git remote: [remote URL, or "none configured"]
 ```
@@ -198,5 +224,6 @@ Present next steps:
 - [ ] Git remote offered (if missing)
 - [ ] Validation summary displayed
 - [ ] Config.json code_review values set (or preserved if skipped)
+- [ ] Config.json open_mockups value set (or preserved if skipped)
 
 </success_criteria>

package/commands/ms/create-roadmap.md

@@ -323,10 +323,9 @@ Requirements and roadmap created:
 </step>
 
 <step name="update_last_command">
-Update `.planning/STATE.md` Last Command field:
-- Find line starting with `Last Command:` in Current Position section
-- Replace with: `Last Command: ms:create-roadmap | YYYY-MM-DD HH:MM`
-- If line doesn't exist, add it after `Status:` line
+```bash
+ms-tools set-last-command "ms:create-roadmap"
+```
 </step>
 
 </process>

package/commands/ms/debug.md

@@ -140,10 +140,9 @@ Task(
 
 ## 6. Update Last Command
 
-Update `.planning/STATE.md` Last Command field:
-- Find line starting with `Last Command:` in Current Position section
-- Replace with: `Last Command: ms:debug $ARGUMENTS | YYYY-MM-DD HH:MM`
-- If line doesn't exist, add it after `Status:` line
+```bash
+ms-tools set-last-command "ms:debug $ARGUMENTS"
+```
 
 </process>