AskaEth
540b82e197
fix(m200-r1): 文档降到实测能撑的程度 + 守门收紧 core 声明内容（复审 P2-1 / P3-1）
复审 reviewer-presenterfix-r1 的 fix-then-merge 两条，逐条落地。
P2-1(a)「两档」措辞被本次提交自己作废 ⇒ 三处全改成三档：
* `crates/core/src/update/trust.rs` 模块文档（读者最先看到的那句，上次漏了）
* `crates/core/src/update/tests/support_sign.rs` 模块文档 + `TEST_SIGNING_SEED` 的文档
P2-1(b)「三者都进不了发布产物」被复证实测证伪（`cfg!()` 是运行时假分支，不是 `#[cfg]`
编译期剔除；无 feature 的 dev 与 --release 两档 core rlib 里公钥十六进制与 `test-only-key` 都在）
⇒ 降级到事实能撑的断言：「不会被 `keyring()` 并进信任表，正式构建永远不认这把测试钥」，
并明写「字节仍编在产物里」「字节级不在产物里未证、也未声称」「换 `#[cfg]` 是另一条结构性改动」。
没有换成 `#[cfg]`（那是复审建议另开的 mission）。
P3-1 守门对 core「自己的声明」只认形状 ⇒ 收紧为只许空数组：
`DECLARATION` 从 `^\s*update-test-key\s*=\s*\[` 改成 `^\s*update-test-key\s*=\s*\[\s*\]\s*$`，
并加一条自检向量（core 声明里偷偷带子 feature ⇒ 必须红）。`--self-test` 从 6 条变 7 条
（5 红 / 2 绿）+ 基线，`packaging/README.md` 的计数同步。
⚠ 一个自己踩出来的坑，已被既有守门抓住：收紧时我先在 `check_test_key_off.py` 里把那条更宽的
测试通道 feature 写成**字面量**（自检向量 + 文档表格），`check_test_source_off.py` 立刻红
（`packaging/**` 按字面扫，这次提交前它一直是绿的）。改法照该文件自己的声明办——用
`OTHER_FEATURE = "-".join(("update", "test", "source"))` 拼出来，源码里字面量为 0，
自检向量仍然构造出完整字符串并必须判红。
验证（均在最终树上）：`cargo test --workspace --all-targets` 0、`cargo fmt --all --check` 0、
`check_test_key_off.py --self-test` 0（7 向量）/ 正式扫描 0、`check_test_source_off.py` 0、
`check_workflows_yaml.py` 0。
2026-11-09 07:56:33 +08:00
..
2026-11-08 16:20:34 +08:00
2026-11-05 14:08:37 +08:00
2026-11-09 06:46:29 +08:00
2026-11-09 05:06:52 +08:00
2026-11-09 07:56:33 +08:00
2026-11-08 14:50:15 +08:00
2026-11-09 06:46:29 +08:00
2026-11-07 18:56:01 +08:00
2026-11-09 07:56:32 +08:00