chore: sync config from main

Author: github-actions[bot]

airules/codebuddy/rules/auth-tool/rule.md

@@ -53,6 +53,7 @@ Keep local `references/...` paths for files that ship with the current skill dir
 ### Minimal checklist
 
 - Read [Authentication Activation Checklist](checklist.md) before auth implementation.
+- Anonymous login is disabled by default. The SDK initialized with `accessKey` still creates a lightweight anonymous session for API access. If the app requires authentication (e.g. admin panels, personal dashboards), enforce access control through AuthGuard or RLS policies rather than relying on the login strategy toggle.
 
 ## Overview
 
@@ -150,7 +151,7 @@ Internal behavior of `manageAppAuth(action="patchLoginStrategy")`:
 
 ### 2. Anonymous Login
 
-> ⚠️ **Anonymous login is disabled by default for new environments.** Inactive existing environments (no anonymous login usage within the past month) have also been automatically disabled. Additionally, anonymous users are denied AI model invocation permissions by default. Only enable anonymous login when the application explicitly requires unauthenticated access and you accept the associated security trade-offs.
+> ⚠️ **Anonymous login is disabled by default.** The SDK initialized with `accessKey` still creates a lightweight anonymous session for API access. Only enable anonymous login when the application explicitly requires unauthenticated access and you accept the associated security trade-offs. Anonymous users are also denied AI model invocation permissions by default.
 
 Preferred MCP tool path: `manageAppAuth(action="patchLoginStrategy")`
 

airules/codebuddy/rules/auth-web/rule.md

@@ -47,6 +47,7 @@ Keep local `references/...` paths for files that ship with the current skill dir
 - Using `signInWithEmailAndPassword` or `signUpWithEmailAndPassword` for username-style accounts such as `admin` and `editor`.
 - Keeping the login or register account input as `type="email"` when the task explicitly says the account identifier is a plain username string.
 - Starting implementation before calling `queryAppAuth(action="getLoginConfig")` and enabling `usernamePassword` when it is still off.
+- **Writing `auth.signInWithPassword(...)` or `auth.signUp(...)` code without first confirming the provider is enabled via MCP.** Before writing any sign-in or sign-up code in the browser, call `queryAppAuth(action="listProviders")` to verify the target provider (e.g. `email`, `phone`, `usernamePassword`) has `On: "TRUE"`. For email-based sign-up (`auth.signUp({ email, password })`), additionally confirm SMTP is configured — otherwise the provider may throw `"provider email not found"` or similar errors. For username/password login, use `auth.signInWithPassword({ username, password })`; registration is best done through the management API (`manageAppAuth(action="createUser")`) or by confirming email provider readiness first.
 - **Treating `auth.getUser()` or deprecated `auth.getLoginState()` as proof of real login.** When the SDK is initialized with `accessKey`, the deprecated `getLoginState()` returns an object with a valid `uid` even without any login — causing route guards that check `!!loginState` or `!!uid` to incorrectly pass. The fix is to use `auth.getSession()` instead: it returns `data.session === undefined` when no real login has occurred. Only `!!data.session` from `getSession()` is a reliable authentication check.
 - **Copying old CloudBase auth snippets from training data.** Do not use `auth.getLoginState()`, `auth.hasLoginState()`, `auth.getCurrentUser()`, or `auth.toDefaultLoginPage()` as the default Web flow. Use the Supabase-like Web SDK v2 auth methods in this file and provider readiness from `auth-tool`.
 

airules/codebuddy/rules/cloudbase-code-review/references/rules/postgresql/PG-CR001.md

@@ -22,14 +22,16 @@
 
 1. 项目代码中使用了哪些 PG 表名（`db.from("xxx")`）？
 2. 这些表是否已在 PG 中被创建？
