Noelserdna Claude Plugin Sdd Req Change

Skill: sdd-req-change — Requirements Change Manager & Pipeline Cascade Trigger

Version: 2.0.0 Pipeline position: Lateral — can be invoked anytime after specs exist; triggers downstream cascade Complementary to: sdd-spec-auditor Mode Fix (audit-driven fixes) SWEBOK v4 alignment: Chapter 01 (Software Requirements) — Change Management, Traceability, Conflict Resolution; Chapter 05 (Software Maintenance) — Maintenance Classification, Impact Analysis, Feature Retirement

1. Purpose & Scope

Manages the full lifecycle of requirements changes: ADD, MODIFY, and DEPRECATE requirements, propagating changes bidirectionally through all specification documents. Classifies changes using ISO 14764 maintenance categories (corrective, adaptive, perfective, preventive) and optionally triggers downstream pipeline cascade to re-plan, re-task, and re-implement affected FASEs. Ensures zero gaps between requirements and specifications after every change.

What This Skill Does

1. Receives a change request (text free or structured CHANGE-REQUEST.md)
2. Classifies the change by maintenance category (ISO 14764) and urgency
3. Performs impact analysis across the full traceability chain (REQ ↔ UC ↔ WF ↔ API ↔ BDD ↔ INV ↔ ADR ↔ RN)
4. Asks the user every question needed with options and recommendations to eliminate ambiguities
5. Plans all changes with before/after for every affected document
6. Executes changes atomically across all specs and requirements
7. Runs a focused alignment audit on affected documents
8. Generates a Change Report with full context for planning, tasks, and implementation
9. Triggers pipeline cascade (Phase 9) — updates pipeline-state.json and optionally invokes downstream skills

What This Skill Does NOT Do

• Does NOT generate implementation code (delegates to sdd-task-implementer via cascade)
• Does NOT create implementation plans from scratch (delegates to sdd-plan-architect via cascade)
• Does NOT create tasks from scratch (delegates to sdd-task-generator via cascade)
• Does NOT run full cross-document audits (use sdd-spec-auditor)
• Does NOT derive requirements from scratch (use sdd-requirements-engineer)
• Does NOT assume behavior not backed by user answers
• Does NOT modify files outside spec/, changes/, requirements/, and pipeline-state.json
• Does NOT handle runtime operational maintenance (monitoring, incident response, runtime rollback)
• Does NOT estimate effort in person-hours (project management concern, Ch07)

Core Principle

"Every requirement change must propagate completely through the specification chain AND trigger downstream pipeline re-execution. No orphan specs. No orphan requirements. No gaps. No stale plans. No ambiguities introduced."

Aligned with SWEBOK v4 Ch01 (Software Requirements), Change Management and Ch05 (Software Maintenance): the skill that initiates changes owns the cascade through the full pipeline.

2. Invocation Modes

/sdd-req-change                                    # Interactive mode (text free from user)
/sdd-req-change --file changes/CHANGE-REQUEST.md   # From structured file
/sdd-req-change --dry-run                          # Plan only, no execution (stops after Phase 4)
/sdd-req-change --batch                            # Auto-apply recommended solutions (skip Phase 5 interactive)
/sdd-req-change --cascade=auto                     # Full pipeline cascade after changes (Phase 9)
/sdd-req-change --cascade=manual                   # (default) Advisory cascade output only
/sdd-req-change --cascade=dry-run                  # Preview cascade scope without executing
/sdd-req-change --cascade=plan-only                # Cascade through planning but not implementation
/sdd-req-change --maintenance=TYPE                 # Pre-classify as corrective/adaptive/perfective/preventive

Cascade Modes

Input Sources

3. Phases

Phase 0: Inventory & Context Loading

Goal: Build complete understanding of current spec state.

Steps:

