sdlc-framework 1.0.0 → 2.0.0

package/src/workflows/impl-phase.md

@@ -1,4 +1,21 @@
-<purpose>Execute the specification through sub-agent driven parallel implementation. Each task from the spec becomes an independent agent with full context, engineering laws, and boundaries. Tasks run in dependency-ordered waves.</purpose>
+<purpose>Execute the specification through sub-agent driven parallel implementation. Each task from the spec becomes an independent agent with full context, engineering laws, and boundaries. Tasks run in dependency-ordered waves.
+
+╔══════════════════════════════════════════════════════════════════════╗
+║  MANDATORY: You MUST use the Agent tool to spawn sub-agents.        ║
+║  You MUST NOT implement tasks yourself in the main session.         ║
+║  Every task in the spec MUST be executed by a spawned Agent.        ║
+║  Use run_in_background: true for parallel wave execution.           ║
+║  Use TaskCreate/TaskUpdate to track each task's progress.           ║
+║  This is NON-NEGOTIABLE. Implementing inline violates the SDLC.    ║
+╚══════════════════════════════════════════════════════════════════════╝
+</purpose>
+<display_rule>
+  MANDATORY: Display ALL progress in the chat window. The developer monitors via chat, not files.
+  - Before spawning agents: display the full todo list with all tasks and their wave assignments.
+  - After each wave: display updated progress with ✅/🔄/⬚ status per task.
+  - After all waves: display final summary with files modified per task.
+  Keep displays compact (~15-30 lines). The developer sees progress without opening any files.
+</display_rule>
 <when_to_use>Run after /sdlc:spec completes. STATE.md must show loop_position = SPEC ✓ and next_required_action = /sdlc:impl.</when_to_use>
 <required_reading>.sdlc/STATE.md, the current SPEC.md, .sdlc/LAWS.md, .sdlc/PROJECT.md</required_reading>
 <loop_context>
@@ -93,10 +110,35 @@
 </step>
 
 <step name="execute_wave" priority="fifth">
+  ╔══════════════════════════════════════════════════════════════════════╗
+  ║  YOU MUST CALL THE Agent TOOL HERE. THIS IS NOT OPTIONAL.           ║
+  ║  DO NOT write code yourself. DO NOT skip agent spawning.            ║
+  ║  Every task = one Agent tool call with run_in_background: true.     ║
+  ║  All agents in the same wave MUST be spawned in ONE message.        ║
+  ╚══════════════════════════════════════════════════════════════════════╝
+
   FOR EACH WAVE (starting with Wave 1):
 
-  A. SPAWN AGENTS FOR ALL TASKS IN THIS WAVE:
-     For each task in the wave, spawn an agent with run_in_background: true.
+  A. CREATE TRACKABLE TODO LIST:
+     ╔══════════════════════════════════════════════════════════════════╗
+     ║  YOU MUST call TaskCreate for EVERY task. This creates a        ║
+     ║  visible, trackable todo list in the chat. The developer        ║
+     ║  monitors progress through this list. DO NOT SKIP.              ║
+     ╚══════════════════════════════════════════════════════════════════╝
+     For EACH task in the spec (ALL tasks, not just this wave):
+     - Call TaskCreate with: description = "Task {N}: {task-name} — {short action}"
+     This creates the full todo list upfront. The developer sees ALL tasks at once.
+
+     Then for each task in THIS WAVE, call TaskUpdate to set status = "in_progress".
+
+  B. SPAWN AGENTS FOR ALL TASKS IN THIS WAVE:
+     For each task in the wave, call the Agent tool with:
+     - description: "Implement: {task-name}" (short)
+     - run_in_background: true
+     - prompt: the full agent instruction below
+
+     CRITICAL: Spawn ALL agents for a wave in ONE single message.
+     Example for a 3-task wave — your message contains 3 Agent tool calls.
 
      Each agent instruction MUST include ALL of the following (no shortcuts):
 
