restart — 連鎖破綻を判定して再モデル化から建て直す

v0 (2026-06-23) 未検証 N=1。信頼する前に empirical-prompt-tuning で標準実行者に回す。 設計: docs/design-model-first-and-restart.md

$ARGUMENTS の手詰まりに対して、まず連鎖破綻か局所バグかを診断し、連鎖破綻のときだけ 再モデル化から建て直す。この skill を呼んだ時点で、下の手順は standing 承認とみなしてよい。

位置づけ（既存との境界）

restart は固有の新ロジックを 1 つだけ持つ — step1 の連鎖 vs 局所の診断ゲート。 残りは既存 skill を束ねる orchestrator:

• calibrate（着手前の意図再構成）を step3 で内部 invoke — 置換しない。restart は mid-project、calibrate はその意図接地の部分。
• model-first（実装前のモデル固定）を step4 で内部 invoke — 建て直しの正しい先頭を作る。
• forget-approach（却下手法の参照除去）を必要なら invoke。
• codex:rescue（別モデルへの建て直し委譲）を step4 後の重い再実装で使える。
• fix/RED-first — step1 が「局所」と判定したらここへ routing（建て直さない）。

起動トリガ（連鎖破綻の検知）

• 各修正が別箇所の破綻を生む（もぐら叩き）— 損傷がモデル階層であり局所でない信号。
• モデルが一度も明示されず（暗黙仕様）、破綻が多数の実体にまたがる。
• user が「手詰まり／もう無理／断念」を述べた。

「同一手 2 回目で停止」（愚直 retry の停止）とは別階層。restart が拾うのは、各修正は別物（認識は増えている） なのに連鎖し続けるパターンで、それ自体が「先頭が誤っている」信号。

手順（6 段）

1. 連鎖 vs 局所 vs 監査要求の診断ゲート（最重要・固有に新しい唯一の部分） — まず何を問われているかを 3 分岐する（軽い手から）:

   • (あ) 監査要求 — user の「設計から間違ってる?」「手詰まりなら別エージェントに見てもらえば」等が、 行き止まりでなく過大報告された GREEN を別文脈で検算しろの合図のことがある（本リポ実例 6/13・6/18）。 直前が GREEN／diminishing-returns なら、まず verify／第二パスで結論の足元を検算する（建て直さない）。
   • (い) 局所バグ — X を直して解決・lock 済みモデルあり・破綻が 1 箇所 → fix／RED-first へ routing し restart 中止。
   • (う) 連鎖破綻 — 次がいずれも yes 寄り → step2 へ続行:
     • X を直すと Y が確実に壊れるか？
     • 破綻が多数の相互依存実体にまたがるか？
     • 明示 lock 済みモデルが無いか？

   建て直しは高コストで、過剰 restart は固有の失敗モード（難問からの反射的逃避・監査要求の取り違え）。 迷ったら (あ)→(い)→(う) の順に軽い手から試す（監査／局所で済むなら建て直さない）。

2. salvage 棚卸し — 壊れたモデルから独立に再利用できる資産を明示列挙する: データ・素材・test ケース・UI 殻・固まった語彙・そして要件そのもの（要件は今も有効）。 KEEP と DISCARD を分けて書く。良い部品を捨てない。

3. 意図の再接地 — calibrate を内部 invoke し、汚染された session の解釈を持ち込まず user の真意を逐語から再構成。 建て直しを「失敗した解に積もった前提」でなく本物の要件に接地させる。

4. 正しい先頭から再モデル化 — model-first を内部 invoke し、元のビルドに欠けていた明示モデル＋不変条件を作る。 OSS／正準実装を seed してよい。lock 後の重い再実装は codex:rescue（別 quota・別モデル）へ委譲可。 注意: 再モデル化した先頭も誤りうる（本リポ実例 6/9: 再設計の最初のモデルも失敗し組み直した）。 建て直しを一発正解と過大報告せず、新モデルにも step5 の実行可能な不変条件を効かせ、破れたら再 re-model に開いておく。

5. lock 済みモデルに対して建て直し — step4 の不変条件を実行ガードにして、 新ビルドが同じ連鎖を silent に再取得できないようにする。

6. 事後検視を残す — 最初のビルドが連鎖した理由（どの不変条件が暗黙だったか）を 1 段落で記録し、 自己改善ループへ橋渡しする（同型の再発観測が貯まれば model-first の enforced 化判断材料になる）。

安全不変条件

• salvage を必ず先行し、旧ビルドは新ビルドが検証されるまで消さない。 rm／移動を含む段は既存ガード（tmp-retention / block_recursive_rm_unrecoverable / verify_move_landed_before_rm）を経由する形でしか踏まない。建て直し＝即削除ではない。
• restart を難問からの反射的逃避にしない — step1 の診断ゲートが歯止め。局所は必ず fix へ。
• user データの破壊・外部への不可逆作用を含む段は、calibrate の stakes 判定（不可逆-復旧不能なら命令なしに踏まない）に従う。

出力（この skill の成果）

• step1 の判定（監査要求→verify／局所→fix／連鎖破綻→建て直し のどれか）を 1 行で明示。
• 連鎖破綻のときは KEEP/DISCARD 一覧・再モデル化した不変条件・建て直し計画を返す。
• step6 の事後検視（暗黙だった不変条件）を 1 段落。