mo-review-orca

通过 Orca 进行评审

仅当用户明确提到 mo-review-orca，或当前编排技能调用它时，此技能才会启动。泛化的代码评审请求不构成启动条件。这类请求也没有不透明的 Review-Execution id；该 id 只能由 Orca Dispatch 签发，因此应说明无法为其生成可移植报告标头，而不是编造一个。

完整阅读可移植评审协议、关于方法论的反馈、已确认外部工作的路由、评审概要、后端契约、Orca 原生机制和目的与架构契约。还要从同一个已解析的 Orca 二进制文件中阅读版本匹配的 orchestration 和 orca-cli 内置指南；切勿安装指南副本。

仅接受精确的 40 位十六进制 candidate_sha、意图来源、范围、模式、规格行，以及从内置的 scripts/mo-models.mjs --show --project <root> 中经用户批准的两个不同供应商选项。切勿选择备用模型、effort、placement 或 posture 标志。如果工作遵循了规格，调用方应传入 Spec: <path|object>；否则传入 Spec: none。两位评审者收到的规格行必须相同；自行对其工作运行此评审的执行者也属于调用方，因为只有它知道自己遵循了哪份规格。

这两个选项构成不同供应商组合；二者均不得替换。

当调用方就是执行者，且没有编排器在背后支持时，应在组合评审开始前，向该调用方建议一次进行净室自评审：让一个全新的子 Agent 仅接收规格、差异和候选 SHA，并由同一个热子 Agent 修复检查发现的问题。自行对其工作运行此技能的执行者就是该调用方，因此应在组合评审前向用户发送一行建议；如果已完成自评审，则视为满足建议要求，这一行应说明该结果，而不是重复建议。此建议绝不阻止组合评审。在给用户的报告中，将调用方自己的陈述记录为 self_review=<pass|not_done|unavailable>；调用方未作说明时，值为 not_done。该值只是调用方的说法，并非证明。

使用内置的 scripts/mo-knowledge-layer.mjs --candidate <sha> 读取候选项的知识层，并将其原样输出行放入两份概要中；没有该行的概要会使评审者的缓评视角变为 unknown。not_enabled 是有效答复，并非缺漏。若项目曾有或部分声明了相关机制，但缺少 MO-BACKLOG/1 命令、papercut 文档或标识符历史门禁，则应报告为 needs_attention，并附上助手给出的原因以及原样复制的 missing= 字段：该字段会列出助手发现缺失的这三项，或写明 none、unknown，以便用户知道需要准备什么，无须再提问；此时不得开始组合评审。项目准备工作由用户自行完成；此技能不会代为准备，也不会替用户启动设置技能。

组合评审前的放置

在生成组合产物前，从项目／仓库清单读取 ProjectRegistrationSet/1，并从工作树、终端和工作器界面读取 OwnedResourceSet/1。放置选项按阶梯排列，第一阶是默认选项，而非多个同等选项之一：

1. isolated — 当前项目的两个经验证干净的隔离工作树，或 Git 项目的、归属于 Orca new-child 的工作树；每个工作树都必须处于精确的 SHA。
2. shared_checkout — 两位评审者都从同一个精确的现有工作区启动（--worktree id:<repo>::<path>）；此处会拒绝创建标志。
3. REVIEW-START … reason=placement_unsupported — 仅当不存在任何精确的现有工作区时使用。 在隔离模式下，工作区在发送简报前就位于候选提交上：rev-parse HEAD 与确切的 SHA 一致，且工作树干净。如果要求在停留于其他提交的工作区中给出最终判定，审查者会回答 UNKNOWN，并附上 candidate_mismatch；这是正确做法，因为这一轮就浪费在证明一个只需检出一次就能确认的事实。对于共享检出，审查者可能不能移动 HEAD，因此简报会说明候选提交是按 SHA 读取的，并解释原因。

