# 本地 private table SQL 权限修复

场景：
- 后台或 api-server 通过 SpacetimeDB HTTP SQL 读取 `tracking_event` 这类 private table。
- 本地清库、重建 standalone 或重新发布模块后，原 CLI token 失效，SQL 可能报 `no such table ... If the table exists, it may be marked private`。

操作步骤：

1. 清空本地 SpacetimeDB 数据目录
   - 使用项目脚本停止本地实例后，备份或删除 `server-rs/.spacetimedb/local/data`。
   - 只清本地开发环境，不要误伤远端或其他 worktree。

2. 启动本地 standalone
   - 用项目约定的 `scripts/dev-rust-stack.sh` 或等价命令启动 `spacetime`。
   - 确认 `/v1/ping` 可访问后再取 identity。

3. 通过 `/v1/identity` 获取新 token 和 identity
   - 使用 `POST http://127.0.0.1:3101/v1/identity`
   - 只记录 identity，不要在日志中打印 token 明文。

4. 用新 token 登录 CLI
   - 运行：`spacetime login --token <token>`
   - 这会把 token 写到本地 CLI 配置，后续 HTTP SQL 可读 private table。

5. 重新验证 SQL
   - 使用带 token 的 `POST /v1/database/<db>/sql`
   - 先尝试 `SELECT ... FROM tracking_event LIMIT 1`
   - 若成功，再让 api-server 走同样 token。

6. 如果 api-server 需要复用 token
   - 优先读取项目内本地 CLI 配置中的 token，而不是硬编码或回填到 `.env`。
   - 输出日志时统一 `[REDACTED]`。

排查要点：
- `ORDER BY` 和 private table 是两个独立问题，先分开修。
- 清库后旧 token 很可能不再能看见 private table，不代表表不存在。
- 若 `/v1/identity` 返回的 token 没权限，再检查当前 standalone 是否就是刚启动的本地实例、database 名是否一致、模块是否已重新发布。