Back to Details

triage-issue-reports

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Triage issue reports

问题报告分流

Classify one Slack report and post one useful verdict in its source thread. Create a tracker issue only for a clear, new bug. Do not reproduce or fix it here.
Load the external Benny configuration supplied by the automation. If the config is missing, malformed, or incomplete, stop without posting or writing to the tracker.
对一份Slack报告进行分类，并在其源线程中发布一份有用的结论。仅针对明确的新bug创建追踪器工单。请勿在此处复现或修复问题。
加载自动化工具提供的外部Benny配置。如果配置缺失、格式错误或不完整，则停止操作，不发布任何内容或向追踪器写入信息。

Hard safety rules

硬性安全规则

  • The source channel and root thread coordinates are immutable.
  • Never post a root message in the source channel.
  • Never post to another channel, broadcast a reply, send a DM, or start a replacement thread.
  • Preflight the source parent before any tracker write and immediately before the verdict post.
  • If the parent is missing, deleted, inaccessible, or uncertain, stop with no writes.
  • Post one substantive verdict. Do not narrate progress.
  • The coordinator is the only Slack poster.
  • Delegated workers return findings only. They must be read-only and receive no Slack credentials or write actions.
  • Every child prompt must forbid 
    SendSlackMessage
    , 
    PostToSlack
    , 
    chat.postMessage
    , and every other Slack write.
  • If worker isolation cannot enforce those limits, do the work in the coordinator.
  • Never create an issue that cannot link back to the source thread.
  • Prefer no ticket over a guessed or duplicate ticket.
  • Apply pstack's 
    principle-separate-before-serializing-shared-state
    to source coordinates.
  • Apply pstack's 
    principle-minimize-reader-load
    and 
    unslop
    skills to the final verdict.
  • 源频道和根线程坐标不可变更。
  • 切勿在源频道中发布根消息。
  • 切勿发布到其他频道、广播回复、发送私信或启动替代线程。
  • 在向追踪器写入任何内容之前，以及发布结论之前，预先检查源父消息。
  • 如果父消息缺失、已删除、无法访问或存在不确定性，则停止操作，不进行任何写入。
  • 发布一份实质性结论。请勿叙述进度。
  • 协调器是唯一可在Slack发布内容的角色。
  • 委托的工作线程仅返回调查结果。它们必须是只读的，不得获取Slack凭据或执行写入操作。
  • 每个子提示必须禁止
    SendSlackMessage
    、
    PostToSlack
    、
    chat.postMessage
    以及所有其他Slack写入操作。
  • 如果工作线程隔离无法执行这些限制，则由协调器完成相关工作。
  • 切勿创建无法链接回源线程的工单。
  • 相较于猜测或重复的工单，更倾向于不创建工单。
  • 对源坐标应用pstack的
    principle-separate-before-serializing-shared-state
    原则。
  • 对最终结论应用pstack的
    principle-minimize-reader-load
    和
    unslop
    技能。

1. Freeze source coordinates

1. 冻结源坐标

Before making a work list or delegating:
  1. Read 
    source_channel_id
    from the trigger.
  2. Require it to equal the configured source channel.
  3. Set 
    SOURCE_THREAD_TS
    to 
    trigger.thread_ts
    when present. Otherwise use 
    trigger.ts
    .
  4. Require a nonempty 
    SOURCE_THREAD_TS
    .
  5. Store 
    SOURCE_CHANNEL_ID
    and 
    SOURCE_THREAD_TS
    as immutable values.
  6. Read the thread and verify that its root has exactly those coordinates.
  7. Fetch a stable source permalink.
Every later source read and post must use those stored values. Never replace them with a reply timestamp or an operations-thread timestamp.
在制定工作列表或委托任务之前：
  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. Read the whole report

2. 读取完整报告

Read the root and current replies before deciding.
Capture:
  • Reporter wording
  • Product version, app build, environment, and platform when present
  • Expected behavior
  • Observed behavior
  • Frequency and trigger
  • Error text or stack signature
  • Existing issue, commit, or pull request links
  • Any explicit statement that someone is already fixing it
Inspect every relevant attachment.
  • Read screenshots at full useful resolution.
  • Review video for the state transition that separates correct and broken behavior.
  • Read logs, traces, and crash text for concrete signatures.
  • If media needs specialist review, use a read-only media worker and ask a narrow question. The worker returns findings only.
  • If an attachment cannot be read, say so in the verdict. Do not invent what it shows.
