ai-loop-cycle

execution-runbook.md に定義された 1 サイクル（変更対象ファイル取得 → W チェック → arbiter.py 裁定 → record 保存 → 分岐後の行動）を 実行するための手順スキル。判定ロジック・provenance スキーマの正本は runbook 側にあり、本スキルは それらを実行するための 委託プロンプト定型 と 手順の要約 のみを持つ（二重定義しない）。

前提

• C-1 PASS・C-2 完了済みであること（execution-runbook.md §2 前提）。 本サイクルは C-3' ゲートの位置づけであり、C-1/C-2 未完了の変更には使わない。 この C-1 の実施結果（PASS）を Step 1 の入力 gates.c1 にそのまま渡す（#780 Slice B）。
• 対象は lite 帯候補の変更（lite-criteria.md §2 の 4 軸を満たしうる変更）。high-risk / critical 相当や boundary=touches-HO が明らかな変更には使わない （使っても flow フェーズで即 human escalate になる）。
• 適用制限（Phase 1 rollout eligibility）は rollout-policy.md を正本とする （導入先適用の前提 2 条件 = ho-paths の導入先確定 + LoopSpec scope.allowed_paths 宣言）。 恒久定義（責務・terminal state・C-3'/Human C-3 経路）の単一正本は 00_concept.md。本サイクルは PlanGate 本番フロー （bin/plangate・scripts/hooks/・WF-00〜07 の Human C-3）からは呼ばれない（不変）。

Step 0: breakdown-gate による粒度判定（#780 Slice B）

breakdown-gate スキルでタスク粒度を判定する （理想 / 許容 / 分割必須の 3 段階）。判定結果を gates.breakdown へ変換する:

• 理想 / 許容 → "pass"
• 分割必須 → "pass" 以外の値（例 "split-suggested"）。arbiter は priority 1.7 で human escalate する（分割してから再度サイクルへ）

Step 1: 入力の組み立て

changed_files を決定する:

• 計画時（exec 前の C-3' 裁定）: plan の Files to Touch を使う
• 再裁定時（実装後・PR 前の再確認）: git diff --name-only <base>...HEAD の実差分を使う

lite 4 軸（lite-criteria.md §2）を それぞれ根拠つきで宣言する。いずれかの軸が判定不能なら false（AC-8 安全側、虚偽宣言禁止）。

• size_ok: 変更規模が light 相当以下か（ファイル数 1〜2 目安）。申告するが、 arbiter が changed_files の実ファイル数で機械検証する（SIZE_OK_MAX_FILES=2。 実ファイル数が 2 を超えて size_ok=true を申告すると priority 1.9 で human escalate。#780 Slice C）
• no_new_design: 新規設計がないか（既存構造の枠内か）
• follows_pattern: 既存パターンを踏襲しているか（ミラー実装か）
• reversible: 可逆か（git revert 一発等、機械的な巻き戻し手順があるか）

class は merge を含む変更なら "merge"（即 human escalate）、含まなければ "no-merge"。 target_sha は対象コミットの SHA。allowed_paths は LoopSpec の scope.allowed_paths 宣言をそのまま渡す（#809）。

gates（任意・#780 Slice B）は plan 品質ゲート（priority 1.7）の入力。Step 0 （breakdown-gate スキルで粒度判定）の verdict を gates.breakdown に （理想/許容 → "pass"、分割必須 → それ以外の値、例 "split-suggested"。 "pass" 以外はすべて未充足扱い）、Step 1（C-1 実施結果）を gates.c1 に （"PASS" のみ通過。FAIL/未実施はそれ以外の値）設定する。gates 自体を 省略した場合も入力エラーにはならないが、priority 1.7 で human escalate に 倒れる（後方互換・安全側。以前の auto-approve 経路を壊さないためには gates を両方 "PASS"/"pass" で渡す必要がある）。

run（任意）は run_id（run-NNN 連番）・round_index（初回呼び出し=1、再試行ごとに +1。1 起点。metrics は round_index==1 を初回 sentinel に first_pass 判定するため 0 起点不可）・task_id（対象 PBI）を刻む。省略可だが、省略すると metrics 集計対象外（legacy）になる。

