3 Commits

Include renames

Author	SHA1	Message	Date
AskaEth	66eb912df0	fix(packaging): --generate-key 打印的 PinnedKey 改成 rustfmt 保持的多行形态（M265） ... `--generate-key` 与「信任表是空的」报错里给人粘贴的 `PinnedKey` 原来是单行： PinnedKey { key_id: "…", public_key_hex: "<64 hex>" }, 这一行有 113+ 字符（即使 key_id 为空），超出 .rustfmt.toml 的 max_width = 100， 所以 `cargo fmt` **必然**把它拆成 4 行 —— 人贴单行 → 下一轮 fmt 改动 → 谁忘了跑 fmt 就把 fmt 红带进 main（T30 那次就是这条路径）。 改的是「打印模板」与文档，不是解析器（KID_RE 的 \s* 本来就吃两种形态）： - 新增 render_pinned_key()，字段各占一行、元素缩进 4/字段缩进 8、结尾逗号， 与 trust.rs 里 cargo fmt 生成的形状逐字一致；两条打印路径都走它。 - 提示文案不再暗示「贴完还要 fmt」，改成「贴完直接提交，不用再跑 fmt」。 - docs：signing.md §3 与 signing-runbook.md §2/§4/§8 的「那一行」→「那一段（4 行）」， 并在 runbook §7 明写这条断言在没装 rustfmt 时的退化边界。 - --self-test 新增形态断言：① 渲染结果 == 4 行期望字面量 ② 形状与 trust.rs 现存条目 （字段值抹平后逐行）一致 ③ 单行必然超 max_width、多行每行都不超 ④ 贴进标记之间能解析 ⑤ 有 rustfmt 时在临时副本上真跑一遍，要求粘贴块字节不变（没有则打 note 跳过，不装成验过）。	2026-11-12 09:26:05 +08:00
AskaEth	bc1b09b776	fix(packaging): 播报 workflow 的种子只在 main 注入 + --key 用法错回 2 + 指针修正（M255 r1 P2-1/2/3） ... P2-1（安全）：`signing-status.yml` 原先把生产签名种子注入到 `pull_request` 与任意 ref 的 `workflow_dispatch` 运行里，而 CI 跑的是那个 ref 自己的代码 ⇒ 任何能推分支的人都能把种子搬走 （这把种子能给全量已装客户端签可信清单）。改成： - 去掉 `pull_request` 触发； - 注入行加 ref 门：`github.ref == 'refs/heads/main' && secrets.… || ''`； - 非 main 用 `ULL_SIGNING_KEY_WITHHELD` 说明原因，于是 ② 读「未判定（未注入）」而不是「没配」。 runbook §2 步② 加硬顺序：先合这笔、再录 Secret。 P2-2：`--key` 读不了（不存在 / 是目录 / 非 UTF-8）曾在 main 的 try 之外抛 traceback + rc=1， 与「未就绪」同码；现在统一 rc=2 + 一行说明，并补用例 `key_unreadable`。 P2-3：4 处文案指针修正（`signing-ready.yml` → `signing-status.yml`；§3 → §2 步③；§1–§3 → §2 步①–③；§4 → §2 步⑤ / §5）。新增两条机检：`section_refs`（输出的 `§N` 必须是 runbook 真实 章节号）与 `signing_ready_wiring_selftest.py`（文档里的 `packaging/…`/`crates/…`/`.github/…` 路径必须真存在），后者另带三处变异重放：去掉 ref 门 / 加回 pull_request / 改坏文档路径 ⇒ 必须红。 顺带修掉 r1 复审指出的两处小问题：`--release-assets` 里只有 `manifest.json.sig` 时的子串假读数 （先剥 `.sig` 再判清单）、③ 那个从不参与判定的 bool 保持原样（无行为影响）。 selftest 拆成两份（400 行红线）：判据本体 + 接线/文案。guards.yml 仍 399 行零改动。	2026-11-11 20:17:04 +08:00
AskaEth	bff48e27fa	feat(packaging): 签名就绪度播报 + 操作手册（M255） ... M254 查出 `trust.rs` 的 `PRODUCTION` 表在 PINNED-KEYS 标记之间是空的 ⇒ 任何正式二进制都验不过 任何清单（fail-closed）。工具链早就齐了，缺的是操作步骤与可见性；本条补的就是这两样，不生成钥、 不改 Rust、不碰 release-publish 的判据。 - `packaging/check_signing_ready.py`（只读、零第三方依赖）：三行读数 ① 信任表空不空 ② 环境有没有钥 （顺手对账「这把钥在不在表里」，种子一个字节都不打印）③ 最近一次发布的 .sig/清单痕迹（取不到写 「未知」）。退出码 0 就绪 / 1 未就绪（打印 fail-closed 后果 + 一行修复命令）/ 2 用法错。 - `packaging/tests/signing_ready_selftest.py`：判据自测，含**两个方向的变异重放**（退出码永远 0 ⇒ 判据①必须红；永远 1 ⇒ 判据②必须红）与接线判据（没人 uses: 它、没有 error 级注解、就绪度那步恒 exit 0）。 - `packaging/docs/signing-runbook.md`：人类照做的 5 步 + 每步判据 + 11 条已知坑 + 没验的部分（无任何密钥值）。 - `.github/workflows/signing-status.yml`：把三行搬进 job summary 的**播报** workflow。guards.yml 已 399/400，与 gpu-evidence.yml 同先例另开文件；刻意不声明 workflow_call:，未就绪用 ::warning::、 就绪度那步恒 exit 0，明确「不应被设为 required」。 - `packaging/README.md` / `packaging/docs/signing.md`：索引与指针。	2026-11-11 20:05:45 +08:00