meta-apply

Meta-Apply：自我修改补丁的特权落地关卡

每个审查席位开始前，请遵循 Selectable Reviewers： 通过规范的辅助程序解析器解析调用方式 → .aris/reviewer.json → 默认使用 Claude Code（Codex MCP）， 并通过 reviewer_route.py 保留此席位的层级、新鲜上下文、源文件／图像输入和确定性关卡。 以下 Codex 示例／固定配置仅适用于 backend=codex；其他路由使用各自的首次调用／回复约定。保存所选路由和实际返回的身份； 无法使用所选项时记为 REVIEW_UNAVAILABLE。根据实际模型家族／完成情况／范围对验收结果分类。 将调用方式中覆盖审查者／模型／推理力度的设置传递给包含审查者的子流程。生成工作器保持不变。

此技能用于执行权限边界。/meta-optimize（以及之后的 corpus-audit）等生产者均为只读——不能使用 Write／Edit，也没有应用步骤；它们只能在 .aris/meta/pending/ 下暂存候选补丁。**此技能是唯一能将暂存补丁变成语料库实际变更的地方。**将“提议”和“落地”拆分为两个工具授权不同的技能，才能从结构上确保“循环不能应用自己的补丁”，而不是仅靠要求生产者遵守一句话。

此技能仅由人工调用。用户阅读生产者的 REPORT 后，明确输入 /meta-apply 时才会运行。该调用即为落地授权（2026-05-30 锁定的决策：人工仍把守落地关卡）。

无罪认定在此处生成，而非转述

早期设计信任生产者清单中的 jury_verdict: pass 字段。这是可伪造的——该字段由生产者写入，因此有缺陷／不一致的生产者可能会暂存已被否决、却标记为“pass”的补丁。**因此，此技能不信任任何由生产者写入的裁决。**它会在落地时自行对实际暂存的差异运行跨模型陪审团审查（新建会话，仅提供路径）。裁决在使用之处生成，由人工调用的特权技能给出——没有可伪造之处。

不容妥协的规则（落地时陪审团审查，默认拒绝）

对用户要求落地的每个暂存补丁，按以下顺序处理——任何一步失败 ⇒ 跳过并报告，绝不静默应用：

1. **人工指定了此补丁。**仅应用用户列出的补丁（/meta-apply 1,3 或 all）；默认不应用任何补丁。
2. 现在获取全新的跨模型陪审团 PASS。运行 mcp__codex__codex（新建会话， 不是 codex-reply；model: gpt-6-astra，config: {"model_reasoning_effort": "ultra"}，sandbox: read-only， 按 reviewer-independence.md 仅提供路径） 审查暂存的 .diff 及其目标。询问：此变更是否能在不引发回归的情况下改进工具框架？请给出 PASS 或 KILL，并说明一句理由。在提示词中加入 review-scope-limits.md 中的范围限制块： 此陪审团评判的是 ARIS 自身机制，因此过度防御性的 KILL 会永久阻止有益补丁。注意，该限制块禁止提出新的哈希绑定；但这并不是 KILL 涉及现有来源证明戳的补丁的理由。KILL ⇒ 拒绝。人工不能推翻 KILL，只能从陪审团判定为 PASS 的候选补丁中选择。（循环可以驱动；只有跨模型陪审团才能宣告无罪。）
3. **作者 ≠ 审查者所属模型家族。**作者是生产者执行器所用的模型；审查者是刚刚作出判断的实际返回模型。运行 provenance.py assert_cross_family——如果引发异常（同属一个模型家族／未知），则拒绝。使用实际的作者／审查者身份，绝不根据主机或传输方式推断模型家族。此严格落地关卡仍为强制要求。

工作流

步骤 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 中的四层链解析 provenance.py （.aris/tools/ → tools/ → $ARIS_REPO/tools/ → 通过 ~/.aris/repo 指向的 $ARIS_REPO/tools/）。

步骤 1：对每个请求应用的补丁进行落地评审

对于用户要求应用的每个补丁，读取其暂存的 .diff 和目标文件，然后运行新一轮 codex 评审（规则 2）——仅提供路径，不提供生成者的推理，也不提供此前轮次的上下文。 记录 {patch, jury_verdict, jury_thread_id, one_line_reason}。每个补丁打印一行结果（PASS → 符合条件 / KILL → 拒绝：<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>（附备份路径 + 来源信息 sidecar）或 REFUSED <patch>: <reason>。将已应用的补丁从 .aris/meta/pending/ 中移除。提醒用户，已应用的补丁可从备份恢复，并请在下次运行时测试更改后的技能。

来源信息是回执，不是对正确性的认可

印记记录的是更改通过了一个流程（落地时的跨模型评审 + 人工落地），而非其正确性。为防止出现“已获批准但实际错误，印记却为其背书”的情况（虚假权威洗白——这比没有印记更糟，因为后续自动整理器会将其视为证据）：

• 印记包含 verdict_id（可审计的评审）和 content_hash（之后的手动编辑会使其失效）。
• 建议（尚未实现）：设置 TTL，强制重新评审长期存在的自动生成产物；并加入行为审计器，在已落地的技能行为异常时撤销印记。将此列为后续事项；绝不可将印记视为永久真相。

关键规则

• **仅由人工调用。**绝不可作为其他技能或钩子的副作用运行。
• **落地时评审，默认拒绝，不得覆盖。**约束性判定必须在此处针对暂存的差异作出；绝不信任生成者写入的判定；人工只能在通过评审的补丁中选择，绝不能让已判定为 KILL 的补丁起死回生。
• 必须跨家族，否则拒绝。assert_cross_family 不得抛出异常。根据 skill-governance.md，deterministic:<verifier> 评审者有效。
• 通过 Write/Edit 修改语料库（可审查、可追溯），而非 Bash。corpus_write_guard 钩子（若已安装）还会拒绝 Bash 写入语料库——但它不会限制 Write/Edit，因此它本身无法阻止此技能编辑语料库；上述落地评审 + 印记规范才是约束 Write/Edit 修改的机制（该规范属于流程，并非由钩子强制执行）。
• **每次修改前都要备份。**从设计上保证可恢复。
• **只应用暂存的补丁。**仅应用生成者暂存于 .aris/meta/pending/ 的内容；不自行编造内容。

审核追踪

按照 review-tracing.md，将每次 landing-jury codex 调用的追踪记录保存到 .aris/traces/meta-apply/<date>_run<NN>/ — 使促成语料库变更的无罪判定能够被取证还原。