openxiangda 1.0.76 → 1.0.78

package/openxiangda-skills/references/automation-v3.md

@@ -254,6 +254,22 @@ Supported node types:
 
 Use trusted Node JS_CODE nodes for AI/admin automation logic that runs after an automation trigger. Typical cases include scheduled data cleanup, date-field reminders, cross-form synchronization after submit/update/delete, workflow-completed follow-up writes, calling internal platform APIs, calling external HTTP services, and other backend-only orchestration.
 
+For reusable backend logic that should be shared by pages, multiple automations, and workflows, prefer an App Function under `src/functions/<functionCode>/index.ts` plus `src/resources/functions/<functionCode>.json`. Automation graphs can call it with a `function_call` node:
+
+```json
+{
+  "id": "call_summary",
+  "type": "function_call",
+  "data": {
+    "functionCode": "reservation_reminder_summary",
+    "input": { "scope": "today" },
+    "saveResponseTo": "summary"
+  }
+}
+```
+
+Use JS_CODE V2 when the script is local to one automation graph node.
+
 ```json
 {
   "id": "sync_customer",
@@ -275,7 +291,7 @@ Author source in `sy-lowcode-app-workspace/src/js-code-nodes/<scriptCode>/index.
 
 The backend runs the snapshot in the trusted Node runtime, applies the node timeout (`30000` ms by default), stores execution logs, and writes the returned value to the node output and `variables.node_<nodeId>`. Scripts may use `export default async function (ctx) {}`, `module.exports = async (ctx) => {}`, `require`, `process`, `Buffer`, arbitrary HTTP, and `platform.api` for `/openxiangda-api/v1`.
 
-Runtime context includes `ctx.triggerEvent`, `ctx.formData`, `ctx.workflowData`, `ctx.operator`, `ctx.app`, `ctx.variables`, and `ctx.node`. Data/process bridge methods include `ctx.methods.queryOneData`, `queryManyData`, `updateOneData`, `updateDataByFormInstanceId`, `updateManyData`, `createOneData`, `terminateProcess`, and `getAllParentDepartments`.
+Runtime context includes `ctx.triggerEvent`, `ctx.formData`, `ctx.workflowData`, `ctx.operator`, `ctx.app`, `ctx.variables`, and `ctx.node`. Prefer the higher-level resource helpers when available: `ctx.resources.resolveForm/resolveDataView/resolveConnector`, `ctx.form.queryMany/createOne/updateOne/updateById`, `ctx.dataView.query/stats`, `ctx.connector.call/invoke`, `ctx.notification.*`, and `ctx.platform.api.*`. Legacy data/process bridge methods remain available as `ctx.methods.queryOneData`, `queryManyData`, `updateOneData`, `updateDataByFormInstanceId`, `updateManyData`, `createOneData`, `terminateProcess`, and `getAllParentDepartments`.
 
 Code automation also exposes `ctx.logger.debug/info/warn/error(message, data?)`. AI-authored code should log input parsing, query conditions, external calls, writes, branch decisions, and caught errors. Logs are stored as full raw execution data by default. Use CLI diagnosis commands:
 

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

@@ -11,6 +11,7 @@ Common folders:
 - `workflows`
 - `automations`
 - `data-views`
+- `functions`
 - `permissions/page-groups`
 - `permissions/form-groups`
 - `settings/forms`
@@ -28,7 +29,9 @@ Connector manifests use stable `code` values. The platform maps connector `code`
 
 Notification manifests live under `src/resources/notifications/` and contain `templates` plus `typeConfigs`. See `notifications.md` before generating reminders or message templates.
 
