sdlc-framework 1.0.2 → 2.0.0

package/src/commands/hotfix.md

@@ -1,99 +0,0 @@
----
-name: sdlc:hotfix
-description: "Emergency fix with minimal ceremony, maximum verification"
-argument-hint: "<critical-issue>"
-allowed-tools: [Read, Write, Bash, Glob, Grep, Edit, mcp__plugin_playwright_playwright__browser_navigate, mcp__plugin_playwright_playwright__browser_snapshot, mcp__plugin_playwright_playwright__browser_click, mcp__plugin_playwright_playwright__browser_fill_form, mcp__plugin_playwright_playwright__browser_take_screenshot, mcp__plugin_playwright_playwright__browser_evaluate, mcp__plugin_playwright_playwright__browser_console_messages, mcp__plugin_playwright_playwright__browser_close, AskUserQuestion]
----
-
-<objective>
-Emergency fix for critical issues. Minimal ceremony getting to the fix. Maximum verification after the fix. No corners cut on quality — only on planning overhead.
-
-**When to use:** Production is broken. A critical path is failing. Security vulnerability discovered. Something that cannot wait for a full SPEC cycle.
-
-**What it does:**
-1. Skip full spec — create a lightweight inline spec (3 lines).
-2. Fix the issue directly.
-3. Run FULL verification (tests + Playwright).
-4. Run FULL review (engineering laws compliance).
-5. Record as a hotfix with decimal phase numbering (2.1, 2.2, etc.).
-
-**What happens next:** /sdlc:verify to run the full verification suite.
-</objective>
-
-<execution_context>
-@~/.claude/sdlc-framework/workflows/hotfix.md
-@.sdlc/STATE.md
-@.sdlc/LAWS.md
-</execution_context>
-
-<context>
-$ARGUMENTS
-
-Read .sdlc/STATE.md to get current milestone and phase.
-Read .sdlc/LAWS.md — hotfixes are NOT exempt from engineering laws.
-</context>
-
-<process>
-Follow workflow: @~/.claude/sdlc-framework/workflows/hotfix.md
-
-Step-by-step:
-
-1. **Pre-flight check**
-   - Verify .sdlc/ exists. If not, tell the user to run /sdlc:init first.
-   - Read .sdlc/STATE.md to get current phase number (e.g., phase 2).
-   - Assign hotfix number: current phase + decimal increment (2.1, 2.2, etc.).
-   - Update STATE.md: set loop_position to HOTFIX, record hotfix number.
-
-2. **Lightweight inline spec (3 lines)**
-   - Line 1: WHAT is broken. (From $ARGUMENTS.)
-   - Line 2: WHERE is the likely location. (Quick search with Grep.)
-   - Line 3: WHAT the fix should achieve. (Expected behavior.)
-   - Record this inline spec in STATE.md under the hotfix entry.
-
-3. **Fix the issue**
-   - Search for the affected code using Grep and Read.
-   - Apply the fix. Follow engineering laws:
-     - DRY: use existing patterns.
-     - Handle edge cases.
-     - Named types for complex objects.
-     - No lint suppression. No non-null assertions.
-     - Max 40 lines per function.
-   - Keep the change surface as small as possible. Fix the issue, nothing more.
-
-4. **Full verification**
-   - Run the entire test suite. Not just affected tests — ALL tests.
-   - For UI-related hotfixes:
-     - Use Playwright to navigate to affected pages.
-     - Verify the fix visually with screenshots.
-     - Check console for errors.
-     - Test the happy path AND edge cases.
-   - If tests fail: fix the test failures before proceeding. Do not skip.
-
-5. **Full review against engineering laws**
-   - Read .sdlc/LAWS.md.
-   - Check every changed line against every applicable law.
-   - Verify: no dead code introduced, no unused imports, no inline complex types.
-   - If any law is violated: fix it. Hotfixes are not exempt.
-
-6. **Record in STATE.md**
-   - Update .sdlc/STATE.md:
-     - Record hotfix number (decimal: 2.1, 2.2, etc.).
-     - Record: issue description, files changed, tests run, verification status.
-     - Set loop_position back to current phase position.
-   - Create .sdlc/hotfixes/HOTFIX-{number}-{timestamp}.md with full details.
-
-7. **Force next action**
-   - Output: "NEXT ACTION REQUIRED: /sdlc:verify — run full verification suite to confirm no regressions."
-</process>
-
-<success_criteria>
-- [ ] Inline spec created (3 lines: what, where, expected behavior)
-- [ ] Fix applied following engineering laws — no exceptions for hotfixes
-- [ ] Full test suite runs and passes
-- [ ] Playwright verification completed for UI-related hotfixes
-- [ ] Engineering laws review passed on all changed code
-- [ ] Hotfix recorded in STATE.md with decimal phase numbering
-- [ ] Hotfix detail file created in .sdlc/hotfixes/
-- [ ] Change surface is minimal — only the fix, nothing extra
-- [ ] Output ends with NEXT ACTION REQUIRED: /sdlc:verify
-</success_criteria>

