sdlc-framework 2.1.0 → 3.0.0

package/src/workflows/transition-phase.md

@@ -1,203 +0,0 @@
-<purpose>Transition from one phase to the next within a milestone. Called automatically by close-phase when the last plan in a phase completes. Verifies completeness, updates project state, and commits the phase.</purpose>
-<when_to_use>Triggered automatically when /sdlc:close detects the last plan in a phase is done. Can also be run manually via /sdlc:transition to force a phase transition.</when_to_use>
-<required_reading>.sdlc/STATE.md, .sdlc/ROADMAP.md, .sdlc/PROJECT.md, all SUMMARY.md files in the completing phase</required_reading>
-<loop_context>
-  expected_phase: TRANSITION (between phases)
-  prior_phase: CLOSE ✓ (last plan in phase)
-  next_phase: first SPEC of the next phase, or milestone completion
-</loop_context>
-<process>
-
-<step name="verify_phase_completeness" priority="first">
-  Read .sdlc/STATE.md. Extract the current phase.
-  Read .sdlc/ROADMAP.md. Get the current phase's plan count.
-
-  List all files in .sdlc/phases/{current_phase}/:
-  - Count *-SPEC.md files (plans created)
-  - Count *-SUMMARY.md files (plans completed)
-  - Count HOTFIX-*-SUMMARY.md files (hotfixes applied)
-
-  VERIFY: Every SPEC.md has a corresponding SUMMARY.md.
-  - If a SPEC exists without a SUMMARY: that plan was not completed.
-  - STOP. Display: "Phase transition blocked. Plan {N} has a spec but no summary. Complete it first."
-
-  VERIFY: Every SUMMARY.md shows all ACs passed.
-  - Read each SUMMARY.md. Check the AC results table.
-  - If any AC is FAIL: STOP. Display: "Phase transition blocked. Plan {N} has failing ACs."
-
-  Display:
-  ```
-  Phase {phase} completeness check:
-  Plans: {N} created, {N} completed
-  Hotfixes: {N}
-  All ACs: PASSED
-  Phase is ready for transition.
-  ```
-
-  WHY: Transitioning with incomplete work means skipping it forever. The completeness check prevents accidental abandonment.
-</step>
-
-<step name="verify_state_consistency" priority="second">
-  Cross-check three state files for consistency:
-
-  STATE.MD:
-  - current_milestone should match ROADMAP.md's in-progress milestone
-  - current_phase should match the phase being completed
-  - loop_position should be CLOSE ✓
-
-  PROJECT.MD:
-  - Tech stack should still be accurate (ask user if uncertain)
-  - Requirements section should reflect what was built
-
-  ROADMAP.MD:
-  - Current phase should show correct plan count
-  - Prior phases in this milestone should all be COMPLETE
-
-  IF INCONSISTENCY FOUND:
-  Display: "State inconsistency: {detail}. Recommend fixing before transitioning."
-  Offer to auto-fix obvious inconsistencies (e.g., plan count mismatch).
-  Ask for user confirmation before applying fixes.
-
-  WHY: State drift accumulates silently. Catching it at phase boundaries prevents compounding errors.
-</step>
-
-<step name="update_project_md" priority="third">
-  Read .sdlc/PROJECT.md.
-
-  Based on the completed phase's summaries:
-
-  A. VALIDATE EXISTING REQUIREMENTS:
-  For each requirement listed in PROJECT.md:
-  - Was it addressed in this phase? (search summaries for related work)
-  - If addressed: mark as IMPLEMENTED with reference to plan number
-  - If not addressed: leave as-is (future phase responsibility)
-
-  B. INVALIDATE OUTDATED REQUIREMENTS:
-  For each requirement:
-  - Does the implementation contradict or supersede it?
-  - If yes: mark as SUPERSEDED with explanation
-
-  C. ADD NEW REQUIREMENTS:
-  From decisions and lessons learned in summaries:
-  - Were new requirements discovered during implementation?
-  - If yes: add them to PROJECT.md with status NOT STARTED
-
-  Display changes to user before writing:
-  ```
-  PROJECT.md updates:
-  - IMPLEMENTED: {requirement} (Plan {N})
-  - SUPERSEDED: {requirement} (replaced by {new approach})
-  - NEW: {requirement} (discovered in Plan {N})
-
-  Apply these changes? (yes/no)
-  ```
-
-  WHY: PROJECT.md must stay current. Stale requirements mislead future specs. New requirements discovered during implementation must be captured or they are forgotten.
-</step>
-
-<step name="update_state_for_next_phase" priority="fourth">
-  Read .sdlc/ROADMAP.md. Identify the next phase in the current milestone.
-
-  IF NEXT PHASE EXISTS:
-    Update .sdlc/STATE.md:
-    - current_phase: {next phase number and name}
-    - current_plan: cleared
-    - loop_position: TRANSITION ✓
-    - next_required_action: /sdlc:spec
-    - Add history entry: "{timestamp} | transition | Phase {old} complete. Transitioning to phase {new}."
-
-    Update .sdlc/ROADMAP.md:
-    - Set completed phase status to COMPLETE with date
-    - Set next phase status to IN PROGRESS
-
-  IF NO NEXT PHASE (this was the last phase in the milestone):
-    Update .sdlc/STATE.md:
-    - loop_position: TRANSITION ✓
-    - 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:
-    - Set completed phase status to COMPLETE with date
-
-  WHY: The state machine must always point to exactly one next action. Whether that is the next phase or milestone completion depends on the roadmap.
-</step>
-
-<step name="update_roadmap" priority="fifth">
-  Update .sdlc/ROADMAP.md with phase completion details:
-
-  For the completed phase, update the row:
-  ```
-  | {phase-num} | {name} | COMPLETE ({date}) | {plan-count} |
-  ```
-
-  Add a phase summary note under the milestone:
-  ```
-  #### Phase {number} Summary
-  - Plans executed: {N}
-  - Hotfixes: {N}
-  - Key deliverables: {from summaries}
-  - Duration: {first spec date} to {completion date}
-  ```
-
-  WHY: The roadmap is the high-level progress tracker. Completion details help stakeholders understand velocity and scope.
-</step>
-
-<step name="create_git_commit" priority="sixth">
-  IF the project is a git repository:
-
-  Check: git status for uncommitted changes.
-
-  IF UNCOMMITTED CHANGES EXIST:
-    Stage all .sdlc/ files: git add .sdlc/
-    Stage any source files that were part of the phase
-
-    Create commit:
-    ```
-    feat({phase-name}): complete phase {number}
-
-    Phase {number} ({phase-name}) of milestone {milestone-number} is complete.
-
-    Plans executed: {N}
-    Key deliverables:
-    - {deliverable 1}
-    - {deliverable 2}
-    ```
-
-    Display: "Git commit created: {hash}"
-
-  IF NO UNCOMMITTED CHANGES:
-    Display: "No uncommitted changes to commit."
-
-  WHY: Phase completion is a natural commit point. The commit message documents what was accomplished, making git log useful as a project history.
-</step>
-
-<step name="display_result" priority="seventh">
-  IF NEXT PHASE EXISTS:
-    Display:
-    ```
-    Phase transition complete.
-
-    Completed: Phase {old-number} — {old-name}
-    Plans: {N} executed
-    Starting: Phase {new-number} — {new-name}
-
-    NEXT ACTION REQUIRED: /sdlc:spec
-    Run /sdlc:spec to create the first specification for Phase {new-number}.
-    ```
-
-  IF MILESTONE COMPLETE (no next phase):
-    Display:
-    ```
-    Phase transition complete.
-
-    Completed: Phase {number} — {name} (LAST PHASE)
-    Milestone {milestone-number} — {milestone-name}: ALL PHASES COMPLETE
-
-    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.
-</step>
-
-</process>