修复项目中的问题
目标：在现有项目中形成可审阅的修复，避免仅凭 AI 的完成描述验收。需要已选工作区、项目依赖和可用的命令环境；执行命令前先确认当前项目 README 和规则。
打开
1. 描述可复现的问题
提供实际行为、预期行为与触发步骤。例如：
当前项目的计数器点击“重置”后，显示为 0，但再点击加一会从旧值继续。预期重置内部计数。请检查当前工作区，先定位原因，按项目规则做最小修复，运行已有相关测试，最后列出变更与结果。不要更换框架或修改无关页面。
使用仓库已有版本控制或独立副本保存起点。不要把真实生产凭据作为复现材料。
2. 定位并保留证据
Agent 应先找 README、项目规则、入口和测试配置，再读取事件处理与状态更新代码。命令从项目实际目录运行，测试脚本以项目配置为准，不凭框架名称猜命令。
如果原测试通过但问题仍存在，补充能覆盖触发条件的回归检查；如果无法复现，记录缺少的环境和步骤，而不是直接重写模块。
3. 修改并验证
优先修改导致错误的状态更新路径，核对改动没有引入第二份状态。再次运行相关测试，并执行原来的手动步骤。测试失败时先判断是否为修复相关回归或既有环境问题。
计数器示例的验收顺序：加三次 → 重置 → 加一次，应得到 1。最终报告应提供实际执行的命令与退出结果，以及哪些手动步骤仍需用户在界面验证。
4. 审查交付
| 检查项 | 期望 |
|---|---|
| 变更范围 | 只修改与原因、回归验证有关的文件 |
| Diff | 没有无关格式化、依赖升级或凭据 |
| 测试 | 已执行的检查有真实结果，未执行的明确标记 |
| 残留进程 | 临时服务已停止，或记录继续运行的用途和端口 |
发现其他问题时单独记录，保持本次修复可独立理解。文件与命令结果的查看方式见对话审查。