openxiangda 1.0.212 → 1.0.214

package/README.md

@@ -106,7 +106,7 @@ React SPA workspaces publish their frontend with `openxiangda runtime deploy`. E
 
 Parallel tasks develop and test in isolated worktrees, but feature worktrees do not publish. After approved commits are merged and pushed, `sdd bundle <release-change> --changes ...` unions their exact structured scope and preserves the source changes' common Git baseline instead of adopting the post-merge `HEAD`. Old imported changes that predate source-base metadata must pass `--source-base-ref <commit>` explicitly. Commit/push the bundle, then run `release publish --change <release-change> --profile <name>` from a clean local main/master whose commit exactly equals the authoritative remote tip. It verifies without rewriting reviewed SDD files, waits for the app lease, freezes one authoritative App capture, executes exact Form/Backend/Runtime staged steps, atomically finalizes the Root App release, and records a resumable local execution journal. Runtime checks use the narrow head endpoint; immutable Git-base artifact hashes are reused across plans.
 
-Because promotion starts from an already-pushed authoritative mainline commit, `openxiangda release integration-status --profile <name>` should pass immediately after activation. Run it and `release end`; there is no post-release merge step.
+Because promotion starts from an already-pushed authoritative mainline commit, `openxiangda release integration-status --change <change> --profile <name>` should pass immediately after activation. After a managed ship has ended, `--change` recovers lineage directly from the private `ship.json` or follows its production/preproduction deployment IDs to the matching `execution.json`; a recovery failure names the missing file or field. Run it and `release end`; there is no post-release merge step.
 
 `openxiangda task status --change <id>` is the compact, read-only answer to
 “现在到哪一步”：it combines SDD、TaskResult、IntegrationBundle、execution
