协作指南
本仓两人协作：主干维护者（直接提交 main）与协作者（自己的分支写页，由主干侧合入）。 规范尽量不靠自觉——能程序化的都挂在 pre-commit 钩子和 intake 脚本上，本文说明”程序挡什么、人看什么”。一次性准备（每个克隆都要做）
铁律（程序拦截，违反无法提交）
行级规则（外链、
$ 转义、正文 H1 等）只检查本次新增的行，历史遗留不会卡你。
合并主干的正确姿势（本次事故的根源，重点读）
背景：2026-08-12 复盘发现，协作分支把 main 合进来时，冲突文件全选了”自己的版本”， 导致主干此前的修复（品牌名、BOM 剥离、one-click-integration / lobehub / workbuddy
的内容重写）被静默回退。这种回退在后续 diff 里长得和”新改动”一模一样，主干侧几乎无法分辨。
规矩：
-
勤合并：动手写新东西前先
git merge origin/main，别攒。攒得越久冲突越多，判断成本越高。 -
冲突时默认吃掉主干的版本。把 main 合进你的分支时，main 是
--theirs：你在这个文件上的新内容，合并后重新改一遍再提交——改动在 diff 里清清楚楚， 远比”保留旧版把主干修复冲掉”好收拾。 -
merge-guard 会自动拦：合并提交时若发现”main 改过的文件被整体退回你的旧版”，提交会被拒绝，
并列出文件清单和修复命令。真的有理由保留自己版本（极少见），用
SKIP_MERGE_GUARD=1 git commit并在提交说明里写明原因。
写新页面之前：先搜主干，防主题撞车
背景：协作分支写了faq/log-export-timezone-utc.mdx，而主干四天后已有同主题的
faq/log-timezone-and-export.mdx——文件名不同、措辞不同、内容重复，合入时只能弃掉一篇。
这种撞车程序判不了（实测两篇的文本相似度只有 0.05），只能靠动手前先查：
协作者提交前自查
- 只产出简体中文（根目录）+ 英文（
en/）两版，其余语种是主干侧跑管线生成的 - 时间标注时区：
18:30 (UTC+8) - 正文
$转义为\$，frontmatter 里直接写$ - 外链只允许第一方域名（
apiyi.com全系、icover.ai、企微客服work.weixin.qq.com）， 其它域名写成纯文本 + 反引号 - push 自己的分支，不推 main
主干侧合入流程
git diff --cached过内容口径（定价话术、折扣数字、竞品措辞——脚本挡不了这些）- 人工合并
docs.json（只动 zh / en 两块） npm run i18n:plan看成本 →npm run i18n出繁日韩俄npm run links确认坏链不升 → 提交