openxiangda 1.0.256 → 1.0.257

package/README.md

@@ -133,7 +133,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 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` always executes the same ordered candidate → preproduction → production protocol. The normal first invocation seals the candidate, deploys only to preproduction, and stops at `awaiting_production_confirmation`; a later invocation with `--confirm-production` promotes it. For an explicitly authorized emergency, supplying `--confirm-production` on the first invocation runs both phases in one command without bypassing preproduction, CAS, evidence, or production confirmation. Candidate sealing covers source, `public/`, build controls/scripts, stable environment/resource bindings, and target-specific hashed Runtime artifacts. Both deployments upload those artifacts with `--no-build`; each deployment is completed with evidence and reaches terminal `succeeded`, so it cannot leave the target slot blocked. Unrelated commits may land on authoritative mainline between phases only while the sealed commit remains an ancestor and every sealed input/binding/artifact still validates. Real human acceptance remains the recommended default and `--acceptance-note` records it. For audited historical-lineage adoption or reviewed Backend manifest replacement, the existing paired flags and exact-scope gates remain mandatory. Supported configuration resources use exact `resourceSelectors`; unknown, wildcard, destructive, and genuinely unscoped generic resources remain blocked. Lower-level candidate/deploy/test/fail/promote commands are recovery primitives. `release fail` requires an explicit preproduction target, deployment ID, and audit message; it verifies the deployment belongs to that preproduction environment before writing optional code/details to the platform failure audit. Direct `release publish` is retained only for legacy unmanaged workspaces.
+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` always executes the same ordered candidate → preproduction → production protocol. The normal first invocation seals the candidate, deploys only to preproduction, and stops at `awaiting_production_confirmation`; a later invocation with `--confirm-production` promotes it. For an explicitly authorized emergency, supplying `--confirm-production` on the first invocation runs both phases in one command without bypassing preproduction, CAS, evidence, or production confirmation. Candidate sealing covers source, `public/`, build controls/scripts, stable environment/resource bindings, and target-specific hashed Runtime artifacts. Both deployments upload those artifacts with `--no-build`; Backend, Runtime, and Root children all retain the sealed candidate `sourceRevision`, even when promotion starts from a later clean descendant mainline commit. Each deployment is completed with evidence and reaches terminal `succeeded`, so it cannot leave the target slot blocked. Unrelated commits may land on authoritative mainline between phases only while the sealed commit remains an ancestor and every sealed input/binding/artifact still validates. Real human acceptance remains the recommended default and `--acceptance-note` records it. For audited historical-lineage adoption or reviewed Backend manifest replacement, the existing paired flags and exact-scope gates remain mandatory. Supported configuration resources use exact `resourceSelectors`; unknown, wildcard, destructive, and genuinely unscoped generic resources remain blocked. Lower-level candidate/deploy/test/fail/promote commands are recovery primitives. `release fail` requires an explicit preproduction target, deployment ID, and audit message; it verifies the deployment belongs to that preproduction environment before writing optional code/details to the platform failure audit. Direct `release publish` is retained only for legacy unmanaged workspaces.
 
 DataView `status` is a last-observed lifecycle value, not a stable candidate binding: the same managed deployment legitimately moves it between `draft` and `active`. Candidate creation and validation therefore omit only `resources.dataViews.<code>.status`, including when resuming a candidate sealed by an older CLI. `dataViewId`, `materializedViewName`, `storageMode`, candidate hashes, environment identity, CAS, lease, source and every non-DataView status remain fail-closed.
 

package/lib/cli.js

