docs(验收闭合): 测试规范新增 §9 改动级验收闭合——每个需求点与行为改动都要真实入口断言+撤销证明,合回前独立验收审计
病根=测试规范 §5.2 只要求「每条清单条目至少一个自动断言」,没要求断言从改动的真实入口进入: 裸 EffectEngine 断言可替 BattleOrchestrator 接线,报告写「V1 绿」而 V1 断言并不存在。 - test-conventions §9(9.1–9.8):验收单位=行为改动;四层与真实入口;改动—验收对照表六列 双端对上(需求点正向、diff 反向、断言挂载测试侧);撤销证明(改既有行为回退变红、新增行为 变异变红);禁削弱测试;明确不要求 TDD;合回前独立验收审计;旧卡不回头改、开工前补齐 - process-conventions §3:第 7 条挂对照表、第 9 条补撤销证明、第 10 条合回前审计、新增第 16 条 - AGENTS.md 硬性红线新增「验收闭合」,与变异验证并列 - pipeline_gate 新增 C3:卡片须有对照表节、五个必需列、至少一行、必填格非空、全文声明验收审计; 只查结构不判语义(生效 2026-10-21,按卡片文件名日期追新) - reports/README 与 batch-closure 同步验收审计报告的落点与退役判据 - 待办清单登记「验收闭合规则——下一次迭代实测评估」,按规则评估红线等真实迭代检验
This commit is contained in:
1 parent
f103177471
commit
feaf01454a
6 files changed
+167
-8
No files matched your search
@@ -61,6 +61,7 @@
|
||||
- MC/模拟:无数值改动零跑;档位硬闸见 `sim-data/README.md`「MC 采集档位表」,一档只能由用户发起
|
||||
- 闸机轮次纪律:新码先孤立验证 → 出红只跑红件最小单元 → 长批先最小参数试车 → 开工扫坑册(process-conventions §6)
|
||||
- 变异验证——新增/改写验收函数必须变异变红才算验收成立;无变异红记录只写「已实现,拦截能力未证」(test-conventions §6)
|
||||
- **验收闭合**——每个需求点与每个行为改动都要有从真实入口进入的验收断言,撤销该改动能让对应断言变红;禁删断言/放宽阈值换绿;合回前独立验收审计未过不得合并(细则=test-conventions §9+iter 技能第 5 步)
|
||||
- 规则评估——没在真实任务上评估过的规则修订,不算完成。
|
||||
- 中间产物吸收即死——结论先吸收进权威文档、未决先迁待办清单,文件即删且永不提交(doc-conventions 第 11 节)
|
||||
- **禁写变更记录**——文档与代码文件内一律禁设「版本历史/修订记录/变更记录/修改记录/更新记录/更新日志」节或表格,禁写「本版改了哪些条款」式逐版本叙述与 `# 2026-xx-xx 缺陷修批——` 式行内修订注记;沿革只进 git commit log。版本号可作文档现行身份标记留在文首状态行与正文引用中(doc-conventions 第 5 节,机检闸 gdd_lint R4 反转拦截)
|
||||
|
||||
@@ -45,17 +45,18 @@
|
||||
6. **涉数值改动先采改前读数**——与改后同随机种子配对比较并写明逐项比对口径;无数值改动禁跑模拟
|
||||
|
||||
**实施**
|
||||
7. **新功能必配新测试**——新增玩法/机制必须配套新测试套件进 `tests/run_all`;没有对应测试的变更不许合并
|
||||
7. **新功能必配新测试**——新增玩法/机制必须配套新测试套件进 `tests/run_all`;没有对应测试的变更不许合并;并按 test-conventions §9 挂进改动—验收对照表,没有对照表行的行为改动同样不许合并
|
||||
8. **验收改动先行声明**——验收变化(基线换代/探针增改/旧断言改判)预先写进需求卡片,禁事后补
|
||||
9. **验收函数变异验证**——新增/改写的验收函数(冒烟断言/探针自检/闸机判据)必须配一次变异验证:故意把被测件改坏成该类缺陷形态 → 跑最窄那道闸确认变红 → `git checkout` 精确还原;变异点/跑的闸/红输出摘要/还原结论四件记入实现报告变异验证记录表;**无变异红记录的断言不写「已验收」,只写「已实现,拦截能力未证」**(细则见 test-conventions §6)
|
||||
9. **验收函数变异验证**——新增/改写的验收函数(冒烟断言/探针自检/闸机判据)必须配一次变异验证:故意把被测件改坏成该类缺陷形态 → 跑最窄那道闸确认变红 → `git checkout` 精确还原;变异点/跑的闸/红输出摘要/还原结论四件记入实现报告变异验证记录表;**无变异红记录的断言不写「已验收」,只写「已实现,拦截能力未证」**(细则见 test-conventions §6);行为改动另做撤销证明(test-conventions §9.4),两类证明都记入实现报告
|
||||
|
||||
**完成**
|
||||
10. **批末按域验收才合并**——在任务 worktree 内跑 `tools/run_all_gates.sh`,**按本批改动域选档**:本批改动触及 `game/`(游戏工程代码、测试、探针、场景)→ `--code`;不触及 `game/` 的一切改动(`design/`、根规则文件、`tools/` 工具脚本、`.zcode/` 配置等)→ `--docs`;同批混触 `game/` 与文档面 → 全量档不带参数。所选域全绿才合回 master。该脚本是全部验证闸的**唯一入口、唯一清单与唯一域划分**,闸件增减、分域调整都只改它;**本文与其他文档禁另列闸件清单**(清单散落多处正是 iter27 漏跑 `probe_gate --full` 的成因)。跑完写回执 `game/tests/.gates/receipt.json`(含 `domain` 字段),合回时由 worktree-guard 按 diff 路径推域强制校验(五况拦截:缺回执/quick 模式/回执 commit ≠ HEAD/域不覆盖本次改动/含新增红)。闸件(`tools/` 下机检脚本与闸壳)自身的改动不占合回全量——其质量义务=落批时的变异验证(test-conventions §6),闸真崩溃时合回闸 fail-closed(跑不出回执即拦),不以合回全量为兜底
|
||||
10. **批末按域验收才合并**——在任务 worktree 内跑 `tools/run_all_gates.sh`,**按本批改动域选档**:本批改动触及 `game/`(游戏工程代码、测试、探针、场景)→ `--code`;不触及 `game/` 的一切改动(`design/`、根规则文件、`tools/` 工具脚本、`.zcode/` 配置等)→ `--docs`;同批混触 `game/` 与文档面 → 全量档不带参数。所选域全绿才合回 master。合回前独立验收审计通过(iter 技能第 5 步),未过不合回。该脚本是全部验证闸的**唯一入口、唯一清单与唯一域划分**,闸件增减、分域调整都只改它;**本文与其他文档禁另列闸件清单**(清单散落多处正是 iter27 漏跑 `probe_gate --full` 的成因)。跑完写回执 `game/tests/.gates/receipt.json`(含 `domain` 字段),合回时由 worktree-guard 按 diff 路径推域强制校验(五况拦截:缺回执/quick 模式/回执 commit ≠ HEAD/域不覆盖本次改动/含新增红)。闸件(`tools/` 下机检脚本与闸壳)自身的改动不占合回全量——其质量义务=落批时的变异验证(test-conventions §6),闸真崩溃时合回闸 fail-closed(跑不出回执即拦),不以合回全量为兜底
|
||||
11. **合并后主区按域复跑**——合并可能引入冲突或环境差异,落回 master 后按本批改动域复跑:触及 `game/` 的批=全量复跑(维持);纯文档域批=复跑文档域档(秒级),不再全量
|
||||
12. **批次完成后的登记义务**——合回 master 后按 doc-conventions §12.1 推进待办清单条目状态(做完整条删除),涉及迭代编排的在 roadmap 迭代总表与顶部「当前位」节换代——执行入口=项目技能 batch-closure(批后收尾与中间文档退役),跨会话教训写记忆库。批次过程与结论由 git 提交信息承载,禁止再写会话状态文件(见 doc-conventions 第 10 节)。`design/` 与根规则文件(`AGENTS.md`/`roadmap.md`/`待办清单.md`/`体验验证清单.md`)实现批禁写,见 §13
|
||||
13. **文档同步闸(实现批禁写文档)**——实现批**禁写 `design/` 整个目录与根规则文件**,要往外交代的东西一律落 `reports/`:实现报告 `reports/iter<N>-实现报告-<日期>.md`(各卡状态+实机目检总清单+遗留读数义务)、代拍板追认单 `reports/iter<N>-代拍板-<日期>.md`、GDD 反哺点清单 `reports/iter<N>-反哺点-<日期>.md`(每条写清哪个文件哪一节、改成什么、依据是什么)。设计权威文档(GDD/art-bible)**任何批都不直改**:用户在会话中逐点裁决后,由非迭代批(工具/规则/文档批)写入 `design/`(执行入口=doc-design 技能),并把反哺条目从 `reports/` 清掉(吸收即死;退役执行=batch-closure 技能)。机械面文档(roadmap 行/术语表/README 工具注)同样归非迭代批在合并前更新。反哺点未落地期间相关 GDD 节视为待反哺,读前先查 `reports/` 与待办清单;需求卡片必列「关联文档同步面」按两层标注
|
||||
14. **实机目检归用户,只登记不阻塞**——真人检测项登记进实现报告目检总清单与体验验证清单即完成批内义务;禁把等目检当停工理由或完成前置
|
||||
15. **中间产物吸收即死**——细则见 AGENTS.md 硬性红线与 doc-conventions 第 11 节
|
||||
16. **改动级验收闭合**——写卡期列需求侧对照表,实现期补实际对照表(测试文件:行),每个行为改动做撤销证明;合回前独立验收审计。细则=test-conventions §9
|
||||
|
||||
## 4. 测试执行两入口铁规(细则)
|
||||
|
||||
|
||||
@@ -31,10 +31,10 @@
|
||||
|
||||
## 5. 测试函数怎么写——验收清单条目的落码规范
|
||||
|
||||
需求卡片 §7「逐需求点验收清单」每一条都要落成可执行的验证;本文定统一写法,卡里定每批的具体内容(测什么/注入哪里)。写卡期查不出执行载体的条目=不可测,当场呈报,禁拖到实现期。
|
||||
需求卡片 §8「改动—验收对照表」每一条都要落成可执行的验证;本文定统一写法,卡里定每批的具体内容(测什么/注入哪里)。写卡期查不出执行载体的条目=不可测,当场呈报,禁拖到实现期。
|
||||
|
||||
1. **执行载体五选一,逐条声明**:单元测试(`tests/run_all`)/冒烟断言(`smoke_all.gd` 对应场景段)/场景探针(`smoke/` 下 `*_probe`)/MC 同种子逐项比对/人工核对(仅限无法自动化的纪律类需求点,如命名锁定、数值占位)。行为类条目以自动化载体为主。
|
||||
2. **粒度与对应关系**:每条清单条目至少一个自动断言;多条条目可合用一个测试函数。断言失败消息末尾带编号尾缀〔卡短名 Vn〕(如〔秘宝批 V3〕)——断言与卡片清单可互相 grep 查找。
|
||||
2. **粒度与对应关系**:每条清单条目至少一个自动断言,且断言必须从该条目的真实入口进入;多条条目可合用一个测试函数,但撤销对应改动时每条都要能单独变红。断言失败消息末尾带编号尾缀〔卡短名 Vn〕(如〔秘宝批 V3〕)——断言与卡片清单可互相 grep 查找。
|
||||
3. **断言词汇按验证对象五选一**:
|
||||
|
||||
| 词汇 | 适用场景 |
|
||||
@@ -52,6 +52,8 @@
|
||||
|
||||
测试绿只证明「当前代码没犯这个错」,不证明「犯了这个错会被抓住」。新增或改写的验收函数(冒烟断言/探针自检/闸机判据)必须配一次变异验证,把拦截能力自证一遍。**无变异红记录的断言不写「已验收」,只写「已实现,拦截能力未证」。**
|
||||
|
||||
行为改动的撤销证明见 §9.4。新增或改写断言用变异验证;修改既有行为用撤销证明。两者不互相代替:变异证明断言能抓这一类缺陷,撤销证明断言真的钉在这次改动上。
|
||||
|
||||
**操作四步(逐条落实现报告变异验证记录表)**:
|
||||
|
||||
1. **注入**——把被测件改坏成该类缺陷的最小形态(翻装配序、注释一行 `add_child`、把状态源取反、把层 `visible` 置 false)。一次只注入一处;可直接改源码,不必留长期开关。
|
||||
@@ -84,3 +86,60 @@
|
||||
- **脚本错误会静默中断所在函数的剩余断言,而套件仍报全绿**(机制事实):GDScript 无脚本错误陷阱 API,错误不改进程退出码、不计失败数。三处实证:①2026-09-19「309 项 0 失败」实为断言未跑全(状态记录 83);②敌人表行集纪律 10 条断言因定型数组赋值错误从未执行(迭代 29 修复后两条正向见红=夹具本缺锚行);③`Callable` 形参类型写错致解析函数返回 null、后续断言整段蒸发。
|
||||
- 由此产生两条义务:**写闸件**按 §7 配三硬闸;**写验收函数**必须自证断言全数执行——变异验证(§6)为主证,反例实证(构造缺陷态改前判绿/改后判红)与零命中自检(扫描面为空即判红)为辅证。
|
||||
- **覆盖率不是目标**:行覆盖率度量缺失(Godot 无内建,第三方属新基建,是否引入待办清单在册待裁);现行补洞=零指名单测清单+人工判定,判定可靠性靠上列自证手段,不靠覆盖率数字。
|
||||
|
||||
## 9. 改动级验收闭合(2026-10-21 立)
|
||||
|
||||
### 9.1 验收单位是行为改动
|
||||
|
||||
一个行为改动 = 新增或修改一条函数、一条数据、一处接线、一个生命周期行为、一条玩家可见文案。纯改名、注释、格式化不算行为改动,但必须在对照表里单独列一行写「非行为改动」及判断依据。禁止用「重构」两个字把行为改动藏起来。
|
||||
|
||||
### 9.2 四层与真实入口
|
||||
|
||||
- **单元**:不依赖场景树和真实宿主的纯逻辑;测试直接调用被测函数。
|
||||
- **接口**:模块边界的公开契约——数据表加载、存档与断点、事件载荷、命令接口;测试从公开入口进出。
|
||||
- **集成**:跨宿主的接线、持久、生命周期——例如 LevelRunner 把 level_counters 传给 BattleOrchestrator、两场战斗共享同一个桶、断点续玩;测试必须实例化真实宿主链,禁止用裸 EffectEngine 代替。
|
||||
- **探针/golden**:玩家可达性与观感;真实实例化场景、驱动真实输入。
|
||||
|
||||
分层不是形式。改动发生在哪一层,验收就必须从那一层的真实入口进入。测试绕过了改动点,就不算这个改动的验收——这正是「断言存在、接线坏了却不红」的来源。
|
||||
|
||||
### 9.3 改动—验收对照表
|
||||
|
||||
需求卡片列需求侧对照表;实现报告列实际对照表。每行至少六格:
|
||||
|
||||
| 需求点 | 改动(文件:行/行为) | 验收测试(名称+文件:行+尾缀) | 层级 | 真实入口 | 撤销或变异证明 |
|
||||
|---|---|---|---|---|---|
|
||||
|
||||
实现报告另加「结果」格(绿/红/未过及依据)。两端都要对上:
|
||||
|
||||
- **正向**:每个需求点至少一行;每行必须有真实入口和证明方式。缺任一项=该需求点未验收。
|
||||
- **反向**:diff 里每个行为改动至少一行;没有对应行的改动,必须写明「非行为改动」或「由第 X 行覆盖」。
|
||||
- **测试侧**:新增或改写的每条断言至少挂一行;挂不上的孤儿断言删掉或补挂到需求点。
|
||||
|
||||
### 9.4 撤销证明
|
||||
|
||||
- **修改既有行为**:只撤销该改动(回退该 hunk 或该处接线)→ 跑能覆盖它的最窄测试 → 对应断言必须变红 → 还原 → 复绿。
|
||||
- **新增行为**:用 §6 的变异办法把新代码改坏成最小缺陷形态 → 对应断言必须变红。
|
||||
- **撤销后仍然绿**:说明断言没钉在这个改动上,判缺漏;不得用「代码能跑通」代替。
|
||||
- 每张任务卡至少一条撤销或变异记录;持久化、生命周期、存档、跨战共享这类接线逐行做。
|
||||
|
||||
### 9.5 禁止削弱测试
|
||||
|
||||
实现期不得为了让测试变绿而删除断言、放宽阈值、缩小扫描面、把真实入口换成下层直调。确需改判据=需求卡片没写清=上游缺陷:停该卡、呈报退回写卡段,不在实现期自行决定。卡片可预先声明允许改动的旧断言及理由;未声明的削弱由独立审计判红。
|
||||
|
||||
### 9.6 测试时机
|
||||
|
||||
不要求 TDD,不要求先红后绿。允许实现后补测试;但补的测试必须通过 §9.4 的撤销证明。实现完再补、补完就绿,不算验收。
|
||||
|
||||
### 9.7 独立验收审计
|
||||
|
||||
合并前由没有参与实现的会话或子代理做一次审计。审计只读需求卡片、实际对照表、diff、测试文件和实现报告,自己跑最窄测试抽查,不采信报告里的「已全绿」。审计至少做三件事:
|
||||
|
||||
1. 逐行核对对照表:测试存在、真的执行、尾缀能 grep 到、真实入口没有绕过改动点;
|
||||
2. 抽查撤销证明:每张任务卡至少一条,按记录复现红/绿;
|
||||
3. 检查测试削弱:删除断言、放宽阈值、缩小扫描面、换下层直调,逐处要卡片申报或用户批准。
|
||||
|
||||
审计报告落 `reports/iter<N>-验收审计-<日期>.md`,逐行写「通过/缺漏/例外及依据」。未通过不得合并。测试执行两入口铁规不变:审计在迭代 loop 内启动的子代理算 loop;另开会话须用户点名。
|
||||
|
||||
### 9.8 生效与旧卡
|
||||
|
||||
本规自 2026-10-21 起对文件名日期不早于该日的需求卡片生效;旧卡不回头改。旧卡在开工前缺对照表的,由写卡段补,补完再开工。
|
||||
+2
-1
@@ -10,6 +10,7 @@
|
||||
| `iter<N>-实现报告-<日期>.md` | 各任务卡状态、实机目检总清单、遗留读数义务 | 迭代批 |
|
||||
| `iter<N>-代拍板-<日期>.md` | 批内 agent 替你拍的决定清单,等你追认或推翻 | 迭代批 |
|
||||
| `iter<N>-反哺点-<日期>.md` | 需要写进 `design/` 权威文档的点,逐条列清"哪个文件哪一节、改成什么、依据是什么" | 迭代批 |
|
||||
| `iter<N>-验收审计-<日期>.md` | 独立验收审计结果:逐行对照表核对、撤销证明抽查、未过项与例外及依据 | 独立审计方(未参与实现) |
|
||||
| `iter<N>-<交付物名>-<日期>.md` | 需求卡片点名的其它交付物(例:`iter27-探针迁移对照-2026-10-14.md`=11 个探针的成员依赖面清单,已随迭代 27 收尾退役) | 迭代批 |
|
||||
|
||||
## 不放什么
|
||||
@@ -23,4 +24,4 @@
|
||||
|
||||
一个迭代号一组文件,落档即死:反哺点被 `design/` 吸收后,对应文件删除,历史进 git commit log
|
||||
(与"历史决策记录只进 git log、不设决策文档"这条红线同口径)。退役执行=batch-closure 技能
|
||||
(批后收尾与中间文档退役),删前先过 doc-conventions §11 判据。
|
||||
(批后收尾与中间文档退役),删前先过 doc-conventions §11 判据。验收审计报告随实现报告同批退役(结论已并入实现报告)。
|
||||
+91
-2
@@ -7,7 +7,9 @@ r"""pipeline_gate.py — 工作流程流水线闸(待办清单条目状态机
|
||||
历史行「—」豁免/周期≤2 周可特批豁免/单元格白名单/零命中);「已编迭代↔已写卡段↔迭代行
|
||||
卡片列」交叉核只此一处。2026-10-18 卡片冲突修订批补两条卡片机检:C1 关联文档同步面的
|
||||
文档义务口径(生效 2026-10-17)、C2 设计事实源声明(生效 2026-10-18)——两条都按文件名
|
||||
日期只追新规生效日之后的卡,旧卡属 git 历史留档不回头改。
|
||||
日期只追新规生效日之后的卡,旧卡属 git 历史留档不回头改。2026-10-21 验收闭合批补 C3:
|
||||
改动—验收对照表的结构检查(生效 2026-10-21)——只查节/列/行/必填格非空,不判断覆盖真假;
|
||||
覆盖真假由独立验收审计判。
|
||||
约束:每红项一行「文件:行号 判据名 一句白话说明」,exit 0=全绿 / 1=有红 / 2=输入件缺失;
|
||||
卡片与报告存在性相对 --repo-root 解析(缺省=本文件上两级);待办清单与 roadmap 均已为新格式
|
||||
(2026-10-18 数据整改批),本闸已注册进 tools/run_all_gates.sh 文档域(08c 流水线闸)。
|
||||
@@ -47,6 +49,12 @@ SOURCE_MARKS = ("设计事实源", "唯一事实源") # 两种合格写法,
|
||||
SYNC_HEADING_RE = re.compile(r"^#{2,3}\s*\d*\.?\s*关联文档同步面")
|
||||
BANNED_DOC_MARKS = ("design/", "../gdd/", "../registry/", "../research/", "../qa/",
|
||||
"../engineering/", "../ux/", "../art/", "roadmap.md", "AGENTS.md")
|
||||
# C3 改动—验收对照表(2026-10-21 验收闭合批,生效 2026-10-21)
|
||||
LEDGER_RULE_DATE = (2026, 10, 21)
|
||||
LEDGER_HEADING_RE = re.compile(r"^#{2,4}\s*.*(验收对照表|改动[—\-]验收)")
|
||||
LEDGER_REQUIRED = ("需求点", "改动", "验收测试", "真实入口")
|
||||
LEDGER_PROOF_MARKS = ("撤销", "变异", "证明")
|
||||
AUDIT_MARK = "验收审计"
|
||||
|
||||
DATE_RE = re.compile(r"\d{4}-\d{2}-\d{2}")
|
||||
VER_RE = re.compile(r"[vV]\d+(?:\.\d+)*")
|
||||
@@ -411,13 +419,88 @@ def card_date(path):
|
||||
return tuple(int(x) for x in found[-1].split("-"))
|
||||
|
||||
|
||||
def check_ledger(text, path, issues):
|
||||
"""C3 改动—验收对照表结构检查(生效 2026-10-21)。
|
||||
|
||||
只查:对照表节在不在、表头有没有五个必需列、有没有数据行、必填格空不空。
|
||||
不判断测试是否真的覆盖改动——那是独立验收审计的职责,机器闸不猜语义。
|
||||
"""
|
||||
lines = text.splitlines()
|
||||
start = None
|
||||
for i, raw in enumerate(lines):
|
||||
if LEDGER_HEADING_RE.match(raw.strip()):
|
||||
start = i
|
||||
break
|
||||
if start is None:
|
||||
issues.append((str(path), 1, "验收对照表缺失",
|
||||
"须含「改动—验收对照表」节(2026-10-21 起,req-card §8)"))
|
||||
return
|
||||
|
||||
header = None
|
||||
header_line = 0
|
||||
for i in range(start + 1, len(lines)):
|
||||
s = lines[i].strip()
|
||||
if s.startswith("#") and not LEDGER_HEADING_RE.match(s):
|
||||
break
|
||||
if s.startswith("|") and not SEP_ROW_RE.match(s):
|
||||
header = row_cells(s)
|
||||
header_line = i + 1
|
||||
break
|
||||
if header is None:
|
||||
issues.append((str(path), start + 1, "验收对照表缺表",
|
||||
"节内未找到表格"))
|
||||
return
|
||||
|
||||
idx = {}
|
||||
for name in LEDGER_REQUIRED:
|
||||
hit = next((k for k, cell in enumerate(header) if name in cell), None)
|
||||
if hit is None:
|
||||
issues.append((str(path), header_line, "验收对照表缺列",
|
||||
"缺「%s」列" % name))
|
||||
return
|
||||
idx[name] = hit
|
||||
proof_hit = next((k for k, cell in enumerate(header)
|
||||
if any(mark in cell for mark in LEDGER_PROOF_MARKS)), None)
|
||||
if proof_hit is None:
|
||||
issues.append((str(path), header_line, "验收对照表缺列",
|
||||
"缺「撤销或变异证明」列"))
|
||||
return
|
||||
idx["证明"] = proof_hit
|
||||
|
||||
rows = 0
|
||||
for i in range(header_line, len(lines)):
|
||||
s = lines[i].strip()
|
||||
if not s:
|
||||
continue
|
||||
if not s.startswith("|"):
|
||||
break
|
||||
if SEP_ROW_RE.match(s):
|
||||
continue
|
||||
cells = row_cells(s)
|
||||
if len(cells) < len(header):
|
||||
issues.append((str(path), i + 1, "验收对照表缺格",
|
||||
"列数少于表头(%d<%d)" % (len(cells), len(header))))
|
||||
continue
|
||||
rows += 1
|
||||
for name, k in idx.items():
|
||||
if k >= len(cells) or not cells[k].strip():
|
||||
issues.append((str(path), i + 1, "验收对照表空格",
|
||||
"「%s」列为空" % name))
|
||||
if rows == 0:
|
||||
issues.append((str(path), header_line, "验收对照表零行",
|
||||
"表内没有数据行"))
|
||||
|
||||
|
||||
def check_cards(root, issues):
|
||||
"""C1 文档义务口径(生效 2026-10-17)+C2 设计事实源声明(生效 2026-10-18)。
|
||||
"""C1 文档义务口径(生效 2026-10-17)+C2 设计事实源声明(生效 2026-10-18)
|
||||
+C3 改动—验收对照表结构(生效 2026-10-21)。
|
||||
|
||||
只检文件名日期达生效日的卡——更早的卡属已实现批次的历史留档,不回头改。
|
||||
C1 判据:「关联文档同步面」表内,目标格指向 design/ 或根规则文件、而义务格仍写
|
||||
「随批」者红(2026-10-17 req-card §6 改口径后,这类点只能列 reports/ 反哺点清单)。
|
||||
C2 判据:全文既无「设计事实源」也无「唯一事实源」者红(两种写法都与库内实态对齐)。
|
||||
C3 判据:有「改动—验收对照表」节;表头含需求点/改动/验收测试/真实入口/证明列;
|
||||
至少一行;必填格非空;全文含「验收审计」声明。语义覆盖不在此判。
|
||||
"""
|
||||
dirn = root / CARD_DIR
|
||||
if not dirn.is_dir():
|
||||
@@ -434,6 +517,12 @@ def check_cards(root, issues):
|
||||
issues.append((str(path), 1, "设计事实源缺失",
|
||||
"须含「设计事实源」或「唯一事实源」声明句(req-card §2 三选一,"
|
||||
"GDD 节+版本号/样张+art-bible 版本/工程直入证据指认)"))
|
||||
if when >= LEDGER_RULE_DATE:
|
||||
check_ledger(text, path, issues)
|
||||
if AUDIT_MARK not in text:
|
||||
issues.append((str(path), 1, "独立验收审计未声明",
|
||||
"须在卡内写明独立验收审计入口与报告文件(2026-10-21 起,"
|
||||
"test-conventions §9.7)"))
|
||||
if when < SYNC_RULE_DATE:
|
||||
continue
|
||||
in_sec = False
|
||||
|
||||
@@ -2,6 +2,14 @@
|
||||
|
||||
本清单是流水线的唯一登记处:要做的事先在此登记一条,随流水线段推进改状态,做完整条删除;各系统文档的「待办」节只留一行指路存根,不再自建条目。条目格式(标题=登记元数据,正文=现状/缺口/归属/状态四属性)与状态机以 [doc-conventions §12.1](design/engineering/doc-conventions.md) 为权威。
|
||||
|
||||
#### 验收闭合规则——下一次迭代实测评估(2026-10-21 登记,来源=审计发现,设计面=工程直入)
|
||||
|
||||
**现状**:2026-10-21 已改工作流技能与规约——[测试规范](design/engineering/test-conventions.md) 新增 §9(改动—验收对照表、真实入口、撤销证明、禁削弱、独立验收审计),[AGENTS.md](AGENTS.md) 硬性红线新增「验收闭合」,`req-card`/`iter`/`batch-closure` 三份技能同步,[流水线闸](tools/pipeline_gate.py) 新增 C3 卡片结构检查。规则文本已落地,还没在真实迭代上跑过。
|
||||
|
||||
**归属**:下一次迭代的实现批(按新规写卡、施工、审计;实测规则是否抓到缺漏、是否误红)。
|
||||
|
||||
**状态**:待裁决
|
||||
|
||||
#### UI 贴图重构批——营地与元进度件仍是程序化占位(2026-10-13 登记,来源=审计发现,设计面=美术轨)
|
||||
|
||||
**现状**:营地的柜台场景贴图目前是程序化画出来的临时形态,没有上贴图。这条债原先只写在美术侧的资产清单里([美术资产清单](design/art/art-assets-checklist.md) 第 134 行与第 175 行,原文注明"营地现为程序化占位,状态记录 121⑧ 口径,排期归 UI 贴图重构批"),2026-10-13 由 UI 美化三层诊断转立本清单专条。规格其实已经定了——烛光黄 `#F6C667` 配木色 `#8A5A34`(见 [美术圣经](design/art/art-bible.md) §4.4),素材来源允许走"通用图标改色复用"这条低成本渠道。
|
||||
|
||||
Reference in new issue
Block a user