supabase

Supabase

构建由迁移支持、类型明确且授权边界清晰的 Supabase 集成。

工作流

1. 检查 supabase/、迁移文件、生成的类型、已安装的 Supabase 软件包及版本、框架/运行时、环境变量名称（不要打印其值）、身份验证/会话流程、通过 Data API 暴露的架构，以及现有授权和 RLS。
2. 根据领域模型推断表的所有权和租户关系。只有当所有权、协作、删除、保留或外部身份验证行为不明确时才提问。不要机械地给每张表都添加 user_id 或四条 CRUD 策略。
3. 为每张表设计合适的键、外键、约束、索引、时间戳、生命周期/删除行为，以及由服务器生成的所有权默认值。除非有意建模本地身份映射，否则应将外部提供商的主体 ID 用作文本。
4. 创建具名迁移。本地更改使用 supabase migration new 或经过审查的 db diff，通过本地重置/测试数据库进行验证，检查 db push --dry-run，仅当明确涉及远程部署时才使用 db push。migration up 不能替代远程部署。
5. 同时通过 Postgres 授权和 RLS 保护每个暴露的对象。将策略限定到相应角色，使用带索引的谓词，为插入/更新添加 with check，分别审查视图/函数，并为 security definer 函数设置安全的 search_path。
6. 匹配身份验证策略：
   • Supabase Auth：使用 auth.uid()/auth.jwt()，并遵循当前 SSR 会话指南。
   • Clerk 或其他受支持的第三方提供商：配置原生集成，通过客户端传递提供商令牌，并使用实际的 JWT sub/声明。不要假设仅凭 RLS 表达式就配置了令牌验证。
   • 服务器端管理：使用专用的、仅供服务器使用的客户端并进行明确授权；绝不要暴露密钥/服务凭据。
7. 对于当前的 @supabase/ssr，每个请求都创建一个客户端，使用受支持的 Cookie getAll/setAll 适配器，等待异步框架 Cookie API，并添加所需的代理/中间件刷新流程。不要使用旧式的单 Cookie 适配器。
8. 将迁移应用到用于生成类型的目标后，再生成 TypeScript 类型，然后运行类型检查并更新类型化查询。避免使用 any，并明确处理 { data, error }。

验证

运行本地迁移重置/应用、架构/类型偏差检查，以及仓库的 lint/类型检查/测试/构建。针对每条策略，测试允许所有者/成员/管理员/服务的访问，以及拒绝匿名用户/其他用户/其他租户的读取和修改，包括尝试更改所有权的情况。在目标运行时测试会话刷新/过期以及外部提供商令牌。

输出

报告已更改的表/函数/存储、迁移文件、授权策略和 RLS 策略及其身份验证策略、客户端/会话更改、类型生成命令及结果、授权拒绝测试，以及尚需完成的关联项目/仪表板/生产环境步骤。