feat(prd): enforce FR number immutability in edit workflows
FR numbers are unique identifiers referenced by downstream artifacts (Epics, Stories, Tests, Architecture). This change enforces append-only semantics to protect traceability. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
This commit is contained in:
parent
274dea16fa
commit
9ecff1f3d8
|
|
@ -224,6 +224,10 @@ When user selects 'C', append the content directly to the document using the str
|
||||||
|
|
||||||
Emphasize to user: "This FR list is now binding. Any feature not listed here will not exist in the final product unless we explicitly add it. This is why it's critical to ensure completeness now."
|
Emphasize to user: "This FR list is now binding. Any feature not listed here will not exist in the final product unless we explicitly add it. This is why it's critical to ensure completeness now."
|
||||||
|
|
||||||
|
## ⚠️ FR IMMUTABILITY:
|
||||||
|
|
||||||
|
Before saving, warn user: "FR numbers become **immutable IDs** after this step. New FRs always get next sequential ID (no inserting/reordering). Can mark `[DEPRECATED]` or add `[Supersedes FRx]`. Review carefully."
|
||||||
|
|
||||||
## NEXT STEP:
|
## NEXT STEP:
|
||||||
|
|
||||||
After user selects 'C' and content is saved to document, load {nextStepFile} to define non-functional requirements.
|
After user selects 'C' and content is saved to document, load {nextStepFile} to define non-functional requirements.
|
||||||
|
|
|
||||||
|
|
@ -158,6 +158,8 @@ Please describe the changes you want to make. For example:
|
||||||
|
|
||||||
**Wait for user to describe their requirements.**
|
**Wait for user to describe their requirements.**
|
||||||
|
|
||||||
|
**IF user wants to modify/reorder existing FRs:** FR numbers are IDs - redirect to allowed operations (add new sequential FRs, mark `[DEPRECATED]`, or `[Supersedes]`).
|
||||||
|
|
||||||
### 7. Detect PRD Format
|
### 7. Detect PRD Format
|
||||||
|
|
||||||
Analyze the loaded PRD:
|
Analyze the loaded PRD:
|
||||||
|
|
|
||||||
|
|
@ -123,6 +123,14 @@ Return detailed change plan with section breakdown."
|
||||||
- Content to remove (if incorrect/leakage)
|
- Content to remove (if incorrect/leakage)
|
||||||
- Structure changes (if reformatting needed)
|
- Structure changes (if reformatting needed)
|
||||||
|
|
||||||
|
### 2.1 FR Immutability Check
|
||||||
|
|
||||||
|
FR numbers are **IDs**, not logical order. IF plan includes FR modifications, block and redirect:
|
||||||
|
- ✅ New FRs get next ID (FR1-10 exists → FR11, even if extending FR6)
|
||||||
|
- ✅ Add `[DEPRECATED]` prefix to obsolete FRs
|
||||||
|
- ✅ Add `[Supersedes FRx]` to replacement FRs
|
||||||
|
- ❌ Never modify/delete/reorder/renumber existing FRs
|
||||||
|
|
||||||
### 3. Prepare Change Plan Summary
|
### 3. Prepare Change Plan Summary
|
||||||
|
|
||||||
**Summary sections:**
|
**Summary sections:**
|
||||||
|
|
@ -245,5 +253,6 @@ Load and execute {nextStepFile} (step-e-03-edit.md)
|
||||||
- Missing section-by-section breakdown
|
- Missing section-by-section breakdown
|
||||||
- Not prioritizing changes
|
- Not prioritizing changes
|
||||||
- Proceeding without user approval
|
- Proceeding without user approval
|
||||||
|
- Approving FR modifications (immutability violation)
|
||||||
|
|
||||||
**Master Rule:** Plan before editing. Thorough analysis ensures we make the right changes in the right order. User approval prevents misalignment.
|
**Master Rule:** Plan before editing. Thorough analysis ensures we make the right changes in the right order. User approval prevents misalignment.
|
||||||
|
|
|
||||||
|
|
@ -124,6 +124,16 @@ Apply changes and return updated section."
|
||||||
Changes: {brief summary}
|
Changes: {brief summary}
|
||||||
{More sections remaining...}"
|
{More sections remaining...}"
|
||||||
|
|
||||||
|
### 3.1 FR Immutability Enforcement
|
||||||
|
|
||||||
|
FR numbers are **IDs**, not logical order:
|
||||||
|
- ✅ New FRs get next sequential ID (FR1-10 → FR11, regardless of conceptual grouping)
|
||||||
|
- ✅ Add `[DEPRECATED]` prefix (preserve original text)
|
||||||
|
- ✅ Add `[Supersedes FRx]` to replacement FRs
|
||||||
|
- ❌ Never modify/delete/reorder/renumber existing FRs
|
||||||
|
|
||||||
|
**IF violation detected:** STOP, return to step-e-02-review.md
|
||||||
|
|
||||||
### 4. Handle Restructuring (If Needed)
|
### 4. Handle Restructuring (If Needed)
|
||||||
|
|
||||||
**If conversion mode is "Full restructuring" or "Both":**
|
**If conversion mode is "Full restructuring" or "Both":**
|
||||||
|
|
@ -249,5 +259,6 @@ Display:
|
||||||
- Not updating frontmatter
|
- Not updating frontmatter
|
||||||
- No final verification
|
- No final verification
|
||||||
- Not saving updated PRD
|
- Not saving updated PRD
|
||||||
|
- Modifying/deleting/renumbering existing FRs (immutability violation)
|
||||||
|
|
||||||
**Master Rule:** Execute the plan exactly as approved. PRD is now ready for validation or downstream use. Validation integration ensures quality.
|
**Master Rule:** Execute the plan exactly as approved. PRD is now ready for validation or downstream use. Validation integration ensures quality.
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue