Repository navigation
[BUG] 覆盖率门禁只守 3 个 snapshot 文件，发布/回滚路径没有独立地板 #277
Description
Bug 描述
.github/workflows/test.yml 的 Guard critical runtime coverage 为 3 个 snapshot 文件设了独立地板（90 / 88 / 84），pyproject.toml 另有总体 fail_under = 90。但 AGENTS.md 反复强调的最高风险区——import/split 的暂存、事务发布、回滚与焦点写入——没有任何独立地板，只能被总体 92.9% 稀释。
当前实测低于总体水平的正是这些模块（见“实际行为”）。总语句数 8659，这些模块掉十几行覆盖对总分会造成不到 0.2 个百分点的影响，只要 snapshot 那边覆盖略高，CI 仍然全绿。
复现步骤
- 执行
python -m pytest -m "not slow and not nightly" --cov=pt_snap_cli --cov-report=term - 查看
python -m coverage report --show-missing --fail-under=0中下列文件 - 对照
.github/workflows/test.yml中仅有的 3 条--fail-under
预期行为
高风险模块拥有与风险等级匹配的独立覆盖率地板，单模块回退不会被总体达标掩盖。
实际行为
本机 macOS / Python 3.13.11 / f876665，pytest -m "not slow and not nightly" 加分支覆盖：
core/import_metadata_contract.py76%（miss 6 行 + 6 分支）core/import_metadata.py79%（miss 30 + 1）snapshot/representation.py82%（miss 12 + 4）core/split_service.py84%（miss 28 + 17 分支）core/focus_service.py88%（miss 19 + 8）core/skill_service.py88%（miss 42 + 18）core/snapshot_cache.py89%（miss 18 + 18）
总体 92.9%（门槛 90），全部通过。现有 3 个地板实测为 92.0 / 90.3 / 85.4，说明地板机制本身有效——问题在覆盖对象与 AGENTS.md 的风险排序不一致。
操作系统
macOS
Python 版本
3.13.11
pt-snap-cli 版本
0.4.0（HEAD f876665，v0.4.1-4-gf876665）
日志/错误信息
$ python -m coverage report --show-missing --fail-under=0 | grep -E "split_service|import_metadata|focus_service|skill_service|snapshot_cache|representation"
src/pt_snap_cli/core/focus_service.py 178 19 38 8 88% 69-70, 85, 97, ...
src/pt_snap_cli/core/import_metadata.py 141 30 36 1 79% 59-60, 71-72, ...
src/pt_snap_cli/core/import_metadata_contract.py 33 6 16 6 76% 15, 21, 27, ...
src/pt_snap_cli/core/skill_service.py 400 42 168 18 88% 333, 370, 397, ...
src/pt_snap_cli/core/snapshot_cache.py 209 18 114 18 89% 88, 105, 125, ...
src/pt_snap_cli/core/split_service.py 224 28 82 17 84% 51, 72-73, 154, ...
src/pt_snap_cli/snapshot/representation.py 80 12 32 4 82% 27, 41, 48-52, ...补充信息
只有 3.13 的 test 作业会生成覆盖率；platform 作业（macOS/Windows）不测覆盖率，因此平台相关分支本来也在这道门禁之外。
Activity
fix: close checkpoint descriptor before failure cleanup (#285)
test: enforce independent critical transaction coverage floors (#284)
codeasier commentedon Nov 1, 2026
状态纠正：本 issue 曾在 PR #285 合入时（2026-11-01 16:22:18 UTC）被 GitHub 自动标为 completed。正文使用了带关闭关键字的否定句，GitHub 仍识别为关闭指令；这是状态管理失误，不代表验收完成。现已于 17:06:45 UTC 重开，并移除相关 PR 正文的自动关闭语法，不重写提交历史。
PR #285 的 Windows checkpoint 清理修复已合入且合后 CI 通过；完整覆盖率门禁 PR #284 已合入 main
81af6698675efcc0bd63c8b9be0a331b14241f66，其合后 Test / Platform 仍在执行。保持本 issue 开放，全部必要合后检查通过后才显式完成。codeasier commentedon Nov 1, 2026
最终合后验收已完成。main
81af6698675efcc0bd63c8b9be0a331b14241f66的原 push Test run 41329139788, attempt 2 与 Platform run 41329139799, attempt 2 均成功，12 项适用检查全部通过。attempt 1 曾被已合 PR 正文修正触发的并发组取消；取消不算通过，本次恢复后已核 event=push、branch=main、精确 head。Python 3.13 合后证据：3478 passed，总体覆盖 94.51%，原总体90及三个90/88/84门槛保持，新增七项独立门槛全部通过（10项总计）；真实构建 wheel、来源审计和离线安装 CLI/skills 双格式验收均成功。Windows 原始零写入安全断言
test_zero_checkpoint_write_fails_before_any_focus_mutation保持不变并通过；最小运行时修复独立在 #285，覆盖测试/CI 变更在 #284。Python 3.11 最后于 17:54 UTC 成功（3462 passed）；此前较慢不据此宣称设备故障。nightly/manual job 按普通 push 事件策略 skipped，不冒充已执行；本项按已确认的 focus/覆盖门禁范围验收；#286 输入解析变更另需该补充验收。相关 issue 将在本回执后显式完成。#280 仍开放，#286 的精确最终 head 仍需独立 manual dataset/200-seed 验收及后续合后检查。