@@ -138,14 +180,29 @@
   B. WAIT FOR ALL AGENTS IN THIS WAVE TO COMPLETE.
      Do NOT proceed to the next wave until every agent in the current wave has returned.
 
-  C. REVIEW WAVE RESULTS:
+  C. REVIEW WAVE RESULTS AND UPDATE TODO LIST:
      For each agent result:
      - Did it complete successfully?
      - Did it list modified files?
      - Did it report any issues or blockers?
 
+     For EACH completed task, call TaskUpdate to set status = "completed".
+     For EACH failed task, call TaskUpdate to set status = "failed".
+
+     DISPLAY the todo list progress in chat after EVERY wave:
+     ```
+     ── Implementation Progress ──────────────
+     ✅ Task 1: {name} — DONE ({N} files)
+     ✅ Task 2: {name} — DONE ({N} files)
+     🔄 Task 3: {name} — IN PROGRESS (wave 2)
+     ⬚ Task 4: {name} — PENDING (wave 3)
+     ──────────────────────────────────────────
+     Wave {N}/{total} complete. {N}/{total} tasks done.
+     ```
+
      IF ANY AGENT FAILED:
-       - Display: "Agent for task '{task-name}' failed: {error}"
+       - Call TaskUpdate to set failed task status = "failed"
+       - Display: "❌ Agent for task '{task-name}' failed: {error}"
        - Display the failure details
        - STOP. Do NOT proceed to next wave.
        - Ask user: "How do you want to proceed? Options:

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/review-phase.md

@@ -6,6 +6,12 @@
   prior_phase: VERIFY ✓
   next_phase: CLOSE
 </loop_context>
+<display_rule>
+  MANDATORY: Display the review findings in the chat window. The developer reads findings
+  in chat, not by opening REVIEW.md. Show: per-file findings table (file, line, law, severity,
+  description), blocker count, warning count, and the verdict (PASS/FAIL).
+  Keep it compact (~20-40 lines). Full details are in REVIEW.md for reference.
+</display_rule>
 <process>
 
 <step name="validate_state" priority="first">

package/src/workflows/spec-phase.md

@@ -6,6 +6,18 @@
   prior_phase: CLOSE (or INIT for first spec)
   next_phase: IMPL
 </loop_context>
+<display_rule>
+  MANDATORY: After writing ANY artifact (SPEC.md, REVIEW.md, SUMMARY.md), you MUST
+  display a COMPACT summary of the artifact in the chat window. The developer does NOT
+  have time to open files and read them. They monitor progress in the chat.
+
+  COMPACT means: key sections with content, NOT just section headers.
+  Show: objective (2 lines), tasks (numbered list with files), ACs (numbered Given/When/Then),
+  dependency graph (wave diagram), boundaries (list).
+
+  DO NOT dump the entire file verbatim — that bloats context. Show the substance in ~30-50 lines.
+  The full artifact is in the file for reference; the chat shows the actionable summary.
+</display_rule>
 <process>
 
 <step name="validate_state" priority="first">
@@ -256,41 +268,91 @@
 </step>
 
 <step name="spec_integrity_review" priority="eighth">
-  BEFORE updating state, perform a self-review of the spec for completeness and correctness.
+  ╔══════════════════════════════════════════════════════════════════════╗
+  ║  THIS STEP IS MANDATORY. DO NOT SKIP. DO NOT ABBREVIATE.           ║
+  ║  You MUST print the full integrity review table before proceeding.  ║
+  ╚══════════════════════════════════════════════════════════════════════╝
+
+  Re-read the SPEC.md file you just wrote. Perform ALL FIVE checks below.
+  For EACH check item, print ✓ (pass) or ✗ (fail) with explanation.
 
   CHECK 1 — COMPLETENESS:
-  - Every task has: name, action, files, verification, done criteria, complexity ✓ or ✗
-  - Every AC has: GIVEN, WHEN, THEN with specific values (not vague) ✓ or ✗
-  - Dependency graph accounts for all tasks ✓ or ✗
-  - Boundaries section is non-empty ✓ or ✗
-  - Required patterns section references actual existing files ✓ or ✗
+  For each task, verify it has ALL of these fields (print each):
+  - [ ] name (descriptive, kebab-case)
+  - [ ] action (imperative, specific — not vague like "implement the feature")
+  - [ ] files to modify (specific file paths, not "relevant files")
+  - [ ] verification (how to confirm — a command, a test, an observable outcome)
+  - [ ] done criteria (links to AC-N)
+  - [ ] complexity (LOW/MEDIUM/HIGH)
+  For each AC, verify it has ALL of these (print each):
+  - [ ] AC number (AC-1, AC-2, etc.)
+  - [ ] GIVEN with specific precondition (not "given the system is running")
+  - [ ] WHEN with specific action (not "when the user does something")
+  - [ ] THEN with specific observable outcome (not "then it works correctly")
 
   CHECK 2 — CONSISTENCY:
-  - Every task links to at least one AC (no orphan tasks)
-  - Every AC is covered by at least one task (no orphan ACs)
-  - File lists in tasks do not overlap with boundaries (no protected file modification)
-  - Task dependency graph has no cycles
-  - Parallel groups contain only truly independent tasks (no shared file writes)
-
-  CHECK 3 — FEASIBILITY:
-  - No single task exceeds HIGH complexity (60+ lines) — if so, suggest splitting
-  - Total task count is 2-5 per spec — if more, suggest splitting into multiple plans
-  - Estimated total change stays under ~300 lines — if more, warn user
-
-  IF ANY CHECK FAILS: Fix the spec before presenting for approval. Do not present a broken spec.
-
-  Present the integrity review results:
+  - [ ] Every task references at least one AC in its done criteria (no orphan tasks)
+  - [ ] Every AC is satisfied by at least one task (no orphan ACs)
+  - [ ] No task modifies a file listed in Boundaries/DO NOT CHANGE
+  - [ ] Dependency graph has no cycles (A→B→A)
+  - [ ] Tasks in the same parallel group do NOT write to the same file
+
+  CHECK 3 — CONTRADICTION DETECTION:
+  Compare every AC pair and every task pair for contradictions:
+  - [ ] No two ACs define conflicting behavior for the same input/state
+      Example contradiction: AC-1 says "return 404" but AC-3 says "return empty array" for missing resource
+  - [ ] No two tasks modify the same function/method with conflicting changes
+      Example contradiction: Task-1 adds validation to createUser, Task-2 removes validation from createUser
+  - [ ] No task action contradicts a boundary
+      Example contradiction: Boundary says "do not change auth logic" but Task-3 says "update auth middleware"
+  - [ ] No AC contradicts project constraints from PROJECT.md
+      Example contradiction: PROJECT.md says "REST API only" but AC-2 tests a GraphQL endpoint
+  - [ ] The acceptance criteria as a whole describe a coherent feature (not fragments that don't connect)
+
+  CHECK 4 — FEASIBILITY:
+  - [ ] No single task exceeds HIGH complexity (60+ lines) — if so, split it
+  - [ ] Total task count is 2-5 — if more, split into multiple plans
+  - [ ] Estimated total change under ~300 lines — if more, warn user
+  - [ ] All referenced files in tasks actually exist (or are marked as "create")
+
+  CHECK 5 — DEPENDENCY GRAPH VALIDITY:
+  - [ ] Every task appears in exactly one parallel group
+  - [ ] Wave ordering matches dependencies (no task in Wave 1 that depends on another task)
+  - [ ] Independent tasks (no shared files, no shared types) are correctly parallelized
+  - [ ] Dependent tasks (shared files, shared types/interfaces) are correctly sequenced
+
+  IF ANY CHECK ITEM FAILS:
+  1. List all failures with specific descriptions
+  2. Propose a fix for each failure
+  3. Apply all fixes to the SPEC.md
+  4. Re-run ALL five checks on the updated spec
+  5. Repeat until all checks pass
+
+  PRINT the full integrity review report:
   ```
-  Spec Integrity Review:
-  ✓ Completeness: All {N} tasks fully defined, {N} ACs with Given/When/Then
-  ✓ Consistency: All tasks linked to ACs, no boundary violations, no cycles
-  ✓ Feasibility: {N} tasks across {N} waves, estimated ~{N} lines of change
-
-  Issues found: {count}
-  {list any issues with suggested fixes}
+  ══════════════════════════════════════════════
+  SPEC INTEGRITY REVIEW
+  ══════════════════════════════════════════════
+  Completeness:      {✓ or ✗} — {details}
+  Consistency:       {✓ or ✗} — {details}
+  Contradictions:    {✓ or ✗} — {details or "none found"}
+  Feasibility:       {✓ or ✗} — {details}
+  Dependency Graph:  {✓ or ✗} — {details}
+
+  Tasks: {N} fully defined
+  ACs: {N} with specific Given/When/Then
+  Waves: {N} parallel execution groups
+  Estimated scope: ~{N} lines across {N} files
+
+  Contradictions found: {N}
+  {if any: list each contradiction and how it was resolved}
+
+  Issues found and fixed: {N}
+  {if any: list each issue and the fix applied}
+  ══════════════════════════════════════════════
   ```
 
-  WHY: A broken spec cascades failures through every downstream step. Catching spec issues here is 10x cheaper than catching them in review. This is the cheapest point to fix problems.
+  WHY: A spec with contradictions produces agents that build conflicting code. A spec with orphan ACs means untested features. A spec with invalid dependencies means agents wait forever or overwrite each other. This review catches all of these. It costs 30 seconds now and saves hours of debugging later.
 </step>
 
 <step name="user_approval_gate" priority="ninth">

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.

package/src/workflows/verify-phase.md

@@ -6,6 +6,13 @@
   prior_phase: IMPL ✓
   next_phase: REVIEW
 </loop_context>
+<display_rule>
+  MANDATORY: Display verification results in the chat window as a table. The developer
+  monitors pass/fail per AC in chat, not by opening files. Show:
+  | AC | Description | Type | Status | Evidence (1 line) |
+  Keep it compact. If Playwright screenshots were taken, mention the screenshot but
+  do not embed images — just note "screenshot captured."
+</display_rule>
 <process>
 
 <step name="validate_state" priority="first">
@@ -116,7 +123,18 @@
      - Include console errors in the evidence
      - Continue to next AC (do not stop on first failure)
 
-  WHY: Playwright MCP replaces manual UAT. Every UI acceptance criterion gets tested programmatically with screenshot evidence, making verification reproducible and auditable.
+  ╔══════════════════════════════════════════════════════════════════════╗
+  ║  YOU MUST USE THE PLAYWRIGHT MCP TOOLS FOR UI VERIFICATION.         ║
+  ║  DO NOT ask the user to manually test UI. DO NOT skip UI ACs.       ║
+  ║  Call: mcp__plugin_playwright_playwright__browser_navigate           ║
+  ║  Call: mcp__plugin_playwright_playwright__browser_snapshot           ║
+  ║  Call: mcp__plugin_playwright_playwright__browser_click              ║
+  ║  Call: mcp__plugin_playwright_playwright__browser_fill_form          ║
+  ║  Call: mcp__plugin_playwright_playwright__browser_take_screenshot    ║
+  ║  These are the ACTUAL tool names you must invoke.                   ║
+  ╚══════════════════════════════════════════════════════════════════════╝
+
+  WHY: Playwright MCP replaces manual UAT. Every UI acceptance criterion gets tested programmatically with screenshot evidence, making verification reproducible and auditable. NEVER fall back to "please test this manually."
 </step>
 
 <step name="verify_api_endpoints" priority="fifth">

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>