发布工程

同一源码修订为五个原生目标构建两条产品线：

• Core 压缩包：节点、CLI 和外部矿工；
• GUI 安装包：钱包应用和私有节点。

发布文件从现有的带注释版本标签以及一份经过认证的 HistoryStep 矩阵包构建。

支持目标

所有包均使用 Cargo.toml 中的工作区版本。

源码准备

创建标签前：

1. 更新工作区版本和发布说明；
2. 运行格式检查、工作区检查及已变更 crate 的测试；
3. 运行适用的真实进程测试场景；
4. 认证规范矩阵包；
5. 确认差异中没有无关改动；
6. 创建带注释的 vMAJOR.MINOR.PATCH 标签。

标签与包版本必须完全一致。

矩阵包

发布使用一个名为以下内容的归档：

history-step-pack-v1.tar.gz

它的 SHA-256 摘要是工作流的显式输入。每个原生运行器都独立解压并 认证矩阵包；运行时元数据和两个矩阵叶节点摘要必须等于 pins.env。

发布构建把这些已认证字节嵌入 parano1d，安装后首次启动无需下载矩阵。

平台验证

在带标签的提交上手动运行 Platform CI 工作流。它检查：

• 可移植构建标志；
• 完整工作区编译；
• 原生二进制链接；
• 硬件检查行为；
• GUI 自检；
• 每种支持架构上的生产用证明内核；
• 对不支持的旧 x86 虚拟 CPU 作出干净拒绝。

记录成功的运行 ID 和准确的头部提交。

发布草稿

为标签创建 GitHub 发布草稿，并附上已认证矩阵包。原生工作流 完成前不要公开。

启动 Native Release 时传入：

• 已存在的标签；
• 矩阵包 SHA-256；
• 成功的 Platform CI 运行 ID；
• stable 发布频道。

预检要求标签带注释且版本匹配、发布仍处于草稿状态、 Platform CI 成功运行所对应的修订完全一致，并且矩阵包摘要有效。

原生构建

每个运行器调用：

./scripts/build_release.sh \
  --pack .release-ci/pack/history-step-pack-v1 \
  --output .release-ci/build \
  --skip-tests

完整源码测试已经在同一带标签修订上通过。每个任务仍会认证矩阵包、编译 完整目标、执行原生冒烟测试、打包两条产品线并上传到发布草稿。

发布

最终任务从发布草稿下载每个预期文件，验证矩阵包摘要，生成统一的 SHA256SUMS 并上传，之后才公开发布。

平台文件不完整时绝不发布。

签名状态

打包流水线支持可选的 macOS Developer ID 身份。没有项目签名凭据时， macOS 使用临时应用签名，Windows 则没有 Authenticode 签名。启用正式签名 前，用户文档必须说明首次运行警告，并要求校验 SHA-256。

发布后验证

公开后：

1. 按用户方式下载全部文件；
2. 验证 SHA256SUMS；
3. 在原生平台安装并卸载每个 GUI 包；
4. 运行 Core 硬件检查和帮助命令；
5. 用全新数据目录启动节点；
6. 检查 P2P 同步、钱包发送、收据恢复和正常关闭；
7. 将构建日志和准确的矩阵包摘要与发布记录一同保存。