1. Glob all .md files under spec/ — build manifest with IDs, types, versions
2. Read spec/requirements/REQUIREMENTS.md — extract all REQ IDs, categories, traceability
3. Read spec/domain/01-GLOSSARY.md — load ubiquitous language (MANDATORY reference)
4. Read spec/CLARIFICATIONS.md — load business rules (RN-*)
5. Read spec/CHANGELOG.md — identify current spec version
6. Read audits/AUDIT-BASELINE.md — know current audit state
7. Read pipeline-state.json — load current pipeline state (create default if absent)
8. Scan changes/ for existing DRAFT/REVIEWED deltas — warn if unapplied deltas exist
9. If --file provided: Read and parse CHANGE-REQUEST.md
10. Build internal index:
    • REQ-ID → [source specs] (forward traceability)
    • spec-file → [REQ-IDs] (backward traceability)
    • REQ-ID → [dependent REQ-IDs] (dependency graph)
    • stage → status (pipeline staleness map from pipeline-state.json)

Readiness Gates:

Output: Internal manifest (not written to disk). Console summary:

Inventory Complete
==================
Spec files:        {N}
Requirements:      {N} (FUN:{N} NFR:{N} OPS:{N} REG:{N} DER:{N})
Current version:   v{X.Y.Z}
Audit state:       {clean | N open findings}
Pipeline state:    {fresh | plan exists (FASE 1-N) | tasks exist (FASE 1-N) | implementation started}
Cascade impact:    {N stages would be invalidated}
Change source:     {text free | CHANGE-REQUEST.md | both}
Pending deltas:    {N DRAFT | N REVIEWED | none}

Phase 1: Change Request Intake & Classification

Goal: Parse, classify, and structure each change request.

Steps:

1. Parse user input (natural language) and/or structured file
2. For each change, classify:

3. For each change, classify by ISO 14764 Maintenance Category:

   Classification	Sub-classification	Signal
   ADD	Perfective	New capability
   ADD	Adaptive	New external integration, dependency addition
   MODIFY	Corrective	Bug fix, incorrect behavior
   MODIFY	Perfective	Feature enhancement
   MODIFY	Adaptive	External API change, dependency update, platform migration
   MODIFY	Preventive	Tech debt reduction, code health improvement
   DEPRECATE	Perfective	Feature simplification
   DEPRECATE	Adaptive	External dependency removal
   DEPRECATE	Preventive	Removing tech debt source

   If --maintenance=TYPE was provided, use it directly. Otherwise, auto-detect from change description. See references/maintenance-classification.md for the full decision tree.

   Corrective changes additionally get urgency-based priority:

   Urgency	Criteria	Response
   P0 (Critical)	Data loss risk, core feature completely broken	Immediate
   P1 (High)	Major feature broken, no workaround	Same day
   P2 (Medium)	Feature broken, workaround exists	Next sprint
   P3 (Low)	Minor defect, cosmetic issue	Backlog

4. For each change, identify:

   • Category (FUN/NFR/OPS/REG/DER)
   • Subcategory (EXT/CVA/MAT/GDP/USR/ORG/OFF/CAN/SEL/DSH/SYS/PERF/SEC/etc.)
   • Affected existing REQs (if MODIFY or DEPRECATE)
   • Related existing REQs (that may need updating due to dependency)
   • Priority estimate (Must/Should/Could)
   • Stability estimate (Stable/Moderate/Volatile)
   • Maintenance category (Corrective/Adaptive/Perfective/Preventive)

5. Apply SWEBOK 5-Whys technique for unclear requests:

   • Ask "Why is this needed?" recursively (2-3 cycles)
   • Converge on the true requirement vs. proposed solution
   • Goal: identify the stakeholder need, not the implementation

6. Generate structured Change Request Summary:

## Change Request Summary

| # | Type | Maintenance | Category | Subcategory | Description | Affected REQs | Complexity |
|---|------|-------------|----------|-------------|-------------|----------------|-----------|
| CR-001 | ADD | Perfective | FUN | EXT | Bulk PDF extraction | - | Medium |
| CR-002 | MODIFY | Corrective (P2) | NFR | PERF | Increase timeout to 480s | REQ-PERF-001 | Low |
| CR-003 | DEPRECATE | Preventive | FUN | CAN | Remove percentile feature | REQ-CAN-011 | High |

