sdd-change

/claude-sdd:sdd-change — 변경 관리

통합이 완료된 프로젝트에서 변경 요청(CR)을 체계적으로 처리합니다. 영향 분석 → 기존 스펙 업데이트 → 체크리스트 부분 갱신 → TDD 델타 빌드 → 회귀 검증 → PR 생성의 7단계 프로세스를 실행합니다.

사용법

/claude-sdd:sdd-change                    # 새 변경 요청 시작
/claude-sdd:sdd-change status             # 변경 사이클 상태 확인
/claude-sdd:sdd-change resume             # 진행 중인 변경 사이클 재개

# 레거시 분석 기반 옵션
/claude-sdd:sdd-change --from-analysis                  # 분석 보고서 갭에서 CR 자동 생성
/claude-sdd:sdd-change --lightweight --from-analysis     # 소규모 갭 빠른 처리 (Phase 1-4 자동)

# 멀티 도메인 옵션
/claude-sdd:sdd-change --domain=<id>      # 특정 도메인 변경 관리
/claude-sdd:sdd-change --domain=<id> status   # 특정 도메인 변경 상태
/claude-sdd:sdd-change --domain=<id> resume   # 특정 도메인 변경 재개

사전 조건

1. docs/specs/sdd-config.yaml을 읽어 프로젝트 설정을 확인합니다.

2. 전제조건 확인 (프로젝트 유형에 따라):

   레거시 프로젝트 (project.type: legacy):

   • 10-analysis-report.md가 존재해야 합니다 (분석 완료 상태)
   • 08-review-report.md는 불필요합니다 (갭 해소가 리뷰 전에 수행됨)
   • 분석이 완료되지 않은 경우 안내:

     이 프로젝트는 아직 분석이 완료되지 않았습니다.
     먼저 /claude-sdd:sdd-build를 실행하여 분석을 수행하세요.
     
     현재 상태: [현재 단계]
     체크리스트: X/Y 완료 (Z%)
     

   신규 프로젝트 (project.type: new):

   • 08-review-report.md가 존재하고 리뷰가 통과된 상태여야 합니다 (기존 동작)
   • 통합이 완료되지 않은 경우 안내:

     이 프로젝트는 아직 통합이 완료되지 않았습니다.
     먼저 /claude-sdd:sdd-integrate를 실행하세요.
     
     현재 상태: [현재 단계]
     체크리스트: X/Y 완료 (Z%)
     

3. 도메인 모드 감지: domains 키 존재 여부로 단일/멀티 도메인 모드를 결정합니다.

---

--from-analysis: 분석 보고서 기반 CR 생성

--from-analysis 플래그가 있으면 10-analysis-report.md의 "추천 변경 요청" 섹션에서 CR을 자동으로 생성합니다.

동작

1. 10-analysis-report.md를 읽어 갭 항목과 추천 CR 그룹을 파싱합니다.
2. 사용자에게 CR 생성 방식을 확인합니다:

   분석 보고서에서 6개 갭 항목이 식별되었습니다.
   
   추천 변경 요청:
     CR-001: API 레이어 갭 (3개 항목)
     CR-002: 데이터 모델 갭 (1개 항목)
     CR-003: 테스트 커버리지 갭 (2개 항목)
   
   옵션:
     1. 전체 수락 — 3개 CR 생성
     2. 단일 CR — 모든 갭을 1개 CR로 통합
     3. 커스터마이즈 — 그룹핑 조정
   

3. 선택에 따라 09-change-request.md를 생성하고 Phase 2로 진행합니다.

CR 자동 생성 시 Phase 1 간소화

--from-analysis 모드에서는 Phase 1의 인터뷰 질문을 건너뛰고, 분석 보고서의 갭 정보로 CR을 채웁니다:

• 변경 요약: "분석 보고서 갭 해소" + 갭 항목 요약
• 변경 사유: "레거시 분석에서 식별된 스펙 미충족 항목 보완"
• 변경 범위: 분석 보고서의 갭 항목 목록
• 우선순위: 분석 보고서의 추천 우선순위
• 제약 조건: "기존 코드 구조 보존, 하위 호환성 유지, 기존 테스트 무결성"
• gap_source: 10-analysis-report.md (추적성을 위한 참조)

---

--lightweight: 소규모 갭 빠른 처리

--lightweight 플래그는 --from-analysis와 함께 사용하며, 소규모 갭에 대해 Phase 1-4를 자동 처리합니다.

