文档(验证与清单体系·阶段1): 三层模型入法——验收意图/覆盖索引/执行证据分层,四法则与写卡段维护时序落三份规约+AGENTS.md 红线
test-conventions 新增 §8.9(三层表+四法则=每格非空/每条断言有归属/数量不守恒覆盖守恒/无全局对账总账,含维护时序与文档纯度);§8.3 能力清单维护锚改写为写卡段维护、实现批禁写。doc-conventions §5 增「禁实现内容」行(代码路径/测试文件名/断言名全文禁写,例外=配置文件索引),§6 骨架验收标准口径同步。process-conventions §3 第 11 条与 AGENTS.md 改动四类红线补 `game/tests/README.md` 禁写面。待办条目 5 实况记 2026-10-29 用户三裁与五批落地计划,状态维持文档设计已闭合。pipeline_gate 绿(42 条目/41 行/7 卡)。
This commit is contained in:
1 parent
eb9bb53752
commit
032d923c7e
5 files changed
+27
-5
No files matched your search
@@ -97,7 +97,7 @@
|
||||
- **反向**:diff 里每个行为改动至少一行;没有对应行的改动,必须写明「非行为改动」或「由第 X 行覆盖」。
|
||||
- **测试侧**:新增或改写的每条断言至少挂一行;挂不上的孤儿断言删掉或补挂到需求点。
|
||||
|
||||
**能力清单维护锚(2026-10-28 用户裁,验证与清单体系整改阶段 1;阶段 2 后定稿)**:逐断言账本 `game/tests/验证集清单.md` 已随阶段 2「存量断言精简」完成退役——冻结对账基准(基点 `b9260138`/1587 条)与精简对账结果(33 站点并为 7、1587→1561,合回 `87d241c1`)留 git 历史。覆盖索引由 `game/tests/README.md`「能力清单 v1」唯一承担:每行一个能力,给真实入口与 2–3 个代表用例(`文件:函数`)。维护义务——**每批收口核对本批受影响能力行**:代表用例可 grep、在本批真实跑批中执行、真实入口未绕过改动点,并刷新「最后验证批次」;新增能力加行,能力退役删行。改动—验收对照表纪律不变:新增或改写的每条断言仍须挂一行(上文「测试侧」);断言改判仍受 §8.4 真实入口口径约束。
|
||||
**能力清单维护锚(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 真实入口口径约束。
|
||||
|
||||
### 8.4 真实入口断言(验收闭合的主判据)
|
||||
|
||||
@@ -129,3 +129,24 @@
|
||||
### 8.8 生效与旧卡
|
||||
|
||||
本规自 2026-10-21 起对文件名日期不早于该日的需求卡片生效;旧卡不回头改。旧卡在开工前缺对照表的,由写卡段补,补完再开工。
|
||||
|
||||
### 8.9 三层模型(验收意图·覆盖索引·执行证据,2026-10-29 定稿)
|
||||
|
||||
验收体系分三层,各层各管一件事,互不代行:
|
||||
|
||||
| 层 | 载体 | 切分轴 | 一行是什么 |
|
||||
|---|---|---|---|
|
||||
| 验收意图 | 系统文档「验收标准」节 | 按 owner 文档 | 一条玩家或系统可观测的判据 |
|
||||
| 覆盖索引 | `game/tests/README.md`「能力清单」 | 按玩家旅程与系统归属 | 一个能力+真实入口+代表用例(`文件:函数`) |
|
||||
| 执行证据 | 测试套件断言 | 按代码归属 | 一条从真实入口进入的断言 |
|
||||
|
||||
四条法则:
|
||||
|
||||
1. **每格非空**:每个系统文档有验收标准节;每个能力行有真实入口与至少一个代表用例;每条断言挂在某个需求点或能力行上。
|
||||
2. **每条断言有归属**:孤儿断言删掉或补挂;不建无归属断言。
|
||||
3. **数量不守恒、覆盖守恒**:三层条数天然不等——一条验收意图可由多个能力承接,一个能力由多条断言覆盖。要守的是两个满射:每条验收意图至少有一个能力行承接,每个能力行至少有一条真实入口断言。数量对账只在批内做,见第 4 条。
|
||||
4. **无全局对账总账**:不建逐断言账本,不做跨层条数对账;对账只在每批的改动—验收对照表里做(§8.3)。历史教训:阶段 2 退役的逐断言账本正因把索引层与证据层压成一本账而失修。
|
||||
|
||||
**维护时序**:能力清单归写卡段维护——写需求卡片时增删能力行、刷新本批受影响行的「最后验证批次」;实现批禁写该文件(process-conventions §3 第 11 条)。规则后果是清单滞后一个迭代:本批实现后的代表用例与「最后验证批次」由下次写卡补齐。实现批的验收义务在改动—验收对照表,不在能力清单。
|
||||
|
||||
**文档纯度**:验收意图与能力描述只写玩家或系统可观测面,禁写代码路径(`.gd`/`.py`/`.sh`)、测试文件名、断言名;唯一例外=配置文件索引(`game/data/tables/*.tres` 这类表路径与表名)。规则正文见 doc-conventions §5「禁实现内容」。
|
||||
Reference in new issue
Block a user