openxiangda 1.0.208 → 1.0.209

package/README.md

@@ -80,9 +80,9 @@ openxiangda inspect app --profile dev --json
 openxiangda app snapshot APP_XXXX --profile dev --json
 ```
 
-User tokens are stored in `~/.openxiangda/profiles.json` with `0600` permissions. Shared workspace environment values, including `APP_OSS_*`, can live in `~/.openxiangda/.env` and are inherited by new workspaces. Project `.env` files still work and override the global defaults. Project state is stored in `.openxiangda/state.json` and contains only profile-specific resource IDs; CLI writes use a workspace lock plus atomic merge/rename so concurrent processes do not truncate another profile's state.
+User tokens are stored in `~/.openxiangda/profiles.json` with `0600` permissions. Shared workspace environment values, including `APP_OSS_*`, can live in `~/.openxiangda/.env` and are inherited by new workspaces. Project `.env` files still work and override the global defaults. Project state is stored in `.openxiangda/state.json` and contains only durable profile-specific resource IDs and environment bindings; volatile candidate/deployment progress lives in the private `.openxiangda/releases/` journal so a release does not dirty the reviewed Git state. Durable CLI writes use a workspace lock plus atomic merge/rename so concurrent processes do not truncate another profile's state.
 
-An environment-managed workspace keeps one logical application with independent `preproduction` and `production` targets. Each target owns its own `appType`, resource IDs, release heads, data, and side-effect policy; IDs must never be copied across targets. `release ship` is deliberately two-phase: the first invocation seals the clean authoritative Git revision and deploys one immutable candidate only to preproduction; it always stops at `awaiting_production_confirmation`. A later invocation includes `--confirm-production` and promotes that exact candidate to production without rebuilding it. Real human acceptance is the recommended default; an optional `--acceptance-note` records it in the deployment evidence, but the platform does not force every low-risk or emergency release through a rigid approval gate. It is impossible to prepare and promote in one invocation. For an audited catch-up whose exact non-delete targets are already merged but whose active resources came from several historical release lineages, the first invocation may explicitly add `--adopt-online-baseline --adoption-reason "..."`; ship validates this pair before creating a candidate/deployment, then forwards it only to exact scoped resource stages. A reviewed complete Function/Automation manifest replacement may similarly add the inseparable `--replace-manifest --reason "..."` pair; ship forwards it only to an exact Backend stage and requires the production confirmation to repeat the exact preproduction intent. Frozen online heads, change/lease ownership, server CAS, staged children, and the single App finalize remain mandatory. Supported configuration resources use exact `resourceSelectors`; a legacy `resources=true` category marker is narrowed by those selectors, while unknown, wildcard, destructive, and genuinely unscoped generic resources remain blocked. The lower-level `candidate/deploy/test/promote` commands remain available for recovery and diagnostics. Direct `release publish` is retained only for legacy, unmanaged workspaces and fails closed for either target of an environment-managed application.
+An environment-managed workspace keeps one logical application with independent `preproduction` and `production` targets. Each target owns its own `appType`, resource IDs, release heads, data, and side-effect policy; IDs must never be copied across targets. `release ship` is deliberately two-phase: the first invocation seals the clean authoritative Git revision and deploys one immutable candidate only to preproduction; it always stops at `awaiting_production_confirmation`. A later invocation includes `--confirm-production` and promotes that exact candidate to production without rebuilding it. Real human acceptance is the recommended default; an optional `--acceptance-note` records it in the deployment evidence, but the platform does not force every low-risk or emergency release through a rigid approval gate. It is impossible to prepare and promote in one invocation. For an audited catch-up whose exact non-delete targets are already merged but whose active resources came from several historical release lineages, the first invocation may explicitly add `--adopt-online-baseline --adoption-reason "..."`; ship validates and freezes this pair before creating a candidate/deployment, then automatically reuses it during the later production confirmation and forwards it only to exact scoped resource stages. A reviewed complete Function/Automation manifest replacement may similarly add the inseparable `--replace-manifest --reason "..."` pair; ship forwards it only to an exact Backend stage and requires the production confirmation to repeat the exact preproduction intent. Frozen online heads, change/lease ownership, server CAS, staged children, and the single App finalize remain mandatory. Supported configuration resources use exact `resourceSelectors`; a legacy `resources=true` category marker is narrowed by those selectors, while unknown, wildcard, destructive, and genuinely unscoped generic resources remain blocked. The lower-level `candidate/deploy/test/promote` commands remain available for recovery and diagnostics. Direct `release publish` is retained only for legacy, unmanaged workspaces and fails closed for either target of an environment-managed application.
 
 Exact, non-destructive configuration selectors such as Data Views and permission groups are now sequenced automatically inside the same ship journal instead of requiring separate SDD changes. New forms are idempotently ensured per environment before their immutable FormRelease is staged. Unscoped resources and destructive configuration deletes remain fail-closed.
 

package/lib/application-environments.js

@@ -474,6 +474,76 @@ function readCandidate(candidateId, cwd = process.cwd()) {
   }
 }
 
+function managedTargetDeploymentFile(target, cwd = process.cwd()) {
+  const safeSegment = (value, fallback) =>
+    String(value || fallback)
+      .trim()
+      .replace(/[^A-Za-z0-9._-]+/g, '_')
+      .slice(0, 128);
+  return path.join(
+    cwd,
+    '.openxiangda',
+    'releases',
+    'targets',
+    safeSegment(target.logicalApp?.code, 'unmanaged'),
+    `${safeSegment(
+      target.targetName || target.environmentId || target.appType,
+      'default'
+    )}.json`
+  );
+}
+
+function readRememberedTargetDeployment(target, cwd = process.cwd()) {
+  const file = managedTargetDeploymentFile(target, cwd);
+  if (fs.existsSync(file)) {
+    try {
+      return JSON.parse(fs.readFileSync(file, 'utf8'));
+    } catch (error) {
+      throw new Error(
+        `MANAGED_TARGET_DEPLOYMENT_STATE_INVALID: ${path.relative(
+          cwd,
+          file
+        )} 无法读取: ${error.message}`
+      );
+    }
+  }
+  if (
+    target.bound?.lastDeploymentId ||
+    target.bound?.lastCandidateId ||
+    target.bound?.lastDeploymentStatus
+  ) {
+    return {
+      schemaVersion: 'openxiangda_target_deployment_v1',
+      deploymentId: target.bound.lastDeploymentId || null,
+      candidateId: target.bound.lastCandidateId || null,
+      status: target.bound.lastDeploymentStatus || null,
+      migratedFromProjectState: true,
+    };
+  }
+  return null;
+}
+
+function rememberTargetDeployment(
+  target,
+  deployment,
+  cwd = process.cwd()
+) {
+  const record = {
+    schemaVersion: 'openxiangda_target_deployment_v1',
+    logicalAppCode: target.logicalApp?.code || null,
+    targetName: target.targetName || null,
+    environmentId: target.environmentId || null,
+    appType: target.appType,
+    deploymentId: deployment.id,
+    candidateId: deployment.candidateId || null,
+    status: deployment.status,
+    updatedAt: new Date().toISOString(),
+  };
+  const file = managedTargetDeploymentFile(target, cwd);
+  writePrivateJsonAtomic(file, record);
+  return { record, file };
+}
+
 function readJsonInput(value, label, cwd = process.cwd()) {
   const input = String(value || '').trim();
   if (!input) throw new Error(`${label} 不能为空`);
@@ -648,9 +718,12 @@ module.exports = {
   normalizeSideEffectPolicyInput,
   normalizeTargetName,
   hasStateResourceMappings,
+  managedTargetDeploymentFile,
   readCandidate,
   readJsonInput,
+  readRememberedTargetDeployment,
   releaseExecutionPath,
+  rememberTargetDeployment,
   resolveManagedStateBinding,
   resolveEnvironmentTarget,
   saveCandidate,

package/lib/cli.js

@@ -139,7 +139,9 @@ const {
   normalizeReleaseSourceRevisionForBaseline,
   readCandidate,
   readJsonInput,
+  readRememberedTargetDeployment,
   releaseExecutionPath,
+  rememberTargetDeployment,
   resolveManagedStateBinding,
   resolveEnvironmentTarget,
   saveCandidate,
@@ -1104,6 +1106,128 @@ function writeManagedShip(changeId, value) {
   };
 }
 
+function normalizeManagedShipIntent(value = {}) {
+  return {
+    enabled: Boolean(value.enabled),
+    reason: String(value.reason || '').trim() || null,
+  };
+}
+
+function managedShipIntentMatches(left, right) {
+  const normalizedLeft = normalizeManagedShipIntent(left);
+  const normalizedRight = normalizeManagedShipIntent(right);
+  return (
+    normalizedLeft.enabled === normalizedRight.enabled &&
+    normalizedLeft.reason === normalizedRight.reason
+  );
+}
+
+function resolveManagedShipIntents(flags = {}, existingShip = null) {
+  const manifestReplacement = normalizeManagedShipIntent({
+    enabled: flags['replace-manifest'],
+    reason: flags.reason,
+  });
+  const requestedBaselineAdoption = normalizeManagedShipIntent({
+    enabled: flags['adopt-online-baseline'],
+    reason: flags['adoption-reason'],
+  });
+  const hasFrozenCandidate = Boolean(existingShip?.candidateId);
+  let baselineAdoption = requestedBaselineAdoption;
+
+  if (hasFrozenCandidate) {
+    const recordedReplacement = normalizeManagedShipIntent(
+      existingShip.manifestReplacement
+    );
+    if (!managedShipIntentMatches(recordedReplacement, manifestReplacement)) {
+      fail(
+        'RELEASE_SHIP_REPLACE_MANIFEST_INTENT_MISMATCH: --replace-manifest/--reason 必须与该 candidate 的预发发布意图完全一致；请使用 ship.json 记录的同一对参数'
+      );
+    }
+
+    const hasRecordedAdoption = Object.prototype.hasOwnProperty.call(
+      existingShip,
+      'baselineAdoption'
+    );
+    const recordedAdoption = normalizeManagedShipIntent(
+      existingShip.baselineAdoption
+    );
+    const adoptionExplicitlySupplied =
+      Object.prototype.hasOwnProperty.call(
+        flags,
+        'adopt-online-baseline'
+      ) ||
+      Object.prototype.hasOwnProperty.call(flags, 'adoption-reason');
+    if (
+      hasRecordedAdoption &&
+      adoptionExplicitlySupplied &&
+      !managedShipIntentMatches(recordedAdoption, requestedBaselineAdoption)
+    ) {
+      fail(
+        'RELEASE_SHIP_ADOPTION_INTENT_MISMATCH: --adopt-online-baseline/--adoption-reason 与该 candidate 的预发发布意图不一致；省略这两个参数可自动复用 ship.json 中的已冻结意图'
+      );
+    }
+    baselineAdoption = adoptionExplicitlySupplied
+      ? requestedBaselineAdoption
+      : recordedAdoption;
+  }
+
+  const effectiveFlags = { ...flags };
+  if (baselineAdoption.enabled) {
+    effectiveFlags['adopt-online-baseline'] = true;
+    effectiveFlags['adoption-reason'] = baselineAdoption.reason;
+  } else {
+    delete effectiveFlags['adopt-online-baseline'];
+    delete effectiveFlags['adoption-reason'];
+  }
+
+  return {
+    manifestReplacement,
+    baselineAdoption,
+    effectiveFlags,
+  };
+}
+
+function buildManagedShipCommand(
+  changeId,
+  profileName,
+  intents,
+  options = {}
+) {
+  const args = [
+    'openxiangda release ship',
+    '--change',
+    JSON.stringify(changeId),
+    '--profile',
+    JSON.stringify(profileName),
+  ];
+  if (options.confirmProduction) args.push('--confirm-production');
+  if (intents.manifestReplacement.enabled) {
+    args.push(
+      '--replace-manifest',
+      '--reason',
+      JSON.stringify(intents.manifestReplacement.reason)
+    );
+  }
+  if (intents.baselineAdoption.enabled) {
+    args.push(
+      '--adopt-online-baseline',
+      '--adoption-reason',
+      JSON.stringify(intents.baselineAdoption.reason)
+    );
+  }
+  return args.join(' ');
+}
+
+function managedShipFailure(error) {
+  return {
+    code: String(error?.code || 'OPENXIANGDA_DEPLOYMENT_FAILED'),
+    message: maskText(error?.message || String(error)).slice(0, 2000),
+    deploymentId: error?.deploymentId || null,
+    deploymentStatus: error?.deploymentStatus || 'failed',
+    recordedAt: new Date().toISOString(),
+  };
+}
+
 function writePrivateJsonAtomic(file, value) {
   fs.mkdirSync(path.dirname(file), { recursive: true });
   const tempFile = `${file}.${process.pid}.${Date.now()}.tmp`;
@@ -2717,14 +2841,6 @@ function applicationDeploymentApiPath(logicalAppCode, deploymentId, action) {
   return environmentSetApiPath(logicalAppCode, suffix);
 }
 
-function rememberTargetDeployment(target, deployment) {
-  target.bound.lastDeploymentId = deployment.id;
-  target.bound.lastCandidateId = deployment.candidateId || null;
-  target.bound.lastDeploymentStatus = deployment.status;
-  target.bound.updatedAt = new Date().toISOString();
-  saveProjectState(target.state);
-}
-
 function assertLocalCandidate(candidate) {
   if (
     !candidate?.id ||
@@ -2906,7 +3022,7 @@ async function markApplicationDeploymentFailed(
   error
 ) {
   try {
-    await requestWithAuth(
+    return await requestWithAuth(
       config,
       target.profileName,
       applicationDeploymentApiPath(
@@ -2930,6 +3046,7 @@ async function markApplicationDeploymentFailed(
     warn(
       `部署失败记录未写入平台: ${maskText(recordError?.message || recordError)}`
     );
+    return null;
   }
 }
 
@@ -3003,13 +3120,24 @@ async function deployApplicationCandidate(
         },
       };
     }
-    await markApplicationDeploymentFailed(
+    const failedDeployment = await markApplicationDeploymentFailed(
       config,
       target,
       logicalApp.code,
       deployment.id,
       error
     );
+    rememberTargetDeployment(
+      target,
+      failedDeployment?.id
+        ? failedDeployment
+        : {
+            ...deployment,
+            status: 'failed',
+          }
+    );
+    error.deploymentId = deployment.id;
+    error.deploymentStatus = failedDeployment?.status || 'failed';
     throw error;
   }
 }
@@ -3173,26 +3301,12 @@ async function runApplicationShipCommand(
   );
   const existingShip = readManagedShip(changeId);
   const confirmProduction = Boolean(flags['confirm-production']);
-  const manifestReplacement = {
-    enabled: Boolean(flags['replace-manifest']),
-    reason: String(flags.reason || '').trim() || null,
-  };
-
-  if (existingShip?.candidateId) {
-    const recordedReplacement = existingShip.manifestReplacement || {
-      enabled: false,
-      reason: null,
-    };
-    if (
-      Boolean(recordedReplacement.enabled) !== manifestReplacement.enabled ||
-      String(recordedReplacement.reason || '') !==
-        String(manifestReplacement.reason || '')
-    ) {
-      fail(
-        'RELEASE_SHIP_REPLACE_MANIFEST_INTENT_MISMATCH: --replace-manifest/--reason 必须与该 candidate 的预发发布意图完全一致；请使用 ship.json 记录的同一对参数'
-      );
-    }
-  }
+  const intents = resolveManagedShipIntents(flags, existingShip);
+  const {
+    manifestReplacement,
+    baselineAdoption,
+    effectiveFlags,
+  } = intents;
 
   if (confirmProduction && !existingShip?.preproductionDeploymentId) {
     fail(
@@ -3209,7 +3323,7 @@ async function runApplicationShipCommand(
         config,
         preproduction,
         {
-          ...flags,
+          ...effectiveFlags,
           change: changeId,
           'test-plan-json': JSON.stringify(
             managedShipTestPlan()
@@ -3225,6 +3339,7 @@ async function runApplicationShipCommand(
         sourceRevision: candidate.sourceRevision,
         candidateFile: created.candidateFile,
         manifestReplacement,
+        baselineAdoption,
       });
     } else {
       assertLocalCandidate(candidate);
@@ -3243,13 +3358,34 @@ async function runApplicationShipCommand(
       !deployment ||
       !['deployed', 'succeeded'].includes(deployment.status)
     ) {
-      const deployed = await deployApplicationCandidate(
-        config,
-        preproduction,
-        candidate,
-        { kind: 'deploy', flags }
-      );
-      deployment = deployed.deployment;
+      try {
+        const deployed = await deployApplicationCandidate(
+          config,
+          preproduction,
+          candidate,
+          { kind: 'deploy', flags: effectiveFlags }
+        );
+        deployment = deployed.deployment;
+      } catch (error) {
+        const failure = managedShipFailure(error);
+        writeManagedShip(changeId, {
+          status: 'preproduction_failed',
+          candidateId: candidate.id,
+          candidateHash: candidate.candidateHash,
+          preproductionEnvironment: preproduction.targetName,
+          preproductionDeploymentId: failure.deploymentId,
+          preproductionStatus: failure.deploymentStatus,
+          manifestReplacement,
+          baselineAdoption,
+          failure,
+          nextCommand: buildManagedShipCommand(
+            changeId,
+            preproduction.profileName,
+            intents
+          ),
+        });
+        throw error;
+      }
     }
     const saved = writeManagedShip(changeId, {
       status: 'awaiting_production_confirmation',
@@ -3262,17 +3398,17 @@ async function runApplicationShipCommand(
         deployment.targetAppReleaseId || null,
       preproductionStatus: deployment.status,
       manifestReplacement,
+      baselineAdoption,
+      failure: null,
       preparedAt:
         existingShip?.preparedAt ||
         new Date().toISOString(),
-      nextCommand:
-        `openxiangda release ship --change ${changeId} ` +
-        '--confirm-production' +
-        (manifestReplacement.enabled
-          ? ` --replace-manifest --reason ${JSON.stringify(
-              manifestReplacement.reason
-            )}`
-          : ''),
+      nextCommand: buildManagedShipCommand(
+        changeId,
+        preproduction.profileName,
+        intents,
+        { confirmProduction: true }
+      ),
     });
     return {
       phase: 'preproduction',
@@ -3394,17 +3530,38 @@ async function runApplicationShipCommand(
     manualAcceptance,
     preproductionStatus: preproductionDeployment.status,
   });
-  const promoted = await deployApplicationCandidate(
-    config,
-    production,
-    candidate,
-    {
-      kind: 'promotion',
-      sourceEnvironmentId:
-        preproduction.environmentId,
-      flags,
-    }
-  );
+  let promoted;
+  try {
+    promoted = await deployApplicationCandidate(
+      config,
+      production,
+      candidate,
+      {
+        kind: 'promotion',
+        sourceEnvironmentId:
+          preproduction.environmentId,
+        flags: effectiveFlags,
+      }
+    );
+  } catch (error) {
+    const failure = managedShipFailure(error);
+    writeManagedShip(changeId, {
+      status: 'production_failed',
+      productionEnvironment: production.targetName,
+      productionDeploymentId: failure.deploymentId,
+      productionStatus: failure.deploymentStatus,
+      manifestReplacement,
+      baselineAdoption,
+      failure,
+      nextCommand: buildManagedShipCommand(
+        changeId,
+        preproduction.profileName,
+        intents,
+        { confirmProduction: true }
+      ),
+    });
+    throw error;
+  }
   const saved = writeManagedShip(changeId, {
     status: 'completed',
     productionEnvironment: production.targetName,
@@ -3412,6 +3569,7 @@ async function runApplicationShipCommand(
     productionAppReleaseId:
       promoted.deployment.targetAppReleaseId || null,
     productionStatus: promoted.deployment.status,
+    failure: null,
     completedAt: new Date().toISOString(),
   });
   return {
@@ -3458,7 +3616,7 @@ async function runApplicationEnvironmentReleaseCommand(
       readStringFlag(flags, 'deployment') ||
       readStringFlag(flags, 'deployment-id') ||
       positional[0] ||
-      target.bound.lastDeploymentId;
+      readRememberedTargetDeployment(target)?.deploymentId;
     const reason = readStringFlag(flags, 'reason');
     if (!deploymentId || reason.length < 8) {
       fail(
@@ -3486,7 +3644,7 @@ async function runApplicationEnvironmentReleaseCommand(
     readStringFlag(flags, 'candidate') ||
     readStringFlag(flags, 'candidate-id') ||
     positional[0] ||
-    target.bound.lastCandidateId;
+    readRememberedTargetDeployment(target)?.candidateId;
   if (subcommand === 'deploy') {
     if (target.environmentKind !== 'preproduction') {
       fail('release deploy 只允许目标为 preproduction');
@@ -3527,7 +3685,7 @@ async function runApplicationEnvironmentReleaseCommand(
     const deploymentId =
       readStringFlag(flags, 'deployment') ||
       readStringFlag(flags, 'deployment-id') ||
-      target.bound.lastDeploymentId;
+      readRememberedTargetDeployment(target)?.deploymentId;
     if (!deploymentId || !flags['evidence-json']) {
       fail(
         'release test 必须提供 --deployment <id>（首次可省略）和 --evidence-json <JSON|file>'
@@ -3636,7 +3794,7 @@ async function release(args) {
       '  openxiangda release app-finalize --change <id> --staged-resources-json <JSON|file> --profile <name>',
       '说明:',
       '  - ship 是环境托管应用的两段式快车道：首次只部署预发并停止；确认预发结果后，第二次以同一 candidate 晋级正式。人工验收备注可选。',
-      '  - 已合入主线但线上来自多次历史 lineage 的精确非删除恢复可显式使用 --adopt-online-baseline 与 --adoption-reason；仍保留冻结 Head、CAS、租约、staged children 和单次 App finalize。',
+      '  - 已合入主线但线上来自多次历史 lineage 的精确非删除恢复可显式使用 --adopt-online-baseline 与 --adoption-reason；预发冻结后，正式确认会从 ship.json 自动复用同一意图，仍保留冻结 Head、CAS、租约、staged children 和单次 App finalize。',
       '  - ship 的 --replace-manifest 与 --reason 必须成对，只透传给精确 Backend Function/Automation stage；正式确认必须复用与预发完全相同的参数。',
       '  - ship 当前不支持 --dry-run；任何未声明参数都会在 candidate/deployment 写入前 fail-closed。需要只读检查时使用 environment status/diff 与 release status。',
       '  - publish 默认等待租约并按私有执行日志恢复；上次写结果不确定时必须只读核对后显式 --resume-after-review。',
@@ -10719,6 +10877,27 @@ async function appFunction(args) {
   if (subcommand === 'invoke') {
     const [functionCode] = positional;
     if (!functionCode) fail('用法: openxiangda function invoke <functionCode> [--body-json file|json]');
+    if (
+      target.logicalApp &&
+      Object.keys(target.state.targets || {}).length > 1 &&
+      !flags.environment &&
+      !flags.target
+    ) {
+      fail(
+        'FUNCTION_INVOKE_ENVIRONMENT_REQUIRED: 托管应用调用 Function 必须显式提供 --environment <target>，避免把预发结果误判为生产结果'
+      );
+    }
+    warn(
+      [
+        'Resolved target:',
+        'operation=function invoke',
+        `profile=${target.profileName}`,
+        `environment=${target.targetName || 'legacy'}`,
+        `kind=${target.environmentKind || 'unmanaged'}`,
+        `appType=${target.appType}`,
+        `environmentId=${target.environmentId || '-'}`,
+      ].join(' ')
+    );
     const body = readDirectJsonBody(flags, 'function invoke', { optional: true });
     const openXiangdaApiRequest = buildOpenXiangdaFunctionInvokeRequest(
       target.appType,

package/openxiangda-skills/SKILL.md

@@ -106,7 +106,7 @@ openxiangda release ship --change <release-change> --profile <name> \
 
 For a workspace registered by `openxiangda environment init` or connected to an existing set with `openxiangda environment attach`, production is never a direct publish target. Use the two-phase `release ship` fast path by default. Its first invocation creates/deploys the immutable candidate to preproduction and always returns `awaiting_production_confirmation`; it cannot promote. A second invocation with `--confirm-production` promotes the exact same candidate hash. Real human acceptance is the recommended normal practice and can be recorded with optional `--acceptance-note`, but do not invent an acceptance note and do not treat it as a universal hard platform gate when the user explicitly authorizes a low-risk or emergency promotion. The lower-level candidate/deploy/test/promote commands are recovery primitives, not the normal agent loop. Preproduction and production keep independent app/resource/data identities in `.openxiangda/state.json`; do not copy IDs between targets. `environment attach` may seed only the matching legacy app binding into preproduction and must leave production empty. Only during authorized commissioning/reclassification may `environment swap --reason "..." --confirm-production` atomically exchange the two existing roles; it preserves each app's data and Release Heads, remaps local resource IDs by appType, and does not enable production side effects by default. To change only one environment's side-effect policy, run `environment policy update <kind|id> --side-effect-policy-json <JSON|file> --reason "..." --dry-run` first, then repeat without `--dry-run`; never use swap for this. Policy reads are forward-compatible: patch mode validates only caller-supplied fields and preserves unrecognized historical fields, while `--full-replace` validates the supplied complete target and intentionally removes omissions. The update is revision-CAS, production needs `--confirm-production`, and `organizationWrites=explicit_capability_only` still requires `app:organization:manage`. Keep release hard gates limited 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 was intentionally configured. Use `openxiangda studio` for the loopback-only developer view of bindings, drift, evidence, and safe next actions.
 
-For an audited catch-up whose exact non-delete targets are already merged but whose active resources combine multiple historical release lineages, the first ship invocation may add `--adopt-online-baseline --adoption-reason "..."`. Ship validates the pair before candidate/deployment creation and forwards it only to exact scoped resource stages; frozen online heads, change/lease ownership, delete/prune/force rejection, server CAS, staged-child verification, and the single atomic App finalize remain mandatory.
+For an audited catch-up whose exact non-delete targets are already merged but whose active resources combine multiple historical release lineages, the first ship invocation may add `--adopt-online-baseline --adoption-reason "..."`. Ship validates and freezes the pair before candidate/deployment creation; the later `--confirm-production` invocation automatically reuses the same intent from the private ship journal and forwards it only to exact scoped resource stages. Frozen online heads, change/lease ownership, delete/prune/force rejection, server CAS, staged-child verification, and the single atomic App finalize remain mandatory.
 
 When an environment-managed release intentionally replaces complete Function/Automation manifests, `release ship` may add the inseparable `--replace-manifest --reason "..."` pair. The reason must be at least 8 characters; only an exact Backend selector receives it, and the production confirmation must repeat the exact preproduction pair. It never widens Form, Workflow, Runtime, configuration, wildcard, or app-wide stages.
 
@@ -136,7 +136,7 @@ The lease is app-level promotion ownership, while worktree ownership prevents tw
 
 ## Always
 
-- Treat `.openxiangda/state.json` as CLI-maintained ID mapping, not a task lock or merge mechanism.
+- Treat `.openxiangda/state.json` as CLI-maintained durable ID/environment mapping, not a task lock or merge mechanism. Volatile candidate/deployment progress belongs under the private `.openxiangda/releases/` journal.
 - Keep resource IDs isolated per profile; never copy IDs from dev to prod.
 - Use platform roles, permission groups, public grants, and backend Function checks for authorization; frontend hiding is presentation only.
 - Keep tokens and secrets out of project files and chat.

package/openxiangda-skills/references/workspace-state.md

@@ -1,6 +1,6 @@
 # Workspace State
 
-OpenXiangda project state lives in `.openxiangda/state.json`.
+OpenXiangda durable project bindings live in `.openxiangda/state.json`. Volatile release execution, candidate, deployment, and recovery progress lives under the private `.openxiangda/releases/` journal and must not be copied into the durable ID map.
 
 Tokens never belong in the project. User tokens live in `~/.openxiangda/profiles.json`. Shared workspace env values such as `APP_OSS_*` live in `~/.openxiangda/.env` by default, while project `.env` is only a local override.
 
@@ -95,7 +95,7 @@ Environment-managed workspaces add a logical application and target-specific bin
 ## Rules
 
 - Profile is the deployment boundary.
-- For an environment-managed logical application, the selected target is the deployment boundary inside the profile. `preproduction` and `production` own independent appType, resource IDs, release/deployment state, data, and side-effect policy.
+- For an environment-managed logical application, the selected target is the deployment boundary inside the profile. `preproduction` and `production` own independent appType, resource IDs, Release Heads, data, and side-effect policy. Their volatile deployment progress is isolated in `.openxiangda/releases/targets/`.
 - `baseUrl` is the backend API base. On standard private deployments it is `<origin>/service`; management pages use `/platform`, and app runtime pages use `/view`.
 - Local state is authoritative for app binding. If a workspace has no `appType` for the target profile, create a new app/workspace with `openxiangda workspace init <dir> --profile <name> --app-name "应用名称"`.
 - Do not search platform apps or reuse similar names unless the user explicitly asks to reuse an existing app or provides an `appType`.
@@ -108,6 +108,7 @@ Environment-managed workspaces add a logical application and target-specific bin
 - This protects the ID map from truncation/lost updates. Concurrent development still uses separate Git worktrees/branches; `.openxiangda/worktree-owner.json` binds one worktree to one active `CODEX_THREAD_ID` and blocks a second task at SDD context/publish time.
 - A prod publish must not read dev IDs.
 - Never copy target resource bindings. Use `openxiangda environment use <target>` or pass `--environment <target>` and let the CLI populate that target from its own deployment.
-- Managed targets cannot use direct `release publish`; use two-phase `release ship`. The first invocation only prepares preproduction and stops; after confirming the preproduction result, a separate invocation with `--confirm-production` promotes the same candidate. Human acceptance is recommended and may be recorded with optional `--acceptance-note`.
+- Managed targets cannot use direct `release publish`; use two-phase `release ship`. The first invocation only prepares preproduction and stops; after confirming the preproduction result, a separate invocation with `--confirm-production` promotes the same candidate. A frozen baseline-adoption intent is automatically reused from `ship.json`; an explicitly repeated but different intent fails before a request. Human acceptance is recommended and may be recorded with optional `--acceptance-note`.
+- In a managed workspace with multiple targets, `function invoke` must include `--environment <target>` and reports the resolved target on stderr before sending the request.
 - Change a single target's side-effect policy with `openxiangda environment policy update <kind|id> --side-effect-policy-json <JSON|file> --reason "..." --dry-run`, inspect the exact diff, then repeat without `--dry-run`. The write uses the server revision as CAS and updates local `revision`; it does not swap roles or alter Release Heads. Omitted fields are preserved unless `--full-replace` is explicit, and production additionally requires `--confirm-production`.
 - Before publishing to another platform, run `openxiangda workspace bind --profile <name> --app-type <APP_XXX>`.

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

@@ -109,7 +109,7 @@ openxiangda release ship --change <release-change> --profile <name> \
 
 Once `environment init` registers a logical application, or `environment attach` connects an existing workspace, `preproduction` and `production` are separate target bindings with separate app/resource/data IDs. Never copy IDs between them. Existing legacy resource mappings may seed only the target whose appType matches (normally preproduction); production stays empty. The normal path is the two-phase `release ship`. Its first invocation creates and deploys the immutable candidate only to preproduction and stops at `awaiting_production_confirmation`. A different, later invocation with `--confirm-production` promotes the exact same candidate and fresh deployment-bound evidence. Human acceptance is recommended and an optional `--acceptance-note` records it, but it is not a universal hard platform gate for explicitly authorized low-risk or emergency releases. Direct `release publish` to either managed target fails closed. Only authorized commissioning/reclassification may run `environment swap --reason "..." --confirm-production`; the atomic operation preserves each app's data and Release Heads, remaps local resources by appType, and keeps existing side-effect restrictions unless explicit replacement policies are supplied. A single environment policy change uses `environment policy update <kind|id>` with a GET-only `--dry-run` first; patch mode validates only caller-supplied fields and preserves unrecognized historical fields, while `--full-replace` validates the supplied complete target and intentionally removes omissions. It uses revision CAS and never swaps roles or Release Heads. Production writes require `--confirm-production`. `organizationWrites=explicit_capability_only` only removes the environment deny and never bypasses `app:organization:manage`. Keep release hard gates limited 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 was intentionally configured. `openxiangda studio` is the local loopback-only developer view and exposes only registered safe actions.
 
-When a reviewed catch-up contains exact non-delete targets that are already on authoritative mainline but the active application combines several historical release lineages, the first ship invocation may add `--adopt-online-baseline --adoption-reason "..."`. Ship validates the pair before candidate/deployment creation and forwards it only to exact scoped resource stages. It does not relax frozen online heads, change/lease ownership, delete/prune/force rejection, server CAS, staged-child verification, or the single atomic App finalize.
+When a reviewed catch-up contains exact non-delete targets that are already on authoritative mainline but the active application combines several historical release lineages, the first ship invocation may add `--adopt-online-baseline --adoption-reason "..."`. Ship validates and freezes the pair before candidate/deployment creation. The later `--confirm-production` invocation automatically reuses the same intent from `ship.json` and forwards it only to exact scoped resource stages. It does not relax frozen online heads, change/lease ownership, delete/prune/force rejection, server CAS, staged-child verification, or the single atomic App finalize.
 
 An environment-managed release may intentionally replace complete Function/Automation manifests with `release ship --replace-manifest --reason "..."`. The two flags are inseparable, the reason is at least 8 characters, only an exact Backend stage receives them, and production confirmation must repeat the exact preproduction intent. They never widen Form, Workflow, Runtime, configuration, wildcard, or app-wide stages.
 
@@ -137,7 +137,9 @@ openxiangda platform use dev
 
 Root, `/platform`, and `/view` URLs normalize to `<origin>/service`. Normal work uses the user's profile token and `/openxiangda-api/v1`; never ask for AK/SK. Each profile has independent `appType` and resource IDs.
 
-Local state lives in `.openxiangda/state.json`; user tokens live in `~/.openxiangda/profiles.json`; shared environment values live in `~/.openxiangda/.env`. Never copy resource IDs between profiles or put tokens in the workspace.
+Durable local resource/environment mappings live in `.openxiangda/state.json`; volatile candidate/deployment progress lives in the private `.openxiangda/releases/` journal. User tokens live in `~/.openxiangda/profiles.json`; shared environment values live in `~/.openxiangda/.env`. Never copy resource IDs between profiles or put tokens in the workspace.
+
+For an environment-managed workspace with more than one target, `function invoke` requires an explicit `--environment <target>` and prints the resolved profile, environment, kind, appType, and environmentId to stderr before the request. Treat this line as part of the diagnostic evidence; do not infer production behavior from an invocation whose resolved target is preproduction.
 
 ## Workspace creation/binding
 

package/package.json

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

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

@@ -35,7 +35,9 @@ This is an OpenXiangda React SPA workspace. See [AGENTS.md](mdc:AGENTS.md) for f
 - Select logical resource codes with `--only`, or one code with `--code`; type-wide/app-wide release requires an approved dependency closure.
 - Source-triggered Function/Automation publishing uses server-side source-field PATCH 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 Backend Release manifest create without `--replace-manifest`; replacing an existing whole manifest requires `--replace-manifest --reason "..."`. On `SOURCE_BASE_DIVERGED` or `RESOURCE_FIELD_CONFLICT`, reconcile, rebuild, and re-plan.
 - 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.
+- 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.
 - Backend permissions, public-access grants, and App Function role/scope checks are authoritative.

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

@@ -31,7 +31,9 @@ This is an OpenXiangda React SPA workspace. Read [AGENTS.md](AGENTS.md) for full
 - 默认按逻辑资源 code 使用 `--only` 或单资源 `--code`；全类型/全应用发布必须由批准的依赖闭包明确覆盖。
 - Function/Automation 源码触发默认走服务端 source-field PATCH，保留线上 bindings/contracts/metadata/trigger/view/enabled/published state；无源码且 `definitionJson.version="v3"` 完整的新建 Automation 自动走 manifest create，只有替换已有整包 manifest 才必须加 `--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 --adopt-online-baseline --adoption-reason "..."` 会把审计意图冻结进私有 ship journal，后续 `--confirm-production` 自动复用；显式传入不同参数会在任何请求前失败。
 - 环境托管 `release ship --replace-manifest --reason "..."` 必须成对、reason 至少 8 字符且仅限精确 Backend selector；正式确认复用与预发完全相同的参数，不透传 Form/Workflow/Runtime/配置或全量步骤。
+- 多 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，且默认不放开副作用。
 - 单独修改某个环境的副作用策略只能使用 `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/openxiangda-react-spa/AGENTS.md

