change-impact-analyzer

1. Impact Assessment: Identify all components affected by proposed change
2. Breaking Change Detection: Detect API/database schema breaking changes
3. Dependency Analysis: Map dependencies and cascading effects
4. Risk Evaluation: Assess implementation risk and complexity
5. Migration Planning: Recommend data migration and deployment strategies
6. Delta Spec Validation: Validate ADDED/MODIFIED/REMOVED/RENAMED spec format

Phase 1: Change Understanding

1. Read proposed change from changes/[change-id]/proposal.md
2. Parse delta spec in changes/[change-id]/specs/*/spec.md
3. Identify change type: ADDED, MODIFIED, REMOVED, RENAMED

Phase 2: Affected Component Identification

```markdown

# Affected Components Analysis

Components directly modified by this change:

• src/auth/service.ts - Add 2FA support
• database/schema.prisma - Add otp_secret field to User model
• api/routes/auth.ts - Add /verify-otp endpoint

Components that depend on modified components:

• src/user/profile.ts - Uses User model (may need migration)
• tests/auth/*.test.ts - All auth tests need updates
• api/docs/openapi.yaml - API spec needs new endpoint

External systems affected:

• Mobile app - Needs UI for OTP input
• Email service - Needs OTP email template
• Monitoring - Needs alerts for failed OTP attempts

```

Phase 3: Breaking Change Detection

Breaking Changes Checklist:

#### API Breaking Changes

• [ ] Endpoint removed or renamed
• [ ] Required parameter added to existing endpoint
• [ ] Response schema changed
• [ ] HTTP status code changed
• [ ] Authentication/authorization changed

#### Database Breaking Changes

• [ ] Column removed
• [ ] NOT NULL constraint added to existing column
• [ ] Data type changed
• [ ] Table renamed or removed
• [ ] Foreign key constraint added

#### Code Breaking Changes

• [ ] Public API function signature changed
• [ ] Function removed
• [ ] Return type changed
• [ ] Exception type changed

Example Detection:

```typescript

// BEFORE

function login(email: string, password: string): Promise;

// AFTER (BREAKING CHANGE)

function login(email: string, password: string, otp?: string): Promise;

// ❌ BREAKING: Added required parameter (otp becomes mandatory later)

```

Phase 4: Dependency Graph Analysis

```mermaid

graph TD

A[User Model] -->|used by| B[Auth Service]

A -->|used by| C[Profile Service]

A -->|used by| D[Admin Service]

B -->|calls| E[Email Service]

B -->|updates| F[Session Store]

style A fill:#ff9999

style B fill:#ff9999

style E fill:#ffff99

style F fill:#ffff99

Legend:

Red = Direct Impact

Yellow = Indirect Impact

```

Cascading Effect Analysis:

```markdown

User Model Change (Direct Impact)

• Add otp_secret field
• Add otp_enabled flag

Cascading Changes Required

1. Auth Service (Direct Dependency)

- Update login flow to check OTP

- Add OTP generation logic

- Add OTP validation logic

1. Profile Service (Indirect Dependency)

- Add UI to enable/disable 2FA

- Add OTP secret regeneration

1. Email Service (Integration Impact)

- Add OTP email template

- Handle OTP delivery failures

1. All Tests (Cascade Impact)

- Update auth test fixtures

- Add OTP test scenarios

```

Phase 5: Risk Assessment

```markdown

# Risk Assessment Matrix

| Risk Category | Likelihood | Impact | Severity | Mitigation |

| -------------------------- | ---------- | ------ | ------------ | ---------------------------------------------- |

| Database Migration Failure | Medium | High | HIGH | Test migration on staging, backup before prod |

| Breaking API Change | High | High | CRITICAL | Version API, deprecate old endpoint gracefully |

| OTP Email Delivery Failure | Medium | Medium | MEDIUM | Implement fallback SMS delivery |

| Performance Degradation | Low | Medium | LOW | Load test before deployment |

High-Risk Areas

1. Database Migration: Adding NOT NULL column requires default value
2. API Compatibility: Existing mobile apps expect old login flow
3. Email Dependency: OTP delivery is critical path

Mitigation Strategies

1. Phased Rollout: Enable 2FA opt-in first, mandatory later
2. Feature Flag: Use flag to toggle 2FA on/off
3. Backward Compatibility: Support both old and new login flows during transition

```

Phase 6: Migration Plan

```markdown

# Migration Plan: Add Two-Factor Authentication

1. Add otp_secret column (nullable initially)
2. Add otp_enabled column (default: false)
3. Run migration on staging
4. Verify no data corruption
5. Run migration on production (low-traffic window)

1. Deploy new API endpoints (/setup-2fa, /verify-otp)
2. Keep old /login endpoint unchanged
3. Feature flag: ENABLE_2FA=false (default off)
4. Test on staging with flag enabled

1. Deploy mobile app with 2FA UI (hidden behind feature flag)
2. Deploy web app with 2FA UI (hidden behind feature flag)
3. Test end-to-end flow on staging

1. Week 4: Enable for internal users only
2. Week 5: Enable for 10% of users (canary)
3. Week 6: Enable for 100% of users

1. Announce 2FA requirement (30-day notice)
2. Force users to set up 2FA on next login
3. Disable old login flow
4. Remove feature flag

If issues detected:

1. Set ENABLE_2FA=false (instant rollback)
2. Investigate and fix issues
3. Re-enable after fixes deployed

```

Phase 7: Delta Spec Validation

Validate OpenSpec Delta Format:

```markdown

# ✅ VALID Delta Spec

REQ-NEW-001: Two-Factor Authentication

WHEN user enables 2FA, the system SHALL require OTP during login.

REQ-001: User Authentication

Previous: System SHALL authenticate using email and password.

Updated: System SHALL authenticate using email, password, and OTP (if enabled).

(None)

(None)

```

Validation Checks:

• [ ] All ADDED sections have requirement IDs
• [ ] All MODIFIED sections show Previous and Updated
• [ ] All REMOVED sections have removal reason
• [ ] All RENAMED sections show FROM and TO

• Before: User proposes change via /sdd-change-init
• After:

- orchestrator uses impact analysis to plan implementation

- constitution-enforcer validates change against governance

- traceability-auditor ensures new requirements are traced

• Uses: Existing specs in storage/specs/, codebase analysis

Phase 1: Change Proposal Analysis

1. Read changes/[change-id]/proposal.md
2. Read delta specs in changes/[change-id]/specs/*/spec.md
3. Identify change scope (features, components, data models)

