feat: #57 계획 가능성 판정 및 초기 계획 생성 View 연결

[wngjs8114]

관련 이슈

Closes #57

작업 내용

planner 서비스 로직(scheduler, feasibility_checker, schedule_generator)은 이미 구현·머지돼 있었지만 이를 호출하는 View/URL이 전혀 없었음. 확정된 View 연결 우선순위의 첫 단계로 계획 가능성 판정 및 초기 계획 생성 흐름을 연결한다.

• planner:feasibility (GET): 시험기간 전체 가용시간·확정 작업 기준 가능성 판정 표시
• planner:plan_generate (POST): 가능성 재검증 후 generate_schedule() 호출, 실패 시 사유별 안내
• planner:plan_complete (GET): 생성된 DailyPlan 요약 표시

검증 로직

• 화면 버튼(RISKY/IMPOSSIBLE 비활성화)만 믿지 않고 서버에서 POSSIBLE 여부 재검증
• 계획 배치용 가용시간은 항상 오늘 이후만 사용 (과거 날짜 배치 방지)
• _validate_task_readiness(): 과목이 여러 개인데 일부만 확정된 상태로 조용히 계획이 생성되는 것 방지
  • 등록된 과목 없음 / 학습 작업 없음 / 미확정 작업 존재 / 작업 없는 과목 존재 / 예상시간 0인 작업 존재 → 전부 차단
• generate_schedule()의 예외를 사유별로 안내
  • ScheduleAlreadyExistsError → 기존 계획으로 이동
  • UnallocatedTasksError → "날짜별 가능시간 제약으로 일부 작업을 배치하지 못했습니다"
  • MismatchedExamPeriodError/DuplicateTaskAllocationError → 일반 오류 안내

정책 확정 사항 (리뷰 과정에서 정리)

• ExamPeriodStatus.ACTIVE 전환 로직은 제거함 — period_create()가 이미 생성 시점에 ACTIVE로 저장하므로 plan_generate에서 다시 설정하는 건 의미 없는 코드였음
• ScheduleHasProgressError는 이 View에서 처리하지 않음 — replace_existing=False로만 호출하므로 이 경로에서는 발생하지 않음 (전체 재생성 정책이 아직 없음)
• 과목별 세부 가능성 판정은 이번 범위 밖 — AvailableTime이 exam_period 단위라 과목별 배분 정책 없이는 계산 불가 (style: #49 대시보드 화면 구현 #51 리뷰에서 확정된 동일 제약)

템플릿

feasibility.html, plan_complete.html은 최소 뼈대만 구현 (base.html의 {% block content %} 활용). FE1이 Figma 기준 실제 디자인으로 교체 예정.

테스트

• python manage.py test planner → 112개 통과 (기존 102 + 신규 10)
• 신규 테스트: 다른 사용자 접근 차단, 확정 작업 없음/미확정 작업 존재/작업 없는 과목 존재/예상시간 0인 작업 존재 시 생성 차단, 과거 가용시간 미사용, RISKY 판정 시 생성 거부, 정상 생성 시 전체 작업 배치, 중복 제출 시 기존 계획으로 이동, 계획 없을 때 plan_complete 접근 시 가능성 화면으로 리다이렉트

이번 PR 범위 밖

• 과목별 세부 가능성 판정
• RISKY 판정 시 계획 생성 (후속 이슈)
• 최종 템플릿/CSS

[6ye0m]

확인한 것들

1. 함수 시그니처 다 정확히 맞물려요

calculate_feasibility(required_min_minutes, required_max_minutes, available_minutes) 호출부와 반환 딕셔너리 키(status, required_min_minutes, required_recommended_minutes, available_minutes) 다 일치
generate_schedule(exam_period=, study_tasks=, available_times=, replace_existing=) 키워드 인자도 정확히 매칭

2. ScheduleHasProgressError를 안 잡는 이유가 실제로 맞아요
   직접 schedule_generator.py 코드 봤는데, 이 예외는 replace_existing=True일 때만 도달 가능한 코드 경로예요. 이 View는 항상 기본값(False)으로만 호출하니까, 그 경로 자체가 실행이 안 돼요. "안 잡아도 된다"는 판단이 정확해요.

3. 과거 날짜 가용시간 제외 로직 검증됨

python
planning_start = max(exam_period.start_date, timezone.localdate())

테스트(test_plan_generate_ignores_past_available_time)로 실제 확인했고, DailyPlan 개수가 0인 것까지 검증해서 신뢰도 높아요.

4. 테스트 실행 결과

python manage.py test planner → Ran 112 tests ... OK (말씀하신 숫자와 정확히 일치)
python manage.py test → Ran 161 tests ... OK
python manage.py check → 이상 없음

5. 크로스앱 연동도 확인됨
   study_task_confirm()(exams 앱)이 예전부터 redirect('planner:feasibility', period_id=...)를 부르고 있었는데, 그동안 planner:feasibility URL 자체가 없어서 실제로 터지면 NoReverseMatch였을 거예요. 이 PR로 그 URL이 드디어 실제로 생겨서, 두 앱이 처음으로 제대로 연결됐어요.

사소한 것 하나 (블로킹 아님)

_validate_task_readiness()에서 "과목에 확정 안 된 작업이 있음"과 "그 과목에 작업 자체가 하나도 없음"이 같은 메시지("학습 작업이 확정되지 않은 과목이 있습니다")로 나와요. 기능상 둘 다 막는 건 맞는데, 사용자 입장에서 "작업을 안 만든 건지 확정을 안 한 건지" 구분이 안 될 수 있어요. 급한 건 아니에요.

결론: 승인하셔도 될 것 같아요.