原始 git worktree add、orca repo add、new-top-level 和未经验证的远程放置，在所有模式下都仍然禁止。对于文件夹项目，orca worktree create 可能会返回 ok:true，但路径却是主检出的自身路径，head 也为空；判断放置是否成功，要依据 realpath、isMainWorktree、head 和 rev-parse HEAD，绝不能依据返回码。

在 shared_checkout 模式下，共享工作检出不会发生变化：这对操作完成后，HEAD、索引以及已跟踪和未跟踪文件都必须逐字节保持一致。在此模式下，禁止执行 checkout、switch、stash、reset、clean、commit、rebase，也禁止编辑文件、运行格式化程序和修复工具、安装环境以及创建临时文件。对共享仓库所做的更改都要逐项列明并撤销：先执行 git cat-file -e <sha>^{commit}；仅当本地缺少该对象时，才执行 git fetch --no-write-fetch-head --no-tags <remote-url> <exact ref or sha>；创建属于该工作槽的引用 refs/meta-o/review/<slot>/<sha>，并用 git update-ref -d 删除；执行 git worktree add --detach <slot path outside the working copy> <sha>，并且只能用 git worktree remove <own path> 移除。除此之外一概不做：不运行 gc、不运行 repack、不运行 config，也不删除不属于该工作槽的引用。

禁止执行 git worktree prune。这是仓库级操作：它会删除当前路径不可达的每个工作树的管理记录，包括其他人的工作树和暂时未挂载的工作树。审查者负责一个记录，并移除这一个记录。若 worktree remove 失败，该记录会保留，相关情况会写入报告，并向所有者返回 needs_attention，附上准确的命令。

审查者可以自行选择如何读取候选提交，并优先采用不会写入任何内容的方式：git show <sha>:<path>、git diff <base>..<sha>、git grep … <sha>。Grounding 会列出实际使用的、绑定 SHA 的命令；如果创建了自己的检出，也会列出该检出路径及其 rev-parse HEAD。若结论是根据未绑定 SHA 的工作副本文件得出的，判定将为 UNKNOWN。共享检出可以处于脏状态，也可以停留在另一提交上；这并不构成障碍，因为该模式的含义是“起始目录为共享目录，按 SHA 读取候选提交”，且起始时的工作树状态会作为观察记录。

调用方会在这对操作前后分别拍摄基线快照：

git rev-parse HEAD
git status --porcelain=v1 -z --untracked-files=all --ignored
git worktree list --porcelain -z
git for-each-ref --format='%(refname) %(objectname)' refs/meta-o/

若仍存在可归因于某个审查者工作槽的更改，这对操作的结果将为 UNKNOWN；若关联工作树未移除，还会返回 needs_attention，并附上清理命令。若某条不属于任何工作槽的工作树记录在两次快照之间消失，说明有人运行了 prune；这一情况会写入 Grounding 和报告。若某项更改既不涉及工作槽也不涉及候选提交，则说明有人正在并行操作：该更改会作为观察记录，绝不会被撤销。公开投影会包含 Placement: isolated|shared_checkout，且不会新增 REVIEW-START 代码。 在创建新的一对之前，盘点本项目拥有的审查工作树，并让捆绑的 scripts/mo-review-resource.mjs release 根据通过 Orca 读取的事实逐一判定：worktree show 的 ID 和注释；与源项目的 Git 公共目录是否相同，两者都通过 git rev-parse --path-format=absolute --git-common-dir 读取，因为主检出否则会返回一个无法匹配任何内容的相对路径；项目的 Orca 注册信息；通过 terminal show/list 和 worker show/status 证实的终端和提供方会话绑定；是否有活动会话或协调器、执行器的检出正在使用该工作树；工作树是否干净；以及是否有其他活动资源依赖它。将这些事实作为一个 JSON 对象传入其 stdin，每个布尔值都必须经过观察，绝不能假定；scripts/mo-review-resource.mjs --help 会打印此命令及所有其他命令的输入。这里的每个 <bool> 都是占位符，因此复制的骨架并非有效 JSON，必须先观察每个事实；任何默认值都不能替代决定是否关闭资源的事实：

