读者看到的「版本」，和仓库里的 tag 对齐了吗？——文档、发布面与 Git tag 的最小约定

摘要（结论先行）

7 条要点；与下方 ipedia-meta 中 summary 数组逐字一致。

对读者而言，「仓库里存在某个 tag」只说明版本控制里有一个锚点，并不自动等于「浏览器里打开的文档、npm 装的包或镜像 digest 已与该锚点对齐」。
最小约定是：对外可读的文档版本号或 `updated_at`、changelog 条目与 Git tag 名称（或 release 资产名）在同一套发布说明里写清对应关系，避免 HEAD 与「声称版本」两张皮。
静态站点读者应以 canonical URL、构建注入的版本号或 footer 中的 commit/tag 核对；若站点无版本脚注，则只能相信 CDN 缓存与人工书签，核对成本陡增。
npm 等包注册表读者应以 package 版本号、`dist-tag`、lockfile 与 tarball 内容核对；容器读者应以 digest（SHA256）与镜像标签是否可变动核对，标签不等于不可变引用。
典型失败模式包括：长期只读无 tag 的默认分支、只改线上文档不打 tag、只打 tag 不更新对外索引或下载页上的「当前推荐版本」文案。
IPedia 文章通过 `updated_at`、更新记录与稳定 slug 的 canonical 路径提示「本页文本属于哪次编辑批次」，不替代你方仓库的 tag 与 CI 证明链；该做法意在降低「静默改文」误读，而非提供通用运维教程。
与 HDGP-Core 的字段语义对齐，解决的是声明层语言一致；不从「对齐 Meta」推出「已绑定某 tag 或某发布面」，更不推出已部署 Judge 或 Engine；法条与监管映射见 governance 轨既有文。

正文

读者任务 → 最小约定表 → 发布面枚举 → 失败模式 → IPedia 一句 → 延伸阅读。

1. 读者任务：为什么「tag 存在」≠「我看到的已更新」

维护者在本地打 v1.4.2 很痛快，但对外读者分布在四条链路上：浏览器里的静态文档、包管理器里的 semver、镜像仓库里的 tag/digest、邮件或 PDF 附件里的离线副本。任一条链若未与 tag 显式绑定，读者就会合理推断错误：例如读到「Scope 已不含某能力」，而生产仍按旧镜像运行——这不是读者粗心，而是发布面未给可核对的锚。

本篇不把「What/Scope/Links 怎么写」「声明冻结」再讲一遍；那是 protocols 上一篇与 governance 三连发的地盘。你需要的是：把「我声称的版本」与「读者实际消费的那一层」写成可验证的一句话关系。

关于 Meta-only 与运行时、双轨、承诺过度若仍有疑问，请直接读 governance 既有三文（见 §6），本篇合计只保留上段量级，不展开。

2. 最小约定：文档版本号、updated_at、changelog 与 tag

下面用虚构示例 acme/hdgp-meta-docs（无商业绑定）说明「最小可核对包」长什么样。

要素	建议	读者核对方式
Git tag	与对外 semver 或 docs-1.4.2 等团队约定一致	`git show v1.4.2` 或 GitHub/GitLab Releases 页
文档内版本号	README 或规范首页顶栏：Spec 1.4.2	与 tag 字符串一致或可映射表可查
updated_at / 日期	单页 HTML/Meta 中的 ISO 日期	与 changelog 最新条或 release 日期同序
changelog	遵循「人读得懂的一条一条」；与 tag 一一对应或注明「多 commit 合入」	对照 Keep a Changelog 的精神（见来源）

tag 命名若采用 semver，应与 SemVer 2.0.0 的公开语义一致（见来源）：主/次/补丁各自代表什么，避免「v1 与 1.0.0 混用」导致脚本与读者双重混乱。若文档版本与软件版本刻意脱钩（常见），必须在首页写死对照表，例如：软件 v2.0.0 ↔ 文档 bundle docs-2025-11。

3. 发布面枚举：读者如何知道「自己读的是哪一版」

静态站点（含 IPedia 类）

理想：构建时写入 git describe 或短 SHA、tag，页脚或 <meta> 可见。
底线：至少 URL 不变时在正文或 Meta 区有 updated_at + 更新记录，读者能判断「上次我读的是不是这一版」。

npm（或同类包）

读者看 package.json 的 version、安装的 lockfile、以及 npm view 的 dist-tag；「latest」不等于「文档当前稿」，除非团队明确政策。

容器镜像

digest 是唯一强锚；同一 tag 指向不同 digest 在不少注册表上可能发生，读者若只记 tag 会误判。

PDF / 离线包

须在封面或页眉写文档版本号 + 生成日期 + 对应 tag/commit；否则法务或采购附件无法与线上一致性对齐。

4. 失败模式（短清单）

无 tag 的 HEAD 即对外「当前规范」——读者与 CI 都无法复现同一棵树。
只改 CDN 上的静态站，不打 tag、不写 changelog——对外仍是「v1.4.2」视觉，语义已变。
只打 tag，下载页 / 索引仍指向旧 tarball 或旧镜像 digest——发布动作不完整。
多发布面只更新其一——例如 npm 已 2.0.0，文档站仍描述 1.x 行为。

5. 与 IPedia 自身实践的一句弱相关

IPedia 单篇文章使用稳定 slug 路径（如 …/doc-release-tag-and-published-surface.html）、文内 updated_at 与「更新记录」合并叙述，意图是：在无登录、无强制读者追踪的前提下，让读者能判断「该页是否在我上次访问后改过」。这不等于替你方做 SBOM、签名制品或 CI 证明链；若你要的是供应链级证明，需在自有仓库与发布流水线中单独建设。

6. 延伸阅读（中性锚文本）

来源与引用

3 个可验证入口；与 ipedia-meta.sources 一致。

HDGP-Core（Meta-only baseline）· core.hdgp-protocol.com （镜像 GitHub Pages；仓库 GitHub） —— Meta-only 字段语义与声明层对齐的事实锚点。
Semantic Versioning 2.0.0 —— tag 与 semver 命名时的公开语义参照。
Keep a Changelog —— changelog 可读性与与 release 对齐的实践参照。

边界声明

置于来源之后；与 ipedia-meta.scope_boundary 一致。

本文不提供法律意见或监管背书；不评价具体产品、CI/CD 平台或发布流水线是否满足某法规或标准。
不承诺任何商业或开源 CI/CD 工具能力；不暗示对齐 HDGP-Core 字段语义即等同于已绑定特定 Git tag、制品 digest 或已部署 Judge、Engine。
不代表主系统、PFaaS 或商业交付方立场。

更新记录

按时间倒序。

2026-05-15：读者体验 — 移除正文渲染区「关于 slug」内部命名说明（路径与 canonical 已体现 slug；正文不再展开备选名）。
2026-05-14：站内修订 — 全站 risk_tags 中 supply_chain 命名策略挂起；本篇 ipedia-meta 改回 ["misinfo","security"]；后续稿件若再出现该维度，由编辑直接落盘，不先行统一枚举。
2026-05-14：主系统侧验稿 — Accept；机读与摘要一致；采纳非阻塞建议：audience 与全站统一为「G=Government，公共机构读者」。
2026-05-14：首发定稿 — JSON（ipedia-meta）、摘要 7 条、正文六节、来源 3 条（GitHub + SemVer + Keep a Changelog）及后置边界声明；栏目 protocols；与上一篇导读差异化（tag / 发布面 / 读者核对）。