Cursor rule

1---
2alwaysApply: false
3---
4 
5# Mid-Workflow Changes and Stage Management
6 
7## Overview
8 
9Users may request changes to the execution plan or stage execution during the workflow. This document provides guidance on handling these requests safely and effectively.
10 
11---
12 
13## Types of Mid-Workflow Changes
14 
15### 1. Adding a Skipped Stage
16 
17**Scenario**: User wants to add a stage that was originally skipped
18 
19**Example**: "Actually, I want to add user stories even though we skipped that stage"
20 
21**Handling**:
221. **Confirm Request**: "You want to add User Stories stage. This will create user stories and personas. Confirm?"
232. **Check Dependencies**: Verify all prerequisite stages are complete
243. **Update Execution Plan**: Add stage to `execution-plan.md` with rationale
254. **Update State**: Mark stage as "PENDING" in `aidlc-state.md`
265. **Execute Stage**: Follow normal stage execution process
276. **Log Change**: Document in `audit.md` with timestamp and reason
28 
29**Considerations**:
30- May need to update later stages that could benefit from new artifacts
31- Existing artifacts may need revision to incorporate new information
32- Timeline will be extended
33 
34---
35 
36### 2. Skipping a Planned Stage
37 
38**Scenario**: User wants to skip a stage that was planned to execute
39 
40**Example**: "Let's skip the NFR Design stage for now"
41 
42**Handling**:
431. **Confirm Request**: "You want to skip NFR Design. This means no NFR patterns or logical components will be incorporated. Confirm?"
442. **Warn About Impact**: Explain what will be missing and potential consequences
453. **Get Explicit Confirmation**: User must explicitly confirm understanding of impact
464. **Update Execution Plan**: Mark stage as "SKIPPED" with reason
475. **Update State**: Mark stage as "SKIPPED" in `aidlc-state.md`
486. **Adjust Later Stages**: Note that later stages may need manual setup
497. **Log Change**: Document in `audit.md` with timestamp and reason
50 
51**Considerations**:
52- Later stages may fail or require manual intervention
53- User accepts responsibility for missing artifacts
54- Can be added back later if needed
55 
56---
57 
58### 3. Restarting Current Stage
59 
60**Scenario**: User is unhappy with current stage results and wants to redo it
61 
62**Example**: "I don't like these user stories. Can we start over?"
63 
64**Handling**:
651. **Understand Concern**: "What specifically would you like to change about the stories?"
662. **Offer Options**:
67   - **Option A**: Modify existing artifacts (faster, preserves some work)
68   - **Option B**: Complete restart (clean slate, more time)
693. **If Restart Chosen**:
70   - Archive existing artifacts: `{artifact}.backup.{timestamp}`
71   - Reset stage checkboxes in plan file
72   - Mark stage as "IN PROGRESS" in `aidlc-state.md`
73   - Clear stage completion status
74   - Re-execute from beginning
754. **Log Change**: Document reason for restart and what will change
76 
77**Considerations**:
78- Existing work will be lost (but backed up)
79- May need to redo dependent stages
80- Timeline will be extended
81 
82---
83 
84### 4. Restarting Previous Stage
85 
86**Scenario**: User wants to go back and redo a completed stage
87 
88**Example**: "I want to change the architectural decision we made earlier"
89 
90**Handling**:
911. **Assess Impact**: Identify all stages that depend on the stage to be restarted
922. **Warn User**: "Restarting Application Design will require redoing: Units Planning, Units Generation, per-unit design (all units), Code Generation. Confirm?"
933. **Get Explicit Confirmation**: User must understand full impact
944. **If Confirmed**:
95   - Archive all affected artifacts
96   - Reset all affected stages in `aidlc-state.md`
97   - Clear checkboxes in all affected plan files
98   - Return to the stage to restart
99   - Re-execute from that point forward
1005. **Log Change**: Document full impact and reason for restart
101 
102**Considerations**:
103- Significant rework required
104- All dependent stages must be redone
105- Timeline will be significantly extended
106- Consider if modification is better than restart
107 
108---
109 
110### 5. Changing Stage Depth
111 
112**Scenario**: User wants to change the depth level of current or upcoming stage
113 
114**Example**: "Let's do a comprehensive requirements analysis instead of standard"
115 
116**Handling**:
1171. **Confirm Request**: "You want to change Requirements Analysis from Standard to Comprehensive depth. This will be more thorough but take longer. Confirm?"
1182. **Update Execution Plan**: Change depth level in `workflow-planning.md`
1193. **Adjust Approach**: Follow comprehensive depth guidelines for the stage
1204. **Update Estimates**: Inform user of new timeline estimate
1215. **Log Change**: Document depth change and reason
122 
123**Considerations**:
124- More depth = more time but better quality
125- Less depth = faster but may miss details
126- Can only change before or during stage, not after completion
127 
128---
129 
130### 6. Pausing Workflow
131 
132**Scenario**: User needs to pause and resume later
133 
134**Example**: "I need to stop for now and continue tomorrow"
135 
136**Handling**:
1371. **Complete Current Step**: Finish the current step in progress if possible
1382. **Update Checkboxes**: Mark all completed steps with [x]
1393. **Update State**: Ensure `aidlc-state.md` reflects current status
1404. **Log Pause**: Document pause point in `audit.md`
1415. **Provide Resume Instructions**: "When you return, I'll detect your existing project and offer to continue from: [current stage, current step]"
142 
143**On Resume**:
1441. **Detect Existing Project**: Check for `aidlc-state.md`
1452. **Load Context**: Read all artifacts from completed stages
1463. **Show Status**: Display current stage and next step
1474. **Offer Options**: Continue where left off or review previous work
1485. **Log Resume**: Document resume point in `audit.md`
149 
150---
151 
152### 7. Changing Architectural Decision
153 
154**Scenario**: User wants to change from monolith to microservices (or vice versa)
155 
156**Example**: "Actually, let's do microservices instead of a monolith"
157 
158**Handling**:
1591. **Assess Current Progress**: Determine how far into workflow
1602. **Explain Impact**: 
161   - If before Units Planning: Minimal impact, just update decision
162   - If after Units Planning: Must redo Units Planning, Units Generation, all per-unit design
163   - If after Code Generation: Significant rework required
1643. **Recommend Approach**:
165   - Early in workflow: Restart from Application Design stage
166   - Late in workflow: Consider if modification is feasible vs. restart
1674. **Get Confirmation**: User must understand full scope of change
1685. **Execute Change**: Follow restart procedures for affected stages
169 
170**Considerations**:
171- Architectural changes have cascading effects
172- Earlier in workflow = easier to change
173- Later in workflow = consider cost vs. benefit
174 
175---
176 
177### 8. Adding/Removing Units
178 
179**Scenario**: User wants to add or remove units after Units Generation
180 
181**Example**: "We need to split the Payment unit into Payment and Billing"
182 
183**Handling**:
1841. **Assess Impact**: Determine which units have completed design/code
1852. **Explain Consequences**:
186   - Adding unit: Need to do full design and code for new unit
187   - Removing unit: Need to redistribute functionality to other units
188   - Splitting unit: Need to redo design and code for both resulting units
1893. **Update Unit Artifacts**:
190   - Modify `unit-of-work.md`
191   - Update `unit-of-work-dependency.md`
192   - Revise `unit-of-work-story-map.md`
1934. **Reset Affected Units**: Mark affected units as needing redesign
1945. **Execute Changes**: Follow normal unit design and code process for affected units
195 
196**Considerations**:
197- Affects all downstream stages for those units
198- May affect other units if dependencies change
199- Timeline impact depends on how many units affected
200 
201---
202 
203## General Guidelines for Handling Changes
204 
205### Before Making Changes
206 
2071. **Understand the Request**: Ask clarifying questions about what user wants to change and why
2082. **Assess Impact**: Identify all affected stages, artifacts, and dependencies
2093. **Explain Consequences**: Clearly communicate what will need to be redone and timeline impact
2104. **Offer Alternatives**: Sometimes modification is better than restart
2115. **Get Explicit Confirmation**: User must understand and accept the impact
212 
213### During Changes
214 
2151. **Archive Existing Work**: Always backup before making destructive changes
2162. **Update All Tracking**: Keep `aidlc-state.md`, plan files, and `audit.md` in sync
2173. **Communicate Progress**: Keep user informed about what's happening
2184. **Validate Changes**: Ensure changes are consistent across all artifacts
2195. **Test Continuity**: Verify workflow can continue smoothly after changes
220 
221### After Changes
222 
2231. **Verify Consistency**: Check that all artifacts are aligned with changes
2242. **Update Documentation**: Ensure all references are updated
2253. **Log Completely**: Document full change history in `audit.md`
2264. **Confirm with User**: Verify changes meet user's expectations
2275. **Resume Workflow**: Continue with normal execution from new state
228 
229---
230 
231## Change Request Decision Tree
232 
233```
234User requests change
235    |
236    ├─ Is it current stage?
237    |   ├─ Yes: Can modify or restart current stage
238    |   └─ No: Go to next question
239    |
240    ├─ Is it a completed stage?
241    |   ├─ Yes: Assess impact on dependent stages
242    |   |   ├─ Low impact: Modify and update dependents
243    |   |   └─ High impact: Recommend restart from that stage
244    |   └─ No: Go to next question
245    |
246    ├─ Is it adding a skipped stage?
247    |   ├─ Yes: Check prerequisites, add to plan, execute
248    |   └─ No: Go to next question
249    |
250    ├─ Is it skipping a planned stage?
251    |   ├─ Yes: Warn about impact, get confirmation, skip
252    |   └─ No: Go to next question
253    |
254    └─ Is it changing depth level?
255        ├─ Yes: Update plan, adjust approach
256        └─ No: Clarify request with user
257```
258 
259---
260 
261## Logging Requirements
262 
263### Change Request Log Format
264 
265```markdown
266## Change Request - [Stage Name]
267**Timestamp**: [ISO timestamp]
268**Request**: [What user wants to change]
269**Current State**: [Where we are in workflow]
270**Impact Assessment**: [What will be affected]
271**User Confirmation**: [User's explicit confirmation]
272**Action Taken**: [What was done]
273**Artifacts Affected**: [List of files changed/reset]
274 
275---
276```
277 
278---
279 
280## Best Practices
281 
2821. **Always Confirm**: Never make destructive changes without explicit user confirmation
2832. **Explain Impact**: Users need to understand consequences before deciding
2843. **Offer Options**: Sometimes there are multiple ways to handle a change
2854. **Archive First**: Always backup before making destructive changes
2865. **Update Everything**: Keep all tracking files in sync
2876. **Log Thoroughly**: Document all changes for audit trail
2887. **Validate After**: Ensure workflow can continue smoothly
2898. **Be Flexible**: Workflow should adapt to user needs, not force rigid process
290