Status: Phase 0 MERGED（PR #1273・Human C-4 DONE）/ Independent Review DONE（R1 I1 ×2 + R2 I1 /
reviewed_at_sha=f8f1e8b8。phase0-migration.md§7 が正本） / Phase 0.1 CANON_HARDENING（#1275） Companion canon:taxonomy.md/harness-manifest.md/evaluation-trust-boundary.md/artifact-responsibilities.mdRole: V2 の最上位判断基準。詳細実装仕様ではなく、目的・不変原則・境界・成功条件を固定する。
ai-loop V2 は、検証可能な開発成果と、次の判断に使える Evidence を継続的に生み出し、その経験から開発システム自体を改善するための Harness である。
品質・安全性・Evidence の妥当性を守りながら、問題の観測から判断に必要な Evidence を得るまでの時間、回避可能な確認・復旧負担、失敗の影響と再発を減らす。Time to Learning の短縮だけを目的に、必要な観測を打ち切ったり、成功条件を緩めたりしない。
本文で使う語を次のとおり定義する。
AI が開発を実行し、その結果を検証し、失敗と成功を振り返り、自らの Skill / Agent / Flow / Verifier を改善し、その改善が本当に有効かを独立検証したうえで、次の Harness version を作れる開発システムを構築する。
一言で表す。
AI builds software. AI also improves the system that builds software.
AI側の探索・実装・レビュー・検証能力を増やしても、その複雑さをそのままHumanの読解・確認量へ転嫁しない。
Machine complexity should not become Human complexity.
Human-facing artifact / handoff / escalation は、既存のEvidence・state・decisionを次の原則でprojectionする。
ここでいうcompressionはfinding・Evidence・不確実性を消すことではない。Humanが最初に読む面を判断対象へ絞り、完全な情報とprovenanceへ辿れる状態を維持する。必要なHuman review / approvalはリスクに応じて維持し、Human Attentionの削減自体を目的にしない。
Projection != Judgment
Compression != Suppression
Summary != SSoT
Human Attention削減のために新しいJudge / Gate / authoritative artifactを作ることを既定としない。各layerは既存のSSoTからHuman-facing projectionを生成し、Human-owned authority（§3 / §15）を維持する。
この原則のcross-layer rolloutは #1343、canon gap analysisは #1344、共通measurement contractは #1349で追跡する。River Reviewの先行実証（s977043/river-review#2368）をEvidenceとして利用する。
ただし、自己進化と実行中の自己変更は分離する。
Self-Evolution != Live Self-Modification
Harness N
-> Delivery Run
-> Evidence
-> Retrospective
-> Improvement Candidate
-> Experiment / Evaluation / Canary
-> Promotion Ready
-> Human Decision
-> Harness N+1
1 Task を MERGE_READY へ収束させる。
Request
-> Bounded Discovery (adaptive depth; may be minimal)
- Goal / Actor / Problem / Job
- Assumptions / Constraints / Unknowns
- Evidence / Questions
- Requirement candidates
-> Plan
-> Plan Verification
- Requirements Review
- Design Review
- Technical / Feasibility Review
- Research Evidence Review (when required)
-> Plan Gate
-> Execute -> Verify -> Diagnose -> Repair / Replan -> Verify
-> PR Convergence -> MERGE_READY
Initial Plan も Plan Verification を通る。Replan 時だけ Plan Review する構造にしない（§9）。
Bounded Discovery は全 Task に同じ ceremony を要求しない。depth はコード変更量ではなく、少なくとも uncertainty / impact / irreversibility / evidence quality を材料に調整する。単純で十分に既知な変更は Goal / Constraints / Acceptance Criteria の確認で足りる一方、曖昧・高影響・不可逆な変更では As-Is / stakeholder evidence / alternatives / requirement mapping まで広げてよい。RDRA は利用可能な手段の 1 つであり、必須フレームワークにはしない。
AI は Discovery で正解の Requirement を創作する主体ではないが、PBI / Requirement candidate の作成者にはなれる。AI は user feedback / Issue / RunEvidence / FailureRecord / operational observation / stakeholder input などから hypothesis generation / question generation / evidence-gap detection / structuring を行い、pbi-input.md を新規作成・更新してよい。PBI の信頼性は author identity ではなく、provenance / Evidence / uncertainty / policy によって判断する。
AI-generated PBI は claim provenance を失ってはならない。少なくとも問題設定に使う material claim を observed（artifact / measurement / verifier で直接確認）、reported（Human / external source から受領した未独立検証の報告）、inferred（source から導出した仮説・解釈）に分ける。要約・再記述・別 Agent による再生成は source の独立性を増やさず、inferred を observed に昇格させない。PBI 自身や、その PBI から生成した Plan / Review を upstream claim の独立 Evidence として循環参照しない。
pbi-input.md を Goal / Problem / Requirement semantics の authority とするが、これは Human-authored を意味しない。Author / Evidence / Authority / Approval を分離する。AI-generated PBI でも、根拠が追跡可能で必要な policy / review を満たせば authoritative input になりうる。Human は stakeholder input、意味・優先順位・trade-off、high-impact / irreversible / conflicting requirements など policy が Human decision を要求する箇所の authority を保持する。低リスクで既知の変更に一律の Human authoring / interview / review を要求しない。Evidence が不足する場合は Unknown として残し、もっともらしい Requirement で埋めない。accepted Requirement は、author ではなく evidence / explicit decision / policy rule のどれを acceptance basis としたかを辿れるようにする。
Discovery の結果は既存 Plan Package に保持し、Goal / Problem -> Requirement -> Acceptance Criteria -> Plan decision -> Work Item / Task (when applicable) -> Verification / Evidence の Traceability Chain を既存 ID / ref で構成する。新しい Lifecycle State / Gate / top-level artifact / mutable graph store をこのためだけに追加しない。
AI が feedback / Evidence から PBI を materialize する場合、PBI Admission と PBI Materialization を分離する。
signal
-> Admission: materialize | no_action | discover_more
-> materialize の場合のみ
Materialization: update_existing | link_only | create_new
Admission は「この signal を PBI work として扱うか」の判断であり、Materialization は「PBI work として扱うと決めた signal を既存 work へどう接続するか」の判断である。両者を 1 enum / 1 authority に混ぜない。
materialize: PBI work として materialization に進むno_action: 現時点で新しい PBI work を materialize しないという proposal。source Issue / PBI の close / resolve / suppress authority を持たないdiscover_more: Evidence / semantic certainty が不足しているため Bounded Discovery に戻す。Human review 固定を意味せず、既存 policy に従って追加 Evidence / question / verification を行うreported / inferred / ambiguous な signal を、根拠なく no_action に落として false negative を隠さない。Harness-target signal の Admission は Delivery 側に第 2 の Evolution trigger を作らず、既存 #874 / #869 の Candidate / Evolution boundary に委譲する。
Admission を通過した PBI work には Reuse / Update Before Create を適用する。新規 PBI を作る前に、既存の open Issue / PBI を source refs と Goal / Problem / AC の意味で照合し、update_existing / link_only / create_new のいずれかを選ぶ。類似しているという LLM 判断だけで別 PBI を自動 close / merge しない。既存 PBI が Plan / approval と binding 済みで Goal / Requirement / AC の semantic change が必要なら、重複解消として silent update せず §9 の Replan / policy boundary に従う。
AI-generated PBI の 作成時点と適用時点を分離する。Active Run 中に feedback から PBI を作成してよいが、PBI は application timing と target layer を別軸で扱う。
follow_up | replan_currentdelivery | harnessfollow_up は future Run 向けであり current LoopContract / Plan / Harness identity を変更しない。replan_current は current delivery の Goal / Requirement / AC を変更する場合にだけ使い、§9 の Replan -> Plan Verification -> Plan Gate を通す。
target layer = harness は North Star §10 のため 常に follow_up とし、Active Run の Harness identity を変更する replan_current は許可しない。Harness / Skill / Agent / Flow / Verifier / Routing / Eval を変更する PBI は、draft 自体は feedback から先に作成してよいが、Plan / implementation へ進む前に North Star §13–§15 / #869 の HarnessImprovementCandidate ref を持つ。PBI は Candidate contract / evaluation plan / independent evaluation を置き換えない。
Do not optimize a solution before validating the problem enough for the risk at hand.
Delivery は合意した Contract のもとで実行する。探索を支える実装では、実装の受入基準と価値仮説の学習条件を区別し、必要な観測条件と Evidence の返却先を明確にする。MERGE_READY は必須の検証・PR 収束を含む Delivery 契約全体を満たし、C-4 / merge（Human-owned）待ちで停止した終端である（taxonomy.md §3）。これは価値仮説の検証完了を意味しない（本 North Star が置く区別であり、taxonomy 側の規定ではない）。Product Discovery 全体やリリース後の観測・意思決定を V2 に内包せず、それらへ Evidence を接続する。
Run の観測・検証結果を記録し、成功・失敗・摩擦を振り返って、次の判断に再利用できる Evidence にする。観測事実、原因仮説、未確認事項を区別する。
仮説の棄却や Candidate の不採用も、妥当な Evidence に基づくなら学習として扱う。評価実験の成立と Candidate の採用可否は別であり、Evidence 不足を、評価計画（§14）の成立や採用可能と見なさない。不足の原因や観測・検証上の摩擦は、次の改善の材料として残す。
Run -> RunEvidence -> Retrospective -> Pattern / Friction / Success
Evidence から Harness 改善候補を作成・検証する。
Pattern -> Hypothesis -> Skill / Agent / Flow / Verifier Candidate
-> Experiment -> Independent Evaluation -> Canary -> Promotion Ready
ai-dev-workflow の利用者向け契約を V2 のために変更しない。
Request -> Plan -> C-1 -> C-2 -> Human C-3 -> Execute -> Verify -> PR_CREATED
V2 は ai-dev command を内側から直接チェーンすることを前提とせず、必要な既存能力を共通 primitive / adapter として利用する。Bounded Discovery は V2 内部の準備責務として扱い、この stable public contract に新しい必須 phase を追加しない。V2 は feedback / evidence から pbi-input.md を生成して既存 plan contract へ渡してよく、PBI authoring を Human-only boundary にしない。
少なくとも次は Human-owned のままとする。
AI は proposal / patch / evidence / experiment / promotion-ready PR までは作れる。不可逆な Production 適用の最終権限は Human が持つ。
PBI materialization の自律度を上げる場合でも、次の 3 つを同じ boolean / Gate にまとめない。
Evidence readiness
!= Quality acceptance
!= Mutation authorization
review_ready=true 相当の projection があっても、write / close / suppress / merge authority を暗黙に付与しない。評価器は quality metric を示してよいが、threshold が定義されていなければ PASS/FAIL を創作しない。
write-capable behavior を導入する場合、policy definition / quality acceptance / rollout activation / mutation execution を分離する。policy 文書が存在するだけで activation 済みと扱わず、byte / version drift 後に以前の activation を暗黙継承しない。
Delivery と Evolution は同じ state / gate / success condition で表現しない。
MERGE_READY へ収束C-3’ / auto approval は ai-loop の本体ではない。Autonomy / Policy profile の一選択肢として扱う。
Loop Execution != Auto Approval
最低限、次の責務を分離する。
Planner -> Builder -> Verifier -> Diagnoser -> Decision Engine
原則:
同じ Model を利用する場合でも、context / role / run を分離する。独立度は I0（same context）〜 I4（Human + machine independent evidence）で段階化し、Verifier / Gate / Policy / protected Flow の変更は通常の Prompt 変更より高い独立度を要求する（evaluation-trust-boundary.md §4）。
Worker の「完了」「PASS」等の自己申告を完了根拠にしない。報告は主張として受け取り、対象の成果物・外部状態・検証結果との対応を確認する。検証不能を「対象なし」や PASS として扱わない。
Worker -> Artifact -> Verifier -> Evidence -> Decision Engine
Worker produces artifacts. Verifier produces evidence. Gate decides whether the contract is satisfied.
Verifier は安価で決定論的なものを優先する。
決定論的 FAIL を LLM の PASS で上書きしない。
PBI Admission / Materialization の評価では、Evidence の出所を少なくとも次の class で分離し、名前だけを書き換えて trust を昇格させない。
synthetic_fixture
!= historical_replay
!= live_shadow
live_shadow に昇格しないlive-shadow の trust は「artifact が repository に存在する」だけでは成立しない。少なくとも、capture が対象 RunEvidence の finalize より前の実行文脈に属し、source / capture / RunEvidence の対応を辿れ、reviewed oracle が maker actual と別 authority で与えられる構造を持つ。
maker actual
!= reviewer expected
独立 review を主張する場合、reviewer に maker actual を先に開示して expected を決めさせない。blind review packet / separate context / separate reviewer 等の実装手段は選べるが、repository 上で別ファイルにしただけで reviewer independence を証明したことにはしない。
同様に、tracked live-shadow chain が repository に存在しても、それだけで以下を証明しない。
これらを必要とする claim は、それぞれ別の Evidence / policy / Human judgment を要求する。検証不能を PASS 側へ倒さない。
Failure を会話だけに残さない。最低限、以下を正規化する。
Observation と Cause Hypothesis を別フィールドにする。
単純な retry < N だけで継続しない。Iteration 間で最低限以下を比較する。
Run の記述は 4 軸を別フィールドで持つ（正本: taxonomy.md）。
| 軸 | 値域（最低限） |
|---|---|
| Lifecycle State | PLANNING / PLAN_VERIFYING / EXECUTING / VERIFYING / DIAGNOSING / REPAIRING / REPLANNING / PR_CONVERGING / WAITING_HUMAN / WAITING_EXTERNAL |
| Terminal Outcome | MERGE_READY / HUMAN_ESCALATED / BLOCKED |
| Stop Reason | NO_PROGRESS / REPEATED_FAILURE / OSCILLATION / BUDGET_EXHAUSTED / POLICY_DENIED / VERIFIER_UNAVAILABLE / REQUIREMENT_CONFLICT / STATE_CONFLICT / HUMAN_REJECTED |
| Policy Verdict | AUTO_APPROVED / HUMAN_REQUIRED / DENIED |
NO_PROGRESS は State ではなく Stop Reason、AUTO_APPROVED は Outcome ではなく Policy Verdict、MERGE_READY は Verdict ではなく Outcome である。
止まれることは自律性の失敗ではなく、自律性の要件である。
Verify FAIL
-> Diagnose
-> Plan valid?
YES -> Repair
NO -> Replan -> Plan Verification -> Plan Gate
Delivery の Plan / Contract に含まれる Goal / Problem / Requirement semantics / 目的 / 受入基準 / 学習条件 の変更が必要な場合は、通常の repair で暗黙に書き換えず、変更提案を明示して Replan / Plan Verification / Plan Gate を通す。判断主体と承認権限は既存の境界に従い、合格させるために条件を緩めない。
この Replan は、Evolution Candidate の実装前に固定した評価計画・採用閾値を同じ Candidate の評価中に変更する権限を与えない。評価条件そのものの変更は別 Candidate・別評価として扱い、§14 と Evaluation Trust Boundary の保護・Human-owned 規則に従う。
Plan が変更された場合、旧 Plan に束縛された verification evidence は再検証する。Initial Plan と Replan 後の Plan は同じ Plan Verification を通る（§2）。
Run 開始時に HarnessManifest（harness-manifest.md）を固定し、RunState / RunEvidence は harness_manifest_ref で束縛する。harness_version 文字列は人間向けラベルであり、同一性の根拠にしない。
Active Run 中に Skill / Agent / Flow / Verifier contract / Gate / Policy / Budget policy を暗黙変更しない。
改善は Harness N+1 Candidate として別 Task / Branch / Run で検証する。
Evolution Loop は次を正式な改善対象とする。
Skill / Agent / Flow / Verifier は既存 Component の更新だけでなく新規作成も扱う。
正式な operation:
ただし Reuse Before Create を原則とする。
Improvement Need
-> Existing Harness Search
-> existing component can solve it?
YES -> REUSE / UPDATE
NO -> CREATE
Create Last.
Harness の進化を Component 数の増加と定義しない。
次も改善候補に含める。
必要に応じて MERGE / DEPRECATE / REMOVE_FROM_FLOW / SIMPLIFY を提案する。
運用で検査を追加・変更する動機は、原則として観測した事故や失敗パターンへ紐づけ、適用範囲・誤検知・維持コストも評価する。基礎的な安全境界の設置は事故の発生を待たない。
簡素化は、必要な能力・検出力・安全条件を維持できることを Evidence で確かめて採用する。読まれない警告も範囲調整・統合・廃止の検討対象とするが、Gate・Verifier の削除・緩和・適用範囲縮小の権限はいずれも §15 に従う（範囲調整・統合が適用範囲の縮小を伴う場合を含む）。
Model / Runtime の major update は、既存 Harness の前提が変わったことを示す 再評価 Trigger として扱う。能力向上そのものを、Skill / Agent / Flow / Verifier / Prompt / Context の削除・無効化・適用範囲縮小を許可する Permission にはしない。
Capability change
-> Re-evaluation trigger
!= Simplification permission
強い基盤 Model が、以前は Harness component で補っていた能力を吸収する場合がある。その可能性を検証するときは、同じ更新後 Model / Runtime / Effort と同じ task / fixture を固定し、対象 component の WITH / WITHOUT paired ablation を行う。
same updated Model / Runtime / Effort / task
├─ baseline: existing Harness WITH target component
└─ candidate: simplified Harness WITHOUT target component
↓
compare quality / safety / evidence / cost
旧 Model + component と新 Model - component の比較だけでは、Model 変更と Harness 簡素化が同時に変わるため限界寄与を帰属しない。component の material update では、同じ実行条件で旧版 baseline と candidate を比較する。
activation 未確認、paired case 不足、sample 不足、必要 Evidence の欠測がある場合は INCONCLUSIVE とし、簡素化の根拠へ昇格させない。再評価後も approval / permission / security policy、Protected Gate、Human-owned boundary は独立した authority として維持し、緩和・削除は §15 の Human Gate に従う。
Harness 変更を直接始めない。
1 Candidate = 1 Hypothesis
Candidate は最低限以下を持つ。
Harness 改善は baseline と candidate を同一 fixture / task で比較する。Model / Runtime の能力変化を契機に簡素化を評価する場合も、baseline / candidate の双方で更新後の Model / Runtime / Effort を固定する。
Same Fixture
-> Harness N baseline
-> Harness N+1 candidate
-> Compare
最低限評価する。
Candidate が実際に対象経路で発火したことを Activation Check で確認する（installed / registered / selected / fired / produced_evidence / influenced_decision の 6 段階。fired 以上を要求）。重要変更では held-out / sealed regression set を使う。
Verifier / Gate の改善では、存在や発火だけでなく、既知の欠陥を検出でき、その結果が期待した続行・停止の判断へ接続されることを確かめる。要求段階は一般則の fired 以上ではなく influenced_decision（harness-manifest.md の 6 段階定義）とする。検出力・適用範囲・誤検知も改善の評価対象とする。
評価の結果は PASS / FAIL / INCONCLUSIVE の 3 値で、evaluation plan（fixture IDs / task profile / trial count / metrics / threshold / critical regression condition）は Candidate 実装前に固定する。
Candidate cannot modify the authority that judges the candidate.
正本: evaluation-trust-boundary.md。
V2 初期目標は E4。AI による Production Harness の自動 merge は Non-goal。
初期に実験しやすい領域: Prompt / Context / Skill instruction / review rubric / test strategy。
条件付き領域: 新 Skill / 新 Agent / Agent role / Verifier 追加 / Flow stage 追加・順序変更。
Human Gate 必須: Gate・Verifier 削除、Stop / Escalation policy、Hook、Permission、Approval boundary、HO、C-4、Merge、First Principles、Gate・Verifier の緩和・適用範囲縮小（無効化 / 条件付き skip / 適用対象の縮小を含み、削除と同じ扱い）。
V2 初期実装は Stable Harness で作る。
ai-dev-workflow -> V2 Plan -> C-1 -> C-2 -> Human C-3
-> Implementation -> Verification -> PR_CREATED
Delivery V2 が検証されるまで、V2 自身を V2 で開発しない。
最低限、次を E2E で実証する。
Request -> Plan -> Plan Verify -> Execute -> Verify FAIL -> Diagnose -> Repair
-> Verify PASS -> PR -> Review finding -> Repair -> MERGE_READY
さらに:
NO_PROGRESS -> safe stop / escalation
Delivery が安定する前に Evolution を Production feedback loop として接続しない。
Development Run
-> RunEvidence
-> Retrospective
-> Pattern Detection
-> Improvement Classification
-> Skill / Agent / Flow / Verifier
-> Reuse or Create
-> Harness Candidate
-> AI Implementation
-> Independent Evaluation
-> Baseline Comparison
-> Canary
-> Promotion Ready
-> Human Merge
-> Harness N+1
Candidate 数や Component 数を KPI にしない。
主に以下を見る。
human intervention に対応。実装は scripts/ai-loop/metrics.py の human_intervention_rate）
加えて、目的に応じて次の評価軸を見る。測定定義・対象範囲は詳細の評価計画で定める。
これら 3 つは Phase 1 時点では未対応である。算出に必要な時刻フィールドは、Phase 1 で別に定義する V2 RunEvidence schema 側に持たせる（追跡: #1285）。
Legacy schema（run-evidence.schema.json）は、phase0-migration.md §2 の freeze 例外（security fix / critical bug fix / migration・compatibility support / V2 移行に必要な観測・説明の追加）を除き拡張しない。 本節が禁じるのは V2 の時刻フィールド追加を Legacy schema へ寄せることであり、freeze 例外に該当する変更まで一律に禁じるものではない（例外の判定主体・手順は同 §2）。 同 schema は artifact-responsibilities.md（docs/schemas/run-evidence.schema.json の行）および taxonomy.md（Legacy RunEvidence schema の行）で 「Legacy schema。変更しない」 と宣言されており、V2 RunEvidence schema を Phase 1 で別に定義して terminal_state → outcome の写像を持たせる方針が正本である。実装上も scripts/ai-loop/run_evidence_verify.py が同 schema を 唯一の正として必須キー・許可キーを導出しているため、拡張すると legacy 受理器と既存 fixture に波及する。
現行 legacy schema の制約そのものは以下のとおり（V2 側で時刻を持つ根拠として残す / 実測）: 時刻は started_at / completed_at の 2 つのみで、Evidence 取得時刻・判断時刻・failure 発生時刻に対応するフィールドが無く、escalation / quality_metrics を含む object は additionalProperties: false のためフィールドを足せない。
Product 側と Harness 側の学習を混同せず、V2 が直接観測できる範囲と外部から受け取る Evidence を区別する。必要な人間判断は維持し、証拠不足による聞き直し・反復確認・手動復旧の負担を減らす。承認時には Evidence・残存リスク・未解決事項を提示して判断を支える。
品質・安全性・Evidence の妥当性を速度やコストで上書きしない。
迷った場合は次の順で判断する。
自律性向上のために検証可能性を犠牲にしない。
これらへ回答できない Plan は実装へ進めない。
ai-loop V2 は、AI に無制限な自律性を与えるための仕組みではない。
AI が自律的に開発し、自分の失敗と成功を Evidence として学び、Skill・Agent・Flow・Verifier を改善し、その改善自体を検証可能・rollback 可能な Software Engineering Process として運用するための Harness である。
良い Loop は、正しく検証し、必要なら止まり、経験から次のより良い Harness を作れる。誤りを前提に、早期検知・影響限定・復旧・再発防止を可能にする。
Delivery は合意した Contract のもとで MERGE_READY まで進める。実行中の Harness は固定し、C-4・マージ・次版 Harness の本番への最終 Promotion と既存の Human-owned 境界を維持する。