@@ -502,7 +502,7 @@ const PublicAccessError = ({ error }: { error: { message?: string } }) => (
 
 多表只读查询和固定口径统计优先声明 `src/resources/data-views/*.json` 数据视图，而不是在页面里手写多次单表查询再拼数据。默认 `storageMode: "materialized"` 会创建 PostgreSQL materialized view，适合读多写少和可接受刷新延迟的列表/报表；`storageMode: "live"` 每次查询实时编译逻辑视图，适合强实时但数据量可控的复杂查询。`viewType: "aggregate"` 是统计聚合视图，适合按客户、状态、月份等维度聚合 count/sum/avg/min/max。发布时 CLI 会把 `formCode` 解析为当前 profile 的 `formUuid`；页面通过 `sdk.dataView.query(code, params)` 查询行级视图，通过 `sdk.dataView.stats(code, params)` 查询聚合视图，也可以用 `sdk.dataSource.run()` 路由 `dataView.query` / `dataView.stats`。materialized 模式应为常用筛选、排序、统计维度和时间桶声明 `indexes`，并确认用户能接受的刷新延迟；live 模式忽略 `indexes`，不需要刷新。
 
-后端业务逻辑优先声明为 App Function：源码放在 `src/functions/<functionCode>/index.ts`，资源 manifest 放在 `src/resources/functions/<functionCode>.json`。函数运行在 trusted_node 中，通过 `ctx.form.queryOne/queryMany/getById/createOne/updateOne/updateById`、`ctx.dataView`、`ctx.connector`、`ctx.notification`、`ctx.organization`、`ctx.platform.roles`、`ctx.platform.api` 等受控 API 访问平台能力；自动化、流程和运行时接口都可以调用同一个 function。角色查询和角色成员维护优先使用 `ctx.platform.roles.list/findByCode/addUsers/removeUser`，底层 `ctx.platform.api` 返回 HTTP 包装和平台 envelope，需要业务代码自行解包。运行时页面调用会在 `ctx.operator`、`ctx.currentUser`、`ctx.permissions` 中注入可信的 `roleCodes`、`currentRoleCode`、`hasFullAccess`、`isAppAdmin`、`isPlatformAdmin`，敏感动作必须读取这些服务端上下文做授权，不要信任页面 input 里传入的角色字段。`ctx.form.createOne/updateOne/updateById` 是后端受控写入，授权边界是函数 manifest 的 `resources.forms` 绑定和函数调用授权，不是页面用户对目标表单的直接提交入口；报名、签到、福利选择等内部多表写入应走 App Function，不要为了写内部表单给普通用户开放原始 submit 权限。JS_CODE V2 仍兼容，但新逻辑建议写成 function，再由 `function_call` 节点、`sdk.function.invoke(code, { input })` 或 `/:appType/v1/functions/:code/invoke.json` 调用。直接运行时接口默认要求调用者具备应用自动化管理权限；普通页面调用必须在函数 `definitionJson.runtimeInvoke.audience` 声明 `authenticated`、`page_permission_group`、`app_roles` 或 `scope_policy`，`roleCodes` 只用于当前应用角色精确匹配，不支持 `"*"` / `"all-app-roles"`。自动化/流程内部调用走服务端受控上下文。内部业务表单需要关闭原始写入接口时，在表单 settings 中设置 `runtimeWrite.mode="function_only"`。
+后端业务逻辑优先声明为 App Function：源码放在 `src/functions/<functionCode>/index.ts`，资源 manifest 放在 `src/resources/functions/<functionCode>.json`。函数运行在 trusted_node 中，通过 `ctx.form.queryOne/queryMany/getById/createOne/updateOne/updateById`、`ctx.process.startFromExistingInstance/resolveCapabilities/resubmitTask/withdraw/transferTask`、`ctx.dataView`、`ctx.connector`、`ctx.notification`、`ctx.organization`、`ctx.platform.roles`、`ctx.platform.api` 等受控 API 访问平台能力；自动化、流程和运行时接口都可以调用同一个 function。`ctx.process` 复用正式工作流服务，以真实运行时 operator 执行，并严格限制在当前应用及 Function `resources.forms` 已绑定的流程表单；流程实例、任务授权、操作日志、事件和 replay 语义与 PageSdk 后端接口一致。角色查询和角色成员维护优先使用 `ctx.platform.roles.list/findByCode/addUsers/removeUser`，底层 `ctx.platform.api` 返回 HTTP 包装和平台 envelope，需要业务代码自行解包。运行时页面调用会在 `ctx.operator`、`ctx.currentUser`、`ctx.permissions` 中注入可信的 `roleCodes`、`currentRoleCode`、`hasFullAccess`、`isAppAdmin`、`isPlatformAdmin`，敏感动作必须读取这些服务端上下文做授权，不要信任页面 input 里传入的角色字段。`ctx.form.createOne/updateOne/updateById` 是后端受控写入，授权边界是函数 manifest 的 `resources.forms` 绑定和函数调用授权，不是页面用户对目标表单的直接提交入口；报名、签到、福利选择等内部多表写入应走 App Function，不要为了写内部表单给普通用户开放原始 submit 权限。JS_CODE V2 仍兼容，但新逻辑建议写成 function，再由 `function_call` 节点、`sdk.function.invoke(code, { input })` 或 `/:appType/v1/functions/:code/invoke.json` 调用。直接运行时接口默认要求调用者具备应用自动化管理权限；普通页面调用必须在函数 `definitionJson.runtimeInvoke.audience` 声明 `authenticated`、`page_permission_group`、`app_roles` 或 `scope_policy`，`roleCodes` 只用于当前应用角色精确匹配，不支持 `"*"` / `"all-app-roles"`。自动化/流程内部调用走服务端受控上下文。内部业务表单需要关闭原始写入接口时，在表单 settings 中设置 `runtimeWrite.mode="function_only"`。
 
 App Function 访问第三方凭据时使用 `app_function_secrets_v1`：manifest 顶层只声明 `secretRefs: [{ "name": "dingtalk_org_app_key", "required": true }]`，同时使用 `definitionJson.version="function_v2"`、`runtimeContractVersion="trusted_node_v2"`；源码通过 `await ctx.secrets.get(name)` 解析，并通过 `ctx.utils.http` 访问受控公网 HTTPS（该桥接不会携带平台 Runtime token）。值只能经 `openxiangda secret create|rotate --value-stdin --change <id> --profile <name>` 或隐藏 TTY 输入，禁止进入 Git、manifest、源码、构建产物、plan、日志或异常。带 `secretRefs` 的 Function 必须走 `backend_release_v2`；需要整应用原子发布时先执行 `resource publish function --only <code> --stage-only`，再把返回的真实 `stagedResource` 交给 `release app-finalize --staged-resources-json ...` 完成 `atomic_staged_children_v2`。默认直接激活的 Backend Release 只返回 `activeResource`，不会伪装成 staged；旧平台 capability 不完整时 CLI 会失败关闭，绝不忽略绑定。
 

package/lib/cli.js

@@ -1484,6 +1484,139 @@ function readReleaseRecoveryContext(target, changeId, deploymentId) {
   return { execution, context };
 }
 
+function releaseSourceRevisionFromExecution(execution) {
+  return (
+    execution?.releaseSourceRevision ||
+    execution?.releaseContext?.releaseSourceRevision ||
+    null
+  );
+}
+
+function privateReleasePathLabel(file) {
+  return path.relative(process.cwd(), file).replace(/\\/g, '/');
+}
+
+function readReleaseLineageRecovery(changeId, deploymentId) {
+  if (!changeId) {
+    return {
+      sourceRevision: null,
+      source: null,
+      checked: [],
+    };
+  }
+
+  const checked = [];
+  const recovered = [];
+  const inspectedExecutions = new Set();
+  const inspectExecution = (candidateDeploymentId, label) => {
+    const normalizedDeploymentId = String(candidateDeploymentId || '').trim();
+    const key = normalizedDeploymentId || '<root>';
+    if (inspectedExecutions.has(key)) return;
+    inspectedExecutions.add(key);
+    const file = releaseExecutionFile(
+      changeId,
+      normalizedDeploymentId || undefined
+    );
+    const exists = fs.existsSync(file);
+    const execution = exists
+      ? readReleaseExecution(changeId, normalizedDeploymentId || undefined)
+      : null;
+    const sourceRevision = releaseSourceRevisionFromExecution(execution);
+    const changeMatches =
+      !execution?.changeId || execution.changeId === changeId;
+    checked.push({
+      label,
+      file: privateReleasePathLabel(file),
+      exists,
+      field:
+        sourceRevision && changeMatches
+          ? 'releaseSourceRevision'
+          : sourceRevision
+            ? `changeId 不匹配 (${execution.changeId})`
+            : '缺少 releaseContext.releaseSourceRevision/releaseSourceRevision',
+    });
+    if (sourceRevision && changeMatches) {
+      recovered.push({
+        sourceRevision,
+        source: privateReleasePathLabel(file),
+      });
+    }
+  };
+
+  const shipFile = managedShipFile(changeId);
+  const shipExists = fs.existsSync(shipFile);
+  const ship = shipExists ? readManagedShip(changeId) : null;
+  const shipSourceRevision = ship?.sourceRevision || null;
+  checked.push({
+    label: 'managed ship journal',
+    file: privateReleasePathLabel(shipFile),
+    exists: shipExists,
+    field: shipSourceRevision ? 'sourceRevision' : '缺少 sourceRevision',
+  });
+  if (shipSourceRevision) {
+    return {
+      sourceRevision: shipSourceRevision,
+      source: `${privateReleasePathLabel(shipFile)}#sourceRevision`,
+      checked,
+    };
+  }
+
+  if (deploymentId) {
+    inspectExecution(deploymentId, 'explicit deployment execution');
+  }
+  for (const [label, candidateDeploymentId] of [
+    ['production deployment execution', ship?.productionDeploymentId],
+    ['preproduction deployment execution', ship?.preproductionDeploymentId],
+  ]) {
+    if (candidateDeploymentId) {
+      inspectExecution(candidateDeploymentId, label);
+    }
+  }
+  inspectExecution(null, 'root release execution');
+
+  const releaseDir = releaseExecutionDir(changeId);
+  if (fs.existsSync(releaseDir)) {
+    for (const entry of fs
+      .readdirSync(releaseDir, { withFileTypes: true })
+      .filter(item => item.isDirectory())
+      .sort((left, right) => left.name.localeCompare(right.name))) {
+      inspectExecution(entry.name, 'discovered deployment execution');
+    }
+  }
+
+  const distinct = new Map();
+  for (const item of recovered) {
+    const fingerprint = sha256Canonical({
+      repo:
+        item.sourceRevision?.repo ||
+        item.sourceRevision?.repositoryId ||
+        null,
+      baseCommit:
+        item.sourceRevision?.baseCommit ||
+        item.sourceRevision?.commit ||
+        null,
+      treeHash: item.sourceRevision?.treeHash || null,
+      remoteName: item.sourceRevision?.remoteName || null,
+      remoteUrlHash: item.sourceRevision?.remoteUrlHash || null,
+      mainBranch: item.sourceRevision?.mainBranch || null,
+    });
+    if (!distinct.has(fingerprint)) distinct.set(fingerprint, item);
+  }
+  if (distinct.size > 1) {
+    fail(
+      `RELEASE_SOURCE_LINEAGE_CONFLICT: change ${changeId} 的私有 deployment execution 日志包含互不一致的 releaseSourceRevision: ${Array.from(
+        distinct.values(),
+        item => item.source
+      ).join(', ')}`
+    );
+  }
+  return {
+    sourceRevision: recovered[0]?.sourceRevision || null,
+    source: recovered[0]?.source || null,
+    checked,
+  };
+}
+
 function remoteLeaseOwnedByRecovery(remote, recovery) {
   if (!remote?.active || !recovery) return false;
   const holder = remote.holder;
@@ -3520,13 +3653,21 @@ async function runApplicationShipCommand(
     );
   }
 
+  const promotionStartedAt = new Date().toISOString();
   writeManagedShip(changeId, {
     status: 'confirmed_for_production',
     productionConfirmation: {
+      status: 'confirmed',
       confirmedAt,
       profile: preproduction.profileName,
       acceptanceNote: acceptanceNote || null,
     },
+    productionPromotion: {
+      status: 'running',
+      startedAt: promotionStartedAt,
+      environment: production.targetName,
+      deploymentId: null,
+    },
     manualAcceptance,
     preproductionStatus: preproductionDeployment.status,
   });
@@ -3553,6 +3694,15 @@ async function runApplicationShipCommand(
       manifestReplacement,
       baselineAdoption,
       failure,
+      productionPromotion: {
+        status: 'failed',
+        startedAt: promotionStartedAt,
+        failedAt: failure.recordedAt,
+        environment: production.targetName,
+        deploymentId: failure.deploymentId,
+        deploymentStatus: failure.deploymentStatus,
+        failure,
+      },
       nextCommand: buildManagedShipCommand(
         changeId,
         preproduction.profileName,
@@ -3562,6 +3712,7 @@ async function runApplicationShipCommand(
     });
     throw error;
   }
+  const completedAt = new Date().toISOString();
   const saved = writeManagedShip(changeId, {
     status: 'completed',
     productionEnvironment: production.targetName,
@@ -3570,7 +3721,15 @@ async function runApplicationShipCommand(
       promoted.deployment.targetAppReleaseId || null,
     productionStatus: promoted.deployment.status,
     failure: null,
-    completedAt: new Date().toISOString(),
+    completedAt,
+    productionPromotion: {
+      status: 'completed',
+      startedAt: promotionStartedAt,
+      completedAt,
+      environment: production.targetName,
+      deploymentId: promoted.deployment.id,
+      deploymentStatus: promoted.deployment.status,
+    },
   });
   return {
     phase: 'production',
@@ -3786,7 +3945,7 @@ async function release(args) {
       '  openxiangda release begin --change <id> --profile <name>',
       '  openxiangda resource publish function --only <code> --change <id> --profile <name>',
       '  openxiangda runtime deploy --change <id> --profile <name>',
-      '  openxiangda release integration-status --profile <name>',
+      '  openxiangda release integration-status --change <id> --profile <name>',
       '  openxiangda release end --profile <name>',
       '  openxiangda release backend-head --profile <name>',
       '  openxiangda release backend-diff <fromReleaseId> <toReleaseId> --profile <name>',
@@ -3805,6 +3964,7 @@ async function release(args) {
       '  - 默认 TTL 为 120 秒；活动发布每 30 秒心跳并在到期前续租，客户端退出后孤儿租约最多阻塞约 2 分钟。',
       '  - begin 仅接受 clean 且与权威远端默认 main/master 完全一致的 HEAD；feature branch 先合并并 push，再由主分支一次发布。',
       '  - 因发布源已在远端主线，成功激活后 integration-status 会立即通过，end 不再等待补合并。',
+      '  - 发布已结束时，integration-status --change 会先从 ship.json 恢复托管 candidate 血缘，再自动查找其 production/preproduction deployment execution 日志；恢复失败会列出实际缺失的文件或字段。',
       '  - integration-status --check 可作为 CI 门禁；尚未回合时返回非零。',
       '  - 主线目标只能来自权威 Git remote 的实时默认 main/master；参数和环境变量不能改写。',
       '  - 租约过期也会保留待回合证据；完成 merge/push 后仍可执行 end 清理。',
@@ -3953,23 +4113,45 @@ async function release(args) {
       access: 'reconciliation-read',
     });
     const changeId = positional[0] || readStringFlag(flags, 'change');
-    const recovered = readReleaseRecoveryContext(
-      target,
-      changeId,
-      readStringFlag(flags, 'deployment-id')
-    );
+    const recovered = baseline?.releaseSourceRevision
+      ? {
+          sourceRevision: null,
+          source: null,
+          checked: [],
+        }
+      : readReleaseLineageRecovery(
+          changeId,
+          readStringFlag(flags, 'deployment-id')
+        );
     const sourceRevision =
       baseline?.releaseSourceRevision ||
-      recovered?.context?.releaseSourceRevision;
+      recovered.sourceRevision;
     if (!sourceRevision) {
+      if (changeId) {
+        const checked = recovered.checked
+          .map(item =>
+            item.exists
+              ? `${item.file} (${item.field})`
+              : `${item.file} (文件不存在)`
+          )
+          .join('; ');
+        fail(
+          `RELEASE_SOURCE_LINEAGE_REQUIRED: change ${changeId} 的私有发布记录无法恢复 releaseSourceRevision；已检查: ${checked}`
+        );
+      }
       fail(
         'RELEASE_SOURCE_LINEAGE_REQUIRED: 当前 release 没有冻结的 releaseSourceRevision；发布已结束时请同时传入 --change <id>，以便从私有执行日志恢复主线证据'
       );
     }
-    const result = inspectReleaseSourceIntegration(
-      sourceRevision,
-      { cwd: process.cwd() }
-    );
+    const result = {
+      ...inspectReleaseSourceIntegration(
+        sourceRevision,
+        { cwd: process.cwd() }
+      ),
+      lineageSource: baseline?.releaseSourceRevision
+        ? '.openxiangda/state.json#promotion.changeBaseline.releaseSourceRevision'
+        : recovered.source,
+    };
     if (flags.check && !result.integrated) {
       assertReleaseSourceIntegrated(sourceRevision, { cwd: process.cwd() });
     }

package/openxiangda-skills/SKILL.md

@@ -120,7 +120,7 @@ Exact `resourceSelectors` are authoritative for supported configuration resource
 
 `release begin --change` freezes a clean committed `HEAD` only when the current branch is the authoritative default `main`/`master` and its commit exactly equals the live remote tip. Before any live write, the CLI preflights the complete target set and rejects source changes during the release. A feature worktree or unpushed main receives `RELEASE_SOURCE_MAINLINE_REQUIRED` / `RELEASE_SOURCE_MAINLINE_NOT_PUSHED`; merge, test, push, and start the one mainline release instead of forcing it. Optional `.git` remote suffix differences and other recorded repository aliases are accepted only when the frozen source-base ID intersects `releaseSourceRevision.repoAliases`; Backend, Workflow, and Root App Release writes then use the frozen canonical ID. Genuinely different identity sets still fail closed before prepare.
 
-Because promotion begins from the already-pushed authoritative mainline, `release integration-status` should pass immediately after activation. Run it, then `release end`; no post-release branch merge is required.
+Because promotion begins from the already-pushed authoritative mainline, `release integration-status --change <change>` should pass immediately after activation. For a completed managed ship it recovers lineage from private `ship.json`, then from the referenced production/preproduction deployment execution journal; a failure identifies the missing file or field. Run it, then `release end`; no post-release branch merge is required.
 
 `runtime deploy` separately freezes the clean committed `HEAD` as `sourceRevision` together with the current active Runtime parent before any build or upload. Any deploy whose source does not descend from the online Runtime fails with `RUNTIME_SOURCE_BASE_DIVERGED`, including `--no-activate`; this prevents staging an old preview for later activation. `--no-build` does not bypass this guard. Only an intentional audited rollback may use `--allow-runtime-rollback --reason "<at least 8 characters>"`, and that flag never permits dirty or non-Git input. SDD evidence under `openspec/` and generated/state paths do not make Runtime source dirty.
 

package/openxiangda-skills/references/connector-resources.md

@@ -32,7 +32,7 @@ Notification manifests live under `src/resources/notifications/` and contain `te
 
 Data view manifests live under `src/resources/data-views/` and define read-only joined or aggregate query resources. Use `storageMode: "materialized"` for refreshed lists/reports where lag is acceptable, and `storageMode: "live"` for bounded real-time query shapes. Use row views with `sdk.dataView.query` and aggregate views with `sdk.dataView.stats`. Before generating one, confirm freshness tolerance, query bounds, and indexes for materialized filters/sort fields/dimensions/date buckets. Do not use them for single-form CRUD, simple linkedForm selects, writes, write-back, or ad-hoc BI. See `data-views.md` before generating one.
 
-App Function manifests live under `src/resources/functions/`, with source in `src/functions/<functionCode>/index.ts`. Use them for reusable server-side logic that pages, automations, and workflows can share through `sdk.function.invoke` or `function_call` nodes. App Functions expose controlled runtime helpers such as `ctx.resources`, `ctx.form.queryOne/queryMany/getById/createOne/updateOne/updateById`, `ctx.dataView`, `ctx.connector`, `ctx.notification`, `ctx.organization`, `ctx.platform.roles`, and `ctx.platform.api`; they do not expose raw SQL or Redis in the current MVP. Use `ctx.platform.roles.list/findByCode/addUsers/removeUser` for app role lookup and membership changes; raw `ctx.platform.api` returns an HTTP response plus platform envelope. Runtime page invocations also expose trusted role context on `ctx.operator.roleCodes`, `ctx.operator.currentRoleCode`, `ctx.operator.hasFullAccess`, `ctx.currentUser`, and `ctx.permissions`; use that context for server-side authorization, and never trust page-submitted role codes for sensitive actions. Page-call grants should use `definitionJson.runtimeInvoke.audience` (`authenticated`, `page_permission_group`, `app_roles`, or `scope_policy`); `roleCodes` is only for current app-role grants and does not support `"*"` or `"all-app-roles"`. App Function form writes are trusted backend writes governed by declared `resources.forms` and function invocation authorization, not by direct page-user submit access to the target form. For internal function-only forms, publish form settings with `runtimeWrite.mode="function_only"` so raw write endpoints are closed. App Function organization writes require `app:organization:manage` on the real operator/audit actor. Use JS_CODE V2 only for node-local workflow/automation scripts.
+App Function manifests live under `src/resources/functions/`, with source in `src/functions/<functionCode>/index.ts`. Use them for reusable server-side logic that pages, automations, and workflows can share through `sdk.function.invoke` or `function_call` nodes. App Functions expose controlled runtime helpers such as `ctx.resources`, `ctx.form.queryOne/queryMany/getById/createOne/updateOne/updateById`, `ctx.process.startFromExistingInstance/resolveCapabilities/resubmitTask/withdraw/transferTask`, `ctx.dataView`, `ctx.connector`, `ctx.notification`, `ctx.organization`, `ctx.platform.roles`, and `ctx.platform.api`; they do not expose raw SQL or Redis in the current MVP. `ctx.process` uses the official workflow services with the real operator and is restricted to the current app plus Function `resources.forms` bindings. Use `ctx.platform.roles.list/findByCode/addUsers/removeUser` for app role lookup and membership changes; raw `ctx.platform.api` returns an HTTP response plus platform envelope. Runtime page invocations also expose trusted role context on `ctx.operator.roleCodes`, `ctx.operator.currentRoleCode`, `ctx.operator.hasFullAccess`, `ctx.currentUser`, and `ctx.permissions`; use that context for server-side authorization, and never trust page-submitted role codes for sensitive actions. Page-call grants should use `definitionJson.runtimeInvoke.audience` (`authenticated`, `page_permission_group`, `app_roles`, or `scope_policy`); `roleCodes` is only for current app-role grants and does not support `"*"` or `"all-app-roles"`. App Function form writes are trusted backend writes governed by declared `resources.forms` and function invocation authorization, not by direct page-user submit access to the target form. For internal function-only forms, publish form settings with `runtimeWrite.mode="function_only"` so raw write endpoints are closed. App Function organization writes require `app:organization:manage` on the real operator/audit actor. Use JS_CODE V2 only for node-local workflow/automation scripts.
 
 Auth manifests live under `src/resources/auth/`. Use them to enable app-level login methods and bind phone-code/CAS/custom providers to App Functions. Auth provider functions are called only by the platform auth flow. They validate external credentials and return identity assertions such as `phone`, `email`, `externalId`, or `unionId`; they must not issue tokens, set cookies, or mutate platform user/binding tables.
 

package/openxiangda-skills/references/workflow-v3.md

@@ -389,7 +389,7 @@ For reusable backend logic that should be shared by pages, automations, and work
 
 Use JS_CODE V2 when the script is local to one workflow node.
 
-Scripts can export `export default async function (ctx) {}` or `module.exports = async (ctx) => {}`. The runtime exposes `ctx.triggerEvent`, `ctx.formData`, `ctx.workflowData`, `ctx.operator`, `ctx.app`, `ctx.variables`, `ctx.resources`, `ctx.form`, `ctx.dataView`, `ctx.connector`, `ctx.notification`, `ctx.organization`, `ctx.platform.roles.*`, `ctx.platform.api.*`, `ctx.utils`, `require`, `process`, and `Buffer`. Prefer `ctx.resources.resolveForm/resolveDataView/resolveConnector`, `ctx.form.queryOne/queryMany/getById/createOne/updateOne/updateById`, `ctx.dataView.query/stats`, `ctx.connector.call/invoke`, and `ctx.platform.roles.findByCode/addUsers/removeUser` for platform-side work. Use `ctx.organization.departments.*` and `ctx.organization.accounts.*` only for intentional organization-management flows; the real operator/audit actor must hold `app:organization:manage`. App Function and trusted-node form writes are backend operations over declared resources, not direct page-user submit access; keep internal forms closed to raw user submission unless the business requires it. Raw `ctx.platform.api.*` calls return HTTP response plus platform envelope. Legacy data/process bridge methods remain available as `ctx.methods.queryOneData/queryManyData/getDataByFormInstanceId/updateOneData/updateDataByFormInstanceId/updateManyData/createOneData/terminateProcess/getAllParentDepartments`.
+Scripts can export `export default async function (ctx) {}` or `module.exports = async (ctx) => {}`. The runtime exposes `ctx.triggerEvent`, `ctx.formData`, `ctx.workflowData`, `ctx.operator`, `ctx.app`, `ctx.variables`, `ctx.resources`, `ctx.form`, `ctx.dataView`, `ctx.connector`, `ctx.notification`, `ctx.organization`, `ctx.platform.roles.*`, `ctx.platform.api.*`, `ctx.utils`, `require`, `process`, and `Buffer`. App Functions additionally expose `ctx.process.startFromExistingInstance/resolveCapabilities/resubmitTask/withdraw/transferTask`; these calls are restricted to the current app and declared `resources.forms`, and reuse the real operator's official workflow permission, operation-log, event, idempotency, and replay paths. Prefer `ctx.resources.resolveForm/resolveDataView/resolveConnector`, `ctx.form.queryOne/queryMany/getById/createOne/updateOne/updateById`, `ctx.dataView.query/stats`, `ctx.connector.call/invoke`, and `ctx.platform.roles.findByCode/addUsers/removeUser` for platform-side work. Use `ctx.organization.departments.*` and `ctx.organization.accounts.*` only for intentional organization-management flows; the real operator/audit actor must hold `app:organization:manage`. App Function and trusted-node form writes are backend operations over declared resources, not direct page-user submit access; keep internal forms closed to raw user submission unless the business requires it. Raw `ctx.platform.api.*` calls return HTTP response plus platform envelope. Legacy data/process bridge methods remain available as `ctx.methods.queryOneData/queryManyData/getDataByFormInstanceId/updateOneData/updateDataByFormInstanceId/updateManyData/createOneData/terminateProcess/getAllParentDepartments`.
 
 Example `src/js-code-nodes/sync_customer/index.ts`:
 

package/openxiangda-skills/skills/openxiangda-core/SKILL.md

@@ -119,7 +119,7 @@ Reviewed bundle commands may retain `<profile>` as a template. The explicit real
 
 Exact `resourceSelectors` are authoritative for supported configuration resources such as `publicAccessPolicies`. A legacy `resources=true` category marker is narrowed by those exact selectors and must not become an app-wide generic-resource release. Missing selectors, unknown resource types, wildcard `*`, deletes, and genuine app-wide resource closures remain fail closed.
 
-`runtime deploy --no-activate` uploads an immutable preview release from a clean committed mainline `HEAD`. It reads a narrow Runtime head instead of the full app snapshot. Before acquiring a lease, the CLI confirms `package.json#scripts.build` and existing dependencies; it uses `npm run build` to execute the declared script so pnpm worktree symlinks do not trigger a reinstall. Immutable Git-base artifact hashes are cached under the Git common directory. `release begin` requires local main/master and the live remote default tip to be identical, so `integration-status` is already satisfied after activation and `release end` does not wait for a later merge.
+`runtime deploy --no-activate` uploads an immutable preview release from a clean committed mainline `HEAD`. It reads a narrow Runtime head instead of the full app snapshot. Before acquiring a lease, the CLI confirms `package.json#scripts.build` and existing dependencies; it uses `npm run build` to execute the declared script so pnpm worktree symlinks do not trigger a reinstall. Immutable Git-base artifact hashes are cached under the Git common directory. `release begin` requires local main/master and the live remote default tip to be identical, so `integration-status --change <change>` is already satisfied after activation and `release end` does not wait for a later merge. For a completed managed ship, `--change` recovers lineage from private `ship.json` or the referenced production/preproduction deployment execution journal and reports the exact missing file or field when recovery fails.
 
 `release app-head` and `runtime releases` return compact summaries by default. Use `--full` only when the complete manifest is required.
 

package/openxiangda-skills/skills/openxiangda-workflow-automation/SKILL.md

@@ -103,7 +103,7 @@ Use `workflow pull` to inspect the live definition. Use `workflow list --json` a
 
 JS_CODE is the backend execution escape hatch for workflow and automation. Use it when the logic must run on the server after a backend trigger, such as a fixed cron schedule, a form date-field schedule, a form submit/update/delete/field-change event, or a workflow approval/process event. It is appropriate for cross-form data queries, create/update/batch update operations, process termination, platform API calls, external HTTP calls, and complex orchestration that the frontend cannot handle reliably.
 
-App Function is the reusable backend execution model. Use it when the logic should be called by custom pages, multiple automations, workflows, or the runtime API. Source lives in `src/functions/<functionCode>/index.ts`; manifest lives in `src/resources/functions/<functionCode>.json`. Call it from pages with `sdk.function.invoke(code, { input })`, from graph definitions with `function_call`, or from the runtime endpoint `/:appType/v1/functions/:code/invoke.json`. Direct runtime invocation defaults to app automation management permission; ordinary page callers must declare `definitionJson.runtimeInvoke.audience` (`authenticated`, `page_permission_group`, `app_roles`, or `scope_policy`). Prefer `export default async function(ctx, input) {}` for App Function source; the second argument is the invoke input and the same value is available as `ctx.input`. Current MVP exposes controlled helpers only and does not expose raw SQL or Redis. `ctx.form.createOne/updateOne/updateById` are trusted backend writes governed by declared `resources.forms` and function invocation authorization; keep internal forms closed to direct user submit unless the business explicitly needs raw form submission. For internal function-only forms, set form settings `runtimeWrite.mode="function_only"` instead of relying only on missing submit permission groups.
+App Function is the reusable backend execution model. Use it when the logic should be called by custom pages, multiple automations, workflows, or the runtime API. Source lives in `src/functions/<functionCode>/index.ts`; manifest lives in `src/resources/functions/<functionCode>.json`. Call it from pages with `sdk.function.invoke(code, { input })`, from graph definitions with `function_call`, or from the runtime endpoint `/:appType/v1/functions/:code/invoke.json`. Direct runtime invocation defaults to app automation management permission; ordinary page callers must declare `definitionJson.runtimeInvoke.audience` (`authenticated`, `page_permission_group`, `app_roles`, or `scope_policy`). Prefer `export default async function(ctx, input) {}` for App Function source; the second argument is the invoke input and the same value is available as `ctx.input`. Current MVP exposes controlled helpers only and does not expose raw SQL or Redis. App Functions can call `ctx.process.startFromExistingInstance`, `resolveCapabilities`, `resubmitTask`, `withdraw`, and `transferTask`; the bridge uses the current app, declared `resources.forms`, and the real operator's workflow/task authorization, audit, event, and replay contracts. `ctx.form.createOne/updateOne/updateById` are trusted backend writes governed by declared `resources.forms` and function invocation authorization; keep internal forms closed to direct user submit unless the business explicitly needs raw form submission. For internal function-only forms, set form settings `runtimeWrite.mode="function_only"` instead of relying only on missing submit permission groups.
 
 For third-party credentials, use top-level metadata-only `secretRefs` plus `definitionJson.version="function_v2"` and `runtimeContractVersion="trusted_node_v2"`; read a declared value with `await ctx.secrets.get(name)` and call public business APIs through `ctx.utils.http`. Never use `process.env` for platform secrets. Values are managed with `openxiangda secret create|rotate --value-stdin --change <change> --profile <name>` and never appear in Git, build output, snapshots, plan diffs, logs, exceptions, or traces. Local tests may use `function test --secret-from-env logical=ENV` only; the value is passed to an isolated child over stdin and is never written to workspace/cache/state. For a Root App transaction, use exact-scope `resource publish function --only <code> --stage-only` and include its verified `stagedResource` in `release app-finalize`.
 
@@ -143,7 +143,7 @@ Inside the TypeScript script, prefer `export default async function (ctx) {}` or
 - Data/process methods: `ctx.methods.queryOneData`, `queryManyData`, `getDataByFormInstanceId`, `updateOneData`, `updateDataByFormInstanceId`, `updateManyData`, `createOneData`, `terminateProcess`, and `getAllParentDepartments`.
 - Notification bridge: `ctx.notification.sendByType`, `batchSendByType`, `findConfig`, and `previewTemplate`. Declare templates in `src/resources/notifications/` before using custom `notificationType`.
 - Platform API bridge: `ctx.platform.api.get/post/put/patch/delete/request` for `/openxiangda-api/v1`; role helpers: `ctx.platform.roles.list/findByCode/addUsers/removeUser`.
-- Resource helpers: `ctx.resources.resolveForm/resolveDataView/resolveConnector`, `ctx.form.queryOne/queryMany/getById/createOne/updateOne/updateById`, `ctx.dataView.query/stats`, and `ctx.connector.call/invoke`.
+- Resource helpers: `ctx.resources.resolveForm/resolveDataView/resolveConnector`, `ctx.form.queryOne/queryMany/getById/createOne/updateOne/updateById`, `ctx.process.startFromExistingInstance/resolveCapabilities/resubmitTask/withdraw/transferTask` for App Functions, `ctx.dataView.query/stats`, and `ctx.connector.call/invoke`.
 - Node runtime helpers: `require`, `process`, `Buffer`, `ctx.utils`, `ctx.utils.http`, and `ctx.console`.
 
 Example `function_call` node:

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "openxiangda",
-  "version": "1.0.212",
+  "version": "1.0.214",
   "description": "OpenXiangda CLI, workspace build tools, runtime SDK, and form components.",
   "private": false,
   "bin": {