工程改动(验证整改阶段3+4·用户令): 验收档三档申报落test-conventions §8.3(判据=失败代价单维,卡头申报U0确认改判,2026-11-05生效,未申报旧卡按高档全量审计)+审计深度分级落§8.7(高档=现行四件事全量,中档=逐行保留复跑省略以CI回执代证,低档=对照表抽查≥1/3且新增改判行必抽,削弱检查与例外核对三档全保留,档位存疑按高档)+doc-conventions §12.1条目正文限长双判据(≤12行且≤700字去空白,过程叙事归git提交信息)+pipeline_gate机检两件(条目超长行/字双判据+卡片验收档申报C4)+req-card/iter两技能随动(必备结构第16节/审计深度分级口径)+待办清单9条存量压缩(过程叙事归git与过程件指针)+ci_watch中间态误写终局红回执缺陷登记(run 37实证:回执16:59记红,run 17:03才succeeded,现查API全绿)+整改条目整条删除(四方向全完成,测试有效性度量用户裁暂不处理)+盘点报告退役(吸收即死,design零引用)+批报告; 负证三件(字数829红/行数18红/验收档缺申报红-申报后消红); pipeline_gate PASS 28条目; --docs全绿

design/engineering/doc-conventions.md

@@ -155,6 +155,8 @@
 **状态**：按状态机取词。
 ```
 
+**条目正文限长（2026-11-04 立）**：正文四属性只写现行状态与证据指针；过程叙事（逐轮裁定追记、「某日用户裁…」式沿革叙述、设计讨论过程复述）禁入正文——沿革与裁定史由 git 提交信息承载（第 10 节同源）。长度硬上限双判据：正文（四属性全部内容，不含标题与空行）≤12 行，且去空白字符合计 ≤700 字；任一超限即须压缩，由流水线闸机检。行数判据抓清单行蔓延，字数判据抓单行堆砌，两条并用缺一不可（实证：单行堆砌型超长条目一行可塞 1500 字，只限行数拦不住）。压缩方向＝枚举与裁定细节迁 owner 文档或过程件（关联文档清单指过去），正文只留现行状态＋证据指针＋缺口。
+
 `改动面` 四档的划线判据（按被改对象的路径归属，与闸的分域同口径）：
 
 | 档 | 覆盖范围 |

design/engineering/test-conventions.md

@@ -97,6 +97,8 @@
 - **反向**：diff 里每个行为改动至少一行；没有对应行的改动，必须写明「非行为改动」或「由第 X 行覆盖」。
 - **测试侧**：新增或改写的每条断言至少挂一行；挂不上的孤儿断言删掉或补挂到需求点。
 
+**验收档申报（2026-11-04 立，自 2026-11-05 起对文件名日期不早于该日的需求卡片生效；旧卡不回头改）**：每张需求卡片在头部信息区（与设计事实源声明同区）申报一个验收档，三档：高／中／低。判据＝失败代价单维——这条改动做错了，后果随存档或结算传播的（存档写读与迁移、RNG 流、战斗结算公式与乘区、经济入账、数值表结构校验）＝高；后果玩家可见但不损持久状态的（常规玩法逻辑、门控、交互逻辑、呈现数据面）＝中；后果即看即知且无状态残留的（文案、纯呈现样式、布局微调）＝低。一张卡触多档按最高档申报；申报由写卡段落笔，用户批卡（U0）时确认或改判。档位只调节 §8.7 审计深度——闸机与 CI 的域划分、选闸算法、全量强制档一概不因档位变化，真实入口、判据绑定面、禁削弱等验收闭合判据全部照旧。未申报档位的卡一律按高档全量审计。机检＝`tools/pipeline_gate.py` 判据 C4：卡内须含「验收档：高／中／低」申报行。
+
 **能力清单维护锚（2026-10-29 用户裁改版定稿）**：`game/tests/README.md`「能力清单」是**实现指导＋阅读导航＋义务声明**——只宣布「要验证什么」，不记「是否已验证／是否跑过」；落地账归现行验收闭合链（改动—验收对照表逐条挂断言＋合回前独立验收审计），本清单不承载验证状态。表为四列：能力｜系统｜真实入口｜代表用例（`文件:函数`）。**维护归写卡段，当场入表**：写需求卡片时，本批新增能力当场写入能力行——真实入口取自设计文档已定的入口，代表用例＝卡里定死的计划测试（`文件:函数`）；受影响存量行（入口／用例名变更）同批更新；能力退役删行。**实现照单落名**：测试函数名以清单为唯一依据，名实不符＝卡片没写清＝停卡退回。**收尾核对**：批末收尾只核对表上名字与实际落地一致（改名则回表），不刷任何批次字段；实现批禁写该文件的现行红线不变（process-conventions §3 第 11 条），核对义务归收尾提交。三层模型见 §8.9。改动—验收对照表纪律不变：新增或改写的每条断言仍须挂一行（上文「测试侧」）；断言改判仍受 §8.4 真实入口口径约束。
 
 **新增 core 件的覆盖登记义务（2026-11-03 架构审查 P1 余项裁）**：拆件或重构产出的新 core 文件不触发 process-conventions §3 第 6 条「新功能必配新测试」（那条只管新增玩法/机制），因此单由本条承接——新 core 件要么被 `game/tests/` 某套件按文件名或 `class_name` 点名，要么在承接它的能力行「代表用例」里申报「经宿主链覆盖（宿主＝<件>）」；两者都无＝批末收尾核对时补登。本条**不是覆盖率要求**，与 §7「覆盖率不是目标」同轨：登记的是能力义务的归属，不做文件计数——「每个 core 件必须被点名一次」的机器闸已裁否（它逼出为点名而点名的空套件，且与 §7 正面冲突）。落笔面沿用现行分工：申报行由写卡段入能力清单（实现批禁写该文件），核对归批末收尾提交。
@@ -126,7 +128,19 @@
 3. 检查测试削弱：删除断言、放宽阈值、缩小扫描面、换下层直调，逐处要卡片申报或用户批准。
 4. 核对内部字段直查的受控例外：直查行是否已在对照表注明理由（该行为无公开可观测面可钉）。
 
-审计报告落 `reports/iter<N>-验收审计-<日期>.md`，逐行写「通过／缺漏／例外及依据」。未通过不得合并。测试执行两入口铁规不变：审计在迭代 loop 内启动的子代理算 loop；另开会话须用户点名。
+**审计深度分级（2026-11-04 立）**：审计按卡内申报的验收档（§8.3）逐卡定深度；梯度只落在昂贵的判断件上，机械且堵造假向量的两件（削弱检查、例外核对）三档全保留不抽。中/低档省略的测试复跑以 CI 回执为执行证据（回执是机器产物——「不采信实现者自述已全绿」的口径不变）：
+
+| 审计动作 | 高 | 中 | 低 |
+|---|---|---|---|
+| 对照表逐行核对 | 全量 | 全量 | 抽查 ≥1/3 行；新增行与改判行必抽 |
+| 判据绑定面核对 | 抽查（现行口径） | 抽查（现行口径） | 抽 1 行 |
+| 测试削弱检查 | 逐处 | 逐处 | 逐处 |
+| 直查例外核对 | 逐条 | 逐条 | 逐条 |
+| 最窄测试复跑 | 抽查（现行口径） | 省略——以 CI 回执代证 | 省略——以 CI 回执代证 |
+
+低档的抽查面与抽中依据照写审计报告；「每批必有审计、禁零审计批」不变；档位存疑按高档执行。
+
+审计报告落 `reports/iter<N>-验收审计-<日期>.md`，逐行写「通过／缺漏／例外及依据」，逐卡标注验收档与实际执行深度。未通过不得合并。测试执行两入口铁规不变：审计在迭代 loop 内启动的子代理算 loop；另开会话须用户点名。
 
 ### 8.8 生效与旧卡