# CODE_OF_CONDUCT
## 原则
本项目的运行遵循"先造围栏，再上智能体"的工程哲学。以下规则适用于所有贡献者——无论是人类还是 AI。
### 1. 每个改动必须有据可查
不得提交无关联的变更。每次提交应当对应一条 CHANGELOG 记录或一个已关闭的 Issue。AI 提交应在消息中标注判断依据。
### 2. 测试覆盖优先于功能推进
新增功能必须附带测试。coverage 低于当前基线时，不得合入主分支。如果测试工具本身崩溃，先修复测试基础设施，再提交功能代码。
### 3. Trait 优先于 Mock，抽象优先于注入
Rust 项目的测试不依赖 Mock 框架，而是通过 Trait 定义边界、用假实现（fake）替代真实依赖进行验证。贡献者应当：
- 将外部依赖（文件系统、Git、网络）抽象为 Trait
- 为每个 Trait 提供至少一个假实现用于测试
- 不得引入动态 Mock 框架；如果需要替换行为，说明 Trait 设计不合理
### 4. 抽象遵循"用得上"原则
不要为"以后可能有用"的场景设计抽象。子模块状态机一类过度设计的教训表明：没人用的抽象就是技术债。抽象必须被至少一个真实消费者验证后才能合入。
### 5. 性能回归视为 bug
任何导致性能下降的改动都应被标记和修复。当依赖链变长时，贡献者有责任评估性能影响。覆盖率和构建时间作为关键指标，不得持续恶化。
### 6. 透明优先
系统内部复杂性不应被隐藏。如果一个改动让代码变得更难理解，必须补充注释或文档。不得用"AI 能看懂就行"为由绕过可读性要求——人类审阅者也是系统的消费者。
### 7. 自举验证
贡献者应尽量用自己的工具管理自己的贡献。如果提交的是发布相关的改动，应能通过本工具的 release 命令完成发布流程。无法自举的功能不被认为是成熟的。
## 违规示例
- 提交了 200 行新功能但没有一行测试
- 引入了一个新抽象层但没有现成的消费者
- 用 git2 实现了一个 Git CLI 已经支持的功能，但没有解释为什么不做外部调用
- 删除了测试而没有补充等效覆盖
- 合入了覆盖率下降超过 5% 的 PR
## 执行
以上规则由契约（contract）和代码审查共同执行。契约能自动检测的由契约拦截，契约覆盖不到的由审查把关。AI 贡献者的 PR 至少需要一次人类审阅方可合入。