1. 요청 분석: 사용자의 아키텍처 계획 의도를 파악합니다.
2. 컨텍스트 읽기: 프로젝트 루트에서 다음 2개 파일을 읽습니다:
   • SPEC.md — 요구사항 (기능/비기능 요구사항, 제약조건, 사용자 시나리오)
   • survey.md — 아키텍처 결정 사항
   • SPEC.md가 없으면 /spec을 먼저 실행하도록 안내합니다.
   • survey.md가 없으면 /survey를 먼저 실행하도록 안내합니다.
3. 계획 생성: SPEC.md와 survey.md를 기반으로 포괄적인 구현 계획(plan.md)을 한국어로 작성합니다.
   • 컨텍스트: SPEC.md와 survey.md의 정보를 기반으로 합니다.
   • 요구사항 매핑: SPEC.md의 기능 요구사항(F1, F2…)을 plan.md 구현 항목에 매핑합니다.
   • 아키텍처: Feature-Sliced Design (FSD) 원칙을 반드시 준수합니다.
   • 품질: “높은 응집도”, “낮은 결합도”, “추상화”, “SOLID” 원칙을 우선시합니다.
   • 형식: 세부 코드 스니펫이 아닌 고수준 설계 문서(아키텍처)로 작성합니다. 거시적 구조와 향후 확장성에 집중합니다.
   • 필수: 생성되는 내용은 반드시 한국어여야 합니다.
4. 파일 작성: 생성된 내용을 프로젝트 루트의 plan.md에 저장합니다.
   • plan.md 상단에 참조 문서로 SPEC.md, survey.md를 명시합니다.

참고 자료: plan.md 작성을 위한 아키텍처 원칙

1. FSD (Feature-Sliced Design) 적용

• 레이어: app -> pages -> widgets -> features -> entities -> shared
• 슬라이스: 비즈니스 도메인별 코드 그룹화 (예: user, cart, product)
• 세그먼트: ui, model (store/types), lib (utils), api
• 규칙: 상위 레이어가 하위 레이어를 import할 수 있음. 하위 레이어는 상위를 import할 수 없음. 같은 레이어의 슬라이스끼리는 서로 import 불가 (Widget/Page에서 합성으로 해결).

2. 설계 원칙

• SOLID:
  • SRP: 각 컴포넌트/훅은 변경 이유가 하나여야 합니다.
  • OCP: 확장에는 열려 있고, 수정에는 닫혀 있어야 합니다 (props/전략 패턴 활용).
  • LSP: 하위 타입은 상위 타입을 대체할 수 있어야 합니다.
  • ISP: 작고 구체적인 인터페이스를 사용합니다.
  • DIP: 구체 구현이 아닌 추상(인터페이스)에 의존합니다.
• 응집도 & 결합도:
  • 관련된 것들을 함께 배치합니다 (코로케이션).
  • 서로 다른 기능 간 의존성을 최소화합니다.

3. plan.md 구조

• 참조 문서: SPEC.md, survey.md
• 목적: 구축 대상에 대한 명확한 서술
• 아키텍처 개요: 관련 레이어 및 슬라이스의 다이어그램 또는 텍스트 설명
• 디렉토리 구조: FSD를 따르는 폴더 구조 제안
• 핵심 컴포넌트/모듈: 주요 단위 및 역할 설명
• 데이터 흐름: 상태 이동 방식 (서버 -> 클라이언트 -> UI)
• 확장 전략: 기존 코드 수정 없이 새 기능을 추가하는 방법