triage-frontend-issues

分流前端问题

从 sentry/javascript 问题队列中归档不可操作的噪声：只归档，始终使用 untilEscalating，并且始终说明原因。看起来可能需要在我们的代码中采取行动的问题，或无法确信如何分类的问题，都必须跳过。

硬性规则

以下规则优先于其他任何内容。不得放宽。

1. 项目范围。 仅操作 organizationSlug=sentry、项目 slug 为 javascript 的项目。如果用户要求分流其他项目，请停止并让用户确认。
2. 仅归档。 唯一允许的状态变更是 status=ignored。绝不解决、取消解决、分配、删除，也绝不批量更新状态以外的字段。
3. 始终使用 untilEscalating。 使用 ignoreMode=untilEscalating。绝不使用 forever、forDuration、untilOccurrenceCount 或 untilUserCount。如果用户要求使用其他模式，请停止并让用户手动归档该问题——此技能不执行不会升级的归档。
4. 始终包含 reason。 reason 必须是简短、客观的句子，并指出 references/archive-criteria.md 中的类别（例如：“第三方库噪声 — echarts 内部问题；在我们的代码中不可操作”）。
5. 绝不触碰未解决队列之外的问题。 跳过 status 为 resolved、ignored 或 reprocessing 的问题。
6. 未经确认绝不归档。 制定完整计划并展示给用户，在调用 update_issue 前等待明确批准。一次批准仅适用于展示的计划；新的批次需要重新批准。
7. 有疑问时跳过。 如果某个问题可能确实是我们代码中的 Bug，请勿归档。在计划中将其标记为 needs-human，并附上一行说明。

前置条件

• 已通过 mcp.sentry.dev 验证 Sentry MCP。所需工具：search_issues、get_sentry_resource、update_issue。
• 如果 update_issue 不可用，请停止并要求用户验证 Sentry MCP 服务。

输入

$ARGUMENTS 必须属于以下一种：

输入形式	含义
Sentry 问题 URL（https://sentry.sentry.io/issues/JAVASCRIPT-…）	分流该单个问题。
问题短 ID（JAVASCRIPT-…）	分流该单个问题。
Sentry 问题查询（包含冒号，例如 is:unresolved firstSeen:-24h）	将其用作搜索查询。
空	使用默认分流队列：is:unresolved is:unassigned firstSeen:-7d，按 new 排序，限制 50 条。

如果 $ARGUMENTS 存在歧义，请在搜索前询问用户以澄清。

工作流

1. 加载队列

对于单个问题输入：

• 调用 get_sentry_resource(url=<issue-url>) 或 get_sentry_resource(resourceType='issue', organizationSlug='sentry', resourceId=<shortId>)。
• 确认 Project 是 javascript 前端项目。如果不是，请停止。

对于查询或默认输入：

• 调用 search_issues(organizationSlug='sentry', projectSlugOrId='javascript', query=<query>, sort='new', limit=50)。
• 然后并行调用每个结果的 get_sentry_resource，以获取 culprit、substatus、assignee 和堆栈帧提示（搜索响应会省略部分字段）。

如果某个问题符合以下任一条件，请立即跳过：

• status 不是 unresolved（已归档、已解决或正在重新处理）。
• assignedTo 已设置为某个人（已有负责人）。
• assignedTo 已设置为 frontend/issues 以外的团队，且问题看起来与该团队相关（交由负责团队分流）。

2. 对每个问题进行分类

阅读 references/archive-criteria.md，了解带有识别启发和示例的分类体系。对于每个候选问题，给出以下一种决定：

决定	含义
archive	符合有文档记录的类别；在理由中注明类别名称。
skip	可能是我们代码中的真实 bug，或证据不足；不要归档。
needs-human	看起来像噪声，但无法明确归入某个类别，或数量异常高；标记出来供用户审核。

评估时按以下顺序权衡这些信号：

1. 最靠前的非 Sentry-SDK 栈帧。 如果应用内最靠前的栈帧位于 node_modules/、chrome-extension://、第三方主机或 <unknown>，这是强烈的归档信号。
2. 标题模式。 许多归档问题仅凭标题即可识别（参见分类标准）。
3. 数量不是否决条件。 即使数量很高（10k+ 个事件、数千名用户），只要最靠前的栈帧来自第三方，问题仍可能值得归档。数量本身不会强制归档。
4. 近期程度。 超过 30 天且没有再次出现的单次事件问题通常是噪声。
5. 客户组织分布。 如果事件仅来自一个客户子域名（检查 customerDomain.subdomain 标签），很可能是客户环境噪声。

3. 制定计划

向用户输出一个 Markdown 表格，格式必须完全如下：

## Triage plan — sentry/javascript (<N> candidates)

| # | Issue | Title | Volume | Decision | Category | Reason |
|---|-------|-------|--------|----------|----------|--------|
| 1 | [JAVASCRIPT-XXXX](url) | TypeError: ... | 12e/3u | archive | browser-api-noise | Browser clipboard permission denied; not actionable. |
| 2 | [JAVASCRIPT-YYYY](url) | <unknown> | 4945e/123u | needs-human | — | High volume, no title — please review before archiving. |
| 3 | [JAVASCRIPT-ZZZZ](url) | ZodError: ... | 360e/132u | skip | — | Schema validation failure in our code; looks actionable. |

然后汇总数量：N archive / M skip / K needs-human。最后以以下内容结尾：

Reply `apply` to archive the N issues marked `archive`, `apply N,M,...` to archive a subset, or `cancel` to take no action.

4. 获批后执行

当用户回复 apply（或 apply <subset>）时：

对获批集合中的每个问题，调用：

update_issue(
  organizationSlug='sentry',
  issueId=<shortId>,
  status='ignored',
  ignoreMode='untilEscalating',
  reason=<category-tagged reason from the plan>,
)

按顺序运行（不要并行）。如果某次调用失败，记录失败并继续处理剩余问题，然后在第 5 步报告失败的 ID。

如果用户回复 cancel 或要求修改计划，不要调用 update_issue。如果他们提出修改（例如“将第 2 行改为 skip”），请重新制定计划并再次确认。

5. 报告

执行后，输出：

## Triage report

- Archived: N
- Skipped: M
- Needs human review: K
- Failures: F (with issue IDs)

<details><summary>Archived issues</summary>

- JAVASCRIPT-XXXX — <reason>
- ...

</details>

恢复处理

• 如果 update_issue 对某一项执行失败，记录失败并继续处理其余项。最后报告失败的 ID。
• 如果用户发现错误归档，用户可以在 Sentry 中自行取消归档。该技能不会自动撤销自己的操作。
• 如果用户在流程中要求“按这些调整重新制定计划”，请从头重新生成计划，不要假设之前的计划仍然适用。

示例理由（采用以下措辞风格）

• 第三方库噪声 — echarts tooltip；在我们的代码中不可处理。
• 浏览器 API 权限噪声 — 用户代理拒绝了 Clipboard writeText。
• 客户环境代理干扰 — 将 200 响应视为错误（企业代理返回 HTML 正文）。
• 后端瞬时 5xx — /api/0/organizations/.../events-meta/ 上的 InternalServerError；后端瞬时故障。
• 测试/合成事件 — 冒烟测试或安全探测，不是生产流量。
• 项目错误 — Prisma/Python 错误被错误路由到前端项目。
• 单次事件异常 — 1 个事件、1 名用户，30 多天内没有再次出现。
• 浏览器扩展噪声 — 扩展注入的全局变量导致 ReferenceError（DarkReader/WeixinJSBridge）。