구현 계획 수립

확정된 스펙을 구체적인 파일 수정 계획으로 변환한다. 사용자 승인 후 코딩 단계로 진행한다.

실행 워크플로우

Step 1: 관련 코드 탐색

스펙에서 식별된 레이어의 기존 파일을 탐색하여 현재 구현 상태를 파악한다.

레이어별 탐색 경로: 01-architecture-check의 디렉터리 구조와 레이어 표를 기준으로 삼는다. 그 문서가 낡았다고 판단되면 코드를 우선하고, 어긋난 지점은 harness-evolve로 갱신한다.

탐색 전략:

1. 변경 대상 파일을 직접 읽어서 현재 구조 파악
2. 같은 레이어에서 유사한 기능의 파일을 찾아 참조 패턴으로 활용
3. Grep으로 관련 함수명, require 경로를 검색하여 의존 관계 파악

Step 2: 변경 파일 목록 작성

수정/생성/삭제할 파일을 레이어별로 분류한다.

Step 3: 구현 순서 결정

의존성 기반으로 구현 순서를 결정한다. 일반적인 순서:

1. 저장소(Model/Repository) - 쿼리·영속화 함수 추가/수정
2. 도메인 로직(Lib/Domain) - 비즈니스 규칙 구현
3. 변환(Entity/DTO) - 외부 포맷 ↔ 내부 포맷 (필요 시)
4. 서비스(Service) - 오케스트레이션, 분기 처리
5. 진입점(Controller/Handler) - 라우트 등록, 요청/응답 처리
6. 테스트 - 테스트 코드 작성

레이어 이름은 01-architecture-check의 표를 따른다.

Step 4: 리스크 식별

• 사이드이펙트: 변경된 함수를 호출하는 다른 파일에 미치는 영향
• 캐시 무효화: 데이터 변경 시 관련 캐시 삭제 필요 여부 (TTL 없는 캐시를 특히 확인)
• DB 마이그레이션: 스키마 변경 필요 여부
• API 호환성: 기존 클라이언트에 미치는 영향
• 분기 누락: 프로젝트에 분기 축(테넌트·프로바이더·타입)이 있다면 전 분기를 처리했는지

Step 5: 계획 출력

## 구현 계획

### 변경 파일 목록

| # | 파일 | 레이어 | 작업 | 설명 |
|---|------|--------|------|------|
| 1 | (경로) | (레이어) | 수정 | (변경 내용) |
| 2 | (경로) | (레이어) | 생성 | (변경 내용) |
| ... | | | | |

### 구현 순서
1. (의존성 순서 기반 작업 목록)
2. ...

### 리스크 및 주의사항
- (사이드이펙트, 캐시, DB, API 호환성)

### 테스트 계획
- 테스트 파일: (test-writer 스킬의 디렉터리·네이밍 규칙에 따라)
- 테스트 시나리오: (주요 케이스)

주의사항

• 계획은 코드 작성 전 반드시 사용자 확인을 받을 것
• 단순 수정(한두 파일)이라도 변경 파일 목록과 영향 범위를 명시
• 기존 패턴과 다른 접근이 필요할 경우 그 이유를 명시
• 계획 확정 후 5단계(플랜 검토)로 진행