openxiangda 2.44.0 → 2.55.1

package/releases/2.51.0.json

@@ -0,0 +1,32 @@
+{
+  "schemaVersion": "openxiangda.release-notes/v1",
+  "version": "2.51.0",
+  "status": "reviewed",
+  "title": "固定流程支持通知最后业务修改人",
+  "summary": "申请被拒绝时，在原事务冻结最后成功业务写入者，通知队列沿原事实投递和恢复。",
+  "newFeatures": [
+    "流程定义新增固定 rejectionNotification 声明，源码与目标编译器导出相同能力闭包。",
+    "平台读取 Native updated_by 与当前资料 revision，固定一个有效用户或明确跳过原因。",
+    "通知中心复用标准模板、站内消息、导航和 outbox，不要求应用后端或自建订阅。"
+  ],
+  "fixes": [],
+  "affectedUsers": [
+    "需要向最后业务修改人发送拒绝通知的 V2 流程应用。"
+  ],
+  "upgradeSteps": [
+    "消费同源包和提供 workflow.rejection-notification@1.0.0 的 Server，再注册与激活新固定流程版本。",
+    "声明固定文案和 record_last_modifier 收件来源；初始化无需增加开关。"
+  ],
+  "knownLimitations": [
+    "尚未发布 npm、写学校或生产数据；本地应用运行验收待共享平台验证结束。",
+    "最后成功业务写入者是明确目标语义，宜搭 form_inst_modifier 的事件时点仍需另核。",
+    "修改人当前无法查看详情时，消息跳转按现有权限拒绝，不扩大授权。"
+  ],
+  "issues": [],
+  "compatibility": {
+    "node": ">=24",
+    "platform": "workflow.rejection-notification@1.0.0；未声明应用和旧固定实例继续原行为。"
+  },
+  "sha256": "598c4fd3660cbe3d50693da26488fa6b31f400ad71f330f4dda6382b97552a33",
+  "url": "https://github.com/1377385356/openxiangda/releases/tag/v2.51.0"
+}

package/releases/2.54.4.json

@@ -0,0 +1,30 @@
+{
+  "schemaVersion": "openxiangda.release-notes/v1",
+  "version": "2.54.4",
+  "status": "reviewed",
+  "title": "原子业务审批的最终状态合同修正",
+  "summary": "同源SDK的审批事务守卫对齐Workflow实例实际的已通过、已拒绝状态，防止最终审批或驳回被错误阻断。",
+  "newFeatures": [],
+  "fixes": [
+    "expectedTransition.status使用running、approved、rejected、withdrawn；拒绝将任务completed状态当作实例状态。",
+    "Schema与公开TypeScript类型同步，补充四种实际状态与错误completed状态的回归验证。"
+  ],
+  "affectedUsers": [
+    "显式使用definition.commandHandlers及BusinessProcess.commandWithData的V2应用。"
+  ],
+  "upgradeSteps": [
+    "整体使用同源SDK发行，并配套接受实际实例状态的平台Server；在测试环境验证原token、回执、补填及业务效果的原子提交。"
+  ],
+  "knownLimitations": [
+    "这是本机测试候选，npm发布和真实三端业务验收分别记录，源码检查不代表完成交付。",
+    "固定handler仍仅支持approve、reject、withdraw；不降级为分离事务，也不支持跳转、强制决定或自动同意。",
+    "正式npm发行验证仍需配套参考应用锁文件；本机同源制品不替代该门禁。"
+  ],
+  "issues": [],
+  "compatibility": {
+    "node": ">=24",
+    "platform": "workflow.business-data-command@1.0.0，Server使用真实实例状态与同事务Native效果。"
+  },
+  "sha256": "245c53a18b1af890f22f38e5d0f75129e47aaae8898ae98844fa0ebd141ba48b",
+  "url": "https://github.com/1377385356/openxiangda/releases/tag/v2.54.4"
+}

package/releases/2.54.6.json

@@ -0,0 +1,30 @@
+{
+  "schemaVersion": "openxiangda.release-notes/v1",
+  "version": "2.54.6",
+  "status": "reviewed",
+  "title": "业务提交前检查必需审批人",
+  "summary": "流程可显式要求提交前解析指定审批节点。缺少当前有效审批人时，平台在业务事务内拒绝申请，避免保存后留下无法推进的流程。",
+  "newFeatures": [
+    "固定 definition.launchPreflight.requiredApprovalNodes 指定最多20个必需审批节点，两端编译器验证引用、范围和本机参与人来源。",
+    "BusinessProcess 同事务解析当前有效配置与 Native 角色成员；原成功提交回执优先返回，实际节点进入仍重新核验审批人。"
+  ],
+  "fixes": [],
+  "affectedUsers": [
+    "需要在保存申请时保证前置审批人存在的 V2 应用；仅显式声明时要求新平台能力。"
+  ],
+  "upgradeSteps": [
+    "完整升级同源SDK与支持 workflow.launch-preflight@1.0.0 的平台，然后为所需审批节点声明准入并验证当前角色范围。"
+  ],
+  "knownLimitations": [
+    "当前为本机开发候选，未发布 npm 或学校生产；工具检查、平台事务测试与真实应用角色验收分别记录。",
+    "仅支持 fixed_users、initiator、app_role、app_role_in_scope；未来任务字段、外部provider和交互选人不参与同步准入。",
+    "准入不冻结未来参与人，成功后人员改变仍由实际节点进入处理；正式 npm 发行门禁尚未完成。"
+  ],
+  "issues": [],
+  "compatibility": {
+    "node": ">=24",
+    "platform": "workflow.launch-preflight@1.0.0（显式声明才要求）"
+  },
+  "sha256": "ca379b1ab33ef8362ea34b9242cc30772caf30c0830f2a77fbd4dba1b17a6c21",
+  "url": "https://github.com/1377385356/openxiangda/releases/tag/v2.54.6"
+}

package/releases/2.55.0.json

