openxiangda 1.0.211 → 1.0.213

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
@@ -206,7 +206,7 @@ For source-only Function/Automation changes, the final command does not reconstr
 
 Page repair publishing is staged by default. It first freezes `pages/snapshot`, sends the active Page Release parent plus every page revision, and uses revision `0` only for a genuinely new page. Review with `openxiangda page head|releases|detail|diff`; activate an immutable complete release explicitly with `page activate <releaseId> --change <change>`. Historical activation requires `page rollback <releaseId> --rollback --change <change> --reason "..."`. Parent or revision conflicts are never refreshed or retried automatically.
 
-Use `openxiangda release app-capture` to read the platform's transactionally consistent whole-app manifest. For a normal multi-resource release, stage the changed Runtime/Page/Backend/Form child releases; commands carrying the same `--change` atomically accumulate their canonical immutable entries in `.openxiangda/releases/<change>/staged-resources.json`. Then run `app-finalize --change <change> --staged-resources-json <JSON|file>`. The CLI overlays Runtime/Page/Backend by singleton kind and Form by `formUuid`, preserves every unmodified active child from the read-only capture, and sends the complete frozen manifest through `prepare -> verify -> activate` with `activateStagedChildren=true`. Runtime staging never rewrites local active Runtime state, and a malformed staged response fails closed. The child heads and App head therefore switch in one database transaction (`atomic_staged_children_v1`); any parent, revision, asset, or hash drift stops with zero root activation and is never refreshed or retried. An aborted Form Release is never an idempotent success: rerunning the same scoped form publish removes its aborted staged index and creates a new immutable attempt automatically, after which the whole App is retried atomically. Never work around an App failure by sequentially activating forms. `app-prepare` accepts the same overlay for a manual reviewed flow, and `app-activate <releaseId> --activate-staged-children` performs the explicit atomic activation. For a legacy workspace whose already verified immutable Root cannot pass historical baseline/session compatibility, a platform administrator may use the audited break-glass path: `app-activate <releaseId> --activate-staged-children --break-glass-adopt-verified-root --reason "..."`. It skips only workspace/baseline/source compatibility checks; a fresh lease/baseline plus Root parent CAS, exact child identity/hash/parent/head, and the atomic transaction remain mandatory. Calling `app-finalize` without an overlay remains a compatibility-only retrospective aggregation of already-active children. `app-rollback <releaseId> --change <change> --reason "..."` prepares the audited rollback manifest.
+Use `openxiangda release app-capture` to read the platform's transactionally consistent whole-app manifest. For a normal multi-resource release, stage the changed Runtime/Page/Backend/Form child releases; commands carrying the same `--change` atomically accumulate their canonical immutable entries in `.openxiangda/releases/<change>/staged-resources.json`. Then run `app-finalize --change <change> --staged-resources-json <JSON|file>`. The CLI overlays Runtime/Page/Backend by singleton kind and Form by `formUuid`, preserves every unmodified active child from the read-only capture, and sends the complete frozen manifest through `prepare -> verify -> activate` with `activateStagedChildren=true`. Runtime staging never rewrites local active Runtime state, and a malformed staged response fails closed. The child heads and App head therefore switch in one database transaction (`atomic_staged_children_v1`); any parent, revision, asset, or hash drift stops with zero root activation and is never refreshed or retried. An aborted Form Release is never an idempotent success: rerunning the same scoped form publish removes its aborted staged index and creates a new immutable attempt automatically, after which the whole App is retried atomically. Never work around an App failure by sequentially activating forms. `app-prepare` accepts the same overlay for a manual reviewed flow, and `app-activate <releaseId> --activate-staged-children` performs the explicit atomic activation. For a legacy workspace whose already verified immutable Root cannot pass historical baseline/session compatibility, a platform administrator may use the audited break-glass path: `app-activate <releaseId> --activate-staged-children --break-glass-adopt-verified-root --reason "..."`. It skips only workspace/baseline/source compatibility checks; a fresh lease/baseline plus Root parent CAS, exact child identity/hash/parent/head, and the atomic transaction remain mandatory. When the operator explicitly requires an unconditional legacy recovery, `app-activate <releaseId> --force-activate-without-validation --profile <name>` sends a single activation write without reading detail/capture or requiring change, lease, baseline, source, status, parent, hash, resource-head, environment, or child-lineage checks. Authentication, the bound tenant/appType data boundary, target-row existence, database constraints, and the one database transaction remain inherent execution requirements. Calling `app-finalize` without an overlay remains a compatibility-only retrospective aggregation of already-active children. `app-rollback <releaseId> --change <change> --reason "..."` prepares the audited rollback manifest.
 
 If exact FormRelease children were already staged for the same change before a new release baseline or lease is acquired, the CLI reuses them only after checking the server's immutable, inactive, non-aborted release, exact app/form identity and content hash, frozen schema/formType, finalized resources, parent/base revision, and current Form head. Verified children are rebound to the newly owned baseline/session; local `schemaSyncedAt` is not treated as release evidence. Missing or conflicting evidence still fails closed, and neither direct schema synchronization nor early Form activation is required.
 