@@ -55,7 +55,7 @@ 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` 提供仅本机访问的开发者页面，用于查看绑定、漂移、候选、部署、证据和下一安全动作。
 
-只有已审计代码早已进入权威主线、而精确非删除目标在线上来自多次历史发布且无法对应单一 Git 基线时，第一次 `release ship` 才可增加 `--adopt-online-baseline --adoption-reason "..."`。该参数不会放松冻结 online heads、change/lease、删除/全量拒绝、服务端 CAS、staged children 或单次 App finalize 原子激活。
+只有已审计代码早已进入权威主线、而精确非删除目标在线上来自多次历史发布且无法对应单一 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

@@ -39,7 +39,8 @@ This is a `sy-lowcode-app-workspace` managed by the `openxiangda` CLI. See [AGEN
 - Account/role/permission/RBAC/organization-account/query-param authorization work must choose a mode first: `managed-platform-account`, `existing-platform-user-assignment`, `static-role-permission`, or `query-param-context`, then write the permission matrix.
 - Roles that create roles, assign members, grant API permissions, maintain permission groups, or manage organization accounts must declare `apiPermissionCodes` in `src/resources/roles/<code>.json`, such as `app:role:manage`, `app:page-permission-group:manage`, `app:form-permission-group:manage`, and `app:organization:manage`.
 - Confirm current profile before any write: `openxiangda env --profile <name>`.
-- `.openxiangda/state.json` is the authoritative profile → appType → resource-ID map; CLI maintains it, do not hand-edit.
+- `.openxiangda/state.json` is the authoritative durable profile → appType → resource-ID map; volatile release/deployment progress stays in the private `.openxiangda/releases/` journal. CLI maintains both; do not hand-edit.
+- In a managed workspace with multiple targets, pass `--environment <target>` to `function invoke` and verify the resolved target printed on stderr.
 - User tokens live in `~/.openxiangda/profiles.json`; shared env in `~/.openxiangda/.env`.
 - Form fields need user-facing `placeholder`; use `SelectField` / `RadioField` for enums, `linkedForm` SelectField for cross-form sources.
 - Form-entry component priority: OpenXiangda platform components → `antd` / `antd-mobile` wrappers → custom business component only when neither fits.

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

@@ -39,7 +39,8 @@ This is a `sy-lowcode-app-workspace` managed by the `openxiangda` CLI. Read [AGE
 - 账号/角色/权限/RBAC/组织账号/查询参数授权需求先选权限模式：`managed-platform-account` / `existing-platform-user-assignment` / `static-role-permission` / `query-param-context`，并输出权限矩阵。
 - 角色能新增角色、分配成员、授接口权限、维护权限组或管理组织账号时，`src/resources/roles/<code>.json` 必须声明 `apiPermissionCodes`，例如 `app:role:manage`、`app:page-permission-group:manage`、`app:form-permission-group:manage`、`app:organization:manage`。
 - 任何写操作前确认当前 profile：`openxiangda env --profile <name>`。
-- `.openxiangda/state.json` 是 profile 到 appType / 资源 ID 的权威映射，由 CLI 维护，不要手改。
+- `.openxiangda/state.json` 是 profile 到 appType / 资源 ID 的持久权威映射；临时 release/deployment 进度只写私有 `.openxiangda/releases/` journal。两者均由 CLI 维护，不要手改。
+- 多 target 的托管工作区执行 `function invoke` 必须显式传 `--environment <target>`，并核对 stderr 回显的最终 target。
 - 用户 token 在 `~/.openxiangda/profiles.json`；共享 env 在 `~/.openxiangda/.env`。
 - 表单字段必须有 user-facing `placeholder`；选项使用 `SelectField` / `RadioField`，跨表用 `linkedForm` SelectField。
 - 表单录入组件顺序：OpenXiangda 平台组件 → `antd` / `antd-mobile` 包装 → 必要时自定义业务组件。

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

@@ -59,7 +59,7 @@
 - ✅ 相同 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>`。
 - ✅ 已通过 `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 模式才阻断。
-- ✅ 只有已审计目标早已进入权威主线、线上却由多次历史 lineage 组成且无法对应单一 Git 基线时，第一次 `release ship` 才可增加 `--adopt-online-baseline --adoption-reason "..."`；仅允许精确非删除 selectors，冻结 Head、change/lease、服务端 CAS、staged children 与单次 App finalize 仍是硬门禁。
+- ✅ 只有已审计目标早已进入权威主线、线上却由多次历史 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。
 - ✅ 本地开发者可运行 `openxiangda studio` 查看两套环境、差异、候选、部署和测试证据；该页面只监听回环地址且只暴露注册动作，生产操作仍需显式确认。