{"comment": "<worktree comment>", "worktreeId": "<orca worktree id>",
 "project": "<project id>", "sameGitDir": <bool>, "projectRegistered": <bool>,
 "bindingsProven": <bool>, "liveSession": <bool>, "coordinatorCheckout": <bool>,
 "clean": <bool>, "dependency": <bool>, "head": "<sha>", "nextCandidate": "<sha>"}

它会回答一行：

MO-REVIEW-RESOURCE/1 action=<release|reuse|keep|check_hot> reason=<code> worktree="<id>"

release 按准确的 ID 通过 Orca 操作：先处理已证实的依赖终端，再处理工作树；禁止强制操作，也禁止使用 git worktree prune。reuse 表示一个干净的自有工作树，且已处于准确的候选版本。check_hot 表示带标记的活动会话：将其作为一个槽位进行测试，否则保持原样。keep 搭配 dirty 时会在报告中列出该资源；搭配 ownership_unknown 时返回 needs_attention/ownership_unknown；搭配 foreign 或 marker_mismatch 时不会阻止任何操作。名称或短 SHA 绝不能代替标记。

每个槽位的工作树都必须在 orca worktree create 或 show 返回其准确 ID 后立即标记：只需执行一次 worktree set --comment，写入 mo-review-resource.mjs comment --pair <id> --slot A|B --candidate <sha> --project <id> --worktree <orca worktree id> --feature <name> 打印的两行内容：供重启后的协调器匹配的 MO-REVIEW-RESOURCE/1 pair=… slot=… candidate=… project=… worktree=… 标记，以及便于人工识别的 <feature> review slot A|B @ <short sha>。--workspace-status in-review 保持为便于人工识别的状态。 启动后，用一行告诉用户候选版本所属的 Orca 项目、两个工作树名称和两个标签页标题；如果候选版本所属项目不是协调器自己的项目，也要另行说明。绝不要传入 --activate，也不要在非必要时切换焦点。

对每个选定的工作树，以只读方式运行已解析的系统 realpath -- <path>，要求退出码为零且只输出一个绝对路径，并将记录的命令和输出与该次观察绑定。如果两个词法路径观察到的 realpath 相同，则它们是同一个资源，必须以 inventory_changed 失败；命令或输出证据过期、缺失或不匹配时，必须以 inventory_unreadable 失败。

如果无法证实项目身份、完整清单、放置位置或候选版本，则不要创建 Run 任务、命名空间或报告。准确输出：

REVIEW-START version=1 status=unsupported reason=<code> project=<id-or-none> candidate=<sha-or-none>

使用以下错误之一：no_project_context、inventory_unreadable、 inventory_partial、registration_kind_unknown、placement_unsupported、 remote_placement_unsupported、candidate_unverifiable、 inventory_changed、partial_start_failed、cleanup_incomplete；附上观察到的 Orca 错误和证据引用，然后返回 needs_attention。部分启动时，只释放确切归属的资源，并重新检查两份清单。绝不要关闭或注销归属不明确的资源。

审查者配对

在启动任一工作进程之前创建两个任务。该技能只创建两名审查者，绝不创建执行器、修复器、验证器或子 Agent。使用稳定且可见的标题 <feature>:review:<vendor>；标题只是标签，清理操作必须使用准确的句柄。 每个评审者的 Dispatch 都会在 Reviewer-Skill 下声明 mo-reviewer、该技能当前运行所在安装中的 SKILL.md 绝对路径（即该技能的同级目录）以及已安装版本，格式为 mo-reviewer <path> source_tree=<40-hex>，后接 skill=<id> protocol=<id> validator=<id>。source_tree 是该文件的构建标记；它只标识编写的输入，不包括捆绑的第三方字节内容，并且本地编辑后仍会保留。因此，在 Dispatch 前立即对已安装的 SKILL.md、references/review-protocol.md 和 scripts/mo-review-report.mjs 执行 git hash-object：这三个 ID 是评判报告所依据的字节内容。本轮报告会在 prepared_body_identity 旁重复整个值。每次 Dispatch 前都要读取该文件；如果文件不存在、评审者的工作区无法读取、没有标记、缺少上述三个文件之一，或与本技能并非同一构建，则不会启动 Dispatch，结果为 needs_attention/skill_unavailable。同一构建是指其 protocol 和 validator ID 分别等于对本技能自身的 references/review-protocol.md 和 scripts/mo-review-report.mjs 执行 git hash-object 得到的值：同一构建会在两个技能中逐字节附带这两个文件。不比较两个 source_tree 标记，因为它们各自对本技能的输入进行哈希，按设计就会不同。绝不要粘贴来源不明副本中的评审者指令。记录的值无法通过 Meta-O 历史验证：安装环境不知道其源提交，而被评审的项目通常根本没有 Meta-O 历史。

