fix-loop: モグラたたき防止プロトコル

複数回の試行が予想される修正作業で使う。核心は 3 つ: 固定ガードテストセット / 1 変更 1 検証 / 試行台帳。

フェーズ 0: セッション開始

1. 修正目標を 1 文で定義する (何が通れば完了か)。
2. ガードテストセットを確定する:
   • 直したいテスト (target)
   • 過去にこの領域で壊れたことのあるテスト
   • 変更予定ファイルに関連するテスト (lit なら該当ディレクトリ)
   • 実行時間の目安: 1 回 5 分以内に収まる範囲。収まらなければ絞り、 最終確認でフルテストを走らせる前提にする。
   • セッション途中でセットを狭めない (広げるのは可。狭めるとモグラたたきが再発する)。
3. 台帳ファイル notes/fix-sessions/YYYYMMDD-<topic>.md を作る。関連するトレース ID (S-03 など) があれば冒頭に書く (影響範囲調査で辿れるように)。
4. ベースライン取得: ガードセットを 1 回実行し、結果を台帳に記録する。 lit の場合はログを保存し parse-lit-log.py save でベースライン化 (triage Skill のディレクトリに同梱されている)。

フェーズ 1: 修正ループ (1 反復 = 1 仮説 = 1 変更)

各反復で:

1. 仮説を台帳に書いてから変更する (「何が原因で、この変更でなぜ直るか」)。
2. 変更は論理的に 1 箇所。複数の仮説を同時に入れない。
3. ガードセットを毎回全部実行する (target だけ実行して他を確認しないのが whack-a-mole の温床)。 実行・計測の前に、測る対象が今のソースから作られたものかを確かめる (ビルドし直す、または実行ファイルとソースの時刻を比べる)。古いビルドを測ると 「コードの読みと挙動が食い違う」形の存在しない不具合を追うことになる (実例: 3 分古いバイナリの挙動を 30 分調べた)。
4. 結果を台帳のマトリクスに記録する:

## 試行履歴
| # | 仮説/変更 | 変更ファイル | target | ガード他 | 判定 |
|---|---|---|---|---|---|
| 0 | (baseline) | - | FAIL | all PASS | - |
| 1 | XXX が原因、YYY に修正 | foo.cpp | PASS | bar.ll FAIL | 後退→revert |

5. 判定ルール:
   • target 改善 + ガード後退なし → 採用、次へ
   • ガードのどれかが後退 → その変更を積んだまま次の修正をしない。 revert するか、後退の原因を理解して仮説を立て直す。 「壊れた方をあとで直す」は禁止 (それがモグラたたき)。

フェーズ 2: 収束判定

• 3 反復連続で純改善なしなら手を止める。追加の変更ではなく根本原因分析に戻る。 そもそも 2 つの要求が矛盾していないか (A と B が同じコードに逆の期待をしている)。 修正すべき層が違うのではないか (フロントエンド vs backend、共通部 vs ターゲット固有部)。 分析結果と選択肢をユーザーに提示して判断を仰ぐ。

フェーズ 3: セッション終了

1. 最終状態でベースラインとの差分を取り、純減 (直った数 − 壊した数) を明示する。
2. フルテスト (check-llvm 等の重いもの) の実行はプロジェクトルールに従いユーザーに確認する。
3. 台帳に結論 (採用した修正、根本原因、学んだこと) を追記して閉じる。 台帳は消さない — 次に同じ領域を触るときの「過去に壊れたことのあるテスト」リストになる。