fix: ローカルLLM 実行の安定化 — opencode の防護装置と Finding Contract の凍結解消 - #1017

- tool.execute.before プラグインで数値引数の型違い（"290.0"）と filePath の
  別名（filepaath / path）を矯正する。上流 anomalyco/opencode#1328・#26870・
  #29142 が未修正で、qwen3-coder-next は同じ呼び出しを繰り返して cycle budget
  を使い切る。実在する絶対パスのときだけ読み替え、推測はしない。
- サイクル予算を「ツール成功のない連続サイクル」で数える。総サイクル数で
  打ち切ると健全な作業も殺す（実測: 9万行のリポジトリで implement が 120
  サイクル・ツール成功 150 回の途中で abort された）。
- session.summarize() はジョブ投入で即返るため、完了と成功の両方を待つ。
  今回の summarize が作った summary だけを id で識別する。要約対象が無くても
  summary は必ず作られる（実測）。
- agent プロンプトを OpenCode 既定に戻し、#892 が必要とした ls / Task tool の
  2 箇所だけを取り除く。節ごと削ったせいで弱いモデルがツールの使い方を
  失っていた。client.ts は常に 'en' を読むため ja 版は削除する。
- 失敗したツール引数の debug ログで、機密キーの値をマスクする。

judge に provider 指定が無いと、ループを踏んだステップ（fix = coder）の
provider/model を runtime として強制していた。実装した本人が「自分のループは
健全か」を判定することになり、監視が機能しない（実測: qwen が 4 回とも
「健全」と判定し、reviewers → final-gate → fix が 56 周・9 時間続いた）。

優先順位を judge.provider/model → provider_routing / persona_providers.loop-judge
→ トリガー元、に正す。judge ステップに providerRoutingPersonaKey: 'loop-judge'
を持たせ、findings-manager と同じ仕組みで席を指定できるようにする。
provider だけ明示された場合はトリガー元の model を引き継がない。

取り込みは ParallelRunner からしか呼ばれておらず、単独ステップの final-gate が
出した指摘は台帳に入らず fix に届かなかった。final-gate が同じ指摘を出し続け、
fix は直すものが無く、reviewers → final-gate → fix が永久に回る（実測: 56 周）。

- output_contracts.report[].formatRef が *-finding-contract のステップは、
  単独でも parallel でも取り込む。取り込みはルール評価の前に行い、直後に
  findings 状態を再読込する。
- workflow_call の子エンジンへ親の findingContract / findingLedgerStore を
  継承する。子が自前の contract も持つ場合は設定エラー（ledger_path が
  ワークフロー名に紐づき、親の when(findings.*) が別の台帳を見るため）。
- 子の書き込みを親が見られるよう、workflow_call 完了後に findings を再読込。
- 台帳が無いのに finding-contract 形式で出力するステップは実行前に落とす。
  黙って指摘を捨てない。
- raw finding ID に呼び出し名前空間（親ステップ#反復）を含める。継承により
  複数の子が同じ台帳へ書くようになり、同じ子を並列で呼ぶと ID が衝突した。
- 台帳の更新を直列化し、保存直前に再読込してから適用する。

従来は 2,599 字のスキーマで 8 つの配列を LLM に組み立てさせ、台帳の不変条件も
守らせていた。gpt-5.5 でも破る（takt-bench v2 の 7 走行が検証失敗。
"Cannot resolve finding F-0006 because it is not open" など）。難しさはモデルの
賢さではなく仕事の渡し方にある。

- LLM は 1 件ごとの判断（same / new / resolved / reopened / conflict、
  waive / note、resolve / keep）だけを返す。
- 組み立てと不変条件の強制は decision-assembly.ts が行う。違反した決定は
  その 1 件だけ不採用にし、不採用項目だけを再問い合わせする。
- 決定が欠落した residual raw finding も不採用として扱い、再問い合わせに乗せる。
- 同一 familyTag・同一 location の new は機械的に 1 件へ畳む。既存の open
  finding と一致するものは same に倒す。LLM の判断に委ねない。
- resolution_confirmation は new の証跡にできないため new に倒さず記録に残す。

これにより弱いモデルでも manager が動く。

