姚章浩
4d43a9386a
build / build (push) Successful in 1m5s
真实数据发现（本机 p1 实例第一次同步后核对）：
- **缺陷**：tag `v0.1.0` 之前的 20 个提交，提交内 CHANGELOG 顶部**也已经**是 0.1.0（旧分支遗留条目），
而它们的祖先集合被那个**更晚才打**的 tag 全覆盖 ⇒ 按提交数算得 0 ⇒ 被错标成「0.1.0 开发版」。
它们的正确判定是「历史提交」：那个 tag 是后来才打的，当时还没有发布基线。
- **修复**：基线 tag 必须是该提交的**祖先（或就是该提交）**，否则不给号；新增原因码
`release_tag_created_later`（页面文案：'该版本是在更晚的提交上发布的 —— 这个提交当时还没有 tag'）。
回归用例两条：`TestDeriveVersionsDoesNotNumberCommitsThatPredateTheTag`、
`TestDeriveVersionsSideBranchWithoutTagStaysHistorical`（不含 tag 的侧分支同样不给号）。
- **部署脚本注入构建身份**：`scripts/deploy-api-web.sh` 原先不传 `-ldflags -X`，产物 `CommitSHA=unknown`
⇒ 页面只能显示"当前运行版本未知"（契约上诚实，但没用）。现在按 `scripts/version.py --identity`
（唯一来源，与 Makefile/CI 同规则）注入 VERSION/RELEASE_VERSION/BUILD_KIND/COMMITS_SINCE_RELEASE/
COMMIT_SHA/BUILD_TIME；取不到身份**拒绝继续**（宁可不上线，也不上线一个认不出自己的产物），
并在收尾核对注入的 SHA 真的进了产物。
- compose.yaml：把 VERSION_HISTORY_* 五项接进应用环境（api/worker 共享锚点），留空即未接线。
验证：真实仓库复验（114 条对账一致）⇒ 正式 1 / 开发 4 / 历史 109（原来错的 19 条现在都是
`release_tag_created_later`）；p1 实例重新同步后当前快照分布一致，带号的记录只剩 1 正式 + 4 开发
（含真实存在的「同号不同 SHA」：950c1b4 与 3a1d32d 都是 0.1.1，各占一行）；
make verify 15/15 success；前端 18 用例 + typecheck 通过。