sdlc-framework 1.0.0

package/src/templates/SUMMARY.md

@@ -0,0 +1,126 @@
+# Loop Closure Summary Template
+
+This template defines the summary document produced during `/sdlc:close`. It is stored at `.sdlc/milestones/M{{N}}/phases/P{{N}}/summaries/SUMMARY-{{NNN}}.md`. Each summary corresponds to one completed spec and records what was built, whether it met acceptance criteria, and what was learned.
+
+---
+
+```markdown
+# Summary: {{SPEC_TITLE}}
+
+## Reference
+
+- **Phase:** {{PHASE_NAME}}
+- **Plan:** {{PLAN_NUMBER}}/{{TOTAL_PLANS}}
+- **Spec:** {{SPEC_FILE_PATH}}
+- **Type:** {{feature/bugfix/refactor/test/docs}}
+- **Started:** {{DATE}}
+- **Completed:** {{DATE}}
+
+## Deliverables
+
+What was built or changed in this loop iteration:
+
+1. {{DELIVERABLE_DESCRIPTION — what it is and what it does}}
+2. {{DELIVERABLE_DESCRIPTION}}
+3. {{DELIVERABLE_DESCRIPTION}}
+
+## Acceptance Criteria Results
+
+| AC | Description | Status | Evidence |
+|----|-------------|--------|----------|
+| AC-1 | {{CRITERION_NAME}} | {{pass/fail}} | {{HOW_IT_WAS_VERIFIED — test name, screenshot path, manual check description}} |
+| AC-2 | {{CRITERION_NAME}} | {{pass/fail}} | {{EVIDENCE}} |
+| AC-3 | {{CRITERION_NAME}} | {{pass/fail}} | {{EVIDENCE}} |
+
+### Failed Criteria
+
+If any criteria failed, document what went wrong and what was done about it:
+
+| AC | Failure Reason | Resolution |
+|----|----------------|------------|
+| {{AC_ID}} | {{WHY_IT_FAILED}} | {{WHAT_WAS_DONE — fixed and re-verified / deferred to next plan / accepted as known limitation}} |
+
+## Deviations
+
+Differences between the spec and what was actually built:
+
+| # | Planned | Actual | Reason |
+|---|---------|--------|--------|
+| DEV-001 | {{WHAT_THE_SPEC_SAID}} | {{WHAT_WAS_ACTUALLY_DONE}} | {{WHY_THE_DEVIATION_WAS_NECESSARY}} |
+
+If no deviations: "Implementation matched spec exactly."
+
+## Decisions Made
+
+Decisions made during implementation that were not covered by the spec:
+
+| # | Decision | Context | Impact |
+|---|----------|---------|--------|
+| D-001 | {{WHAT_WAS_DECIDED}} | {{WHY_THIS_DECISION_CAME_UP}} | {{HOW_IT_AFFECTS_FUTURE_WORK}} |
+
+## Engineering Laws Review
+
+Summary of the code review against engineering laws:
+
+| Law | Status | Findings |
+|-----|--------|----------|
+| SOLID | {{pass/warning/violation}} | {{BRIEF_SUMMARY or "No issues found"}} |
+| DRY | {{pass/warning/violation}} | {{BRIEF_SUMMARY or "No issues found"}} |
+| YAGNI | {{pass/warning/violation}} | {{BRIEF_SUMMARY or "No issues found"}} |
+| CLEAN_CODE | {{pass/warning/violation}} | {{BRIEF_SUMMARY or "No issues found"}} |
+| SECURITY | {{pass/warning/violation}} | {{BRIEF_SUMMARY or "No issues found"}} |
+| TESTING | {{pass/warning/violation}} | {{BRIEF_SUMMARY or "No issues found"}} |
+| NAMING | {{pass/warning/violation}} | {{BRIEF_SUMMARY or "No issues found"}} |
+| ERROR_HANDLING | {{pass/warning/violation}} | {{BRIEF_SUMMARY or "No issues found"}} |
+
+**Review file:** {{REVIEW_FILE_PATH}}
+
+## Files Modified
+
+| File | Action | Description |
+|------|--------|-------------|
+| {{FILE_PATH}} | {{created/modified/deleted}} | {{WHAT_CHANGED_AND_WHY}} |
+
+## Lessons Learned
+
+Observations for future iterations:
+
+1. **{{LESSON_TITLE}}** — {{WHAT_WAS_LEARNED_AND_HOW_TO_APPLY_IT_NEXT_TIME}}
+2. **{{LESSON_TITLE}}** — {{WHAT_WAS_LEARNED}}
+3. **{{LESSON_TITLE}}** — {{WHAT_WAS_LEARNED}}
+```
+
+---
+
+## Field Documentation
+
+### Reference Section
+Links the summary back to its spec and provides temporal context. The started/completed dates show how long the loop iteration took.
+
+### Deliverables
+Concrete outputs. Each deliverable should be something you can point to — a file, a feature, a test suite, a configuration. Not aspirational; factual.
+
+### Acceptance Criteria Results
+The most important section. Every AC from the spec must appear here with a pass/fail status and evidence. Evidence must be specific:
+- For UI features: screenshot path or Playwright test name
+- For API endpoints: curl command output or integration test name
+- For business logic: unit test name and assertion
+- For refactors: before/after comparison showing behavior preservation
+
+### Failed Criteria
+If any AC failed, this section explains why and what was done. Options:
+- **Fixed and re-verified** — The issue was found, fixed, and the AC now passes
+- **Deferred to next plan** — The issue requires work outside this spec's scope
+- **Accepted as known limitation** — The stakeholder agreed this is acceptable for now
+
+### Deviations
+Reality rarely matches the plan exactly. Deviations are not failures — they are documented adjustments. The key is that each deviation has a clear reason. "I felt like it" is not a reason.
+
+### Engineering Laws Review
+Summary of the code review. Points to the full REVIEW.md file for details. If any law had a violation at `error` severity, the loop cannot close until it is resolved.
+
+### Files Modified
+Complete inventory of every file touched. Useful for post-implementation auditing and for understanding the blast radius of the change.
+
+### Lessons Learned
+The most undervalued section. Each lesson should be actionable — not "testing is important" but "mocking the database connection at the repository layer instead of the service layer cuts test setup time in half."