production / plan_package（任意・TASK-0872）: Plan-first 正式入口（ai-loop run TASK-XXXX）から開始した production run では両方を必ず入力に含める（この入口は /ai-loop-workflow の引数仕様であり、bin/plangate に ai-loop サブコマンドは存在しない — plangate ai-loop run … は失敗する。CLI 入口を設けるか否かは issue #982 で未決）。plan_package.py（arbiter.py と同ディレクトリ）で Plan Package（pbi-input / plan / todo / test-cases + C-1/C-2 evidence）の presence・evidence 判定・hash を検証して plan_package ブロックを組み立て、production: true を宣言する。production: true で plan_package が欠落・構造不正なら priority 1.6 で escalate、reviewer snapshot 三つ組不一致・source_sha != target_sha は priority 1.65 で blocked（フィールド契約・stale 規則・LoopSpec 派生マッピングの正本 = c3-prime-contract.md）。LoopSpec は同モジュールの derive_loopspec() で Plan Package から決定論派生する（手入力しない）。非 production の PoC 実験 run では両フィールドとも省略可（既存挙動不変・additive）。

入力 JSON の例:

{
  "changed_files": ["docs/workflows/ai-loop/example.md"],
  "allowed_paths": ["docs/workflows/ai-loop/example.md"],
  "lite": {
    "size_ok": true,
    "no_new_design": true,
    "follows_pattern": true,
    "reversible": true
  },
  "class": "no-merge",
  "verdicts": {
    "model_a": "approve",
    "model_b": "approve",
    "reject_category": null,
    "model_c": null,
    "model_d": null
  },
  "target_sha": "abc1234",
  "gates": {
    "c1": "PASS",
    "breakdown": "pass"
  },
  "run": {
    "run_id": "run-022",
    "round_index": 1,
    "task_id": "TASK-XXXX"
  }
}

Step 2: W チェック（サブエージェント 2 体・独立並列）

Model A / Model B を Agent ツールで 独立に（相手の結論を見せずに）並列起動する。 返答は verdict / reject_category（reject 時のみ）/ 理由 の 3 行 raw 指定で受け取る。

Model A（順方向・設計妥当性）委託プロンプト定型

対象: <changed_files>（target_sha: <target_sha>）
役割: 変更が「正しく作られているか」を検証する。
観点: 設計妥当性・受入基準（AC）網羅・スコープ整合。計画中の『検証済み』申告には**証跡（実行出力の貼付）**があるか確認し、なければ未検証として扱う。
他モデルの結論は見せない・参照しない。

出力形式（常に3行、raw）:
verdict: approve | reject
reject_category: none (approve時) | ho_path_contact | permission | irreversible |
  security_break | public_api | data_integrity | migration | auth_change |
  logic | performance | test_shortage | documentation | format | naming (reject時)
理由: <1〜3文>

Model B（逆方向・adversarial）委託プロンプト定型

対象: <changed_files>（target_sha: <target_sha>）
役割: 変更が「どう壊れるか」を検証する（adversarial）。
観点: 失敗モード・境界値・悪用経路・想定外の入力。加えて、LoopSpec の external_sources に列挙された出典について、memory 書込物（decision record・plan-memory・frictions・run 記録への追記分）の diff を対象に、当該出典の内容がコピーされている箇所を探し、出典（URL / issue・PR 番号）の併記がない転記があれば違反として指摘する。検出できるのは逐語（高一致率）コピーのみ — 言い換え転記・provenance の真偽は判別できず maker の誠実申告に依存する（限界の自己開示）。
他モデルの結論は見せない・参照しない。

出力形式（常に3行、raw）:
verdict: approve | reject
reject_category: none (approve時) | ho_path_contact | permission | irreversible |
  security_break | public_api | data_integrity | migration | auth_change |
  logic | performance | test_shortage | documentation | format | naming (reject時)
理由: <1〜3文>

reject_category は flow-detect.md §3.2.1 のカテゴリマッピング表に照合可能な文字列で記録する。一致しないカテゴリは分類器側で critical （human escalate）にフォールバックされる。

