mindsystem-cc 3.10.1 → 3.12.0

package/commands/ms/new-project.md

@@ -215,46 +215,9 @@ Do not compress. Capture everything gathered.
 
 </step>
 
-<step name="workflow_preferences">
-
-Ask workflow preferences in a single AskUserQuestion call (2 questions):
-
-Use AskUserQuestion with questions array:
-
-```
-questions: [
-  {
-    header: "Depth",
-    question: "How thorough should planning be?",
-    multiSelect: false,
-    options: [
-      { label: "Quick", description: "Ship fast (3-5 phases, 1-3 plans each)" },
-      { label: "Standard (Recommended)", description: "Balanced scope and speed (5-8 phases, 3-5 plans each)" },
-      { label: "Comprehensive", description: "Thorough coverage (8-12 phases, 5-10 plans each)" }
-    ]
-  },
-  {
-    header: "Execution",
-    question: "Run plans in parallel?",
-    multiSelect: false,
-    options: [
-      { label: "Parallel (Recommended)", description: "Independent plans run simultaneously" },
-      { label: "Sequential", description: "One plan at a time" }
-    ]
-  }
-]
-```
-
-**Notes:**
-- Depth controls compression tolerance, not artificial inflation
-- Parallelization spawns multiple agents for independent plans
-- All settings can be changed later in config.json
-
-</step>
-
 <step name="config">
 
-Create `.planning/config.json` with chosen depth, parallelization, and subsystems using `templates/config.json` structure.
+Create `.planning/config.json` with subsystems and code_review using `templates/config.json` structure.
 
 **Subsystems:** Derive 5-10 initial subsystems from the project context gathered during questioning. These are short, lowercase identifiers for the major functional areas of the project.
 
@@ -263,7 +226,7 @@ Examples by project type:
 - SaaS: `["auth", "dashboard", "analytics", "billing", "notifications", "ui", "api", "database"]`
 - Mobile app: `["auth", "onboarding", "feed", "messaging", "profile", "media", "api", "storage"]`
 
-Place `subsystems` array as the first field in config.json (before `depth`). These values are used throughout the system for consistent categorization of summaries, debug docs, and adhoc work.
+These values are used throughout the system for consistent categorization of summaries, debug docs, and adhoc work.
 
 </step>
 
@@ -340,7 +303,7 @@ Update `.planning/STATE.md` Last Command field (if STATE.md exists):
 - [ ] PROJECT.md captures full context with evolutionary structure
 - [ ] Requirements initialized as hypotheses (greenfield) or with inferred Validated (brownfield)
 - [ ] Key Decisions table initialized
-- [ ] config.json has depth and parallelization settings
+- [ ] config.json has subsystems and code_review settings
 - [ ] All committed to git
 
 </success_criteria>

package/commands/ms/review-design.md

