mindsystem-cc 4.3.1 → 4.4.0

package/commands/ms/insert-phase.md

@@ -6,19 +6,21 @@ allowed-tools:
   - Read
   - Write
   - Bash
+  - AskUserQuestion
 ---
 
 <objective>
-Insert a decimal phase for urgent work discovered mid-milestone that must be completed between existing integer phases.
+Insert a decimal phase for urgent work discovered mid-milestone that must be completed between existing integer phases, fully specified with goal, success criteria, and requirements.
 
-Uses decimal numbering (72.1, 72.2, etc.) to preserve the logical sequence of planned phases while accommodating urgent insertions.
+Uses decimal numbering (72.1, 72.2, etc.) to preserve the logical sequence of planned phases while accommodating urgent insertions. The phase is set up identically to phases created by the roadmapper — downstream commands work without degradation.
 
-Purpose: Handle urgent work discovered during execution without renumbering entire roadmap.
+Purpose: Handle urgent work discovered during execution without renumbering entire roadmap, with full pipeline support.
 </objective>
 
 <execution_context>
 @.planning/ROADMAP.md
 @.planning/STATE.md
+@.planning/REQUIREMENTS.md
 </execution_context>
 
 <process>
@@ -59,8 +61,8 @@ fi
 
 </step>
 
-<step name="load_roadmap">
-Load the roadmap file:
+<step name="load_context">
+Load project context:
 
 ```bash
 if [ -f .planning/ROADMAP.md ]; then
@@ -69,9 +71,33 @@ else
   echo "ERROR: No roadmap found (.planning/ROADMAP.md)"
   exit 1
 fi
+
+if [ ! -f .planning/REQUIREMENTS.md ]; then
+  echo "ERROR: No REQUIREMENTS.md found"
+  exit 1
+fi
+```
+
+If REQUIREMENTS.md is missing, display:
+
+```
+Phase insertion requires an active milestone with requirements tracking.
+No .planning/REQUIREMENTS.md found.
+
+Instead, consider:
+- `/ms:new-milestone` — start a new milestone with requirements
+- `/ms:create-roadmap` — if milestone context exists but roadmap wasn't created yet
+- `/ms:adhoc "<description>"` — for work that doesn't need milestone tracking
 ```
 
-Read roadmap content for parsing.
+Exit command.
+
+Read ROADMAP.md and REQUIREMENTS.md.
+
+From REQUIREMENTS.md, extract:
+- Existing REQ-ID categories and their prefixes (e.g., AUTH, SUB, CONTENT)
+- Highest REQ-ID number per category (e.g., AUTH-04 → next is AUTH-05)
+- Traceability table structure
 </step>
 
 <step name="verify_target_phase">
@@ -88,7 +114,7 @@ Verify that the target phase exists in the roadmap:
    Exit.
 
 3. Verify phase is in current milestone (not completed/archived)
-   </step>
+</step>
 
 <step name="find_existing_decimals">
 Find existing decimal phases after the target phase:
@@ -107,6 +133,14 @@ Examples:
 Store as: `decimal_phase="$(printf "%02d" $after_phase).${next_decimal}"`
 </step>
 
+<step name="derive_phase_specification">
+Read `~/.claude/mindsystem/references/derive-phase-specification.md` and follow its algorithm.
+
+Variables: `{PHASE_ID}` = `{decimal_phase}`, `{PHASE_MARKER}` = `(INSERTED)`.
+
+Input: user's description + project context (PROJECT.md, ROADMAP.md phases, REQUIREMENTS.md categories).
+</step>
+
 <step name="generate_slug">
 Convert the phase description to a kebab-case slug:
 
@@ -129,46 +163,44 @@ mkdir -p "$phase_dir"
 Confirm: "Created directory: $phase_dir"
 </step>
 
-<step name="update_roadmap">
-Insert the new phase entry into the roadmap:
-
-1. Find insertion point: immediately after Phase {after_phase}'s content (before next phase heading or "---")
+<step name="update_requirements">
+Follow the requirements update procedure in `~/.claude/mindsystem/references/derive-phase-specification.md`.
 
-2. Before writing the phase entry, analyze the description to determine pre-work flags:
+Use Phase `{decimal_phase}` for traceability table references and footer dating.
+</step>
 
-   **Discuss**: Default Likely — enumerate 2-4 assumptions or open questions specific
-   to the phase. Unlikely only for fully mechanical zero-decision work (version bump,
-   rename-only refactor, config-only change, pure deletion/cleanup).
+<step name="update_roadmap">
+Insert the new phase entry into the roadmap:
 
