openxiangda 1.0.204 → 1.0.206

package/README.md

@@ -82,7 +82,7 @@ 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.
 
-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. 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 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.
 
 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.
 
@@ -135,7 +135,7 @@ openxiangda policy render
 entrypoints. Generated documents carry `OpenXiangda-Policy-Version`; edit the
 canonical policy first instead of independently changing duplicate instructions.
 
-Source-triggered Function and Automation publishing is source-only by default. Backend Release v2 can mix create, source-only update, and manifest replacement update in one immutable child; a stale target therefore causes zero resource writes instead of failing halfway through 88 Functions and 11 Automations. `--stage-only` stops after verification, reports all handled selectors, and never falls back to direct Function/Automation writes when the platform is missing or incompatible. The release preserves online `resourceBindings`, input/output contracts, descriptive metadata, trigger/view configuration, and enabled/published state, and planned noops do not advance resource versions or timestamps. To intentionally make a complete local manifest replace the online definition, select exact codes and opt in explicitly with `--replace-manifest --reason "<why this replacement is safe>"`; `--sdd-bypass` does not widen that scope. Standard workspaces use the CLI-bundled scoped builder without spawning workspace `pnpm`, and `source_lineage_v1` compares authored source/dependencies independently from generated bundle bytes.
+Source-triggered Function and Automation publishing is source-only by default. Backend Release v2 can mix source-backed create, source-free declarative Automation manifest create, source-only update, and manifest replacement update in one immutable child; a stale target therefore causes zero resource writes instead of failing halfway through 88 Functions and 11 Automations. A new Automation with a complete `definitionJson.version="v3"` definition and no `sourceFile` automatically uses manifest create and does not require `--replace-manifest`; incomplete definitions still fail closed. `--stage-only` stops after verification, reports all handled selectors, and never falls back to direct Function/Automation writes when the platform is missing or incompatible. The release preserves online `resourceBindings`, input/output contracts, descriptive metadata, trigger/view configuration, and enabled/published state, and planned noops do not advance resource versions or timestamps. To intentionally make a complete local manifest replace an existing online definition, select exact codes and opt in explicitly with `--replace-manifest --reason "<why this replacement is safe>"`; `--sdd-bypass` does not widen that scope. Standard workspaces use the CLI-bundled scoped builder without spawning workspace `pnpm`, and `source_lineage_v1` compares authored source/dependencies independently from generated bundle bytes.
 
 React SPA templates include stable Vite manual chunk grouping for React, antd, ECharts, editor dependencies, and OpenXiangda runtime/component entrypoints. The SDK keeps large UI dependencies such as `antd-mobile` and `dayjs` external so the application bundler can split them by route. Applications should import from public package entrypoints such as `openxiangda`, `openxiangda/runtime`, and `openxiangda/runtime/react`; do not import `openxiangda/packages/sdk/dist/...` internals to chase bundle size.
 

package/lib/application-environments.js