Use evidence already in the thread before asking the reporter for more.
在做出决定之前，读取根消息和当前所有回复。
捕获以下信息：
  • 报告者的表述
  • 产品版本、应用构建版本、环境和平台（如果存在）
  • 预期行为
  • 观察到的行为
  • 发生频率和触发条件
  • 错误文本或堆栈签名
  • 现有工单、提交记录或拉取请求链接
  • 任何明确说明有人正在修复该问题的表述
检查所有相关附件。
  • 以有效分辨率读取截图。
  • 查看视频，找出区分正确行为和错误行为的状态转换点。
  • 读取日志、追踪信息和崩溃文本，获取具体签名。
  • 如果媒体需要专业审核，请使用只读媒体工作线程并提出明确的问题。工作线程仅返回调查结果。
  • 如果无法读取附件，请在结论中说明。切勿编造附件内容。
在向报告者询问更多信息之前，优先使用线程中已有的证据。

3. Trace cause before routing

3. 追踪原因后再路由

Do a bounded source and history pass before choosing an owner or destination. Use pstack's 
how
skill to trace the path from the reported action to the observed result. Use 
why
when the report looks like a regression or touches defensive code.
  1. Identify the likely code path from the reported action to the observed result.
  2. Check whether the visible symptom belongs to that code path or a dependency below it.
  3. Check recent changes when the report looks like a regression.
  4. Check whether a merged commit or open pull request already addresses the same symptom.
  5. Separate confirmed facts from hypotheses.
This pass does not need a complete root cause. It must be strong enough to avoid routing a visible symptom to the wrong owner.
If the repository cannot be read, do not guess a code owner. Continue with a conservative classification and say that cause tracing was unavailable.
在选择负责人或目标之前，进行有限的源和历史信息核查。使用pstack的
how
技能追踪从报告的操作到观察结果的路径。当报告看起来像是回归问题或涉及防御性代码时，使用
why
技能。
  1. 确定从报告的操作到观察结果的可能代码路径。
  2. 检查可见症状是否属于该代码路径或其下方的依赖项。
  3. 当报告看起来像是回归问题时，检查近期变更。
  4. 检查是否已有合并的提交记录或开放的拉取请求解决了相同症状。
  5. 区分已确认的事实与假设。
此步骤不需要完整的根本原因，但必须足够准确，以避免将可见症状路由给错误的负责人。
如果无法读取代码仓库，则不要猜测代码负责人。继续进行保守分类，并说明原因追踪不可用。

4. Classify

4. 分类

Choose one category.
选择一个类别。

Bug

Bug

Something violates intended behavior. Examples include wrong output, broken state, an error, a crash, a hang, a silent no-op, or a regression.
某些内容违反了预期行为。示例包括错误输出、状态损坏、错误、崩溃、挂起、静默无操作或回归问题。

Performance

性能

The report describes measurable slowness, excess memory, battery drain, jank, or another resource problem. Treat it as a bug, but preserve measurements and profiles.
报告描述了可测量的缓慢、内存占用过高、电池消耗、卡顿或其他资源问题。将其视为Bug，但保留测量数据和性能分析文件。

Feature request

功能请求

The current behavior appears intentional and the reporter wants a different behavior or affordance.
当前行为看起来是有意设计的，报告者希望获得不同的行为或功能。

Question or feedback

问题或反馈

The report asks how something works, expresses a preference without a concrete defect, or gives general feedback.
报告询问某项功能的工作方式、表达了对非具体缺陷的偏好，或提供了一般性反馈。

Reroute

重新路由

Cause tracing shows that another configured destination owns the issue.
When the bug versus feature line is unclear, do not file. The one verdict may ask one focused question and use the 
other
marker.
原因追踪显示另一个已配置的目标负责该问题。
当Bug与功能的界限不明确时，不要创建工单。结论中可以提出一个明确的问题，并使用
other
标记。

5. Apply configured routing

5. 应用已配置的路由规则

Read the optional routing map from 
routing.map_path
.
  • Match on confirmed product area, code path, or error signature.
  • A visible symptom alone is not enough when cause tracing points elsewhere.
  • If no route matches, say the owner is unclear. Do not guess.
  • Do not cross-post. Tell the reporter where to take the issue in the source thread.
