SessionUserAFS 把调用者专用与临时 provider 叠在共享的 per-instance 世界上。它故意不是一个包含所有用户数据的目录。
构造在运行时是单点的（buildSessionView / daemon join 路径）。不要发明第二条构造路径去挂载另一个调用者的 /user。
视图合同
| 视图 | 当前已测行为 |
|---|---|
/user | 解析到当前已认证调用者的 user provider。没有该 provider 时，/user 不存在；写入被拒绝。 |
/tmp | 解析到为当前 session 创建的 provider。每个已 join 的 session 都有。 |
/space | 可选。当运行时为 scope:user 启用时，已认证调用者可在此看到自己的整个 DID Space 根。匿名调用者不会得到替代的 /space。 |
根叠加是一等的：可通过 list("/") 枚举，可 stat，并按各叠加策略路由读/写/删/exec。
隔离（测试钉住的部分）
Daemon 测试钉住了 todo 风格路径上的双用户隔离：
- 调用者 A 与 B 各自写入并读回自己的
/user/app/x。 - 试图经
/blocklets/<name>/users/<other-did>/…等 host 布局，或/user下的穿越变体访问另一用户的路径，会在该 session 中被拒绝。 - 隔离是结构性的，因为 session 只为已解析调用者挂载单数
/user。
这是 session 视图边界，不是「每个 Blocklet 的任意路径都有同一 ACL」的承诺。
写入与 base 数据门控
落到共享 base 的网络源写入与删除会被拒绝。针对允许叠加（例如当前调用者的 /user provider）的写入，由该叠加的策略评估。内部代码与网络请求不是可互换上下文。
对 /space 特别说明：
- 在当前 user-scope daemon 覆盖中，投影为 readonly 时，
/space下的一般写入会被拒绝。 - 当运行时接入固定 write-guard 时，可仅在
blocklets/<app>/user/collections/**以及规范 provenance siblingblocklets/<app>/user/.provenance/collections/**下允许写入。在这些根之外，不要假定可写。 - 需要 collections 写通道的消费者应检查已发布的 collections + provenance 能力标记，而不是只凭路径形状推断。
不要
- 把
/user别名、隐藏组件或客户端路由当作访问控制机制。 - 在 session 内枚举其他用户的数据并称之为受支持 API。
- 把
~/.afs/spaces或隔离--root-path下的物理存储，与 session 路径/user、/space当成同一件事。CLI 检查看到的是逻辑 space 片段；session 视图是另一种组合。
证据
| 主张 | 证据 |
|---|---|
/user、/tmp、/space 叠加设计 | packages/aos/src/session/session-user-afs.ts |
双用户 /user 隔离 | runtimes/node/test/daemon/two-user-space-isolation.test.ts |
scope:user 的 /space 叠加（自己的根、跨调用者拒绝） | runtimes/node/test/daemon/scope-user-space-overlay.test.ts |
| 网络 base 写入门控 | packages/aos/test/session/session-user-afs-base-write-gate.test.ts |
/space collections 写守卫策略 | packages/aos/src/session/space-write-gate.ts |
继续阅读 检查本地空间，用离线 CLI 检查同一逻辑片段，但不要把 CLI 当成 session。