openxiangda 1.0.252 → 1.0.254

package/README.md

@@ -1,4 +1,4 @@
-<!-- OpenXiangda-Policy-Version: 6 -->
+<!-- OpenXiangda-Policy-Version: 7 -->
 # OpenXiangda
 
 OpenXiangda is a lightweight CLI and skill package for private low-code platforms.
@@ -38,7 +38,12 @@ path is used.
 `status` and `retry` locate the run across preproduction and production when
 `--environment` is omitted. Retry resumes only unfinished checkpoints, safely
 replays local Form bindings on another machine, and uses a server-side attempt
-fence so an older executor cannot continue writing after takeover.
+fence so an older executor cannot continue writing after takeover. Runtime
+build IDs include both the Runtime layer and sealed package digests, so a newly
+sealed package cannot collide with an older package that happens to contain the
+same Runtime bytes. An exact same-package retry may reuse an `uploaded` release
+only after verifying its content hash, source revision, and Runtime parent;
+immutable storage objects are never overwritten.
 
 The lower-level commands later in this README remain available for V1
 compatibility and diagnostics; do not use them to assemble a normal V2 release.
@@ -123,6 +128,8 @@ User tokens are stored in `~/.openxiangda/profiles.json` with `0600` permissions
 
 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.
 
+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.
+
 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.
 
 Existing workspaces connect to a server-side environment set with `environment attach`. If the legacy `profiles.<profile>` binding has the same `appType` as one environment, its resource mappings are copied only into that matching target (normally preproduction). Production starts with an empty mapping, and later writes update only the selected target even when both targets reuse one login profile.

package/lib/application-environments.js

@@ -33,6 +33,15 @@ const CANDIDATE_RESOURCE_OBSERVATION_FIELDS = new Set([
   'bundlePublishedAt',
 ]);
 
+function isCandidateResourceObservationField(pathParts, key) {
+  if (CANDIDATE_RESOURCE_OBSERVATION_FIELDS.has(key)) return true;
+  return (
+    key === 'status' &&
+    pathParts.length === 2 &&
+    pathParts[0] === 'dataViews'
+  );
+}
+
 function canonicalJson(value) {
   if (Array.isArray(value)) {
     return `[${value.map(item => canonicalJson(item)).join(',')}]`;
@@ -707,18 +716,22 @@ function normalizeCandidateProjectStateForHash(input, hashPolicy) {
   return state;
 }
 
-function normalizeCandidateResourceBindings(value) {
+function normalizeCandidateResourceBindings(value, pathParts = []) {
   if (Array.isArray(value)) {
-    return value.map(item => normalizeCandidateResourceBindings(item));
+    return value.map((item, index) =>
+      normalizeCandidateResourceBindings(item, [...pathParts, String(index)])
+    );
   }
   if (!value || typeof value !== 'object') return value;
   return Object.fromEntries(
     Object.entries(value)
-      .filter(([key]) => !CANDIDATE_RESOURCE_OBSERVATION_FIELDS.has(key))
+      .filter(
+        ([key]) => !isCandidateResourceObservationField(pathParts, key)
+      )
       .sort(([left], [right]) => left.localeCompare(right))
       .map(([key, item]) => [
         key,
-        normalizeCandidateResourceBindings(item),
+        normalizeCandidateResourceBindings(item, [...pathParts, key]),
       ])
   );
 }
@@ -819,18 +832,19 @@ function inspectCandidateEnvironmentBindings(candidate, state) {
         });
       }
     }
-    if (
-      !candidateBindingValueContains(
-        expectedBinding?.resources || {},
-        currentBinding.resources || {}
-      )
-    ) {
+    const expectedResources = normalizeCandidateResourceBindings(
+      expectedBinding?.resources || {}
+    );
+    const currentResources = normalizeCandidateResourceBindings(
+      currentBinding.resources || {}
+    );
+    if (!candidateBindingValueContains(expectedResources, currentResources)) {
       mismatches.push({
         targetName,
         field: 'resources',
         reason: 'sealed-resource-binding-changed',
-        expected: expectedBinding?.resources || {},
-        current: currentBinding.resources || {},
+        expected: expectedResources,
+        current: currentResources,
       });
     }
   }

package/lib/cli.js