Present to user for confirmation before proceeding.

Phase 2: Impact Analysis

Goal: Identify ALL documents affected by each change. SWEBOK v4 Ch01 (Software Requirements), Traceability: "Establish footprint for volume of work to incorporate change."

Steps per change request:

1. Direct Impact — Documents that MUST change:

2. Indirect Impact — Documents that SHOULD be reviewed:

3. Trace the full chain per affected REQ:

REQ-{id} → UC-{nnn} → WF-{nnn} → API-{module} → BDD-{feature} → INV-{area}-{nnn} → ADR-{nnn} → RN-{nnn}

4. Conflict Detection:

   • Check if change contradicts existing INVs
   • Check if change conflicts with existing ADR decisions
   • Check if change breaks existing BDD scenarios
   • Check if change violates CLARIFICATIONS business rules

5. Complexity Rating:

6. Generate Impact Matrix:

## Impact Matrix — CR-{NNN}

### Direct Impact (MUST change)
| Document | Section | Change Type | Description |
|----------|---------|-------------|-------------|
| requirements/REQUIREMENTS.md | §4.1 | ADD | New REQ-EXT-{NNN} |
| use-cases/UC-001.md | Flujo Principal | MODIFY | Add bulk step |
| contracts/API-pdf-reader.md | POST /extract | MODIFY | Add batch param |
| tests/BDD-extraction.md | Scenarios | ADD | New bulk scenario |

### Indirect Impact (SHOULD review)
| Document | Reason |
|----------|--------|
| domain/02-ENTITIES.md | May need BulkExtraction entity |
| nfr/LIMITS.md | May need bulk rate limits |

### Conflicts Detected
| Conflict | Severity | Resolution Needed |
|----------|----------|-------------------|
| INV-EXT-003 limits single PDF | Medium | Clarify: bulk bypasses or respects limit? |

### Complexity: {Low | Medium | High | Very High}
### Estimated documents to modify: {N}

### Regression Risk Matrix

| Area | Risk Level | Existing Tests | Mitigation |
|------|-----------|----------------|------------|
| {feature area} | {Low/Medium/High} | {BDD-xxx: N scenarios} | {existing coverage sufficient / needs new scenarios} |

### Downstream Pipeline Impact

| Artifact | Current Status | Action Needed |
|----------|---------------|---------------|
| plan/fases/FASE-{N}.md | {Fresh/Stale} | {Regenerate / No change} |
| task/TASK-FASE-{N}.md | {Fresh/Stale} | {Regenerate after plan update / No change} |
| src/ (FASE-{N} code) | {Fresh/Stale} | {New tasks needed / No change} |

### Code & Commit Impact

| Artifact | Commits | Last Commit | Files Affected |
|----------|---------|-------------|----------------|
| UC-002 | abc1234, def5678 | 2026-02-27 | src/auth/middleware.ts, src/auth/jwt.ts |
| INV-SYS-001 | ghi9012 | 2026-02-26 | src/middleware/tenant.ts |

Blast radius: {N} commits, {M} source files, {K} test files

7. Commit Impact Analysis (if git available):

   Check git availability first:

   git rev-parse --is-inside-work-tree 2>/dev/null
   

   If git is available, for each artifact in the Direct Impact list:

   git log --all --oneline --grep='Refs:.*{ARTIFACT-ID}'
   

   Build a commit impact map:

   • Artifact → commits: Which commits reference this artifact via Refs: trailers
   • Commits → files: Which source files were touched by those commits (git diff-tree --no-commit-id --name-only -r {SHA})
   • Last commit date: When was the most recent commit for this artifact

   Estimate blast radius:

   • Total unique commits referencing affected artifacts
   • Total unique source files touched by those commits
   • Total unique test files touched by those commits

   Graceful degradation: If git is not available, skip this step and note "Git not available — commit impact analysis skipped" in the Impact Matrix.

