sdlc-framework 1.0.2 → 2.1.0

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>

package/src/workflows/milestone-management.md

@@ -1,169 +0,0 @@
-<purpose>Create new milestones or complete existing ones. Milestones are the highest-level organizational unit — they contain phases, which contain plans. This workflow manages the milestone lifecycle.</purpose>
-<when_to_use>Run to create a new milestone (/sdlc:milestone create) or complete an existing one (/sdlc:milestone complete). Also triggered automatically by transition-phase when the last phase in a milestone completes.</when_to_use>
-<required_reading>.sdlc/STATE.md, .sdlc/ROADMAP.md, .sdlc/PROJECT.md</required_reading>
-<loop_context>
-  expected_phase: MILESTONE (meta-workflow, operates above the loop)
-  prior_phase: varies
-  next_phase: SPEC (for new milestone) or none (project complete)
-</loop_context>
-<process>
-
-<step name="determine_operation" priority="first">
-  Determine whether the user wants to CREATE or COMPLETE a milestone.
-
-  IF explicitly specified (e.g., "/sdlc:milestone create" or "/sdlc:milestone complete"):
-    Use the specified operation.
-
-  IF not specified:
-    Read .sdlc/ROADMAP.md.
-    - If the current milestone has incomplete phases → likely COMPLETE is premature
-    - If the current milestone is done or no milestone is active → likely CREATE
-
-    Ask: "Do you want to:
-    A. Create a new milestone
-    B. Complete the current milestone ({name})
-    ?"
-
-  WHY: The two operations are very different. Creating sets up future work. Completing archives past work. Mixing them up would corrupt the state.
-</step>
-
-<step name="create_milestone" priority="second">
-  ONLY IF operation = CREATE.
-
-  A. GATHER MILESTONE INFO:
-
-  Question 1: "What is the milestone name? (e.g., 'MVP', 'Auth System', 'v2.0')"
-
-  Question 2: "What is the goal of this milestone? What will be true when it is done?"
-    - This becomes the milestone completion criteria
-    - Be specific: "Users can register, log in, and reset passwords" not "Auth works"
-
-  Question 3: "What phases make up this milestone? List 2-5 phases in order."
-    - Provide guidance: "Each phase should be a cohesive group of related work"
-    - Example: "Phase 01: Database Schema, Phase 02: API Endpoints, Phase 03: Frontend Forms"
-
-  Question 4: "Any dependencies on prior milestones? (e.g., requires 'MVP' milestone to be complete)"
-    - If yes: verify the dependency milestone is complete
-
-  Question 5: "Any rough timeline or priority? (optional)"
-
-  B. CALCULATE MILESTONE NUMBER:
-  Read ROADMAP.md. Count existing milestones. New milestone = max + 1, zero-padded to 2 digits.
-
-  C. CREATE PHASE DIRECTORIES:
-  For each phase in the new milestone:
-    mkdir -p .sdlc/phases/{phase-number}-{phase-name}
-
-  D. UPDATE ROADMAP.MD:
-  Add the new milestone section:
-  ```markdown
-  ## Milestone {number}: {name}
-  **Goal**: {goal}
-  **Status**: NOT STARTED
-  **Dependencies**: {list or "None"}
-
-  ### Phases
-  | Phase | Name | Status | Plans |
-  |-------|------|--------|-------|
-  | {NN} | {name} | NOT STARTED | 0 |
-  | {NN} | {name} | NOT STARTED | 0 |
-  ```
-
-  E. UPDATE STATE.MD:
-  - If no active milestone: set this as the current milestone
-  - Add history entry: "{timestamp} | milestone | Created milestone {number}: {name} with {N} phases"
-
-  Display:
-  ```
-  Milestone created: {number} — {name}
-
-  Phases:
-  1. {phase-name}
-  2. {phase-name}
-  ...
-
-  Directories created: .sdlc/phases/{phase-dirs}
-
-  NEXT ACTION REQUIRED: /sdlc:spec
-  Start the first phase with /sdlc:spec.
-  ```
-
-  WHY: Milestones provide the big-picture structure. Without them, phases are disconnected chunks of work with no clear endpoint.
-</step>
-
-<step name="complete_milestone" priority="third">
-  ONLY IF operation = COMPLETE.
-
-  A. VERIFY ALL PHASES ARE DONE:
-  Read ROADMAP.md. For the current milestone:
-  - List all phases
-  - Check each phase status: must be COMPLETE
-  - Check each phase directory: must have at least one SUMMARY.md
-
-  IF ANY PHASE IS INCOMPLETE:
-    STOP. Display: "Cannot complete milestone. Phase {N} ({name}) is not complete. Status: {status}."
-    List incomplete phases with their current status.
-
-  B. VERIFY STATE CONSISTENCY:
-  Cross-check:
-  - STATE.md milestone number matches ROADMAP.md current milestone
-  - STATE.md loop_position is CLOSE ✓ or ready for new spec
-  - No active plan is in progress
-
-  IF INCONSISTENCY FOUND:
-    Display: "State inconsistency detected: {details}. Run /sdlc:resume to reconcile."
-
-  C. GENERATE MILESTONE SUMMARY:
-  Read all SUMMARY.md files across all phases in this milestone.
-  Compile a milestone-level summary:
-
-  ```
-  Milestone {number}: {name}
-
-  Completed: {date}
-  Duration: {first spec date} to {last close date}
-  Phases: {count}
-  Plans executed: {total across all phases}
-  Hotfixes: {count, if any}
-
-  Deliverables:
-  - {consolidated list from all summaries}
-
-  Key decisions:
-  - {consolidated from all summaries}
-
-  Technical debt introduced:
-  - {from hotfixes and review warnings}
-  ```
-
-  D. ARCHIVE:
-  The milestone's phase directories remain in place (they are the historical record).
-  No files are moved or deleted.
-
-  E. GIT TAG (if git repository):
-  Ask user: "Create a git tag for this milestone? (recommended)"
-  If yes:
-    git tag -a "milestone-{number}-{name}" -m "Milestone {number}: {name} complete"
-  Display the tag name.
-
-  F. UPDATE ROADMAP.MD:
-  Set milestone status to COMPLETE with completion date.
-
-  G. UPDATE STATE.MD:
-  - Clear current milestone
-  - Add history entry: "{timestamp} | milestone | Completed milestone {number}: {name}. {N} phases, {N} plans."
-
-  H. DETERMINE NEXT MILESTONE:
-  Check ROADMAP.md for the next NOT STARTED milestone.
-
-  IF NEXT MILESTONE EXISTS:
-    Set it as current in STATE.md.
-    Display: "Milestone {number} complete. Next milestone: {next-number} — {next-name}. Run /sdlc:spec to begin."
-
-  IF NO NEXT MILESTONE:
-    Display: "Milestone {number} complete. No further milestones planned. Run /sdlc:milestone create to plan the next one, or the project may be complete."
-
-  WHY: Milestone completion is a significant checkpoint. The git tag marks a stable point. The summary captures institutional knowledge. Without completion, milestones just fade out with no clear ending.
-</step>
-
-</process>

