openxiangda 2.0.0-alpha.62 → 2.0.0-alpha.63

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "openxiangda",
-  "version": "2.0.0-alpha.62",
+  "version": "2.0.0-alpha.63",
   "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.143",
-    "openxiangda-contracts": "2.0.0-alpha.72",
-    "openxiangda-devkit-core": "2.0.0-alpha.92",
-    "openxiangda-mcp": "2.0.0-alpha.92",
-    "openxiangda-nest": "2.0.0-alpha.83",
-    "openxiangda-skill-kit": "2.0.0-alpha.113",
+    "openxiangda-cli": "2.0.0-alpha.144",
+    "openxiangda-contracts": "2.0.0-alpha.73",
+    "openxiangda-devkit-core": "2.0.0-alpha.93",
+    "openxiangda-mcp": "2.0.0-alpha.93",
+    "openxiangda-nest": "2.0.0-alpha.84",
+    "openxiangda-skill-kit": "2.0.0-alpha.114",
     "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.62 login --base-url <platform>
-pnpm dlx openxiangda@2.0.0-alpha.62 create <directory>
+pnpm dlx openxiangda@2.0.0-alpha.63 login --base-url <platform>
+pnpm dlx openxiangda@2.0.0-alpha.63 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.62 skill install --force
+pnpm dlx openxiangda@2.0.0-alpha.63 skill install --force
 ```
 
 Use this order:
@@ -41,7 +41,7 @@ pnpm exec openxiangda --mcp-stdio --cwd <workspace>
 
 Read `openxiangda://workspace/contracts` or call `contract_describe`. For first-time menu authoring, copy `data.adminNavigationAuthoring.suggestion.expression` once into `frontend.admin.navigation` with its listed `openxiangda/config` imports, then edit that application-owned declaration; never treat the proposal as runtime discovery. When AppSpec is enabled, read `openxiangda://workspace/appspec` or call `appspec_context`; treat it as advisory context, never as deployment authority. Require `aiCatalog` and `aiCatalogDigest` to match the normal compiler output. Never create an application MCP server, Catalog file, preview store or AI authorization path.
 
-Authenticated browser routes use the current logged-in user's complete application-role union. The only no-account exception is an exact static user route declared through `frontend.publicAccess`; it uses a platform-issued HttpOnly browser credential and dedicated `createAnonymousPublicClient` operations. It is not an application role, login session or general Data API identity. For both paths the platform remains authoritative for capabilities, fields, rows and RLS. A declared Perspective is only a read projection over the authenticated union: it may narrow pages, rows and readable fields, but never create/update/delete, workflow or custom-action authorization. Omitted Perspective means the complete union. Application code does not replace either identity, persist a platform token, construct an authorization result or keep a second permission state.
+Authenticated browser routes use the current logged-in user's complete application-role union. An application that serves every logged-in platform user may declare one existing package role through `authz.authenticatedUserRoleCode`; the platform materializes that role on first access and unions it with manual and business-projected roles. Do not fake the role in React, use a membership resource for a universal audience, or confuse the baseline access role with business membership. The only no-account exception is an exact static user route declared through `frontend.publicAccess`; it uses a platform-issued HttpOnly browser credential and dedicated `createAnonymousPublicClient` operations. It is not an application role, login session or general Data API identity. For both paths the platform remains authoritative for capabilities, fields, rows and RLS. A declared Perspective is only a read projection over the authenticated union: it may narrow pages, rows and readable fields, but never create/update/delete, workflow or custom-action authorization. Omitted Perspective means the complete union. Application code does not replace either identity, persist a platform token, construct an authorization result or keep a second permission state.
 
 Applications own one explicit typed admin navigation declaration. The compiler
 owns page/route generation, but it never turns every generated resource or

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

@@ -234,6 +234,31 @@ 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:
 
