Chain · 显式推送——AI 对话变为一份经过策展的语料库
L0 · 愿景
- thesis —— AI 对话是主要输入；循环是这样的：由 agent 策展出好的部分 → 通过 MCP 推送 → 语料库逐渐积累。两个承重的选择，原文照录："Explicit push, not automatic capture"（显式推送，而非自动捕获）与 "Curated corpus, not raw transcript dump."（经过策展的语料库，而非原始对话转储）。
- ai-conversation-is-the-substrate —— 思考的基质已经迁移进了聊天记录里，而聊天记录是私有且转瞬即逝的。
- why-now —— (b) MCP 让 agent 化的摄取变得顺手。
- introduction —— "the act of attaching it is the trust boundary; never scraped."（附加这个动作本身就是信任边界；绝不抓取。）
L1 · 承诺
除了主理人刻意策展并推送的内容之外，没有任何东西能进入语料库；私有的基质只有经过刻意的动作，才会变成一层持久的、面向公众的层。
L2 · 需求（旅程与功能）
主理人的策展旅程——raw→wiki→output 的晋升链。功能面：admin 端的 Raw / Wiki / Output / Subjectivity / Writings（app/src/components/admin/sections/）；service-handle 工具（StandMeet 作为 MCP server——见 confusables）：corpus.create / update / delete / promote，genre 是一个参数（原来按层分开的 promote_to_wiki / promote_wiki_to_output 已于 2026-08-01 收拢，27a407e31；backend/internal/corpus/ops），外加 writings.save / publish / unpublish 和 subjectivity.write；以及 admin 端的 Obsidian 界面，作为第二条摄取路径。
L3 · 设计决策
- 策展是一条流水线，不是一次倾倒 —— three-tier-corpus-promotion：条目按 raw→wiki→output 逐级晋升；这些层级把"curated, not dumped"（策展而非倾倒）变成一种结构性的事实。
- derived-path-corpus-as-filesystem ——
parent_id树，路径由此派生；backlinks-as-rebuilt-edge-tables ——wiki_refs从[[wikilinks]]声明式地重建。 - 推送搭乘的是 service handle —— 主理人的 AI 会话通过 StandMeet-as-MCP-server 推送（as-mcp-facade，对外的那一面——不是 agent 的能力面；见 capabilities），由 owner-keypair-auth 的 Sigv1 完成认证；这把密钥对是 agent 化摄取的信任锚点。
- vault 路线 —— writings-import-export / obsidian-sync-mechanism，实际机制（36789537d 核实）：手动、批量、无 watcher——流式 zip 导出 / 整个 vault 的 multipart 导入（
authoritative表单字段决定是剪枝还是只增改，routes/admin/obsidian.go:262）；每个被路由到的.md都会落库——frontmatter 的publish不是导入闸门，它只喂给published列，那一列闸的是匿名 reader（backend/internal/corpus/obsidian/sync.go:13-16）；幂等键 =obsidian_source_path；web-edit guard 会跳过任何在上次导入之后又在网页端被编辑过的行。它自 2026-07-08 起就是一个同步模式的连接器（d51805372：connector.NewSyncConnector+SyncIngester，backend/internal/connector/sync.go:41-62；/obsidian/import经它委托，routes/admin/obsidian.go:221）。
L4 · 工程产物
- 表：一张
corpus_notes表带genre列（raw/wiki/output/subjectivity/writing）+note_refs边表（writing 这个 genre 另有writing_refs）——backend/db/schema.sql。 - 查询/用例：
backend/db/queries/corpus/*.sql、backend/internal/corpus/{usecase,ops,repo}（域模块布局，backend-domain-modules）。 - MCP 界面：
routes/mcphandle（工具通过OwnerMCPBindings注册，backend/internal/capabilities/capreg/registry.go，as-mcp-facade）。 - obsidian 子系统：
backend/internal/corpus/obsidian/（sync.go、sync_classify.go、sync_note.go、export_corpus.go）+routes/admin/obsidian{,_multipart,_state}.go，挂在connector/sync.go之后。
L5 · 验证
晋升链和 admin-corpus 的端到端（e2e）测试已经存在；service-handle（Sigv1）认证也有覆盖。vault 路线不再是薄弱的一层：36789537d 下有十七个 e2e/test/sync-*.spec.ts（routing、tree、title、publish、links、alias-links、frontmatter、hidden、reconcile、raw、export、authoritative-prune、large-vault、subjectivity），所以反向链接重建（writings-import-export）有了自己的测试规范（sync-e-links、sync-e-alias-links）。
现状与缺口
Writings：推送 + 导出/导入在两个方向上都已落地。Wiki、subjectivity 和 raw 也接入了 vault——SyncVault 按顶层文件夹路由（obsidian/sync.go:2、sync_classify.go:64）；进来的方向上 output 仍只由晋升派生，而反向导出会把 wiki/subjectivity/output 按 genre 文件夹写回（export_corpus.go，9f1ffcf13，2026-07-29）。没有 watcher/实时同步——按当前设计是批量的；这条路线已经是同步模式的连接器，所以剩下的是那一步，不是重接管线。"策展而非倾倒"这个立场是靠结构（层级 + published 这道 reader 闸门）来强制的，不是靠审核——这是刻意的选择。