Archon SDLC 评审范围锚定深入解析 review-scope 命令的目标解析与契约边界【免费下载链接】ArchonThe first open-source harness builder for AI coding. Make AI coding deterministic and repeatable.项目地址: https://gitcode.com/GitHub_Trending/archon3/Archon导读review-scope是 Archon 仓库 SDLC 评审工作流 的第一道闸门它不评判任何代码只负责把这一轮评审到底看什么精确地写进scope.md供后续所有专业评审视角code、seams、simplify、tests、errors、docs与最终合成者共用。读完本文你将掌握 review-scope 如何处理 PR 号、URL、分支与工作区差异四种评审目标如何从工作订单或 PR 正文中提取已接受契约如何在多轮修正循环中通过 light mode 只评审增量以及产出 scope.md 的六段式结构与验证清单。一、review-scope 在评审工作流中的定位在 archon-review.yaml 中评审流程被编排为mode → scope → 各专业 lens → synthesize的顺序mode节点运行 resolve-review-mode.py根据是否存在prior_report判定本轮是full review还是continuationscope节点调用review-scope命令产出$ARTIFACTS_DIR/review/scope.md并返回布尔值docs作为 docs lens 是否启用的依据各专业 lens代码、接缝、简化、测试、错误、文档以 scope.md 描述的精确 diff 为唯一评审对象synthesize节点review-synthesize.md汇总各 lens 报告并给出ready/action判定。scope 节点使用的context: fresh与output_format要求输出docs布尔值说明它是一次自包含的预检它的全部职责就是把目标写清楚下游 agent 不再自行猜测评审对象。正因如此archon-review.yaml 中的review-complete屏障对synthesize单独强制要求scope必须先成功——评审可以容忍某个专业 lens 失败降级但绝不能在范围未锚定的情况下开始合成。二、输入解析四条信息源及其优先级review-scope 接收四类输入来源与优先级如下输入含义为空时的处理$INPUTS.scope请求的评审范围PR 号 / URL / 分支 / 空可能为空此时按工作区差异解析目标$INPUTS.prior_report上一轮评审报告的路径为空表示首轮全量评审非空则进入 light mode$INPUTS.work_order已接受的实现工作订单可能为空独立评审此时改用 PR 正文作为契约$ARGUMENTS本次运行的触发消息可以收窄或覆盖上述所有输入注意$ARGUMENTS的优先级声明The runs trigger message, which may narrow or override the above——用户在下达评审指令时的措辞具有最高解释权这体现了命令让目标精确的核心意图任何上下文都不得让评审对象变得含糊。三、目标解析三种输入的三种收敛路径3.1 裸 PR 号只认记录在案的那个 PR当$INPUTS.scope是一个裸 PR 号时说明 delivery 阶段已经记录过它。review-scope 要求从originremote 推导规范化的owner/repo但不把原始 URL 写进任何工件防止 token 泄漏这与 SDLC 包约定旧版 scope 命令仍保留在默认命令集中的 Phase 1 逻辑一致先读$ARTIFACTS_DIR/.pr-number再从$ARGUMENTS提取数字最后退回gh pr view按分支查询。区别在于 review-scope 将这一判定收敛为PR 优先否则工作区差异而旧命令仅处理 PR。四、已接受契约Accepted Contract的解析评审不是无边界挑错而是对照这个改动承诺了什么来判定。契约的解析按三级回退work_order非空完整读取它就是实现所接受的契约。其中要求的结果、显式非目标non-goals和边界以散文形式原样保留禁止用脚本、正则或关键词提取——机器抽取会丢失语境的细微差别work_order为空且目标是 PR以 PR 正文中的 problem/outcome 与显式 scope 或非目标作为独立评审契约且不得从改动文件反推更宽泛的承诺两者都没有显式边界明确声明本轮评审使用请求的范围 仓库契约不发明非目标。这条规则的实战意义在于如果某改动刻意不做 X比如迁移脚本不处理旧数据回填只要 work_order 或 PR 正文声明了X 不在范围内评审者就不能把缺 X 报成缺陷。旧版命令同样在 Phase 3.5 强调从plan-context.md的 NOT Building 段或investigation.md的 OUT OF SCOPE 段提取有意排除项并标注不要把这些标成 bug——review-scope 则把同样的边界语义提升为独立且不可脚本化的契约解析步骤。五、docs lens 的自动选择规则review-scope 的返回值为docs布尔值用于决定 docs 专业 lens 是否启用。选择逻辑当被评审的 diff 改动已发布的文档shipped documentation时docs为true但若该 diff小而机械且大概率正确——版本号 bump、一行修复、重命名、纯测试调整——仅靠碰了文档不配获得 docs lens该选择仅在工作流的docs输入为auto时生效显式输入true/false直接覆盖自动判定。这一规则在 archon-review.yaml 的 when 条件中落地$INPUTS.docs true或$INPUTS.docs auto $scope.output.docs true才运行review-docs。dry-run 测试 docs-auto-selected.stubs.yaml 与 docs-auto-declined.stubs.yaml 分别覆盖了auto 下命中文档 lens与被拒两条路径。注意从源码结构看该选择规则在 continuation 模式下并不触发 fan-out因为此时所有专业 lens 都会被整体跳过。六、Light mode多轮修正循环中的增量评审当$INPUTS.prior_report提供路径时进入 light mode必须存在且完整读取缺失的 prior report 是断裂的续接契约——必须报错并点名该路径绝不静默降级为全量评审提取其记录的reviewed-head cursor上轮评审的 head SHAPR 目标本轮 diff 仅是增量git diff cursor..HEAD工作区差异目标该增量加上任何未提交改动上一份报告是先前发现与覆盖范围的唯一拥有者scope.md 不得复制或重建旧发现。这个模式是成本与正确性的平衡点多轮修正如 deliver 工作流中 repeated review rounds时若每轮都全量重跑所有 lens成本随轮次线性增长light mode 让单名续接评审者验证旧发现、只评审修正增量。配套的 resolve-review-mode.py 只做一件事prior_report非空且文件存在则输出{continuation: true}文件缺失直接SystemExit报错。fixture continuation.stubs.yaml 明确验证continuation 轮不运行任何专业 lens即使 scope 节点判定docs: true整个 fan-out 仍被when: continuation false全部挡下。七、scope.md 的结构六段式范围契约review-scope 的输出是$ARTIFACTS_DIR/review/scope.md包含六个强制段落Accepted contract——必需结果后跟显式非目标或边界必须声明来源work order / PR body / 请求范围与仓库契约Target——PR 引用或 working diff、基础分支、被评审的 head SHA它将成为下一轮的 cursorMode——full review或light (delta since cursor)Changed files——路径列表 每个文件的变更形态added/modified/deleted、大致规模The diff to review——小 diff 直接内联大 diff 给出评审者执行的确切命令git diff range、gh pr diff nPrior report——仅续接模式其路径与 reviewed-head cursor不得复制其发现或覆盖范围。从第 2 点可见 scope.md 同时扮演评审契约与轮次游标双重角色head SHA 被 review-synthesize.md 原样写进报告Reviewed head SHA: from scope.md, stated exactly; this is the next rounds cursor构成多轮循环的状态链。作为对照旧版 archon-pr-review-scope.md 的 scope manifest 还包含 Pre-Review Status合并冲突、CI 状态、落后基础分支数、草稿状态、规模告警与 Review Focus Areas、CLAUDE.md 规则等更重的上下文段——新版 review-scope 把这些决策内化到目标解析与 docs 选择中scope.md 本身则收敛为评审者需要精确知道的最小契约。八、完成前的验证清单命令在收尾前强制自检任何一项不满足都不算完成$ARTIFACTS_DIR/review/scope.md存在其中点名了 accepted contract 与 head SHAscope.md 中给出的 diff 命令在当前 checkout 中实际能产出输出防止写死一段无法执行的命令返回docs布尔值供工作流门控 docs lens。最后一步diff 命令实跑可产出是防呆设计scope.md 若只是纸面描述而命令失效下游评审者将无物可审。九、从 scope 到 verdict边界如何传导review-scope 的边界语义会贯穿整条评审链值得理解其传导方式评审对象传导lens 只评审 scope.md 描述的 diffPR 模式下本地未提交改动天然出界契约传导scope.md 的 accepted contract 是 review-synthesize.md 判定 severity 的依据——A defect outside that contract is an adjacent discovery跨出显式边界才能成立replan状态传导head SHA 成为下一轮 cursorprior report 成为下一轮 light mode 的输入形成scope → lens → synthesize → correction → scope的收敛循环。这种设计把评审什么从怎么评判中彻底剥离范围一旦锚定就不再受模型临场发挥影响——这正是 Archon 追求让 AI 编码确定且可重复在评审环节的具体体现。若要实际运行这套流程可在项目根目录通过archon review pr-number|url之类的触发词调用 archon-review 工作流scope输入留空时评审当前工作区差异并在$ARTIFACTS_DIR/review/目录下检查 scope.md、各 lens 报告与最终 report.md。【免费下载链接】ArchonThe first open-source harness builder for AI coding. Make AI coding deterministic and repeatable.项目地址: https://gitcode.com/GitHub_Trending/archon3/Archon创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Archon SDLC 评审范围锚定：深入解析 review-scope 命令的目标解析与契约边界
Archon SDLC 评审范围锚定深入解析 review-scope 命令的目标解析与契约边界【免费下载链接】ArchonThe first open-source harness builder for AI coding. Make AI coding deterministic and repeatable.项目地址: https://gitcode.com/GitHub_Trending/archon3/Archon导读review-scope是 Archon 仓库 SDLC 评审工作流 的第一道闸门它不评判任何代码只负责把这一轮评审到底看什么精确地写进scope.md供后续所有专业评审视角code、seams、simplify、tests、errors、docs与最终合成者共用。读完本文你将掌握 review-scope 如何处理 PR 号、URL、分支与工作区差异四种评审目标如何从工作订单或 PR 正文中提取已接受契约如何在多轮修正循环中通过 light mode 只评审增量以及产出 scope.md 的六段式结构与验证清单。一、review-scope 在评审工作流中的定位在 archon-review.yaml 中评审流程被编排为mode → scope → 各专业 lens → synthesize的顺序mode节点运行 resolve-review-mode.py根据是否存在prior_report判定本轮是full review还是continuationscope节点调用review-scope命令产出$ARTIFACTS_DIR/review/scope.md并返回布尔值docs作为 docs lens 是否启用的依据各专业 lens代码、接缝、简化、测试、错误、文档以 scope.md 描述的精确 diff 为唯一评审对象synthesize节点review-synthesize.md汇总各 lens 报告并给出ready/action判定。scope 节点使用的context: fresh与output_format要求输出docs布尔值说明它是一次自包含的预检它的全部职责就是把目标写清楚下游 agent 不再自行猜测评审对象。正因如此archon-review.yaml 中的review-complete屏障对synthesize单独强制要求scope必须先成功——评审可以容忍某个专业 lens 失败降级但绝不能在范围未锚定的情况下开始合成。二、输入解析四条信息源及其优先级review-scope 接收四类输入来源与优先级如下输入含义为空时的处理$INPUTS.scope请求的评审范围PR 号 / URL / 分支 / 空可能为空此时按工作区差异解析目标$INPUTS.prior_report上一轮评审报告的路径为空表示首轮全量评审非空则进入 light mode$INPUTS.work_order已接受的实现工作订单可能为空独立评审此时改用 PR 正文作为契约$ARGUMENTS本次运行的触发消息可以收窄或覆盖上述所有输入注意$ARGUMENTS的优先级声明The runs trigger message, which may narrow or override the above——用户在下达评审指令时的措辞具有最高解释权这体现了命令让目标精确的核心意图任何上下文都不得让评审对象变得含糊。三、目标解析三种输入的三种收敛路径3.1 裸 PR 号只认记录在案的那个 PR当$INPUTS.scope是一个裸 PR 号时说明 delivery 阶段已经记录过它。review-scope 要求从originremote 推导规范化的owner/repo但不把原始 URL 写进任何工件防止 token 泄漏这与 SDLC 包约定旧版 scope 命令仍保留在默认命令集中的 Phase 1 逻辑一致先读$ARTIFACTS_DIR/.pr-number再从$ARGUMENTS提取数字最后退回gh pr view按分支查询。区别在于 review-scope 将这一判定收敛为PR 优先否则工作区差异而旧命令仅处理 PR。四、已接受契约Accepted Contract的解析评审不是无边界挑错而是对照这个改动承诺了什么来判定。契约的解析按三级回退work_order非空完整读取它就是实现所接受的契约。其中要求的结果、显式非目标non-goals和边界以散文形式原样保留禁止用脚本、正则或关键词提取——机器抽取会丢失语境的细微差别work_order为空且目标是 PR以 PR 正文中的 problem/outcome 与显式 scope 或非目标作为独立评审契约且不得从改动文件反推更宽泛的承诺两者都没有显式边界明确声明本轮评审使用请求的范围 仓库契约不发明非目标。这条规则的实战意义在于如果某改动刻意不做 X比如迁移脚本不处理旧数据回填只要 work_order 或 PR 正文声明了X 不在范围内评审者就不能把缺 X 报成缺陷。旧版命令同样在 Phase 3.5 强调从plan-context.md的 NOT Building 段或investigation.md的 OUT OF SCOPE 段提取有意排除项并标注不要把这些标成 bug——review-scope 则把同样的边界语义提升为独立且不可脚本化的契约解析步骤。五、docs lens 的自动选择规则review-scope 的返回值为docs布尔值用于决定 docs 专业 lens 是否启用。选择逻辑当被评审的 diff 改动已发布的文档shipped documentation时docs为true但若该 diff小而机械且大概率正确——版本号 bump、一行修复、重命名、纯测试调整——仅靠碰了文档不配获得 docs lens该选择仅在工作流的docs输入为auto时生效显式输入true/false直接覆盖自动判定。这一规则在 archon-review.yaml 的 when 条件中落地$INPUTS.docs true或$INPUTS.docs auto $scope.output.docs true才运行review-docs。dry-run 测试 docs-auto-selected.stubs.yaml 与 docs-auto-declined.stubs.yaml 分别覆盖了auto 下命中文档 lens与被拒两条路径。注意从源码结构看该选择规则在 continuation 模式下并不触发 fan-out因为此时所有专业 lens 都会被整体跳过。六、Light mode多轮修正循环中的增量评审当$INPUTS.prior_report提供路径时进入 light mode必须存在且完整读取缺失的 prior report 是断裂的续接契约——必须报错并点名该路径绝不静默降级为全量评审提取其记录的reviewed-head cursor上轮评审的 head SHAPR 目标本轮 diff 仅是增量git diff cursor..HEAD工作区差异目标该增量加上任何未提交改动上一份报告是先前发现与覆盖范围的唯一拥有者scope.md 不得复制或重建旧发现。这个模式是成本与正确性的平衡点多轮修正如 deliver 工作流中 repeated review rounds时若每轮都全量重跑所有 lens成本随轮次线性增长light mode 让单名续接评审者验证旧发现、只评审修正增量。配套的 resolve-review-mode.py 只做一件事prior_report非空且文件存在则输出{continuation: true}文件缺失直接SystemExit报错。fixture continuation.stubs.yaml 明确验证continuation 轮不运行任何专业 lens即使 scope 节点判定docs: true整个 fan-out 仍被when: continuation false全部挡下。七、scope.md 的结构六段式范围契约review-scope 的输出是$ARTIFACTS_DIR/review/scope.md包含六个强制段落Accepted contract——必需结果后跟显式非目标或边界必须声明来源work order / PR body / 请求范围与仓库契约Target——PR 引用或 working diff、基础分支、被评审的 head SHA它将成为下一轮的 cursorMode——full review或light (delta since cursor)Changed files——路径列表 每个文件的变更形态added/modified/deleted、大致规模The diff to review——小 diff 直接内联大 diff 给出评审者执行的确切命令git diff range、gh pr diff nPrior report——仅续接模式其路径与 reviewed-head cursor不得复制其发现或覆盖范围。从第 2 点可见 scope.md 同时扮演评审契约与轮次游标双重角色head SHA 被 review-synthesize.md 原样写进报告Reviewed head SHA: from scope.md, stated exactly; this is the next rounds cursor构成多轮循环的状态链。作为对照旧版 archon-pr-review-scope.md 的 scope manifest 还包含 Pre-Review Status合并冲突、CI 状态、落后基础分支数、草稿状态、规模告警与 Review Focus Areas、CLAUDE.md 规则等更重的上下文段——新版 review-scope 把这些决策内化到目标解析与 docs 选择中scope.md 本身则收敛为评审者需要精确知道的最小契约。八、完成前的验证清单命令在收尾前强制自检任何一项不满足都不算完成$ARTIFACTS_DIR/review/scope.md存在其中点名了 accepted contract 与 head SHAscope.md 中给出的 diff 命令在当前 checkout 中实际能产出输出防止写死一段无法执行的命令返回docs布尔值供工作流门控 docs lens。最后一步diff 命令实跑可产出是防呆设计scope.md 若只是纸面描述而命令失效下游评审者将无物可审。九、从 scope 到 verdict边界如何传导review-scope 的边界语义会贯穿整条评审链值得理解其传导方式评审对象传导lens 只评审 scope.md 描述的 diffPR 模式下本地未提交改动天然出界契约传导scope.md 的 accepted contract 是 review-synthesize.md 判定 severity 的依据——A defect outside that contract is an adjacent discovery跨出显式边界才能成立replan状态传导head SHA 成为下一轮 cursorprior report 成为下一轮 light mode 的输入形成scope → lens → synthesize → correction → scope的收敛循环。这种设计把评审什么从怎么评判中彻底剥离范围一旦锚定就不再受模型临场发挥影响——这正是 Archon 追求让 AI 编码确定且可重复在评审环节的具体体现。若要实际运行这套流程可在项目根目录通过archon review pr-number|url之类的触发词调用 archon-review 工作流scope输入留空时评审当前工作区差异并在$ARTIFACTS_DIR/review/目录下检查 scope.md、各 lens 报告与最终 report.md。【免费下载链接】ArchonThe first open-source harness builder for AI coding. Make AI coding deterministic and repeatable.项目地址: https://gitcode.com/GitHub_Trending/archon3/Archon创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考