@@ -15674,7 +15674,13 @@ async function runtime(args) {
     const files = collectRuntimeDistFiles(distDir, {
       includeSourceMaps: Boolean(flags['include-sourcemaps']),
     });
+    const declaredReleaseFiles = runtimeReleaseFileDescriptors(files);
     const totalBytes = files.reduce((sum, file) => sum + file.size, 0);
+    const reusableRuntimeRelease = await telemetry.runPhase(
+      'reuse-check',
+      async () =>
+        findRuntimeReleaseByBuildId(config, target, buildId)
+    );
     printRuntimeProgress(
       `runtime release upload: mode=${effectiveUploadMode} traceId=${traceId} files=${files.length} size=${formatBytes(totalBytes)} timeout=${uploadTimeoutMs}ms`
     );
@@ -15682,6 +15688,20 @@ async function runtime(args) {
       'upload',
       { fileCount: files.length, totalBytes, mode: effectiveUploadMode },
       async () => {
+        if (reusableRuntimeRelease) {
+          assertRuntimeReleaseReusable(reusableRuntimeRelease, {
+            appType: target.appType,
+            buildId,
+            files: declaredReleaseFiles,
+            sourceRevision: runtimeLineage.sourceRevision,
+            parentReleaseId: runtimeLineage.parentReleaseId,
+          });
+          effectiveUploadMode = 'reuse-existing';
+          printRuntimeProgress(
+            `runtime immutable release reused: releaseId=${reusableRuntimeRelease.id} buildId=${buildId} traceId=${traceId}`
+          );
+          return declaredReleaseFiles;
+        }
         if (uploadMode === 'legacy-json') {
           effectiveUploadMode = 'legacy-json';
           return files.map(file => ({
@@ -15714,6 +15734,27 @@ async function runtime(args) {
             timeoutMs: uploadTimeoutMs,
           });
         } catch (error) {
+          if (isRuntimeBuildImmutableConflict(error)) {
+            const racedRuntimeRelease = await findRuntimeReleaseByBuildId(
+              config,
+              target,
+              buildId
+            );
+            if (racedRuntimeRelease) {
+              assertRuntimeReleaseReusable(racedRuntimeRelease, {
+                appType: target.appType,
+                buildId,
+                files: declaredReleaseFiles,
+                sourceRevision: runtimeLineage.sourceRevision,
+                parentReleaseId: runtimeLineage.parentReleaseId,
+              });
+              effectiveUploadMode = 'reuse-existing';
+              printRuntimeProgress(
+                `runtime immutable release won upload race and was reused: releaseId=${racedRuntimeRelease.id} buildId=${buildId} traceId=${traceId}`
+              );
+              return declaredReleaseFiles;
+            }
+          }
           if (uploadMode !== 'auto' || !isRuntimeStagedUploadBlocked(error)) {
             throw error;
           }
@@ -16076,6 +16117,134 @@ function collectRuntimeDistFiles(distDir, options = {}) {
   return files;
 }
 
+function runtimeReleaseFileDescriptors(files) {
+  return (files || []).map(file => ({
+    path: file.path,
+    size: file.size,
+    sha256: file.sha256,
+    contentType: file.contentType,
+  }));
+}
+
+function calculateRuntimeReleaseContentHash(files) {
+  const hash = crypto.createHash('sha256');
+  for (const file of files || []) {
+    const filePath = String(file?.path || '').trim();
+    const fileSha256 = String(file?.sha256 || '').trim().toLowerCase();
+    if (!filePath || !/^[a-f0-9]{64}$/.test(fileSha256)) {
+      throw runtimeReleaseReuseError(
+        'RUNTIME_RELEASE_REUSE_LOCAL_MANIFEST_INVALID',
+        `本地 Runtime 文件描述不完整: ${filePath || '(unknown)'}`,
+        { filePath: filePath || null }
+      );
+    }
+    hash.update(filePath);
+    hash.update(fileSha256);
+  }
+  return hash.digest('hex');
+}
+
+async function findRuntimeReleaseByBuildId(config, target, buildId) {
+  const appPath = `/openxiangda-api/v1/apps/${encodeURIComponent(target.appType)}/runtime/releases`;
+  try {
+    const exact = await requestWithAuth(
+      config,
+      target.profileName,
+      `${appPath}/by-build/${encodeURIComponent(buildId)}`
+    );
+    return exact?.id ? exact : null;
+  } catch (error) {
+    if (Number(error?.status) !== 404) throw error;
+  }
+  const releases = await requestWithAuth(
+    config,
+    target.profileName,
+    appPath
+  );
+  const items = Array.isArray(releases)
+    ? releases
+    : Array.isArray(releases?.items)
+      ? releases.items
+      : [];
+  return (
+    items.find(item => String(item?.buildId || '') === String(buildId)) ||
+    null
+  );
+}
+
+function assertRuntimeReleaseReusable(existing, expected) {
+  const context = {
+    appType: expected.appType,
+    buildId: expected.buildId,
+    existingReleaseId: existing?.id || null,
+  };
+  if (String(existing?.status || '') !== 'uploaded') {
+    throw runtimeReleaseReuseError(
+      'RUNTIME_RELEASE_REUSE_STATUS_INVALID',
+      `相同 buildId 的 Runtime Release 状态为 ${existing?.status || '(unknown)'}，仅 uploaded 状态可作为失败发布的暂存恢复点`,
+      { ...context, existingStatus: existing?.status || null }
+    );
+  }
+  const expectedContentHash = calculateRuntimeReleaseContentHash(
+    expected.files
+  );
+  if (
+    String(existing?.contentHash || '').trim().toLowerCase() !==
+    expectedContentHash
+  ) {
+    throw runtimeReleaseReuseError(
+      'RUNTIME_RELEASE_REUSE_CONTENT_MISMATCH',
+      '相同 buildId 的历史 Runtime Release 内容与当前密封包不一致，拒绝复用',
+      {
+        ...context,
+        expectedContentHash,
+        existingContentHash: existing?.contentHash || null,
+      }
+    );
+  }
+  if (
+    !runtimeSourceRevisionEquals(
+      existing?.sourceRevision,
+      expected.sourceRevision
+    )
+  ) {
+    throw runtimeReleaseReuseError(
+      'RUNTIME_RELEASE_REUSE_SOURCE_MISMATCH',
+      '相同 buildId 的历史 Runtime Release 源码血缘与当前密封包不一致，拒绝复用',
+      context
+    );
+  }
+  const existingParentReleaseId =
+    String(existing?.parentReleaseId || '').trim() || null;
+  const expectedParentReleaseId =
+    String(expected.parentReleaseId || '').trim() || null;
+  if (existingParentReleaseId !== expectedParentReleaseId) {
+    throw runtimeReleaseReuseError(
+      'RUNTIME_RELEASE_REUSE_PARENT_MISMATCH',
+      '相同 buildId 的历史 Runtime Release 父版本已与当前 Runtime head 不一致，拒绝复用',
+      {
+        ...context,
+        existingParentReleaseId,
+        expectedParentReleaseId,
+      }
+    );
+  }
+  return existing;
+}
+
+function runtimeSourceRevisionEquals(left, right) {
+  return ['repo', 'baseCommit', 'treeHash'].every(
+    key => String(left?.[key] || '').trim() === String(right?.[key] || '').trim()
+  );
+}
+
+function runtimeReleaseReuseError(code, message, data = {}) {
+  const error = new Error(`${code}: ${message}`);
+  error.code = code;
+  error.data = data;
+  return error;
+}
+
 function walkRuntimeDist(rootDir, currentDir, files, options) {
   const entries = fs.readdirSync(currentDir, { withFileTypes: true });
   for (const entry of entries) {
@@ -16311,6 +16480,16 @@ function isRuntimeStagedUploadBlocked(error) {
   return /^HTTP 403\b/.test(String(error?.message || ''));
 }
 
+function isRuntimeBuildImmutableConflict(error) {
+  return (
+    Number(error?.status) === 409 &&
+    (String(error?.code || '') === 'RUNTIME_BUILD_IMMUTABLE' ||
+      /Runtime buildId .*禁止覆盖|RUNTIME_BUILD_IMMUTABLE/.test(
+        String(error?.message || '')
+      ))
+  );
+}
+
 function normalizeRuntimeUploadTimeoutMs(value) {
   const candidate =
     value === undefined || value === null || value === ''
@@ -30664,12 +30843,14 @@ function buildWorkspacePublishEnv(
 }
 
 module.exports = {
+  assertRuntimeReleaseReusable,
   buildResourceManifestSddTargets,
   buildScopeGrantSourceSyncDecision,
   deploymentEvidencePendingError,
   deploymentQueueWaitDecision,
   inspectSucceededPreproductionDeployment,
   main,
+  calculateRuntimeReleaseContentHash,
   recoveredPreproductionShipPatch,
   resolveReleaseCommandScopedFiles,
   selectSucceededPreproductionDeployment,

package/lib/delivery-v2-executor.js

@@ -1096,7 +1096,7 @@ function decorateSteps(
         '--dist',
         path.join(executionRoot, 'dist'),
         '--build-id',
-        `pkg-${runtime.digest.slice(0, 20)}`,
+        deliveryV2RuntimeBuildId(runtime?.digest, run?.packageDigest),
         '--upload-mode',
         'staged'
       );
@@ -1129,6 +1129,30 @@ function decorateSteps(
   return result;
 }
 
+function deliveryV2RuntimeBuildId(runtimeDigest, packageDigest) {
+  const normalizedRuntimeDigest = String(runtimeDigest || '')
+    .trim()
+    .toLowerCase();
+  const normalizedPackageDigest = String(packageDigest || '')
+    .trim()
+    .toLowerCase();
+  if (!/^[a-f0-9]{64}$/.test(normalizedRuntimeDigest)) {
+    throw deliveryError(
+      'DELIVERY_RUNTIME_LAYER_DIGEST_INVALID',
+      'Runtime layer digest 必须是 64 位 SHA-256',
+      false
+    );
+  }
+  if (!/^[a-f0-9]{64}$/.test(normalizedPackageDigest)) {
+    throw deliveryError(
+      'DELIVERY_PACKAGE_DIGEST_INVALID',
+      'package digest 必须是 64 位 SHA-256',
+      false
+    );
+  }
+  return `pkg-${normalizedRuntimeDigest.slice(0, 20)}-${normalizedPackageDigest.slice(0, 12)}`;
+}
+
 function packageSummary(manifest, previousManifest) {
   return {
     sourceFileCount: layerByKind(manifest, 'source')?.fileCount || 0,
@@ -1668,6 +1692,7 @@ module.exports = {
   compactStepResult,
   createDeliveryV2Executor,
   decorateSteps,
+  deliveryV2RuntimeBuildId,
   normalizeLegacyPackageTargetsForExecution,
   packageWorkspaceRoot,
   prepareAppFinalizeStep,

package/lib/policy.js

@@ -60,10 +60,14 @@ function validateEngineeringPolicy(policy) {
     policy?.release?.deletionsFailClosed !== true ||
     policy?.release?.attemptFencing !== true ||
     policy?.release?.crossMachineBindingReplay !== true ||
+    policy?.release?.deterministicRuntimeBuildIdentity !==
+      'runtime-layer-plus-package-digest' ||
+    policy?.release?.deterministicRuntimeUploadedReleaseReuse !==
+      'exact-content-source-parent-only' ||
     policy?.release?.statusAutoResolvesEnvironment !== true
   ) {
     errors.push(
-      'Delivery V2 必须启用密封构建、精确差异、删除关闭、attempt 隔离、跨机器绑定恢复和环境自动解析'
+      'Delivery V2 必须启用密封构建、精确差异、删除关闭、attempt 隔离、跨机器绑定恢复、Runtime 包级身份与严格恢复，以及环境自动解析'
     );
   }
   const ttl = Number(policy?.ownership?.defaultTtlSeconds);

package/openxiangda-skills/SKILL.md

@@ -3,7 +3,7 @@ name: openxiangda
 description: "Use OpenXiangda for private low-code platform work: app workspaces, forms, pages, resources, functions, automations, workflows, permissions, publishing, deployment, diagnosis, profiles, and the openxiangda CLI."
 ---
 
-<!-- OpenXiangda-Policy-Version: 6 -->
+<!-- OpenXiangda-Policy-Version: 7 -->
 # OpenXiangda
 
 OpenXiangda connects an AI coding workspace to the private low-code platform through a normal-user profile and `/openxiangda-api/v1`. External backends using AK/SK are a separate `openxiangda-open-api` flow.
@@ -37,6 +37,10 @@ Keep the `runId`; failures preserve successful checkpoints. `status` and
 `retry` auto-locate preproduction or production when no environment is given.
 Retry fences the previous attempt and safely replays local Form bindings, so it
 can resume from another machine without recreating completed platform writes.
+Deterministic Runtime build IDs combine the Runtime layer and sealed package
+digests, preventing cross-package provenance collisions. An exact same-package
+retry reuses an existing `uploaded` release only after exact
+content/source/parent verification and never overwrites immutable storage.
 
 ## Keep the agent loop small
 
@@ -137,6 +141,8 @@ openxiangda release ship --change <release-change> --profile <name> \
 
 For a workspace registered by `environment init` or connected by `environment attach`, production is never a direct publish target. `release ship` always executes candidate → preproduction → production. The normal first invocation stops after preproduction; a later `--confirm-production` promotes the same candidate. If the user explicitly authorizes an emergency, putting `--confirm-production` on the first invocation runs both phases in one command without skipping preproduction, evidence, CAS, or confirmation. The sealed candidate contains source/build/public/script inputs, stable environment/resource bindings, and hashed target-specific Runtime artifacts; deployment uploads those exact artifacts with no rebuild and closes each server deployment as `succeeded`. Human acceptance remains recommended and may be recorded with `--acceptance-note`. Lower-level candidate/deploy/test/fail/promote commands are recovery primitives. `release fail` is preproduction-only: pass an explicit deployment and audit message, and the CLI verifies the deployment belongs to the selected preproduction environment before it writes optional code/details. Keep preproduction and production identities isolated, and retain the existing authorization/CAS rules for environment swap and policy changes. Use `openxiangda studio` for bindings, drift, evidence, and safe next actions.
 
+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.
 
 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/references/workspace-state.md

@@ -102,6 +102,7 @@ Environment-managed workspaces add a logical application and target-specific bin
 - Local resource keys are logical codes.
 - Live IDs and lightweight runtime aliases are nested under the profile that produced them.
 - `resources.dataViews` is keyed by data view `code` and stores only profile-local platform metadata such as `dataViewId`, `materializedViewName`, and last known `status`.
+- The stored DataView `status` is observational: managed staging legitimately moves it between `draft` and `active`. Candidate binding validation ignores only that field, including for older sealed candidates, while keeping `dataViewId`, `materializedViewName`, `storageMode`, and all non-DataView status fields strict.
 - Data view definitions, refresh config, permissions, and source `formCode` references belong in `src/resources/data-views/*.json`, not in state.
 - Do not store business configuration or secrets in `.openxiangda/state.json`; store those in `src/resources/`.
 - CLI writes use a lock, a three-way merge at profile/resource-key granularity, and fsync + atomic rename. Concurrent writes to different profiles or logical resource keys are preserved; competing writes to the same field fail with `OPENXIANGDA_STATE_CONFLICT` and must be retried from a freshly loaded state.

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

@@ -30,7 +30,11 @@ unsupported and fail before remote writes. V2 executes authored builds with the
 CLI-sealed toolchain, never a workspace `node_modules` or custom builder.
 `status`/`retry` auto-resolve the run environment if omitted. Retry preserves
 completed checkpoints, fences the older attempt, and replays only local Form
-bindings when resuming on a different machine.
+bindings when resuming on a different machine. Deterministic Runtime build IDs
+combine the Runtime layer and sealed package digests, preventing provenance
+collisions across packages with identical Runtime bytes. An `uploaded` release
+is reused only for an exact same-package retry when its content hash, source
+revision, and parent Runtime release match; all other identities fail closed.
 
 ## Resolve the boundary
 
@@ -140,6 +144,8 @@ 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 appType-matching target. `release ship` always runs candidate → preproduction → production. Normally the first invocation stops at `awaiting_production_confirmation` and a later `--confirm-production` invocation promotes the same candidate. When the user explicitly authorizes an emergency release, `--confirm-production` may be supplied on the first invocation to execute both phases in one command; it bypasses no preproduction, evidence, CAS, or confirmation gate. Candidate sealing includes source/build/public/script inputs, stable environment/resource bindings, and hashed target-specific Runtime artifacts. Deployment reuses those artifacts without rebuilding and completes both server deployment records to `succeeded`. Human acceptance remains recommended and an optional `--acceptance-note` records it. Direct `release publish` to either managed target fails closed. Environment swap and policy updates retain their existing explicit authorization, CAS, and permission rules. `openxiangda studio` is the local loopback-only developer view and exposes only registered safe actions.
 
+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.
 
 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.252",
+  "version": "1.0.254",
   "description": "OpenXiangda CLI, workspace build tools, runtime SDK, and form components.",
   "private": false,
   "bin": {

package/policy/openxiangda-policy.json

@@ -1,6 +1,6 @@
 {
   "schemaVersion": "openxiangda_engineering_policy_v1",
-  "policyVersion": 6,
+  "policyVersion": 7,
   "risk": {
     "levels": ["L0", "L1", "L2", "L3"],
     "quickMaxLevel": "L1",
@@ -39,6 +39,8 @@
     "deletionsFailClosed": true,
     "attemptFencing": true,
     "crossMachineBindingReplay": true,
+    "deterministicRuntimeBuildIdentity": "runtime-layer-plus-package-digest",
+    "deterministicRuntimeUploadedReleaseReuse": "exact-content-source-parent-only",
     "statusAutoResolvesEnvironment": true,
     "v2RequiresSdd": false,
     "v2RequiresGitMainline": false,

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

@@ -21,7 +21,7 @@ This is an OpenXiangda React SPA workspace using Delivery V2. See [DELIVERY.md](
 ## Always
 
 - Delivery V2 derives exact scope and does not require SDD, Git clean, `--change`, `--only`, candidate, or ship.
-- Treat `check --json` as the authoritative exact delta and execution plan. Deletions and unsealed third-party build dependencies fail before writes; package execution uses only the CLI toolchain and never links workspace `node_modules`. `status`/`retry` auto-locate the environment, while retry fences the old attempt and replays only cross-machine local Form bindings.
+- Treat `check --json` as the authoritative exact delta and execution plan. Deletions and unsealed third-party build dependencies fail before writes; package execution uses only the CLI toolchain and never links workspace `node_modules`. `status`/`retry` auto-locate the environment, while retry fences the old attempt and replays only cross-machine local Form bindings. Runtime build IDs combine the Runtime layer and sealed package digests; only an exact same-package `uploaded` release with matching content, source, and parent may be reused, and immutable storage is never overwritten.
 - Writes and deploys must pass `--profile <name>` explicitly.
 - Architecture-class work is plan-gated: run `openxiangda design gates --topic <code> --json` and wait for confirmation.
 - Give every task an isolated worktree/branch and one explicit development change; feature worktrees never publish. Merge approved commits to the remote default branch, create one `sdd bundle <release-change> --changes ...`, commit/push it, then publish once from the synchronized clean main/master checkout.

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

@@ -21,7 +21,7 @@ This is an OpenXiangda React SPA workspace using Delivery V2. Read [DELIVERY.md]
 ## Always
 
 - Delivery V2 自动计算精确范围，不要求 SDD、Git clean、`--change`、`--only` 或 candidate/ship。
-- `check --json` 是 V2 权威预检：确认精确资源差异和执行计划。删除与未密封第三方构建依赖在写入前失败；包执行只用 CLI 工具链且不链接工作区 `node_modules`。`status`/`retry` 自动定位环境，retry 以 attempt 隔离旧执行器并仅重放跨机器所需的本地 Form 绑定。
+- `check --json` 是 V2 权威预检：确认精确资源差异和执行计划。删除与未密封第三方构建依赖在写入前失败；包执行只用 CLI 工具链且不链接工作区 `node_modules`。`status`/`retry` 自动定位环境，retry 以 attempt 隔离旧执行器并仅重放跨机器所需的本地 Form 绑定。Runtime buildId 同时包含 Runtime layer 与密封包摘要；仅同包 `uploaded` Release 在内容、源码、父版本完全一致时复用，不覆盖不可变存储对象。
 - 发布和写平台资源必须显式传 `--profile <name>`。
 - 架构类需求先跑 `openxiangda design gates --topic <code> --json` 并等用户确认。
 - 每个任务使用独立 worktree/branch 和一个开发 change，但 feature worktree 不发布。批准提交先合并并 push 到远端默认主分支，再创建一个 `sdd bundle <release-change> --changes ...`，从同步且干净的 main/master 一次发布。

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

@@ -1,11 +1,11 @@
-<!-- OpenXiangda-Policy-Version: 6 -->
+<!-- OpenXiangda-Policy-Version: 7 -->
 # AGENTS.md — OpenXiangda React SPA 应用工作区
 
 本工作区是标准 React 18 + Vite + React Router 应用。默认模板只提供应用壳、账号菜单和一个首页，不是开发验证控制台。
 
 ## Delivery V2（发布唯一入口）
 
-本工作区声明 `deliveryVersion: 2`，正常发布只使用 `openxiangda check`、`openxiangda deploy`、`openxiangda status`、`openxiangda retry`、`openxiangda rollback`，完整约定见 [DELIVERY.md](DELIVERY.md)。V2 按资源指纹计算精确范围，使用不依赖工作区 `node_modules` 的 CLI 密封工具链，并在服务端持久化 ReleaseRun、attempt 和检查点；跨机器重试只重放本地 Form 绑定，删除和未密封构建依赖在写入前失败关闭。`status`/`retry` 未指定环境时会自动定位预发或生产。V2 不要求 SDD、Git clean、主线 ancestry、`--change`、`--only` 或生产确认参数。本文后续出现的 `resource publish`、`runtime deploy`、`release publish/ship`、candidate、SDD/mainline 发布门禁均为 V1 底层兼容说明，不得用于 V2 正常发布。
+本工作区声明 `deliveryVersion: 2`，正常发布只使用 `openxiangda check`、`openxiangda deploy`、`openxiangda status`、`openxiangda retry`、`openxiangda rollback`，完整约定见 [DELIVERY.md](DELIVERY.md)。V2 按资源指纹计算精确范围，使用不依赖工作区 `node_modules` 的 CLI 密封工具链，并在服务端持久化 ReleaseRun、attempt 和检查点；跨机器重试只重放本地 Form 绑定。Runtime buildId 同时包含 Runtime layer 与密封包摘要，避免相同 Runtime 字节在不同包之间发生来源碰撞；同包重试仅在历史 Release 为 `uploaded` 且内容、源码、父版本完全一致时复用，不覆盖不可变存储对象。删除和未密封构建依赖在写入前失败关闭。`status`/`retry` 未指定环境时会自动定位预发或生产。V2 不要求 SDD、Git clean、主线 ancestry、`--change`、`--only` 或生产确认参数。本文后续出现的 `resource publish`、`runtime deploy`、`release publish/ship`、candidate、SDD/mainline 发布门禁均为 V1 底层兼容说明，不得用于 V2 正常发布。
 
 ## 开发原则
 
@@ -60,6 +60,8 @@ openxiangda commands --json
 
 工作区一旦通过 `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` 用于查看绑定、漂移、候选、部署和证据。
 
+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`；失败信息必须指出实际缺失的日志或字段。

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

@@ -30,7 +30,11 @@ Rules:
   dependencies fail preflight.
 - On failure, keep the `runId`. `status` and `retry` auto-locate its environment
   when omitted. Retry preserves successful checkpoints, fences the previous
-  attempt, and safely replays local Form bindings on another machine.
+  attempt, and safely replays local Form bindings on another machine. Runtime
+  build IDs include the Runtime layer and sealed package digests, preventing
+  cross-package provenance collisions. A same-package retry reuses an existing
+  Runtime release only in `uploaded` state after exact content, source, and
+  parent verification; storage is never overwritten.
 - Project `.env`, credentials, private keys, `.git`, `node_modules`, `dist`,
   and generated `.openxiangda` state are never included in the authored source
   layer. Runtime output is a separate immutable layer.

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

@@ -27,7 +27,7 @@ This is a `sy-lowcode-app-workspace` managed by the `openxiangda` CLI. See [AGEN
 
 ## Always
 
-- For `deliveryVersion: 2`, use only Delivery V2 commands. Later V1 SDD/mainline/`--only`/candidate/ship text is compatibility guidance and must not be mixed into V2.
+- For `deliveryVersion: 2`, use only Delivery V2 commands. Runtime build IDs combine the Runtime layer and sealed package digests; retry may reuse only an exact same-package `uploaded` release whose content, source, and parent match. Immutable storage is never overwritten. Later V1 SDD/mainline/`--only`/candidate/ship text is compatibility guidance and must not be mixed into V2.
 - Treat V2 `check --json` as the authoritative exact delta and execution plan. Deletions and unsealed third-party build dependencies fail before writes; package execution uses only the CLI toolchain and never links workspace `node_modules`. `status`/`retry` auto-locate the environment, while retry fences the old attempt and replays only cross-machine local Form bindings.
 - Give every task an isolated worktree/branch and one development change; feature worktrees never publish. Merge approved commits to the remote default branch, create one `sdd bundle`, commit/push it, and publish once from synchronized clean main/master.
 - Close tasks from canonical main only. Review `openxiangda workspace cleanup`, then run `openxiangda workspace cleanup --apply` for that exact hashed `SAFE` plan; it revalidates managed worktrees under the owner lock, never picks up newly-safe entries, and never runs global `git worktree prune`. Review stale records separately.

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

@@ -27,7 +27,7 @@ This is a `sy-lowcode-app-workspace` managed by the `openxiangda` CLI. Read [AGE
 
 ## Always
 
-- `deliveryVersion: 2` 的正常发布只允许 Delivery V2 命令；后续 V1 SDD/mainline/`--only`/candidate/ship 内容仅作兼容说明，不得混入 V2。
+- `deliveryVersion: 2` 的正常发布只允许 Delivery V2 命令；Runtime buildId 同时包含 Runtime layer 与密封包摘要，仅同包 `uploaded` Release 在内容、源码、父版本完全一致时复用，不覆盖不可变存储对象；后续 V1 SDD/mainline/`--only`/candidate/ship 内容仅作兼容说明，不得混入 V2。
 - V2 `check --json` 是权威预检：确认精确资源差异和执行计划。删除与未密封第三方构建依赖在写入前失败；包执行只用 CLI 工具链且不链接工作区 `node_modules`。`status`/`retry` 自动定位环境，retry 以 attempt 隔离旧执行器并仅重放跨机器所需的本地 Form 绑定。
 - 每个任务使用独立 worktree/branch 和一个开发 change，但 feature worktree 不发布。批准提交先合并并 push 到远端默认主分支，再创建一个 `sdd bundle`，从同步且干净的 main/master 一次发布。
 - 合并、push、发布和 `release end` 后，回到 canonical 主工作区先审阅 `openxiangda workspace cleanup`，再执行 `openxiangda workspace cleanup --apply` 应用精确哈希计划。CLI 在 owner lock 内复核，只删除已审阅的 managed `SAFE` 项，不顺带处理后来才安全的项，也不执行全局 `git worktree prune`；stale 记录单独人工审阅。

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

@@ -1,4 +1,4 @@
-<!-- OpenXiangda-Policy-Version: 6 -->
+<!-- OpenXiangda-Policy-Version: 7 -->
 # AGENTS.md — OpenXiangda 工作区 AI 强约束
 
 > 任何 AI（Qoder / Claude / Codex / Cursor / Copilot 等）在本工作区操作前 **必须先读完本文件**。
@@ -8,7 +8,7 @@
 
 **本工作区声明 `deliveryVersion: 2`。所有“发布 / 上线 / 部署 / publish / deploy / ship / release”请求只使用 `openxiangda check`、`openxiangda deploy`、`openxiangda status`、`openxiangda retry`、`openxiangda rollback`，完整约定见 [DELIVERY.md](DELIVERY.md)。**
 
-Delivery V2 自动从期望状态按资源指纹计算精确范围，使用 CLI 密封工具链封存内容寻址 App Package，并在服务端持久化 ReleaseRun、attempt 和检查点；包执行不链接工作区 `node_modules`。`status`/`retry` 可自动定位预发或生产环境，跨机器重试只重放本地 Form 绑定并跳过已完成的平台写入。删除和未密封的第三方构建依赖会在远程写入前失败关闭。它不要求 SDD、Git clean、主线 ancestry、`--change`、`--only` 或生产确认参数。本文后续出现的 `workspace publish`、`resource publish`、`runtime deploy`、`release publish/ship`、candidate、SDD/mainline 发布门禁均属于 V1 底层兼容说明，不得用于 V2 正常发布。
+Delivery V2 自动从期望状态按资源指纹计算精确范围，使用 CLI 密封工具链封存内容寻址 App Package，并在服务端持久化 ReleaseRun、attempt 和检查点；包执行不链接工作区 `node_modules`。`status`/`retry` 可自动定位预发或生产环境，跨机器重试只重放本地 Form 绑定并跳过已完成的平台写入。Runtime buildId 同时包含 Runtime layer 与密封包摘要，避免相同 Runtime 字节在不同包之间发生来源碰撞；同包重试仅在历史 Release 为 `uploaded` 且内容、源码、父版本完全一致时复用，绝不覆盖不可变存储对象。删除和未密封的第三方构建依赖会在远程写入前失败关闭。它不要求 SDD、Git clean、主线 ancestry、`--change`、`--only` 或生产确认参数。本文后续出现的 `workspace publish`、`resource publish`、`runtime deploy`、`release publish/ship`、candidate、SDD/mainline 发布门禁均属于 V1 底层兼容说明，不得用于 V2 正常发布。
 
 **架构类需求先过设计门。** 新应用、复杂页面、登录注册、公开访问、权限数据范围、流程自动化、连接器/通知等需求，先 `openxiangda doctor --json` + `openxiangda design gates --topic <code> --json`。只有仍存在会改变实现方向的业务、安全或数据选择时才输出设计并等待确认；用户已经给出具体需求与验收标准时，直接记录结构化 SDD 范围并实现，不再写长篇设计或重复确认。
 
@@ -65,6 +65,7 @@ Delivery V2 自动从期望状态按资源指纹计算精确范围，使用 CLI
 - ✅ 未登记环境的旧工作区，正式 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/权限门禁保持不变。
+- ✅ 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`；失败信息必须指出实际缺失的日志或字段。
 - ✅ 只有已审计目标早已进入权威主线、线上却由多次历史 lineage 组成且无法对应单一 Git 基线时，第一次 `release ship` 才可增加 `--adopt-online-baseline --adoption-reason "..."`；该意图冻结进私有 `ship.json` 并由后续 `--confirm-production` 自动复用。仅允许精确非删除 selectors，冻结 Head、change/lease、服务端 CAS、staged children 与单次 App finalize 仍是硬门禁。

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

@@ -30,7 +30,11 @@ Rules:
   dependencies fail preflight.
 - On failure, keep the `runId`. `status` and `retry` auto-locate its environment
   when omitted. Retry preserves successful checkpoints, fences the previous
-  attempt, and safely replays local Form bindings on another machine.
+  attempt, and safely replays local Form bindings on another machine. Runtime
+  build IDs include the Runtime layer and sealed package digests, preventing
+  cross-package provenance collisions. A same-package retry reuses an existing
+  Runtime release only in `uploaded` state after exact content, source, and
+  parent verification; storage is never overwritten.
 - Project `.env`, credentials, private keys, `.git`, `node_modules`, `dist`,
   and generated `.openxiangda` state are never included in the authored source
   layer. Runtime output is a separate immutable layer.