package/src/commands/milestone.md

@@ -1,136 +0,0 @@
----
-name: sdlc:milestone
-description: "Create or complete project milestones"
-argument-hint: "[create <name> | complete]"
-allowed-tools: [Read, Write, Bash, Glob, Grep, AskUserQuestion]
----
-
-<objective>
-Manage project milestones. Create new milestones with scope definition. Complete milestones with verification, archival, and tagging.
-
-**When to use:**
-- Starting a new body of work: `/sdlc:milestone create <name>`
-- Finishing a milestone: `/sdlc:milestone complete`
-- Checking milestone status: `/sdlc:milestone` (no argument)
-
-**What it does:**
-- **No argument:** Show current milestone status, phases, and progress.
-- **create:** Ask clarification questions about scope, then create milestone with phases.
-- **complete:** Verify all phases done, archive, update ROADMAP.md, create git tag.
-
-**What happens next:**
-- After create: /sdlc:spec to define the first unit of work.
-- After complete: Completion summary displayed.
-</objective>
-
-<execution_context>
-@~/.claude/sdlc-framework/workflows/milestone.md
-@.sdlc/STATE.md
-@.sdlc/ROADMAP.md
-</execution_context>
-
-<context>
-$ARGUMENTS — one of: empty, "create <name>", or "complete".
-
-Read .sdlc/STATE.md for current milestone.
-Read .sdlc/ROADMAP.md for milestone definitions and progress.
-</context>
-
-<process>
-Follow workflow: @~/.claude/sdlc-framework/workflows/milestone.md
-
-Step-by-step:
-
-### If no argument: SHOW STATUS
-
-1. Read .sdlc/ROADMAP.md.
-2. Read .sdlc/STATE.md for current milestone.
-3. Display:
-   ```
-   Current Milestone: {name}
-   Status: {in-progress | blocked}
-
-   Phases:
-   [x] Phase 1: {name} — completed
-   [x] Phase 2: {name} — completed
-   [ ] Phase 3: {name} — in progress (3/5 plans done)
-   [ ] Phase 4: {name} — not started
-
-   Progress: [████████████░░░░░░░░] 60%
-   ```
-4. Show the next required action based on current loop position.
-
-### If "create <name>": CREATE MILESTONE
-
-1. Parse the milestone name from $ARGUMENTS.
-2. Ask clarification questions via AskUserQuestion:
-   - "What is the objective of this milestone? (1-2 sentences)"
-   - "What are the key deliverables? (list 3-5)"
-   - "What does 'done' look like? (acceptance criteria)"
-   - "Estimated number of phases? (suggest based on deliverables)"
-3. Create the milestone in .sdlc/ROADMAP.md:
-   ```
-   ## Milestone: {name}
-   Objective: {from answer}
-   Status: in-progress
-
-   ### Phases
-   - Phase 1: {derived from deliverables}
-   - Phase 2: {derived from deliverables}
-   ...
-
-   ### Acceptance Criteria
-   - {from answer}
-   ```
-4. Update .sdlc/STATE.md:
-   - Set current_milestone to the new milestone name.
-   - Set current_phase to Phase 1.
-   - Set loop_position to SPEC.
-5. Output: "NEXT ACTION REQUIRED: /sdlc:spec — define the first unit of work for Phase 1."
-
-### If "complete": COMPLETE MILESTONE
-
-1. Read .sdlc/STATE.md and .sdlc/ROADMAP.md.
-2. Verify ALL phases in the current milestone are marked complete.
-   - If any phase is incomplete, output: "Cannot complete milestone. Phase {N}: {name} is not done. Complete it first." Then stop.
-3. Archive the milestone:
-   - Create .sdlc/archive/MILESTONE-{name}-{timestamp}.md with full milestone data.
-   - Mark the milestone as `completed` in ROADMAP.md with completion timestamp.
-4. Update ROADMAP.md:
-   - Set milestone status to `completed`.
-   - If there is a next milestone, note it.
-5. Create a git tag:
-   - Run `git tag -a milestone/{name} -m "Milestone completed: {name}"`.
-   - If git is not initialized or tag fails, warn but continue.
-6. Update STATE.md:
-   - Clear current_milestone if no next milestone.
-   - Or set current_milestone to the next milestone and loop_position to SPEC.
-7. Output completion summary:
-   ```
-   Milestone Complete: {name}
-
-   Phases completed: {N}
-   Plans executed: {N}
-   Hotfixes applied: {N}
-   Git tag: milestone/{name}
-
-   {If next milestone exists}
-   Next milestone: {name}
-   Run /sdlc:spec to begin.
-
-   {If no next milestone}
-   All milestones complete. Define new milestones with /sdlc:milestone create <name>.
-   ```
-</process>
-
-<success_criteria>
-- [ ] No argument: milestone status displayed with phase progress
-- [ ] Create: clarification questions asked, milestone added to ROADMAP.md, STATE.md updated
-- [ ] Create: output ends with NEXT ACTION REQUIRED: /sdlc:spec
-- [ ] Complete: all phases verified as done before completing
-- [ ] Complete: milestone archived to .sdlc/archive/
-- [ ] Complete: ROADMAP.md updated with completion status
-- [ ] Complete: git tag created
-- [ ] Complete: STATE.md updated for next milestone (or cleared)
-- [ ] No guessing — all scope gathered via clarification questions
-</success_criteria>

