Skill · 整体架构概览
何时用：搞不清楚四个仓库都是干嘛的、谁推谁、谁渲染谁的时候。
解决什么：把 sbraveyoung 系博客生态的四个 GitHub 仓库以及它们之间的发布链路一次说清，作为后续所有 skill 的上下文锚点。
四个仓库，一句话各自的角色
| 仓库 | 角色 | 谁在维护 |
|---|---|---|
sbraveyoung/blog |
markdown 原始内容（唯一可信源） | 我（手写） |
sbraveyoung/gobog |
Go 写的渲染引擎 + 三套主题 | 我（手写） |
sbraveyoung/gobog-obsidian |
Obsidian 插件：双向同步 + 自动 front-matter + 微信草稿推送 + 本地预览 | 我（手写） |
sbraveyoung/sbraveyoung.github.io |
渲染后的 HTML，挂在 GitHub Pages 上 | 机器（CI 维护） |
关键约束：github.io 仓库不要手改——它的工作树会被 deploy workflow 整体替换。手改的东西下次 deploy 就没了。允许手改的只有 _gobog.json 和 .github/、scripts/。
数据流
本地 Obsidian vault
╱ Blog/
post/ ← 文章
pages/ ← /about、/contact 这种顶层页
resource/image/ ← 图片
│
│ gobog-obsidian 插件（双向）
│ • Pull：fetch + ff-only
│ • Push：stage → diff confirm → commit → push
│ • 新文件自动填 front-matter
▼
sbraveyoung/blog （GitHub）
│
│ push 到 master 触发
│ .github/workflows/deploy.yml → repository_dispatch
│ (event_type=blog-update) → 通知 github.io
▼
sbraveyoung/sbraveyoung.github.io 的 deploy.yml 跑起来：
1. checkout sbraveyoung/blog (markdown)
2. checkout sbraveyoung/gobog (渲染引擎)
3. go build ./_gobog/src (编译)
4. 读 _gobog.json 拼出 _gobog.toml (主题、评论、品牌)
5. gobog -config _gobog.toml -export _dist
6. scripts/check-export.sh _dist (死链 / 孤儿资源审计)
7. 用 _dist/ 替换工作树 + commit + push
▼
GitHub Pages 自动伺服 → sbrave.cn
唯一可信源 (source-of-truth) 规则
- 内容永远从 vault → blog → github.io 流，单向。github.io 上看到的内容，源头一定在
sbraveyoung/blog/source/。 - URL 由
front-matter url:锚定。一旦写过，gobog 永不会改。改一篇老文章的 URL = 对外的死链，慎重。 - 主题 + 品牌 + 评论开关住在
sbraveyoung.github.io/_gobog.json，不在 blog 里。改这些是在 github.io 仓库的提交，不是 blog。 - 代码逻辑（渲染、URL 生成、front-matter 默认填充）在
sbraveyoung/gobog。改这里要重新跑 deploy 才能在 github.io 上看到。
三种典型操作的"该改哪个仓库"
| 想做的事 | 改哪儿 |
|---|---|
| 写 / 改一篇文章 | vault 的 Blog/，插件 push 到 sbraveyoung/blog |
| 换主题、改站点标题、开评论 | sbraveyoung.github.io/_gobog.json |
| 改渲染逻辑、加 URL 路由 | sbraveyoung/gobog，再触发 github.io 的 deploy 才能看到效果 |
| 调插件行为（同步、模板等） | sbraveyoung/gobog-obsidian，本地 npm run build 后在 Obsidian 里 reload |
后续每个 skill 都默认你已经懂这张图。