@@ -5214,7 +5214,7 @@ async function release(args) {
       '  openxiangda release app-finalize --change <id> --staged-resources-json <JSON|file> --profile <name>',
       '说明:',
       '  - ship 是环境托管应用的有序快车道：默认首次只部署预发并停止，第二次以同一 candidate 晋级正式；明确授权紧急发布时可在首次携带 --confirm-production，一条命令顺序完成两阶段。人工验收备注可选。',
-      '  - candidate 封存环境/资源绑定和两目标 Runtime 哈希产物；预发与正式部署均不现场重建，并以 deployment succeeded 闭环。',
+      '  - candidate 封存环境/资源绑定、源码身份和两目标 Runtime 哈希产物；预发与正式部署均不现场重建，Backend/Runtime/Root 始终使用 candidate sourceRevision，并以 deployment succeeded 闭环。',
       '  - 已合入主线但线上来自多次历史 lineage 的精确非删除恢复可显式使用 --adopt-online-baseline 与 --adoption-reason；预发冻结后，正式确认会从 ship.json 自动复用同一意图，仍保留冻结 Head、CAS、租约、staged children 和单次 App finalize。',
       '  - ship 的 --replace-manifest 与 --reason 必须成对，只透传给精确 Backend Function/Automation stage；正式确认必须复用与预发完全相同的参数。',
       '  - --allow-runtime-rollback 与 --reason 必须成对，只透传给 runtime-stage；ship 会冻结并在正式确认自动复用该审计意图，app-finalize 不会收到这些参数。',
@@ -6052,6 +6052,12 @@ async function runBackendReleaseCommand(
     if (!releaseId) {
       fail('用法: openxiangda release backend-abort <releaseId> [--reason text] [--profile name]');
     }
+    const releaseContext = await ensureBackendReleasePublishContext(
+      config,
+      target,
+      flags,
+      'Backend Release abort'
+    );
     data = await requestWithAuth(
       config,
       target.profileName,
@@ -6061,7 +6067,10 @@ async function runBackendReleaseCommand(
       ),
       {
         method: 'POST',
-        body: stripUndefinedValues({ reason: readStringFlag(flags, 'reason') }),
+        body: stripUndefinedValues({
+          ...releaseContext.control,
+          reason: readStringFlag(flags, 'reason'),
+        }),
       }
     );
   } else if (subcommand === 'backend-retry') {
@@ -15559,6 +15568,12 @@ async function runtime(args) {
     const runtimeHead = await telemetry.runPhase('head', async () =>
       loadRuntimeHeadApp(config, target)
     );
+    const releaseBaseline = activeDeliveryV2Context
+      ? null
+      : getStoredChangeBaseline(target);
+    const sealedCandidateSourceRevision = releaseBaseline?.candidateId
+      ? releaseBaseline.releaseSourceRevision
+      : null;
     const runtimeLineage = activeDeliveryV2Context
       ? {
           sourceRevision: activeDeliveryV2Context.sourceRevision,
@@ -15578,6 +15593,9 @@ async function runtime(args) {
           activate: !flags['no-activate'],
           allowRollback: flags['allow-runtime-rollback'],
           reason: readStringFlag(flags, 'reason'),
+          ...(sealedCandidateSourceRevision
+            ? { sourceRevision: sealedCandidateSourceRevision }
+            : {}),
         });
     if (runtimeLineage.lineageStatus === 'rollback-bypass') {
       warn(
@@ -15665,6 +15683,9 @@ async function runtime(args) {
             activate: !flags['no-activate'],
             allowRollback: flags['allow-runtime-rollback'],
             reason: readStringFlag(flags, 'reason'),
+            ...(sealedCandidateSourceRevision
+              ? { sourceRevision: sealedCandidateSourceRevision }
+              : {}),
           });
       assertRuntimeSourceRevisionStable(
         runtimeLineage.sourceRevision,

package/lib/runtime-lineage.js

@@ -47,11 +47,13 @@ function prepareRuntimeDeployLineage(options = {}) {
 
   let sourceRevision;
   try {
-    sourceRevision = normalizeRuntimeSourceRevision(readGitSourceBase(cwd, 'HEAD'));
+    sourceRevision = normalizeRuntimeSourceRevision(
+      options.sourceRevision || readGitSourceBase(cwd, 'HEAD')
+    );
   } catch (error) {
     throw runtimeLineageError(
       'RUNTIME_SOURCE_LINEAGE_REQUIRED',
-      `创建 Runtime release 前必须在可审计 Git 工作区的已提交 HEAD 上构建；当前目录无法读取 Git HEAD。${formatCause(error)}`
+      `创建 Runtime release 前必须使用可审计的已提交源码版本；当前目录无法解析 Runtime source revision。${formatCause(error)}`
     );
   }
 

package/openxiangda-skills/SKILL.md

@@ -143,7 +143,7 @@ For a workspace registered by `environment init` or connected by `environment at
 
 Candidate binding checks treat only `resources.dataViews.<code>.status` as a mutable platform lifecycle observation, so a candidate survives its own `active → draft → active` staging sequence and older sealed candidates remain resumable. DataView IDs, materialized-view names, storage modes, other resource statuses, candidate hashes, environment identity, CAS, lease, and source/mainline checks remain exact.
 
-A sealed candidate may be promoted from a later clean, pushed authoritative mainline commit only when the candidate commit remains its Git ancestor and every sealed candidate input file still has the exact recorded hash. This permits unrelated parallel merges without allowing stale candidate inputs to overwrite newer work. Do not edit private candidate metadata to bypass `CANDIDATE_INPUTS_CHANGED`. The CLI waits for both the app lease and target deployment slot; each target permits only one running or evidence-pending deployment. Emergency fixes stay on the same candidate → preproduction → production path with a narrow L1 scope. `--wait-seconds 0` is fail-fast, not a binding-contract, CAS, or production-confirmation bypass.
+A sealed candidate may be promoted from a later clean, pushed authoritative mainline commit only when the candidate commit remains its Git ancestor and every sealed candidate input file still has the exact recorded hash. This permits unrelated parallel merges without allowing stale candidate inputs to overwrite newer work. The later HEAD is only a safety gate: Backend, Runtime, and Root child releases all keep the sealed candidate `sourceRevision`; cleanup commands such as `backend-abort` remain protected by the same publish lease/baseline/session. Do not edit private candidate metadata to bypass `CANDIDATE_INPUTS_CHANGED`. The CLI waits for both the app lease and target deployment slot; each target permits only one running or evidence-pending deployment. Emergency fixes stay on the same candidate → preproduction → production path with a narrow L1 scope. `--wait-seconds 0` is fail-fast, not a binding-contract, CAS, or production-confirmation bypass.
 
 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.
 

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

@@ -148,7 +148,7 @@ Once `environment init` registers a logical application, or `environment attach`
 
 Treat DataView `status` as a platform lifecycle observation during candidate binding checks. The same deployment may change `resources.dataViews.<code>.status` between `draft` and `active`, including between preproduction and production confirmation, without invalidating the sealed candidate. Continue to validate the DataView ID, materialized-view name, storage mode, every other resource status, hashes, environment identity, CAS, lease, and source/mainline evidence exactly.
 
-A sealed candidate may continue from a later clean, pushed authoritative mainline commit only when its commit remains a Git ancestor and all sealed release inputs retain their exact hashes. If any input changed, create a new candidate; never edit the private candidate file. The CLI waits for the app lease and target deployment slot before writes, and the platform permits one running or evidence-pending deployment per target. Emergency releases still use a narrow L1 scope and the same candidate → preproduction → production path; `--wait-seconds 0` only fails fast.
+A sealed candidate may continue from a later clean, pushed authoritative mainline commit only when its commit remains a Git ancestor and all sealed release inputs retain their exact hashes. The later HEAD is only a safety gate: Backend, Runtime, and Root children keep the sealed candidate `sourceRevision`, and `backend-abort` uses the same publish lease/baseline/session as the staged release. If any input changed, create a new candidate; never edit the private candidate file. The CLI waits for the app lease and target deployment slot before writes, and the platform permits one running or evidence-pending deployment per target. Emergency releases still use a narrow L1 scope and the same candidate → preproduction → production path; `--wait-seconds 0` only fails fast.
 
 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.
 

package/package.json

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

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

@@ -31,7 +31,7 @@ This is an OpenXiangda React SPA workspace using Delivery V2. See [DELIVERY.md](
 - 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. 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.
-- Managed `release ship` always runs candidate → preproduction → production. Normally confirmation is a later invocation; an explicitly authorized emergency may put `--confirm-production` on the first invocation to run both phases in one command. The candidate seals environment/resource bindings and target-specific Runtime artifacts; deployment uses no rebuild and must finish each server deployment as `succeeded`.
+- Managed `release ship` always runs candidate → preproduction → production. Normally confirmation is a later invocation; an explicitly authorized emergency may put `--confirm-production` on the first invocation to run both phases in one command. The candidate seals environment/resource bindings, sourceRevision, and target-specific Runtime artifacts; a later mainline HEAD is only a safety gate, while Backend/Runtime/Root retain candidate provenance. Deployment uses no rebuild and must finish each server deployment as `succeeded`.
 - Record a failed preproduction UAT with `release fail --deployment <id> --message "..." [--code <code>] [--details-json <JSON|file>] --environment preproduction`; the CLI verifies target ownership before the audited write and rejects production or mismatched deployments.
 - 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.

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

@@ -36,7 +36,7 @@ This is an OpenXiangda React SPA workspace using Delivery V2. Read [DELIVERY.md]
 - Form 设置与表单权限组同时发布时，必须合并为一条 `resource publish form-setting,form-permission-group`，并使用 `form-setting:<code>`、`form-permission-group:<code>` 精确 selector；SDD 生成与校验共享同一契约，禁止缺失、夹带或拆分 FormRelease。
 - 环境托管 `release ship --adopt-online-baseline --adoption-reason "..."` 会把审计意图冻结进私有 ship journal，后续 `--confirm-production` 自动复用；显式传入不同参数会在任何请求前失败。
 - 环境托管 `release ship --replace-manifest --reason "..."` 必须成对、reason 至少 8 字符且仅限精确 Backend selector；正式确认复用与预发完全相同的参数，不透传 Form/Workflow/Runtime/配置或全量步骤。
-- `release ship` 始终顺序执行 candidate → 预发 → 生产。日常分两次确认；明确授权紧急发布时首条命令可带 `--confirm-production` 一次完成，但不跳过预发/证据/CAS。candidate 封存环境/资源绑定及两目标 Runtime 哈希产物，部署不重建且每条服务端 deployment 必须闭环为 `succeeded`。
+- `release ship` 始终顺序执行 candidate → 预发 → 生产。日常分两次确认；明确授权紧急发布时首条命令可带 `--confirm-production` 一次完成，但不跳过预发/证据/CAS。candidate 封存环境/资源绑定、sourceRevision 及两目标 Runtime 哈希产物；后续主线 HEAD 只作安全门禁，Backend/Runtime/Root 不改写候选来源，且每条服务端 deployment 必须闭环为 `succeeded`。
 - 预发 UAT 失败使用 `release fail --deployment <id> --message "..." [--code <code>] [--details-json <JSON|file>] --environment preproduction` 写审计；CLI 先校验 deployment 属于所选预发环境，禁止 production 或环境不匹配写入。
 - 托管发布完成后运行 `release integration-status --change <change> --profile <name> --check`；CLI 从私有 `ship.json` 或其引用的 production/preproduction deployment execution 日志恢复血缘，无法恢复时指出实际缺失的文件或字段。
 - 多 target 的托管工作区执行 `function invoke` 必须显式传 `--environment <target>`，并先核对 stderr 回显的最终 target 再判断响应。

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

@@ -60,7 +60,7 @@ openxiangda commands --json
 
 同一发布同时包含 Form 设置和表单权限组时，必须由一条 `resource publish form-setting,form-permission-group` 命令暂存，并在 `--only` 中分别使用 `form-setting:<code>`、`form-permission-group:<code>`。SDD bundle 与 prepublish 校验使用同一精确契约；缺失、夹带、拆成两个 FormRelease 或提前激活都应失败关闭。
 
-工作区一旦通过 `environment init` 登记或 `environment attach` 接入，`release publish` 即不再是入口。`release ship` 始终按 candidate → preproduction → production 执行：日常首条命令在预发停止，后续 `--confirm-production` 晋级；用户明确授权紧急发布时，首条命令可直接携带 `--confirm-production`，在一个命令内顺序执行两阶段，但不跳过预发、证据、CAS 或确认。candidate 封存源码、public、构建配置/脚本、稳定环境/资源绑定和两目标 Runtime 哈希产物；部署不再现场构建，并将两条服务端 deployment 都闭环为 `succeeded`。两套环境身份仍完全隔离，人工验收默认建议且可用 `--acceptance-note` 留痕；swap、policy 和权限规则保持不变。`openxiangda studio` 用于查看绑定、漂移、候选、部署和证据。
+工作区一旦通过 `environment init` 登记或 `environment attach` 接入，`release publish` 即不再是入口。`release ship` 始终按 candidate → preproduction → production 执行：日常首条命令在预发停止，后续 `--confirm-production` 晋级；用户明确授权紧急发布时，首条命令可直接携带 `--confirm-production`，在一个命令内顺序执行两阶段，但不跳过预发、证据、CAS 或确认。candidate 封存源码、public、构建配置/脚本、稳定环境/资源绑定和两目标 Runtime 哈希产物；部署不再现场构建，Backend/Runtime/Root 子发布始终使用 candidate sourceRevision，并将两条服务端 deployment 都闭环为 `succeeded`。两套环境身份仍完全隔离，人工验收默认建议且可用 `--acceptance-note` 留痕；swap、policy 和权限规则保持不变。`openxiangda studio` 用于查看绑定、漂移、候选、部署和证据。
 
 DataView 的 `status` 是平台生命周期观察值；同一托管部署在预发暂存和正式确认之间发生 `active → draft → active` 不构成候选漂移。候选仍严格校验 `dataViewId`、`materializedViewName`、`storageMode`、其他资源状态、哈希、环境身份、CAS、租约和来源主线。
 

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

@@ -78,4 +78,4 @@ Read [AGENTS.md](mdc:AGENTS.md) and the global skill: `~/.qoder/skills/openxiang
 
 ## Parallel candidates
 
-A candidate may cross unrelated later mainline commits only when its commit remains an ancestor of clean pushed mainline and all sealed input hashes remain unchanged. Each target allows one running or evidence-pending deployment; wait for the lease/slot, and keep emergency fixes on the narrow candidate → preproduction → production path.
+A candidate may cross unrelated later mainline commits only when its commit remains an ancestor of clean pushed mainline and all sealed input hashes remain unchanged. The later HEAD is only a safety gate; Backend, Runtime, and Root keep the candidate sourceRevision. Each target allows one running or evidence-pending deployment; wait for the lease/slot, and keep emergency fixes on the narrow candidate → preproduction → production path.

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

@@ -38,7 +38,7 @@ This is a `sy-lowcode-app-workspace` managed by the `openxiangda` CLI. Read [AGE
 - 相同 change 的 staged FormRelease 只有经服务端重新核验 immutable/inactive/non-aborted、identity/hash、冻结 schema/formType、finalized 资源、parent/base revision 与当前 Form Head 后，才可重挂接新 baseline/session。`schemaSyncedAt` 不是发布证据；禁止伪造、直发 schema 或提前激活 Form 绕过 Workflow 校验。
 - Form 设置与表单权限组同时发布时，必须合并为一条 `resource publish form-setting,form-permission-group`，并使用 `form-setting:<code>`、`form-permission-group:<code>` 精确 selector；SDD 生成与校验共享同一契约，禁止缺失、夹带或拆分 FormRelease。
 - 环境托管 `release ship --replace-manifest --reason "..."` 必须成对、reason 至少 8 字符且仅限精确 Backend selector；正式确认复用与预发完全相同的参数，不透传 Form/Workflow/Runtime/配置或全量步骤。
-- `release ship` 始终顺序执行 candidate → 预发 → 生产。日常分两次确认；明确授权紧急发布时首条命令可带 `--confirm-production` 一次完成，但不跳过预发/证据/CAS。candidate 封存环境/资源绑定及两目标 Runtime 哈希产物，部署不重建且每条服务端 deployment 必须闭环为 `succeeded`。
+- `release ship` 始终顺序执行 candidate → 预发 → 生产。日常分两次确认；明确授权紧急发布时首条命令可带 `--confirm-production` 一次完成，但不跳过预发/证据/CAS。candidate 封存环境/资源绑定、sourceRevision 及两目标 Runtime 哈希产物；后续主线 HEAD 只作安全门禁，Backend/Runtime/Root 不改写候选来源，且每条服务端 deployment 必须闭环为 `succeeded`。
 - 预发 UAT 失败使用 `release fail --deployment <id> --message "..." [--code <code>] [--details-json <JSON|file>] --environment preproduction` 写审计；CLI 先校验 deployment 属于所选预发环境，禁止 production 或环境不匹配写入。
 - 托管发布完成后运行 `release integration-status --change <change> --profile <name> --check`；CLI 从私有 `ship.json` 或其引用的 production/preproduction deployment execution 日志恢复血缘，无法恢复时指出实际缺失的文件或字段。
 - 写入平台前只从与权威远端 tip 完全一致的 clean main/master 执行 `release begin`。feature branch 或未 push 主线在任何写入前失败；clone primary 只有在冻结仓库 ID 已存在于 `repoAliases` 时才会 canonicalize，无交集在 Release prepare 前失败关闭；激活后直接运行 `integration-status` 和 `release end`，无需发布后再合并。

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

@@ -65,7 +65,7 @@ Delivery V2 自动从期望状态按资源指纹计算精确范围，使用 CLI
 - ✅ 同一发布同时包含 Form 设置和表单权限组时，必须使用一条 `resource publish form-setting,form-permission-group`，并以 `form-setting:<code>`、`form-permission-group:<code>` 精确限定 `--only`；SDD bundle 与 prepublish 校验共享该契约，禁止缺失、夹带、拆分发布或提前激活。
 - ✅ 未登记环境的旧工作区，正式 promotion 先聚合 mainline bundle 并 commit/push，再运行 `release publish --change <id> --profile <name>`。
 - ✅ 旧工作区已有 Root、且操作者明确授权无条件恢复时，可执行 `release app-activate <releaseId> --force-activate-without-validation --profile <name>`。该命令不读取 detail/capture，不要求 change、租约、baseline、源码 lineage、状态、parent、hash、resource head 或环境发布门禁；服务端直接在目标 tenant/appType 内以单事务切换 Root 与可识别的 staged children。
-- ✅ 已通过 `environment init` 或 `environment attach` 接入的工作区使用 `release ship`，始终按 candidate → preproduction → production 执行。日常首条命令在预发停止，后续 `--confirm-production` 晋级；用户明确授权紧急发布时，首条命令可携带 `--confirm-production` 在一个命令内顺序完成两阶段，但不跳过预发、证据、CAS 或确认。candidate 封存源码、public、构建配置/脚本、稳定环境/资源绑定和两目标 Runtime 哈希产物；部署不现场重建，并将两条服务端 deployment 闭环为 `succeeded`。两套环境身份仍完全隔离，人工验收建议和 swap/policy/权限门禁保持不变。
+- ✅ 已通过 `environment init` 或 `environment attach` 接入的工作区使用 `release ship`，始终按 candidate → preproduction → production 执行。日常首条命令在预发停止，后续 `--confirm-production` 晋级；用户明确授权紧急发布时，首条命令可携带 `--confirm-production` 在一个命令内顺序完成两阶段，但不跳过预发、证据、CAS 或确认。candidate 封存源码、public、构建配置/脚本、稳定环境/资源绑定和两目标 Runtime 哈希产物；部署不现场重建，Backend/Runtime/Root 子发布始终使用 candidate sourceRevision，并将两条服务端 deployment 闭环为 `succeeded`。两套环境身份仍完全隔离，人工验收建议和 swap/policy/权限门禁保持不变。
 - ✅ DataView `status` 仅是平台生命周期观察值；同一托管部署导致的 `active → draft → active` 不应让候选失效。`dataViewId`、`materializedViewName`、`storageMode`、其他资源状态、哈希、环境身份、CAS、租约和来源主线仍严格校验。
 - ✅ 预发 UAT 未通过时，使用 `release fail --deployment <id> --message "..." [--code <code>] [--details-json <JSON|file>] --environment preproduction --profile <name>` 写入平台审计。CLI 会先核对 deployment 属于所选预发环境；production target 或不匹配的 deployment 必须在写入前拒绝。
 - ✅ 托管发布完成后运行 `release integration-status --change <change> --profile <name> --check`。CLI 会从私有 `ship.json` 恢复血缘，必要时自动沿 production/preproduction deployment ID 查找对应 `execution.json`；失败信息必须指出实际缺失的日志或字段。