openxiangda 1.0.134 → 1.0.136

package/templates/openxiangda-react-spa/.cursor/rules/openxiangda.mdc

@@ -21,13 +21,20 @@ This is an OpenXiangda React SPA workspace. See [AGENTS.md](mdc:AGENTS.md) for f
 
 - Writes and deploys must pass `--profile <name>` explicitly.
 - Architecture-class work is plan-gated: run `openxiangda design gates --topic <code> --json` and wait for confirmation.
+- High-risk changes must start with `openxiangda sdd context --json`, use an approved change, and run `openxiangda sdd verify <change> --changed` before release.
+- Account/role/permission/RBAC/organization-account/query-param authorization work must run `openxiangda design gates --topic permissions --json`, choose `managed-platform-account`, `existing-platform-user-assignment`, `static-role-permission`, or `query-param-context`, and write the permission matrix.
+- Roles that create roles, assign members, grant API permissions, maintain permission groups, or manage organization accounts must declare `apiPermissionCodes`, such as `app:role:manage`, `app:page-permission-group:manage`, `app:form-permission-group:manage`, and `app:organization:manage`.
 - `src/resources/**` is the resource source of truth; use `validate -> plan -> publish`.
 - React routes live in `src/app/router.tsx`; frontend artifacts are deployed with `openxiangda runtime deploy`.
-- Backend permissions and public-access grants are authoritative.
+- Backend permissions, public-access grants, and App Function role/scope checks are authoritative.
+- Query parameters are context, filters, or ticket input only; they are not sensitive authorization.
 
 ## Never
 
 - Do not run `lowcode-workspace publish-all`, `pnpm publish:all`, or `pnpm openxiangda:publish` directly.
 - Do not deploy without `--profile`.
 - Do not use legacy `?publicAccess=guest`, `isRenderNav`, or workbench page parameters for new React SPA routes.
+- Do not rely on frontend-only button hiding, query-param checks, hardcoded roles, mock permissions, fake account IDs, or `PermissionBoundary` alone for real authorization.
+- Do not assign a business admin role without the role-setting API permissions needed for role/member management.
+- Do not bypass `sdk.organization` / `ctx.organization` for platform account/department writes.
 - Do not commit tokens, AK/SK, or third-party secrets.

package/templates/openxiangda-react-spa/.qoder/rules/openxiangda.md

@@ -21,13 +21,20 @@ This is an OpenXiangda React SPA workspace. Read [AGENTS.md](AGENTS.md) for full
 
 - 发布和写平台资源必须显式传 `--profile <name>`。
 - 架构类需求先跑 `openxiangda design gates --topic <code> --json` 并等用户确认。
+- 高风险变更先跑 `openxiangda sdd context --json`，创建/继续 change，并在用户确认后 `openxiangda sdd approve <change>`；发布前 `openxiangda sdd verify <change> --changed`。
+- 账号/角色/权限/RBAC/组织账号/查询参数授权需求先跑 `openxiangda design gates --topic permissions --json`，选择 `managed-platform-account` / `existing-platform-user-assignment` / `static-role-permission` / `query-param-context` 并输出权限矩阵。
+- 角色能新增角色、分配成员、授接口权限、维护权限组或管理组织账号时，角色资源必须声明 `apiPermissionCodes`，例如 `app:role:manage`、`app:page-permission-group:manage`、`app:form-permission-group:manage`、`app:organization:manage`。
 - `src/resources/**` 是工程化资源来源，正式多资源变更走 `validate -> plan -> publish`。
 - React SPA 路由由 `src/app/router.tsx` 管理，前端包通过 `openxiangda runtime deploy` 发布。
-- 页面权限、表单权限、公开访问 grants 以后端资源为准；前端只做展示保护。
+- 页面权限、表单权限、公开访问 grants、App Function 后端检查是授权依据；前端只做展示保护。
+- 查询参数只能做上下文、筛选或 ticket 输入，不能作为敏感数据授权依据。
 
 ## Never
 
 - 不要直接运行 `lowcode-workspace publish-all`、`pnpm publish:all` 或 `pnpm openxiangda:publish`。
 - 不要省略 `--profile` 发布。
 - 不要使用旧 `?publicAccess=guest`、`isRenderNav` 或 workbench 参数模型开发新 React SPA。
+- 不要只隐藏按钮、只判断 query 参数、硬编码角色、前端模拟权限、假账号/假 ID、或用 `PermissionBoundary` 代替真实授权。
+- 不要给用户挂“管理员”业务角色但不给该角色绑定 `app:role:manage` 等角色设置接口权限。
+- 不要绕过 `sdk.organization` / `ctx.organization` 直接写平台账号/部门。
 - 不要把 token、AK、SK、第三方密钥写入项目文件。

package/templates/openxiangda-react-spa/AGENTS.md

@@ -5,12 +5,18 @@
 ## 开发原则
 
 - 架构类需求默认只规划、不实现。新应用、复杂页面、登录注册、公开访问、权限数据范围、流程自动化、连接器/通知等需求，先运行 `openxiangda doctor --json` 和 `openxiangda design gates --topic <code> --json`，输出设计并等用户确认；确认前只允许读取、快照、dry-run、提问和写设计文档，不允许改源码、写平台、发布或发送通知。