@@ -0,0 +1,34 @@
+{
+  "schemaVersion": "openxiangda.release-notes/v1",
+  "version": "2.55.0",
+  "status": "reviewed",
+  "title": "流程拒绝意见策略与受限资料编辑",
+  "summary": "流程定义可显式允许选填拒绝意见，保留旧流程必填默认和管理员收紧边界；同步主线的具名资料编辑支持固定字段及受限输入。",
+  "newFeatures": [
+    "固定审批节点可声明 operationPolicy.reject.commentRequired:false；省略时仍必填，新声明要求 workflow.optional-rejection-comment@1.0.0。",
+    "具名资料编辑可声明固定资源和字段，复用受限人员、字典和托管附件输入，PC 与移动页共用 Field Kit。"
+  ],
+  "fixes": [
+    "审批节点 JSON Schema 接受并有界校验正式 operationPolicy，Surface 和执行端使用同一冻结策略。",
+    "主线修正 dataCommands 在开发配置和产物投影中的遗漏。"
+  ],
+  "affectedUsers": [
+    "需要保留选填拒绝意见语义的 V2 流程，或使用具名动作编辑固定资料字段的应用。"
+  ],
+  "upgradeSteps": [
+    "完整升级同源 SDK 与目标平台；选填拒绝意见须启用支持该能力的平台，并以新不可变流程版本声明。",
+    "已有任务继续使用进入节点时冻结的规则，管理员不得放宽代码必填策略。"
+  ],
+  "knownLimitations": [
+    "当前用于本机开发配套，不代表 npm 或学校生产已发布；真实应用验收单独记录。",
+    "选填仅允许省略、空串或空白；已提供的非字符串及超过 4000 字符仍拒绝。",
+    "具名资料编辑仍受动作能力、行范围和原修订校验约束，不开放普通 UPDATE。"
+  ],
+  "issues": [],
+  "compatibility": {
+    "node": ">=24",
+    "platform": "显式选填要求 workflow.optional-rejection-comment@1.0.0；具名资料编辑按声明要求匹配平台能力"
+  },
+  "sha256": "c48e83ce9ccb01af7e8af97458fee0fb192e0945fc6a596b985ed1fffaf876a0",
+  "url": "https://github.com/1377385356/openxiangda/releases/tag/v2.55.0"
+}

package/releases/2.55.1.json

@@ -0,0 +1,32 @@
+{
+  "schemaVersion": "openxiangda.release-notes/v1",
+  "version": "2.55.1",
+  "status": "reviewed",
+  "title": "持久原结果恢复与流程字段策略修复",
+  "summary": "已受理命令的短读取超时不会提前终止原三十分钟观察；同步主线的条件必填错误清理和冻结的选填撤回原因策略。",
+  "newFeatures": [
+    "固定流程定义支持 instanceCommands.withdraw.reasonRequired:false；省略仍必填，新声明要求 workflow.optional-withdrawal-reason@1.0.0。"
+  ],
+  "fixes": [
+    "已受理 durable 原结果查询收到 SDK 明确标记可恢复的短读取预算耗尽后，在原绝对截止前按退避继续只读查询；不重放提交。",
+    "另一字段解除条件必填后清除 SDK 自己生成的旧必填错误，保留其他客户端、子表和服务端错误。"
+  ],
+  "affectedUsers": [
+    "使用 durable 持久命令的热点报名应用和包含条件必填或撤回策略的 V2 流程。"
+  ],
+  "upgradeSteps": [
+    "使用正式精确版本升级应用 SDK；原结果恢复无需更改服务端协议。",
+    "使用选填撤回原因时，平台必须具备对应能力；已有实例继续使用冻结版本。"
+  ],
+  "knownLimitations": [
+    "一次读取仍最多两分钟，总观察仍为原三十分钟；权限、依赖和普通网络错误不会被自动隐藏。",
+    "容量必须在目标硬件上独立测量；单元验证不能证明万人或浏览器洪峰已通过。"
+  ],
+  "issues": [],
+  "compatibility": {
+    "node": ">=24",
+    "platform": "durable 恢复沿用既有结果协议；显式选填撤回原因要求 workflow.optional-withdrawal-reason@1.0.0"
+  },
+  "sha256": "c6c0691f9fe9571dfe1c9078546a5db3f63645ba11a67a3f3d0d6324ba7713d1",
+  "url": "https://github.com/1377385356/openxiangda/releases/tag/v2.55.1"
+}

package/skills/manifest.json

@@ -4,7 +4,7 @@
     {
       "name": "openxiangda-v2",
       "description": "使用 OpenXiangda 2.0 从模糊业务想法、已有资料或具体变更出发，通过对话发现模块、完成详细产品设计，由当前 AI Agent 按需用 Image 2.5 等图片能力形成视觉参考，直接实现真实页面并在浏览器修正，再检查和交付应用；维护 1.x 应用时使用对应的 1.x 技能。",
-      "sha256": "9350d7e567e877208b86929f0eeedade792f9750989ca08055061092c980ec37"
+      "sha256": "a8cd59d165b5b58e5c39ce53b7e19b6a886d0567d3da711f721fce35e806a591"
     }
   ]
 }

package/skills/openxiangda-v2/SKILL.md

@@ -40,10 +40,10 @@ AI 接到新应用、页面或改版任务时，在同一个 OpenXiangda 工作
 未创建工作区时使用本 Skill 随根包发布的精确版本：
 
 ```bash
-pnpm dlx openxiangda@2.44.0 auth status --cwd <应用目录> --base-url <平台地址> --json
-pnpm dlx openxiangda@2.44.0 login --cwd <应用目录> --base-url <平台地址>
-pnpm dlx openxiangda@2.44.0 create <应用目录> --base-url <同一平台地址>
-pnpm dlx openxiangda@2.44.0 skill install --force
+pnpm dlx openxiangda@2.55.1 auth status --cwd <应用目录> --base-url <平台地址> --json
+pnpm dlx openxiangda@2.55.1 login --cwd <应用目录> --base-url <平台地址>
+pnpm dlx openxiangda@2.55.1 create <应用目录> --base-url <同一平台地址>
+pnpm dlx openxiangda@2.55.1 skill install --force
 ```
 
 创建前把产品要求的目标平台明确带入命令，不从旧登录态推断站点。已有工作区从原绑定恢复，平台不一致时先解决登录与目标，不改 link 文件跨站创建。

package/skills/openxiangda-v2/references/administration.md

@@ -2,6 +2,12 @@
 
 平台的应用管理控制台维护应用成员、角色授权和流程运行参数。应用自身声明的 `/admin` 业务菜单展示业务页面，两者职责不同。可见入口和可执行操作以当前用户与目标环境返回结果为准。
 
