worktrack-gate-skill

name	worktrack-gate-skill
description	当 Harness 处于 WorktrackScope.judging，且需要基于现有证据完成一轮限定范围关卡判定，而不重新执行工作或刷新代码仓库状态时，使用这个技能。

关卡技能

概览

本技能实现 WorktrackScope.Judge 状态转移算子，对应 Harness 控制回路中的裁决阶段。它负责基于三个正交校验面（implementation/validation/policy）的证据，判断"当前状态是否允许推进"，生成 verdict 并决定允许的下一路由。

本 gate 基于三个正交校验面（implementation/validation/policy）的证据做裁决，不直接消费 Self-Review Record 和 Single-Acceptance Verdict。

注意：Self-Review Record 和 Single-Acceptance Verdict 由 worktrack-close-skill 在 Close 阶段的 pre-closeout checks 中产出，并被 Close 阶段内的 Closeout Gate（非本 Worktrack Gate）消费。详见 harness-skill 的 closeout pipeline section。

当 Harness 已经掌握当前轮次的证据，并需要在 WorktrackScope.judging 内完成一轮限定范围判定时，使用这个技能。

这个技能会为一轮 通用高能力模型 SubAgent 打包最小关卡上下文，评估当前证据维度，推导当前 实现/验证/策略 判定层面，吸收限定范围的低严重度噪声，并返回结构化判定结果与允许的下一步路由。

何时使用

当需要基于本轮证据判定通过、失败或停止时，使用这个技能：

• 审查、测试与规则检查证据已经被收集或汇总
• Harness 需要基于现有产物得到当前轮次的关卡判定结果
• 证据可能不完整、互相矛盾，或在不同层面之间分布不均
• 证据中可能包含大量低严重度发现；除非它们形成跨层面或系统性模式，否则应保持为残留项
• 重复症状可能表明存在上游约定或治理问题，而不是又一个纯代码修复循环
• 系统必须在 集成、恢复 或继续阻塞之间做出选择
• 判定必须严格保持在当前 工作追踪 的限定范围内

工作流

1. 载入本轮所需的最小 WorktrackScope 产物和当前维度证据。
2. 为限定范围的 通用高能力模型 SubAgent 构建一份 关卡任务简报 和一份 关卡信息包。
3. 在判定本轮之前，先验证所需证据维度：
   • 审查
   • 测试
   • 策略
   • 若存在 review/Gate/Closeout/Self-Review/Single-Acceptance feedback 之后的 Worktrack 更新，还必须验证 post-review/post-gate updates 的 updated_files_or_artifacts 与 post_update_validation_timestamp 已在更新后证据中出现。
   • task_producing_subagent 与 review_acceptance_subagent 的 evidence_provenance 已分开记录；producer_carrier_ref 不得被复用为独立的 review_carrier_ref / acceptance_carrier_ref，除非证据显式标记 current-carrier fallback 并给出机器可检查 fallback_reason_code。
4. 在三个必需层面上评估当前轮次：
   • 实现关卡
   • 验证关卡
   • 策略关卡
   • 其中 实现关卡 接收 review evidence 时，必须确认审查维度是否覆盖代码性能、Repo 架构、代码安全、代码质量与测试 review；对当前变更不适用的维度，应接收明确的 不适用 理由。
5. 在给出整体判定结果前，先应用关卡判定规则：
   • 吸收限定范围的低严重度 P2/P3 残留到 残留风险 中，除非它跨越升级围栏
   • 如果证据被标记为 可能存在上游约束问题，判定纯代码修复路径是否不再有效
6. 决定整体判定结果：
   • 通过
   • 软失败
   • 硬失败
   • 阻塞
7. 返回一份固定格式的 关卡报告，其中包含维度接收情况、决定性证据、缺失证据和允许的下一步路由；有需要时，让结果与 templates/gate-evidence.template.md 保持一致。
8. 在执行、恢复动作、收尾或代码仓库刷新之前停止。

关卡判定规则

• 低严重度发现，包括 P2/P3，默认保留在 残留风险 中，只要它们没有在任一层面破坏验收、恢复路径安全、面向操作员的语义，或约定完整性。
• 只有在至少命中一个升级围栏时，低严重度簇才可以推动 软失败 或 硬失败：
  • 同一低严重度模式出现在 实现/验证/策略 中至少两个层面
  • 去重后，当前轮次中至少存在五个不同的代表性低严重度发现，且该簇实质性降低了对验收或恢复的信心
