PlanGate

ai-loop V2 Phase 0 — Freeze / Migration Matrix

Status: Phase 0 MERGED（PR #1273・Human C-4 DONE）/ Independent Review DONE（R1 I1 ×2 + R2 I1 / reviewed_at_sha = f8f1e8b8。§7 が正本） / Phase 0.1 CANON_HARDENING（#1275） North Star: north-star.md Baseline: Phase 0 main@9f7bac9f62dccc057be5ae58570dcb65a4acbec8 / Phase 0.1 main@1e95e8a

1. Phase 0 decision

ai-loop V2 は既存 ai-loop の追加改修として作らない。

既存 ai-loop は削除しない。実装・契約・失敗履歴を Evidence として再利用する。

2. Legacy freeze policy

Legacy ai-loop に許可する変更:

原則として Legacy ai-loop に追加しないもの:

例外を入れる場合は、V2 North Star に照らして「Legacy に入れる必要」を Plan に明示する。

判定主体と判定手順

許可・不許可の列挙だけでは、同じ変更が「security fix」とも「V2 専用 verifier の本実装」とも読める。どちらに当たるかを誰がどの手順で決めるかを次に固定する。

役割 担当 責務
分類の提案 AI（Plan 作成者） 当該変更が上記のどの許可カテゴリに当たるか、および「V2 側で実装しない理由」を Plan に明示する
例外の承認 Human（C-3 ゲート） freeze 例外の可否を裁定する。AI は自分の Plan の freeze 例外を自分で承認できない（evaluation-trust-boundary.md §1 と同じ趣旨）
適用の確認 Human（C-4） merge 時点で、実差分が承認した例外カテゴリの範囲に収まっているかを確認する

判定手順:

  1. Plan に freeze 例外の申告（対象 Legacy 資産 / 許可カテゴリ / V2 側で実装しない理由 / 範囲）を書く。
  2. Human が C-3 で可否を裁定する。分類が両解釈可能なときは不許可側（V2 で実装する）を既定とする（fail-closed）。
  3. 承認した例外カテゴリと範囲を、当該 Plan と本 §2 の実例表に残す。

判定不能・未申告の変更は Legacy に入れない。

freeze 例外の承認は autonomous APPROVE の対象にしない

上表の「例外の承認 = Human（C-3 ゲート）」は、AI が C-3 を自己承認する経路を含まない。.claude/rules/working-context.md の C-3 Autonomous APPROVE（自律実行指示下で、mode が standard 以下かつ Hardening Override 対象パスを含まない場合に AI が C-3 を自己承認できる規定）は、本 §2 の freeze 例外には適用しない。

実例: #916

論点 判定
対象 Legacy C-3’ arbiter への carve-out 機械層配線（evaluation-trust-boundary.md §2）
許可カテゴリ security fix / migration・compatibility support。arbiter が自分の判定基盤を auto-approve 経路で改変しうる構造的盲点を塞ぐため
不許可カテゴリに当たらない理由 配線するのは Legacy arbiter の既存 escalate 経路への carve-out 適用であり、V2 の Policy Gate / Evaluation Trust Boundary の本実装ではない。V2 側は同じ protected surface 定義を再利用するだけで、Legacy 実装を V2 正本にしない
承認 本 §2 の判定手順に従い Human C-3 で裁定する（未裁定のまま着手しない）

taxonomy.md §7 の「C-3’ arbiter の Legacy 実装は変更しない」は V2 taxonomy を Legacy 実装へ逆輸入しない（語彙・state 機械の書き換えをしない）という意味であり、本 §2 が定める freeze 例外（security fix 等）を禁じるものではない。2 つの記述はこの限定で読む。

3. Classification rule

Classification Meaning
KEEP V2 の中核要件として概念・契約を継承する
ADAPT 問題設定・Evidence は継承するが V2 責務へ合わせ再設計する
SUPERSEDE 現行 ai-loop 固有構造を前提としており、V2 の新契約で置き換える
DEFER 有用だが V2 Delivery MVP の critical path 外。後段へ送る
LEGACY EVIDENCE 完了済み/既存実装を新正本にせず、fixture・pattern・失敗履歴として再利用する

SUPERSEDE は即 close を意味しない。V2 側の replacement が main に入るまでは回帰・移行の参照元として保持する。

4. Issue migration matrix

V2 Core / Delivery critical path

