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

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "openxiangda-skill-kit",
-  "version": "2.0.0-alpha.113",
+  "version": "2.0.0-alpha.115",
   "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

@@ -3,6 +3,25 @@
 - 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.
+- The platform `openxiangda/react` owns the only admin `ConfigProvider` and the
+  `light`/`dark`/`system` appearance preference. Admin pages use Ant Design's
+  `defaultAlgorithm`/`darkAlgorithm`, `theme.useToken()`, or generated
+  `--oxa-antd-*` CSS variables. Do not add a nested theme provider, theme
+  store, palette editor, `--oxa-color-*`/`--oxa-shell-*` aliases, or fixed
+  white/black/neutral structural colors. Future palettes are centralized
+  platform seed configurations; alpha contracts are replaced directly without
+  compatibility aliases. User-end pages are outside this admin visual contract
+  and may use Tailwind CSS and their own product design tokens/components, but
+  must not mutate the admin provider or Seed.
+- Use the complete Ant Design Seed/Map/Alias/Component model on admin pages:
+  platform-owned Seed values feed the selected algorithm; admin code consumes
+  generated Alias values for colors, spacing, typography, control dimensions,
+  motion, shadows, z-index and breakpoints. Never hand-write Map values or
+  introduce an admin token registry. Component tokens are only for
+  platform-approved non-color dimensions and typography.
+- The template includes Tailwind CSS v4 for user-end pages. Keep its `@theme`
+  and utility classes in the user-end layer, omit Tailwind preflight from the
+  admin shell, and do not make user-end utilities depend on `--oxa-antd-*`.
 - 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.
 - External users without platform accounts use only an exact static `surface: 'user'` route declared through `frontend.publicAccess`. Declare the one resource, bounded field sets, required operations, draft limits and named duplicate validations; consume only generated `anonymousPublicAccess` and `createAnonymousPublicClient`. `own.list`/`own.read` mean records submitted by the same platform-issued HttpOnly browser credential, not a verified natural person, and another browser or cleared cookie intentionally loses access. Never create a guest role/user, call the general Native Data API, expose an anonymous upload path, store identity locally or derive ownership from IP, user-agent or fingerprint.
@@ -12,7 +31,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 `[)`.