openxiangda-skill-kit 2.3.52 → 2.3.81

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "openxiangda-skill-kit",
-  "version": "2.3.52",
+  "version": "2.3.81",
   "description": "OpenXiangda 2.0 中文 AI 技能的校验、分发与安装。",
   "type": "module",
   "main": "./dist/index.js",
@@ -17,7 +17,7 @@
     "README.md"
   ],
   "dependencies": {
-    "openxiangda-devkit-core": "2.41.2"
+    "openxiangda-devkit-core": "2.48.2"
   },
   "devDependencies": {
     "tsx": "4.23.12",

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/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}

package/skills/openxiangda-v2/references/workflow-events.md

@@ -254,14 +254,18 @@ fields: [{ code: 'startsAt', label: '开始时间', type: 'datetime', required:
 所声明精确 capability 的用户；capability 必须在同一应用显式声明，不支持
 通配符。该授权同时允许读取对应流程实例的详情及时间线，包括完成后查阅；
 不授予审批、抄送、改派、删除、普通数据读取或管理后台权限。撤销 capability
-后读取和终止权限都失效。撤回、终止均要求填写原因；超级管理员也遵守已声明时限。
+后读取和终止权限都失效。撤回默认要求填写原因；固定定义显式声明
+`instanceCommands: { withdraw: { reasonRequired: false } }` 时允许省略、空串或空白，
+仍拒绝已提供的非字符串及超过4000字符。该选项自动要求
+`workflow.optional-withdrawal-reason@1.0.0`，旧平台不能激活。`beforeFact` 可独立
+声明或与选填组合，空策略无效。终止仍必填原因；超级管理员也遵守已声明时限。
 
 不声明 `instanceCommands` 时沿用既有行为；只为终止授权时可以省略其
 `beforeFact`。声明策略的交付包自动要求平台能力
 `workflow.instance-cancellation-policy`，旧平台无法激活该应用版本。
 已经固定该策略的实例存在期间，平台回滚也必须保留策略执行能力。
 发布新 definition 不会改写旧实例固定的 definition 版本，因此不会给旧实例
-补上截止时间或业务管理员终止授权。升级前应盘点存量实例，按各自原定义完成
+补上截止时间、选填原因或业务管理员终止授权。升级前应盘点存量实例，按各自原定义完成
 或由原有授权主体处置；不要通过重发事件或改写事实迁移策略。已使用新策略的
 实例在截止后及终态仍允许当前被授权的业务管理员查阅，撤销其 capability
 也会撤销这些存量实例的详情读取权限。
@@ -404,6 +408,38 @@ processCommand 路径和 allowlisted context 预填。标准页调用原 Named A
 `ProcessCommandSurface`；`awaiting_input` 只回答已生成 requirement，`started` 再进入 pinned
 instance entry。浏览器不再导出 prepare/start 发起协议。
 
+### 标准提交页的业务表单扩展
+
+应用读取获授权的业务资料后，可将 canonical 预填值和同步字段规则传给公开
+`WorkflowSubmissionPage` 的 `formOptions`。PC和手机复用同一个组件及Field Kit；
+上传、具名动作、幂等操作和未知结果恢复继续由标准页处理，应用不要复制提交生命周期。
+
+```tsx
+import { WorkflowSubmissionPage, type WorkflowSubmissionFormOptions } from 'openxiangda/react';
+
+const formOptions: WorkflowSubmissionFormOptions = {
+  initialValues: { phone: profile.phone, className: profile.className },
+  fieldState: values => {
+    const medical = (values.reason as { value?: string } | undefined)?.value === 'illness';
+    return {
+      recoveryEvidence: { visible: medical, required: medical, hiddenValue: [] },
+      medicalReviewer: { visible: medical, required: medical, hiddenValue: null },
+    };
+  },
+  intro: <p>请核对预填资料；因病申请需要康复证明。</p>,
+};
+return <WorkflowSubmissionPage workflowCode="reinstatement" variant="mobile" formOptions={formOptions} />;
+```
+
+初值仅在当前匹配的发起合同内应用到未触碰字段，每字段一次；后到资料和父组件重新渲染
+不会覆盖已填写或手动清空的内容。日期和范围使用canonical值，标准页通过原codec转换。
+`fieldState`读取canonical值，`required`只能增加校验，不能撤销原必填或隐藏原必填字段；
+可选字段隐藏时清为`hiddenValue`或undefined，提交也使用同一投影，不发送旧材料/人员。
+初值或规则引用范围外字段会阻断表单。`intro`只提供页面说明，不拥有身份、授权或提交。
+资料加载/失败或业务资格提示可传`preparation`内容，它仅阻断尚未提交的表单；原请求查询
+及已接受命令的展示优先于该提示。应用应始终挂载标准页，避免当前资格变化遮蔽原结果恢复。
+这些规则属于应用代码，不能通过管理员节点配置修改；服务器仍独立校验实际业务资格与字段。
+
 通用应用待办页通过 `frontend.user.applicationTodoCenter: true` 启用，平台同时提供
 `/todos` 和 `/m/todos`。它只投影当前登录用户的 Notification Hub 收件人数据，
 `查看详情` 使用上述统一导航解析；待办页不常驻业务详情，审批命令仍在目标 Workflow
@@ -443,6 +479,10 @@ readability: {
 
 说明的执行位置只能是 submission、某节点的 node_input 或 completion。它是对已有逻辑的注释，不会自动执行计算或产生新流程节点。没有实际计算步骤时，不应写成“系统已计算总金额”。条件的变量必须存在于输入 Schema；对旧未标注定义，读取投影会明确给出未知来源诊断。
 
+流程图的条件卡直接摘要参与判断的变量与分支数，业务步骤卡摘要声明的产出。管理详情在条件旁显示申请字段、流程输入或固定步骤来源；业务步骤优先展示输出说明，缺少说明时明确提示。来源节点只有与当前图的 handler 代码和版本一致才可跳转，历史实例使用自己的固定定义。界面不根据节点标题推断公式，也不加载或执行源码引用。
+
+长图首次打开会保留可读比例；可用“适应全图”查看全貌，再通过搜索、来源链接、缩略导航或方向键定位。手机使用同一结构的节点列表和详情。图的连线、条件和代码始终只读，审批/抄送配置沿已声明的管理员能力修改，字段行为仍由页面代码定义。
+
 可选 `source: { path, symbol?, digest }` 只返回源码位置和 SHA256，不返回源码内容。path 指向工作区 apps/packages/platform 下的代码文件，digest 为 `sha256:<原始文件字节摘要>`。工作区加载时核对文件存在、无符号链接、大小和摘要；源码变化后以 WORKFLOW_LOGIC_DESCRIPTION_STALE 阻止封装，开发者应核实说明并更新引用。32 个文件、单文件 2MiB、总量 8MiB 为上限。元数据不能验证任意 TypeScript 的业务含义，业务说明及验收仍由开发者维护。
 
 ## 持久业务步骤
@@ -513,9 +553,74 @@ outbox容量等事务故障会回滚，处理器按原键核对后重交，不
 `examples/workflow-administration/task-page.ts`。
 
 页面表达式只读取本页 `values.*`，平台以合并后的业务值强制显隐和必填。
-最多16页、每页64字段、单次值64KiB，表达式8层/64节点。
+最多16页、每页64字段、单次值1MiB，表达式8层/64节点。
 系统、流水号和隐藏字段不可作为补填入口。根附件、图片复用平台托管文件；
-签名、子表和富文本仍需后续任务页面支持，不将它们降为任意 JSON。
+签名和富文本同样保留 Native 字段协议；普通 owned 子行以固定页面白名单和行 CAS 提交。
+
+### 标准流程的主子表发起
+
+标准发起页复用 Field Kit 的 PC/手机子表，通过原 `standard-commands` 的
+`mutation.data` 一次提交完整表单。子表字段值沿用表单行结构：
+`{ key, state, data, id?, revision? }`；日期等子字段按字段 codec 编码，
+界面快照与原值不作为授权或并发依据。声明关系、行序和父记录引用由 Native 生成。
+创建主表、所有子行和持久流程发起命令在同一个事务中完成；失败不留下部分申请。
+
+发起仍执行当前用户的父、子资源及字段授权。拥有主表权限不会自动得到通用子表权限。
+已有记录提交核对父 CAS 和完整已读子行集合，包括未修改行；删除显式保留原 id/revision，
+跨单、遗漏、重复或陈旧行均拒绝。原命令已提交时先返回同一回执，再也不重新展开当前行。
+每表100/累计400、完整意图双倍、整请求2MiB及展开后1000操作与 Native 预算一致。
+普通显式 Named Action 的16个业务操作预算不变；其自定义子表提交仍按自身合同实现。
+
+### 任务 owned 子表
+
+在主模型的 subtable 字段上声明 `subtable: { fields, create, delete, reorder }`，例如：
+
+```ts
+{ code: 'items', required: true, subtable: {
+  create: true, delete: true, reorder: true,
+  fields: [{ code: 'name', required: true }, { code: 'quantity', required: true },
+    { code: 'originalNote', readonly: true }],
+} }
+```
+
+关系沿用模型的 `resourceCode/foreignKey/orderField/maxRows`，不接受任务调用者自报。
+子字段可声明同样的只读、可见和条件必填规则；这些属于页面代码，管理员不能覆盖。
+`create/delete/reorder` 省略时关闭。仅一层，每表 maxRows 最多100，父资源及任务页
+声明总量最多400；默认仍20。完整意图最多为每表 maxRows 的两倍，可在一次提交中
+删除满表旧行并新增同等数量，仍按有效行数校验上限。整个 form/任务私有草稿值限1MiB，
+页面定义仍64KiB/64根字段；系统、隐藏、关系键和顺序字段不进入子字段白名单。
+标准主子表提交复用同一个 Native 原子事务，最多1000操作/2MiB（400行全量替换加主表为801操作），
+任一行失败全单回滚，不静默截断或分批提交。普通表单草稿values最多2MiB，含原值与当前值；
+状态字段的独立配额不变。附件上传数量/字节与详情读取预算仍独立执行，行数容量不豁免文件配额。
+子行支持 file/image/signature/text.rich，使用同一个任务上传入口并绑定准确行；普通
+子行字段和已授权只读展示不降为 JSON 编辑框。例子见 `examples/workflow-administration/task-owned-subtable.ts`。
+
+标准 PC/手机控件自动消费 `surface.taskForm.subtables`，不会调用普通 child CRUD。
+自定义客户端提交 `values.items` 的完整行意图数组：
+`{key,state,values,id?,revision?}`；state为created/persisted/deleted，key为小写UUID，
+持久行key等于id。删除显式列出原id/revision与空values，遗漏不代表删除。
+所有观察到的行版本都核对，包括未修改行；新行key作为其业务行ID。
+values只能写白名单的当前可编辑字段，关系键与顺序由服务器维护。
+
+原save_form/approve/resubmit同时提交主子数据、事实与决定，失败全部回滚。
+子表提交推进主版本；普通child操作仍各自拥有行版本，不能仅用主版本判断子表并发。
+私有草稿保存相同行意图，不改业务。CAS拒绝保留输入，核对后明确保留编辑或采用最新资料；
+正在编辑的行被别人删除时不会静默丢弃或复活。未知命令沿原请求/原回执恢复。
+能力 `workflow.task-owned-subtables@1.0.0` 从声明自动推导，正式 SQL
+`AuthorizeWorkflowTaskOwnedSubtablesV2` 随初始化迁移自动生效，无新增默认关闭开关。
+
+子行上传时在原 `WorkflowTaskFileUpload` 上增加
+`row: { subtableFieldCode: 'items', rowKey }`，`fieldCode` 是该行中的材料字段。
+rowKey 是新建或已持久化行的稳定小写 UUID；新行上传不会提前写入业务记录，排序也不会
+改变文件归属。不能自行指定子资源或父记录，也不能把任务私有文件交给普通 child CRUD。
+草稿递归保留有效行文件，删除意图不保留文件；原流程命令统一提交数据、引用和草稿消费。
+
+条件文件的上传资格依据已保存业务值。若本地编辑才使字段可见，标准页面提示先保存补填，
+再上传；私有草稿不会改变已经生效的业务事实。无条件材料可直接在尚未保存的新行上传。
+上传未知时保留原行地址、ID、规格和字节，核对 ready 回执只读恢复，不再 PUT；处理中
+禁用行修改、删除、排序和提交。标准 PC/手机控件自动处理四类值和准确行恢复。
+声明可写子行材料自动要求 `workflow.task-owned-files@1.0.0` 及适用的 managed/rich 能力；
+平台正式迁移 `AddWorkflowTaskOwnedFilesV2` 自动扩展绑定列，无需另开功能开关。
 
 标准 PC/手机任务页和 `WorkflowTaskOperationsPanel` 自动显示当前参与人的
 `surface.taskForm`。`save_form` 表示“提交补填，继续办理”，不是私有草稿。
@@ -538,6 +643,12 @@ approve/resubmit 携带 `form: { expectedRevision, values }` 时，Native 业务
 多人补填与管理纠错使用 Native 记录 CAS，冲突保留输入。首次请求的明确拒绝会只读刷新，
 修订变化时对照最新已保存值和本人输入，核对前锁住字段与操作；可选择保留输入或采用最新值。
 拒绝后的读取失败明确提示本次未提交，锁住旧操作，恢复读取后再核对；未知结果仍只能恢复原请求。
+操作确认表单使用同一 Surface 的必填、字符数与非空白规则校验意见和原因。
+拒绝意见默认必填。固定节点显式设置 `operationPolicy.reject.commentRequired: false` 时允许省略或空意见，目标须具备 `workflow.optional-rejection-comment@1.0.0`；已进入任务使用冻结规则，后续配置不追溯。选填仍限制为最多4000字符的字符串，不写入假意见。
+`commentRequired` 只配置同意/拒绝的 `comment`；转交、委托、加签、退回与管理员改派
+继续使用原合同的必填 `reason`，不用再填写第二份意见。
+明确拒绝后，实例、任务版本及操作签名仍一致且操作仍可用时，对话框保留输入供人工核对；
+任务、权限、字段规则或版本变化时不能沿用旧操作。刷新和保留输入都不会自动重发请求。
 补填刷新固定事实投影；
 修改已计算步骤的输入时清除当前失效输出及依赖输出。仅退回 replay 且所有前向
 审批路径确定重经生产者时允许；resume_current 或后置补填跳过重算会返回
@@ -558,8 +669,8 @@ approve/resubmit 携带 `form: { expectedRevision, values }` 时，Native 业务
 身份、环境、业务记录和固定页面由平台派生，不传actor/resource/page作为授权。
 可编译例子见 `examples/workflow-administration/task-draft.ts`。
 
-最多20份/90天与同用户、应用、环境、资源的其他表单草稿共享，单份最多64字段/64KiB。
-字段支持根附件、图片，暂不包含签名、富文本或子表。读到不兼容草稿时只返回安全标识与诊断，
+最多20份/90天与同用户、应用、环境、资源的其他表单草稿共享，单份最多64根字段/1MiB。
+字段支持根附件、图片、完整业务签名和富文本，暂不包含 owned 子表。读到不兼容草稿时只返回安全标识与诊断，
 不静默丢弃或泄露旧值。失去任务、角色或代理资格后不能继续读/用。
 
 读取不会自动覆盖输入；采用前确认，业务基线变化先核对并再次保存。相同输入暂存成功后
@@ -612,3 +723,107 @@ const readyFile = await completeWorkflowTaskFileUpload(taskId, input.id);
 复用既有 Native 文件引用 worker 和 GC；流式正式复制限时10秒。
 需要服务端正式 SQL `AddWorkflowTaskManagedFilesV2` 和自动能力
 `workflow.task-managed-files@1.0.0`，初始化无需新增开关。
+
+### 任务业务签名与富文本
+
+任务页面声明可编辑 `signature/text.rich` 时，标准 PC/手机字段控件自动使用同一任务
+文件、私有草稿和原流程提交入口。编译器同时要求 `workflow.task-rich-fields@1.0.0`；
+平台初始化自动提供，无新增配置开关。只有只读展示时不要求上传能力。
+
+业务签名保留完整 Native 值：`file: { id, name, size, contentType }`、可选 `signer`、
+`signedAt`、可选 `points` 和 `hash`，清空为 `null`。PNG、时间、笔迹与 SHA-256 在上传前
+固定，未知结果恢复只采用原文件，不重新签署。任务控件最多采样512个笔迹点并保留首尾；
+原 PNG 字节不改，仍受任务值1MiB限制。这些是业务采集信息，不代表平台认证的签署人、
+可信时间或法律电子签章。
+
+富文本保存清洗后的 HTML 和 Native 稳定托管图片地址，支持最多20图、单图10MiB、100MP。
+PC/手机保留格式、图片和前后文字；插图未知时锁住编辑，恢复采用原插入位置并只插入一次。
+`blob:` 仅用于授权预览，不进入保存值。新任务签名/富文本图片完成时核验实际图片解码与
+声明格式。完整值经 Native 校验后，草稿和正式审批共用排序文件锁、引用验证、保留期及事务。
+
+自定义 Field Kit 上传 renderer 的第四参数为可选 `onRecovered(file)`，仅在恢复原任务上传
+时采用完整字段值；正常上传仍返回 `DataFileRef`。非数组字段必须提供该回调；不能用文件数组
+append 处理签名或 HTML。当前任务、实例、记录或字段改变时清理旧图片预览，重新按范围读取。
+
+### 发起人同时参与审批
+
+审批节点可声明 `initiatorApprovalPolicy: 'auto_approve'`；省略或声明 `manual` 时由本人办理。
+该策略由流程代码固定，管理员可以调整已开放的审批方式与人员，不能修改此策略。
+仅当前已激活、由原人员解析或授权解析重试产生的发起人直接席位自动同意。
+单人/或签按正常同意规则完成；会签仍等待其他席位；依次审批只有轮到本人时才自动处理。
+发起人代理给他人、他人代理给发起人、转交、加签、管理员重分配及退回补正均需人工。
+
+带 `taskPageCode`、可写字段或强制同意意见的节点不能使用自动同意。需要补选负责人等
+业务输入的节点继续采用人工办理；配置也不能给自动节点增加强制同意意见。
+实际自动票使用原审批依赖与事务，历史显示“发起人自动同意”，事件包含 `automatic: true`
+及流程内核主体；没有伪造人工意见。后续解析失败会回滚本次自动票、任务与事件。
+每个事务最多进入 200 个节点、处理 200 个自动席位，业务步骤仍等待原业务结果。
+前一办理人来源保留原发起人；重启或原命令重放不重复自动票。
+
+此声明要求 `workflow.initiator-approval-policy@1.0.0`，缺少实现的目标平台会拒绝应用。
+
+### 审批人为空时的节点策略
+
+审批节点可声明 `emptyPolicy: 'skip'`，省略或声明 `block` 时保持阻塞。第一版 skip 支持 fixed_users、input_users、form_field_users、app_role、app_role_in_scope；编译器拒绝其他来源与 skip 组合。表单人员明确为 `[]`，或存在的角色在有效范围内没有成员，且解析成功、没有警告，才允许自动继续到 `onApprove`。缺失/null 字段、不存在的角色、无效账号、缺少范围、解析失败和非零人数不满足 min/max 都不能跳过。
+
+该策略由代码固定。每次实际跳过记录节点访问、当时配置、解析依据和 `openxiangda.workflow.node.skipped.v2` 事件；图和 PC/手机历史显示“已跳过”。连续节点推进受 200 节点上限约束，业务步骤仍等待其正式结果。后续失败与业务变更在原事务一起回滚，重试沿用原命令。
+
+退回补正（return_review）必须有人实际处理，不能靠空人跳过；重提后的正常 replay/resume 流转继续采用原节点策略。使用此声明时，生成契约要求目标平台支持 `workflow.approval-empty-policy@1.0.0`，缺少该能力的旧服务端不能接收。
+
+## 按业务资料权限查看办理历史 {#record-history-read}
+
+发起人、审批人、抄送人使用既有 Workflow 详情。业务查看人员需要根据当前资料范围读取办理记录时，模型可显式声明：
+
+```ts
+workflowHistory: { read: ['app:my-app:history:read'] },
+```
+
+`read: true` 绑定本资源的 read 能力，`false` 关闭入口；省略也关闭。能力数组引用已声明能力，最多20项，必须由同一角色成员全部持有，同时具备资源read。ALL资料读取角色与本人历史角色组合时，历史仍限本人行；Perspective和Native RLS继续收窄范围。此声明不授予审批、转交、后台或流程图管理能力，且独立于 `audit.read` 的资料变更记录。
+
+标准Native详情按声明提供折叠的“流程办理记录”。自定义用户端PC/手机页面可复用 `WorkflowRecordHistoryPanel`（`openxiangda/react`），传入 `resourceCode`、`recordId` 和 `variant`。通过 `loadWorkflowRecordHistory`（`openxiangda/core` 或 `openxiangda/react`）直接读取时，可传 `instanceId` 查看该记录的原固定实例，以及 `limit`（默认20、最多100）、`offset`（最多500）。环境来自当前平台runtime；接口不提供办理Surface或操作令牌。
+
+结果仅包含原流程版本、实际节点访问、人员、操作时间和意见，不返回条件事实、业务字段、代码、角色席位、原始log detail或授权摘要。每次请求重新授权；无权、没有可读实例、容量超限及读取中资料/实例变化分别保留明确失败。组件清除失败后的旧数据并提供手动重试，不自动重放写入。单实例最多500操作、200访问、1000审批/自动抄送席位，响应最多2MiB；历史较大时返回413，不静默截断。
+
+本能力要求平台 `workflow.record-history-read@1.0.0`。只读历史不提供评论发布、源系统打印或删除；这些行为需分别声明、授权和验收。
+
+## 拒绝通知的修改人 {#workflow-rejection-notification}
+
+当业务要求“申请被拒绝时通知最后修改人”，在固定流程定义中声明：
+
+```ts
+rejectionNotification: {
+  recipient: 'record_last_modifier',
+  title: '审批拒绝',
+  summary: '您有一个审批被拒绝，请查看',
+},
+```
+
+最后修改人是拒绝事务读取的 Native 主记录 `updated_by`，即最后一次成功业务写入所归属的用户。
+例如 A 发起、B 成功补填、C 拒绝时，专用拒绝通知发给 B。审批意见、拒绝操作和未成功的
+业务写入不会替换修改人。平台在原事务锁定主记录、冻结当前资料 revision 和收件人，
+通知队列恢复时使用原事实；之后的编辑不会改变这次通知的对象。
+
+标题最多160、摘要最多500字符，都是固定文本；不支持客户端收件人、任意字段路径、
+默认兜底人或节点管理员修改。缺失记录、空修改人或当前租户内无有效普通用户时，
+事实明确记录跳过原因；数据库或资源绑定失败沿原命令回滚，不产生部分拒绝事实。
+
+能力 `workflow.rejection-notification@1.0.0` 和 Notification Hub 由声明自动推导，平台
+初始化无需增加开关。省略声明或旧固定实例继续原行为。消息只读且没有审批按钮；
+点击仍认证并核验当前详情权限，收到消息不产生资料查看或流程办理权。
+实例原参与消息继续更新终态，专用消息另以实例为键去重。发送仍采用既有 outbox 的
+至少一次语义，沿原回执恢复；本地验证使用站内或 fake 渠道。
+
+应用无需后端或自建事件订阅。可编译例子见
+`examples/workflow-administration/rejection-notification.ts`。
+
+### 提交前检查必需审批人
+
+需要在保存业务资料前确认特定审批节点有人时，可在固定 definition 中声明：
+
+```ts
+launchPreflight: { requiredApprovalNodes: ['departmentReview', 'finalReview'] }
+```
+
+节点必须为实际 approval，最多20个且不能重复；本版只支持 fixed_users、initiator、app_role、app_role_in_scope，不能依赖未来任务补填、外部 provider 或候选字段。BusinessProcess.commit 在业务写入的同一事务内，按当前有效节点配置和真实成员/范围解析这些节点；空人、失效账号、超限或需要尚未提供的交互输入时整笔回滚。emptyPolicy:skip 不能绕过该准入。命中原提交回执时不会重新执行检查。
+
+这是提交准入，不预先冻结未来审批人；实际进入节点仍重新解析。声明要求目标具备 workflow.launch-preflight@1.0.0，未声明的流程保持原提交行为。实际角色与事务回滚需在目标平台验收。