자동 감지 기준

다음 조건을 모두 만족하면 자동으로 lightweight 모드를 권장합니다:

• 레거시 프로젝트 (project.type: legacy)
• 분석 기반 CR (gap_source: 10-analysis-report.md)
• 갭 항목 5개 이하
• 크로스 모듈 영향 없음 (갭이 단일 모듈 내에 집중)

Lightweight 동작

전체 Phase	Lightweight
Phase 1: CR 수집	분석 보고서에서 자동 생성 ✓
Phase 2: 영향 분석	건너뜀 (분석에서 이미 범위 파악)
Phase 3: 체크리스트 갱신	자동 적용 (갭 항목 → CHG- 항목)
Phase 4: 태스크 계획	단일 CWP 자동 생성
Phase 5: TDD 델타 빌드	정상 실행
Phase 6: 리뷰 + 회귀 검증	정상 실행
Phase 7: PR 생성	정상 실행

Lightweight 체크리스트 자동 갱신

Phase 3 자동 적용 시:

1. 갭 항목을 CHG- 항목으로 변환합니다.
2. 분석 보고서에서 근접한 기존 코드에 대해 CHG-REG- 회귀 테스트 항목을 추가합니다.
3. 기존 [x] 항목은 재설정하지 않습니다 (충족 (satisfied) 항목 보존).

Lightweight 모드 — 자동 설정 완료

Phase 1-4 자동 완료:
  CR: CR-001 (분석 갭 해소)
  CHG 항목: 3개 (API-003, SEC-001, TEST-004)
  CHG-REG 항목: 2개 (회귀 테스트)
  CWP: 1개 (CWP-001)

Phase 5로 진행합니다 — TDD 델타 빌드...

---

Phase 0: 브랜치 확인 및 생성

변경 관리 시작 전에 현재 Git 브랜치를 확인합니다.

1. git branch --show-current로 현재 브랜치를 확인합니다.
2. 브랜치가 feature/로 시작하면 건너뜁니다.
3. feature/가 아닌 경우: a. Jira 소스가 설정된 경우: feature/CR-<N>-<jira-key> (예: feature/CR-001-DEV-200) b. Jira 소스가 없는 경우: feature/change-CR-<N> 또는 사용자 입력
4. git checkout -b feature/<name> 실행

---

Phase 1: 변경 요청 수집

사용자와 대화하여 변경 요청 정보를 수집합니다.

인터뷰 질문

1. 변경 요약: 어떤 변경이 필요한가요?
2. 변경 사유: 왜 이 변경이 필요한가요? (비즈니스 요구, 버그, 성능 등)
3. 변경 범위: 어떤 기능/API/데이터 모델이 영향받나요?
4. 우선순위: 긴급/높음/보통/낮음?
5. 제약 조건: 하위 호환성, 다운타임, 마이그레이션 관련 제약이 있나요?

CR ID 자동 생성

기존 변경 이력을 확인하여 다음 CR ID를 자동 생성합니다:

• sdd-config.yaml의 change_cycles 배열에서 마지막 CR 번호를 확인
• 없으면 CR-001부터 시작

출력

docs/specs/09-change-request.md를 templates/specs/change-request.md.tmpl 기반으로 생성합니다.

Phase 1 완료: 변경 요청 수집

CR ID: CR-002
제목: 사용자 프로필 API에 프로필 이미지 필드 추가
우선순위: 보통
상태: 신규

생성된 파일: docs/specs/09-change-request.md

Phase 2로 진행합니다 — 영향 분석...

---

Phase 2: 영향 분석

sdd-change-analyst 에이전트의 규칙을 사용하여 변경 요청의 영향을 분석합니다.

에이전트 실행

팀 모드 (Agent Teams 활성화):

1. sdd-change-analyst 에이전트로 팀 멤버 생성:
   • 에이전트: sdd-change-analyst
   • 컨텍스트: 09-change-request.md, 기존 스펙 문서 전체 (02~05, 06-checklist)
   • 지시: "변경 요청을 분석하고 영향 범위를 식별하세요."

솔로 모드 (Agent Teams 비활성화):

1. agents/sdd-change-analyst.md를 Read 도구로 읽고 해당 규칙을 따라 직접 분석합니다.

   • 09-change-request.md와 기존 스펙 문서 전체 (02~05, 06-checklist)를 참조
   • LSP 도구(findReferences, incomingCalls)를 활용하여 영향 범위를 식별

