用途：将具有业务意义的完整交付单元整理为可直接回滚的本地提交。当用户要求提交或原子提交时使用。
核心标准：一是业务意义，提交后用户、角色或系统获得完整能力或可观察业务结果，能用业务语言说明价值；二是完整交付单元，共同完成同一业务结果的实现、测试、文档、配置、迁移和生成文件放在同一提交，在其依赖基线上能完整成立、整体验证，不依赖未提交改动；三是可直接回滚，整笔回滚即可撤销交付，无需挑选 hunk 或手工拼接。业务边界优先于粒度，不按文件数、改动量、技术层次或提交类型拆分；只有形成不同且各自完整的业务结果且能分别验证、交付、回滚时才拆分。
使用方式：先使用已加载的 CONTEXT 术语与 RULE，未加载则按项目知识协议执行，知识不可用时继续并如实说明。根据当前会话理解变更目的与范围，查看 git status，只读取划分提交边界和生成消息所需的相关 diff。暂存前用业务语言说明每个提交单元完成后的能力或结果，再校验交付完整性与直接回滚能力。逐个交付单元执行：只暂存该单元的路径或 hunk；检查 staged diff；沿用会话中已完成的验证并如实保留边界；为 staged diff 生成消息并完成本地提交。边界冲突、归属不清或提交方式会破坏完整性时，在写入前提问确认。
提交消息格式：<type>[(scope)]: <summary>，可选 body、footer。类型包括 feat、fix、refactor、perf、docs、test、build、ci、style、chore、revert。scope 优先用稳定业务领域，无法归类可用模块或组件，仍不准确则省略。summary 用祈使语气描述业务结果，不加句号，标题不超过 72 字符。破坏性变更在类型后加 !，footer 写 BREAKING CHANGE: <影响>；关联信息按需用 Refs: #123。
限制：只暂存当前会话相关改动；不得自动 push；不得为重新理解已知改动扩大调查；不得根据文件分布或技术层次重新拆分完整业务结果。示例：fix(订单): 处理空订单号时不再崩溃。