openxiangda 2.0.0-alpha.22 → 2.0.0-alpha.24

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "openxiangda",
-  "version": "2.0.0-alpha.22",
+  "version": "2.0.0-alpha.24",
   "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.109",
-    "openxiangda-contracts": "2.0.0-alpha.51",
-    "openxiangda-devkit-core": "2.0.0-alpha.68",
-    "openxiangda-mcp": "2.0.0-alpha.68",
-    "openxiangda-nest": "2.0.0-alpha.62",
-    "openxiangda-skill-kit": "2.0.0-alpha.86",
+    "openxiangda-cli": "2.0.0-alpha.111",
+    "openxiangda-contracts": "2.0.0-alpha.53",
+    "openxiangda-devkit-core": "2.0.0-alpha.70",
+    "openxiangda-mcp": "2.0.0-alpha.70",
+    "openxiangda-nest": "2.0.0-alpha.64",
+    "openxiangda-skill-kit": "2.0.0-alpha.88",
     "xlsx": "https://cdn.sheetjs.com/xlsx-0.20.3/xlsx-0.20.3.tgz"
   },
   "peerDependencies": {

package/skills/manifest.json

@@ -4,7 +4,7 @@
     {
       "name": "openxiangda-v2",
       "description": "Use when researching, designing, building, testing, or delivering a complete OpenXiangda 2.0 application.",
-      "sha256": "0d7a537bb7af5b79bc9e9b78de2a078cfc39201d65cecffd78231086cfa2bf55"
+      "sha256": "928646b9ded6fd61a73f3bd909d163d35b9735313e7bff40dc8490fbbdc32e1f"
     }
   ]
 }

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.22 login --base-url <platform>
-pnpm dlx openxiangda@2.0.0-alpha.22 create <directory>
+pnpm dlx openxiangda@2.0.0-alpha.24 login --base-url <platform>
+pnpm dlx openxiangda@2.0.0-alpha.24 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.22 skill install --force
+pnpm dlx openxiangda@2.0.0-alpha.24 skill install --force
 ```
 
 Use this order:
@@ -29,7 +29,7 @@ Use this order:
 5. For every resource or permission change, read [Data and authorization](references/data-authz.md) before editing `openxiangda.config.ts`.
 6. Read [Frontend](references/frontend.md) for pages or fields and [Backend actions](references/backend.md) only for a real business action.
 7. When the application explicitly enables standard approval, application events or notifications, read [Workflow, Events and Notification Hub](references/workflow-events.md). Keep them optional and out of ordinary CRUD.
-8. Run the connected loop with `pnpm openxiangda dev`, then follow [Testing](references/testing.md) and `pnpm openxiangda check`.
+8. Run the connected loop with `pnpm openxiangda dev`, then follow [Testing](references/testing.md) and `pnpm openxiangda check`; check performs the target platform's read-only Native compatibility preflight before application checks or builds.
 9. Follow [Delivery](references/delivery.md): deploy preproduction first, inspect status/logs, then promote the exact successful version to production.
 
 For an AI-native client, start the workspace protocol through the same pinned executable:

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

@@ -6,7 +6,7 @@
 | --- | --- | --- |
 | `pnpm openxiangda create` | deploy | 创建、绑定并初始化应用 |
 | `pnpm openxiangda dev` | write-local | 连接平台测试数据启动本地 Web 与 Nest |
-| `pnpm openxiangda check` | write-local | 生成契约并执行检查、测试和构建 |
+| `pnpm openxiangda check` | write-local | 生成契约并在目标平台预检后执行检查、测试和构建 |
 | `pnpm openxiangda accept` | deploy | 按计划准备可选的真实预发验收身份 |
 | `pnpm openxiangda deploy` | deploy | 部署测试环境或显式复用测试版本部署生产 |
 | `pnpm openxiangda status` | read | 查询最近或指定部署状态 |

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

@@ -124,4 +124,50 @@ resource `dataPolicyCode` to the same code. Do not invent `operator`, `value`,
 policy-level `roleCodes`. The compiler and platform know that `user.*` fields
 compare their stable `value`; `field` remains the declared field root code.
 
+When a business membership resource is the durable source of a package role or
+RelationshipGrant, declare the projection instead of calling authorization
+management endpoints from application code:
+
+```ts
+authz: {
+  // ...capabilities, roles and policies...
+  roleMembershipSources: [{
+    code: 'venue-managers',
+    name: '场馆管理员角色成员',
+    resourceCode: 'venue-manager-relations',
+    userIdField: 'manager.value',
+    roleCode: 'venue_admin',
+    enabledField: 'enabled',
+    failureMode: 'strict',
+  }],
+  relationshipGrantSources: [{
+    code: 'venue-member-grants',
+    name: '场馆成员关系授权',
+    resourceCode: 'venue-manager-relations',
+    subject: { type: 'user', userIdField: 'manager.value' },
+    relationCode: 'member',
+    targetResourceCode: 'venues',
+    resourceIdField: 'venue.value',
+    operations: ['read', 'update'],
+    enabledField: 'enabled',
+    failureMode: 'strict',
+  }],
+}
+```
+
+The user path must be `user.single.value`; the target path is `id` only when the
+source resource is also the target resource, or a `resource-ref.single.value`
+that points at the declared target resource.
+Operations are a bounded constant list. Create/update/delete the relationship
+resource through the standard Data API; the platform converges and revokes only
+the facts owned by that source. Projection failure is always strict because a
+last-known-good grant could defeat revocation.
+
+Use the SDK projection health call after deployment. A platform operator with
+the existing authorization-management capability may run rebuild for historical
+rows or recover a dead-letter job. Rebuild/recovery are idempotent and accept an
+`operationId`; they never accept a user token, user id override or impersonation
+input. Do not write `sourceCode`, canonical membership rows or relationship
+grant rows yourself.
+
 Run `pnpm openxiangda check` after every declaration or permission change.

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

@@ -1,7 +1,22 @@
 # OpenXiangda 2.0 Delivery
 
-Run `pnpm openxiangda check --json`; it owns generation, static checks, tests
-and production builds but deliberately does not seal an AppPackage. Its
+Run `pnpm openxiangda check --json`; it defaults to the test target, compiles
+the complete configuration and contract bundles, and asks the target
+platform's advertised `configurationCompatibility` endpoint to run the same
+Native compiler validation used during deployment preparation. This read-only
+preflight happens before workspace checks, tests, builds, Buildx or uploads.
+Use `--environment production` only when explicitly checking that target. A
+failure preserves `pointer`, client contract/schema versions, platform
+version/capability and the required/supported application-contract tuples.
+The capability also publishes the existing 4 MiB configuration, 8 MiB
+contract and 10 MiB total request bounds so oversized input fails before the
+transport layer.
+Never remove generated fields, reduce versions, raise limits, add app-code
+exceptions or introduce 1.x compatibility to make it pass. The platform
+revalidates authoritatively during deployment preparation.
+
+After compatibility succeeds, check owns static checks, tests and production
+builds but deliberately does not seal an AppPackage. Its
 `data.sealedArtifact` object and `.openxiangda/build/seal-status.json` make that
 state explicit even when an older `app-package.json` remains on disk. Deploy to
 test with the returned `openxiangda deploy` next command. Deploy owns the

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

@@ -1,8 +1,11 @@
 # Testing and Acceptance
 
 Run `pnpm openxiangda check --json` after declaration or code changes. It owns
-generation, static validation, unit tests and production builds; preserve its
-stable diagnostic instead of bypassing a failing stage. Read
+generation plus a read-only Native compatibility preflight against the test
+platform before static validation, unit tests or production builds. Use
+`--environment production` only for an explicit production-target check.
+Preserve the stable diagnostic and JSON pointer instead of bypassing a failing
+stage. Read
 `data.sealedArtifact` in the machine result. A successful check always reports
 `state: "check-did-not-seal"`, `sealed: false` and
 `usableForDeploy: false`; it may also describe an older package as
@@ -20,8 +23,11 @@ For each changed resource, verify the real chain:
 6. PostgreSQL/RLS remains authoritative, including current-user and multi-role-union cases.
 
 For platform generator changes, add a representative multi-resource fixture
-(currently nineteen standard resources), assert each Surface literal is emitted
-only once, then run the unchanged Web dist budget gate. A budget failure is a
+(the compatibility corpus fixes 43 resources, complete list/form/detail/mobile
+surfaces, Perspective/AuthZ/Workflow/Event and exactly 161 producers), assert
+the real toolchain generator output remains byte-identical, and pass the same
+fixture through the platform's exported Native validator. Then run the unchanged
+Web dist budget gate. A budget failure is a
 generator/runtime regression to fix; never raise the application budget or copy
 generated contracts into a smaller application-local format. Browser acceptance
 must also cover the large more-filters modal, declaration-order forms, hidden