-   **Design**: Likely when description involves UI work, visual elements, forms,
-   dashboards, or multi-screen flows. Unlikely for backend-only, API, infrastructure,
-   or established UI patterns.
+**1. Find insertion point:** immediately after Phase {after_phase}'s content (and any existing decimals), before next integer phase heading or "---".
 
-   **Research**: Likely when description mentions external APIs/services, new
-   libraries/frameworks, or unclear technical approach. Unlikely for established
-   internal patterns or well-documented conventions.
+**2. Add phase details:**
 
-   Use binary Likely/Unlikely with parenthetical reason. Include topics/focus only when Likely.
+Insert full phase entry matching roadmapper format with (INSERTED) marker:
 
-3. Insert new phase heading with (INSERTED) marker and pre-work flags:
+```
+### Phase {decimal_phase}: {Name} (INSERTED)
+**Goal**: {approved goal}
+**Depends on**: Phase {after_phase}
+**Requirements**: {REQ-IDs comma-separated}
+**Success Criteria** (what must be TRUE):
+  1. {criterion}
+  2. {criterion}
+  3. {criterion}
+**Discuss**: {Likely (reason) | Unlikely (reason)}
+**Discuss topics**: {topics} ← only if Likely
+**Design**: {Likely (reason) | Unlikely (reason)}
+**Design focus**: {focus} ← only if Likely
+**Research**: {Likely (reason) | Unlikely (reason)}
+**Research topics**: {topics} ← only if Likely
+```
 
-   ```
-   ### Phase {decimal_phase}: {Description} (INSERTED)
-
-   **Goal:** [Urgent work - to be planned]
-   **Depends on:** Phase {after_phase}
-   **Discuss**: {Likely (reason) | Unlikely (reason)}
-   **Discuss topics**: {topics} ← only if Likely
-   **Design**: {Likely (reason) | Unlikely (reason)}
-   **Design focus**: {focus} ← only if Likely
-   **Research**: {Likely (reason) | Unlikely (reason)}
-   **Research topics**: {topics} ← only if Likely
-
-   **Details:**
-   [To be added during planning]
-   ```
+**3. Update progress table** — insert row in correct position:
+```
+| {decimal_phase}. {Name} (INSERTED) | Not started | - |
+```
 
-4. Write updated roadmap back to file
+Write updated roadmap back to file.
 
 The "(INSERTED)" marker helps identify decimal phases as urgent insertions.
 
@@ -194,14 +226,17 @@ Present completion summary:
 
 ```
 Phase {decimal_phase} inserted after Phase {after_phase}:
-- Description: {description}
+- Goal: {goal}
+- Requirements: {REQ-IDs}
+- Success criteria: {count}
 - Directory: .planning/phases/{decimal-phase}-{slug}/
 - Status: Not planned yet
 - Marker: (INSERTED) - indicates urgent work
 
-Roadmap updated: {roadmap-path}
-Project state updated: .planning/STATE.md
-
+Files updated:
+- .planning/ROADMAP.md
+- .planning/REQUIREMENTS.md
+- .planning/STATE.md
 ```
 
 Read `~/.claude/mindsystem/references/routing/next-phase-routing.md` and follow its instructions
@@ -227,15 +262,18 @@ ms-tools set-last-command "ms:insert-phase $ARGUMENTS"
 - Don't modify the target phase content
 - Don't create plans yet (that's /ms:plan-phase)
 - Don't commit changes (user decides when to commit)
-  </anti_patterns>
+- Don't write skeletal "[To be planned]" entries — derive a real goal and success criteria
+</anti_patterns>
 
 <success_criteria>
 Phase insertion is complete when:
 
-- [ ] Phase directory created: `.planning/phases/{N.M}-{slug}/`
-- [ ] Roadmap updated with new phase entry (includes "(INSERTED)" marker)
-- [ ] Phase inserted in correct position (after target phase, before next integer phase)
+- [ ] Specification derived with outcome-focused goal and 2-5 observable success criteria
+- [ ] Requirements derived with REQ-IDs and REQUIREMENTS.md updated with traceability mapping
+- [ ] Phase directory and roadmap entry created with (INSERTED) marker and correct decimal number
+- [ ] Phase inserted after target phase, before next integer phase
+- [ ] Roadmap entry matches roadmapper format (Goal, Requirements, Success Criteria, pre-work flags)
 - [ ] STATE.md updated with roadmap evolution note
