mindsystem-cc 3.13.1 → 3.14.0

package/LICENSE

@@ -1,6 +1,6 @@
 MIT License
 
-Copyright (c) 2025 Lex Christopherson
+Copyright (c) 2026 Roland Tolnay
 
 Permission is hereby granted, free of charge, to any person obtaining a copy
 of this software and associated documentation files (the "Software"), to deal

package/commands/ms/design-phase.md

@@ -109,7 +109,11 @@ If exists, extract:
 
 **3c. Optional context — project UI skill:**
 
-Before proceeding, check your available skills for one that provides domain expertise relevant to this project's UI implementation patterns. If found, invoke it via the Skill tool and extract aesthetic patterns (colors, components, spacing, typography) for the `<existing_aesthetic>` block passed to ms-designer.
+Scan the skills list in the most recent system-reminder for a skill whose description mentions UI patterns, components, design system, or implementation styling (e.g., "Flutter/Dart patterns", "React component library", "UI implementation patterns").
+
+If a matching skill is found, invoke it: `Skill(skill: "skill-name")`. Extract aesthetic patterns (colors, components, spacing, typography) from the loaded content for the `<existing_aesthetic>` block passed to ms-designer.
+
+If no matching skill is found, skip this step and note "No project UI skill found" in the `<existing_aesthetic>` block.
 
 **3d. Optional context - codebase analysis:**
 
@@ -178,7 +182,7 @@ Follow mockup-generation workflow:
 4. Present directions to user for approval/tweaking
 5. Read platform template (mobile or web)
 6. Spawn 3 x ms-mockup-designer agents in parallel
-7. Generate comparison page, open in browser, and present to user
+7. Run comparison script (`compare_mockups.py`), open in browser, and present to user
 8. Handle selection (single pick, combine, tweak, more variants, or skip)
 9. Extract CSS specs from chosen variant into `<mockup_direction>` block
 

package/commands/ms/verify-work.md

@@ -82,18 +82,11 @@ Phase: $ARGUMENTS (optional)
 </anti_patterns>
 
 <success_criteria>
-- [ ] Dirty tree handled at start (stash/commit/abort)
-- [ ] Tests extracted from SUMMARY.md and classified
-- [ ] Tests batched by mock requirements
-- [ ] Mocks applied inline when needed (1-4 direct, 5+ via subagent)
-- [ ] Tests presented in batches of 4 using AskUserQuestion
-- [ ] Issues investigated with lightweight check first
-- [ ] Simple issues fixed inline with proper commit message
-- [ ] Complex issues escalated to fixer subagent
-- [ ] Failed re-tests get 2 retries then options
-- [ ] Stash conflicts auto-resolved to fix version
-- [ ] Mocks reverted on completion (git checkout)
+- [ ] Mocks stashed before fixing, restored after (git stash push/pop cycle)
+- [ ] Stash conflicts auto-resolved to fix version (git checkout --theirs)
+- [ ] Blocked tests re-presented after blocking issues resolved
+- [ ] Failed re-tests get 2 retries then options (tracked via retry_count)
+- [ ] All mocks reverted on completion (git checkout -- <mocked_files>)
 - [ ] UAT fixes patch generated
-- [ ] User's pre-existing work restored
-- [ ] UAT.md committed with final summary
+- [ ] User's pre-existing work restored from stash
 </success_criteria>

package/mindsystem/templates/UAT.md

