openxiangda 2.34.3 → 2.44.0

package/documentation/workflow-events.md

@@ -104,6 +104,8 @@ events: {
 
 待办中心通过 Workflow 查询 `pending`、`handled`、`created`、`cc` 四种视图；消息中心默认向 Notification Hub 查询 `view=all`，沿用应用声明的渲染扩展。各入口按服务端 `detailNavigation` 打开详情，页面不自行拼接人员范围。
 
+标准任务和实例详情的“返回”由应用 Router 使用同一份 route manifest 中对应设备的流程中心路径；没有中心条目时返回已声明门户。普通用户无需管理后台权限。应用独立消费 `WorkflowTaskPage` 或 `WorkflowInstancePage` 时，可以传入本应用已声明的 `returnPath`，例如 `<WorkflowInstancePage variant="mobile" returnPath="/m/work-center" />`。抽屉的 `onDismiss` 仍负责关闭当前抽屉；返回导航不授予目标页面权限。
+
 抄送由动态 Surface 提供 `cc` 操作，使用 `user_select` 多选组件收集 1 至 20 位人员。任务 Surface 可以正式包含实例抄送命令；前端按 `operation.execute.href` 和该 Surface 的 token 提交，不另造任务命令或 token。公共事件为 `openxiangda.workflow.instance.cc_added.v2`。
 
 ## 钉钉卡片已读查询
@@ -151,13 +153,55 @@ Workflow 发起只接受 `{ resourceCode, id }` 形式的 `dataRef`，并要求
 
 ## 标准工作流范围
 
-首期只支持 `approval`、`condition`、`end`，以及 `single`、`any`、`all`、`sequence` 审批模式。标准操作为提交、同意、拒绝、退回、重新提交、转交、委托、前/后加签、撤回、管理员改派、管理员终止和不改变流程状态的催办。
+标准节点支持 `approval`、`condition`、`cc`、`end`，以及 `single`、`any`、`all`、`sequence` 审批模式。标准操作为提交、同意、拒绝、退回、重新提交、转交、委托、前/后加签、撤回、管理员改派、管理员终止和不改变流程状态的催办。
 
 除命令集之外，平台为实例管理员提供两个维护动作：`admin_jump`（把处于运行或退回状态的实例跳转到指定节点）与 `admin_delete`（删除实例，可选同时删除表单数据、是否触发自动化）。两者走平台管理端点的预览/执行两步流程并要求同源浏览器请求，不属于应用声明的工作流命令，也不占用 `commandToken` 命令合同。
 
 复杂业务状态机继续放在应用领域服务。不要把任意 JavaScript、Service Task、BPMN、通用长事务或业务记录复制进 Workflow。
 
 所有页面和消息动作必须来自后端 Workflow Surface 的 `operations[]`。前端、模板和渠道 Adapter 不自行推断操作权限。
+
+### 自动抄送 {#automatic-cc}
+
+在固定拓扑中声明 `cc` 节点，进入时解析接收人、保存抄送事实，然后继续 `next`。
+完整声明例子见 `examples/workflow-administration/automatic-cc.ts`：
+
+```ts
+copy: {
+  id: 'copy', kind: 'cc', title: '抄送办理负责人',
+  binding: 'readers', next: 'approved', emptyPolicy: 'block',
+  administration: { assigneeProviders: ['app_role', 'fixed_users'] },
+},
+```
+
+接收 binding 支持 `fixed_users`、`initiator`、`input_users`、`form_field_users`、
+`app_role`、`app_role_in_scope`、`previous_node_actor`。仅使用事务内原生来源，
+不支持 `application_provider` 或需要申请人交互的 `initiator_select`。名单按用户去重，
+每次进入最多 20 人；`min/max` 默认 1/20，非空名单仍必须符合声明的下限。
+角色查询超过 200 条有效成员行时明确拒绝，不能使用截断后的名单。
+范围角色要求对应范围的 `cc` 授权（或未限制操作、`*`），仅 `approve` 不满足。
+抄送不套用审批代理。
+
+`emptyPolicy: 'block'` 在真实空名单时回滚触发动作，补齐人员后可重试原申请或任务；
+`'skip'` 记录无人跳过并继续。未知角色、失效账号、非法输入和超限均属于错误，
+不会被 skip 吞掉。通知默认开启；`notify: false` 仍保存抄送审计、事件和实例阅读关系，
+Notification Hub 不生成该次抄送消息。渠道失败通过原 Hub 恢复，不回滚流程。
+
+进入记录、系统抄送日志及事件在同一事务提交。原命令重放不重复抄送；退回等导致实际
+再次进入时产生新轮次，可采用新的兼容节点配置，过去名单和配置保持冻结。时间线显示
+“流程自动抄送”，不会把系统动作记为发起人的人工操作。
+
+接收人可以使用既有抄送列表及实例详情，不获得审批权、后台权限或通用业务数据读取权。
+标准流程详情由服务器按页面代码声明的固定详情字段投影读取；需要排除敏感字段时，
+在 `crud.detail` 和 `subject.factProjection` 中明确选择允许字段，不能仅在浏览器隐藏。
+通用 Data API 继续核验当前数据授权，流程节点不提供字段权限配置。
+
+含 cc 的包自动声明 `workflow.automatic-cc@1.0.0`，平台正式迁移后自动提供该能力，
+没有额外开关。管理员仅可修改名称、说明及代码显式开放的接收来源，
+`next/emptyPolicy/notify` 保持代码所有；配置 SDK 见[应用管理](./administration.md#node-administration)。
+
+### 工作流命令
+
 Surface 同时签发短期、一次性的 `commandToken`，绑定当前用户/会话、应用环境
 Head、实例/任务版本、允许的命令集合与 CSRF。命令请求只提交
 `commandToken + idempotencyKey + input`；旧的 caller-authored
@@ -240,8 +284,8 @@ Native Data 事件的 capture plan 由当前 Head 的 Event、Data、AuthZ revis
 不是增量 patch。definition 和 activation 必须一致声明
 `acceptedCommandDeactivationPolicy`：`finish-pinned` 让已接受的 durable process
 command 按固定版本完成，`cancel-on-deactivate` 在声明删除后取消尚未启动的命令；
-既有 Workflow instance 始终按固定版本继续。所有审批人 Provider 的 `min/max`
-默认 1/200，最大 200。
+既有 Workflow instance 始终按固定版本继续。审批人 Provider 的 `min/max`
+默认 1/200，最大 200；自动抄送默认 1/20，最大 20。
 需要按流程实例串行投递时只声明 `ordering: 'workflow-instance'`，不接受下划线别名。
 
 平台按 desired set 直接覆盖环境 Head，不做版本比较。因此 `openxiangda deploy`
@@ -378,3 +422,193 @@ Surface 上执行。
 ## 验证
 
 至少验证：完整标准详情投影、父子表边界、流程附件读取、桌面/移动独立渲染、全部标准操作、多人模式、重复/并发命令、stale revision、重启 replay、乱序事件、重复回调、消息终态全量更新、详情跳转、错用户/错租户/过期动作、渠道超时/unknown、死信重放和 1.x 零触碰。
+
+## 流程说明与变量来源 {#workflow-readability}
+
+`definition.readability` 是可选说明，随不可变定义及其摘要发布。变量来源从实际 `inputSchema` 和 `subject.factProjection` 推导；不另行声明一个可编辑的条件图。例如，条件路径 `amountCents` 对应业务字段 `amountCents`，单选条件通常读取 `reason.value`：
+
+```ts
+readability: {
+  variables: {
+    amountCents: { label: '申请金额', unit: '分', description: '提交记录中的非负整数金额' },
+    'reason.value': { label: '休学原因值' },
+  },
+  logic: [{
+    code: 'submission-validation', title: '核验申请',
+    description: '提交时校验已声明字段；金额由表单直接提供',
+    phase: 'submission', inputPaths: ['amountCents'],
+  }],
+}
+```
+
+说明的执行位置只能是 submission、某节点的 node_input 或 completion。它是对已有逻辑的注释，不会自动执行计算或产生新流程节点。没有实际计算步骤时，不应写成“系统已计算总金额”。条件的变量必须存在于输入 Schema；对旧未标注定义，读取投影会明确给出未知来源诊断。
+
+可选 `source: { path, symbol?, digest }` 只返回源码位置和 SHA256，不返回源码内容。path 指向工作区 apps/packages/platform 下的代码文件，digest 为 `sha256:<原始文件字节摘要>`。工作区加载时核对文件存在、无符号链接、大小和摘要；源码变化后以 WORKFLOW_LOGIC_DESCRIPTION_STALE 阻止封装，开发者应核实说明并更新引用。32 个文件、单文件 2MiB、总量 8MiB 为上限。元数据不能验证任意 TypeScript 的业务含义，业务说明及验收仍由开发者维护。
+
+## 持久业务步骤
+
+必须收到业务计算或外部操作结果后才继续的流程，用固定 `action` 节点。平台自动
+提供 `workflow.durable-business-step@1.0.0`；应用包含动作时自动声明能力需求并
+按需引导标准 Nest 后端，普通无动作应用保持原合同。字段显隐/编辑/必填继续由
+页面代码负责；动作版本、Schema、条件和连线只由开发者发布。
+
+```ts
+const amountSchema = { type: 'object', additionalProperties: false,
+  required: ['amountCents'], properties: { amountCents: { type: 'integer', minimum: 0 } } };
+// 放入已声明流程的 nodes；amount-route 必须是同一固定定义中的真实目标。
+const calculate = {
+  id: 'calculate', kind: 'action', title: '核算金额', next: 'amount-route',
+  handler: { code: 'calculate-v1', version: 1, mode: 'pure' },
+  inputSchema: amountSchema, outputSchema: amountSchema,
+  inputs: { amountCents: { source: 'fact', path: 'amountCents' } },
+};
+// 放入 events.subscriptions；应用 backend.enabled=true，消费 generated manifest。
+const subscription = {
+  code: 'calculate-v1', eventTypes: ['openxiangda.workflow.step.requested.v2'],
+  filter: { workflowStep: { handlerCode: 'calculate-v1' } },
+  payload: { includeChanges: false, fields: [] },
+};
+```
+
+成功输出写入 `steps.calculate.amountCents`。后续条件或动作只能读取每条路径上
+已经完成的生产者；前向/自引用、非法路径和输入类型不兼容会拒绝编译。步骤后
+需要 HTTP provider 或发起人选人的组合暂不支持，先在动作中产生有 Schema 的
+人员数据，再使用原生人员字段/角色分派。示例见
+`examples/workflow-administration/business-step.ts`。
+
+Nest 使用 `@OpenXiangdaEventHandler(generatedContract)` 注册实现，`handle` 返回
+`{ output, receipt? }`；上下文 `workflowStep` 包含验证过的固定请求，
+`idempotencyKey` 是稳定 executionId。不得通过返回值任意指定下一节点或调用
+Workflow 跳转。使用标准 `PlatformOpenXiangdaEventReceiptStore`；内存 receipt
+不能完成业务步骤。
+
+`pure` 用于无外部效果的计算；`reconciled-effect` 必须实现 `reconcile(event,
+context)`：成功返回 `{ status:'succeeded', result:{output,receipt?} }`，确定未执行
+返回 `{status:'not-executed'}`，无法确定返回 `{status:'unknown'}`。每次尝试先
+核对原执行键，未知结果需要人工核对后重放原事件。增加v2时保留v1合同及代码；
+旧具名版本合同不可变，缺失实现明确失败，不自动改用最新版本。
+
+输入输出各16KiB、回执2KiB，最多32映射、200节点；Schema闭合且有界，无远端
+引用或正则执行。平台先持久保存合法结果，再尝试流转；下游缺人等失败保留
+`result_ready`，恢复仅推进，不再次执行处理器。自动恢复最多5次，每批20；
+outbox容量等事务故障会回滚，处理器按原键核对后重交，不承诺跨服务绝对一次。
+撤回后的未领取步骤拒绝执行，已开始的外部操作仍需原键核对。
+
+管理员在标准实例管理页或 `WorkflowBusinessStepRecoveryPanel` 查看并继续受阻
+步骤；公开客户端为 `loadWorkflowBusinessStepRecovery`、
+`previewWorkflowBusinessStepRecovery`、`executeWorkflowBusinessStepRecovery`。
+复用原管理权限/token/CAS/CSRF/审计，提交失败保留相同token/input/idempotencyKey。
+组件通过 `onDraftStateChange` 报告 dirty/busy/unknown；宿主将其接入已有导航保护，
+提交中或结果未知时保留组件和实例。未知结果只允许显式重试原恢复请求；首次明确
+的4xx拒绝可保留原因并重新预览。宿主刷新失败不改变已经确认的提交结果。
+等待处理器的失败从原事件管理受控重放，保留原执行键。普通详情只显示安全状态
+摘要；原输入、输出和外部回执不放入普通时间线。
+
+## 代码任务页面与补填 {#task-page-submit}
+
+需要办理人补填时，在定义的 `taskPages` 声明命名页面，审批节点以
+`taskPageCode` 引用。页面字段顺序、`readonly`、`required`、`visibleWhen` 和
+`requiredWhen` 属于应用代码；流程管理员不能覆盖页面字段、条件或连线。
+字段类型和编码来自同一个 Native 模型。例子见
+`examples/workflow-administration/task-page.ts`。
+
+页面表达式只读取本页 `values.*`，平台以合并后的业务值强制显隐和必填。
+最多16页、每页64字段、单次值64KiB，表达式8层/64节点。
+系统、流水号和隐藏字段不可作为补填入口。根附件、图片复用平台托管文件；
+签名、子表和富文本仍需后续任务页面支持，不将它们降为任意 JSON。
+
+标准 PC/手机任务页和 `WorkflowTaskOperationsPanel` 自动显示当前参与人的
+`surface.taskForm`。`save_form` 表示“提交补填，继续办理”，不是私有草稿。
+approve/resubmit 携带 `form: { expectedRevision, values }` 时，Native 业务更新、
+事实刷新、任务决定和下游流转同事务提交。reject/return/transfer 等操作不得
+夹带表单。审批人仅获得当前任务对应的单记录/页面字段入口，不获得通用 CRUD。
+
+相同幂等键不同输入拒绝；结果未知时保留原 token/input/key。共享组件锁定
+编辑，只重试原请求或调用 `loadWorkflowTaskCommandReceipt(taskId, key, tokenDigest)`
+查询本人原回执。重载只保存定位信息和 SHA256 token 摘要，不保存凭据或表单。
+`not_observed` 仍然未知；只有平台锁住确切凭证、确认数据库时间已过期且未使用
+的 `expired_unconsumed` 才能解除等待，供用户核对资料后重新确认。
+组件复用宿主的 `OpenXiangdaApplication` 导航保护；成功后刷新失败不变成提交失败。
+
+嵌入自定义详情时，可用 `renderLayout={({ content, actions, surface }) => ...}` 将补填表单和
+恢复提示放在可滚动正文，将操作按钮放在底栏。两部分始终使用同一个任务面板，
+不要分别创建两个面板或复制其表单、请求和回执状态。`surface` 是面板当前实际展示的
+资料，自定义详情用它显示刷新后的字段；加载或无可用资料时为空。标准详情已采用该布局。
+
+多人补填与管理纠错使用 Native 记录 CAS，冲突保留输入。首次请求的明确拒绝会只读刷新，
+修订变化时对照最新已保存值和本人输入，核对前锁住字段与操作；可选择保留输入或采用最新值。
+拒绝后的读取失败明确提示本次未提交，锁住旧操作，恢复读取后再核对；未知结果仍只能恢复原请求。
+补填刷新固定事实投影；
+修改已计算步骤的输入时清除当前失效输出及依赖输出。仅退回 replay 且所有前向
+审批路径确定重经生产者时允许；resume_current 或后置补填跳过重算会返回
+`WORKFLOW_TASK_FORM_RECOMPUTATION_REQUIRED` 并回滚，历史结果与签名保持。
+自动能力为 `workflow.task-page-submit@1.0.0`，平台初始化无需额外开关。
+
+### 任务私有草稿
+
+标准PC/手机任务页和嵌入面板提供“保存私有草稿”“我的草稿”。暂存仅本人可见，
+不会更新业务资料、事实、待办或推进任务；可以保存尚未完成必填的标量输入。
+页面的显隐/只读规则和Native类型仍强制，管理员没有字段覆盖或读取他人草稿的入口。
+
+自定义页面从 `openxiangda/core` 或 `openxiangda/react` 调用
+`loadWorkflowTaskDrafts(taskId)`、`saveWorkflowTaskDraft(taskId, input)` 和
+`removeWorkflowTaskDraft(taskId, { id, expectedRevision })`。
+保存输入为 `{ id, expectedRevision, recordRevision, values }`：首写前固定UUID及
+`expectedRevision: 0`；recordRevision来自当前taskForm.expectedRevision。
+身份、环境、业务记录和固定页面由平台派生，不传actor/resource/page作为授权。
+可编译例子见 `examples/workflow-administration/task-draft.ts`。
+
+最多20份/90天与同用户、应用、环境、资源的其他表单草稿共享，单份最多64字段/64KiB。
+字段支持根附件、图片，暂不包含签名、富文本或子表。读到不兼容草稿时只返回安全标识与诊断，
+不静默丢弃或泄露旧值。失去任务、角色或代理资格后不能继续读/用。
+
+读取不会自动覆盖输入；采用前确认，业务基线变化先核对并再次保存。相同输入暂存成功后
+可安全离开，后续新编辑恢复导航保护；浏览器持久存储不保存字段值。
+结果未知保留原id/CAS/values，仅核对同id或重试原保存；同一次最后保存确认不新增修订，
+其他CAS冲突保留输入。新id必须是用户明确另存，不能用自动另存掩盖未知结果。
+
+正式 `form: { expectedRevision, values, draft: { id, expectedRevision } }` 可以包含暂存之后的新编辑。
+平台锁住本人草稿及业务基线，再沿原save_form/approve/resubmit命令同事务更新业务并消费，
+失败全部回滚。原成功命令重试先返回唯一Workflow回执，不因草稿已消费重复写入。
+任务真正关闭才过期未消费草稿，all/sequence任务仍可办理时保留其他人的有效草稿。
+能力 `workflow.task-private-drafts@1.0.0` 自动提供，无额外配置开关。
+
+### 任务附件与图片
+
+当前任务的可编辑 `file/image` 字段自动接入标准 PC/手机上传、缩略图、预览和下载。
+当前处理资格不授通用资源 CRUD；平台从固定任务派生记录、页面、身份和环境，
+上传时还核验**已保存业务资料对应的页面状态**。局部修改才显示附件字段时，
+先“保存补填”使字段生效，再上传；组件说明此边界，不自动提交业务值。
+
+自定义页面可从 `openxiangda/core` 或 `openxiangda/react` 调用：
+
+```ts
+const input = { id: crypto.randomUUID(), fieldCode: 'evidence',
+  fileName: file.name, fileSize: file.size, contentType: file.type };
+const plan = await initiateWorkflowTaskFileUpload(taskId, input);
+// pending 才按 plan.uploadMethod/uploadUrl/headers 上传原 File；ready 直接采用 plan.file。
+const readyFile = await completeWorkflowTaskFileUpload(taskId, input.id);
+// 结果未知时：loadWorkflowTaskFileUploadPlan(taskId, input.id)，或重试同 ID/规格。
+```
+
+上传 ID 必须在第一次请求前固定。标准组件一次处理一个文件；上传中或结果未知时
+保留原 File、ID、规格和当前输入，锁住新任务动作与草稿写入，提供“核对原上传”
+和“重试原上传”。ready 结果不再 PUT；完成响应丢失后只恢复原完成结果。
+文件字节、签名地址与表单值不进入浏览器持久存储。离开未完成上传时需先确认结果。
+
+预览字段组件传入 `workflowFileBinding: { taskId, resourceCode, recordId, fieldCode }`；
+正式实例详情使用原 `instanceId` binding。同一 binding 只提供一种范围。
+仅本人当前任务可读私有暂存文件，其他处理人和管理员没有私有读取特权。
+当前根业务记录已经引用的文件可按该任务页面规则读取；隐藏、资格失效或任务关闭后拒绝。
+通用 Native 完成、删除和未绑定文件读取不能绕过此范围。
+
+附件完成后仍只是当前输入；私有草稿延长文件保留至该草稿到期，业务绑定再移除引用
+仍尊重该保留期。原 save_form/approve/resubmit 验证真实文件状态、字段、范围与元数据，
+同事务提交业务引用、事实、任务决定和草稿消费；失败全回滚。完成上传时平台复制为
+独占正式对象，旧上传地址不能再修改正式字节。
+
+单文件不超过字段限制与100MiB；每账号/应用/环境最多100个尚未业务绑定的任务文件，
+声明大小合计200MiB。此大小是上传容量预算，staging/正式对象与缩略图另有存储开销。
+复用既有 Native 文件引用 worker 和 GC；流式正式复制限时10秒。
+需要服务端正式 SQL `AddWorkflowTaskManagedFilesV2` 和自动能力
+`workflow.task-managed-files@1.0.0`，初始化无需新增开关。

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "openxiangda",
-  "version": "2.34.3",
+  "version": "2.44.0",
   "description": "OpenXiangda 2.0 的统一命令、应用 SDK、MCP 与中文 AI 技能资料。",
   "type": "module",
   "main": "./dist/index.js",
@@ -61,16 +61,18 @@
   "dependencies": {
     "@js-temporal/polyfill": "0.5.1",
     "@rc-component/picker": "1.10.0",
+    "@xyflow/react": "12.12.0",
     "antd-mobile": "5.42.3",
     "dayjs": "1.11.18",
     "docx-preview": "0.3.7",
-    "openxiangda-cli": "2.6.17",
-    "openxiangda-contracts": "2.34.0",
-    "openxiangda-devkit-core": "2.35.0",
+    "elkjs": "0.12.0",
+    "openxiangda-cli": "2.6.37",
+    "openxiangda-contracts": "2.43.0",
+    "openxiangda-devkit-core": "2.41.2",
     "openxiangda-legacy": "npm:openxiangda@1.0.269",
-    "openxiangda-mcp": "2.0.62",
-    "openxiangda-nest": "2.11.0",
-    "openxiangda-skill-kit": "2.3.40",
+    "openxiangda-mcp": "2.0.73",
+    "openxiangda-nest": "2.13.3",
+    "openxiangda-skill-kit": "2.3.52",
     "xlsx": "https://github.com/1377385356/openxiangda/releases/download/vendor-mirror/xlsx-0.20.3.tgz"
   },
   "peerDependencies": {
@@ -136,38 +138,39 @@
   },
   "openxiangdaRelease": {
     "schemaVersion": "openxiangda.release-notes/v1",
-    "version": "2.34.3",
+    "version": "2.44.0",
     "status": "reviewed",
-    "title": "OpenXiangda 2.34.3：显式长期只读繁忙恢复",
-    "summary": "允许热点详情等只读页面显式选择最长三十分钟恢复；默认两分钟策略及持久申请原期限保持，取消与真实故障仍及时结束。",
+    "title": "OpenXiangda 2.44.0：当前任务的托管附件与图片",
+    "summary": "代码任务页面支持根附件与图片，普通审批人通过固定任务上传和预览，草稿保留和正式流程提交复用平台文件生命周期。",
     "newFeatures": [
-      "受管read、mine、result、allocation可显式设置budgetMs，超过120秒时最多恢复30分钟、120次请求；默认120秒和12次保持。"
+      "任务文件 SDK 支持固定 ID 的原计划与完成恢复，标准 PC/手机上传及预览自动接入。",
+      "编译器按可编辑任务文件申请 workflow.task-managed-files 自动能力，无额外默认关闭开关。"
     ],
     "fixes": [
-      "长期读取仍冻结原输入、身份与权限视角，按原调用截止及Retry-After/抖动退避；AbortSignal中止请求和等待。",
-      "持久申请控制器显式保留原单次120秒上限，防止SDK扩展隐式改变既有受理和观察行为。"
+      "上传结果未知时保留原文件与请求并锁住新流程动作和草稿写入；ready 结果不再次 PUT。",
+      "任务表单和本人草稿比较使用任务文件范围，避免依赖通用 CRUD 预览资格。"
     ],
     "affectedUsers": [
-      "使用受管热点详情和持久排队能力的活动报名、预约及抢票应用开发者。"
+      "声明 file/image 任务补填页面的 V2 应用开发者、办理人和平台维护者。"
     ],
     "upgradeSteps": [
-      "将应用openxiangda精确升级到2.34.3并刷新资料；应用按业务选择显式预算、离页取消及未结束窗口的固定截止。",
-      "验证繁忙恢复、真实网络/权限/依赖错误、身份切换和持久申请原期限后部署测试环境，目标硬件容量另外实测。"
+      "消费同批本地 SDK/contracts 与匹配平台 Server，应用迁移 AddWorkflowTaskManagedFilesV2，刷新资料并重启。",
+      "局部修改才显示附件字段时先保存补填，再上传；自定义页面固定上传 UUID，并保留原请求处理未知结果。"
     ],
     "knownLimitations": [
-      "仅已知只读繁忙恢复；不吞未知429、网络、权限或依赖失败，不自动重试写入。",
-      "客户端等待窗口不承诺服务端容量或最终处理时间，不代表已经受理或报名。",
-      "长期恢复不自动启用，普通Data API、平台后端与V1业务不变；刷新固定窗口由应用生命周期接入。"
+      "本轮交付根 file/image，签名、富文本和 owned 子表仍按后续任务页面切片验证。",
+      "上传资格依据已保存资料的页面状态；管理员不能配置字段权限。",
+      "本轮是本地迁移实验，npm 发布与学校生产迁移分别另行执行。"
     ],
     "issues": [],
     "compatibility": {
       "node": ">=24",
       "workspaceGenerations": "v2",
-      "platform": "沿用data.managed-concurrency.durable@1.0.0；新入口429预算错误需要匹配平台版本。",
-      "v1": "V1引擎及业务不变。"
+      "platform": "workflow.task-managed-files@1.0.0 与 AddWorkflowTaskManagedFilesV2",
+      "v1": "1.x 引擎独立，本轮不改变其上传入口。"
     },
-    "sha256": "fe3ba4a4c33af0e158cbe5bb7b25c9ba4c75e4ef97a02479eded9c71885d00ec",
-    "url": "https://github.com/1377385356/openxiangda/releases/tag/v2.34.3"
+    "sha256": "b4d4027b81772f5c63ef0638b7ffa9c73374799a398bd17c8828ed126410e4da",
+    "url": "https://github.com/1377385356/openxiangda/releases/tag/v2.44.0"
   },
   "scripts": {
     "build": "node ../../scripts/prune-package-dist.mjs && tsc -p tsconfig.json && node scripts/copy-assets.mjs",

package/releases/2.43.0.json

@@ -0,0 +1,38 @@
+{
+  "schemaVersion": "openxiangda.release-notes/v1",
+  "version": "2.43.0",
+  "status": "reviewed",
+  "title": "OpenXiangda 2.43.0：持久命令的有界发现与原申请恢复",
+  "summary": "热点应用可显式延长只读发现预算，刷新合并并优先核对原键；未知受理保留原申请与输入，避免误报排队成功。",
+  "newFeatures": [
+    "DurableCommandOptions 与 useDurableCommand 新增 discoveryRecoveryMs，默认 120 秒，可显式配置最长 30 分钟；每次发现共享固定截止。",
+    "DurableCommandSnapshot 新增 acceptanceConfirmed，供界面区分已确认受理与仍需核对的原申请。"
+  ],
+  "fixes": [
+    "已确认非终态优先读取原键，原键 404 保留受控本人列表兜底；未确认原意图不会被其他周期覆盖。",
+    "重复刷新合并，停止后重新挂载可重新只读发现；回执同时核对原键、operationId 和作用域。",
+    "CLI 内置模板与同批 SDK 精确版本同步，中文接入资料随 skill-kit 发布。"
+  ],
+  "affectedUsers": [
+    "使用持久命令排队提交、原申请恢复的 V2 页面开发者及应用用户。"
+  ],
+  "upgradeSteps": [
+    "安装同批正式 openxiangda 包，刷新技能资料并重启应用；按应用需求显式配置 discoveryRecoveryMs。",
+    "排队文案以 acceptanceConfirmed 为准，未知受理提供显式恢复原申请操作，不在挂载时重放提交。",
+    "本轮能力不要求新服务端契约或 SQL；使用此前新增的工作流能力时仍需对应平台正式迁移与服务端版本。"
+  ],
+  "knownLimitations": [
+    "延长只读发现预算不会延长原首次提交的受理或观察窗口，也不会自动补单。",
+    "单元与发行门禁不证明实际服务器容量；入口、受理和本人结果须在目标环境独立测量。",
+    "浏览器尚未取得受理回执时，离页不能保证原申请已经进入后台队列。"
+  ],
+  "issues": [],
+  "compatibility": {
+    "node": ">=24",
+    "workspaceGenerations": "v2",
+    "platform": "现有 managed concurrency durable command 契约；新增恢复选项为可选。",
+    "v1": "V1 引擎保持独立，本轮无行为变更。"
+  },
+  "sha256": "456c5671abc109c2cadc82bd22ae82adb2756293b63ee79aad941fc3450138d3",
+  "url": "https://github.com/1377385356/openxiangda/releases/tag/v2.43.0"
+}

package/releases/2.44.0.json

@@ -0,0 +1,36 @@
+{
+  "schemaVersion": "openxiangda.release-notes/v1",
+  "version": "2.44.0",
+  "status": "reviewed",
+  "title": "OpenXiangda 2.44.0：当前任务的托管附件与图片",
+  "summary": "代码任务页面支持根附件与图片，普通审批人通过固定任务上传和预览，草稿保留和正式流程提交复用平台文件生命周期。",
+  "newFeatures": [
+    "任务文件 SDK 支持固定 ID 的原计划与完成恢复，标准 PC/手机上传及预览自动接入。",
+    "编译器按可编辑任务文件申请 workflow.task-managed-files 自动能力，无额外默认关闭开关。"
+  ],
+  "fixes": [
+    "上传结果未知时保留原文件与请求并锁住新流程动作和草稿写入；ready 结果不再次 PUT。",
+    "任务表单和本人草稿比较使用任务文件范围，避免依赖通用 CRUD 预览资格。"
+  ],
+  "affectedUsers": [
+    "声明 file/image 任务补填页面的 V2 应用开发者、办理人和平台维护者。"
+  ],
+  "upgradeSteps": [
+    "消费同批本地 SDK/contracts 与匹配平台 Server，应用迁移 AddWorkflowTaskManagedFilesV2，刷新资料并重启。",
+    "局部修改才显示附件字段时先保存补填，再上传；自定义页面固定上传 UUID，并保留原请求处理未知结果。"
+  ],
+  "knownLimitations": [
+    "本轮交付根 file/image，签名、富文本和 owned 子表仍按后续任务页面切片验证。",
+    "上传资格依据已保存资料的页面状态；管理员不能配置字段权限。",
+    "本轮是本地迁移实验，npm 发布与学校生产迁移分别另行执行。"
+  ],
+  "issues": [],
+  "compatibility": {
+    "node": ">=24",
+    "workspaceGenerations": "v2",
+    "platform": "workflow.task-managed-files@1.0.0 与 AddWorkflowTaskManagedFilesV2",
+    "v1": "1.x 引擎独立，本轮不改变其上传入口。"
+  },
+  "sha256": "b4d4027b81772f5c63ef0638b7ffa9c73374799a398bd17c8828ed126410e4da",
+  "url": "https://github.com/1377385356/openxiangda/releases/tag/v2.44.0"
+}

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": "cef2746d78672c453d225e3609dcbee446b30898fa3e146b734a26b0cd3f6a92"
+      "sha256": "9350d7e567e877208b86929f0eeedade792f9750989ca08055061092c980ec37"
     }
   ]
 }

package/skills/openxiangda-v2/SKILL.md

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