-3. 建表是通过什么方式完成的？
+3. **建表前是否先检查了表结构？** 在 CREATE TABLE 之前，是否先调用了 `queryPgDatabase(action="sql", sql="SELECT column_name, data_type FROM information_schema.columns WHERE table_name='xxx'")` 确认表是否存在及其精确列名？
+4. **是否依赖了 `CREATE TABLE IF NOT EXISTS` 的静默跳过行为？** 如果表已存在但列名不匹配（例如预期 `uid` 但实际是 `user_id`），`IF NOT EXISTS` 会静默跳过，导致所有 CRUD 查询用错字段名。必须使用 `ALTER TABLE` 或 `DROP TABLE ... CASCADE`（确认数据影响后）重建。
+5. 建表是通过什么方式完成的？
    - MCP 工具 `executePgSql` 或 `manageSqlDatabase`？
    - SQL 脚本？
    - ORM migration？
-4. 表结构是否包含必要字段？
+6. 表结构是否包含必要字段？
    - articles 表：`title`, `content`, `author_id`, `status`, `created_at`, `updated_at`
    - users 表：`id/uid`, `username`, `role`
-5. 建表操作是否在实际 CRUD 调用**之前**执行？顺序对吗？
+7. 建表操作是否在实际 CRUD 调用**之前**执行？顺序对吗？
 
 ## 修复指引
 

airules/codebuddy/rules/cloudbase-code-review/references/rules/postgresql/PG-CR002.md

@@ -26,9 +26,10 @@
 | UPDATE | 可更新所有 | 仅更新自己的（author_id = uid） |
 | DELETE | 可删除所有 | 仅删除自己的（author_id = uid） |
 
-4. 检查策略是否使用了 `auth.uid()` 来获取当前用户 ID？
-5. 仅开启了 RLS（`ALTER TABLE ... ENABLE ROW LEVEL SECURITY`）但没有创建策略，等于拒绝所有访问。
-6. 如果选择不放 RLS 而用在应用层（CRUD 代码中）做权限判断，确认后端/数据库层确实限制了 editor 只能操作自己的文章，而 admin 可以操作全部。
+4. **检查策略中是否使用了 `current_user` 或 `current_setting(...)`？** 这是常见错误！`current_user` 返回的是数据库角色名（如 `authenticated`），不是 CloudBase 认证用户 ID。必须使用 `auth.uid()`。
+5. 检查策略是否使用了 `auth.uid()` 来获取当前用户 ID？
+6. 仅开启了 RLS（`ALTER TABLE ... ENABLE ROW LEVEL SECURITY`）但没有创建策略，等于拒绝所有访问。
+7. 如果选择不放 RLS 而用在应用层（CRUD 代码中）做权限判断，确认后端/数据库层确实限制了 editor 只能操作自己的文章，而 admin 可以操作全部。
 
 ## 修复指引
 

airules/codebuddy/rules/cloudbase-platform/rule.md

@@ -189,6 +189,8 @@ Example structure for operation recording:
 - **Forbidden behavior**: Do not use cloud functions to implement login authentication logic
 - **Session management**: For route guards and login proof, use `auth.getSession()` and require `data.session`; do not use deprecated `getLoginState()` or `auth.getUser()` / `auth.getCurrentUser()` as proof of real login.
 - **Provider and login-method setup**: Use `queryAppAuth` / `manageAppAuth`, not the MCP `auth` tool
+- **Anonymous login is disabled by default.** The SDK initialized with `accessKey` automatically creates an anonymous session. If the app uses AuthGuard or RLS for access control, ensure `is_anonymous` checks are in place when anonymous access is allowed.
+- **⚠️ PG RLS: Use `auth.uid()`, NOT `current_user`.** When writing RLS policies for CloudBase PostgreSQL, the user identity must use `auth.uid()` (returns the JWT `sub` / actual user ID). Do NOT use `current_user` or `current_setting(...)` — these PostgreSQL built-in functions return the database role name (e.g. `authenticated`), not the CloudBase auth user ID. CloudBase PG provides four auth helper functions: `auth.uid()`, `auth.role()`, `auth.email()`, `auth.jwt()`. Verify availability with `SELECT proname FROM pg_proc WHERE pronamespace = 'auth'::regnamespace`.
 
 ### Mini Program Authentication
 - **Login-free feature**: Mini program CloudBase is naturally login-free, no login flow needed

