docs(rules): 记录「dev 早期一包提交」——G14.5 例外 + E09 复盘

上一条提交（c1af86c）刻意混合了多条并行线，本提交把这次的教训沉淀下来：

- G14.5 增补例外条款：dev 早期直接 `git add -A` 一包提交，不为粒度打断节奏、
  不反问用户提交范围；同时保留「如实披露混合内容」的硬要求，并给出可操作判据
  「为了让提交能编译而不得不先测依赖锥 ⇒ 本来就是一个单元」。
  原文一字未删，例外写在原文之下；头部版本 V1.3 → V1.5。
- bugs_and_errors.md 新增 E09：症状（一句「提交一下」被做成依赖锥测量 +
  hunk 挑拣工具 + 5 轮索引导出编译 + 最后反问用户范围）、根因（把 G14
  「git 是后台事务」读成了「提交粒度值得花成本」）、修法、以及实测出的依赖锥
  （ASR / LLM 调用层 / 编排 Agent / 联网搜索 是一个编译单元）。

E09 记的是我自己的工作方式错误，不是环境坑。

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

TOP_CODING_RULES.md

@@ -1,6 +1,6 @@
 # eai_agentplatform 博昇 AI 数字员工平台（EAI Agent Platform）— 编码与调试最高准则
 
-> **版本：V1.3**
+> **版本：V1.5**
 > **日期：2026-09-26**
 > **状态：必须强制执行 (Highest Priority)**
 > **适用范围：eai_agentplatform（EAI 数字员工平台）后端(Go)、前端(Vue3)、数据库(SQLite)、AI 检索/对话、考试引擎、素材上传与审批**
@@ -35,6 +35,13 @@
 > 按「是否属于工具/语言/框架的固有性质、是否会换个场景再犯」筛过后才进来。
 > 另：本地 ASR 落地中遇到的版本与依赖坑（`torchaudio>=2.9` 删 API 等）记在仓库根
 > `bugs_and_errors.md`，不重复进 P06 —— 那份文件管「一次性的错」，P06 管「会复发的坑」。
+>
+> **V1.5 补充说明**：G14.5 增补**「dev 早期一包提交」例外**，并给出可操作判据
+> （「为了让提交能编译而不得不先测依赖锥 ⇒ 本来就是一个单元，别拆」）。
+> 起因：一句「提交一下」被我做成了一次依赖锥测量 + hunk 级挑选工具 + 反复导出索引编译，
+> 最后停下来问用户「这次提交装哪些文件」——用户驳回，要的是直接一包提交。
+> 原文「一次提交只装一件事」一字未删，例外写在它下面；**粒度可以放宽，如实披露不能放宽**。
+> 事故复盘见 `bugs_and_errors.md` E09。
 
 ---
 
@@ -324,6 +331,14 @@
 4. **用户显式要求时照做**：用户说提交就提交、说推送才推送 —— 本条只约束 AI 的主动行为。
 5. **要提交就要提交得干净**：
    - 一次提交只装一件事，多件事分开提交（例：功能改动与在制品清理分两次）
+     - **例外：dev 早期一包提交**（2026-09-26 用户指示）。项目还在早期时，粒度不是收益，
+       是打扰——**直接 `git add -A` 一包提交，不要停下来问用户「这次提交装哪些文件」**。
+       用户原话：「不做任何区分了，直接一包提交，这种事情以后不要干扰工作节奏」。
+     - 但「一包」不等于「闭嘴」：混合了哪些并行线，**必须在提交正文里逐条写明**
+       （下面第 3 条照旧生效）。粒度可以放宽，诚实不能放宽。
+     - 什么时候收回来：进入交付/需要回滚定位/多人协作时，再恢复按事拆分。
+     - 判据（比「阶段」更好操作）：**如果为了让这次提交能编译，你得先测量一遍依赖锥，
+       那这些改动本来就是一个单元，不要拆。** 详见 `bugs_and_errors.md` E09。
    - 提交信息写「为什么」，不只写「改了什么」
    - 共享文件里混有并行改动、他人改动时，在提交正文里**如实写明**，不假装全是自己这次的改动
    - 提交前扫一遍待提交内容有无密钥、大文件、运行期数据（参见 P06.10）