package/lib/cli.js

@@ -309,7 +309,7 @@ Usage:
   openxiangda release ship|candidate|deploy|test|promote|rollback [--candidate id] [--environment target] [--replace-manifest --reason text] [--adopt-online-baseline --adoption-reason text] [--json]
   openxiangda task status --change <id> [--profile name] [--watch] [--json]
   openxiangda release backend-head|backend-list|backend-detail|backend-diff|backend-rollback|backend-abort|backend-retry [releaseId] [--profile name] [--json]
-  openxiangda release app-capture|app-head|app-list|app-detail|app-diff|app-prepare|app-verify|app-activate|app-finalize|app-rollback|app-abort [releaseId] [--staged-resources-json <JSON|file>] [--activate-staged-children] [--break-glass-adopt-verified-root --reason text] [--profile name] [--json]
+  openxiangda release app-capture|app-head|app-list|app-detail|app-diff|app-prepare|app-verify|app-activate|app-finalize|app-rollback|app-abort [releaseId] [--staged-resources-json <JSON|file>] [--activate-staged-children] [--break-glass-adopt-verified-root --reason text] [--force-activate-without-validation] [--profile name] [--json]
   openxiangda env [--profile name]
   openxiangda workspace init [dir] [--name package-name] [--runtime legacy|react-spa] [--install] [--profile name --app-type APP_XXX]
   openxiangda workspace prepare [--check] [--force] [--json]
@@ -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',
@@ -3775,7 +3934,7 @@ async function release(args) {
       '用法: openxiangda release publish|begin|status|explain|integration-status|renew|end [--change id] [--profile name] [--json]',
       '      openxiangda release ship|candidate|deploy|reconcile|test|promote|rollback [--candidate id] [--environment target] [--replace-manifest --reason text] [--adopt-online-baseline --adoption-reason text] [--confirm-production] [--json]',
       '      openxiangda release backend-head|backend-list|backend-detail|backend-diff|backend-rollback|backend-abort|backend-retry [releaseId] [--profile name] [--json]',
-      '      openxiangda release app-capture|app-head|app-list|app-detail|app-diff|app-post-commit|app-retry|app-prepare|app-verify|app-activate|app-finalize|app-rollback|app-abort [releaseId] [--staged-resources-json <JSON|file>] [--activate-staged-children] [--break-glass-adopt-verified-root --reason text] [--profile name] [--json]',
+      '      openxiangda release app-capture|app-head|app-list|app-detail|app-diff|app-post-commit|app-retry|app-prepare|app-verify|app-activate|app-finalize|app-rollback|app-abort [releaseId] [--staged-resources-json <JSON|file>] [--activate-staged-children] [--break-glass-adopt-verified-root --reason text] [--force-activate-without-validation] [--profile name] [--json]',
       '常用流程:',
       '  openxiangda release ship --change <id> --profile <name>',
       '  openxiangda release ship --change <id> --profile <name> --adopt-online-baseline --adoption-reason "已审计目标来自多次历史发布"',
@@ -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() });
     }
@@ -5828,6 +6010,22 @@ async function activateAppReleaseDetail(
   releaseId,
   options = {}
 ) {
+  const body = stripUndefinedValues({
+    ...(options.activateStagedChildren === true
+      ? { activateStagedChildren: true }
+      : {}),
+    ...(options.breakGlassAdoptVerifiedRoot === true
+      ? {
+          breakGlassAdoptVerifiedRoot: true,
+          breakGlassReason: options.breakGlassReason,
+        }
+      : {}),
+    ...(options.forceActivateWithoutValidation === true
+      ? { forceActivateWithoutValidation: true }
+      : {}),
+    protocolVersion: options.protocolVersion,
+    ...(options.environmentControl || {}),
+  });
   return await requestWithAuth(
     config,
     target.profileName,
@@ -5837,22 +6035,10 @@ async function activateAppReleaseDetail(
     ),
     {
       method: 'POST',
-      body: appReleaseWriteBody(
-        releaseContext,
-        stripUndefinedValues({
-          ...(options.activateStagedChildren === true
-            ? { activateStagedChildren: true }
-            : {}),
-          ...(options.breakGlassAdoptVerifiedRoot === true
-            ? {
-                breakGlassAdoptVerifiedRoot: true,
-                breakGlassReason: options.breakGlassReason,
-              }
-            : {}),
-          protocolVersion: options.protocolVersion,
-          ...(options.environmentControl || {}),
-        })
-      ),
+      body:
+        options.forceActivateWithoutValidation === true
+          ? body
+          : appReleaseWriteBody(releaseContext, body),
     }
   );
 }
