scope_id。它决定这次请求读写哪一组数据。
把 设错，最常见的结果不是报错，而是明明写过却查不到。更糟的情况是两个本应隔离的项目用了同一个 Scope。
Scope 解析应是应用决策，而不是随手使用的后备值。多租户服务要先通过认证与授权确定允许访问的租户和项目，再把对应的 scope_id 交给适配器。
Scope 隔离什么
同一个scope_id 下，PowerContext 维护一组相互关联的状态。这里有 Source 日志和处理游标，有 Memory 生命周期与启用状态搜索投影，有 Experience 和 Skill 的 Candidate 收件箱，有 Handoff 历史内容与工作连续性，也有 Scope 内部运行时缓存、锁和统计。
另一个 Scope 看不到这些数据，除非应用把同样的内容再次写入。
Scope 不做什么
Scope 不是安全身份。 知道scope_id="project:payments" 不代表调用者属于 payments 团队，也不代表它可以调用写工具。Bearer 令牌、Server 部署边界和宿主权限准入规则负责访问控制。
Scope 也不会授予执行权限。召回结果即使来自正确 Scope，仍然是历史证据。Agent 必须遵守当前系统或用户指令，并检查实时工作区。
选择稳定的 Scope
一个好 Scope 应该随着工作持续存在，而不是随着会话变化。
Scope 字符串区分大小写。
project:PowerContext 和 project:powercontext 是两个 Scope。
没有统一的自动推导顺序
各集成会根据宿主能提供的信息推导 Scope，但策略并不相同。
心智模型只给选择原则。具体优先顺序放在对应适配器页面。不要把某个适配器的后备路径复制到所有宿主。
Git 远程会先规范化
推导 Scope 时，集成会去掉远程 URL 中的凭证。下面两个地址不应该形成两个项目，也不应该把令牌写进 Scope。跨宿主共享
Codex 和 Claude Code 可以对同一仓库推导出相同项目 Scope。这样，一边显式保存的 Memory 可以在另一边召回。 共享成立需要三个条件同时满足。两个宿主连接同一个 PowerContext Server。两边最终得到完全相同的scope_id。读写使用同一套访问授权。
只满足“目录看起来一样”还不够。排查共享问题时，先打印或检查最终 Scope，再看 Memory 搜索。
OpenClaw 的项目模式当前仍把 agent ID 放进 Scope。相同项目、不同 agent 不会自动共享一个纯项目 Scope。
Server 内的 ScopeCache
Server 为活跃 Scope 缓存运行时组合和一把 Scope 内部写入锁。默认容量是 128 个停用状态条目。 这不是数据缓存。淘汰不会删除数据库中的 Source、Memory 或 Handoff。正在使用或等待同一 Scope 锁的条目不会被驱逐。如果所有条目都处于启用状态，缓存可以暂时超过容量。操作完成后，Server 再清理最久未使用的停用状态条目。 同一 Scope 的写操作需要串行化，以保护头版本和游标更新。只读搜索和已经开始的 rerank 不应全部被这把写锁串行。常见故障
写入成功，但 Dashboard 看不到
检查 Dashboard 和客户端使用的 Scope 是否逐字相同。切换数据库 URL 也会让你看到另一套数据，这和 Scope 问题表现相似。逐步对照见用 Dashboard 核对 Scope 统计。两个租户看到了同一条 Memory
确认应用没有把服务进程 cwd 或固定字符串当成所有租户的 Scope。Scope 必须来自已经授权的租户或项目映射。LangGraph 在本地目录报 MissingScope
LangGraph 不会在缺少网络 Git 远程时自动回退到本地路径哈希。为这次调用提供PowerContextScope(scope_id=...)。
每次新会话都像第一次使用
通常是把会话 ID 当成 Scope。改用稳定项目或租户 Scope。怎么知道分清了
- Scope 稳定，并且不包含凭证。
- 多租户应用先授权，再选择 Scope。
- 需要共享的宿主得到完全相同的值。
- 不要假设所有适配器都有相同后备路径。
- 缓存淘汰不是持久数据删除。
下一步
再看失败时谁能继续
自动找回失败时，手头工作还应继续。你明确要求写入时，失败必须看得见。
对上最像的那条故障
搜不到、页面是空的，或诊断过了还是不行？先对照已经出现过的情况。