[editor][P1] IndexedDB 保存失敗を同期状態に残し、メモリ上の証拠を救出できるようにする

[shinyaoguri]

確認日: 2026-09-09。対象コミット: 07277b86572f12dd67e6458867541dab7d7aad56。

何が起きるか（静的確認）

executeSave() は saveToIndexedDB() の例外を捕捉し、saveToSessionStorage() を呼んで Promise を正常完了する。後続 then は hasPendingEvents() だけで pending/synced を決め、永続化の成功/失敗を参照しない。

sessionStorage は events を含まない LightweightMultiTabStorage で、quota エラーも捕捉して返る。イベント処理済み（pending=0）でも保存が失敗した場合に、完全な記録が残っていないまま synced を表示しうる。

さらに export 前の flushToIndexedDB() は保存例外を伝播するため、永続化障害が ZIP の緊急出力も妨げる。

今回はコード経路の確認であり、実ブラウザに quota 障害を注入してデータ消失を実測したものではない。

影響・期待した動作

学習者に「保存済み」と見せた記録が reload 後に復旧できない可能性がある。保存状態は PoSW/イベント処理の完了とディスクへの永続化を区別すべき。保存先に障害があっても、メモリに残るデータの救出手段が必要。

再現・回帰テストの設計

1. イベント処理が完了し pending=0 のタブを用意する。
2. SessionStorageService の appendEvent/updateTab 等に QuotaExceededError または保存拒否を注入する。
3. debounce 保存の後、同期状態と最後に永続化できたイベント位置を確認する。
4. sessionStorage.setItem も失敗する場合を試験する。
5. メモリ上の記録を救出し、その proof を full 検証する。
6. 別途 reload を試験し、救済なしでどこまで残るかを確認する。

修正方針

保存処理の結果に failed/degraded を持たせ、最後に永続化したカーソルを表示状態に反映する。再試行には上限/間隔を設ける。緊急 export はイベント処理・スナップショットの整合性を維持しつつ IndexedDB 成功への依存を外す。未処理イベントを黙って捨てて valid な proof と称しない。

受け入れ条件

• 永続化失敗時に synced と表示しない。
• sessionStorage のみの退避が完全なイベント保存と区別される。
• 保存回復後に再試行し、欠落/二重 append なく状態が戻る。
• IndexedDB 不達でもメモリ上の整合した証拠を救出できる。
• quota、transaction abort、reload のテストがある。
• 救出できない場合は保存されていない範囲を明示する。

関連情報

• executeSave
• 軽量保存
• flushToIndexedDB
• export 前の flush
• Reload does not restore files from session storage #17 は原因未特定の復元問題。本件は保存失敗状態の消失と rescue 経路を対象。
• [editor] クラッシュ時に PoSW 計算中イベントは失われるが content は残り、復旧後 proof が content replay 不一致で invalid になりうる #142 / [editor] waitForQueueDrain timeout 時の export が content replay で invalid になる proof を生む #225 の処理待ち・復旧整合性を維持する。

スコープ外

保存基盤全体の置換、サーバーへのソース常時保存。

[shinyaoguri]

要件更新（2026-09-09）：コード保全と後からの再取得を最優先にする

ユーザーから「不正検知より、課題・試験で作成したコードが喪失せず、必ず後からログをダウンロードしてファイルを利用できることが最重要」と明示された。本 Issue を #306 の最優先の作業とする。以下は実装済みの報告ではなく、既存本文を補う・必要箇所を上書きする要件。

変更する原則

• 証明の valid を守るためにコードを捨てたり、古い内容に置換したりしない。
• 「整合した proof を出せるときだけ救出」から、現在のコードと取得できた全記録を救出し、証明の欠損は別に明示するへ変更する。
• メモリ上の最新コード、永続化済みのコード版、生イベント/処理待ち記録、暗号処理済みの証拠を区別する。コード保存を PoSW 完了・署名・分析・ネットワークに従属させない。
• 作業終了、期限切れ、タブを閉じる操作、モード変更、認証切れ、export 呼び出しを理由に、後から回収するための記録を自動消去しない。削除・保存期間は別の明示されたライフサイクルとして設計する。

今回の要件と衝突する既存箇所

対象コミット 07277b8 の TabManager.ts:1111-1133 は、復元した savedContent が chain replay と異なると reconstructedContent を返す。元のコードを別途保存せずこの内容を採用・再保存すれば、学生が書いた末尾を失う経路になる。静的確認であり、今回新たなクラッシュ再現試験を実施したものではない。

#142 の「整合性を回復する」という目的は維持するが、元の savedContent を不可逆に切り詰める方式は採らない。元コードを保存し、証明から再生できる版を別の候補として扱う。過去イベントの捏造で帳尻を合わせることもしない。

ProofExporter は queue drain、認証、IndexedDB flush 等の失敗で正常 export を止める経路がある。正常な証明の出力と、失敗時のデータ救出を別経路にし、後者はそれらの成功を前提にしない。

ダウンロードする成果物

• 最新のコードを通常のソースファイルとして取り出せること（全タブの名前・言語・フォルダ対応を保持）。
• 保存できた生ログ/暗号証拠/署名/画像と、それぞれの欠損・未処理範囲を保持すること。
• 正常な提出物と救出用データを schema/manifest で区別し、救出用ファイルを偽って valid と表示しないこと。
• ZIP 生成や画像読込が失敗しても、コード単体と取得可能なログを別々にダウンロードできること。
• ダウンロード済みファイルを再読込してコードと残存ログを利用でき、元のブラウザ DB・サーバー・署名鍵・ログイン状態を必須にしないこと。
• ダウンロードの開始を保存完了とみなして元データを消さないこと。

更新後の受け入れ条件

• 通信断/署名 API 不達/認証失敗/試験終了後でも、保持されているコード・ログを再取得できる。
• IndexedDB quota/transaction abort/PoSW Worker 停止/queue drain timeout/画像破損でも、最新コードの救出ボタンが使える。
• replay と savedContent が不一致でも元コードが消えず、両方を区別して取得できる。
• 一つの破損タブ/ログ/画像が、他のタブの保存・救出を妨げない。
• 保存状態はコード永続化・ログ永続化・暗号処理・外部署名を区別する。
• reload/Chrome 再起動後に保存済みのセッションを一覧から回収できる。試験期限やモードは閲覧/救出の障壁にしない。
• 救出ファイルを別のクリーンなブラウザ環境で読み込み、コードが元の内容と一致することをテストする。
• 保存失敗・ブラウザ強制終了・復元中断・長時間多タブ・容量不足を注入して評価する。
• 画面キャプチャ等の補助機能の負荷がコード保存を圧迫する場合、先に補助機能を制限し、その欠落を記録する。
• コード保存は世代管理/原子的更新等で直前の回収可能版を破壊しない。具体方式は測定して決める。

保証範囲を実装と合わせる

「絶対に喪失しない」は最上位の設計目標として扱う。ただし端末故障、全保存領域の消去、永続化前の強制終了までブラウザ内の一つのコピーで保証したとは表示しない。保存済みと通知する版の耐久性、未永続化の時間窓、独立したローカルファイルへのバックアップ導線を明確にする。別アプリのインストールや常時オンラインを前提にせず、警告だけで終わらず回収可能なコピーを増やす設計を行う。