+For an application intended for every logged-in platform user, declare one
+baseline package role directly on `authz`. The platform materializes a real
+membership for that role on first access, so routes, Data RLS, Workflow and
+business actions consume the same union. Omit the declaration for applications
+that require explicit role assignment:
+
+```ts
+authz: {
+  authenticatedUserRoleCode: 'applicant',
+  capabilities: [/* explicit UI and backend capabilities */],
+  roles: [
+    {
+      code: 'applicant',
+      name: '普通申请人',
+      capabilities: [/* bounded baseline capabilities */],
+    },
+  ],
+}
+```
+
+The referenced role must exist and cannot also be the target of a
+`roleMembershipSource`. Use projected roles such as `member` for approved
+business membership and let the current user receive the union, for example
+`applicant + member`.
+
 ```ts
 authz: {
   // ...capabilities, roles and policies...

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

@@ -12,7 +12,7 @@
 - Add NestJS only for a named business action that needs a cross-resource transaction, an invariant or an external side effect.
 - Every interactive business action binds `@OpenXiangdaOperation(operation)` and injects `OpenXiangdaBusinessDataApiService`, `OpenXiangdaBusinessNotificationService`, or `OpenXiangdaStandardOperations`. The platform checks the action capability once at App API ingress; the trusted backend then has full Data/managed business-notification access only to its exact application/environment while audit retains the initiating user and action. Do not author `authorizationJSON`, forward user tokens, grant ordinary users `app:notification2:send`, or reapply the user's resource, row and field permissions inside the action.
 - A NestJS backend declares only `enabled`, `isolation: 'shared' | 'dedicated'` and `resourceProfile: 'light' | 'standard'`. Never put raw Kubernetes resources, replicas, ports or environment maps in application metadata; the platform owns capacity and scaling.
-- Use the current logged-in user and the union of that user's application roles. An optional declared Perspective projects only read visibility (pages, rows and fields); create/update/delete, workflows and custom actions continue to authorize against the complete union. Standard Data API calls inherit `X-OpenXiangda-Perspective` automatically. Use `@CurrentPerspective()` only when custom Nest code reads outside the standard Data API, and apply an equivalent read projection explicitly. Business code must not persist a platform Token or authorization result and must not implement a second identity path.
+- Use the current logged-in user and the union of that user's application roles. An app for every logged-in platform user may declare one existing package role through `authz.authenticatedUserRoleCode`; the platform materializes it on first access and unions it with manual and business-projected roles. Do not fabricate a browser fallback role or use a business membership resource for this universal audience. An optional declared Perspective projects only read visibility (pages, rows and fields); create/update/delete, workflows and custom actions continue to authorize against the complete union. Standard Data API calls inherit `X-OpenXiangda-Perspective` automatically. Use `@CurrentPerspective()` only when custom Nest code reads outside the standard Data API, and apply an equivalent read projection explicitly. Business code must not persist a platform Token or authorization result and must not implement a second identity path.
 - Fields inherit the resource read/create/update capabilities. Use field `access` only to tighten them; arrays are all-of and `false` is explicit deny. There is no `write` fallback.
 - Field `type` is semantic, never a hand-authored database type. The supported catalog is exactly `text.short`, `text.long`, `text.rich`, `number.integer`, `number.decimal`, `boolean`, `date`, `time`, `datetime`, `date-range`, `datetime-range`, `option.single`, `option.multiple`, `cascade.single`, `cascade.multiple`, `user.single`, `user.multiple`, `department.single`, `department.multiple`, `resource-ref.single`, `resource-ref.multiple`, `file`, `image`, `signature`, `address`, `location`, `json`, `serial-number`, `uuid` and `subtable`. The compiler alone derives PostgreSQL columns, constraints and indexes.
 - Every `date-range` and `datetime-range` field explicitly declares `rangeBoundary: 'closed' | 'half-open'`. Values remain `{ start, end }`; callers never send or override the boundary. Closed ranges allow `start <= end` and use PostgreSQL `[]`; half-open ranges require `start < end` and use `[)`.