在 Slack 线程中分类问题报告并安全创建追踪工单

当需要从 Slack 线程中的问题报告自动分类、去重并决定是否创建追踪工单时使用。

适用场景

解决思路

1. 加载自动化提供的外部 Benny 配置；如果配置缺失、格式错误或不完整，停止操作，不发布消息也不写入追踪器。
2. 冻结源坐标：从触发器中读取 source_channel_id，要求它等于配置的源频道；将 SOURCE_THREAD_TS 设为 trigger.thread_ts（若存在），否则用 trigger.ts；要求 SOURCE_THREAD_TS 非空；将 SOURCE_CHANNEL_ID 和 SOURCE_THREAD_TS 存为不可变值；读取线程并验证其根消息坐标完全一致；获取稳定的源永久链接。之后所有源读取和发布都必须使用这些存储值，绝不用回复时间戳或操作线程时间戳替换。
3. 阅读完整报告：在决定前读取根消息和当前回复，捕获报告者措辞、产品版本、应用构建、环境、平台、预期行为、观察行为、频率与触发条件、错误文本或堆栈签名、已有 issue/commit/PR 链接、以及任何明确说明有人已在修复的陈述。
4. 检查每个相关附件：以完整可用分辨率读取截图；查看视频中区分正确与错误行为的状态转换；读取日志、追踪和崩溃文本中的具体签名；如果媒体需要专家审查，使用只读媒体 worker 并问一个窄问题，worker 只返回发现；如果附件无法读取，在裁决中说明，不要编造其内容。
5. 在向报告者索要更多信息前，先使用线程中已有的证据。
6. 在路由前追踪原因：在选所有者或目的地前做有界的源码和历史检查；使用 pstack 的 how 技能追踪从报告动作到观察结果的路径；当报告看起来像回归或涉及防御性代码时使用 why；识别从报告动作到观察结果的可能代码路径；检查可见症状属于该代码路径还是其下层依赖；当报告看起来像回归时检查近期变更；检查已合并的 commit 或打开的 PR 是否已处理相同症状；区分已确认事实与假设。如果仓库无法读取，不要猜测代码所有者，继续保守分类并说明原因追踪不可用。
7. 分类：选择以下之一——Bug（违反预期行为，如错误输出、状态损坏、错误、崩溃、挂起、静默无操作或回归）；Performance（可测量的缓慢、内存过多、耗电、卡顿或其他资源问题，按 bug 处理但保留测量和 profile）；Feature request（当前行为看似有意，报告者想要不同行为或功能）；Question or feedback（询问如何工作、表达偏好但无具体缺陷、或一般反馈）；Reroute（原因追踪显示另一个配置目的地拥有该问题）。当 bug 与 feature 界限不清时，不要提交工单；裁决可以问一个聚焦问题并使用 other 标记。
8. 应用配置路由：从 routing.map_path 读取可选路由映射；根据已确认的产品区域、代码路径或错误签名匹配；当原因追踪指向别处时，仅凭可见症状不够；如果没有路由匹配，说明所有者不明确，不要猜测；不要交叉发布，在源线程中告诉报告者将问题带到哪里。所有者 ping 默认关闭；仅当以下全部成立时才允许 ping：路由映射明确指定所有者；配置允许该 ping 类型；该项是需要所有者输入的 feature request，或近期历史以强证据识别出可能的回归作者；所有者不是广泛的 on-call 组。其他情况不得 ping。
9. 使用 issue-tracker 适配器：追踪器是适配器而非必需供应商；Linear 适配器是一个有效示例；GitHub Issues 适配器或其他追踪器可实现相同契约。配置的适配器必须提供：按文本、状态、标签、源 URL 和日期范围搜索 issue；读取一个 issue 及其链接；创建带标题、正文、状态、标签和源 URL 的 issue；更新现有 issue 而不替换无关字段；添加源链接和复发说明；如果 Slack 交接失败，取消、关闭或删除本次运行创建的 issue。如果所需操作不可用，对该写入 fail closed。在运行时解析配置的团队、项目、状态和标签；不要编造 ID、创建标签、分配所有者或设置优先级，除非配置明确要求。
10. 去重：始终检查此源永久链接是否已链接到追踪器 issue 或先前的分类回复；如果是，不要发布或创建重复项。对于 bug 和 performance 报告，使用以下条件搜索追踪器：精确错误或崩溃签名、产品区域、触发条件、症状、版本或日期窗口、疑似回归 commit、源永久链接。选择一种结果：Confident duplicate（相同签名，或相同区域、触发条件和症状，或已确认的共同原因）；Possibly related（共同原因可能但未证实）；Weak resemblance（相似性表面）；No match。对于 confident duplicate，用源永久链接和一条简短复发说明更新现有 issue；不要重新打开、重新标记或重新分配，除非配置要求。对于 possible match，在裁决中作为不确定项链接，不创建任何内容。长期关闭的 issue 是回归线索，不自动是活跃重复项。
11. 决定是否创建：仅当以下全部成立时才创建：分类为 bug 或 performance；行为明确损坏；问题仍活跃或未知已修复；去重未发现 confident 或 plausible 的活跃匹配；源父消息和永久链接通过预检；追踪器目标字段已解析；适配器能在裁决发布失败时补偿。绝不为 feature request、question、feedback、reroute、possible duplicate、confident duplicate 或已修复 issue 创建。新 issue 必须自包含：命名区域和症状的简洁标题；报告者引用；预期和观察行为；版本和环境，或 unknown；触发条件和频率；源线程永久链接；简短原因追踪发现，假设标注为假设；支持时内联截图或代表性视频帧；剩余工件的链接；配置的 intake 状态和标签。不要在标题中放入猜测的根本原因。
12. 发布一条裁决：运行新的源父消息预检；然后使用 channel=SOURCE_CHANNEL_ID 和 thread_ts=SOURCE_THREAD_TS 发布恰好一条回复。绝不在 thread_ts 为空时调用源频道发布操作。保持回复简短：以结果开头；有现有或新追踪器 issue 时链接它；需要时提及 reroute 或一个缺失事实；最多包含一个允许的所有者 ping；以恰好一行标记结尾。标记契约：仅使用配置的标记字符串，如 [benny:bug]、[benny:bug] tracker=https://tracker.example/issue/123、[benny:performance]、[benny:performance] tracker=https://tracker.example/issue/123、[benny:other]。repro 自动化仅当标记来自此源线程中配置的分类身份时才信任它。发布后，读取同一源线程并验证裁决出现在 SOURCE_THREAD_TS 下；如果没有，绝不在根消息重试。如果本次运行创建了追踪器 issue 但裁决未落地，使用适配器的补偿操作；验证 issue 已取消、关闭或删除；如果补偿无法验证，仅在自动化运行输出中报告失败。
13. 观察一个跟进窗口：在配置的跟进窗口内观察源线程，然后停止。仅回答对分类身份的直接问题；在安全时对追踪器 issue 应用具体更正；同一次运行中不要发出第二个标记；远离人类协调和闲聊；如果有人要求自动化停止，提前停止。不要将窗口延长超过一次；新报告应开始新运行。

适用边界 · 注意事项

• 仅限从配置的 Benny 分类自动化中使用；不适用于其他上下文。
• 如果外部 Benny 配置缺失、格式错误或不完整，停止操作，不发布消息也不写入追踪器。
• 如果源父消息缺失、删除、不可访问或不确定，停止且不写入。