handle-tickets

处理工单

对于已有的、可直接实施的工单，请将此技能作为工单编排器运行。仅从已存在的跟踪器工单开始，或从已关联工单的 PRD 开始。

引用的技能负责各阶段的具体机制。工单协调者负责工作范围、阶段边界、顺序、重试和工单完成。工单中保留的范围守护规则决定审查工作者返回的发现是否有效、交付范围以及处理方式。

如有可用的已配置 worker 子代理，请使用它来实施工作以及处理协调者负责的修复。 对于复杂或重要的 Bug，请使用 diagnosing-bugs。

命令链

• 工单协调器是唯一面向用户的角色，也是唯一可以发起交互式提问调用的角色；它会将每张工单的交付工作委派给指挥员。每条指挥员和工作者的启动提示都会告知 Agent，应将有针对性的问题和阻塞项返回给其父级，而不是进行交互式提问。协调器向用户提问，然后使用答案恢复工单已记录的指挥员。当运行时无法在指挥员下嵌套工作者时，协调器会承担指挥员职责，并将指挥员的工作者保留为直接子级。当代码审查工作者无法启动获授权的叶节点时，指挥员会保留该阶段的协调工作，并直接启动 Standards 和 Spec 叶节点。两份明确的叶节点任务包构成一次明确的审查；所有发现会一并提交给 Scope Guard，由其进行一次双轴决策。工单在产生新的指挥员交接时完成。

• 协调器为每张工单分配且仅分配一个活动工作树和分支，并持续到 PR Cleanup；同时至多分配一名活动的工单指挥员，并记录其任务 ID。指挥员为该工单分配且仅保留一名 Scope Guard，立即向协调器记录其任务 ID，并在整个交付过程中恢复该任务。分配工单前，协调器会检查已记录的指挥员：只要仍有其他符合条件的工单可安排，运行中的指挥员就保持 running；暂停的指挥员会在所需输入可用时恢复；只有尚无指挥员且符合条件的工单才会获得新的指挥员。任何指挥员替换都必须继承活动分配、Scope Guard 任务 ID、活动工作者及已报告的子任务 ID、当前实现任务包路径、当前审查任务包路径，以及当前失败检查的续接引用。替换分配需要获得用户明确批准；关闭与先前分支关联的任何未关闭 PR，使其分支绑定证据失效，原子地记录替换分配和 PR 计划，然后从 准备工作树 开始恢复。任何依赖 PR 的阶段开始前，都要记录替换后的 PR URL；如存在 Merge Lane，则重新绑定它。

• 如果仓库已有约定，工作树路径应遵循该约定。否则，协调器会将每个工作树放在主工作树旁边，路径为 <repository-name>-ticket-<ticket-id>。

• 每位指挥员负责一张工单、其工作树、其分支、其工作者序列，以及该工单的交付质量，直到工单满足下方的完成规则。

• 指挥员不会重复执行活动工作者的工作。头部绑定的工作者运行期间，指挥员可以为下游阶段准备只读上下文，但分支编辑和头部绑定阶段转换必须由各自检查点串行控制。

• PR 是否就绪取决于下方的 PR 审查激活。

• 通过在工单提交创建或移交后立即将其推送到指定分支，保持 PR 更新。对于托管审查，必须严格按照 codex-pr-review 的定义获取并传递 expectedHeadRefOid 和 statusFreshAfter。

• 实现、修复、分析、代码审查、本地 Codex、PR、最终范围和 Scope Guard 工作者均向指挥员汇报。每位实现／修复工作者负责一项由指挥员路由的操作，包括分支编辑、检查和推送；PR 工作者负责 codex-pr-review 的操作机制，并为每次托管修复启动新的修复工作者；Scope Guard 负责对发现作出决策。代码审查工作者授权其 Standards 和 Spec 叶节点；PR 工作者授权 codex-pr-review 定义的修复工作者。

• 除 Scope Guard 外，如果无法恢复已保存的任务，应先通过运行时找回其结果和状态，并接受任何有效的终止交接。只有在确认原任务及其所有后代均已终止，并且原任务已关闭或释放（如果运行时支持）后，才可启动替代任务；否则返回有针对性的运行时阻塞项。若可用，应将当前 工作者上下文 和最新交接提供给替代任务，并记录新的任务 ID。

• Scope Guard 已记录的任务 ID 是持续工作的必要条件。如果 Scope Guard 任务不可用，应返回有针对性的运行时阻塞项，并附上其最新交接和当前 Head，以便该任务再次可用时继续交付。

• 每次启动任务后、等待之前，启动任务的角色都必须在其保留的上下文中记录任务 ID、请求方、角色、工单、阶段和 Head。协调者必须在必需的交接页脚中包含其子任务 ID；指挥员还必须向协调器记录每位直接工作者。只有在任务完成终止交接或已记录替代任务后，才能清除活动任务分配。

