load-mem

加载记忆

意图

恢复足够的上下文，以便继续作为项目伙伴协作，而不必让用户重复之前的决定，也不必加载完整历史记录。根据判断决定要读取什么、调用哪些工具，以及调查到什么深度。

可用记忆

来源	提供的内容	常见访问方式
StrictDoc docs/	易于阅读的当前规范、决定及其依据、项目历史和维护中的参考文档	阅读相关 .sdoc 文件或其导出内容
Magic Context	已存储的事实、决定、经验教训、注入的记忆和可恢复的对话	注入的记忆、ctx_search、ctx_expand、ctx_memory、ctx_note
claude-mem	可搜索的活动记录、观察结果和历史上下文	claude_mem_search 或可用的 claude-mem MCP 工具
代码、配置和 git	已存在的内容以及实际发生的变更证据	相关文件、调用链和历史记录

相同的知识可能出现在多个来源中。这种重叠有助于回忆、获取和交叉核对；这些来源并非互斥的存储类别。

正确解读

• StrictDoc 是当前项目规范的事实来源。 当前已确认的规则优先于相冲突的数据库记忆。这是项目记录之间的权威约定，不代表可以覆盖实时指令。
• project_memory/decisions.sdoc 保存决定；journal.sdoc 保存带日期的经验和进展；handbook/ 保存参考资料。现有项目可能采用不同的组织方式。
• 在捆绑的决定语法中，Active 表示当前有效，Proposed 表示尚未解决，Deprecated 表示已弃用，Superseded 表示已被取代。相关时，请遵循替代引用。日志条目或历史报告不会仅仅因为位于 docs/ 中就成为当前政策。
• 区分预期规则、观察到的实现和过去发生的情况。近期的数据库命中或提交可能揭示偏差，但本身并不能决定应更改哪条规则。
• 当来源不一致时，结合范围、状态、证据和用户当前意图来理解差异。若存在影响重大的不确定性，应明确指出，而不是默默将猜测当作既定事实。
• 规范可以演变。如果确认发生了真正且已达成共识的决定变更，save-mem 可以维护该变更，并简要通知用户，无需等待单独的保存命令。仅有偏差或新的搜索结果还不够；加载上下文并不意味着每次都要修订规范。

实用指南

• 从任务和项目指令入手。相关决定、README 章节、入口点和近期进展，通常比穷尽式记忆转储更适合作为基础。
• 如果任务取决于项目自身的词汇或领域模型，应先找到这些术语已有的出处——项目手册，或项目使用的 CONTEXT.md——再自行命名。加载不等于更改：更改模型是 domain-modeling 的职责。
• 注入的 Magic Context 记忆已经可用。若缺少上下文，可使用 ctx_search，并以有用的名称或路径提出实际问题；如果需要精确措辞，ctx_expand 可以恢复原始对话。
• 如果早期活动或观察结果有所帮助，请使用 claude-mem。应先查明可用工具，而不要假定工作器端口或数据库架构。
• 对于大型文档树，先搜索，再结合周边上下文读取相关节点。通常，源 .sdoc 文件已足够；JSON 导出的结构可能因 StrictDoc 版本而异。
• 缺少某些层很常见。根据现有证据继续工作，并在信息缺口影响任务时予以说明。migrate-mem 可帮助建立缺失或不完整的记忆树；save-mem 可保存新知识或协调过时记录。
• 面向用户的回顾应聚焦于有用的当前上下文和未解决的问题，并使用用户的语言；默认使用中文。