2. 분석 결과 수집:

   • 직접 영향 / 간접 영향 / 회귀 위험 항목
   • 체크리스트 재설정 대상 및 신규 CHG- 항목

프로젝트 규칙 영향 분석 (규칙 활성화 시)

rules.enabled가 true이면 변경이 프로젝트 규칙에 미치는 영향도 분석합니다:

1. 규칙 충돌 확인: 변경 요청이 기존 프로젝트 규칙과 충돌하는지 확인합니다.
   • 충돌 시 사용자에게 알리고 규칙 수정 여부를 질문합니다.
2. 규칙 영향 체크리스트: 체크리스트에 CHG-RULE-NNN 항목을 추가합니다:

   ### 규칙 준수 검증
   - [ ] CHG-RULE-001: 변경된 코드가 RULE-ARCH-001 (계층 의존성) 준수
   - [ ] CHG-RULE-002: 변경된 API가 RULE-API-010 (응답 형식) 준수
   

기존 스펙 문서 업데이트

영향 분석 결과에 따라 기존 스펙 문서 끝에 ## 변경 사이클 CR-NNN 섹션을 추가합니다. 새 문서를 생성하지 않고 기존 문서를 업데이트합니다:

영향 대상	업데이트 문서	추가 섹션 템플릿
아키텍처 변경	02-architecture.md	templates/specs/change-cycle-section.md.tmpl
API 변경	03-api-spec.md	templates/specs/change-cycle-section.md.tmpl
데이터 모델 변경	04-data-model.md	templates/specs/change-cycle-section.md.tmpl
컴포넌트 변경	05-component-breakdown.md	templates/specs/change-cycle-section.md.tmpl

업데이트 전 각 문서를 .pre-CR-NNN.bak 파일로 백업합니다.

09-change-request.md 업데이트

영향 분석 결과를 09-change-request.md의 "영향 분석 요약" 섹션에 반영합니다.

Phase 2 완료: 영향 분석

직접 영향: 3개 항목 (API 2개, DM 1개)
간접 영향: 2개 항목
회귀 위험: 1개 항목

업데이트된 스펙 문서:
  - docs/specs/03-api-spec.md (변경 사이클 CR-002 섹션 추가, 2개 엔드포인트)
  - docs/specs/04-data-model.md (변경 사이클 CR-002 섹션 추가, 1개 엔티티)

Phase 3으로 진행합니다 — 체크리스트 부분 갱신...

---

Phase 3: 체크리스트 부분 갱신

영향 분석 결과에 따라 06-spec-checklist.md를 부분적으로 갱신합니다.

갱신 전략

핵심 원칙: 영향받지 않는 항목은 절대 변경하지 않습니다.

1. 영향받는 [x] 항목 → [ ]로 재설정:

   • 재설정 사유를 코멘트로 추가: (CR-NNN 재작업 필요)

   - [ ] API-001: GET /users 페이지네이션 (CR-002 재작업 필요)
   

2. 영향받지 않는 [x] 항목 → 절대 변경 안함:

   - [x] API-002: POST /users 필드 유효성 검사  ← 그대로 유지
   

3. 신규 CHG- 항목 추가:

   • ## 변경 사이클 CR-NNN 섹션을 체크리스트 끝에 추가

   ## 변경 사이클 CR-002
   
   ### 변경 항목
   - [ ] CHG-001: GET /users 응답에 profileImage 필드 추가
   - [ ] CHG-002: User 엔티티에 profileImage 컬럼 추가
   - [ ] CHG-003: 프로필 이미지 업로드 API 추가
   
   ### 회귀 테스트
   - [ ] CHG-REG-001: 기존 GET /users 응답 형식 보존
   - [ ] CHG-REG-002: 기존 User 엔티티 CRUD 동작 보존
   

갱신 전 백업

체크리스트 갱신 전에 원본을 보존합니다:

• 06-spec-checklist.md → 06-spec-checklist.md.pre-CR-NNN.bak

갱신 확인

Phase 3 완료: 체크리스트 부분 갱신

재설정: 2개 항목 ([x] → [ ])
  - API-001: GET /users 페이지네이션
  - DM-003: User 엔티티 필드 정의

보존: 10개 항목 (변경 없음)

추가: 5개 항목
  - CHG-001 ~ CHG-003: 변경 항목 3개
  - CHG-REG-001 ~ CHG-REG-002: 회귀 테스트 2개

