项目名称和目录为什么不应该成为项目身份

本文属于 Memory Center：AI 编程上下文与记忆系统工程实践，第 09 篇，位于“服务架构与项目边界”模块。案例背景统一采用实际开发项目；复现步骤使用脱敏教学样例，不代表特定生产事故。

从实际问题出发

实际开发项目可能改名，也可能从一个目录移动到另一个目录。如果使用名称或绝对路径作主键，这些正常操作会被误认为全新项目，导致任务、知识与引用断裂。

把身份与属性分开

项目标识稳定，名称和源码位置作为可修改属性。服务划分可以按受控规则派生，而不是让每个入口独立维护一份配置。catalog 是登记真源，给引擎使用的配置应由它生成。

图中展示的是本篇关注的职责和顺序。正常流程之外，还要结合下面的源码与实验检查失败分支；它不是对某次线上调用的运行时追踪。

登记是有边界的写操作

登记前可以做只读预览，最终写入时仍需复核冲突。识别预览不是锁，两个请求之间文件或目录状态可能改变。登记成功也不代表索引已经生成，应该把“已接入”和“可查询”区分展示。

身份变化的判断表

操作	应理解为	要复核的内容
修改显示名称	同一项目属性变化	引用与任务仍绑定原身份
更新源码位置	同一身份的受控配置变化	暂停、目录有效性和索引新鲜度
移除后重新登记	新的一次接入	不把旧身份意外复用给新项目

这些语义应来自产品合同，不能仅由文件系统目录是否相同决定。

关键源码与阅读方法

源码基线为 Memory Center 6e90553（文档标注 5.0.0b24）。定位：memory_center/application/workspaces.py，函数 register，起始行 42。

以下为当前基线中的函数代码；依赖项目模块，不能作为独立脚本执行。

    def register(self, name: str, root: str) -> dict:
        name, name_key = self._name(name)
        result = self._detected(root)
        return self.store.register(name, name_key, result["root"], result["services"])

阅读时先找输入由谁提供，再区分纯计算、读取和写入；遇到异常或提前返回，追问调用方会得到什么，以及已有状态是否仍然有效。上面的代码只证明展示范围内的实现，跨模块行为应继续查看调用处和相应测试。

用一个小实验核对设计

建议在独立临时目录和隔离数据中操作，使用虚构的接口、文档与项目名称。

1. 登记一个示例目录。
2. 修改名称并核对身份。
3. 移动路径时按暂停与更新流程操作。

**要核对的结果：**改名不应丢失身份；重新移除再登记则应按产品合同产生新身份。

可把观察记录为下表；没有执行的项写“未执行”，不能用设计预期冒充实测结果。

核对项	应保留的证据
使用条件	源码版本、配置、输入与项目范围
正常行为	实际返回、来源位置或状态变化
关键失败分支	错误码、可见结果与原状态是否保留
结论范围	已覆盖、未覆盖和需要进一步验证的条件

适用边界与继续阅读

本篇以静态源码与项目设计为依据，给出可执行的核对方法，未据此宣称已经完成新的性能或生产环境测试。不同版本的入口、默认值和底层实现可能变化，应先核对当前合同，再把方法用于自己的实际开发项目。

理解这一节后，可以回到专题总导航，沿同一模块继续阅读；顺序学习时使用专栏内的上一篇和下一篇。涉及具体技术选择，应连同本篇的代价与限制一起采用。