+角色成员的范围维度也支持模型字段的 `userCandidates.scope` 引用，不要求为审批人职责增加无关的数据读写策略。目录 `scopeDimensions[].applicability.candidateFields` 返回字段所在的资源、数据修订、字段、角色与操作；当前环境及仍在办理的历史流程所引用的字段均可贡献范围适用性。实例完成或发起命令取消后，旧字段不再单独贡献适用性。配置成员的范围不会自动授予数据读写、菜单或应用管理权限；实际选人与提交仍核验范围、操作、成员有效期及账号状态。
+
+流程的 `app_role_in_scope` 绑定也贡献范围适用性，包括审批、抄送、兼容的节点人员覆盖及路由补充来源。目录 `scopeDimensions[].applicability.workflowBindings` 返回流程、节点、角色、定义/绑定版本、配置修订、来源和 `active`/`in_flight` 上下文；不包含业务事实或标题。当前启用定义和仍在办理的固定版本均可维护其职责，终态实例或已取消发起命令不再单独贡献适用性。
+
+自定义管理页面按“候选字段引用该角色、有效流程范围职责引用该角色，或任一数据策略规则适用于该角色”筛选维度。每条策略须单独处理 `unrestrictedRoleCodes`；不能仅依据汇总 `allRoles`、`roleCodes` 或全局排除列表判断。未返回 `candidateFields` 或 `workflowBindings` 时按空列表处理。流程职责的范围维护不授予普通数据读写权限，也不改变已创建任务的参与人快照。
+
 ## 发现当前入口 {#context}
 
 ```bash
@@ -158,7 +164,7 @@ export function ReadableWorkflow({ workflowCode, version }: {
 
 开发者在审批节点的 `administration` 声明可维护的模式、人员来源和任务按钮。未声明这些项的节点保留名称、说明及原人员来源维护；拓扑、分支、范围计算仍由代码控制。使用新声明的应用需要平台 `workflow.node-administration@1.0.0`，编译与激活均检查该能力。
 
-模式为 `single/any/all/sequence` 的允许子集；可维护来源限 `fixed_users/app_role/app_role_in_scope`，范围角色必须已有代码声明的 scope。按钮 code 保持同意、拒绝、退回、转交、委托、加签的稳定语义；同意和拒绝不能关闭。只有同意/拒绝支持意见规则，拒绝或代码已有必填意见不能放宽。字段显隐、填写与必填行为由应用页面和代码维护，不提供流程节点的字段管理覆盖。可编译声明见 `examples/workflow-administration/declaration.ts`。
+模式为 `single/any/all/sequence` 的允许子集；可维护来源限 `fixed_users/app_role/app_role_in_scope`，范围角色必须已有代码声明的 scope。按钮 code 保持同意、拒绝、退回、转交、委托、加签的稳定语义；同意和拒绝不能关闭。只有同意/拒绝支持意见规则；拒绝默认必填，固定节点代码可用 operationPolicy.reject.commentRequired: false 显式选填。管理员可收紧选填规则，也可恢复代码明确允许的选填；不能放宽代码必填或未声明时的拒绝默认必填。已进入的任务保留冻结规则。字段显隐、填写与必填行为由应用页面和代码维护，不提供流程节点的字段管理覆盖。可编译声明见 `examples/workflow-administration/declaration.ts`。
 
 自动抄送节点仅开放名称、说明和显式声明的 `administration.assigneeProviders`；未开放时接收来源只读。共享编辑器显示“抄送人”，不显示审批方式或审批按钮，固定名单最多20人。`next`、空人策略和通知策略仍归代码；新配置只影响以后进入，过去抄送名单保持冻结。完整例子见 `examples/workflow-administration/automatic-cc.ts`，执行及读取边界见[自动抄送](workflow-events.md#automatic-cc)。
 

package/skills/openxiangda-v2/references/backend.md

@@ -46,10 +46,53 @@ SDK 继承当前环境与身份，平台沿用发起人或既有超级管理员
 `committed` 才有可信回执；`not_observed` 可能仍在提交，不能据此生成新键或宣称回滚。
 前端可用 `resolveBusinessProcessOriginal`（`openxiangda/react`），传原 workflowCode、
 operationCode、idempotencyKey；SDK 绑定当前环境并核验返回关联。Named Action 如果业务无需
-审批，没有流程回执并不代表业务没写入，应沿该动作自身回执诊断。
+审批，使用下面的 Native 数据命令恢复；没有流程回执并不代表业务没写入。
 标准 PC/移动发起页在响应未知时保留原操作定位信息，刷新可继续查询；同一页面、原身份和
 版本内可手动重试冻结的标准输入，绝不自动重发或悄悄换键。
 
+### 数据修改的原结果恢复 {#data-business-commands}
+
+仅修改业务资料的具名动作，在 `platformAccess` 声明
+`dataCommands: { mode: 'recoverable-native' }`，使用请求作用域的
+`OpenXiangdaBusinessDataApiService.commitCommand` 与 `resolveOriginalCommand`。
+编译器自动要求 `data.business-commands` 1.0.0；平台初始化默认提供，无额外开关。
+此声明不授予用户普通 UPDATE，也不替代应用的业务校验、同成员数据范围或附件输入授权。
+
+```ts
+// 固定动作代码从原请求组装；目标、原 revision、字段与原因共同构成稳定意图。
+const original = {
+  idempotencyKey: input.idempotencyKey,
+  intent: { id: input.id, expectedRevision: input.expectedRevision,
+    name: input.name, reason: input.reason },
+};
+const observed = await businessData.resolveOriginalCommand(original);
+if (observed.outcome === 'committed') return observed.receipt;
+
+// 这是用户明确提交或同键重试的动作处理器；只查询结果的接口在上面直接返回。
+// 在此读取合法字典/人员，并把业务规则转为原 Native guards，避免读写竞争。
+const committed = await businessData.commitCommand({
+  ...original,
+  data: { operations: [{ operation: 'update', resourceCode: 'requests',
+    id: input.id, expectedRevision: input.expectedRevision, data: { name: input.name } }] },
+});
+return committed.receipt;
+```
+
+响应丢失时保留原输入和原键，调用只读恢复。`not_observed` 仅表示本次未看到已提交回执，
+另一请求仍可能正在执行；SDK 不自动重放、更换键或提交。显式同键重试在事务锁内最多生效一次，
+相同键但不同意图返回 `OPENXIANGDA_DATA_COMMAND_IDEMPOTENCY_CONFLICT`。
+恢复发生在当前业务校验之前，因此原资料或字典后来变化不会遮蔽已成功结果。
+
+身份、应用、环境和动作来自原验证证明；普通用户直调、Worker、未声明动作与伪造请求拒绝。
+平台另外核对当前动作能力，失权后拒绝读取。用户、动作、能力或环境不同均不能复用原结果。
+同环境升级后可用当前同动作查询，回执保留原 `appVersionId`、`environmentHeadRevision`
+和事务条目；不会把原结果重写为当前版本。恢复不要求原资料仍然存在。
+
+意图只允许 JSON 对象，最多 64 KiB、32 层、10000 个值；不接受 undefined、循环对象或 Date。
+键最多 128 字符；数据仍沿 Native 1000 操作/2 MiB、CAS、guard 和文件规则。
+服务端只持久保存意图和公开键的摘要，复用原 Native 回执，不建立第二份状态表。
+结果仅返回可信应用后端，应用按已声明的 responseSchema 向用户投影。
+
 自定义表单页若先用 `createResourceFormDraftClient` 保存认证草稿，并由 Named Action
 提交业务记录和流程，则在同一次 `OpenXiangdaBusinessProcessService.commit` 中传入
 `formDraft: { resourceCode, id, expectedRevision, mode, recordId?, viewCode? }`。草稿必须
@@ -394,6 +437,19 @@ if (output.status === 'pending') {
 主子记录共享精确金额额度、撤回修订和审批释放，请使用[精确金额占用](decimal-reservations.md)的受管提交及终态事务。
 
 
+## 本人业务联系信息
+
+本人报名等确需联系电话的具名动作，显式声明
+`platformAccess: { directory: { mode: 'current-initiator', fields: ['displayName', 'primaryDepartment', 'phone'] } }`，
+然后调用 `businessDirectory.currentInitiator()`。平台从当前账号返回只读 `phone: string | null`，
+修剪空白且最多80字符；未设置时返回 null，由业务规则处理资料缺失。调用方不能指定人员 ID
+或信任浏览器提交的联系信息，关键提交仍须核对 `snapshotRevision`；电话变化会改变该修订。
+
+`phone` 只在该动作显式声明时查询和返回；默认 SubjectProfile、人员搜索和 `selected-user`
+不提供此投影。使用此字段需要平台能力 `directory.current-initiator-phone` 1.0.0，编译器从声明
+自动派生，不手写能力目录。受管 `backend-plan` 命令可在 execution.directory 中以相同方式
+声明本人电话；平台保留执行证明和有效 lease 边界。本能力不提供电话查人或联系方式修改。
+
 ## 解析管理员选定的组织人员
 
 管理员补录或身份订正应使用平台目录，不创建第二份人员主数据。具名动作声明
@@ -401,3 +457,18 @@ if (output.status === 'pending') {
 后，调用 `businessDirectory.selectedUser(userId)`。仅传标准人员选择器返回的确定 ID；姓名、工号和部门均由平台返回，不能相信表单传入快照。
 
 此动作的调用者还需要既有 `app:<appCode>:directory:read` 权限；平台复核当前租户、环境、目录范围和人员有效期，一次只解析一人。普通用户本人报名继续使用 `currentInitiator()`。身份快照不是永久授权凭据，后续业务事务仍需检查角色、状态与额度。平台能力为 `directory.selected-user` 1.0.0；失败时保留原操作，不回退姓名匹配或应用人员表。
+## 具名资料编辑的字段输入
+
+action-owned 资源需要跨字段业务校验时，可在具名动作声明
+`platformAccess: { dataCommands: { mode: 'recoverable-native' }, recordEdit: { resourceCode: 'requests', fieldCodes: ['name', 'reason'] } }`。
+只允许一个资源、最多200个已声明可更新的普通字段；系统字段、流水号和子表不适用。普通CRUD权限不会因此开放。
+声明自动要求 `data.record-edit` 1.0.0 平台能力；仅支持旧具名数据命令的平台需要先升级。
+
+Field Kit 的 `SurfaceFieldRenderers.recordEditInput` 接受 `{ operationCode, recordId, expectedRevision }`，
+字典与受限人员通过现有接口读取保存资料的范围，不能用浏览器bindings替代。
+上传继续使用 `uploadOperationManagedFile` 的update意图及同记录ID。
+平台验证同一成员同时拥有动作能力与资料read，再按原RLS读取；首次commitCommand仅接受同资源的一条update和声明字段，
+CAS与写后范围检查同事务执行。应用仍负责业务规则和字典guards。
+
+保存与核对共用同一operation，首次业务读取前先resolveOriginalCommand；not_observed只表示观察时未见回执，
+不自动重试或换键。管理员资料修改不会重写已完成意见、已走路径或已派审批人，后续任务按平台原Native修订协议处理。

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

@@ -32,9 +32,13 @@ pnpm openxiangda check
 
 需要“同一编号只能有一条有效主档”时，在模型声明 `uniqueKeys`。平台在环境
 激活时安装约束；普通 CRUD、导入和业务事务共用该约束。应用无需先查重再创建，
-也无需另建锁服务。声明会自动要求平台能力 `data.unique-keys@1.0.0`，旧平台在
+也无需另建锁服务。基础规则要求平台能力 `data.unique-keys@1.0.0`；单人键或布尔条件
+要求 `data.unique-keys@1.1.0`，两者由同一共享编译器确定。旧平台在
 发布前明确报告缺少能力。未声明的模型不增加这一要求。
 
+支持1.1.0的平台同时支持原1.0.0基础规则；工具预检只接受这项已知兼容关系，
+不会按版本大小推断其他版本或能力可用。要求1.1.0的应用不能在1.0.0平台部署。
+
 ```ts
 const partners = defineDataModel({
   code: 'partners', name: '往来单位',
@@ -59,12 +63,16 @@ const partners = defineDataModel({
 
 - 每模型最多 8 条，稳定 `code` 使用最长 20 字符的 lower-kebab-case；每条包含
   1–4 个不重复字段、最多 4 个 AND 条件。
-- 字段支持短文本、UUID、单选和单记录引用；单选/引用比较保存的 `value`，忽略标签。
+- 字段支持短文本、UUID、单选、单记录引用和单人；单选/引用/人员比较保存的 `value`，忽略标签。
 - `exact-v1` 原样比较（默认）；文本可用 `nfkc-space-v1` 做 NFKC 归一化、Unicode
   空白折叠和首尾修剪，或 `nfkc-upper-ascii-v1` 再将 ASCII 小写转大写。非文本只
   支持 exact；不按操作系统 locale 折叠其他文字大小写。
 - 文本条件是 `empty` / `nonempty`，按 NFKC 空白规则判断；单选条件是 `in` /
   `notIn`，包含 1–16 个已声明选项值。缺失选项不满足 `notIn`。
+- 布尔条件是 `eq` / `ne`，使用真实布尔 `value`，例如
+  `when: [{fieldCode:'enabled',operator:'eq',value:true}]`。两种比较均不包含 NULL。
+  用 `user.single` 唯一键配合 enabled eq:true，可维护同一平台用户唯一有效资料；
+  禁用历史记录可共存，改为有效、调整人员或并发创建都由同一数据库约束保护。
 - 任一键字段为空或归一化后为空，该行不参加比较。需要每行填写时仍应声明字段
   必填。参与比较的每个字段归一化后最多 256 个 UTF-8 字节。
 
@@ -175,3 +183,35 @@ publicSubtableFields: { items: ['sku', 'quantity'] },
 业务分派需要目标人员具有指定角色时，使用[事务中的角色条件](backend.md#role-member)，
 由平台在写入事务中核对当前有效成员。候选查询、页面隐藏、应用管理员身份和历史
 角色列表都不能替代这一规则，也不应在应用中复制一份权限状态。
+
+## 独立资料打印 {#record-print}
+
+模型可显式声明 `recordPrint: { read: ['app:my-app:record:print'] }`，能力须在本应用 `authz.capabilities` 定义并授给适当职责。`read: true` 绑定本资源读取能力，`false` 关闭，缺省不提供打印。平台自动提供 `data.record-print@1.0.0`，无需初始化SQL或全局开关；应用打印许可仍由声明拥有。
+
+### 单记录评论
+
+`recordComments: { read: ['app:my-app:comments:read'], create: ['app:my-app:comments:create'] }` 分别声明评论读取与新增，能力在本应用定义并授给职责。`true` 绑定本资源read，`false`关闭对应操作，省略整个声明关闭评论。每组最多20项、全部满足；同一个成员须同时拥有资料read及相应评论能力，不能把ALL-read职责和本人评论职责拼成ALL评论。平台自动注册 `data.record-comments@1.0.0`，fresh/update通过正式SQL迁移建表，不需手动开关。
+
+标准资料详情提供懒加载评论面板；应用定制页面使用 `ResourceRecordComments`、`loadNativeRecordComments`、`createNativeRecordComment`、`loadNativeRecordCommentReceipt`（`openxiangda/react`），沿平台Runtime和导航保护Provider。读取跟随当前Perspective，新增和本人回执由原始当前用户角色并集与相同Native范围决定；界面能力初筛不代替服务端许可。正文为纯文本，4000字上限；分页默认20/最多50，使用返回的nextCursor，单记录最多2000条。
+
+新增前固定 `schemaVersion: 'openxiangda.data-record-comment-create/v1'`、body及idempotencyKey。网络或超时结果不确定时保留原请求，先查本人原键回执；仅 `OPENXIANGDA_NATIVE_RECORD_COMMENTS_RECEIPT_NOT_FOUND` 表明可显式重试原请求，同一键/正文只写一条，改变正文或目标返回409。未解决前标准面板阻止页内导航；刷新/关闭浏览器会提示，当前尚无跨刷新自动保存，需保留原键与正文后通过SDK核对。读评论不获得他人的提交键。
+
+评论属于平台附属数据，不修改申请revision/最后修改人、不推进流程或发业务updated事件，不授给匿名/应用联合主体。当前不含回复、附件、提及、编辑/删除、自动通知和旧评论导入；审批意见继续由Workflow拥有。源宜搭这些附加语义尚未运行核实，不能据COMMENT=y宣称完整等价。
+
+### 按资料权限删除关联流程
+
+模型或直接资源可显式声明 `recordDeletion: { delete: ['app:my-app:record:delete'] }`，引用能力须在同应用定义并授给维护职责。`true` 使用本资源 Native delete，`false` 或缺省关闭。每组最多20项，全部满足；编译器自动派生 `data.workflow-record-deletion@1.0.0`，平台自动注册，不需要初始化开关。标准详情在启用且当前用户具备资料 read、delete 和维护能力时提供“删除资料”，action/workflow拥有普通写入的模型也可单独启用资料维护。
+
+服务端在预览、执行和回执恢复时重新检查当前用户。必须由同一个成员同时持有资源 read/delete 及全部维护能力，再沿该成员原 RLS；不能把全部资料读取职责与本人删除职责拼成全部删除。应用管理员称谓不自动授权，匿名、应用后台断言及工作流任务断言不能调用此浏览器入口。维护能力不授予编辑资料、改派任务或整套流程管理员权限。Perspective 不改变写权限，维护沿当前用户原角色并集。
+
+先填写非空原因（trim后最多1000字符），再预览，确认使用原预览Token和幂等键。无关联实例时复用 Native 事务；一个根关联实例时复用 Workflow Kernel 的 `admin_delete`，同事务删除资料及 owned 明细、关闭任务/参与人/返回会话并记录审计。共享 resource-ref 不级联。待启动命令、多个实例或明细关联其他实例会阻止全部删除；最多根记录加400条后代（合计401条）、深度8，超限明确拒绝。嵌套后代共用总预算，不能按每层累乘；末行关联与revision也参与核对。关联流程仍最多100条，读取101条拒绝。普通 Native 删除的流程关联保护保持，不能用它绕开维护协议。
+
+同一受控请求只选择一条根记录，SDK输入不随容量扩大改变。管理员公开批量请求仍最多100个所选根或普通操作；只有服务器核对并展开的内部DELETE集合可用401条总上限，多个根也共用总量。整管理员请求1MiB、Native事务1000操作/2MiB与原Kernel预算保持。七张各50行的子表属于这个预算；声明和当前资料授权仍须逐项验证，没有新的初始化开关。
+
+预览有效五分钟，绑定当前账号/登录会话/CSRF、环境Head、根revision及全部owned摘要。变化或到期须重新预览。未知结果先读取原回执，只有 `OPENXIANGDA_NATIVE_RECORD_DELETION_RECEIPT_NOT_FOUND` 且预览有效时可显式原键重试，不能创建新键。回执恢复允许预览到期，但仍检查当前权限、原账号/会话/CSRF和同一Head，成功后不重读已删除资料。两类回执的 `receiptOwner` 分别为 `native-transaction` 和 `workflow-command`。
+
+SDK复用现有应用CSRF与512条命令绑定缓存，预览到期不会自动丢弃原header。身份退出、缓存容量淘汰或刷新后不保证恢复原CSRF；标准弹层不跨刷新自动保存原请求。页内导航和关闭保护保留未确认操作，无法确认的请求不得用重新预览掩盖。删除不可由代码回滚恢复；应用须按自身保留和归档要求决定是否开启。
+
+打印先筛选同一成员同时具备资料read及所有打印能力的资格，再沿原RLS、Perspective、字段读取与脱敏；不能把ALL-read职责和own-print职责合并成ALL-print。普通app-admin与平台超管分别验收。SDK `loadNativeRecordPrint(resourceCode, recordId, { viewCode? })` 只读当前单记录投影；公开 `ResourceRecordPrintPreview` 与生成Native详情中的“打印”入口共用它。字段权限仍使用页面/模型规则，不增加流程节点字段权限配置。
+
+预览显示读取时间、当前详情可见字段和分组。打印前重新读取当前授权数据，失败清除旧预览，身份/授权/Perspective变化和关闭淘汰过期请求。附件/图片只列名称及大小、富文本转安全文本，没有自动外部下载；系统打印取消不写业务资料。当前版本只支持主记录，详情包含可读子表返回409，超2MiB返回413，不静默漏项；专用PDF模板、签章与子表完整打印另行提供。独立权限保护平台的打印接口和标准入口，已读资料的截图/浏览器自行打印不属于可撤销许可。

package/skills/openxiangda-v2/references/declarations-cheatsheet.md

@@ -1,5 +1,7 @@
 # 声明速查：一次写对 openxiangda.config.ts {#cheatsheet}
 
+资料维护删除用模型或直接资源的 `recordDeletion: { delete: true | false | string[] }`。缺省关闭；`true`绑定本资源Native delete；能力数组最多20项并须在同应用定义。平台自动注册 `data.workflow-record-deletion@1.0.0`，无需手动初始化开关。维护职责还必须同时持有资料read/delete，同一成员与RLS决定实际可删范围；不使用整套流程管理员替代业务资料权。仅支持零关联实例或一个根关联实例，待启动、多实例、明细其他流程及owned超100/深度8均阻塞。详见[数据与权限](data-authz.md)。
+
 按"错误码 → 规则 → 正确片段"组织。这些规则全部来自真实返工：先扫一遍本页，再写声明，能省掉绝大多数首轮校验迭代。普通 CRUD 的完整可过检骨架见文末。
 
 ## 模块与 CRUD 视图
@@ -212,3 +214,10 @@ export default defineOpenXiangdaApp({
 ## 图片上传的像素上限
 
 image/signature/富文本图片字段在上传计划（initiate）里返回 `maxPixels`；超过上限的图片会被标准组件自动压缩后重新发起上传。用 API 直传时自行按 `maxPixels` 预检。当前平台上限覆盖主流手机主摄（48/50/64MP）；超出会得到带实际尺寸的 `OPENXIANGDA_NATIVE_DATA_IMAGE_PIXEL_LIMIT_EXCEEDED` 错误。
+
+## 业务查看组的流程办理历史
+
+在模型或直接资源声明中设置 `workflowHistory: { read: true | false | string[] }`。
+省略/false关闭新入口；true绑定资源read，数组引用已有能力，不隐式生成能力。
+同一角色成员须同时满足资源read和全部历史能力，原行权限继续约束旧固定实例；该项独立于Native `audit.read`。
+标准Native详情和公开 `WorkflowRecordHistoryPanel` 可复用，参见[工作流历史](workflow-events.md#record-history-read)。

package/skills/openxiangda-v2/references/field-components.md

@@ -68,6 +68,8 @@ import { AttachmentFileList } from 'openxiangda/field-kit';
 
 组件按文件引用选择缩略图，预览和下载经过平台接口。自定义活动封面同样先选择 `cover.thumbnailUrl`；只有平台引用没有缩略图时才回退 `cover.previewUrl`。不要写 `previewUrl || thumbnailUrl`，否则小卡片也会下载完整原图。保留真实宽高或稳定的封面比例，非首屏图片使用懒加载；不得在列表渲染时预取所有原图。
 
+视频或音频需要在原任务界面播放时，使用 `ManagedMediaPlayer`，例如 `<ManagedMediaPlayer file={record.media[0]} resourceCode="lessons" />`。组件先核对官方预览元信息，再鉴权读取内容；当前身份、文件或绑定变化以及卸载会释放播放器与 ObjectURL，不接受任意 `src`。默认单文件容量100MiB，可由应用按实际任务显式配置 `maxSizeMb`，超限明确失败并保留附件下载任务。提供加载、拒绝和重新读取状态，浏览器编码支持须实际播放验证。播放本身不提交业务进度或观看时长。
+
 受限文件的缓存必须保留权限核验。配套平台支持私有条件缓存时，浏览器可以保存文件响应，再次访问由平台先核对当前权限，内容未变化返回 304，从本地复用字节；`no-cache` 表示复用前校验，和 `no-store` 禁止保存不同。缺少可靠实体标识或请求失败时仍禁止缓存。不应由应用添加长期免校验缓存、公开 CDN 缓存或跨账号 Blob 缓存来绕过该规则。公开长期缓存需要独立、明确的公开发布契约，不能仅因字段名叫封面就视为公开。
 
 验收时同时记录原图/缩略图字节、列表实际请求的变体、重复访问传输量和权限撤销结果。仅看到 `blob:` 地址不能判断用了 Base64，HTTP 200 也不能证明命中了缓存。
@@ -140,6 +142,48 @@ import { AttachmentFileList } from 'openxiangda/field-kit';
 成员快照可包含头像、工号、职务、手机号、邮箱和所属部门；部门快照可包含完整路径、
 路径节点和父部门。凭证、Token 和认证秘密永远不能进入快照。
 
+### 限定职责候选（合同已定义，运行时接入中）
+
+`user.single` / `user.multiple` 可在代码中声明 `userCandidates`，引用本应用职责和可选范围。
+它与资源选择的显示 `source` 分开，编译产物中的字段和 Surface 必须一致。
+使用前确认平台已开放 `data.user-candidates@1.0.0`。SDK已接入候选读取和双端字段组件，
+平台运行时仍在本地集成验收；未广告能力时不能部署该声明。不能以普通通讯录过滤替代服务端约束。
+
+```ts
+{
+  code: 'unitLeaders', type: 'user.multiple', label: '单位负责人',
+  userCandidates: {
+    kind: 'app-role', roleCode: 'unit-leader', pageSize: 20,
+    scope: { dimensionCode: 'college', operation: 'approve', field: 'college' },
+  },
+}
+```
+
+职责和范围维度必须在同包声明。`pageSize` 为1–50，默认20；范围使用代码常量 `value`，
+或同资源的 `text.short`、`uuid`、`option.single` 字段 `field`，两者互斥。
+单选范围取稳定的 `.value`，不按显示标签决定身份。记录范围必须来自已授权、已保存的记录或当前任务，
+首版新建不接受非空的记录范围选人。修改范围须清空相依选择并保存，再按新范围重选。
+候选显示失败不能当作空名单；旧选择失效须保留显示快照并提示重选。
+
+流程使用 `{ provider: 'form_field_users', inputPath: 'leaders', candidateField: 'unitLeaders' }`，
+其中 `subject.factProjection.leaders` 必须精确指向 `unitLeaders`，范围字段也须有唯一事实投影。
+不能另写职责、范围或路由覆盖来源，不能用嵌套输入路径绕过候选字段。
+办理页不能同时修改范围字段与相依选人字段。首版任务候选只支持主体字段，任务中可写子表候选字段明确拒绝；
+普通子表记录的 Native 约束和历史只读显示仍按各自合同处理。
+流程进入节点时再次核验原职责成员，随后解释职责代理；历史已创建任务保留当时快照。
+
+标准表单、流程发起和任务补填自动传递候选上下文。自定义页使用Field Kit的
+`SurfaceFieldControl`/`MobileSurfaceFieldControl`，更新时提供`recordId`和`expectedRevision`；
+任务页额外提供`workflowCandidateBinding: { taskId, expectedTaskVersion }`。缺失任务版本会要求刷新，
+不会转用普通数据或通讯录接口。使用`ResourceFormContent`时也提供已加载记录的`expectedRevision`。
+
+自定义选人交互可从`openxiangda/react`调用`queryFieldUserCandidates(resourceCode, fieldCode, input)`
+或`queryWorkflowTaskUserCandidates(taskId, fieldCode, input)`。查询schema固定为
+`openxiangda.user-candidates-query/v2`，支持keyword/cursor/selectedIds；Native更新绑定recordId/expectedRevision，
+任务绑定expectedRevision/expectedTaskVersion。不要传入职责或学院覆盖参数。返回`UserCandidatePage`只包含
+稳定ID、名称、已选项valid/invalid及下一页游标；invalid不返回无权读取的名称，页面保留原显示快照。
+确认前复核选择只能改善交互，不能替代保存及节点进入时的服务器核验。
+
 仅选择时间时使用 `time`，并显式决定精度：
 
 ```ts
@@ -245,7 +289,7 @@ ISO instant）与 `minuteStep`（1 到 60 且整除 60）。设置步长后只
 - 单选、复选直接展示选项；下拉单选／复选使用可搜索的底部弹层，多选展示已选数量。
 - 日期使用月历，日期时间可切换时间滚轮；区间依次选择开始和结束，可返回上一步修改。
 - 地址采用地区路径逐层选择，详细地址单独输入。定位沿用当前可用的钉钉或浏览器能力。
-- 子表单直接展开行内字段，支持折叠、添加和删除；父表提交校验所有行，包括折叠的行。
+- 子表单使用每页十行的行内字段，手机支持折叠、添加和删除；父表提交校验所有行，包括折叠及未显示页的行。分页保留完整输入和草稿，任务完成校验会定位到错误行所在页；有待处理上传时先完成或移除文件，再翻页。
   权限、最大行数、原子事务和已存行的 revision 继续由原有资源契约约束。
 - 签名在底部画布手写并保存；图片、签名和附件仍通过托管文件接口上传与鉴权读取。
 - 手机富文本编辑降级为多行文本。未修改时保留已有 HTML；修改后将纯文本转为转义后的

package/skills/openxiangda-v2/references/frontend.md

@@ -1,5 +1,13 @@
 # 前端架构
 
+## 资料维护删除
+
+模型的 `recordDeletion.delete` 显式开启后，标准 `GeneratedResourcePage` 详情提供“删除资料”。普通资料编辑仍按原 `mutationOwner` 和生成页许可决定。删除面复用平台导航 guard，原因输入、显式影响预览、确认、到期、明确拒绝、未知结果和成功分别呈现，PC与手机使用同一响应式弹层。
+
+自定义详情可嵌入 `ResourceRecordDeletion`（`resourceCode`、`recordId`、`onClose`、`onDeleted`），服务端始终重验资料权限。独立接入使用 `createNativeResourceClient(resourceCode, surface)` 的 `previewDeletion(id)`、`deleteWithPreview(id, input)`、`deletionReceipt(id, input)`；也可从 `openxiangda/react` 导入 `previewNativeRecordDeletion`、`deleteNativeRecordWithPreview`、`recoverNativeRecordDeletion` 及对应 `DataRecordDeletion*` 类型。
+
+写入input包含 `schemaVersion: 'openxiangda.data-record-deletion-request/v1'`、原 `previewToken`、固定 `idempotencyKey` 与 `reason`。提交前固定完整请求，未知时先查原回执；专用回执不存在且预览未过期才可让用户明确重试原请求。预览有效五分钟，回执可在到期后恢复；SDK保留原CSRF的有界缓存不等于跨刷新保存。标准组件不跨刷新保存Token/原因/键，身份退出、Head变化或缓存淘汰后的旧请求恢复限制须向应用维护者说明。详情与历史不从删除成功回执回填已删除旧值。授权、级联预算和错误边界见[数据与权限](data-authz.md)。
+
 状态：Vite/Refine 已成为 OpenXiangda 2.0 唯一默认前端栈。决策与实测见
 [核心架构](concepts.md)。
 

package/skills/openxiangda-v2/references/getting-started.md

@@ -68,10 +68,10 @@ MCP 服务随项目根包一起安装，AI 客户端的 stdio 连接仍需配置
 以下命令的版本占位符由随包资料替换为该根包的精确版本。网站源码阅读者应先确认要使用的发行版本。
 
 ```bash
-pnpm dlx openxiangda@2.44.0 skill install --force
-pnpm dlx openxiangda@2.44.0 auth status --base-url <平台地址> --json
-pnpm dlx openxiangda@2.44.0 login --cwd my-app --base-url https://platform.example.com
-pnpm dlx openxiangda@2.44.0 create my-app --base-url https://platform.example.com
+pnpm dlx openxiangda@2.55.1 skill install --force
+pnpm dlx openxiangda@2.55.1 auth status --base-url <平台地址> --json
+pnpm dlx openxiangda@2.55.1 login --cwd my-app --base-url https://platform.example.com
+pnpm dlx openxiangda@2.55.1 create my-app --base-url https://platform.example.com
 cd my-app
 pnpm openxiangda context --json
 pnpm openxiangda dev
@@ -174,9 +174,9 @@ MCP 的 `docs_read` 可以读取本说明，当前没有独立的源码操作 MC
 无需本地工作区，使用本 Skill 随包精确版本或已安装的对应 CLI：
 
 ```bash
-pnpm dlx openxiangda@2.44.0 auth status --base-url <平台> --json
-pnpm dlx openxiangda@2.44.0 source resolve <仓库URL> --base-url <平台> --json
-pnpm dlx openxiangda@2.44.0 source clone <仓库URL> <新目录> --base-url <平台> --json
+pnpm dlx openxiangda@2.55.1 auth status --base-url <平台> --json
+pnpm dlx openxiangda@2.55.1 source resolve <仓库URL> --base-url <平台> --json
+pnpm dlx openxiangda@2.55.1 source clone <仓库URL> <新目录> --base-url <平台> --json
 ```
 
 登录缺失或站点不匹配时，先按该平台执行 login。resolve 根据平台已经登记的绑定返回

package/skills/openxiangda-v2/references/managed-concurrency-frontend.md

@@ -236,7 +236,7 @@ hook 从 `openxiangda/react` 和 `openxiangda/mobile` 导出。state、initializ
 
 已受理申请的自动观察最多持续到首次明确提交后的 30 分钟，默认受理恢复仍为 120 秒，两者分别计算。自动观察的每次结果读取同时受单次 120 秒和原提交剩余时间限制；刷新和 resume 不重新获得观察时间。跨设备没有本地首次时间时，用原回执 acceptedAt 计算观察窗口，不能以页面挂载时间重新计时。达到窗口后保留原意图，状态为 recovering、isObserving 为 false，提示稍后核对；明确 refresh 仍可用有界初查预算查询迟到终态，但不重新启动已经到期的自动观察，也不自动提交。
 
-正常待处理结果每次至少间隔 5 秒，遵守更长的服务端 retryAfterMs，再加随机抖动。单次只读恢复耗尽且仍是已知预算繁忙时，外层可在原观察窗口内指数退避继续；权限、依赖、网络故障或悬挂请求超过读取预算时立即停止自动观察，显示 error 并保留原回执和请求键。终态停止。受理恢复中核对原结果同样只允许已知预算繁忙继续，读取依赖失败不能被外层重试隐藏。一个业务区域只挂载一个观察者。离开或关闭页面不撤销已受理请求，平台自动继续；新设备通过 mine 找到本人的原请求。position 为空时显示「已受理，稍后可查看」，不要显示虚假的精确人数或预计秒数。
+正常待处理结果每次至少间隔 5 秒，遵守更长的服务端 retryAfterMs，再加随机抖动。单次只读恢复耗尽且仍是已知预算繁忙时，外层可在原观察窗口内指数退避继续。SDK 自身明确标记为 status=504、retryable=true 的 CONCURRENCY_READ_RECOVERY_EXHAUSTED 也只在已受理原结果观察中按退避恢复；它不代表服务端忙，不延长原三十分钟截止，也不触发再次提交。权限、依赖、普通网络错误、其他 504 或未标记可恢复的错误立即停止自动观察，显示 error 并保留原回执和请求键。终态停止。受理恢复中核对原结果同样只允许已知预算繁忙继续，读取依赖失败不能被外层重试隐藏。一个业务区域只挂载一个观察者。离开或关闭页面不撤销已受理请求，平台自动继续；新设备通过 mine 找到本人的原请求。position 为空时显示「已受理，稍后可查看」，不要显示虚假的精确人数或预计秒数。
 
 refresh 有本地原键时先薄查询原 key；找到已受理非终态后不再 mine。没有本地意图或原申请已有终态时，mine 优先恢复新的进行中周期，避免本地历史 succeeded 遮蔽另一个设备的新申请。原键明确 404 后保留一次本人列表兜底；未确认的本地意图只能采用同原键回执。列表中只有别的活跃周期时显示 recovering / CONCURRENCY_ORIGINAL_REQUEST_REQUIRED，并保留原 key/input；没有匹配时显示 CONCURRENCY_ACCEPTANCE_UNCONFIRMED，提供「核对原申请」和「恢复原申请」动作。不能把无匹配解释为业务失败，也不丢弃可能迟到受理的原意图。已知读取繁忙耗尽显示 recovering，真实依赖、网络、权限或未知 400 显示 error；两种状态均保留原键、输入和已受理回执，读取失败不自动提交。
 

package/skills/openxiangda-v2/references/testing.md

@@ -36,6 +36,23 @@ Web 默认保留开发服务回环访问检查。按需 Nest 使用 `tsx --test`
 
 只改文案时验证受影响页面。复杂事务、并发和值转换使用聚焦测试。浏览器验收实际操作并检查错误，不能用模拟响应或空页面加载代替真实角色验收。
 
+应用后端生成 Native 事务或 BusinessProcess 数据守卫时，业务测试通过统一根包的公开测试入口校验真实生成的请求，不复制验证规则或额外依赖底层包：
+
+```ts
+import { SCHEMA_VERSIONS, validateDataTransactionRequest } from 'openxiangda/testing';
+
+const diagnostics = validateDataTransactionRequest({
+  schemaVersion: SCHEMA_VERSIONS.dataTransactionRequest,
+  idempotencyKey: submission.idempotencyKey,
+  guards: submission.data.guards,
+  operations: submission.data.operations.map(item => ({
+    operation: item.kind, resourceCode: item.resourceCode, data: item.data,
+  })),
+});
+```
+
+合法请求返回空诊断数组；守卫失败码必须使用 `OPENXIANGDA_*`。纯合同校验不证明数据库锁、权限、实际执行或失败恢复通过，这些仍需要对应角色和原操作的运行验收。
+
 匿名访问另验证续填、上传、校验、幂等提交、own.list/own.read；另一浏览器应无法获取前一浏览器的记录。工作流按已启用功能检查发起、处理、历史详情和消息跳转，不为未启用通道增加测试负担。
 
 ## 可选临时身份 {#temporary-identities}