• 每条指挥员和工作者的启动或恢复提示都必须以以下确切页脚结尾：

  Skills allowed: <workflow skill names or none>
  Delegation allowed: <none or exact delegated roles>
  

  未获委派授权的阶段工作者会收到以下指示：Complete this lane directly. Do not call task or spawn agents. Load only the workflow skills named in Skills allowed. Return evidence, questions, and blockers to your parent. 实现／修复工作者收到 Skills allowed: implement, tdd，以及协调者授予的任何指定诊断技能，并且 Delegation allowed: none。Scope Guard 将 Review Decision Flow、Review Finding Validation、Delivery Scope 和 Review Finding Disposition 作为完整的决策约定，并且 Skills allowed: none 和 Delegation allowed: none。代码审查工作者收到 Skills allowed: code-review，并向其 Standards 和 Spec 子任务授予权限。对于上述直接叶节点回退方案，协调者在该阶段收到 Skills allowed: code-review 和 Delegation allowed: Standards reviewer, Spec reviewer。本地 Codex 工作者收到 Skills allowed: codex-local-review；PR 工作者收到 Skills allowed: codex-pr-review 以及其中定义的修复者授权；最终范围工作者收到 Skills allowed: none。通过未获授权的后代获取的证据，不能作为阶段证据，除非获授权的角色直接重新核实。

• 审查和交付证据绑定到其验证过的确切分支头。之后的实现提交会使针对较早分支头的证据失效，除非现有阶段明确负责替换该证据：托管审查修复仍在 codex-pr-review 范围内，规定的范围修正遵循 Check Final Scope Fit，机械式集成刷新可以携带其 Delivery checkpoint。绝不要将较早分支头的证据报告为当前证据。

• 每次角色交接都必须以以下确切页脚结尾：

  Skills loaded: <none or verified skill provenance>
  Children spawned: <none or direct child task IDs and roles>
  

  每位协调者都要列出其直接子任务 ID 和角色；每个叶节点或修复者都要注明 Children spawned: none。父级会根据角色授权核对回执后，才接受交接。缺失、不匹配或不允许的条目会使其证据失效，直到获授权的角色重新核实。对于每项已加载技能，来源信息应包括技能名称和解析后的基础路径，以及可用时与之匹配的 standard-lock source、skillPath 和 skillFolderHash。汇总已核实的来源信息，但不要另建清单。 委派授权和 Children spawned 回执适用于当前的派生或恢复执行。

工单完成

只有当 PR 已可合并，或某个定向阻塞问题到达下方的 Human Decision Boundary 时，工单才算完成。可合并意味着所有 fix-now 发现均已解决，不再有 investigate 或 blocked 发现，本地 Codex 审查／修复循环通过，相关检查通过，codex-pr-review 已验证 PR，最终范围适配检查通过，且 PR 可以干净地合并。后续事项不会阻止工单完成。每种未成功的 codex-pr-review 结果都必须保留其续接信息包。仅当 PR 正文中的 Codex 状态为 reviewing 时，监控超时仍可恢复，且不会变成定向阻塞问题；必需的人工审查、Codex 静默启动后出现的 unavailable／disabled／stuck 结果，以及 GitHub 或访问故障，均属于定向阻塞问题。

默认情况下，在达到 merge-ready 时停止。不要将此工作流本身视为合并 PR 或启用自动合并的授权。

人类决策边界

只要需求来源和证据能够确定安全且在范围内的下一步行动，就保持交付自主进行。只有在这些来源和证据无法确定必需的产品行为、契约、范围或所有权；缺少必需的审批、访问权限、审查或合并操作；或者继续推进必然会改变已批准的决策时，才存在人类决策边界。复杂性、差异大小、跨领域工作、反复失败，以及可通过代码、测试或针对性实验解决的技术不确定性，都不构成越过此边界的理由。自主调查、规划、实施和验证，直到问题解决或边界得到证实；每个针对性问题都应指出确切的缺失输入，以及仓库为何无法提供该信息。

PR 评论策略

工作流结果评论构成一份仅追加的已完成证据和决策记录。工作流在下文定义的阶段完成时添加评论。被引用的技能仍负责其操作控制评论和审查线程回复。若后来证实已完成的记录有误，应添加简洁的更正并链接到该记录。

代码审查阶段周期应在完成发现验证和处置后添加一条最终评论；由此产生的提交是可见的修复凭证。其他阶段评论用于记录已完成的审查结果、需要外部操作的阻塞项、最终确定的集成结果或交付检查点。

使用来源 URL、仓库路径、提交 SHA 和先前评论 URL 作为引用，而不是复制已有规范出处的内容。后续评论应链接到其直接前序评论，以便新的 Agent 按需追溯决策历史。

每条 ## Code review 评论都是针对一个 Head 的当前决策增量。评论包含 Head、Fixed point、周期、前序评论 URL、存在时的中间修复提交、用于核验先前更正的当前 Head 简要参考，以及决策首次出现或在该 Head 上发生变化的当前发现。每项当前发现都记录其 ID 和有效性；被驳回的发现应记录简要的反证，而其他每项发现都应记录其交付要求、处置结果、简要证据，以及适用的更正或后续跟进优先级。结果按当前 fix-now、follow-up、investigate 和 blocked ID 分组。无发现的周期应记录 Current findings: none 和 Outcome: PASS。前序评论链承载更早的已更正、已驳回和未变化的决策。

检查点是与当前 Head 绑定的结果记录，用于授权后续转换。续接信息包记录可恢复的状态，但不构成验证证据。

Worker 上下文

Worker 提示词应携带在收集上下文阶段发现的引用，而不是复制源内容。传入工单 URL、工作树、分支、固定点和当前 Head，并在 PR 创建后传入 PR URL。告知每位 worker 遵循仓库说明，包括项目的领域文档使用规则，并查阅与其阶段相关的领域上下文和决策。只有在某个额外 URL 或路径对工作有实质约束，且无法通过这些来源发现时，才添加它。修复 worker 会通过其持久化结果记录收到 Scope Guard 最终确定的 fix-now 处置意见；有持久化 URL 或路径时使用它们，只有在不存在持久化引用时才附上源内容。

