openxiangda 1.0.207 → 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.
 
@@ -202,7 +202,7 @@ openxiangda resource publish function --code customer_get --change <change> --pr
 
 Exact `--only` / `--code` selectors are applied before unrelated manifests, source dependencies, and JS_CODE targets are read or built. Shared/transitive dependencies of the selected targets remain in scope; omitting a selector intentionally preserves full-workspace validation and planning. Resource commands use the packaged canonical scoped builder for standard workspaces, so an older checked-in `scripts/build-js-code.mjs` does not need to be upgraded before the installed CLI gains this optimization; refresh the workspace template only when developers also need the same behavior from a manual `pnpm build-js-code` command.
 
-For source-only Function/Automation changes, the final command does not reconstruct whole definitions with client-side GET+PUT. `release begin` captures the Git/change baseline, one preflight covers every selected code, and Backend Release performs one `prepare -> verify -> activate` sequence for all eligible updates. Inspect history with `openxiangda release backend-head|backend-list|backend-detail`, compare it with `backend-diff`, or create an audited immutable rollback with `backend-rollback <releaseId> --change <change> --reason "..."`. Always merge/push the frozen SHA and run `release end` when promotion finishes. A lost or expired lease retains the pending-mainline evidence instead of silently clearing it.
+For source-only Function/Automation changes, the final command does not reconstruct whole definitions with client-side GET+PUT. `release begin` captures the Git/change baseline, one preflight covers every selected code, and Backend Release performs one `prepare -> verify -> activate` sequence for all eligible updates. Repository identity is alias-aware but fail-closed: when a clone-derived primary ID differs from the frozen source base, the CLI uses the frozen canonical ID only if it is present in `releaseSourceRevision.repoAliases`; Backend, Workflow, and Root App Release writes all carry that same ID, while a disjoint identity set fails before prepare. Inspect history with `openxiangda release backend-head|backend-list|backend-detail`, compare it with `backend-diff`, or create an audited immutable rollback with `backend-rollback <releaseId> --change <change> --reason "..."`. Always merge/push the frozen SHA and run `release end` when promotion finishes. A lost or expired lease retains the pending-mainline evidence instead of silently clearing it.
 
 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.
 

package/lib/application-environments.js

@@ -247,6 +247,53 @@ function normalizeManagedReleaseSourceRevision(
   };
 }
 