airules/codebuddy/rules/postgresql-development/references/auth-and-rls.md

@@ -21,6 +21,14 @@ select auth.jwt();   -- full JWT claims as jsonb
 select auth.email(); -- current email if available
 ```
 
+**⚠️ CRITICAL: Always use `auth.uid()` for user identity in RLS policies.** Do NOT use `current_user` or `current_setting(...)` — these are PostgreSQL built-in functions that return the database role name (e.g. `authenticated`), not the CloudBase auth user ID. Using `current_user` in a policy like `USING (author_id = current_user)` will never match any real user ID.
+
+If you are unsure whether the auth helper functions are available in your environment, run:
+```sql
+SELECT proname FROM pg_proc WHERE pronamespace = 'auth'::regnamespace;
+```
+This returns the list of available `auth.*` functions (e.g. `uid`, `role`, `jwt`, `email`).
+
 Prefer database-owned identity fields:
 
 ```sql
@@ -83,3 +91,4 @@ CREATE POLICY todos_delete_own ON public.todos
 - `UPDATE` must normally include both `USING` and `WITH CHECK` to prevent owner-field reassignment.
 - `serial` / `bigserial` requires sequence grants or inserts can fail.
 - Admin/control-plane execution can hide user-facing permission failures; test as `anon` / `authenticated` when possible.
+- **Do NOT use `current_user` in RLS policies.** `current_user` returns the database role name (e.g. `authenticated`), not the actual user ID. Always use `auth.uid()` for user identity checks.

airules/codebuddy/rules/postgresql-development/references/rls-patterns.md

@@ -13,6 +13,8 @@ Use this reference when a CloudBase PostgreSQL app needs backend-side row permis
 - Do not use privileged functions or definer-style bypasses to silence permission errors unless the task explicitly needs a trusted server/RPC boundary.
 - The Web session is the source of truth for the app user. Use `auth.getSession()` in Web code and treat `session.user.id` as the candidate owner UID.
 - In SQL policies, use CloudBase PG's official helpers: `auth.uid()` for JWT `sub`, `auth.role()` for `anon` / `authenticated` / `service_role`, `auth.jwt()` for full claims, and `auth.email()` when needed.
+- **⚠️ Do NOT use `current_user` or `current_setting(...)` in RLS policies.** `current_user` returns the database role name (e.g. `authenticated`), NOT the CloudBase auth user ID. Using `author_id = current_user` will never match any real user row.
+- If unsure whether auth helpers are available, run `SELECT proname FROM pg_proc WHERE pronamespace = 'auth'::regnamespace` to list them.
 - Do not use `auth.getUser()` as a route guard or owner UID source unless you have already confirmed it returns the same logged-in user as `getSession()`.
 
 ## Choose One Permission Boundary

airules/codebuddy/rules/postgresql-development/rule.md

@@ -75,6 +75,12 @@ CloudBase PG (`app.rdb()`, `app.storage.from('bucket')`) uses **different API me
    - `managePgDatabase(action=listMigrations)` — list all applied migrations
    - `managePgDatabase(action=migrationDetail, objectName=...)` — inspect a single migration
    - `managePgDatabase(action=rollbackMigration, objectName=..., confirm=true)` — roll back a migration
+
+   **🚨 CRITICAL: Inspect table existence and column names before CREATE TABLE.** `CREATE TABLE IF NOT EXISTS` silently skips when the table already exists, even if the column names are wrong. Always call `queryPgDatabase(action="sql", sql="SELECT column_name, data_type FROM information_schema.columns WHERE table_name='xxx'")` first to check whether the table exists and what exact column names it uses. If the table already exists with mismatched column names (e.g. `user_id` instead of `uid`), you must either:
+   - `ALTER TABLE` to add/rename/drop columns, or
+   - `DROP TABLE IF EXISTS ... CASCADE` and recreate (only when data loss is acceptable, e.g. disposable/evaluation environments).
+   - Do NOT rely on `CREATE TABLE IF NOT EXISTS` silent skip — it will cause all downstream CRUD queries to fail with wrong field names.
+   - After DDL, re-query the schema and compare every column name used by frontend code, insert/update payloads, filters, ordering, and RLS policies.
 5. Check username-password auth before coding login:
    - Call `queryAppAuth(action="getLoginConfig")`.
    - If `loginMethods.usernamePassword !== true`, call `manageAppAuth(action="patchLoginStrategy", patch={ usernamePassword: true })`.