Issue Class V2 treatment
#870 ai-loop vNext EPIC ADAPT → REBASELINED（Phase 0.1） V2 親 EPIC として本文を全面 rebaseline。Verifier-driven Delivery + Evidence-driven Evolution + Self-Evolving Harness を中核、C-3’ は optional autonomy / policy profile。旧本文は Legacy Evidence として Issue 内に保持
#894 Loop Control Contract KEEP PROBLEM / ADAPT CONTRACT Verifier hierarchy / budget / progress / stop の問題設定は KEEP。単一 LoopControlContract は LoopContract / RunState / VerificationResult / FailureRecord / Decision Engine / RunEvidence へ分解（artifact-responsibilities.md §2）
#1025 Durable Run State KEEP + CONCURRENCY HARDENING RunState / intent-receipt / resume を V2 core として利用。revision CAS / concurrent resume / STATE_CONFLICT を追加（同 §4）
#874 RunEvidence KEEP + REBASELINE producer contract は KEEP。harness_version → harness_manifest_ref、RunEvidence = deterministic event projection、非完了 Run も Evolution input（同 §3）
#916 arbiter self-protection KEEP → Evaluation Trust Boundary へ昇格 局所 carve-out から Candidate cannot modify the authority that judges the candidate の Legacy 実例へ（evaluation-trust-boundary.md §2）
#1029 rollback execution ADAPT C-3’ 固有 rollback としてではなく V2 stop / recovery / external decision rollback の pattern として再設計
#1241 task_id portability KEEP V2 Core の portability / external task identity 契約へ取り込む。TASK-XXXX 固定を V2 正本にしない

Verification / Eval

Issue Class V2 treatment
#908 Run / Trajectory Eval KEEP Delivery/Evolution 評価の共通 Eval profile へ
#909 Executable Regression Set KEEP V2 regression / held-out / sealed eval の土台へ
#910 grader calibration / drift KEEP independent model reviewer の校正・drift 監視へ
#1124 verifier detection power KEEP PASS 数ではなく検出力を測る V2 verifier quality へ接続

Evolution

Issue Class V2 treatment
#869 Run Retrospective / Harness Evolution KEEP + REBASELINE V2 Evolution Loop の中核。Skill / Agent / Flow / Verifier の CREATE / UPDATE / SPLIT / MERGE / DEPRECATE を正式対象化。Legacy inner-loop / AUTO_APPROVED 中心の表現と V2 canonical flow を区別（Promotion Decision に INCONCLUSIVE）
#811 Memory Promotion Gate ADAPT / SUB-GATE Promotion 対象が Rule/Skill等の場合の sub-gate。V2 Evolution 全体の owner にはしない

Autonomy / policy

Issue Class V2 treatment
#1035 HOITL → HOTL ladder ADAPT 自律度 rollout / measurement は継承。ただし V2 Core と C-3’ eligibility を分離し、Delivery E2E 完成後に再baseline
#1059 changed_files / size_ok SUPERSEDE current lite/C-3’ eligibility の構造問題。V2 では autonomy profile の問題として扱い、Delivery Loop の成立条件にしない
#1197 no-task startup circularity SUPERSEDE + REGRESSION V2 Plan-first bootstrap が解消すべき構造的回帰 fixture として保持。旧経路の局所修正を V2 core に持ち込まない

Adjacent / distribution / harness prerequisites

Issue Class V2 treatment
#1232 ai-dev plugin resources DEFER / SEPARATE ai-dev Stable の配布品質問題。V2 のために ai-dev public contract を変更しない
#1144 enforcement distribution DEFER / PREREQUISITE V2 plugin E2E 前に必要。ただし Delivery state machine の設計と分離
#1135 AI-owned lane / hook friction DEFER / INPUT Harness usability / governance friction の Evidence として利用。V2 core contractへ直結させない
#911 Intent-to-Execution Context Contract ADAPT / DEFER Context boundary と handoff の設計入力。Delivery MVP の critical path から外し、Phase 1 Architecture で gap analysis

Completed legacy assets

Asset Class V2 treatment
#871〜#873 LEGACY EVIDENCE Plan-first / C-3’ binding / PR convergence の成功・失敗 pattern を再利用。V2 正本にはしない
#917 LEGACY EVIDENCE GitHub collector / intent-receipt / reconciler の pattern を adapter 設計へ再利用

5. Document / code asset migration

KEEP as philosophy / evidence

These are inputs to V2 design; they are not automatically V2 canon.

ADAPT

SUPERSEDE as V2 identity

PRESERVE / DO NOT MUTATE during Phase 0

6. V2 artifact budget

Phase 1 では正本 artifact を無制限に増やさない。初期候補を以下に限定する。

  1. LoopContract
  2. RunState（Phase 0.1: harness_manifest_ref を additive に追加）
  3. VerificationResult
  4. FailureRecord
  5. RunEvidence（Phase 0.1: harness_manifest_ref を additive に追加。event projection として再定義）
  6. HarnessImprovementCandidate（Phase 0.1: evaluation plan digest を additive に追加）
  7. HarnessExperimentResult（Phase 0.1: baseline_manifest_ref / candidate_manifest_ref を additive に追加）
  8. PromotionDecision
  9. HarnessManifest（Phase 0.1 で追加。独立 artifact とする根拠は harness-manifest.md §5）
  10. RunEvent stream（Phase 0.1 で追加。artifact-responsibilities.md §3 が「正本は event stream。RunEvidence は再生成可能なキャッシュ」と宣言しており、budget 外に置くと Phase 1 が正本を budget 外 artifact として定義せざるを得なくなるため budget に含める。V2 RunEvent 型の定義は Phase 1。Legacy schema へ V2 event 型を追加しない点は同 §3）

