[Feature] 승인 플로우 실제 API 연동 — 데모 UI와 서버 모델 정합 필요 (Approval)

[BcKmini]

배경

fowoco/server에 승인·감사 API가 실제로 구현·병합됐다 (#11). CaseDetailPage의 승인 플로우(#146)는 Figma 와이어프레임만 보고 데모로 먼저 만든 것이라, 실제 서버 모델과 차이가 있다.

실제 서버 API

POST /api/v1/tasks/{taskId}/approval-requests
POST /api/v1/tasks/{taskId}/approve
POST /api/v1/tasks/{taskId}/reject

• approval-requests: expected_version, ai_snapshot, hr_snapshot, changed_fields, source_versions
• approve/reject: expected_version, reason(반려는 필수, 승인은 선택)
• 응답(ApprovalResponse): approval_request_id, task_id, approval_status, task_status, content_revision, task_version, requested_at, decided_at

⚠️ 데모 UI와 실제로 다른 부분 (정합 필요)

• 서버는 단일 승인자 approve/reject만 지원한다. 지금 클라이언트 데모([Feature] 승인 플로우 오버레이 5종 구현 (요청/결정/반려사유/다른승인자처리/재승인diff) #146)에 있는 "승인자 그룹·ANY_ONE 규칙", "다른 승인자가 처리했습니다" 오버레이는 대응하는 서버 개념이 없다. 실제로 여러 승인자를 지정하는 기능이 있는지, 있다면 어느 API인지 먼저 확인해야 한다 (지금 스캔한 범위에선 못 찾음).
• "재승인 diff" 화면도 대응 API가 없다. 서버는 content_revision으로 재승인 필요 여부만 판단하고, 필드별 변경 비교(before/after)를 반환하는 API는 없다. 화면에 diff를 보여주려면 클라이언트가 이전 스냅샷(hr_snapshot)을 별도로 저장·비교하거나, 서버에 diff API 추가를 요청해야 한다.
• ai_snapshot/hr_snapshot/changed_fields/source_versions를 채우려면 Task 생성·수정 시점에 이 값들을 만드는 로직이 클라이언트 또는 서버 어디에 있어야 하는지도 확인 필요.

완료 조건

• 위 불일치 사항을 팀(서버 담당자)과 확인해 범위를 확정한다 — 그전까지는 구현 시작하지 않는다
• 확정된 범위에 맞춰 "승인 요청" 버튼이 실제 POST .../approval-requests 호출
• "승인"/"반려" 버튼이 실제 POST .../approve//reject 호출 (expected_version 낙관적 잠금 처리)
• 확정 범위 밖의 데모 오버레이(승인자 그룹, 다른 승인자 처리, 재승인 diff)는 유지할지 제거할지 결정
• 테스트 작성

[BcKmini]

서버 코드 더 깊게 확인했습니다. 확정된 사실:

• `ApprovalStatus`: `PENDING, APPROVED, REJECTED, INVALIDATED` — 4개뿐. 승인자 그룹/ANY_ONE 개념은 코드 어디에도 없습니다 (approval 패키지 전체 파일 목록 확인함, ApproverGroup류 클래스 없음).
• `PENDING_APPROVAL_EXISTS`(409) 에러코드 존재 — 즉 Task 하나당 동시에 승인 요청은 1개만 허용, 여러 승인자가 경합하는 상황 자체를 서버가 상정하지 않습니다.
• `INVALIDATED` 상태가 바로 "재승인 필요"에 해당합니다. Task 내용이 승인 후 변경되면 서버가 기존 승인을 자동으로 이 상태로 바꿉니다. 다만 필드별 before/after diff를 반환하는 API는 없고, content_revision 숫자 변화로만 판단합니다.

결론: #146에서 만든 "승인자 그룹", "다른 승인자가 처리함", "재승인 diff 표" 오버레이 3개는 지금 서버 모델로는 그대로 연동할 방법이 없습니다. 아래 중 하나로 방향을 정해야 합니다.

1. 데모 오버레이는 그대로 두고(향후 서버 확장 대비 화면), 지금은 승인 요청/승인/반려만 실제 API로 연동
2. 서버 담당자에게 다중 승인자 지원 계획이 있는지 먼저 물어보기
3. 데모 오버레이를 서버 모델에 맞춰 다시 설계(단일 승인자 + INVALIDATED 상태 기반 "재승인 필요" 배너로 단순화)

제 판단으로는 3번이 가장 현실적입니다 — 서버에 없는 기능을 프론트에서 흉내내는 것보다, 실제로 붙는 상태값에 맞춰 화면을 단순화하는 쪽이 유지보수하기 낫습니다.