openxiangda-skill-kit 2.0.0-alpha.70 → 2.0.0-alpha.71
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/package.json +2 -2
- package/skills/openxiangda-v2/SKILL.md +3 -3
- package/skills/openxiangda-v2/references/backend.md +1 -1
- package/skills/openxiangda-v2/references/delivery.md +1 -1
- package/skills/openxiangda-v2/references/frontend.md +1 -1
- package/skills/openxiangda-v2/references/workspace.md +4 -4
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "openxiangda-skill-kit",
|
|
3
|
-
"version": "2.0.0-alpha.
|
|
3
|
+
"version": "2.0.0-alpha.71",
|
|
4
4
|
"description": "Validation and deterministic packaging for OpenXiangda 2.0 AI skills.",
|
|
5
5
|
"type": "module",
|
|
6
6
|
"main": "./dist/index.js",
|
|
@@ -17,7 +17,7 @@
|
|
|
17
17
|
"README.md"
|
|
18
18
|
],
|
|
19
19
|
"dependencies": {
|
|
20
|
-
"openxiangda-devkit-core": "2.0.0-alpha.
|
|
20
|
+
"openxiangda-devkit-core": "2.0.0-alpha.53"
|
|
21
21
|
},
|
|
22
22
|
"devDependencies": {
|
|
23
23
|
"tsx": "4.23.12",
|
|
@@ -5,9 +5,9 @@ description: Use when building, inspecting, validating, or delivering a complete
|
|
|
5
5
|
|
|
6
6
|
# OpenXiangda 2.0
|
|
7
7
|
|
|
8
|
-
Use the generated React, NestJS and Data API workspace as one application. Before a workspace exists, invoke the exact 2.0 package published with this Skill: `pnpm dlx openxiangda-cli@2.0.0-alpha.
|
|
8
|
+
Use the generated React, NestJS and Data API workspace as one application. Before a workspace exists, invoke the exact 2.0 package published with this Skill: `pnpm dlx openxiangda-cli@2.0.0-alpha.86`. Inside an application use only its locked CLI through `pnpm openxiangda`; never invoke a bare global `openxiangda`, because that executable may belong to 1.x.
|
|
9
9
|
|
|
10
|
-
Start with `pnpm dlx openxiangda-cli@2.0.0-alpha.
|
|
10
|
+
Start with `pnpm dlx openxiangda-cli@2.0.0-alpha.86 login`, then `pnpm dlx openxiangda-cli@2.0.0-alpha.86 create <directory>`. Run `pnpm openxiangda dev` for the local feedback loop and `pnpm openxiangda check` before delivery. Moving tags such as `latest` and `alpha` are forbidden for bootstrap because package-manager metadata and dlx caches can resolve an older toolchain.
|
|
11
11
|
|
|
12
12
|
For an AI-native development client, start the workspace MCP through the same
|
|
13
13
|
pinned executable with `pnpm exec openxiangda --mcp-stdio --cwd <workspace>`.
|
|
@@ -28,7 +28,7 @@ once. `schema`, `surface`, resource `capabilities`, resource `fieldPolicies` and
|
|
|
28
28
|
|
|
29
29
|
Deploy test data first with `pnpm openxiangda deploy`. Inspect it with `pnpm openxiangda status` and `pnpm openxiangda logs`. Select production explicitly only after the same tested version succeeds. Use `pnpm openxiangda rollback --to <app-version-id>` when a verified prior version must be restored.
|
|
30
30
|
|
|
31
|
-
OpenXiangda 2.0 has no compatibility surface. Do not add Umi, ProComponents, RoleSession, Function CRUD, underscore resource codes, `fieldPolicies.write`, legacy Skill routing, package aliases or migration branches. Replace a wrong alpha contract directly.
|
|
31
|
+
OpenXiangda 2.0 has no compatibility surface. Do not add Umi, ProComponents, an application-owned RoleSession store, Function CRUD, underscore resource codes, `fieldPolicies.write`, legacy Skill routing, package aliases or migration branches. The generated integration may transport the platform-owned opaque RoleSession in memory, but application business code never reads or persists it. Replace a wrong alpha contract directly.
|
|
32
32
|
|
|
33
33
|
Read only the reference needed for the current change, except that CRUD work
|
|
34
34
|
always reads Data and authorization as required above:
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
# OpenXiangda 2.0 Backend
|
|
2
2
|
|
|
3
|
-
Keep normal record CRUD in the platform Data API. Use `apps/server` only for typed business actions that need server-side logic.
|
|
3
|
+
Keep normal record CRUD in the platform Data API. Use `apps/server` only for typed business actions that need server-side logic. For an interactive request, the platform gateway supplies the verified current user, one active application role and its capabilities from the same RoleSession used by Data API. Controllers bind operations and capabilities through the Nest SDK; workers continue to use their explicit application identity.
|
|
4
4
|
|
|
5
5
|
Do not duplicate resource persistence in controllers. Keep actions bounded and side-effect behavior explicit. Run `pnpm openxiangda dev` for the connected loop and `pnpm openxiangda check` before delivery.
|
|
6
6
|
|
|
@@ -6,6 +6,6 @@ Use `pnpm openxiangda status` and `pnpm openxiangda logs` without an ID for the
|
|
|
6
6
|
|
|
7
7
|
For the AI-native MCP entrypoint, `build_app` and `deployment_plan` are explicitly unsealed previews. After the user authorizes deployment, call `deploy_app` without any image coordinate; it owns the same automatic Buildx, push, digest and sealing path as the CLI.
|
|
8
8
|
|
|
9
|
-
Applications with Native Data Resources automatically require `data.native-golden-crud`. If deployment returns `OPENXIANGDA_REQUIRED_CAPABILITY_UNAVAILABLE`, preserve the remediation to upgrade the platform and retry the same deploy command. Never remove the requirement, edit the AppPackage,
|
|
9
|
+
Applications with Native Data Resources automatically require `data.native-golden-crud`. If deployment returns `OPENXIANGDA_REQUIRED_CAPABILITY_UNAVAILABLE`, preserve the remediation to upgrade the platform and retry the same deploy command. Never remove the requirement, edit the AppPackage, bypass the standard platform RoleSession transport, or create Function-based CRUD.
|
|
10
10
|
|
|
11
11
|
After a successful test run, deploy the exact same version with `pnpm openxiangda deploy --environment production --from <test-deployment-id>`. Roll back with `pnpm openxiangda rollback --environment production --to <app-version-id>`. The platform owns durable deployment state.
|
|
@@ -7,4 +7,4 @@ CSV/XLS/XLSX preview import, export, filters, column settings and density. Keep
|
|
|
7
7
|
imports at 100 rows per transaction, use exact declared labels or field codes,
|
|
8
8
|
and leave attachment values to the platform managed-file component.
|
|
9
9
|
|
|
10
|
-
Read the current user, role
|
|
10
|
+
Read the current user, one current application role and capabilities from the platform RoleSession context. Keep switching in the generated application's personal menu; switching replaces the page and request identity rather than merging roles. The standard client carries the opaque RoleSession in memory for Data, Directory, file and App API requests. Use capabilities and field access only to present or disable UI, and never expose or persist the RoleSession identifier. Strip unauthorized fields from create and update payloads; never treat a disabled input as server authorization. Verify with `pnpm openxiangda check`.
|
|
@@ -7,13 +7,13 @@
|
|
|
7
7
|
- 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.
|
|
8
8
|
- Add NestJS only for a named business action that needs a cross-resource transaction, an invariant or an external side effect.
|
|
9
9
|
- 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.
|
|
10
|
-
- Use the current logged-in user and the union of application roles.
|
|
10
|
+
- Use the current logged-in user and the union of that user's application roles. The generated shell automatically carries the platform's opaque authorization context for Data, Directory and App API requests. Business code must not read or persist that identifier, a platform Token, or authorization results, and must not implement a second identity path.
|
|
11
11
|
- 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.
|
|
12
|
-
- Field
|
|
12
|
+
- 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.
|
|
13
13
|
- Declare every custom operation capability in `authz.capabilities` with `kind: 'backend'`, then reference that same code from the operation and its allowed roles. Generated resource CRUD capabilities do not go in this catalog.
|
|
14
14
|
- Visitor duplicate protection uses `createVisitorReservation({ duplicateMatch: { fieldCode: submittedValue }, ... })`. `duplicateMatch` is a non-empty value map, never a field-name array, and no mutable pre-read is allowed.
|
|
15
|
-
- Desktop and mobile pages share values, validation and authorization, but use separate renderers.
|
|
16
|
-
-
|
|
15
|
+
- Desktop and mobile pages share values, validation and authorization, but use separate renderers. Options, members, departments and resource references store their complete display snapshots; attachments, images and signatures use platform-managed file references.
|
|
16
|
+
- `option.*`, `user.*`, `department.*` and `resource-ref.*` values never collapse to scalar IDs. Single values store one labeled snapshot and multiple values store snapshot arrays. `location` accepts only exact WGS84 coordinates captured by DingTalk or browser geolocation; it has no manual input or `manual` source. Roles that consume directory-backed fields explicitly include `app:<app-code>:directory:read`.
|
|
17
17
|
- Derive role grants with `resourceCapabilityCodes(appCode, resourceCode)`. Declare current-user rows only with `currentUserDataPolicy(...)`; do not invent operators, values or alternate current-user spellings.
|
|
18
18
|
- Do not add compatibility aliases, migration branches or silent fallbacks for an earlier 2.0 alpha contract. Replace an incorrect contract and regenerate the application.
|
|
19
19
|
- Run `pnpm openxiangda check` after contract changes. Deploy with `pnpm openxiangda deploy`, inspect with `pnpm openxiangda status` and `pnpm openxiangda logs`, and use the platform rollback command rather than mutating K3s directly.
|