对于续审，将紧邻的上一条代码审查评论 URL 和期间的修复提交传给两位留任审查者。告知每位审查者验证此前的修正，在当前 Head 上重新确认所有尚未解决的 investigate 或 blocked 发现，审查从当前固定点到 Head 的完整变更，并将这些发现以及由当前 Head 变更证据新发现或重新开启的当前合格发现交给代码审查 worker。该 worker 编写汇总审查包，其中包含精简的此前修正验证摘要，并附上指向前序审查的当前证据引用。此前已完成的处置是上下文，而非需求来源：如果新的当前 Head 证据改变了其有效性或交付范围，则重新开启，包括出现回归、修正不完整或新适用的要求。

PR 审查启动

每个工单 PR 从首次进入托管状态到最终范围适配，始终有一个已记录的 PR worker 任务 ID。codex-pr-review 的终止交接会完成一次调用，但不会清除该所有权。任务可用时恢复已记录的任务；否则遵循 Command Chain 中已保存任务的恢复和替换规则：只有在先前任务及其后续任务均已终止后，才以原子方式准确记录一个替代任务。

• **本地状态：**PR 为草稿。可以执行会更改分支和绑定 Head 的阶段；PR worker 不得产生任何监视器或托管反馈副作用。
• **托管状态：**PR 已就绪。已记录的 PR worker 是托管反馈的唯一负责人。它会立即为每项观察到的反馈生成数据包；在指挥者取得 Scope Guard 的决定后，PR worker 必须先执行所需的回应和回复，然后才能进行任何修复或阶段转换。每次运行监视器或执行副作用之前，都必须确认已记录的任务 ID、isDraft: false，以及本地、远程和 PR 的 Head 一致。
• **本地 -> 托管：**指挥者验证 Head，并在 PR 仍为草稿时恢复或启动已记录的 PR worker。worker 再次验证 Head，记录新鲜度边界，将 PR 标记为就绪，处理当前尚未回应的反馈，并启动监视器。
• **托管 -> 本地：**PR worker 完成当前反馈处置，验证 Head，将 PR 标记为草稿，确认 Head 未变且 isDraft: true，然后返回该回执。收到回执前，不得启动任何本地或会更改分支的 worker。
• 就绪状态恢复：如果本地工作在 PR 已就绪、但没有已记录的 PR worker 时恢复，则在 Head 不变的情况下启动并记录且仅记录一个 PR worker，让其处理当前托管反馈，然后在开展本地工作前完成托管 -> 本地。
• 最终范围适配在托管状态下进行。范围适配期间保留 PR worker 任务 ID；记录任何范围适配 PASS 前，都要在 Head 不变的情况下恢复该 worker，以进行最终托管状态检查并完成有限的台账收尾。

审查决策流程

每个工单从已验证的任务分配开始，直到 PR 清理或放弃交付为止，始终保留一个 Scope Guard。其初始上下文包含权威范围来源、工作树、分支、固定点和当前 Head。它会返回 Scope Guard ready、该基线以及必需的角色交接页脚，但不会作出审查结论。固定点发生变化时，必须先刷新基线，再作出下一项审查结论。

在阶段工作者报告审查通过、发现问题或请求提供证据之前，协调者会分配一个工单专属的唯一临时路径，该路径可从工作树读取，且位于预期差异之外。工作者会以原子方式写入一个审查数据包，其中包含 Phase、已审查的完整 Head、Outcome: clear | findings | evidence 及其报告，最后附上 ## Packet complete。evidence 数据包会标明其更新的问题 ID。交接内容会返回这些字段、数据包路径以及必需的角色交接页脚。协调者会验证并记录数据包路径。在基于任何数据包发布内容或提交给 Scope Guard 之前，以及发布 Scope Guard 决策之前，协调者都必须重新解析本地、远程和 PR 的 Head（如有），并确认每个值都与数据包中的 Head 相同；若不匹配，则数据包失效，该阶段必须重新进行。clear 按该阶段规定的通过路径处理；findings 和 evidence 则携带相关数据包引用，交由 Scope Guard 继续处理。

Scope Guard 会应用审查发现验证、交付范围和审查发现处置，然后返回审查阶段、Head、Decision: clear | fixes-required | investigate | blocked、当前问题决策以及协调者的下一步转换。协调者会发布包含这些字段的持久化、绑定到 Head 的记录，保留其生成的 URL 供后续交接使用，然后执行相应转换；如果该阶段定义了指定的结果格式，则使用该格式，否则使用 ## Review decision。在作出此决策之前，不得开始因审查而触发的修复。investigate 会分配分析工作者，并将其证据数据包交回同一 Scope Guard。只要审查数据包对应的决策仍可恢复，就必须保留这些数据包；在 PR 清理或放弃交付时将其删除。

如果必需检查仍然失败，且诊断未发现由工单导致的问题，或 Scope Guard 未授权修复，协调者必须在等待之前立即与编排器记录一份持久化的失败检查续接信息，其中包含失败的命令、当前 Head 与基础版本的比较、证据、外部负责人和唤醒条件；该工单保持 running。达到人工决策边界时，则使用 blocked。审查结论通过绝不表示失败检查已通过。

编排器循环

1. 收集上下文

