openxiangda 1.0.143 → 1.0.144

package/README.md

@@ -365,7 +365,7 @@ const PublicAccessError = ({ error }: { error: { message?: string } }) => (
 
 多表只读查询和固定口径统计优先声明 `src/resources/data-views/*.json` 数据视图，而不是在页面里手写多次单表查询再拼数据。默认 `storageMode: "materialized"` 会创建 PostgreSQL materialized view，适合读多写少和可接受刷新延迟的列表/报表；`storageMode: "live"` 每次查询实时编译逻辑视图，适合强实时但数据量可控的复杂查询。`viewType: "aggregate"` 是统计聚合视图，适合按客户、状态、月份等维度聚合 count/sum/avg/min/max。发布时 CLI 会把 `formCode` 解析为当前 profile 的 `formUuid`；页面通过 `sdk.dataView.query(code, params)` 查询行级视图，通过 `sdk.dataView.stats(code, params)` 查询聚合视图，也可以用 `sdk.dataSource.run()` 路由 `dataView.query` / `dataView.stats`。materialized 模式应为常用筛选、排序、统计维度和时间桶声明 `indexes`，并确认用户能接受的刷新延迟；live 模式忽略 `indexes`，不需要刷新。
 
-后端业务逻辑优先声明为 App Function：源码放在 `src/functions/<functionCode>/index.ts`，资源 manifest 放在 `src/resources/functions/<functionCode>.json`。函数运行在 trusted_node 中，通过 `ctx.form.queryOne/queryMany/getById/createOne/updateOne/updateById`、`ctx.dataView`、`ctx.connector`、`ctx.notification`、`ctx.organization`、`ctx.platform.api` 等受控 API 访问平台能力；自动化、流程和运行时接口都可以调用同一个 function。运行时页面调用会在 `ctx.operator`、`ctx.currentUser`、`ctx.permissions` 中注入可信的 `roleCodes`、`currentRoleCode`、`hasFullAccess`、`isAppAdmin`、`isPlatformAdmin`，敏感动作必须读取这些服务端上下文做授权，不要信任页面 input 里传入的角色字段。`ctx.form.createOne/updateOne/updateById` 是后端受控写入，授权边界是函数 manifest 的 `resources.forms` 绑定和函数调用授权，不是页面用户对目标表单的直接提交入口；报名、签到、福利选择等内部多表写入应走 App Function，不要为了写内部表单给普通用户开放原始 submit 权限。JS_CODE V2 仍兼容，但新逻辑建议写成 function，再由 `function_call` 节点、`sdk.function.invoke(code, { input })` 或 `/:appType/v1/functions/:code/invoke.json` 调用。直接运行时接口默认要求调用者具备应用自动化管理权限；如果普通应用角色需要从页面调用，必须在函数 `definitionJson.runtimeInvoke.roleCodes` 显式声明允许的当前应用角色。自动化/流程内部调用走服务端受控上下文。
+后端业务逻辑优先声明为 App Function：源码放在 `src/functions/<functionCode>/index.ts`，资源 manifest 放在 `src/resources/functions/<functionCode>.json`。函数运行在 trusted_node 中，通过 `ctx.form.queryOne/queryMany/getById/createOne/updateOne/updateById`、`ctx.dataView`、`ctx.connector`、`ctx.notification`、`ctx.organization`、`ctx.platform.api` 等受控 API 访问平台能力；自动化、流程和运行时接口都可以调用同一个 function。运行时页面调用会在 `ctx.operator`、`ctx.currentUser`、`ctx.permissions` 中注入可信的 `roleCodes`、`currentRoleCode`、`hasFullAccess`、`isAppAdmin`、`isPlatformAdmin`，敏感动作必须读取这些服务端上下文做授权，不要信任页面 input 里传入的角色字段。`ctx.form.createOne/updateOne/updateById` 是后端受控写入，授权边界是函数 manifest 的 `resources.forms` 绑定和函数调用授权，不是页面用户对目标表单的直接提交入口；报名、签到、福利选择等内部多表写入应走 App Function，不要为了写内部表单给普通用户开放原始 submit 权限。JS_CODE V2 仍兼容，但新逻辑建议写成 function，再由 `function_call` 节点、`sdk.function.invoke(code, { input })` 或 `/:appType/v1/functions/:code/invoke.json` 调用。直接运行时接口默认要求调用者具备应用自动化管理权限；普通页面调用必须在函数 `definitionJson.runtimeInvoke.audience` 声明 `authenticated`、`page_permission_group`、`app_roles` 或 `scope_policy`，`roleCodes` 只用于当前应用角色精确匹配，不支持 `"*"` / `"all-app-roles"`。自动化/流程内部调用走服务端受控上下文。内部业务表单需要关闭原始写入接口时，在表单 settings 中设置 `runtimeWrite.mode="function_only"`。
 
 平台部门和账号管理走 app-scoped organization 能力。调用者必须在目标应用拥有 `app:organization:manage`；平台管理员天然可用，普通应用角色需要显式授权。Runtime service principal 不会直接放行，`ctx.organization` 会按真实操作人 / audit actor 校验权限。新接口只提供创建、更新、查询和密码专用操作，不提供删除；`account-update` 不能携带 `password`，重置他人密码必须走 `account-reset-password`，当前用户改密用 SDK / `ctx.organization.accounts.changeMyPassword({ oldPassword, newPassword })`。
 

package/lib/cli.js

@@ -7009,6 +7009,7 @@ function validateResourceItem(kind, item, errors, warnings) {
     if (!item.definitionJson && !item.definitionFile) {
       errors.push(`${label}: 缺少 definitionJson 或 definitionFile`);
     }
+    validateFunctionRuntimeInvoke(label, item, errors, warnings);
   }
   if (kind === 'dataViews') {
     const definition = item.definition || item;
@@ -7217,17 +7218,183 @@ function validateResourceItem(kind, item, errors, warnings) {
     if (!item.formCode && !item.formUuid && !item.code) {
       errors.push(`${label}: 缺少 formCode、formUuid 或 code`);
     }
+    validateFormRuntimeWriteSettings(label, item, errors);
     if (
       item.settings === undefined &&
       item.indexes === undefined &&
       item.dataManagement === undefined &&
-      item.publicAccess === undefined
+      item.publicAccess === undefined &&
+      item.runtimeWrite === undefined
     ) {
-      warnings.push(`${label}: 未声明 settings/indexes/dataManagement/publicAccess`);
+      warnings.push(`${label}: 未声明 settings/indexes/dataManagement/publicAccess/runtimeWrite`);
     }
   }
 }
 
+const FUNCTION_RUNTIME_INVOKE_AUDIENCE_TYPES = new Set([
+  'authenticated',
+  'app_roles',
+  'page_permission_group',
+  'scope_policy',
+]);
+
+const FUNCTION_RUNTIME_INVOKE_MAGIC_ROLE_CODES = new Set([
+  '*',
+  'all-app-roles',
+  'all_app_roles',
+  'authenticated',
+  'logged_in',
+  'login',
+]);
+
+function validateFunctionRuntimeInvoke(label, item, errors, warnings) {
+  const definition = item.definitionJson || {};
+  const runtimeInvoke = item.runtimeInvoke || definition.runtimeInvoke;
+  if (!runtimeInvoke) return;
+  if (typeof runtimeInvoke !== 'object' || Array.isArray(runtimeInvoke)) {
+    errors.push(`${label}: runtimeInvoke 必须是对象`);
+    return;
+  }
+  if (
+    runtimeInvoke.enabled !== undefined &&
+    typeof runtimeInvoke.enabled !== 'boolean'
+  ) {
+    errors.push(`${label}: runtimeInvoke.enabled 必须是 boolean`);
+  }
+
+  const roleCodeValues = [
+    runtimeInvoke.roleCodes,
+    runtimeInvoke.roles,
+    runtimeInvoke.allowedRoleCodes,
+    definition.invokeRoleCodes,
+  ];
+  let hasRoleGrant = false;
+  for (const value of roleCodeValues) {
+    if (value === undefined) continue;
+    if (!Array.isArray(value)) {
+      errors.push(`${label}: runtimeInvoke roleCodes/roles/allowedRoleCodes 必须是数组`);
+      continue;
+    }
+    if (value.length > 0) hasRoleGrant = true;
+    for (const roleCode of value) {
+      const normalized = String(roleCode || '').trim();
+      if (!normalized) continue;
+      if (FUNCTION_RUNTIME_INVOKE_MAGIC_ROLE_CODES.has(normalized.toLowerCase())) {
+        errors.push(
+          `${label}: runtimeInvoke.roleCodes 不支持魔法值 "${normalized}"；请使用 audience.type`
+        );
+      }
+    }
+  }
+
+  const audiences = [
+    runtimeInvoke.audience,
+    runtimeInvoke.audiences,
+    definition.invokeAudience,
+    definition.invokeAudiences,
+  ].filter(value => value !== undefined);
+  for (const audience of audiences) {
+    validateFunctionRuntimeInvokeAudience(label, audience, errors);
+  }
+
+  const hasAudience =
+    audiences.length > 0 ||
+    runtimeInvoke.allowAuthenticated === true ||
+    runtimeInvoke.authenticated === true ||
+    runtimeInvoke.allowLoggedIn === true ||
+    runtimeInvoke.scopePolicyCode ||
+    runtimeInvoke.policyCode ||
+    runtimeInvoke.dataScopePolicyCode ||
+    runtimeInvoke.pagePermissionGroupCodes ||
+    runtimeInvoke.pagePermissionGroups ||
+    runtimeInvoke.pageGroups;
+
+  if (!hasAudience && !hasRoleGrant) {
+    warnings.push(
+      `${label}: runtimeInvoke 未声明 audience 或有效 roleCodes，页面运行时调用仍会要求 app:automation:manage`
+    );
+  }
+}
+
+function validateFunctionRuntimeInvokeAudience(label, value, errors) {
+  if (Array.isArray(value)) {
+    value.forEach(item => validateFunctionRuntimeInvokeAudience(label, item, errors));
+    return;
+  }
+  if (typeof value === 'string') {
+    const type = normalizeFunctionRuntimeInvokeAudienceType(value);
+    if (!FUNCTION_RUNTIME_INVOKE_AUDIENCE_TYPES.has(type)) {
+      errors.push(`${label}: 不支持的 runtimeInvoke.audience 类型 "${value}"`);
+    }
+    return;
+  }
+  if (!value || typeof value !== 'object') {
+    errors.push(`${label}: runtimeInvoke.audience 必须是字符串、对象或数组`);
+    return;
+  }
+  const type = normalizeFunctionRuntimeInvokeAudienceType(value.type);
+  if (!FUNCTION_RUNTIME_INVOKE_AUDIENCE_TYPES.has(type)) {
+    errors.push(`${label}: 不支持的 runtimeInvoke.audience.type "${value.type || ''}"`);
+    return;
+  }
+  if (type === 'app_roles') {
+    const roleCodes = normalizePermissionCodeArray(value.roleCodes || value.roles);
+    if (!roleCodes.length) {
+      errors.push(`${label}: audience.type=app_roles 时必须声明 roleCodes`);
+    }
+    for (const roleCode of roleCodes) {
+      if (FUNCTION_RUNTIME_INVOKE_MAGIC_ROLE_CODES.has(roleCode.toLowerCase())) {
+        errors.push(
+          `${label}: audience.roleCodes 不支持魔法值 "${roleCode}"；请改用 authenticated/page_permission_group/scope_policy`
+        );
+      }
+    }
+  }
+  if (type === 'scope_policy') {
+    const policyCode = String(
+      value.policyCode || value.scopePolicyCode || value.dataScopePolicyCode || ''
+    ).trim();
+    if (!policyCode) {
+      errors.push(`${label}: audience.type=scope_policy 时必须声明 policyCode`);
+    }
+  }
+}
+
+function normalizeFunctionRuntimeInvokeAudienceType(value) {
+  const type = String(value || '')
+    .trim()
+    .replace(/[-\s]+/g, '_')
+    .toLowerCase();
+  if (['logged_in', 'login', 'all_authenticated'].includes(type)) {
+    return 'authenticated';
+  }
+  if (['app_role', 'roles', 'role_codes'].includes(type)) {
+    return 'app_roles';
+  }
+  if (['page_permission_groups', 'page_group', 'page_groups'].includes(type)) {
+    return 'page_permission_group';
+  }
+  if (['data_scope_policy', 'business_scope_policy'].includes(type)) {
+    return 'scope_policy';
+  }
+  return type;
+}
+
+function validateFormRuntimeWriteSettings(label, item, errors) {
+  const runtimeWrite = item.runtimeWrite || item.settings?.runtimeWrite;
+  if (runtimeWrite === undefined) return;
+  if (!runtimeWrite || typeof runtimeWrite !== 'object' || Array.isArray(runtimeWrite)) {
+    errors.push(`${label}: runtimeWrite 必须是对象`);
+    return;
+  }
+  const mode = String(runtimeWrite.mode || '').trim();
+  if (!['permission_group', 'function_only', 'public_form'].includes(mode)) {
+    errors.push(
+      `${label}: runtimeWrite.mode 只能是 permission_group、function_only 或 public_form`
+    );
+  }
+}
+
 function validateScopePermissionResources(manifest, errors, warnings) {
   const policyCodes = new Set(
     (manifest.dataScopePolicies || [])
@@ -8507,12 +8674,16 @@ async function publishFormSettingsResources(config, target, settingsItems, resul
     const code = item.code || item.formCode || item.formUuid;
     const formUuid = resolveManifestFormUuid(target.bound, item, { fallbackToCode: true });
     if (!formUuid) fail(`表单设置 ${code} 无法解析 formUuid`);
-    if (item.settings !== undefined) {
+    if (item.settings !== undefined || item.runtimeWrite !== undefined) {
+      const settings = {
+        ...(item.settings || {}),
+        ...(item.runtimeWrite !== undefined ? { runtimeWrite: item.runtimeWrite } : {}),
+      };
       await requestWithAuth(
         config,
         target.profileName,
         `/openxiangda-api/v1/apps/${encodeURIComponent(target.appType)}/forms/${encodeURIComponent(formUuid)}/settings`,
-        { method: 'POST', body: { settings: item.settings } }
+        { method: 'POST', body: { settings } }
       );
     }
     if (item.indexes !== undefined) {
@@ -11551,6 +11722,9 @@ function normalizeFunctionDefinitionJson(functionItem, definitionJson) {
     kind: definition.kind || 'app_function',
     version: definition.version || 'function_v1',
     ...(functionCode ? { functionCode: String(functionCode) } : {}),
+    ...(functionItem.runtimeInvoke !== undefined && definition.runtimeInvoke === undefined
+      ? { runtimeInvoke: functionItem.runtimeInvoke }
+      : {}),
     runtimeMode: definition.runtimeMode || 'trusted_node',
     sourceType: definition.sourceType || 'file_snapshot',
   });
@@ -11613,7 +11787,11 @@ function publicAccessPolicyEquals(bound, desired, existing) {
     String(existing.routeCode || '') === String(expected.routeCode || '') &&
     String(existing.pathPattern || '') === String(expected.pathPattern || '') &&
     stringSetEquals(existing.externalRoleCodes || [], expected.externalRoleCodes || []) &&
-    jsonEqualsForPlan(existing.grantsJson || existing.grants || {}, expected.grants || {}, desired.__dir) &&
+    jsonEqualsForPlan(
+      normalizePublicAccessGrants(bound, existing.grantsJson || existing.grants || {}),
+      expected.grants || {},
+      desired.__dir
+    ) &&
     jsonEqualsForPlan(existing.ticketConfigJson || existing.ticketConfig || {}, expected.ticketConfig || {}, desired.__dir) &&
     jsonEqualsForPlan(existing.rateLimitJson || existing.rateLimit || {}, expected.rateLimit || {}, desired.__dir) &&
     String(existing.expiresAt || '') === String(expected.expiresAt || '')

package/lib/design-gates.js

@@ -522,6 +522,9 @@ const RESOURCE_EXPLAINS = {
         version: 'function_v1',
         runtimeMode: 'trusted_node',
         sourceType: 'inline',
+        runtimeInvoke: {
+          audience: { type: 'authenticated' },
+        },
         code: 'module.exports = async () => ({ ok: true })',
       },
       status: 'active',

package/openxiangda-skills/SKILL.md

@@ -162,7 +162,7 @@ When the user provides a root domain such as `https://yida.wisejob.cn/`, use it
 - Put engineering-managed resources in `src/resources/` and use `openxiangda resource validate|plan|publish|pull`. `workspace publish` publishes workspace forms/pages first, then runs non-destructive resource upsert. Only pass `--prune` when the user explicitly wants local manifests to delete platform-side extras.
 - For repeated read-only multi-form queries or predefined dashboard metrics, create a data view manifest in `src/resources/data-views/`. Use `storageMode: "materialized"` for refreshed lists/reports that tolerate delay; use `storageMode: "live"` for bounded real-time joins where source changes must appear immediately. Use row views plus `sdk.dataView.query` for joined lists/lookups; use `viewType: "aggregate"` plus `sdk.dataView.stats` for count/sum/avg/min/max statistics. Add `indexes` only for materialized views. Do not use data views for single-form CRUD, simple linkedForm selects, writes, write-back, unbounded realtime joins, or ad-hoc BI. Read `references/data-views.md` before designing one.
 - For external APIs, create a connector manifest in `src/resources/connectors/` and call it from pages through `sdk.connector`; never put third-party API keys in page source.
-- For reusable backend logic shared by pages, automations, and workflows, create an App Function in `src/resources/functions/<functionCode>.json` plus `src/functions/<functionCode>/index.ts`. Call it from pages with `sdk.function.invoke`, from automation/workflow graphs with `function_call`, or from the runtime endpoint when the caller has app automation management permission. Current App Function MVP exposes controlled helpers such as `ctx.resources`, `ctx.form.queryOne/queryMany/getById/createOne/updateOne/updateById`, `ctx.dataView`, `ctx.connector`, `ctx.notification`, `ctx.organization`, and `ctx.platform.api`; it does not expose raw SQL or Redis. Runtime functions also receive trusted role context on `ctx.operator.roleCodes`, `ctx.operator.currentRoleCode`, `ctx.operator.hasFullAccess`, `ctx.currentUser`, and `ctx.permissions`; use these for server-side business authorization. Do not trust role codes sent in page input for sensitive actions. App Function form writes are trusted backend writes governed by declared `resources.forms` and function invocation authorization; do not grant normal users raw submit permission to internal forms just to let `ctx.form.createOne/updateOne/updateById` run.
+- For reusable backend logic shared by pages, automations, and workflows, create an App Function in `src/resources/functions/<functionCode>.json` plus `src/functions/<functionCode>/index.ts`. Call it from pages with `sdk.function.invoke`, from automation/workflow graphs with `function_call`, or from the runtime endpoint. Direct runtime invocation defaults to app automation management permission; ordinary page callers must use `definitionJson.runtimeInvoke.audience` (`authenticated`, `page_permission_group`, `app_roles`, or `scope_policy`). `roleCodes` remains only for current app-role grants; never use `"*"` or `"all-app-roles"` there. Current App Function MVP exposes controlled helpers such as `ctx.resources`, `ctx.form.queryOne/queryMany/getById/createOne/updateOne/updateById`, `ctx.dataView`, `ctx.connector`, `ctx.notification`, `ctx.organization`, and `ctx.platform.api`; it does not expose raw SQL or Redis. Runtime functions also receive trusted role context on `ctx.operator.roleCodes`, `ctx.operator.currentRoleCode`, `ctx.operator.hasFullAccess`, `ctx.currentUser`, and `ctx.permissions`; use these for server-side business authorization. Do not trust role codes sent in page input for sensitive actions. App Function form writes are trusted backend writes governed by declared `resources.forms` and function invocation authorization; do not grant normal users raw submit permission to internal forms just to let `ctx.form.createOne/updateOne/updateById` run. For internal function-only forms, publish form settings with `runtimeWrite.mode="function_only"` to close raw write endpoints.
 - For app-managed platform departments/accounts, use `sdk.organization.departments.*`, `sdk.organization.accounts.*`, `ctx.organization.departments.*`, or `ctx.organization.accounts.*`. The real current user/audit actor must hold `app:organization:manage` on the app; runtime service principals do not bypass this permission. Do not call legacy `/user` or `/department` write endpoints from apps. Do not include `password` in account updates; reset target accounts with `resetPassword`, and change the current user's password with `changeMyPassword({ oldPassword, newPassword })`.
 - For account, role, data-scope, organization-account, RBAC, or query-param authorization designs, read `references/permission-design-patterns.md` and choose a permission mode before writing forms/pages/resources. Formal backends should use platform roles, page permission groups, form permission groups, public-access grants, and App Function role/scope checks; frontend hiding is display only.
 - When a role such as 校区管理员 will create app roles, assign role members, grant role permissions, maintain permission groups, or manage organization accounts, its role manifest must declare the needed `apiPermissionCodes` such as `app:role:manage`, `app:page-permission-group:manage`, `app:form-permission-group:manage`, and `app:organization:manage`. If that administrator creates another administrator role, the new role must also declare its own `apiPermissionCodes`; permissions are not inherited from the creator.

package/openxiangda-skills/references/connector-resources.md

@@ -32,7 +32,7 @@ Notification manifests live under `src/resources/notifications/` and contain `te
 
 Data view manifests live under `src/resources/data-views/` and define read-only joined or aggregate query resources. Use `storageMode: "materialized"` for refreshed lists/reports where lag is acceptable, and `storageMode: "live"` for bounded real-time query shapes. Use row views with `sdk.dataView.query` and aggregate views with `sdk.dataView.stats`. Before generating one, confirm freshness tolerance, query bounds, and indexes for materialized filters/sort fields/dimensions/date buckets. Do not use them for single-form CRUD, simple linkedForm selects, writes, write-back, or ad-hoc BI. See `data-views.md` before generating one.
 
-App Function manifests live under `src/resources/functions/`, with source in `src/functions/<functionCode>/index.ts`. Use them for reusable server-side logic that pages, automations, and workflows can share through `sdk.function.invoke` or `function_call` nodes. App Functions expose controlled runtime helpers such as `ctx.resources`, `ctx.form.queryOne/queryMany/getById/createOne/updateOne/updateById`, `ctx.dataView`, `ctx.connector`, `ctx.notification`, `ctx.organization`, and `ctx.platform.api`; they do not expose raw SQL or Redis in the current MVP. Runtime page invocations also expose trusted role context on `ctx.operator.roleCodes`, `ctx.operator.currentRoleCode`, `ctx.operator.hasFullAccess`, `ctx.currentUser`, and `ctx.permissions`; use that context for server-side authorization, and never trust page-submitted role codes for sensitive actions. App Function form writes are trusted backend writes governed by declared `resources.forms` and function invocation authorization, not by direct page-user submit access to the target form. App Function organization writes require `app:organization:manage` on the real operator/audit actor. Use JS_CODE V2 only for node-local workflow/automation scripts.
+App Function manifests live under `src/resources/functions/`, with source in `src/functions/<functionCode>/index.ts`. Use them for reusable server-side logic that pages, automations, and workflows can share through `sdk.function.invoke` or `function_call` nodes. App Functions expose controlled runtime helpers such as `ctx.resources`, `ctx.form.queryOne/queryMany/getById/createOne/updateOne/updateById`, `ctx.dataView`, `ctx.connector`, `ctx.notification`, `ctx.organization`, and `ctx.platform.api`; they do not expose raw SQL or Redis in the current MVP. Runtime page invocations also expose trusted role context on `ctx.operator.roleCodes`, `ctx.operator.currentRoleCode`, `ctx.operator.hasFullAccess`, `ctx.currentUser`, and `ctx.permissions`; use that context for server-side authorization, and never trust page-submitted role codes for sensitive actions. Page-call grants should use `definitionJson.runtimeInvoke.audience` (`authenticated`, `page_permission_group`, `app_roles`, or `scope_policy`); `roleCodes` is only for current app-role grants and does not support `"*"` or `"all-app-roles"`. App Function form writes are trusted backend writes governed by declared `resources.forms` and function invocation authorization, not by direct page-user submit access to the target form. For internal function-only forms, publish form settings with `runtimeWrite.mode="function_only"` so raw write endpoints are closed. App Function organization writes require `app:organization:manage` on the real operator/audit actor. Use JS_CODE V2 only for node-local workflow/automation scripts.
 
 Auth manifests live under `src/resources/auth/`. Use them to enable app-level login methods and bind phone-code/CAS/custom providers to App Functions. Auth provider functions are called only by the platform auth flow. They validate external credentials and return identity assertions such as `phone`, `email`, `externalId`, or `unionId`; they must not issue tokens, set cookies, or mutate platform user/binding tables.
 

package/openxiangda-skills/references/pages/page-sdk.md

@@ -115,7 +115,7 @@ App Function source should prefer `export default async function(ctx, input) {}`
 The second argument is the `input` passed by `sdk.function.invoke`, and the
 same value is also available as `ctx.input` for compatibility.
 
-Use App Functions when the logic must run server-side and be reusable by pages, automations, or workflows. Runtime invocation requires app automation management permission by default. To let ordinary app users call a function from a page, declare the allowed current app roles in `definitionJson.runtimeInvoke.roleCodes`; keep sensitive admin-only functions without broad grants. Inside the function, authorize sensitive actions with trusted runtime context such as `ctx.operator.roleCodes`, `ctx.operator.currentRoleCode`, `ctx.operator.hasFullAccess`, `ctx.currentUser`, or `ctx.permissions`; do not trust role codes sent in the page input. When the function writes forms with `ctx.form.createOne/updateOne/updateById`, treat the write as a trusted backend operation over declared `resources.forms`; do not open direct submit permission on internal forms just for that page action.
+Use App Functions when the logic must run server-side and be reusable by pages, automations, or workflows. Runtime invocation requires app automation management permission by default. To let ordinary app users call a function from a page, declare `definitionJson.runtimeInvoke.audience` with `authenticated`, `page_permission_group`, `app_roles`, or `scope_policy`; use `roleCodes` only for current app-role grants. Do not use `"*"` or `"all-app-roles"` as role codes. Inside the function, authorize sensitive actions with trusted runtime context such as `ctx.operator.roleCodes`, `ctx.operator.currentRoleCode`, `ctx.operator.hasFullAccess`, `ctx.currentUser`, or `ctx.permissions`; do not trust role codes sent in the page input. When the function writes forms with `ctx.form.createOne/updateOne/updateById`, treat the write as a trusted backend operation over declared `resources.forms`; do not open direct submit permission on internal forms just for that page action.
 
 Organization management:
 

package/openxiangda-skills/references/resource-manifest-cheatsheet.md

@@ -571,7 +571,10 @@ JS_CODE 调用：`ctx.notification.sendByType({ ... })`。允许的 channels：`
     "runtimeMode": "trusted_node",
     "timeout": 30000,
     "runtimeInvoke": {
-      "roleCodes": ["union_admin", "member"]
+      "audience": {
+        "type": "page_permission_group",
+        "resourceCodes": ["member_portal_pages"]
+      }
     },
     "sourceFile": {
       "localPath": "src/functions/reservation_reminder_summary/index.ts"
@@ -643,7 +646,7 @@ const result = await sdk.function.invoke("reservation_reminder_summary", {
 }
 ```
 
-适用边界：可复用后端业务逻辑、跨页面/自动化/流程共享的查询编排、连接器调用、通知编排、受控平台 API 调用。App Function 支持 `ctx.form.queryOne/queryMany/getById/createOne/updateOne/updateById`、`ctx.dataView`、`ctx.connector`、`ctx.notification`、`ctx.platform.api` 等受控 helper，当前 MVP 不暴露原始 SQL/Redis。`ctx.form.createOne/updateOne/updateById` 是后端受控写入，权限边界是 function manifest 的 `resources.forms` 和函数调用授权，不是页面用户对目标表单的直接提交权限；内部业务表单不要为了函数写入而开放普通用户原始 submit。运行时接口默认需要应用自动化管理权限；普通用户页面要调用时，在 `definitionJson.runtimeInvoke.roleCodes` 显式声明允许的当前应用角色。自动化/流程内部调用走服务端上下文，不受页面运行时授权限制。
+适用边界：可复用后端业务逻辑、跨页面/自动化/流程共享的查询编排、连接器调用、通知编排、受控平台 API 调用。App Function 支持 `ctx.form.queryOne/queryMany/getById/createOne/updateOne/updateById`、`ctx.dataView`、`ctx.connector`、`ctx.notification`、`ctx.platform.api` 等受控 helper，当前 MVP 不暴露原始 SQL/Redis。`ctx.form.createOne/updateOne/updateById` 是后端受控写入，权限边界是 function manifest 的 `resources.forms` 和函数调用授权，不是页面用户对目标表单的直接提交权限；内部业务表单不要为了函数写入而开放普通用户原始 submit。运行时接口默认需要应用自动化管理权限；普通用户页面要调用时，用 `definitionJson.runtimeInvoke.audience` 声明 `authenticated`、`page_permission_group`、`app_roles` 或 `scope_policy`，不要把 `"*"`、`"all-app-roles"` 写进 `roleCodes`。自动化/流程内部调用走服务端上下文，不受页面运行时授权限制。若表单只能由函数/流程写入，在 `src/resources/settings/forms/<formCode>.json` 设置 `runtimeWrite.mode="function_only"` 关闭原始写入接口。
 
 ## 5. Workflow — `src/resources/workflows/<code>/workflow.json`（manifest）+ `src/workflows/<code>/workflow.ts`（代码优先）
 
@@ -831,7 +834,10 @@ permission codes.
   "code": "customer",
   "settings": {
     "submitButtonText": "提交",
-    "successMessage": "提交成功"
+    "successMessage": "提交成功",
+    "runtimeWrite": {
+      "mode": "permission_group"
+    }
   },
   "indexes": [
     { "fields": ["customerCode"], "unique": true },
@@ -841,6 +847,8 @@ permission codes.
 }
 ```
 
+`runtimeWrite.mode` 可选 `permission_group`、`function_only`、`public_form`。内部业务表单需要强制走 App Function / Workflow 时使用 `function_only`；这会关闭页面原始写入接口，但不影响 `ctx.form.createOne/updateOne/updateById` 等受信后端写入。
+
 `publicAccess` 表单 setting 只用于旧 `sy-lowcode-view` 兼容。新 React SPA 公开页面必须使用 `src/resources/routes/` + `src/resources/public-access/` + `OpenXiangdaProvider` + `OpenXiangdaPageProvider` + `PublicAccessGate`。
 
 ## 12. Menu — `src/resources/menus/<code>.json`

package/openxiangda-skills/skills/openxiangda-workflow-automation/SKILL.md

@@ -103,7 +103,7 @@ Use `workflow pull` to inspect the live definition. Use `workflow list --json` a
 
 JS_CODE is the backend execution escape hatch for workflow and automation. Use it when the logic must run on the server after a backend trigger, such as a fixed cron schedule, a form date-field schedule, a form submit/update/delete/field-change event, or a workflow approval/process event. It is appropriate for cross-form data queries, create/update/batch update operations, process termination, platform API calls, external HTTP calls, and complex orchestration that the frontend cannot handle reliably.
 
-App Function is the reusable backend execution model. Use it when the logic should be called by custom pages, multiple automations, workflows, or the runtime API. Source lives in `src/functions/<functionCode>/index.ts`; manifest lives in `src/resources/functions/<functionCode>.json`. Call it from pages with `sdk.function.invoke(code, { input })`, from graph definitions with `function_call`, or from the runtime endpoint `/:appType/v1/functions/:code/invoke.json` when the caller has app automation management permission. Prefer `export default async function(ctx, input) {}` for App Function source; the second argument is the invoke input and the same value is available as `ctx.input`. Current MVP exposes controlled helpers only and does not expose raw SQL or Redis. `ctx.form.createOne/updateOne/updateById` are trusted backend writes governed by declared `resources.forms` and function invocation authorization; keep internal forms closed to direct user submit unless the business explicitly needs raw form submission.
+App Function is the reusable backend execution model. Use it when the logic should be called by custom pages, multiple automations, workflows, or the runtime API. Source lives in `src/functions/<functionCode>/index.ts`; manifest lives in `src/resources/functions/<functionCode>.json`. Call it from pages with `sdk.function.invoke(code, { input })`, from graph definitions with `function_call`, or from the runtime endpoint `/:appType/v1/functions/:code/invoke.json`. Direct runtime invocation defaults to app automation management permission; ordinary page callers must declare `definitionJson.runtimeInvoke.audience` (`authenticated`, `page_permission_group`, `app_roles`, or `scope_policy`). Prefer `export default async function(ctx, input) {}` for App Function source; the second argument is the invoke input and the same value is available as `ctx.input`. Current MVP exposes controlled helpers only and does not expose raw SQL or Redis. `ctx.form.createOne/updateOne/updateById` are trusted backend writes governed by declared `resources.forms` and function invocation authorization; keep internal forms closed to direct user submit unless the business explicitly needs raw form submission. For internal function-only forms, set form settings `runtimeWrite.mode="function_only"` instead of relying only on missing submit permission groups.
 
 For new AI-authored automations, prefer code-first `automation_code_ts` resources instead of visual v3 graph definitions. Put the source in `src/automations/<resourceCode>/index.ts`, define `definition.code.json` with `kind: "automation_code_ts"`, and provide `preview.json` for read-only frontend display. Use `ctx.logger.debug/info/warn/error(message, data?)` at every important step; OpenXiangda can inspect logs with `automation executions`, `automation logs`, and `automation diagnose`.
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "openxiangda",
-  "version": "1.0.143",
+  "version": "1.0.144",
   "description": "OpenXiangda CLI, workspace build tools, runtime SDK, and form components.",
   "private": false,
   "bin": {