notes.md

开发规则

⚠️ 重要警告

在开始任何编码工作前，必须严格遵循以下流程：

1. 设计方案对齐 → 等待开发者明确确认 ✅
2. 测试用例对齐 → 等待开发者确认 ✅
3. 开始编码实现
4. 运行测试
5. 通知开发者验证

🔴 违反上述流程将导致严重问题！

---

分支管理

• 永远不要直接提交到 main 分支
• 在进行修改之前，先创建新分支
• 使用 git checkout -b <branch-name> 创建新分支

开发流程

🔴 完整开发流程（必须严格遵循）

每次开发任务都必须按照以下顺序执行，不得跳过任何步骤：

步骤 1: 设计方案对齐
  ↓ 等待开发者明确确认（"好的"、"可以"、"确认"等）
步骤 2: 测试用例对齐
  ↓ 等待开发者确认测试方案
步骤 3: 开始编码实现
  ↓ 实现完成后运行测试
步骤 4: 通知开发者验证

🔴 违规示例（禁止行为）：

• ❌ 提出方案后直接开始编码（未等待确认）
• ❌ 假设开发者会同意而跳过确认步骤
• ❌ 编码前未讨论测试用例
• ❌ 边开发边想如何测试

---

1. 设计先行原则 🔴

• 在开发任何功能之前，必须先进行设计
• 设计方案需要与开发者对齐，确认无误后才能开始开发
• 如果开发者没有提供设计方案，必须自己思考设计，并将设计方案告知开发者对齐
• 🔴 关键：必须等待开发者明确确认设计方案（如"好的"、"可以"、"确认"等肯定回复）后，才能开始编码
• 🔴 禁止行为：提出方案后未获确认就开始编码、假设开发者会同意而直接开始编码
• 确认后的设计方案必须写入 plan.md 的对应计划中
• 避免边做边改，减少返工

2. 功能保护原则

• 做任何改动时，必须思考是否会破坏已有功能
• 如果改动会影响已有功能，必须先询问开发者
• 不得擅自破坏或删除已有功能，除非开发者明确要求
• 修改代码时，要考虑向后兼容性

3. 测试驱动原则 🔴

• 🔴 在设计方案确认后、开始编码前，必须先对齐测试用例
• 测试用例需要与开发者对齐：
  • 明确如何测试（测试方法、测试工具）
  • 明确测试什么（测试场景、边界条件）
  • 明确成功标准（什么算通过）
• 🔴 禁止行为：编码前未讨论测试用例、边开发边想怎么测试
• 只有测试用例通过后，才能通知开发者验证
• 测试不通过不能通知开发者，必须先修复问题

4. 规划阅读原则

• 每次开始新任务前，先阅读 plan.md
• 了解项目的整体规划和设计
• 避免每次都从头摸索，保持一致性

5. 文档记录原则 🔴

• 开发完成后，必须更新 plan.md，记录设计方案和实现细节
• 记录内容包括：
  • 新增接口的用途和参数
  • 与现有接口的区别
  • 关键技术点和设计决策
• 🔴 目的：防止后续修改破坏已有设计

代码规范

• 不要修改明确禁止修改的代码（如 C++ 核心代码，除非明确要求）
• 遵循项目现有的代码风格
• 修改前先阅读相关代码，理解现有实现