chore(task-worktree): 活跃任务上限 3 提到 8——磁盘不是依据，锁排队才是（引用面 15 处同步）

唯一事实源是脚本常量 MAX_CONCURRENT（task_worktree.py:30），报错文案与 new 的插件树提示都插值它；
其余全是引用面同步：SKILL.md 12 行（含 frontmatter 的 description 与 whenToUse——它会进技能目录）、
方案文档表格行 + 依据段重写、启动日志原子性复验流程 1 行去掉数字。

依据段按今天的实测重写，不再拿磁盘当理由：一棵纯净检出 84.0 MiB / 2857 个受控文件（docs 独占
46 MiB），.venv 与 simulator/SDL2 走目录联接共享、不随树复制，D 盘余 1.4 TB → 8 棵全开最坏约
3.2 GB（每棵再叠一次构建产物：Keil 中间件 289 MB + 模拟器 35 MB）。真正随并行数上涨的是排队：
build 锁 TTL 1.0h、bench 锁 TTL 6.0h 分别串行化 @build 与 @test，done 的合并也必须串行——8 棵是
8 个空间，仍是一套 Keil 授权 + 一块板。

扫描按全形态跑（上限 3 / 最多 3 / 第 4 棵 / MAX_CONCURRENT = 3 / 硬上限 3 / 名额），整行打印后
另抓到两处只按数字搜不到的形态：whenToUse 里的「白占 3 个名额之一」、「确实要同时开第 4 棵」
（上限变了它必须跟着变第 9 棵，否则自相矛盾）。

冻结不改并写明类别：带日期戳的历史测量（2026-10-28 一次回收 3 棵、各 89 MB）、用户原话引语、
列表与步骤序号。「83 MB」是当时 du 口径、与本次内容字节和 84.0 MiB 同数不同义 → 只补口径注并
指回方案 §4，不合并成同一个数；方案 §2 的「对象库 234 MB」保留——今天的 294 MB 含待两周宽限期
过期的不可达对象，不把临时态钉进文档。

本轮我自己写错并已改掉：新段落引用了不存在的子命令 lock list，真命令是 lock status（全仓零残留）。

验证：上限生效用 %TEMP% 隔离小仓实测（脚本按同深度拷贝，因 REPO_ROOT 由 __file__ 反推）——前 8 棵
全成功，第 9 棵 exit 2 且文案为「已有 8 个活跃任务（上限 8）」，--force 照旧放行，list 9 行；真仓
零副作用（worktree list 仍 1 条、同级 _wt 无新建目录、无 t0* 残留）。门禁：doc-links --all
--sections-strict RC=0（2601 处、无法判定 0）、编号门禁 [OK]、py_compile RC=0、四文件无 BOM、
纯 LF、无 U+FFFD、无行尾空格。改动不落体积门禁指纹面，不需要 @build。

docs/测试说明/启动日志原子性复验流程.md

@@ -138,7 +138,7 @@ SHA 只当坐标（2026-10-26 那天 SHA 被 amend 挪了三轮）。同镜像
 - bench 锁是**会话级**，必须手工 acquire/release，且**用同一个名字**释放。
 - 非登记任务名（如临时验收窗）走 `lock release bench --task <NAME>`（**不带** `--bench-pass`）即可释放；
   `--bench-pass` 会先读 `_wt/.state/<NAME>.json` 台账，没有就报"任务不存在"，`--force` 也救不了。
-  为记一个 PASS 去**造假台账**会白占 3 棵并发工作树名额——PASS 写进任务卡描述即可。
+  为记一个 PASS 去**造假台账**会白占并发工作树名额——PASS 写进任务卡描述即可。
 - ⚠ **脚手架 `*.json` 一律不得放 `_wt/.state/`**：那是 task-worktree 的**台账目录**，脚本把每个 `*.json`
   当台账读，实测 `task_worktree.py list` 直接崩在 `KeyError: 'id'`。放 `_wt/scratch/`。
 

docs/环境与部署/并行任务工作树方案.md

@@ -129,12 +129,18 @@ D:/Code/DTU Code/
 | 任务分支     | `task/<ID>-<slug>`，从主干当前 HEAD 切出                                                                     |
 | `<ID>`   | **沿用 `docs/任务规划/README.md` 的编号空间**（`P0-x`/`N-x`/`S-x`/`T-x`/`B-x`/`C-x`/`D-x`）；无对应条目的临时任务用 `X-<日期>-<slug>` |
 | 合并方式     | `git merge --no-ff` 合入主干                                                                             |
-| 并发上限     | **同时最多 3 棵工作树**                                                                                      |
+| 并发上限     | **同时最多 8 棵登记工作树**（2026-10-29 由 3 上调，用户裁定；另有插件树不计入，见 §3.4）                                                                                      |
 
 **`<ID>` 复用登记簿编号**是为了可追溯：任务分支名直接对应待办条目，回收时销项有据可查。
 
-**并发上限 3** 的依据：`.git` 已 234 MB，每棵工作树要检出约 2400 个受控文件（含 Git LFS 图片），
-并发太多磁盘与 I/O 都不划算，人工也管不过来。
+**并发上限的依据**（2026-10-29 由 3 上调到 8，用户裁定；脚本常量 `MAX_CONCURRENT`）：
+磁盘从来不是这条线的硬约束——实测一棵纯净检出 **84.0 MiB / 2857 个受控文件**（含 LFS smudge
+后的真图；`docs/` 独占 46 MiB），而 `.venv` 与 `simulator/SDL2` 走目录联接共享、不随树复制；同日 D
+盘余 1.4 TB，**8 棵全开的最坏估算也只有约 3.2 GB**（每棵再叠一次构建产物：Keil 中间件 289 MB + 模拟器 35 MB）。
+真正随并行数上涨的是**排队与合并**：`@build` 与台架 `@test` 各被一把独占锁串行化（见 §5），`done`
+的合并必须串行（§5 下方说明），而每多一棵树把 `sync` 追平与冲突面乘一遍。所以这条线现在是**管
+理半径闸门**而非磁盘闸门：调到 8 = 把「同时盯几棵」交回人，两把锁的排队代价用 `$TW lock status` 与
+§7 的台架台账观测；脑子里的名额够不够，看的是锁队列长度，不是磁盘。
 
 ---