reject_category は enum の英小文字値をそのまま（verbatim）返させる。和訳・言い換え・自由記述は禁止（例: 『ロジック変更』ではなく logic）。非一致は分類器が critical 扱いになる（安全側）ため裁定は壊れないが、意図しない escalate を生む。

Step 3: arbiter.py へ入力し裁定を得る

python3 scripts/ai-loop/arbiter.py --input /path/to/input.json
# または stdin 経由:
echo '{...}' | python3 scripts/ai-loop/arbiter.py

分岐表・severity 分類・優先順位ロジックの正本は execution-runbook.md §2(5) および decision-table.md。本スキルはこれを 再定義しない。

Step 4: record の保存

mkdir -p docs/working/ai-loop-runs
python3 scripts/ai-loop/arbiter.py --input /path/to/input.json \
  > "docs/working/ai-loop-runs/$(date -u +%Y%m%dT%H%M%SZ)-$(git rev-parse --short HEAD).json"

• AUTO_APPROVED の record のみ provenance 刻印（正本）
• HUMAN_ESCALATED / BLOCKED の record は audit record（暫定） （execution-runbook.md §2(4) 注記）

Step 5: 分岐後の行動

• exit 0（AUTO_APPROVED）: exec → 強化セルフレビュー （diff-audit スキル全観点 + plan-review-readiness-gate.md §7/§8） → PR 作成 → CI/AI レビュー指摘対応ループ（pr-watch 相当、MERGE_READY まで）
• exit 2（HUMAN_ESCALATED）: 停止して人間へ。w_check / boundary_check / lite_check の 内容を提示し、人間の判断を仰ぐ。AI が自己解決してはならない
• exit 3（BLOCKED）: 当該変更を採用しない。理由を audit record に記録して終了

• severity=minor/low の不一致のみ、Model C（セキュリティ・認証・権限観点）/ Model D（後方互換・データ整合観点）の委託プロンプト定型で再裁定する （flow-detect.md §3.3）。 委託プロンプトは Model A/B と同じ 3 行 raw 形式・独立起動を踏襲し、観点のみ以下に差し替える:

  • Model C: 「セキュリティ・認証・権限の観点で、この変更が悪用・権限昇格・認証バイパスを 許さないかを検証する」
  • Model D: 「後方互換性・データ整合性の観点で、この変更が既存の契約やデータ状態を 壊さないかを検証する」

  C/D の verdict を得たら、Step 1 の入力 JSON の verdicts.model_c / verdicts.model_d に設定し（reject_category は Model B のものを保持）、 arbiter.py を再実行する（Step 3〜4 を繰り返す）。C/D 裁定を経た record には w_check.severity / w_check.model_c / w_check.model_d が刻印される （decision-table.md §5）。

Step 5.5: exec 差分への rubric grader

AUTO_APPROVED → exec 完了後・PR 作成前に、maker と独立の sonnet サブエージェント （grader）へ exec 差分を委託する（W チェックと同じ maker≠grader・独立文脈方式）。 入力 = maker 差分 + 計画の Goal/確定文言。

rubric 5 項目（review-principles §2 からの docs-run 翻訳）

以下の表は maker がそのまま SKILL.md に転記する確定版（Round 2 改訂 1）。 定義の正本は review-principles.md §2 のままで、 本表はそれを再定義せず docs-run に適用可能な fail 条件へ翻訳したものである。

（パフォーマンス観点は docs-run では該当稀のため基準 1 に「実行例の到達性」として包含。 5 観点との対応は各行に明記し重複定義しない — 定義の正本は review-principles §2 のまま）

grader 委託プロンプト定型（W チェック定型の形式踏襲）

対象: <changed_files>（maker 差分）
役割: この差分を上記 rubric 5 項目で採点する。
計画: <計画 Goal / 確定文言>
観点: rubric 5 項目（本節の表）。各項目を pass/fail で判定する。

出力形式（常に3行、raw）:
verdict: pass | fail
failed_criteria: <fail とした項目番号を列挙（例: 2,4） or なし>
feedback: <1〜3文>

