docs(skill): task-worktree 补 done 的三个实测陷阱

1) done 的门禁跑在 @build 之前 → mem-budget/mem-numbers 拿旧 .map 比对新台账
   必然误报 FAIL；处置为主工作树 --write 后追加提交再重跑 done
2) 增量构建可能不重链 → .map 数字瞬态不一致（实测同源两次读到 223,560/223,724，
   差 164B）；以主工作树（集成点）为准
3) 合并冲突常落在生成物（RAM 快照）上，两边都不能直接选，须按合并后实际构建重生成

.dsh/skills/task-worktree/SKILL.md

@@ -76,6 +76,21 @@ whenToUse: 要同时推进多个任务、担心同分支同文档互相冲突；
 - **联接建失败不中止 `new`**：只告警并打印手工补建命令，避免留下半成品任务空间；
   但该任务里跑不了 `.venv\Scripts\python.exe`，`@build` / `ci_local.py` 会找不到解释器。
 - **`done` 前主工作树必须干净**：否则未提交改动会被卷进合并。
+- **⚠ `done` 的门禁跑在 `@build` 之前 → 依赖 `.map` 的钩子会误报**（2026-10-12 实测）：
+  `done` 的顺序是「合并 → 重生成 → **门禁（ci_local）** → `@build`」，而
+  `mem-budget`（N-27）/ `mem-numbers` 是拿**文档快照 vs `.map`** 比对 —— 门禁跑时
+  `.map` 还是**主工作树合并前**的旧产物，与刚合并进来的新台账**必然不一致** →
+  误报 `[FAIL] 台账受管区与 .map 不一致`。`@build` 跑完后 `.map` 才是新的。
+  **处置**：门禁失败且只差这两项时，按提示在主工作树跑
+  `python scripts/ram_baseline.py --write` + `python scripts/check_mem_numbers.py --write`
+  后追加提交，再重跑 `done`（它会检测到「已合入」直接清场）。
+- **⚠ 增量构建可能不重链 → `.map` 数字瞬态不一致**（2026-10-12 实测）：
+  `@build` 若判定无需重链，`.map` 保持旧值，此时 `--write` 生成的快照是**瞬态值**
+  （实测同一份源码两次读到 223,560 与 223,724，差 164 B）。**以主工作树（集成点）
+  的 `.map` 为准**；改完 RAM 相关代码后确认重链再刷新快照。
+- **合并冲突常落在「生成物」上**：`docs/内存管理/RAM使用分析与优化方案.md`（mem-numbers
+  快照）在双方都改过时必冲突，且**两边都不能直接选**（各自基于不同基线）——
+  正确做法是解冲突后用**合并后的实际构建**重新生成，不要挑一侧。
 - **并集合并残留**：双方都改过的文件（尤其 `.gitignore`）会被 git 自动并成**并集**，
   可能留下指向已删目录的死规则或重复条目。脚本会自动报「双方都改过」的文件清单 +
   连续重复行；**权威判据是 base / 两个 tip 三方对比**（`git show <ref>:<file>` 逐项 `grep -F`），