不用改遍每篇笔记，也能修好坏掉的 upstream
删除或移动文件后，点名它的列表会故意保持坏掉。Relink、Relink Everywhere 和 Show Upstream Issues 能一步修好，且可撤销。
你把 notes/schema.md 改名为 notes/data-model.md。另外三篇笔记的 upstream 里还写着旧路径。那些条目变红。这是故意的。
目标路径消失时，BaseHalf 不会悄悄改写每一份列表。缺失的目标仍然是一个信号，直到你决定怎么处理。坏掉的条目会一直留着，直到 Relink、Relink Everywhere 或 Remove。命令面板里还有 BaseHalf: Show Upstream Issues，需要时可以把全部问题收进一处。
为什么坏条目要留着
Upstream 列表是纯文本：Markdown frontmatter 的 upstream:，或其他文件对应的 .bh/mirror/<path>/upstream.yaml。Agent 和工具也可以自己改这些列表。BaseHalf 以文件里写的为准。
如果每个过期路径都自动修好，你就很难发现漂移。本该是移动的删除，和打错的路径，在看起来之前是一样的。让坏条目保持可见，等于把运维步骤说清楚：改指针，或删掉它。
在 BaseHalf 里面 移动或重命名时，能认出来的会按内容识别更新条目。删除、在外面改名，以及手改过的路径，才会出现徽章警告。
Relink、Relink Everywhere、Remove
卡片徽章对 Upstream 报警时，打开它，按情况选动作。
| 动作 | 做什么 |
|---|---|
| Relink | 把这一条坏条目指到你选的文件 |
| Relink Everywhere | 在整个工作区找到同一条坏路径，一步全部改指向 |
| Remove | 从这份列表里丢掉这条坏条目 |
大批笔记还指着旧名字时，用 Relink Everywhere。只有这张卡错了，Relink 就够。这条路径不该再当这里的 upstream 时，用 Remove。
这些修复就是对列表的普通编辑。它们和画布上的其他操作一样，可以一步撤销，指错了也便宜。
图漂了之后的运维
这是结构搬家之后的维护步骤。把上下文放进 upstream 列表（而不是每次粘进 prompt）是设计本身。日常里文件会动，列表会滞后。Show Upstream Issues、Relink Everywhere 和 Remove 让图保持诚实，而不必手工打开每一篇笔记。
打开命令面板，跑 BaseHalf: Show Upstream Issues，清掉红路径，提交更新后的列表。下一次 Claude Code 或 Codex 会话读到的，就是修好的那些文件，和 git 看到的一样。