設定ファイルなど既存データを部分編集して原子的に置換する処理は、書き込み前の状態確認と正常系のrenameだけでは安全性を証明できない。検査後から設置直前までの競合窓、rollback自体の失敗、テキスト変換で失われる管理外バイト、入力より大きくなる生成後データを独立した失敗クラスとして扱う。

検証する失敗クラス

• commit窓: 事前再検査の直後に別プロセスが保存した内容を上書きしない。退避した実物を初期fingerprintと照合し、差異時は新しい内容を復元して全体を中止する。元が存在しなかったpathへ競合createが起きる場合も、上書き不能な設置方法で検知する。
• 二次復旧失敗: 複数対象の途中失敗だけでなく、復元処理そのものを1件だけ失敗させる。1件の復元失敗で残りの復元を止めず、未復旧backupを削除せず、そのpathを診断へ返すことを確認する。
• バイト境界: UTF-8として意味が同じでも、BOM・改行コード・末尾改行・file modeは管理外データである。applyとremoveを往復した後に文字列比較でなくbyte比較し、元と完全一致することを確認する。
• 出力上限: 入力が上限内でも管理ブロック追加後の出力は上限を超え得る。staging前に生成後byte長を検査し、適用後に次回のcheck/removeが自己管理不能にならないことを境界値で確認する。

運用上の判断

fixtureは各失敗クラスを別々に発生させ、期待する非ゼロ終了、全対象の残留状態、backupの存否、診断内容まで固定する。正常系greenだけでなく、隣接する別のfail-open実装では同じ合格にならない反証として使う。