openxiangda 2.34.2 → 2.35.3

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

@@ -25,3 +25,66 @@ MCP 对应 `workflow_node_configurations`。workflowCode 来自当前应用声
 确有业务需要时，使用 `openxiangda/core` 的角色管理 SDK。目录提供可管理角色、动作与授权范围；业务角色只能维护管理员已委托的范围。进一步委托要求 management.delegate，并受已有目标角色及动作子集限制。
 
 成员和委托修改带 UUID operationId、原因，更新/撤销带最新 expectedRevision；冲突后重新读取。应用不另建授权表、选择 actor 或自行保存权限快照。SDK 和当前用户数据边界见[权限](data-authz.md)。
+
+## 可读流程图与实例路径 {#workflow-graph}
+
+管理员在流程目录检索全部定义，查看指定版本的分支顺序、默认路径、变量类型/单位及来源。拓扑和条件由开发者发布；图和列表只用于查看。当前有效配置只叠加在匹配的激活定义上；历史实例使用固定定义和节点进入时的人员/配置，尚未执行的节点不计入执行路径。
+
+目录进入独立流程图地址，刷新及浏览器返回保留所查看流程/版本。共享组件按需加载 React Flow 与 ELK 正交布局：所有线段横平竖直、转角为直角；支持画布平移、滚轮缩放、适应全图、聚焦选中和缩略导航。分支标签可选中，详情保留完整条件、顺序和来源；窄屏采用同源节点列表，方向键/Home/End 定位节点。画布布局上限为 200 节点、1024 连线，不提供拖改、删除或连线编辑。
+
+应用自定义管理页面可复用当前用户客户端和共享图组件：
+
+```tsx
+import { useEffect, useState } from 'react';
+import { WorkflowDiagram } from 'openxiangda/react';
+import { loadWorkflowDefinitionGraph, type WorkflowGraphReadResult } from 'openxiangda/core';
+
+export function ReadableWorkflow({ workflowCode, version }: {
+  workflowCode: string; version: number;
+}) {
+  const [result, setResult] = useState<WorkflowGraphReadResult>();
+  const [selected, setSelected] = useState('');
+  const [error, setError] = useState('');
+  useEffect(() => {
+    let cancelled = false;
+    setResult(undefined); setError('');
+    loadWorkflowDefinitionGraph(workflowCode, version).then(value => {
+      if (!cancelled) { setResult(value); setSelected(value.graph.startAt); }
+    }).catch(error => { if (!cancelled) setError(error.message); });
+    return () => { cancelled = true; };
+  }, [workflowCode, version]);
+  if (error) return <p role="alert">{error}</p>;
+  if (!result) return <p>正在读取流程</p>;
+  return <WorkflowDiagram graph={result.graph} selectedNodeId={selected} onSelectNode={setSelected} />;
+}
+```
+
+组件运行在平台应用作用域内，SDK 使用当前用户，凭据及环境继续由平台管理。`loadWorkflowInstanceGraph(instanceId)` 返回固定版本、序列及持久访问记录，传入组件 `visits` 即可查看实际路径。两种管理读取都受服务端授权；不能给普通申请页暴露整个管理读面。
+
+`titles`、`summaries` 只用于匹配版本的有效配置或进入快照；不能将今天的模式叠加到旧实例。可选 `selectedEdgeId/onSelectEdge` 将图上分支选择关联到自定义详情；它们不修改条件。实际边由访问记录的 `transition/matchedBranch` 确认，两个节点先后出现不能证明中间所有连线都被执行。
+
+## 有界节点配置与 SDK {#node-administration}
+
+开发者在审批节点的 `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`。
+
+应用自定义管理页可使用 `WorkflowNodeConfigurationEditor`（`openxiangda/react`），输入同一读面中的节点、principals 和 context.headRevision，放在平台 App/UI 作用域内。它复用下列当前用户 SDK：
+
+```ts
+import { loadApplicationAdministrationContext, loadWorkflowNodeConfigurations,
+  saveWorkflowNodeConfiguration } from 'openxiangda/core';
+
+const context = await loadApplicationAdministrationContext();
+const configuration = await loadWorkflowNodeConfigurations('requests');
+const node = configuration.nodes.find(item => item.nodeId === 'review')!;
+const operationId = crypto.randomUUID();
+await saveWorkflowNodeConfiguration('requests', node.nodeId, {
+  expectedHeadRevision: context.headRevision!, expectedRevision: node.configuration.revision,
+  operationId, reason: '更新复审方式', patch: { mode: 'all' },
+});
+```
+
+只有已声明允许 all 的节点可保存此例。输入最多 32KiB，人员 200、按钮文字 40 字。用 `patch: null` 恢复默认，也产生审计修订。结果未知时保留相同 operationId 和完整请求，查询后重试相同操作；确认的修订/Head 冲突先重新读取，不能覆盖别人。共享编辑器按审批人、审批按钮、名称与说明分组，显示配置来源、修订与生效范围；切组保留草稿，校验失败定位到相应分组。在冲突时保留草稿，加载最新基准后再次显式保存。
+
+新配置影响以后进入的节点，当前待办保留进入时模式、人员、按钮和必填意见；实时人员资格仍复核。含新增配置或快照的环境不能直接回退到忽略策略的旧服务器。

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

