架空企業「みらい業務サービス」の社内依頼・承認管理アプリの例。実在する会社・案件・人物は含まない。 記事「入力チェック・保存・状態更新をつなぎ、保存前後を照合する」（08-02）の本文で実際に実行して確認した内容をまとめたもの。空欄版は 08-02-storage-check_template.md。

1. 保存確認記録

処理入力期待される保存内容実際の保存内容照合結果
依頼の作成（必須項目不足）件名なし保存されず拒否される「必須項目が不足しています」と表示され保存されなかった一致
依頼の作成（正常）件名・内容・承認者ありrequestsに1件、historyに1件（作成）requestsに1件、historyに1件を確認一致
状態の更新（提出、ガード経由）依頼ID・操作者状態が「提出済み」、historyが2件状態が「提出済み」、historyが2件を確認一致
提出の拒否（存在しない依頼）存在しないID拒否され、保存先は変わらない「対象の依頼が見つかりません」で拒否。保存先は不変一致
提出の拒否（提出済みの再提出）提出済みの依頼ID拒否され、保存先は変わらない「状態が「提出済み」のため提出できません」で拒否。保存先は不変一致
08-01の判定関数との接続保存した依頼から読み出した値提出前は false、提出後は true提出前 false、提出後 true一致

2. 日付・時刻・文字コードの扱い

日時はnew Date().toISOString()によりタイムゾーンが分かる形式で記録。文字コードはNode.js標準のUTF-8。

未検証：書き込み途中の失敗、複数の利用者による同時保存、差戻しからの再提出（08-04・09-03・記事Bで扱う）。1回の書き込みは片方だけ残る隙を小さくする工夫で、トランザクションの保証ではない。実行記録は evidence_public/phase5b2b-2026-09-20/08-02/run_log.md。

3. 完了条件の確認

4. 次工程へ渡すもの