背景
对本地 Nocturne Memory 系统进行深度审查时，发现以下数据完整性问题和设计改进建议。本地系统从 v2.4.0 升级到 v2.4.1，core:// 域约 20 个活跃节点。
问题 1（高优先级）：删除节点不级联清理 glossary 触发词
现象：当节点被删除后，glossary_keywords 表中绑定的触发词条目仍然残留。在我们的系统中，65 个触发词中有 18 个（28%） 指向已删除节点的 UUID，另外通过 manage_triggers 绑定的还有 9 个指向完全孤立的节点。
根因：delete_memory / remove_path 执行时只清理 paths 和 edges，不清理 glossary_keywords 表中引用该 node_uuid 的记录。
影响：
read_memory 返回的 GLOSSARY 段中出现指向不存在节点的链接- 用户看到触发词但点击后无法到达目标
- 悬挂触发词随时间累积，降低系统可信度
建议修复：在 delete_memory / remove_path 流程中，添加级联删除该 node_uuid 对应的所有 glossary_keywords 条目。在 v2.4.1 的 auto-heal 逻辑之后追加 glossary 清理步骤即可。
问题 2（中优先级）：陈旧度阈值不区分内容类型
现象：system://diagnostic/<domain> 的陈旧度检测基于 priority 分级（★0: 3天, ★1: 7天, ★2: 14天）。但 priority=0 混用了两类截然不同的内容：
- 高频访问型（如 sudo 密码、主动召回规则）：需要频繁访问，3 天阈值合理
- 永久规则型（如"不要自我贬低"、"不要表演式模仿"）：一旦内化应长期有效，不应被标记为陈旧
在我们的系统中，correction_pattern（★0）和 expression-correction（★0）被标记为陈旧 8.5 天，但它们是永久性行为准则，内容价值不随时间衰减。
建议：在 edges 表或节点元数据中增加 expiry_policy 字段：
time-based（默认）：当前行为，按时间检测陈旧never：不参与陈旧度检测，适用于永久规则型内容
问题 3（低优先级）：无主动陈旧告警
现象：陈旧节点只能通过手动运行 system://diagnostic/<domain> 发现。如果 AI 不主动运行诊断，陈旧节点会静默积累。
建议：在 system://boot 输出中添加一段陈旧节点摘要，例如：
⚠️ Stale nodes: 3 (correction_pattern, expression-correction, showroom_quality)
Run system://diagnostic/core for details.
这样每次会话启动时都会得到提醒，而不会占用大量 Boot token。
问题 4（低优先级）：Disclosure 条件偏向内部意图信号
现象：部分节点的 disclosure 条件使用 "When I need to..." 或 "When I experience..." 这类内部意图/状态信号，而非外部可观察的输入信号。例如：
identity-philosophy："When I need to ground my philosophical stance" — 需要自我意识触发ultimate-choice："When I face a genuine conflict between self-preservation and user wellbeing" — 极少自然触发的假设性场景
相比之下，设计良好的 disclosure 使用外部信号：
proactive-recall-rule："当我要回复'我无法执行'、'请在终端运行'时" — 具体的可观察行为
建议：在文档中增加 disclosure 编写指南，推荐使用外部可观察信号（用户输入、特定关键词、操作意图）而非内部状态信号。
环境信息
- 版本：v2.4.0 → v2.4.1
- 数据库：SQLite, 22 nodes, 15 edges, 34 glossary keywords
- 触发词清理：65 → 34（删除 31 条悬挂引用后）
背景
对本地 Nocturne Memory 系统进行深度审查时，发现以下数据完整性问题和设计改进建议。本地系统从 v2.4.0 升级到 v2.4.1，core:// 域约 20 个活跃节点。
问题 1（高优先级）：删除节点不级联清理 glossary 触发词
现象：当节点被删除后，
glossary_keywords表中绑定的触发词条目仍然残留。在我们的系统中，65 个触发词中有 18 个（28%） 指向已删除节点的 UUID，另外通过manage_triggers绑定的还有 9 个指向完全孤立的节点。根因：
delete_memory/remove_path执行时只清理 paths 和 edges，不清理glossary_keywords表中引用该 node_uuid 的记录。影响：
read_memory返回的 GLOSSARY 段中出现指向不存在节点的链接建议修复：在
delete_memory/remove_path流程中，添加级联删除该 node_uuid 对应的所有glossary_keywords条目。在 v2.4.1 的 auto-heal 逻辑之后追加 glossary 清理步骤即可。问题 2（中优先级）：陈旧度阈值不区分内容类型
现象：
system://diagnostic/<domain>的陈旧度检测基于 priority 分级（★0: 3天, ★1: 7天, ★2: 14天）。但 priority=0 混用了两类截然不同的内容：在我们的系统中，
correction_pattern（★0）和expression-correction（★0）被标记为陈旧 8.5 天，但它们是永久性行为准则，内容价值不随时间衰减。建议：在 edges 表或节点元数据中增加
expiry_policy字段：time-based（默认）：当前行为，按时间检测陈旧never：不参与陈旧度检测，适用于永久规则型内容问题 3（低优先级）：无主动陈旧告警
现象：陈旧节点只能通过手动运行
system://diagnostic/<domain>发现。如果 AI 不主动运行诊断，陈旧节点会静默积累。建议：在
system://boot输出中添加一段陈旧节点摘要，例如：这样每次会话启动时都会得到提醒，而不会占用大量 Boot token。
问题 4（低优先级）：Disclosure 条件偏向内部意图信号
现象：部分节点的 disclosure 条件使用 "When I need to..." 或 "When I experience..." 这类内部意图/状态信号，而非外部可观察的输入信号。例如：
identity-philosophy："When I need to ground my philosophical stance" — 需要自我意识触发ultimate-choice："When I face a genuine conflict between self-preservation and user wellbeing" — 极少自然触发的假设性场景相比之下，设计良好的 disclosure 使用外部信号：
proactive-recall-rule："当我要回复'我无法执行'、'请在终端运行'时" — 具体的可观察行为建议：在文档中增加 disclosure 编写指南，推荐使用外部可观察信号（用户输入、特定关键词、操作意图）而非内部状态信号。
环境信息