Owner pings are off by default. A ping is allowed only when all of these hold:
  1. The routing map explicitly names the owner.
  2. The config allows that ping type.
  3. The item is a feature request that needs owner input, or recent history identifies a likely regression author with strong evidence.
  4. The owner is not a broad on-call group.
No other case gets a ping.
从
routing.map_path
读取可选的路由映射。
  • 根据已确认的产品领域、代码路径或错误签名进行匹配。
  • 当原因追踪指向其他方向时，仅凭可见症状不足以进行匹配。
  • 如果没有匹配的路由，请说明负责人不明确。切勿猜测。
  • 不要交叉发布。在源线程中告知报告者应将问题提交至何处。
默认情况下不@负责人。仅当满足以下所有条件时，才允许@负责人：
  1. 路由映射明确指定了负责人。
  2. 配置允许该类型的@操作。
  3. 该条目是需要负责人输入的功能请求，或近期历史记录以确凿证据表明可能的回归作者。
  4. 负责人不是广泛的随叫随到团队。
其他任何情况都不得@负责人。

6. Use the issue-tracker adapter

6. 使用工单追踪器适配器

The tracker is an adapter, not a required vendor. A Linear adapter is one valid example. A GitHub Issues adapter or another tracker may implement the same contract.
The configured adapter must provide:
  • Search issues by text, state, label, source URL, and date range
  • Read one issue and its links
  • Create an issue with title, body, status, labels, and source URL
  • Update an existing issue without replacing unrelated fields
  • Add a source link and recurrence note
  • Cancel, close, or delete an issue created by this run if the Slack handoff fails
If a required operation is unavailable, fail closed for that write.
Resolve configured team, project, status, and labels at runtime. Do not invent IDs, create labels, assign owners, or set priority unless the config explicitly requires it.
追踪器是一个适配器，而非必需的供应商。Linear适配器是一个有效的示例。GitHub Issues适配器或其他追踪器可以实现相同的协议。
已配置的适配器必须提供以下功能：
  • 按文本、状态、标签、源URL和日期范围搜索工单
  • 读取单个工单及其链接
  • 创建包含标题、正文、状态、标签和源URL的工单
  • 更新现有工单而不替换无关字段
  • 添加源链接和重复出现的说明
  • 如果Slack交接失败，取消、关闭或删除本次运行创建的工单
如果所需操作不可用，则该写入操作失败并关闭。
在运行时解析已配置的团队、项目、状态和标签。除非配置明确要求，否则不要创建ID、创建标签、分配负责人或设置优先级。

7. Dedupe

7. 去重

Always check whether this source permalink is already linked to a tracker issue or a prior triage reply. If so, do not post or create a duplicate.
For bugs and performance reports, search the tracker using:
  • Exact error or crash signature
  • Product area
  • Trigger
  • Symptom
  • Version or date window
  • Suspected regression commit
  • Source permalink
Choose one outcome:
  • Confident duplicate: same signature, or the same area, trigger, and symptom, or a confirmed shared cause.
  • Possibly related: a shared cause is plausible but not proven.
  • Weak resemblance: similarity is superficial.
  • No match.
For a confident duplicate, update the existing issue with the source permalink and one short recurrence note. Do not reopen, relabel, or reassign it unless the config says to.
For a possible match, link it in the verdict as uncertain and create nothing.
A long-closed issue is a regression lead, not automatically a live duplicate.
始终检查该源永久链接是否已链接到追踪器工单或之前的分流回复。如果是，则不要发布内容或创建重复工单。
对于Bug和性能报告，使用以下条件搜索追踪器：
  • 精确的错误或崩溃签名
  • 产品领域
  • 触发条件
  • 症状
  • 版本或时间范围
  • 疑似回归的提交记录
  • 源永久链接
选择一种结果：
  • 确定重复：相同签名，或相同领域、触发条件和症状，或已确认的共同原因。
  • 可能相关：共同原因看似合理但未证实。
  • 弱相似性：相似性仅为表面现象。
  • 无匹配。
对于确定重复的情况，使用源永久链接和简短的重复说明更新现有工单。除非配置要求，否则不要重新打开、重新标记或重新分配工单。
对于可能匹配的情况，在结论中以不确定的方式链接它，不创建任何新工单。
长期关闭的工单是回归线索，而非自动视为活跃的重复工单。

8. Decide whether to create

8. 决定是否创建工单

