[feat] user画面再提出機能の実装

[batcho0428]

開発目的

• DBで対応した申請ごとのステータス管理に対応し、申請の再提出・承認ワークフローを実現する。
• 提出状態と再提出フラグに基づいて、編集可否を動的に制御する。

考えられる開発内容

編集可否の制御ロジック

if (提出機能 == True) {
編集可
} else if (ステータス == 再提出) {
編集可
} else {
編集不可
}

ステータスの定義

• 未登録: 初期状態。編集可能
• 登録済: ユーザーが申請を提出した状態。編集不可
• 再提出: 管理者が再提出を指示した状態。編集可能
• 承認済: 管理者が最終承認した状態。編集不可
• 未チェック: 再提出後または承認済み後に編集された場合に遷移する状態。編集可能（再審査待ち）

実装の要件

• ステータスが NULL の時（DB未登録時）も問題なく動作する（デフォルト: 未登録として扱い編集可）
• 再提出が必要な時は、「登録済」「未登録」のステータスをオレンジ色の「再提出」に変更
• 再提出ステータスで編集したら、ステータスを「未チェック」に自動変更
• 承認済みで編集したら、ステータスを「未チェック」に自動変更（管理者の再レビュー促行）
• 1度再提出したら、編集できないようにロック状態に変更
• 管理者画面から再提出機能をトグル ON/OFF で制御（余裕があれば）

テスト項目

編集可否制御

• 提出機能 ON の場合、編集可能状態であることを確認
• 提出機能 OFF かつステータスが「再提出」の場合、編集可能状態であることを確認
• 提出機能 OFF かつステータスが「登録済」の場合、編集不可状態であることを確認
• 提出機能 OFF かつステータスが「承認済」の場合、編集不可状態であることを確認
• ステータスが NULL（未登録）の場合、編集可能状態であることを確認
• ステータスが「未チェック」の場合、編集可能状態であることを確認

ステータス管理

• 再提出が必要な場合、既存ステータス（登録済/未登録）がオレンジ色の「再提出」に表示されることを確認
• 再提出ステータスで編集後、DB内のステータスが「未チェック」に更新されることを確認
• 承認済みステータスで編集後、DB内のステータスが「未チェック」に更新されることを確認
• 未チェック→再提出（リジェクト）→未チェック のサイクルが複数回可能か確認
• ロック後は編集不可状態に遷移することを確認

ステータス遷移フロー

• 未登録 → 登録済（提出時）
• 登録済 → 再提出（管理者指示時）
• 再提出 + 編集 → 未チェック
• 登録済/未登録 → 承認済（管理者承認時）
• 承認済 + 編集 → 未チェック
• 未チェック → 登録済（管理者が再度チェック）

エッジケース

• 最初の申請で NULL ステータスから開始できることを確認
• 複数の申請がある場合、各申請のステータスが独立して管理されることを確認
• 再提出前から承認済みへの遷移が可能か確認

UI/UX

• 再提出ステータスがオレンジ色で表示されることを確認
• 承認済ステータスが視覚的に区別される色で表示されることを確認
• 未チェックステータスが適切に表示されることを確認
• 編集不可状態の場合、UI上で無効化（disabled）されることを確認
• ロック状態の場合、理由メッセージが表示されることを確認

管理者機能（余裕があれば）

• 管理者画面から再提出トグルを ON にできることを確認
• 管理者画面から再提出トグルを OFF にできることを確認
• トグル状態が各申請に正しく反映されることを確認

考えられる開発時間

• コア機能（ステータス遷移 + 編集可否制御）: 5～7時間
• UI/UX（3つのステータス表示、disabled制御）: 2～3時間
• テスト実装: 2～3時間
• 合計: 9～13時間（管理者トグルは +2～3時間）

備考

• リポジトリメモリの order_status_check_includes と同様に eager load を設計する
• 既存の health_center_document_review ステータス判定パターンを参考にする
• ステータス値の定義をマイグレーション or enum で統一する
• API レスポンスと フロント表示の境界を明確にし、ステータス値の統一を図る
• マイグレーション: ステータス列（nullable）と再提出フラグ、ロックフラグの追加が必要