체크리스트: 10/17 완료 (59%) — 재설정 2개 + 신규 5개

Phase 4로 진행합니다 — 델타 태스크 계획...

---

Phase 4: 델타 태스크 계획

변경 항목(CHG-) 및 재설정 항목을 워크 패키지로 분해합니다.

변경 워크 패키지 (CWP)

기존 태스크 계획(07-task-plan.md)에 변경 워크 패키지를 추가합니다:

## 변경 사이클 CR-002 — 워크 패키지

### CWP-1: API 변경 구현
- CHG-001: GET /users 응답에 profileImage 필드 추가
- API-001: GET /users 페이지네이션 재검증 (재설정)
- CHG-REG-001: 기존 GET /users 응답 형식 보존

### CWP-2: 데이터 모델 변경 구현
- CHG-002: User 엔티티에 profileImage 컬럼 추가
- DM-003: User 엔티티 필드 정의 재검증 (재설정)
- CHG-REG-002: 기존 User 엔티티 CRUD 동작 보존

### CWP-3: 프로필 이미지 API 구현
- CHG-003: 프로필 이미지 업로드 API 추가

Phase 4 완료: 델타 태스크 계획

변경 워크 패키지: 3개
  CWP-1: API 변경 구현 (3개 항목)
  CWP-2: 데이터 모델 변경 구현 (3개 항목)
  CWP-3: 프로필 이미지 API 구현 (1개 항목)

Phase 5로 진행합니다 — TDD 델타 빌드...

---

Phase 5: TDD 델타 빌드

변경 워크 패키지를 TDD 모드로 빌드합니다. 이 단계는 /claude-sdd:sdd-build --tdd의 Phase A/B/C 루프를 사용합니다.

실행 모드에 따른 분기:

• 팀 모드: 각 CWP에 대해 sdd-test-writer, sdd-implementer 팀 멤버를 생성하여 병렬 빌드
• 솔로 모드: 각 CWP에 대해 순차적으로 Phase A→B→C를 실행. agents/sdd-test-writer.md와 agents/sdd-implementer.md를 읽고 해당 규칙을 따라 직접 테스트 작성 및 구현

에이전트 모달 선별 주입: sdd-build와 동일하게 agents/sdd-implementer.md의 모드별 필요 섹션만 프롬프트에 포함합니다. 변경 빌드에서는 TDD + 레거시 갭 해소(해당 시) 섹션을 포함합니다.

체크리스트 선별 로딩: CWP에 배정된 체크리스트 항목만 추출하여 프롬프트에 인라인 포함합니다. 전체 체크리스트 파일 경로는 참조로만 제공합니다.

레거시 갭 해소 빌드 규칙

레거시 프로젝트의 갭 해소 CR인 경우 (gap_source: 10-analysis-report.md), Phase 5에서 다음 추가 규칙을 적용합니다:

1. sdd-implementer에게 갭 해소 모드를 지시: agents/sdd-implementer.md의 "레거시 갭 해소 모드" 섹션(줄 119~167)만 포함합니다.
2. 기존 코드 구조 보존: 기존 코드 스타일, 네이밍, 디렉토리 구조를 따릅니다.
3. 기존 테스트 무결성: Phase 5C 검증 시 기존 테스트(분석 보고서의 테스트 베이스라인)가 모두 통과해야 합니다.
4. 하위 호환성: 기존 공개 API를 변경/삭제하지 않습니다.

빌드 흐름

각 CWP에 대해:

1. Phase A (Red): sdd-test-writer가 변경 스펙 기반으로 테스트를 작성합니다.

   • CHG- 항목: 변경된 동작을 검증하는 테스트
   • CHG-REG- 항목: 기존 기능 보존을 검증하는 회귀 테스트
   • 참조 스펙: 03-api-spec.md (변경 사이클 CR-NNN), 04-data-model.md (변경 사이클 CR-NNN), 05-component-breakdown.md (변경 사이클 CR-NNN)

2. Phase B (Green): sdd-implementer가 모든 테스트(신규 + 회귀) 통과 코드를 작성합니다.

   • 기존 테스트도 모두 통과해야 합니다.
   • 테스트 파일 수정 금지 규칙 적용.

3. Phase C (Verify): 전체 테스트 스위트를 실행합니다.

   • 변경 테스트 + 기존 테스트 모두 통과해야 합니다.
   • 기존 테스트 실패 = 회귀 발생, 재작업 필요.

