openxiangda 1.0.124 → 1.0.125

package/README.md

@@ -335,6 +335,7 @@ AI-authored workflows can use compile-time SDK resources:
 - Read-only preview: `preview.json`
 - Local check: `openxiangda workflow compile src/workflows/<resourceCode>/workflow.ts --check`
 - Runtime operations: use `sdk.process.resolveCapabilities(...)` or `ProcessActionBar` / `ProcessTimeline` from `openxiangda/runtime/react` instead of hard-coded workflow buttons.
+- Runtime task centers: use `sdk.workCenter.listItems({ boxType: "todo" })` and `sdk.workCenter.getStats()` for the current user's todo/done/cc/initiated lists and counts; do not build end-user todo pages by reading workflow operation logs or raw process-task tables.
 - Delayed approval start: save a process-form draft without starting workflow via `StandardFormPage submitBehavior="save-draft"` or `sdk.form.create({ formUuid, data, saveAsDraft: true, startProcess: false })`; later call `sdk.process.startFromExistingInstance({ formUuid, formInstId })` or render `StandardFormPage` with `submitBehavior="start-existing-process"` to start approval in place. Do not create a second process instance and delete the draft.
 - AI workflow cookbook and action payload table: read `openxiangda-skills/references/workflow-v3.md` for the draft -> start existing instance -> return to initiator -> resubmit flow, and for operation payload details such as `approve` using process `instanceId` while `transfer` / `return` / `resubmit` use `taskId`.
 

package/openxiangda-skills/SKILL.md

@@ -164,7 +164,7 @@ When the user provides a root domain such as `https://yida.wisejob.cn/`, use it
 - Use JS_CODE for node-local cross-form data queries, create/update/batch update operations, process termination, platform API calls, external HTTP calls, and backend trigger orchestration. For logic that pages, automations, and workflows should reuse through a stable backend entry, prefer App Function. Do not use JS_CODE for simple UI interactions, ordinary form validation, or display-only page behavior.
 - For workflow/automation JS_CODE nodes, prefer V2 `runtimeMode: "trusted_node"`. AI-authored source must be TypeScript under `src/js-code-nodes/<scriptCode>/index.ts`, `src/automations/<resourceCode>/index.ts`, or `src/functions/<functionCode>/index.ts`. `pnpm build-js-code --script <scriptCode>` runs TypeScript validation before bundling, and `sourceFile.localPath` should point to the TS source; the CLI builds, uploads, and replaces it with snapshot metadata during validate/create.
 - Form permission group resources must have stable local codes. Use unique `code` values such as `ticket_reporter_view` and `ticket_repairer_view`; do not rely on the form code when one form has multiple groups.
-- Workflow resources should prefer `workflowFile` + `defineWorkflow` semantic DSL over hand-written raw JSON. For workflows bound by `formCode`, run `openxiangda workspace publish --form <formCode>` first so the process form schema/table is initialized, then run `openxiangda workflow compile <workflow.ts> --check` and `openxiangda resource publish --dry-run --profile <name>` before publish; use `sdk.process.resolveCapabilities(...)` or `ProcessActionBar` / `ProcessTimeline` from `openxiangda/runtime/react` for runtime buttons and timelines instead of hard-coded operation lists. For delayed approval start from an existing saved draft, first save without starting workflow via `StandardFormPage submitBehavior="save-draft"` or `sdk.form.create({ formUuid, data, saveAsDraft: true, startProcess: false })`; later use `sdk.process.startFromExistingInstance({ formUuid, formInstId })` or `StandardFormPage submitBehavior="start-existing-process"`; do not create a duplicate process instance and delete the draft. For custom workflow UI, return-to-initiator, resubmit, and action payload details, read `references/workflow-v3.md` sections `Cookbook: draft, start, return, resubmit` and `Capability action reference`.
+- Workflow resources should prefer `workflowFile` + `defineWorkflow` semantic DSL over hand-written raw JSON. For workflows bound by `formCode`, run `openxiangda workspace publish --form <formCode>` first so the process form schema/table is initialized, then run `openxiangda workflow compile <workflow.ts> --check` and `openxiangda resource publish --dry-run --profile <name>` before publish; use `sdk.process.resolveCapabilities(...)` or `ProcessActionBar` / `ProcessTimeline` from `openxiangda/runtime/react` for runtime buttons and timelines instead of hard-coded operation lists. For end-user task centers, use `sdk.workCenter.listItems({ boxType: "todo" | "done" | "cc" | "initiated" })` and `sdk.workCenter.getStats()` instead of reading workflow logs or process-task tables. For delayed approval start from an existing saved draft, first save without starting workflow via `StandardFormPage submitBehavior="save-draft"` or `sdk.form.create({ formUuid, data, saveAsDraft: true, startProcess: false })`; later use `sdk.process.startFromExistingInstance({ formUuid, formInstId })` or `StandardFormPage submitBehavior="start-existing-process"`; do not create a duplicate process instance and delete the draft. For custom workflow UI, return-to-initiator, resubmit, and action payload details, read `references/workflow-v3.md` sections `Cookbook: draft, start, return, resubmit` and `Capability action reference`.
 - Workflow resources can be created as drafts. After resource publish, verify `openxiangda workflow list --profile <name> --json` and run `openxiangda workflow publish <workflowCode> --profile <name>` until `isPublished: true` is visible. `workflow list` hides platform shell workflows with empty `resourceCode` by default; pass `--all` only when diagnosing raw platform rows.
 
 ## Subskills

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

