Orisumi文档站的发布
文档站构建为静态文件，GitHub Actions 从 main 构建并发布到 GitHub Pages，测试报告随发布固定
背景
文档站原来只在本地环境里运行，由 Next.js 服务按请求读取测试报告、改写 Markdown 地址。人和 Agent 要在不启动本地环境的情况下读文档，需要一个公开地址。后端和客户端要等重写完成后才部署，文档站需要先单独发布。
决定
- 文档站构建为静态文件，由 GitHub Pages 托管在
docs.orisumi.dev。 - main 上有相关改动时，GitHub Actions 构建并发布，也可以手动触发。构建依次运行文档检查、集成测试和静态构建，任何一步失败都不发布，线上保留上一次的站点。
- 公开站的测试报告来自这次构建运行的集成测试，并标明提交 SHA。
- 每个页面的 Markdown 版本以
.md文件发布。 - Playground、热更新和按请求读取报告只在本地文档站提供。
理由
文档只依赖仓库内容，静态文件就够了，发布不需要服务器，也不需要密钥。工作流和仓库在一起，发布由提交触发。
报告在发布时生成，所以页面上的结果和文档对应同一个提交。报告仍是测试结果的权威来源，见 ADR · 开发验证与测试证据。
公开站没有能调用的后端，所以接口页只展示契约。
放弃的方案：
- 部署 Next.js 服务。 需要一台常驻主机，换来的只是 Accept 协商和按请求读取报告。
- 把本机的 TestResults 提交到仓库。 报告可能和提交对不上，仓库里也会多出生成的文件。
代价
- 页面地址只返回 HTML。Agent 读 Markdown 要用
.md地址、/llms.txt或/llms-full.txt。 - 报告和页面历史要等下次发布才更新。每次发布都要等集成测试跑完。
- 开发服务器不按静态导出的规则检查，导出不支持的写法要到构建时才报错。
规则位置
- 构建、发布和发布后的检查：
src/Docs/Orisumi.Docs/README.md - 工作流：
.github/workflows/docs.yml
