Feature/#54 fe1 templates

[daynight0219-ux]

작업 내용

• 회원가입/로그인 화면
• 시험기간 등록/수정/삭제, 시험기간 목록/상세
• 과목 등록/수정/삭제
• 가용시간 입력 (캘린더 + 사이드패널)
• 시험범위 등록 (PDF/텍스트, 추출·분석 자동 진행)
• 학습 작업 확인/추가 (formset 일괄 저장 방식)
• 공통 컴포넌트 CSS (tokens.css 변수만 사용)

확인이 필요한 부분

1. exams/templatetags/exam_extras.py를 새로 추가했습니다. subject_create/material_create/task_review 뷰가 같은 시험기간의 다른 과목 리스트를 context로 안 내려줘서, 프론트 표시용 읽기 전용 조회 함수를 템플릿 태그로 분리했습니다. views.py는 건드리지 않았습니다. (@장희원 확인 부탁드려요)
2. URL/View 계약서상 /exams/tasks/review/인데 실제로는 /exams/subjects/<exam_id>/tasks/review/로 구현되어 있어서, 과목 탭이 실제 페이지 이동 방식입니다.
3. study_task_confirm이 planner:feasibility로 리다이렉트하는데 아직 해당 URL이 없어서, 학습 작업 확정 이후 흐름은 테스트 못 했습니다.
4. task_review 뷰의 action=save|confirm 분기 처리가 아직 반영 안 된 상태라, 화면은 미리 만들어뒀지만 "저장하고 다음으로" 버튼 동작은 BE 반영 후 확인 필요합니다.

Closes #54

[h2ew0n]

확인해 주셔서 감사합니다! 공유해 주신 내용 검토 및 로컬 확인 완료했습니다.

1. templatetags/exam_extras.py 추가 관련

   • 뷰 수정 없이 템플릿 태그로 타 과목 목록을 분리 처리해 주신 덕분에 백엔드 데이터 조회 구조에 영향 없이 화면 렌더링이 깔끔하게 잘 동작합니다! 👍

2. URL 경로 (/exams/subjects/<exam_id>/tasks/review/) 관련

   • 특정 과목의 작업들을 조회하기 위해 <exam_id> 파라미터 전달이 필수적이어서 해당 경로로 구성해 두었는데, 프론트에서 탭 클릭 시 실제 페이지 이동 방식으로 깔끔하게 잘 맞춰주셨네요. 감사합니다.

3. task_review 뷰 분기 로직 (action=save|confirm)

   • 말씀해 주신 action 분기 로직 관련해서는 **BE 작업(PR test: task_review 폼 제출 및 material_analysis_status API 테스트 보강 #60)**에 포함하여 반영해 두었습니다. 다만, 해당 PR(test: task_review 폼 제출 및 material_analysis_status API 테스트 보강 #60)이 아직 dev에 머지되지 않은 상태라 추후 머지되면 재확인이 필요해보입니다.
   • 현재 뷰 로직에는 request.POST.get('action')을 통해 save 시에는 임시 저장 후 재이동, confirm (및 confirm_and_next) 시에는 확정 처리 후 planner:feasibility로 이동하도록 구현되어 있으니 PR test: task_review 폼 제출 및 material_analysis_status API 테스트 보강 #60 머지 후 함께 연동 테스트해 주시면 될 것 같습니다!

4. planner:feasibility 연동

   • 해당 URL 및 뷰가 현재 dev에 머지되어있는 것으로 확인 됩니다. 확인 후 반영 부탁드립니다!

고생 많으셨습니다!

[wngjs8114]

추가 확인 결과, material_analysis_status 폴링 로직의 필드 사용은 현재 API 응답 구조와 일치하는 것으로 확인했습니다.

JavaScript에서는 아래 필드를 사용하고 있습니다.

data.stage
data.extraction_status
data.analysis_status

실패 상태에서는 failed_stage, retry_remaining 등을 JavaScript에서 직접 렌더링하지 않고 location.reload()로 서버 렌더링 페이지를 다시 불러오는 구조이므로, 해당 필드를 폴링 코드에서 사용하지 않는 것은 문제가 아닙니다.

따라서 이전에 언급한 API 응답 필드 불일치 부분은 수정 요청에서 제외하겠습니다.

다만 서버 렌더링 화면에서는 다음 모델 필드를 기준으로 추출 실패와 분석 실패가 구분되는지 확인 부탁드립니다.

material.status
material.error_message
material.analysis_status
material.analysis_error_message
material.analysis_retry_count

특히 분석 실패 시:

• analysis_error_message 표시
• analysis_retry_count < 2일 때만 재시도 버튼 표시
• 재시도 2회 소진 시 직접 작업 추가 안내 표시

가 적용되어야 합니다.

현재 실질적인 연동 확인 사항은 task_review의 action=save|confirm 처리입니다. 해당 View 변경이 포함된 PR #60을 먼저 dev에 반영한 뒤 최신 dev를 병합하고 아래 흐름을 확인해주세요.

• 임시 저장 후 작업 검토 화면 복귀
• 작업 확정 후 planner:feasibility 이동
• PDF 추출 및 AI 분석 완료
• 추출 실패와 분석 실패 화면 구분
• 분석 실패 후 재시도 및 재시도 소진 처리

위 연동 확인과 전체 테스트 결과가 확인되면 PR #60 이 머지된 후 PR #63은 머지해도 될 것 같습니다.

[daynight0219-ux]

확인 감사합니다!

material_analysis_status 필드 관련 지적해주셨던 부분은 원래 문제없었다고 확인해주셔서 감사합니다.
실패 화면에서 analysis_retry_count < 2일 때만 재시도 버튼 노출, 2회 소진 시 "직접 작업 추가" 안내로 전환하는 로직 반영했습니다.
planner:feasibility는 로컬에서 확인했고, 이제 정상적으로 URL이 존재하는 것 확인했습니다.
action=save|confirm 분기는 PR #60 머지되면 바로 dev 받아서 전체 흐름(임시저장→복귀, 확정→feasibility 이동, 재시도 소진 처리 등) 다시 테스트해서 결과 공유하겠습니다.