工程改动(验证整改阶段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全绿
This commit is contained in:
DKChan committed
1 parent
536dc07261
commit
7639ec5b3a
6 files changed
+93
-101
No files matched your search
@@ -0,0 +1,31 @@
|
||||
# 工程改动报告：验收档分级与待办条目限长批（2026-11-04）
|
||||
|
||||
> 接收方：待办清单「验证与清单体系整改——四方向分阶段推进」条（阶段 3＋阶段 4 收口凭据）
|
||||
> 性质：工程改动＋文档设计改动直改批（用户 2026-11-04 发令开工；W 层八裁点当日全裁——档名高/中/低、判据=失败代价单维、三档、强度差只落审计深度且每批必有审计、U0 确认权、行数硬上限、入 pipeline_gate 机检、存量同批压缩；How 细则由本批推导落文）
|
||||
|
||||
## 1. 改动清单
|
||||
|
||||
| 面 | 改动 |
|
||||
|---|---|
|
||||
| `design/engineering/test-conventions.md` | §8.3 新增「验收档申报」：三档高/中/低，判据＝失败代价单维，卡头申报、U0 确认或改判，2026-11-05 起对文件名日期不早于该日的卡生效，未申报旧卡按高档全量审计。§8.7 新增「审计深度分级」梯度表：高档＝现行四件事全量；中档＝对照表逐行保留、复跑省略以 CI 回执代证；低档＝对照表抽查 ≥1/3（新增行与改判行必抽）＋复跑省略；测试削弱检查与直查例外核对三档全保留；档位存疑按高档。 |
|
||||
| `design/engineering/doc-conventions.md` §12.1 | 新增「条目正文限长」：正文只写现行状态＋证据指针，过程叙事归 git 提交信息；≤12 行且 ≤700 字（去空白）双判据，流水线闸机检。 |
|
||||
| `tools/pipeline_gate.py` | ①待办条目限长双判据机检（行/字，超限判据名「条目超长」）；②卡片验收档申报机检 C4（GRADE_RULE_DATE=2026-11-05）。 |
|
||||
| `.zcode/skills/req-card`（不入 git） | 必备结构新增第 16 节「验收档申报」。 |
|
||||
| `.zcode/skills/iter`（不入 git） | 独立验收审计节挂深度分级口径（逐卡定档、旧卡按高档）。 |
|
||||
| `待办清单.md` | 存量超限条目 9 条压缩（架构审查余项／三关色相／验证与清单体系整改／数值标定窗口／棋盘键盘／二三关观感／封印印记／生涯／EffectPort 删键）——过程叙事归 git 提交信息与既有过程件，正文留现行状态＋证据指针＋缺口。 |
|
||||
|
||||
## 2. How 数值与判据推导
|
||||
|
||||
- **限长 12 行**＝实况说明行 1＋文档指针行至多 8＋缺口/改动面/状态各 1；**700 字**≈8 条指针（约 320 字）＋现行状态叙述余量——以现行合规条目实测校准（压缩后的整改条目约 400 字）。行数与字数并用：单判据皆可绕（多行蔓延／单行堆砌），实证＝整改条目原实况为单段 1500+ 字。
|
||||
- **审计深度梯度锚定现行 §8.7 四件事**：机械且堵造假向量的两件（削弱检查、例外核对）三档全保留不抽；昂贵的判断件（逐行核对、复跑）按档放宽；中/低档复跑省略的执行证据由 CI 回执承担（CI 全量强制档不因档位变化——迭代 44 实证的跨卡漏网兜底保持原样）。
|
||||
- **档名取「高/中/低」**：P0/P1/P2 记号已被 doc-conventions §12.1 占用为待办紧急度专用（新文档禁另立别义）。
|
||||
- **生效日 2026-11-05**：沿用卡片按文件名日期生效的惯例（§8.8 同型），当日已写卡（EffectPort 批 2026-11-04）不回头改。
|
||||
|
||||
## 3. 验证
|
||||
|
||||
- `pipeline_gate.py` 全仓 PASS（压缩后零超限）；负证：临时超长条目行数与字数两判据各自触发红（临时件在 /tmp，未入库）。
|
||||
- `run_all_gates.sh --docs` 全绿；合回后远端 CI 追验（文档批＝文档域秒级闸）。
|
||||
|
||||
## 4. 同批发现与登记（不在本批修）
|
||||
|
||||
- `tools/ci_watch.sh` 在 run 未落定时把中间态写成终局红回执：2026-11-04 run 37（commit 536dc072）实证——回执 16:59:55 写入 verdict=red，而该 run 17:03:10 才以「Job succeeded」落定，现查 Gitea API 组合状态＝success；回执与真值相反，下游按「红未修不开新批」被误阻塞（本批开工时人工查 API 解封）。已登记待办清单新条目（直改类，修复方向＝只认 run conclusion 落定后的终局态）。
|
||||
@@ -1,46 +0,0 @@
|
||||
# 盘点：验证与清单体系（阶段 0）
|
||||
|
||||
> 2026-10-28 · 服务待办清单「验证与清单体系整改——四方向分阶段推进」条
|
||||
> 性质：过程件（吸收即死）——结论吸收进待办条目与阶段 1 设计文档后删除。
|
||||
|
||||
## 1. 结论
|
||||
|
||||
1. **验证集清单零机器闸依赖**：`tools/run_all_gates.sh`、hooks、五个项目技能均不引用它；规范性锚点只有 `design/engineering/test-conventions.md` §8.3 一处。退役不需要改闸、改钩子、改技能。
|
||||
2. **测试名尾缀不是全量追溯键**：47 个有断言的文件中 19 个零尾缀（含三条 35 条以上断言的大套件）。能力清单只能按「能力→代表用例」建，不能要求逐断言尾缀。
|
||||
3. **对照表与待办清单都有机器闸**：前者的列结构、后者的条目格式均由 `tools/pipeline_gate.py` 强制；这两处瘦身要动闸，属阶段 3／4，不是阶段 1 的顺手活。
|
||||
4. **能力清单已有现成形态**：`game/tests/README.md` 的「集成旅程清单」5 行，扩面成本低；`repo_structure_audit.py` 不限制 `game/tests/` 下的 .md 文件名。
|
||||
|
||||
## 2. 依赖面盘点
|
||||
|
||||
| 件 | 消费方 | 机器闸依赖 | 退役／改动成本 |
|
||||
|---|---|---|---|
|
||||
| `game/tests/验证集清单.md` | test-conventions §8.3、待办清单 1 条、2 份过程报告、`tools/extract_checks.py` | 无 | 低：改 1 条规约＋删文件 |
|
||||
| `tools/extract_checks.py` | 无自动调用；手工生成／对账 | 无 | 可保留为审计工具，或随清单退役 |
|
||||
| 改动—验收对照表 | req-card 技能、iter 技能、`pipeline_gate.check_ledger`（强制 5 列） | 有 | 中：规约＋两技能＋闸三处 |
|
||||
| 待办清单 | `pipeline_gate`（格式全套）、`doc_ref_audit`、`doc_term_audit`、`repo_structure_audit`、各技能 | 有 | 低：正文压缩不触机检；新增「≤5 行」规则才动闸 |
|
||||
| 独立验收审计 | iter 技能、req-card 技能、`pipeline_gate`（只查「验收审计」字样） | 有（字样） | 中：改抽样规则要动两技能＋规约 |
|
||||
| 集成旅程清单 | 无机器消费 | 无 | 低：直接扩面 |
|
||||
|
||||
## 3. 覆盖数据
|
||||
|
||||
- `game/tests/**/*.gd` 共 70 个文件；静态 `check(` 粗口径 1607 处（含 `test_kit` 定义行与 `smoke_boot` 等提取器口径外宿主），清单口径 1587 处。
|
||||
- 标签尾缀〔…〕756 个（上限口径，一条标签一个）。
|
||||
- 有断言的文件 47 个：28 个有尾缀，19 个零尾缀。
|
||||
- 零尾缀大套件：`seal_polarity` 69、`variant_placement` 42、`roll_multiplier` 35、`cross_system_flow` 22、`damage_math` 21、`skill_unlock` 20、`type_glow` 20、`minesweeper_rules` 16、`system_contracts` 15。
|
||||
- 静默收集通道 `check_quiet` 约 407 站点在提取口径外（既有备案，test-conventions §5 工具局限）。
|
||||
|
||||
## 4. 对四阶段的影响
|
||||
|
||||
| 阶段 | 盘点结论对它的约束 |
|
||||
|---|---|
|
||||
| 1 换尺子（A） | 先扩「集成旅程清单」到核心域；每行＝能力｜真实入口｜代表用例｜最后验证批次｜缺口。退役验证集清单；`extract_checks.py` 去留在设计讨论裁 |
|
||||
| 2 按新尺子精简（B） | 删并对象改为能力项；每项能力保留至少一个代表用例；不要求逐断言尾缀 |
|
||||
| 3 调验收强度（C） | 对照表列与审计抽样一起改，触 `pipeline_gate`、req-card、iter 三处；不要与阶段 1 同批 |
|
||||
| 4 文档减肥（D） | 待办正文压缩可直接做；「≤5 行」入闸需改 `pipeline_gate` |
|
||||
|
||||
## 5. 未决点（阶段 1 设计讨论）
|
||||
|
||||
1. 能力清单落点：`game/tests/README.md` 扩面，还是独立文件？
|
||||
2. 能力项粒度与覆盖面：按哪些域切、预计多少行？
|
||||
3. `tools/extract_checks.py` 去留：随清单退役，还是保留为审计工具？
|
||||
4. 验证集清单退役时点：立即冻结，还是阶段 1 设计定稿后一并退役？
|
||||
Reference in new issue
Block a user