@@ -536,18 +536,24 @@ function withManagedReleaseForwardedFlags(stepId, args = [], flags = {}) {
     forwarded[0] === 'resource' &&
     forwarded[1] === 'publish' &&
     (forwarded.includes('--only') || forwarded.includes('--code'));
-  if (
-    !isExactResourcePublish ||
-    !flags['adopt-online-baseline']
-  ) {
+  if (!isExactResourcePublish) {
     return forwarded;
   }
-  forwarded.push('--adopt-online-baseline');
-  const reason = String(
-    flags['adoption-reason'] || flags.reason || ''
-  ).trim();
-  if (reason) {
-    forwarded.push('--adoption-reason', reason);
+  if (stepId === 'backend-stage' && flags['replace-manifest']) {
+    forwarded.push('--replace-manifest');
+    const replacementReason = String(flags.reason || '').trim();
+    if (replacementReason) {
+      forwarded.push('--reason', replacementReason);
+    }
+  }
+  if (flags['adopt-online-baseline']) {
+    forwarded.push('--adopt-online-baseline');
+    const adoptionReason = String(
+      flags['adoption-reason'] || flags.reason || ''
+    ).trim();
+    if (adoptionReason) {
+      forwarded.push('--adoption-reason', adoptionReason);
+    }
   }
   return forwarded;
 }

package/lib/cli.js

@@ -303,7 +303,7 @@ Usage:
   openxiangda sdd init|migrate|propose|quick|bundle|approve|status|context|verify|sync|archive [change] [--change id] [--json]
   openxiangda environment init|attach|bind|swap|policy update|list|status|diff|use [preproduction|production] [--logical-app code] [--environment target] [--json]
   openxiangda release publish|begin|status|integration-status|renew|end [--change id] [--profile name] [--watch] [--json]
-  openxiangda release ship|candidate|deploy|test|promote|rollback [--candidate id] [--environment target] [--adopt-online-baseline --adoption-reason text] [--json]
+  openxiangda release ship|candidate|deploy|test|promote|rollback [--candidate id] [--environment target] [--replace-manifest --reason text] [--adopt-online-baseline --adoption-reason text] [--json]
   openxiangda task status --change <id> [--profile name] [--watch] [--json]
   openxiangda release backend-head|backend-list|backend-detail|backend-diff|backend-rollback|backend-abort|backend-retry [releaseId] [--profile name] [--json]
   openxiangda release app-capture|app-head|app-list|app-detail|app-diff|app-prepare|app-verify|app-activate|app-finalize|app-rollback|app-abort [releaseId] [--staged-resources-json <JSON|file>] [--activate-staged-children] [--profile name] [--json]
@@ -3087,6 +3087,8 @@ const RELEASE_SHIP_SUPPORTED_FLAGS = new Set([
   'app-type',
   'since',
   'expand-dependencies',
+  'replace-manifest',
+  'reason',
   'adopt-online-baseline',
   'adoption-reason',
   'confirm-production',
@@ -3109,6 +3111,22 @@ function assertReleaseShipFlags(flags = {}) {
     error.unsupportedFlags = unsupported;
     throw error;
   }
+  const replacementRequested = Boolean(flags['replace-manifest']);
+  const replacementReason = String(flags.reason || '').trim();
+  if (!replacementRequested && replacementReason) {
+    const error = new Error(
+      'RELEASE_SHIP_REPLACE_MANIFEST_FLAG_REQUIRED: --reason 必须与 --replace-manifest 一起使用；命令已在任何 candidate/deployment 写入前终止'
+    );
+    error.code = 'RELEASE_SHIP_REPLACE_MANIFEST_FLAG_REQUIRED';
+    throw error;
+  }
+  if (replacementRequested && replacementReason.length < 8) {
+    const error = new Error(
+      'RELEASE_SHIP_REPLACE_MANIFEST_REASON_REQUIRED: --replace-manifest 必须提供至少 8 个字符的 --reason；命令已在任何 candidate/deployment 写入前终止'
+    );
+    error.code = 'RELEASE_SHIP_REPLACE_MANIFEST_REASON_REQUIRED';
+    throw error;
+  }
   const adoptionRequested = Boolean(flags['adopt-online-baseline']);
   const adoptionReason = String(flags['adoption-reason'] || '').trim();
   if (!adoptionRequested && adoptionReason) {
@@ -3138,7 +3156,7 @@ async function runApplicationShipCommand(
     readStringFlag(flags, 'change') || positional[0];
   if (!changeId) {
     fail(
-      '用法: openxiangda release ship --change <id> [--adopt-online-baseline --adoption-reason "..."] [--confirm-production] [--acceptance-note "..."]'
+      '用法: openxiangda release ship --change <id> [--replace-manifest --reason "..."] [--adopt-online-baseline --adoption-reason "..."] [--confirm-production] [--acceptance-note "..."]'
     );
   }
   const logicalApp = requireLogicalApplication(initialTarget);
@@ -3154,6 +3172,26 @@ 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 记录的同一对参数'
+      );
+    }
+  }
 
   if (confirmProduction && !existingShip?.preproductionDeploymentId) {
     fail(
@@ -3185,6 +3223,7 @@ async function runApplicationShipCommand(
         candidateHash: candidate.candidateHash,
         sourceRevision: candidate.sourceRevision,
         candidateFile: created.candidateFile,
+        manifestReplacement,
       });
     } else {
       assertLocalCandidate(candidate);
@@ -3221,12 +3260,18 @@ async function runApplicationShipCommand(
       preproductionAppReleaseId:
         deployment.targetAppReleaseId || null,
       preproductionStatus: deployment.status,
+      manifestReplacement,
       preparedAt:
         existingShip?.preparedAt ||
         new Date().toISOString(),
       nextCommand:
         `openxiangda release ship --change ${changeId} ` +
-        '--confirm-production',
+        '--confirm-production' +
+        (manifestReplacement.enabled
+          ? ` --replace-manifest --reason ${JSON.stringify(
+              manifestReplacement.reason
+            )}`
+          : ''),
     });
     return {
       phase: 'preproduction',
@@ -3569,12 +3614,13 @@ async function release(args) {
   if (wantsSubcommandHelp(subcommand, flags)) {
     print([
       '用法: openxiangda release publish|begin|status|explain|integration-status|renew|end [--change id] [--profile name] [--json]',
-      '      openxiangda release ship|candidate|deploy|reconcile|test|promote|rollback [--candidate id] [--environment target] [--adopt-online-baseline --adoption-reason text] [--confirm-production] [--json]',
+      '      openxiangda release ship|candidate|deploy|reconcile|test|promote|rollback [--candidate id] [--environment target] [--replace-manifest --reason text] [--adopt-online-baseline --adoption-reason text] [--confirm-production] [--json]',
       '      openxiangda release backend-head|backend-list|backend-detail|backend-diff|backend-rollback|backend-abort|backend-retry [releaseId] [--profile name] [--json]',
       '      openxiangda release app-capture|app-head|app-list|app-detail|app-diff|app-post-commit|app-retry|app-prepare|app-verify|app-activate|app-finalize|app-rollback|app-abort [releaseId] [--staged-resources-json <JSON|file>] [--activate-staged-children] [--profile name] [--json]',
       '常用流程:',
       '  openxiangda release ship --change <id> --profile <name>',
       '  openxiangda release ship --change <id> --profile <name> --adopt-online-baseline --adoption-reason "已审计目标来自多次历史发布"',
+      '  openxiangda release ship --change <id> --profile <name> --replace-manifest --reason "已审查精确 Function manifest"',
       '  # 确认预发结果后；可选 --acceptance-note 留下人工验收记录：',
       '  openxiangda release ship --change <id> --profile <name> --confirm-production',
       '  openxiangda release publish --change <id> --profile <name>',
@@ -3590,6 +3636,7 @@ async function release(args) {
       '说明:',
       '  - ship 是环境托管应用的两段式快车道：首次只部署预发并停止；确认预发结果后，第二次以同一 candidate 晋级正式。人工验收备注可选。',
       '  - 已合入主线但线上来自多次历史 lineage 的精确非删除恢复可显式使用 --adopt-online-baseline 与 --adoption-reason；仍保留冻结 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。',
       '  - app-head 默认只输出紧凑 head 摘要；需要完整 manifest 时显式追加 --full。',
@@ -17855,6 +17902,66 @@ function buildAutomationBackendReleaseSources(definition, label) {
   return sources;
 }
 
+function isCompleteDeclarativeAutomationDefinition(definition) {
+  if (
+    !definition ||
+    typeof definition !== 'object' ||
+    Array.isArray(definition) ||
+    definition.version !== 'v3' ||
+    !Array.isArray(definition.nodes) ||
+    definition.nodes.length === 0 ||
+    !Array.isArray(definition.edges)
+  ) {
+    return false;
+  }
+  const nodeIds = new Set();
+  let startCount = 0;
+  for (const node of definition.nodes) {
+    if (
+      !node ||
+      typeof node !== 'object' ||
+      !String(node.id || '').trim() ||
+      !String(node.type || '').trim() ||
+      !node.data ||
+      typeof node.data !== 'object' ||
+      Array.isArray(node.data)
+    ) {
+      return false;
+    }
+    const nodeId = String(node.id);
+    if (nodeIds.has(nodeId)) return false;
+    nodeIds.add(nodeId);
+    if (node.type === 'start') startCount += 1;
+  }
+  if (startCount !== 1) return false;
+  return definition.edges.every(
+    edge =>
+      edge &&
+      typeof edge === 'object' &&
+      String(edge.id || '').trim() &&
+      nodeIds.has(String(edge.source || '')) &&
+      nodeIds.has(String(edge.target || ''))
+  );
+}
+
+function resolveAutomationCreateBackendReleaseMode(candidate, definition) {
+  if (
+    candidate.operation !== 'create' ||
+    candidate.mode === 'manifest_replacement'
+  ) {
+    return candidate.mode;
+  }
+  if (buildAutomationSourcePatchSources({}, definition).length > 0) {
+    return 'source_only';
+  }
+  if (isCompleteDeclarativeAutomationDefinition(definition)) {
+    return 'manifest_replacement';
+  }
+  fail(
+    `Automation:${candidate.code} 新建资源既不包含可发布的源码快照，也不包含完整的 definitionJson.version=v3 声明式定义`
+  );
+}
+
 async function buildBackendReleaseResourceInput(
   config,
   target,
@@ -17945,21 +18052,37 @@ async function buildBackendReleaseResourceInput(
       true,
       uploadCache
     ));
+  const mode = resolveAutomationCreateBackendReleaseMode(
+    candidate,
+    definitionJson
+  );
+  candidate.mode = mode;
   const common = {
     kind: 'Automation',
     code: candidate.code,
-    mode: candidate.mode,
+    mode,
     operation: candidate.operation,
   };
-  if (candidate.mode === 'manifest_replacement') {
+  if (mode === 'manifest_replacement') {
     return {
       ...common,
-      replacement: buildBackendReleaseAutomationMetadata(
-        target,
-        candidate.item,
-        definitionJson,
-        viewJson
-      ),
+      ...(candidate.operation === 'create'
+        ? {
+            create: buildBackendReleaseAutomationMetadata(
+              target,
+              candidate.item,
+              definitionJson,
+              viewJson
+            ),
+          }
+        : {
+            replacement: buildBackendReleaseAutomationMetadata(
+              target,
+              candidate.item,
+              definitionJson,
+              viewJson
+            ),
+          }),
     };
   }
   return {
@@ -18358,9 +18481,6 @@ async function publishBackendReleaseResources(
       `${candidate.kind === 'Function' ? 'function' : 'automation'}:${candidate.code}`
     )
     .sort();
-  const resourceModes = unique(candidates.map(candidate => candidate.mode));
-  const releaseMode =
-    resourceModes.length > 1 ? 'mixed' : resourceModes[0] || 'source_only';
   const replacementReason = String(
     options.publishLeaseFlags?.reason ||
       options.publishLeaseFlags?.['replace-reason'] ||
@@ -18418,6 +18538,14 @@ async function publishBackendReleaseResources(
         uploadCache
       )
   );
+  const resourceModes = unique(resources.map(resource => resource.mode));
+  const releaseMode =
+    resourceModes.length > 1 ? 'mixed' : resourceModes[0] || 'source_only';
+  const requiresReplacementReason = resources.some(
+    resource =>
+      resource.mode === 'manifest_replacement' &&
+      resource.operation === 'update'
+  );
   const prepared = await requestWithAuth(
     config,
     target.profileName,
@@ -18429,7 +18557,7 @@ async function publishBackendReleaseResources(
         ...(protocolVersion ? { protocolVersion } : {}),
         parentReleaseId: head?.activeBackendReleaseId || null,
         mode: releaseMode,
-        ...(releaseMode !== 'source_only'
+        ...(requiresReplacementReason
           ? { replacementReason }
           : {}),
         sourceRepositoryId: releaseContext.sourceRepositoryId,

package/openxiangda-skills/SKILL.md

@@ -108,6 +108,8 @@ For a workspace registered by `openxiangda environment init` or connected to an
 
 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.
 
+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.
+
 `resource plan` and publish dry-runs are strictly GET/HEAD-only. `READ_ONLY_AUTH_REQUIRED` means the access token expired; run `openxiangda auth refresh --profile <name>` or log in again before retrying. Never add an automatic refresh POST inside a plan.
 
 `release publish` is the default promotion entrypoint only for legacy unmanaged workspaces. It verifies without rewriting reviewed `change.json`/`release.json`, waits for the app lease, freezes the App capture after ownership is acquired, executes deterministic exact staged steps, resumes from `.openxiangda/releases/<change>/execution.json`, atomically finalizes, verifies mainline integration, and releases the lease. Environment-managed applications use the two-phase `release ship`; candidate/deploy/test/promote, `release begin`, and child commands remain recovery/diagnostic primitives.
@@ -124,7 +126,7 @@ Because promotion begins from the already-pushed authoritative mainline, `releas
 
 For a whole-app release, keep changed Runtime/Page/Backend/Form children staged and run `openxiangda release app-finalize --change <change> --staged-resources-json <JSON|file> --profile <name>`. The JSON contains only changed immutable child entries; the CLI overlays Runtime/Page/Backend by singleton kind and FormRelease by `formUuid` onto one authoritative read-only capture, preserving every unmodified active child. It then performs `prepare -> verify -> activateStagedChildren=true`, switching child heads and the App head atomically (`atomic_staged_children_v1`, or `atomic_staged_children_v2` when a Backend Release v2 child is present). Never refresh or retry after a conflict. The flow requires the owned stored lease/change baseline and carries the same client session and Git lineage on every write. Omitting the overlay is compatibility-only retrospective aggregation of already-active children.
 
-When a Function or Automation is selected because its TypeScript source changed, publishing is source-only by default. Backend Release v2 accepts per-resource create, source-only update, and manifest replacement update in one immutable child and one database transaction, so a stale member produces zero resource writes and noops do not advance versions/timestamps. `--stage-only` is fail-closed: every selected mutation must enter that child, and a missing/incompatible Backend Release API never falls back to direct writes. Online bindings, input/output contracts, metadata, trigger/view configuration, and enabled/published state remain unchanged unless exact `--replace-manifest --reason "..."` authority was provided.
+When a Function or Automation is selected because its TypeScript source changed, publishing is source-only by default. Backend Release v2 accepts source-backed create, source-free declarative Automation manifest create, source-only update, and manifest replacement update in one immutable child and one database transaction, so a stale member produces zero resource writes and noops do not advance versions/timestamps. 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. `--stage-only` is fail-closed: every selected mutation must enter that child, and a missing/incompatible Backend Release API never falls back to direct writes. Online bindings, input/output contracts, metadata, trigger/view configuration, and enabled/published state remain unchanged unless exact `--replace-manifest --reason "..."` authority was provided for an existing resource.
 
 An App Function may declare metadata-only top-level `secretRefs: [{ name, required }]` only with `function_v2` + `trusted_node_v2`; source resolves values with `await ctx.secrets.get(name)` and uses `ctx.utils.http` for controlled public HTTPS. Create/rotate values through hidden TTY or `openxiangda secret ... --value-stdin --change <change> --profile <name>`. Never put values in arguments, files, manifests, state, plans, logs, errors, or chat. Secret bindings require `backend_release_v2` and whole-app `atomic_staged_children_v2`; a missing capability is fail-closed and never uses the legacy source PATCH. For whole-app activation use exact-scope `resource publish <type> --only <code> --stage-only`, then pass the returned verified `stagedResource` to `release app-finalize`; an active Backend Release is never labeled staged.
 

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

@@ -61,7 +61,7 @@ Selectors apply before manifest parsing, source dependency analysis, and JS_CODE
 
 Function/Automation source analysis also extracts statically declared Form filter and order fields. `resource plan` compares them with each bound Form's frozen online schema and reports `formFieldContracts`; publish fails before lease/write when a binding or field is missing. Fix the source or stage the Form schema in the same reviewed release instead of waiting for a production SQL-column error. Dynamic field names remain runtime-validated by the platform and return `FORM_FIELD_NOT_FOUND` as a configuration error.
 
-Source-triggered Function/Automation targets use Backend Release v2 when the platform exposes that capability. One child may mix 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`. 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 requires exact `--only/--code` and `--replace-manifest --reason "<why>"`; SDD bypass does not imply replacement authority.
+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.
 
 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.
 
@@ -109,6 +109,8 @@ Once `environment init` registers a logical application, or `environment attach`
 
 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.
 
+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.
+
 `release publish` is the normal whole-app entrypoint for legacy unmanaged workspaces: it verifies SDD without mutating reviewed files, waits for the promotion lease, freezes one App capture, stages the exact Form/Backend/Runtime children, resumes from a private execution journal, finalizes once, and releases the lease. Managed applications use two-phase `release ship` and its deployment-scoped journal. Individual candidate/deploy/test/promote commands are recovery/diagnostic primitives.
 
 Reviewed bundle commands may retain `<profile>` as a template. The explicit real `release publish --profile <name>` value is bound to actual child argv without rewriting tracked SDD. React SPA page codes remain logical coverage targets and activate through the single Runtime child; they do not require PageRelease. If local lease state disappears, `release end --change <id>` reconciles a self-owned remote lease from the private execution journal and never reports inactive while a remote lease is active.

package/package.json

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

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

@@ -28,5 +28,5 @@ openxiangda resource typegen --profile <name>
 - Formal changes should keep Git as the source of truth: edit manifests, validate, plan, then publish.
 - Exact selectors apply before manifest/source analysis and JS_CODE build: touch only selected targets plus transitive/shared/ambient dependencies; omit selectors only for intentional full-workspace work.
 - `resource plan` and publish dry-runs are GET/HEAD-only. On `READ_ONLY_AUTH_REQUIRED`, run `openxiangda auth refresh --profile <name>` or log in again before retrying; never refresh inside the plan.
-- Source-triggered Function/Automation publishing patches only source fields on the server and preserves online bindings/contracts/metadata/state. Whole-manifest replacement requires `--replace-manifest --reason "..."`.
+- Source-triggered Function/Automation publishing patches only source fields on the server and preserves online bindings/contracts/metadata/state. A new source-free Automation with a complete `definitionJson.version="v3"` automatically uses manifest create; replacing an existing whole manifest requires `--replace-manifest --reason "..."`.
 - Formal promotion freezes the clean publish HEAD separately from the change base, preflights the complete set, and rejects `SOURCE_BASE_DIVERGED` / `RELEASE_SOURCE_BEHIND_MAIN` / `RESOURCE_FIELD_CONFLICT`. After activation, merge/fast-forward and push the frozen SHA, verify `release integration-status`, then run normal `release end`; squash/rebase does not preserve the released source.

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

@@ -33,7 +33,8 @@ This is an OpenXiangda React SPA workspace. See [AGENTS.md](mdc:AGENTS.md) for f
 - Roles that create roles, assign members, grant API permissions, maintain permission groups, or manage organization accounts must declare `apiPermissionCodes`, such as `app:role:manage`, `app:page-permission-group:manage`, `app:form-permission-group:manage`, and `app:organization:manage`.
 - `src/resources/**` is the resource source of truth; use `validate -> plan -> publish`.
 - 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. Whole-manifest replacement requires `--replace-manifest --reason "..."`. On `SOURCE_BASE_DIVERGED` or `RESOURCE_FIELD_CONFLICT`, reconcile, rebuild, and re-plan.
+- 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.
+- 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.
 - 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-resources.md

@@ -28,5 +28,5 @@ openxiangda resource typegen --profile <name>
 - Formal changes should keep Git as the source of truth: edit manifests, validate, plan, then publish.
 - Exact selectors apply before manifest/source analysis and JS_CODE build: touch only selected targets plus transitive/shared/ambient dependencies; omit selectors only for intentional full-workspace work.
 - `resource plan` and publish dry-runs are GET/HEAD-only. On `READ_ONLY_AUTH_REQUIRED`, run `openxiangda auth refresh --profile <name>` or log in again before retrying; never refresh inside the plan.
-- Source-triggered Function/Automation publishing patches only source fields on the server and preserves online bindings/contracts/metadata/state. Whole-manifest replacement requires `--replace-manifest --reason "..."`.
+- Source-triggered Function/Automation publishing patches only source fields on the server and preserves online bindings/contracts/metadata/state. A new source-free Automation with a complete `definitionJson.version="v3"` automatically uses manifest create; replacing an existing whole manifest requires `--replace-manifest --reason "..."`.
 - Formal promotion freezes the clean publish HEAD separately from the change base, preflights the complete set, and rejects `SOURCE_BASE_DIVERGED` / `RELEASE_SOURCE_BEHIND_MAIN` / `RESOURCE_FIELD_CONFLICT`. After activation, merge/fast-forward and push the frozen SHA, verify `release integration-status`, then run normal `release end`; squash/rebase does not preserve the released source.

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

@@ -29,7 +29,8 @@ This is an OpenXiangda React SPA workspace. Read [AGENTS.md](AGENTS.md) for full
 - 角色能新增角色、分配成员、授接口权限、维护权限组或管理组织账号时，角色资源必须声明 `apiPermissionCodes`，例如 `app:role:manage`、`app:page-permission-group:manage`、`app:form-permission-group:manage`、`app:organization:manage`。
 - `src/resources/**` 是工程化资源来源，正式多资源变更走 `validate -> plan -> publish`。
 - 默认按逻辑资源 code 使用 `--only` 或单资源 `--code`；全类型/全应用发布必须由批准的依赖闭包明确覆盖。
-- Function/Automation 源码触发默认走服务端 source-field PATCH，保留线上 bindings/contracts/metadata/trigger/view/enabled/published state；整包 manifest 替换必须加 `--replace-manifest --reason "..."`。
+- Function/Automation 源码触发默认走服务端 source-field PATCH，保留线上 bindings/contracts/metadata/trigger/view/enabled/published state；无源码且 `definitionJson.version="v3"` 完整的新建 Automation 自动走 manifest create，只有替换已有整包 manifest 才必须加 `--replace-manifest --reason "..."`。
+- 环境托管 `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`，不再补做发布后合并。
 - 已有工作区通过 `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

@@ -57,6 +57,8 @@ openxiangda commands --json
 
 只有已审计代码早已进入权威主线、而精确非删除目标在线上来自多次历史发布且无法对应单一 Git 基线时，第一次 `release ship` 才可增加 `--adopt-online-baseline --adoption-reason "..."`。该参数不会放松冻结 online heads、change/lease、删除/全量拒绝、服务端 CAS、staged children 或单次 App finalize 原子激活。
 
+环境托管发布需要完整替换 Function/Automation manifest 时，`release ship` 可成对增加 `--replace-manifest --reason "..."`；reason 至少 8 字符，只会进入精确 Backend selector，正式确认必须复用与预发完全相同的参数，绝不扩散到表单、流程、Runtime、配置资源或全量范围。
+
 受支持的配置资源（如 `publicAccessPolicies`）以精确 `resourceSelectors` 为发布边界；历史 `resources=true` 类别标记会被精确 selector 收窄。缺失 selector、未知类型、通配符 `*`、删除和真正全量资源仍必须 fail closed。
 
 `resource plan` 与 publish dry-run 严格只允许 GET/HEAD。遇到 `READ_ONLY_AUTH_REQUIRED` 时，先执行 `openxiangda auth refresh --profile <name>` 或重新登录再重试；不得在 plan 内自动 POST 刷新 token。
@@ -80,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、source-only update 与显式 manifest replacement，并对整个集合做 CAS。正式多资源发布必须使用 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 会在任何平台写入前失败。成功激活后主线证据天然成立，不再补做发布后合并。
 
 ## 应用结构
 

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

@@ -31,7 +31,7 @@ Exact `--only/--code` selectors apply before manifest/source analysis and JS_COD
 
 App Function manifests may contain only logical names in top-level `secretRefs`; use `function_v2` / `trusted_node_v2`, resolve values with `ctx.secrets.get(name)`, and manage values only with `openxiangda secret ... --value-stdin --change ... --profile ...`. Values never belong in Git, `.env`, manifests, source, builds, plans, logs, or errors.
 
-When a Function/Automation enters scope only through source changes, publishing uses a server-side source-field PATCH and preserves online bindings, contracts, metadata, trigger/view configuration, and enabled/published state. Whole-manifest replacement requires `--replace-manifest --reason "..."`. Formal promotion freezes the clean publish HEAD separately from the change/remote baseline and preflights the whole set; `SOURCE_BASE_DIVERGED`, `RELEASE_SOURCE_BEHIND_MAIN`, and `RESOURCE_FIELD_CONFLICT` require reconciliation. After activation, merge/push the frozen SHA, verify `release integration-status`, then run normal `release end`.
+When a Function/Automation enters scope only through source changes, publishing uses a 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 manifest create; replacing an existing whole manifest requires `--replace-manifest --reason "..."`. Formal promotion freezes the clean publish HEAD separately from the change/remote baseline and preflights the whole set; `SOURCE_BASE_DIVERGED`, `RELEASE_SOURCE_BEHIND_MAIN`, and `RESOURCE_FIELD_CONFLICT` require reconciliation. After activation, merge/push the frozen SHA, verify `release integration-status`, then run normal `release end`.
 
 Before editing `roles`, `permissions/page-groups`, or `permissions/form-groups` for account/role/data-scope/RBAC/query-param authorization work, run `openxiangda design gates --topic permissions --json`, choose the permission mode, and write the permission matrix.
 

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

@@ -29,7 +29,8 @@ This is a `sy-lowcode-app-workspace` managed by the `openxiangda` CLI. See [AGEN
 - 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 is limited to an exact low-risk scope and does not add a redundant proposal/approval loop when the user already requested that exact edit.
 - SDD is streamlined by default: approval and exact structured scope are hard gates, while unfinished task/evidence/spec prose only warns. Use `strictDocumentation: true` only when prose must block.
-- 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. Whole-manifest replacement requires exact `--only/--code` plus `--replace-manifest --reason "..."`.
+- 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 "..."`.
+- 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.
 - Environment-managed workspaces never publish directly. Existing workspaces use `environment attach`; only an appType-matching legacy binding may seed preproduction and production starts empty. Run `release candidate`, `release deploy --environment preproduction`, `release test`, then promote that same candidate with `release promote --environment production --confirm-production`. Keep app/resource/data IDs isolated and inspect state with `openxiangda studio`. Only an explicitly authorized commissioning reclassification may use `environment swap --reason "..." --confirm-production`; it preserves app data/Release Heads and keeps side effects restricted by default.
 - Change one target's side-effect policy only with `environment policy update <preproduction|production> --side-effect-policy-json <JSON|file> --reason "..."`: run `--dry-run` first, add `--confirm-production` for production, and never use `environment swap` for this. Patch mode validates only supplied fields and preserves unrecognized historical fields; `--full-replace` validates the supplied complete target and intentionally removes omissions. `organizationWrites=explicit_capability_only` removes the environment deny but still requires `app:organization:manage`. Keep release hard gates to explicit scope/profile/target, authorization, clean pushed mainline, immutable identity, CAS/lease, and production confirmation; prose and human acceptance notes are advisory unless strict mode is configured.

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

@@ -41,7 +41,7 @@ openxiangda resource publish  <type> --code <code> --profile <name>  # 单资源
 openxiangda resource pull     --profile <name>          # 平台 → 本地
 ```
 
-Function/Automation 仅因源码变化进入 scope 时，默认通过服务端字段 PATCH 只更新 source snapshot，并保留线上 bindings、contracts、metadata、trigger/view 配置和 enabled/published state。确需让本地整包 manifest 覆盖线上定义时，必须追加 `--replace-manifest --reason "..."`。正式发布先 `release begin --change <change>` 分别冻结 clean publish HEAD 与 change/远端 baseline 并整体 preflight；`SOURCE_BASE_DIVERGED` / `RELEASE_SOURCE_BEHIND_MAIN` / `RESOURCE_FIELD_CONFLICT` 不能强行重试。上线后 merge/push 冻结 SHA，验证 `release integration-status`，再正常 `release end`。
+Function/Automation 仅因源码变化进入 scope 时，默认通过服务端字段 PATCH 只更新 source snapshot，并保留线上 bindings、contracts、metadata、trigger/view 配置和 enabled/published state。无源码且 `definitionJson.version="v3"` 完整的新建 Automation 自动走 manifest create；确需让本地整包 manifest 覆盖已有线上定义时，必须追加 `--replace-manifest --reason "..."`。正式发布先 `release begin --change <change>` 分别冻结 clean publish HEAD 与 change/远端 baseline 并整体 preflight；`SOURCE_BASE_DIVERGED` / `RELEASE_SOURCE_BEHIND_MAIN` / `RESOURCE_FIELD_CONFLICT` 不能强行重试。上线后 merge/push 冻结 SHA，验证 `release integration-status`，再正常 `release end`。
 
 `resource plan` 与 publish dry-run 严格只允许 GET/HEAD。遇到 `READ_ONLY_AUTH_REQUIRED` 时，先执行 `openxiangda auth refresh --profile <name>` 或重新登录再重试；不得在 plan 内自动 POST 刷新 token。
 

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

@@ -29,7 +29,8 @@ This is a `sy-lowcode-app-workspace` managed by the `openxiangda` CLI. Read [AGE
 - L0 只读/文档/测试无需 SDD；L1 窄小可逆改动记录精确范围且不重复确认；表单结构、业务函数、自动化/流程、权限、登录/公开访问、数据写入、runtime/config 等 L2/L3 走完整 SDD，live evidence/archive 放到发布后。
 - 极小的文案、样式、绑定修正可使用 `openxiangda sdd quick <change> ...`，但必须限制在精确的低风险范围内；用户已明确要求该小改时不再重复 propose/approve。
 - SDD 默认 streamlined：approval 与结构化精确范围是硬门禁，未完成的 task/evidence/spec 文案只告警；只有 `strictDocumentation: true` 才阻断。
-- Function/Automation 源码触发默认走服务端 source-field PATCH，保留线上 bindings/contracts/metadata/trigger/view/enabled/published state；整包 manifest 替换必须精确 `--only/--code` 并加 `--replace-manifest --reason "..."`。
+- 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 "..."`。
+- 环境托管 `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`，无需发布后再合并。
 - 环境托管工作区禁止直发：已有工作区先用 `environment attach` 接入，旧映射只能迁移到 appType 相同的预发 target，正式 target 必须为空。然后执行 `release candidate`、`release deploy --environment preproduction`、`release test`，最后将同一 candidate 用 `release promote --environment production --confirm-production` 晋级。两套环境的 appType、资源 ID 和数据不可互拷；用 `openxiangda studio` 查看状态。只有用户明确授权的投产前重分类可执行 `environment swap --reason "..." --confirm-production`；它不移动应用数据或 Release Head，且默认不放开副作用。
 - 单独修改某个环境的副作用策略只能使用 `environment policy update <preproduction|production> --side-effect-policy-json <JSON|file> --reason "..."`：先执行 `--dry-run`，正式环境额外要求 `--confirm-production`，不得借用 `environment swap`。patch 只校验本次提交字段并原样保留未知历史字段，`--full-replace` 才按完整目标删除遗漏字段。`organizationWrites=explicit_capability_only` 只解除环境级 deny，仍强制 `app:organization:manage`。发布硬门禁只保留明确 scope/profile/target、权限、干净且已推送主线、不可变版本、CAS/租约与生产确认；文案和人工验收说明默认是建议，只有显式 strict 模式才阻断。

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

@@ -55,10 +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、source-only update 和显式 manifest replacement，再由 Root App finalize 原子激活。整包 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 "..."`。
 - ✅ 未登记环境的旧工作区，正式 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 仍是硬门禁。
+- ✅ 环境托管发布需要完整替换 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` 查看两套环境、差异、候选、部署和测试证据；该页面只监听回环地址且只暴露注册动作，生产操作仍需显式确认。