**사용자 요청**: "사용자가 시간대를 선택할 수 있어야 한다"

**해석 후보**:
- 해석 A: 단순 체크박스 목록
- 해석 B: 드래그 기반 시간 범위 선택
- 해석 C: 캘린더 뷰 시각적 블록 선택
- 해석 D: 시작/종료 시간 입력 필드

**해석 A 평가**:
- 구현 복잡도: 28/30 (매우 간단)
- 요구사항 충족도: 20/30 (기본 기능만)
- UX 품질: 12/20 (직관적이지만 제한적)
- 유지보수성: 9/10 (단순 구조)
- 팀 역량: 10/10 (표준 HTML)
- **총점: 79/100 (가능함)**

**해석 B 평가**:
- 구현 복잡도: 20/30 (중간 복잡도)
- 요구사항 충족도: 28/30 (우수한 UX)
- UX 품질: 18/20 (직관적이고 효율적)
- 유지보수성: 7/10 (상태 관리 복잡)
- 팀 역량: 9/10 (React DnD 경험 있음)
- **총점: 82/100 (확실함)** ✅

decision:
  selected_interpretation:
    id: "B"
    description: "드래그 기반 시간 범위 선택"
    score: 82
    rationale: "UX와 요구사항 충족도가 가장 높으며, 팀이 React DnD 경험 보유"

  alternatives:
    - id: "A"
      description: "단순 체크박스"
      score: 79
      fallback_condition: "드래그 구현 중 막힐 경우 전환"

    - id: "C"
      description: "캘린더 뷰"
      score: 68
      rejected_reason: "복잡도 대비 효과 낮음, 팀 경험 없음"

  lookahead:
    next_decision: "드래그 라이브러리 선택 (react-dnd vs react-beautiful-dnd)"
    expected_complexity: "중간"
    risks:
      - "모바일 터치 지원 이슈 가능성"
      - "성능 문제 (대량 시간대 렌더링)"

  backtrack_plan:
    trigger: "구현 중 2일 이상 진행 없음 또는 성능 목표 미달"
    action: "해석 A로 전환 (체크박스 방식)"
    estimated_recovery_time: "1일"

입력: "사용자가 프로필 사진을 업로드할 수 있어야 한다"

ToT 프로세스:
1. 후보 생성: 파일 input, 드래그앤드롭, 카메라 촬영, URL 입력 (4개)
2. 평가: 각각 점수화
3. 선택: 드래그앤드롭 + 파일 input 조합 (85점)
4. Lookahead: 이미지 크기 제한, 포맷 검증

입력: "사용자가 데이터를 내보낼 수 있어야 한다"

ToT 프로세스:
1. 후보 생성: CSV 다운로드, JSON API, PDF 보고서, Excel, 프린트 (5개)
2. 평가: 사용 사례별 점수화
3. 선택: CSV + JSON 조합 (78점)
4. Lookahead: 대용량 데이터 처리 전략

입력: "전역 상태 관리 라이브러리 선택"

ToT 프로세스:
1. 후보 생성: Redux Toolkit, Zustand, Jotai, Recoil, MobX (5개)
2. 평가: 프로젝트 규모, 팀 경험, 학습 곡선 고려
3. 선택: Jotai (85점) for 중소 규모 프로젝트
4. Lookahead: 향후 Redux로 마이그레이션 비용 예측

## ToT 요구사항 해석 분석

### 원본 요청
"{사용자 요청 내용}"

### 해석 후보 생성
[해석 A, B, C, D 설명]

### 평가 결과
[평가 표]

### 최종 선택
**선택**: 해석 B (드래그 기반 시간 범위 선택)
**점수**: 82/100 (확실함)
**근거**: [선택 이유 3-5줄]

### Lookahead
- 다음 결정: [예측]
- 리스크: [예상 문제]

### Backtrack Plan
- 대안: 해석 A (79점)
- 전환 조건: [트리거]

error_handling:
  severity_high:
    conditions:
      - 사용자 요청이 너무 모호함 (해석 불가)
      - 프로젝트 컨텍스트 없음 (.project-structure.yaml 누락)
      - 평가 기준 충돌 (모든 후보 60점 미만)
      - 해석 후보 생성 실패 (0-2개만 생성)
      - YAML 출력 파싱 실패
    action: |
      ❌ 치명적 오류 - 요구사항 해석 중단
      → 사용자 요청 명확화: 구체적인 요구사항 재작성 요청
      → 프로젝트 컨텍스트 확인: .project-structure.yaml 존재 확인
      → 평가 기준 재검토: 가중치 조정 또는 후보 재생성
      → 재실행: 명확화 및 컨텍스트 확보 후 재시도
    examples:
      - condition: "요청 너무 모호"
        message: "❌ 오류: 사용자 요청이 너무 모호하여 해석 불가"
        recovery: "구체적인 요구사항 재작성 요청 (예: 'UI 개선' → '시간대 선택 UI 드래그 기능 추가')"
      - condition: "모든 후보 낮은 점수"
        message: "❌ 오류: 모든 해석 후보가 60점 미만 (최고 58점)"
        recovery: "새로운 해석 후보 생성 또는 평가 기준 재검토"

  severity_medium:
    conditions:
      - 일부 평가 기준 계산 실패
      - Lookahead 예측 불확실
      - Backtrack Plan 생성 실패
      - 동점 해석 후보 (2개 이상)
      - 팀 역량 정보 없음
    action: |
      ⚠️  경고 - 부분 평가로 진행
      1. 실패한 평가 기준을 기본값(50점)으로 설정
      2. Lookahead를 "불확실"로 표시
      3. Backtrack Plan을 "미정의"로 표시
      4. 동점 시 재사용성 > SRP > 효율성 순으로 선택
      5. 팀 역량을 "보통(50점)"으로 가정
      6. 평가 결과에 경고 추가:
         > ⚠️  WARNING: 일부 평가 불완전
         > → {missing_criteria}
    fallback_values:
      evaluation_score: 50
      lookahead: "불확실"
      backtrack_plan: "미정의"
      team_capability: 50
    examples:
      - condition: "평가 기준 계산 실패"
        message: "⚠️  경고: '유지보수성' 평가 실패 (정보 부족)"
        fallback: "기본 50점으로 설정 → 수동 재평가 권장"
      - condition: "동점 해석"
        message: "⚠️  경고: 해석 A, B 모두 82점 (동점)"
        fallback: "재사용성 기준으로 선택 → 해석 A 선택"

  severity_low:
    conditions:
      - 선택적 메타데이터 누락
      - YAML 출력 포맷팅 경고
      - Lookahead 세부 정보 부족
      - 해석 설명 간략함
    action: |
      ℹ️  정보: 선택적 항목 생략 - 핵심 평가 진행
      → 메타데이터: 누락 시 생략
      → 포맷팅: 자동 보정
      → Lookahead: 간략 버전 제공
      → 설명: 최소 정보로 진행
    examples:
      - condition: "메타데이터 누락"
        auto_handling: "선택적 메타데이터 생략 → 핵심 평가 정보만 제공"
      - condition: "Lookahead 간략"
        auto_handling: "세부 정보 부족 → 주요 다음 결정만 예측"