@@ -68,10 +68,10 @@ MCP 服务随项目根包一起安装，AI 客户端的 stdio 连接仍需配置
 以下命令的版本占位符由随包资料替换为该根包的精确版本。网站源码阅读者应先确认要使用的发行版本。
 
 ```bash
-pnpm dlx openxiangda@2.34.2 skill install --force
-pnpm dlx openxiangda@2.34.2 auth status --base-url <平台地址> --json
-pnpm dlx openxiangda@2.34.2 login --cwd my-app --base-url https://platform.example.com
-pnpm dlx openxiangda@2.34.2 create my-app --base-url https://platform.example.com
+pnpm dlx openxiangda@2.35.3 skill install --force
+pnpm dlx openxiangda@2.35.3 auth status --base-url <平台地址> --json
+pnpm dlx openxiangda@2.35.3 login --cwd my-app --base-url https://platform.example.com
+pnpm dlx openxiangda@2.35.3 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.34.2 auth status --base-url <平台> --json
-pnpm dlx openxiangda@2.34.2 source resolve <仓库URL> --base-url <平台> --json
-pnpm dlx openxiangda@2.34.2 source clone <仓库URL> <新目录> --base-url <平台> --json
+pnpm dlx openxiangda@2.35.3 auth status --base-url <平台> --json
+pnpm dlx openxiangda@2.35.3 source resolve <仓库URL> --base-url <平台> --json
+pnpm dlx openxiangda@2.35.3 source clone <仓库URL> <新目录> --base-url <平台> --json
 ```
 
 登录缺失或站点不匹配时，先按该平台执行 login。resolve 根据平台已经登记的绑定返回

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

