mindsystem-cc 3.17.1 → 3.18.1

package/mindsystem/references/scope-estimation.md

@@ -27,21 +27,23 @@ Why 50% not 80%?
 </context_target>
 
 <task_rule>
-**Each plan: 2-3 tasks maximum. Stay under 50% context.**
+**Budget-based grouping.** Classify tasks by weight, then pack plans until budget full.
 
-| Task Complexity | Tasks/Plan | Context/Task | Total |
-|-----------------|------------|--------------|-------|
-| Simple (CRUD, config) | 3 | ~10-15% | ~30-45% |
-| Complex (auth, payments) | 2-3 | ~15-25% | ~40-50% |
-| Very complex (migrations, refactors) | 1-2 | ~30-40% | ~30-50% |
+| Weight | Cost | Examples |
+|--------|------|----------|
+| Light | 5% | One-line fixes, config changes, dead code removal, renaming |
+| Medium | 10% | CRUD endpoints, widget extraction, single-file refactoring |
+| Heavy | 20% | Complex business logic, architecture changes, multi-file integrations |
 
-**Default to 3 tasks for simple-medium work, 2 for complex.** Executor overhead reduction creates headroom for the third task.
+**Grouping rule:** `sum(weights) <= 45%`. Pack tasks by feature affinity until budget full. Bias toward consolidation — fewer plans, less overhead.
+
+**Minimum plan threshold:** Plans under ~10% → consolidate with related work in the same wave. A single light task alone wastes executor overhead.
 </task_rule>
 
 <tdd_plans>
 **TDD features get their own plans. Target ~40% context.**
 
-TDD requires 2-3 execution cycles (RED → GREEN → REFACTOR), each with file reads, test runs, and potential debugging. This is fundamentally heavier than linear task execution.
+TDD requires 2-3 execution cycles (RED → GREEN → REFACTOR), each with file reads, test runs, and potential debugging. This is fundamentally heavier than linear task execution. TDD features are inherently heavy-weight (~25-40% marginal) and are always isolated into dedicated plans.
 
 | TDD Feature Complexity | Context Usage |
 |------------------------|---------------|
@@ -62,7 +64,7 @@ See `~/.claude/mindsystem/references/tdd.md` for TDD plan structure.
 <split_signals>
 
 <always_split>
-- **More than 3 tasks** - Even if tasks seem small
+- **Budget sum exceeds 45%** - Budget overflow regardless of task count
 - **Multiple subsystems** - DB + API + UI = separate plans
 - **Any task with >5 file modifications** - Split by file groups
 - **Discovery + verification in separate plans** - Don't mix exploratory and implementation work
@@ -161,13 +163,12 @@ Tasks: 8 (models, migrations, API, JWT, middleware, hashing, login form, registe
 Result: Task 1-3 good, Task 4-5 degrading, Task 6-8 rushed
 ```
 
-**Good - Atomic plans:**
+**Good - Budget-aware plans:**
 ```
-Plan 1: "Auth Database Models" (2 tasks)
-Plan 2: "Auth API Core" (3 tasks)
-Plan 3: "Auth API Protection" (2 tasks)
-Plan 4: "Auth UI Components" (2 tasks)
-Each: 30-40% context, peak quality, atomic commits
+Plan 1: "Auth Database + Config" (4L+1M = ~30%)
+Plan 2: "Auth API" (3M = ~30%)
+Plan 3: "Auth UI" (1H+1M = ~30%)
+Each: within 45% budget, peak quality, atomic commits
 ```
 
 **Bad - Horizontal layers (sequential):**
@@ -190,35 +191,21 @@ Waves: [01, 02, 03] (all parallel)
 </anti_patterns>
 
 <estimating_context>
-| Files Modified | Context Impact |
-|----------------|----------------|
-| 0-3 files | ~10-15% (small) |
-| 4-6 files | ~20-30% (medium) |
-| 7+ files | ~40%+ (large - split) |
-
-| Complexity | Context/Task |
-|------------|--------------|
-| Simple CRUD | ~15% |
-| Business logic | ~25% |
-| Complex algorithms | ~40% |
-| Domain modeling | ~35% |
-
-**2 tasks:** Simple ~30%, Medium ~50%, Complex ~80% (split)
-**3 tasks:** Simple ~45%, Medium ~75% (risky), Complex 120% (impossible)
-
-**Executor overhead:** ~2,400 tokens (down from ~6,900 in previous versions), freeing ~4,500 tokens per plan for code quality.
+Weight estimates are heuristics for the plan-writer to bias toward consolidation, not precise predictions. Actual context usage depends on model, task complexity, file sizes, and context window. Calibrate from real execution data — when plans consistently finish with headroom, pack more aggressively.
 </estimating_context>
 
 <summary>
-**2-3 tasks, 50% context target:**
+**Budget-aware consolidation, 50% context target:**
 - All tasks: Peak quality
 - Git: Atomic per-task commits
 - Parallel by default: Fresh context per subagent
 
-**The principle:** Aggressive atomicity. More plans, smaller scope, consistent quality.
+**The principle:** Fewer executors, same quality, less overhead. Bias toward consolidation.
 
 **The rules:**
-- If in doubt, split. Quality over consolidation.
+- Group by weight budget (`sum(weights) <= 45%`), not by fixed task count.
+- Consolidate plans under ~10% with related same-wave work.
+- Split when budget sum exceeds 45%.
 - Vertical slices over horizontal layers.
 - Dependencies centralized in EXECUTION-ORDER.md.
 - Autonomous plans get parallel execution.

package/mindsystem/templates/design-iteration.md

@@ -27,11 +27,11 @@ Iteration: v[N] (previous: v[N-1])
 <previous_design>
 [Include key sections from current DESIGN.md that are relevant to the changes]
 
-Visual Identity:
-[Current visual identity section]
+Design Direction:
+[Current design direction]
 
-Relevant screens/components:
-[Sections being modified]
+Relevant screens (wireframe + states + behavior + hints):
+[Screens being modified]
 </previous_design>
 
 <feedback_on_previous>
@@ -87,14 +87,14 @@ Iteration: v2 (previous: v1)
 </iteration_context>
 
 <previous_design>
-Visual Identity:
-Professional analytics dashboard with dark mode. Deep navy background (#0a0f1a) with amber accent (#F59E0B).
-
-Design System Colors:
-- Primary: #0a0f1a
-- Secondary: #1a1f2e
-- Text: #ffffff
-- Accent: #F59E0B
+Design Direction:
+Professional analytics dashboard with dark mode. Deep navy background instead of generic black, amber accent for energy.
+
+Design Tokens (relevant):
+- bg-primary: #0a0f1a
+- bg-surface: #1a1f2e
+- text-primary: #ffffff
+- accent: #F59E0B
 </previous_design>
 
 <feedback_on_previous>
@@ -139,7 +139,7 @@ Iteration: v3 (previous: v2)
 </iteration_context>
 
 <previous_design>
-Screen Layout (Kanban Board):
+Kanban Board screen (wireframe):
 +------------------------------------------+
 | [Header]                                 |
 +------------------------------------------+