a8de47ca3f
票面:task-20 交付后的回报——全新工作树没有 .map,依赖它的门禁必然红,而现场只看到一句 "找不到 .map 事实源",容易误判成代码问题。(Lead 定的两头修法都做,本笔独立于 UI 改动。) - scripts/check_mem_numbers.py:FAIL 后补三行原因与动作——.map 是**每棵工作树各自的**构建产物、 不入版本库,新开的工作树(task-worktree new)从未构建过时必然走到这里,先 @build 一次即可, 再按需要 ram_baseline.py --update 回填台账。保持 FAIL 语义不变,只把提示词写对。 - scripts/ram_baseline.py:两处(--update / --write 路径)同样的补充说明。 - docs/环境与部署/并行任务工作树方案.md:生命周期表加一行「新空间首次:@build 一次生成 .map」, 表下补一段说明点名 mem-numbers / mem-budget / L0c 三个消费者。 - .dsh/skills/task-worktree/SKILL.md:陷阱区加同一条,并与既有的「done 的门禁跑在 @build 之前 → .map 是旧的」明确区分——一条是"有但旧",一条是"根本没有",处置动作不同。 只改提示文案与文档,不改判定逻辑与阈值;两个脚本 py_compile 通过并实测打印。 跳过的门禁(三条同族):mem-numbers / mem-budget / size-gate(L0c)——本笔恰恰是在解释其中两条 为什么会红,数值本身仍等 Lead 回填。