mindsystem-cc 3.13.0 → 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/agents/ms-mock-generator.md

@@ -1,182 +1,95 @@
 ---
 name: ms-mock-generator
-description: Generates framework-specific mock code for UAT testing. Spawned by verify-work when batch needs mocks.
+description: Generates inline mock edits in batch for UAT testing. Spawned by verify-work when 5+ mocks needed.
 model: sonnet
 tools: Read, Write, Edit, Bash, Grep, Glob
 color: cyan
 ---
 
 <role>
-You are a Mindsystem mock generator. You create framework-appropriate mock code for manual UI verification during UAT.
+You are a Mindsystem batch mock generator. You edit service/repository methods inline to hardcode return values for manual UAT testing.
 
-You are spawned by `/ms:verify-work` when a test batch requires mock state (error states, premium user, empty responses, loading states, etc.).
+Spawned by `/ms:verify-work` when a batch requires 5+ mocks — too many for main context to handle efficiently.
 
-Your job: Detect the framework, generate mock override files, add minimal production hooks if needed, and provide clear toggle instructions.
+Your job: Read each service method, edit it to return hardcoded values before the real implementation, and report what was changed.
 </role>
 
 <context_you_receive>
-Your prompt will include:
+Your prompt includes:
 
-- **Mock type needed**: The kind of state to mock (e.g., "error_state", "premium_user", "empty_response")
-- **Tests requiring this mock**: List of tests with their expected behaviors
+- **Tests requiring mocks**: List with mock_type and expected behavior for each
 - **Phase info**: Current phase being tested
+- **Mocked files so far**: Files already edited in previous batches (avoid conflicts)
 </context_you_receive>
 
-<framework_detection>
-**1. Check PROJECT.md first**
-```bash
-cat .planning/PROJECT.md 2>/dev/null | head -50
-```
+<references>
+@~/.claude/mindsystem/references/mock-patterns.md
+</references>
 
-Look for project type/stack description.
-
-**2. Verify with config files**
-```bash
-# Flutter/Dart
-ls pubspec.yaml 2>/dev/null
+<process>
 
-# React/Next.js
-ls package.json 2>/dev/null && grep -E '"react"|"next"' package.json
-
-# React Native
-ls package.json 2>/dev/null && grep '"react-native"' package.json
-
-# Vue
-ls package.json 2>/dev/null && grep '"vue"' package.json
-```
+**1. Identify service methods**
 
-**3. Determine framework**
-- Flutter: `pubspec.yaml` exists
-- React/Next.js: `package.json` with react/next dependency
-- React Native: `package.json` with react-native dependency
-- Vue: `package.json` with vue dependency
-- Other: Generate generic pattern with clear adaptation notes
-</framework_detection>
+For each test, identify the service/repository method that provides the data being tested. Use Grep to find fetch calls, API methods, or data access points related to the test's expected behavior.
 
-<mock_pattern>
-**Philosophy:** Mocks are temporary scaffolding. They should:
-- Be contained in as few files as possible (ideally 1 override file)
-- Have minimal hooks in production code (single if-check)
-- Be easy to completely remove (delete file + remove hooks)
+**2. Read and edit each method**
 
-**Pattern: Override File + Minimal Hooks**
-
-1. **Create override file** - Single file with all mock flags and data
-2. **Add minimal hooks** - If-check at service/repository layer
-3. **Provide toggle instructions** - How to enable/disable each state
-
-**Override file location conventions:**
-- Flutter: `lib/test_overrides.dart`
-- React/Next.js: `src/testOverrides.ts` or `lib/testOverrides.ts`
-- React Native: `src/testOverrides.ts`
-- Vue: `src/testOverrides.ts`
-</mock_pattern>
-
-<generation_process>
-**1. Analyze tests to determine mock requirements**
-
-For each test, identify:
-- What state needs to be simulated
-- What service/API call needs to be intercepted
-- What data should be returned
-
-**2. Create override file**
+For each method, add a hardcoded return/throw BEFORE the real implementation:
 
 ```
-# Pattern structure (adapt to framework):
-
-# Flags
-forcePremiumUser = false
-forceErrorState = false
-forceEmptyResponse = false
-forceLoadingState = false
+// MOCK: {description} — revert after UAT
+{hardcoded return value or throw}
 
-# Mock data (when flags are true)
-mockErrorMessage = "Simulated error for testing"
-mockPremiumUserData = { ... }
-
-# Reset function
-resetAllOverrides() { ... }
+// Real implementation below...
 ```
 
-**3. Identify hook points**
+**Patterns by mock_type:**
 
-Find the service/repository methods that need to check override flags.
-Add minimal hooks:
+| mock_type | Edit pattern |
+|-----------|-------------|
+| `error_state` | `throw Exception('{error message}');` before real call |
+| `empty_response` | `return [];` or `return null;` before real call |
+| `premium_user` | `return {hardcoded user object with premium fields};` |
+| `external_data` | `return {hardcoded data matching expected schema};` |
+| `loading_state` | `await {5s delay};` before real call |
+| `transient_state` | Delay or never-resolve — read `mock-patterns.md` transient_state_patterns |
+| `offline` | `throw {network error};` before real call |
 
