测试规则
- 每次代码改动都要补充或更新测试覆盖。
- Source code 放在
src/，tests 放在test/。 - 局部行为靠单测，runtime-visible 行为靠集成验证。
- 前端和文档站改动要验证真实渲染结果，而不只是看源文件是否改过。
对读者的影响
若文档站结构已变，却没有测试锁定入口与导航，读者会遇到断链或缺失页面，这类变更就不宜视为已经完成。
推荐测试栈
单元测试
验证局部解析、配置编译、策略判断等隔离行为。
集成测试
验证 approvals、persistence、exports、transports、recovery 等 runtime-visible 行为。
文档站测试
验证静态文档入口、导航和关键文案仍然存在。
真实环境验证
只要依赖外部系统、provider 或发布链路，就要把关键路径跑到真实环境。
集成与真实环境验证
仓库约束明确要求：一旦功能依赖 provider 行为、外部协议或 GitHub Actions release flow，就不能只停留在本地自测。
npm test
./node_modules/.bin/vitest run test/docs/developer-docs-site.test.ts
./node_modules/.bin/vitest run test/docs/docs-site.test.ts文档与行为保持一致
每次功能变更都应顺带检查：README.md、README.zh.md、docs/index.html、受影响的 docs/ 专题页，以及 RELEASE_NOTES.md 是否需要同步更新。
至少要查这些
README.md、README.zh.md、首页、专题文档、release notes。
为什么重要
行为已更新而文档未跟上，用户会按过时说明操作，相当于多出一个与代码并行的缺陷。
发布流程
- 先 triage 并确认问题属于产品边界。
- 实现最小、最准确的 product-owned 修复。
- 补 unit tests 和 integration tests。
- 把文档与 release notes 一起更新。
- 推送后持续盯 GitHub Actions，直到关键流水线全部变绿。
- 如果修复对应 issue，在 release 确认后关闭 issue。
GitHub Actions 的正确姿势
push 到 master 不是结束。只有当新 head commit 对应的关键 workflow 全部成功，才能算真正发布完成。
交付清单
代码
实现符合产品边界，没有把 backend 细节误暴露成产品语义。
测试
关键行为有证据，不靠口头解释证明“应该没问题”。
文档
README、文档站、专题文档和 release notes 全部同步。
发布
CI 全绿、release 成功、相关 issue 可以闭环。
发布前自检清单
- 代码与产品边界一致。
- 改动行为有聚焦测试覆盖。
- 文档和 release notes 已同步。
- 新
masterhead 对应的 GitHub Actions 全绿。 - 相关 issue 可以明确说明“已经发布了什么”。