zuozh11 Atomic Commit
核心目标是让每笔提交都具有可独立说明的业务意义，并能整笔直接回滚。提交边界由完整业务结果、交付完整性和回滚边界共同决定，不追求最小、最细。
原子性标准
- 业务意义：完成该 commit 后，用户、角色或系统获得一项完整能力，或者产生一个可观察的业务结果。提交应能用业务语言说明价值，而不是只描述修改了哪些文件或技术层。
- 完整提交单元：共同完成同一业务结果所需的实现、测试、文档、配置、迁移和生成文件放在同一 commit。该 commit 在其依赖基线之上能够完整成立、整体验证，不依赖剩余未提交改动。
- 可直接回滚：可以通过整笔回滚该 commit 撤销这次交付，无需挑选 hunk、同时回滚无关提交或手工拼接恢复状态；回滚后不会留下明显残缺状态。
- 拆分边界：只有形成不同且各自完整、能分别验证和回滚的业务结果时才拆分；不按文件数、技术层或提交类型拆分。
流程
按项目知识协议使用相关 CONTEXT 与适用 RULE；已有知识足够时复用，知识不可用时说明缺口并继续。
优先根据当前会话理解变更目的和范围。查看
git status，并只读取划分提交边界和生成消息所需的相关 diff；不得为重新理解已知改动而扩大调查。在暂存前用业务语言说明每个提交单元完成后的能力或可观察结果，再验证其交付完整性和直接回滚能力。调用方已经给出边界时仍需完成该校验；不得根据文件分布或技术层次重新拆分完整业务结果。
逐个提交单元执行：
- 只暂存该单元的路径或 hunk；
- 检查 staged diff，确认内容完整、没有无关改动，也不依赖剩余未提交改动；
- 沿用当前会话已经完成的验证并如实保留验证边界；
- 为 staged diff 生成消息并完成本地提交，再处理下一个单元。
调用方给出的提交单元与 diff 不一致时，写入前返回边界冲突。改动归属不清，或用户要求的提交方式会破坏交付完整性或直接回滚能力时，提问确认。
提交消息涉及业务术语时，使用 CONTEXT 中的统一术语，并使用以下格式：
<type>[(scope)]: <summary> [body] [footer]类型沿用项目约定；
scope优先使用稳定的业务领域，其次使用模块或组件，无法准确归类时省略。summary使用祈使语气，直接描述业务结果或工程交付价值，不写成文件操作清单。不加句号，标题不超过 72 个字符，沿用已确定的术语。仅在标题不足以说明内容或原因时添加
body；破坏性变更使用!和BREAKING CHANGE: <影响>，关联信息按需写入 footer。
执行边界
- 只暂存当前会话相关的改动。如果已暂存内容的归属不清，在写入前提问确认。
- 不得自动 push。
示例
fix(订单): 处理空订单号时不再崩溃