package/src/workflows/close-phase.md

@@ -0,0 +1,189 @@
+<purpose>Close the current SPEC-IMPL-VERIFY-REVIEW loop by reconciling planned work against actual outcomes, creating a SUMMARY.md, and advancing the state machine to the next spec or phase transition.</purpose>
+<when_to_use>Run after /sdlc:review passes with zero blockers. STATE.md must show loop_position = REVIEW ✓ and next_required_action = /sdlc:close.</when_to_use>
+<required_reading>.sdlc/STATE.md, the current SPEC.md, REVIEW.md, VERIFY.md</required_reading>
+<loop_context>
+  expected_phase: CLOSE (active)
+  prior_phase: REVIEW ✓
+  next_phase: SPEC (next loop) or transition-phase (if last plan)
+</loop_context>
+<process>
+
+<step name="validate_state" priority="first">
+  Read .sdlc/STATE.md.
+
+  CHECK: loop_position must be "REVIEW ✓"
+  CHECK: next_required_action must be "/sdlc:close"
+
+  IF EITHER CHECK FAILS: STOP. Display: "Cannot close. State requires: {next_required_action}. Run that first."
+
+  Extract current_phase and current_plan from STATE.md.
+
+  WHY: Closing before review means shipping unreviewed code. The loop enforces quality gates.
+</step>
+
+<step name="verify_no_blockers" priority="second">
+  Read .sdlc/phases/{current_phase}/{current_plan}-REVIEW.md.
+
+  CHECK: blocker count must be 0.
+
+  IF BLOCKERS REMAIN: STOP. Display: "Cannot close with {N} unresolved blockers. Fix them and re-run /sdlc:review."
+
+  WHY: This is a safety net. Even if the user tries to close manually, the blockers gate holds.
+</step>
+
+<step name="reconcile_plan_vs_actual" priority="third">
+  Read the SPEC.md. Extract:
+  - Planned tasks (name, action, done criteria)
+  - Planned acceptance criteria
+  - Planned files to modify/create
+
+  Read the VERIFY.md. Extract:
+  - AC results (pass/fail per criterion)
+
+  Read the REVIEW.md. Extract:
+  - Actual files reviewed (which includes actual files modified)
+  - Warnings (non-blocking issues that remain)
+
+  COMPARE planned vs actual:
+
+  TASKS:
+  - For each planned task: was it completed? (check if files were modified as expected)
+  - Were any unplanned tasks added? (files modified that were not in the spec)
+  - Were any planned tasks skipped?
+
+  ACCEPTANCE CRITERIA:
+  - For each AC: PASS or FAIL (from VERIFY.md)
+  - Were any ACs added or removed during implementation?
+
+  FILES:
+  - Compare spec files_modified vs actual files reviewed
+  - Were any files modified outside the boundary list?
+  - Were any planned files NOT modified?
+
+  Record deviations:
+  ```
+  Deviation 1: {what differed}
+  Reason: {why it changed — ask user if unknown}
+  Impact: {what this means for the project}
+  ```
+
+  IF DEVIATIONS EXIST: Present them to the user and ask for confirmation before proceeding.
+
+  WHY: Deviations are not inherently bad — scope often shifts during implementation. But they must be RECORDED. Unrecorded deviations become hidden technical debt and surprise future developers.
+</step>
+
+<step name="create_summary" priority="fourth">
+  Create .sdlc/phases/{current_phase}/{current_plan}-SUMMARY.md:
+
+  ```markdown
+  # Summary: Plan {plan-number} — {title from spec}
+
+  ## Deliverables
+  - {What was built — concrete, not vague}
+  - {Each deliverable on its own line}
+
+  ## Acceptance Criteria Results
+  | AC | Description | Status | Evidence |
+  |----|-------------|--------|----------|
+  | AC-1 | {desc} | PASS | {evidence from VERIFY.md} |
+  | AC-2 | {desc} | PASS | {evidence} |
+
+  ## Deviations from Spec
+  | # | Planned | Actual | Reason |
+  |---|---------|--------|--------|
+  | 1 | {what was planned} | {what actually happened} | {why} |
+
+  Or: "No deviations. Implementation matched spec exactly."
+
+  ## Decisions Made During Implementation
+  - {Decision}: {rationale}
+  - {Decision}: {rationale}
+
+  Or: "No implementation-time decisions. Spec was followed as written."
+
+  ## Lessons Learned
+  - {What went well}
+  - {What could improve}
+  - {Patterns discovered that should be reused}
+
+  ## Files Modified
+  - {file-path}: {what changed}
+
+  ## Files Created
+  - {file-path}: {purpose}
+
+  ## Review Warnings (Non-Blocking)
+  - {warning from REVIEW.md, if any}
+
+  Or: "Review passed with zero warnings."
+  ```
+
+  WHY: SUMMARY.md is the institutional memory. When the next spec runs, it reads prior summaries to maintain context continuity. Without summaries, each loop starts from scratch.
+</step>
+
+<step name="update_state" priority="fifth">
+  Determine what happens next:
+
+  OPTION A — More plans in this phase:
+  - Check ROADMAP.md: is this the last planned plan for the current phase?
+  - If there are more plans (or the phase is open-ended): set next to /sdlc:spec
+
+  OPTION B — Last plan in phase:
+  - If this was the last plan: trigger transition-phase workflow
+  - Set next to /sdlc:transition (which handles phase advancement)
+
+  Update .sdlc/STATE.md:
+  - loop_position: CLOSE ✓
+  - current_plan: cleared (no active plan)
+  - next_required_action: /sdlc:spec OR /sdlc:transition
+  - Add history entry: "{timestamp} | close | Plan {N} closed. {N} ACs passed. {N} deviations."
+
+  Update .sdlc/ROADMAP.md:
+  - Increment completed plan count for current phase
+  - If phase is complete: mark phase status as COMPLETE
+
+  WHY: The state machine must always have a clear next action. Ambiguity in state leads to confusion about what to do next.
+</step>
+
+<step name="display_result" priority="sixth">
+  IF more plans in phase:
+    Display:
+    ```
+    Loop closed: Plan {N} complete.
+
+    Summary: .sdlc/phases/{phase}/{plan}-SUMMARY.md
+
+    Deliverables: {count}
+    ACs passed: {count}/{count}
+    Deviations: {count}
+
+    NEXT ACTION REQUIRED: /sdlc:spec
+    Run /sdlc:spec to create the next specification.
+    ```
+
+  IF phase complete:
+    Display:
+    ```
+    Loop closed: Plan {N} complete.
+    Phase {phase} COMPLETE — all plans finished.
+
+    Summary: .sdlc/phases/{phase}/{plan}-SUMMARY.md
+
+    Transitioning to next phase...
+    NEXT ACTION REQUIRED: /sdlc:transition
+    ```
+
+  IF milestone complete (last phase, last plan):
+    Display:
+    ```
+    Loop closed: Plan {N} complete.
+    Phase {phase} COMPLETE.
+    MILESTONE {milestone} COMPLETE.
+
+    Run /sdlc:milestone to finalize and start next milestone.
+    ```
+
+  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.
+</step>
+
+</process>