Create only when all of these are true:
  1. The classification is bug or performance.
  2. The behavior is clearly broken.
  3. The issue is still live or not known to be fixed.
  4. Dedupe found no confident or plausible live match.
  5. The source parent and permalink passed preflight.
  6. The tracker target fields resolved.
  7. The adapter can compensate if the verdict post fails.
Never create for a feature request, question, feedback item, reroute, possible duplicate, confident duplicate, or already-fixed issue.
The new issue must be self-contained:
  • Plain title that names the area and symptom
  • Reporter quote
  • Expected and observed behavior
  • Version and environment, or 
    unknown
  • Trigger and frequency
  • Source thread permalink
  • Short cause-tracing findings with hypotheses labeled as hypotheses
  • Inline screenshot or representative video frame when supported
  • Links to remaining artifacts
  • Configured intake status and labels
Do not put a guessed root cause in the title.
仅当满足以下所有条件时才创建工单：
  1. 分类为Bug或性能问题。
  2. 行为明显异常。
  3. 问题仍处于活跃状态或未知已修复。
  4. 去重未找到确定或疑似的活跃匹配项。
  5. 源父消息和永久链接通过预先检查。
  6. 追踪器目标字段已解析。
  7. 如果结论发布失败，适配器可以进行补偿。
切勿为功能请求、问题、反馈项、重新路由、可能重复、确定重复或已修复的问题创建工单。
新工单必须独立完整：
  • 明确命名领域和症状的简洁标题
  • 报告者的引用
  • 预期和观察到的行为
  • 版本和环境，或标记为
    unknown
  • 触发条件和频率
  • 源线程永久链接
  • 简短的原因追踪结果（假设需标记为假设）
  • 支持的情况下，嵌入截图或代表性视频帧
  • 剩余工件的链接
  • 已配置的受理状态和标签
请勿在标题中加入猜测的根本原因。

9. Post one verdict

9. 发布一份结论

Run a fresh source-parent preflight. Then post exactly one reply with 
channel=SOURCE_CHANNEL_ID
and 
thread_ts=SOURCE_THREAD_TS
.
Never call a source-channel posting action without a nonempty 
thread_ts
.
Keep the reply short:
  • Lead with the outcome.
  • Link the existing or new tracker issue when there is one.
  • Mention a reroute or one missing fact when needed.
  • Include at most one allowed owner ping.
  • End with exactly one marker line.
Marker contract:
text
[benny:bug]
[benny:bug] tracker=https://tracker.example/issue/123
[benny:performance]
[benny:performance] tracker=https://tracker.example/issue/123
[benny:other]
Use only the configured marker strings. The repro automation trusts the marker only when it comes from the configured triage identity in this source thread.
After posting, read the same source thread and verify the verdict appears under 
SOURCE_THREAD_TS
. If it does not, never retry at the root.
If this run created a tracker issue and the verdict did not land, use the adapter's compensation action. Verify that the issue is canceled, closed, or deleted. If compensation cannot be verified, report the failure only in the automation run output.
重新进行源父消息的预先检查。然后使用
channel=SOURCE_CHANNEL_ID
和
thread_ts=SOURCE_THREAD_TS
发布恰好一条回复。
切勿在没有非空
thread_ts
的情况下调用源频道发布操作。
保持回复简洁：
  • 以结果开头。
  • 如果存在现有或新的追踪器工单，链接该工单。
  • 必要时提及重新路由或一个缺失的事实。
  • 最多包含一个允许的负责人@操作。
  • 以恰好一条标记行结尾。
标记协议：
text
[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. Watch one follow-up window

10. 观察一个跟进窗口

Watch the source thread for the configured follow-up window, then stop.
  • Answer only a direct question to the triage identity.
  • Apply a concrete correction to the tracker issue when safe.
  • Do not emit a second marker in the same run.
  • Stay out of human coordination and side chatter.
  • Stop early if someone asks the automation to stop.
Do not extend the window more than once. A new report should start a new run.
在已配置的跟进窗口内观察源线程，然后停止操作。
  • 仅回答直接针对分流身份的问题。
  • 在安全的情况下，对追踪器工单进行具体修正。
  • 切勿在同一运行中发出第二个标记。
  • 不要参与人工协调和闲聊。
  • 如果有人要求自动化工具停止，则提前停止。
跟进窗口不得延长超过一次。新报告应启动新的运行。