放宽 commit 规范：可直接提交、可合并、不必每次确认

旧规范要求每次 commit 前给用户审建议 message、严格按职责拆分，操作链冗余。
新规范：
- 改动通过最小验证后直接 commit，不必每次先征求同意
- commit 颗粒以"未来回看时能不能看懂、能不能二分回滚"为准；密切相关的
  改动可合并，无关的拆开；不强制按职责拆
- 桥接契约改动 / 不可逆结构性变更仍要求独立 commit

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

CLAUDE.md

@@ -287,15 +287,13 @@ H5 页面通过特定的 JavaScript 协议初始化桥并注册自己的 handler
 - 提交信息使用中文短句，描述"做了什么 + 为什么"
 - 不在未授权情况下执行 `git push`、`git reset --hard`、`git rebase`、`git push --force` 等不可逆操作
 - 涉及桥接接口名 / 参数字段名 / 数据结构的改动，提交信息必须明示 "契约影响" 并附 `docs/H5-Native-Contract.md` 对应章节
-- 工作树有多个不相关改动时，按职责拆 commit，不混提
+- **及时提交，无需每次确认**：改动通过最小验证（BuildProject 通过 / 关键路径手测通过 / 单测通过）后，可直接 `git commit`，不必每次先征求用户同意。
-- **及时提交**：每完成一个可独立验证的工作单元（一项 bug 修复 / 一处配置变更 / 一次文档更新 / 一次依赖升级 / 一个 M 里程碑的子项），就应在工作树干净时主动提议提交。理由：
+- **commit 颗粒按情况自行判断**：
-  - 项目处于 greenfield 重写阶段，commit 颗粒越小越容易在出错时二分定位 / 回滚
+  - 多个改动彼此相关、属于同一目标的，可合并为一个 commit
-  - 长时间不提交容易让 pbxproj / Info.plist / SDK 二进制等结构化文件互相耦合，git diff 失去可读性
+  - 多个改动彼此完全无关、合并后 git diff 失去可读性的，再拆开
-  - CLAUDE.md / docs 与 git log 一起构成项目记忆——commit message 是"为什么"的第一现场，比事后补文档更可信
+  - 桥接契约改动 / 不可逆的结构性变更必须独立 commit，便于回滚定位
-- 主动提议提交的时机判定：
+  - 不强制"按职责拆"——合并 vs 拆分以"未来回看时能不能看懂、能不能二分回滚"为准
-  - 改动已通过最小验证（BuildProject 通过 / 关键路径手测通过 / 单测通过）→ 立即提议
+- commit message 直接写"做了什么 + 为什么"，无需事先把建议 message 给用户审一遍。用户若不满意会主动反馈，再 amend / 重提即可
-  - 工作树还有其它无关待提交内容 → 先帮用户分类、按职责拆 commit，**不混提**
-  - 用户未明确同意前不直接执行 `git commit`，但应当**清晰地告诉用户"现在适合提交了"**，并附上建议的 commit message
 
 ---