takt-default-for-local-llm は #974 で takt-default から派生させたのではなく、
レビュアー編成の実験ワークフローに Finding Contract を足したものだった。本流に
ある工程が 2 つ落ちている。

- implement の後に AI 自己レビュー（ai-antipattern-review-1st ⇄
  ai-antipattern-fix ⇄ ai-antipattern-no-fix）を戻す。本流の backend.yaml
  などが持つ工程で、弱いモデルほど必要になる。
- final-gate を merge-readiness-review + supervise の parallel にする。
  supervise が新規・継続・解消を突き合わせないと、merge-readiness が毎周
  同じ指摘を出し直して閉じない（実測: 56 周・9 時間）。

対象は finding_contract を持つ 5 本（takt-default / backend / backend-cqrs /
frontend / dual）の ja / en。

あわせて、OpenCode の送信内容を捕まえる計器（prompt-evals/）と、その観測で
判明した事実（既定プロンプトの取得方法、CLAUDE.md の注入、リクエストが 2 本
飛ぶこと、opencode run は計器に使えないこと）を CLAUDE.md に記録する。

OpenCode は存在しないツール名と実在ツールの引数不備を、どちらも
`invalid` という擬似ツールの status='completed' として返す。3つの検出器
（unavailable / invalid-argument / error-budget）は status==='error' で
しか observe されないため、拒否がまるごと死角に入っていた。さらに
completed 扱いなので「ツール成功」とみなされ、空転サイクルの計数まで
リセットしていた。

実測（takt-bench v3-r1、qwen3-coder-next の implement）: invalid 435件
（read の引数不備 219 / 存在しない run 216 / ほか）、最長195回連続。
どの防護装置も発火せず、cycle budget を焼き切って abort した。

- extractOpenCodeToolRejection() で error と invalid/completed を正規化し、
  state.input.tool から本来のツール名を取り出して検出器へ渡す
- 空転リセットを else if にして、拒否ではリセットしない
- 引数欠落の実際の文言 "is missing or invalid" をパターンに追加

回帰テストは実測したイベント形状（tool='invalid', status='completed',
input={tool,error}）で書いた。既存テストは status='error' を使っており、
実データに1件も存在しない形だった。単発の空振り後に成功する自己修正は
打ち切らないことも検証する。

同じ finding について、あるレビュアーが「修正済み」を確認し、別のレビュアーが
「同じ問題が別の行に残っている」と報告することがある。どちらも正当な観測で、
矛盾は現実の側にある（部分的にしか直っていない）。

このとき manager の決定は同じ finding id を matches と resolvedFindings の
両方に載せる。「1 finding = 1 決定」の不変条件がこれを違反として扱い、出力
全体を破棄して台帳を更新しなかった。矛盾を記録するための conflicts 自体も
同じ検査に含まれていたため、逃げ道が無かった。

結果、レビュアーは毎ラウンド同じ修正確認を出し続け、reviewers ↔ fix が
収束しない。実測（takt-bench v3-r2）: F-0002 の修正確認と同 familyTag の
残存指摘（:137 と :149）が衝突し、12 イテレーション回っても台帳は
最初のラウンドの 4 件で凍ったままだった。

- same と resolved が同じ finding に付いた場合、未修正の証拠を優先して
  open に留め、修正確認を conflict として記録する（manager 指示の
  「迷ったら open を維持」と同じ向き）
- conflicts は他の決定について述べるメタ決定なので、検証・適用の双方で
  「1 finding = 1 決定」検査の対象から外す
- resolution_confirmation の raw を根拠にした "new" は組み立て時に 1 件
  だけ不採用にする。最終検証まで通すと 1 件の違反で出力全体が無効化される

flatten → 再組み立ての往復（保存直前の lost update 対策）が安定することも
検証する。既存テスト1件は matches と conflicts の併存を「拒否すべき」と
固定しており、逃げ道を塞いでいた張本人だったため差し替えた。

同じ finding への修正確認と残存指摘の衝突が「1 finding = 1 決定」違反として
出力全体を破棄し、台帳が更新されないまま reviewers ↔ fix が収束しない問題の
恒久修正。8e17d94d は組み立て側だけを直しており、resolution_confirmation を
機械分類が先に消費する本番経路（機械分類 → LLM → merge）では衝突が merge で
再生して同じ凍結が残っていた（codex が直接実行で再現）。

