openxiangda 1.0.77 → 1.0.78

package/openxiangda-skills/skills/openxiangda-page/SKILL.md

@@ -34,6 +34,8 @@ openxiangda workspace publish --profile <name> --page <pageCode>
 - ✅ Split complex pages into `domain/`, `shared/services/`, `shared/hooks/`, `components/`, route/config files, `styles.css` (see `references/best-practices.md` and `references/architecture-patterns.md`).
 - ✅ List/detail/CRUD pages: follow `DataManagementList` pattern from `references/architecture-patterns.md`. Pagination + structured `filterGroup` + `OR`. Never fetch huge `pageSize` and filter in browser.
 - ✅ For external APIs use `src/resources/connectors/<code>.json` + `sdk.connector.invoke()`; for joined read-only lists use row data views + `sdk.dataView.query`; for stable dashboard metrics use aggregate data views + `sdk.dataView.stats`.
+- ✅ Choose data view `storageMode` deliberately: `materialized` for refreshed reports/lists that tolerate delay, `live` for bounded real-time multi-form reads.
+- ✅ For reusable backend orchestration use App Function (`src/functions/<functionCode>/index.ts` + `src/resources/functions/<functionCode>.json`) and call `sdk.function.invoke(code, { input })`; keep page components out of multi-table business orchestration.
 - ✅ Filters, search bars, modal forms, drawers, and inline edits use platform components for platform data fields, otherwise `antd` / `antd-mobile` controls.
 - ❌ Single-file giant pages. Split per `references/best-practices.md`.
 - ❌ Hardcoded `/view/...&isRenderNav=false` URLs scattered through page code; use the runtime navigation helper.
@@ -90,28 +92,29 @@ openxiangda page publish dashboard \
 
 Read these references only when editing page code:
 
-- `../../references/pages/workspace-structure.md`
-- `../../references/pages/app-shell.md` — formal backend / PC portal / mobile portal entry pattern. Read before creating any user-facing main entry or admin console.
-- `../../references/best-practices.md` — initialized examples for modular pages, status lifecycles, role governance, high-performance queries, portal shells, and interactive workbenches. Read before scaffolding complex pages or data management pages.
-- `../../references/pages/page-sdk.md`
-- `../../references/notifications.md` — notification resources and `sdk.notification` usage. Read before adding reminders, alerts, or message templates to a page.
-- `../../references/pages/publish-flow.md`
-- `../../references/style-system.md` — style isolation defaults, Tailwind/CSS guidance, and legacy namespace compatibility. Read before writing substantial page CSS or Tailwind classes.
-- `../../references/architecture-patterns.md` — CRUD data flow, `DataManagementList` pattern, and recommended `src/pages/<pageCode>/` layout. Read before scaffolding a new page or list view.
-- `../../references/component-guide.md` — platform component first, `antd` / `antd-mobile` fallback, and native-control ban for AI-authored app code. Read before introducing a new component.
-- `../../references/troubleshooting.md` — known failure modes (missing styles, `options` runtime errors, broken option rendering, etc.) and their fixes. Read when something does not behave as expected.
+- `references/pages/workspace-structure.md`
+- `references/pages/app-shell.md` — formal backend / PC portal / mobile portal entry pattern. Read before creating any user-facing main entry or admin console.
+- `references/best-practices.md` — initialized examples for modular pages, status lifecycles, role governance, high-performance queries, portal shells, and interactive workbenches. Read before scaffolding complex pages or data management pages.
+- `references/pages/page-sdk.md`
+- `references/notifications.md` — notification resources and `sdk.notification` usage. Read before adding reminders, alerts, or message templates to a page.
+- `references/pages/publish-flow.md`
+- `references/style-system.md` — style isolation defaults, Tailwind/CSS guidance, and legacy namespace compatibility. Read before writing substantial page CSS or Tailwind classes.
+- `references/architecture-patterns.md` — CRUD data flow, `DataManagementList` pattern, and recommended `src/pages/<pageCode>/` layout. Read before scaffolding a new page or list view.
+- `references/component-guide.md` — platform component first, `antd` / `antd-mobile` fallback, and native-control ban for AI-authored app code. Read before introducing a new component.
+- `references/troubleshooting.md` — known failure modes (missing styles, `options` runtime errors, broken option rendering, etc.) and their fixes. Read when something does not behave as expected.
 
 ## Rules
 
 - Keep `pageCode` stable and use it as the local logical key.
 - Formal user-facing entries such as admin consoles, PC portals, and mobile portals must be app-shell code pages. Declare `entry: { mode: "app-shell", hidePlatformNav: true, defaultRoute: "<home-route>" }` in `page.config.ts`.
