meta-apply

Meta-Apply：自己変更パッチを適用するための特権ゲート

各レビュー担当者のスロットの前に、Selectable Reviewers に従ってください： 呼び出しを解決 → .aris/reviewer.json → Claude Code のデフォルト（Codex MCP） を reviewer_route.py と標準ヘルパーリゾルバー経由で実行し、この スロットのティア、新鮮なコンテキスト、ソース／画像入力、決定論的なゲートを維持します。 以下の Codex の例／固定設定は backend=codex にのみ適用されます。それ以外のルートでは、 それぞれの初回呼び出し／返信の契約を使用します。ルートと実際に返された ID を保存してください。 選択したバックエンドが利用できない場合は REVIEW_UNAVAILABLE です。実際の ファミリー／完了状況／スコープに基づいて合否を判定します。レビュアーを伴う子プロセスには、 呼び出し時のレビュアー／モデル／effort のオーバーライドを引き継いでください。 生成ワーカーに変更はありません。

このスキルは特権境界を強制するために存在します。 /meta-optimize（および将来的には corpus-audit）のような プロデューサーは読み取り専用です。Write／Edit や適用ステップはなく、候補パッチを .aris/meta/pending/ にステージングすることしかできません。ステージングされたパッチを実際に コーパスへ反映できるのは、このスキルだけです。「提案」と「適用」を、異なるツール権限を持つ 2つのスキルに分けることで、「ループが自分自身のパッチを適用できない」ことを、プロデューサーに 守るよう求めるだけの文言ではなく、構造によって保証できます。

これは人間による呼び出し専用です。ユーザーがプロデューサーの REPORT を読んだ後に 明示的に /meta-apply と入力したときに実行されます。この呼び出しが適用の承認となります （2026-05-30 の決定事項：適用ゲートでは人間が判断を続けます）。

無罪判定はここで生成し、引き継ぐものではありません

以前の設計では、プロデューサーのマニフェストにある jury_verdict: pass フィールドを信頼していました。 これは偽造可能です。そのフィールドを書くのはプロデューサーなので、バグや不整合のある プロデューサーが、却下されたパッチに「pass」のラベルを付けてステージングできてしまいます。 **そのため、このスキルはいかなるプロデューサー記入の判定も信頼しません。**このスキル自身が 適用時に、実際にステージングされた差分に対して、クロスモデルの陪審レビューを実行します （新しいスレッド、パスのみ）。判定は、それを使用する場所で、特権を持つ人間呼び出し専用スキルが 生成します。偽造する余地はありません。

絶対に守るルール（適用時の陪審レビュー、却下をデフォルトにする）

ユーザーが適用を求めたステージング済みパッチごとに、次の順で確認します。いずれかに失敗した場合は 適用をスキップして報告し、決して黙って適用しないでください：

1. **人間がこのパッチを指定していること。**ユーザーが指定したパッチ（/meta-apply 1,3 または all）だけを適用します。指定がなければ何も適用しないでください。
2. **今、新しいクロスモデル陪審レビューで PASS を得ること。**ステージング済みの .diff とその 適用先に対して、mcp__codex__codex を実行します（新しいスレッドを使用し、 codex-reply は使用しません。model: gpt-6-astra、config: {"model_reasoning_effort": "ultra"}、 sandbox: read-only、reviewer-independence.md に従ってパスのみを指定します）。「この変更は回帰を起こさずにハーネスを改善しますか。PASS または KILL と、理由を一行で回答してください」と尋ねます。このプロンプトには review-scope-limits.md のスコープ制限ブロックを 含めてください。この陪審レビューは ARIS 自身の仕組みを評価するため、過剰に防御的な KILL によって 良いパッチを永久に阻止してはならないためです。このブロックは新たなハッシュバインディングの 提案を禁じるものであり、既存の来歴スタンプに触れるパッチを KILL する理由にはなりません。 KILL ⇒ 拒否。人間が KILL を覆すことはできません。陪審レビューで PASS となったパッチの中から 選べるだけです。（ループは実行を進められますが、無罪判定を下せるのはクロスモデルの陪審だけです。）
3. **作成者とレビュアーのモデルファミリーが異なること。**作成者はプロデューサーの実行モデルであり、 レビュアーは直前にパッチを評価した、実際に返されたモデルです。provenance.py assert_cross_family を実行し、例外が発生した場合（同一ファミリー／不明）は拒否します。ホストやトランスポートから ファミリーを推測せず、作成者とレビュアーの実際の ID を使用してください。この厳格な適用ゲートは 引き続き必須です。

ワークフロー

ステップ 0：ステージングを読み込み、ヘルパーを解決する

PENDING=".aris/meta/pending"
[ -d "$PENDING" ] || { echo "Nothing staged. Run /meta-optimize first."; exit 0; }
echo "Staged:"; cat "$PENDING/manifest.jsonl"

