sdlc-framework 1.0.2 → 2.0.0

package/src/references/prompt-detection.md

@@ -10,7 +10,7 @@ When a developer types `/sdlc:fast "add a login page"`, the framework must deter
 
 1. **What type of work is this?** (feature, bug, critical, research, test, refactor, docs)
 2. **How complex is it?** (simple, medium, complex)
-3. **Where should it route?** (inline execution, /sdlc:spec, /sdlc:debug, /sdlc:hotfix, /sdlc:research)
+3. **Where should it route?** (inline execution, /sdlc:spec, /sdlc:debug, /sdlc:research, /sdlc:discuss, or inline hotfix)
 
 `/sdlc:fast` is the **default entry point** for all work — not just small tasks. It is a universal router that classifies intent and complexity, then either handles work inline (simple) or routes to the appropriate specialized command (complex, bugs, research, emergencies).
 

package/src/templates/PRD.md

@@ -0,0 +1,89 @@
+# PRD: {title}
+
+## Meta
+
+| Field | Value |
+|-------|-------|
+| Created | {date} |
+| Status | DRAFT / APPROVED |
+| Author | {user} + AI |
+| Source | /sdlc:discuss |
+
+## Problem Statement
+
+{2-3 sentences describing the problem being solved. Focus on the pain, not the solution.}
+
+### Who Has This Problem
+
+- **Primary user:** {role/persona} — {how they encounter the problem}
+- **Secondary user:** {role/persona} — {how they are affected}
+
+### Current Workarounds
+
+- {How users solve this today, and why it is insufficient}
+
+### Impact
+
+- {What happens if this problem is not solved}
+- {Quantifiable impact if available: time wasted, errors caused, revenue lost}
+
+## Proposed Solution
+
+{2-3 sentences describing the solution at a high level. What changes for the user.}
+
+### Approach
+
+{Technical approach chosen during discussion, with rationale for why this approach over alternatives.}
+
+### Alternatives Considered
+
+| Approach | Pros | Cons | Why Not |
+|----------|------|------|---------|
+| {alternative 1} | {pros} | {cons} | {reason rejected} |
+| {alternative 2} | {pros} | {cons} | {reason rejected} |
+
+## Requirements
+
+### Functional Requirements
+
+- **FR-1:** {requirement} — Priority: {must/should/could}
+- **FR-2:** {requirement} — Priority: {must/should/could}
+
+### Non-Functional Requirements
+
+- **NFR-1:** {performance, security, scalability, accessibility requirement}
+
+### User Flows
+
+#### Flow 1: {flow name}
+
+1. User {action}
+2. System {response}
+3. User {action}
+4. System {response}
+
+## Constraints
+
+- **Technical:** {tech stack limitations, existing architecture constraints}
+- **Timeline:** {deadline or time budget}
+- **Scope:** {explicit boundaries — what is NOT included}
+
+## Edge Cases
+
+- {edge case 1} — Expected behavior: {behavior}
+- {edge case 2} — Expected behavior: {behavior}
+
+## Success Metrics
+
+- {How to measure whether this solution works}
+- {Concrete, measurable criteria}
+
+## Open Questions
+
+- {Unresolved questions deferred to spec phase}
+
+## Decisions Log
+
+| # | Question | Decision | Rationale |
+|---|----------|----------|-----------|
+| 1 | {question asked during discussion} | {answer} | {why} |

package/src/workflows/close-phase.md

@@ -188,7 +188,7 @@
     Phase {phase} COMPLETE.
     MILESTONE {milestone} COMPLETE.
 