+- 高风险变更必须挂到 SDD change。修改 `src/forms/**`、`src/pages/**`、`src/resources/**`、`src/functions/**`、`src/automations/**`、`src/workflows/**`、`src/js-code-nodes/**`、`src/runtime/**` 或 `app-workspace.config.ts` 前，先运行 `openxiangda sdd context --json`，没有合适 change 就 `openxiangda sdd propose <change>`，等用户确认后运行 `openxiangda sdd approve <change>` 再实现。发布前运行 `openxiangda sdd verify <change> --changed`、`openxiangda workspace check --changed`、`openxiangda resource plan --profile <name>`。
+- 账号、角色、权限、数据范围、组织账号、RBAC、查询参数授权需求必须先运行 `openxiangda design gates --topic permissions --json`，选择 `managed-platform-account` / `existing-platform-user-assignment` / `static-role-permission` / `query-param-context`，输出权限矩阵后再实现。
+- 应用角色如果要创建角色、分配角色成员、给角色授接口权限、维护页面/表单权限组或管理组织账号，必须在角色资源声明 `apiPermissionCodes`，例如 `app:role:manage`、`app:page-permission-group:manage`、`app:form-permission-group:manage`、`app:organization:manage`。
 - 默认用户界面保持克制：左侧应用导航、顶部账号信息、首页内容区域。
 - 不在默认可见页面展示 SDK、Runtime、Cookie、Proxy、Playwright、AI 验证、调试上下文、构建号等开发语言。
 - 使用 React Router 管理路由，路由定义在 `src/app/router.tsx`。
 - 使用 Tailwind CSS 表达样式，不依赖平台 theme tokens。
 - 菜单和首页文案优先改 `src/app/navigation.ts`、`src/app/starter-content.ts` 与 `src/pages/admin/AdminDashboardPage.tsx`。
 - 页面、表单、字段、数据范围、流程动作、文件、连接器权限以后端接口为准；前端只做展示保护和清晰状态页。
+- 查询参数只能作为上下文、筛选或 ticket 输入，不能作为敏感数据授权依据；敏感读写必须由 public-access grants、平台角色、页面/表单权限组或 App Function 后端校验保护。
+- 应用管理平台账号/部门时，必须走 `sdk.organization` / `ctx.organization`，并要求当前操作者具备 `app:organization:manage`。
+- 只给用户分配“管理员”业务角色不等于授权其设置角色；缺少 `app:role:manage` 时角色创建、成员分配和角色接口权限授予会被后端拒绝。
 - 本地开发通过 Vite `/service` 代理远端平台，保持 HttpOnly Cookie 同域访问。
 - 新公开访问页使用 `/view/:appType/public/*`、`src/resources/routes/`、`src/resources/public-access/` 和 `PublicAccessGate`。不要使用旧 `?publicAccess=guest`。
 
@@ -27,6 +33,8 @@ pnpm deploy -- --profile <name>
 openxiangda workspace publish --profile <name> --form <formCode>
 openxiangda doctor --profile <name> --json
 openxiangda design gates --topic public-access --json
+openxiangda sdd context --json
+openxiangda sdd verify <change> --changed
 openxiangda resource plan --profile <name>
 openxiangda resource publish --profile <name>
 openxiangda runtime deploy --profile <name>
