openxiangda-skill-kit 2.0.0-alpha.88 → 2.0.0-alpha.89

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "openxiangda-skill-kit",
-  "version": "2.0.0-alpha.88",
+  "version": "2.0.0-alpha.89",
   "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.70"
+    "openxiangda-devkit-core": "2.0.0-alpha.71"
   },
   "devDependencies": {
     "tsx": "4.23.12",

package/skills/manifest.json

@@ -4,7 +4,7 @@
     {
       "name": "openxiangda-v2",
       "description": "Use when researching, designing, building, testing, or delivering a complete OpenXiangda 2.0 application.",
-      "sha256": "928646b9ded6fd61a73f3bd909d163d35b9735313e7bff40dc8490fbbdc32e1f"
+      "sha256": "08bd64cb7f0dee4889fd34e9081b3b01dcafa714273c51bae57ee9e22ccfcf9e"
     }
   ]
 }

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

@@ -8,8 +8,10 @@ source. Do not create `platform/data` modules.
 ```ts
 import {
   currentUserDataPolicy,
+  dataPolicyExpression,
   defineOpenXiangdaApp,
   resourceCapabilityCodes,
+  resourceReadPolicy,
 } from 'openxiangda/config';
 
 const APP_CODE = 'visitor-center';
@@ -119,10 +121,50 @@ currentUserDataPolicy({
 ```
 
 Put that value in `authz.dataPolicies`, declare both roles, and set the
-resource `dataPolicyCode` to the same code. Do not invent `operator`, `value`,
-`current_user: true`, lowercase match modes, a dotted value path, or
-policy-level `roleCodes`. The compiler and platform know that `user.*` fields
-compare their stable `value`; `field` remains the declared field root code.
+resource `dataPolicyCode` to the same code. Do not invent `current_user: true`,
+lowercase match modes, a dotted value path, or policy-level `roleCodes`. The
+compiler and platform know that `user.*` fields compare their stable `value`;
+`field` remains the declared field root code.
+
+For portal visibility windows, use the typed SDK expression and keep it a
+server-enforced read policy:
+
+```ts
+resourceReadPolicy({
+  code: 'published-articles',
+  name: '仅查看当前已发布内容',
+  resourceCode: 'articles',
+  matchMode: 'AND',
+  rules: [{ dimensionCode: 'organization', field: 'organizationId' }],
+  expression: dataPolicyExpression.allOf(
+    dataPolicyExpression.constant({
+      field: 'status', operator: 'eq', value: 'PUBLISHED',
+    }),
+    dataPolicyExpression.databaseNow({
+      field: 'publishAt', operator: 'lte',
+    }),
+    dataPolicyExpression.anyOf(
+      dataPolicyExpression.null({ field: 'expireAt', operator: 'is_null' }),
+      dataPolicyExpression.databaseNow({ field: 'expireAt', operator: 'gt' }),
+    ),
+  ),
+})
+```
+
+`db_now` is platform-owned PostgreSQL statement time and only accepts a
+`datetime` field. Missing/null values match only `is_null`; they do not match
+negative constants or time comparisons. The same bounded expression can
+combine `currentUser`, `dimension`, `relation`, `constant`, `null`, and
+`databaseNow` leaves under `allOf`/`anyOf`. Never duplicate this expression in
+a page `where` filter and call it authorization: UI filters are optional
+display state and cannot weaken or replace Native RLS.
+
+`readExpression` is always added on top of the base `matchMode`/`rules`; those
+base rules continue to restrict create/update/delete. If writes truly need no
+row scope beyond capability checks, say so explicitly with
+`writeBoundary: 'capability_only'` instead of `matchMode`/`rules`. Never use an
+empty base implicitly: `check` rejects it so an AI cannot accidentally remove
+write authorization while adding a portal read window.
 
 When a business membership resource is the durable source of a package role or
 RelationshipGrant, declare the projection instead of calling authorization