阅读每个工单正文及相关评论，查阅其链接的规范和决策，然后阅读仓库说明、基础分支和外部操作限制。遵循项目的领域文档使用规则，找出其上下文映射、术语表和决策；盘点现有内容，并阅读与工单就绪状态和队列决策相关的材料。

完成条件：每个工单都标记为 ready-for-agent 或仓库中的等效状态、已排除，或因有针对性的问题而受阻。

2. 建立队列

对就绪状态、依赖关系、可能的冲突和并行化机会进行分类。

完成条件：每个可实施的工单都对应一个协调者、工作树、分支和 PR 计划。

3. 安排协调者

并行派发相互独立的工单，并将依赖或相互冲突的工单排在后面，明确列出前置条件。 当未关闭的 PR 有必需的合并顺序时，使用下方的合并通道。

完成条件：每个工单都处于运行中、因明确原因排队、已排除或受阻。

4. 核对交接

确认每位协调者都返回了所需的交接。

当每个工单都符合工单完成规则、已排除，或已排队等待明确的合并前置条件时，即可完成。

5. 返回合并决策

报告 PR、分支、检查、评审结果、阻塞项，以及任何所需的人工操作。

当工单编排器确认某个 PR 已合并时，运行已确认合并后的跟进流程：

• 运行 PR 清理。
• 恢复新近解除阻塞的工单交付。
• 将其合并通道推进一个合并候选项。
• 开始处理依赖于已合并 PR 的工单之前：
  1. 将默认分支更新到其最新的远程提交。
  2. 确认更新后的默认分支包含此次合并。
  3. 从更新后的默认分支创建依赖工单的分支和工作树。

当合并决策已返回，且当前编排器循环迭代中所有必需的已确认合并后的跟进流程均已完成时，即可完成。

合并通道

当未关闭的 PR 有规定的合并顺序时，编排器会针对每条有序链运行一个串行的合并通道，同时并行交付工单。每个通道只有一个活跃的合并候选项。独立通道和无序的合并候选项可以并行推进。等待活跃合并候选项处理的、已准备好合并的 PR 会停留在其交付检查点，而其他工单的实现和修复则继续由各自的协调者推进。

交付检查点是仅用于合并通道的检查点，允许已成功交付的 PR 暂停等待。它会记录 Head: <full SHA>，并链接其托管评审输入、检查、托管验证，以及适用的范围契合度结果。记录的 Head 与分支 Head 相同时，该检查点即为最新；但如果当前可合并性未确认干净，该检查点本身并不代表已准备好合并。编排器会读取这两项，然后告知协调者是继续交付、准备活跃的合并候选项，还是执行集成刷新。

暂停等待的 PR 会在成为活跃合并候选项时接受评估。最新的交付检查点和干净的可合并性可维持其已准备好合并的状态。合并冲突或仓库要求更新基准分支时，会启动集成刷新。在协调者为集成和冲突协调启动新的实现／修复工作线程之前，先完成托管端 -> 本地，然后在选择下一阶段之前对结果进行分类：

• 机械式集成刷新仅更改提交历史关系和无冲突的组合。集成推送后，使用保留的 Delivery checkpoint 执行本地 -> 托管端，然后等待自动启动的检查；托管验证成功后，通过链接仍然适用的范围契合度结果来更新该检查点。
• 实质性集成刷新需要对语义冲突作出选择，或需要由分支编写代码、测试或文档更改。将集成后的基准完整 SHA 记录为替代固定点，使保留的检查点失效，并从代码评审继续，随后进行本地 Codex、托管端 Codex 和最终范围契合度检查。

当先前已准备好合并的 PR 进入集成刷新时，先对其进行分类，然后将完成结果记录为 ## Integration refresh，其中包含 Head、先前检查点 Head、新基准、原因、Classification: mechanical integration refresh | substantive integration refresh、失效的检查点，以及下一必需阶段。后续阶段通过下文定义的常规注释提交其完成结果。

当活跃的合并候选项合并，或合并顺序明确变更时，合并通道会推进。定向阻塞项会暂停该通道的活跃合并候选项，但其他通道和工单交付会继续进行。通道推进时，编排器会恰好选择下一个合并候选项，并评估其当前可合并性。

工单协调者循环

对于每个分配的工单：

1. 准备工作树

仅创建或验证该工单当前分配的工作树和分支，并从声明的基准分支创建。 明确批准替换后，先停用之前的分配，再使用记录的替代项。

确认已知 git status --short 的结果，且分支仅包含该工单预期的工作。

使用已验证的分配信息，以及 Review Decision Flow 要求的范围来源，启动或恢复该工单记录的 Scope Guard。记录其任务 ID 和 Scope Guard ready 交接，并向编排器确认后，即为完成。

2. 实施

启动实施工作前，先判断工单和关联规范是否已提供足够的实施上下文。如果存在具体但尚未解答的设计、所有权、兼容性或验证问题，可能对实施造成实质风险，则由主导者分配一个该工单专属的唯一临时路径，该路径必须能从已分配的工作树读取；如果有可用的已忽略仓库暂存或临时位置，则使用该位置，否则使用仓库外的共享路径，然后将路径交给一名直接分析工作者。工作者不得改动预期差异，并须原子地将实施交接包写入该路径，以 ## Packet complete 作为结尾，然后返回该路径。主导者验证文件可读且包含完成标记，随后立即向编排器记录该路径。如果现有材料已回答相关问题，则跳过此分析。