package/src/commands/pause.md

@@ -1,115 +0,0 @@
----
-name: sdlc:pause
-description: "Save context for session break"
-argument-hint: "[reason]"
-allowed-tools: [Read, Write, Bash, Glob, Grep, AskUserQuestion]
----
-
-<objective>
-Save complete session context so you can walk away and pick up exactly where you left off. Creates a HANDOFF.md that captures everything the next session needs.
-
-**When to use:** You need to take a break, switch tasks, or end your session. Run this before closing your terminal.
-
-**What it does:**
-1. Detect current loop position from STATE.md.
-2. Gather all context: work done, decisions made, blockers, in-progress tasks.
-3. Create HANDOFF.md with everything needed to resume.
-4. Optionally create a WIP git commit.
-5. Tell you exactly how to resume.
-
-**What happens next:** When you return, run /sdlc:resume.
-</objective>
-
-<execution_context>
-@~/.claude/sdlc-framework/workflows/pause-resume.md
-@.sdlc/STATE.md
-</execution_context>
-
-<context>
-$ARGUMENTS — optional reason for pausing (e.g., "end of day", "switching to urgent task").
-
-Read .sdlc/STATE.md to detect current loop position and active work.
-</context>
-
-<process>
-Follow workflow: @~/.claude/sdlc-framework/workflows/pause-resume.md
-
-Step-by-step:
-
-1. **Read current state**
-   - Read .sdlc/STATE.md to get:
-     - Current loop_position (SPEC, IMPLEMENT, VERIFY, REVIEW, CLOSE, DEBUG, HOTFIX).
-     - Current milestone and phase.
-     - Current plan (if any).
-     - Any recorded blockers.
-
-2. **Gather session context**
-   - Check git status for uncommitted changes (`git status --short`).
-   - Check git log for recent commits in this session (`git log --oneline -5`).
-   - Read any in-progress spec, plan, or task files referenced in STATE.md.
-   - Scan .sdlc/ for recently modified files (`find .sdlc -mmin -120 -type f`).
-
-3. **Create HANDOFF.md**
-   - Save to .sdlc/handoffs/HANDOFF-{timestamp}.md with:
-
-   ```
-   # Session Handoff — {timestamp}
-
-   ## Loop Position
-   {current loop_position} in {milestone} / {phase}
-
-   ## Work Completed This Session
-   - {list of completed tasks, commits, files changed}
-
-   ## Work In Progress
-   - {what was being worked on when paused}
-   - {current state of that work}
-
-   ## Decisions Made
-   - {any architectural or design decisions}
-
-   ## Blockers
-   - {anything preventing progress}
-
-   ## Uncommitted Changes
-   - {list of modified/untracked files from git status}
-
-   ## Resume Instructions
-   Run /sdlc:resume to continue.
-   The framework will pick up at: {loop_position}
-   Next action will be: {determined next action}
-   ```
-
-4. **Update STATE.md**
-   - Add session continuity section:
-     - `paused_at: {timestamp}`
-     - `pause_reason: {from $ARGUMENTS or "manual pause"}`
-     - `handoff_file: .sdlc/handoffs/HANDOFF-{timestamp}.md`
-   - Do NOT change loop_position — it stays where it was.
-
-5. **Offer WIP commit**
-   - Check if there are uncommitted changes.
-   - If yes, ask the user via AskUserQuestion:
-     "You have uncommitted changes. Create a WIP commit? (yes/no)"
-   - If yes: stage all changes and commit with message "WIP: {current task} [sdlc:pause]".
-   - If no: note in HANDOFF.md that uncommitted changes exist.
-
-6. **Output resume instructions**
-   - Print:
-     ```
-     Session paused. Context saved to .sdlc/handoffs/HANDOFF-{timestamp}.md
-
-     When you return, run: /sdlc:resume
-     ```
-   - Do not suggest any other actions. The only valid next step is /sdlc:resume.
-</process>
-
-<success_criteria>
-- [ ] Current loop position detected from STATE.md
-- [ ] All session context gathered (commits, changes, decisions, blockers)
-- [ ] HANDOFF.md created in .sdlc/handoffs/ with complete context
-- [ ] STATE.md updated with session continuity section
-- [ ] WIP commit offered if uncommitted changes exist
-- [ ] Output clearly states: "When you return, run /sdlc:resume"
-- [ ] No ambiguity — exactly one path forward
-</success_criteria>

