Meta Apply

Meta-Apply: the privileged landing gate for self-modification patches

This skill exists to enforce a privilege boundary. Producers like /meta-optimize (and, later, corpus-audit) are read-only — no Write/Edit, no apply step; they can only stage candidate patches under .aris/meta/pending/. This skill is the only place a staged patch becomes a real change to the corpus. Splitting "propose" from "land" across two skills with different tool grants is what makes "a loop cannot apply its own patch" structural rather than a sentence the producer is asked to obey.

It is human-invoked only. It runs when the user explicitly types /meta-apply after reading the producer's REPORT. That invocation IS the landing authorization (the locked 2026-05-30 decision: the human stays at the landing gate).

The acquittal is generated HERE, not relayed

The earlier design trusted a jury_verdict: pass field in the producer's manifest. That is forgeable — the producer writes that field, so a buggy/misaligned producer could stage a killed patch labelled "pass." So this skill does not trust any producer-written verdict. It runs the cross-model jury itself, at landing time, on the actual staged diff (fresh thread, paths-only). The verdict is produced where it is consumed, by the privileged human-invoked skill — nothing to forge.

The non-negotiable rules (jury-at-landing, reject-default)

For each staged patch the user asks to land, in order — any failure ⇒ skip & report, never silently apply:

1. The human named THIS patch. Apply only patches the user listed (/meta-apply 1,3 or all); default to applying nothing.
2. Fresh cross-model jury PASS, obtained now. Run mcp__codex__codex (fresh thread, NOT codex-reply; model: gpt-6-astra, config: {"model_reasoning_effort": "ultra"}, sandbox: read-only, paths-only per reviewer-independence.md) on the staged .diff + its target. Ask: does this change improve the harness without regressions; PASS or KILL + one-line reason. Include the scope-limits block from review-scope-limits.md in that prompt: this jury judges ARIS's own mechanism, so an over-defensive KILL permanently blocks a good patch. Note the block bans proposing new hash binding — it is not a reason to KILL a patch that touches the existing provenance stamp. KILL ⇒ refuse. The human cannot override a KILL — they may only pick among jury-PASSED survivors. (A loop can DRIVE; only the cross-model jury can ACQUIT.)
3. Author ≠ reviewer family. The author is the producer's executor model; the reviewer is the codex model that just judged it. Run provenance.py assert_cross_family — if it raises (same family / unknown), refuse. (Here it always holds: producer=Claude, jury=codex. The check is the structural backstop.)

Workflow

Step 0: Load staging + resolve the helper

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

Resolve provenance.py via the 4-layer chain in integration-contract.md §2 (.aris/tools/ → tools/ → $ARIS_REPO/tools/ → $ARIS_REPO/tools/ via ~/.aris/repo).

Step 1: Jury-at-landing for each requested patch

For every patch the user asked to land, read its staged .diff and target, then run the fresh codex jury (Rule 2) — paths-only, no producer reasoning, no prior-round context. Record {patch, jury_verdict, jury_thread_id, one_line_reason}. Print a one-line result per patch (PASS → eligible / KILL → refused: <reason>).

The producer may have written an advisory pre-screen into the manifest to help the human read the REPORT — ignore it for the landing decision. Only this fresh verdict counts.