yunxiao-mr-review

云效 MR 审查

使用本 Skill 完成跨项目一致的云效 Codeup 合并请求审查闭环。阿里云 CLI、云效插件、组织身份、PAT 生命周期和多身份路由由全局 aliyun-profile 管理；项目 Skill 只提供身份、组织、仓库和业务边界覆盖，不复制通用审查流程。

固定边界

• 先读取目标项目与目标软件仓库的 AGENTS.md、README.md、STATUS.md 及当前 Git 状态；项目实时规则优先。
• 从项目规则与 {{AGENT_ROOT}}\GLOBAL\ALIYUN_PROFILES.md 解析唯一逻辑 Profile、组织和仓库路由。缺失、冲突或无法核验时停止，不使用全局默认、残留环境变量或其他项目身份回退。
• 项目覆盖层可以固定或收窄身份、仓库与授权边界，但不得省略本 Skill 的证据门禁，也不得在没有用户明确指令时扩大写操作范围。
• PAT 仅通过安全凭据通道进入当前进程环境，不出现在参数、日志、评论或报告中。
• 用户明确要求使用本 Skill 或项目覆盖层审查 MR 时，该请求同时授权三类受控写入：对高可信问题发布精确行内评论；解决经最新代码与讨论证据确认已经修复、失效，或被用户明确接受/暂缓的现有评论；在证据完整、风险相称验证通过且没有问题时提交“通过”评审。
• 请求修改、关闭、合并、重跑流水线、删除分支和部署仍分别需要用户明确授权。
• 有任何仍然有效或无法验证的高可信代码问题、未解决讨论、冲突、必需检查未通过或足以影响结论的证据缺口时，不得提交“通过”评审。已经修复、失效或被用户明确接受/暂缓的评论不得长期保留为形式性阻断项，应先解决并回读，再判断是否通过。
• 不把 MR 已创建、分支已推送、评审已通过或流水线部分通过等同于已合并或已部署。

首审与复审契约

• 首次审查必须在同一轮覆盖当时 MR 的完整差异、全部讨论、冲突、必需检查和风险相称验证，集中提出所有已经确认的高可信问题。不得故意保留问题、只抽查局部，或把同一 patchset 拆成多轮逐步挑错。
• 首审结束时记录审查基线：目标分支 SHA、已审源 SHA/patchset、文件范围、测试与检查结果、已发布评论。优先从云效版本历史、评论和评审记录回读基线；不能可靠确定基线时，明确证据缺口，不假装已经完成增量复审。
• 复审先比较“上次已审源 SHA/patchset → 当前源 SHA/patchset”。审查范围仅包含：原评论对应修复、期间新增或改动的代码，以及验证这些变化所必需的直接影响链。不得重新扫描未变化且已经审过的旧代码，并以新发现的普通问题继续阻断开发。
• 只有两类情况允许复审新增阻断评论：修复或新增差异本身存在问题；修复或新增差异直接触发了与旧代码的可证实交互问题。评论必须说明属于“修复引入”还是“新增代码引入”，并锚定本轮变化的真实致因行。
• 对未变化旧代码的漏审问题，只有达到严重安全漏洞、数据损坏、不可逆业务错误等必须立即阻断的级别，才允许作为例外补充；必须明确承认这是首审遗漏、说明为何例外阻断，不得包装成普通复审发现。其余旧代码问题进入后续独立治理，不阻断当前复审。
• 如果当前版本仅包含针对既有评论的修复，没有其他新增差异；所有评论已被代码、测试和讨论证据确认解决；冲突、必需检查和风险相称验证均通过；且 SHA 未变化，则必须自动解决适用评论并立即提交“通过”评审，不得等待再次确认或开启新一轮全量审查。

审查流程

1. 读取 审查契约，解析逻辑 Profile、组织、仓库和 MR 编号；MR 链接、项目路由与本地 remote 不一致时停止。
2. 使用 $aliyun-profile 验证目标云效身份，再通过当前 CLI/插件的 --help 发现精确命令，不依赖历史命令形态。
3. 回读 MR 标题、描述、作者、源/目标分支、提交列表、完整文件差异、讨论、评审状态、冲突状态和自动化检查。识别这是首次审查还是复审：首次审查锁定当前完整差异；复审回读上次已审 SHA/patchset，并生成到当前版本的增量差异。逐条把未解决评论映射到最新 patchset 与当前业务决定，分类为“仍有效”“已修复”“已失效”“用户明确接受/暂缓”或“无法验证”；记录获取不到的证据，不能假设为空或通过。
4. 在不污染用户工作树的前提下审查代码。优先使用现有干净仓库；需要 checkout 时使用临时 worktree/临时目录，并保留用户未提交改动。
5. 运行与改动风险相称的测试、静态检查或构建。因环境缺失未运行时明确区分“未验证”和“失败”。
6. 对每个高可信问题，在当前 patchset 中选择真正导致问题的最小变更行，发布一条独立行内评论；评论包含严重度、问题机制、触发条件、用户影响和修复建议。首次审查集中发布全部已确认问题；复审只评论修复或新增差异引入的问题，并标明来源类别。不得重复已解决问题、把多个无关问题堆进一条评论，也不得为了满足行内形式而锚定无关代码。
7. 发布评论或解决评论前锁定组织、仓库、MR、最新 patchset 和源 SHA。对“已修复”“已失效”或“用户明确接受/暂缓”的评论直接标记已解决；对“仍有效”或“无法验证”的评论保持未解决。每次写入后按评论 ID 回读内容、文件、行号、patchset 和 resolved 状态。任一写入期间源 SHA 变化，停止剩余动作并从最新版本重新审查。
8. 评论处理完成后再次回读全部讨论。首次审查仅当完整差异和全部门禁均已覆盖时通过；复审仅当既有评论、从审查基线到当前版本的增量差异及其直接影响已覆盖时通过。风险相称验证通过、没有仍然有效或无法验证的高可信问题、没有未解决讨论或其他阻断项，且写前复核确认 SHA 未变化时，必须直接提交“通过”评审；随后回读评审人、评审状态、时间和最新 SHA。没有问题但证据不足时保持未通过并向用户说明缺口。
9. 最终结论注明审查模式及基线，例如“首审：目标 SHA / 源 SHA”或“复审：上次已审 SHA → 当前 SHA”；先列仍有效的行内发现，按严重度排序并给出文件/行号，同时汇总本轮自动解决的评论及依据。没有发现时明确说明已解决适用评论并通过评审，单列仍不影响本次代码结论的环境边界。未经另行授权不执行合并、关闭、重跑、删分支或部署。