@@ -127,277 +127,3 @@ mock_type: empty_response
   reason: "[user-provided reason when skipping batch]"
 ```
 
----
-
-<section_rules>
-
-**Frontmatter:**
-- `status`: OVERWRITE - "testing", "fixing", or "complete"
-- `phase`: IMMUTABLE - set on creation
-- `source`: IMMUTABLE - SUMMARY files being tested
-- `started`: IMMUTABLE - set on creation
-- `updated`: OVERWRITE - update on every change
-- `current_batch`: OVERWRITE - current batch number
-- `mocked_files`: OVERWRITE - list of files with inline mocks, or empty array
-- `pre_work_stash`: OVERWRITE - user's pre-existing work stash or null
-
-**Progress:**
-- OVERWRITE after each test result or fix
-- Tracks: total, tested, passed, issues, fixing, pending, skipped
-
-**Current Batch:**
-- OVERWRITE entirely on batch transitions
-- Shows which batch is active
-
-**Tests:**
-- Each test: OVERWRITE result/fix fields when status changes
-- `result` values: [pending], pass, issue, blocked, skipped
-- If issue: add `reported` (verbatim), `severity` (inferred), `fix_status`, `fix_commit`, `retry_count`
-- If blocked: no additional fields (will be re-tested)
-- If skipped: add `reason`
-
-**Fixes Applied:**
-- APPEND only when fix committed
-- Records commit hash, test number, description, files
-
-**Batches:**
-- Each batch: OVERWRITE status and counts as batch progresses
-- Tracks: tests, status, mock_type, passed, issues
-
-**Assumptions:**
-- APPEND when test is skipped
-- Records test number, name, expected behavior, reason
-
-</section_rules>
-
-<fix_lifecycle>
-
-**When issue reported:**
-1. result → "issue"
-2. Add `reported`, `severity`
-3. Add `fix_status: investigating`, `retry_count: 0`
-
-**When fix committed:**
-4. `fix_status: applied`
-5. `fix_commit: {hash}`
-6. Append to "Fixes Applied" section
-
-**When re-test passes:**
-7. result → "pass"
-8. `fix_status: verified`
-
-**When re-test fails:**
-9. Increment `retry_count`
-10. If `retry_count >= 2`: offer skip/escalate options
-11. If user chooses skip: result → "skipped", add reason
-
-</fix_lifecycle>
-
-<mock_lifecycle>
-
-**When batch needs mocks:**
-1. Edit service methods inline (hardcoded return values)
-2. Record files in `mocked_files` frontmatter
-3. User hot reloads, testing proceeds
-
-**When fix needed:**
-1. `git stash push -m "mocks-batch-N" -- <mocked_files>`
-2. Fix applied, committed
-3. `git stash pop` to restore mocks
-4. If conflict: take fix version, remove file from `mocked_files`
-
-**On batch transition (different mock_type):**
-1. Revert old mocks: `git checkout -- <mocked_files>`
-2. Clear `mocked_files`, apply new inline mocks
-
-**On session complete:**
-1. Revert all mocks: `git checkout -- <mocked_files>`
-2. Restore pre_work_stash if exists
-
-</mock_lifecycle>
-
-<resume_behavior>
-
-On `/ms:verify-work` with existing UAT.md:
-
-1. Check `status`:
-   - "complete" → offer to re-run or view results
-   - "testing" or "fixing" → resume
-
-2. Check `mocked_files`:
-   - If non-empty, verify mocks still present via `git diff --name-only`
-   - If mocks lost, regenerate for current batch
-
-3. Check `current_batch`:
-   - Resume from that batch
-
-4. Check for tests with `fix_status: investigating` or `fix_status: applied`:
-   - Resume fix/re-test flow for those
-
-5. Present remaining tests in current batch
-
-</resume_behavior>
-
-<severity_guide>
-
-Severity is INFERRED from user's natural language, never asked.
-
-| User describes | Infer |
-|----------------|-------|
-| Crash, error, exception, fails completely, unusable | blocker |
-| Doesn't work, nothing happens, wrong behavior, missing | major |
-| Works but..., slow, weird, off, minor, small | minor |
-| Color, font, spacing, alignment, looks off | cosmetic |
-
-Default: **major** (safe default, user can clarify if wrong)
-
-</severity_guide>
-
-<good_example>
-```markdown
----
-status: fixing
-phase: 04-comments
-source: 04-01-SUMMARY.md, 04-02-SUMMARY.md
-started: 2025-01-15T10:30:00Z
-updated: 2025-01-15T11:15:00Z
-current_batch: 2
-mocked_files: [src/services/auth_service.dart, src/services/api_service.dart]
-pre_work_stash: null
----
-
-## Progress
-
-total: 12
-tested: 7
-passed: 5
-issues: 1
-fixing: 1
-pending: 5
-skipped: 0
-
-## Current Batch
-
-batch: 2 of 4
-name: "Error States"
-mock_type: error_state
-tests: [4, 5, 6, 7]
-status: testing
-
-## Tests
-
-### 1. View Comments on Post
-expected: Comments section expands, shows count and comment list
-mock_required: false
-mock_type: null
-result: pass
-
-### 2. Create Top-Level Comment
-expected: Submit comment via rich text editor, appears in list with author info
-mock_required: false
-mock_type: null
-result: pass
-
-### 3. Reply to a Comment
-expected: Click Reply, inline composer appears, submit shows nested reply
-mock_required: false
-mock_type: null
-result: pass
-
-### 4. Login Error Message
-expected: Invalid credentials show "Invalid email or password" message
-mock_required: true
-mock_type: error_state
-result: issue
-reported: "Shows 'Something went wrong' instead of specific error"
-severity: major
-fix_status: applied
-fix_commit: abc123f
-retry_count: 0
-
-### 5. Network Error Handling
-expected: No connection shows "Check your internet connection" with retry button
-mock_required: true
-mock_type: error_state
-result: [pending]
-
-### 6. Server Error Display
-expected: 500 error shows "Try again later" message
-mock_required: true
-mock_type: error_state
-result: [pending]
-
-### 7. Rate Limit Message
-expected: Too many requests shows "Too many attempts" with countdown
-mock_required: true
-mock_type: error_state
-result: [pending]
-
-### 8. Premium Badge Display
-expected: Premium users show gold badge on profile
-mock_required: true
-mock_type: premium_user
-result: [pending]
-
-### 9. Premium Feature Access
-expected: Premium features accessible, non-premium shows upgrade prompt
-mock_required: true
-mock_type: premium_user
-result: [pending]
-
-### 10. Subscription Status
-expected: Account page shows current subscription tier and expiry
-mock_required: true
-mock_type: premium_user
-result: [pending]
-
-### 11. Empty Comments List
-expected: Post with no comments shows "No comments yet" placeholder
-mock_required: true
-mock_type: empty_response
-result: [pending]
-
-### 12. Empty Search Results
-expected: Search with no matches shows "No results found" with suggestions
-mock_required: true
-mock_type: empty_response
-result: [pending]
-
-## Fixes Applied
-
-- commit: abc123f
-  test: 4
-  description: "Display actual error message from API response"
-  files: [src/components/ErrorBanner.tsx]
-
-## Batches
-
-### Batch 1: No Mocks Required
-tests: [1, 2, 3]
-status: complete
-mock_type: null
-passed: 3
-issues: 0
-
-### Batch 2: Error States
-tests: [4, 5, 6, 7]
-status: in_progress
-mock_type: error_state
-passed: 0
-issues: 1
-
-### Batch 3: Premium Features
-tests: [8, 9, 10]
-status: pending
-mock_type: premium_user
-
-### Batch 4: Empty States
-tests: [11, 12]
-status: pending
-mock_type: empty_response
-
-## Assumptions
-
-[none yet]
-```
-</good_example>

package/mindsystem/workflows/mockup-generation.md

@@ -87,7 +87,7 @@ Task(prompt=assembled_context, subagent_type="ms-mockup-designer", description="
 </step>
 
 <step name="present_mockups">
-After all 3 agents return, generate comparison page and open it:
+After all 3 agents return, run the comparison script to create the comparison page. Do NOT generate comparison HTML manually — use the script:
 
 ```bash
 uv run ~/.claude/mindsystem/scripts/compare_mockups.py "${PHASE_DIR}/mockups"

