工程(能力清单改版——验证账本改实现指导地图): 能力清单定位改实现指导＋阅读导航＋义务声明，只宣布「要验证什么」不记验证状态（落地账归改动—验收对照表＋合回前独立审计）——game/tests/README.md 八张能力表瘦身四列（能力｜系统｜真实入口｜代表用例，删「最后验证批次」「缺口」两列，存量行内容保留不回溯验证）、引区块改版（义务清单定位＋写卡当场入表＋实现照单落名＋收尾核对，废「滞后一个迭代」），覆盖域表保留现状不动；test-conventions §8.3 维护锚整段改写、§8.9 三层模型中层「覆盖索引」改「义务清单」并同步法则与机器闸句；tools/capability_audit.py 判据随改（CAP_COLS 收窄四列含系统列非空、删「最后验证批次＝真实 commit」检查、代表用例与真实入口改双通道＝代码在或卡在 reports/需求卡片*.md——两头都无＝红、条件闸行豁免保留代表用例口径）；tools/pipeline_gate.py 对照表能力行收紧（「新增：<能力名>」同样要求该能力行已在清单在场——写卡与入表同 commit）。新判据经造红探针孤立验证（两头无=红/卡在=绿/代码在=绿；新增不在表=红）

design/engineering/test-conventions.md

@@ -97,7 +97,7 @@
 - **反向**：diff 里每个行为改动至少一行；没有对应行的改动，必须写明「非行为改动」或「由第 X 行覆盖」。
 - **测试侧**：新增或改写的每条断言至少挂一行；挂不上的孤儿断言删掉或补挂到需求点。
 
-**能力清单维护锚（2026-10-28 用户裁，2026-10-29 定稿）**：逐断言账本 `game/tests/验证集清单.md` 已随阶段 2「存量断言精简」完成退役——冻结对账基准（基点 `b9260138`／1587 条）与精简对账结果（33 站点并为 7、1587→1561，合回 `87d241c1`）留 git 历史。覆盖索引由 `game/tests/README.md`「能力清单」唯一承担：每行一个能力，给真实入口、2–3 个代表用例（`文件:函数`）与最后验证批次（三层模型见 §8.9）。**维护归写卡段**——增删能力行与刷新「最后验证批次」在写需求卡片时完成，实现批禁写该文件。改动—验收对照表纪律不变：新增或改写的每条断言仍须挂一行（上文「测试侧」）；断言改判仍受 §8.4 真实入口口径约束。
+**能力清单维护锚（2026-10-29 用户裁改版定稿）**：`game/tests/README.md`「能力清单」是**实现指导＋阅读导航＋义务声明**——只宣布「要验证什么」，不记「是否已验证／是否跑过」；落地账归现行验收闭合链（改动—验收对照表逐条挂断言＋合回前独立验收审计），本清单不承载验证状态。表为四列：能力｜系统｜真实入口｜代表用例（`文件:函数`）。**维护归写卡段，当场入表**：写需求卡片时，本批新增能力当场写入能力行——真实入口取自设计文档已定的入口，代表用例＝卡里定死的计划测试（`文件:函数`）；受影响存量行（入口／用例名变更）同批更新；能力退役删行。**实现照单落名**：测试函数名以清单为唯一依据，名实不符＝卡片没写清＝停卡退回。**收尾核对**：批末收尾只核对表上名字与实际落地一致（改名则回表），不刷任何批次字段；实现批禁写该文件的现行红线不变（process-conventions §3 第 11 条），核对义务归收尾提交。三层模型见 §8.9。改动—验收对照表纪律不变：新增或改写的每条断言仍须挂一行（上文「测试侧」）；断言改判仍受 §8.4 真实入口口径约束。
 
 ### 8.4 真实入口断言（验收闭合的主判据）
 
@@ -130,25 +130,25 @@
 
 本规自 2026-10-21 起对文件名日期不早于该日的需求卡片生效；旧卡不回头改。旧卡在开工前缺对照表的，由写卡段补，补完再开工。
 
-### 8.9 三层模型（验收意图·覆盖索引·执行证据，2026-10-29 定稿）
+### 8.9 三层模型（验收意图·义务清单·执行证据，2026-10-29 定稿）
 
 验收体系分三层，各层各管一件事，互不代行：
 
 | 层 | 载体 | 切分轴 | 一行是什么 |
 |---|---|---|---|
 | 验收意图 | 系统文档「验收标准」节 | 按 owner 文档 | 一条玩家或系统可观测的判据 |