Phase 5 — TDD 델타 빌드

CWP-1: API 변경 구현
  Phase A: 3개 테스트 작성 (CHG-001: 1, CHG-REG-001: 1, API-001: 1)
  Phase B: sdd-implementer 실행 중...
  Phase C: 전체 테스트 실행
    변경 테스트: 3/3 통과 ✓
    기존 테스트: 24/24 통과 ✓ (회귀 없음)
  CWP-1 완료 ✓

CWP-2: 데이터 모델 변경 구현
  Phase A: 3개 테스트 작성
  Phase B: sdd-implementer 실행 중...
  Phase C: 전체 테스트 실행
    변경 테스트: 3/3 통과 ✓
    기존 테스트: 27/27 통과 ✓ (회귀 없음)
  CWP-2 완료 ✓

CWP-3: 프로필 이미지 API 구현
  Phase A: 2개 테스트 작성
  Phase B: sdd-implementer 실행 중...
  Phase C: 전체 테스트 실행
    변경 테스트: 2/2 통과 ✓
    기존 테스트: 30/30 통과 ✓ (회귀 없음)
  CWP-3 완료 ✓

Phase 5 완료: 3/3 CWP 완료

Phase 6으로 진행합니다 — 리뷰 + 회귀 검증...

---

Phase 6: 리뷰 + 회귀 검증

변경 항목과 회귀 방지를 검증합니다.

• 팀 모드: sdd-reviewer 에이전트로 팀 멤버를 생성하여 검증
• 솔로 모드: agents/sdd-reviewer.md를 Read 도구로 읽고 해당 규칙을 따라 직접 리뷰

검증 범위

1. CHG- 항목 검증: 변경된 기능이 스펙과 일치하는지 확인
2. CHG-REG- 항목 검증: 기존 기능이 보존되는지 확인
3. 재설정 항목 재검증: [ ]로 재설정된 항목이 다시 [x]로 완료되었는지 확인
4. 전체 테스트 최종 실행: 전체 테스트 스위트 실행

리뷰 리포트 업데이트

08-review-report.md에 변경 사이클 리뷰 섹션을 추가합니다:

## 변경 사이클 CR-002 리뷰

### 요약
- 변경 항목: 3/3 PASS
- 회귀 테스트: 2/2 PASS
- 재설정 항목: 2/2 PASS
- 전체 테스트: 32/32 PASS

### 변경 항목 상세
- [x] CHG-001: GET /users 응답에 profileImage 필드 추가 — PASS
- [x] CHG-002: User 엔티티에 profileImage 컬럼 추가 — PASS
- [x] CHG-003: 프로필 이미지 업로드 API 추가 — PASS

### 회귀 테스트 상세
- [x] CHG-REG-001: 기존 GET /users 응답 형식 보존 — PASS
- [x] CHG-REG-002: 기존 User 엔티티 CRUD 동작 보존 — PASS

Phase 6 완료: 리뷰 + 회귀 검증

변경 항목: 3/3 PASS ✓
회귀 테스트: 2/2 PASS ✓
재설정 항목: 2/2 PASS ✓
전체 테스트: 32/32 PASS ✓

Phase 7로 진행합니다 — PR 생성...

---

Phase 7: PR 생성

변경 내용을 포함한 PR을 생성합니다.

PR 제목 형식

[CR-NNN] 변경 제목

PR 본문

## 변경 요청

- **CR ID**: CR-002
- **제목**: 사용자 프로필 API에 프로필 이미지 필드 추가
- **영향 범위**: API 2개, 데이터 모델 1개

## 변경 내역

### API 변경
- GET /users: 응답에 `profileImage` 필드 추가
- POST /users/profile-image: 신규 프로필 이미지 업로드 API

### 데이터 모델 변경
- User 엔티티: `profileImage` 컬럼 추가 (VARCHAR, nullable)

## 체크리스트
- [x] 영향 분석 완료
- [x] 기존 스펙 문서 업데이트
- [x] 체크리스트 부분 갱신
- [x] TDD 델타 빌드 완료
- [x] 리뷰 + 회귀 검증 통과
- [x] 전체 테스트 통과 (회귀 없음)

## 추적성

