docs: add ai development guardrails

docs/refactor/architecture.md

@@ -6,7 +6,7 @@
 
 ```text
 apps/
-  api/                    新业务 API，前端和小程序都通过它访问业务数据
+  api/                    业务命令 API，承接复杂事务、第三方 provider、密钥和审计
     src/core/             配置、HTTP、错误响应、路由注册、数据库访问等基础层
     src/features/         领域模块，按 catalog、tenant、health 等拆分
     src/features/platform-admin/
@@ -26,14 +26,15 @@ scripts/
   import-pocketbase/      PocketBase schema 风险分析、JSON 导入、导入后校验
   smoke-seed.js           本地 reset 后的最小业务烟测数据
 
-src/
-  services/supabaseApi.ts 旧 Web 前端迁向新 API 的兼容客户端
-  tenant.config.ts        租户解析配置，优先读新 API
+docs/refactor/
+  ai-development-guardrails.md
+                            后续 AI/开发者必须遵守的架构和安全守则
 ```
 
 ## 设计原则
 
-- `apps/api` 是业务 API 层，复杂交易、支付、权益、租户解析都应该在这里做，不让前端直接操作表。
+- 本项目采用 Supabase-first 架构。简单安全的数据访问优先使用 RLS、视图、RPC 等 Supabase/PostgreSQL 原生能力；复杂交易、支付、权益、租户解析、密钥、webhook、异步任务和审计放在 `apps/api`、Edge Functions 或 worker。
+- 前端可以使用 Supabase client 管理 Auth/JWT，也可以在严格 RLS 下访问低风险 table/view/RPC；但不得直接写订单、支付、权益、租户密钥、CRM、导入等复杂业务表。
 - 平台方与合作商之间的 SaaS 收费，使用 `platform_saas_plans`、`tenant_subscriptions`、`tenant_invoices`、`tenant_invoice_payments`；学生 C 端会员订单仍使用 `orders/payments/entitlements`。
 - `apps/api/src/server.ts` 只负责 HTTP 生命周期；业务路由统一放在 `features/*`，由 `core/router.ts` 汇总注册。
 - API 对外错误必须走 `HttpError` 或统一错误响应，生产环境不向前端泄露数据库异常和内部栈信息。
@@ -94,4 +95,4 @@ npm run pb:import:validate
 - `apps/api/src/features` 继续按业务域扩展：真实支付 provider、真实 OAuth provider、平台审计和 worker。
 - `src/services/supabaseApi.ts` 逐页替换旧 PB 只读接口，优先学生端和小程序共用页面。
 - 新增 `apps/worker` 承接 CRM webhook、支付补偿、日报统计、导入后异步检查。
-- 新增 `apps/taro` 后，所有租户解析和公开业务读取都复用 API，不单独维护另一套后端逻辑。
+- 新增 `apps/taro` 后，Auth/JWT 优先复用 Supabase client；复杂业务命令复用 `apps/api`/RPC/Edge Functions，不单独维护另一套后端逻辑。