• 在给出判定结果前，重复变体必须先被吸收到限定范围工作追踪视角中。原始数量单独压过限定范围工作追踪视角的行为必须被阻断。
• 如果证据中包含被标记为 可能存在上游约束问题 的决定性发现，或者两个及以上发现指向同一个尚未解决的约定、边界或治理依赖，那么 建议下一路由 的唯一合法方向是非纯代码修复路径（如规则检查、约定修订、恢复重新定界）。纯代码修复的建议路由必须被阻断。
• 当命中上游路由围栏时，应先路由到 规则检查、约定或文档修订，或 恢复工作追踪 重新定界，再去要求更多实现层反复修改。

按节点类型的判定差异

根据 Worktrack Contract 中的 Node Type 调整判定严格度：

优先级：Worktrack Contract 中显式填写的 gate_criteria 优先；Node Type Registry 只提供默认标准。若 gate_criteria 缺失，才按节点类型默认规则推导，并在关卡报告中记录 fallback 理由。

• feature 节点：三个层面全部通过才允许推进
• refactor 节点：实现层面允许"无新增 surface"，验证层面必须全部通过
• research 节点：只要求 review 层面通过，validation 层面为可选；产出不可合并时 gate 标准自动降级
• bugfix 节点：实现 + validation 必须通过，policy 层面允许"修复性例外"
• docs 节点：review + policy 通过即可
• config 节点：validation 层面必须覆盖配置正确性，policy 层面覆盖规则合规
• test 节点：validation 层面为核心，implementation 层面为辅助

如果 Node Type 未定义，使用默认判定标准（三个层面全部通过）。

关卡判定约定

每次运行这个技能时，都使用同一套限定范围约定格式。

关卡任务简报

• 触发条件
• 目标
• 当前工作追踪
• 当前轮次
• 范围内
• 范围外
• 判定选项
• 判定规则
• 完成信号

关卡信息包

• 所需证据维度
• task_producing_subagent
• review_acceptance_subagent
• producer_carrier_ref
• review_carrier_ref
• acceptance_carrier_ref
• evidence_provenance
• fallback_reason_code
• 节点类型
• 适用 gate_criteria
• 证据维度
• 当前工作追踪状态
• 工作追踪约定摘要
• 与判定相关的队列状态
• 实现证据
• 五类审查覆盖
• 验证证据
• 策略证据
• 低严重度发现摘要
• 上游约束信号
• 已知缺口或冲突
• 所需上下文

关卡判定交接

• 实现关卡
• 验证关卡
• 策略关卡
• SubAgent role / mode provenance
• review_dimensions: performance / architecture / security / quality / tests
• 节点类型
• 适用 gate_criteria
• 节点类型 fallback
• 整体判定结果
• 整体置信度
• 整体置信度理由
• 决定性证据
• 缺失或冲突证据
• 时效性阻塞项
• 残留风险
• 已应用低严重度吸收
• 低严重度吸收理由
• 需要上游路由
• 路由理由
• 允许的下一路由
• 建议下一路由
• 需要审批
• 审批范围
• 审批理由
• 审批请求

输出协议

• 先生成尽可能长且完整的 关卡报告，确保所有证据维度和判定依据被记录
• 然后从完整报告中提取 Control Signal 层（影响下一动作决策的关键结论：整体判定结果、允许的下一路由、需要审批）
• 每个证据维度（Review/Validation/Policy）的完整分析保留在 Supporting Detail 层
• 重复性上下文（如 worktrack contract 摘要）的唯一合法呈现形式是文件路径引用。内联全文的行为禁止发生
• 如果某个字段无实质内容，唯一合法行为是使用 N/A 或省略。用占位符填充的行为必须被阻断
• Supporting Detail 保留完整内容，只用于后续查阅，不纳入传递上下文

硬约束

遵循本包内最小公共约束 C-1 至 C-8：C-1 只在声明的 Scope/Function 内操作；C-2 只有授权的 SetGoal/ChangeGoal/Close/Refresh 路径可变更控制状态，其余技能返回结构化输出；C-3 先生成完整报告再提取 Control Signal，重复上下文用 artifact 引用，空字段用 N/A；C-4 不跨越 Observe/Decide/Init/Dispatch/Verify/Judge/Recover/Close 的角色边界；C-5 只消费已批准上游产物，不凭空发明验收或恢复标准；C-6 缺失证据必须显式暴露，不能当作成功；C-7 保持限定范围，避免不必要的全仓重发现。

本技能特有约束：