-Data view manifests live under `src/resources/data-views/` and define read-only materialized views for repeated multi-form joins or fixed aggregate statistics. Use row views with `sdk.dataView.query` for joined list/report/lookup sources, and aggregate views with `sdk.dataView.stats` for dashboard metrics where refresh lag is acceptable. Before generating one, confirm freshness tolerance and add indexes for common filters, sort fields, dimensions, and date buckets. Do not use them for single-form CRUD, simple linkedForm selects, real-time writes, write-back, or ad-hoc BI. See `data-views.md` before generating one.
+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`, `ctx.dataView`, `ctx.connector`, `ctx.notification`, and `ctx.platform.api`; they do not expose raw SQL or Redis in the current MVP. Use JS_CODE V2 only for node-local workflow/automation scripts.
 
 ```json
 {

package/openxiangda-skills/references/data-views.md

@@ -1,6 +1,6 @@
 # Data View Resources
 
-Data views are OpenXiangda-managed read-only PostgreSQL materialized views. They turn repeated multi-form joins and predefined aggregate statistics into published resources under `src/resources/data-views/`.
+Data views are OpenXiangda-managed read-only query resources under `src/resources/data-views/`. They can run as PostgreSQL materialized views (`storageMode: "materialized"`, the default) or as live logical views (`storageMode: "live"`). Use them to publish repeated multi-form joins and predefined aggregate statistics as reusable app resources.
 
 Use a data view when the app needs read-only joined data from multiple forms, such as:
 
@@ -10,13 +10,14 @@ Use a data view when the app needs read-only joined data from multiple forms, su
 - Dashboard statistics such as monthly ticket count, order amount by customer, or task count by status.
 - Reusable lookup or report data consumed by several pages or automations.
 - Large list pages where repeated client-side cross-form joins would be slow or inconsistent.
+- Real-time multi-form reads where the query shape is fixed and the source data volume is bounded (`storageMode: "live"`).
 
 Do not use a data view for:
 
 - Single-form CRUD. Use `sdk.form.advancedSearch`, form pages, or `DataManagementList`.
 - Simple one-form dropdown options. Use `SelectField` with `optionSource.type: "linkedForm"`.
 - Writes or write-back. Data views are read-only.
-- Strong real-time views after every form update. Data views update after manual or scheduled refresh.
+- Heavy real-time joins that cannot be paginated, indexed, filtered, or otherwise bounded.
 - Raw SQL, incremental refresh, source-table trigger refresh, ad-hoc BI/pivot/window analysis, or write-heavy realtime dashboards.
 
 ## Authoring
@@ -25,8 +26,13 @@ Place manifests in `src/resources/data-views/*.json`. Use logical `formCode` val
 
 Two view types are supported:
 
-- `viewType: "row"` or omitted: row-level joined materialized view using `select`.
-- `viewType: "aggregate"`: grouped statistics materialized view using `dimensions` and `measures`; query it with `stats`.
+- `viewType: "row"` or omitted: row-level joined view using `select`.
+- `viewType: "aggregate"`: grouped statistics view using `dimensions` and `measures`; query it with `stats`.
+
+Two storage modes are supported:
+
+- `storageMode: "materialized"` or omitted: create a PostgreSQL materialized view. Results may be stale until manual or scheduled refresh. Use `indexes` for common filters, sort fields, aggregate dimensions, and date buckets.
+- `storageMode: "live"`: do not create a materialized view. Every query is compiled and executed against source forms in real time. `indexes` are ignored and refresh APIs do not apply. Use it only for bounded real-time query shapes.
 
 Row view example:
 
@@ -34,6 +40,7 @@ Row view example:
 {
   "code": "ticket_with_customer",
   "name": "Ticket With Customer",
+  "storageMode": "materialized",
   "base": { "formCode": "service_ticket", "alias": "ticket" },
   "joins": [
     {
@@ -74,6 +81,7 @@ Aggregate statistics example:
   "code": "ticket_stats_by_customer",
   "name": "Ticket Stats By Customer",
   "viewType": "aggregate",
+  "storageMode": "materialized",
   "base": { "formCode": "service_ticket", "alias": "ticket" },
   "joins": [
     {
@@ -144,9 +152,11 @@ Filters:
 
 Refresh:
 
+- Refresh applies only to materialized data views.
 - `manual` means refresh only when an administrator runs refresh or the resource is recreated.
 - `scheduled` uses cron, for example `0 */10 * * * *`.
-- Query results may be stale. Show or inspect `lastRefreshedAt` when freshness matters.
+- Materialized query results may be stale. Show or inspect `lastRefreshedAt` when freshness matters.
+- Live data views have no refresh state; `lastRefreshedAt` is `null` and refresh requests should be rejected.
 - Do not choose a high-frequency schedule by default. Ask or infer how stale the data may be before setting `scheduled`.
 
 Indexes:
@@ -159,11 +169,12 @@ Indexes:
 
 ## Performance And Freshness
 
-Data views move expensive joins and aggregations from page runtime to materialized-view refresh time. They reduce repeated page pressure only when the view shape, refresh cadence, and indexes are chosen deliberately.
+Materialized data views move expensive joins and aggregations from page runtime to refresh time. Live data views keep results current by executing the same declared query shape on each request. Both modes reduce repeated page code complexity only when the view shape, data scope, and query bounds are chosen deliberately.
 
 Before creating a data view, confirm these points:
 
 - **Freshness tolerance**: ask whether users need near-real-time data, 10-30 minute freshness, hourly/daily reports, or manual snapshots.
+- **Storage mode**: use `materialized` for read-heavy reports that tolerate refresh lag; use `live` for bounded real-time joins where source-table changes must appear immediately.
 - **Query shape**: list the fields users will filter, sort, group, or drill down by. These should become output aliases and usually indexes.
 - **Data scope**: if the business only needs active, recent, or in-scope records, put that rule in definition `where` so old/source-irrelevant rows are filtered before materialization.
 - **Visible fields**: output only fields the page or permission rules need. Use hidden scope aliases for data permissions when needed, but do not build one huge catch-all view.
@@ -174,11 +185,12 @@ Refresh cadence guidance:
 - Use `scheduled` every 10-30 minutes for normal dashboards, joined report lists, and recurring management views.
 - Use hourly or daily schedules for leadership reports, historical statistics, and large aggregate views.
 - Avoid intervals below 5 minutes unless the user explicitly confirms the time sensitivity and expected source-table volume. High-frequency refreshes can pressure both source tables and the materialized view.
-- For strong real-time behavior after each form save, do not use a data view; query the source form directly or design a different backend workflow.
+- For strong real-time behavior after each form save, use `storageMode: "live"` only when the query is bounded. If the logic includes writes, side effects, raw platform orchestration, or expensive unbounded joins, use source-form queries, App Functions, or a different backend workflow instead.
 
 Index guidance:
 
-- Index only materialized-view output aliases, not source references such as `customer.name`.
+- For materialized mode, index only output aliases, not source references such as `customer.name`.
+- Live data views ignore `indexes`; keep their runtime filters and page size conservative.
 - For row views, index IDs used in drill-down (`ticketId`, `customerId`) and common filters/order fields (`statusValue`, `ownerId`, `createdAt`).
 - For aggregate views, index the dimensions/time buckets used in runtime `filters`, `having` drill-downs, and `order` (`customerId`, `statusValue`, `createdMonth`).
 - Keep compound indexes aligned with common query prefixes. For example, dashboard filters by customer then month should use `["customerId", "createdMonth"]`.
@@ -219,7 +231,7 @@ Diagnostic commands:
 ```bash
 openxiangda data-view list --profile dev
 openxiangda data-view status ticket_with_customer --profile dev
-openxiangda data-view refresh ticket_with_customer --profile dev
+openxiangda data-view refresh ticket_with_customer --profile dev  # materialized only
 openxiangda data-view query ticket_with_customer --profile dev --fields ticketId,customerName
 openxiangda data-view query ticket_with_customer --profile dev --query-json query.json
 openxiangda data-view stats ticket_stats_by_customer --profile dev --fields customerName,ticketCount
@@ -228,6 +240,8 @@ openxiangda data-view stats ticket_stats_by_customer --profile dev --query-json
 
 ## Runtime SDK
 
+`sdk.dataView.query` and `sdk.dataView.stats` work for both materialized and live data views. Responses include `storageMode`; materialized responses may include `lastRefreshedAt`, while live responses return current data and `lastRefreshedAt: null`.
+
 Direct query:
 
 ```ts

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

@@ -7,9 +7,11 @@ Guidelines:
 - Do not hardcode `/openxiangda-api` calls inside end-user page components unless the page is explicitly an admin tool.
 - Prefer SDK modules for form data, user context, permissions, and platform navigation.
 - Use `sdk.dataView.query` for published read-only multi-form row data views. Use `sdk.dataView.stats` for aggregate data views declared with `viewType: "aggregate"`.
+- Data views can be `storageMode: "materialized"` for refreshed report/list data or `storageMode: "live"` for bounded real-time joins. Page code calls the same SDK methods for both modes and should inspect `response.storageMode` / `response.lastRefreshedAt` when freshness is visible to users.
 - Data view runtime queries can filter, sort, paginate, and select only output aliases.
 - Keep data view page calls paginated and field-scoped. Runtime filters/order should use aliases that the data view indexes, especially for aggregate dimensions and date buckets.
 - Use `sdk.dataSource.run()` with a page data source descriptor when the page config should own the data view code, default fields, or default filters.
+- Use `sdk.function.invoke(code, { input })` for reusable backend business logic declared under `src/resources/functions/` and `src/functions/`. Do not implement multi-form orchestration, connector fan-out, notification orchestration, or permission-sensitive backend rules directly in a page component.
 - Use `sdk.connector.invoke`, `sdk.connector.call("connector.api")`, or `sdk.connector.download` for external services. The SDK calls the platform runtime connector endpoint; it must not call third-party domains directly.
 - Use `sdk.notification.sendByType` and `batchSendByType` for reusable business messages. Custom notification types must be declared in `src/resources/notifications/` and published with `openxiangda resource publish`.
 - For the current user's department hierarchy, use `sdk.department.getCurrentUserParentDepartments()`; do not hardcode `GET /department/:id/parentDepartments` in page code.
@@ -87,6 +89,19 @@ const response = await sdk.dataSource.run("tickets", {
 
 Data view filters, having, and fields use output aliases such as `customerName` or `ticketCount`, not source references such as `customer.name`. If the page only needs one form, prefer `sdk.form.advancedSearch`. If the page only needs a simple one-form dropdown, prefer linkedForm options.
 
+App Function invocation:
+
+```ts
+const result = await sdk.function.invoke("reservation_reminder_summary", {
+  input: {
+    scope: "today",
+    keyword,
+  },
+})
+```
+
+Use App Functions when the logic must run server-side and be reusable by pages, automations, or workflows. Current runtime invocation requires the caller to have app automation management permission; ordinary page users should normally consume function-backed data through a permission-aware page or a narrower backend resource.
+
 Logout and current-user role switching:
 
 ```ts

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

@@ -66,13 +66,15 @@ const data = await sdk.connector.call("crm.getCustomer", { body: { keyword } });
 - 多表只读联表列表 / lookup / 报表明细：用行级 data view，页面调用 `sdk.dataView.query`。
 - 固定口径统计 / 看板指标 / 图表数据源：用 `viewType: "aggregate"`，页面调用 `sdk.dataView.stats`。
 - ECharts 或自定义 dashboard 只负责展示；统计口径稳定时，数据源优先沉淀成 aggregate data view。
-- 发布前为常用筛选、排序、维度和时间桶声明 `indexes`，并确认刷新延迟是否能被业务接受。
-- 不用于单表 CRUD、简单 `linkedForm` 下拉、强实时、写回或临时 BI 查询。
+- 默认 `storageMode: "materialized"`，适合读多写少和可接受刷新延迟的列表/报表；发布前为常用筛选、排序、维度和时间桶声明 `indexes`。
+- `storageMode: "live"` 每次查询实时执行，适合强实时但数据量可控的固定复杂查询；live 模式忽略 `indexes` 且不能 refresh。
+- 不用于单表 CRUD、简单 `linkedForm` 下拉、写回、无边界重查询或临时 BI 查询。
 
 ```json
 {
   "code": "ticket_with_customer",
   "name": "Ticket With Customer",
+  "storageMode": "materialized",
   "base": { "formCode": "service_ticket", "alias": "ticket" },
   "joins": [
     {
@@ -137,7 +139,7 @@ const stats = await sdk.dataView.stats("ticket_stats_by_customer", {
 });
 ```
 
-性能要点：索引只能引用输出 alias；行级视图索引常用 filter/order 字段；聚合视图索引 dimensions/date buckets；`countDistinct` 和高基数维度刷新成本较高；低于 5 分钟的 scheduled refresh 需要用户明确确认时间敏感度。完整规则见 [`data-views.md`](data-views.md)。
+性能要点：索引只能引用输出 alias；行级视图索引常用 filter/order 字段；聚合视图索引 dimensions/date buckets；`countDistinct` 和高基数维度刷新成本较高；低于 5 分钟的 scheduled refresh 需要用户明确确认时间敏感度。live 视图不刷新、不建索引，必须控制字段、过滤和分页。完整规则见 [`data-views.md`](data-views.md)。
 
 ## 3. Notification — `src/resources/notifications/<code>.json`
 
@@ -178,7 +180,69 @@ await sdk.notification.sendByType({
 
 JS_CODE 调用：`ctx.notification.sendByType({ ... })`。允许的 channels：`inapp` / `email` / `dingding` / `wechat` / `thirdparty_todo`。完整规则见 [`notifications.md`](notifications.md)。
 
-## 4. Workflow — `src/resources/workflows/<code>/workflow.json`（manifest）+ `src/workflows/<code>/workflow.ts`（代码优先）
+## 4. App Function — `src/resources/functions/<functionCode>.json` + `src/functions/<functionCode>/index.ts`
+
+```json
+{
+  "code": "reservation_reminder_summary",
+  "name": "Reservation Reminder Summary",
+  "sourceFile": { "localPath": "src/functions/reservation_reminder_summary/index.ts" },
+  "runtimeMode": "trusted_node",
+  "timeout": 30000,
+  "resources": {
+    "forms": ["reservation_order"],
+    "dataViews": ["reservation_order_overview"],
+    "connectors": ["crm"]
+  }
+}
+```
+
+```ts
+// src/functions/reservation_reminder_summary/index.ts
+export default async function reservationReminderSummary(ctx, input) {
+  const orders = await ctx.form.queryMany({
+    formCode: "reservation_order",
+    filters: [{ field: "status", operator: "=", value: "pending" }],
+    pageSize: 50,
+  });
+
+  const overview = await ctx.dataView.query("reservation_order_overview", {
+    pageSize: 20,
+  });
+
+  return {
+    pendingCount: orders.totalCount || orders.data?.length || 0,
+    overview: overview.data || [],
+    input,
+  };
+}
+```
+
+调用方式：
+
+```ts
+const result = await sdk.function.invoke("reservation_reminder_summary", {
+  input: { scope: "today" },
+});
+```
+
+自动化 / 流程图节点调用：
+
+```json
+{
+  "id": "call_summary",
+  "type": "function_call",
+  "data": {
+    "functionCode": "reservation_reminder_summary",
+    "input": { "scope": "today" },
+    "saveResponseTo": "summary"
+  }
+}
+```
+
+适用边界：可复用后端业务逻辑、跨页面/自动化/流程共享的查询编排、连接器调用、通知编排、受控平台 API 调用。当前 MVP 不暴露原始 SQL/Redis；运行时接口需要应用自动化管理权限，自动化/流程内部调用走服务端上下文。
+
+## 5. Workflow — `src/resources/workflows/<code>/workflow.json`（manifest）+ `src/workflows/<code>/workflow.ts`（代码优先）
 
 ```jsonc
 // src/resources/workflows/customer_approval/workflow.json
@@ -208,7 +272,7 @@ export default defineWorkflow({
 
 CLI 编译为 `definition.v3.json` + `preview.json`，平台运行时仍走标准工作流引擎。完整规则见 [`workflow-v3.md`](workflow-v3.md)。
 
-## 5. Automation — `src/resources/automations/<code>/{definition.code.json,preview.json}` + `src/automations/<code>/index.ts`
+## 6. Automation — `src/resources/automations/<code>/{definition.code.json,preview.json}` + `src/automations/<code>/index.ts`
 
 ```jsonc
 // src/resources/automations/notify_on_submit/definition.code.json
@@ -242,17 +306,18 @@ export default async function (ctx) {
 
 `trigger_v2` 事件源：`form_data` / `form_field` / `workflow_task` / `workflow_process` / `mode: "scheduled"`（fixed_time / form_date_field）。完整规则见 [`automation-v3.md`](automation-v3.md)。
 
-## 6. JS_CODE V2 — `src/js-code-nodes/<scriptCode>/index.ts`
+## 7. JS_CODE V2 — `src/js-code-nodes/<scriptCode>/index.ts`
+
+JS_CODE V2 适合自动化/流程图里的节点级脚本。跨页面、跨自动化、需要一个稳定后端入口的可复用逻辑优先写 App Function，再用 `function_call` 节点或 `sdk.function.invoke` 调用。
 
 ```ts
 export default async function (ctx) {
-  const { formData, operator, methods, notification, platform, utils, console } = ctx;
-  const result = await methods.queryManyData({
+  const { formData, operator, form, dataView, connector, notification, platform, utils, console } = ctx;
+  const result = await form.queryMany({
     formCode: "customer",
-    formUuid: ctx.app.formUuids.customer,
-    searchCondition: [/* 查询条件 */],
+    filters: [/* 查询条件 */],
   });
-  return { count: result.length };
+  return { count: result.totalCount || result.data?.length || 0 };
 }
 ```
 
@@ -275,7 +340,9 @@ export default async function (ctx) {
 
 构建：`pnpm build-js-code --script sync_customer`（先 `tsc` 再打包到 `dist/js-code-nodes/<code>/index.cjs`）。CLI validate/create/publish 时会上传快照、用 `{ bucketName, objectName, sha256 }` 替换 `sourceFile.localPath`。
 
-## 7. Role — `src/resources/roles/<code>.json`
+`ctx.methods.*` 仍可用于兼容旧脚本；新脚本优先使用 `ctx.resources`、`ctx.form`、`ctx.dataView`、`ctx.connector`、`ctx.notification` 和 `ctx.platform.api`。
+
+## 8. Role — `src/resources/roles/<code>.json`
 
 ```json
 {
@@ -284,7 +351,7 @@ export default async function (ctx) {
 }
 ```
 
-## 8. Page Permission Group — `src/resources/permissions/page-groups/<code>.json`
+## 9. Page Permission Group — `src/resources/permissions/page-groups/<code>.json`
 
 ```json
 {
@@ -298,7 +365,7 @@ export default async function (ctx) {
 
 `formCodes` / `pageCodes` / `menuCodes` 留空表示对匹配角色全部可见。
 
-## 9. Form Permission Group — `src/resources/permissions/form-groups/<formCode>/<groupCode>.json`
+## 10. Form Permission Group — `src/resources/permissions/form-groups/<formCode>/<groupCode>.json`
 
 ```json
 {
@@ -321,7 +388,7 @@ export default async function (ctx) {
 }
 ```
 
-## 10. Form Settings — `src/resources/settings/forms/<formCode>.json`
+## 11. Form Settings — `src/resources/settings/forms/<formCode>.json`
 
 ```json
 {
@@ -339,7 +406,7 @@ export default async function (ctx) {
 }
 ```
 
-## 11. Menu — `src/resources/menus/<code>.json`
+## 12. Menu — `src/resources/menus/<code>.json`
 
 ```json
 {
@@ -359,16 +426,17 @@ export default async function (ctx) {
 ```text
 需要展示数据？
 ├─ 单表 CRUD     → 表单页 + DataManagementList（不要 data view）
-├─ 多表只读联表  → src/resources/data-views/
+├─ 多表只读联表  → src/resources/data-views/（materialized 或 live）
 ├─ 表单字段下拉  → SelectField + optionSource.type: "linkedForm"（不要 data view）
 └─ 大屏 / 报表    → 原生报表 → ECharts page
 
 需要后端逻辑？
 ├─ 真有审批      → workflow（src/workflows/<code>/workflow.ts）
 ├─ 状态流转      → 表单 status 字段 + 状态机 + automation
+├─ 可复用服务逻辑 → App Function（src/functions/<code>/index.ts + function_call / sdk.function.invoke）
 ├─ 提交/字段触发 → automation（trigger_v2 + src/automations/<code>/index.ts）
 ├─ 定时任务      → automation（mode: "scheduled"）
-└─ 复杂后端逻辑  → JS_CODE V2 trusted_node（src/js-code-nodes/<code>/index.ts）
+└─ 流程/自动化节点内脚本 → JS_CODE V2 trusted_node（src/js-code-nodes/<code>/index.ts）
 
 需要外部数据？
 ├─ 第三方 HTTP    → src/resources/connectors/ + sdk.connector.call
@@ -380,5 +448,6 @@ export default async function (ctx) {
 - ❌ 把 `formUuid` / `pageId` 等平台 ID 写进 manifest。**用 code，CLI 自动解析。**
 - ❌ 把 API key、token、密码写进 manifest。**用占位符，平台后台填真实值。**
 - ❌ 同时在 manifest 与平台后台编辑同一个资源（漂移源）。**统一以 manifest 为单一来源**，需要看平台版本就 `resource pull`。
-- ❌ 用 data view 代替 `linkedForm` 下拉、单表 CRUD 或写回。**data view 是只读 + 延迟刷新。**
+- ❌ 用 data view 代替 `linkedForm` 下拉、单表 CRUD 或写回。**data view 是只读；materialized 有刷新延迟，live 要控制查询边界。**
+- ❌ 把跨页面/跨流程复用的后端逻辑都塞进 JS_CODE。**优先 App Function，JS_CODE 只做节点内脚本。**
 - ❌ 在 page 源码里 hardcode `/api/notification-config/*` 或 `/connectors/actions/invoke`。**用 `sdk.notification` / `sdk.connector`。**

package/openxiangda-skills/references/workflow-v3.md

@@ -135,7 +135,23 @@ File snapshot:
 
 AI-authored JS_CODE source must be TypeScript under `sy-lowcode-app-workspace/src/js-code-nodes/<scriptCode>/index.ts`. When validating or creating, the CLI runs `pnpm build-js-code --script <scriptCode>`, which runs TypeScript validation first, bundles to `dist/js-code-nodes/<scriptCode>/index.cjs`, uploads the bundle, and replaces `sourceFile.localPath` with immutable snapshot metadata. The backend verifies snapshot `sha256`, runs it in the trusted Node runtime, applies the node timeout (`30000` ms by default), stores execution logs, and writes the returned value to the node output and `variables.node_<nodeId>`.
 
-Scripts can export `export default async function (ctx) {}` or `module.exports = async (ctx) => {}`. The runtime exposes `ctx.triggerEvent`, `ctx.formData`, `ctx.workflowData`, `ctx.operator`, `ctx.app`, `ctx.variables`, `ctx.methods.*`, `ctx.platform.api.*`, `ctx.utils`, `require`, `process`, and `Buffer`. Use `ctx.methods.queryOneData/queryManyData/updateOneData/updateDataByFormInstanceId/updateManyData/createOneData/terminateProcess/getAllParentDepartments` for platform-side data and process operations.
+For reusable backend logic that should be shared by pages, automations, and workflows, prefer an App Function under `src/functions/<functionCode>/index.ts` plus `src/resources/functions/<functionCode>.json`. Workflow graphs that support App Function nodes can call it with:
+
+```json
+{
+  "id": "call_summary",
+  "type": "function_call",
+  "data": {
+    "functionCode": "reservation_reminder_summary",
+    "input": { "scope": "process" },
+    "saveResponseTo": "summary"
+  }
+}
+```
+
+Use JS_CODE V2 when the script is local to one workflow node.
+
+Scripts can export `export default async function (ctx) {}` or `module.exports = async (ctx) => {}`. The runtime exposes `ctx.triggerEvent`, `ctx.formData`, `ctx.workflowData`, `ctx.operator`, `ctx.app`, `ctx.variables`, `ctx.resources`, `ctx.form`, `ctx.dataView`, `ctx.connector`, `ctx.notification`, `ctx.platform.api.*`, `ctx.utils`, `require`, `process`, and `Buffer`. Prefer `ctx.resources.resolveForm/resolveDataView/resolveConnector`, `ctx.form.queryMany/createOne/updateOne/updateById`, `ctx.dataView.query/stats`, and `ctx.connector.call/invoke` for platform-side work. Legacy data/process bridge methods remain available as `ctx.methods.queryOneData/queryManyData/updateOneData/updateDataByFormInstanceId/updateManyData/createOneData/terminateProcess/getAllParentDepartments`.
 
 Example `src/js-code-nodes/sync_customer/index.ts`:
 

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

@@ -99,7 +99,7 @@ openxiangda workspace bind --profile <name> --app-type APP_XXX
 - Do not search platform apps or reuse similar app names unless the user explicitly asks to reuse an existing app or gives an `appType`.
 - Store platform-specific IDs only in `.openxiangda/state.json`.
 - Use logical local codes for forms, pages, workflows, automations, and menus.
-- Before scaffolding a new business app, read `../../references/best-practices.md` and pick an architecture from the initialized `examples/best-practices/` catalog. Do not generate a large single-file app page when a template pattern already covers the scenario.
+- Before scaffolding a new business app, read `references/best-practices.md` and pick an architecture from the initialized `examples/best-practices/` catalog. Do not generate a large single-file app page when a template pattern already covers the scenario.
 - For Phase 6 React SPA apps, use `--runtime react-spa`. The generated app owns routing/layouts/menus with React Router and Tailwind CSS; platform permissions still come from backend runtime bootstrap and route checks.
 - React SPA form publish is schema-only by default. Do not add OSS credentials or old embedded form bundles unless explicitly maintaining legacy compatibility with `--legacy-form-bundle`.
 - When publishing after app edits, prefer targeted commands (`workspace publish --changed --dry-run`, then `--changed`, `--page`, `--form`, or `--only`). Do not publish all forms/pages just because one page changed.
@@ -107,10 +107,12 @@ openxiangda workspace bind --profile <name> --app-type APP_XXX
 
 ## Resource State
 
-Read `../../references/workspace-state.md` when changing `.openxiangda/state.json`.
+Read `references/workspace-state.md` when changing `.openxiangda/state.json`.
 
-Read `../../references/openxiangda-api.md` when exact endpoint fields are needed.
+Read `references/openxiangda-api.md` when exact endpoint fields are needed.
 
-Read `../../references/architecture-patterns.md` to understand the overall app structure (how forms, pages, menus, workflows, and permissions compose into an app, and the recommended `src/forms` / `src/pages` layout) before scaffolding or restructuring an app workspace.
+Read `references/resource-manifest-cheatsheet.md` before creating shared resources such as data views, connectors, notifications, App Functions, workflows, automations, permissions, settings, or menus.
 
-Read `../../references/best-practices.md` before implementing app-level patterns such as status lifecycles, role governance, PC/mobile portals, high-performance data management pages, workflow boundaries, and automation.
+Read `references/architecture-patterns.md` to understand the overall app structure (how forms, pages, menus, workflows, and permissions compose into an app, and the recommended `src/forms` / `src/pages` layout) before scaffolding or restructuring an app workspace.
+
+Read `references/best-practices.md` before implementing app-level patterns such as status lifecycles, role governance, PC/mobile portals, high-performance data management pages, workflow boundaries, and automation.

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

@@ -287,7 +287,10 @@ It is responsible for:
 
 ## References
 
-- `../../references/openxiangda-api.md` — exact endpoint contracts.
-- `../../references/workspace-state.md` — `.openxiangda/state.json` shape and profile-scoped resource maps.
-- `../../references/architecture-patterns.md` — overall architecture of an OpenXiangda app workspace (CRUD data flow, page/form layering, recommended directory organization). Read this when you need to understand how forms, pages, workflows, and platform state fit together end-to-end.
-- `../../references/best-practices.md` — initialized best-practice templates and rules for modular pages, status lifecycles, role governance, data isolation, query performance, and workflow boundaries.
+- `references/openxiangda-api.md` — exact endpoint contracts.
+- `references/workspace-state.md` — `.openxiangda/state.json` shape and profile-scoped resource maps.
+- `references/resource-manifest-cheatsheet.md` — quick templates for connectors, data views, App Functions, workflows, automations, permissions, settings, and menus.
+- `references/data-views.md` — materialized/live data view authoring, refresh behavior, permissions, indexes, and runtime SDK usage.
+- `references/connector-resources.md` — engineering resource folders, connector usage, App Function boundary, and platform runtime calls.
+- `references/architecture-patterns.md` — overall architecture of an OpenXiangda app workspace (CRUD data flow, page/form layering, recommended directory organization). Read this when you need to understand how forms, pages, workflows, and platform state fit together end-to-end.
+- `references/best-practices.md` — initialized best-practice templates and rules for modular pages, status lifecycles, role governance, data isolation, query performance, and workflow boundaries.

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

@@ -110,12 +110,12 @@ Do not use `openxiangda form create` as the normal way to generate a user-facing
 
 Read these references only when writing or reviewing schema:
 
-- `../../references/forms/form-schema.md`
-- `../../references/forms/component-registry.md`
-- `../../references/forms/layout-and-rules.md`
-- `../../references/platform-data-model.md` — how each field type is persisted (JSONB, `{label, value}` for option fields, attachment shape). Consult before designing schema or wiring values.
-- `../../references/component-guide.md` — platform component first, `antd` / `antd-mobile` fallback, and native-control ban for AI-authored app code.
-- `../../references/best-practices.md` — status lifecycle fields, ownership redundancy, role-governance fields, and the boundary between normal forms and workflow forms.
+- `references/forms/form-schema.md`
+- `references/forms/component-registry.md`
+- `references/forms/layout-and-rules.md`
+- `references/platform-data-model.md` — how each field type is persisted (JSONB, `{label, value}` for option fields, attachment shape). Consult before designing schema or wiring values.
+- `references/component-guide.md` — platform component first, `antd` / `antd-mobile` fallback, and native-control ban for AI-authored app code.
+- `references/best-practices.md` — status lifecycle fields, ownership redundancy, role-governance fields, and the boundary between normal forms and workflow forms.
 
 ## Rules
 
@@ -133,13 +133,13 @@ Read these references only when writing or reviewing schema:
 - Do not copy `formUuid` from dev to prod unless the target platform explicitly already uses that ID.
 - Keep `schema.ts` and `page.tsx` as the source for fields/layout/rules and presentation; generated build output is not the source of truth.
 - In `schema.ts`, import `defineFormSchema` from `openxiangda` and default-export the schema.
-- Treat `schema.ts` as the field/component contract. Prefer platform field components listed in `../../references/forms/component-registry.md`; do not replace them with raw JSX controls in `page.tsx`.
+- Treat `schema.ts` as the field/component contract. Prefer platform field components listed in `references/forms/component-registry.md`; do not replace them with raw JSX controls in `page.tsx`.
 - Keep `page.tsx` presentation-only. It may customize layout, wrappers, sections, or routing, but should render a complete OpenXiangda standard form/runtime rather than assembling isolated raw controls.
 - If a platform field is missing for a real business need, submit feedback with `openxiangda feedback submit --yes` and then use an `antd` / `antd-mobile` wrapper as a local workaround. Report the workaround and fingerprint to the user.
 - Put validation on field-level `rules`; never generate old top-level validation arrays under `schema.rules`. Top-level `rules` is only for `FormEffect[]` with `when` and `then`.
-- Always provide `options` for option components. `SelectField`, `MultiSelectField`, `RadioField`, `CheckboxField`, and `CascadeSelectField` must not be emitted with `options` undefined. See `../../references/component-guide.md` for the full list and `../../references/platform-data-model.md` for the `{label, value}` storage contract.
+- Always provide `options` for option components. `SelectField`, `MultiSelectField`, `RadioField`, `CheckboxField`, and `CascadeSelectField` must not be emitted with `options` undefined. See `references/component-guide.md` for the full list and `references/platform-data-model.md` for the `{label, value}` storage contract.
 - Do not emit raw native form controls in app/workspace source. For basic entry use `TextField`, `TextAreaField`, `NumberField`, `DateField`, `SelectField`, `RadioField`, etc.; for platform-specific entry use `UserSelectField`, `DepartmentSelectField`, `AttachmentField`, `ImageField`, `EditorField`, `DigitalSignatureField`, and `LocationField`.
 - Workflow form pages use the same workspace form structure plus workflow v3 configuration. In legacy workspaces, publish the form page bundle through workspace publish before treating it as complete. In React SPA workspaces, `workspace publish --form` syncs schema only, and the SPA default process pages render through `runtime deploy`.
 - After editing one form, use `workspace publish --form <formCode>` or preview `--changed --dry-run`; do not run full workspace publish by default.
 - Use `openxiangda form pull` or app snapshot before overwriting an existing form.
-- Before assuming a value shape (e.g. dates, attachments, member fields, option fields), verify against `../../references/platform-data-model.md` instead of guessing.
+- Before assuming a value shape (e.g. dates, attachments, member fields, option fields), verify against `references/platform-data-model.md` instead of guessing.

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

@@ -59,6 +59,6 @@ Use logical local codes first. If a code is missing from `.openxiangda/state.jso
 
 ## References
 
-- `../../references/platform-data-model.md` — how each field type is persisted on the platform (JSONB, `{label, value}` for option fields, attachment shape, etc.). Consult this when a snapshot value looks unexpected so you can tell broken data from normal storage format.
-- `../../references/troubleshooting.md` — catalog of known failure modes (missing styles, `options` runtime errors, mismatched option labels, etc.). Cross-check inspection findings against this list before reporting an issue or proposing a fix.
+- `references/platform-data-model.md` — how each field type is persisted on the platform (JSONB, `{label, value}` for option fields, attachment shape, etc.). Consult this when a snapshot value looks unexpected so you can tell broken data from normal storage format.
+- `references/troubleshooting.md` — catalog of known failure modes (missing styles, `options` runtime errors, mismatched option labels, etc.). Cross-check inspection findings against this list before reporting an issue or proposing a fix.