triage

分流

通过一组简单的受理角色状态机，推进已配置跟踪系统中的任务。分流针对远程记录或本地受理任务正文；能力草稿中的未解决提案不适用任何角色。

如果跟踪系统将外部拉取请求视为一种请求入口，分流也涵盖这些请求。拉取请求是附带代码的任务，使用相同的角色和状态，但下文所述差异除外。根据跟踪系统配置，将单独的 #42 解析为问题或拉取请求。

文档与跟踪系统约定

项目文档及其规则见 project-documents.md；更新项目文档前请先阅读。其术语（已授权、义务、惰性、指针）适用于全文。阅读相关要求、规范、当前工作状态和待办列表（如有）。

阅读跟踪系统配置，以及 AGENTS.md 指向的分流角色。若缺少跟踪系统配置，请询问用户本次运行的任务位于何处（通过命令行工具或已连接的服务器访问仓库远程端的跟踪系统，或使用本地受理任务正文），并在分流前通过一次只读查询确认读取权限。若缺少角色定义，请使用下方的规范字符串。在报告中说明缺少了哪些配置，以及本次运行采用了什么假设；不要将任何内容记录为配置。

“评论”、“应用角色”和“关闭”均依据跟踪系统配置执行：

• 远程操作使用平台实际支持的命令和标签。指向已发布远程任务的本地标题／链接引用不会复制远程角色状态。
• 本地任务正文在顶部附近使用 Category: 和 Status:。评论追加在 ## Comments 下方。拒绝时，通过 Status: not-planned 关闭受理。交付进度、阻碍和验收证据可与受理状态分开记录在正文中。

远程评论、角色变更和关闭操作，需要获得维护者明确提出的分流请求或已确认的处理结果授权。一般性的本地文档编辑不授予远程发布权限。在授权范围内，于本地维护规范、当前工作状态和变更日志。候选延期事项遵循 project-documents.md 中规定的待办列表权限；不要在远程待办列表之外另建本地队列。

分流期间发布的每条评论或新任务都必须以以下内容开头：

> *This was generated by AI during triage.*

参考文档

• agent-brief.md：持久化的就绪简报。
• out-of-scope.md：已拒绝增强需求的知识库。

角色

类别角色：

• bug：存在故障。
• enhancement：新功能或改进。

受理状态角色：

• to-evaluate：需要维护者评估。
• on-hold：等待指定的回复、依赖项或阻碍因素，暂时搁置。
• ready：已充分明确并附有简报，可以安全着手处理。
• not-planned：已关闭，不采取行动，并记录原因。

这些状态用于回答工作是否可以着手处理。进行中、审核中和已部署等状态，属于跟踪器自身的交付字段、本地任务进度、分支或 PR。

一份 ready 简报可以指出必须由人工实施的工作，以及无法委派的原因，例如访问权限、判断或手动测试。这是简报中的一行内容，不是另一种角色。对于 PR，ready 表示已明确说明对其差异内容的下一步，无论是由 Agent 完成，还是由人工合并。

每个经过分类的任务恰好带有一个类别和一个状态。如果状态冲突（同一任务上有两行状态，或某个角色与跟踪器自身的状态不一致），应注明各自的来源和日期，推荐最新证据（最新评论、关联拉取请求的状态）支持的状态，并在维护者作出选择前不应用任何角色。角色文件会将规范角色映射到项目实际使用的字符串；请使用该映射，不要创建重复的词汇。

通常，未分类的任务会进入 to-evaluate，随后转为 on-hold、ready 或 not-planned。指定条件满足后，暂停状态会返回 to-evaluate。维护者可以覆盖此流程；遇到不寻常的状态转换时，先标记并确认。

调用

维护者运行 /triage 并描述请求：

• “显示所有需要我关注的事项。”
• “我们来看看 #42。”
• “将 #42 转为 ready。”
• “有哪些任务已准备好供 Agent 着手处理？”

显示需要关注的事项

查询已配置的跟踪器，并按最早优先显示以下三个分组：

1. 未分类且没有状态角色的任务。
2. to-evaluate 任务。
3. 指定条件已满足的 on-hold 任务。将其列出前，先检查备注中是否有相关回复、已合并的依赖项或已关闭的阻碍因素。

如果范围包含 PR，请为条目标注 [PR] 或 [task]。发现阶段仅包含外部 PR，并使用配置中的作者筛选条件；明确指定的 PR 不受作者限制，均需分类。显示数量和每项的一行摘要，然后让维护者选择。

分类处理任务或 PR

1. 收集背景信息。 阅读正文、评论、角色、作者、日期和之前的分类处理备注；对于 PR，还要阅读差异。参考 AGENTS.md 指向的领域词汇表和适用的架构决策记录进行探索。按领域概念搜索现有实现，并报告你查找过的位置。如果 AGENTS.md 指定了范围外文件夹，则阅读其中的记录，并指出相关的既往拒绝。
2. 提出建议。 给出类别和状态，说明理由，并概述相关代码库情况，包括已经实现的行为。等待指示。
3. 验证。 开始完善前，根据报告者提供的步骤复现问题。对于 PR，检查差异是否符合其声明，并运行相关测试或命令。报告已确认的行为及其代码路径、失败情况或细节不足。细节不足时，可以建议暂缓处理。
4. 必要时完善。 按照访谈方法与相关人员厘清问题。如果某个术语含义模糊、有争议，或与词汇表或代码冲突，请指出冲突，用具体场景验证，建议一个规范术语，并在人类确认后，按照glossary-format.md将其写入词汇表。将尚未解决的提案保留在该功能的草案中，将已达成一致的行为和验收标准纳入其规范，并按照decision-record-format.md记录难以撤销的决策。
5. 落实已确认的结果：
   • ready：发布一份Agent 简报。它是权威的任务执行约定，链接到规范文档和适用要求。说明工作需要人工介入的原因。
   • on-hold：发布备注，准确说明暂缓处理等待什么。将候选延期事项保留在权威配置的待办列表中：本地跟踪使用本地正文，远程跟踪使用已批准的远程更新。等待发布的内容和当前暂停的工作应保留在本地工作状态中，而不是放入相互冲突的待办列表或复制跟踪器状态。
   • not-planned，已实现：通过链接指向现有实现并关闭。这不属于拒绝，也不应纳入拒绝知识库。
   • not-planned，已拒绝的缺陷：礼貌地说明原因并关闭。
   • not-planned，已拒绝的增强：创建或更新范围外记录，在评论中附上链接，然后关闭。
   • to-evaluate：应用角色设置，并可选择记录部分进展。
6. 按照project-documents.md更新相关本地背景信息和根目录变更日志。报告结果和后续行动。

快速覆盖状态

如果维护者直接指定状态，则遵从其决定。操作前确认角色变更、评论或关闭操作，并跳过完善环节。如果在未进行完善会话的情况下将状态改为 ready，请询问是否需要 Agent 简报。这一明确覆盖不代表缺失的简报已存在。

暂缓处理模板

## Triage Notes

**What we've established so far:**

- Resolved fact or decision

**Waiting on:** the concrete reply, dependency, or blocker that must arrive

**What we still need (@reporter):**

- Specific, actionable question

记录已经解决的问题，避免后续会话重复讨论。准确说明暂缓事项，确保无需重读整个讨论串也能判断暂缓条件是否已解除。

恢复处理

阅读之前的备注、尚待回答的问题和相关的当前工作背景。检查所述暂缓条件是否已解除，并在继续前提供最新情况。复用已解决问题的答案，不要再次提问。