@@ -149,6 +149,9 @@ Filters:
 - Runtime query filters use output aliases such as `ticketTitle`.
 - Aggregate definition `having` and runtime stats `having` also use output aliases such as `ticketCount`.
 - Supported operators include `=`, `!=`, `<>`, `>`, `>=`, `<`, `<=`, `contains`, `notContains`, `in`, `isEmpty`, and `isNotEmpty`, with aliases such as `eq`, `neq`, `gte`, `lte`, `like`, `is_null`, and `is_not_null`.
+- Runtime SDK filters may be a search group/rule object or an array, for example `{ key: "statusValue", operator: "EQ", value: "已发布" }`; `field` is also accepted. Use output aliases, not source references.
+- If a row view outputs a full option-like JSON field, runtime string `EQ` and `IN` filters can match the JSON text for compatibility. For new data views, prefer selecting `.value` or `.label` into scalar aliases such as `statusValue` and indexing those aliases for exact, predictable filters.
+- Data view `permissionGroups.dataPermission` should use scalar hidden scope aliases such as `ownerUserScopeKey`, `unionGroupScopeKey`, or `departmentScopeKey`. Do not rely on fuzzy JSON option matching for permission boundaries.
 
 Refresh:
 
@@ -248,7 +251,8 @@ Direct query:
 const response = await sdk.dataView.query("ticket_with_customer", {
   fields: ["ticketId", "ticketTitle", "customerName"],
   filters: [
-    { field: "customerName", operator: "contains", value: keyword },
+    { key: "customerName", operator: "contains", value: keyword },
+    { key: "statusValue", operator: "EQ", value: "已发布" },
   ],
   order: [{ field: "ticketTitle", isAsc: "y" }],
   currentPage: 1,
@@ -262,10 +266,10 @@ Aggregate stats query:
 const response = await sdk.dataView.stats("ticket_stats_by_customer", {
   fields: ["customerName", "createdMonth", "ticketCount", "totalAmount"],
   filters: [
-    { field: "customerName", operator: "contains", value: keyword },
+    { key: "customerName", operator: "contains", value: keyword },
   ],
   having: [
-    { field: "ticketCount", operator: ">", value: 0 },
+    { key: "ticketCount", operator: ">", value: 0 },
   ],
   order: [{ field: "ticketCount", isAsc: "n" }],
   currentPage: 1,
@@ -296,7 +300,7 @@ export default {
       code: "ticket_with_customer",
       fields: ["ticketId", "ticketTitle", "customerName"],
       defaultFilter: [
-        { field: "ticketTitle", operator: "isNotEmpty" }
+        { key: "ticketTitle", operator: "isNotEmpty" }
       ]
     },
     {
@@ -305,7 +309,7 @@ export default {
       code: "ticket_stats_by_customer",
       fields: ["customerName", "ticketCount"],
       defaultHaving: [
-        { field: "ticketCount", operator: ">", value: 0 }
+        { key: "ticketCount", operator: ">", value: 0 }
       ]
     }
   ]
@@ -313,7 +317,7 @@ export default {
 
 const response = await sdk.dataSource.run("tickets", {
   filters: [
-    { field: "customerName", operator: "contains", value: keyword }
+    { key: "customerName", operator: "contains", value: keyword }
   ],
   pageSize: 20,
 })

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

@@ -10,10 +10,13 @@ Guidelines:
 - 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.
+- Runtime data view filters may use `{ key, operator, value }` or `{ field, operator, value }`. Prefer `key` in new page code to match search-expression style.
+- If a data view exposes a full option-like JSON field, runtime string `EQ` and `IN` filters can match it for compatibility. New pages should prefer scalar output aliases such as `statusValue` or `statusLabel` declared by the data view.
 - 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`.
+- Use `sdk.workCenter.listItems({ boxType })` and `sdk.workCenter.getStats()` for current-user work center lists and counts. `boxType` is one of `todo`, `done`, `cc`, or `initiated`. This is the end-user task/handled/cc/initiated surface; do not build todo pages by reading workflow operation logs, automation logs, or raw process-task tables.
 - Use `createAuthClient` from `openxiangda/runtime` or `LoginPage` / `useAuth` from `openxiangda/runtime/react` for application login pages. Auth provider App Functions return identity assertions only; platform auth owns create/bind/reject/token decisions.
 - Use `PublicAccessGate` from `openxiangda/runtime/react` or `createPublicAccessClient` from `openxiangda/runtime` for React SPA public pages under `/view/:appType/public/*`. Do not append old `?publicAccess=guest` links in new apps.
 - In React SPA apps, wrap route children with `OpenXiangdaPageProvider` inside `OpenXiangdaProvider` before using `usePageSdk()`, `usePageContext()`, `useDataSource()`, or `useFormViewPermissions()`. `OpenXiangdaProvider` alone is not enough and missing the page provider causes `usePageSdkStore 必须在 PageProvider 内使用`.
@@ -31,7 +34,8 @@ Data view query:
 const response = await sdk.dataView.query("ticket_with_customer", {
   fields: ["ticketId", "ticketTitle", "customerName"],
   filters: [
-    { field: "customerName", operator: "contains", value: keyword },
+    { key: "customerName", operator: "contains", value: keyword },
+    { key: "statusValue", operator: "EQ", value: "已发布" },
   ],
   order: [{ field: "ticketTitle", isAsc: "y" }],
   currentPage: 1,
@@ -45,10 +49,10 @@ Data view stats:
 const response = await sdk.dataView.stats("ticket_stats_by_customer", {
   fields: ["customerName", "ticketCount", "totalAmount"],
   filters: [
-    { field: "customerName", operator: "contains", value: keyword },
+    { key: "customerName", operator: "contains", value: keyword },
   ],
   having: [
-    { field: "ticketCount", operator: ">", value: 0 },
+    { key: "ticketCount", operator: ">", value: 0 },
   ],
   order: [{ field: "ticketCount", isAsc: "n" }],
   currentPage: 1,
@@ -67,7 +71,7 @@ export default {
       code: "ticket_with_customer",
       fields: ["ticketId", "ticketTitle", "customerName"],
       defaultFilter: [
-        { field: "ticketTitle", operator: "isNotEmpty" }
+        { key: "ticketTitle", operator: "isNotEmpty" }
       ]
     },
     {
@@ -76,7 +80,7 @@ export default {
       code: "ticket_stats_by_customer",
       fields: ["customerName", "ticketCount"],
       defaultHaving: [
-        { field: "ticketCount", operator: ">", value: 0 }
+        { key: "ticketCount", operator: ">", value: 0 }
       ]
     }
   ]
@@ -84,13 +88,13 @@ export default {
 
 const response = await sdk.dataSource.run("tickets", {
   filters: [
-    { field: "customerName", operator: "contains", value: keyword }
+    { key: "customerName", operator: "contains", value: keyword }
   ],
   pageSize: 20,
 })
 ```
 
-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.
+Data view filters, having, and fields use output aliases such as `customerName` or `ticketCount`, not source references such as `customer.name`. For option-like fields, prefer scalar aliases such as `statusValue` in the view definition and page filters. 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:
 
@@ -105,6 +109,22 @@ const result = await sdk.function.invoke("reservation_reminder_summary", {
 
 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.
 
+Work center:
+
+```ts
+const todoList = await sdk.workCenter.listItems({
+  boxType: "todo",
+  page: 1,
+  limit: 20,
+  keyword,
+  appType,
+})
+
+const stats = await sdk.workCenter.getStats({ appType })
+```
+
+Use `actionUrl` from a work-center item when present; otherwise link workflow items with both `formUuid` and `formInstanceId` to the app's process detail route. Keep lists paginated and role-scoped by the platform current user.
+
 Application auth:
 
 ```tsx

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

@@ -106,6 +106,8 @@ openxiangda workflow compile src/workflows/expense_approval/workflow.ts \
 
 Runtime pages should not guess buttons. Use `sdk.process.resolveCapabilities(...)` or the React helpers from `openxiangda/runtime/react`: `useProcessCapabilities`, `useProcessActions`, `ProcessActionBar`, `ProcessTimeline`, `ProcessPreviewPanel`, and `InitiatorApproverSelector`. The capability protocol returns `visible`, `enabled`, `disabledReason`, `paramsSchema`, `uiSchema`, return candidates, field permissions, and refresh hints for operations such as approve, reject, transfer, return, save, withdraw, resubmit, callback, retryException, and adminTransfer.
 
+Runtime todo, done, cc, and initiated lists should use `sdk.workCenter.listItems({ boxType })` plus `sdk.workCenter.getStats()`. These APIs return the current user's projected work-center items with pagination, app/form filters, status/result filters, `actionUrl`, `formUuid`, `formInstanceId`, `taskId`, and node/title snapshots. Do not query workflow operation logs, automation logs, or raw process task tables for end-user task-center pages.
+
 For delayed approval start, do not submit a process form and then delete/recreate records. Save the process-form instance without starting workflow via `StandardFormPage submitBehavior="save-draft"` or `sdk.form.create({ formUuid, data, saveAsDraft: true, startProcess: false })`. Later start approval on that same `formInstId` with `sdk.process.startFromExistingInstance({ formUuid, formInstId })` or `StandardFormPage submitBehavior="start-existing-process"`.
 
 For return-to-initiator workflows, prefer `returnPolicy: { scopeType: "initiator", resubmitMode: "resume_current" }` or `flow.action.returnToInitiator()`. The runtime capabilities protocol exposes `resubmit` only on pending `originator_return` tasks. If a user returns to a previous approval node, continuing the flow is a normal `approve` action on that returned approval task.

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

@@ -24,6 +24,7 @@ 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: prefer **semantic DSL** `src/workflows/<code>/workflow.ts` using `defineWorkflow`; compile it to v3 designer JSON with `openxiangda workflow compile`.
 - ✅ Runtime workflow pages: use `sdk.process.resolveCapabilities(...)` or `ProcessActionBar` / `ProcessTimeline` from `openxiangda/runtime/react`; do not hard-code buttons.
+- ✅ Runtime task centers: use `sdk.workCenter.listItems({ boxType: "todo" | "done" | "cc" | "initiated" })` and `sdk.workCenter.getStats()` for current-user lists/counts; do not read workflow logs, automation logs, or raw process-task tables for end-user todo pages.
 - ✅ Before custom workflow UI or delayed approval work, read `references/workflow-v3.md` sections **Cookbook: draft, start, return, resubmit** and **Capability action reference** for payloads, required IDs, and refresh rules.
 - ✅ Delayed approval start: save the process-form record first with `StandardFormPage submitBehavior="save-draft"` or `sdk.form.create({ formUuid, data, saveAsDraft: true, startProcess: false })`, then start approval in place with `sdk.process.startFromExistingInstance({ formUuid, formInstId })` or `StandardFormPage submitBehavior="start-existing-process"`.
 - ✅ Return-to-initiator flows: use `returnPolicy: { scopeType: "initiator", resubmitMode: "resume_current" | "replay" }` or `flow.action.returnToInitiator()`. The runtime capabilities protocol exposes `resubmit` only for pending `originator_return` tasks; return to a previous approval node continues through the normal `approve` action.

package/package.json

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

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

@@ -2486,6 +2486,24 @@ var createPageSdk = (context) => {
       method: "post"
     })
   };
+  const workCenter = {
+    listItems: (params) => request({
+      path: "/work-center/items",
+      method: "get",
+      query: {
+        ...params,
+        appType: resolveAppType(context, params.appType)
+      }
+    }),
+    getStats: (params = {}) => request({
+      path: "/work-center/stats",
+      method: "get",
+      query: {
+        ...params,
+        appType: resolveAppType(context, params.appType)
+      }
+    })
+  };
   const sdk = {
     context,
     request,
@@ -2503,6 +2521,7 @@ var createPageSdk = (context) => {
     permission,
     process: process2,
     notification,
+    workCenter,
     dataView,
     function: appFunction,
     dataSource: {