triage-issue-reports

分类处理问题报告

对一条 Slack 报告进行分类，并在其来源线程中发布一条有用的结论。只有确认是新 bug 时才创建跟踪问题。不要在此处复现或修复问题。

加载自动化提供的外部 Benny 配置。如果配置缺失、格式错误或不完整，请停止，不要发帖，也不要写入跟踪系统。

严格安全规则

• 来源频道和根线程坐标不可更改。
• 绝不要在来源频道发布根消息。
• 绝不要向其他频道发帖、广播回复、发送私信或另开替代线程。
• 在写入跟踪系统之前，以及发布结论之前立即预检来源父消息。
• 如果父消息缺失、已删除、无法访问或状态不确定，请停止，不进行任何写入。
• 发布一条有实质内容的结论。不要叙述进度。
• 协调者是唯一可以在 Slack 发帖的人。
• 委派的工作者只能返回调查结果。它们必须只读，且不得获得 Slack 凭据或写入操作。
• 每个子提示词都必须禁止使用 SendSlackMessage、PostToSlack、chat.postMessage 以及所有其他 Slack 写入操作。
• 如果无法通过隔离来强制执行这些限制，则由协调者自行完成工作。
• 绝不要创建无法链接回来源线程的问题。
• 宁可不创建工单，也不要创建猜测或重复的工单。
• 对来源坐标应用 pstack 的 principle-separate-before-serializing-shared-state。
• 对最终结论应用 pstack 的 principle-minimize-reader-load 和 unslop 技能。

1. 固定来源坐标

在列出工作项或委派任务之前：

1. 从触发信息中读取 source_channel_id。
2. 确认它与配置的来源频道一致。
3. 如果存在 trigger.thread_ts，则将 SOURCE_THREAD_TS 设为该值；否则设为 trigger.ts。
4. 确认 SOURCE_THREAD_TS 非空。
5. 将 SOURCE_CHANNEL_ID 和 SOURCE_THREAD_TS 保存为不可变值。
6. 读取线程，并确认其根消息的坐标恰好与这些值一致。
7. 获取稳定的来源永久链接。

之后所有来源读取和发帖都必须使用这些已保存的值。绝不要用回复时间戳或运维线程时间戳替换它们。

2. 阅读完整报告

在作出判断之前，阅读根消息和当前所有回复。

记录：

• 报告者的原话
• 产品版本、应用构建版本、环境和平台（如有）
• 预期行为
• 实际行为
• 发生频率和触发条件
• 错误文本或堆栈特征
• 现有问题、提交或拉取请求的链接
• 是否有人明确表示已经在修复

检查所有相关附件。

• 以足够清晰的分辨率查看截图。
• 检查视频中正确行为转为异常行为的状态变化。
• 阅读日志、跟踪记录和崩溃文本，寻找具体特征。
• 如果需要专门审查媒体，使用只读媒体工作者并提出范围明确的问题。工作者只能返回调查结果。
• 如果无法读取某个附件，请在结论中说明。不要臆测附件内容。

在向报告者索取更多信息之前，先使用线程中已有的证据。

3. 路由前追查原因

在选择负责人或处理去向之前，有限度地检查源代码和历史记录。使用 pstack 的 how 技能，追踪从报告所述操作到实际结果的路径。如果报告看起来像回归问题或涉及防御性代码，则使用 why。

1. 根据报告所述操作，确定通向实际结果的可能代码路径。
2. 检查可见症状是否属于该代码路径，或属于其下层依赖。
3. 如果报告看起来像回归问题，则检查近期变更。
4. 检查是否已有合并提交或开放的拉取请求在处理相同症状。
5. 区分已确认事实和假设。

此步骤不要求找到完整根因，但必须有足够依据，避免将可见症状路由给错误的负责人。

如果无法读取代码仓库，不要猜测代码负责人。继续进行保守分类，并说明无法追查原因。

4. 分类

选择一个类别。

Bug

某些行为违反了预期。示例包括输出错误、状态异常、报错、崩溃、卡住、无提示地无操作，或出现回归。

性能

报告描述了可测量的运行缓慢、内存占用过高、电量消耗、卡顿或其他资源问题。将其视为 Bug，但保留测量数据和性能分析资料。

功能请求

当前行为看起来是有意设计的，报告者希望改变行为或增加某种功能。

问题或反馈

报告者询问某项功能的工作方式、表达了偏好但没有指出具体缺陷，或提供了一般性反馈。

转交

原因追踪表明，该问题应由另一个已配置的目标负责。

当 Bug 与功能请求的界限不明确时，不要提交。唯一的结论可以提出一个聚焦的问题，并使用 other 标记。

5. 应用已配置的路由

从 routing.map_path 读取可选的路由映射。

• 根据已确认的产品领域、代码路径或错误特征进行匹配。
• 如果原因追踪指向其他问题，仅凭表面症状不足以进行匹配。
• 如果没有匹配的路由，说明负责人不明确。不要猜测。
• 不要跨渠道重复发布。告知报告者应在源帖中将问题提交到哪里。

