execute-ticket

执行工单

负责：单个工单的质量闭环，从语义基线到实现、聚焦简化、审查隔离门禁、QA 协调和验证交接。

不负责从文件夹中选择工单、解析旧版 Markdown、更新运行台账、移动工单文件、提交、推送、创建或编辑 PR、合并或清理工作树。

使用调用方提供的规范化 Ticket Envelope。验证语义和输出记录由 verification-audit负责。

在默认的仅使用技能流程中，加载仅使用技能契约： 输入无需运行器，除非需要完整记录，否则交接内容为简短说明。

输入

必须提供：

• 规范化信封和工单正文；
• 仓库／工作树路径和允许的文件范围；
• 来源和当前 CandidateRef；
• 验收标准和明确的兼容性要求；
• 质量重试上限以及任何已打开的工单级门禁。

拒绝过时的 CandidateRef 和尚未解决的实现启动 HITL 门禁。仅限人工的验证门禁可以保持打开状态，但会限制最终处置。

可移植组合

没有委派权限时，按顺序以内联方式调用每个阶段；这是默认方式，无需 AgentTool。选择不同的工作者之前，应用 操作默认设置；记录用户要求的范围和观察到的隔离情况。

质量闭环

1. 仅检查建立语义基线所需的代码、测试、规范和当前文档。对于库、SDK、CLI、API 或云服务行为，按仓库要求获取最新的主要文档。
2. 将验收标准转化为可观察的测试和不变量。代码行为变更时，采用要求的测试优先流程：复现 RED，实现 GREEN，然后在不改变语义的前提下重构。
3. 仅实现工单范围内的内容。保留无关的用户改动；除非明确要求兼容性，否则不要添加兼容性垫片。
4. 执行检查前，应用每次尝试的验证准入和成本规则：验证交付的打包／制品依赖图，选择因果检查和强制检查，并保留所有先前尝试以及当前尝试剩余的预算。候选版本发生变化时，不要自动重复完整套件。运行获准的定向检查。通过时，仅保留清单和内容寻址引用，不要粘贴制品；强制执行每个叶节点声明的规范化字节接收量和输出上限；即使结果为 budget-exhausted，也要继续处理剩余范围，不得遗漏。仅在 GREEN 之后通过 code-simplification 执行聚焦清理；任何编辑后都要重新运行受影响的检查。
5. 冻结候选差异和 CandidateRef。调用只读的 code-review；仅在观察到独立上下文隔离时，才将其描述为独立审查。审查期间绝不编辑。
6. 发现阻断问题时，修改候选版本，使先前的审查／QA／审计证据失效，并从相关阶段重试。达到配置的重试上限后停止。
7. 通过 qa-test-plan 构建 QA 计划。出现偏移后重新检查验证准入；保留旧证据原有的标识，不得重新标记。仅执行可行且获准的检查，并如实归类观察结果；模拟证据绝不能变成真实证据。
8. 除非仅使用技能的流程以简短说明结束，否则将调用方提供的规范化工单 ID、Ticket Envelope 制品引用、完整的冻结 CandidateRef、审查结果、QA 计划／结果、门禁、提供方记录和请求的操作交给 verification-audit。只有它可以生成规范的 Verification Record 和声明上限。

移交

返回包含以下内容的结构化结果：

• 工单 ID、Ticket Envelope 工件引用和 CandidateRef；
• 变更路径和验收标准状态；
• 运行的命令、观察到的结果、所有保留的尝试／分片、每次尝试的消耗量、 未知成本、当前尝试的剩余预算，以及任何全套测试重跑的原因；
• 评审发现和重试次数；
• QA 计划及已执行证据引用；
• 每个叶节点的规范化执行模式、隔离方式、并行标志和授权引用；
• 已验证的 Verification Record 或准确的验证错误；
• 尚未解决的人工、凭证、提供商或实时环境关卡。

不要在此移交中声称 done、PR-open、integrated 或已具备生产就绪条件。 规范验证归约机制限制了可作出的声明。交付状态必须有 Autopilot 通道中的调度器回执， 或者在 skills-only 模式下有经单独授权的调用方交付和提供商回读；不能仅凭实现完成情况推断这些状态。