8. Code Intelligence Impact Analysis (if SDD MCP server available):

   IF the SDD MCP server is available (tool sdd_impact exists):

   result = sdd_impact({ artifact_id: "{ARTIFACT-ID}", direction: "downstream", maxDepth: 3 })
   

   Classify by depth:

   • d=1 (WILL_BREAK): Direct implementors — these symbols/files implement the artifact
   • d=2 (LIKELY_AFFECTED): Callers of implementors — functions that call the affected code
   • d=3 (MAY_NEED_REVIEW): Transitive callers — indirect dependents needing testing

   IF codeIntelligence data available in the graph (from /sdd-code-index):

   • Enrich the Impact Matrix with symbol-level detail:

   | Symbol | File | Depth | Callers | Risk |
   |--------|------|-------|---------|------|
   | validateUser() | src/auth/validator.ts | d=1 | 3 direct | HIGH |
   | handleLogin() | src/routes/auth.ts | d=2 | 2 direct | MEDIUM |
   | authMiddleware() | src/middleware/auth.ts | d=3 | 5 direct | LOW |
   

   ELSE:

   • Fallback to git-based analysis from Step 7 (commit blast radius only)

   Graceful degradation: If MCP server not available, rely entirely on Step 7's git-based analysis.

Phase 3: Clarification & Decision

Goal: Eliminate ALL ambiguities before planning changes. Every gap gets a question with options and a recommendation.

Methodology: SWEBOK v4 §3.1 (7 desirable properties) + §3.4 (Conflict Resolution)

Steps:

1. For each change request, evaluate against 7 SWEBOK properties:

2. For each ambiguity/gap, present options with recommendation:

### Question {N} of {M}: CR-{NNN} — {Short Title}