-- [ ] Decimal number calculated correctly (based on existing decimals)
+- [ ] User approved specification before writing
 - [ ] User informed of next steps and dependency implications
-      </success_criteria>
+</success_criteria>

package/commands/ms/new-milestone.md

@@ -130,7 +130,7 @@ Milestone name: $ARGUMENTS (optional — will emerge during discovery if not pro
 
 6. **Adaptive depth based on response clarity:**
 
-   - **Clear, detailed response** → brief confirmation ("Sounds like you want X, Y, Z — let me confirm a few things"), then move toward Phase 3 quickly
+   - **Clear, detailed response** → brief confirmation ("Sounds like you want X, Y, Z — let me confirm a few things"), then build on what they shared rather than re-asking
    - **Vague response** → probe with AskUserQuestion, explore features, challenge vagueness
    - **External context shared** → integrate it, clarify implications, ask follow-ups
 

package/commands/ms/plan-phase.md

@@ -19,7 +19,7 @@ allowed-tools:
 Create executable phase prompt with discovery, context injection, and task breakdown.
 
 Purpose: Break down roadmap phases into concrete, executable PLAN.md files that Claude can execute.
-Output: One or more PLAN.md files in the phase directory (.planning/phases/XX-name/{phase}-{plan}-PLAN.md)
+Output: PLAN.md file(s) in the phase directory (single plan by default; multiple when multi_plan enabled)
 
 </objective>
 
@@ -86,7 +86,7 @@ Check for `.planning/codebase/` and load relevant documents based on phase type.
    - Perform mandatory discovery (Level 0-3 as appropriate)
    - Scan project history via context scanner script (prior decisions, issues, debug resolutions, adhoc learnings, cross-milestone patterns)
    - Break phase into tasks
-   - Propose plan grouping (plan boundaries, wave structure, budget estimates) for user review
+   - Determine plan grouping (single plan by default; multi-plan with user confirmation when enabled)
    - Discover relevant project skills, confirm with user
    - Hand off tasks + proposed grouping + confirmed skills to plan-writer subagent
    - Create PLAN.md file(s) with executable structure
@@ -94,7 +94,7 @@ Check for `.planning/codebase/` and load relevant documents based on phase type.
 6. **Update last command:** `ms-tools set-last-command "ms:plan-phase $ARGUMENTS"`
 
 7. **Risk assessment**
-   - Calculate risk score from context already loaded (task count, plan count, external services, CONTEXT.md, cross-cutting concerns, new deps, complex domains)
+   - Calculate risk score from context already loaded (task count, external services, CONTEXT.md, cross-cutting concerns, new deps, complex domains)
    - Present score + top factors via AskUserQuestion
    - Tier-based recommendation: Skip (0-39), Optional (40-69), Verify (70+)
    - If user chooses verify: spawn ms-plan-checker, surface results
@@ -103,7 +103,7 @@ Check for `.planning/codebase/` and load relevant documents based on phase type.
 
 <success_criteria>
 
-- One or more PLAN.md files created in .planning/phases/XX-name/
+- PLAN.md file(s) created in .planning/phases/XX-name/
 - Each plan has: Context, Changes, Verification, Must-Haves (pure markdown format)
 - Must-Haves derived as markdown checklist of user-observable truths
 - Changes are specific enough for Claude to execute

package/mindsystem/references/browser-verification.md

@@ -32,7 +32,7 @@ Store the result as `{dev_url}`.
 If `HAS_STATE`:
 1. Open app headless at `{dev_url}`
 2. Check current URL — if redirected to a login/auth path, auth has expired
-3. If still on app pages: auth valid, proceed to Derive Browser Checklist
+3. If still on app pages: auth valid, proceed to Derive User Journeys
 
 If `NO_STATE` or auth expired:
 1. Close headless browser
@@ -47,9 +47,9 @@ If `NO_STATE` or auth expired:
    ```
 5. If user skips: proceed to code_review, skip browser verification
 
-## Derive Browser Checklist
+## Derive User Journeys
 
-Transform SUMMARY.md accomplishments into a structured checklist for the browser verifier.
+Transform SUMMARY.md accomplishments into user journeys for the browser verifier.
 
 **Step 1: Read summaries**
 
@@ -62,29 +62,38 @@ For each SUMMARY, extract:
 - **mock_hints** frontmatter (if present) — specifically `external_data` entries
 - **key-files** frontmatter (if present) — for route inference
 
-**Step 3: Derive checklist items**
+**Step 3: Derive user journeys**
 
-For each user-observable accomplishment, derive:
-- `name`: brief description of what to verify
-- `route`: URL path (infer from key-files paths, routing config, or component names)
-- `expected`: what should be visible on screen (be specific — "table with columns X, Y, Z", not "data displays")
-- `interaction`: optional action + expected result (e.g., "click Add button → modal opens with form fields A, B, C")
+For each user-observable accomplishment, derive a journey:
+- `name`: verb-first — what the user is trying to accomplish (e.g., "Create a new project via the Add button")
+- `start`: page reachable via sidebar/nav (NOT a deep URL)
+- `steps`: ordered actions — click, fill, submit, verify state change
+- `success`: what should be true after completing the journey
 - `needs_backend_data`: true/false (from mock_hints `external_data` entries)
 
+**Derivation rules:**
+- New pages/routes: journey starts from parent page, navigates via UI
+- Forms: MUST include fill AND submit
+- Toggles/filters: MUST include activate AND deactivate
+- CRUD: one journey per built operation
+- Modals: open, interact, confirm — not just "modal opens"
+
 **Step 4: Filter**
 
-Include: UI renders, navigation, forms, data display, visual states, user interactions.
+Include: UI renders, navigation, forms, data display, visual states, user interactions — each as a complete journey.
 Exclude: refactors, type changes, API internals, test files, build config, non-visual changes.
 
 **Step 5: Group and format**
 
-Group items by route for efficient navigation. Format as a numbered list:
+Group journeys by starting area for efficient navigation. Format as a numbered list:
 
 ```
 1. **{name}**
-   Route: {route}
-   Expected: {expected}
-   Interaction: {interaction or "none"}
+   Start: {start page/area}
+   Steps:
+   - {action 1}
+   - {action 2}
+   Success: {what should be true after}
    Needs backend data: {yes/no}
 
 2. **{name}**
@@ -93,7 +102,7 @@ Group items by route for efficient navigation. Format as a numbered list:
 
 ## Spawn
 
-Spawn the browser verifier agent after auth is established and checklist is derived:
+Spawn the browser verifier agent after auth is established and journeys are derived:
 
 ```
 Task(
@@ -104,16 +113,16 @@ Dev URL: {dev_url}
 Auth state: .agent-browser-state.json
 Screenshots directory: {phase_dir}/screenshots
 
-## Browser Checklist
+## User Journeys
 
-{derived_checklist}
+{derived_journeys}
 
 ## Backend Context
 
-{summary of which items need real backend data — from mock_hints external_data entries.
-Items needing backend data may show empty states or errors — mark as ENVIRONMENT_BLOCKED, not ISSUE.}
+{summary of which journeys need real backend data — from mock_hints external_data entries.
+Journeys needing backend data may show empty states or errors — mark as ENVIRONMENT_BLOCKED, not ISSUE.}
 
-Verify each checklist item. Save all screenshots to {phase_dir}/screenshots/.
+Complete each user journey end-to-end. Save all screenshots to {phase_dir}/screenshots/.
 Fix trivial issues inline. Return structured report.",
   subagent_type="ms-browser-verifier"
 )
@@ -138,6 +147,6 @@ Report: "Browser verification: {N} issues found (see screenshots in {phase_dir}/
 Note issues for verify-work — these are candidates for manual UAT.
 
 **`all_passed`:**
-Report: "Browser verification: all {N} items passed"
+Report: "Browser verification: all {N} journeys passed"
 
 </browser_verification>

package/mindsystem/references/derive-phase-specification.md

@@ -0,0 +1,147 @@
+# Phase Specification Derivation
+
+Shared algorithm for deriving goal, success criteria, requirements, and pre-work flags from a user's phase description. Used by `add-phase` and `insert-phase`.
+
+## Variables
+
+Set by calling command before loading this reference:
+
+- `{PHASE_ID}` — phase number (integer like `7` or decimal like `06.1`)
+- `{PHASE_MARKER}` — empty for add-phase, `(INSERTED)` for insert-phase
+
+## Input Assessment
+
+Read `.planning/PROJECT.md` for vision and domain context (target audience, project scope).
+
+Proceed directly when the user's description provides enough context to derive a confident specification — clear domain, identifiable user outcomes, enough scope to define 2-5 success criteria.
+
+When scope is ambiguous or domain is unclear, ask targeted clarifying questions before deriving. Keep asking until confident.
+
+Use AskUserQuestion with concrete options derived from PROJECT.md/ROADMAP.md context:
+- header: "Phase Clarification"
+- question: specific ambiguity identified
+- options: 2-4 concrete interpretations plus "Something else"
+
+Examples of when to ask:
+- "Add notifications" → notifications for what? (new content, billing events, system alerts, all of these?)
+- "Fix performance" → which user-facing flow? (page load, search, data export?)
+- "Add settings" → which settings? (account, preferences, integrations?)
+
+Examples of when to proceed directly:
+- "Add dark mode toggle to settings page" → clear scope, clear UI, clear outcome
+- "Add Stripe subscription billing with plan selection" → clear domain, clear integration
+
+## Derivation Algorithm
+
+### 1. Goal Statement
+
+Transform the description into an outcome-focused goal:
+
+- Good: "Users can manage subscription billing without edge-case failures"
+- Good: "Content creators can schedule posts for future publication"
+- Good: "Administrators can monitor system health through a real-time dashboard"
+- Bad: "Fix subscription billing" (task, not outcome)
+- Bad: "Add scheduling feature" (feature label, not user outcome)
+- Bad: "Implement admin dashboard" (implementation task, not user value)
+
+Use existing phase goals from ROADMAP.md as style reference.
+
+### 2. Success Criteria (2-5)
+
+Ask: "What must be TRUE for users when this phase completes?"
+
+- Each criterion must be verifiable by a human using the application
+- Observable user behaviors, not implementation tasks
+- Good: "User sees correct prorated amount when changing plans mid-cycle"
+- Good: "User receives email confirmation within 30 seconds of signup"
+- Good: "Dark mode persists across browser sessions"
+- Bad: "Billing calculation is fixed"
+- Bad: "Email service is integrated"
+- Bad: "CSS variables are used for theming"
+
+### 3. Requirements with REQ-IDs
+
+Create atomic, checkable requirements:
+
+- Follow existing category patterns from REQUIREMENTS.md (e.g., if AUTH-01..AUTH-04 exist, continue with AUTH-05)
+- If the work fits an existing category, reuse that prefix and continue numbering
+- If the work introduces a new domain, create a new category prefix
+- User-centric: "User can X" not "System does Y"
+- Each requirement maps to Phase {PHASE_ID}
+
+The calling command has already extracted existing REQ-ID categories and highest numbers from REQUIREMENTS.md — use that context.
+
+### 4. Pre-work Flags
+
+Analyze the description to determine:
+
+**Discuss**: Default Likely — enumerate 2-4 assumptions or open questions specific
+to the phase. Unlikely only for fully mechanical zero-decision work (version bump,
+rename-only refactor, config-only change, pure deletion/cleanup).
+
+**Design**: Likely when description involves UI work, visual elements, forms,
+dashboards, or multi-screen flows. Unlikely for backend-only, API, infrastructure,
+or established UI patterns.
+
+**Research**: Likely when description mentions external APIs/services, new
+libraries/frameworks, or unclear technical approach. Unlikely for established
+internal patterns or well-documented conventions.
+
+Use binary Likely/Unlikely with parenthetical reason. Include topics/focus only when Likely.
+
+## Presentation & Approval
+
+Present the full specification:
+
+```
+## Phase {PHASE_ID}: {Name} {PHASE_MARKER}
+
+**Goal:** {proposed goal}
+
+**Success Criteria:**
+1. {criterion}
+2. {criterion}
+3. {criterion}
+
+**New Requirements:**
+- [ ] **{CAT}-{NN}**: {description}
+- [ ] **{CAT}-{NN}**: {description}
+
+**Pre-work:** Discuss {L/U} | Design {L/U} | Research {L/U}
+```
+
+Use AskUserQuestion:
+- header: "Phase Specification"
+- question: "Does this capture what Phase {PHASE_ID} should deliver?"
+- options:
+  - "Approve" — Proceed with this specification
+  - "Adjust" — I want to refine the goal, criteria, or requirements
+  - "Add context" — I need to provide more detail first
+
+If "Adjust": Ask what to change, revise, re-present.
+If "Add context": Get additional detail, re-derive, re-present.
+Loop until approved.
+
+## Requirements Update
+
+Update REQUIREMENTS.md with the approved requirements:
+
+1. Append new requirements under the appropriate category section in `## v1 Requirements`:
+   - If category exists: add new requirements after the last requirement in that category
+   - If new category: add new category section after last existing category
+
+2. Update `## Traceability` table — append rows for each new requirement:
+   ```
+   | {REQ-ID} | Phase {PHASE_ID} | Pending |
+   ```
+
+3. Update coverage counts:
+   ```
+   - v1 requirements: {X + new count} total
+   - Mapped to phases: {Y + new count}
+   ```
+
+4. Update `*Last updated:*` footer:
+   ```
+   *Last updated: {date} after Phase {PHASE_ID} addition*
+   ```

package/mindsystem/templates/config.json

@@ -8,5 +8,6 @@
   "open_mockups": "auto",
   "browser_verification": {
     "enabled": true
-  }
+  },
+  "multi_plan": false
 }

package/mindsystem/templates/roadmap.md

@@ -68,10 +68,16 @@ Decimal phases appear between their surrounding integers in numeric order.
 **Research topics**: [What needs investigating]
 
 ### Phase 2.1: Critical Fix (INSERTED)
-**Goal**: [Urgent work inserted between phases]
+**Goal**: [Outcome-focused goal derived during insertion]
 **Depends on**: Phase 2
+**Requirements**: [REQ-05, REQ-06]
 **Success Criteria** (what must be TRUE):
-  1. [What the fix achieves]
+  1. [Observable behavior from user perspective]
+  2. [Observable behavior from user perspective]
+**Discuss**: Likely (assumes X, unclear if Y)
+**Discuss topics**: [What to clarify]
+**Design**: Unlikely (backend fix)
+**Research**: Unlikely (known patterns)
 
 ### Phase 3: [Name]
 **Goal**: [What this phase delivers]

package/mindsystem/workflows/adhoc.md

@@ -87,7 +87,7 @@ Governing principle: each question must save more context than it costs. A quest
   - Looks right
   - Some corrections (let me clarify)
   - Let me reframe the task
-- Additional questions (conditional): Only when exploration surfaced genuine behavioral ambiguity the user must resolve. Frame with implementation context discovered during exploration. Typically 1-2 for focused work, 3-4 for multi-area work.
+- Additional questions (conditional): Only when exploration surfaced genuine behavioral ambiguity the user must resolve. Frame with implementation context discovered during exploration. Continue until scope is unambiguous — focused work may need one question; multi-area work may need several.
 
 **What NOT to ask** (Claude determines these from exploration):
 - Technical approach or patterns