| 변경 항목 | 원본 요구사항 | 스펙 참조 |
|-----------|-------------|-----------|
| CHG-001 | CR-002-FC-001 | 03-api-spec.md (변경 사이클 CR-002) |
| CHG-002 | CR-002-FC-001 | 04-data-model.md (변경 사이클 CR-002) |
| CHG-003 | CR-002-FC-002 | 03-api-spec.md (변경 사이클 CR-002) |

sdd-config.yaml 업데이트

변경 사이클 이력을 sdd-config.yaml의 change_cycles에 추가합니다:

change_cycles:
  - id: "CR-002"
    title: "사용자 프로필 API에 프로필 이미지 필드 추가"
    status: "completed"
    date: "2025-03-15"
    affected_items: 2
    new_items: 5

Phase 7 완료: PR 생성

PR: [CR-002] 사용자 프로필 API에 프로필 이미지 필드 추가
브랜치: sdd/change-CR-002
상태: 생성 완료

변경 사이클 CR-002 완료!

체크리스트: 17/17 완료 (100%)
  기존 항목: 12/12 완료
  변경 항목: 3/3 완료
  회귀 테스트: 2/2 완료

---

서브커맨드

status — 변경 사이클 상태

현재 진행 중인 변경 사이클의 상태를 표시합니다.

변경 사이클 상태 — CR-002

제목: 사용자 프로필 API에 프로필 이미지 필드 추가
상태: Phase 5 (TDD 델타 빌드)

Phase별 진행:
  [x] Phase 1: 변경 요청 수집
  [x] Phase 2: 영향 분석
  [x] Phase 3: 체크리스트 부분 갱신
  [x] Phase 4: 델타 태스크 계획
  [ ] Phase 5: TDD 델타 빌드 (CWP-2/3 진행 중)
  [ ] Phase 6: 리뷰 + 회귀 검증
  [ ] Phase 7: PR 생성

체크리스트: 13/17 완료 (76%)
  기존 항목: 12/12
  변경 항목: 1/3
  회귀 테스트: 0/2

resume — 변경 사이클 재개

중단된 변경 사이클을 현재 Phase부터 재개합니다.

1. 09-change-request.md의 상태를 확인합니다.
2. sdd-config.yaml의 change_cycles에서 진행 중인 CR을 찾습니다.
3. 마지막으로 완료된 Phase 다음부터 실행합니다.

---

동작 (멀티 도메인 모드)

--domain= (특정 도메인 변경 관리)

1. 도메인 스코프에서 변경 요청을 수집합니다.
2. 도메인별 스펙(docs/specs/domains/<id>/)을 기준으로 영향 분석합니다.
3. 도메인별 체크리스트를 부분 갱신합니다.
4. 도메인별 CWP를 생성하고 TDD 빌드합니다.
5. 프로젝트 통합 체크리스트도 자동 갱신합니다.

크로스 도메인 변경

변경이 여러 도메인에 영향을 미치는 경우:

1. Phase 2에서 영향받는 모든 도메인을 식별합니다.
2. 각 도메인별로 개별 델타 스펙과 체크리스트를 갱신합니다.
3. 크로스 도메인 통합 체크리스트도 갱신합니다.
4. Phase 5에서 도메인별로 순차 빌드합니다 (의존성 순서).

---

출력

Phase	생성/수정 파일
Phase 1	09-change-request.md (신규)
Phase 2	02~05 기존 스펙 업데이트 (변경 사이클 섹션 추가, 해당 문서만), 09-change-request.md (업데이트)
Phase 3	06-spec-checklist.md (부분 갱신), 06-spec-checklist.md.pre-CR-NNN.bak (백업)
Phase 4	07-task-plan.md (CWP 추가)
Phase 5	소스 코드 + 테스트 코드, 06-spec-checklist.md (업데이트)
Phase 6	08-review-report.md (업데이트)
Phase 7	PR 생성, sdd-config.yaml (change_cycles 업데이트)

의존성

• docs/specs/sdd-config.yaml (/claude-sdd:sdd-init에서 생성)
• 기존 스펙 문서 (02~05, 06-checklist, 07-task-plan, 08-review-report)
• Agent Teams 활성화 시 병렬 빌드(팀 모드), 비활성화 시 순차 빌드(솔로 모드)
• sdd-change-analyst 에이전트 (Phase 2)
• sdd-test-writer 에이전트 (Phase 5)
• sdd-implementer 에이전트 (Phase 5)
• sdd-reviewer 에이전트 (Phase 6)