- canonicalize.ts: matches ∪ conflicts に現れる finding の resolvedFindings を
  取り下げて conflict へ畳む正規化を新設し、merge 直後と組み立て直後の両方に適用
- decision-rules.ts: 許可ペア（match+conflict / reopened+conflict）と
  「closed な finding を conflict が参照するなら同じ出力で reopen 必須」の
  status 不変条件を一本化。検証と適用が同じ規則を使い、順序非依存で全ペア検査
- waive の裁定を merge 後の正規化済み出力に対して行う。レビュアーが再観測して
  いる finding への waive はゲートを開けず、conflict + disputeNote へ変換して
  need_replan 側へ流す（manager は allowedTools: [] でコードを照合できないため、
  ゲート開放の権限を与えない）
- flatten の戻り値に finding-only conflict を持ち越す carriedFindingOnlyConflicts
  を追加（raw ID の無い conflict は raw decisions から復元できず、保存直前の
  再組み立てで消えていた）。統合前に fresh ledger での open を検査し、並列子が
  先に resolved にした finding への carried は理由つきで不採用にする
- 同一ラウンドで再生成される conflict の resolve を不採用にする（最終形の
  conflicts から formatConflictId で判定）
- reconciler の重複した決定組み合わせ検査を削除（入口の validate に一本化）

エンジン実経路（実 FindingLedgerStore の updateLedger 往復）で、保存後台帳に
open finding + active conflict + disputeNote が残り conflicts.count>0 ルールが
選ばれることを正方向テストとして固定。旧テストは凍結挙動を仕様として固定して
いたため、新仕様の正方向へ転用し、negative は別の不変条件違反へ差し替えた。

main 起点への積み直しで、#1008 が finding_contract.manager に入れた
provider/model 指定（直接指定を最優先、未指定時は workflow provider/model →
provider_routing.personas の順で解決）が、衝突解決時に4ファイルから
脱落していた。ブランチの現在構造（decisions-only manager、contract-intake
経由の並列/単独共通取り込み）に載せ直す。

- manager-step.ts を唯一の合成ステップビルダーに戻し、スキーマを
  ブランチの decisions 契約（takt.findings.manager.v2）へ更新。
  #1008 の provider/model ロジックは維持
- manager-runner.ts のローカル簡易ビルダーと重複スキーマ定義を削除し、
  workflowProvider/workflowModel を受けてビルダーへ渡す
- 単独ステップ取り込み（StepExecutor 経由）にも同じ解決を適用
  （#1008 は ParallelRunner のみだったが、ブランチは両経路で manager を起動する）
- WorkflowValidator の finding_contract.manager 検証を main と同内容で復元

…け回復する

FC レビュアステップの phase 1 が次の連鎖で abort していた（takt-bench v3-r2 実測）:
セッションキーの既定が persona のため -1st レビュアと parallel FC レビュアが
セッションを共有し、native StructuredOutput の成功履歴が混入 → native 失敗後の
退化が同じセッションのままツールだけ外し、フェンス指示も注入せず再試行 →
モデルが記憶にあるツールを2回呼び、UnavailableToolLoopDetector（閾値2）で
ステップ失敗 → workflow abort。検出器は幻覚ツールと「TAKT がいま外した
ツール」を区別できない。

- structured-output-recovery.ts を新設し、attempt 計画（sessionMode ×
  structuredMode）・退化遷移・stale 回復遷移を純粋関数に集約
- 退化（native 失敗後の formatless）は fresh session で実行し、プロンプトを
  structured_json_schema_instruction で包む（従来は生プロンプトを指示ゼロで
  再送していた）。1回限り。新しい session ID を上位へ返す
- resumed かつ format 無しの attempt で StructuredOutput だけが閾値到達した
  場合、エラーにせず fresh session で1回だけ再実行。fresh で再発したら本物の
  失敗として従来どおり落とす。run 等の他ツールは従来どおり即検出
- テンプレート（en/ja）に「StructuredOutput ツールは呼ばないでください」を明記
- builtin 10本で -1st レビュアと parallel FC レビュアに別 session_key を付け、
  契約混線を入口で防ぐ

