mo-review-orca

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Review through Orca

通过Orca进行审查

Read Portable review protocol, Backend contract, Orca native mechanics, and Purpose and architecture contract completely.
Accept only an exact 40-hex
candidate_sha
, intent source, scope, mode and two user-approved reviewer selections. Read selections through bundled
scripts/mo-models.mjs --show --project <root>
when it is available; never pick a fallback model, effort or posture flag. A dirty/mismatched checkout or invalid selection is
UNKNOWN
.
Create both review tasks before launching either worker. Start one Codex and one Claude reviewer (or another explicitly approved vendor-diverse pair) with stable titles
<feature>:review:<vendor>
. Each receives original intent and candidate, but no peer bytes. The first lifecycle pair uses
deep
; remediation uses
follow_up
with only that reviewer's own prior report and dispositions.
fast
is only an explicitly requested standalone/advisory mode. The portable protocol may escalate any mode to
deep
.
Each reviewer proves the full SHA and clean status, performs non-mutating review, and returns the entire textual report in authoritative Orca
worker_done
. Its native Dispatch id is the opaque
Review-Execution
. After accepted delivery, show a brief TUI severity summary linked to that id. A missing summary is a UX defect, but never invalidates a complete
worker_done
; terminal text never replaces a missing/rejected report. If delivery is not confirmed, display
REVIEW DELIVERY UNKNOWN <Review-Execution>
and return
UNKNOWN
.
Wait for both full reports before releasing either to the caller. Preserve the original bodies without merging, ranking, paraphrasing or exposing peer output. Keep remediation reviewers hot. Before the one final same-SHA proof, release only owned old sessions and create two fresh independent sessions with no prior reports. Never close unnamed or foreign tabs.
P0–P2 block settlement. Deliver every P3 for fixing or reasoned rejection, but do not create a separate P3-only round. A substantive slice permits at most five paired review/fix attempts; remediation does not reset that budget. This limit does not weaken the final requirement: settlement still needs two independent
PASS
reports on one exact SHA, or an honest
needs_attention
.
Never use
/goal
, edit/commit, start another reviewer, or run concurrent full QC. Report E2E as not evaluated unless separately requested.
完整阅读可移植审查协议后端契约Orca原生机制以及目标与架构契约
仅接受精确的40位十六进制
candidate_sha
、意图来源、范围、模式以及两名用户认可的审查者选择。若可用,通过捆绑的
scripts/mo-models.mjs --show --project <root>
查看选择结果;绝不能选择 fallback 模型、工作量或姿态标记。若检出状态异常/不匹配或选择无效,则返回
UNKNOWN
在启动任一工作者之前,先创建两个审查任务。启动一名Codex审查者和一名Claude审查者(或其他明确获批的跨供应商组合),使用稳定标题
<feature>:review:<vendor>
。两者均会收到原始意图和候选对象,但不会收到对方的输出内容。首次生命周期组合使用
deep
模式;整改阶段使用
follow_up
模式,且仅提供该审查者自身之前的报告和处理结果。
fast
模式仅适用于明确要求的独立/咨询场景。可移植协议可能会将任何模式升级为
deep
模式。
每位审查者需验证完整SHA和清洁状态,执行非修改性审查,并在权威的Orca
worker_done
中返回完整的文本报告。其原生Dispatch ID为不透明的
Review-Execution
。在确认接收后,展示一个简短的TUI严重程度摘要,并关联至该ID。缺少摘要属于UX缺陷,但绝不会使完整的
worker_done
失效;终端文本绝不能替代缺失/被拒绝的报告。若未确认交付,则显示
REVIEW DELIVERY UNKNOWN <Review-Execution>
并返回
UNKNOWN
在向调用者返回任一报告之前,需等待两份完整报告。保留原始报告内容,不得合并、排序、改写或暴露对方的输出内容。保持整改审查者处于就绪状态。在最终的一次相同SHA验证之前,仅释放自身的旧会话,并创建两个全新的独立会话,不携带任何之前的报告。绝不能关闭未命名或外部标签页。
P0–P2级问题会阻碍结算。需交付所有P3级问题以供修复或给出合理的拒绝理由,但无需创建单独的P3专属审查轮次。一个实质性模块最多允许五次配对的审查/修复尝试;整改不会重置该次数限制。此限制不会削弱最终要求:结算仍需基于同一精确SHA的两份独立
PASS
报告,或诚实的
needs_attention
结果。
绝不能使用
/goal
命令、编辑/提交代码、启动其他审查者或运行并发的完整QC。除非单独要求,否则报告E2E为未评估状态。