-| 覆盖索引 | `game/tests/README.md`「能力清单」 | 按玩家旅程与系统归属 | 一个能力＋真实入口＋代表用例（`文件:函数`） |
+| 义务清单 | `game/tests/README.md`「能力清单」 | 按玩家旅程与系统归属 | 一条待验证义务：能力＋真实入口＋代表用例（`文件:函数`） |
 | 执行证据 | 测试套件断言 | 按代码归属 | 一条从真实入口进入的断言 |
 
 四条法则：
 
 1. **每格非空**：每个系统文档有验收标准节；每个能力行有真实入口与至少一个代表用例；每条断言挂在某个需求点或能力行上。
 2. **每条断言有归属**：孤儿断言删掉或补挂；不建无归属断言。
-3. **数量不守恒、覆盖守恒**：三层条数天然不等——一条验收意图可由多个能力承接，一个能力由多条断言覆盖。要守的是两个满射：每条验收意图至少有一个能力行承接，每个能力行至少有一条真实入口断言。数量对账只在批内做，见第 4 条。
-4. **无全局对账总账**：不建逐断言账本，不做跨层条数对账；对账只在每批的改动—验收对照表里做（§8.3）。历史教训：阶段 2 退役的逐断言账本正因把索引层与证据层压成一本账而失修。
+3. **数量不守恒、承接守恒**：三层条数天然不等——一条验收意图可由多个能力承接，一条能力义务由多条断言覆盖。要守的是两个满射：每条验收意图至少有一条能力义务承接，每条能力义务至少有一条真实入口断言落地。数量对账只在批内做，见第 4 条。
+4. **无全局对账总账**：不建逐断言账本，不做跨层条数对账；对账只在每批的改动—验收对照表里做（§8.3）。历史教训：阶段 2 退役的逐断言账本正因把义务清单层与证据层压成一本账而失修。
 
-**维护时序**：能力清单归写卡段维护——写需求卡片时增删能力行、刷新本批受影响行的「最后验证批次」；实现批禁写该文件（process-conventions §3 第 11 条）。规则后果是清单滞后一个迭代：本批实现后的代表用例与「最后验证批次」由下次写卡补齐。实现批的验收义务在改动—验收对照表，不在能力清单。
+**维护时序（2026-10-29 改版：废「滞后一个迭代」）**：能力清单归写卡段维护——写需求卡片时当场入表：本批新增能力当场增行（真实入口取自设计文档已定的入口，代表用例＝卡内定死的计划测试 `文件:函数`），受影响存量行（入口／用例名变更）同批更新，能力退役删行；实现批禁写该文件（process-conventions §3 第 11 条）。实现照单落名：测试函数名以清单为唯一依据，名实不符＝卡片没写清＝停卡退回。批末收尾只核对表上名字与实际落地一致（改名则回表），不刷任何批次字段——清单不记「是否已验证／是否跑过」，落地账在改动—验收对照表（§8.3）与独立验收审计（§8.7）。
 
 **文档纯度**：验收意图与能力描述只写玩家或系统可观测面，禁写代码路径（`.gd`／`.py`／`.sh`）、测试文件名、断言名；唯一例外＝配置文件索引（`game/data/tables/*.tres` 这类表路径与表名）。规则正文见 doc-conventions §5「禁实现内容」。
 
-**机器闸**：本节的结构由文档域闸「能力审计」机检——GDD 纯度（同款禁实现内容口径）、系统文档验收标准节非空、能力行六列与非空、代表用例（`文件:函数`）与真实入口可核、覆盖域表与能力行对得上；红项按新增红处理。闸件清单与域划分的唯一出处＝`tools/run_all_gates.sh` 头部。
+**机器闸**：本节的结构由文档域闸「能力审计」机检——GDD 纯度（同款禁实现内容口径）、系统文档验收标准节非空、能力行四列与非空、代表用例（`文件:函数`）与真实入口可核（双通道：代码在或卡在——计划中的用例与入口由需求卡片锚定）、覆盖域表与能力行对得上；红项按新增红处理。闸件清单与域划分的唯一出处＝`tools/run_all_gates.sh` 头部。