openxiangda 2.0.0-alpha.37 → 2.0.0-alpha.38

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "openxiangda",
-  "version": "2.0.0-alpha.37",
+  "version": "2.0.0-alpha.38",
   "description": "Unified OpenXiangda 2.0 CLI, SDK, React runtime, NestJS integration and AI skill distribution.",
   "type": "module",
   "main": "./dist/index.js",
@@ -49,12 +49,12 @@
   "dependencies": {
     "dayjs": "1.11.18",
     "docx-preview": "0.3.7",
-    "openxiangda-cli": "2.0.0-alpha.123",
-    "openxiangda-contracts": "2.0.0-alpha.59",
-    "openxiangda-devkit-core": "2.0.0-alpha.77",
-    "openxiangda-mcp": "2.0.0-alpha.77",
-    "openxiangda-nest": "2.0.0-alpha.70",
-    "openxiangda-skill-kit": "2.0.0-alpha.98",
+    "openxiangda-cli": "2.0.0-alpha.124",
+    "openxiangda-contracts": "2.0.0-alpha.60",
+    "openxiangda-devkit-core": "2.0.0-alpha.78",
+    "openxiangda-mcp": "2.0.0-alpha.78",
+    "openxiangda-nest": "2.0.0-alpha.71",
+    "openxiangda-skill-kit": "2.0.0-alpha.99",
     "xlsx": "https://cdn.sheetjs.com/xlsx-0.20.3/xlsx-0.20.3.tgz"
   },
   "peerDependencies": {

package/skills/openxiangda-v2/SKILL.md

@@ -10,14 +10,14 @@ Treat requirement discovery, architecture, authorization, development, testing a
 Before a workspace exists, use this Skill's exact npm version:
 
 ```bash
-pnpm dlx openxiangda@2.0.0-alpha.37 login --base-url <platform>
-pnpm dlx openxiangda@2.0.0-alpha.37 create <directory>
+pnpm dlx openxiangda@2.0.0-alpha.38 login --base-url <platform>
+pnpm dlx openxiangda@2.0.0-alpha.38 create <directory>
 ```
 
 Inside an application, use only its locked executable through `pnpm openxiangda`. Never invoke a bare global `openxiangda`, because that executable may belong to stable 1.x. Moving tags such as `latest` and `alpha` are forbidden. To install or refresh this same Skill from the package, run:
 
 ```bash
-pnpm dlx openxiangda@2.0.0-alpha.37 skill install --force
+pnpm dlx openxiangda@2.0.0-alpha.38 skill install --force
 ```
 
 Use this order:

package/skills/openxiangda-v2/references/data-authz.md

@@ -107,6 +107,11 @@ without `access` inherits the resource read/create/update capability. Each
 access array is all-of; `false` is explicit deny. The same arrays drive the
 generated UI and platform field policies.
 
+For `uuid` fields, omission never generates a value. Only the resource system
+field `id` is platform-generated. An omitted optional UUID remains `null`; a
+required UUID must be supplied explicitly and cannot rely on an implicit
+database default.
+
 Field types are semantic, not PostgreSQL storage aliases. Use the catalog in the generated `AGENTS.md`: for example `text.short`, `number.integer`, `user.single`, `department.multiple`, `resource-ref.single`, `file`, `address` and `subtable`. The compiler alone chooses storage columns and constraints. Reference fields store JSON display values. For `resource-ref.*`, `resourceCode`, `value`, `label`, optional `description` and optional `snapshot` are convenient historical display data only: the target resource remains authoritative, the platform does not create a foreign key or refresh/check the stored JSON, and business actions that need current target state must query it by `resourceCode` plus `value`. A resource source `labelField` must point to `text.short` or `text.long`; a `serial-number` field can be listed in `searchFields`, `descriptionFields` or `snapshotFields`, but it is not a display label. File limits exist only under `file`; `maxCount` owns the single/multiple bound and `maxSizeMb` owns the per-file size bound. There is no `file.multiple` key.
 
 Generated list, detail, audit and preview surfaces render the stored canonical

package/skills/openxiangda-v2/references/workflow-events.md

@@ -160,6 +160,19 @@ Use direct card actions first for approve/reject. Return, transfer, delegate and
 
 Consume typed participant/task/instance facts with durable idempotency. Order Workflow message projection by `instanceId + instanceSequence`; never assume global event order. Terminal instance facts dominate stale participant facts and update every historical message for that instance.
 
+For Native Data facts, the platform owns the capture plan under the exact Event
+revision, Data revision, AuthZ revision and resource tuple selected by the
+Native Head. Adding a snapshot field or extending RLS may create a new plan;
+applications do not version it and must not remove the field to satisfy an old
+plan. Historical replay uses the data and plan digest frozen in the original
+fact, so it never gains fields from the current Head.
+
+Every Workflow fact v2 carries the immutable instance identity envelope:
+`workflowCode`, `definitionVersion`, `bindingVersion`, `instanceId`,
+`generation`, `businessKey`, `instanceSequence`, `revision`, `dataRef`, and
+`dataRevision`, plus `actor` and `cause`. Treat missing identity as an invalid
+fact; never infer historical versions from the current Workflow Head.
+
 Use Fake Channel before a real Adapter. Verify create, update, close, reconcile, duplicate, out-of-order, restart, retryable failure, terminal failure and unknown delivery before DingTalk or campus canaries.
 
 ## Verification