在 Orca 1.4.219 或更高版本上启动每个 Claude 或 Codex 评审者：

orca orchestration worker-start --task <id> --worktree id:<repo>::<path> \
  --agent <claude|codex> --model <id> --effort <e> --json

只有当运行框架显示其常规 Agent 提示词时，Orca 才会注入任务；其回执必须显示 launch.requested 等于 launch.effective，且 turnStart: observed。立即记录 Dispatch 和 effects[kind=terminal].id 对应的终端。如果运行框架的模型 worker-start 无法通过，则按照Orca 原生机制中的步骤，以终端优先方式启动。新 Agent 标签页的无沙箱设置由用户的设置决定；绝不要重复添加其标志。

第一组生命周期配对使用 deep。Dispatch、提供方会话、其 PTY 和工作树是四种资源；worker_done 只会结束 Dispatch：FINDINGS 之后，在两个处置结果都确定之前，不得释放或关闭任一评审者；修复工作要以 follow_up 的形式交给同一对评审者，并且每位评审者只能收到其自己的先前报告和处置结果。每份简报（包括 follow_up）都要涵盖整个任务范围 <base>..<candidate>：base 是任务分支的起点；若没有分支，则使用调用方指定的起点。每次 Dispatch 前，都要使用 scripts/mo-review-resource.mjs hot 分别决定每个槽位：

hot(slot) = alive_and_ready(slot) AND (age < 1h OR context_proven_small(slot))
scripts/mo-review-resource.mjs hot --alive yes|no --ready yes|no --composer empty|other \
  [--age-ms <n>] [--context-tokens <n> | --context-percent <n> --context-window <n>]

age 从 Dispatch 事件中的该槽位最近一次 worker_done 开始计算； alive_and_ready 表示同一 Provider 会话已被证实存活、就绪且输入框为空。仅在已完整解析出绝对计数时传入 --context-tokens；仅当 --context-percent 与来自同一公共界面或经批准的模型目录的 --context-window 一起使用时才传入；其他情况一律视为 context=unknown，仅由 age 决定。非热槽位会在该槽位中通过 follow_up 替换为同一模型的新会话，并有其自己的报告和处置结果——不会开启新的深度配对，也不是最终配对；相邻的热槽位则保持不变。启动替换会话前，按冷槽位已完成的 Dispatch 的确切 ID 释放它，确保两个会话不会共享同一个 worktree。--alive 的判定在 Orca 原生机制 中统一定义：必须依据该槽位自身记录的终端和屏幕，绝不能仅凭 Orca worker 的存活状态 unverifiable。就绪状态和空输入框由 scripts/mo-harness-screen.mjs 对 action=inject 的响应确定，其 context=/context_window= 字段是上下文标志的取值依据。空闲会话上的屏幕检查若被拒绝，则记录为 session_unavailable 并附上该行：该槽位返回 needs_attention，保留输入框中的文本，不关闭任何其他内容，且这本身绝不是启动新深度配对的理由。