各 artifact の責務境界は artifact-responsibilities.md。新 artifact を追加する Plan は、既存 artifact へ additive に表現できない理由を North Star review で説明する。

7. Phase 0 exit criteria

独立レビュー記録の要求（reviewed_at_sha）

canon は Phase 0 baseline 以降も更新されるため、「独立レビュー済み」は どの SHA を見たレビューかと対で記録しないと意味を持たない（本節の Baseline は作成時 baseline であってレビュー済み SHA ではない）。

Phase 0.1 exit criteria（#1275 / Canon Hardening）

各項目の根拠は、その項目が何によって達成されるかで書き分ける（docs の新規作成は docs PR のマージで達成できるが、GitHub 上の Issue body 更新は docs PR のマージでは原理的に達成できない）。

Phase 0 の独立レビューと Phase 0.1 の全項目が満たされるまで Phase 1 実装を開始しない。Phase 0.1 の PR は MERGE_READY で停止し、Phase 1 へ自動的に進まない。

Human 判断事項（2026-09-10 決着 / 選択肢 (b) を採用）

canon docs 自体に要求する Independence Level を I1 のままにするか、I4 へ引き上げるか。

決定（2026-09-10 / Human）

選択肢 (b) を採用する。 canon 7 本は「それを強制する実行系をまだ持たない仕様文書」であることを理由に、独立レビュー要求 I1 を evaluation-trust-boundary.md §3（Evaluation Harness そのものの変更は I4 でのみ採用する）の 明示的な例外として認める。

なぜ現時点で例外が成り立つか（例外の根拠）:

I4 移行条件（例外が切れる条件・判定可能）

M-1 / M-2 / M-3 の いずれか 1 つでも baseline から動いた時点で本例外は失効し、以後の canon 7 本の規定変更は I4（Human + machine independent evidence）を要求する。「実装が入ったら」という主観判定ではなく、下記コマンドの出力が baseline と一致するか否かで測る。

ID 条件（何が入ったら例外が切れるか） baseline（9f1b9f63 実測）
M-1 canon 由来の schema が schemas/ に入る、または既存 schema に canon 語彙が入る 出力なし / ヒット 0 件
M-2 V2 実行系の namespace が repo に出現する（scripts/ai-loop-v2 / bin/ai-loop-v2） 出力なし
M-3 canon 固有語彙が実行系ファイル（scripts / bin / schemas / .github/workflows）に現れる 下記 4 ファイル（Legacy 側の既存実装。完全一致で比較する）

判定コマンド（3 条件を一括で測る）:

V='HarnessManifest|harness_manifest|harness_id|distribution_digest|protected_surfaces'
V="$V"'|independence_level|LoopContract|paired_replay|meta_verifier|promotion_evaluat'
V="$V"'|carve_out|sealed_fixture'

echo "== M-1 =="
ls schemas/ | grep -Ei 'harness|loop-contract|run-state|runstate' || echo "(none)"
git grep -liE "$V" -- schemas || echo "(none)"

echo "== M-2 =="
ls -d scripts/ai-loop-v2 bin/ai-loop-v2 2>/dev/null || echo "(none)"

echo "== M-3 =="
git grep -liE "$V" -- scripts bin .github/workflows | sort

M-3 の baseline（9f1b9f63 実測。この 4 行と完全一致すれば未失効）:

scripts/ai-loop/corpus_hash.py
scripts/ai-loop/run_evidence.py
scripts/ai-loop/test_corpus_hash.py
scripts/ai-loop/test_run_evidence.py

検出力の実証（変異注入 / 独立レビュー I1 の指摘 1 を受けて是正）: 是正前の語彙は case-sensitive かつ harness_manifest_ref / PROTECTED_SURFACES / build_harness_manifest() / paired_replay() を取りこぼし、Phase 1 の実装が 入っても失効しない状態だった（変異注入 6 本中 4 本が未検出）。是正後は -i と 語彙拡張により 7 本すべてを検出し、negative control（def main(): / import json / manifest = load()）は 0 件で誤検出しない。

carve_out を語彙へ加えたのは、#916（判定基盤 carve-out の arbiter 機械強制）が 本例外を最も切るべき変更でありながら、旧語彙では素通りしていたためである。

判定規則:

経緯（決着前の記録・そのまま保存する）

以下は決着前（2026-09-10 より前）の記述であり、上記「決定」に置き換わっている。当時の論点を追えるように改変せず残す。

8. Next phase

Phase 1 は実装ではなく V2 Architecture / Contract design から開始する。

最初に決めるもの:

Evolution 実装は Delivery E2E (FAIL -> Diagnose -> Repair -> PASS -> MERGE_READY + NO_PROGRESS -> STOP) の成立後に開始する。

This site is open source. Improve this page.