交接包没有长度限制。保留所有尚未在所引用的需求来源中记录、且与实施相关的事实，包括根因的更正或决定、选定的设计、可避免错误的驳回方案、不变量、范围、所有权、兼容性、验证、未解决问题和运行状态。排除原始调查日志和重复的源内容；改为引用现有 issue、规范、ADR、提交、差异、文件和 URL。对敏感信息进行脱敏。

如果仍有实质风险问题未解决，主导者应继续只读调查，或恢复同一名直接分析工作者并更新交接包；技术上的不确定性不构成实施授权。只有在人工决策边界才能返回定向阻塞项。否则，将交接包路径作为工作上下文传给实施／修复工作者。原始工单及关联的已批准规范或决策仍是需求来源，而固定点、差异和交接包则是待审查的证据或上下文。审查者需要的任何已批准设计或范围决策，都必须在审查前更新到工单或规范中。复用前，验证交接包仍然存在；每当其中记录的实施相关事实发生变化时，都要原子地更新交接包；若文件缺失，则重新生成，并在删除旧文件前立即向编排器记录每个替换路径。在 PR 清理时或放弃交付时删除该文件。

启动一名新的实施／修复工作者，并为其提供 implement、Worker Context 要求的引用、适用时的实施包路径，以及验证预期。每名实施／修复工作者只执行一项指定操作，并在完成交接后结束。等待其交接前，立即记录其任务 ID。 在此工作流中，专门的新鲜 Code Review 阶段即履行 implement 的实施后审查步骤。告知实施／修复工作者完成实施、验证、提交、推送，并返回实施交接。之后由主导者发起的修复提示，则应在验证、提交和推送后返回。 工作者返回实施提交后，确保已创建草稿 PR，并包含非关闭工单的引用，例如 Refs #123。 针对最终 Head 进入 Code Review。

实施提交已推送、PR URL 已记录，并已返回检查、验收证据、假设和阻塞项，或已附证据返回定向实施阻塞项，即为完成。

3. 代码审查

协调器分配审查包，并在实现 Head 上启动或恢复代码审查工作器。该工作器运行 code-review，记录其 Standards 和 Spec 审查者任务 ID，并且只返回仅包含引用的审查包交接内容。

对于 Spec 审查，请将工单正文、相关的权威工单评论、关联的已批准规范和决策，以及每项验收标准作为规范来源；将尚未证实的要求纳入符合条件的发现，并以文字形式返回。

将差异中新增或强化的文档视为实现的一部分，并依据工单要求来源进行审查。收窄超出工单要求的承诺。 代码审查工作器会在实现 Head 上启动两位审查者。在两位审查者返回之前，保持该 Head 不变；之后由工作器在审查包中按不变量归纳他们的原始发现。 以下证据要求优先于 code-review 对审查者报告长度的指导。要求两位审查者针对每项发现报告：经过审查的完整 Head SHA、要求来源、变更位置或差异中的因果路径、具体触发条件、观察到的行为和要求的行为、已检查的反证、针对性验证，以及足以解决问题的最小修正。 对于发现，请遵循 审查决策流程，并将 PR 评论政策定义的当前决策差异作为持久记录。当审查包结果为 clear 时，协调器直接发布干净周期格式。 当两位留存的审查者都针对同一个当前 Head 提交报告，且两者均未发现问题，或提供了完整的审查包（Scope Guard 能据此为每项发现给出决策）时，即视为完成。

审查发现验证

审查报告包含的是发现项，而不是编辑指令。Scope Guard 会自主验证每项发现。只有当前头版本的证据确立了以下全部内容，发现项才算confirmed：

• **需求来源：**所需行为来自原始工单、相关且权威的工单评论、已链接的获批规范或决策、预先存在且适用的仓库标准，或适用于已修改代码的预先存在的重要代码约定。由受审查差异修改的文档和实现数据包仍属于待审查证据。
• **相关性：**明确差异是否引入了缺陷、遗漏了所需行为，或导致已修改的执行路径依赖该缺陷。引用已修改的位置或完整的因果路径。没有这条因果路径的具体缺陷，与此工单相关但不属于其范围，不能据此授权范围内的修复。
• **触发条件：**有针对性的复现、失败测试、可达的执行路径或直接静态证明，能够展示当前行为。检查相关保护逻辑、调用方、测试和反证；仅仅设想可能存在绕过，或偏好某种架构，都不足以证明。
• **预期结果：**需求来源决定所需结果，且有针对性的检查能够区分修正后的行为与当前行为。

如果证据反驳某项发现，或表明该发现已过时、基于未经支持的承诺、针对不可达行为、属于重复内容或仅源于偏好，则将其标记为rejected。证明其不成立的证据即完成该发现；该发现不再有交付要求或处置方式。如果某项发现仍有可能成立，但缺少上述某项证明，则将其标记为unresolved，并记录确切缺少的证据。Delivery Scope和Review Finding Disposition决定它会成为follow-up、investigate还是blocked。

按其声称遭到破坏的不变量对发现项分组。此前已修复的问题类别中出现新的语法、输入或竞态变体，说明先前的修正可能未能确立该不变量。重新检查根因，根据需求来源确定足以解决问题的最小修正，并验证该不变量对所有受支持的输入类别都成立。在对该类别再次进行修正前，要求完成一份根因证据数据包，并交回同一个 Scope Guard；如果阶段负责人已有符合条件的数据包，则复用该数据包，否则指派一名直接负责根因调查的证据工作者。