-- Do not generate single-file large pages. Split complex code pages into `domain/`, `shared/services/`, `shared/hooks/`, shared/page-local `components/`, route/config files, and `styles.css` as described in `../../references/best-practices.md`.
+- Do not generate single-file large pages. Split complex code pages into `domain/`, `shared/services/`, `shared/hooks/`, shared/page-local `components/`, route/config files, and `styles.css` as described in `references/best-practices.md`.
 - Keep view code thin. Page components call hooks/services; business rules, state transition rules, permission predicates, and query builders live outside TSX and are reusable by PC and mobile pages.
 - All visible page copy must be end-user-facing business text. Do not put developer explanations, implementation notes, schema descriptions, or "this module is generated by..." text into sections, cards, alerts, empty states, tooltips, or helper copy.
 - Store live `pageId`, `routeKey`, and `legacyFormUuid` under the current profile only.
 - Use `openxiangda/runtime` for platform data access instead of hardcoding backend URLs in page code.
 - For reminders, alerts, and business messages, declare `src/resources/notifications/` first and call `sdk.notification`; do not hardcode notification API URLs.
-- Before hand-writing mature UI behavior, consult `../../references/component-guide.md` and use established libraries: platform components for platform data fields, antd/antd-mobile for controls and overlays, ECharts for charts, GSAP for complex animation timelines, and maintained packages such as dnd-kit for drag/drop. Do not rebuild mature controls with raw DOM/native inputs.
+- For backend business logic shared by pages, automations, or workflows, declare an App Function and call `sdk.function.invoke`; do not duplicate the same multi-form query/connector/notification orchestration in page code.
+- Before hand-writing mature UI behavior, consult `references/component-guide.md` and use established libraries: platform components for platform data fields, antd/antd-mobile for controls and overlays, ECharts for charts, GSAP for complex animation timelines, and maintained packages such as dnd-kit for drag/drop. Do not rebuild mature controls with raw DOM/native inputs.
 - Named imports from `@ant-design/icons` are supported by the `openxiangda` workspace build proxy, which enumerates icon module exports at runtime.
 - Publish through `openxiangda workspace publish --profile <name>` unless there is a specific repair reason to call `page publish` directly.
 - After editing one code page, publish with `--page <pageCode>` instead of triggering all forms/pages. Use `--changed --dry-run` before `--changed` when git touched several modules.
@@ -119,11 +122,11 @@ Read these references only when editing page code:
 - Do not scatter hardcoded `/view/...&isRenderNav=false` URLs through page code. Use the runtime navigation API or the local route helper generated for the app shell.
 - Platform menus should bind only the formal app-shell code page for user-facing entry points. Original forms, workflows, and native view pages may remain as development / maintenance resources or permission targets, but should not become the product navigation shell.
 - For prod, explicitly run with `--profile prod`; never rely on the current profile for release operations.
