6.9 KiB
6.9 KiB
工程改动报告——能力清单改版（验证账本改实现指导地图）
2026-10-29 · 文档设计改动批（用户裁决定稿后发令执行）· worktree 分支 caplist-20261029 合回
接收方：待办清单.md「能力清单改版——验证账本改实现指导地图」条（本批完成即整条删除，条目内容 git 历史可考）
定位换代（用户裁定，本批不改设计）
能力清单从「覆盖索引＋验证账本」改为实现指导＋阅读导航＋义务声明：只宣布「要验证什么」，不记「是否已验证／是否跑过」；落地账归现行验收闭合链（卡片改动—验收对照表逐条挂断言＋合回前独立验收审计），那套机制本批不动。废「滞后一个迭代」：写需求卡片时本批新增能力行当场入表，计划测试文件名与函数名卡里定死；实现照单落名，名实不符＝卡片没写清＝停卡退回；收尾只核对表上名字与实际落地一致（改名则回表），不刷任何批次字段。
改动面
| 文件 | 改动 |
|---|---|
game/tests/README.md |
八张能力表（七旅程段＋跨域条件闸）瘦身四列：能力｜系统｜真实入口｜代表用例（文件:函数）——删「最后验证批次」「缺口」两列，存量行内容保留、不回溯验证；引区块改写（义务清单定位、维护规则、代表用例口径），删「最后验证批次」整段说明；覆盖域表（含其「缺口」列）按用户裁保留现状不动 |
design/engineering/test-conventions.md |
§8.3「能力清单维护锚」整段改写（新定位＋四列＋写卡当场入表＋实现照单落名＋收尾核对）；§8.9 三层模型中层「覆盖索引」改「义务清单」，法则 3「覆盖守恒」改「承接守恒」并同步措辞，维护时序段删滞后与批次刷新表述，机器闸句改四列＋双通道口径 |
tools/capability_audit.py |
CAP_COLS 收窄四列（「系统」列纳入非空机检）；删「最后验证批次＝真实 commit」检查（check_hash／commit_ok／HASH_RE 随删，subprocess 导入随之移除）；代表用例与真实入口判据改双通道（见下表）；条件闸行豁免保留（按「代表用例」含「条件闸」字样）；头部判据清单同步 |
tools/pipeline_gate.py |
对照表「能力行」判据收紧：「新增：<能力名>」同样要求该能力行已在 game/tests/README.md 能力表在场（写卡与入表同 commit；改版前仅核「既有：」） |
.zcode/skills/req-card/SKILL.md（主区直改，不入 git） |
验证闸节增「能力行当场入表」义务：本批新增能力写卡时增行（真实入口取自设计文档已定入口；代表用例＝卡内定死的计划测试 文件:函数 名）；受影响存量行同批更新；能力退役删行；实现照单落名、收尾核对 |
.zcode/skills/iter/SKILL.md（主区直改，不入 git） |
批性质注记更新（能力行增删归写卡段当场入表，「最后验证批次」列已废除）；第 5 步账面随批增「能力清单核对」：核对表上名字与实际落地一致、退役能力行已删，名实不符＝停卡退回，本批禁代改 README |
待办清单.md |
「能力清单改版——验证账本改实现指导地图」条整条删除（完成即删） |
判据变更前后对照
| 判据点 | 改版前 | 改版后 |
|---|---|---|
| 能力表列 | 六列（能力｜真实入口｜代表用例｜最后验证批次｜缺口；「系统」列不在机检列） | 四列（能力｜系统｜真实入口｜代表用例），四格全非空机检 |
| 最后验证批次 | 须为可解析 commit（git cat-file），条件闸行豁免 | 列删除、检查随之删除——清单不记「是否已验证／是否跑过」 |
| 代表用例可核 | 单通道：文件在 run_all.gd 套件 manifest 内且文件有 func 函数名( |
双通道：代码在（同左）或卡在（文件名或函数名见于 reports/需求卡片*.md——写卡当场入表的计划用例锚）；两头都无＝红 |
| 真实入口可核 | 单通道：产品码有 func 方法( |
双通道：产品码有 func 方法( 或方法名见于需求卡片（计划入口锚）；两头都无＝红。※延伸申报见下 |
| 对照表「能力行」 | 仅「既有：<能力名>」须在能力表可查，「新增：」不核 | 「既有：」与「新增：」都须在场——新增不在表＝「写卡须同批把能力行写入能力清单」红 |
| 维护时序 | 清单滞后一个迭代：本批实现的代表用例与批次由下次写卡补齐 | 写卡时当场入表（新增行＋受影响存量行更新＋退役删行）；收尾只核对名字与落地一致，不刷批次字段 |
| 条件闸行豁免 | 「代表用例」或「缺口」含「条件闸」即豁免 | 仅「代表用例」含「条件闸」（缺口列已删） |
※延伸申报（超出任务清单原文的一处判据延伸，显式呈报待用户追认）：任务原文只要求「代表用例」改双通道；「真实入口」按原文保持单通道（产品码 func 在场）。但用户裁定 ③「受影响存量行（入口／用例名变更）同批更新」与「新增系统的能力行」都在写卡 commit 点生效——彼时入口代码尚未落地，单通道必被闸拦（写卡提交被自家闸机拦死，与裁定 ③ 直接矛盾）。故按同一已裁口径「两头都无＝红」把卡片通道延伸到入口列：产品码有定义或需求卡片载名，其一即绿。若裁回退，只需还原 check_entry 单通道判断（约两行）。
验证
- 闸件新判据孤立验证（造红探针，未触库内文件）：代表用例双通道两头无＝红／卡在＝绿／代码在＝绿（3/3）；对照表「既有：」不在表＝红、「新增：」不在表＝红（2/2）。
- 文档域闸（
tools/run_all_gates.sh --docs，提交点钩子与收口跑批同判据各一遍）：06 gdd_lint／06b 变更记录节／07 doc_link／08 doc_term／08c 流水线闸／08d 引用可核／08e 能力审计／10 熵增闸全绿无新增红；08e 能力审计读数＝系统文档 25 篇 · 能力行 59 · 套件 65 · 覆盖域表 25 行 · 红项 0。 - 收口回执
game/tests/.gates/receipt.json：domain=docs、all_green=true、tree＝分支尖内容树（不入 git，合回闸按树哈希校验）。
边界与遗留
- 本批零游戏代码面改动（未跑代码域闸，符合批令）；存量 59 行的代表用例全部经代码通道锚定，行内容未动。
- 全库「最后验证批次」引用面已清零（test-conventions／README／iter 技能三处随本批改写）；待办清单另一条「验证与清单体系整改」实况中的「最后验证批次」字样为历史叙述留档，不在本批改写面。
- 主区两个未跟踪旧报告（reports/工程改动报告-存量断言精简C档-2026-10-28.md、reports/盘点-验证与清单体系-2026-10-28.md）按批令未触碰。