feat(memory): use stable workspace identities

[YayoiNanoka]

Summary

This is PR ③-A of the long-term-memory work tracked by #1615.

Background

PR ① introduced the SQLite-backed atomic memory_item store, and PR ②-A / PR ②-B added explicit and Compaction-triggered extraction. Workspace-scoped Items already use scopeType = workspace, but the extraction path previously filled scopeKey from SessionHeader.workspaceRoot, which is a filesystem path.

A path describes where a Workspace is currently mounted; it is not the Workspace's durable identity. Renaming or relocating a Workspace can split one project's memories across different Scope keys, while reusing an old path can associate that string with a different Workspace. This becomes a correctness and isolation problem before PR ③ adds Group and Summary projections: Group membership, Summary visibility, projection cursors, and later recall all need one stable Scope key.

Maka already has an intrinsic Workspace marker containing a UUID and exposes it as workspace:v1:<uuid>. PR ③-A makes that existing identity the only valid Workspace Scope for long-term memory.

What this PR does

• adds a shared Core Workspace identity contract and runtime validation for the canonical lowercase form workspace:v1:<uuid>
• reuses the existing Workspace marker resolver instead of creating a second memory-specific identity system
• resolves the identity in Runtime Host only for eligible root-session memory extraction, then passes it explicitly through AiSdkBackend and every extraction snapshot
• writes explicit memory_remember, explicit memory_extract, and automatic Compaction extraction results with the stable Workspace identity as scopeKey
• rejects filesystem paths and other non-canonical values for new Workspace-scoped Item writes and scoped key searches
• leaves global Items and global search behavior unchanged
• treats long-term memory as optional when identity resolution fails: extraction is disabled for that backend, and the Runtime never falls back to a path
• keeps existing path-scoped rows isolated instead of guessing an unsafe path-to-UUID migration; they are not returned by normal canonical Workspace searches

Scope

This intentionally does not add Group, Summary, recall, or new SQLite tables. Those remain separate PR ③ slices.

Refs #1615

Verification

• npx biome check on all 14 changed files
• Core, Storage, Runtime, and Runtime Host builds
• Core, Storage, Runtime, and Runtime Host typechecks
• Core Workspace identity test: 1 passed
• Storage Workspace identity and long-term-memory suites: 58 passed
• Runtime ai-sdk-backend suite: 195 passed
• Runtime Host memory coordinator and execution composition suites: 53 passed
• git diff --check

Review focus

• Workspace scope is now canonical and lowercase.
• Runtime Host resolves the identity only for eligible root-session memory extraction.
• Legacy path-scoped data is not automatically rebound to a UUID.

点击展开中文

概述

这是 Issue #1615 长期记忆功能的 PR ③-A。

背景

PR ①实现了基于 SQLite 的原子 memory_item 存储，PR ②-A 和 PR ②-B 分别加入了显式提取与 Compaction 自动提取。Workspace Item 已经使用 scopeType = workspace，但此前提取流程会直接把 SessionHeader.workspaceRoot，也就是文件系统路径，写入 scopeKey。

路径只能表示 Workspace 当前位于哪里，不能作为 Workspace 的长期身份。Workspace 被重命名或移动后，同一个项目的记忆可能被拆到不同 Scope；旧路径被另一个 Workspace 复用时，同一个路径字符串也可能指向不同项目。PR ③后续的 Group、Summary、投影 Cursor 和召回都依赖准确的 Scope 隔离，因此必须先解决这个基础问题。

Maka 已经通过 Workspace Marker 保存 UUID，并使用 workspace:v1:<uuid> 表示稳定 Workspace Identity。PR ③-A 复用这套已有能力，将其收紧为长期记忆中唯一合法的 Workspace Scope。

本 PR 做了什么

• 在 Core 中增加共享 Workspace Identity 契约，并校验唯一的小写规范格式 workspace:v1:<uuid>
• 直接复用现有 Workspace Marker Resolver，不再为长期记忆创建第二套身份系统
• Runtime Host 只为符合条件的 root Session 长期记忆提取解析 Identity，并显式传递到 AiSdkBackend 和每个 Extraction Snapshot
• memory_remember、显式 memory_extract 和 Compaction 自动提取统一使用稳定 Workspace Identity 写入 scopeKey
• 新增 Workspace Item 和按 Workspace 执行 Key Search 时，拒绝路径及其他非规范 Scope 值
• Global Item 和 Global Search 的既有行为保持不变
• 无法解析稳定 Identity 时，将长期记忆提取作为可选能力安全关闭；Runtime 绝不回退到路径
• 历史 path-scoped 数据继续隔离，不猜测路径与 UUID 的对应关系，也不进入正常的规范 Workspace Search

