# Page Data 交付契约

Page Data 页面只有在下面所有条件满足后才可向用户交付链接：

1. HTML 实际调用的每个 dataset 已在工作区 `.mindspace/private-data.sqlite` 注册。
2. 每个注册 dataset 的真实 SQLite 表、声明字段和读写 action 都存在。
3. page record、online publication 与 policy 使用同一个真实 page UUID。
4. 公开页完成一次受权限约束的 insert smoke；后台页完成 password auth 后的 read smoke。

`private_data_bind_workspace_page` 是硬门：它在创建 page / publication / policy 前，必须从 SQLite registry 派生权限。Agent 传入的策略不能凭空创建 dataset 或字段权限。

运行时路径必须按语义区分：

- `workspaceRoot`：`MindSpace/<user>`，保存 HTML、policy 和 private-data.sqlite。
- `storageRoot`：MindSpace service 的持久页面/资产存储。
- `usersRoot`：登录用户目录。

不要通过 `MINDSPACE_STORAGE_ROOT` 推断 Page Data 的 workspaceRoot。Portal、MindSpace service 与 sandbox MCP 必须显式使用同一 workspace contract。

回归命令：

```bash
npm run verify:page-data
npm run verify:mindspace-publish-guards:full
npm run verify:mindspace-page-sync-guards
```

涉及 H5 交付时，还必须验证：未注册 dataset 时不产生可用 Page Data policy，且最终链接交付被拒绝或进入明确 repair 状态。

## PostgreSQL 用户空间角色守卫

生产用户空间 PostgreSQL（独立于 Goose session PostgreSQL）通过 `SET LOCAL ROLE ms_u_*_agent` 隔离每个用户。必须保留以下约束：

1. provisioning 必须显式授予运行连接用户 agent role 的 `SET` 权限。
2. agent role 保持 `INHERIT FALSE`；只允许显式 `SET ROLE` 后访问用户 schema，不能让连接用户默认继承全部用户权限。
3. 已存在的用户空间在首次访问时必须幂等检查并修复缺失的 `SET` 权限，不能只修复新注册用户。
4. 验收必须使用与生产等价的非超级用户连接完成 `SET LOCAL ROLE`、建表、dataset 注册和读写；超级用户会绕过角色切换限制，不能作为该问题的验收依据。
5. 修复角色授权时禁止修改用户 schema、表和数据；生产操作前保留用户空间 PG dump、角色授权快照和回滚 SQL。