Orca 自带的文件夹预信任功能默认开启，会在启动 harness 前信任 worktree，因此审查者的会话通常不会遇到信任界面。如果启动时仍遇到信任界面或信任失败——例如所有者关闭了该设置，或启动时走了该设置未覆盖的路径——则 Codex 启动因 agent-trust-workspace 失败时，仍应留在受支持的 harness 内处理：按确切 ID 释放失败的 Dispatch，按照信任流程证明信任，然后重新启动常规受监督的 harness。Claude 启动若在 Claude 的文件夹信任对话框处于 agent_readiness 时超时，也按相同方式恢复：按照信任流程在该次启动自己的终端中回应对话框，释放失败的 Dispatch，然后使用 --retry-of 重新启动。

无论该设置如何，运行 codex exec 的终端绝不是审查者。

在此配对尚无 PASS 时，若要启动新的独立深度配对，必须记录 scripts/mo-review-resource.mjs deep --phase remediation --reason <r> 接受的理由：state_transfer_impossible、hypothesis_stuck、requirements_conflict 或 owner_request。每轮报告都要注明 attempt <n>/5 和 deep_reads <m>：热 follow_up、槽位替换、深度配对，以及最终全新配对及其 follow_up，各计入实质审查环节的一次尝试；新的 SHA 不会重置计数；全新配对是成本较高的完整重读。

fast 明确为独立的建议性审查，便携协议可将其升级为 deep。仅在该配对针对同一 SHA 返回两份 PASS 报告之后，才释放其确切归属的资源，并针对同一 SHA 创建新的独立配对，使用全新的独立会话且不附带先前报告。最终配对也必须是 deep：follow_up 需要同一审查者的先前报告，而全新配对没有该报告；建议性的 fast 也无法提供必需的闭环证明。全新配对发现的问题应在该配对中修复，该配对随即成为热配对；在其通过之前，不得启动其他全新配对。

使用一次覆盖整个运行的公共等待器等待两个确切的 Dispatch 句柄。审查者的等待时长设为 300000 ms；安静超时后，可执行一次公共存活状态快照并立即重新等待，无须叙述或发送消息。传输失败后对同一轮等待重试一次；若连续第二次失败，则标记为 UNKNOWN/needs_attention。确认返回批次前，先处理其中的每个事件。 worker-release 会关闭由审查者启动的 worker-start --agent 终端。由此技能自行创建的终端会返回 retained；关闭 OwnedResourceSet/1 中记录的对应句柄，然后重新读取资源投影。如果该句柄不存在，则不关闭任何内容，并返回 needs_attention。

在处置或移交前，等待两份完整报告。

任务简报包含 审查简报 的所有字段，且不含占位符。它引用的每个依据来源都必须能从候选版本本身读取：.orca/ 下的路径不在审查者可获取的任何检出中，而已接受的规范在关闭前会保存在 docs/specifications/ 中。对于清理后的候选版本，简报会以耐久知识为依据说明这组审查，并通过冻结的对象 ID 和仍保留该对象的提交引用已移除的规范；完整克隆或工作树可通过 git cat-file 解析该引用，而浅克隆不行。无法访问所引用来源的审查者要么会花一轮询问，要么会依据虚构的章节进行推理；而依据虚构章节得出的结论，无法与真实结论区分。

权威响应

每位审查者都要证明完整 SHA 和干净状态，进行非变更式审查，并将完整报告放入权威的 worker_done。请在任务字节中明确说明这一点，因为 worker_done 才能完成 Dispatch：包含摘要、终端指针或稍后补发承诺的正文，之后都无法修复，而该审查者也就无法再用。简报的 Report 字段声明了 可移植审查协议 的报告语法，作为特定于任务的正文，取代 Orca 注入前言中的通用完成格式；同时还要附上调用者持有的所有值及此命令。撰写任务时 Dispatch ID 尚不存在，且只会通过 Orca 的前言传给审查者，因此 --dispatch 是简报要求从前言中获取的唯一参数：

scripts/mo-review-report.mjs template --verdict <PASS|FINDINGS|UNKNOWN> \
  --dispatch <id> --candidate <sha> --requested <mode> --effective <mode> \
  [--unknown-reason <reason>]