@@ -51,11 +51,11 @@ export async function readOffer(
 
 ### 只读预算繁忙恢复
 
-`read`、`mine`、`result`、`allocation` 共用有界恢复：单次调用默认含 HTTP 和等待的总预算 120 秒，最多 12 次总请求。只重试 HTTP 429 的 `CONCURRENCY_API_BUSY`、`CONCURRENCY_RESULT_BUSY`、`CONCURRENCY_RATE_LIMITED`、`CONCURRENCY_SOURCE_BUSY`；兼容旧平台的 HTTP 503 仅限前两个已知预算错误。明确 `retryable: false`、未知 429、权限拒绝、Redis/数据库/授权依赖失败和网络失败直接返回，不用繁忙重试掩盖。
+`read`、`mine`、`result`、`allocation` 共用有界恢复：单次调用默认含 HTTP 和等待的总预算 120 秒，最多 12 次总请求。应用可以通过 `budgetMs` 显式延长；超过 120 秒时最多 120 次总请求，预算上限为 30 分钟，超出上限按 30 分钟处理。只重试 HTTP 429 的 `CONCURRENCY_API_BUSY`、`CONCURRENCY_RESULT_BUSY`、`CONCURRENCY_RATE_LIMITED`、`CONCURRENCY_SOURCE_BUSY`；兼容旧平台的 HTTP 503 仅限前两个已知预算错误。明确 `retryable: false`、未知 429、权限拒绝、Redis/数据库/授权依赖失败和网络失败直接返回，不用繁忙重试掩盖。
 
-第一次失败后的基础等待为 2 秒，之后指数增加到最多 30 秒；取其与有效服务端提示的较大值，再加 0% 至 25% 随机抖动。提示优先使用合法 `Retry-After`（秒或 HTTP 日期），缺失时使用 `data.retryAfterMs`。若等待达到剩余预算，不提前查询，直接返回最后一次繁忙错误；12 次用完也保留最后繁忙响应。正在进行的请求超过总预算则中止并返回 `CONCURRENCY_READ_RECOVERY_EXHAUSTED`，不以之前的繁忙响应掩盖悬挂请求。
+第一次失败后的基础等待为 2 秒，之后指数增加到最多 30 秒；取其与有效服务端提示的较大值，再加 0% 至 25% 随机抖动。提示优先使用合法 `Retry-After`（秒或 HTTP 日期），缺失时使用 `data.retryAfterMs`。若等待达到剩余预算，不提前查询，直接返回最后一次繁忙错误；请求次数用完也保留最后繁忙响应。正在进行的请求超过总预算则中止并返回 `CONCURRENCY_READ_RECOVERY_EXHAUSTED`，不以之前的繁忙响应掩盖悬挂请求。
 
-可以传入更短的剩余预算，不能扩展单次 120 秒上限：
+可以传入更短的剩余预算，或为高流量详情入口显式选择较长的等待窗口：
 
 ```ts
 // budgetMs 含本次请求和所有预算繁忙退避；服务端事实仍为最终依据。
@@ -63,8 +63,13 @@ const receipt = await client.result({ operationId }, signal, {
   budgetMs: Math.max(0, originalDeadline - Date.now()),
 });
 const offer = await client.read<Offer>('offer', { id: offerId }, signal, { budgetMs: 30_000 });
+const detail = await client.read<Offer>('offer', { id: offerId }, signal, {
+  budgetMs: 30 * 60 * 1000,
+});
 ```
 
+预算在本次调用启动时固定，繁忙重试不重新计时。页面应保留同一资源、身份和视角的整体截止时间，并在重新查询时传入剩余量；刷新不能无限续期。长期读取等待只表示尚未取得页面信息，不能显示为已报名或已进入业务队列。持久申请控制器继续保留每次读取最多 120 秒和原有受理、观察期限，显式延长详情读取不会更改已提交申请的首次期限。
+
 每次调用在第一次请求前冻结完整参数、环境、主体及权限视角；后续修改表单不会改变重试内容。身份或视角变化时停止旧调用并返回 `CONCURRENCY_IDENTITY_CHANGED`。`AbortSignal` 可以中止请求和等待；组件卸载应中止旧读取。`enqueue`、`accept`、`cancel` 等写方法不使用这层自动重试，持久申请的原键受理恢复由下述控制器单独管理。普通 Data API 也不自动获得此策略。
 
 `freshness: 'stale'` 表示返回的是允许使用的旧内容，并不证明后台刷新已经成功。保留内容并提示“当前展示最近一次可用信息”；按新鲜期和有界退避刷新，超过 `staleUntil` 后不能继续无限展示。手动刷新仍调用同一命名读取，不绕回普通 CRUD。

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

@@ -4,6 +4,16 @@
 
 页面开发参见[并发能力的前端接入](managed-concurrency-frontend.md)：按热点详情、一键申请、填完再提交、短确认入口、预占确认和原结果恢复选择交互方式，并核对当前 API 与尚未提供的封装边界。
 
+## 开抢瞬间的完整请求链
+
+容量验收覆盖同一批用户的整条请求链：进入 HTML 和静态资源、运行时身份初始化、活动内容与本人状态、持久排队提交、后台执行、按原请求键恢复结果，以及页面的自然查询。为这些入口共同规划连接数、HTTP 在途数、数据库连接、回源和 worker 预算；只测 enqueue 或缓存命中，不能证明整条链能承受同一秒进入的人数。共享活动内容和本人状态分别使用合适的读取范围与失效依赖，排队阶段按服务端建议间隔和抖动查询，避免自然刷新再次形成尖峰。
+
+运行时 current 对明确繁忙响应最多恢复 300 秒，安全只读传输故障最多三次总尝试。它只帮助用户完成入口初始化，尚未持久受理业务申请；只有 enqueue 返回持久回执后才展示已受理。退出、真实身份变化、权限或版本拒绝仍应停止旧客户端。同身份检查保留页面和原申请，刷新或重新进入继续查原请求键，不自动创建第二次提交。
+
+资源不足时，通过独立 intake 预算保护新受理，再让持久命令在业务 deadline 内等待受控执行；等待、重试与恢复不延长原截止。资源充足时，根据已测的 CPU、数据库连接、锁竞争和完成率提高工作预算，分别调整受理、回源、查询与执行，不能只增加队列长度或 worker 数。业务需要三十分钟内完成时，同时核对命令自身的 acceptedAt/deadlineAt，以及从开抢时刻到最终结果的总耗时，入口等待不能被排除在体验指标之外。
+
+记录同一秒发起人数、进入成功率、持久受理率、明确拒绝、暂时无法确认、最终结果耗时分布、最老非终态与资源峰值。合成独立测试主体用于验证目标服务器的应用请求链；真实 SSO 认证、客户端网络和浏览器渲染容量需要另行验证，不能由合成压测推断。
+
 ## 声明与权限
 
 完整且由双编译器测试验证的示例位于源码 `examples/managed-concurrency/declaration.ts`。调用 `defineOpenXiangdaApp(concurrencyExample())` 即可编译。把示例中的 `data.concurrency` 合入应用配置，并按实际业务配置模型和参与权限。

package/skills/openxiangda-v2/references/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`。
 
 ## 钉钉卡片已读查询
@@ -378,3 +380,25 @@ 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 的业务含义，业务说明及验收仍由开发者维护。

package/releases/2.0.0.json

@@ -1,50 +0,0 @@
-{
-  "schemaVersion": "openxiangda.release-notes/v1",
-  "version": "2.0.0",
-  "title": "OpenXiangda 2.0 正式版",
-  "status": "reviewed",
-  "summary": "以统一入口使用两代工作区，新应用默认采用 V2。V2 提供从需求设计到 React 应用、平台数据权限和应用交付的完整工具链。",
-  "newFeatures": [
-    "统一入口识别最近的 V1/V2 工作区，优先使用项目已安装的锁定引擎；无本地 V1 引擎的旧工作区使用随入口固定的 V1 维护引擎。",
-    "新应用默认 V2：自然语言澄清产品需求，形成产品、页面、权限和架构设计基线，确认后再制定开发计划。",
-    "V2 提供标准 PC/移动端 CRUD、字段组件、Data API 权限、流程与协作能力；默认本地 React 连接平台测试环境，Nest 后端按需使用。",
-    "提供版本识别、分代更新、随包更新说明和 V1 到 V2 的只读迁移评估。"
-  ],
-  "fixes": [
-    "全局入口切换到 V2 后，旧 V1 工作区仍由 V1 执行，不再因同名命令使用错误代际。",
-    "项目工具链升级与全局入口升级明确分开；V1 维护渠道不再改写 latest。",
-    "两代 Skill 使用独立入口，V1 安装不再覆盖统一入口或清理 V2 Skill。"
-  ],
-  "affectedUsers": [
-    "新建应用的开发者",
-    "需要继续维护 V1 工作区的开发者",
-    "从 V2 alpha 升级的现有用户"
-  ],
-  "compatibility": {
-    "node": ">=24",
-    "workspaceGenerations": [
-      "v1",
-      "v2"
-    ],
-    "v1Policy": "保持现有配置、数据、流程、登录绑定与项目工具链代际；原 V1 CLI 可继续使用其原运行环境。",
-    "platformPolicy": "V2 应用部署前按平台 capabilities 和配置验证器预检；工具版本不能代替平台实际部署版本。",
-    "backendBuild": "Nest 镜像由开发者电脑上的 Docker 构建；普通 React/Nest 连接开发不要求本地平台或数据库。",
-    "releaseChannels": "latest / stable-v2：V2 正式版；legacy-v1：V1 维护版；alpha：预发布。npm 不允许把 v1/v2 作为标签。"
-  },
-  "upgradeSteps": [
-    "在 Node.js 24 环境安装统一入口：npm install -g openxiangda@2.0.0。",
-    "进入已有项目运行 openxiangda version --json，核对工作区代际、实际引擎和解析来源。",
-    "运行 openxiangda update check 查看本项目更新；需要升级时执行 openxiangda update install --target workspace。",
-    "检查依赖与锁文件差异，刷新本项目 Skill，并完成项目检查、测试环境和真实角色业务验收后再晋级生产。",
-    "V2 能力满足、项目仍在测试阶段且迁移成本可控时，优先建议 V1 项目采用 V2；先完成项目评估、设计确认和迁移验收。"
-  ],
-  "knownLimitations": [
-    "V1 到 V2 首期仅提供本地源码迁移评估，不读取远端业务数据，也不自动迁移应用。",
-    "源码扫描不会证明远端权限、流程和数据完整性；迁移须按项目制定映射、演练和回滚方案。",
-    "内网或离线环境可读取随包说明；联网检查失败时保留当前工具与项目。",
-    "内部支持 Agent 独立交付和验收，不随此 npm 版本自动部署。"
-  ],
-  "issues": [],
-  "sha256": "a6100370946d253328c924c19f6577bac383c4633e3650d69b7ad378486ae880",
-  "url": "https://github.com/1377385356/openxiangda/releases/tag/v2.0.0"
-}

package/releases/2.0.1.json

@@ -1,39 +0,0 @@
-{
-  "schemaVersion": "openxiangda.release-notes/v1",
-  "version": "2.0.1",
-  "title": "OpenXiangda pnpm 工作区识别修复",
-  "status": "reviewed",
-  "summary": "修复独立安装的统一入口进入 pnpm 工作区时无法找到项目 CLI 的问题，继续严格使用该项目锁定的同代引擎。",
-  "newFeatures": [
-    "本次为 2.0.0 的修复发布，没有新增应用能力。"
-  ],
-  "fixes": [
-    "从 pnpm 符号链接指向的真实包目录解析 openxiangda-cli，避免 WORKSPACE_ENGINE_DEPENDENCY_MISSING。"
-  ],
-  "affectedUsers": [
-    "使用全局或独立安装的统一入口维护 pnpm 工作区的开发者。"
-  ],
-  "compatibility": {
-    "node": ">=24",
-    "workspaceGenerations": [
-      "v1",
-      "v2"
-    ],
-    "v1Policy": "V1 应用保持原代际、版本锁定与登录绑定。",
-    "platformPolicy": "没有新增平台能力要求，部署仍执行目标平台预检。",
-    "backendBuild": "Nest 镜像继续由开发者电脑上的 Docker 构建。",
-    "releaseChannels": "latest / stable-v2：V2 正式版；legacy-v1：V1 维护版；alpha：预发布。"
-  },
-  "upgradeSteps": [
-    "在 Node.js 24 环境安装统一入口：npm install -g openxiangda@2.0.1。",
-    "在项目及其子目录运行 openxiangda version --json，核对工作区代际、项目引擎版本和解析来源。",
-    "需要更新 V2 项目依赖时运行 openxiangda update install --target workspace，检查锁文件并完成项目验收。"
-  ],
-  "knownLimitations": [
-    "独立入口更新不会自动升级项目锁定的工具链，也不会迁移 V1 应用。",
-    "已发布的 2.0.0 保持不可变；本修复不代表平台部署或业务验收已完成。"
-  ],
-  "issues": [],
-  "sha256": "6bba13f70a956b58412da587fc9d7b50dd279fea809eae2461dd3515321a83dd",
-  "url": "https://github.com/1377385356/openxiangda/releases/tag/v2.0.1"
-}

package/releases/2.1.0.json

@@ -1,44 +0,0 @@
-{
-  "schemaVersion": "openxiangda.release-notes/v1",
-  "version": "2.1.0",
-  "title": "OpenXiangda 平台托管应用镜像上传",
-  "status": "reviewed",
-  "summary": "应用 Nest 后端在本机构建为 OCI 镜像后，通过平台登录态分片上传。平台负责应用归属校验、镜像存储和运行时拉取，开发者无需取得平台维护者个人镜像仓库的推送权限。",
-  "newFeatures": [
-    "发现并优先使用平台 backendImageUpload 能力，导出 linux/amd64 OCI 镜像并上传有界分片。",
-    "上传前校验本地镜像大小和摘要，复用已完成的镜像回执，并恢复分片传输中断。"
-  ],
-  "fixes": [
-    "启用平台上传后，应用部署不再依赖开发者对平台维护者镜像仓库的推送权限。",
-    "Docker classic image store 不支持 OCI 导出时，返回明确的 builder 配置指引。"
-  ],
-  "affectedUsers": [
-    "声明可选 Nest 后端并通过 CLI 或 MCP 部署的 OpenXiangda 2.0 应用开发者。",
-    "维护共享应用运行时及平台镜像存储的平台管理员。"
-  ],
-  "compatibility": {
-    "node": ">=24",
-    "workspaceGenerations": [
-      "v1",
-      "v2"
-    ],
-    "v1Policy": "V1 应用保持原代际、版本锁定与登录绑定。",
-    "platformPolicy": "平台托管上传需要匹配的后端、Registry 和网关发布，并启用 backendImageUpload；旧平台继续使用既有构建合同。",
-    "backendBuild": "可选 Nest 后端仍在开发者电脑上使用 Docker Buildx 构建，需要支持 OCI exporter 的 builder。",
-    "releaseChannels": "latest / stable-v2：V2 正式版；legacy-v1：V1 维护版；alpha：预发布。"
-  },
-  "upgradeSteps": [
-    "平台管理员先按部署运行手册准备镜像存储与凭据，再部署匹配的后端和网关。",
-    "在 Node.js 24 环境安装统一入口：npm install -g openxiangda@2.1.0。",
-    "更新 V2 项目锁定的工具链并刷新项目资料，核对平台上传能力后运行项目的 openxiangda deploy。"
-  ],
-  "knownLimitations": [
-    "当前仅支持 linux/amd64 单平台 OCI 镜像；默认单镜像上限为 1Gi，由平台配置控制。",
-    "已声明但未启用的平台上传能力会阻止部署，避免回退到个人镜像仓库推送。",
-    "镜像保留与垃圾回收由平台运维单独管理；现有版本仍可能需要历史镜像进行部署或回滚。",
-    "托管镜像开始使用后，后端回滚必须保留 Registry、持久卷、凭据和网关读取路由。"
-  ],
-  "issues": [],
-  "sha256": "d7f6a21ddc37b3d2439350bf17f5f4575192168944dc33efb15460f7d1854aff",
-  "url": "https://github.com/1377385356/openxiangda/releases/tag/v2.1.0"
-}

package/releases/2.1.1.json

@@ -1,48 +0,0 @@
-{
-  "schemaVersion": "openxiangda.release-notes/v1",
-  "version": "2.1.1",
-  "title": "OpenXiangda 应用源码托管",
-  "status": "reviewed",
-  "summary": "私有化平台通过共享 Forgejo 管理应用源码。创建应用时自动初始化私有仓库并推送代码，应用管理员自动获得仓库管理权限，开发者使用长期 Git 凭据。",
-  "newFeatures": [
-    "既有 PLATFORM_ADMIN 自动获得共享 Git 服务全部已有和新建仓库的管理权限。",
-    "source resolve/clone 支持仅凭平台与仓库 URL、使用当前登录态读取源码，不安装或执行应用脚本。",
-    "新增 source status、source setup 和 source push 命令，支持初始化恢复和已有工作区接入。",
-    "创建应用后自动提交并推送初始源码，通过系统凭据管理器保存个人 Git 凭据。",
-    "配套平台支持首次部署前浏览源码及最近提交，并核验部署关联的提交已经推送。"
-  ],
-  "fixes": [
-    "应用源码可直接保留在平台托管仓库中，减少对开发者个人 Git 服务的依赖。",
-    "显式导入保留原 origin 为 external-source，初始化重试保留已有未提交修改，冲突推送不覆盖远端提交。"
-  ],
-  "affectedUsers": [
-    "使用 OpenXiangda 2.0 创建应用或接入平台源码仓库的开发者。",
-    "维护内部私有化平台和应用管理员权限的平台管理员。"
-  ],
-  "compatibility": {
-    "node": ">=24",
-    "workspaceGenerations": [
-      "v1",
-      "v2"
-    ],
-    "v1Policy": "V1 应用保持原代际、版本锁定与登录绑定。",
-    "platformPolicy": "自动源码托管需要匹配的平台后端、管理前端和网关，并配置 OPENXIANGDA_SOURCE_*；未启用的站点保持原创建行为。",
-    "gitCredential": "支持 macOS Keychain、Windows Git Credential Manager，以及 Linux 已安装的 Git Credential Manager 或 libsecret。",
-    "releaseChannels": "latest / stable-v2：V2 正式版；legacy-v1：V1 维护版；alpha：预发布。"
-  },
-  "upgradeSteps": [
-    "平台管理员配置共享 Forgejo、源码入口和专用凭据派生密钥，部署匹配的平台版本；长期保留密钥及 Git 数据。",
-    "在 Node.js 24 环境安装统一入口：npm install -g openxiangda@2.1.1。",
-    "更新 V2 工作区工具链；新应用自动接入，已有应用运行 openxiangda source setup --import 接入。",
-    "完成修改后运行 openxiangda source push -m 描述，再按现有检查和部署流程交付。"
-  ],
-  "knownLimitations": [
-    "当前仅同步应用管理员新增授权，不同步撤销或删除。",
-    "导入推送当前分支，不自动迁移全部历史分支、标签及 LFS 对象。",
-    "制品仍在本地构建；提交存在性核验不构成服务端构建证明。",
-    "新源码功能不依赖 Studio；Studio 旧代码移除属于独立后续工作。"
-  ],
-  "issues": [],
-  "sha256": "f7341eb21e1489c684ee03eed31568063dfad01bfe345f914552bd51b7357f84",
-  "url": "https://github.com/1377385356/openxiangda/releases/tag/v2.1.1"
-}

package/releases/2.10.0.json

@@ -1,42 +0,0 @@
-{
-  "schemaVersion": "openxiangda.release-notes/v1",
-  "version": "2.10.0",
-  "status": "reviewed",
-  "title": "OpenXiangda 2.10.0：通知已读回执基础能力",
-  "summary": "浏览器与 Nest SDK 增加通知投递详情、已读回执缓存和单次刷新接口，应用通过平台消息与投递标识使用钉钉已读查询。",
-  "newFeatures": [
-    "浏览器与 Nest SDK 同步提供 getNotificationMessage、getDingTalkCardReadReceipt 和 refreshDingTalkCardReadReceipt，并公开对应类型。",
-    "配套平台保存卡片查询标识，持久化单投递查询任务，区分已读、未读、未知、不可查询和查询失败。",
-    "配套平台通用化钉钉卡片发送、查询及总预算，并按资源配置准备和投递并发。"
-  ],
-  "fixes": [
-    "配套平台将钉钉 HTTP 403 QpsLimitForApi 识别为可退避重试的限流响应，保留创建请求结果未知时的既有处理边界。"
-  ],
-  "affectedUsers": [
-    "需要查询钉钉卡片已读状态或使用平台通知 SDK 的 OpenXiangda 2.0 应用开发者。"
-  ],
-  "compatibility": {
-    "node": ">=24",
-    "workspaceGenerations": [
-      "v1",
-      "v2"
-    ],
-    "v1Policy": "V1 引擎和已有应用不变。",
-    "platformPolicy": "已读接口需要匹配的平台后端、通知回执追加迁移，以及通知读取和内容读取权限。",
-    "releaseChannels": "latest / stable-v2：V2 正式版；legacy-v1：V1 维护版；alpha：预发布。"
-  },
-  "upgradeSteps": [
-    "先部署匹配的平台后端及追加迁移，按实际钉钉额度配置统一的发送、查询和总预算。",
-    "将应用精确依赖升级到 openxiangda 2.10.0，更新锁文件，并通过标准检查。",
-    "使用平台消息 ID 和投递 ID 查询缓存或请求一次刷新；应用负责选择消息、分组和后续业务轮询。",
-    "在测试环境验证实际投递和已读回执，再使用同一应用候选晋级生产。"
-  ],
-  "knownLimitations": [
-    "一次上游查询针对一个 processQueryKey 下最多 20 名收件人；本版本不提供跨消息批量查询或自动全量轮询。",
-    "历史投递没有保存查询标识时返回不可查询，不能推断为未读；查询遵循钉钉提供方的 24 小时窗口。",
-    "包发布、平台部署与真实消息验收分别记录；本版本不会自动补发历史失败或未知通知。"
-  ],
-  "issues": [],
-  "sha256": "a1be367ab9c5de6b66ec8dd02724af71611183d99ddb9dae861e6253c58875df",
-  "url": "https://github.com/1377385356/openxiangda/releases/tag/v2.10.0"
-}

package/releases/2.11.0.json

@@ -1,41 +0,0 @@
-{
-  "schemaVersion": "openxiangda.release-notes/v1",
-  "version": "2.11.0",
-  "status": "reviewed",
-  "title": "工作区登录隔离与工具链升级指引",
-  "summary": "平台开发者会话按工作区隔离，CLI、MCP 与自动刷新共用本地会话；补齐 V1 采用 V2 的建议及 CLI、Skill、MCP 升级步骤。本版也包含主线已审查的数据事件捕获策略。",
-  "newFeatures": [
-    "login --cwd 与 auth --cwd 明确选择工作区；创建应用前可在目标目录登录，初始化保留受管会话文件。",
-    "V1 入口展示 V2 采用建议及迁移评估指引，文档说明 CLI、Skill 与 MCP 的版本刷新。",
-    "应用可用 events.capturePolicies 按资源声明 all 或 subscribed，编译为不可变的操作事件捕获计划。"
-  ],
-  "fixes": [
-    "默认登录态改为工作区 .openxiangda/session.json，停止读取旧全局会话；本地文件优先于 CI 环境凭据。",
-    "刷新、退出与 MCP 授权检查固定工作区来源，嵌套应用不会继承父应用账号，损坏或平台不符的文件不会换用其他身份。",
-    "登录文件使用原子写入、0600 权限及自动 Git 忽略，初始化不替换凭据内容。"
-  ],
-  "affectedUsers": [
-    "使用 CLI、MCP 或多个应用工作区的开发者。",
-    "从 V1 评估 V2 的用户，以及需要减少无消费者事件写入的 Native 应用开发者。"
-  ],
-  "compatibility": {
-    "node": ">=24",
-    "workspacePolicy": "升级后在每个工作区重新登录；不自动复制旧全局或其他工作区的令牌。",
-    "platformPolicy": "平台登录与授权协议不变；远端检查和部署需要平台的 Native configurationCompatibility 校验器摘要与本版工具链匹配。采用 events.capturePolicies 还需要 events.capture-policy 1.0.0。"
-  },
-  "upgradeSteps": [
-    "使用项目包管理器更新并锁定 OpenXiangda 依赖，刷新 Skill 并重启 MCP 客户端。",
-    "远端检查和部署前确认工具链与平台为配套版本；出现 OPENXIANGDA_CONFIGURATION_VALIDATOR_MISMATCH 时先升级不匹配的一端，保留当前源码和候选。",
-    "已有项目在根目录运行 `openxiangda login --base-url <platform>`，再运行 `openxiangda auth status` 检查授权。",
-    "新项目先运行 `openxiangda login --cwd my-app --base-url <platform>`，然后 `openxiangda create my-app --base-url <platform>`。",
-    "CI 仅在没有本地会话文件时使用成对 OPENXIANGDA_BASE_URL 与 OPENXIANGDA_TOKEN。",
-    "采用事件捕获策略前先升级支持该能力的平台，确认事件历史要求，并完成测试环境验收后晋级同一应用版本。"
-  ],
-  "knownLimitations": [
-    "钉钉支持的 DWS 授权仍由 DWS 自己管理，不与平台会话混用。",
-    "V1 业务不会自动迁移到 V2。subscribed 不保留未声明操作的历史，恢复 all 不能补造历史事件。"
-  ],
-  "issues": [],
-  "sha256": "a6383deacc92dc3e058909c7db537e1a1bf29fc00fbb04345225c1f4f70f23c3",
-  "url": "https://github.com/1377385356/openxiangda/releases/tag/v2.11.0"
-}

package/releases/2.12.0.json

@@ -1,38 +0,0 @@
-{
-  "schemaVersion": "openxiangda.release-notes/v1",
-  "version": "2.12.0",
-  "status": "reviewed",
-  "title": "OpenXiangda 2.12.0：平台原生数据自动化",
-  "summary": "数据事件可直接触发平台 Native 数据动作，省去应用 HTTP 接收链路；发布计划固定捕获字段与目标资源，业务效果与执行结果原子提交。",
-  "newFeatures": [
-    "events.subscriptions.execution 支持 native-data v1 声明式 create/update/delete，无需 Nest 应用后端。",
-    "共享编译器自动派生事件捕获字段及目标模型摘要，新增 events.native-data-actions 能力检查。"
-  ],
-  "fixes": [
-    "保留旧 Webhook 消费者与处理器契约，运维查询区分 Native 执行计划。",
-    "包含已合并的后台入口状态修复与 PC 优先开发引导，菜单缺失、无权限及未知地址分别展示。"
-  ],
-  "affectedUsers": [
-    "使用平台数据自动化和 OpenXiangda V2 事件订阅的应用。",
-    "平台维护者必须同步升级匹配的共享 Native 校验器；V1 业务引擎保持独立。"
-  ],
-  "upgradeSteps": [
-    "先部署支持 events.native-data-actions 1.0.0、同版共享 Native 校验器和 SQL 扩展迁移的平台后端。",
-    "将应用依赖升级到 openxiangda 2.12.0 并按普通测试发布、验收和生产晋级流程交付。",
-    "简单数据动作按 execution 显式启用，外部 Webhook 与自定义代码继续使用现有处理器。"
-  ],
-  "knownLimitations": [
-    "首版 Native 动作仅支持明确源资源的数据事件，最多 16 个操作、每个 32 字段及 64 KiB 输入，不执行脚本、SQL 或 HTTP。",
-    "不兼容的目标模型变化会停止旧动作并报告错误；回退平台前需停用并排空 Native 动作。",
-    "按需事件不能重放从未捕获的历史；权限过滤的轻量操作历史由配套平台提供。",
-    "发行包验证不能代替客户环境的实际部署及容量测试。"
-  ],
-  "compatibility": {
-    "node": ">=24",
-    "platform": "events.native-data-actions 1.0.0，匹配共享 Native 校验器与 Native action SQL 迁移",
-    "v1": "独立 legacy-v1 引擎，不引入兼容桥"
-  },
-  "issues": [],
-  "sha256": "ae2cf493d03c916d22f093d366ac8c7f9d8cf0d0cbc71d6ab5db99fc34617738",
-  "url": "https://github.com/1377385356/openxiangda/releases/tag/v2.12.0"
-}

package/releases/2.13.0.json

@@ -1,41 +0,0 @@
-{
-  "schemaVersion": "openxiangda.release-notes/v1",
-  "version": "2.13.0",
-  "status": "reviewed",
-  "title": "OpenXiangda 2.13.0：原版 OpenDesign 设计体验",
-  "summary": "通过轻量入口直接使用 OpenDesign 原版桌面与完整 CLI，默认先设计和验证原型再实现应用；设计资源进入 AppSpec 评审摘要，PC 与移动字段支持应用作用域内的视觉设计。",
-  "newFeatures": [
-    "design open/status/cli 发现原版安装、连接原版动态服务并透传完整 CLI 和原版 MCP；保留参数、标准输入输出、退出码与取消。",
-    "AppSpec assets 固定设计系统和原型依赖，评审与原测试提交的资源摘要可复核。",
-    "PC Provider 接收应用主题，弹层、消息及移动字段继承应用设计作用域。",
-    "同版 Skill、CLI docs 和平台 MCP 提供原版开发流程及精选 OpenDesign 离线参考。"
-  ],
-  "fixes": [
-    "替换与用户目标冲突的默认外观和固定设备限制，复用字段行为并允许完善整体设计。",
-    "防止原生 --cwd、--json 和 MCP 参数被享搭分发层截获，避免误运行系统同名 od。"
-  ],
-  "affectedUsers": [
-    "使用 OpenXiangda V2 开发新界面、改版和原型的应用开发者。",
-    "采用 AppSpec 原型资源评审或应用主题的 V2 工作区。"
-  ],
-  "upgradeSteps": [
-    "将应用锁定的 openxiangda 升级到 2.13.0，并刷新当前版本 Skill 和工作区指引。",
-    "从 OpenDesign 官方发行页安装原版，运行 openxiangda design open；在原版中选择已有本地 Agent 或配置所需提供商。",
-    "使用 design cli --help 查看完整原生命令；将实际采用的原型及依赖交接到 AppSpec assets 后验证业务实现。"
-  ],
-  "knownLimitations": [
-    "macOS 桌面发现针对官方 arm64 0.22.2 验证；其他平台和源码安装使用绝对路径 OPENXIANGDA_OPENDESIGN_CLI 或 OD_BIN，未声称完成各平台桌面验收。",
-    "npm 包不包含 OpenDesign 桌面二进制；原版更新、模型登录、云媒体和连接器按原版配置与权限使用。",
-    "原版桌面导入等受授权上下文保护的操作可能需要桌面选择目录；桥接不伪造 token。",
-    "设计资源检查最多 128 文件、单文件 2 MiB、总计 8 MiB；大媒体留在原版项目并导出有界审阅产物。",
-    "原型与包验证不代表生产应用已经部署或完成实际业务验收。"
-  ],
-  "compatibility": {
-    "node": ">=24",
-    "platform": "本轮不增加平台后端接口或数据库迁移要求",
-    "v1": "保持独立 legacy-v1 引擎"
-  },
-  "issues": [],
-  "sha256": "bd50c7e044926d5d7d4f44bbe17827c2f1758f6b6e9ae258d8eb27594379ee98",
-  "url": "https://github.com/1377385356/openxiangda/releases/tag/v2.13.0"
-}

package/releases/2.13.1.json

@@ -1,33 +0,0 @@
-{
-  "schemaVersion": "openxiangda.release-notes/v1",
-  "version": "2.13.1",
-  "status": "reviewed",
-  "title": "OpenXiangda 2.13.1：管理后台优先的应用结构规范",
-  "summary": "明确标准管理后台是 OpenXiangda 2.0 应用骨架，并规定 OpenDesign 在后台与用户端 PC/移动端的页面归属和交接边界。",
-  "newFeatures": [
-    "Skill、中文前端资料和 OpenDesign 工作流新增后台骨架优先规则。",
-    "新应用模板 AGENTS 明确后台、用户端 PC 和移动端的分层开发与验收入口。"
-  ],
-  "fixes": [
-    "禁止使用单页 HTML、iframe 或独立假后台替代标准管理后台。"
-  ],
-  "affectedUsers": [
-    "使用 OpenXiangda 2.0 创建应用、设计页面或维护应用模板的 AI 和开发者。"
-  ],
-  "upgradeSteps": [
-    "升级 openxiangda 与 openxiangda-cli 到 2.13.1。",
-    "刷新项目 Skill，并按后台骨架优先规则重新检查页面归属和发布验收。"
-  ],
-  "knownLimitations": [
-    "本版本只更新规范、模板和发布资料，不自动改造已有应用页面。",
-    "标准审批、通知和具体业务流程仍需按应用需求声明和验收。"
-  ],
-  "compatibility": {
-    "node": ">=24",
-    "platform": "本轮不增加平台后端接口或数据库迁移要求",
-    "v1": "保持独立 legacy-v1 引擎"
-  },
-  "issues": [],
-  "sha256": "3be803becc123e1cfafd76b7e217c660a78d2e62f9d3cc7092c33872a1bf07b6",
-  "url": "https://github.com/1377385356/openxiangda/releases/tag/v2.13.1"
-}

package/releases/2.13.2.json

@@ -1,31 +0,0 @@
-{
-  "schemaVersion": "openxiangda.release-notes/v1",
-  "version": "2.13.2",
-  "status": "reviewed",
-  "title": "OpenXiangda 2.13.2：管理后台优先规范同步",
-  "summary": "将标准管理后台优先和 OpenDesign 页面归属规则同步到统一包、CLI 与 Skill 包，确保新应用开发遵循同一应用结构。",
-  "newFeatures": [
-    "统一包、CLI 和 Skill 包同步应用骨架与 OpenDesign 页面边界规范。"
-  ],
-  "fixes": [
-    "防止用户端原型、单页 HTML 或 iframe 被误当作管理后台。"
-  ],
-  "affectedUsers": [
-    "使用 OpenXiangda 2.0 创建应用和执行 AI 辅助开发的开发者。"
-  ],
-  "upgradeSteps": [
-    "升级 openxiangda、openxiangda-cli 和 openxiangda-skill-kit 到本版本。",
-    "刷新项目 Skill 后重新执行应用结构和入口验收。"
-  ],
-  "knownLimitations": [
-    "本版本更新规范和模板，不自动改造已有应用。"
-  ],
-  "compatibility": {
-    "node": ">=24",
-    "platform": "本轮不增加平台后端接口或数据库迁移要求",
-    "v1": "保持独立 legacy-v1 引擎"
-  },
-  "issues": [],
-  "sha256": "8925c3252c55e2bec1d1cdf755151777650b3ac6f8b7c82576760761dca6a786",
-  "url": "https://github.com/1377385356/openxiangda/releases/tag/v2.13.2"
-}