[Follow-up] packaged installer：签名 / 公证 / 原生信任链

[kxn]

背景

#647 第一阶段已明确：先把 macOS / Windows 的 packaged installer 主链跑通，但签名 / 公证不纳入本期完成标准。

这不是说签名不重要，而是当前缺少的外部条件与运维前置独立成了一张 follow-up：

• macOS 需要 Developer ID / notarization 相关账号与证书能力
• Windows 需要 Authenticode / SmartScreen 友好的签名链路
• release workflow 需要额外 secret、runner/tooling、失败诊断与验签验证面

如果把这些能力和 packaged installer 基础能力混在 #647 首期里，会把“先有原生安装器”这个主目标拖进证书与发布运维准备里。

目标

1. 为 packaged installer 补齐 macOS 与 Windows 的原生信任链能力。
2. 把签名 / 公证纳入 release workflow，而不是事后手工补。
3. 让最终下载体验尽量减少 Gatekeeper / SmartScreen 警告摩擦。

范围

• macOS Developer ID / notarization 集成
• Windows 代码签名链路集成
• release workflow secret / signing step / failure diagnostics
• 最小验签 / 公证状态 / 产物验证链
• 发布与运维文档同步

非目标

• 不在本单承担 packaged installer 本体落地；那部分由 #647 及其子单先完成。
• 不在账号、证书、secret、runner 条件未就绪时强行推进半成品集成。

完成标准

1. macOS packaged installer 已接入 Developer ID / notarization 方案。
2. Windows packaged installer 已接入正式代码签名方案。
3. release workflow 已能产出签名后的安装器资产。
4. 有最小 smoke / 验签 / 公证状态回传检查，不是纯黑盒手工点点看。
5. 文档已补齐证书/secret/运维前置与发布约束。

依赖

• #647 主线 packaged installer 能先稳定产出未签名资产。
• 外部账号 / 证书 / secret 准备完成。

信息索引

• #647 已决定本项延后处理，不阻塞 packaged installer 第一阶段。
• macOS 当前没有可替代 Apple Developer ID / notarization 的等价免费原生信任方案。
• Windows 可优先评估 SignPath for Open Source，但仍需要正式接入与验证。

相关文档

• docs/general/install-deploy-design.md
• .github/workflows/release.yml

涉及文件

• .github/workflows/release.yml
• scripts/release/**
• 未来 packaged installer 生成脚本与平台 signing helper

建议范围

1. 先等 #647 主线完成未签名 packaged installer。
2. 再单独收口 macOS 与 Windows 的签名 / 公证方案、secrets 与验证链路。

实现参考

• 不要把 signing 逻辑反向塞回 packaged installer 基础主线；它应该建立在稳定产物之上。
• macOS 与 Windows 的 signing requirements、runner、secret 管理面不同，允许在同一单下分阶段收口，但不应模糊 native trust 链目标。
• 若后续要引入额外供应链签名（如 Sigstore），也只能作为补充，不替代原生系统信任链。

检查参考

• 安装器资产验签 / 公证状态
• release workflow 秘钥注入与失败诊断
• 最终用户下载体验回归

收尾参考

• 结果不回阻塞 #647 的首期 close judgment。
• 完成后再回写安装文档与发布文档。