@@ -92,6 +98,7 @@ CloudBase PG (`app.rdb()`, `app.storage.from('bucket')`) uses **different API me
    - Insert a test row using `author_id = session.user.id`.
    - Read it back with `queryPgDatabase`.
    - If INSERT/SELECT fails, inspect the exact RLS error and fix the policy or switch to a server/RPC boundary. Do not leave browser-facing tables with broken RLS.
+   - **⚠️ Do NOT use `current_user` or `current_setting(...)` in RLS policies.** `current_user` in PostgreSQL returns the database role name (e.g. `authenticated`), NOT the CloudBase auth user ID. Always use `auth.uid()` for user identity checks. If you are unsure whether the auth helpers are available, run `SELECT proname FROM pg_proc WHERE pronamespace = 'auth'::regnamespace` to list all available `auth.*` functions.
 10. Use PG HTTP API only as a fallback after reading OpenAPI docs and verifying the auth model in the installed SDK. Do not guess URLs such as `/api/v1/rdb/rest`; the documented base is `https://<envId>.api.tcloudbasegateway.com/v1/rdb/rest/<table>` and auth is `Authorization: Bearer <Publishable Key | access_token | API Key>`.
 11. Keep cover images in CloudBase Storage. Store only the final file URL or file metadata in PG.
 12. Verify both layers before claiming done: project build/typecheck and browser E2E for login/CRUD, then read back rows with `queryPgDatabase`. When debugging RLS, run SQL as `authenticated` / `anon` if the tool supports role simulation; admin/default execution can bypass the user-facing failure.

airules/codebuddy/rules/web-development/rule.md

@@ -32,6 +32,7 @@ Keep local `references/...` paths for files that ship with the current skill dir
 
 - The task includes project structure, framework conventions, build config, deployment, routing, or frontend test and validation flows.
 - The request includes UI implementation but the visual direction is already fixed; otherwise read `ui-design` first.
+- **⚠️ Any task involving interface styling, layout, color scheme, or font selection — before writing the first line of CSS/Tailwind, you MUST load the `ui-design` skill and output a Design Specification.** Skipping this step causes frontend styling to degrade to generic AI template defaults. The `ui-design` skill must be loaded before any visual implementation begins, not retroactively after the user complains about the appearance.
 
 ### Then also read
 

miniprogram/cloudbase-ai-video/.agent/rules/auth-tool/rule.md

@@ -53,6 +53,7 @@ Keep local `references/...` paths for files that ship with the current skill dir
 ### Minimal checklist
 
 - Read [Authentication Activation Checklist](checklist.md) before auth implementation.
+- Anonymous login is disabled by default. The SDK initialized with `accessKey` still creates a lightweight anonymous session for API access. If the app requires authentication (e.g. admin panels, personal dashboards), enforce access control through AuthGuard or RLS policies rather than relying on the login strategy toggle.
 
 ## Overview
 
@@ -150,7 +151,7 @@ Internal behavior of `manageAppAuth(action="patchLoginStrategy")`:
 
 ### 2. Anonymous Login
 
-> ⚠️ **Anonymous login is disabled by default for new environments.** Inactive existing environments (no anonymous login usage within the past month) have also been automatically disabled. Additionally, anonymous users are denied AI model invocation permissions by default. Only enable anonymous login when the application explicitly requires unauthenticated access and you accept the associated security trade-offs.
+> ⚠️ **Anonymous login is disabled by default.** The SDK initialized with `accessKey` still creates a lightweight anonymous session for API access. Only enable anonymous login when the application explicitly requires unauthenticated access and you accept the associated security trade-offs. Anonymous users are also denied AI model invocation permissions by default.
 
 Preferred MCP tool path: `manageAppAuth(action="patchLoginStrategy")`