bug-diagnosislisted

# bug-diagnosis: バグ診断の規律 手強いバグ向けの規律。工程を飛ばすときは理由を明示する。 ## 工程1 — 再現ループを構築する **これが本体。他の工程はすべて機械的作業。** ユーザーの症状そ���ものに反応する tight な pass/fail シグナルさえあれば、二分探索・仮説検証・計装はそのシグナルを消費するだけで原因へ到達する。無ければどれだけコードを読んでも到達しない。 ここに不釣り合いなほどの労力をかける。 ### 構築手段（この順に試す） 1. バグに到達する層（unit・integration・e2e）での**失敗テスト** 2. 動作中の dev サーバーへの **curl / HTTP スクリプト** 3. fixture 入力を渡す **CLI 実行**（既知良好出力との diff） 4. **headless ブラウザスクリプト**（DOM・console・network を assert） 5. 実際のリクエスト・ペイロード・イベントログを保存しての**トレース再生** 6. バグの経路だけを単一関数呼び出しで通す**使い捨てハーネス** 7. 「たまに違う出力になる」系は乱数入力1000件を回す **property / fuzz ループ** 8. 既知2状態間で出たバグなら `git bisect run` できる**bisect ハーネス** 9. 旧バージョン・旧設定と新バージョン・新設定へ同一入力を通す**差分実行** 10. 最後の手段として、人が操作する場合もスクリプトで手順を構造化し、出力を回収してループに乗せる ### ループを締める ループを得たら製品として扱い、締める: 速くできないか（セットアップキャッシュ・無関係な初期化のスキップ・テスト範囲の縮小）、シグナルを鋭くできないか（症状そのものを assert する。「クラッシュしない」では不十分）、決定的にできないか（時刻固定・乱数シード固定・ファイルシステム分離・ネットワーク凍結）。 非決定的なバグは、きれいな再現ではな��**再現率を上げる**ことが目標。トリガーをループさせ・並列化し・負荷をかけ・タイミング窓を狭め・sleep を注入する。 ### ループを作れない場合 明示的に停止し、試した内容を列挙する。ユーザーへ (a) 再現する環境へのアクセス、(b) 採取物（HAR・ログダンプ・コアダンプ・タイムスタンプ付き録画）、(c) 一時的な本番計装の許可のいずれかを求める。ループ無しで仮説立案へ進まない。 ### 工程1の完了条件 次を1つでも満たさない状態でコードを読んで仮説を立て始めたら、それ自体が停止合図であり工程1へ戻る: - [ ] **red-capable** — 実際のバグ経路を通り、ユーザーの症状そのものを assert する（「エラーなく完走」では不十分）。このバグで赤くなり、直れば緑になる - [ ] **決定的** — 毎回同じ判定を返す（非決定的バグは高い再現率へ固定済み） - [ ] **秒単位** — 分単位ではない - [ ] **agent 単独実行可能** — 無人で実行できる単一コマンドとして、既に1回以上実行済みである ## 工程2 — 再現と最小化 ループを実行し、赤くなることを確認する。 - ユーザーが記述した故障モードと一致している（似て非なる別の失敗ではない） - 複数回の実行で再現する（非決定的バグは十分な再現率で） - 後段の検証用