Issue 与 PR 自动化

了解上游分诊、CI 和发布之间的分工，以及实际触发条件。

This page has not been translated into English yet. The original Chinese version is shown below.

Qwen Code 上游通过 GitHub Actions 分别处理 issue 分诊、PR 检查和发布。它们是仓库维护流程，不是安装 CLI 后会在用户项目中自动启用的功能。

Issue 分诊

分诊工作流监听 issue opened、edited、reopened，并支持手动运行。官方维护指南按 area、kind 和 priority 分类，还会使用 need-information、need-retesting 等标签表达后续动作。

标签帮助维护者筛选问题，但不能替代重现材料。报告时应提供实际版本、运行平台、触发步骤和必要日志；补充资料后也要检查自动化是否已重新处理。

维护指南给出 @qwen-code /triage 评论入口。该入口受维护权限和工作流授权逻辑约束，不是任何外部评论都能触发等价执行。

当前分诊工作流还监听 pull_request_target 的 opened、ready_for_review，以及新建 issue_comment。工作流为相关处理声明 issues 和 pull-requests 写权限，但这不表示每个事件都会直接写入或执行 PR 代码。

实现中还有 fork PR 的预检查、操作授权和具体命令分支。审查自动化变更时，需要沿实际事件和命令检查这些条件，不能仅看到触发器就推断所有评论者拥有相同能力。

主 CI 支持 push、PR、merge_group、调度及手动入口，但各 job 仍受 profile 和条件控制。平台覆盖、脚本测试和 coverage 是否运行，要核对具体步骤；旧维护文档关于每次 PR 全平台检查或固定 coverage 评论的表述不能当作当前保证。

独立 E2E 工作流目前主要通过指定分支推送、调度或手动触发，见集成测试。一次 PR 检查全绿只说明该次实际执行的检查通过。

标签、PR 合并和夜间调度分别属于不同流程。问题获得标签不等于代码修复，PR 合并也不等于目标 npm 渠道已更新。

判断修复是否可用时，应追踪关联变更、对应发布记录与实际包版本。维护自动化的默认值及演练入口见发布工作流。