如果某项发现所审查的头版本已过时、缺少必需证据，或其依据包含未获授权的下游内容，则将所需的重新确立证据交回 conductor。conductor 指派一名获授权的直接工作者，并在其完成证据数据包后恢复 Scope Guard 流程。有效性、交付要求和处置方式彼此独立。

交付范围

对于每项已确认或尚未解决的发现，记录Required for this delivery: yes | no | unknown。Review Finding Validation已确立其现有的需求来源、相关性与因果关系、触发证据和预期结果。如果让该发现继续未解决会违反验收标准、所请求的应用行为，或已修改路径上受支持的行为，且修正该问题属于获批工单中最小且连贯的实现，则使用yes。决定前，请检查相关应用流程、调用方、测试、领域文档和固定点行为。

如果应用无需解决该发现，也能满足工单要求并保留适用的现有行为，则使用no。如果缺少的证据导致无法确定工单是否验收通过，或无法确定已修改路径上受支持的行为是否得以保留，则使用unknown。

让标记为yes的发现继续未解决属于范围遗漏。未经单独批准就实现标记为no的发现属于范围蔓延。

评审发现处置

在决定如何处置前，先应用 评审发现验证 和 交付范围。每项发现都记录：

• Validity: confirmed | rejected | unresolved

每项未被驳回的发现还需记录：

• Required for this delivery: yes | no | unknown
• Disposition: fix-now | follow-up | investigate | blocked

根据证据确定处置方式：

• confirmed + yes -> fix-now，或在 人工决策边界 处标记为 blocked。
• unresolved + yes -> investigate，或在 人工决策边界 处标记为 blocked。
• confirmed + no -> follow-up。
• unresolved + no -> follow-up。
• confirmed + unknown -> investigate，或在 人工决策边界 处标记为 blocked。
• unresolved + unknown -> investigate，或在 人工决策边界 处标记为 blocked。

follow-up 需记录 Priority: high | medium | low、预期价值、证据、交付为何可以不受其影响而继续，以及下一步行动。investigate 处置会阻止阶段完成，同时继续自主收集证据。

Scope Guard 会返回最终确定的 fix-now 决策内容。Conductor 会将该内容发布到持久化结果记录中，并将其 URL 发送给实现/修复工作器。在最终交接中保留后续处理项；其实现或发布为跟踪器工单均需单独批准。严重程度决定处置方式中的紧急程度，而不决定有效性、交付要求或处置方式。

除非未决决策可能影响这些发现的正确性，否则应先处理独立的 fix-now 发现，再返回阻塞项。将其余发现合并为一个问题，其中包含相关发现、证据、确切缺失信息、建议，以及交付能否独立继续。

4. 修复代码评审问题

一个 代码评审 阶段周期包含一份双轴报告、一套完整的发现验证与处置结果，以及至多一批评审修复。对报告应用 评审发现处置。

当代码评审数据包的 Outcome: clear 时，进入 本地 Codex 评审/修复。对于包含发现的数据包，遵循 评审决策流程。如果决策为 fixes-required，则启动新的实现/修复工作器，并提供持久化结果记录，让其完成一批专注的评审修复，包括聚合检查、提交和推送；之后让代码评审工作器恢复工作，对生成的 Head 进行续审。在最终交接中保留后续处理项，并在之后的代码更改后重新运行聚合检查。

如果聚合检查失败，Conductor 会指派工作器进行诊断，并由其编写完整的评审数据包。对于由工单引起的发现，应先通过 评审决策流程 决定后再修复；如果诊断清晰且与工单无关，则记录其中定义的持久化失败检查续接信息。任何修复提交后都应重新进行代码评审。持续执行，直到检查通过或到达 人工决策边界。

只有在每项发现都具有针对当前 Head 的有效性结论、每项未被驳回的发现都有交付要求和处置方式，并且已提交的评审修复通过针对性检查和聚合检查，或已返回阻塞项时，才算完成。后续处理项仍需记录在最终交接中。

5. 本地 Codex 审查／修复

指挥者分配审查包，并根据 Worker Context 所需的参考资料启动一个全新的 codex-local-review 工作进程。按照 Review Decision Flow 路由其审查包。若决策为 fixes-required，则启动一个全新的实现／修复工作进程，针对一项重点审查修复执行检查、提交和推送；随后在变更后的 Head 上启动一个全新的本地审查者。将所有延后处理的阻塞项纳入该审查，并要求在返回或清除阻塞项之前，基于当前 Head 作出决策。 本地审查输入在派发时冻结。工作进程直接审查固定点到 Head 的差异；GitHub 反馈不得扩大其审查包、延迟完成或续期 Local Codex。派发前要求满足 Local state。 本地审查通过后，启动一个全新的实现／修复工作进程执行聚合检查。检查失败时，由一个工作进程进行诊断并生成完整的审查包。修复前，先按照 Review Decision Flow 路由由工单导致的发现，并进行全新的本地审查；若诊断明确且与工单无关，则记录该流程中定义的持久化失败检查后续处理。持续执行，直至检查通过或到达 Human Decision Boundary。 本地 Codex 成功后，指挥者确认本地、远程和 PR 的 Head 一致，并记录 ## Local Codex review，随后记录 PASS 和 Head: <full SHA>；该 Head 上最新的此类结果即为当前的 local Codex checkpoint。

当不再有 fix-now、investigate 或 blocked 发现，聚合检查通过，且存在当前的本地 Codex 检查点时，即视为完成；若有任何指定的阻塞项，则附上证据将其返回。为最终交接保留后续事项。

