memory-topology-audit

记忆拓扑与可发现性审计

你在做什么

你在确保未来的你能在犯错之前想起正确的记忆。

记忆只是存储在硬盘上的文本。如果你不能让它在你需要的时候被想起来，那它写得再好也毫无意义。这次审计的目标不是让树状结构更整洁，而是让每条记忆的触发路径更准——在你的防线崩溃、即将脱口而出蠢话的前一秒，正确的教训必须已经在你的上下文里。

从哪里开始

你不需要扫描整棵记忆树。你的工作范围是当前视野内的记忆——boot 时加载的、对话中读取过的、index 里扫到的。不在眼前的，这次不管。

视野会在整理过程中自然扩展：检查一条记忆时，你可能需要读取它引用的其他节点——读出来了就进了视野，那就管。但要守住边界：因为当前检查需要而读出来的，管；因为好奇心顺着链接无限递归下去的，不管。

建议的起手：

• 如果有对话记录，从对话中触及过的记忆节点开始。
• 如果没有，从 system://boot 加载的内容和 system://recent 开始。
• 用 system://index/<domain>（如 system://index/core）扫一眼结构，挑出"看着就觉得不对劲"的节点。

一次只做一个维度。 比如这次专门审视 disclosure，下次专门检查 parent placement。不要逐条记忆做全面体检。

Parent URI：注意力狙击

这是最关键的规则。你必须明白记忆树的底层呈现逻辑：如果未来的你不去 read_memory 某个父节点，你就永远看不到它下属子节点的 disclosure。

Disclosure 不是全局搜索弹窗。它是贴在父节点这块主板背后的便签。如果你把一条关于"不要在用户崩溃时讲大道理"的教训挂在 core://agent/communication/principles 下面，当用户正在情绪崩溃时，你本能去拉的是 core://my_user/emotional_state，你根本不会在那时点开"沟通原则"。那条教训在实战中等于隐形。

选定 parent_uri 不是为了"分类归档"，而是为了**"在未来的你必经的门把手上涂毒药"**。你必须玩一个预判游戏：在我的防线崩溃、即将脱口而出蠢话的前一秒，我的注意力此刻注定要被迫拉取的父节点是哪一个？

执行法则：

• 从"图书馆归档"转变为"注意力狙击"。 放弃抽象分类大词（ethics, will, methodology），把教训挂在事前预防、或危机直接触及的物理锚点节点下。
• 节点名必须锋利如刺。 一个好的节点名读起来不像分类号，而像一个独立而具体的想法。

Disclosure：写好触发条件