-- Follow the style system in `../../references/style-system.md`: default to native Tailwind utilities and arbitrary values for business pages (`bg-white`, `border`, `border-slate-200`, `text-slate-600`, `grid-cols-[240px_1fr]`, etc.). New pages default to `cssIsolation: "none"` and do not need `.sy-app-workspace`; keep namespace/shadow handling only for legacy pages that explicitly configure it. Do not treat platform token classes as the default authoring pattern, and do not use shadcn token classes such as `bg-card`, `text-muted-foreground`, or `text-foreground` unless the workspace explicitly configures them.
-- For list / detail / CRUD pages, follow `../../references/architecture-patterns.md` (e.g. `DataManagementList`) before writing custom data-fetching loops.
+- Follow the style system in `references/style-system.md`: default to native Tailwind utilities and arbitrary values for business pages (`bg-white`, `border`, `border-slate-200`, `text-slate-600`, `grid-cols-[240px_1fr]`, etc.). New pages default to `cssIsolation: "none"` and do not need `.sy-app-workspace`; keep namespace/shadow handling only for legacy pages that explicitly configure it. Do not treat platform token classes as the default authoring pattern, and do not use shadcn token classes such as `bg-card`, `text-muted-foreground`, or `text-foreground` unless the workspace explicitly configures them.
+- For list / detail / CRUD pages, follow `references/architecture-patterns.md` (e.g. `DataManagementList`) before writing custom data-fetching loops.
 - Query pages must use pagination with structured conditions. Do not fetch a large `pageSize` and filter in the browser; avoid default `searchKeyWord`, and build multi-field fuzzy search with explicit `filterGroup` + `OR`.
-- Pick components per `../../references/component-guide.md`: prefer the platform component, fall back to Ant Design / antd-mobile wrappers, and only build a custom component when neither fits. In app/workspace page code, do not emit raw `<input>`, `<select>`, `<textarea>`, file inputs, hand-written pickers, or hand-written uploaders.
-- When a page misbehaves (lost styles, `options is undefined`, option labels showing raw values, etc.), consult `../../references/troubleshooting.md` before patching symptoms.
+- Pick components per `references/component-guide.md`: prefer the platform component, fall back to Ant Design / antd-mobile wrappers, and only build a custom component when neither fits. In app/workspace page code, do not emit raw `<input>`, `<select>`, `<textarea>`, file inputs, hand-written pickers, or hand-written uploaders.
+- When a page misbehaves (lost styles, `options is undefined`, option labels showing raw values, etc.), consult `references/troubleshooting.md` before patching symptoms.
 - For custom portal pages and business modals, do not temporarily embed a single `FormProvider` field component from the standard form runtime. If a standard component is required, navigate to a full standard form page or render a complete `StandardFormPage` inside a dedicated carrier route.
 - Keep PC and mobile portal styles separate. Do not share one form UI implementation across both viewports unless the surrounding shell, modal layer, date picker, and bottom-sheet behavior have been tested in both contexts.
 - After introducing Ant Design overlays, date/datetime fields, or mobile bottom-sheet selectors, verify that global button, modal, picker, and sheet styles do not leak into the host business page.

package/openxiangda-skills/skills/openxiangda-permission-settings/SKILL.md