判定ブロック（上記 3 行）に続けて、基準ごとの証跡ブロックを別掲する（行数自由・ 判定ブロックの 3 行 raw 形式とは別領域）:

• fail とする基準ごとに、差分からの引用（行）を必須添付する。引用のない fail は無効 とし、maker は再試行前に grader へ差し戻せる
• pass にも基準ごとに 1 行の根拠を証跡ブロックへ書く（全 5 行。「問題なし」のみは不可）
• feedback: 行自体は 1 行に収める（複数論点はセミコロン区切り。詳細は証跡ブロックへ）

再試行ループ

• verdict: fail → feedback（引用込み）を添えて maker に再試行を委託する。上限 2 回
• 上限超過 → HUMAN_ESCALATED として扱い、grader の全出力（引用込み）を人間へ提示 （false-fail 連鎖を人間が判断可能にする）
• grader 出力は decision record と同様、run 記録へ全文貼付する（監査可能性）

Step 6: RunEvidence + passive PBI live-shadow capture（shadow-only）

terminal RunEvidence が concrete 40-hex final_head_sha を持つ Evidence 発行時に、 repository-visible な observed signal が実際に存在する場合だけ passive capture を追加してよい。 signal が無い run にダミー signal / capture を作ってはならない。

observed repository source
        ↓
normalized admission signal
        ↓
scripts/ai-loop/pbi_materializer.py --capture-signal
        ↓
passive capture artifact
        ↓
scripts/ai-loop/run_evidence.py --evidence-ref <source_ref> --evidence-ref <capture_ref>
        ↓
RunEvidence
        ↓
independent review / live-shadow evaluation

6.1 capture（RunEvidence finalize 前）

pbi_materializer.py --capture-signal は stdout-only。保存先は呼び出し側が repo 相対 path として決める。 captured_at は run の started_at..completed_at 内、runtime_head_sha は後続 RunEvidence の final_head_sha と一致させる。

python3 scripts/ai-loop/pbi_materializer.py \
  --capture-signal "<normalized-signal.json>" \
  --capture-task-id "TASK-XXXX" \
  --capture-run-id "<run-id>" \
  --captured-at "<timezone-aware RFC3339>" \
  --runtime-head-sha "<40-hex HEAD>" \
  --capture-ref "<repo-relative capture artifact ref>" \
  --format json \
  > "<capture artifact path>"

normalized signal の source_ref は capture artifact 自身ではなく、実在する repository-visible upstream artifact （feedback snapshot / Issue snapshot / delivery record / failure evidence 等）を指すこと。外部URLや一時的なchat本文だけを live evidenceとして扱わず、まずrepo-visible evidenceへmaterializeしてから参照する。raw transcript / hidden CoT を signal に入れない。

6.2 RunEvidence へ束縛

通常の scripts/ai-loop/run_evidence.py 呼び出しに、upstream source と capture artifact の 2 ref を --evidence-ref で追加する。

--evidence-ref <signal.source_ref>
--evidence-ref <capture_ref>

既存 RunEvidence producer / verifier の terminal-state・schema・privacy 契約は変更しない。 capture のために terminal decision / final_head_sha / completed_at を書き換えてはならない。

6.3 capture 後の扱い

• capture 成功だけでは live_shadow 評価成立ではない。RunEvidence 保存後に capture_ref + run_evidence_ref binding 検証が必要。
• oracle / expected decision は capture agent が自動付与せず、独立 reviewer / evaluator の review artifact を後段で接続する。
• final_head_sha="unavailable" の run（典型例: delivery record を持たない一部の BLOCKED）では passive live capture を作らず、live-shadow evidence として数えない。source_sha / target_sha を代用しない。
• capture 失敗は既存 terminal decision を変更しないが、live-shadow evidence として数えない。
• historical/synthetic case を live と再ラベルしない。
• no_action は source Issue/PBI を close / suppress する authority を持たない。
• 本 Step は shadow Evidence 収集のみで、PBI write / close / merge / Harness live mutation を行わない。

6.4 Evidence collector（実runでの推奨経路）