package/mindsystem/workflows/verify-work.md

@@ -8,29 +8,6 @@ Complete verify-and-fix session: by session end, everything verified, issues fix
 <!-- mock-patterns.md loaded on demand for transient_state mocks (see generate_mocks step) -->
 </execution_context>
 
-<template>
-@~/.claude/mindsystem/templates/UAT.md
-</template>
-
-<philosophy>
-**Verify and fix in one session.**
-
-Old flow: verify → log gaps → /clear → plan-phase --gaps → execute → verify again
-New flow: verify → investigate → fix → re-test → continue
-
-**Mocks enable testing unreachable states.**
-
-Error displays, premium features, empty lists — all require specific backend conditions. Mocks let you toggle states and test immediately.
-
-**Keep mocks and fixes separate.**
-
-Mocks are uncommitted scaffolding. Fixes are clean commits. Git stash keeps them separated.
-
-**Fix while context is hot.**
-
-When you find an issue, you have the mock state active, the test fresh in mind, and the user ready to re-test. Fix it now, not later.
-</philosophy>
-
 <process>
 
 <step name="check_dirty_tree" priority="first">
@@ -42,20 +19,7 @@ git status --porcelain
 
 **If output is non-empty (dirty tree):**
 
-Present options via AskUserQuestion:
-```
-questions:
-  - question: "You have uncommitted changes. How should I handle them before starting UAT?"
-    header: "Git state"
-    options:
-      - label: "Stash changes"
-        description: "git stash push -m 'pre-verify-work' — I'll restore them after UAT"
-      - label: "Commit first"
-        description: "Let me commit these changes before we start"
-      - label: "Abort"
-        description: "Cancel UAT, I'll handle my changes manually"
-    multiSelect: false
-```
+AskUserQuestion with options: Stash changes / Commit first / Abort
 
 **Handle response:**
 - "Stash changes" → `git stash push -m "pre-verify-work"`, record `pre_work_stash: "pre-verify-work"` for later