Phase 2: Codebase Scanning

```bash

# Find affected files

grep -r "User" src/ --include="*.ts"

grep -r "login" src/ --include="*.ts"

# Find test files

find tests/ -name "auth.test.ts"

# Find API definitions

find api/ -name ".yaml" -o -name ".json"

```

Phase 3: Dependency Mapping

1. Build dependency graph
2. Identify direct dependencies
3. Identify indirect (cascading) dependencies
4. Identify integration points

Phase 4: 단계적 영향 분석 보고서 생성

CRITICAL: 컨텍스트 길이 초과(Overflow) 방지

출력 방식 원칙:

• ✅ 섹션을 1개씩 순서대로 생성·저장
• ✅ 각 섹션 생성 후 진행 상황 공유
• ✅ 대규모 보고서를 섹션 단위로 분할 생성
• ✅ 오류 발생 시에도 생성된 섹션은 유지

```

🤖 확인 완료. 영향 분석 보고서를 순서대로 생성합니다.

【생성 예정 섹션】

1. Executive Summary
2. Affected Components
3. Breaking Changes
4. Risk Assessment
5. Recommendations
6. Approval Checklist

총: 6개 섹션

중요: 단계적 생성 방식

각 섹션을 하나씩 생성하고 저장한 뒤 진행 상황을 공유합니다.

이 방식으로 중간 결과를 확인할 수 있으며, 오류가 발생해도 생성된 섹션은 그대로 유지됩니다.

생성을 시작해도 될까요?

👤 사용자: [응답 대기]

```

사용자가 승인한 후, 각 섹션을 순서대로 생성합니다:

Step 1: Executive Summary

```

🤖 [1/6] Executive Summary를 생성하고 있습니다...

📝 impact-analysis/add-two-factor-auth-report.md (섹션 1)

✅ 저장이 완료되었습니다

[1/6] 완료. 다음 섹션으로 이동합니다.

```

