为什么改
在此之前，Build 内容的发布依赖人工判断：内容是否合规、结构是否完整、发布后运行时能否正确读取，都缺少统一的检查点。一旦内容格式与运行时预期不一致，问题往往要到发布之后才暴露。
这次改动的目标不是增加功能，而是把「内容能不能发」变成一个可以在发布前回答的问题：内容先经过契约校验，再经过 CI 门禁，最后才进入发布流程。
改了什么
改动集中在几个相互衔接的部分：工作流、内容目录、文档、运行时内容模块、脚本与测试。
内容侧引入了 schema 与 topics 定义，把笔记、变体与主题的关系显式化；脚本侧负责按契约校验内容；测试侧同时覆盖 PHP 与 Node 两条检查路径；工作流侧把预览与门禁串起来，使发布前必须通过检查。
发布本身以一次生产部署收尾，部署记录写入仓库文档，并打上对应的验证标签。具体版本、提交、产物摘要、测试数量与语料计数见上方 facts。
怎么验证的
验证分两层。第一层是自动化检查：PHP 与 Node 两套检查在 CI 中运行，并设有若干门禁，只有全部通过才允许继续。第二层是生产验证：产物部署到生产环境后，运行时报告了自身的状态与所加载的内容规模。
需要区分两个时间点的语料口径：
- 1.3.5 部署时生产语料 | 5 篇笔记 / 15 个 variant / 13 个 topics
- 截至当前仓库语料 | 6 篇笔记 / 18 个 variant（其中 1 篇仍未发布）
前者是部署当时的运行时快照，后者是仓库当前的内容状态。两者不一致是正常的：仓库里可以存在尚未发布的草稿。
- 版本
- 1.3.5
- 主发布提交
- 57bf785a0bcd6e886397de776cbe7bd7156fd64c
- 生产 provenance 提交
- 4b4ec32a3aac70a8222ca7255f0db38fb6683200
- 部署产物
- weour-core-1.3.5.zip
- 产物 SHA-256
- f660c0d9b48cbe774a3ba10d380eedfbf9a4fee5cf1a49c97c024ee7c1ee28ab
- 插件清单 SHA-256
- 952f570124787702fc8c71ce6ebd5410dca3099730b212d805189f3764d2a703
- 部署环境
- production
- 部署状态
- deployed
- 运行时状态
- ready
- 运行时版本
- 1.3.5
- 运行时模块数
- 12
- 测试数量
- PHP 1100 项检查 / Node 97 项检查
- 门禁数量
- 5
- 1.3.5 部署时生产语料
- 5 篇笔记 / 15 个 variant / 13 个 topics
- 截至当前仓库语料
- 6 篇笔记 / 18 个 variant（其中 1 篇仍未发布）
它不意味着什么
它不意味着内容发布从此不需要人工判断。流水线检查的是契约与结构，不检查内容本身是否恰当、是否值得发布。
它不意味着仓库里的内容都已经上线。仓库当前的内容数量多于部署时的运行时数量，差额来自尚未发布的草稿。
它也不意味着这套流程已经覆盖未来所有内容形态。这次验证针对的是当前的内容契约与运行时读取路径，契约之外的形态不在本次验证范围内。
最后，它不构成对后续版本、时间线或能力的承诺。这里记录的是一次已经发生的发布与验证，以及支撑它的证据。