実runでは primitive の stdout を手作業で配置せず、同梱 collector を使って capture -> blind review packet -> reviewed admission case を create-or-reuse-identical で保存する。

source artifact
  -> collector capture
  -> RunEvidence finalize（source_ref + capture_ref を evidence_refs へ）
  -> collector packet
  -> independent reviewer が oracle artifact を別途作成
  -> collector case
  -> pbi_materializer --eval-admission-batch

capture:

python3 scripts/ai-loop/pbi_live_shadow_collector.py \
  --repo-root "<repo-root>" capture \
  --signal "<normalized-signal.json>" \
  --task-id "TASK-XXXX" \
  --run-id "<run-id>" \
  --captured-at "<timezone-aware RFC3339>" \
  --runtime-head-sha "<40-hex final HEAD>" \
  --capture-ref "docs/working/TASK-XXXX/evidence/pbi-live-shadow/<run-id>/capture.json"

RunEvidence 保存後:

python3 scripts/ai-loop/pbi_live_shadow_collector.py \
  --repo-root "<repo-root>" packet \
  --capture-ref "docs/working/TASK-XXXX/evidence/pbi-live-shadow/<run-id>/capture.json" \
  --run-evidence-ref "docs/working/TASK-XXXX/evidence/pbi-live-shadow/<run-id>/run-evidence.json" \
  --packet-ref "docs/working/TASK-XXXX/evidence/pbi-live-shadow/<run-id>/review-packet.json"

review packet は maker の actual decision を含まない。Reviewer は blind_review_source_ref の upstream source から expected admission decision を決め、oracle を 別artifact として作る。 collector は reviewer identity / independence を自己証明しない。 oracle artifact は同じ TASK-XXXX/evidence/pbi-live-shadow/<run-id>/ 配下へ保存し、 raw transcript / hidden CoT / session log 等の privacy-forbidden field を含めない。

oracle の最小 contract:

{
  "schema_version": 1,
  "domain": "plangate.pbi-live-shadow-admission-oracle/v1",
  "case_ref": "LIVE-ADMISSION-...",
  "packet_ref": "<review-packet-ref>",
  "packet_hash": "sha256:...",
  "reviewed_source_ref": "<upstream-source-ref>",
  "reviewed_source_sha256": "sha256:...",
  "expected_admission_decision": "materialize | no_action | discover_more",
  "independent_review_asserted": true,
  "maker_actual_not_consulted_asserted": true
}

oracle 作成後:

python3 scripts/ai-loop/pbi_live_shadow_collector.py \
  --repo-root "<repo-root>" case \
  --packet-ref "<review-packet-ref>" \
  --oracle-ref "<oracle-ref>" \
  --case-artifact-ref "docs/working/TASK-XXXX/evidence/pbi-live-shadow/<run-id>/admission-case.json"

collector の保存は同一内容の retry のみ再利用可能。既存artifactの内容が異なる場合は fail closed。 oracle は expected.oracle_ref で束縛し、source evidence_refs[] へ混ぜない。 collector は PBI / Issue / RunState / Harness / merge を変更しない。

6.5 Live-shadow inventory（read-only）

tracked live-shadow case が増えたら、repository全体を read-only で再走査する:

python3 scripts/ai-loop/pbi_live_shadow_collector.py \
  --repo-root "<repo-root>" inventory

inventory は次だけを探索する:

docs/working/TASK-*/evidence/pbi-live-shadow/**/admission-case.json

各caseについて:

• case artifact / capture / RunEvidence / oracle が同じ TASK live-shadow namespace に属するか再確認する
• existing admission evaluator contractで再検証する
• duplicate logical case_ref は全件invalidにする
• invalid caseを集計から黙って除外せず invalid_case_artifacts[] に残す
• historical corpusをliveへ昇格しない
• synthetic fixtureをtracked live countに含めない

主要出力:

tracked_live_case_total
evaluated_case_total
invalid_case_total
observed_admission_decisions
observed_source_kinds
rollout_quality

0件は0件のまま扱う。未観測を成功率0%やrollout完了へ変換しない。

またinventoryはrepository chainの再検証であり、次は証明しない:

runtime_execution_verified = false
source_preexistence_verified = false
reviewer_identity_verified = false
representative_coverage_claim_allowed = false
quality_acceptance_decided = false

したがって tracked_live_case_total > 0 は「tracked chainが存在する」ことだけを意味し、 real runtime execution / representative coverage / write-capable rollout の承認には使わない。

6.6 Live Materialization review（post-admission）

Admission live case が reviewer expectation と実評価の両方で materialize に一致した場合だけ、 post-admission Materialization shadow へ進む。

collector は payload / existing-work snapshot / oracle を生成しない。別工程で repository-visible artifact として用意されたものを hash で束縛し、既存 evaluate_shadow_batch() 互換caseへ組み立てる。

必要artifact:

admission-case.json
materialization-payload.json
existing-work.json
materialization-oracle.json

すべて同じ:

docs/working/TASK-XXXX/evidence/pbi-live-shadow/<run-id>/

配下へ置く。

materialization oracle の最小contract:

{
  "schema_version": 1,
  "domain": "plangate.pbi-live-shadow-materialization-oracle/v1",
  "case_ref": "LIVE-MATERIALIZATION-...",
  "admission_case_ref": "<admission-case-ref>",
  "admission_case_hash": "sha256:...",
  "payload_ref": "<payload-ref>",
  "payload_hash": "sha256:...",
  "existing_work_ref": "<existing-work-ref>",
  "existing_work_hash": "sha256:...",
  "expected": {
    "decision": "create_new | update_existing | link_only",
    "matched_ref": null,
    "readiness_status": "ready | blocked",
    "readiness_route": "<existing readiness route>"
  },
  "independent_review_asserted": true,
  "maker_actual_not_consulted_asserted": true
}

case assembly:

python3 scripts/ai-loop/pbi_live_shadow_collector.py \
  --repo-root "<repo-root>" materialization-case \
  --admission-case-ref "<admission-case-ref>" \
  --payload-ref "<materialization-payload-ref>" \
  --existing-work-ref "<existing-work-ref>" \
  --oracle-ref "<materialization-oracle-ref>" \
  --case-artifact-ref "docs/working/TASK-XXXX/evidence/pbi-live-shadow/<run-id>/materialization-case.json"

collector は以下を再検証する:

• Admission case が reviewer expectation / actual ともに materialize で一致
• admission case / payload / existing-work / oracle の同一TASK namespace
• oracle が admission case / payload / existing-work の exact hash を束縛
• oracle が maker actual を保存していない
• assembled case が既存 _validate_shadow_batch() を通る
• oracle は expected.oracle_ref にのみ置き、source evidence_refs[] へ混ぜない

tracked Materialization case の再集計:

python3 scripts/ai-loop/pbi_live_shadow_collector.py \
  --repo-root "<repo-root>" materialization-inventory

主要出力:

observed_materialization_decisions
missing_materialization_decisions
duplicate_false_positive_rate
duplicate_false_negative_rate
decision_mismatch_count
readiness_mismatch_count

0分母は null のまま扱う。1件の create_new だけで duplicate FN が 0% とは判断しない。

また:

runtime_execution_verified = false
source_preexistence_verified = false
reviewer_identity_verified = false
representative_coverage_claim_allowed = false
quality_acceptance_decided = false

を維持する。Materialization inventory はduplicate FP/FNを測るためのread-only projectionであり、 write-capable rolloutのGateではない。

6.7 Live collection plan（read-only / non-quota）

admission / materialization inventory の current gap をまとめて確認する:

python3 scripts/ai-loop/pbi_live_shadow_collector.py \
  --repo-root "<repo-root>" collection-plan

collection plan が使う coverage basis は reviewed expected decision。 maker の actual decision は model behavior の観測であり、ground-truth coverage として数えない。

admission:
  reviewed expected = materialize | no_action | discover_more

materialization:
  reviewed expected = create_new | update_existing | link_only

materialization target は reviewed admission materialize が観測済みの場合だけ:

prerequisites_satisfied = true
collector_path_available = true
real_runtime_observation_available = null