codex レビューの残ブロッカー2件の解消。

- findings-manager の起動判定を resolveFindingContractIntakeStep として
  contract-intake.ts へ切り出し、実行時（StepExecutor）と preview
  （workflowPreview）が同じ述語を使う。preview は単独 FC ステップの後にも
  manager を表示する。並列サブステップには付けない（実行時は並列全体で
  親レベル1回のため）。parallel / arpeggio / team_leader は
  isDelegatedWorkflowStep で除外（専用 Runner は manager を起動しない）
- validateFindingContractManagerProviderModel が inheritedFindingContract も
  検証するよう修正して export。WorkflowCallExecutor は子 engine 構築前に
  明示的に検証し、workflow_call で継承した契約の manager が子の
  provider/model 解決で成立しない場合に fail-fast する

takt-bench v3-r2（292分・49イテレーション）の台帳解剖で確定した3つの
非収束要因への対応。

1) 幻覚 location: 実在しないファイルへの指摘4件（うち critical 1件）が
   台帳に入り、critical は waive 不可 + 証跡は file:line 必須のため永久 open
   だった。raw の受け入れ時に path と行範囲を決定的に検証し（末尾改行の
   境界と symlink 脱出も遮断）、不採用は監査記録に残す。既存 finding には
   invalidated 状態を新設 — エンジンが fs で候補を計算し、manager は候補から
   選ぶだけ（LLM の主張単独では無効化できない）。critical も無効化できる。

2) 同一性の誤り: familyTag + location の完全一致は、同一問題を分裂させ
   （タグはレビュアごとの語彙、行はコード変更でずれる。F-0011/17/18 が
   3重に積まれた）、別問題を誤統合もした（F-0016 の混成）。familyTag と
   行番号を同一性から降格し、機械分類は3ケース（完全同一 raw / relation +
   targetFindingId の明示参照 / resolution_confirmation）に縮小。同一性の
   最終判断は manager の意味判断へ。機械の畳み込み鍵は正規化 path + title +
   description の完全一致（大小文字保存）に統一。

3) 逃げ道の不足: raw findings に relation（new / persists /
   resolution_confirmation / reopened）を追加し、既存指摘への言及を構造化
   （旧形式は kind と targetFindingId から導出して後方互換）。manager には
   unsupported 判断を追加 — 根拠が成立しない再報告を new に落とさない。
   duplicateDecisions で既存の重複 finding を canonical へ統合し、重複側は
   superseded にする（open 限定・循環検証・履歴保存。resolved/waived とは
   別の意味）。invalidated / superseded はサマリとルールコンテキストに
   件数を出し、open が減った理由を監査可能にする。

台帳スキーマは追加的（version 1 のまま）。v3-r2 の実台帳をフィクスチャに、
F-0016 を生んだ実 raw 群のリプレイで再マージが起きないことを固定した。

v3-r2 実測の詰み — coder の反証とレビュアの再観測が衝突した conflict が、
裁定の場なく即 ABORT — への対応（収束設計 Phase B）。

- finding-conflict-adjudication をエンジン合成の実在ステップとして注入
  （イベント・履歴・resume・ループ検出は標準機構）。supervisor persona +
  読み取り専用ツールで conflict の全証拠と現在の diff を読み、構造化4択
  （finding_valid / finding_stale / evidence_invalid / undetermined）で裁定。
  outcome → 遷移はエンジンが照合し、LLM の自由記述に権限を与えない
- actionable（finding_valid + 修正案あり）は conflict を解消して fix へ、
  stale/evidence_invalid は resolved / invalidated へ（file:line 実在検証つき）、
  undetermined はゲートを開けず ABORT 側（安全側エスカレーション）
- 裁定は証拠集合につき1回: 内容ベースの evidenceHash（raw 本文 + disputes +
  conflict description）を LLM 呼び出し前に排他区間で記録し、適用直前に
  fresh hash と一致確認（不一致は破棄して監査）。過去の全裁定・全 attempt と
  照合して既出 hash への再裁定を禁止。同一 run の rate-limit fallback だけが
  pending 予約を引き継げる（別 run の resume は封鎖）
- 戻り先 origin は attempt 記録に永続化し、previousStep → pending attempt →
  一意な配線元 → ABORT の順で解決（推測遷移をしない）
