Issue 与 PR 自动化

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

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 渠道已更新。

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