package/src/workflows/pause-work.md

@@ -1,153 +0,0 @@
-<purpose>Save the current session state so work can be resumed later without context loss. Creates a HANDOFF.md that captures everything the next session needs to continue seamlessly.</purpose>
-<when_to_use>Run when ending a work session, switching context, or before a break. Can be run at any point in the loop — the state is preserved exactly as-is.</when_to_use>
-<required_reading>.sdlc/STATE.md</required_reading>
-<loop_context>
-  expected_phase: any (pause works at any loop position)
-  prior_phase: current position is preserved
-  next_phase: RESUME (the next session must run /sdlc:resume)
-</loop_context>
-<process>
-
-<step name="read_current_state" priority="first">
-  Read .sdlc/STATE.md. Capture:
-  - Current milestone, phase, plan
-  - Loop position (e.g., "IMPL ✓", "VERIFY in progress")
-  - Next required action
-  - Last history entry
-
-  WHY: The state machine is the primary context. Without it, the resume workflow does not know where to continue.
-</step>
-
-<step name="gather_session_context" priority="second">
-  Collect all relevant context from the current session:
-
-  A. WORK COMPLETED THIS SESSION:
-     - Read STATE.md history entries from today/this session
-     - Summarize what was done (e.g., "Completed spec for auth module, started implementation")
-
-  B. DECISIONS MADE:
-     - Scan recent SPEC.md, REVIEW.md, or SUMMARY.md files for decisions
-     - List any verbal decisions or trade-offs discussed but not yet written down
-
-  C. IN-PROGRESS WORK:
-     - If mid-implementation: which tasks are done, which are pending?
-     - If mid-verification: which ACs passed, which remain?
-     - If mid-review: which files reviewed, which remain?
-
-  D. BLOCKERS AND OPEN QUESTIONS:
-     - Any unresolved issues?
-     - Any questions that need user input?
-     - Any external dependencies (waiting on API, waiting on design)?
-
-  E. IMPORTANT CONTEXT NOT IN FILES:
-     Ask the user: "Is there anything I should remember for next session that is not already written down? (decisions, context, concerns)"
-     If yes: record their response verbatim.
-
-  WHY: Session context is ephemeral — it lives in conversation history, not in files. The handoff captures it before it is lost.
-</step>
-
-<step name="check_uncommitted_changes" priority="third">
-  Run: git status (if the project is a git repository)
-
-  IF UNCOMMITTED CHANGES EXIST:
-    Display the list of modified/untracked files.
-
-    Ask the user:
-    "You have uncommitted changes:
-    {file list}
-
-    Options:
-    A. Create a WIP commit now (recommended — prevents accidental loss)
-    B. Leave changes uncommitted (they will persist in the working directory)
-    C. Stash changes (saves them without committing)"
-
-    IF user chooses A:
-      Stage relevant files (not .env or secret files)
-      Create commit with message: "wip({phase}): {brief description of current work}"
-      Note the commit hash in the handoff
-
-    IF user chooses B:
-      Note in handoff: "WARNING: uncommitted changes exist. Do not run git clean or git checkout."
-
-    IF user chooses C:
-      Run: git stash push -m "sdlc-pause-{timestamp}"
-      Note the stash reference in the handoff
-
-  IF NO UNCOMMITTED CHANGES:
-    Note: "Working directory clean. No uncommitted changes."
-
-  WHY: Uncommitted changes can be lost (accidental git clean, system crash, someone else working on the branch). A WIP commit is the safest option.
-</step>
-
-<step name="create_handoff" priority="fourth">
-  Create .sdlc/HANDOFF.md (overwrite if exists — only one active handoff at a time):
-
-  ```markdown
-  # Session Handoff
-
-  ## Session Info
-  - **Paused at**: {ISO timestamp}
-  - **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**: {SPEC|IMPL|VERIFY|REVIEW|CLOSE} — {status}
-
-  ## In-Progress Work
-  {What is partially done — specific tasks, files, ACs}
-  - Task X: COMPLETE
-  - Task Y: IN PROGRESS — {what remains}
-  - Task Z: NOT STARTED
-
-  ## Decisions Made
-  {List of decisions with rationale}
-
-  ## Blockers / Open Questions
-  {List of blockers or questions that need resolution}
-
-  ## 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}
-  - **Stash**: {stash reference, if applicable}
-
-  ## Resume Instructions
-  Run /sdlc:resume to continue. The resume workflow will:
-  1. Read this handoff
-  2. Restore context
-  3. Tell you exactly what to do next
-  ```
-
-  WHY: HANDOFF.md is the bridge between sessions. Without it, resuming requires re-reading all files and reconstructing context manually — slow and error-prone.
-</step>
-
-<step name="update_state" priority="fifth">
-  Update .sdlc/STATE.md:
-  - Add session field: paused_at = {timestamp}
-  - Add history entry: "{timestamp} | pause | Session paused at {loop_position}. Handoff created."
-  - Do NOT change loop_position or next_required_action — those are preserved for resume
-
-  Display:
-  ```
-  Session saved.
-
-  Handoff: .sdlc/HANDOFF.md
-  State: {loop_position}
-  Next action (on resume): {next_required_action}
-  Git: {clean | WIP committed | stashed | uncommitted changes}
-
-  When you return, run /sdlc:resume to continue exactly where you left off.
-  ```
-
-  WHY: The explicit "run /sdlc:resume" instruction ensures the next session starts correctly. Without it, the user might try to pick up manually and skip steps.
-</step>
-
-</process>