架空企業「みらい業務サービス」の社内依頼・承認管理アプリの例。実在する会社・案件・人物は含まない。 記事「承認処理の修正差分を、実装者以外の観点でレビューする」（09-04）の本文で実際に記録した内容をまとめたもの。空欄版は 09-04-review-record_template.md。

1. レビュー記録

対象差分観点指摘対応確認者
08-04 storage_v1.js→v2.js要件との対応部分失敗を正常完了として扱わない報告にはなっている（REQ-007）。ただし保存先には状態だけ変わった依頼が残る（不変条件の行）報告は対応不要。保存先は未対応Claude Code（実装者と同一の自己レビュー。独立レビューではない。本文第3.3節・第8.1節）
同上権限権限判定は変更しておらず、新たに許可される操作はない対応不要同上
同上履歴失敗時にも原因調査に必要な情報が失敗ログに残る対応不要同上
同上秘密情報の混入失敗ログにパスワード等の秘密情報は含まれていない対応不要同上
同上不変条件（状態のロールバック）履歴の書き込み失敗時に状態を元に戻す処理がなく、記事Aの不変条件（承認済みには承認履歴が必ずある）を満たさない未対応（残課題）同上

2. 残課題一覧

残課題影響対処予定
実装者以外の人による確認が行われていない中（利用開始前に人による確認が必要）10-01の確認者も同じAI。10-04で「限定試行へ進む条件」として延期。この教材の範囲では未回収
履歴書き込み失敗時に状態をロールバックしない設計（不変条件の違反）中（頻度は低いが発生時に運用対応が必要）設計の解決は記事B（09-02）のトランザクション。題材アプリへの適用は未決。12-02の本文は現時点でこの課題を扱っておらず未回収

3. 完了条件の確認

4. 次工程へ渡すもの