fix-issue

修复已报告的问题

错误报告不是规格说明。读者一旦接受报告者的猜测，就会跟着他们的视线走，症状消失时便停下。子 Agent 会读取报告，只返回可观察到的事实。你要根据代码形成自己的假设。

绝不要亲自读取问题报告——不要运行 gh issue view，不要用 WebFetch，不要对文件使用 Read，也不要之后再去核实细节。如果摘录信息不足，就向提取 Agent 发送 SendMessage；报告仍保留在它的上下文中。

1. 提取事实

启动一个 general-purpose Agent，设置 run_in_background: false，并原样传递参数：

读取 处的错误报告。对于 GitHub issue，使用 gh issue view <n> --comments。 对于路径，读取该文件。

返回一份事实摘要。工程师只能看到你的输出。

仅在报告中明确提及时，逐项包含：

• 症状 — 用户观察到的情况，用一到两句话说明。
• 预期 — 用户预期的情况。
• 复现 — 准确步骤、输入和数据。逐字保留，绝不缩短。
• 证据 — 错误、回溯、日志、响应正文。完整逐字保留。
• 环境 — 版本、分支、数据库、浏览器、部署类型。
• 范围 — 总是发生还是偶尔发生，影响一个用户还是所有用户，何时开始。

排除：任何拟议的修复、补丁或 PR 链接；任何对原因的猜测，或报告者怀疑的文件、函数、提交；“我认为”“可能”“看起来像”等表述；严重程度、紧急程度、责备、+1、问候语、机器人评论；对症状的重复描述。

回溯属于证据——即使其中提到了文件，也要保留。评论者写“bug 在 x.py 中”属于猜测——应删除。

以 Gaps 结尾：复现所需但报告未提供的信息。信息完整时写“无”。

不要读取代码库、核实任何内容或表达意见。正文少于 400 词，逐字引用的内容不计入。

2. 修复前先复现

根据摘要复现症状。以下三种结果都意味着到此结束，且都可以作为有效结果报告：无法复现且摘要列出了信息缺口；无法复现且摘要完整（搜索日志，确认是否已有提交修复此问题）；或者能够复现，但行为是正确的。

3. 自行查明原因

沿着代码从故障处向上追查。报告指出的是症状显现的位置，而不是缺陷所在。修复根因；如果只能触及症状，就如实说明，不要悄悄打补丁。

4. 修复并验证

以最小改动消除根因——不做重构，不顺手修复其他问题。添加一个回归测试，确保没有该改动时测试会失败；然后分别在有和没有该改动的情况下运行测试，再运行相关测试模块和 pre-commit run --files <changed files>。

5. 让另一个 Agent 单独审查

启动一个 general-purpose Agent，设置 run_in_background: false：

加载 frappe-code-review 技能，并审查工作区差异（git diff 以及它新增的任何未跟踪文件）。此次改动旨在修复以下问题：

<粘贴第 1 步中的症状和预期部分>

评估两点：改动是否从根因上阻止了 bug，还是只掩盖了症状；以及技能中的检查清单。只报告值得处理的问题，按严重程度从高到低排列，并说明文件和行号、影响对象及故障情况、修复方法。不要总结差异。如果没有值得处理的问题，用一句话说明。

根据审查结果采取行动并重新运行测试。

6. 报告

用四到六行说明：原因、改动、测试、审查结果，以及任何未解决的问题。只有在有人要求时才提交；如果提交，加载 technical-writing 技能来撰写提交信息，且不要添加共同作者署名。