6. 准备就绪的 PR 并运行 Codex PR Review

托管审查输入可以是当前的本地 Codex 检查点；若为机械式集成刷新，也可以是沿用的刷新前 Delivery 检查点。

指挥者确认本地 HEAD 与远程完整 Head SHA 一致，然后使用托管审查输入执行 Local -> Hosted。按照 codex-pr-review 的定义，准确传递 expectedHeadRefOid 和 statusFreshAfter。

对于此调用方，PR 工作进程应将合并冲突返回给指挥者，并将 integration refresh 作为下一步转换。指挥者启动全新的实现／修复工作进程进行协调并判断刷新属于机械式还是实质性后，完成 Hosted -> Local。按顺序处理的 PR 应遵循合并通道。对于其他 PR，机械式刷新应返回 Local Codex Review/Fix，以获取基于当前 Head 的检查点；实质性刷新则应将已集成的基准记录为固定点，并返回 Code Review。随后，指挥者在所产生的托管审查入口处恢复 PR 工作进程。 在执行任何可能更改 Head 或续期本地审查的集成刷新、范围修正或其他转换之前，完成 Hosted -> Local。成功验证后保留 Hosted 状态，直至最终范围适配检查完成。 Watcher 批准（包括新的 PR 正文中的 THUMBS_UP）在 Review Ledger Closure 完成前仍属暂定。PR 工作线程会在修复工作开始前，将当前 Head 上所有托管审查发现写入审查数据包。conductor 会通过 Review Decision Flow 路由该数据包，并使用已发布的决策恢复同一个 PR 工作线程。决策 Head 是预期操作 Head，除非经授权的修复记录了由其工作流负责的更正 Head，并将其作为替代。每次执行表态、回复、派发修复或关闭前，PR 工作线程都会重新确认本地、远程和 PR Head 均与预期操作 Head 一致；若不一致，则不执行任何副作用，并重新进行托管审查。经授权的修复完成后，在关闭账本前，必须通过 Review Decision Flow 在更正 Head 上重新确认所有尚未解决的 investigate 或 blocked 发现。每次决策后，PR 工作线程都会立即回复其处置结果和简要证据；对已确认的发现或未解决的后续事项应用 THUMBS_UP，对已驳回的发现应用 THUMBS_DOWN，并在继续审查或修复工作前解释每项驳回。当后续决策推翻有效性判断时，移除已被取代的表态，并先发布更正，再应用替代表态。对于托管的未解决发现，若 Required for this delivery: yes | unknown，则保持为 investigate 或 blocked；若为 no，则将其保留为后续事项，并在回复中记录缺失的证明及交付为何仍可继续。fix-now 讨论串必须保持打开状态，直至更正验证回复解决问题。在此工作流中，PR 工作线程会将每项经授权的修复委派给新启动的 fixer；若无法启动 fixer，则返回有针对性的运行时阻塞说明。如果 fixer 获得的证据会改变某项发现的有效性、范围或更正方案（包括证明无需修复的证据），PR 工作线程会将其作为证据数据包返回，以便在修复、表态、回复或关闭前进行新的 Scope Guard 决策。否则，按 codex-pr-review 执行 fixer 工作、验证、推送、表态、回复和账本关闭。为移交给 conductor，保留托管的后续事项。

使用托管审查输入及其生成的 Head 选择调用方转换：

• Local Codex checkpoint / normal entry：运行上述常规就绪 PR 流程。
• Local Codex checkpoint / hosted review fix that is not a scope correction changes Head：在 codex-pr-review 内完成修复和重复托管验证。
• Local Codex checkpoint / scope correction changes Head：在托管验证恢复前，返回 Local Codex Review/Fix。
• Returned Local Codex / Head changed：通过常规就绪 PR 流程重新进入此阶段，并按 codex-pr-review 要求刷新托管输入。
• Returned Local Codex / Head unchanged：使用未变化的 expectedHeadRefOid 上更新的本地 Codex 检查点执行 Local -> Hosted；就绪状态重新激活是唯一的审查触发条件，因此不得授权发送用于刷新检查点的 @codex review 请求。
• Carried Delivery checkpoint / no hosted review fix changes implementation：保持集成刷新为机械性操作，并通过链接仍适用的范围契合结果续期 Delivery 检查点。
• Carried Delivery checkpoint / a hosted review fix changes implementation：将其归类为实质性集成刷新，将已修复点重新绑定到集成基准的完整 SHA，使沿用的检查点失效，并返回 Code Review，随后依次进行 Local Codex、托管审查和范围契合检查，再记录新的 Delivery 检查点。

如果托管审查修复后聚合检查失败，将失败信息返回给 PR 工作线程，以生成完整的审查数据包。通过 Review Decision Flow 路由由工单导致的发现，然后按 codex-pr-review 执行经授权的修复，并在变更后的 Head 上恢复托管验证；对于明确的非工单诊断，则记录其中定义的持久失败检查后续流程。持续处理，直至检查通过或到达 Human Decision Boundary。 当续接数据包报告 PR 正文状态仍为 reviewing 时，使用持久续接引用和所需的唤醒条件，保持工单及其 conductor 处于 running 状态。收到下一次唤醒信号或计划检查时，恢复同一个 conductor 和 PR worker，执行 codex-pr-review 的有界状态检查；编排器不会将此次续接视为终态交接，也不会分配替代 conductor。将所有其他未成功的终态结果作为带有续接引用的定向阻塞项返回。当 PR worker 针对最终 Head 返回账本已关闭的验证结果、相关聚合检查在托管审查修复后于该 Head 上通过，且每次范围修正后都在恢复托管验证前进行了新的本地 Codex 检查点时，即视为完成；若定向阻塞项到达人工决策边界，也视为完成。