integration-contract.md §2 の4層チェーン（.aris/tools/ → tools/ → $ARIS_REPO/tools/ → ~/.aris/repo 経由で $ARIS_REPO/tools/）を使って、provenance.py を解決します。

ステップ 1：依頼されたパッチごとにランディング時の審査を実施する

ユーザーがランディングを依頼したすべてのパッチについて、ステージング済みの .diff と対象を読み込み、新しい codex 審査（ルール 2）を実行します。対象パスのみを使い、作成者の推論や前回ラウンドのコンテキストは使いません。 {patch, jury_verdict, jury_thread_id, one_line_reason} を記録します。パッチごとに1行の結果（PASS → eligible / KILL → refused: <reason>）を出力します。

作成者が REPORT を人間が読みやすくするため、マニフェストに参考用の事前審査結果を記載している場合がありますが、ランディングの判断には使用しないでください。 判断に使うのは、この新しい審査結果のみです。

ステップ 2：合格したパッチをランディングする（Write/Edit のみ。Bash は絶対に使用しない）

ステップ 1 に合格し、かつユーザーが指定したパッチごとに、次を行います。

1. バックアップを .aris/meta/backups/<date>/<target> に作成します（Write ツールを使って内容をコピーします。corpus_write_guard が有効な場合、コーパスのパスには Bash で書き込めません。また、適用側はコーパスの変更に Write/Edit を使う必要があります）。
2. 適用は、対象のコーパスファイルに対して Edit/Write を使って行います。
3. 変更したファイルにプロベナンスを記録します。

   python3 "$PROVENANCE" stamp "$TARGET" --author "$AUTHOR" \
     --reviewer "$JURY_MODEL" --verdict-id "$JURY_THREAD_ID"
   

   stamp() はファミリーをまたぐことを再確認し、同一ファミリーの場合は拒否します。これは認可記録の書き込み時点で機能する構造上の最後の防護策です。スタンプはプロセスの記録（作成者、ランディング時に承認した者、コンテンツハッシュ）であり、変更が正しいという主張ではありません。
4. .aris/meta/optimizations.jsonl に次を記録します。 {ts, patch, target, author_model, reviewer_model, jury_thread_id, applied: true}。

ステップ 3：報告する

パッチごとに、LANDED <target>（バックアップパスとプロベナンスサイドカーを併記）または REFUSED <patch>: <reason> を報告します。ランディングしたパッチを .aris/meta/pending/ から削除します。ランディングしたパッチはバックアップから元に戻せること、次回実行時に変更したスキルをテストすることをユーザーに伝えます。

プロベナンスは記録であり、正しさを保証する承認ではありません

スタンプが記録するのは、変更がプロセス（ランディング時のクロスモデル審査と人間によるランディング）を通過したことです。変更が正しいことを意味するものではありません。「承認済みだが誤っているのに、スタンプが正しさを保証する」という事態（誤った権威付け）は防ぐ必要があります。後続の自動キュレーターがスタンプを証拠として読み取るため、スタンプがない場合よりも悪い結果になります。

• スタンプには verdict_id（監査可能なレビュー）と content_hash（後から手動編集すると無効になる）が含まれます。
• 推奨事項（未実装）： 長期間残る自動作成アーティファクトを強制的に再レビューする TTL と、ランディングしたスキルの動作に問題があった場合にスタンプを取り消す動作監査機能。フォローアップとして管理し、スタンプを恒久的な真実として扱わないでください。

主なルール

• 人間が呼び出した場合のみ実行します。 別のスキルやフックの副作用として実行してはいけません。
• ランディング時に審査し、不合格を既定とし、上書きは認めません。 拘束力のある判定は、ステージング済みの diff に対してここで行います。作成者が記載した判定を信用してはいけません。人間は合格した候補から選び、KILL を復活させることはできません。
• クロスファミリーでなければ拒否します。 assert_cross_family が例外を発生させてはなりません。skill-governance.md に従い、deterministic:<verifier> のレビュアーは有効です。
• コーパスの変更には Bash ではなく Write/Edit を使います（レビュー可能で、実行者を追跡できるため）。corpus_write_guard フック（インストールされている場合）は Bash によるコーパスへの書き込みも拒否します。ただし、Write/Edit は制限しないため、このスキルによるコーパス編集を単独で阻止するものではありません。Write/Edit による変更を管理するのは、上記のランディング時の審査とスタンプの規律です（この規律は手順であり、フックによって強制される仕組みではありません）。
• 変更の前に必ずバックアップを作成します。 構造上、変更を元に戻せるようにします。
• ステージング済みのパッチのみをランディングします。 作成者が .aris/meta/pending/ にステージングした内容を適用し、独自の変更を作り出してはいけません。

レビューの追跡

各 landing-jury codex 呼び出しのトレースを、 review-tracing.md に従って .aris/traces/meta-apply/<date>_run<NN>/ に保存してください。コーパスの変更を確定させた無罪判決は、法医学的に復元できなければなりません。