openxiangda-skill-kit 2.0.0-alpha.113 → 2.0.0-alpha.114

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "openxiangda-skill-kit",
-  "version": "2.0.0-alpha.113",
+  "version": "2.0.0-alpha.114",
   "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.92"
+    "openxiangda-devkit-core": "2.0.0-alpha.93"
   },
   "devDependencies": {
     "tsx": "4.23.12",

package/skills/openxiangda-v2/SKILL.md

@@ -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 `[)`.