# 实现规则

在编写代码或判断测试失败原因之前先读取本文件。

## 执行代码实现

遵循 `.agents/workflows/feature-development.yaml` 中的 `implementation` 步骤。

**必做任务**：
- [ ] 按计划实现功能代码
- [ ] 编写完整的单元测试
- [ ] 在本地运行测试验证功能
- [ ] 更新相关文档和注释
- [ ] 遵守项目编码规范

**实现原则**：
1. **严格遵循方案**：不要偏离技术方案
2. **按步骤推进**：按计划顺序执行
3. **持续测试**：实现过程中持续运行 **smoke 子集**（参见 `test` skill）
4. **保持简单**：不要加入未计划的功能

## 运行测试验证

实现过程中：
- **内循环**：每次修改后运行项目测试的 **smoke 子集**（参见 `test` skill），快速反馈
- **写实现报告前**：运行 **core 子集**做最终验证，确保进入审查的代码已通过完整的核心测试

> 项目特定命令请参考 `test` skill；不存在分层 script 的下游项目回退到完整项目测试命令。

如果测试失败：
- 先分析失败原因，并优先修复由本次实现引入的问题
- 每次修复后重新运行至少 smoke 子集，进入下一轮再升级到 core
- 只有当失败由外部阻塞、环境缺失或当前任务内无法澄清的需求问题导致时，才允许在不生成实现产物的情况下停止

双分支失败处理：
1. 本次实现引入的失败：
   - 修复由本次实现引入的代码、测试、文档或 fixture 问题
   - 每次修复后重新运行测试（smoke 用于本次修复验证，core 用于本轮整体验证）
   - 持续处理直到所有必需测试通过
2. 外部阻塞：
   - 确认失败来自缺失环境、无关的上游损坏，或任务范围外的需求不明确
   - 停止，并且不要创建 `implementation.md` / `implementation-r{N}.md`
   - 不要在 `task.md` 中把实现标记为完成
   - 不要输出正常的成功/下一步模板

## 注意事项

1. **前置条件**：必须存在已批准的技术方案（`plan.md` 或 `plan-r{N}.md`）
2. **禁止自动提交**：不要执行 `git commit` 或 `git add`
3. **测试质量**：新增测试必须验证有意义的业务逻辑
4. **代码质量**：遵循项目编码规范
5. **方案偏离**：任何偏离都要记录到实现报告中
6. **版本命名**：Round 1 使用 `implementation.md`，后续轮次使用 `implementation-r{N}.md`