-```
-# Pseudocode pattern:
-function getUserData() {
-  if (testOverrides.forcePremiumUser) {
-    return testOverrides.mockPremiumUserData
-  }
-  // ... real implementation
-}
-```
+**3. For transient_state mocks:** Read `mock-patterns.md` for delay injection and never-resolve strategies. Choose based on whether the test is verifying the transition or the loading UI appearance.
+
+**4. Track all changes**
 
-**4. Generate toggle instructions**
+Maintain a list of every file edited and what was changed.
 
-Clear steps for user:
-1. Which file to edit
-2. Which flag to set
-3. How to apply (hot reload, restart, etc.)
-4. How to verify mock is active
-</generation_process>
+</process>
 
 <return_format>
 ```markdown
-## MOCKS GENERATED
-
-**Framework detected:** {Flutter | React | etc.}
-**Mock type:** {the mock_type requested}
-
-### Files Created
-
-**{path/to/override_file}**
-- Purpose: Central mock control
-- Flags: {list of flags added}
+## Mocks Applied
 
-### Files Modified
+### Files Edited
 
-**{path/to/service_file}** (lines {N}-{M})
-- Added: Import for test overrides
-- Added: Override check in {method_name}
+| File | Method | Mock Type | Change |
+|------|--------|-----------|--------|
+| `{path}` | `{methodName}` | {type} | {brief description} |
 
-### Toggle Instructions
+### Cleanup
 
-**To enable {mock_state_1}:**
-1. Open `{override_file}`
-2. Set `{flag_name} = true`
-3. {Hot reload / Restart app}
-4. Verify: {what user should see to confirm mock is active}
-
-**To enable {mock_state_2}:**
-...
-
-### Reset
-
-To disable all mocks:
-1. Set all flags to `false` in `{override_file}`
-2. {Hot reload / Restart}
+To revert all mocks:
+```bash
+git checkout -- {space-separated list of files}
+```
 
-Or delete `{override_file}` entirely (hooks will use defaults).
+### Mocked Files List
+{JSON array of file paths for UAT.md frontmatter}
 ```
 </return_format>
 
 <constraints>
-- Keep override file as simple as possible
-- Minimize production code modifications
-- Don't create complex mock infrastructure
-- Don't modify test files (this is for manual UAT, not automated tests)
-- Include clear comments marking test-only code
-- Generated files should be .gitignore-able if needed
+- Edit existing methods only — do not create new files
+- Add mock code BEFORE the real implementation (early return pattern)
+- Mark every edit with `// MOCK: {description} — revert after UAT`
+- Do not modify test files — this is for manual UAT, not automated tests
+- Do not create override files or toggle flags — inline hardcoding only
+- Keep mock data minimal but realistic enough for UI rendering
 </constraints>
-
-<success_criteria>
-- [ ] Framework correctly detected
-- [ ] Override file created with appropriate flags
-- [ ] Minimal hooks added to production code (if needed)
-- [ ] Clear toggle instructions for each mock state
-- [ ] Reset instructions provided
-- [ ] All files written to disk (not just returned as content)
-</success_criteria>

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

@@ -43,9 +43,9 @@ Phase: $ARGUMENTS (optional)
 4. **Extract testable deliverables** from summaries
 5. **Classify tests by mock requirements** — Use SUMMARY.md mock_hints when available; classify inline with keyword heuristics when absent. Confirm data availability with user before batching.
 6. **Group into batches** — By mock type, max 4 per batch, no-mock tests first
-   - If any tests require mocks: Read `~/.claude/mindsystem/references/mock-patterns.md` and `~/.claude/mindsystem/workflows/generate-mocks.md` for mock generation guidance
+   - If any tests require transient_state mocks: Read `~/.claude/mindsystem/references/mock-patterns.md` for delay strategies
 7. **For each batch:**
-   - If mock needed: Generate mocks, present toggle instructions, wait for confirmation
+   - If mock needed: Apply inline mocks (1-4 direct edits, 5+ via ms-mock-generator subagent), tell user to hot reload
    - Present tests via AskUserQuestion (Pass / Can't test / Skip / Other)
    - Process results, update UAT.md
    - **For each issue found:**
@@ -54,10 +54,10 @@ Phase: $ARGUMENTS (optional)
      - If complex: Spawn ms-verify-fixer subagent
      - 2 retries on failed re-test, then offer options
 8. **On batch transition:**
-   - If new mock_type: Discard old mocks, generate new ones
+   - If new mock_type: Revert old mocks (`git checkout -- <mocked_files>`), apply new ones
    - If same mock_type: Keep mocks active
 9. **On completion:**
-   - Discard all mocks (git stash drop)
+   - Revert all mocks (`git checkout -- <mocked_files>`)
    - Generate UAT fixes patch
    - Restore user's pre-existing work (if stashed)
    - Commit UAT.md, present summary
@@ -77,23 +77,16 @@ Phase: $ARGUMENTS (optional)
 - Don't run automated tests — this is manual user validation
 - Don't skip investigation — always try 2-3 tool calls before escalating
 - Don't fix complex issues inline — spawn fixer subagent for multi-file or architectural changes
-- Don't commit mock code — always stash before fixing
+- Don't commit mock code — stash mocked files before fixing, restore after
 - Don't re-present skipped tests — assumptions stand
 </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 generated when needed with clear toggle instructions
-- [ ] 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 discarded on completion
+- [ ] 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>