migrate-mem

迁移记忆

意图

帮助已经开发完成的项目建立清晰、可信的记忆基础。重点是理解项目并初始化实用的 StrictDoc 文档，而不是迁移旧文件或转换每一份资料。

请自行判断调查深度、文档结构、存储内容的重叠情况，以及哪些问题需要用户提供信息。没有固定的清单、强制的分类报告，也不需要为每次初始化都举行审批流程。

了解项目现状

• 查看项目说明、README、主要模块、入口点、配置、现有文档和相关开发历史。根据证据深入了解项目目的、架构、惯例、当前状态和未完成的工作。
• 现有的 Magic Context 记忆和 claude-mem 观察记录，可能有助于还原代码中未体现的决策或经验。即使没有这些记录，也不妨碍初始化 StrictDoc。
• 在上下文中阅读有用的来源，不要想当然地认定笔记名称、计划目录或较早采用的开发方法。与关键代码和决策相比，生成的输出和详尽的记录通常不需要投入同等精力。
• 区分预期策略、观察到的实现、过往经验和未解决的问题。较新的证据可能表明情况已有变化，但不应因此自动认定当前规则应该是什么。

建立实用的记忆基础

配套的 save-mem 技能介绍了记忆维护和 StrictDoc 机制。其 assets/docs-skeleton/ 是一个起点，可通过技能注册表或同级目录 ../save-mem/ 找到，并非固定的主目录路径。

常见位置	有用内容
docs/project_memory/decisions.sdoc	当前规则和决策、适用范围及理由，以及已废弃的前序规则
docs/project_memory/journal.sdoc	带日期的项目基线、重要经验、进展和未解决的问题
docs/handbook/	值得维护的参考资料：架构、用法、规范或运维指南
docs/strictdoc_config.py	StrictDoc 项目配置

• 根据现有情况调整此布局。缺少文档或骨架文件是常见的起点；已有的 docs 目录并不意味着可以覆盖其内容。
• 提炼足够的知识，让人能够理解项目。优先建立精简实用的基线，而不是为每个模块或每项过往操作都创建一份文档。
• 让当前的 StrictDoc 规范成为事实依据，并与历史日志条目和报告区分开来。随着项目演进，Active、Proposed、Deprecated 和 Superseded 等状态有助于保持这种区分。
• 如果来源相互冲突，或预期规则不明确，请指出关键问题。不要编造理由，也不要将推断出的策略说成已确认的内容。如果已确定的决策确实发生变化，应维护当前规范并简要告知用户，而不是等到用户单独发出文档命令；日常记忆维护和说明性清理则可以更灵活地处理。
• 同一事实或决策也可以存储在 Magic Context 中。应选择有助于信息召回和可靠性的重叠方式；目标既不是每条事实只存一处，也不是所有内容都完全镜像。

在提升可读性的同时保留项目内容

• 保留现有源材料和实用文档。优先添加或整合内容，而不是自动迁移、归档、删除或重新排版所有内容；涉及重大结构调整时，应与用户讨论。
• 后续运行时，应基于现有节点和引用继续完善，而不是重新创建基线。遵循项目的历史保留和版本控制惯例。
• 起草或修订文本前，先加载 readable-docs，了解项目通用的写作风格：使用简洁的短语、列表和紧凑的表格，同时不遗漏事实或条件。此风格也适用于记忆和 docs/ 之外的内容。
• 在适当时，将结论关联到源文件、提交记录或记忆引用。原始文档可作为佐证保留，无需逐字复制到新手册中。
• AGENTS.md 中的启动和保存指南有助于未来的 Agent 找到记忆。必要时，使其与约定的意图保持一致，同时保留项目中无关的说明。

在实际项目中检查结果

• 使用可用的 StrictDoc 安装或项目环境。修改前检查现有配置和语法，避免假定特定版本、环境管理器或插件已安装。
• 从文档根目录运行 strictdoc export .，验证 .sdoc 和配置变更，并检查足够多的导出内容，确认列表、表格和注释易于阅读。
• 考虑新读者能否分辨哪些内容当前适用、适用原因、以往发生过什么，以及哪些事项仍不确定。导出成功本身并不能证明内容正确。
• 简要报告建立的有用记忆、未解决的问题和实际验证状态。缺少集成或未经验证的运行时声明，可以明确作为待补缺口，而不必虚构已完成的内容。