package/mindsystem/workflows/discuss-phase.md

@@ -208,9 +208,9 @@ Present brief product analysis, then use AskUserQuestion:
 - question: "How do you imagine this working?"
 - options: 2-3 interpretations based on phase description, requirements, and industry context + "Let me describe it"
 
-**2. Follow the thread (2-4 rounds typical):**
+**2. Follow the thread:**
 
-Follow the user's thread. Each round: apply product lens to the topic they raised, then AskUserQuestion with 2-3 interpretations + escape hatch. Use multiSelect for priority/essential questions. Stop when vision is clear — don't over-question.
+Follow the user's thread. Each round: apply product lens to the topic they raised, then AskUserQuestion with 2-3 interpretations + escape hatch. Use multiSelect for priority/essential questions. Continue until you could write a CONTEXT.md that plan-phase can act on without clarifying questions — that's the downstream test. Don't ask about edge cases when core behaviors are still undefined; depth over breadth.
 
 **3. Decision gate:**
 

package/mindsystem/workflows/execute-phase.md

@@ -298,12 +298,12 @@ ms-tools browser-check
 
 **If exit 0 (READY):**
 
-Ensure `$PHASE_DIR/*-SUMMARY.md` files are available (needed for checklist derivation — may already be in context from wave reports).
+Ensure `$PHASE_DIR/*-SUMMARY.md` files are available (needed for journey derivation — may already be in context from wave reports).
 
 Read `~/.claude/mindsystem/references/browser-verification.md` and follow its sections in order:
 1. **Auth Flow** — establish browser authentication
-2. **Derive Browser Checklist** — transform SUMMARYs into visual checklist items
-3. **Spawn** — launch verifier with derived checklist
+2. **Derive User Journeys** — transform SUMMARYs into user journeys
+3. **Spawn** — launch verifier with derived journeys
 4. **Post-Verifier Handling** — route by report status
 
 **If exit 1 (MISSING_DEPS):**