AskaEth
add7f2e672
test(m170): 改对复审点出的两处证据陈述 + 收紧用例前提（零行为改动）
r1 复审 p2-2items（守卫本身判 clean，四条变异自跑确认有牙）。这一轮**只动注释与测试
前提，产品行为零变化**：`format/write.rs` 一字未改，`probe.rs` 保持上一提交的收窄结果。
p2-1 复审核正的事实：`one_file_over_the_threshold_...` 的 `kind()` **不区分闸的位置**。
它的源是**可读的** 8 KiB 真文件，闸被挪到 `File::open` 之后时写循环第二道闸
`Written::spend`（每块之后 `guard_with`）照样返回 `Limits`——所以它在「闸挪位置」的
变异下仍然绿（我这轮重跑变异 A 也复现：其余 4 条全绿）。原来那句「源文件能读时这里
拿到的是 pack_io」是错的，改成「可读源命中第二道闸」并把顺序的举证责任明确交给
`the_gate_runs_before_any_content_is_opened`。
p2-2 目录长度的实测数字之前钉错了：我早先那条探针用的是**短名**（`f0`..`f39`，7 条
才到 4096、40 条仍 4096），而用例里填的是 `filler-NN`。这轮按用例真实形状重测三组
（`std::fs::metadata`，同一台机器同一 `%TEMP%`）：
短名 `f0`…`f39`：空 0 ｜ 3 条 0 ｜ 7 条 4096 ｜ 20/32/39/40 条 4096
`filler-NN`： 空 0 ｜ 3 条 4096 ｜ 7 条 4096 ｜ 20 条 8192 ｜ 32 条 8192 ｜ 39 条 12288 ｜ 40 条 16384
两次独立跑同形状结果一致。所以「第几个条目起非零」没有平台无关答案（NTFS 目录索引按
4 KiB 一档分配，跟条目名长度与条数都有关），三处注释改成区间 + 一张实测表，并注明
「只钉 32 个 `filler-NN` 这个形状（本机 8192）」，不再硬凑一个好看的数字。
顺带做掉复审那条「不计入 p2 但建议收紧」：前提从 `declared > 0` 提到
**`limit > 清单 JSON 长度`**（`limit = declared.saturating_sub(1)`，`json_len` 由
`CURSEFORGE.render(&manifest)` 现算，本用例实测 220 字节）。否则某个对 32 个条目报得很
小的文件系统会让用例因「清单自己越线」而假绿。同时把 `declared - 1` 换成
`saturating_sub`，让长度为 0 时走到清楚的 assert 文案而不是整数下溢 panic。
把 `DIR_LENGTH_FILLERS` 临时改成 0 验证过这条 assert 是活的：红在这句上
（`声明长度 0 − 1 = 0 … 必须大于清单 JSON 自身长度（220）`）。
变异复跑（本机 Windows/NTFS，跑完已还原 write.rs）：
- A：`preflight` 挪到 `File::open(&source)` 之后 → 新用例**红**（left Io / right Limits），
其余 4 条仍绿（含上面那条可读源用例，正好印证 p2-1 的更正）；
- C：A 之上只留 `expect_err` / `!target.exists()` / `leftovers` → **5 条全绿**，
结构断言确属同义反复。
门禁：`cargo test -p unlucky-core --lib` 613 passed / 0 failed / 0 ignored；
`cargo fmt --all --check` 干净；`cargo clippy -p unlucky-core --all-targets -- -D warnings`
干净；zip64.rs 345 行（<400）、probe.rs 45 行。
2026-11-08 10:39:28 +08:00
..
2026-11-08 10:39:28 +08:00
2026-11-07 17:01:13 +08:00
2026-10-31 21:54:10 +08:00