默认情况下，不会通知负责人。只有满足以下所有条件时才允许通知：

1. 路由映射明确指定了负责人。
2. 配置允许此类通知。
3. 该事项是需要负责人提供意见的功能请求，或近期历史记录有充分证据表明某人可能是回归的引入者。
4. 负责人不是范围过广的值班团队。

其他情况一律不得通知负责人。

6. 使用问题跟踪器适配器

问题跟踪器是适配器，并非必需使用某个特定供应商。Linear 适配器是一个有效示例。GitHub Issues 适配器或其他问题跟踪器也可以实现相同的契约。

已配置的适配器必须提供以下功能：

• 按文本、状态、标签、来源 URL 和日期范围搜索问题
• 读取单个问题及其链接
• 创建包含标题、正文、状态、标签和来源 URL 的问题
• 更新现有问题，且不替换无关字段
• 添加来源链接和再次发生的备注
• 如果 Slack 移交失败，取消、关闭或删除本次运行创建的问题

如果无法执行必需操作，则对此写入操作采取失败关闭策略。

在运行时解析已配置的团队、项目、状态和标签。不要臆造 ID、创建标签、分配负责人，或设置优先级，除非配置明确要求这样做。

7. 去重

始终检查此来源永久链接是否已关联到问题跟踪器中的问题或先前的分流回复。如果是，不要重复发布或创建重复问题。

对于 Bug 和性能报告，使用以下信息搜索问题跟踪器：

• 完全匹配的错误或崩溃特征
• 产品领域
• 触发条件
• 症状
• 版本或日期范围
• 疑似引入回归的提交
• 来源永久链接

选择一种结果：

• 确认重复：特征相同，或领域、触发条件和症状相同，或已确认原因相同。
• 可能相关：可能存在共同原因，但尚未证实。
• 相似性较弱：相似之处只是表面的。
• 无匹配项。

对于确认重复的问题，在现有问题中更新来源永久链接，并添加一条简短的再次发生备注。除非配置另有要求，否则不要重新打开、重新标记或重新分配该问题。

对于可能匹配的问题，在结论中注明关联关系尚不确定，不要创建新问题。

长期关闭的问题可作为回归线索，但不应自动视为仍在处理的重复问题。

8. 判断是否创建

仅当以下条件全部满足时才创建：

1. 分类为 bug 或 performance。
2. 行为明显异常。
3. 问题仍然存在，或尚不确定是否已修复。
4. 去重未找到可信或可能仍存在的匹配项。
5. 来源父级和永久链接通过了预检。
6. 跟踪器目标字段已解析。
7. 如果判定回复发布失败，适配器能够进行补偿。

切勿为功能请求、问题、反馈项、重新路由、可能重复、确定重复或已修复的问题创建条目。

新问题必须自包含：

• 简洁明了的标题，指出相关领域和症状
• 报告者的原话
• 预期行为和实际观察到的行为
• 版本和环境，或 unknown
• 触发条件和发生频率
• 来源线程永久链接
• 简短的原因追踪结果，并将假设明确标为假设
• 支持时附上内嵌截图或有代表性的视频帧
• 其余材料的链接
• 已配置的受理状态和标签

不要在标题中写入猜测的根本原因。

9. 发布一条判定回复

重新执行来源父级预检。然后只发布一条回复，并设置 channel=SOURCE_CHANNEL_ID 和 thread_ts=SOURCE_THREAD_TS。

调用来源频道的发布操作时，thread_ts 必须非空。

回复应简短：

• 开头说明结论。
• 如有现成或新建的跟踪器问题，附上链接。
• 必要时说明重新路由或一项缺失的信息。
• 最多提及一位允许联系的负责人。
• 以且仅以一行标记结尾。

标记约定：

[benny:bug]
[benny:bug] tracker=https://tracker.example/issue/123
[benny:performance]
[benny:performance] tracker=https://tracker.example/issue/123
[benny:other]

只能使用已配置的标记字符串。只有当标记由已配置的分诊身份发布在此来源线程中时，复现自动化才会认可该标记。

发布后，读取同一来源线程，并确认判定回复出现在 SOURCE_THREAD_TS 下。如果没有，切勿在根级别重试。

如果本次运行创建了跟踪器问题，但判定回复未成功发布，则使用适配器的补偿操作。确认该问题已取消、关闭或删除。如果无法确认补偿结果，只在自动化运行输出中报告失败。

10. 观察一个后续跟进时段

在已配置的后续跟进时段内观察来源线程，然后停止。

• 只回答直接向分诊身份提出的问题。
• 安全时，对跟踪器问题应用具体更正。
• 同一次运行中不要发布第二个标记。
• 不介入人工协调和无关讨论。
• 如果有人要求自动化停止，立即停止。

延长时段最多一次。新报告应启动新的运行。