openxiangda-skill-kit 2.0.0-alpha.126 → 2.0.0-alpha.128

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "openxiangda-skill-kit",
-  "version": "2.0.0-alpha.126",
+  "version": "2.0.0-alpha.128",
   "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.104"
+    "openxiangda-devkit-core": "2.0.0-alpha.105"
   },
   "devDependencies": {
     "tsx": "4.23.12",

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

@@ -113,15 +113,20 @@ normal authorized role union with that Perspective before capability, field,
 row-policy and RLS evaluation. Omit the header for the complete union. Never
 use Perspective to guard writes, workflows or custom actions.
 
-`required: true` owns both storage nullability and form validation. A field
-without `access` inherits the resource read/create/update capability. Each
-access array is all-of; `false` is explicit deny. The same arrays drive the
-generated UI and platform field policies.
+`required: true` is a logical application rule: generated forms show it as
+required, and the Native Data API rejects omission on create or explicit null
+on create/update. It does not create PostgreSQL `NOT NULL`; every authored
+business column remains physically nullable so fields can be added or made
+required without a historical-data backfill. Older rows may therefore contain
+null when they predate the rule. A field without `access` inherits the resource
+read/create/update capability. Each access array is all-of; `false` is explicit
+deny. The same arrays drive the generated UI and platform field policies.
 
 For `uuid` fields, omission never generates a value. Only the resource system
 field `id` is platform-generated. An omitted optional UUID remains `null`; a
-required UUID must be supplied explicitly and cannot rely on an implicit
-database default.
+required UUID must be supplied by a current create request and cannot rely on
+an implicit database default. This is Data API validation, not a physical
+`NOT NULL` constraint.
 
 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.