openxiangda 2.0.0-alpha.37 → 2.0.0-alpha.39

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "openxiangda",
-  "version": "2.0.0-alpha.37",
+  "version": "2.0.0-alpha.39",
   "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.125",
+    "openxiangda-contracts": "2.0.0-alpha.61",
+    "openxiangda-devkit-core": "2.0.0-alpha.79",
+    "openxiangda-mcp": "2.0.0-alpha.79",
+    "openxiangda-nest": "2.0.0-alpha.72",
+    "openxiangda-skill-kit": "2.0.0-alpha.100",
     "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.39 login --base-url <platform>
+pnpm dlx openxiangda@2.0.0-alpha.39 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.39 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/frontend.md

@@ -69,6 +69,36 @@ operation pages under `/admin/operations`; parameterized routes remain
 reachable but cannot be menu references. `defineAdminContributions` remains an
 admin-only helper and intentionally rejects `user` routes.
 
+Declare application-owned login visuals with optional
+`frontend.authentication`. The only supported account contract is
+`existing-platform-users-only` with `registration.mode: 'reject'`; use exact
+desktop `/login` and mobile `/m/login`, each pointing to a static protected user
+default route. Import generated `authenticationSurfaces` and bind an exact
+desktop/mobile renderer map alongside `appRoutes`:
+
+```tsx
+const contributions = defineApplicationContributions(
+  { routes: appRoutes, authenticationSurfaces },
+  {
+    pages,
+    authentication: {
+      applicationLogin: DesktopLogin,
+      applicationLoginMobile: MobileLogin,
+    },
+  },
+);
+```
+
+Renderers receive only `ApplicationLoginSurfaceProps`: safe method descriptors,
+state/error metadata, normalized `returnTo`, and platform callbacks. They never
+receive credentials, provider configuration, OAuth state, tokens, roles, or
+authorization facts. The platform owns the one Router and authentication
+boundary, tokenless v2 facade, Secure HttpOnly session/refresh family and
+logout. Do not put login in `appRoutes`, call v1 auth APIs, persist tokens, or
+translate network/5xx and authenticated 403 states into login. Generated
+`platformAuthManifest` is the independent login QA denominator and does not
+change protected user route counts.
+
 This is also the whole-application composition contract: pass the resulting
 `contributions` to `OpenXiangdaApplication` and let that component remain the
 only owner of `BrowserRouter`, `RuntimeBoundary`, Refine, generated resource and

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

package/skills/openxiangda-v2/references/workspace.md

@@ -4,6 +4,7 @@
 - `appspec/` is the optional OpenXiangda 2.0 business-intent layer. Before changing observable behavior, read the bounded index with `pnpm openxiangda spec context --json`, then select only the relevant stable ID; use no ChangeSpec for L0 work, one short ChangeSpec for L1, and add permission/rollback/concurrency detail only for L2/L3. Before close, the user—not AI—confirms `currentSpec=merged` or `not-applicable`. AppSpec is advisory and never a release gate. Never read, import or migrate 1.x `openspec/` or SDD.
 - Use Vite, React Router, Refine Core and Ant Design. Do not add Umi, ProComponents or another admin shell.
 - Bind every generated `appRoutes` entry to its local page with `defineApplicationContributions`; desktop `admin` routes stay inside the platform Shell, while `user` routes render without an admin Shell for independent mobile/user experiences. Generated resource CRUD routes are compiler-owned under `/admin/resources/<resourceCode>...` and `/m/admin/resources/<resourceCode>...`; never recreate root resource paths, aliases or redirects. Explicit routes that have the same canonical shape as another explicit or generated route fail compilation, even when dynamic parameter names differ. Use only the typed `toolbar`, `row` and `detail` resource slots for generated resource actions. Declare the complete editable admin menu with `defineAdminNavigation` and its page/group helpers; the Shell renders only generated `adminNavigation` references and permissions only filter them. Do not create another router, menu store, layout, identity provider, permission store or copied CRUD page; route/action access uses capability or `allOf`/`anyOf`, while Data/App API and Workflow authorization remain server-owned.
+- Application login is optional `frontend.authentication`: existing platform users only, registration rejected, exact desktop `/login` and mobile `/m/login`. Bind generated `authenticationSurfaces` to separate PC/mobile renderers through `defineApplicationContributions`; renderers own only brand visuals and call `ApplicationLoginSurfaceProps`. The platform alone owns passwords, providers, OAuth state/callbacks, secure cookies, current identity and authorization. Never put login in protected `appRoutes`, call a v1 auth route, store tokens, create users/roles, or add another Router/identity provider. Keep QA in generated `platformAuthManifest`, outside the protected route denominator.
 - Declare each resource once in `openxiangda.config.ts` with only `code`, `name`, `fields` and optional `mutationOwner`, generated/list/layout/data-policy settings. Each field owns type, label, required state, Surface flags, reference/file metadata and access. Resource codes are lower kebab-case. Use `native` for direct Data API mutations, `action`, `readonly` or `workflow` for non-Native ownership; never grant or generate Native mutation for a non-Native owner.
 - Never write resource-level `schemaVersion`, `appCode`, `schema`, `surface`, `capabilities`, `fieldPolicies` or `platform/data` modules. The compiler derives the strict DataResource, CRUD capabilities, Surface and AI Schema. The application manifest still starts with its one top-level `schemaVersion: 3`.
 - Ordinary list/get/create/update/delete, filters, export and batch operations use the platform Native Data API. Do not create Function CRUD or NestJS wrappers.