# Affected Components Analysis

## Direct Impact

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

## Indirect Impact (Dependencies)

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

## Integration Points

External systems affected:

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

// BEFORE
function login(email: string, password: string): Promise<Session>;

// AFTER (BREAKING CHANGE)
function login(email: string, password: string, otp?: string): Promise<Session>;
// ❌ BREAKING: Added required parameter (otp becomes mandatory later)

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

## Dependency Impact

### 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

2. **Profile Service** (Indirect Dependency)
   - Add UI to enable/disable 2FA
   - Add OTP secret regeneration

3. **Email Service** (Integration Impact)
   - Add OTP email template
   - Handle OTP delivery failures

4. **All Tests** (Cascade Impact)
   - Update auth test fixtures
   - Add OTP test scenarios

# 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                    |

## Overall Risk Level: **HIGH**

### 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

# Migration Plan: Add Two-Factor Authentication

## Phase 1: Database Migration (Week 1)

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)

## Phase 2: Backend Implementation (Week 2)

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

## Phase 3: Client Updates (Week 3)

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

## Phase 4: Gradual Rollout (Week 4-6)

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

## Phase 5: Mandatory Enforcement (Month 2)

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

## Rollback Plan

If issues detected:

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

# ✅ VALID Delta Spec

## ADDED Requirements

### REQ-NEW-001: Two-Factor Authentication

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

## MODIFIED Requirements

### REQ-001: User Authentication

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

## REMOVED Requirements

(None)

## RENAMED Requirements

(None)

# 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"

🤖 確認ありがとうございます。影響分析レポートを順番に生成します。

【生成予定のセクション】
1. Executive Summary
2. Affected Components
3. Breaking Changes
4. Risk Assessment
5. Recommendations
6. Approval Checklist

合計: 6セクション

**重要: 段階的生成方式**
各セクションを1つずつ生成・保存し、進捗を報告します。
これにより、途中経過が見え、エラーが発生しても部分的なレポートが残ります。

生成を開始してよろしいですか?
👤 ユーザー: [回答待ち]

🤖 [1/6] Executive Summaryを生成しています...

📝 impact-analysis/add-two-factor-auth-report.md (Section 1)
✅ 保存が完了しました

[1/6] 完了。次のセクションに進みます。

🤖 [2/6] Affected Componentsを生成しています...

📝 impact-analysis/add-two-factor-auth-report.md (Section 2)
✅ 保存が完了しました

[2/6] 完了。次のセクションに進みます。

🤖 影響分析レポート全体が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行)
💡 必要に応じて統合版も生成できます

🤖 ✨ 影響分析レポートの生成が完了しました！

## 📊 分析サマリー
- **影響を受けるコンポーネント**: 12ファイル
- **破壊的変更**: 1件
- **リスクレベル**: HIGH

## 📂 生成されたレポート
✅ impact-analysis/add-two-factor-auth-report.md (6セクション)

# Change Impact Analysis Report

**Change ID**: add-two-factor-auth
**Proposed By**: [User]
**Date**: 2025-11-16

## Executive Summary

- **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

## Detailed Analysis

[Sections from above]

## Recommendations

### 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

## Approval

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

# Change Impact Analysis: [Change Title]

**Change ID**: [change-id]
**Analyzer**: change-impact-analyzer
**Date**: [YYYY-MM-DD]

## Impact Summary

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

## Affected Components

[List from Phase 2]

## Breaking Changes

[List from Phase 3]

## Dependency Graph

[Mermaid diagram from Phase 4]

## Risk Assessment

[Matrix from Phase 5]

## Migration Plan

[Phased plan from Phase 6]

## Delta Spec Validation

✅ VALID / ❌ INVALID
[Validation results]

## Recommendations

[Prioritized action items]

## Approval Status

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