反馈、Issue 交付与验证

最后复核：2026-10-29 证据来源：用户确认的维护者 PR 流程、相关修复合为一个 PR 的要求、反馈来源与优先级约定、issue #95、PR #96、项目看板状态判据。

反馈收集与汇总

• 来源包括 GitHub issue（含评论与反应）、Discussions（全部分类，含评论与回复）、社区 PR、GitGud issue、Telegram 反馈群聊和 X 提及与回复，只读其中一处不算收齐；读不到的来源写明「未取得」及原因。Discussions 不在 gh issue 与 gh pr 的输出里，要用 GraphQL repository.discussions 读取。
• 「汇总」指一份带优先级和修复批次的总表，不是逐条摘要。每条都要判断：本地是否已修复、属于需求还是缺陷、轻重缓急、马上修还是先讨论、适合放在哪个版本、关联 PR 能否直接合。
• 已修复与否，逐条对照 CHANGELOG.md 的已发布版本和「未发布」段、主线提交与当前代码；没核实的写「未核实」，不凭 issue 开闭状态推断。建单日期晚于修复版本时，要先确认报告者的版本。
• 报告之间可能互相包含，要按问题合并，不能只按编号去重。写明报告人数、编号、关联的社区 PR 和还缺的复现信息。
• 批次由严重性决定先后，由是否共享代码和夹具决定合批。一个批次可以包含多个任务，各自独立提交、统一回归；能用社区 PR 的代码修复就优先采用，保留和社区的沟通记录。同时给出发版建议，说明做完哪几批可以发版，并按 peach-worktree 写明升级后修复能否生效。
• 汇总只读：不评论、不改标签、不关单；后续动作按下列各节另行取得授权。

Issue 与 PR 范围

• 维护者自己的代码与社区贡献都经 PR；小修、文档和测试可直接提 PR。复杂缺陷、新功能、默认行为或架构变化先有 issue，复用已有问题记录，不重复建单。已在对话确认的方向沿用，将目标和取舍留在 issue，不重复审批。
• PR 按可独立验收的目标分组。同一目标的实现、测试、升级补修和解除该交付 CI 失败所需的修复，默认放在同一个 PR，按可单独描述与回退的改动分提交；不按工具、工作者、文件类型或单条警告拆 PR。
• 无关目标分别评审；只有需要独立交付、发布或回退，或确需隔离产品授权、维护归属与实际冲突时才拆 PR，并在说明中写明理由。批次可包含这些独立目标的多个 PR，统一组合验证与集成。
• 提交保持 type(scope): 描述，实现与测试原子提交。PR 记录目标、实际改动、影响面、验证及适用的升级生效方式，具体格式见 贡献约定。
• 在主线合入前完成 PR 审阅与必要验证；本地组合树可用于统一验收。平台不可写时保存分支、PR 说明和验证回执，明确远端 PR 未完成，不以事后补单替代合入前审阅。

沟通与标记

• 默认不自动发表 issue 或 Discussions 评论，也不回复报告者；只有用户明确要求代发时才发送。保留人工已有回复。
• 起草回复时，缺口若源于早期只按维护者自用环境与偏好设计，如实说明这个起点和现在的补齐方向。只写有代码、提交或维护者过往回复为据的经历，推断的内容标出来交维护者确认。
• 重复或交叉的 issue、PR 要指定一条继续跟踪，其余在回复里引用它；互相包含或改同一批文件的 PR 先定评审与合入顺序。
• 在用户授权的 issue 维护范围内，优先用现有标签表达平台、影响域与验证状态。先读取标签和原生 Issue Type，避免重复分类。

合并责任

• 在已授权的开发与仓库操作范围内完成 PR 创建、验证及获准的合并；PR 不是必须由用户手动完成的步骤。
• 用户授权合并后，由你完成必要检查、合并和结果核验；不要把已授权且可执行的合并交回用户。工作树与本地集成按 peach-worktree 执行。

验证与关闭

• 分别确认代码合并、CI 结果、修复产物发布和 issue 验收；每项结论只使用对应证据。
• 汇总的发布状态绑定候选提交和实际制品；标签已打或版本段已改不能批量转为「已发布」。发布失败保留已合入状态，成功后只推进候选真正包含的修复。
• 问题依赖特定硬件、部署环境或报告者确认时，通用测试、CI 通过和镜像发布不能代替该验证。必要验证未完成时保持 issue 开放；修复产物可供测试时使用 status:needs-verification。
• 尚需验证的 issue，在 PR 正文中用独立的 Refs #编号 行关联，跨仓库使用 Refs owner/repo#编号。此格式也供项目看板识别实现关联。
• 检查 PR 正文、提交消息以及合并时采用的消息，避免用 Fixes、Closes、Resolves 等关键词触发尚需验证的 issue 自动关闭。
• 关闭前取得覆盖问题验收条件的实际验证证据，或用户明确要求关闭。证据写清测试环境、修复版本、结果与未覆盖范围；不得把未覆盖范围说成已验证。
• 若 issue 被自动关闭且必要验证未完成，重新打开并恢复适用标签；无需为修正状态自动追加评论。

这些是操作约定；现有看板脚本只映射状态，不会阻止 GitHub 自动关闭 issue。