- for-local-llm 10本 × reviewers/final-gate の conflict ルールを裁定経由に
  変更し、裁定を迂回していた ai() ルールを削除
- レビュア再生成: 既存 open finding と同 path+title（description は異なる）の
  relation=new raw は1回だけ明示を求めて再生成。契約検証（raw 集合の完全一致・
  非対象 raw 不変）に違反する再生成は破棄し、なお不整合なら unsupported として
  監査記録に落とす。例外時は元出力保持でステップを失敗させない

- 保存直前の再組み立てで invalidation 候補を fresh 台帳・現 cwd で再計算し、
  判断時点と保存時点の間に location が有効化した finding への stale な
  invalidate を不採用にする（判断の鮮度保証を carried conflict と同水準に）
- duplicateDecisions の canonical を waive/note 併存禁止集合に追加
  （canonical は open 維持が契約）
- duplicateFindingIds の非空をスキーマと検証の両方で強制（決定側と対称）
- relation 導出ロジックを deriveRawFindingRelation に一本化
  （mechanical-classification 側の独立実装を委譲に変更）、実在しない
  関数名を指していたコメントを修正
- レビュア向けプロンプト（en/ja）に kind の設定規則を明示
- workflow_call 継承時、裁定 runner の workflowName を台帳ストアの
  正準名（親名）にし、saveLedger の検証不整合を解消

サブステップの rules の next は並列集約で消費されない（condition 文字列しか
読まれない）のに、合成ステップの注入条件はサブステップ配線も数えるため、
「注入されるが到達不能」という黙った死に設定が作れた。doctor はこれを
警告し（親の rules に配線せよ）、finding_contract なしの配線はエラーにする。
WorkflowValidator も同じ境界に揃える。

…E ゲートで塞ぐ

レビュア出力の kind/relation 矛盾などの曖昧な raw finding を、parse 失敗による
run 死ではなく3段の梯子で処理する:

1. 機械正規化: 決定可能な矛盾はコードで正規化（kind は relation から導出、
   矛盾 target は wire から除外）。正規化前の元の主張は rawNormalizations として
   intake 直後に write-ahead 永続化（監査復元可能）
2. レビュア1回突き返し: relation 不整合はレビュアへ1度だけ訂正機会を返す
3. manager 解釈: なお曖昧な raw は findings-manager が解釈を提案（capability 格子で
   ambiguous 起源は new/provisional/conflict のみ発行可能、resolve/waive 系は不可）

解釈不能な raw は provisional finding（status=open + provisional metadata）として
台帳に着地し、gate-blocking として COMPLETE をエンジン不変条件で fail-fast させる。
builtin 10 ワークフローに findings.provisional ルーティングを追加し、
旧 invalid_manager_output 迂回路は削除（doctor 警告 + docs 移行手順あり）。

- 2層スキーマ（candidate/canonical の nominal brand + WeakSet 登録）と ambiguity taint
- CAS 前提条件（全 confirmation/reopen/waive/invalidate/supersede）
- interpretation WAL（started/completed/ledger_applied、applied 再来は着地種別で分岐）
- provisional の確定は完全 identity または保存済み lineage の一意対応のみ
- clean raw の location 不成立は drop せず invalid-location-evidence provisional 化
- 出力上限は schema 構造（maxItems/maxLength）で強制
- 攻撃回帰テスト35件（finding-ladder-attacks.test.ts）

codex 検証4巡（B1-B4 + 監査復元 + write-ahead）合格済み

…容に受ける

v3-r3 ベンチ実測で、reviewer(gemma) が legacy の kind を rawFindings に併記し、
strict な wire スキーマ（additionalProperties: false・kind なし）が 1回訂正後も
出力を拒否して run が abort した。intake 側は kind を受けて機械正規化・claimedKind
監査する実装済みで、wire スキーマだけが寛容経路を到達不能にしていた。

単純に kind を optional 追加すると OpenAI/Codex 系 native structured output の
全プロパティ required 制約に違反し、逆に native 経路が生成前に死ぬため、役割で分離する:

- RawFindingsOutputJsonSchema（provider 向け）: strict のまま復元。native provider は
  スキーマで生成が拘束されるため kind を出力できず、寛容化は不要
