Vault 导入：单一 vault 与忽略规则

上级：obsidian-sync-mechanism

决策：一个实时 vault（而非多 vault 实时同步）

StandMeet 的账户以单一 Obsidian vault作为其实时数据源——方案 A。另外两个方案先搜置：

B. 多个实时数据源——需要命名空间、按数据源分别做快照 diff、多传输通道；这是"笨重"的路线，会在源头就把链接图打散。目前否决。
C. 一个规范 StandMeet vault + 偶尔从其他 vault 导入——考虑过后否决；多 vault 不是方向。

为什么选 A：

机制最简单——单一数据源，不需要命名空间，不需要多源 diff。"别做得笨重"这个目标，最好的实现方式就是不去构建多数据源那套机制。
一张连通的图更能代表这个人——语料库的资产就是它的链接图（反向链接 → 图检索）。一个连通的 vault 胜过几个碎片化的 vault；多 vault 换来的是内容更多但结构更差。
可逆——先上线单 vault 版本，等真实需求出现再加导入功能（方案 C）；不要为一个日后可以容纳的使用习惯提前支付复杂度成本。

从 vault 里导入什么（隐藏文件夹问题）

一个 vault 里有很多隐藏的配置文件夹（.obsidian/、.trash/、.git/、.vscode/……）。这是一套已经定下来的做法——综合了 Obsidian、Digital Garden、File Ignore 插件和 git 工作流各自的处理方式：

主规则——publish: true 白名单式打标。 这是设计时的写法。 wiki/subjectivity/raw 实际落地的是反过来的（84080bac5，2026-07-15，F-L-8）：每个被路由到的 .md 都落库，publish 只决定匿名访客看不看得见（published）——owner 要让 agent 用不公开的笔记打底，一个标志装不下两件事。只有 writing/ 分支仍然按 publish: true 摄入（import.go:146）。所以真正做筛选的是下面的遍历规则，不是这个标志。
遍历时的防御措施（用于解析链接/附件）：
- 忽略所有以点号开头的文件/文件夹——一条规则就覆盖了 .obsidian/、.trash/、.git/，以及未来可能出现的其他工具目录（Obsidian 本身也不索引以点号开头的名字；不需要去枚举一份黑名单）。落地为 isHiddenPath（sync_classify.go:136），它也顺带跳过 _templates/；唯一的例外是 .obsidian/snippets/*.css + appearance.json，作为 owner CSS 被采集；
- 按扩展名白名单：只要 .md（再加一个指定的附件目录）。落地：routeFile 只接受已知顶层文件夹（wiki/ subjectivity/ raw/）下的 .md，根目录裸文件和未知文件夹一律跳过；writing/ 桶带着自己的附件；
- 一个 .standmeetignore（gitignore 语法）文件，供用户自定义排除项（Templates/、归档目录）——没有建（backend/ 里没有任何引用）；取而代之的是写死的 _templates；
不要把 vault 自带的 .gitignore 拿来做内容筛选。 .gitignore 针对的是开发产物（node_modules、.obsidian/），不是内容；把两者混为一谈会悄无声息地丢掉真实内容（参见 Quartz issue #2240）。

.trash/ 的陷阱：Obsidian 的本地回收站里存的是已删除的笔记——把它导入进来等于把删掉的东西复活。点号前缀规则已经覆盖了这一点。

前人做法

Obsidian——以点号开头的文件/文件夹不被索引（这是一个通行的约定）。
Digital Garden（dg-publish）——白名单式发布标记，与 StandMeet 的 publish 是同一思路。
File Ignore 插件——通过加点号前缀来隐藏文件；自动跳过 .obsidian//.git//.trash/。
Quartz #2240——一个警示案例：不要把 .gitignore 用于内容筛选。