package/src/workflows/debug-flow.md

@@ -0,0 +1,302 @@
+<purpose>Structured debugging workflow: reproduce the bug, isolate the root cause, fix it, and verify the fix. Prevents "shotgun debugging" where developers change random things until the error goes away.</purpose>
+<when_to_use>Run when a bug is reported or discovered. Can be invoked directly via /sdlc:debug or routed from /sdlc:fast when task classification detects bug-related keywords.</when_to_use>
+<required_reading>.sdlc/STATE.md, .sdlc/PROJECT.md, .sdlc/LAWS.md</required_reading>
+<loop_context>
+  expected_phase: DEBUG (special flow, parallel to main loop)
+  prior_phase: any
+  next_phase: REVIEW (debug fixes must be reviewed)
+</loop_context>
+<process>
+
+<step name="accept_bug_report" priority="first">
+  Gather information about the bug. Ask the user:
+
+  Question 1: "What is the bug? Describe the unexpected behavior."
+  Question 2: "What is the expected behavior?"
+  Question 3: "How do you trigger it? (steps to reproduce, if known)"
+  Question 4: "Any error messages or stack traces? (paste them)"
+  Question 5: "When did it start? (recent change, always been there, unknown)"
+
+  IF the user provides an error message or stack trace:
+  - Parse it immediately for file paths, line numbers, and function names
+  - These are the starting points for investigation
+
+  IF the user does not know how to reproduce:
+  - Note this — the reproduce step will need to discover the trigger
+
+  WHY: A structured bug report prevents thrashing. Without clear symptoms, debugging is guessing. The "when did it start" question is critical — if recent, git log shows the introducing change.
+</step>
+
+<step name="reproduce" priority="second">
+  The goal is to trigger the bug reliably, on demand.
+
+  A. SEARCH THE CODEBASE for relevant code:
+     - Use file paths from error messages/stack traces
+     - Search for function names mentioned in the bug description
+     - Search for keywords from the error message
+
+  B. CREATE A MINIMAL REPRODUCTION based on bug type:
+
+     FOR UI BUGS (visual, interaction, layout):
+       1. Use browser_navigate to go to the relevant page
+       2. Use browser_snapshot to see the current state
+       3. Follow the user's reproduction steps using Playwright MCP:
+          - browser_click, browser_fill_form, browser_select_option, etc.
+       4. Use browser_snapshot after each step to observe behavior
+       5. Use browser_take_screenshot for evidence
+       6. Use browser_console_messages to check for JavaScript errors
+       7. Record: "Bug reproduced at step {N}. Expected: {X}. Actual: {Y}."
+
+     FOR API BUGS (wrong response, crash, timeout):
+       1. Construct the HTTP request from the bug report
+       2. Execute via Bash: curl -v {request}
+       3. Capture response status, body, headers
+       4. Record: "Bug reproduced. Endpoint {X} returns {status} with body {Y}. Expected: {Z}."
+
+     FOR LOGIC BUGS (wrong calculation, bad data, incorrect behavior):
+       1. Write a failing test case that exercises the buggy code path
+       2. Run the test — it should FAIL (proving the bug exists)
+       3. Record: "Bug reproduced in test. {function} returns {actual} when given {input}. Expected: {expected}."
+
+     FOR CLI BUGS (wrong output, crash, incorrect exit code):
+       1. Run the command that triggers the bug
+       2. Capture stdout, stderr, exit code
+       3. Record: "Bug reproduced. Command {X} outputs {Y}. Expected: {Z}."
+
+  C. CONFIRM REPRODUCTION:
+     The reproduction must be RELIABLE — run it twice to confirm the same result.
+
+     IF REPRODUCTION FAILS (bug does not appear):
+       - Check for race conditions (timing-dependent bugs)
+       - Check for environment differences (missing env var, different data)
+       - Ask user: "I could not reproduce the bug. Can you provide more details?"
+       - Do NOT proceed until the bug is reproducible
+
+  WHY: A bug you cannot reproduce is a bug you cannot verify as fixed. The reproduction becomes the regression test — run it before the fix (fails) and after (passes).
+</step>
+
+<step name="isolate" priority="third">
+  Narrow down the bug to a specific module, file, function, and line.
+
+  A. START FROM THE REPRODUCTION:
+     - Which file is the entry point for the buggy behavior?
+     - Read that file. Trace the execution path from input to output.
+
+  B. USE BINARY SEARCH STRATEGY:
+     The goal is to find the EXACT line where behavior diverges from expectation.
+
+     1. Identify the input and the incorrect output
+     2. Find the midpoint of the execution path
+     3. Check: is the data correct at the midpoint?
+        - If YES: the bug is AFTER the midpoint
+        - If NO: the bug is BEFORE the midpoint
+     4. Repeat, halving the search space each time
+
+     Techniques for checking data at a point:
+     - Add temporary console.log/print statements (remove after debugging)
+     - Read the code and mentally trace the data flow
+     - Use the test to add assertions at intermediate points
+
+  C. TRACE DATA FLOW:
+     Follow the data from where it enters the system to where it exits wrong:
+     - Controller/handler → service → repository → database (and back)
+     - For each hop: what goes in? What comes out? Where does it change?
+
+  D. CHECK RELATED FILES:
+     - Does the buggy function call other functions? Read those too.
+     - Does the buggy module import shared utilities? Check if THOSE are wrong.
+     - Did a recent change modify a shared dependency? (git log on the file)
+
+  Record the isolation result:
+  ```
+  Bug isolated to: {file}:{line}
+  Function: {function-name}
+  The value of {variable} is {actual} but should be {expected}
+  This happens because: {initial hypothesis}
+  ```
+
+  WHY: Isolation prevents "shotgun debugging" — changing random things until the error disappears. Without isolation, you might fix the symptom while the root cause remains.
+</step>
+
+<step name="root_cause_analysis" priority="fourth">
+  Explain WHY the bug exists, not just WHERE it is.
+
+  A. CLASSIFY THE ROOT CAUSE:
+
+     LOGIC ERROR: The code does the wrong thing by design
+     - Example: off-by-one in loop, wrong comparison operator, inverted condition
+     - Question: "What did the author think this code would do vs what it actually does?"
+
+     RACE CONDITION: Timing-dependent behavior
+     - Example: async operations completing in unexpected order, shared state mutation
+     - Question: "What happens if operation A completes before/after operation B?"
+
+     MISSING VALIDATION: Input not checked at boundary
+     - Example: null/undefined passed to function that assumes non-null, empty string treated as valid
+     - Question: "What inputs were not considered when this code was written?"
+
+     WRONG ASSUMPTION: Code assumes something that is not always true
+     - Example: assumes array is non-empty, assumes API always returns 200, assumes file exists
+     - Question: "What assumption does this code make that can be violated?"
+
+     STALE STATE: Data is cached or stored but not updated
+     - Example: reading from cache after the source changed, UI not re-rendering after state update
+     - Question: "Is the data being read the most current version?"
+
+     DEPENDENCY CHANGE: External library or service changed behavior
+     - Example: API response format changed, library function signature changed
+     - Question: "Did something outside this codebase change recently?"
+
+  B. CHECK FOR SYSTEMIC ISSUES:
+     - Does this same bug pattern exist elsewhere in the codebase?
+     - Search for the same anti-pattern in other files
+     - If found: this is not a single bug — it is a pattern bug. ALL instances must be fixed.
+
+  Record:
+  ```
+  Root Cause: {classification}
+  Explanation: {WHY the bug exists, in plain language}
+  Systemic: {YES — found in N other locations | NO — isolated incident}
+  ```
+
+  WHY: Understanding WHY prevents the same bug from reappearing. Fixing the WHAT without the WHY is like treating symptoms without diagnosing the disease.
+</step>
+
+<step name="fix" priority="fifth">
+  Apply the fix following engineering laws.
+
+  RULES FOR THE FIX:
+  1. Fix the ROOT CAUSE, not the symptom
+     - Bad: add a null check before the crash line
+     - Good: fix the function that returns null when it should not
+
+  2. If the same pattern exists elsewhere (systemic = YES), fix ALL instances
+     - Search for every occurrence
+     - Fix each one
+     - This is DRY applied to bug fixes
+
+  3. Add a guard for the edge case that caused the bug
+     - If missing validation: add validation
+     - If wrong assumption: make the assumption explicit with a check
+     - If race condition: add synchronization or ordering
+
+  4. Follow engineering laws:
+     - Max 40 lines per function (the fix should not bloat the function)
+     - If the function is already too long, extract a helper as part of the fix
+     - Named types if the fix introduces complex parameters
+     - No lint suppressions
+
+  5. Add or update tests:
+     - The reproduction test case must now PASS
+     - Add a regression test that specifically covers the bug scenario
+     - If systemic: add tests for each fixed instance
+
+  Record:
+  ```
+  Files modified: {list}
+  Lines changed: {count}
+  Tests added: {list}
+  Systemic fixes: {N instances fixed across N files}
+  ```
+
+  WHY: A fix without a regression test will regress. A fix that only addresses one instance of a systemic issue leaves time bombs in the codebase.
+</step>
+
+<step name="verify_fix" priority="sixth">
+  A. RUN THE REPRODUCTION AGAIN:
+     Execute the exact same steps from the reproduce step.
+     The bug MUST NOT appear.
+
+     IF BUG STILL APPEARS: The fix is wrong. Return to isolate step.
+
+  B. RUN REGRESSION TESTS:
+     Run the full test suite (or at minimum, tests for modified files).
+     ALL tests must pass. Zero regressions.
+
+     IF REGRESSIONS: The fix broke something else. Return to isolate step — the fix introduced a new bug.
+
+  C. FOR UI BUGS:
+     Use Playwright MCP to verify:
+     - browser_navigate to the page
+     - Execute the reproduction steps
+     - browser_take_screenshot for evidence
+     - Confirm expected behavior in snapshot
+
+  D. FOR API BUGS:
+     Re-run the curl command
+     Confirm correct status and response body
+
+  Record:
+  ```
+  Reproduction: FIXED (no longer reproduces)
+  Regression: CLEAN (all {N} tests pass)
+  Evidence: {screenshot, test output, curl response}
+  ```
+
+  WHY: "I think it is fixed" is not verification. Run the reproduction. If it still fails, the fix is wrong.
+</step>
+
+<step name="create_debug_record" priority="seventh">
+  Create .sdlc/phases/{current_phase}/DEBUG-{issue-slug}-{timestamp}.md:
+
+  ```markdown
+  # Debug: {bug title}
+
+  ## Bug Report
+  - **Symptom**: {what was wrong}
+  - **Expected**: {what should happen}
+  - **Reported**: {timestamp}
+
+  ## Reproduction
+  - **Type**: {UI|API|Logic|CLI}
+  - **Steps**: {reproduction steps}
+  - **Reliability**: {always|intermittent}
+
+  ## Isolation
+  - **File**: {file}:{line}
+  - **Function**: {function-name}
+  - **Data flow**: {trace summary}
+
+  ## Root Cause
+  - **Classification**: {logic error|race condition|missing validation|wrong assumption|stale state|dependency change}
+  - **Explanation**: {plain language WHY}
+  - **Systemic**: {yes/no — if yes, how many instances}
+
+  ## Fix
+  - **Files modified**: {list}
+  - **Approach**: {what was changed and why}
+  - **Tests added**: {list}
+
+  ## Verification
+  - **Reproduction**: FIXED
+  - **Regressions**: CLEAN
+  - **Evidence**: {summary}
+  ```
+
+  WHY: The debug record is a knowledge base. When a similar bug appears, search debug records first. The root cause analysis saves hours of re-investigation.
+</step>
+
+<step name="update_state" priority="eighth">
+  Update .sdlc/STATE.md:
+  - Add history entry: "{timestamp} | debug | Fixed: {bug title}. Root cause: {classification}. {N} files modified."
+  - next_required_action: /sdlc:review
+
+  Display:
+  ```
+  Bug fixed and verified.
+
+  Root cause: {classification}
+  Files modified: {N}
+  Tests added: {N}
+  Systemic fixes: {N} (if applicable)
+
+  Debug record: .sdlc/phases/{phase}/DEBUG-{slug}.md
+
+  NEXT ACTION REQUIRED: /sdlc:review
+  Run /sdlc:review to check the fix against engineering laws.
+  ```
+
+  WHY: Debug fixes still go through review. A hurried fix might violate engineering laws — empty catch blocks, missing types, function too long. The review catches that.
+</step>
+
+</process>