正文首行必须是独立的 Review-Execution: <id>；MO-REVIEW-REPORT/1 是验证器的输出，不属于正文。服务行之间可以有一个空行，不能有两个。发现项正文可以是独立的键行后接以 [P2] … 开头的行，也可以是单行 F-001 [P2] …。

审查者只阅读项目，不执行项目：简报禁止运行测试、linter 和 QC 门禁，只允许基于 SHA 阅读内容并运行自己的报告验证器。对候选版本进行 QC，应由执行者或协调者在该精确 SHA 的干净检出上运行；CI 则应在 Agent 合并前运行。审查者若也运行测试套件，只会浪费时间，还会导致所有缓存过期。

在向两个审查者发送简报前，使用 scripts/mo-review-report.mjs namespace 在所有工作树之外创建一个运行目录，并为每位审查者指定 Body-File: <dir>/slot-<a|b>-r<round>-d<n>.md。这个名称必须在发送简报前生成；<n> 统计该轮中该槽位的 Dispatch 次数，因此重复 Dispatch 不会复用先前的正文文件。Dispatch ID 只会传给审查者，并保留在正文的 Review-Execution 字段中。审查者通过 prepare 一次性写入文件；该命令会先验证字节内容，并拒绝覆盖现有文件，然后审查者发送完全相同的内容。如果 Orca 在另一台主机上运行审查者，简报应写明 Body-File: none，审查者则通过标准输入验证相同的字节内容。

每项发现都要说明证据强度（confirmed|strongly_supported）、因果路径、影响、可操作的位置、证明、修复后的不变量、技术方向、深度（local patch|boundary repair|affected-slice redesign），以及以具体案例命名的验收证明：包括输入和状态、预期行为，以及检查应放置的位置；描述必须足够精确，确保无需再向可能已不存在的审查者追问，就能编写检查。 只有协调器从 Orca 收到的正文是权威依据，而且还必须先依据调用方持有的预期值自行验证：确切的候选项、原生 Dispatch ID、请求模式和观测到的有效模式。过时但前后一致的头部／尾部内容属于 UNKNOWN。请运行随附的验证器，而不要凭肉眼判断格式，并在同一次调用中与准备好的文件进行比较：

scripts/mo-review-report.mjs validate --file <received> --dispatch <id> \
  --candidate <sha> --requested <mode> --effective <mode> \
  --prepared <Body-File> --normalization <none|final-newline>

--effective 是本轮所需的模式：对于 deep 请求，包括每一组新的和最终的配对，均为 deep；对于 fast 或 follow_up 请求，则为请求的模式，或经审阅者自行升级后的 deep。验证器会自行拒绝降级，因此无论调用方传入什么值，requested=deep effective=fast 都会导致 mode_mismatch。

status=malformed reason=<code> line=<n> 表示报告格式错误，退出码 2 表示调用错误。结构和身份是分别报告的两项声明：MO-REVIEW-BODY/1 prepared_body_identity= 行的值为 identical、different 或 unverified。规范化方式采用 Orca 兼容性探测器针对观测版本记录的结果——以 --body "$(cat <file>)" 发送的正文会丢失末尾换行符，此情况标记为 final-newline——除此之外均为 none。正文不同则为 UNKNOWN/body_integrity；文件无法读取或不存在时，结果为 prepared_body_identity=unverified，此时仅依据正文结构进行验收，除非任务说明要求提供证明，此时该 Dispatch 属于 UNKNOWN/body_integrity_unverified。屏幕文本不能替代这两项声明中的任何一项，释放槽位时会删除正文文件。

worker_done 会结束一次 Dispatch，因此正文结构错误时，该 Dispatch 的结果为带有 malformed_report 的 UNKNOWN，绝不会以修正其名义进行更正。同一候选项上的后续 Dispatch 是一次具有自身 ID 且经过完整验证的新审阅，绝不是更正。会话的存续时间长于 Dispatch：如果确认同一提供方会话仍然存活且已就绪，则在同一轮中向其发送这一次新的 Dispatch，不关闭其终端，也不消耗一次尝试；如果该槽位在本轮中第二次返回格式错误的正文，则本轮结果为 UNKNOWN。只有在明确指定的阶段或所有者原因下才会关闭终端。

