核心用户旅程

Blog Studio 旨在消除从一个想法到安全发布之间的协调成本。它不是 CMS 数据库、托管控制平面或 Hexo 管理面板。

1. 回到创作本身

所有者注册发现的 Site，随后回到一个合并已发布文档、原生草稿和已修改工作副本的内容库。发现过程绝不改写文件。工作副本以乐观版本存入 SQLite，已发布的 Markdown 文件仍是权威来源。

兼容的编辑器始终必须提供源码模式。可视化编辑是一项便利功能，不能以丢弃未知 front matter、原始 HTML 或生成器语法为代价。

2. 请求有边界的协助

Site Agent 可从任意页面打开，并为每个 Site 保留多个持久 Session。文章和 Markdown 选区上下文必须显式附加且只属于一条消息；工作区边界仍是完整 Site。文件修改在相同硬策略下采用审批或 YOLO，而发布始终由人执行。

3. 看到真实结果

预览先在不启动子进程或 Provider 的情况下渲染已净化的 Markdown。条件满足时，增强预览会在隔离沙箱内运行配置的静态网站生成器，并代理经过标记验证的目标。增强模式较慢，但能保留主题、插件、永久链接和旧资源行为；失败时会带着类型化诊断回退到 Markdown。

4. 让生产变更清晰可读

公开发布绝不会基于点击时碰巧存在的文件开始。所有者先准备不可变 ChangeSet，审查并应用它，然后另行创建本地 Git 提交。只有该记录提交能进入持久化远程发布状态机：

1. 预检已审查的 revision 和目标；
2. 在 detached Git worktree 中构建并哈希输出；
3. 与最后一份已验证清单比较；
4. 先上传不可变资源，再上传引用它们的页面；
5. 让精确的缓存范围失效；
6. 验证公网标记和 URL。

每个服务商操作都会等待并记录。无差异时不会上传任何内容。

5. 无需临场发挥即可恢复

修改目标前，发布器保留足以恢复此前已验证清单的信息。准备或构建失败绝不会触碰生产。发布中途失败会进入回滚，而不会被报告为成功。

Studio 重启和公开网站可用性彼此独立：公开网站是静态的，请求时不依赖 Blog Studio。

为什么 Hexo 是适配器

Hexo 包含自定义 front matter、标签、主题、插件、永久链接规则和旧资源，是首个严格的兼容性验证，但它不定义核心领域。生成器、仓库、资源、发布器和缓存边界独立版本化，其他文件式生成器也能实现同一旅程。

有意推迟的范围

多用户协作、定时或自主发布、托管 Agent 均不在项目完成线内。AI 协助终止于本地、可审查的生产变更，不会把预览或发布变成自主控制平面。