@@ -183,50 +147,14 @@ Reason over SUMMARY.md content (accomplishments, files created/modified, decisio
 | "offline", "no connection" | offline_state |
 | Normal happy path | no mock needed |
 
-For tests that remain genuinely uncertain after both the two-question framework and keyword heuristics, present them via AskUserQuestion grouped by uncertainty:
-```
-questions:
-  - question: "Does [test name] require mock data or a special app state to test?"
-    header: "Mock needed?"
-    options:
-      - label: "No mock needed"
-        description: "Can test with real/local data"
-      - label: "Needs mock"
-        description: "Requires simulated state or data"
-```
+For tests that remain genuinely uncertain after both the two-question framework and keyword heuristics, AskUserQuestion per uncertain test: No mock needed / Needs mock.
 
 **Dependency inference (both tiers):**
 - "Reply to comment" depends on "View comments"
 - "Delete account" depends on "Login"
 - Tests mentioning prior state depend on tests that create that state
 
-Build classification list:
-```yaml
-tests:
-  - name: "Login success"
-    mock_required: false
-    mock_type: null
-    dependencies: []
-
-  - name: "Login error message"
-    mock_required: true
-    mock_type: "error_state"
-    mock_reason: "error response from auth endpoint"
-    dependencies: ["login_flow"]
-
-  - name: "Recipe list loading skeleton"
-    mock_required: true
-    mock_type: "transient_state"
-    mock_reason: "loading skeleton during recipe fetch — async, resolves in <1s"
-    dependencies: []
-
-  - name: "View recipe list"
-    mock_required: true
-    mock_type: "external_data"
-    mock_reason: "recipe items from /api/recipes"
-    needs_user_confirmation: true
-    dependencies: []
-```
+Build classification list with fields: name, mock_required, mock_type, mock_reason, dependencies, needs_user_confirmation.
 </step>
 
 <step name="create_batches">
@@ -236,136 +164,24 @@ tests:
 
 **Rules:**
 1. Group by mock_type (tests needing same mock state go together)
-2. **User confirmation for external_data tests:** Before batching, collect all tests with `needs_user_confirmation: true`, grouped by data source. Present via AskUserQuestion:
-
-```
-questions:
-  - question: "Do you have [data_type] data from [source] locally?"
-    header: "[data_type]"
-    options:
-      - label: "Yes, data exists"
-        description: "I have [data_type] in my local environment"
-      - label: "No, needs mock"
-        description: "I need this data mocked for testing"
-      - label: "Skip these tests"
-        description: "Log as assumptions and move on"
-    multiSelect: false
-```
-
-Handle responses:
-- "Yes, data exists" → reclassify affected tests as `mock_required: false`
-- "No, needs mock" → keep as `mock_required: true`, `mock_type: "external_data"`
-- "Skip these tests" → mark all affected tests as `skipped`
-
-Group by data source (not per-test) to stay within AskUserQuestion's 4-question limit.
+2. **User confirmation for external_data tests:** Before batching, collect all tests with `needs_user_confirmation: true`, grouped by data source. AskUserQuestion per data source: Yes, data exists / No, needs mock / Skip these tests. Handle responses: reclassify as `mock_required: false`, keep as mock, or mark `skipped`. Group by data source (not per-test) to stay within AskUserQuestion's 4-question limit.
 
 3. **Separate transient_state batch:** Transient states use a different mock strategy (delay/force) than data mocks. Give them their own batch.
 4. Respect dependencies (if B depends on A, A must be in same or earlier batch)
 5. Max 4 tests per batch (AskUserQuestion limit)
 6. Batch ordering: no-mock → external_data → error_state → empty_response → transient_state → premium_user → offline_state
 
-**Batch structure:**
-```yaml
-batches:
-  - batch: 1
-    name: "No Mocks Required"
-    mock_type: null
-    tests: [1, 2, 3]
-
-  - batch: 2
-    name: "External Data"
-    mock_type: "external_data"
-    tests: [4, 5]
-
-  - batch: 3
-    name: "Error States"
-    mock_type: "error_state"
-    tests: [6, 7, 8]
-
-  - batch: 4
-    name: "Transient States"
-    mock_type: "transient_state"
-    tests: [9, 10]
-
-  - batch: 5
-    name: "Premium Features"
-    mock_type: "premium_user"
-    tests: [11, 12]
-```
+Each batch has: batch number, name, mock_type, and test list.
 </step>
 
 <step name="create_uat_file">
-**Create UAT file with full structure:**
+**Create UAT file:**
 
 ```bash
 mkdir -p "$PHASE_DIR"
 ```
 
-Create file at `.planning/phases/XX-name/{phase}-UAT.md`:
-
-```markdown
----
-status: testing
-phase: XX-name
-source: [list of SUMMARY.md files]
-started: [ISO timestamp]
-updated: [ISO timestamp]
-current_batch: 1
-mocked_files: []
-pre_work_stash: [from dirty tree handling, or null]
----
-
-## Progress
-
-total: [N]
-tested: 0
-passed: 0
-issues: 0
-fixing: 0
-pending: [N]
-skipped: 0
-
-## Current Batch
-
-batch: 1 of [total_batches]
-name: "[batch name]"
-mock_type: [mock_type or null]
-tests: [test numbers]
-status: pending
-
-## Tests
-
-### 1. [Test Name]
-expected: [observable behavior]
-mock_required: [true/false]
-mock_type: [type or null]
-result: [pending]
-
-### 2. [Test Name]
-...
-
-## Fixes Applied
-
-[none yet]
-
-## Batches
-
-### Batch 1: [Name]
-tests: [1, 2, 3]
-status: pending
-mock_type: null
-
-### Batch 2: [Name]
-tests: [4, 5, 6, 7]
-status: pending
-mock_type: error_state
-
-...
-
-## Assumptions
-
-[none yet]
-```
+Create file at `.planning/phases/XX-name/{phase}-UAT.md` following the template structure in context. Populate with classified tests and batch data from previous steps.
 
 Proceed to `execute_batch`.
 </step>
@@ -456,22 +272,7 @@ If user has previously indicated they want to skip mock batches, or if mock gene
 
 Collect tests for current batch (only `[pending]` and `blocked` results).
 
-Build AskUserQuestion with up to 4 questions:
-```
-questions:
-  - question: "Test {N}: {name} — {expected}"
-    header: "Test {N}"
-    options:
-      - label: "Pass"
-        description: "Works as expected"
-      - label: "Can't test"
-        description: "Blocked by a previous failure"
-      - label: "Skip"
-        description: "Assume it works (can't test this state)"
-    multiSelect: false
-```
-
-The "Other" option is auto-added for issue descriptions.
+AskUserQuestion per test (up to 4): Pass / Can't test / Skip. "Other" auto-added for issue descriptions.
 
 **Tip for users:** To skip with custom reason, select "Other" and start with `Skip:` — e.g., `Skip: Requires paid API key`.
 
@@ -680,20 +481,7 @@ Mocks are stashed — working tree is clean.
 <step name="handle_retest">
 **Handle re-test result:**
 
-Present re-test question:
-```
-questions:
-  - question: "Re-test: {test_name} — Does it work now?"
-    header: "Re-test"
-    options:
-      - label: "Pass"
-        description: "Fixed! Works correctly now"
-      - label: "Still broken"
-        description: "Same issue persists"
-      - label: "New issue"
-        description: "Original fixed but found different problem"
-    multiSelect: false
-```
+AskUserQuestion: Pass / Still broken / New issue.
 
 **If Pass:**
 - Update test: `result: pass`, `fix_status: verified`
@@ -840,6 +628,11 @@ Check if more phases remain in ROADMAP.md:
 </process>
 
 <update_rules>
+**Immutable (set on creation, never overwrite):** phase, source, started
+**Result values:** [pending], pass, issue, blocked, skipped
+**Issue adds:** reported, severity, fix_status (investigating | applied | verified), fix_commit, retry_count
+**Skipped adds:** reason
+
 **Write UAT.md after:**
 - Each batch of responses processed
 - Each fix applied
@@ -851,6 +644,7 @@ Check if more phases remain in ROADMAP.md:
 | Frontmatter.status | OVERWRITE | Phase transitions |
 | Frontmatter.current_batch | OVERWRITE | Batch transitions |
 | Frontmatter.mocked_files | OVERWRITE | Mock generation/cleanup |
+| Frontmatter.pre_work_stash | OVERWRITE | Dirty tree handling |
 | Frontmatter.updated | OVERWRITE | Every write |
 | Progress | OVERWRITE | After each test result |
 | Current Batch | OVERWRITE | Batch transitions |
@@ -879,19 +673,11 @@ Default: **major** (safe default)
 </severity_inference>
 
 <success_criteria>
-- [ ] Dirty tree handled at start
-- [ ] Tests classified by mock requirements
-- [ ] Batches created respecting dependencies and mock types
-- [ ] Mocks applied inline when needed (1-4 direct, 5+ via subagent)
-- [ ] Tests presented in batches of 4
-- [ ] Issues investigated with lightweight check (2-3 calls)
-- [ ] Simple issues fixed inline with proper commit
-- [ ] Complex issues escalated to fixer subagent
-- [ ] Re-test retries (2 max, tracked via retry_count) before offering options
+- [ ] Mocks stashed before fixing, restored after (git stash push/pop cycle)
+- [ ] Stash conflicts auto-resolved to fix version (git checkout --theirs)
 - [ ] Blocked tests re-presented after blocking issues resolved
-- [ ] Stash conflicts auto-resolved to fix version
-- [ ] Mocks reverted on completion (git checkout)
+- [ ] Failed re-tests get 2 retries then options (tracked via retry_count)
+- [ ] All mocks reverted on completion (git checkout -- <mocked_files>)
 - [ ] UAT fixes patch generated
-- [ ] User's pre-existing work restored
-- [ ] UAT.md committed with final summary
+- [ ] User's pre-existing work restored from stash
 </success_criteria>

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "mindsystem-cc",
-  "version": "3.13.1",
+  "version": "3.14.0",
   "description": "A meta-prompting, context engineering and spec-driven development system for Claude Code by TÂCHES.",
   "bin": {
     "mindsystem-cc": "bin/install.js"

package/skills/flutter-code-quality/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: flutter-code-quality
-description: Flutter/Dart code quality, widget organization, and folder structure guidelines. Use when reviewing, refactoring, or cleaning up Flutter code after implementation.
+description: Organize Flutter/Dart code to follow project conventions. Use after implementation to restructure folders, fix widget file organization, align naming patterns, or clean up code to match project standards.
 license: MIT
 metadata:
   author: Roland Tolnay

package/skills/flutter-code-simplification/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: flutter-code-simplification
-description: Flutter/Dart code simplification principles. Use when simplifying, refactoring, or cleaning up Flutter code for clarity and maintainability.
+description: Reduce complexity in Flutter/Dart code. Use when code is too nested, hard to read, or has duplication. Extracts widgets, flattens logic, removes unnecessary abstraction.
 license: MIT
 metadata:
   author: Roland Tolnay

package/skills/flutter-senior-review/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: flutter-senior-review
-description: Senior engineering principles for Flutter/Dart code reviews. Apply when reviewing, refactoring, or writing Flutter code to identify structural improvements that make code evolvable, not just working.
+description: Review Flutter/Dart code for architectural and structural design issues. Use when reviewing PRs, auditing widget design, evaluating state management, or identifying problems that make code hard to evolve.
 license: MIT
 metadata:
   author: Roland Tolnay