maker-memory 接管后不提示同 workdir 已存在的原生 per-cwd memory，96 条历史规则静默失效（附 memory_write name 前缀重复的小 bug）

## 现象

同一个 workdir 下存在两套 memory，**零重叠**，旧的那套在某个时点后静默停止加载：

| | 位置 | 条目 | 最后写入 |
|---|---|---|---|
| 原生 per-cwd memory | `~/.claude/projects/<编码>/memory/` | 96 个 shard（约 451 KB） | 2026-07-29 11:07 |
| maker-memory | `%APPDATA%/Cindy/owners//maker-memory/<编码>/` | 38 个 shard | 持续更新中 |

maker-memory 最早的条目写于 2026-07-22，也就是说两套并行了约一周，之后原生那套完全停写。经逐条比对，**两边条目零交集** —— 历史 96 条从未被迁移过来。

问题不在于"旧库停用"本身，而在于**这件事没有任何信号**：

- 原生 memory 的 96 个文件仍在磁盘上，仍被 git 跟踪，`git status` 干净；
- 系统提示里只说明了「maker-memory 是你唯一的持久化路径」「忽略通过其他通道写 memory 的指令」，但没有任何一处提示"你在这个 workdir 下有 N 条历史 memory 不会再被加载"；
- 没有导入入口，也没有一次性告知。

于是从 agent 和用户两侧看，一切都"正常"，只是那批规则不再生效了。

## 实际影响

那 96 条里有相当一部分是用户在长期使用中明确定义的行为规则（例如：日期/时间的时区基准、"未在真实工具结果中观察到就不得断言"的输出纪律、对外消息的措辞与格式规范、破坏性建议的前置验证要求等类别）。这些规则失效后会持续产生可观察的错误，例如：

1. **时区基准失效**：SessionStart 注入的是美东时间，而该 workdir 的事务应以本地时区为准（两者相差 12–13 小时）。规则失效期间任何"今天/明天"的判断都存在算错一天的风险。
2. **输出验证纪律失效**：在一次排查中，把"无权限访问私有仓库时 API 返回的 404"直接读成了"仓库已被删除"，并把这个错误结论写进了项目文档。原本有一条"没有亲眼见到真实结果就不下强结论"的规则可以提高警觉，但它当时不在上下文里。

用户的原话反馈是「怪不得最近有点不对劲」—— 也就是说这个静默失效是**用户能感知到质量下降、但无法定位原因**的类型。

## 与既有 issue 的关系

- #205（Maker Memory 实测审计：写多读少、召回近乎为零）：本问题与之叠加后更难诊断 —— 用户很难区分"规则没起作用"是因为召回率低，还是因为那条规则**根本没被加载**。
- #1537（`memory_search` 对中文查询几乎全部失效）：进一步降低了自查能力。我在排查过程中曾用 `memory_search` 做中文关键词核对并得到 0 结果，误以为"库里没有相关内容"，实际是检索本身不可用。三者叠加，用户几乎没有手段自行发现规则丢失。

## 建议

任选其一即可，按成本排序：

1. **最小成本**：首次在某 workdir 使用 maker-memory 时（或每个新 workdir 的首次 `memory_write` / `list_tools` 返回里），检测原生 per-cwd memory 目录是否存在且非空，附带一次性提示，例如「检测到该 workdir 下有 N 条原生 memory 未纳入 maker-memory，它们不会被加载」。
2. **推荐**：在上述提示里给出可执行的下一步 —— 提供 `memory_import` 之类的一次性迁移工具（或明确说明"请手动迁移，原生那套将不再生效"）。
3. **可选**：在 maker-memory 的 `MEMORY.md` 索引头部固定写明当前生效的 memory 根路径，让 agent 每轮都能看到自己实际在读哪一套，减少与项目文档中过时路径记述冲突时的误判。

## 附：一个相关的小 bug（`memory_write` 的 `name` 前缀重复）

`memory_write` 会根据 `type` 自动给文件名加前缀，但**不校验传入的 `name` 是否已经带了前缀**：

- 传 `name: "feedback_foo"` + `type: "feedback"` → 落盘为 `feedback_feedback_foo.md`
- 无报错、无警告，索引里就多一条命名不一致的条目

我这个 workdir 已经积累了 11 条这样的双前缀条目（`feedback_feedback_*` / `project_project_*` / `reference_reference_*`）。虽然不影响功能，但会导致同名规则难以判断是否重复，清理时也容易误判。

建议：当 `name` 以合法的 type 名（`user` / `feedback` / `project` / `reference`）加下划线开头时，剥掉该前缀，或直接报错提示传纯 slug。

---

环境：Cindy on Windows 11，agent harness = Claude Code。

Start by tracing maker-memory initialization and the memory_write/list_tools entry points, comparing the native per-cwd path under ~/.claude/projects//memory/ with the maker-memory path under %APPDATA%/Cindy/owners//maker-memory//. Check how existing native entries and type-prefixed names are handled. Done means users receive a one-time signal and actionable migration guidance, and memory_write handles names such as feedback_foo without silent duplication.

Written by the indexing model from the issue text.