package/src/commands/resume.md

@@ -1,103 +0,0 @@
----
-name: sdlc:resume
-description: "Restore context and continue with ONE next action"
-argument-hint: "[handoff-path]"
-allowed-tools: [Read, Write, Bash, Glob, Grep]
----
-
-<objective>
-Restore session context after a break and determine exactly ONE next action. No menus. No options. The framework decides what happens next.
-
-**When to use:** After running /sdlc:pause and returning to work. The framework picks up exactly where you left off.
-
-**What it does:**
-1. Read STATE.md and the most recent HANDOFF.md.
-2. Display: where you stopped, what was in progress, any blockers.
-3. Determine and force exactly ONE next action.
-4. Archive the consumed handoff.
-
-**What happens next:** The determined action. You do not choose — the framework routes you.
-</objective>
-
-<execution_context>
-@~/.claude/sdlc-framework/workflows/pause-resume.md
-@.sdlc/STATE.md
-</execution_context>
-
-<context>
-$ARGUMENTS — optional path to a specific handoff file. If not provided, use the most recent one.
-
-Read .sdlc/STATE.md for loop position and session continuity data.
-</context>
-
-<process>
-Follow workflow: @~/.claude/sdlc-framework/workflows/pause-resume.md
-
-Step-by-step:
-
-1. **Locate the handoff file**
-   - If $ARGUMENTS contains a path, use that file.
-   - Otherwise, read .sdlc/STATE.md for the `handoff_file` field.
-   - If no handoff_file in STATE.md, scan .sdlc/handoffs/ for the most recently modified file.
-   - If no handoff exists at all, output: "No handoff found. Check .sdlc/STATE.md for current position and run /sdlc:status." Then stop.
-
-2. **Read and display context**
-   - Read the handoff file.
-   - Read .sdlc/STATE.md.
-   - Display to the user:
-
-   ```
-   ## Session Restored
-
-   **Where you stopped:** {loop_position} in {milestone} / {phase}
-   **Paused at:** {timestamp}
-   **Reason:** {pause_reason}
-
-   ### Work In Progress
-   {from handoff}
-
-   ### Blockers
-   {from handoff, or "None"}
-
-   ### Uncommitted Changes
-   {from handoff — verify against current git status}
-   ```
-
-3. **Verify current state**
-   - Run `git status --short` to check if uncommitted changes match the handoff.
-   - If they do not match, warn: "Git state has changed since pause. Review before proceeding."
-   - Check if any WIP commit exists from the pause (`git log --oneline -3`).
-
-4. **Determine the ONE next action**
-   - Use the loop_position from STATE.md to determine the next action:
-     - `SPEC` → "NEXT ACTION REQUIRED: /sdlc:spec"
-     - `IMPLEMENT` → "NEXT ACTION REQUIRED: /sdlc:impl"
-     - `VERIFY` → "NEXT ACTION REQUIRED: /sdlc:verify"
-     - `REVIEW` → "NEXT ACTION REQUIRED: /sdlc:review"
-     - `CLOSE` → "NEXT ACTION REQUIRED: /sdlc:close"
-     - `DEBUG` → "NEXT ACTION REQUIRED: /sdlc:debug"
-     - `HOTFIX` → "NEXT ACTION REQUIRED: /sdlc:hotfix"
-   - If blockers exist, prepend: "BLOCKER: {blocker}. Resolve before proceeding."
-   - Output exactly ONE action. No alternatives. No menus.
-
-5. **Archive the consumed handoff**
-   - Move the handoff file to .sdlc/handoffs/archive/:
-     `mkdir -p .sdlc/handoffs/archive && mv {handoff_file} .sdlc/handoffs/archive/`
-   - Remove the `handoff_file` field from STATE.md session continuity section.
-   - Remove the `paused_at` and `pause_reason` fields.
-
-6. **Force the next action**
-   - Output the determined next action as the final line.
-   - Do not offer choices. The loop position dictates the action.
-</process>
-
-<success_criteria>
-- [ ] Handoff file located (from argument, STATE.md, or most recent)
-- [ ] Context displayed: loop position, work in progress, blockers
-- [ ] Git state verified against handoff (warn if mismatch)
-- [ ] Exactly ONE next action determined from loop_position
-- [ ] Handoff file archived to .sdlc/handoffs/archive/
-- [ ] STATE.md session continuity fields cleaned up
-- [ ] Output ends with NEXT ACTION REQUIRED: /sdlc:{action}
-- [ ] No menus, no options, no choices — one path forward
-</success_criteria>