- RawFindingsOutputValidationJsonSchema（post-hoc 検証用、新設）: strict + kind optional。
  スキーマが生成を拘束しない formless/劣化経路（opencode+ollama 等）の出力検証専用
- WorkflowStructuredOutput.validationSchema を追加し「provider へは schema のみ /
  post-hoc は validationSchema ?? schema」を契約として明文化。StepExecutor の
  post-hoc 検証2箇所を validationSchema 優先に変更

codex 検証合格（native/post-hoc 両立・選択漏れなし・寛容版の provider 逆流なし）

… 監査添付・npm test 高速化

v3-r3 ベンチ実測で、コードは収束したのに provisional が9件蓄積して COMPLETE に
到達できない非収束が観測された。codex 診断は「安全性（観測を消さない）は証明済みだが
liveness（いつか収束する）が未証明」。原因別に4対策を入れる:

- A-1: resolution_confirmation の証拠不採用時の除外が clean 経路にしかなく、
  tainted 経路では一律 provisional 化されていた経路非対称バグを修正。
  さらに tainted confirmation は admission 成否に依らず ladder に載せず
  監査保存のみとし、着地規則を4象限で対称化（曖昧起源は capability 格子上
  resolve 権限を持たないため、blocker も作らず target も触らない）
- A-2: location の機械正規化 — 行範囲 path:start-end は path で実在検証、
  N/A と空文字は locationless。適用事実は rawNormalizations に監査記録
- A-3: 証跡不成立の persists 再観測は、reconcile 後の台帳で target が open なら
  rejectedObservations へ監査添付（独立 provisional を作らない。target が既に
  gate を塞いでいるため観測は消えずゲートも開かない）。reconcile 中に target が
  閉じた場合は provisional へフォールバック（gate 非減少）
- A-4: npm test の引数なし経路を4シャード同時×1ワーカーから test:unit:parallel
  単一実行（既定75%ワーカー）へ変更。実測 98.6s→67.2s。CI は ci.yml が
  shard を直接実行しており無影響

codex 検証2巡合格（v3-r3 実台帳データでの再現防止・攻撃回帰42件・gate 非減少）

v3-r4 ベンチ実測で、implement 中の qwen3-coder-next が幻覚 oldString による
edit 失敗を14分半に散発させ（間に build 完走・write 成功を挟む生産的走行）、
累積25エラーで ToolErrorBudgetDetector が発動して run が abort した。
旧検出器は成功ツールコールを考慮しない単純累積で、「プロバイダ劣化スピン」
（導入動機: 559ループ・26分空転）と「弱いモデルの edit 税」を区別できない。

codex 診断に基づき単一カウンタを3つの独立した保護へ分離する:

- tool_error_burst: 進捗感知型の退行検出。成功なし連続数（既定10 — 559型は
  旧25より速く停止）、直近ウィンドウのエラー率、非 edit 同一署名反復で判定。
  弱い進捗（read/glob/grep）は緩和のみ、強い進捗（edit/write/patch/bash 成功）
  は短期カウンタとウィンドウをリセット
- edit_conflict_loop: 幻覚 oldString の専用検出。署名 = sha256(filePath+oldString)。
  同一署名3反復 → 同一セッション correction（再読込を指示）→ 再発で
  fresh-session recovery 最大1回 → さらに再発で失敗。矯正済み署名を追跡し、
  別署名の新規 conflict は自前の correction 段階から開始
- absolute_cost_limit: recovery をまたいで引き継ぐ絶対台帳（総エラー上限
  既定60、同一署名絶対反復12）。fresh session でも短期カウンタのみリセット

処遇は型付き ToolGuardFailure として client 内で決定（engine の文字列再解析なし、
needs_fix/plan への自動迂回なし）。ToolHealthStats を debugInfo に構造化して
閾値校正の材料にする。

edit の oldString/newString 本文は全経路で {sha256:先頭12,length} にマスク:
tool_use（発火時点）/ tool_result / debug ログ / ToolGuardFailure.message /
AgentResponse.error / correction 文 / provider-events.jsonl。

codex 検証5巡合格（誤 burst 再現・署名状態機械・漏えい経路網羅）