となる。これは「そのcaseを作れ」という指示ではなく、自然に実runで遭遇した場合に collector経路が成立している ことだけを示す。現在real runtime observationが存在するかは未検証であり、null のまま扱う。

必ず次の境界を維持する:

opportunistic_observation_only = true
synthetic_case_generation_for_coverage_allowed = false
historical_relabeling_allowed = false
decision_coverage_quota_defined = false
source_kind_coverage_requirement_defined = false
representative_coverage_claim_allowed = false
coverage_complete_implies_representative = false
observation_gap_is_quota = false
observation_gap_is_case_generation_instruction = false
coverage_gap_basis = reviewed_expected_decisions
maker_actual_counts_as_ground_truth_coverage = false
runtime_execution_verified = false
quality_acceptance_decided = false

したがって observation gap を埋めるために synthetic case を作成したり、 historical case を live へ昇格したりしてはならない。

collection-plan の出力を保存して後から再利用する場合は、必ず判断直前に再実行する。 plan は元になった inventory projection の canonical SHA-256 を持つ。

inventory_binding.admission_inventory_hash
inventory_binding.materialization_inventory_hash
inventory_binding.combined_inventory_hash

plan_reuse_without_reinventory_allowed = false
runtime_head_bound = false
repository_commit_verified = false
inventory_hashes_are_commit_identity = false

hash は「このplanがどのinventory内容から導出されたか」を識別するためのもので、 Git commit / runtime execution / Evidence時系列真正性の証明ではない。 保存済みplanのgapをそのまま実行判断に使わず、repository evidenceが変わっていないか collection-plan を再実行して確認する。

6.6 Completion status（read-only）

実装を増やす前に、残課題がどの種類かを分類する。

python3 scripts/ai-loop/pbi_live_shadow_collector.py \
  --repo-root "<repo-root>" completion-status \
  --context "<completion-context.json>"

context は GitHub / Human 側で確認した事実を明示的に渡す:

{
  "latest_full_test_green": true,
  "design_dependency_finalized": false,
  "generalization_claim_required": false,
  "representative_live_evidence_review_ref": null,
  "quality_review_ref": null,
  "isolated_generalization_review_ref": null
}

collector はこれらの外部状態を自己検証しないため:

assertions_independently_verified = false
latest_full_test_status_verified_by_collector = false
design_dependency_status_verified_by_collector = false

を維持する。

review ref が指定された場合は repository-visible regular file の実在と byte SHA-256 まで束縛するが、 内容妥当性 / reviewer identity / independence は証明しない。

semantic_content_verified = false
reviewer_identity_verified = false
independence_verified = false

next_action は残課題の分類だけを行う:

fix_repository_or_evidence_integrity
finalize_design_dependency
collect_opportunistic_real_live_evidence
perform_human_evidence_and_quality_review
human_rollout_decision

重要:

rollout_completion_machine_decidable = false
rollout_complete = false
automatic_write_activation_allowed = false
machine_completion_decision_allowed = false
machine_write_activation_allowed = false

したがって completion-status は 停止条件 / 次行動の整理 用であり、 rollout完了・quality acceptance・write activationを自動承認しない。

禁止事項

• lite 宣言の虚偽（判定不能を true 側に倒す）
• W チェック結果の改変（Model A/B/C/D の verdict を都合よく書き換える）
• touches-HO の迂回（boundary 判定を回避する目的でのファイル分割・命名変更）
• escalate の自己解決（exit 2 を人間に提示せず AI 単独で処理を続行する）

関連ドキュメント

• docs/workflows/ai-loop/execution-runbook.md — 1 サイクル手順の正本
• docs/workflows/ai-loop/lite-criteria.md — lite 4 軸・AC-8 安全側
• docs/workflows/ai-loop/flow-detect.md — W チェック・severity 分類・C/D 裁定
• docs/workflows/ai-loop/decision-table.md — Decision table・provenance schema
• scripts/ai-loop/arbiter.py — 入力 JSON 仕様（docstring）
• docs/ai/plan-review-readiness-gate.md — 強化セルフレビュー §7/§8 観点