Comet GitHub Issue 分诊

先读取 ../comet-github/references/maintainer-contract.md。除非用户明确授权 GitHub 或代码变更，否则保持只读。

收集当前证据

1. 阅读完整 Issue 正文、评论、标签、作者、时间、关联 PR 和此前的分诊记录。
2. 按领域概念搜索已有 Issue，而不只是复用报告者的原文措辞。识别重复、被替代的 Issue 和已经实现的行为。
3. 检查当前源码、配置、安装路径、生成资产和相关测试，以实际仓库契约作为判断依据。
4. Bug 信息充分时复现最小有效路径。环境或凭证问题需要区分本地设置和产品行为。

不要仅因描述听起来合理就认定存在缺陷。报告可能有效、夸大、过期，或由本地安装/配置不一致造成。

分类结果

选择一个主要分类：

• confirmed defect：当前行为违反用户可见行为或仓库契约，且证据能定位路径；
• likely defect：证据较强，但仍缺少复现或决定性边界；
• configuration/install issue：产品行为正确，或本地安装已过期/配置错误；
• duplicate/already implemented：行为或 Issue 已在其他位置存在；
• insufficient information：需要补充具体步骤、版本、日志、平台或项目状态；
• feature request：请求的是新能力，而不是回归问题。

报告与下一步

返回分类和置信度、检查过的证据、相关代码/Runtime 路径、已确认和未知的内容，以及建议动作：补充信息、本地修复、创建聚焦 follow-up、关联已有 PR，或按重复/已实现处理。

不得自动关闭、加标签、评论或创建 follow-up Issue。确实需要新 Issue 时，用户确认范围后再交给 comet-github-idea-to-issue 起草。