每次开发默认遵循以下顺序：
- 先确认需求落在哪个边界上下文。
- 先看现有模型和端口能否复用。
- 先做最小闭环。
- 再补充验证。
- 最后更新 README 或规则文档。
- 改动范围明确
- 命名可读
- 目录正确
- 没有重复实现
- 至少有一种验证方式
- 这次有没有把业务逻辑写错层
- 这次有没有新建多余抽象
- 这次有没有引入重复类型
- 这次有没有留下无用代码
- 这次有没有破坏 README 与实际结构一致性
默认至少执行下面之一：
bun testbunx tsc --noEmitbun run build
如果改动影响范围较大，应至少执行两项。
出现以下情况时，必须更新文档：
- 新增目录层级
- 新增边界上下文
- 新增核心用例
- 新增工具协议
- 新增重要开发约束
文档不同步视为未完成。
- 一次提交优先只解决一个主题
- 不把“重构 + 新功能 + 样式调整 + 杂项修复”混成一个改动
- 大改动要先搭骨架，再补实现，再补验证
AI 参与开发时，必须遵守：
- 先读现有结构，再下手改
- 优先复用已有文件和模型
- 不擅自重命名大范围目录
- 不批量制造样板代码
- 不把“推测的未来需求”一次性全部实现
一个任务只有同时满足以下条件才算完成：
- 代码已经落地，不是只写方案。
- 结构符合规则。
- 至少有基础验证。
- 必要文档已更新。
- 没有留下明显重复和脏代码。
以下行为在本项目中视为违规：
- 跳过验证直接宣称完成
- UI 和领域逻辑混写
- 用临时脚本替代正式架构长期存在
- 为了省事复制已有实现再改一点点
- 明知不符合规则还继续叠加复杂度