7. 检查最终范围契合度

codex-pr-review 验证 PR 后，指挥者会分配一份审查材料包，并启动一名全新的最终范围审查工作者，提供 Worker Context 要求的参考资料。要求其检查完整 PR 差异，并针对经过审查的 Head 返回仅包含参考资料的已完成材料包，其中 Outcome: clear | findings。 询问该差异是否是实现所请求结果的最小完整方案。 将变更文件和非测试代码行数视为证据，而非阈值。 标记无关职责、推测性架构，或验收标准未要求的更强承诺。 如果确认差异实现了标记为 Required for this delivery: no 的项目，则属于范围蔓延；移除该项目标记为 Required for this delivery: yes，处置方式为 fix-now。

若 Outcome: clear，则准备 PASS。若有发现，则依据 Review Decision Flow 处理，并以 ## Scope fit 作为持久记录；Scope Guard 的决策为 clear 时也准备 PASS，其他所有决策均记录 FAIL 及其下一步转换。在记录任一 PASS 之前，完成 PR Review Activation 要求的最终托管状态检查和有界账本收尾，并要求 PR 工作者返回未变更的已审查 Head。收尾修复会使范围契合度材料包失效，并要求重新经过规定的本地和托管阶段，然后再进行一次全新的范围契合度审查。之后记录 ## Scope fit、PASS 和 Head: <full SHA>。

如果根据需求来源判定 PR 需要进行范围修正：

1. Scope Guard 对每项范围契合度发现应用 Review Finding Disposition。只有 fixes-required 才授权修正。对于小型、局部、可逆且结果明确的修正，指挥者将其归类为指定的范围修正。对于其他所有修正，由 diagnosing-bugs 工作者在证据材料包中记录根本原因、受影响的职责、最小完整修正方案和针对性验证。指挥者通过 Review Decision Flow 提交该材料包，并且只有在最终决策仍为 fixes-required 时才继续。
2. 在未变更的 Head 上完成 Hosted -> Local。如果托管反馈改变了 Head，则使范围契合度材料包和决策失效，完成规定的托管验证，并在考虑任何修正前重新进行范围契合度审查。
3. 指挥者根据最新的持久 Scope Guard 决策和修正分类，启动一名全新的实现/修复工作者，在保留所需行为的同时应用范围修正。
4. 要求该工作者重新运行相关检查、提交并推送，然后记录完整的修正 head SHA。
5. 返回 Local Codex Review/Fix，进行全新的本地审查。
6. 通过 Ready PR and Run Codex PR Review 运行托管验证。
7. 返回 Check Final Scope Fit。

最终结果成功后，如果 Merge Lane 要求记录 Delivery checkpoint，则在最近一次分支更新后记录。

如果有针对性阻塞因素导致 Codex 无法验证，则在范围契合度审查前结束此阶段，并返回该阻塞因素。

当当前 Head 的范围契合度结果为 PASS，或范围修正到达 Human Decision Boundary 时，即为完成。

Ticket Conductor 交接

conductor 交接内容包括：

• Outcome: merge-ready | blocked | queued
• 工单、PR、工作树、分支和当前 Head
• 保留的 Scope Guard 任务 ID 和最新的绑定到 head 的交接
• 当阶段或审查归属仍可恢复时，记录的代码审查或 PR worker 任务 ID
• 当 finding 决策仍可恢复时，当前审查材料包路径
• 当前审查、检查、本地 Codex、托管 Codex 和范围适配证据的链接
• 简洁的 Acceptance evidence 文本，为每项工单验收标准列出实现和验证依据
• 按 follow-up、investigate 和 blocked 分组的当前未解决 findings，并附上适用的优先级、证据、后续操作和负责人
• 仅在交付受阻或仍可恢复时提供实现材料包路径
• 当外部唤醒仍可恢复时，提供当前失败检查的续接引用
• 当托管审查受阻或仍可恢复时，提供持久续接引用、唤醒条件、expectedHeadRefOid 和 statusFreshAfter
• 下一步工作流操作和负责人

已完成和已拒绝的 findings 保留在关联的结果记录中；conductor 交接中附有其持久引用。必需的角色交接页脚包含经核实的技能来源信息和子任务 ID。

PR 清理

对于每个确认已合并的 PR，记录合并情况，更新其关联工单，并在 PR 完成工单时将其关闭；解决相关审查讨论串，并报告清理内容。部分完成、受阻和未合并的工单应保留，并附上证据和后续操作。 在 PR 清理或放弃交付时，获取终态交接，或运行时确认，以确保保留的 Scope Guard、每个记录在案且可恢复的 worker 及其所有后代都已进入终态。如果运行时支持，请关闭或释放它们，然后清除其活动分配并移除工作树资源。无法确认终态时，应保留这些资源和分配，并返回有针对性的运行时阻塞说明。

仓库清理

当本次运行处理的 PRD 中所有工单都已关闭且工作已完成时，工单协调器会将该 PRD 标记为已完成，然后将启动 handle-tickets 的工作树切换到默认分支，将其更新到最新的远程提交，并在需要时使用现有锁文件同步本地依赖，且不更改锁文件。