-    Run /sdlc:milestone to finalize and start next milestone.
+    Milestone completion is handled automatically by /sdlc:close.
     ```
 
   WHY: The display tells the user exactly where they are in the bigger picture. Completing a phase or milestone is a significant moment — acknowledge it.

package/src/workflows/discuss-phase.md

@@ -0,0 +1,195 @@
+<purpose>Drive AI-led brainstorming to transform a raw idea into a structured PRD. The discuss phase sits upstream of spec — it explores the problem space, validates approaches, and builds requirements through targeted questioning. Without this phase, specs are built on assumptions instead of explored decisions.</purpose>
+<when_to_use>Run when the user has an idea but has not yet defined what to build. This is pre-loop discovery — it feeds into /sdlc:spec. Can run at any point: before init, between loops, or when pivoting direction.</when_to_use>
+<required_reading>.sdlc/PROJECT.md (if exists), .sdlc/ROADMAP.md (if exists), codebase structure for technical context</required_reading>
+<loop_context>
+  expected_phase: DISCUSS (pre-loop activity)
+  prior_phase: any (entry point or between loops)
+  next_phase: SPEC (discuss always leads to spec)
+</loop_context>
+<process>
+
+<step name="seed_idea" priority="first">
+  The discussion needs a starting point — without one, questions are unfocused.
+
+  IF $ARGUMENTS provided:
+    Restate the idea in one sentence to confirm understanding.
+    Ask: "Is this what you want to explore, or should I adjust the framing?"
+
+  IF $ARGUMENTS empty:
+    Ask: "What idea, feature, or problem do you want to explore?"
+    Wait for response before proceeding.
+
+  IF .sdlc/PROJECT.md exists:
+    Read it. Note the tech stack, architecture, and constraints.
+    These inform all downstream questions — do not ask about things the project context already answers.
+
+  Record the seed idea for the decisions log.
+</step>
+
+<step name="explore_problem" priority="second">
+  Understanding the problem prevents building solutions to the wrong thing. Most failed features solve real problems badly because the problem was never properly defined.
+
+  Ask 2-4 questions from this category. Include a recommendation with each. Use AskUserQuestion.
+
+  PROBLEM QUESTIONS (pick the most relevant):
+  - "What specific problem does this solve? Who encounters it and how often?"
+    Recommendation: Frame the problem from the user's perspective, not the system's.
+  - "How do users solve this today? What makes current workarounds insufficient?"
+    Recommendation: Based on codebase scan, suggest what exists and what gaps you see.
+  - "What happens if this is not built? What is the cost of inaction?"
+    Recommendation: Assess severity based on what you know about the project.
+  - "Is this a new capability, an improvement to something existing, or a fix?"
+    Recommendation: Based on codebase, state whether related functionality already exists.
+
+  DO NOT ask questions whose answers are already in PROJECT.md or the codebase.
+  DO NOT ask questions that do not affect the technical solution.
+
+  Record all answers in the decisions log.
+</step>
+
+<step name="define_scope" priority="third">
+  Scope prevents building too much or too little. Without explicit scope, features creep and deadlines slip.
+
+  Ask 2-4 questions from this category. Include a recommendation with each.
+
+  SCOPE QUESTIONS (pick the most relevant):
+  - "What is the smallest version of this that delivers value? What is the full vision?"
+    Recommendation: Propose an MVP scope based on the problem definition.
+  - "What is explicitly NOT included? What should be deferred to later?"
+    Recommendation: Suggest boundaries based on complexity and dependencies.
+  - "Are there timeline or resource constraints that affect scope?"
+    Recommendation: If constraints exist, suggest what to cut first.
+  - "Does this interact with existing features? Which ones?"
+    Recommendation: Based on codebase scan, identify integration points.
+
+  After this round, you should be able to state the scope in one sentence.
+  Display: "Scope summary: {one sentence}. Does this match your intent?"
+
+  Record all answers in the decisions log.
+</step>
+
+<step name="validate_approach" priority="fourth">
+  Choosing the wrong approach is the most expensive mistake — it compounds through every downstream phase. Presenting options with trade-offs prevents blind commitment to the first idea.
+
+  Based on the problem and scope, identify 2-3 viable technical approaches.
+
+  Present each approach:
+  ```
+  Approach A (recommended): {description}
+  - Effort: {low/medium/high}
+  - Risk: {what could go wrong}
+  - Maintenance: {ongoing burden}
+  - Fits existing patterns: {yes/no — reference specific codebase patterns}
+
+  Approach B: {description}
+  - Effort: {low/medium/high}
+  - Risk: {what could go wrong}
+  - Maintenance: {ongoing burden}
+  - Fits existing patterns: {yes/no}
+
+  Approach C (do nothing / defer): {description}
+  - Risk of deferring: {what happens}
+  ```
+
+  Ask: "Which approach do you prefer? I recommend Approach A because {concrete reason}."
+
+  IF the user picks a non-recommended approach:
+    Acknowledge the choice. Do not argue. Record the rationale.
+
+  IF the user is unsure:
+    Ask one targeted follow-up to resolve the uncertainty.
+
+  Record the chosen approach and rationale in the decisions log.
+</step>
+
+<step name="detail_requirements" priority="fifth">
+  Requirements bridge the gap between "what to build" and "how to spec it." Missing requirements surface as bugs during implementation.
+
+  Ask 2-4 questions from this category. Include a recommendation with each.
+
+  REQUIREMENTS QUESTIONS (pick the most relevant):
+  - "Walk me through the primary user flow. What does the user do step by step?"
+    Recommendation: Propose a flow based on the chosen approach.
+  - "What are the edge cases? What happens when {unlikely but possible scenario}?"
+    Recommendation: List 2-3 edge cases you identified and propose handling.
+  - "Are there security, performance, or accessibility requirements?"
+    Recommendation: Based on project context, suggest relevant NFRs.
+  - "How will you know this works? What does success look like?"
+    Recommendation: Propose measurable success criteria.
+  - "What data does this feature need? New models, fields, or API endpoints?"
+    Recommendation: Based on codebase, suggest data model approach.
+
+  STOP ASKING SIGNAL:
+  - You can write functional requirements for the core flow.
+  - You can list at least 3 edge cases with expected behavior.
+  - You know the primary user flow end to end.
+  - Remaining unknowns are implementation details, not requirements.
+
+  IF clarity is sufficient after round 2 or 3, skip this round and proceed to compile.
+
+  Record all answers in the decisions log.
+</step>
+
+<step name="compile_prd" priority="sixth">
+  The PRD is the deliverable — it captures every decision made during discussion. Without it, the discussion is just a conversation that evaporates.
+
+  Create .sdlc/discuss/ directory if it does not exist.
+
+  Generate a topic slug from the seed idea: lowercase, hyphens, no special characters, max 40 chars.
+
+  Write .sdlc/discuss/{topic-slug}-PRD.md using the PRD template structure:
+  - Problem Statement: from explore_problem answers
+  - Proposed Solution: from validate_approach chosen approach
+  - Alternatives Considered: from validate_approach rejected approaches
+  - Requirements: from detail_requirements answers
+  - Constraints: from define_scope answers
+  - Edge Cases: from detail_requirements answers
+  - Success Metrics: from detail_requirements answers
+  - Decisions Log: every question asked and answer received, numbered
+
+  Display a compact summary of the PRD (30-50 lines):
+  - Problem (2 lines)
+  - Solution (2 lines)
+  - Requirements (numbered list)
+  - Constraints (list)
+  - Edge cases (list)
+  - Open questions (list)
+</step>
+
+<step name="approve_and_route" priority="seventh">
+  The user must approve the PRD before it feeds into spec. An unapproved PRD is just notes.
+
+  Ask: "PRD complete. Review the summary above."
+  Present options:
+  - APPROVE: Lock the PRD and proceed to /sdlc:spec
+  - REVISE: Tell me what to change (re-compile after changes)
+  - REJECT: Discard the PRD and stop
+
+  IF APPROVE:
+    Set PRD status to APPROVED.
+    Update .sdlc/STATE.md:
+    - Add history entry: "{timestamp} | discuss | Topic: {topic}. PRD saved."
+    - Set next_required_action: /sdlc:spec
+    - Add prd_path: .sdlc/discuss/{topic-slug}-PRD.md
+
+    Display:
+    ```
+    PRD approved.
+
+    Saved: .sdlc/discuss/{topic-slug}-PRD.md
+
+    The spec phase will use this PRD to create a detailed specification with
+    acceptance criteria and task dependencies.
+
+    NEXT ACTION REQUIRED: /sdlc:spec
+    Run /sdlc:spec to formalize this PRD into an implementation-ready specification.
+    ```
+
+  IF REVISE:
+    Apply changes. Re-display summary. Re-ask for approval.
+
+  IF REJECT:
+    Delete the PRD file. Display: "PRD discarded." Stop.
+</step>
+
+</process>

package/src/workflows/fast-forward.md

@@ -1,10 +1,10 @@
-<purpose>The universal entry point workflow. Accept a plain language description, classify the work, estimate complexity, and either execute inline (simple work) or route to the appropriate specialized command (complex work, bugs, research, hotfixes). This is the "just tell me what to do" workflow.</purpose>
+<purpose>The universal entry point workflow. Accept a plain language description, classify the work, estimate complexity, and either execute inline (simple work), handle critical issues as inline hotfixes, or route to the appropriate specialized command. This is the "just tell me what to do" workflow.</purpose>
 <when_to_use>Use anytime. This is the default way to start work. The user describes what they need, and this workflow figures out the rest. No prior knowledge of SDLC commands required.</when_to_use>
 <required_reading>.sdlc/STATE.md, .sdlc/PROJECT.md, .sdlc/LAWS.md</required_reading>
 <loop_context>
-  expected_phase: FAST (compressed loop or routing)
+  expected_phase: FAST (compressed loop, inline hotfix, or routing)
   prior_phase: any (fast can be used between loops or as the first action)
-  next_phase: depends on routing — SPEC, DEBUG, HOTFIX, RESEARCH, or self-contained
+  next_phase: depends on routing — SPEC, DEBUG, RESEARCH, DISCUSS, or self-contained
 </loop_context>
 <references>
 @~/.claude/sdlc-framework/references/prompt-detection.md
@@ -49,10 +49,9 @@
 
   1. CRITICAL — urgent production issues
      Indicators: "urgent", "production", "down", "outage", "critical", "P0", "hotfix", "emergency", "ASAP"
-     Route: /sdlc:hotfix
-     Display: "Critical issue detected. Routing to /sdlc:hotfix for emergency handling."
-     Write to STATE.md: fast_context = {original description}
-     STOP this workflow.
+     Route: inline hotfix (skip to inline_hotfix step)
+     Display: "Critical issue detected. Running inline hotfix — minimal spec, full verification."
+     Do NOT stop — proceed to inline_hotfix step.
 
   2. BUG — something broken that needs debugging
      Indicators: "fix bug", "broken", "crash", "error when", "fails to", "wrong output", "regression", "not working", "throws", "exception"
@@ -337,4 +336,56 @@
   WHY: Fast is a side-quest. It records what happened (audit trail) but does not disrupt the main loop state.
 </step>
 
+<step name="inline_hotfix" priority="tenth">
+  ONLY IF classification = CRITICAL. Emergency fix with minimal ceremony, maximum verification.
+
+  A. TRIAGE:
+  Ask 3 questions:
+  - "What is broken? (specific symptom)"
+  - "What is the impact? (who is affected)"
+  - "When did it start? (recent deploy, config change)"
+
+  Classify severity:
+  - P0: system down, critical path unavailable
+  - P1: data corruption, security breach, data loss
+  - P2: major feature broken but system is up
+
+  If not P0/P1: Display "This may not be critical. Consider /sdlc:debug instead." Let user override.
+
+  Save current STATE.md position — hotfix restores it when done.
+
+  B. 3-LINE INLINE SPEC:
+  - Line 1: WHAT is broken (from triage)
+  - Line 2: WHERE is the likely location (quick Grep search)
+  - Line 3: WHAT the fix should achieve (expected behavior)
+  Display but do NOT wait for approval — speed matters.
+  Boundary: fix ONLY the critical issue. No refactoring. No cleanup.
+
+  C. FIX DIRECTLY:
+  - Single-threaded, no sub-agents
+  - Read relevant files, apply MINIMAL fix
+  - Engineering laws still apply (no empty catch, no hardcoded secrets)
+  - Add regression test for the specific failure
+  - Mark debt with TODO(hotfix-{date})
+
+  D. FULL VERIFICATION:
+  - Run FULL test suite (all tests, not just affected)
+  - For UI: Playwright verification
+  - If any fail: fix before proceeding
+
+  E. FULL REVIEW:
+  - Check all modified files against engineering laws
+  - Security blockers still block even in emergencies
+  - Warnings acceptable for hotfixes
+
+  F. RECORD:
+  - Hotfix number = {phase}.{count+1} (e.g., 02.1, 02.2)
+  - Create .sdlc/phases/{phase}/HOTFIX-{number}-SUMMARY.md
+  - Update STATE.md: restore prior state, add history entry
+  - Update ROADMAP.md: note hotfix under current phase
+  - Display completion summary with verification results
+
+  WHY: Hotfixes trade planning ceremony for speed, but never trade verification or review. The inline approach avoids command-switching overhead during emergencies while maintaining quality gates.
+</step>
+
 </process>

package/src/workflows/init-project.md

@@ -152,7 +152,7 @@
   | ... | ... | ... | ... |
 
   ## Future Milestones
-  {Leave blank — added via /sdlc:milestone}
+  {Leave blank — added via /sdlc:init milestone <name>}
   ```
 
   WHY: The roadmap gives structure to the work. Without it, specs are disconnected tasks with no arc. The phase structure ensures work builds on itself in a logical order.