@@ -6075,8 +6261,26 @@ async function runAppReleaseCommand(
     );
   } else if (subcommand === 'app-activate') {
     if (!releaseId) {
-      fail('用法: openxiangda release app-activate <releaseId> --change <id>');
+      fail(
+        '用法: openxiangda release app-activate <releaseId> [--change <id> | --force-activate-without-validation]'
+      );
     }
+    const forceActivateWithoutValidation =
+      flags['force-activate-without-validation'] === true ||
+      String(flags['force-activate-without-validation'] || '').toLowerCase() ===
+        'true';
+    if (forceActivateWithoutValidation) {
+      data = await activateAppReleaseDetail(
+        config,
+        target,
+        null,
+        releaseId,
+        {
+          activateStagedChildren: true,
+          forceActivateWithoutValidation: true,
+        }
+      );
+    } else {
     const breakGlassAdoptVerifiedRoot =
       flags['break-glass-adopt-verified-root'] === true ||
       String(flags['break-glass-adopt-verified-root'] || '').toLowerCase() ===
@@ -6133,6 +6337,7 @@ async function runAppReleaseCommand(
         environmentControl: appReleaseEnvironmentControl(flags),
       }
     );
+    }
   } else if (subcommand === 'app-finalize') {
     const stagedResources = readStagedAppReleaseResources(flags);
     let stagedScope = null;

package/openxiangda-skills/SKILL.md

@@ -120,11 +120,11 @@ 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.
 
-For a whole-app release, keep changed Runtime/Page/Backend/Form children staged and run `openxiangda release app-finalize --change <change> --staged-resources-json <JSON|file> --profile <name>`. The JSON contains only changed immutable child entries; the CLI overlays Runtime/Page/Backend by singleton kind and FormRelease by `formUuid` onto one authoritative read-only capture, preserving every unmodified active child. It then performs `prepare -> verify -> activateStagedChildren=true`, switching child heads and the App head atomically (`atomic_staged_children_v1`, or `atomic_staged_children_v2` when a Backend Release v2 child is present). Never refresh or retry after a conflict. The flow requires the owned stored lease/change baseline and carries the same client session and Git lineage on every write. A platform administrator may recover a legacy, already verified immutable Root with `app-activate <releaseId> --activate-staged-children --break-glass-adopt-verified-root --reason "..."`. This audited recovery skips workspace/baseline/source compatibility only; it still requires a fresh lease/baseline and enforces Root parent CAS, exact child identity/hash/parent/head, and atomic activation. Omitting the overlay is compatibility-only retrospective aggregation of already-active children.
+For a whole-app release, keep changed Runtime/Page/Backend/Form children staged and run `openxiangda release app-finalize --change <change> --staged-resources-json <JSON|file> --profile <name>`. The JSON contains only changed immutable child entries; the CLI overlays Runtime/Page/Backend by singleton kind and FormRelease by `formUuid` onto one authoritative read-only capture, preserving every unmodified active child. It then performs `prepare -> verify -> activateStagedChildren=true`, switching child heads and the App head atomically (`atomic_staged_children_v1`, or `atomic_staged_children_v2` when a Backend Release v2 child is present). Never refresh or retry after a conflict. The flow requires the owned stored lease/change baseline and carries the same client session and Git lineage on every write. A platform administrator may recover a legacy, already verified immutable Root with `app-activate <releaseId> --activate-staged-children --break-glass-adopt-verified-root --reason "..."`. This audited recovery skips workspace/baseline/source compatibility only; it still requires a fresh lease/baseline and enforces Root parent CAS, exact child identity/hash/parent/head, and atomic activation. An explicitly authorized unconditional legacy recovery may use `app-activate <releaseId> --force-activate-without-validation --profile <name>`; this sends one activation write without local reads or release control/lineage/CAS gates. Authentication, bound tenant/appType scope, target-row existence, database constraints, and transactional execution remain inherent. Omitting the overlay is compatibility-only retrospective aggregation of already-active children.
 
 When the same change already has staged FormRelease children before a fresh baseline/lease is acquired, keep them staged. The CLI may rebind each child into the new session only after server verification of immutable/inactive/non-aborted state, exact app/form identity and content hash, frozen schema/formType, finalized resources, parent/base revision, and current Form head. `schemaSyncedAt` is local cache metadata, not release evidence. Do not direct-publish or activate a Form to bypass Workflow validation; missing or conflicting staged evidence must fail closed.
 

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

@@ -73,7 +73,7 @@ Standard workspaces use the CLI-bundled scoped JS_CODE builder directly, includi
 
 Use `openxiangda release backend-head|backend-list|backend-detail|backend-diff` to inspect immutable history. `backend-rollback <releaseId> --change <change> --reason "..."` prepares, verifies, and activates a new release from the historical snapshot; it never mutates or directly reactivates the old row. `backend-abort` stops prepared/verified work and `backend-retry` retries only recorded post-commit side effects. Do not fetch newer revisions to replay an older payload.
 
-Use `openxiangda release app-capture` for the platform's authoritative transactionally consistent whole-app manifest. Normal publishing stages changed Runtime/Page/Backend/Form children first, then runs `app-finalize --change <change> --staged-resources-json <JSON|file>`. The overlay contains only changed immutable child entries; Runtime/Page/Backend use singleton kind identity and FormRelease uses `formUuid`. The CLI preserves unmodified active children from the capture and performs `prepare -> verify -> activateStagedChildren=true`, atomically switching all child heads and the App head (`atomic_staged_children_v1`). Child drift or a lost lease causes zero root activation; never auto-refresh or conflict-retry. An aborted Form Release must never be reused as an idempotent result. Rerun the same exact form resource publish: the CLI discards the aborted staged entry, the platform creates a new immutable attempt for the same logical artifact, and the Root App transaction is retried. Never sequentially activate forms as a workaround. `app-prepare` accepts the same overlay for manual review, and `app-activate <releaseId> --activate-staged-children` performs the explicit transaction switch. A platform administrator may recover a legacy, already verified immutable Root with `app-activate <releaseId> --activate-staged-children --break-glass-adopt-verified-root --reason "..."`. This audited path skips only workspace/baseline/source compatibility checks; it still requires a fresh lease/baseline and enforces Root parent CAS, exact child identity/hash/parent/head, and atomic activation. No-overlay finalize remains retrospective compatibility only. `app-rollback <releaseId> --change <change> --reason "..."` prepares an audited rollback manifest.
+Use `openxiangda release app-capture` for the platform's authoritative transactionally consistent whole-app manifest. Normal publishing stages changed Runtime/Page/Backend/Form children first, then runs `app-finalize --change <change> --staged-resources-json <JSON|file>`. The overlay contains only changed immutable child entries; Runtime/Page/Backend use singleton kind identity and FormRelease uses `formUuid`. The CLI preserves unmodified active children from the capture and performs `prepare -> verify -> activateStagedChildren=true`, atomically switching all child heads and the App head (`atomic_staged_children_v1`). Child drift or a lost lease causes zero root activation; never auto-refresh or conflict-retry. An aborted Form Release must never be reused as an idempotent result. Rerun the same exact form resource publish: the CLI discards the aborted staged entry, the platform creates a new immutable attempt automatically, and the Root App transaction is retried. Never sequentially activate forms as a workaround. `app-prepare` accepts the same overlay for manual review, and `app-activate <releaseId> --activate-staged-children` performs the explicit transaction switch. A platform administrator may recover a legacy, already verified immutable Root with `app-activate <releaseId> --activate-staged-children --break-glass-adopt-verified-root --reason "..."`. This audited path skips only workspace/baseline/source compatibility checks; it still requires a fresh lease/baseline and enforces Root parent CAS, exact child identity/hash/parent/head, and atomic activation. For an explicitly authorized unconditional legacy recovery, `app-activate <releaseId> --force-activate-without-validation --profile <name>` performs one direct activation write without detail/capture/change/lease/baseline/source/status/parent/hash/resource-head/environment/child-lineage gates; only authentication, the bound tenant/appType data boundary, target-row existence, database constraints, and the transaction remain inherent. No-overlay finalize remains retrospective compatibility only. `app-rollback <releaseId> --change <change> --reason "..."` prepares an audited rollback manifest.
 
 ## Classic workspace
 
@@ -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/package.json

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

package/templates/openxiangda-react-spa/.cursor/rules/openxiangda.mdc

@@ -37,6 +37,7 @@ This is an OpenXiangda React SPA workspace. See [AGENTS.md](mdc:AGENTS.md) for f
 - A staged FormRelease for the same change may be rebound to a fresh baseline/session only after server verification of immutable/inactive/non-aborted state, identity/hash, frozen schema/formType, finalized resources, parent/base revision, and current Form head. `schemaSyncedAt` is not release evidence; never synthesize it, direct-publish the schema, or activate the Form early to bypass Workflow validation.
 - Managed `release ship --adopt-online-baseline --adoption-reason "..."` freezes that audited intent in the private ship journal; the later `--confirm-production` automatically reuses it and rejects an explicitly different pair before any request.
 - Managed `release ship --replace-manifest --reason "..."` requires the pair, reason length >= 8, and exact Backend selectors; production confirmation repeats the exact preproduction pair, with no forwarding to Form/Workflow/Runtime/config/all stages.
+- After managed promotion, run `release integration-status --change <change> --profile <name> --check`; it recovers lineage from private `ship.json` or its referenced production/preproduction deployment execution journal, and names the missing file or field when recovery is impossible.
 - In a managed workspace with multiple targets, `function invoke` must include `--environment <target>`; verify the resolved target line on stderr before drawing conclusions from the response.
 - React routes live in `src/app/router.tsx`; frontend artifacts are deployed with `openxiangda runtime deploy`.
 - Use `AttachmentField` / `ImageField` for form-context previews, and `AttachmentPreviewList` / `ImagePreviewGrid` / `useFilePreview` for standalone custom pages. Do not fake form context, import internal preview implementations, or maintain local previewable-extension lists.

package/templates/openxiangda-react-spa/.qoder/rules/openxiangda.md

@@ -33,6 +33,7 @@ This is an OpenXiangda React SPA workspace. Read [AGENTS.md](AGENTS.md) for full
 - 相同 change 的 staged FormRelease 只有经服务端重新核验 immutable/inactive/non-aborted、identity/hash、冻结 schema/formType、finalized 资源、parent/base revision 与当前 Form Head 后，才可重挂接新 baseline/session。`schemaSyncedAt` 不是发布证据；禁止伪造、直发 schema 或提前激活 Form 绕过 Workflow 校验。
 - 环境托管 `release ship --adopt-online-baseline --adoption-reason "..."` 会把审计意图冻结进私有 ship journal，后续 `--confirm-production` 自动复用；显式传入不同参数会在任何请求前失败。
 - 环境托管 `release ship --replace-manifest --reason "..."` 必须成对、reason 至少 8 字符且仅限精确 Backend selector；正式确认复用与预发完全相同的参数，不透传 Form/Workflow/Runtime/配置或全量步骤。
+- 托管发布完成后运行 `release integration-status --change <change> --profile <name> --check`；CLI 从私有 `ship.json` 或其引用的 production/preproduction deployment execution 日志恢复血缘，无法恢复时指出实际缺失的文件或字段。
 - 多 target 的托管工作区执行 `function invoke` 必须显式传 `--environment <target>`，并先核对 stderr 回显的最终 target 再判断响应。
 - Promotion 必须持有 `release begin/end` 租约；`release begin` 只接受与权威远端 tip 完全一致的 clean main/master。feature branch 或未 push 主线在任何写入前失败。clone primary 只有在冻结仓库 ID 已存在于 `repoAliases` 时才会 canonicalize；无交集在 Release prepare 前失败关闭。激活后直接运行 `integration-status` 和 `release end`，不再补做发布后合并。
 - 已有工作区通过 `environment attach` 接入环境组，旧资源映射只迁移到 appType 相同的预发 target，正式 target 必须为空。preproduction / production 分别拥有独立 appType、资源 ID、数据和副作用策略；禁止直接 `release publish`，禁止跨环境复制 ID，使用 `openxiangda studio` 查看状态。只有用户明确授权的投产前重分类可执行 `environment swap --reason "..." --confirm-production`；它不移动应用数据或 Release Head，且默认不放开副作用。

package/templates/openxiangda-react-spa/AGENTS.md

@@ -55,6 +55,8 @@ openxiangda commands --json
 
 工作区一旦通过 `environment init` 登记，或通过 `environment attach` 接入已有环境组，`release publish` 即不再是入口。日常使用两段式 `release ship`：第一次冻结不可变 candidate 并只部署到 preproduction，停止在 `awaiting_production_confirmation`；确认预发结果后，第二次命令提供 `--confirm-production`，把同一 candidate 晋级 production，不会重新构建。真实人工验收是默认建议，可用可选的 `--acceptance-note` 留痕；但用户明确授权的低风险或紧急发布不受僵硬审批门禁阻塞。两套环境的 appType、资源 ID、数据和副作用策略完全独立；旧单目标资源映射只允许迁移到 appType 相同的预发 target，正式 target 必须为空。仅在用户明确授权的投产前重分类中使用 `environment swap --reason "..." --confirm-production` 原子交换两个既有应用的环境角色；数据和 Release Head 不移动，副作用默认不放开。单独调整某个环境的副作用策略时，先运行 `environment policy update <kind|id> ... --dry-run` 查看差异，再按 CAS revision 写入；patch 只校验本次提交字段并原样保留未知历史字段，`--full-replace` 才按完整目标删除遗漏字段。不得借用 swap，正式写入另需 `--confirm-production`。`organizationWrites=explicit_capability_only` 仍强制 `app:organization:manage`。发布硬门禁只保留明确 scope/profile/target、权限、干净且已推送主线、不可变版本、CAS/租约与生产确认；文案和人工验收说明默认是建议，只有显式 strict 模式才阻断。`openxiangda studio` 提供仅本机访问的开发者页面，用于查看绑定、漂移、候选、部署、证据和下一安全动作。
 
+托管发布完成后运行 `release integration-status --change <change> --profile <name> --check`。CLI 会从私有 `ship.json` 恢复血缘，必要时自动沿 production/preproduction deployment ID 查找对应 `execution.json`；失败信息必须指出实际缺失的日志或字段。
+
 只有已审计代码早已进入权威主线、而精确非删除目标在线上来自多次历史发布且无法对应单一 Git 基线时，第一次 `release ship` 才可增加 `--adopt-online-baseline --adoption-reason "..."`。该意图会冻结进私有 `ship.json`，后续 `--confirm-production` 自动复用；它不会放松冻结 online heads、change/lease、删除/全量拒绝、服务端 CAS、staged children 或单次 App finalize 原子激活。
 
 环境托管发布需要完整替换 Function/Automation manifest 时，`release ship` 可成对增加 `--replace-manifest --reason "..."`；reason 至少 8 字符，只会进入精确 Backend selector，正式确认必须复用与预发完全相同的参数，绝不扩散到表单、流程、Runtime、配置资源或全量范围。

package/templates/sy-lowcode-app-workspace/.cursor/rules/openxiangda.mdc

@@ -32,6 +32,7 @@ This is a `sy-lowcode-app-workspace` managed by the `openxiangda` CLI. See [AGEN
 - Source-triggered Function/Automation publishing uses server-side source-field PATCH by default and preserves online bindings, contracts, metadata, trigger/view configuration, and enabled/published state. A new source-free Automation with a complete `definitionJson.version="v3"` automatically uses manifest create; replacing an existing whole manifest requires exact `--only/--code` plus `--replace-manifest --reason "..."`.
 - A staged FormRelease for the same change may be rebound to a fresh baseline/session only after server verification of immutable/inactive/non-aborted state, identity/hash, frozen schema/formType, finalized resources, parent/base revision, and current Form head. `schemaSyncedAt` is not release evidence; never synthesize it, direct-publish the schema, or activate the Form early to bypass Workflow validation.
 - Managed `release ship --replace-manifest --reason "..."` requires the pair, reason length >= 8, and exact Backend selectors; production confirmation repeats the exact preproduction pair, with no forwarding to Form/Workflow/Runtime/config/all stages.
+- After managed promotion, run `release integration-status --change <change> --profile <name> --check`; it recovers lineage from private `ship.json` or its referenced production/preproduction deployment execution journal, and names the missing file or field when recovery is impossible.
 - Before platform writes, run `release begin` only from clean main/master exactly equal to the authoritative remote tip. Feature branches and unpushed mainline commits fail before writes. A clone primary may be canonicalized to the frozen repository ID only when that ID is already in `repoAliases`; otherwise release prepare fails closed. After activation, run `integration-status` and `release end`; no post-release merge is needed.
 - Environment-managed workspaces never publish directly. Existing workspaces use `environment attach`; only an appType-matching legacy binding may seed preproduction and production starts empty. Run `release candidate`, `release deploy --environment preproduction`, `release test`, then promote that same candidate with `release promote --environment production --confirm-production`. Keep app/resource/data IDs isolated and inspect state with `openxiangda studio`. Only an explicitly authorized commissioning reclassification may use `environment swap --reason "..." --confirm-production`; it preserves app data/Release Heads and keeps side effects restricted by default.
 - Change one target's side-effect policy only with `environment policy update <preproduction|production> --side-effect-policy-json <JSON|file> --reason "..."`: run `--dry-run` first, add `--confirm-production` for production, and never use `environment swap` for this. Patch mode validates only supplied fields and preserves unrecognized historical fields; `--full-replace` validates the supplied complete target and intentionally removes omissions. `organizationWrites=explicit_capability_only` removes the environment deny but still requires `app:organization:manage`. Keep release hard gates to explicit scope/profile/target, authorization, clean pushed mainline, immutable identity, CAS/lease, and production confirmation; prose and human acceptance notes are advisory unless strict mode is configured.

package/templates/sy-lowcode-app-workspace/.qoder/rules/openxiangda.md

@@ -32,6 +32,7 @@ This is a `sy-lowcode-app-workspace` managed by the `openxiangda` CLI. Read [AGE
 - Function/Automation 源码触发默认走服务端 source-field PATCH，保留线上 bindings/contracts/metadata/trigger/view/enabled/published state；无源码且 `definitionJson.version="v3"` 完整的新建 Automation 自动走 manifest create，只有替换已有整包 manifest 才必须精确 `--only/--code` 并加 `--replace-manifest --reason "..."`。
 - 相同 change 的 staged FormRelease 只有经服务端重新核验 immutable/inactive/non-aborted、identity/hash、冻结 schema/formType、finalized 资源、parent/base revision 与当前 Form Head 后，才可重挂接新 baseline/session。`schemaSyncedAt` 不是发布证据；禁止伪造、直发 schema 或提前激活 Form 绕过 Workflow 校验。
 - 环境托管 `release ship --replace-manifest --reason "..."` 必须成对、reason 至少 8 字符且仅限精确 Backend selector；正式确认复用与预发完全相同的参数，不透传 Form/Workflow/Runtime/配置或全量步骤。
+- 托管发布完成后运行 `release integration-status --change <change> --profile <name> --check`；CLI 从私有 `ship.json` 或其引用的 production/preproduction deployment execution 日志恢复血缘，无法恢复时指出实际缺失的文件或字段。
 - 写入平台前只从与权威远端 tip 完全一致的 clean main/master 执行 `release begin`。feature branch 或未 push 主线在任何写入前失败；clone primary 只有在冻结仓库 ID 已存在于 `repoAliases` 时才会 canonicalize，无交集在 Release prepare 前失败关闭；激活后直接运行 `integration-status` 和 `release end`，无需发布后再合并。
 - 环境托管工作区禁止直发：已有工作区先用 `environment attach` 接入，旧映射只能迁移到 appType 相同的预发 target，正式 target 必须为空。然后执行 `release candidate`、`release deploy --environment preproduction`、`release test`，最后将同一 candidate 用 `release promote --environment production --confirm-production` 晋级。两套环境的 appType、资源 ID 和数据不可互拷；用 `openxiangda studio` 查看状态。只有用户明确授权的投产前重分类可执行 `environment swap --reason "..." --confirm-production`；它不移动应用数据或 Release Head，且默认不放开副作用。
 - 单独修改某个环境的副作用策略只能使用 `environment policy update <preproduction|production> --side-effect-policy-json <JSON|file> --reason "..."`：先执行 `--dry-run`，正式环境额外要求 `--confirm-production`，不得借用 `environment swap`。patch 只校验本次提交字段并原样保留未知历史字段，`--full-replace` 才按完整目标删除遗漏字段。`organizationWrites=explicit_capability_only` 只解除环境级 deny，仍强制 `app:organization:manage`。发布硬门禁只保留明确 scope/profile/target、权限、干净且已推送主线、不可变版本、CAS/租约与生产确认；文案和人工验收说明默认是建议，只有显式 strict 模式才阻断。

package/templates/sy-lowcode-app-workspace/AGENTS.md

@@ -58,8 +58,9 @@
 - ✅ Function/Automation 使用 Backend Release v2；正式多资源发布用精确 `--only/--code` 加 `--stage-only` 暂存，同一 child 可混合源码 create、无 `sourceFile` 的完整 v3 声明式 Automation manifest create、source-only update 和显式 manifest replacement，再由 Root App finalize 原子激活。声明式 create 自动选路；替换已有资源的整包 manifest 才需要另加 `--replace-manifest --reason "..."`。clone primary 与冻结仓库 ID 不同时，只有冻结 ID 已存在于 `repoAliases` 才会统一用于 Backend/Workflow/Root App Release；无交集继续失败关闭。
 - ✅ 相同 change 已有 staged FormRelease 时，不要直发 schema、伪造 `schemaSyncedAt` 或提前激活 Form。CLI 只在重新核验服务端不可变状态、identity/hash、冻结 schema/formType、finalized 资源、parent/base revision 与当前 Form Head 后，才将 child 重挂接到新的 baseline/session；冲突继续失败关闭。
 - ✅ 未登记环境的旧工作区，正式 promotion 先聚合 mainline bundle 并 commit/push，再运行 `release publish --change <id> --profile <name>`。
-- ✅ 旧工作区已有 `verified + immutable` Root、但历史 baseline/session 兼容校验无法恢复时，只允许平台管理员显式执行 `release app-activate <releaseId> --activate-staged-children --break-glass-adopt-verified-root --reason "..."`。该审计入口仍要求新租约/基线、相同 tenant/app/holder/change，并保留 Root parent CAS、child identity/hash/parent/head 与原子事务门禁。
+- ✅ 旧工作区已有 Root、且操作者明确授权无条件恢复时，可执行 `release app-activate <releaseId> --force-activate-without-validation --profile <name>`。该命令不读取 detail/capture，不要求 change、租约、baseline、源码 lineage、状态、parent、hash、resource head 或环境发布门禁；服务端直接在目标 tenant/appType 内以单事务切换 Root 与可识别的 staged children。
 - ✅ 已通过 `environment init` 登记或 `environment attach` 接入的工作区默认使用两段式 `release ship`。第一次命令只冻结 candidate 并部署 preproduction，停止等待正式晋级确认；确认预发结果后，另一次命令提供 `--confirm-production`，即可晋级同一 candidate。人工验收是默认建议，可用可选的 `--acceptance-note` 留痕，但不是所有低风险或紧急发布的硬审批门禁。preproduction / production 的 appType、资源 ID、数据和副作用策略完全隔离，严禁跨环境复制 ID 或直接 `release publish`。旧单目标映射只允许按相同 appType 迁移到预发。仅在用户明确授权的投产前重分类中使用 `environment swap --reason "..." --confirm-production` 原子交换两个既有应用的环境角色；数据和 Release Head 不移动，副作用默认不放开。单环境副作用策略用 `environment policy update <kind|id> ... --dry-run` 预览后按 revision CAS 写入，禁止借用 swap；patch 只校验本次提交字段并原样保留未知历史字段，`--full-replace` 才按完整目标删除遗漏字段，正式写入需 `--confirm-production`，且 `organizationWrites=explicit_capability_only` 不绕过 `app:organization:manage`。发布硬门禁只保留明确 scope/profile/target、权限、干净且已推送主线、不可变版本、CAS/租约与生产确认；文案和人工验收说明默认是建议，只有显式 strict 模式才阻断。
+- ✅ 托管发布完成后运行 `release integration-status --change <change> --profile <name> --check`。CLI 会从私有 `ship.json` 恢复血缘，必要时自动沿 production/preproduction deployment ID 查找对应 `execution.json`；失败信息必须指出实际缺失的日志或字段。
 - ✅ 只有已审计目标早已进入权威主线、线上却由多次历史 lineage 组成且无法对应单一 Git 基线时，第一次 `release ship` 才可增加 `--adopt-online-baseline --adoption-reason "..."`；该意图冻结进私有 `ship.json` 并由后续 `--confirm-production` 自动复用。仅允许精确非删除 selectors，冻结 Head、change/lease、服务端 CAS、staged children 与单次 App finalize 仍是硬门禁。
 - ✅ 环境托管发布需要完整替换 Function/Automation manifest 时，`release ship` 可成对增加 `--replace-manifest --reason "..."`；reason 至少 8 字符，只透传精确 Backend selector，正式确认必须复用同一对参数，不扩散到 Form/Workflow/Runtime/配置或全量范围。
 - ✅ 受支持的配置资源（如 `publicAccessPolicies`）以精确 `resourceSelectors` 为边界；历史 `resources=true` 类别标记会被精确 selector 收窄。缺失 selector、未知类型、通配符 `*`、删除和真正全量资源仍 fail closed。