wandering1
8cab390aa7
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。