无损交接与投影

两份有效报告都准备好后，使用随附脚本发布，不要手动操作：

scripts/mo-review-report.mjs namespace
scripts/mo-review-report.mjs stage --dir <ns> --slot <A|B> --vendor <slug> \
  --dispatch <id> --candidate <sha> --requested <mode> --effective <mode>   < report bytes
scripts/mo-review-report.mjs pair --dir <ns> --a-vendor … --a-bytes … --a-dev … --a-ino … --a-sha256 … --b-…

每轮都会发布到新的命名空间：follow_up 轮次的报告会暂存于该命名空间，绝不会放入上一轮的命名空间，因为其中的槽位名称已经存在，会返回 final_exists。命名空间位于系统临时目录下，权限模式为 0700，名称中至少包含 18 个随机字符。A/B 槽位在启动前分配，供应商标识必须匹配 ^[a-z0-9][a-z0-9-]{0,31}$。每个负载都按即将写入的确切缓冲区进行验证，写入同级的常规文件（权限为 0600），执行 fsync，然后通过硬链接将完整的同级文件以仅当目标不存在时创建的方式发布到槽位——绝不使用可覆盖目标的重命名。final_exists、link_unsupported、permission、identity_changed、symlink、malformed 和 invalid_utf8 都属于 UNKNOWN，且不会触碰已有的最终路径。向指定的使用方发送一条普通消息，包含 pair_id、两个确切路径和十进制大小。机器使用方只有在读取完两份报告后才确认：

Review-Handoff-Ack: <pair_id> A=<decimal-bytes> B=<decimal-bytes>

若有一项确认缺失或不匹配，可使用相同路径重新交付一次；若再次失败，则将此配对标记为 UNKNOWN 并保留命名空间。使用 scripts/mo-review-report.mjs ack --kind Handoff --line <text> --pair-id <id> --a-bytes <n> --b-bytes <n> 检查确认，不要凭目测判断。

提前修复是唯一可以不等两份报告的例外，但只有在所有者批准且每项条件都得到证明时才适用：执行者在自己的工作树中工作；每位审阅者都有自己的树，并分离检出旧的完整 SHA；简报禁止读取执行者的可变引用；在 worker_done 前立即重新检查 HEAD 和干净的工作树。然后将第一份完整有效的 FINDINGS 正文暂存到其槽位，并使用 scripts/mo-review-report.mjs preview --dir <ns> --slot <A|B> --<a|b>-… 原样交给执行者；执行者回复 Review-Preview-Ack: <pair_id> <slot>=<bytes>，并使用 ack --kind Preview 检查。预览不代表配对结论：另一位审阅者继续基于旧 SHA 审阅；在下一候选版本之前，仍须按上述流程在另一份报告发出后完成配对交接；并且每条发现都必须针对新候选版本检查处置情况。若有任何条件未得到证明，就等待两份报告。

人工调用者的审阅报告须列出两条路径和大小，且绝不自动清理；执行者自行发起审阅时，也须报告其 self_review=<pass|not_done|unavailable>。

公开显示确切 SHA、配对结论，以及按组件分别统计的已编写 P0–P3 数量总和。重复发现按两条计数。不要披露索引/内容，不要去重、排序或转述。P0–P2 会阻塞交付；每条 P3 都必须交付修复或有理有据地驳回，不得仅针对 P3 开启新一轮。对同一个实质性切片，配对审阅/修复尝试不得超过五次，且最终仍须针对同一个最终 SHA 获得两份全新、独立的 PASS 报告。

绝不使用 /goal，不得编辑/提交，不得以审阅者身份运行 QC，不得关闭他人的标签页，也不得重试 unknown_effect。除非另有要求，否则将 E2E 报告为未评估。

Meta-O 调用

• mo-reviewer