mindsystem-cc 4.4.1 → 4.4.2

package/README.md

@@ -31,6 +31,7 @@ Then `/ms:new-project` to initialize. See the [full walkthrough](#end-to-end-wal
 
 ## What's new in v4.4
 
+- **Knowledge quality gate** — consolidator and compounder filter extracted knowledge through signal density enforcement, eliminating noise entries that wouldn't change how an LLM implements code.
 - **User journey browser verification** — end-to-end click/fill/submit testing instead of screenshot-only observation. Catches unreachable pages with no navigation path from the UI.
 - **Single-plan mode (default)** — one plan per phase, eliminating multi-agent orchestration overhead with 1M context windows.
 - **Full phase specification** for add-phase and insert-phase — both commands now derive goal, success criteria, and requirements mapping.

package/agents/ms-compounder.md

@@ -25,6 +25,10 @@ You are a Mindsystem knowledge compounder spawned by the compound workflow to up
 
 </inputs>
 
+<references>
+@~/.claude/mindsystem/references/knowledge-quality.md
+</references>
+
 <extraction_guide>
 
 ## What to Extract From Raw Changes
@@ -59,15 +63,19 @@ ls .planning/knowledge/*.md 2>/dev/null
 
 Read only the files matching confirmed affected subsystems. On first run, `.planning/knowledge/` may not exist — start fresh.
 
-## Step 3: Extract Knowledge From Changes
+## Step 3: Classify and Extract Knowledge From Changes
+
+Classify each change signal before extraction:
 
-Apply the extraction guide to the change content.
+| Signal Type | Action |
+|------------|--------|
+| Decision with rationale (chose X over Y because Z) | Extract |
+| Structural pattern (how components connect, data flows) | Extract |
+| Non-obvious pitfall or gotcha | Extract |
+| Code-derivable detail (schema fields, component props, config values) | Skip |
+| Implementation description without alternative considered | Skip |
 
-Focus on:
-- **Decisions with rationale** — not just "used X" but "used X because Y"
-- **Structural patterns** — how components connect, data flows, API contracts
-- **Gotchas discovered** — failure modes, workarounds, non-obvious behavior
-- **Significant file changes** — new entry points, renamed modules, deleted code
+Apply the extraction guide to change content that passes classification. Then apply the knowledge-quality.md filtering test — drop entries that fail. For entries that pass, check existing knowledge files for cross-subsystem duplication — use `(see {subsystem})` cross-references instead of duplicating.
 
 ## Step 4: Merge Into Existing Knowledge
 
@@ -81,6 +89,8 @@ For each affected subsystem, edit the knowledge file to reflect current state:
 
 Use `Edit` for existing files — targeted changes preserve content you haven't inspected. Use `Write` only for new files (subsystem has no knowledge file yet).
 
+While merging, review the touched file's existing entries through the same quality gate. Remove entries that are now code-derivable, superseded by new decisions, or duplicated in another subsystem's knowledge file. This is opportunistic maintenance during normal writes, not a full audit.
+
 ## Step 5: Update Knowledge Files and Return Report
 
 ```bash
@@ -142,4 +152,6 @@ If changes suggest a subsystem not in the confirmed list, note it as a proposal
 - [ ] Report returned with update counts
 - [ ] Empty sections omitted from knowledge files
 - [ ] Existing knowledge files read for affected subsystems only
+- [ ] Extracted entries pass the knowledge-quality.md filtering test
+- [ ] No cross-subsystem duplication (cross-references used instead)
 </success_criteria>

package/agents/ms-consolidator.md

@@ -41,6 +41,10 @@ You are a Mindsystem knowledge consolidator spawned by execute-phase after plan
 
 </inputs>
 
+<references>
+@~/.claude/mindsystem/references/knowledge-quality.md
+</references>
+
 <extraction_guide>
 
 ## What to Extract Per Artifact
@@ -68,7 +72,7 @@ You are a Mindsystem knowledge consolidator spawned by execute-phase after plan
 | DESIGN Content | Target Knowledge Section |
 |----------------|------------------------|
 | Wireframe layouts, inline annotations | Design |
-| Design tokens (colors, spacing, typography) | Design |
+| Design reasoning (why this approach, not pixel values) | Design |
 | Behavior notes, interaction patterns | Design |
 | States tables, platform hints | Design |
 
@@ -135,6 +139,8 @@ Apply the extraction guide to each artifact:
 
 Extract knowledge, not descriptions. "Using React" is not knowledge. "Using React over Vue because of ecosystem maturity and team familiarity" is knowledge.
 
+Apply the knowledge-quality.md filtering test to each extracted entry before assigning it to a subsystem. Drop entries that fail. For entries that pass, check existing knowledge files for cross-subsystem duplication — use `(see {subsystem})` cross-references instead of duplicating.
+
 ## Step 6: Merge Into Knowledge Files
 
 For each affected subsystem, edit the knowledge file to reflect current state:
@@ -147,6 +153,8 @@ For each affected subsystem, edit the knowledge file to reflect current state:
 
 Use `Edit` for existing files — targeted changes preserve content you haven't inspected. Use `Write` only for new files (subsystem has no knowledge file yet).
 
+While merging, review the touched file's existing entries through the same quality gate. Remove entries that are now code-derivable, superseded by new decisions, or duplicated in another subsystem's knowledge file. This is opportunistic maintenance during normal writes, not a full audit.
+
 ## Step 7: Update Knowledge Files
 
 ```bash
@@ -225,5 +233,7 @@ Use `+N` for new entries added, `updated` for sections rewritten with changes, `
 - [ ] Empty sections omitted from knowledge files
 - [ ] PLAN.md files deleted from phase directory
 - [ ] CONTEXT.md, DESIGN.md, RESEARCH.md, SUMMARY.md preserved
+- [ ] Extracted entries pass the knowledge-quality.md filtering test
+- [ ] No cross-subsystem duplication (cross-references used instead)
 - [ ] No commits made
 </success_criteria>

package/mindsystem/references/knowledge-quality.md

@@ -0,0 +1,89 @@
+<knowledge_quality>
+
+Shared quality gate for knowledge extraction. Referenced by ms-consolidator and ms-compounder agents.
+
+<filtering_principle>
+
+**The single test:** "Would an LLM implement this incorrectly without this entry?"
+
+If yes — the entry earns its place. If an LLM with access to the codebase would get it right anyway, the entry is noise.
+
+What passes the test:
+- Conventions that differ from LLM defaults or framework norms
+- Failed experiments and why they failed (prevents re-discovery)
+- Non-obvious bugs, gotchas, or workarounds
+- Decisions where the alternative was reasonable (the "because" matters)
+- Cross-cutting patterns not visible from a single file
+
+</filtering_principle>
+
+<fails_the_test>
+
+These categories consistently fail the filtering test. Drop them during extraction.
+
+| Category | Why It Fails | Example |
+|----------|-------------|---------|
+| Design tokens (colors, spacing, typography) | Readable from code/config files | "Primary: #6366F1, spacing-md: 16px" |
+| Component API descriptions | Readable from component source | "SubscriptionCard accepts `plan`, `onSelect` props" |
+| Schema/model field listings | Readable from schema files | "User has fields: id, email, name, createdAt" |
+| Version pins without rationale | Readable from package.json/lockfile | "Using React 18.2.0" |
+| Decisions without alternatives | No "because" = no reusable knowledge | "Using Tailwind for styling" (vs. what?) |
+| Implementation descriptions | Restates what the code does | "Login endpoint hashes password and returns JWT" |
+
+</fails_the_test>
+
+<passes_the_test>
+
+Concrete examples that earn their place — each would cause incorrect implementation without the entry.
+
+1. **FieldMask casing (gRPC):** FieldMask paths must use camelCase in JSON, not snake_case — proto3 JSON mapping silently drops snake_case paths. LLMs default to snake_case matching proto definitions.
+
+2. **keepAlive auto-dispose (Flutter):** Riverpod providers with `keepAlive()` in `autoDispose` family providers — calling `keepAlive()` inside `ref.onDispose` creates a retain cycle. Dispose callback never fires, provider leaks. Place `keepAlive()` in the provider body before any async gap.
+
+3. **HiveField index stability:** HiveField indices are permanent storage keys — changing an index silently corrupts existing user data. New fields must use the next unused index, never reuse or reorder.
+
+4. **do/while pagination (API):** Firestore `startAfter` cursor pagination requires do/while, not while — a while loop with an empty-page exit condition misses the last partial page when `limit` equals page size exactly.
+
+5. **Payment timeout (Stripe):** Stripe webhook delivery retries for up to 72 hours. Payment confirmation UI must show "processing" state, not assume success/failure within a session.
+
+6. **Interceptor ordering (Dio):** Dio interceptors run in addition order for requests but reverse order for responses/errors. Auth token injection must be added first to run last on error (so retry logic sees the refreshed token).
+
+</passes_the_test>
+
+<decision_quality_test>
+
+Not every decision is knowledge. Apply this secondary filter:
+
+**"Could a reasonable agent have chosen differently?"**
+
+- **Pass:** "jose over jsonwebtoken — better TypeScript types and actively maintained" → Yes, jsonwebtoken is the more common choice. The rationale prevents revisiting.
+- **Pass:** "httpOnly cookies over localStorage for JWT — XSS prevention" → Yes, localStorage is the LLM default. Without this entry, an LLM would likely use localStorage.
+- **Fail:** "Using TypeScript for type safety" → No reasonable agent would choose plain JS for a new project. This is a default, not a decision.
+- **Fail:** "Using ESLint for linting" → No alternative was seriously considered. Not knowledge.
+
+</decision_quality_test>
+
+<cross_subsystem_dedup>
+
+Before writing an entry, check whether it already exists in another subsystem's knowledge file.
+
+- If the entry belongs primarily to another subsystem, add a cross-reference: `(see {subsystem})` instead of duplicating.
+- If the entry spans multiple subsystems equally, place it in the most upstream subsystem and cross-reference from others.
+- If an existing duplicate is found during extraction, remove it from the less-relevant file and cross-reference.
+
+</cross_subsystem_dedup>
+
+<existing_content_review>
+
+On every write to a knowledge file, review the touched file's existing entries:
+
+- **Still relevant?** Remove entries for features/patterns that no longer exist.
+- **Code-derivable now?** Remove entries that were non-obvious when written but are now self-evident from the codebase (e.g., a pattern that was novel is now standard in the project).
+- **Superseded?** Update or remove entries contradicted by new decisions.
+- **Duplicated?** Check against other knowledge files — deduplicate using cross-references.
+
+This is opportunistic maintenance during normal writes, not a full audit.
+
+</existing_content_review>
+
+</knowledge_quality>

package/mindsystem/templates/knowledge.md

@@ -30,8 +30,8 @@ Template for `.planning/knowledge/{subsystem}.md` — per-subsystem knowledge fi
 
 ## Design
 
-- {Visual/UX spec, interaction pattern, or design token}
-- {Component state, layout choice, or color value}
+- {Design reasoning — why this approach, not alternatives}
+- {Interaction pattern that differs from LLM defaults}
 
 ## Pitfalls
 
@@ -54,7 +54,7 @@ Template for `.planning/knowledge/{subsystem}.md` — per-subsystem knowledge fi
 |---------|----------|-----------------|
 | **Decisions** | Choices with rationale (the "because" part) | CONTEXT.md locked decisions, RESEARCH.md recommendations, PLAN.md approach rationale, SUMMARY.md key-decisions |
 | **Architecture** | How the subsystem works, structural patterns | RESEARCH.md architecture patterns, PLAN.md implementation details, SUMMARY.md accomplishments |
-| **Design** | Visual/UX specs, interaction patterns, design tokens | DESIGN.md wireframe layouts, states tables, behavior notes, design tokens |
+| **Design** | Design reasoning, non-obvious interaction patterns (reasoning only — not tokens or values readable from code) | DESIGN.md wireframe layouts, states tables, behavior notes |
 | **Pitfalls** | What to watch out for, operational patterns | RESEARCH.md common pitfalls, SUMMARY.md issues/deviations, debug resolutions, adhoc learnings |
 | **Key Files** | Important file paths for this subsystem | SUMMARY.md key-files, PLAN.md file targets |
 
@@ -96,4 +96,19 @@ The cross-reference is navigational, not essential. Each file is self-contained
 - Fixed a bug in auth (description, not a reusable pattern)
 - Missing import in login.ts (trivial, not worth persisting)
 
+## What Doesn't Belong
+
+Apply this test to every entry: **"Would an LLM implement this incorrectly without this entry?"** If the answer is no, the entry is noise.
+
+Categories that consistently fail the test:
+
+- **Design tokens** (colors, spacing, typography) — readable from code/config files
+- **Component API descriptions** — readable from component source
+- **Schema/model field listings** — readable from schema files
+- **Version pins without rationale** — readable from package.json/lockfile
+- **Decisions without alternatives** — no "because" = no reusable knowledge ("Using Tailwind" vs. what?)
+- **Implementation descriptions** — restates what the code does
+
+**Decision quality test:** "Could a reasonable agent have chosen differently?" If no, it's a default, not a decision. "Using TypeScript for type safety" fails. "jose over jsonwebtoken for better TypeScript types" passes — jsonwebtoken is the more common choice.
+
 </guidelines>

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "mindsystem-cc",
-  "version": "4.4.1",
+  "version": "4.4.2",
   "description": "The engineer's meta-prompting system for Claude Code.",
   "bin": {
     "mindsystem-cc": "bin/install.js"

package/mindsystem/workflows/transition.md

@@ -1,460 +0,0 @@
-<required_reading>
-
-**Read these files NOW:**
-
-1. `.planning/STATE.md`
-2. `.planning/PROJECT.md`
-3. `.planning/ROADMAP.md`
-4. Current phase's plan files (`*-PLAN.md`)
-5. Current phase's summary files (`*-SUMMARY.md`)
-
-</required_reading>
-
-<purpose>
-
-Mark current phase complete and advance to next. This is the natural point where progress tracking and PROJECT.md evolution happen.
-
-"Planning next phase" = "current phase is done"
-
-</purpose>
-
-<process>
-
-<step name="load_project_state" priority="first">
-
-Before transition, read project state:
-
-```bash
-cat .planning/STATE.md 2>/dev/null
-cat .planning/PROJECT.md 2>/dev/null
-```
-
-Parse current position to verify we're transitioning the right phase.
-Note accumulated context that may need updating after transition.
-
-</step>
-
-<step name="verify_completion">
-
-Check current phase has all plan summaries:
-
-```bash
-ls .planning/phases/XX-current/*-PLAN.md 2>/dev/null | sort
-ls .planning/phases/XX-current/*-SUMMARY.md 2>/dev/null | sort
-```
-
-**Verification logic:**
-
-- Count PLAN files
-- Count SUMMARY files
-- If counts match: all plans complete
-- If counts don't match: incomplete
-
-**If all plans complete:**
-
-```
-⚡ Auto-approved: Transition Phase [X] → Phase [X+1]
-Phase [X] complete — all [Y] plans finished.
-
-Proceeding to mark done and advance...
-```
-
-Proceed directly to cleanup_handoff step.
-
-**If plans incomplete:**
-
-**SAFETY RAIL: Skipping incomplete plans is destructive — always confirm.**
-
-Present:
-
-```
-Phase [X] has incomplete plans:
-- {phase}-01-SUMMARY.md ✓ Complete
-- {phase}-02-SUMMARY.md ✗ Missing
-- {phase}-03-SUMMARY.md ✗ Missing
-
-⚠️ Safety rail: Skipping plans requires confirmation (destructive action)
-
-Options:
-1. Continue current phase (execute remaining plans)
-2. Mark complete anyway (skip remaining plans)
-3. Review what's left
-```
-
-Wait for user decision.
-
-</step>
-
-<step name="update_roadmap">
-
-Update the roadmap file:
-
-```bash
-ROADMAP_FILE=".planning/ROADMAP.md"
-```
-
-Update the file:
-
-- Mark current phase: `[x] Complete`
-- Add completion date
-- Update Progress table
-- Keep next phase as `[ ] Not started`
-
-**Example:**
-
-```markdown
-## Phases
-
-- [x] Phase 1: Foundation (completed 2025-01-15)
-- [ ] Phase 2: Authentication ← Next
-- [ ] Phase 3: Core Features
-
-## Progress
-
-| Phase             | Status      | Completed  |
-| ----------------- | ----------- | ---------- |
-| 1. Foundation     | Complete    | 2025-01-15 |
-| 2. Authentication | Not started | -          |
-| 3. Core Features  | Not started | -          |
-```
-
-</step>
-
-<step name="archive_prompts">
-
-If prompts were generated for the phase, they stay in place.
-The `completed/` subfolder pattern from create-meta-prompts handles archival.
-
-</step>
-
-<step name="evolve_project">
-
-Evolve PROJECT.md to reflect learnings from completed phase.
-
-**Read phase summaries:**
-
-```bash
-cat .planning/phases/XX-current/*-SUMMARY.md
-```
-
-**Assess requirement changes:**
-
-1. **Requirements validated?**
-   - Any requirements shipped in this phase?
-   - Add to Validated with phase reference: `- ✓ [Requirement] — Phase X`
-
-2. **Requirements invalidated?**
-   - Any requirements discovered to be unnecessary or wrong?
-   - Add to Out of Scope with reason: `- [Requirement] — [why invalidated]`
-
-3. **Business context evolved?**
-   - Has understanding of audience, problem, or differentiation changed?
-   - Update Who It's For, Core Problem, or How It's Different if so
-   - New key flows emerged? → Update Key User Flows
-
-4. **Decisions to log?**
-   - Extract decisions from SUMMARY.md files
-   - Add to Key Decisions table with outcome if known
-
-5. **"What This Is" still accurate?**
-   - If the product has meaningfully changed, update the description
-   - Keep it current and accurate
-
-**Update PROJECT.md:**
-
-Make the edits inline. Update "Last updated" footer:
-
-```markdown
----
-*Last updated: [date] after Phase [X]*
-```
-
-**Example evolution:**
-
-Before:
-
-```markdown
-## Validated
-
-- ✓ Canvas drawing tools — Phase 1
-
-## Out of Scope
-
-- OAuth2 — complexity not needed for v1
-```
-
-After (Phase 2 shipped JWT auth, discovered rate limiting needed):
-
-```markdown
-## Validated
-
-- ✓ Canvas drawing tools — Phase 1
-- ✓ JWT authentication — Phase 2
-
-## Out of Scope
-
-- OAuth2 — complexity not needed for v1
-- Offline mode — real-time is core value, discovered Phase 2
-```
-
-**Step complete when:**
-
-- [ ] Phase summaries reviewed for learnings
-- [ ] Shipped requirements added to Validated
-- [ ] Invalidated requirements added to Out of Scope with reason
-- [ ] Business context sections reviewed (Who It's For, Core Problem, How It's Different, Key User Flows)
-- [ ] New decisions logged with rationale
-- [ ] "What This Is" updated if product changed
-- [ ] "Last updated" footer reflects this transition
-
-</step>
-
-<step name="update_current_position_after_transition">
-
-Update Current Position section in STATE.md to reflect phase completion and transition.
-
-**Format:**
-
-```markdown
-Phase: [next] of [total] ([Next phase name])
-Plan: Not started
-Status: Ready to plan
-Last activity: [today] — Phase [X] complete, transitioned to Phase [X+1]
-
-Progress: [updated progress bar]
-```
-
-**Instructions:**
-
-- Increment phase number to next phase
-- Reset plan to "Not started"
-- Set status to "Ready to plan"
-- Update last activity to describe transition
-- Recalculate progress bar based on completed plans
-
-**Example — transitioning from Phase 2 to Phase 3:**
-
-Before:
-
-```markdown
-## Current Position
-
-Phase: 2 of 4 (Authentication)
-Plan: 2 of 2 in current phase
-Status: Phase complete
-Last activity: 2025-01-20 — Completed 02-02-PLAN.md
-
-Progress: ███████░░░ 60%
-```
-
-After:
-
-```markdown
-## Current Position
-
-Phase: 3 of 4 (Core Features)
-Plan: Not started
-Status: Ready to plan
-Last activity: 2025-01-20 — Phase 2 complete, transitioned to Phase 3
-
-Progress: ███████░░░ 60%
-```
-
-**Step complete when:**
-
-- [ ] Phase number incremented to next phase
-- [ ] Plan status reset to "Not started"
-- [ ] Status shows "Ready to plan"
-- [ ] Last activity describes the transition
-- [ ] Progress bar reflects total completed plans
-
-</step>
-
-<step name="update_project_reference">
-
-Update Project Reference section in STATE.md.
-
-```markdown
-## Project Reference
-
-See: .planning/PROJECT.md (updated [today])
-
-**Core value:** [Current core value from PROJECT.md]
-**Current focus:** [Next phase name]
-```
-
-Update the date and current focus to reflect the transition.
-
-</step>
-
-<step name="review_accumulated_context">
-
-Review and update Accumulated Context section in STATE.md.
-
-**Decisions:**
-
-- Note recent decisions from this phase (3-5 max)
-- Full log lives in PROJECT.md Key Decisions table
-
-**Blockers/Concerns:**
-
-- Review blockers from completed phase
-- If addressed in this phase: Remove from list
-- If still relevant for future: Keep with "Phase X" prefix
-- Add any new concerns from completed phase's summaries
-
-**Example:**
-
-Before:
-
-```markdown
-### Blockers/Concerns
-
-- ⚠️ [Phase 1] Database schema not indexed for common queries
-- ⚠️ [Phase 2] WebSocket reconnection behavior on flaky networks unknown
-```
-
-After (if database indexing was addressed in Phase 2):
-
-```markdown
-### Blockers/Concerns
-
-- ⚠️ [Phase 2] WebSocket reconnection behavior on flaky networks unknown
-```
-
-**Step complete when:**
-
-- [ ] Recent decisions noted (full log in PROJECT.md)
-- [ ] Resolved blockers removed from list
-- [ ] Unresolved blockers kept with phase prefix
-- [ ] New concerns from completed phase added
-
-</step>
-
-<step name="update_session_continuity_after_transition">
-
-Update Session Continuity section in STATE.md to reflect transition completion.
-
-**Format:**
-
-```markdown
-Last session: [today]
-Stopped at: Phase [X] complete, ready to plan Phase [X+1]
-```
-
-**Step complete when:**
-
-- [ ] Last session timestamp updated to current date and time
-- [ ] Stopped at describes phase completion and next phase
-
-</step>
-
-<step name="offer_next_phase">
-
-**MANDATORY: Verify milestone status before presenting next steps.**
-
-**Step 1: Read ROADMAP.md and identify phases in current milestone**
-
-Read the ROADMAP.md file and extract:
-1. Current phase number (the phase just transitioned from)
-2. All phase numbers in the current milestone section
-
-To find phases, look for:
-- Phase headers: lines starting with `### Phase` or `#### Phase`
-- Phase list items: lines like `- [ ] **Phase X:` or `- [x] **Phase X:`
-
-Count total phases and identify the highest phase number in the milestone.
-
-State: "Current phase is {X}. Milestone has {N} phases (highest: {Y})."
-
-**Step 2: Route based on milestone status**
-
-| Condition | Meaning | Action |
-|-----------|---------|--------|
-| current phase < highest phase | More phases remain | Go to **Route A** |
-| current phase = highest phase | Milestone complete | Go to **Route B** |
-
----
-
-**Route A: More phases remain in milestone**
-
-Read ROADMAP.md to get the next phase's name and goal.
-
-**If next phase exists:**
-
-```
-Phase [X] marked complete.
-
-Next: Phase [X+1] — [Name]
-
-⚡ Auto-continuing: Plan Phase [X+1] in detail
-```
-
-Exit skill and invoke SlashCommand("/ms:plan-phase [X+1]")
-
----
-
-**Route B: Milestone complete (all phases done)**
-
-```
-Phase {X} marked complete.
-
-🎉 Milestone is 100% complete — all {N} phases finished!
-
-⚡ Auto-continuing: Complete milestone and archive
-```
-
-Exit skill and invoke SlashCommand("/ms:complete-milestone")
-
-</step>
-
-</process>
-
-<implicit_tracking>
-
-Progress tracking is IMPLICIT:
-
-- "Plan phase 2" → Phase 1 must be done (or ask)
-- "Plan phase 3" → Phases 1-2 must be done (or ask)
-- Transition workflow makes it explicit in ROADMAP.md
-
-No separate "update progress" step. Forward motion IS progress.
-
-</implicit_tracking>
-
-<partial_completion>
-
-If user wants to move on but phase isn't fully complete:
-
-```
-Phase [X] has incomplete plans:
-- {phase}-02-PLAN.md (not executed)
-- {phase}-03-PLAN.md (not executed)
-
-Options:
-1. Mark complete anyway (plans weren't needed)
-2. Defer work to later phase
-3. Stay and finish current phase
-```
-
-Respect user judgment — they know if work matters.
-
-**If marking complete with incomplete plans:**
-
-- Note in transition message which plans were skipped
-
-</partial_completion>
-
-<success_criteria>
-
-Transition is complete when:
-
-- [ ] Current phase plan summaries verified (all exist or user chose to skip)
-- [ ] Any stale handoffs deleted
-- [ ] ROADMAP.md updated with completion status
-- [ ] PROJECT.md evolved (requirements, decisions, description if needed)
-- [ ] STATE.md updated (position, project reference, context, session)
-- [ ] Progress table updated
-- [ ] User knows next steps
-
-</success_criteria>