实测的缺陷：v1.0.2 的二进制是对的（校验和与 b060f86 干净树上的本地构建逐字节一致），但 **tag 落在 1.0.1 那个提交上**——因为脚本不自己建 tag，而是让 Gitea 建，而 Gitea 把 release 的 tag 建在"创建那一刻远端默认分支的 HEAD"上。当时 b060f86 还没 push，origin/main 还是 f499d02， 于是 v1.0.1 和 v1.0.2 指向同一个树，去读该 release 源码的人拿到的是修复前的版本。 两处修正： 1. 创建 release 时显式给 `target_commitish`，不再让服务器决定。 2. 发布前要求工作树干净、且 HEAD 已在某个远端分支上。前者不只是洁癖：Go 默认把 VCS 信息打进 二进制，工作树脏时构建产物带 "modified" 标记——实测同一个提交，干净树是 9c9c09dd…，脏树是 1d9bf3a1…，所以"tag 必须指向二进制所来自的那个提交"这句话在有未提交改动时根本不成立。
b060f86
发布逻辑搬到这里，因为二进制从这里构建、这里拥有契约。simadmin-relay 的那个脚本改成 转发（一条命令，不是两份实现——两处知道怎么发同一批产物，就是两处要在注册表 API 变化时 一起改，这个仓库已经犯过一次）。 与本仓库的一条硬约束绑定：**必须公开可读**。安装命令由节点执行、节点没有凭据，而 Gitea 对私有仓库返回 404，所以节点上看到的失败长得像 URL 写错。脚本现在会检查并**拒绝发布**， 而不是发出一批拿不到的东西。 VERSION 提到 1.0.0，release body 里的安装片段更新为 enroll + install 两步。
chick
chick
chick
chick