@@ -75,7 +83,7 @@ React SPA 页面需要声明菜单 code、route code 和 path pattern。默认
 import { PermissionBoundary, useAppMenus, useRuntimeBootstrap } from "openxiangda/runtime/react";
 ```
 
-`PermissionBoundary` 只能做展示保护，不能替代后端权限。后端返回 401 时跳登录，403 时展示无权限状态。
+`PermissionBoundary` 只能做展示保护，不能替代后端权限。不要硬编码角色、前端模拟权限、只判断 query 参数或用空数组兜底伪装成功。后端返回 401 时跳登录，403 时展示无权限状态。
 
 公开页面需要同时声明 route 和 public access policy：
 

package/templates/openxiangda-react-spa/app-workspace.config.ts

@@ -30,4 +30,18 @@ export default defineAppWorkspaceConfig({
     pageMenuParentId: process.env.APP_PAGE_MENU_PARENT_ID || "",
     pageMenuIcon: process.env.APP_PAGE_MENU_ICON || "",
   },
+  compatibility: {
+    apiContracts:
+      process.env.OPENXIANGDA_API_CONTRACTS === "legacy" ? "legacy" : "strict",
+    legacyFallbacks: process.env.OPENXIANGDA_LEGACY_FALLBACKS === "true",
+    requestTrace: process.env.OPENXIANGDA_REQUEST_TRACE === "true",
+  },
+  governance: {
+    sdd: {
+      enabled: process.env.OPENXIANGDA_SDD_ENABLED === "false" ? false : true,
+      strictHighRisk:
+        process.env.OPENXIANGDA_SDD_STRICT_HIGH_RISK === "false" ? false : true,
+      path: process.env.OPENXIANGDA_SDD_PATH || "openspec",
+    },
+  },
 });

package/templates/sy-lowcode-app-workspace/.cursor/rules/openxiangda-resources.mdc

@@ -25,4 +25,8 @@ See `references/resource-manifest-cheatsheet.md` for copy-paste skeletons.
 
 Commands: `openxiangda resource validate|plan|publish|pull --profile <name>`.
 
-Forbidden: 把 `formUuid` / `pageId` / `workflowId` 等平台 ID 写进 manifest；把 API key / token / secret / authorization 写进 manifest；data view 用作单表 CRUD / linkedForm / 写回 / 强实时；page 源里 hardcode 通知或 connector URL。
+Before editing `roles`, `permissions/page-groups`, or `permissions/form-groups` for account/role/data-scope/RBAC/query-param authorization work, run `openxiangda design gates --topic permissions --json`, choose the permission mode, and write the permission matrix.
+
+If a `roles/<code>.json` role can create roles, assign members, grant API permissions, maintain permission groups, or manage organization accounts, it must declare `apiPermissionCodes`; a business role name alone does not grant backend API permission.
+
+Forbidden: 把 `formUuid` / `pageId` / `workflowId` 等平台 ID 写进 manifest；把 API key / token / secret / authorization 写进 manifest；data view 用作单表 CRUD / linkedForm / 写回 / 强实时；只靠 query 参数、前端隐藏按钮、硬编码角色、mock 权限或 `PermissionBoundary` 作为敏感授权；管理型角色缺少 `app:role:manage` / `app:page-permission-group:manage` / `app:form-permission-group:manage` / `app:organization:manage`；page 源里 hardcode 通知或 connector URL。

package/templates/sy-lowcode-app-workspace/.cursor/rules/openxiangda.mdc

@@ -18,13 +18,16 @@ This is a `sy-lowcode-app-workspace` managed by the `openxiangda` CLI. See [AGEN
 | edit code page / portal / dashboard / 代码页 | `openxiangda-page` | edit `src/pages/<code>/` → `workspace publish --page <code>` |
 | approval workflow / 审批流程 / JS_CODE | `openxiangda-workflow-automation` | `openxiangda workflow ...` |
 | automation / cron / 自动化 / 定时 | `openxiangda-workflow-automation` | `openxiangda automation ...` |
-| role / permission / 公开访问 | `openxiangda-permission-settings` | `openxiangda permission ...` / `openxiangda settings ...` |
+| account / role / permission / data scope / query-param authorization | `openxiangda-permission-settings` | run `openxiangda design gates --topic permissions --json` first, then `openxiangda permission ...` / `openxiangda settings ...` |
 | diagnose / snapshot / 排查 / 报错 | `openxiangda-inspect` | `openxiangda app snapshot APP_XXX --profile <name> --json` |
 | login / token / switch profile | `openxiangda-core` | `openxiangda env --profile <name>` / `openxiangda auth status` |
 
 ## Always
 
 - For routine edits, default to incremental publish: `workspace publish --profile <name> --changed --dry-run` then `--changed` or targeted `--page <code>` / `--form <code>`.
+- High-risk changes must use SDD first: `openxiangda sdd context --json` -> `openxiangda sdd propose <change>` -> user confirmation -> `openxiangda sdd approve <change>`; before release run `openxiangda sdd verify <change> --changed`.
+- Account/role/permission/RBAC/organization-account/query-param authorization work must choose a mode first: `managed-platform-account`, `existing-platform-user-assignment`, `static-role-permission`, or `query-param-context`, then write the permission matrix.
+- Roles that create roles, assign members, grant API permissions, maintain permission groups, or manage organization accounts must declare `apiPermissionCodes` in `src/resources/roles/<code>.json`, such as `app:role:manage`, `app:page-permission-group:manage`, `app:form-permission-group:manage`, and `app:organization:manage`.
 - Confirm current profile before any write: `openxiangda env --profile <name>`.
 - `.openxiangda/state.json` is the authoritative profile → appType → resource-ID map; CLI maintains it, do not hand-edit.
 - User tokens live in `~/.openxiangda/profiles.json`; shared env in `~/.openxiangda/.env`.
@@ -40,6 +43,9 @@ This is a `sy-lowcode-app-workspace` managed by the `openxiangda` CLI. See [AGEN
 - ❌ Search the platform for similar app names when `.openxiangda/state.json` has no binding.
 - ❌ Copy `formUuid` / `pageId` / `workflowId` / `automationId` across profiles.
 - ❌ Run a full publish for a single-file edit.
+- ❌ Frontend-only button hiding, query-param checks, hardcoded roles, mock permissions, fake account IDs, or `PermissionBoundary` alone as real authorization.
+- ❌ Business admin roles without `app:role:manage` or required role-setting API permissions when they are expected to manage roles or members.
+- ❌ Direct platform account/department writes that bypass `sdk.organization` / `ctx.organization`.
 - ❌ Use `openxiangda form create` / `form publish` / `page publish` as the normal page generation path.
 - ❌ Store tokens / AK / SK / third-party secrets in project files.
 - ❌ `npm publish` — this workspace is `"private": true`, not an npm package.

package/templates/sy-lowcode-app-workspace/.qoder/rules/openxiangda-resources.md

@@ -12,6 +12,10 @@ You are editing engineering-managed resource manifests under `src/resources/`. *
 
 `references/resource-manifest-cheatsheet.md`（installed at `~/.qoder/skills/openxiangda/references/resource-manifest-cheatsheet.md`）— connector / data-view / notification / workflow / automation / JS_CODE / role / page-group / form-group / settings / menu 骨架。
 
+编辑 `roles`、`permissions/page-groups`、`permissions/form-groups` 前，如果需求涉及账号、角色、数据范围、组织账号、RBAC 或查询参数授权，先运行 `openxiangda design gates --topic permissions --json`，选择权限模式并输出权限矩阵。
+
+如果 `roles/<code>.json` 代表的角色需要新增角色、分配成员、授接口权限、维护权限组或管理组织账号，必须声明 `apiPermissionCodes`；只写业务角色名不会获得这些后端接口权限。
+
 ## 文件夹与对应 skill
 
 | 路径 | 用途 | 主导 skill |
@@ -42,5 +46,7 @@ openxiangda resource pull     --profile <name>          # 平台 → 本地
 - ❌ 把 `formUuid` / `pageId` / `workflowId` 等平台 ID 直接写进 manifest（CLI 解析逻辑 code）。
 - ❌ 把 API key / token / secret / password / authorization / headers / credential 写进 manifest（平台后台配置）。
 - ❌ data view 用作单表 CRUD、`linkedForm` 下拉、写回、强实时数据源。
+- ❌ 只靠 query 参数、前端隐藏按钮、硬编码角色、mock 权限或 `PermissionBoundary` 作为敏感授权。
+- ❌ 管理型角色缺少 `app:role:manage`、`app:page-permission-group:manage`、`app:form-permission-group:manage` 或 `app:organization:manage`。
 - ❌ 在 page 源里 hardcode `/api/notification-config/*` 或 `/connectors/actions/invoke`（用 `sdk.notification` / `sdk.connector`）。
 - ❌ 同时在 manifest 与平台后台编辑同一个资源（漂移源）。

package/templates/sy-lowcode-app-workspace/.qoder/rules/openxiangda.md

@@ -18,13 +18,16 @@ This is a `sy-lowcode-app-workspace` managed by the `openxiangda` CLI. Read [AGE
 | 改代码页 / portal / dashboard | `openxiangda-page` | 编辑 `src/pages/<code>/` → `workspace publish --page <code>` |
 | 审批流程 / workflow / JS_CODE | `openxiangda-workflow-automation` | `openxiangda workflow ...` |
 | 自动化 / 定时 / 提交触发 | `openxiangda-workflow-automation` | `openxiangda automation ...` |
-| 角色 / 权限 / 公开访问 | `openxiangda-permission-settings` | `openxiangda permission ...` / `openxiangda settings ...` |
+| 账号 / 角色 / 权限 / 数据范围 / 查询参数授权 | `openxiangda-permission-settings` | 先 `openxiangda design gates --topic permissions --json`，再 `openxiangda permission ...` / `openxiangda settings ...` |
 | 排查 / 快照 / 对比 / 报错 | `openxiangda-inspect` | `openxiangda app snapshot APP_XXX --profile <name> --json` |
 | 登录 / token / 切平台 | `openxiangda-core` | `openxiangda env --profile <name>` / `openxiangda auth status` |
 
 ## Always
 
 - 单文件改动默认增量发布：先 `workspace publish --profile <name> --changed --dry-run`，再 `--changed` 或 `--page <code>` / `--form <code>`。
+- 高风险变更先走 SDD：`openxiangda sdd context --json` → `openxiangda sdd propose <change>` → 用户确认 → `openxiangda sdd approve <change>`；发布前 `openxiangda sdd verify <change> --changed`。
+- 账号/角色/权限/RBAC/组织账号/查询参数授权需求先选权限模式：`managed-platform-account` / `existing-platform-user-assignment` / `static-role-permission` / `query-param-context`，并输出权限矩阵。
+- 角色能新增角色、分配成员、授接口权限、维护权限组或管理组织账号时，`src/resources/roles/<code>.json` 必须声明 `apiPermissionCodes`，例如 `app:role:manage`、`app:page-permission-group:manage`、`app:form-permission-group:manage`、`app:organization:manage`。
 - 任何写操作前确认当前 profile：`openxiangda env --profile <name>`。
 - `.openxiangda/state.json` 是 profile 到 appType / 资源 ID 的权威映射，由 CLI 维护，不要手改。
 - 用户 token 在 `~/.openxiangda/profiles.json`；共享 env 在 `~/.openxiangda/.env`。
@@ -40,6 +43,9 @@ This is a `sy-lowcode-app-workspace` managed by the `openxiangda` CLI. Read [AGE
 - ❌ 在没有本地 `.openxiangda/state.json` 绑定时，去平台搜索同名应用"复用"。
 - ❌ 把 `formUuid` / `pageId` / `workflowId` / `automationId` 从 dev 复制到 prod。
 - ❌ 改一处就全量发布。
+- ❌ 只隐藏按钮、只判断 query 参数、硬编码角色、前端模拟权限、假账号/假 ID、或用 `PermissionBoundary` 代替真实授权。
+- ❌ 给用户挂“管理员”业务角色但不给该角色绑定 `app:role:manage` 等角色设置接口权限。
+- ❌ 绕过 `sdk.organization` / `ctx.organization` 直接写平台账号/部门。
 - ❌ `openxiangda form create` / `form publish` / `page publish` 当作页面生成方式（仅底层修复）。
 - ❌ 把 token / AK / SK / 第三方密钥写进项目文件。
 - ❌ `npm publish` — 本工作区 `"private": true`，不发 npm 包。

package/templates/sy-lowcode-app-workspace/AGENTS.md

@@ -9,6 +9,8 @@
 
 **架构类需求默认只规划、不实现。** 新应用、复杂页面、登录注册、公开访问、权限数据范围、流程自动化、连接器/通知等需求，先 `openxiangda doctor --json` + `openxiangda design gates --topic <code> --json`，输出设计并等待用户确认；确认前只允许读取、快照、dry-run、提问和写设计文档，不允许改源码、写平台、发布、部署或发送通知。
 
+**高风险变更必须挂到 SDD change。** 修改 `src/forms/**`、`src/pages/**`、`src/resources/**`、`src/functions/**`、`src/automations/**`、`src/workflows/**`、`src/js-code-nodes/**`、`src/runtime/**` 或 `app-workspace.config.ts` 前，先运行 `openxiangda sdd context --json`，没有合适 change 就 `openxiangda sdd propose <change>`，等用户确认后运行 `openxiangda sdd approve <change>` 再实现。发布前运行 `openxiangda sdd verify <change> --changed` 和 `openxiangda workspace check --changed`。
+
 工作区内的 npm scripts（`publish:all` / `publish:oss` / `register`）已加 `_guard:publish` 守卫；缺少 `OPENXIANGDA_PROFILE` 环境变量时会立即 fail，提示重新走 CLI 入口。
 
 ## 路由表 — 用户意图 → 命令 / skill
@@ -23,7 +25,7 @@
 | 创建 / 改自定义代码页、portal、看板 | `openxiangda-page` | 编辑 `src/pages/<code>/` → `workspace publish --page <code>` |
 | 审批流程 / 流程节点 / JS_CODE | `openxiangda-workflow-automation` | `openxiangda workflow validate / create / publish` |
 | 自动化 / 定时任务 / 提交触发 / cron | `openxiangda-workflow-automation` | `openxiangda automation validate / create / publish / enable` |
-| 角色 / 权限组 / 字段权限 / 公开访问 | `openxiangda-permission-settings` | `openxiangda permission ...` / `openxiangda settings ...` |
+| 账号 / 角色 / 权限组 / 字段权限 / 数据范围 / 查询参数授权 | `openxiangda-permission-settings` | 先 `openxiangda design gates --topic permissions --json`，再 `openxiangda permission ...` / `openxiangda settings ...` |
 | 查应用结构 / 快照 / 对比 / 排查 / 报错 | `openxiangda-inspect` | `openxiangda app snapshot <APP_XXX> --profile <name> --json` |
 | 登录 / 切平台 / token / whoami | `openxiangda-core` | `openxiangda env --profile <name>` / `openxiangda auth status` |
 | 多表只读联表查询 / 报表数据源 | `openxiangda-form`（data view） | 在 `src/resources/data-views/<code>.json` 声明 → `resource publish` |
@@ -34,6 +36,9 @@
 
 - ✅ 先 preflight：`openxiangda env --profile <name>` + `openxiangda auth status --profile <name>` + `openxiangda update check --json`。
 - ✅ 架构类需求先 plan gate：`openxiangda doctor --profile <name> --json` + `openxiangda design gates --topic <code> --json`，用户确认后再实现。
+- ✅ 高风险变更先 SDD gate：`openxiangda sdd context --json` → `openxiangda sdd propose <change>` → 用户确认 → `openxiangda sdd approve <change>`。
+- ✅ 涉及账号、角色、权限、数据范围、组织账号、RBAC、查询参数授权时，先跑 `openxiangda design gates --topic permissions --json`，选择 `managed-platform-account` / `existing-platform-user-assignment` / `static-role-permission` / `query-param-context`，并输出权限矩阵后再改资源。
+- ✅ 某个应用角色如果要创建角色、分配角色成员、给角色授接口权限、维护页面/表单权限组或管理组织账号，必须在 `src/resources/roles/<code>.json` 声明 `apiPermissionCodes`，例如 `app:role:manage`、`app:page-permission-group:manage`、`app:form-permission-group:manage`、`app:organization:manage`。
 - ✅ 单文件改动默认增量发布：`workspace publish --profile <name> --changed --dry-run` → `--changed` / `--page` / `--form`。
 - ✅ 用户 token 在 `~/.openxiangda/profiles.json`；项目 state 在 `.openxiangda/state.json`（只存 ID）。
 - ✅ 共享环境（`APP_OSS_*`、反馈机器人等）在 `~/.openxiangda/.env`，项目 `.env` 仅做 per-workspace override。
@@ -51,6 +56,9 @@
 - ❌ 把 `openxiangda form create` / `form publish` / `page publish` 当作日常页面生成方式。它们仅作底层修复 / 诊断。
 - ❌ 改一个文件就 `workspace publish` 全量。
 - ❌ 用户确认架构设计前就实现、写平台资源、发布、部署或发送通知。
+- ❌ 只隐藏按钮、只判断 query 参数、硬编码角色、前端模拟权限、假账号/假 ID、或用 `PermissionBoundary` 代替真实授权。敏感数据必须由角色、页面/表单权限组、public-access grants 或 App Function 后端校验保护。
+- ❌ 只给用户分配“管理员”业务角色，却不给该角色绑定 `app:role:manage` 等角色设置接口权限，然后期望他能新增账号、角色或权限组。
+- ❌ 直接绕过 SDK 调平台账号/组织写接口；应用管理平台账号/部门必须使用 `sdk.organization` / `ctx.organization`，且当前操作者具备 `app:organization:manage`。
 - ❌ 把 token、AK、SK、第三方密钥写进项目文件。
 - ❌ `npm publish` —— 这个工作区是 `"private": true` 的应用工作区，不是要发到 npm 的 package。
 - ❌ 在 AI 生成的 `src/forms/**` / `src/pages/**` 里直接写原生 `<input>` / `<select>` / `<textarea>` / `<input type="file">`、手写 picker、手写 uploader、手写人员/部门选择器。原生控件只允许出现在 OpenXiangda SDK / 平台组件内部。
@@ -75,6 +83,7 @@ sy-lowcode-app-workspace/
 ├── AGENTS.md                        # 本文件
 ├── .qoder/rules/openxiangda.md      # Qoder always-on 项目规则
 ├── .cursor/rules/openxiangda.mdc    # Cursor always-on 项目规则
+├── openspec/                        # SDD specs / changes / archive
 ├── .openxiangda/state.json          # profile → appType → 资源 ID 的权威映射（CLI 维护）
 ├── app-workspace.config.ts
 ├── package.json                     # publish:all/publish:oss/register 都被 _guard:publish 守卫

package/templates/sy-lowcode-app-workspace/app-workspace.config.ts

@@ -31,4 +31,18 @@ export default defineAppWorkspaceConfig({
     pageMenuParentId: process.env.APP_PAGE_MENU_PARENT_ID || "",
     pageMenuIcon: process.env.APP_PAGE_MENU_ICON || "",
   },
+  compatibility: {
+    apiContracts:
+      process.env.OPENXIANGDA_API_CONTRACTS === "legacy" ? "legacy" : "strict",
+    legacyFallbacks: process.env.OPENXIANGDA_LEGACY_FALLBACKS === "true",
+    requestTrace: process.env.OPENXIANGDA_REQUEST_TRACE === "true",
+  },
+  governance: {
+    sdd: {
+      enabled: process.env.OPENXIANGDA_SDD_ENABLED === "false" ? false : true,
+      strictHighRisk:
+        process.env.OPENXIANGDA_SDD_STRICT_HIGH_RISK === "false" ? false : true,
+      path: process.env.OPENXIANGDA_SDD_PATH || "openspec",
+    },
+  },
 });

package/templates/sy-lowcode-app-workspace/examples/best-practices/README.md

@@ -27,6 +27,9 @@ Run `pnpm examples:check` after editing examples, and run the normal
   `shared/components/`.
 - Use state fields and operation logs for business lifecycle flows.
 - Use workflow only for real approval tasks.
+- For account, role, data scope, organization-account, RBAC, or query-param
+  authorization work, run `openxiangda design gates --topic permissions --json`
+  and choose an access governance mode before copying examples.
 - Query with pagination and structured conditions. Avoid large page sizes,
   client-side filtering, and broad `searchKeyWord` queries.
 - For admin UI, choose one optional default from `glass-home-dashboard`,

package/templates/sy-lowcode-app-workspace/examples/best-practices/access-governance.md

@@ -0,0 +1,239 @@
+# Access Governance Pattern
+
+This example is a generic account and permission governance skeleton. Copy only
+the parts required by the selected permission mode. Do not publish this example
+directly without changing codes, names, roles, and data scopes.
+
+Start with:
+
+```bash
+openxiangda design gates --topic permissions --json
+```
+
+Choose one mode:
+
+- `managed-platform-account`: app creates/maintains platform departments,
+  accounts, and role members.
+- `existing-platform-user-assignment`: app assigns existing platform users to
+  app roles and business scopes.
+- `static-role-permission`: fixed roles and permission groups only.
+- `query-param-context`: query parameters are only context, filters, or ticket
+  input; they do not grant sensitive data access.
+
+## Resource Closure
+
+```text
+src/forms/organization_unit/schema.ts
+src/forms/system_account/schema.ts
+src/forms/role_assignment/schema.ts
+src/functions/sync_access_governance/index.ts
+src/resources/roles/access-roles.json
+src/resources/permissions/page-groups/access-admin-pages.json
+src/resources/permissions/form-groups/role_assignment/access-admin.json
+```
+
+## Form Skeletons
+
+`organization_unit` stores business organization units and the platform
+department sync result:
+
+```ts
+export const organizationUnitFields = [
+  { fieldId: "unitName", label: "组织名称", componentName: "TextField", placeholder: "请输入组织名称" },
+  { fieldId: "unitCode", label: "组织编码", componentName: "TextField", placeholder: "请输入稳定组织编码" },
+  { fieldId: "parentUnit", label: "上级组织", componentName: "SelectField", placeholder: "请选择上级组织", options: [] },
+  { fieldId: "manager", label: "负责人", componentName: "UserSelectField", placeholder: "请选择负责人" },
+  { fieldId: "platformDeptId", label: "平台部门ID", componentName: "TextField", behavior: "HIDDEN" },
+  {
+    fieldId: "syncStatus",
+    label: "同步状态",
+    componentName: "SelectField",
+    behavior: "HIDDEN",
+    options: [
+      { label: "待同步", value: "pending" },
+      { label: "已同步", value: "synced" },
+      { label: "同步失败", value: "failed" },
+    ],
+  },
+  { fieldId: "syncMessage", label: "同步说明", componentName: "TextAreaField", behavior: "HIDDEN" },
+  { fieldId: "lastSyncedAt", label: "最后同步时间", componentName: "DateField", behavior: "HIDDEN" },
+];
+```
+
+`system_account` stores the app-owned account record and the platform user sync
+result:
+
+```ts
+export const systemAccountFields = [
+  { fieldId: "displayName", label: "姓名", componentName: "TextField", placeholder: "请输入姓名" },
+  { fieldId: "loginName", label: "登录名", componentName: "TextField", placeholder: "请输入登录名" },
+  { fieldId: "phone", label: "手机号", componentName: "TextField", placeholder: "请输入手机号" },
+  { fieldId: "unitCode", label: "所属组织", componentName: "SelectField", placeholder: "请选择所属组织", options: [] },
+  {
+    fieldId: "enabled",
+    label: "账号状态",
+    componentName: "RadioField",
+    placeholder: "请选择账号状态",
+    options: [
+      { label: "启用", value: "enabled" },
+      { label: "停用", value: "disabled" },
+    ],
+  },
+  { fieldId: "platformUserId", label: "平台用户ID", componentName: "TextField", behavior: "HIDDEN" },
+  { fieldId: "platformDeptId", label: "平台部门ID", componentName: "TextField", behavior: "HIDDEN" },
+  {
+    fieldId: "syncStatus",
+    label: "同步状态",
+    componentName: "SelectField",
+    behavior: "HIDDEN",
+    options: [
+      { label: "待同步", value: "pending" },
+      { label: "已同步", value: "synced" },
+      { label: "同步失败", value: "failed" },
+    ],
+  },
+  { fieldId: "lastSyncedAt", label: "最后同步时间", componentName: "DateField", behavior: "HIDDEN" },
+];
+```
+
+`role_assignment` maps accounts or existing platform users to roles and business
+scope keys:
+
+```ts
+export const roleAssignmentFields = [
+  { fieldId: "account", label: "账号", componentName: "SelectField", placeholder: "请选择账号", options: [] },
+  { fieldId: "platformUser", label: "平台用户", componentName: "UserSelectField", placeholder: "请选择平台用户" },
+  {
+    fieldId: "roleCodes",
+    label: "角色",
+    componentName: "CheckboxField",
+    placeholder: "请选择角色",
+    options: [
+      { label: "权限管理员", value: "access_admin" },
+      { label: "范围内经办人", value: "scope_operator" },
+    ],
+  },
+  { fieldId: "businessUnit", label: "业务组织", componentName: "SelectField", placeholder: "请选择业务组织", options: [] },
+  { fieldId: "businessScopeKey", label: "业务范围键", componentName: "TextField", behavior: "HIDDEN" },
+  {
+    fieldId: "syncStatus",
+    label: "同步状态",
+    componentName: "SelectField",
+    behavior: "HIDDEN",
+    options: [
+      { label: "待同步", value: "pending" },
+      { label: "已同步", value: "synced" },
+      { label: "同步失败", value: "failed" },
+    ],
+  },
+  { fieldId: "syncMessage", label: "同步说明", componentName: "TextAreaField", behavior: "HIDDEN" },
+];
+```
+
+## Sync App Function Skeleton
+
+```ts
+export default async function syncAccessGovernance(ctx, input) {
+  const roleCodes = ctx.operator?.roleCodes || [];
+  if (!roleCodes.includes("access_admin") && !ctx.operator?.hasFullAccess) {
+    throw new Error("ACCESS_DENIED");
+  }
+
+  if (input.action === "syncAccount") {
+    if (!ctx.organization?.accounts) throw new Error("ORGANIZATION_API_UNAVAILABLE");
+    // Current operator must have app:organization:manage.
+    return ctx.organization.accounts.create({
+      name: input.displayName,
+      loginName: input.loginName,
+      phone: input.phone,
+      departmentId: input.platformDeptId,
+    });
+  }
+
+  if (input.action === "syncRoleMembers") {
+    // Read role_assignment records, resolve platformUserId values, and update
+    // app role members through the platform role API exposed by OpenXiangda.
+    return { ok: true };
+  }
+
+  throw new Error("UNKNOWN_ACTION");
+}
+```
+
+## Role Resource
+
+```json
+[
+  {
+    "code": "access_admin",
+    "name": "权限管理员",
+    "description": "维护组织、账号、角色和权限资源",
+    "apiPermissionMode": "merge",
+    "apiPermissionCodes": [
+      "app:role:manage",
+      "app:page-permission-group:manage",
+      "app:form-permission-group:manage",
+      "app:organization:manage"
+    ]
+  },
+  {
+    "code": "scope_operator",
+    "name": "范围内经办人",
+    "description": "只能访问授权业务范围内的数据"
+  }
+]
+```
+
+The initial grant of `access_admin` is normally done by a platform administrator
+or an existing app administrator. If `access_admin` creates another role that
+also manages accounts, roles, or permission groups, publish that new role with
+its own `apiPermissionCodes`; management power is not inherited from the
+creator.
+
+## Page Permission Group
+
+```json
+{
+  "code": "access_admin_pages",
+  "name": "权限管理员页面",
+  "roles": ["access_admin"],
+  "menuCodes": ["access_governance"],
+  "routeCodes": ["access.governance"],
+  "pathPatterns": ["/view/:appType/admin/access/*"]
+}
+```
+
+## Form Permission Group
+
+```json
+{
+  "code": "role_assignment_admin",
+  "formCode": "role_assignment",
+  "name": "角色分配管理员",
+  "type": "view",
+  "roles": ["access_admin"],
+  "operations": ["view", "edit", "delete"],
+  "dataScope": [{ "type": "all" }],
+  "fieldAccessPolicy": {
+    "defaultAccess": "edit",
+    "fields": [
+      { "fieldId": "syncMessage", "access": "readonly" }
+    ]
+  }
+}
+```
+
+For `scope_operator`, use condition data permission against hidden scalar keys,
+for example `businessScopeKey = ${CURRENT_USER_SCOPE}`. Do not fetch all rows
+and filter them in the page.
+
+## Acceptance
+
+- Permission mode and matrix are written in the SDD change or design document.
+- `openxiangda permission audit --json` has no high-risk gaps.
+- Allowed and denied role paths are both tested.
+- Query parameter tampering does not expand sensitive access.
+- Managed account writes are executed only by a user with
+  `app:organization:manage`.
+- Roles that create roles, assign members, or maintain permission groups include
+  `apiPermissionCodes` such as `app:role:manage`.

package/templates/sy-lowcode-app-workspace/examples/best-practices/catalog.json

@@ -53,6 +53,12 @@
       "path": "src/pages/service-ticket-ops",
       "description": "DataManagementList-based ops page with modular actions, drawer, timeline, hook, and service."
     },
+    {
+      "code": "access-governance",
+      "type": "permissions",
+      "path": "access-governance.md",
+      "description": "Generic account/role permission mode decision with organization, account, role assignment, sync function, role resource, page group, and form group skeletons."
+    },
     {
       "code": "role-governance",
       "type": "permissions",

package/templates/sy-lowcode-app-workspace/examples/best-practices/decision-guide.md

@@ -59,6 +59,21 @@ Frontend code must not be responsible for data isolation or background jobs.
 
 ## Permissions
 
+Run `openxiangda design gates --topic permissions --json` before implementing
+account, role, RBAC, organization-account, data-scope, or query-param
+authorization requirements.
+
+Choose one pattern:
+
+- `managed-platform-account`: app creates and maintains platform departments,
+  accounts, and role members. Start from `access-governance.md`.
+- `existing-platform-user-assignment`: app selects existing platform users and
+  assigns roles/business scopes. Use a role assignment form with
+  `UserSelectField`.
+- `static-role-permission`: fixed roles and permission groups only.
+- `query-param-context`: query parameters are context, filters, or ticket input
+  only; they cannot grant sensitive access.
+
 For dynamic multi-role apps, create a business role table and synchronize it to
 platform app roles. User-facing scope fields should be maintainable controls:
 personnel/department fields for people and orgs, enum fields for fixed option
@@ -67,4 +82,13 @@ customers, and other records maintained by forms. Use `remoteSearch: true` when
 the source form can have many records. If the platform permission condition
 needs a scalar value, derive a hidden scope key such as `collegeScopeKey` or
 `ownerDeptScopeKey`. Use form permission groups with condition-style data
-permissions to enforce data isolation.
+permissions and App Function role/scope checks to enforce data isolation.
+
+When an app role is expected to create roles, assign role members, grant role
+API permissions, maintain permission groups, or manage organization accounts,
+declare the matching `apiPermissionCodes` on that role. `app:role:manage` is
+required for app role creation and member assignment; page/form permission group
+maintenance and organization account management use their own permission codes.
+
+Frontend hiding and query parameters are not authorization. They must not be the
+only barrier for sensitive data or write actions.

package/templates/sy-lowcode-app-workspace/src/types/app-workspace.types.ts

@@ -29,6 +29,18 @@ export interface AppWorkspaceConfig {
     dir?: string;
     publishLegacyBundle?: boolean;
   };
+  compatibility?: {
+    apiContracts?: "strict" | "legacy";
+    legacyFallbacks?: boolean;
+    requestTrace?: boolean;
+  };
+  governance?: {
+    sdd?: {
+      enabled?: boolean;
+      strictHighRisk?: boolean;
+      path?: string;
+    };
+  };
 }
 
 export type CustomPageEntryMode = "app-shell" | "plain-page";