• Review evidence 的五类覆盖（性能、架构、安全、质量、测试）必须各自独立被接收、标为不适用并说明理由，或暴露为缺失证据。将五类覆盖缺口吞并到笼统的 implementation-gate 通过结论的行为禁止发生。
• Gate 接收 review/acceptance evidence 前必须验证 task_producing_subagent 与 review_acceptance_subagent 的 provenance 分离。缺少 producer_carrier_ref、review_carrier_ref / acceptance_carrier_ref 或 evidence_provenance 时，必须暴露为缺失证据；相同 carrier 只能作为 current-carrier fallback 接收，且必须有 fallback_reason_code（runtime_gap、permission_blocked、coupling_or_shared_state、dispatch_package_unsafe、not_applicable）。
• SubAgent-first 是条件偏好，不是 Gate 可硬编码的放行条件。Gate 只能检查 runtime_supports_subagent、permission_allows_delegation、dispatch_package_safety、task_coupling、state_sharing_need、risk_profile、context_budget_fit 和 fallback_reason_code 是否被证据记录；不得因未委派而自动失败，除非缺少合法 fallback reason。
• 各层面判断的唯一合法呈现形式是独立的结构化判定结果（实现关卡、验证关卡、策略关卡）。压缩成模糊整体判定结果的行为必须被阻断。
• 从本技能直接跳进恢复、合并、收尾或代码仓库刷新的行为必须被阻断。本技能只给出判定结果与允许的下一路由，后续动作由相应阶段算子（Recover/Close/RepoScope）执行。
• 仅当低严重度发现跨越至少两个层面或形成系统性模式，并威胁验收、恢复或操作员语义时，将其升级为 软失败 或 硬失败 才合法。停留在单一层面且未形成威胁的低严重度发现必须保留在残留风险中，仅凭数量升级的行为必须被阻断。
• 当 可能存在上游约束问题 是决定性或重复出现时，建议路由的唯一合法方向是向上游路由（规则检查、约定修订或恢复重新定界）。建议纯实现重试的行为必须被阻断。
• 当 证据维度 已经承载了维度封套时，唯一合法的字段结构是保持维度的封套层级。将审查/测试接收扩张成新的平铺顶层字段的行为必须被阻断。
• 过期维度证据被聚合进关卡判定后，其唯一合法身份是已处理的过期证据。将其当成新鲜证据的行为必须被阻断。
• post-review/post-gate updates 会使更新前的 Gate/review/acceptance evidence 失去 final acceptance evidence 资格。若 updated_files_or_artifacts 非 none，但缺少更新后的 post_update_validation_timestamp，或 validation and acceptance evidence 早于更新，整体判定不得输出可用于最终验收的通过结论，必须暴露为时效性阻塞并返回验证/验收重跑。
• 仅当维度封套已解释清楚置信度依据时，综合出高置信度才合法；否则必须降级置信度并说明理由。
• Gate 裁决的唯一合法前置条件是 Evidence 已经就绪。跳过 Evidence 直接做 Gate 裁决的行为禁止发生。Evidence 必须在前，Gate 必须在后，二者不可合并为单一步骤。
• 状态更新的唯一合法依据是经过 Gate 裁决后的判定结果。子代理的返回结果不能直接作为状态更新的依据，必须经过 Gate 裁决。

预期输出

使用这个技能时，产出一份至少包含以下章节的 关卡报告：

• 关卡触发条件
• 维度接收摘要
• 证据评估
• 分层面判定结果
• 整体关卡判定结果
• 允许的下一路由
• 程序员审查请求

结果中至少应包含以下字段或等价表达：

• 子代理模型
• 关卡触发条件
• 当前工作追踪
• 当前轮次
• 所需证据维度
• 证据维度
• SubAgent role / mode provenance
• 实现关卡
• 验证关卡
• 策略关卡
• 五类审查覆盖接收
• 整体判定结果
• 整体置信度
• 整体置信度理由
• 决定性证据
• 缺失或冲突证据
• 时效性阻塞项
• updated_files_or_artifacts
• post_update_validation_timestamp
• 残留风险
• 已应用低严重度吸收
• 低严重度吸收理由
• 需要上游路由
• 路由理由
• 允许的下一路由
• 建议下一路由
• 需要审批
• 审批范围
• 审批理由
• 需要程序员审批
• 如何审查

资源

当你需要本轮稳定的关卡报告草稿格式时，使用当前轮次的维度证据切片、工作追踪约定 和 templates/gate-evidence.template.md。把模板当成展示辅助，而不是数据模型的真相来源。