+function normalizeReleaseSourceRevisionForBaseline(
+  target,
+  sourceBase,
+  sourceRevision,
+  options = {}
+) {
+  const revision = normalizeManagedReleaseSourceRevision(
+    target,
+    sourceRevision,
+    options
+  );
+  const expectedRepositoryId = String(
+    sourceBase?.repo || sourceBase?.repositoryId || ''
+  )
+    .trim()
+    .toLowerCase();
+  if (!expectedRepositoryId) return revision;
+  const repositoryAliases = normalizeIdentityList([
+    revision?.repo,
+    revision?.repositoryId,
+    ...(Array.isArray(revision?.repoAliases) ? revision.repoAliases : []),
+  ]);
+  if (!repositoryAliases.includes(expectedRepositoryId)) {
+    const code =
+      String(options.errorCode || '').trim() ||
+      'RELEASE_SOURCE_REPOSITORY_MISMATCH';
+    const error = new Error(
+      `${code}: 当前 Git 仓库与冻结 change baseline 仓库不一致`
+    );
+    error.code = code;
+    error.details = {
+      expectedRepositoryId,
+      repositoryAliases,
+    };
+    throw error;
+  }
+  return {
+    ...revision,
+    repo: expectedRepositoryId,
+    repositoryId: expectedRepositoryId,
+    repoAliases: normalizeIdentityList([
+      expectedRepositoryId,
+      ...repositoryAliases,
+    ]),
+  };
+}
+
 function normalizeManagedChangeSourceBase(
   target,
   sourceBase,
@@ -427,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} 不能为空`);
@@ -597,12 +714,16 @@ module.exports = {
   normalizeEnvironmentKind,
   normalizeManagedChangeSourceBase,
   normalizeManagedReleaseSourceRevision,
+  normalizeReleaseSourceRevisionForBaseline,
   normalizeSideEffectPolicyInput,
   normalizeTargetName,
   hasStateResourceMappings,
+  managedTargetDeploymentFile,
   readCandidate,
   readJsonInput,
+  readRememberedTargetDeployment,
   releaseExecutionPath,
+  rememberTargetDeployment,
   resolveManagedStateBinding,
   resolveEnvironmentTarget,
   saveCandidate,

package/lib/cli.js

@@ -136,9 +136,12 @@ const {
   normalizeEnvironmentKind,
   normalizeManagedChangeSourceBase,
   normalizeManagedReleaseSourceRevision,
+  normalizeReleaseSourceRevisionForBaseline,
   readCandidate,
   readJsonInput,
+  readRememberedTargetDeployment,
   releaseExecutionPath,
+  rememberTargetDeployment,
   resolveManagedStateBinding,
   resolveEnvironmentTarget,
   saveCandidate,
@@ -1103,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`;
@@ -2716,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 ||
@@ -2905,7 +3022,7 @@ async function markApplicationDeploymentFailed(
   error
 ) {
   try {
-    await requestWithAuth(
+    return await requestWithAuth(
       config,
       target.profileName,
       applicationDeploymentApiPath(
@@ -2929,6 +3046,7 @@ async function markApplicationDeploymentFailed(
     warn(
       `部署失败记录未写入平台: ${maskText(recordError?.message || recordError)}`
     );
+    return null;
   }
 }
 
@@ -3002,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;
   }
 }
@@ -3172,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(
@@ -3208,7 +3323,7 @@ async function runApplicationShipCommand(
         config,
         preproduction,
         {
-          ...flags,
+          ...effectiveFlags,
           change: changeId,
           'test-plan-json': JSON.stringify(
             managedShipTestPlan()
@@ -3224,6 +3339,7 @@ async function runApplicationShipCommand(
         sourceRevision: candidate.sourceRevision,
         candidateFile: created.candidateFile,
         manifestReplacement,
+        baselineAdoption,
       });
     } else {
       assertLocalCandidate(candidate);
@@ -3242,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',
@@ -3261,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',
@@ -3393,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,
@@ -3411,6 +3569,7 @@ async function runApplicationShipCommand(
     productionAppReleaseId:
       promoted.deployment.targetAppReleaseId || null,
     productionStatus: promoted.deployment.status,
+    failure: null,
     completedAt: new Date().toISOString(),
   });
   return {
@@ -3457,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(
@@ -3485,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');
@@ -3526,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>'
@@ -3635,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。',
@@ -10718,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,
@@ -18210,8 +18390,9 @@ async function ensureOwnedImmutableReleasePublishContext(
       `${releaseKind} 只接受与本地冻结基线匹配的 stored lease；外部 opaque lease 不能用于原子发布`
     );
   }
-  const sourceRevision = normalizeManagedReleaseSourceRevision(
+  const sourceRevision = normalizeReleaseSourceRevisionForBaseline(
     target,
+    baseline.sourceBase || {},
     baseline.releaseSourceRevision || {},
     { errorCode: 'RELEASE_SOURCE_REPOSITORY_MISMATCH' }
   );

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.
 
@@ -118,7 +118,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.
 
-`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 are aliases of the same repository; genuinely different remotes still fail closed.
+`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.
 
@@ -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

@@ -63,6 +63,8 @@ Function/Automation source analysis also extracts statically declared Form filte
 
 Source-triggered Function/Automation targets use Backend Release v2 when the platform exposes that capability. One child may mix source-backed create, source-free declarative Automation manifest create, source-only update, and manifest replacement update through explicit per-resource `operation/mode`; the CLI freezes the current Backend Release parent plus Git/change baseline, then runs `prepare -> verify -> activate` or stops verified for `--stage-only`. A new Automation with a complete `definitionJson.version="v3"` and no `sourceFile` automatically uses manifest create without `--replace-manifest`; an incomplete definition still fails closed. Activation CAS-checks the entire set and applies all updates in one transaction. `--stage-only` and Secret-bound Function publishing fail closed when Backend Release v2 is unavailable; compatibility fallback is limited to non-staged, non-Secret publishing after an explicit Backend head 404. Existing online bindings, contracts, metadata, trigger/view configuration, and enabled/published state remain unchanged; noops do not advance versions/timestamps. A deliberate whole-definition replacement of an existing resource requires exact `--only/--code` and `--replace-manifest --reason "<why>"`; SDD bypass does not imply replacement authority.
 
+Repository identity remains strict across immutable releases. If a clone-derived primary repository ID differs from the frozen change source base, the CLI may canonicalize Backend, Workflow, and Root App Release payloads to the frozen ID only when that ID is already present in `releaseSourceRevision.repoAliases`; no alias intersection fails with `RELEASE_SOURCE_REPOSITORY_MISMATCH` before prepare.
+
 Functions with a top-level `secretRefs` field use `backend_release_v2`, including an explicit empty list that removes bindings. This path never falls back to source PATCH. It requires the per-app Secret capability probe to grant `app_function_secrets_v1`, `trusted_node_v2`, `backend_release_v2`, and `atomic_staged_children_v2`; otherwise plan/publish fails closed.
 
 For whole-app atomic activation, publish the exact mixed Function/Automation scope with `resource publish function,automation --only function:<code>,automation:<code> --stage-only --change <change>`. This stops after Backend Release verify and returns `stagedResource` plus every handled selector; the CLI automatically merges it with other changed staged children in `.openxiangda/releases/<change>/staged-resources.json` for `release app-finalize --staged-resources-json`. A Backend Release that was already activated returns `activeResource` and must not be presented as staged.
@@ -107,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.
 
@@ -135,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.207",
+  "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

@@ -26,7 +26,7 @@ This is an OpenXiangda React SPA workspace. See [AGENTS.md](mdc:AGENTS.md) for f
 - L0 read-only/docs/tests need no SDD; L1 narrow reversible fixes record exact scope without a redundant second confirmation; schema, business Functions, Automation/Workflow, permissions, auth/public access, data writes, and runtime/config are L2/L3 full-SDD work. Live evidence/archive are post-release stages.
 - Very small copy/style/binding changes may use `openxiangda sdd quick <change> ...`; quick mode records exact low-risk scope without a redundant proposal/approval loop when the user already requested it.
 - SDD is streamlined by default: approval and exact structured scope are hard gates, while unfinished task/evidence/spec prose only warns. Configure `strictDocumentation: true` only when prose must block.
-- Before platform writes, run `release begin` from a clean local main/master that exactly equals the authoritative remote tip. Feature branches and unpushed mainline commits fail before any write. After activation, run `integration-status` and `release end`; no post-release merge is needed.
+- Before platform writes, run `release begin` from a clean local main/master that exactly equals the authoritative remote tip. Feature branches and unpushed mainline commits fail before any write. 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.
 - Managed preproduction and production targets own independent app/resource/data identities and side-effect policy. Existing workspaces use `environment attach`; only an appType-matching legacy binding may seed preproduction and production starts empty. Never direct-publish or copy IDs across them; use `openxiangda studio` to inspect candidate, evidence, and drift state. 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.
 - Account/role/permission/RBAC/organization-account/query-param authorization work must run `openxiangda design gates --topic permissions --json`, choose `managed-platform-account`, `existing-platform-user-assignment`, `static-role-permission`, or `query-param-context`, and write the permission matrix.
@@ -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,8 +31,10 @@ 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/配置或全量步骤。
-- Promotion 必须持有 `release begin/end` 租约；`release begin` 只接受与权威远端 tip 完全一致的 clean main/master。feature branch 或未 push 主线在任何写入前失败。激活后直接运行 `integration-status` 和 `release end`，不再补做发布后合并。
+- 多 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 模式才阻断。
 - React SPA 路由由 `src/app/router.tsx` 管理，前端包通过 `openxiangda runtime deploy` 发布。

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、配置资源或全量范围。
 
@@ -82,7 +82,7 @@ App Function 第三方凭据只能在 Function manifest 顶层声明 `secretRefs
 
 `openxiangda runtime deploy --no-activate` 会构建并上传不可变预览版本；发布前先提交所有可能进入构建的源码/配置。所有 Runtime deploy（包括 `--no-activate`）都会先获取应用发布 lease，并在任何构建和上传前冻结 clean `HEAD` 与当前 active Runtime 父血缘；旧分支返回 `RUNTIME_SOURCE_BASE_DIVERGED`，不能先上传旧 preview 再激活。`openspec/` SDD 证据和生成/状态目录不算源码 dirty。仅审批的回退可使用 `--allow-runtime-rollback --reason "至少 8 个字符"`；`--no-build` 不会跳过守卫。不要手工修改 `dist/index.html`。
 
-Function/Automation 走 Backend Release v2；同一个 child 可以混合源码 create、无 `sourceFile` 的完整 v3 声明式 Automation manifest create、source-only update 与显式 manifest replacement，并对整个集合做 CAS。声明式 create 自动选路且不需要 `--replace-manifest`；替换已有资源才需要该显式授权。正式多资源发布必须使用 canonical 精确 selector 和 `--stage-only`。`release begin` 只接受与权威远端默认主分支完全一致的 clean HEAD；feature branch 或未 push 的 main 会在任何平台写入前失败。成功激活后主线证据天然成立，不再补做发布后合并。
+Function/Automation 走 Backend Release v2；同一个 child 可以混合源码 create、无 `sourceFile` 的完整 v3 声明式 Automation manifest create、source-only update 与显式 manifest replacement，并对整个集合做 CAS。声明式 create 自动选路且不需要 `--replace-manifest`；替换已有资源才需要该显式授权。正式多资源发布必须使用 canonical 精确 selector 和 `--stage-only`。`release begin` 只接受与权威远端默认主分支完全一致的 clean HEAD；feature branch 或未 push 的 main 会在任何平台写入前失败。clone primary 与冻结仓库 ID 不同时，只有该冻结 ID 已存在于 `repoAliases` 才会统一用于 Backend/Workflow/Root App Release；无交集继续失败关闭。成功激活后主线证据天然成立，不再补做发布后合并。
 
 ## 应用结构
 

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

@@ -32,14 +32,15 @@ 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.
-- 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. After activation, run `integration-status` and `release end`; no post-release merge is needed.
+- 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.
 - Routine edits should plan and publish exact change targets: `workspace plan --profile <name> --change <change> --changed`, then `workspace publish --profile <name> --change <change> --only pages/a,forms/b --dry-run`.
 - 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

@@ -32,14 +32,15 @@ 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/配置或全量步骤。
-- 写入平台前只从与权威远端 tip 完全一致的 clean main/master 执行 `release begin`。feature branch 或未 push 主线在任何写入前失败；激活后直接运行 `integration-status` 和 `release end`，无需发布后再合并。
+- 写入平台前只从与权威远端 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 模式才阻断。
 - 单文件改动默认按 change 和逻辑目标发布：先 `workspace plan --profile <name> --change <change> --changed`，再 `workspace publish --profile <name> --change <change> --only pages/a,forms/b --dry-run`。
 - 账号/角色/权限/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

@@ -55,11 +55,11 @@
 - ✅ 发现平台缺陷、能力缺口、规则不清、反复 workaround、AI 不确定点、用户可见体验问题时，主动 `openxiangda feedback submit --yes`；发送后告诉用户反馈内容和 fingerprint。
 - ✅ 正式多资源开发优先写 `src/resources/**` 后执行 `openxiangda resource validate|plan|publish <type> --only <codes>`；单资源可用 `--code <code>`。直接 CLI 写平台资源时先 `--dry-run`，需要避免漂移就加 `--write-manifest`。
 - ✅ `resource plan` 与 publish dry-run 严格只允许 GET/HEAD；遇到 `READ_ONLY_AUTH_REQUIRED` 时先执行 `openxiangda auth refresh --profile <name>` 或重新登录，不得在 plan 内自动 POST 刷新 token。
-- ✅ 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 "..."`。
+- ✅ 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>`。
 - ✅ 已通过 `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` 查看两套环境、差异、候选、部署和测试证据；该页面只监听回环地址且只暴露注册动作，生产操作仍需显式确认。