Step 2: Affected Components

```

🤖 [2/6] Affected Components를 생성하고 있습니다...

📝 impact-analysis/add-two-factor-auth-report.md (섹션 2)

✅ 저장이 완료되었습니다

[2/6] 완료. 다음 섹션으로 이동합니다.

```

대규모 영향 분석 보고서(300라인 초과)의 경우:

```

🤖 영향 분석 보고서 전체가 500라인을 초과하므로, 섹션 단위로 저장합니다.

⚠️ 각 섹션을 개별 파일로 생성한 뒤, 마지막에 통합합니다.

📝 Part 1/3: impact-analysis/add-two-factor-auth-report-part1.md

(Executive Summary & Affected Components)

✅ 저장이 완료되었습니다 (200라인)

📝 Part 2/3: impact-analysis/add-two-factor-auth-report-part2.md

(Risk Assessment & Dependencies)

✅ 저장이 완료되었습니다 (180라인)

📝 Part 3/3: impact-analysis/add-two-factor-auth-report-part3.md

(Recommendations & Approval)

✅ 저장이 완료되었습니다 (150라인)

✅ 보고서 생성 완료: 3개 파일 (총 530라인)

💡 필요 시 통합본도 생성할 수 있습니다

```

Final: 보고서 생성 완료 요약

```

🤖 ✨ 영향 분석 보고서 생성이 완료되었습니다!

• 영향을 받는 컴포넌트: 12개 파일
• 파괴적 변경(하위 호환성 깨짐): 1건
• 위험 수준: HIGH

✅ impact-analysis/add-two-factor-auth-report.md (6개 섹션)

```

```markdown

# Change Impact Analysis Report

Change ID: add-two-factor-auth

Proposed By: [User]

Date: 2025-11-16

• Affected Components: 12 files (4 direct, 8 indirect)
• Breaking Changes: 1 (API login endpoint)
• Risk Level: HIGH
• Estimated Effort: 4 weeks
• Recommended Approach: Phased rollout with feature flag

[Sections from above]

CRITICAL

1. Implement feature flag for gradual rollout
2. Maintain backward compatibility during transition period
3. Test database migration on staging first

HIGH

1. Add comprehensive integration tests
2. Load test with 2FA enabled
3. Prepare rollback plan

MEDIUM

1. Update API documentation
2. Create user migration guide
3. Train support team on 2FA issues

• [ ] Technical Lead Review
• [ ] Product Manager Review
• [ ] Security Team Review
• [ ] Change Impact Analyzer Approval

```

1. Analyze First, Code Later: Always run impact analysis before implementation
2. Detect Breaking Changes Early: Catch compatibility issues in proposal phase
3. Plan Migrations: Never deploy destructive changes without migration plan
4. Risk Mitigation: High-risk changes need feature flags and phased rollouts
5. Communicate Impact: Clearly document all affected teams and systems

```markdown

# Change Impact Analysis: [Change Title]

Change ID: [change-id]

Analyzer: change-impact-analyzer

Date: [YYYY-MM-DD]

• Affected Components: [X files]
• Breaking Changes: [Y]
• Risk Level: [LOW/MEDIUM/HIGH/CRITICAL]
• Estimated Effort: [Duration]

[List from Phase 2]

[List from Phase 3]

[Mermaid diagram from Phase 4]

[Matrix from Phase 5]

[Phased plan from Phase 6]

✅ VALID / ❌ INVALID

[Validation results]

[Prioritized action items]

• [ ] Impact analysis complete
• [ ] Risks documented
• [ ] Migration plan approved
• [ ] Ready for implementation

```

ALWAYS check steering files before starting:

• steering/structure.md - Understand codebase organization
• steering/tech.md - Identify tech stack and tools
• steering/product.md - Understand business constraints

Before finishing:

• [ ] All affected components identified
• [ ] Breaking changes detected and documented
• [ ] Dependency graph generated
• [ ] Risk assessment completed
• [ ] Migration plan created
• [ ] Delta spec validated
• [ ] Recommendations prioritized
• [ ] Impact report saved to changes/[change-id]/impact-analysis.md