Archon 交付工作流中的评审范围分类classify-review-scope 命令深度解析【免费下载链接】ArchonThe first open-source harness builder for AI coding. Make AI coding deterministic and repeatable.项目地址: https://gitcode.com/GitHub_Trending/archon3/Archon导读在 Archon 的 SDLC软件开发生命周期交付工作流中classify-review-scope是一个决定这份 PR 值不值得开启可选评审透镜的 AI 命令节点它不评审代码只从刚打开的 PR 本身判断errors静默失败与docs文档影响两个可选透镜是否应该被激活并以结构化 JSON 输出唯一被下游读取的判定结论。读完本文你将理解该命令的职责边界、每个可选透镜的狩猎目标、基于 PR 而非工作项的证据校准原则、以及它在 archon-deliver.yaml 中与resolve-review-scope、archon-review之间的完整协作链路。命令定位只分类不评审classify-review-scope.md位于 .archon/workflows/sdlc/deliver/commands/classify-review-scope.md开篇就划定了这条命令的边界它决定刚打开的 PR 是否值得开启任一可选评审透镜而不是替代评审本身。在完整评审full review中code、seams、simplify、tests 四个透镜每次都会运行只有errors和docs是需要人为或分类器选择的可选透镜。该命令运行在无人旁观的场景下——No one watches this run; your structured verdict is the only thing downstream nodes read即它的结构化判定是下游节点唯一依赖的输入因此判定必须建立在证据之上而非猜测。关键的行为约束有三点证据锚定在 PR 本身而非工作项需要读取当前分支的 PR 描述description和完整 diffghCLI 可用该分支的 PR 由更早的节点打开判断改动里实际有什么不得修改任何文件这是一个只读的判定节点判定必须来自所见的 diff不从工作流名称或 issue 主题推断范围。两个可选透镜分别猎取什么原文档对每个透镜给出了一句话式的狩猎定义这一定义与其下游透镜命令review-errors.md、review-docs.md的 charter 严格对齐透镜分类器眼中的目标下游透镜的完整 chartererrors被静默化的失败路径新的 catch / fallback / retry / 默认值代码、错误翻译、恢复行为以及任何失败变得与成功无法区分的地方一个真实失败穿过被改动的代码对必须反应的调用方、操作者或用户变得与成功无法区分docsdiff 改变的已发布文档shipped documentation改动之后有人按仓库文档操作会形成实质错误的预期或缺少某个必要步骤从源码结构看errors透镜的狩猎重点是失败身份的消失suppression pointdocs透镜的狩猎重点是文档与代码事实的漂移。分类器的任务不是深入分析这些缺陷而是判断这类缺陷是否可能存在于这个 diff 中——它回答的是要不要派专门透镜去查。校准原则成本不是约束浪费的注意力才是原文档给出了整个命令最核心的设计哲学Cost is not the constraint; wasted attention is.评审成本不是约束浪费的注意力才是。据此给出的校准规则分为两端小而不值得一个小型、机械、很可能正确的 diff——版本号提升、单行修复、重命名、纯测试调整——通常两个可选透镜都不需要大而值得一个实质性或高风险的 diff其失败类别合理地存在于其中时每个透镜各按其失败类别选择——diff 中确实包含新的失败路径就选errors改动已发布文档就选docs两端都不过度不为真实风险节省do not economize on real risk也不为风险的缺席凭空制造范围do not manufacture scope for its absence。每个透镜的判定测试完全相同这个 diff 是否包含其失败类别可能栖身的实质内容并且必须从亲眼所见的 diff 判断而不是从工作流名称或 issue 主题推断——这条约束直接呼应了命令开篇Ground the decision in the PR itself, not the work item的指令。值得注意的是review-scope命令.archon/workflows/sdlc/review/commands/review-scope.md在docs自动选择上复用了同一套校准即使 diff 触及文档如果它是小型、机械、很可能正确的改动版本号、单行修复、重命名、纯测试调整文档邻近的一笔改动也不足以赚取该透镜。声明格式每个回合都必须输出的结构化判定命令要求每个回合every turn声明一次输出格式严格结构化errors、docs—— 两个布尔值每个可选透镜一个reasons—— 一个对象{errors, docs}每个透镜一句话引用 diff 中决定该判定的证据判false时说明 diff 缺少什么判true时说明 diff 包含什么。reasons不是装饰它让下游以及未来的续跑能追踪判定的证据链避免无理由的开关。结构上还有一个重要的优先级规则操作者operator显式声明的errors设置会覆盖该判定auto才采纳分类器的判断。这一规则在 deliver 工作流中被实现为一个独立的确定性脚本节点见下节。源码级实现classify → resolve-scope → review 的协作链路classify 节点小型模型的二元判定在 archon-deliver.yaml 中classify节点定义如下约第 92–111 行- id: classify command: classify-review-scope model: small depends_on: [pr] mutates_checkout: false output_type: review-scope output_format: type: object properties: errors: { type: boolean } docs: { type: boolean } reasons: type: object properties: errors: { type: string } docs: { type: string } required: [errors, docs] required: [errors, docs, reasons]几个关键实现事实模型分级为small工作流注释明确说明由于工作流顶层不声明模型从 diff 中选择两个布尔值是小规模工作因此分配小模型以节省成本——这与文档成本不是约束的表述相互印证这里省的是推理规模而不是评审覆盖mutates_checkout: false与命令文档不修改任何文件的约束一致depends_on: [pr]分类必须发生在 PR 节点之后因为diff 是 PR 存在之前不存在的信息——工作流注释直言评审范围必须从实际 PR 判定而不是在启动时盲目声明the diff is information that does not exist until the PR does结构化输出校验output_format强制errors/docs为布尔、reasons为双字符串对象任一缺失都会使节点失败而非悄悄通过。resolve-scope 节点操作者覆盖的确定性边界分类器的判断不直接控制errors透镜——中间隔着 resolve-review-scope.pydef resolve(forced: str, judged: str, lens: str) - str: if forced in (true, false): return forced if judged not in (true, false): print(fresolve-review-scope: classifier returned an invalid {lens} verdict: {judged!r}, ...) raise SystemExit(1) return judged其逻辑完全对应命令文档的优先级规则操作者通过errors输入传入true/false时强制值直接胜出forced 优先操作者传auto默认值时采纳分类器对errors的判定judged分类器若返回非布尔值脚本报错退出——错误的判定宁可让节点失败也不能污染下游的评审门控。在archon-deliver.yaml中resolve-scope的with只接收$classify.output.errorsc_errors输出字符串形式的{errors:true/false}随后作为review节点的errors输入。工作流注释对此的总结是确定性合并发生在边界显式的 true/false 胜过分类器auto 采纳其判断。review 节点透镜门控与 docs 的双通道errors与docs的生效路径在 archon-review.yaml 中被分开处理errors 透镜门控条件为$INPUTS.errors true——即resolve-scope合并后的值docs 透镜门控条件为$INPUTS.docs true || ($INPUTS.docs auto $scope.output.docs true)——docs输入默认是auto此时由review-scope命令从 diff 自动选择而deliver工作流把docs绑定为$classify.output.docs即分类器的原始判定不经 resolve 覆盖与errors形成对称的双通道errors 走分类器 操作者覆盖通道docs 走分类器直通通道。classify的输出docs因此成为 docs 透镜门的唯一开关——这也解释了为什么命令文档强调reasons中必须引用 diff 证据docs: true意味着下游会额外启动一个只读评审透镜。续跑continuation模式下透镜如何被消费archon-review的续跑模式存在prior_report时由 resolve-review-mode.py 决定此时只用一个续跑评审者核验先前 findings 并评审修正增量跳过所有 specialist 透镜——archon-deliver.yaml的 recheck 节点注释明确写道Continuation mode owns coverage and skips every specialist, regardless of these conditional-lens bindings. 也就是说分类器判定的可选透镜只作用于首轮完整评审修正轮次不再重新 fan-out。测试与验证fixture 如何守护分类器绑定SDLC 包遵循 .archon/workflows/sdlc/README.md 的守卫原则——如果该包的 fixture 套件无法演练这个守卫它就不是守卫而是注释。分类器绑定由 dry-run fixture 守护selective-review.stubs.yaml 展示了分类器选择docs、errors判定被 resolve 合并的场景classify: errors: false docs: true reasons: errors: stub: no failure paths docs: stub: changed shipped docs need impact review resolve-scope: {errors:false} ... fixture: expect: completed reached: [review__code, review__seams, review__simplify, review__tests, review__docs]关键验证点分类器输出errors: false、docs: true时resolve-scope将errors合并为false而docs保持true直通fixture 的reached断言列出了最终运行的透镜集合四个默认透镜全部运行加上被分类器选中的review__docs而errors透镜review__errors未在列表中——证实了分类器判定直接控制透镜是否实际执行fixture 注释说明loader test protects the classifier-binding seam itself即绑定接缝本身另有专门的 loader 测试覆盖。配套的其他 fixture如 red-introduced.stubs.yaml则验证了相反方向的守卫当实现引入的红introduced red出现时gate-green脚本被刻意保持未 stub真实脚本必须拒绝——这类守卫与分类无关但共同构成了 deliver 尾部门控必须可被 fixture 演练的工程纪律。设计要点回顾与最佳实践综合命令文档与实现源码classify-review-scope沉淀出的可复用设计原则值得单列分类与评审解耦分类器只做二元判定并附带一句话证据reasons把查证留给专业透镜避免小模型承担超出规模的评审工作证据时效性范围必须等 PR 存在后才能判定depends_on: [pr]diff 是 PR 打开前不存在的信息——任何提前声明范围的做法都会引入猜测人机优先级清晰操作者的显式true/false在任何时候都覆盖分类器auto才采纳分类器覆盖发生在确定性脚本边界resolve-review-scope而不是靠提示词约束假阳性与假阴性同样不可取不为真实风险节省diff 含失败路径就选 errors也不为缺席的风险制造范围机械性小改动不配透镜不可观察的判定必须结构化无人旁观的运行中只有结构化的布尔 reasons 对象是下游可消费的契约缺失字段会让节点失败而非静默通过。在 Archon 的 SDLC 包中classify-review-scope是一个典型的低成本决策节点用一个小模型 结构化输出 确定性边界脚本把这个 diff 值不值得多开两个评审透镜这件原本需要人工判断的事变成了一条可测试、可覆盖、可续跑的自动链路。【免费下载链接】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 交付工作流中的评审范围分类：classify-review-scope 命令深度解析
Archon 交付工作流中的评审范围分类classify-review-scope 命令深度解析【免费下载链接】ArchonThe first open-source harness builder for AI coding. Make AI coding deterministic and repeatable.项目地址: https://gitcode.com/GitHub_Trending/archon3/Archon导读在 Archon 的 SDLC软件开发生命周期交付工作流中classify-review-scope是一个决定这份 PR 值不值得开启可选评审透镜的 AI 命令节点它不评审代码只从刚打开的 PR 本身判断errors静默失败与docs文档影响两个可选透镜是否应该被激活并以结构化 JSON 输出唯一被下游读取的判定结论。读完本文你将理解该命令的职责边界、每个可选透镜的狩猎目标、基于 PR 而非工作项的证据校准原则、以及它在 archon-deliver.yaml 中与resolve-review-scope、archon-review之间的完整协作链路。命令定位只分类不评审classify-review-scope.md位于 .archon/workflows/sdlc/deliver/commands/classify-review-scope.md开篇就划定了这条命令的边界它决定刚打开的 PR 是否值得开启任一可选评审透镜而不是替代评审本身。在完整评审full review中code、seams、simplify、tests 四个透镜每次都会运行只有errors和docs是需要人为或分类器选择的可选透镜。该命令运行在无人旁观的场景下——No one watches this run; your structured verdict is the only thing downstream nodes read即它的结构化判定是下游节点唯一依赖的输入因此判定必须建立在证据之上而非猜测。关键的行为约束有三点证据锚定在 PR 本身而非工作项需要读取当前分支的 PR 描述description和完整 diffghCLI 可用该分支的 PR 由更早的节点打开判断改动里实际有什么不得修改任何文件这是一个只读的判定节点判定必须来自所见的 diff不从工作流名称或 issue 主题推断范围。两个可选透镜分别猎取什么原文档对每个透镜给出了一句话式的狩猎定义这一定义与其下游透镜命令review-errors.md、review-docs.md的 charter 严格对齐透镜分类器眼中的目标下游透镜的完整 chartererrors被静默化的失败路径新的 catch / fallback / retry / 默认值代码、错误翻译、恢复行为以及任何失败变得与成功无法区分的地方一个真实失败穿过被改动的代码对必须反应的调用方、操作者或用户变得与成功无法区分docsdiff 改变的已发布文档shipped documentation改动之后有人按仓库文档操作会形成实质错误的预期或缺少某个必要步骤从源码结构看errors透镜的狩猎重点是失败身份的消失suppression pointdocs透镜的狩猎重点是文档与代码事实的漂移。分类器的任务不是深入分析这些缺陷而是判断这类缺陷是否可能存在于这个 diff 中——它回答的是要不要派专门透镜去查。校准原则成本不是约束浪费的注意力才是原文档给出了整个命令最核心的设计哲学Cost is not the constraint; wasted attention is.评审成本不是约束浪费的注意力才是。据此给出的校准规则分为两端小而不值得一个小型、机械、很可能正确的 diff——版本号提升、单行修复、重命名、纯测试调整——通常两个可选透镜都不需要大而值得一个实质性或高风险的 diff其失败类别合理地存在于其中时每个透镜各按其失败类别选择——diff 中确实包含新的失败路径就选errors改动已发布文档就选docs两端都不过度不为真实风险节省do not economize on real risk也不为风险的缺席凭空制造范围do not manufacture scope for its absence。每个透镜的判定测试完全相同这个 diff 是否包含其失败类别可能栖身的实质内容并且必须从亲眼所见的 diff 判断而不是从工作流名称或 issue 主题推断——这条约束直接呼应了命令开篇Ground the decision in the PR itself, not the work item的指令。值得注意的是review-scope命令.archon/workflows/sdlc/review/commands/review-scope.md在docs自动选择上复用了同一套校准即使 diff 触及文档如果它是小型、机械、很可能正确的改动版本号、单行修复、重命名、纯测试调整文档邻近的一笔改动也不足以赚取该透镜。声明格式每个回合都必须输出的结构化判定命令要求每个回合every turn声明一次输出格式严格结构化errors、docs—— 两个布尔值每个可选透镜一个reasons—— 一个对象{errors, docs}每个透镜一句话引用 diff 中决定该判定的证据判false时说明 diff 缺少什么判true时说明 diff 包含什么。reasons不是装饰它让下游以及未来的续跑能追踪判定的证据链避免无理由的开关。结构上还有一个重要的优先级规则操作者operator显式声明的errors设置会覆盖该判定auto才采纳分类器的判断。这一规则在 deliver 工作流中被实现为一个独立的确定性脚本节点见下节。源码级实现classify → resolve-scope → review 的协作链路classify 节点小型模型的二元判定在 archon-deliver.yaml 中classify节点定义如下约第 92–111 行- id: classify command: classify-review-scope model: small depends_on: [pr] mutates_checkout: false output_type: review-scope output_format: type: object properties: errors: { type: boolean } docs: { type: boolean } reasons: type: object properties: errors: { type: string } docs: { type: string } required: [errors, docs] required: [errors, docs, reasons]几个关键实现事实模型分级为small工作流注释明确说明由于工作流顶层不声明模型从 diff 中选择两个布尔值是小规模工作因此分配小模型以节省成本——这与文档成本不是约束的表述相互印证这里省的是推理规模而不是评审覆盖mutates_checkout: false与命令文档不修改任何文件的约束一致depends_on: [pr]分类必须发生在 PR 节点之后因为diff 是 PR 存在之前不存在的信息——工作流注释直言评审范围必须从实际 PR 判定而不是在启动时盲目声明the diff is information that does not exist until the PR does结构化输出校验output_format强制errors/docs为布尔、reasons为双字符串对象任一缺失都会使节点失败而非悄悄通过。resolve-scope 节点操作者覆盖的确定性边界分类器的判断不直接控制errors透镜——中间隔着 resolve-review-scope.pydef resolve(forced: str, judged: str, lens: str) - str: if forced in (true, false): return forced if judged not in (true, false): print(fresolve-review-scope: classifier returned an invalid {lens} verdict: {judged!r}, ...) raise SystemExit(1) return judged其逻辑完全对应命令文档的优先级规则操作者通过errors输入传入true/false时强制值直接胜出forced 优先操作者传auto默认值时采纳分类器对errors的判定judged分类器若返回非布尔值脚本报错退出——错误的判定宁可让节点失败也不能污染下游的评审门控。在archon-deliver.yaml中resolve-scope的with只接收$classify.output.errorsc_errors输出字符串形式的{errors:true/false}随后作为review节点的errors输入。工作流注释对此的总结是确定性合并发生在边界显式的 true/false 胜过分类器auto 采纳其判断。review 节点透镜门控与 docs 的双通道errors与docs的生效路径在 archon-review.yaml 中被分开处理errors 透镜门控条件为$INPUTS.errors true——即resolve-scope合并后的值docs 透镜门控条件为$INPUTS.docs true || ($INPUTS.docs auto $scope.output.docs true)——docs输入默认是auto此时由review-scope命令从 diff 自动选择而deliver工作流把docs绑定为$classify.output.docs即分类器的原始判定不经 resolve 覆盖与errors形成对称的双通道errors 走分类器 操作者覆盖通道docs 走分类器直通通道。classify的输出docs因此成为 docs 透镜门的唯一开关——这也解释了为什么命令文档强调reasons中必须引用 diff 证据docs: true意味着下游会额外启动一个只读评审透镜。续跑continuation模式下透镜如何被消费archon-review的续跑模式存在prior_report时由 resolve-review-mode.py 决定此时只用一个续跑评审者核验先前 findings 并评审修正增量跳过所有 specialist 透镜——archon-deliver.yaml的 recheck 节点注释明确写道Continuation mode owns coverage and skips every specialist, regardless of these conditional-lens bindings. 也就是说分类器判定的可选透镜只作用于首轮完整评审修正轮次不再重新 fan-out。测试与验证fixture 如何守护分类器绑定SDLC 包遵循 .archon/workflows/sdlc/README.md 的守卫原则——如果该包的 fixture 套件无法演练这个守卫它就不是守卫而是注释。分类器绑定由 dry-run fixture 守护selective-review.stubs.yaml 展示了分类器选择docs、errors判定被 resolve 合并的场景classify: errors: false docs: true reasons: errors: stub: no failure paths docs: stub: changed shipped docs need impact review resolve-scope: {errors:false} ... fixture: expect: completed reached: [review__code, review__seams, review__simplify, review__tests, review__docs]关键验证点分类器输出errors: false、docs: true时resolve-scope将errors合并为false而docs保持true直通fixture 的reached断言列出了最终运行的透镜集合四个默认透镜全部运行加上被分类器选中的review__docs而errors透镜review__errors未在列表中——证实了分类器判定直接控制透镜是否实际执行fixture 注释说明loader test protects the classifier-binding seam itself即绑定接缝本身另有专门的 loader 测试覆盖。配套的其他 fixture如 red-introduced.stubs.yaml则验证了相反方向的守卫当实现引入的红introduced red出现时gate-green脚本被刻意保持未 stub真实脚本必须拒绝——这类守卫与分类无关但共同构成了 deliver 尾部门控必须可被 fixture 演练的工程纪律。设计要点回顾与最佳实践综合命令文档与实现源码classify-review-scope沉淀出的可复用设计原则值得单列分类与评审解耦分类器只做二元判定并附带一句话证据reasons把查证留给专业透镜避免小模型承担超出规模的评审工作证据时效性范围必须等 PR 存在后才能判定depends_on: [pr]diff 是 PR 打开前不存在的信息——任何提前声明范围的做法都会引入猜测人机优先级清晰操作者的显式true/false在任何时候都覆盖分类器auto才采纳分类器覆盖发生在确定性脚本边界resolve-review-scope而不是靠提示词约束假阳性与假阴性同样不可取不为真实风险节省diff 含失败路径就选 errors也不为缺席的风险制造范围机械性小改动不配透镜不可观察的判定必须结构化无人旁观的运行中只有结构化的布尔 reasons 对象是下游可消费的契约缺失字段会让节点失败而非静默通过。在 Archon 的 SDLC 包中classify-review-scope是一个典型的低成本决策节点用一个小模型 结构化输出 确定性边界脚本把这个 diff 值不值得多开两个评审透镜这件原本需要人工判断的事变成了一条可测试、可覆盖、可续跑的自动链路。【免费下载链接】ArchonThe first open-source harness builder for AI coding. Make AI coding deterministic and repeatable.项目地址: https://gitcode.com/GitHub_Trending/archon3/Archon创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考