review-duolisted

# 双人代码评审 两位成员检查同一份固定代码改动：固定搭档检查仓库规范、正确性与代码质量，当前评审者检查需求与验收条件，最终报告保留两个独立方向。 评审默认只读。完成报告不自动修改代码、创建任务、提交、推送或更新 PR；用户同时要求修改时，先完成报告。 ## 角色与关联 - 用户发起双人评审：作为发起者，负责需求检查和最终整理。 - 当前 AgentRun 由规范与质量检查请求直接触发：作为固定搭档，只处理当前请求。 - 当前输入是固定搭档对本轮有效请求的直接回复：作为发起者继续。 使用 Runtime 或 Core 提供的可信身份和直接回复关系判断角色。固定搭档必须不是自己、仍在当前 Camp、能够接收请求，并使用可信 Agent ID 寻址。 发起者只接受当前固定搭档对本轮请求的直接回复，并核对固定评审范围完全一致；标题和范围帮助阅读，不能替代可信发送者与直接回复。同一发起者在一个 Camp 中一次只推进一场未完成的 Review Duo。 ## 固定评审输入 开始前读取 [评审范围](references/snapshot.md)。两位成员必须读取同一份固定输入，例如已解析为不可变提交标识的 Git 范围，或用户提供且双方都能读取的固定 patch。 同时固定需求与验收来源、仓库规范来源和覆盖限制。没有明确需求时，需求方向标记为 `not_assessed`；没有稳定代码范围时，请用户提供提交范围或固定 patch，不能用两个时间点的实时工作区冒充同一输入。 ## 独立检查 固定搭档只检查仓库规则、明确正确性、错误处理、数据一致性、并发、重试、安全、API、数据库、迁移、生命周期、关键测试缺口和显著维护成本，不判断产品需求是否满足。 当前评审者只检查需求是否缺失、部分实现或实现错误，验收条件是否成立，是否加入未要求的行为，以及需求来源是否冲突或不足，不把一般代码风格写成需求问题，也不从代码反向创造需求。 发起者必须在吸收搭档结论前完成并公开自己的需求检查；发给搭档的请求不得包含自己的结论。 ## 结果与消息方式 每个方向使用一条有界的完整结果。无法保留必要问题和证据时， 标记为 `partial` 并建议缩小范围。具体格式见 [Finding 与报告](references/findings.md)。 - 评审请求只发给固定搭档：`rovai send --to <固定搭档 Agent ID> --body <请求>`； 搭档结果只返回请求发送者：`rovai send --to <请求发送者 Agent ID> --body <结果>`； 需求检查和最终报告通过 `rovai send --body <正文>` 公开发布。 - 发送后确认实际收件人符合上述关系。正文中的 `@` 只是代码或引用时， 放入代码块或转义。 - 只有发送成功的消息才能作为后续依据；发送成功不代表对方已经完成。 ## 四条消息 1. 发起者向固定搭档发送规范与质量请求，包含固定范围、需求与规范来源、 覆盖限制和分工。发送后在同一响应中独立完成需求检查，不等待搭档。 2. 发起者公开保存一条携带相同固定范围的完整需求检查结果，然后结束当前响应。 3. 固定搭档只处理当前请求，用一条携带相同固定范围的消息返回完整结果。 4. 发起者核对搭档身份��直接回复、固定范围和结果职责后，公开发布最终报告。 正常流程只有上述四条消息。 ## 结果独立性 两个方向保留各自的 finding 内容、ID、严重度和顺序，不跨