**Context:** {Why this question matters}
**Conflict/Gap:** {What's unclear or conflicting}

**Options:**
| Option | Description | Pros | Cons | Recommendation |
|--------|-------------|------|------|----------------|
| A | {description} | {pros} | {cons} | **Recommended** |
| B | {description} | {pros} | {cons} | |
| C | {description} | {pros} | {cons} | |

**Why Option A is recommended:** {rationale}
**Impact of each option on specs:** {brief}

3. For DEPRECATE changes, additional questions:

   • "What happens to data/behavior currently governed by this requirement?"
   • "Should deprecated REQ be marked as Won't Have or physically removed?"
   • "Are there migration steps needed for existing data?"

4. For ADD changes, formulate EARS statement:

   • Present EARS pattern options (Ubiquitous/Event/State/Optional/Unwanted/Complex)
   • Draft EARS statement and ask user to validate
   • Draft acceptance criteria (Gherkin) and ask user to validate

5. For MODIFY changes:

   • Show current EARS statement
   • Show proposed new EARS statement
   • Ask user to validate the delta

6. Collect all answers. Generate Clarification Log:

## Clarification Log — Change Request Session

> Date: YYYY-MM-DD
> Change Requests: {N}
> Questions Asked: {N}
> Questions Answered: {N}

### Q-001: {Title}
**Change Request:** CR-{NNN}
**Question:** {text}
**Answer:** {user's choice + rationale}
**Decision:** {what this means for the plan}
**Needs New ADR:** {Yes/No}
**Needs New INV:** {Yes/No}
**Needs New RN:** {Yes/No}

Phase 4: Change Plan Generation

Goal: Generate a complete, reviewable plan showing every change to every document with before/after.

Steps:

1. For each ADD change:

   • Generate new REQ with full template (ID, Category, EARS, Acceptance Criteria, Traceability)
   • Assign next available REQ-{SUB}-{NNN} ID (scan existing IDs to avoid collision)
   • Draft new UC sections / new UC if needed
   • Draft new API contract sections if needed
   • Draft new BDD scenarios if needed
   • Draft new INVs if needed (assign next available INV-{AREA}-{NNN})
   • Draft new ADRs if needed (assign next available ADR-{NNN})
   • Draft new RNs if needed (assign next available RN-{NNN})

2. For each MODIFY change:

   • Show current state (before) of every affected section
   • Show proposed state (after) of every affected section
   • Track cascading changes through traceability chain

3. For each DEPRECATE change:

   • Mark REQ as Deprecated with reason and date
   • Identify all spec sections to update/remove
   • Identify migration steps if applicable
   • Show deprecation plan for each affected document
   • For multi-REQ deprecations (entire feature removal), generate a Feature Sunset Plan:

   ### Feature Sunset Plan — {Feature Name}
   
   > Applies to: {list of REQ-IDs being deprecated}
   > Replacement: {replacement feature or "None — clean removal"}
   
   | Phase | Timeline | Action | Artifacts |
   |-------|----------|--------|-----------|
   | Announce | Sprint N | Mark as deprecated in API docs, add deprecation warnings | API contracts, CHANGELOG |
   | Disable New | Sprint N+1 | Prevent new usage of deprecated feature | API validation rules |
   | Migrate | Sprint N+2..N+4 | Migrate existing users/data to replacement | Migration scripts, communication |
   | Remove | Sprint N+5 | Remove code, specs, and all references | Full spec chain cleanup |
   
   **Sunset Checklist:**
   - [ ] Replacement feature exists and is stable
   - [ ] Migration path documented
   - [ ] All consumers notified
   - [ ] Data migration tested
   - [ ] Rollback plan exists
   

   See references/maintenance-classification.md §7 for the full sunset template.

4. Apply Atomic Cross-Check Rule (from sdd-spec-auditor Mode Fix):

5. Group changes by document for atomic execution:

   • Each document gets ONE edit pass (no revisiting)
   • Changes ordered: REQUIREMENTS → domain → invariants → UCs → contracts → tests → NFR → ADRs → CLARIFICATIONS → CHANGELOG
   • Requirements FIRST: the REQ defines the change; specs propagate it

6. Generate changes/CHANGE-PLAN-{id}.md:

# Change Plan — {Change Request ID}

> Generated: YYYY-MM-DD
> Source: {text free | CHANGE-REQUEST.md | both}
> Change Requests: {N} (ADD:{N} MODIFY:{N} DEPRECATE:{N})
> Documents affected: {N}
> Estimated complexity: {Low | Medium | High | Very High}
> Spec version: v{current} → v{proposed}

## Summary Table

| # | CR-ID | Type | REQ-ID | Severity | Documents | Breaking |
|---|-------|------|--------|----------|-----------|----------|
| 1 | CR-001 | ADD | REQ-EXT-{new} | - | 5 | No |
| 2 | CR-002 | MODIFY | REQ-PERF-001 | Medium | 3 | No |
| 3 | CR-003 | DEPRECATE | REQ-CAN-011 | High | 8 | Yes |

## Detailed Changes

### CR-001: {Title} [ADD]

#### New Requirement: REQ-{SUB}-{NNN}

| Field | Value |
|-------|-------|
| **ID** | REQ-{SUB}-{NNN} |
| **Category** | {Functional | Non-Functional | Operational | Regulatory | Derived} |
| **Subcategory** | {area} |
| **Priority** | {Must Have | Should Have | Could Have} |
| **Stability** | {Stable | Moderate | Volatile} |
| **Source** | {CR-001, answered questions} |

**EARS Statement:**
> {EARS-formatted requirement}

**Acceptance Criteria:**
```gherkin
Given {precondition}
When {action}
Then {expected result}

Traceability:

Spec Changes for CR-001

1. {document path}

Section: {section name} Action: {ADD section | MODIFY section | REMOVE section}

Before:

{current text, or "(new section)" for ADD}

After:

{proposed text}

Rationale: {why this change is needed for CR-001}

2. {next document}

[... repeat for each affected document ...]

New Artifacts for CR-001

Dependencies

{Other CRs that must be applied first, or "None"}

CR-002: {Title} [MODIFY]

[... same structure with before/after for existing REQ ...]

CR-003: {Title} [DEPRECATE]

Deprecated Requirement: REQ-CAN-011

Current EARS Statement:

{current statement}

Deprecation Reason: {user's stated reason} Migration: {migration steps if applicable, or "None — clean removal"}

Spec Changes for CR-003

[... before/after for each document, showing removals ...]

Breaking Changes

Execution Order

Version Impact

• Spec version: v{current} → v{proposed}
• REQUIREMENTS.md version: {current} → {proposed}
• Documents with version bumps: {list}

**If `--dry-run`: STOP HERE. Present plan and exit.**

---

### Phase 5: User Review & Approval

**Goal:** Get explicit user approval before modifying any file.

**Steps:**

1. Present the Change Plan summary to user
2. Ask workflow mode:

| Mode | Description |
|------|-------------|
| **Batch** (default with `--batch`) | Apply all recommended changes. User already answered all questions in Phase 3. |
| **Interactive** | Present each CR separately. User approves/modifies/rejects per CR. |

3. For **Interactive mode**, per CR:
   - Show full before/after
   - Ask: "Apply this change? (Yes / Modify / Skip)"
   - If Modify: collect new input, re-run Phase 3-4 for that CR only
   - If Skip: mark as skipped in report

4. For **Batch mode**:
   - Show summary table
   - Ask: "Apply all {N} changes? (Yes / Review individually)"

**Approval required before any file modification.**

---

### Phase 6: Change Execution

**Goal:** Apply all approved changes atomically across all documents.

**Execution Order (MANDATORY — requirements-first, then propagate to specs):**

> **IMPORTANT:** Unlike `sdd-spec-auditor` Mode Fix (which goes specs-first because it fixes specs from audit findings),
> this skill is a **Requirements Change Manager**. The requirement is the source of truth for the change.
> Therefore: define the requirement FIRST, then propagate to specifications.

1. requirements/REQUIREMENTS.md (ADD/MODIFY/DEPRECATE REQs — the SOURCE of the change)
2. domain/01-GLOSSARY.md (new terms if needed by the REQ)
3. domain/02-ENTITIES.md (new/modified entities derived from REQ)
4. domain/03-VALUE-OBJECTS.md (new/modified VOs derived from REQ)
5. domain/04-STATES.md (new/modified states derived from REQ)
6. domain/05-INVARIANTS.md (new INVs derived from REQ)
7. use-cases/UC-*.md (new/modified UCs implementing REQ)
8. workflows/WF-*.md (new/modified WFs implementing REQ)
9. contracts/API-*.md (new/modified contracts implementing REQ)
10. contracts/EVENTS-*.md (new/modified events)
11. contracts/PERMISSIONS-MATRIX.md (if roles affected)
12. tests/BDD-*.md (new/modified BDD scenarios verifying REQ)
13. tests/PROPERTIES.md (if property tests affected)
14. nfr/*.md (if NFRs affected)
15. adr/ADR-*.md (new ADRs for decisions needed by REQ)
16. runbooks/*.md (if operational procedures affected)
17. CLARIFICATIONS.md (new RNs derived from REQ)
18. CHANGELOG.md (record all changes)

> **Rationale:** The requirement defines WHAT changes. Specifications define HOW it manifests.
> By writing the requirement first, every subsequent spec edit can reference the authoritative
> REQ-ID, EARS statement, and acceptance criteria as the source of truth for the change.

**Per-document execution rules:**

1. Read current file content
2. Apply ALL changes for that file in single pass
3. Increment document version if file has version header
4. Update any cross-reference tables within the file
5. Verify ubiquitous language compliance (glossary terms only)

**REQUIREMENTS.md specific rules:**

For ADD:
- Insert new REQ in correct subcategory section (maintain alphabetical order within subcategory)
- Update §3 Executive Summary counts
- Update §9 Traceability Matrix
- Update §10 Coverage section
- Update Appendix Statistics

For MODIFY:
- Replace REQ content in-place
- Update traceability if sources changed
- Update §9 if traceability changed

For DEPRECATE:
- Add `**Status:** Deprecated (YYYY-MM-DD) — {reason}` to REQ header
- Move to new §12 "Deprecated Requirements" section (create if doesn't exist)
- Remove from §9 active traceability
- Add to §12 deprecation history
- Update §3 counts (reduce category count, add deprecated count)
- Update Appendix Statistics

**Git Commits:**

One commit per logical change group (1 CR = 1 commit unless very large):

feat(specs): add REQ-{SUB}-{NNN} - {brief description}

Change Request: CR-{NNN} Type: ADD Documents: {comma-separated list} Requirements affected: REQ-{SUB}-{NNN}

Co-Authored-By: Claude Opus 4.6 noreply@anthropic.com

fix(specs): modify REQ-{SUB}-{NNN} - {brief description}

Change Request: CR-{NNN} Type: MODIFY Documents: {comma-separated list} Requirements affected: REQ-{SUB}-{NNN} Breaking: {Yes/No}

Co-Authored-By: Claude Opus 4.6 noreply@anthropic.com

refactor(specs): deprecate REQ-{SUB}-{NNN} - {brief description}

Change Request: CR-{NNN} Type: DEPRECATE Documents: {comma-separated list} Requirements affected: REQ-{SUB}-{NNN} Migration: {Yes/No}

Co-Authored-By: Claude Opus 4.6 noreply@anthropic.com

---

### Phase 7: Alignment Audit

**Goal:** Verify that after all changes, requirements and specifications are perfectly aligned. This is a **focused mini-audit** on affected documents only (not a full cross-document audit).

**Audit Checks (8 alignment verifications):**

| # | Check | Description | Severity if Fails |
|---|-------|-------------|-------------------|
| AA-01 | **REQ → Spec Forward Coverage** | Every new/modified REQ has at least one spec source | Critical |
| AA-02 | **Spec → REQ Backward Coverage** | Every modified spec section contributes to at least one REQ | Critical |
| AA-03 | **Traceability Chain Completeness** | Every new/modified REQ has: Source + Implements + Verifies + Guarantees | High |
| AA-04 | **Cross-Reference Validity** | All cross-references in modified documents resolve to existing targets | Critical |
| AA-05 | **Glossary Compliance** | No undefined terms or synonyms introduced in modified sections | High |
| AA-06 | **Contradiction Check** | No modified section contradicts another document section | Critical |
| AA-07 | **EARS Pattern Compliance** | All new/modified REQs use valid EARS pattern | Medium |
| AA-08 | **Acceptance Criteria Testability** | All new/modified Gherkin scenarios are concrete and testable | Medium |

**Additional checks for DEPRECATE:**

| # | Check | Description | Severity if Fails |
|---|-------|-------------|-------------------|
| AA-09 | **No Orphan References** | No remaining document references deprecated REQ | Critical |
| AA-10 | **Dependent REQ Update** | All REQs that depended on deprecated REQ updated or flagged | High |

**Audit Execution:**

1. For each affected document:
   - Re-read the modified file
   - Run checks AA-01 through AA-08 (+ AA-09/AA-10 for deprecations)
   - Record findings

2. Cross-document verification:
   - Verify all new cross-references resolve
   - Verify no broken links created
   - Verify REQUIREMENTS.md traceability matrix consistent with actual spec content

3. Generate audit results:

```markdown
## Alignment Audit Results

> Scope: {N} documents audited (focused on changes only)
> Checks executed: {8 | 10}
> Findings: {N}

| # | Check | Status | Details |
|---|-------|--------|---------|
| AA-01 | REQ → Spec Forward | PASS | All {N} REQs have spec sources |
| AA-02 | Spec → REQ Backward | PASS | All {N} modified sections covered |
| AA-03 | Traceability Complete | PASS | {N}/{N} chains complete |
| AA-04 | Cross-Refs Valid | PASS | {N} references validated |
| AA-05 | Glossary Compliance | PASS | No violations |
| AA-06 | Contradiction Check | PASS | No contradictions |
| AA-07 | EARS Compliance | PASS | {N}/{N} REQs compliant |
| AA-08 | Testability | PASS | {N}/{N} scenarios testable |

### Findings (if any)
| # | Check | Severity | Location | Problem | Auto-Fix Applied |
|---|-------|----------|----------|---------|------------------|
| 1 | AA-04 | Critical | UC-001.md:45 | Reference to non-existent INV-EXT-099 | Yes: corrected to INV-EXT-{correct} |

### Verdict: {ALIGNED | GAPS DETECTED}

If gaps detected:

• For auto-fixable issues (typos, broken refs): fix immediately and re-audit
• For non-auto-fixable issues: include in Change Report as "Open Items"
• NEVER ignore a failed alignment check

Phase 8: Change Report Generation

Goal: Generate a comprehensive document that provides full context for subsequent planning, task creation, and implementation.

Output: changes/CHANGE-REPORT-{YYYY-MM-DD}-{short-id}.md

Structure:

# Change Report — {Short Title}

> **Report ID:** CHG-{YYYY-MM-DD}-{NNN}
> **Date:** YYYY-MM-DD
> **Spec version:** v{before} → v{after}
> **REQUIREMENTS.md version:** {before} → {after}
> **Change Requests:** {N} (ADD:{N} MODIFY:{N} DEPRECATE:{N})
> **Documents modified:** {N}
> **Alignment audit:** {ALIGNED | N gaps}
> **Breaking changes:** {Yes (N) | No}

---

## 1. Executive Summary

{2-3 paragraph description of what changed and why. Written for someone who needs to understand the full scope of changes without reading every detail.}

### Change Request Summary

| # | CR-ID | Type | REQ-ID(s) | Category | Priority | Complexity | Status |
|---|-------|------|-----------|----------|----------|------------|--------|
| 1 | CR-001 | ADD | REQ-EXT-{NNN} | FUN | Must | Medium | Applied |
| 2 | CR-002 | MODIFY | REQ-PERF-001 | NFR | Must | Low | Applied |
| 3 | CR-003 | DEPRECATE | REQ-CAN-011 | FUN | - | High | Applied |

---

## 2. Changes Applied

### 2.1 New Requirements Added

#### REQ-{SUB}-{NNN}: {Title}

**EARS Statement:**
> {statement}

**Acceptance Criteria:**
```gherkin
{criteria}

Traceability:

Specs Created/Modified:

2.2 Requirements Modified

REQ-{SUB}-{NNN}: {Title}

Before:

{previous EARS statement}

After:

{new EARS statement}

Reason: {rationale from clarification}

Cascade Changes:

2.3 Requirements Deprecated

REQ-{SUB}-{NNN}: {Title} [DEPRECATED]

Previous EARS Statement:

{statement}

Deprecation Reason: {reason} Migration Steps: {steps or "None"}

Removed from:

3. New Artifacts Created

4. Impact Analysis Summary

4.1 Documents Modified

4.2 Breaking Changes

4.3 Cross-Reference Updates

5. Alignment Audit Results

{Full audit results from Phase 7}

6. Clarification Decisions

{Full clarification log from Phase 3 — preserves all decisions and rationale}

7. Context for Planning & Implementation

7.1 Affected FASE Files

Action: Run sdd-plan-architect to regenerate FASE files after this change.

7.2 Architecture Impact

{Description of architectural implications: new endpoints, new entities, new events, modified data flows}

7.3 Implementation Considerations

7.4 Recommended Next Steps

1. Run sdd-plan-architect to regenerate FASE files
2. Run sdd-plan-architect --fase {N} to update implementation plan for affected phases
3. Create implementation tasks for each change
4. {Additional recommendations based on change scope}

7.5 Risk Assessment

7.6 Maintenance Classification (ISO 14764)

7.7 Pipeline Cascade Plan

Cascade mode: {auto | manual | dry-run | plan-only} Invalidated stages: {N}

7.8 Technical Debt Impact (if applicable)

Track open debt items in the project's technical debt register. Preventive maintenance changes should reference and resolve existing TD-* items.

8. Git Commits

…(truncated)