### 开发哲学-**核心信仰**：提倡逐步进展而非一次性大改动；从现有代码中学习；实用主义优于教条主义；清晰意图优于巧妙代码。-**简单意味着**：每个函数/类只负责单一职责；避免过早抽象；不使用巧妙技巧，选择平庸的解决方案；如果需要解释，说明太复杂。
### 流程-**规划和阶段**：将复杂工作分成3-5个阶段，并记录在`IMPLEMENTATION_PLAN.md`文件中。-**实现流程**：先理解现有代码模式，然后先写测试（红色），再编写最小代码通过测试（绿色），接着重构代码，最后提交代码，并附上清晰的提交信息。-**遇到困难时的处理**：最多尝试3次，然后停止，记录失败原因，研究替代方案，质疑基本假设，尝试不同的角度。
### 技术标准-**架构原则**：组合优于继承；使用接口而非单例；明确优于隐式；尽可能使用测试驱动开发。-**代码质量**：每次提交必须成功编译，通过所有现有测试，包含新功能的测试，遵循项目格式化/检查。-**错误处理**：快速失败并给出描述性消息，包含调试上下文，在适当级别处理错误，永不默默吞掉异常。
### 决策框架在存在多个有效方法时，根据可测试性、可读性、一致性、简单性和可逆性来选择。
### 项目集成-**学习代码库**：找到3个类似的功能/组件，识别常见模式和约定，尽可能使用相同的库/工具，遵循现有的测试模式。-**工具使用**：使用项目的现有构建系统、测试框架、格式化/检查设置，不引入新工具。
### 质量关卡-**完成定义**：编写并通过测试，代码遵循项目约定，无格式化/检查警告，清晰的提交信息，实现与计划一致，无无问题号的TODO。-**测试指南**：测试行为而非实现，每个测试尽可能只有一个断言，清晰的测试名称描述场景，使用现有的测试工具/助手，测试应具有确定性。
### 重要提醒永远不要使用`--no-verify`绕过提交钩子，不要禁用测试，不要提交无法编译的代码，不要做假设。总是逐步提交工作代码，更新计划文档，从现有实现中学习，三次失败后停止并重新评估。