docs: clarify supabase frontend access strategy

docs/refactor/multitenant-auth-security-contract.md

@@ -2,7 +2,7 @@
 
 更新时间：2026-06-28
 
-这个系统后续要卖给同行作为题库 SaaS，因此租户隔离、鉴权、资源权限和审计是商用红线。前端可以先按迁移期接口联调，但正式上云验收前必须完成本文件的 P0 项。
+这个系统后续要卖给同行作为题库 SaaS，因此租户隔离、鉴权、资源权限和审计是商用红线。前端可以先按迁移期接口联调，也可以按 Supabase 官方推荐使用 publishable key + RLS 的客户端能力管理 Auth/session，但正式上云验收前必须完成本文件的 P0 项。
 
 ## 安全边界
 
@@ -27,6 +27,8 @@
 
 这些只允许用于本地开发和内网联调，不允许作为正式云端验收方案。
 
+Supabase 官方允许前端用 Data API 访问数据，但前提是 RLS、最小 grant 和 JWT 权限模型都正确。本项目的核心业务表默认不开放给 Taro 直写；任何新增直连表都必须先通过 RLS、跨租户、权限和性能评审。
+
 ## P0：正式云端测试前必须完成
 
 1. 正式用户鉴权
@@ -69,6 +71,7 @@
 ## 前端必须遵守
 
 - 不信任本地缓存里的 tenantId/userId 作为安全依据。
+- 前端只能使用 Supabase publishable key，不能出现 secret key 或 service role key。
 - 不在页面里保存或展示任何商户密钥、短信密钥、OAuth secret。
 - 不在前端硬编码对象存储 bucket、私有资源路径、商户号。
 - 不在前端自行开通会员权益；必须通过订单/支付/激活码后端流程。
@@ -153,4 +156,3 @@ provider event id 幂等
 - 激活码并发兑换只能成功一次。
 - 对象存储签名 URL 有短 TTL。
 - 后台关键操作写入 audit log。
-