openxiangda-skill-kit 2.0.0-alpha.94 → 2.0.0-alpha.97

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "openxiangda-skill-kit",
-  "version": "2.0.0-alpha.94",
+  "version": "2.0.0-alpha.97",
   "description": "Validation and deterministic packaging for OpenXiangda 2.0 AI skills.",
   "type": "module",
   "main": "./dist/index.js",
@@ -17,7 +17,7 @@
     "README.md"
   ],
   "dependencies": {
-    "openxiangda-devkit-core": "2.0.0-alpha.75"
+    "openxiangda-devkit-core": "2.0.0-alpha.76"
   },
   "devDependencies": {
     "tsx": "4.23.12",

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

@@ -14,6 +14,15 @@ for this exact application, environment, version and operation. Do not forward
 the caller's resource, row or field permissions into that internal Data call,
 and do not author an `authorizationJSON` permission mirror. The platform still
 records the initiating user and action code in records, files, events and audit.
+The platform models this internal hop as the request-bounded
+`native-business-action` principal. It is neither an OAuth client nor a Native
+runtime credential: PostgreSQL accepts it only after the platform has verified
+the signed Gateway invocation, exact target/Head, published
+`code + requiredCapability`, application data scope and initiating user. Never
+copy an invocation token into application data, construct the action headers
+yourself, or fall back to `OpenXiangdaApplicationDataApiService` when this
+channel is rejected; a rejection means the platform/package combination is not
+compatible or the invocation is stale.
 
 For an informational business notification, inject
 `OpenXiangdaBusinessNotificationService` in the same declared action. The SDK

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

@@ -109,6 +109,12 @@ generated UI and platform field policies.
 
 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
+`label` snapshots for `option.*`, `user.*`, `department.*` and
+`resource-ref.*`, including multiple arrays and the first linked list column.
+Do not add application formatters, directory re-queries or browser-side joins
+for these standard fields.
+
 Numeric bounds belong on the field declaration and are enforced by the
 platform for every write path. They are inclusive, and only valid on
 `number.integer` or `number.decimal`:

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

@@ -43,6 +43,18 @@ discovery, and permission logic cannot create entries. Read
 proposal is deterministic and editable; the compiler/runtime never invokes it
 or appends newly added resources later.
 
+Generated desktop resource CRUD routes use the compiler-owned
+`/admin/resources/<resourceCode>...` namespace and always render inside the
+platform's one Shell. Their independent mobile admin surface is projected from
+the same generated route catalog under `/m/admin/resources/<resourceCode>...`.
+Generated pages consume that catalog for every list/create/detail/edit/back
+navigation; do not reconstruct root resource paths in application code. Root
+and ordinary `/m/...` paths remain available to explicit user routes. The
+compiler rejects an explicit route whose canonical path shape conflicts with
+any explicit or platform-generated route, including dynamic routes that differ
+only by parameter name. Do not add aliases, redirects or route-order branches
+for earlier alpha paths.
+
 Declare custom routes in `openxiangda.config.ts`, import the generated
 `appRoutes`, and bind every route key to exactly one local React page with
 `defineApplicationContributions` from `openxiangda/react`. Pass the result to

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

@@ -3,7 +3,7 @@
 - Use only the workspace-pinned CLI: `pnpm openxiangda <command>`. Never invoke a bare global `openxiangda` inside a 2.0 task.
 - `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. Use only its 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.
+- 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.
 - 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.