@@ -146,7 +146,7 @@ Do not store platform-specific public access IDs locally. The CLI resolves by `a
 
 ## References
 
-- Permission model and examples: `../../references/permissions-settings.md`
-- Dynamic role governance and data-isolation pattern: `../../references/best-practices.md`
-- Profile-isolated IDs: `../../references/workspace-state.md`
-- API fields: `../../references/openxiangda-api.md`
+- Permission model and examples: `references/permissions-settings.md`
+- Dynamic role governance and data-isolation pattern: `references/best-practices.md`
+- Profile-isolated IDs: `references/workspace-state.md`
+- API fields: `references/openxiangda-api.md`

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

@@ -1,6 +1,6 @@
 ---
 name: openxiangda-workflow-automation
-description: Build / validate / publish / enable / inspect OpenXiangda **workflows** (审批流程 / approval / approve / reject / transfer / withdraw, v3 graph, JS_CODE trusted_node) and **automations** (自动化 / 集成 / 定时任务 / cron / form data submit/update/delete events, form field change, workflow task / process events, message notifications). Includes architecture boundary between workflow and normal status-machine forms, code-first workflows (`src/workflows/<code>/workflow.ts`) and code-first automations (`src/automations/<code>/index.ts`). Trigger on 审批 / 流程 / workflow / approval / process / 节点 / 并行分支 / 条件分支 / 代办 / 转交 / 撤回 / 驳回 / 自动化 / automation / cron / 定时 / 提交后 / 字段变更 / JS_CODE / trusted_node / src/js-code-nodes.
+description: Build / validate / publish / enable / inspect OpenXiangda **workflows** (审批流程 / approval / approve / reject / transfer / withdraw, v3 graph, JS_CODE trusted_node, App Function function_call) and **automations** (自动化 / 集成 / 定时任务 / cron / form data submit/update/delete events, form field change, workflow task / process events, message notifications). Includes architecture boundary between workflow and normal status-machine forms, code-first workflows (`src/workflows/<code>/workflow.ts`), code-first automations (`src/automations/<code>/index.ts`), JS_CODE node scripts, and reusable App Functions (`src/functions/<code>/index.ts`). Trigger on 审批 / 流程 / workflow / approval / process / 节点 / 并行分支 / 条件分支 / 代办 / 转交 / 撤回 / 驳回 / 自动化 / automation / cron / 定时 / 提交后 / 字段变更 / JS_CODE / trusted_node / App Function / function_call / src/js-code-nodes / src/functions.
 ---
 
 # OpenXiangda Workflow And Automation
@@ -10,6 +10,7 @@ description: Build / validate / publish / enable / inspect OpenXiangda **workflo
 - User asks for **approval workflows / 审批 / 流程 / approve / reject / transfer / withdraw / process records / approval-node side effects**.
 - User asks for **automation / 自动化 / cron / 定时 / form-data-submitted/updated/deleted / field-changed / workflow-task-approved / message notification triggers**.
 - User asks for **JS_CODE backend script** (cross-form query, batch update, terminate process, external HTTP, complex orchestration that frontend can't handle).
+- User asks for **App Function / function_call** reusable backend logic that pages, automations, and workflows should share.
 - User wants **code-first workflow / automation** (TypeScript source under `src/workflows/` or `src/automations/`).
 
 ## Boundary — workflow vs. status field
@@ -22,11 +23,12 @@ Create a workflow only when the scenario has **real approval semantics**: approv
 
 - ✅ New AI-authored automations: prefer **code-first** `automation_code_ts` (`src/automations/<code>/index.ts` + `definition.code.json` + `preview.json`).
 - ✅ New AI-authored workflows that don't need canvas editing: prefer **code-first** `src/workflows/<code>/workflow.ts` using `openxiangda/workflow`.
+- ✅ Reusable backend business logic: prefer **App Function** (`src/functions/<functionCode>/index.ts` + `src/resources/functions/<functionCode>.json`), then call it from page `sdk.function.invoke` or automation/workflow `function_call`.
 - ✅ JS_CODE V2 trusted_node: source in TypeScript under `sy-lowcode-app-workspace/src/js-code-nodes/<scriptCode>/index.ts`. Run `pnpm build-js-code --script <code>` (validates with `tsc` first).
 - ✅ Use `trigger_v2` for new automation triggers; CLI fills root `appType` / `formUuid` from active profile when `--form-code` is provided.
 - ✅ Use logical `workflowCode` / `automationCode` locally; live IDs are profile-isolated under `.openxiangda/state.json`.
 - ✅ `ctx.logger.debug/info/warn/error(message, data?)` at every important step — inspect via `automation executions` / `automation logs` / `automation diagnose`.
-- ❌ JS_CODE for simple UI interactions, ordinary form validation, or display-only logic — those belong to a normal React code page.
+- ❌ JS_CODE for simple UI interactions, ordinary form validation, display-only logic, or backend logic that should be reused outside one graph node.
 - ❌ Workflow definitions for non-approval status changes — use a status field instead.
 - ❌ Copy `workflowId` / `automationId` across profiles. Always create/bind separately for each profile.
 - ❌ Inline large JS code blobs in v3 JSON for new work — use trusted_node TypeScript snapshots.
@@ -76,6 +78,8 @@ Use `workflow pull` to inspect the live definition. Use logical workflow codes l
 
 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. Current MVP exposes controlled helpers only and does not expose raw SQL or Redis.
+
 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`.
 
 For new AI-authored workflows where users do not need canvas editing, prefer compile-time `workflow.ts` using `openxiangda/workflow`. The CLI compiles it to v3 `definitionJson` and `preview.json`; the backend still runs the normal workflow engine for approval tasks, copy tasks, callback waits, branch advancement, and process records.
