文件被挪走后，BaseHalf 靠内容认出它
在 BaseHalf、访达、git 或一次代理会话里重命名或移动文件，即使当时 BaseHalf 是关着的，它也会按内容在新路径认出这个文件，并更新所有点名它的 upstream 条目，不会先问你。
你把 research/interviews.md 重命名成 research/interview-notes.md。已经有其他笔记把它写在 upstream 里。如果这些路径会冻住不动，文件一改名，连接就会断。
只要 BaseHalf 还能在新路径上认出这是同一个文件，它就会改写那些点名它的条目。它不会先问你，也不在乎是谁做了这次移动。
它怎样认出文件
不管是谁移动或重命名，条目都保留自己的卡片：你、代理、访达或 git 都一样，BaseHalf 关着的时候也一样。再次打开这个文件夹时，BaseHalf 根据内容在新路径认出这个条目，把它为这个条目保存的东西一起移过去，并改写所有引用旧路径的 upstream 条目。
不需要额外的命令。代理用自己的工具重命名和移动文件即可。与 Agent 协作 也写了这一点：无论代理在哪里运行，BaseHalf 都跟着内容走。
重命名后的卡片位置不变。把卡片移到另一个文件夹时，它会排在那里已有的最后一张卡片后面。
什么时候会改写列表，什么时候会保持断裂
自动改写发生在 BaseHalf 认得出的移动或重命名上。删除是另一回事。删除一个条目，绝不会改写别人的列表。点名它的那些条目会留下来，变成断裂，直到你 Relink、Relink Everywhere 或 Remove。
在一些已经写明的情况下，识别也会失败。
| 发生了什么 | BaseHalf 会怎样 |
|---|---|
| 重命名或移动，并且内容仍然对得上 | 认出文件，转移它保存的数据，并更新所有点名它的条目 |
| 文件同时还被改写了一半以上 | 认不出来；点名它的条目显示为断裂 |
| 空文件 | 认不出来 |
| 没有文件的文件夹 | 认不出来 |
| 删除 | 其他列表原样不动，其中的条目变成断裂 |
| 还没有文件的草稿 | 只能在 BaseHalf 里移动 |
断裂的条目会故意留在原处。不用改遍每篇笔记，也能修好坏掉的 upstream 说明了 Relink、Relink Everywhere、Remove，以及 BaseHalf: Show Upstream Issues。识别没跟上文件时，就走那一步维护。
为什么靠内容，而不只靠路径
upstream 列表是相对于工作区文件夹的纯文本路径。它们写在 Markdown 的 frontmatter 里，或写在 .bh/mirror/<path>/upstream.yaml。git 看出的 diff、代理读到的，都是这条路径。如果唯一的标识就是这串文字，一次重命名看起来就永远像「删掉旧文件，再出现一个新文件」。
按内容匹配，就能在文件其实还是同一份的时候，让路径跟上。下一轮 Claude Code 或 Codex 打开笔记时，看到的已经是更新后的列表。你不必把新路径逐个粘进每一份下游文件。
这是「连接像 import 一样保存」的另一半。一条连接会像 import 一样写进下游文件 解释列表写在哪里。这篇说的是，被 import 的那个文件搬家之后，这些路径会怎样。
需要提前知道的局限
一次大幅度改写如果和移动绑在一起，看起来就会像另一份文件。如果代理在同一步里改写了笔记的大部分内容，又给它换了名字，旧路径可能会变红。这时去 Relink，或者把工作拆开：先重命名，再编辑，让内容识别有机会生效。
空文件和空文件夹没有可匹配的内容。如果要依靠自动更新，先给它们一些内容；否则就要准备 Relink。
草稿在磁盘上还没有文件，访达和 git 移不了它们。这些卡片只能在 BaseHalf 里移动。
连接 列出了识别能覆盖和不能覆盖的情况。一次比较乱的重构之后，运行 BaseHalf: Show Upstream Issues，再提交那些改过的列表。