@@ -117,12 +117,9 @@ ls .planning/phases/${PHASE_ARG}-*/*-DESIGN.md 2>/dev/null
 
 ### Step 2.3: Optional Context
 
-**implement-ui skill (if exists):**
-```bash
-ls .claude/skills/*implement-ui* 2>/dev/null
-```
+**Project UI skill (if exists):**
 
-If exists, load as authoritative source for existing patterns.
+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 use as authoritative source for existing patterns.
 
 **Codebase analysis:**
 - Detect platform (Flutter, React, etc.)
@@ -192,7 +189,7 @@ Apply quality-forcing patterns from `ai-driven-ui-design-system.md`:
 
 ### 3.5: Pattern Alignment
 
-If implement-ui skill or codebase patterns exist:
+If project UI skill or codebase patterns exist:
 - Check for consistent color usage
 - Check for consistent component patterns
 - Check for consistent spacing scale
@@ -478,7 +475,7 @@ Apply these patterns throughout the review:
 
 <success_criteria>
 - [ ] Target code scope clarified (via arguments or AskUserQuestion)
-- [ ] Context chain loaded (PROJECT.md, DESIGN.md if exists, implement-ui skill)
+- [ ] Context chain loaded (PROJECT.md, DESIGN.md if exists, project UI skill)
 - [ ] Code analyzed across all quality dimensions
 - [ ] Retroactive DESIGN.md created if missing
 - [ ] Improvements presented with benefits AND trade-offs

package/commands/ms/verify-work.md

@@ -41,7 +41,7 @@ Phase: $ARGUMENTS (optional)
 2. **Check for active UAT sessions** — Resume or start new
 3. **Find SUMMARY.md files** for the phase
 4. **Extract testable deliverables** from summaries
-5. **Classify tests by mock requirements** — Infer mock_type from test descriptions
+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
 7. **For each batch:**

package/mindsystem/references/design-directions.md

@@ -93,7 +93,7 @@ Rule: If you can only tell variants apart by squinting at colors, they are not d
 
 <existing_aesthetic_constraint>
 
-When the project has an existing visual aesthetic (implement-ui skill, established codebase patterns):
+When the project has an existing visual aesthetic (project UI skill, established codebase patterns):
 
 **ALL variants use the same colors, fonts, and component shapes.** Directions differ ONLY in:
 - Layout and spatial organization

package/mindsystem/references/mock-patterns.md

@@ -16,6 +16,47 @@ Without mocks, testing "error message display" requires actually triggering serv
 4. **Removable** — Delete file + remove imports = clean
 </philosophy>
 
+<classification_framework>
+
+**Two-question framework for mock classification:**
+
+For each test, ask two questions in order:
+
+1. **Is the observable state transient?**
+   - Does it appear briefly during async operations? (loading skeleton, spinner, transition animation)
+   - Does it require precise timing to observe? (appears for <1s before real data loads)
+   - If YES → `mock_type: "transient_state"` — needs delay/force mock strategy
+
+2. **Does the test depend on external data?**
+   - Does the feature fetch from an API, database, or external service?
+   - Would the test fail without specific data existing locally?
+   - If YES → `mock_type: "external_data"` — confirm data availability with user first
+
+**Two-tier classification priority:**
+
+| Priority | Source | When used |
+|----------|--------|-----------|
+| 1 | SUMMARY.md `mock_hints` | Executor captured hints at build time (including `none` for explicit no-mock) |
+| 2 | Inline classification + keyword heuristics | No `mock_hints` key (legacy summaries) — classify in main context using two-question framework + keywords |
+
+**Why keyword matching alone fails:**
+
+Domain terms don't map reliably to mock types. "View recipe list" needs external_data mocks but contains no keywords. "Loading skeleton" is transient_state but keyword matching might miss the underlying async dependency. The two-question framework traces UI elements to their data sources instead of pattern-matching descriptions.
+
+**Category examples:**
+
+| Test | Classification | Reasoning |
+|------|---------------|-----------|
+| "Recipe list loading skeleton" | transient_state | Brief UI state during async fetch — resolves in <1s |
+| "View recipe list" | external_data | Fetches from /api/recipes — data may not exist locally |
+| "Login error message" | error_state | Error response from auth endpoint |
+| "Empty favorites placeholder" | empty_response | Requires zero items in collection |
+| "Premium badge display" | premium_user | Requires premium subscription state |
+| "Offline sync indicator" | offline_state | Requires network disconnection |
+| "Tap login button" | no mock needed | Happy path with available test credentials |
+
+</classification_framework>
+
 <git_stash_lifecycle>
 
 **Why stash?**
@@ -95,10 +136,12 @@ class TestOverrides {
   static bool forceErrorState = false;
   static bool forceEmptyResponse = false;
   static bool forceLoadingState = false;
+  static bool forceTransientState = false;
 
   // === MOCK DATA ===
   static String mockErrorMessage = 'Simulated error for testing';
   static Duration mockLoadingDelay = const Duration(seconds: 3);
+  static Duration mockTransientDelay = const Duration(seconds: 5);
 
   static Map<String, dynamic> mockPremiumUser = {
     'id': 'test-user-001',
@@ -113,6 +156,7 @@ class TestOverrides {
     forceErrorState = false;
     forceEmptyResponse = false;
     forceLoadingState = false;
+    forceTransientState = false;
   }
 }
 ```
@@ -142,6 +186,10 @@ class UserService {
     if (TestOverrides.forceErrorState) {
       throw Exception(TestOverrides.mockErrorMessage);
     }
+    // TEST OVERRIDE - Extend transient state (loading skeleton stays visible)
+    if (TestOverrides.forceTransientState) {
+      await Future.delayed(TestOverrides.mockTransientDelay);
+    }
 
     // Real implementation
     final response = await _api.get('/items');

package/mindsystem/references/plan-format.md

@@ -21,7 +21,6 @@ type: execute
 wave: N                     # Execution wave (1, 2, 3...). Pre-computed at plan time.
 depends_on: []              # Plan IDs this plan requires (e.g., ["01-01"])
 files_modified: []          # Files this plan modifies
-autonomous: true            # false if plan has checkpoints
 ---
 ```
 
@@ -33,12 +32,9 @@ autonomous: true            # false if plan has checkpoints
 | `wave` | Yes | Execution wave number (1, 2, 3...). Pre-computed during planning. |
 | `depends_on` | Yes | Array of plan IDs this plan requires. |
 | `files_modified` | Yes | Files this plan touches. |
-| `autonomous` | Yes | `true` if no checkpoints, `false` if has checkpoints |
 | `subsystem_hint` | No | Subsystem from config.json, assigned by planner for executor to use in SUMMARY.md |
 
 **Wave is pre-computed:** `/ms:plan-phase` assigns wave numbers based on `depends_on`. `/ms:execute-phase` reads `wave` directly from frontmatter and groups plans by wave number. No runtime dependency analysis needed.
-
-**Checkpoint handling:** Plans with `autonomous: false` require user interaction. They run in their assigned wave but pause at checkpoints.
 </frontmatter>
 
 <prompt_structure>
@@ -52,7 +48,6 @@ type: execute
 wave: N
 depends_on: []
 files_modified: [path/to/file.ts]
-autonomous: true
 ---
 
 <objective>
@@ -64,8 +59,6 @@ Output: [...]
 <execution_context>
 @~/.claude/mindsystem/workflows/execute-plan.md
 @~/.claude/mindsystem/templates/summary.md
-[If checkpoints exist:]
-@~/.claude/mindsystem/references/checkpoints.md
 </execution_context>
 
 <context>
@@ -86,21 +79,6 @@ Output: [...]
   <done>[criteria]</done>
 </task>
 
-<task type="checkpoint:human-verify" gate="blocking">
-  <what-built>[what Claude automated]</what-built>
-  <how-to-verify>[numbered verification steps]</how-to-verify>
-  <resume-signal>[how to continue - "approved" or describe issues]</resume-signal>
-</task>
-
-<task type="checkpoint:decision" gate="blocking">
-  <decision>[what needs deciding]</decision>
-  <context>[why this matters]</context>
-  <options>
-    <option id="option-a"><name>[Name]</name><pros>[pros]</pros><cons>[cons]</cons></option>
-    <option id="option-b"><name>[Name]</name><pros>[pros]</pros><cons>[cons]</cons></option>
-  </options>
-  <resume-signal>[how to indicate choice]</resume-signal>
-</task>
 </tasks>
 
 <verification>
@@ -186,114 +164,9 @@ Tasks have a `type` attribute that determines how they execute:
 Use for: Everything Claude can do independently (code, tests, builds, file operations).
 </type>
 
-<type name="checkpoint:human-action">
-**RARELY USED** - Only for actions with NO CLI/API. Claude automates everything possible first.
-
-**Structure:**
-
-```xml
-<task type="checkpoint:human-action" gate="blocking">
-  <action>[Unavoidable manual step - email link, 2FA code]</action>
-  <instructions>
-    [What Claude already automated]
-    [The ONE thing requiring human action]
-  </instructions>
-  <verification>[What Claude can check afterward]</verification>
-  <resume-signal>[How to continue]</resume-signal>
-</task>
-```
-
-Use ONLY for: Email verification links, SMS 2FA codes, manual approvals with no API, 3D Secure payment flows.
-
-Do NOT use for: Anything with a CLI (Vercel, Stripe, Upstash, Railway, GitHub), builds, tests, file creation, deployments.
-
-**Execution:** Claude automates everything with CLI/API, stops only for truly unavoidable manual steps.
-</type>
-
-<type name="checkpoint:human-verify">
-**Human must verify Claude's work** - Visual checks, UX testing.
-
-**Structure:**
-
-```xml
-<task type="checkpoint:human-verify" gate="blocking">
-  <what-built>Responsive dashboard layout</what-built>
-  <how-to-verify>
-    1. Run: npm run dev
-    2. Visit: http://localhost:3000/dashboard
-    3. Desktop (>1024px): Verify sidebar left, content right
-    4. Tablet (768px): Verify sidebar collapses to hamburger
-    5. Mobile (375px): Verify single column, bottom nav
-    6. Check: No layout shift, no horizontal scroll
-  </how-to-verify>
-  <resume-signal>Type "approved" or describe issues</resume-signal>
-</task>
-```
-
-Use for: UI/UX verification, visual design checks, animation smoothness, accessibility testing.
-
-**Execution:** Claude builds the feature, stops, provides testing instructions, waits for approval/feedback.
-</type>
-
-<type name="checkpoint:decision">
-**Human must make implementation choice** - Direction-setting decisions.
-
-**Structure:**
-
-```xml
-<task type="checkpoint:decision" gate="blocking">
-  <decision>Select authentication provider</decision>
-  <context>We need user authentication. Three approaches with different tradeoffs:</context>
-  <options>
-    <option id="supabase">
-      <name>Supabase Auth</name>
-      <pros>Built-in with Supabase, generous free tier</pros>
-      <cons>Less customizable UI, tied to ecosystem</cons>
-    </option>
-    <option id="clerk">
-      <name>Clerk</name>
-      <pros>Beautiful pre-built UI, best DX</pros>
-      <cons>Paid after 10k MAU</cons>
-    </option>
-    <option id="nextauth">
-      <name>NextAuth.js</name>
-      <pros>Free, self-hosted, maximum control</pros>
-      <cons>More setup, you manage security</cons>
-    </option>
-  </options>
-  <resume-signal>Select: supabase, clerk, or nextauth</resume-signal>
-</task>
-```
-
-Use for: Technology selection, architecture decisions, design choices, feature prioritization.
-
-**Execution:** Claude presents options with balanced pros/cons, waits for decision, proceeds with chosen direction.
-</type>
-
-**When to use checkpoints:**
-
-- Visual/UX verification (after Claude builds) → `checkpoint:human-verify`
-- Implementation direction choice → `checkpoint:decision`
-- Truly unavoidable manual actions (email links, 2FA) → `checkpoint:human-action` (rare)
-
-**When NOT to use checkpoints:**
-
-- Anything with CLI/API (Claude automates it) → `type="auto"`
-- Deployments (Vercel, Railway, Fly) → `type="auto"` with CLI
-- Creating resources (Upstash, Stripe, GitHub) → `type="auto"` with CLI/API
-- File operations, tests, builds → `type="auto"`
-
-**Golden rule:** If Claude CAN automate it, Claude MUST automate it.
-
-**Checkpoint impact on parallelization:**
-- Plans with checkpoints set `autonomous: false` in frontmatter
-- Non-autonomous plans execute after parallel wave or in main context
-- Subagent pauses at checkpoint, returns to orchestrator
-- Orchestrator presents checkpoint to user
-- User responds
-- Orchestrator resumes agent with `resume: agent_id`
+**Golden rule:** If Claude CAN automate it, Claude MUST automate it. All tasks use `type="auto"`.
 
-See `./checkpoints.md` for comprehensive checkpoint guidance.
+**Decisions:** Resolve during planning via AskUserQuestion, not during execution. For purely technical choices, make the decision and document it in the plan's objective.
 </task_types>
 
 <tdd_plans>

package/mindsystem/references/scope-estimation.md

@@ -65,7 +65,7 @@ See `~/.claude/mindsystem/references/tdd.md` for TDD plan structure.
 - **More than 3 tasks** - Even if tasks seem small
 - **Multiple subsystems** - DB + API + UI = separate plans
 - **Any task with >5 file modifications** - Split by file groups
-- **Checkpoint + implementation work** - Checkpoints in one plan, implementation after in separate plan
+- **Discovery + verification in separate plans** - Don't mix exploratory and implementation work
 - **Discovery + implementation** - DISCOVERY.md in one plan, implementation in another
 </always_split>
 
@@ -114,12 +114,12 @@ Plan 03: Visualization components
 # Independent plan (Wave 1 candidate)
 depends_on: []
 files_modified: [src/features/user/model.ts, src/features/user/api.ts]
-autonomous: true
+
 
 # Dependent plan (later wave)
 depends_on: ["03-01"]
 files_modified: [src/integration/stripe.ts]
-autonomous: true
+
 ```
 
 **Wave assignment rules:**
@@ -204,38 +204,6 @@ Waves: [01, 02, 03] (all parallel)
 **3 tasks:** Simple ~45%, Medium ~75% (risky), Complex 120% (impossible)
 </estimating_context>
 
-<depth_calibration>
-**Depth controls compression tolerance, not artificial inflation.**
-
-| Depth | Typical Phases | Typical Plans/Phase | Tasks/Plan |
-|-------|----------------|---------------------|------------|
-| Quick | 3-5 | 1-3 | 2-3 |
-| Standard | 5-8 | 3-5 | 2-3 |
-| Comprehensive | 8-12 | 5-10 | 2-3 |
-
-Tasks/plan is CONSTANT at 2-3. The 50% context rule applies universally.
-
-**Key principle:** Derive from actual work. Depth determines how aggressively you combine things, not a target to hit.
-
-- Comprehensive auth = 8 plans (because auth genuinely has 8 concerns)
-- Comprehensive "add favicon" = 1 plan (because that's all it is)
-
-Don't pad small work to hit a number. Don't compress complex work to look efficient.
-
-**Comprehensive depth example:**
-Auth system at comprehensive depth = 8 plans (not 3 big ones):
-- 01: DB models (2 tasks)
-- 02: Password hashing (2 tasks)
-- 03: JWT generation (2 tasks)
-- 04: JWT validation middleware (2 tasks)
-- 05: Login endpoint (2 tasks)
-- 06: Register endpoint (2 tasks)
-- 07: Protected route patterns (2 tasks)
-- 08: Auth UI components (3 tasks)
-
-Each plan: fresh context, peak quality. More plans = more thoroughness, same quality per plan.
-</depth_calibration>
-
 <summary>
 **2-3 tasks, 50% context target:**
 - All tasks: Peak quality
@@ -246,7 +214,6 @@ Each plan: fresh context, peak quality. More plans = more thoroughness, same qua
 
 **The rules:**
 - If in doubt, split. Quality over consolidation.
-- Depth increases plan COUNT, never plan SIZE.
 - Vertical slices over horizontal layers.
 - Explicit dependencies via `depends_on` frontmatter.
 - Autonomous plans get parallel execution.

package/mindsystem/templates/config.json

@@ -1,18 +1,5 @@
 {
   "subsystems": [],
-  "depth": "standard",
-  "parallelization": {
-    "enabled": true,
-    "plan_level": true,
-    "task_level": false,
-    "skip_checkpoints": true,
-    "max_concurrent_agents": 3,
-    "min_plans_for_parallel": 2
-  },
-  "safety": {
-    "always_confirm_destructive": true,
-    "always_confirm_external_services": true
-  },
   "code_review": {
     "adhoc": null,
     "phase": null,

package/mindsystem/templates/design.md

@@ -13,7 +13,7 @@ Template for `.planning/phases/XX-name/{phase}-DESIGN.md` - captures visual/UX d
 
 **Designed:** [date]
 **Platform:** [web / mobile / both]
-**Aesthetic source:** [implement-ui skill / codebase analysis / fresh design]
+**Aesthetic source:** [project UI skill / codebase analysis / fresh design]
 
 ## Visual Identity