@@ -112,8 +116,23 @@ Inside the TypeScript script, prefer `export default async function (ctx) {}` or
 - Data/process methods: `ctx.methods.queryOneData`, `queryManyData`, `updateOneData`, `updateDataByFormInstanceId`, `updateManyData`, `createOneData`, `terminateProcess`, and `getAllParentDepartments`.
 - Notification bridge: `ctx.notification.sendByType`, `batchSendByType`, `findConfig`, and `previewTemplate`. Declare templates in `src/resources/notifications/` before using custom `notificationType`.
 - Platform API bridge: `ctx.platform.api.get/post/put/patch/delete/request` for `/openxiangda-api/v1`.
+- Resource helpers: `ctx.resources.resolveForm/resolveDataView/resolveConnector`, `ctx.form.queryMany/createOne/updateOne/updateById`, `ctx.dataView.query/stats`, and `ctx.connector.call/invoke`.
 - Node runtime helpers: `require`, `process`, `Buffer`, `ctx.utils`, `ctx.utils.http`, and `ctx.console`.
 
+Example `function_call` node:
+
+```json
+{
+  "id": "call_summary",
+  "type": "function_call",
+  "data": {
+    "functionCode": "reservation_reminder_summary",
+    "input": { "scope": "today" },
+    "saveResponseTo": "summary"
+  }
+}
+```
+
 ## Automation Flow
 
 New automation triggers must use `trigger_v2`.
@@ -147,9 +166,9 @@ Use `automation disable` before risky edits. Published automations create a draf
 
 ## References
 
-- Best-practice architecture and status-flow boundary: `../../references/best-practices.md`
-- Workflow v3 JSON: `../../references/workflow-v3.md`
-- Automation v3 JSON and triggers: `../../references/automation-v3.md`
-- Notification resources and runtime calls: `../../references/notifications.md`
-- API fields: `../../references/openxiangda-api.md`
-- Profile-isolated IDs: `../../references/workspace-state.md`
+- Best-practice architecture and status-flow boundary: `references/best-practices.md`
+- Workflow v3 JSON: `references/workflow-v3.md`
+- Automation v3 JSON and triggers: `references/automation-v3.md`
+- Notification resources and runtime calls: `references/notifications.md`
+- API fields: `references/openxiangda-api.md`
+- Profile-isolated IDs: `references/workspace-state.md`

package/package.json

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

package/packages/sdk/dist/runtime/index.cjs

@@ -2070,6 +2070,25 @@ var createPageSdk = (context) => {
       });
     }
   };
+  const appFunction = {
+    invoke: (code, params = {}) => {
+      const functionCode = String(code || "").trim();
+      if (!functionCode) {
+        throw new Error("\u5E94\u7528\u51FD\u6570 code \u4E0D\u80FD\u4E3A\u7A7A");
+      }
+      return request({
+        path: buildAppPath(
+          context,
+          params.appType,
+          `/v1/functions/${encodePathSegment(functionCode)}/invoke.json`
+        ),
+        method: "post",
+        body: {
+          input: params.input
+        }
+      });
+    }
+  };
   const notification = {
     sendByType: (params) => request({
       path: buildOpenXiangdaAppPath(
@@ -2135,6 +2154,7 @@ var createPageSdk = (context) => {
     process: process2,
     notification,
     dataView,
+    function: appFunction,
     dataSource: {
       run: async (name, params = {}) => {
         const descriptor = (context.page.dataSources || []).find(