package/src/workflows/hotfix-flow.md

@@ -1,190 +0,0 @@
-<purpose>Emergency fix workflow for critical production issues. Skips spec ceremony but enforces full verification and review. Tracked as a decimal sub-phase (e.g., 02.1) to maintain audit trail without disrupting the main phase sequence.</purpose>
-<when_to_use>Use ONLY for critical issues: production down, data corruption, security vulnerability, blocking bug affecting users NOW. For non-critical bugs, use /sdlc:debug instead.</when_to_use>
-<required_reading>.sdlc/STATE.md, .sdlc/PROJECT.md, .sdlc/LAWS.md</required_reading>
-<loop_context>
-  expected_phase: HOTFIX (emergency, interrupts main loop)
-  prior_phase: any (hotfix can interrupt at any point)
-  next_phase: VERIFY (hotfix still goes through verify and review)
-</loop_context>
-<process>
-
-<step name="accept_critical_issue" priority="first">
-  Receive the critical issue description.
-
-  Ask the user:
-  Question 1: "What is broken? (specific symptom)"
-  Question 2: "What is the impact? (who is affected, how badly)"
-  Question 3: "When did it start? (recent deploy, config change, external event)"
-
-  CLASSIFY SEVERITY:
-  - P0 (system down): entire service or critical path is unavailable
-  - P1 (data risk): data corruption, security breach, or data loss occurring
-  - P2 (major feature broken): core feature broken but system is up
-
-  IF severity is not P0 or P1: Display: "This does not appear critical. Consider using /sdlc:debug for structured debugging or /sdlc:fast for a quick fix."
-  Let the user override if they insist.
-
-  Save the current STATE.md position — hotfix must restore it when done.
-
-  WHY: Hotfix workflow trades ceremony for speed. That trade-off is only justified for critical issues. Overusing hotfix leads to unreviewed, untested changes accumulating.
-</step>
-
-<step name="create_inline_spec" priority="second">
-  Create a lightweight inline spec (no file — kept in memory for speed).
-
-  Inline spec:
-  ```
-  Hotfix: {title}
-  Severity: {P0|P1|P2}
-  Symptom: {what is broken}
-  Expected: {what should happen}
-  Files likely affected: {from initial analysis}
-  Acceptance criteria:
-    AC-1: GIVEN the fix is deployed WHEN {trigger action} THEN {correct behavior}
-    AC-2: GIVEN the fix is deployed WHEN regression tests run THEN all pass
-  Boundary: fix ONLY the critical issue. No refactoring. No cleanup. No "while I am here" changes.
-  ```
-
-  Display the inline spec to the user. Do NOT wait for approval — in an emergency, speed matters. But DO display it so the user can object if the scope is wrong.
-
-  WHY: Even emergencies get a spec — just a minimal one. Without it, the fix scope creeps and the hotfix becomes a feature.
-</step>
-
-<step name="fix_directly" priority="third">
-  Fix the issue directly. No sub-agents — hotfix is single-threaded for speed and control.
-
-  PROCESS:
-  1. Read the relevant files identified in the inline spec
-  2. If root cause is not immediately obvious, use binary search isolation (same as debug-flow)
-  3. Apply the MINIMAL fix — change as few lines as possible
-  4. Do NOT refactor. Do NOT clean up. Do NOT improve. Fix the bug ONLY.
-  5. Add a regression test for the specific failure scenario
-  6. Run the regression test — it must pass
-
-  RULES FOR HOTFIX CODE:
-  - Engineering laws still apply (no empty catch blocks, no hardcoded secrets)
-  - But scope is strictly limited to the fix
-  - Mark any technical debt created by the minimal fix with a TODO comment:
-    "TODO(hotfix-{date}): Clean up in next regular loop"
-  - These TODOs become tasks in the next spec
-
-  Record:
-  ```
-  Files modified: {list}
-  Lines changed: {count}
-  Root cause: {brief explanation}
-  Technical debt introduced: {yes/no — if yes, describe}
-  ```
-
-  WHY: Hotfixes are surgical. Minimal changes minimize risk of introducing new bugs. The TODO ensures debt is tracked and addressed, not forgotten.
-</step>
-
-<step name="full_verification" priority="fourth">
-  Run the SAME verification as verify-phase. No shortcuts.
-
-  FOR EACH AC in the inline spec:
-  1. Execute the verification (Playwright for UI, curl for API, test suite for logic)
-  2. Record PASS or FAIL with evidence
-
-  Additionally:
-  - Run the FULL test suite (not just related tests)
-  - A hotfix that breaks something else is worse than the original bug
-
-  IF ANY VERIFICATION FAILS:
-    Display: "Hotfix verification failed: {details}. The fix is incomplete or introduced a regression."
-    Return to fix step.
-
-  IF ALL PASS:
-    Proceed to review.
-
-  WHY: Hotfixes are the riskiest changes — rushed, minimal context, high pressure. Full verification is non-negotiable precisely because the process is compressed.
-</step>
-
-<step name="full_review" priority="fifth">
-  Run the SAME review as review-phase. No shortcuts.
-
-  Check all modified files against engineering laws.
-
-  The review is likely to find:
-  - WARN: minimal fix may not follow ideal patterns (acceptable for hotfix)
-  - INFO: TODO comments for technical debt (expected)
-
-  BUT BLOCKERS STILL BLOCK:
-  - Hardcoded secrets: BLOCKER (no exceptions, not even in emergencies)
-  - Empty catch blocks: BLOCKER
-  - SQL injection: BLOCKER
-
-  IF BLOCKERS: Fix them. Even in an emergency, security and error handling are non-negotiable.
-  IF CLEAN or WARNINGS ONLY: Proceed.
-
-  WHY: Security violations in hotfixes are especially dangerous because hotfixes often get deployed without the usual deployment review.
-</step>
-
-<step name="record_and_update_state" priority="sixth">
-  Create the hotfix record.
-
-  Determine the hotfix number:
-  - Read current phase number (e.g., "02")
-  - Count existing hotfixes: look for HOTFIX-*.md in the phase directory
-  - Hotfix number = {phase}.{hotfix-count + 1} (e.g., "02.1", "02.2")
-
-  Create .sdlc/phases/{current_phase}/HOTFIX-{number}-SUMMARY.md:
-  ```markdown
-  # Hotfix {number}: {title}
-
-  ## Issue
-  - **Severity**: {P0|P1|P2}
-  - **Symptom**: {what was broken}
-  - **Impact**: {who was affected}
-  - **Duration**: {how long the issue lasted, if known}
-
-  ## Root Cause
-  {Brief explanation}
-
-  ## Fix
-  - **Files modified**: {list}
-  - **Approach**: {what was changed}
-  - **Lines changed**: {count}
-
-  ## Verification
-  | AC | Status | Evidence |
-  |----|--------|----------|
-  | AC-1 | PASS | {evidence} |
-  | AC-2 | PASS | {evidence} |
-
-  ## Technical Debt
-  - {TODO items introduced by the minimal fix}
-  - These should be addressed in the next regular /sdlc:spec loop
-
-  ## Review
-  - Blockers: 0
-  - Warnings: {count}
-  ```
-
-  Update .sdlc/STATE.md:
-  - RESTORE the prior state (hotfix does not advance the main loop)
-  - Add history entry: "{timestamp} | hotfix | {severity}: {title}. {N} files modified. Debt: {yes/no}."
-
-  Update .sdlc/ROADMAP.md:
-  - Add a note under the current phase: "Hotfix {number}: {title} ({date})"
-
-  Display:
-  ```
-  Hotfix applied and verified.
-
-  Hotfix: {number}
-  Severity: {severity}
-  Files modified: {N}
-  Verification: PASSED
-  Review: PASSED ({N} warnings)
-  Technical debt: {description or "none"}
-
-  Record: .sdlc/phases/{phase}/HOTFIX-{number}-SUMMARY.md
-
-  State restored. Continue with: {prior next_required_action}
-  ```
-
-  WHY: Hotfixes are recorded separately from regular plans so they do not disrupt the plan numbering. The decimal notation (02.1) makes it clear this was an emergency intervention, not planned work.
-</step>
-
-</process>