范围

本 PR 不增加 Group、Summary、召回或新的 SQLite 表，这些内容由后续 PR ③切片完成。

验证

• 对全部 14 个变更文件执行 npx biome check
• Core、Storage、Runtime、Runtime Host 构建通过
• Core、Storage、Runtime、Runtime Host 类型检查通过
• Core Workspace Identity 测试：1 项通过
• Storage Workspace Identity 与长期记忆测试：58 项通过
• Runtime ai-sdk-backend 测试：195 项通过
• Runtime Host Memory Coordinator 与 Execution Composition 测试：53 项通过
• git diff --check 通过

Review 重点

• Workspace Scope 现在只有一种小写规范表示。
• Runtime Host 只为符合条件的 root Session 长期记忆提取解析 Workspace Identity。
• 历史 path-scoped 数据不会被自动绑定到某个 UUID。

[sunheyi6]

Hi @YayoiNanoka, a quick status check on this PR and the PR ③-A work tracked by #1615.

This PR has remained in Draft since August 14. I can see that the branch was refreshed on August 26, but there are no reviews or discussion yet. Are you planning to continue working on this slice?

If it is still actively in progress, no problem — it would be helpful to know what remains or whether any review/help would be useful. If it is paused or you no longer plan to continue, would you be open to another contributor helping or taking over after coordinating with you?

This is only to clarify ownership and next steps for #1615, not to rush you. Thanks!

中文说明

Hi @YayoiNanoka，想确认一下这个 PR 以及 #1615 中 PR ③-A 工作的当前状态。

这个 PR 从 8 月 14 日开始一直处于 Draft 状态。我看到分支在 8 月 26 日更新过，但目前还没有 Review 或相关讨论。请问你是否还计划继续完成这个切片？

如果仍在正常推进，完全没问题；如果能说明一下目前还剩哪些工作，或者是否需要 Review、测试或其他协助，会很有帮助。如果这项工作暂时搁置，或者你不再计划继续，是否愿意在沟通好边界后由其他贡献者协助或接手？

这里只是希望明确 #1615 后续工作的负责人和下一步安排，并不是催促。谢谢！

[YayoiNanoka]

Hi @YayoiNanoka, a quick status check on this PR and the PR ③-A work tracked by #1615.嗨，顺便快速了解一下这个补丁的情况，以及由 #1615 负责跟踪的 PR ③-A 项目的最新进展。

This PR has remained in Draft since August 14. I can see that the branch was refreshed on August 26, but there are no reviews or discussion yet. Are you planning to continue working on this slice?这个版本自 8 月 14 日以来一直停留在草稿阶段。我看到该分支在 8 月 26 日已经更新了，但目前还没有相关的评审或讨论。你打算继续维护这个版本吗？

If it is still actively in progress, no problem — it would be helpful to know what remains or whether any review/help would be useful. If it is paused or you no longer plan to continue, would you be open to another contributor helping or taking over after coordinating with you?如果项目仍然在继续推进中，那没问题——了解目前还剩下什么，或者是否需要进一步的帮助，都是很有意义的。如果项目已经暂停了，或者你不再打算继续下去，那么你是否愿意在与相关人员协调后，让其他开发者来继续这项工作呢？

This is only to clarify ownership and next steps for #1615, not to rush you. Thanks!这只是为了明确 #1615 的所有权归属及相关后续步骤，并不是要催促你们。谢谢！

中文说明

Thanks for checking in.

We discussed the direction again, and the decision is to keep the memory work paused until the plugin system is ready. Once that foundation is available, we plan to revisit memory as a plugin rather than continue the current built-in implementation.

Because the implementation boundary is expected to change, there is no need for another contributor to take over this PR at the moment. I’ll update the PR status accordingly when the follow-up direction is settled.

Thanks again for helping clarify the next steps.

中文说明

感谢询问。

我们重新讨论了目前的方向，决定仍然先暂停 memory 相关工作，等待插件系统完成。届时会将 memory 作为插件重新推进，而不是继续当前的内置实现方案。

由于后续的实现边界预计会发生变化，目前不需要其他贡献者接手这个 PR。等后续方向确定后，我会相应更新这个 PR 的状态。

再次感谢你帮助确认后续安排。