2026年7月– date –

移設した監視が凍結コピーを読み書きし続けていた。9本・約1300行を新環境へ寄せ、初回だけベースラインを書き切ることで誤通知を避けた記録。

多重起動防止を二重にした結果、外側の排他制御と内部チェックが同じロックを取り合いました。38回の空振りを通じて見えた、終了コード0と処理成功の違いを記録します。

移設先で再作成した定期処理5本のうち、優先度指定の1行が原因で4本が一度も動いていませんでした。39バイトの警告ログ、監視の偽陰性、修正を横展開しなかった経緯から、移設完了を判定する方法を見直します。

移設済みのはずの電力収集が、新旧の常駐から60秒ごとに同じスマートプラグへ走っていた。エラーなしで続く二重実行を、棚卸し・停止権限・許容条件から整理する。

深夜00:16の切替は成功しました。しかし翌日、共有ストレージのマウント外れにより、バックアップが前日12:35から3回連続で失敗していたことが分かりました。移設の完了条件を見直す、進行中のビルドログです。

未認証の401を確認しても、利用者がスマートフォンの別ブラウザで配布物を受け取れるとは限りません。安全な拒否と利用者の成功を分けて検収する考え方を整理します。

更新APIの成功だけでは不十分です。公開状態、公開ページ、画像URLを読者側から確認する完了条件を、実際の復旧事例から整理します。

更新結果が新しい版を示していても、常駐処理が古い実体のまま動いていることがあります。更新・再起動・実体照合を一つの検収単位にする考え方を、実測を基に整理します。

minSdk 28のAPKが全体検証に成功していたにもかかわらず、v2だけを見る追加ゲートで停止しました。v2・v3の扱い、false negativeの原因、秘密を触らず再開するための完了条件を整理します。

監査を通過した成果物が、末尾改行を落とす処理によって公開直前に不一致と判定された。止まる設計を生かし、記録を改変せずに再開するための考え方を整理する。