package/src/workflows/status-session.md

@@ -0,0 +1,206 @@
+<purpose>Show loop position, save session context (pause), or restore session context (resume). Consolidates status, pause, and resume into a single workflow. The state machine always knows the next action — this workflow surfaces it.</purpose>
+<when_to_use>Run anytime. No-arg for status. "pause" before a break. "resume" when returning. Can run at any loop position.</when_to_use>
+<required_reading>.sdlc/STATE.md, .sdlc/ROADMAP.md</required_reading>
+<loop_context>
+  expected_phase: any (status/pause/resume work at any loop position)
+  prior_phase: current position is preserved
+  next_phase: determined by STATE.md
+</loop_context>
+<process>
+
+<step name="determine_mode" priority="first">
+  Parse $ARGUMENTS to determine the mode.
+
+  IF $ARGUMENTS is empty or not "pause"/"resume": MODE = STATUS
+  IF $ARGUMENTS starts with "pause": MODE = PAUSE. Extract optional reason.
+  IF $ARGUMENTS starts with "resume": MODE = RESUME. Extract optional handoff path.
+
+  Read .sdlc/STATE.md.
+
+  IF .sdlc/ does not exist:
+    Display: "Framework not initialized. Run /sdlc:init first."
+    STOP.
+
+  Extract: loop_position, current_milestone, current_phase, current_plan, next_required_action, blockers, deferred_issues.
+
+  WHY: One entry point with three modes eliminates the need for three separate commands. The state file is the single source of truth regardless of mode.
+</step>
+
+<step name="show_status" priority="second">
+  ONLY IF MODE = STATUS.
+
+  Read .sdlc/ROADMAP.md for milestone progress data.
+
+  Display the core loop with current position highlighted:
+  ```
+  SDLC Loop Position:
+
+    SPEC ──→ IMPLEMENT ──→ VERIFY ──→ REVIEW ──→ CLOSE
+     │                                              │
+     └──────────────── next cycle ←─────────────────┘
+
+    Current: [IMPLEMENT] ◄── YOU ARE HERE
+  ```
+
+  Use `[PHASE]` brackets around the current position.
+  If in DEBUG, show as a side branch off IMPLEMENT.
+
+  Display project context:
+  ```
+  Milestone: {name} ({completed_phases}/{total_phases} phases)
+  Phase:     {name}
+  Plan:      {name or "none — run /sdlc:spec"}
+  ```
+
+  Calculate and display progress bar from ROADMAP.md:
+  ```
+  Progress: [████████░░░░░░░░░░░░] 40% (4/10 plans completed)
+  ```
+
+  Show blockers and deferred issues (or "No blockers. No deferred issues.").
+
+  Force ONE next action from loop_position with explanation:
+  ```
+  NEXT ACTION REQUIRED: /sdlc:impl
+
+  What it does: Implements the current plan by writing code with subagent workers.
+  Why it is next: The spec phase is complete. The plan has been approved.
+  ```
+
+  WHY: Status is the "where am I" command. Junior developers need the visual. Senior developers need the forced next action. Both get what they need.
+</step>
+
+<step name="pause_gather_context" priority="third">
+  ONLY IF MODE = PAUSE.
+
+  Gather session context:
+
+  A. GIT STATE:
+     Run: git status --short (if git repo)
+     Run: git log --oneline -5
+
+  B. WORK COMPLETED THIS SESSION:
+     Read STATE.md history entries. Summarize recent work.
+
+  C. IN-PROGRESS WORK:
+     Read any active spec, review, or summary files referenced in STATE.md.
+     Determine: which tasks done, which pending, which ACs verified.
+
+  D. DECISIONS AND BLOCKERS:
+     Scan recent .sdlc/ files for recorded decisions.
+     Note any blockers from STATE.md.
+
+  E. USER CONTEXT:
+     Ask: "Anything to remember for next session not already in files? (or press enter to skip)"
+     Record response if provided.
+
+  WHY: Session context is ephemeral — conversation history may not survive. The handoff captures it before it is lost.
+</step>
+
+<step name="pause_save" priority="fourth">
+  ONLY IF MODE = PAUSE.
+
+  Create .sdlc/HANDOFF.md (overwrite if exists):
+  ```markdown
+  # Session Handoff
+
+  ## Session Info
+  - **Paused at**: {ISO timestamp}
+  - **Reason**: {from arguments or "manual pause"}
+  - **Loop position**: {from STATE.md}
+  - **Next required action**: {from STATE.md}
+
+  ## What Was Done This Session
+  {Bulleted list of work completed}
+
+  ## Current State
+  - **Phase**: {phase name and number}
+  - **Plan**: {plan number and title, or "no active plan"}
+  - **Loop step**: {position} — {status}
+
+  ## In-Progress Work
+  {What is partially done — specific tasks, files, ACs}
+
+  ## Decisions Made
+  {List of decisions with rationale}
+
+  ## Blockers / Open Questions
+  {List or "None"}
+
+  ## User Context
+  {Verbatim notes from the user, if any}
+
+  ## Git State
+  - **Branch**: {current branch}
+  - **Commit**: {latest commit hash and message}
+  - **Uncommitted changes**: {yes/no — details}
+  ```
+
+  IF UNCOMMITTED CHANGES EXIST:
+    Ask: "You have uncommitted changes. Create a WIP commit? (yes/no)"
+    If yes: stage relevant files (not .env), commit "wip({phase}): {brief description}"
+    If no: note in handoff that uncommitted changes exist.
+
+  Update STATE.md: add paused_at timestamp, history entry. Do NOT change loop_position.
+
+  Display:
+  ```
+  Session saved.
+
+  Handoff: .sdlc/HANDOFF.md
+  State: {loop_position}
+  Next action (on resume): {next_required_action}
+
+  When you return, run /sdlc:status resume
+  ```
+
+  WHY: HANDOFF.md bridges sessions. The explicit resume instruction ensures the next session starts correctly.
+</step>
+
+<step name="resume_restore" priority="fifth">
+  ONLY IF MODE = RESUME.
+
+  A. LOCATE HANDOFF:
+     If path in $ARGUMENTS: use that file.
+     Else if .sdlc/HANDOFF.md exists: use it.
+     Else: display "No handoff found. Resuming from STATE.md." Skip to next-action determination.
+
+  B. READ AND DISPLAY CONTEXT:
+     Read handoff. Calculate time since pause.
+     ```
+     === SESSION RESUMED ===
+
+     Last session: {time} ago
+     Loop position: {position}
+
+     Work in progress:
+     - {from handoff}
+
+     Decisions:
+     - {from handoff}
+
+     Blockers:
+     - {from handoff, or "None"}
+     ```
+
+     If blockers: ask "These blockers were noted. Are they resolved?"
+
+  C. VERIFY GIT STATE:
+     Run: git status
+     Compare branch and uncommitted changes to handoff.
+     If branch changed: warn.
+     If new commits since pause: display them.
+
+  D. ARCHIVE HANDOFF:
+     Rename .sdlc/HANDOFF.md to .sdlc/HANDOFF-{timestamp}.md.archived
+     Remove paused_at from STATE.md.
+     Add history entry: "{timestamp} | resume | Resumed from {loop_position}."
+
+  E. FORCE NEXT ACTION:
+     Determine from STATE.md next_required_action.
+     Display: "NEXT ACTION REQUIRED: {action}"
+
+  WHY: Exactly ONE next action. The state machine has already decided. The user just executes it.
+</step>
+
+</process>

package/src/workflows/transition-phase.md

@@ -113,7 +113,7 @@
   IF NO NEXT PHASE (this was the last phase in the milestone):
     Update .sdlc/STATE.md:
     - loop_position: TRANSITION ✓
-    - next_required_action: /sdlc:milestone complete
+    - next_required_action: /sdlc:close (milestone completion handled inline)
     - Add history entry: "{timestamp} | transition | Phase {current} complete. Last phase in milestone. Trigger milestone completion."
 
     Update .sdlc/ROADMAP.md:
@@ -193,8 +193,8 @@
     Completed: Phase {number} — {name} (LAST PHASE)
     Milestone {milestone-number} — {milestone-name}: ALL PHASES COMPLETE
 
-    NEXT ACTION REQUIRED: /sdlc:milestone complete
-    Run /sdlc:milestone complete to finalize the milestone.
+    NEXT ACTION REQUIRED: /sdlc:close
+    Run /sdlc:close to finalize the milestone.
     ```
 
   WHY: The display makes the transition visible. Moving to a new phase is a significant moment — the user should know where they are in the broader plan.