一条连接会像 import 一样写进下游文件

你从一张卡片的手柄拖到另一张卡片上，一条线出现了。接下来的问题通常很具体。这条连接写到哪里去了？git 看不看得到？之后 Claude Code 或 Codex 打开这篇笔记时，又怎么发现这个关系？

BaseHalf 保存连接的方式，就像源文件声明自己的 import：只写一次，写在使用这段上下文的那个文件里。A → B 保存在 B 里。A 是 B 的 upstream。没有单独的图数据库，也不会往 A 里再写一份。

列表写在哪里

具体写到哪儿，取决于下游条目本身能不能放下这份列表。

如果一篇 Markdown 笔记本来没有 frontmatter，BaseHalf 第一次需要写入时会补上这个块，并提醒你一次。

常见写法如下，形状和连接文档里的例子一致，仅作说明：

---
upstream:
  - research/interviews.md
  - sources/survey-results.pdf
---

# Launch decision

这些路径相对于工作区文件夹。列表是纯文本。你、代理或其他编辑器都可以改；BaseHalf 以文件里保存的内容为准。你在画布上连接、断开或重连，编辑徽章，创建带连接的条目，或修复一条损坏的条目时，它也会改这份列表。某个条目被移动时，它会改写所有点名该条目的记录。

Downstream 方向不会保存在任何地方。徽章上的 Downstream 列表，是根据工作区里每一份 upstream 列表算出来的。在卡片 A 上点 Add Downstream，等于把 A 写进另一条目的 upstream 列表。真相只有一份，住在消费上下文的那些文件里。

Markdown 链接不会生成这些条目。画一条线，或使用 Add Upstream，才会。

为什么 git 和代理都能读到

声明写在 B 里，所以你画完这条线之后，git diff 会显示你放开鼠标的那个文件里多了一段 upstream:。从没打开过画布的同事也能看到这篇笔记建立在什么之上。打开这篇笔记的代理会看到同一份列表，不需要把整个工作区倒进提示词。

BaseHalf 不会把这些 upstream 文件注入代理的提示词。代理用自己的工具读文件。BaseHalf skill 会告诉它们描述和连接写在哪里，所以它们知道去看 frontmatter 或镜像文件。这和把代理上下文放进 upstream 列表是同一件事：关系在文件夹里，不在你会关掉的聊天里。

B 应该跨会话一直建立在 A 上时，就连上。你只是为这一问才指着「这个」时，用选中。

这种存储方式不会自动做的事

要改 B 依赖什么，就得改 B，或在画布上重连（重连也会改 B）。删除 A 不会改写 B。点名 A 的那条记录会留下来，变成损坏条目，直到你 Relink、Relink Everywhere 或 Remove。修复损坏的 upstream 路径写的就是这一步维护。

生成文件会保留当初的输入。改这些输入会被拒绝。草稿在生成过程中，也会把输入保存在镜像路径下。

你可以像对待 import 列表那样对待 upstream 列表：在需要这段上下文的文件里读它，跟这个文件一起提交，让下一次会话打开文件时自己发现它。