2026年7月11日（土）

今日やったこと

• TSUMOO-59 振り返りAPI契約・エラー形式整理の開始ファイルを作成した
  • TSUMOO-58 で整理した振り返り機能を前提に、API契約、validation、error response、Next.js 側の API 型 / mapper を確認する課題として整理した
  • GET /api/review/today、GET /api/review/weekly、PUT /api/review/memos/{date} を主対象にした
  • 新しい振り返り API endpoint は追加しない方針にした
• Review API のエラー形式について方針を決めた
  • PUT /api/review/memos/{date} の不正日付 422 は、Task API と同じ code: validation_error / message / errors 形式へそろえることにした
  • ReviewMemoController にある日付 validation は、Controller から Request 側へ寄せる方針にした
  • 共通 ApiFormRequest を新設し、まず UpsertReviewMemoRequest だけに小さく適用する方向で進めることにした
• Review API の response shape の責務を見直した
  • Service が target_count や review_memo のような API response key を直接作る状態には違和感があると整理した
  • Service / Action は集計や summary 材料作成に寄せ、Resource は API response shape を担当する方向で検討することにした
  • ReviewDaySummaryBuilder をそのまま response shape の中心として維持するのではなく、Resource 化と合わせて責務を見直す候補にした
• Enum / 定数化の方針を決めた
  • Review 専用 Enum は過剰に増やさず、response contract key を守る目的に限定して小さく導入する方針にした
  • status_counts、extra_counts、time_totals など、API contract として崩したくない key を中心に確認する
• Next.js 側の整理方針を確認した
  • reviewSummaryApi.ts は、API型、画面用型、mapper、API呼び出しがまとまっているため、型と mapper の分割を優先する
  • API呼び出しの挙動は変えず、読みやすさと contract の追いやすさを上げる方針にした

ロードマップ

フェーズ1: タスク管理MVP

進捗: 54 / 67件

今日対応したタスク

• 進行中 TSUMOO-59 振り返りAPI契約・エラー形式整理

完了したタスク

• TSUMOO-58 振り返り機能の責務整理
• TSUMOO-57 一括管理API契約・エラー形式整理
• TSUMOO-56 一括管理機能に向けたタスク操作設計整理

次に取り組むタスク

• TSUMOO-59 振り返りAPI契約・エラー形式整理を実装へ進める
• backend では ApiFormRequest、Review Resource、Enum / 定数化、Feature test を確認する
• frontend では reviewSummaryApi.ts の型と mapper を分ける

考えたこと

TSUMOO-58 では、振り返り summary の組み立てを Service に寄せましたが、API契約として見ると Service が response shape を持ちすぎるのは少し気持ち悪さが残りました。

集計する責務と、APIとしてどの key で返すかを決める責務は分けた方が読みやすいです。TSUMOO-59 では、その違和感をそのまま流さず、Resource と Enum / 定数化でどこまで整理するかを確認します。

決めたこと

• PUT /api/review/memos/{date} の 422 は validation_error 形式へそろえる
• 日付 validation は Controller から Request 側へ寄せる
• 共通 ApiFormRequest を新設し、まず Review メモ保存 Request に適用する
• Review API の response shape は Resource 側へ寄せる方向で検討する
• Service / Action は集計・summary 材料作成に寄せる
• Enum / 定数化は response contract key を守る目的に限定して小さく導入する
• reviewSummaryApi.ts は型と mapper の分割を優先し、API呼び出しの挙動は変えない

次にやること

• TSUMOO-59 の backend 実装候補を棚卸しする
• ApiFormRequest を小さく導入し、Review メモ保存の validation error をそろえる
• Review Resource の最小構成を検討する
• response contract key を守るための Enum / 定数化候補を確認する
• 実装後に ReviewSummaryTest、frontend の type check / lint、docs の git diff --check を通す