openxiangda 1.0.165 → 1.0.166

package/README.md

@@ -36,14 +36,14 @@ openxiangda design gates --topic public-access --json
 openxiangda sdd context --change add-customer-page --changed --json
 openxiangda sdd propose add-customer-page --pages customer --runtime
 openxiangda sdd approve add-customer-page --summary "用户确认"
-openxiangda sdd verify add-customer-page --changed --stage implementation
+openxiangda sdd verify add-customer-page --changed --stage implementation --profile dev
 openxiangda resource validate function --only customer_get,customer_save --profile dev
 openxiangda resource plan function --only customer_get,customer_save --profile dev
 openxiangda runtime deploy --change add-customer-page --profile dev --no-activate --json
-openxiangda sdd verify add-customer-page --changed --stage prepublish
+openxiangda sdd verify add-customer-page --changed --stage prepublish --profile dev
 openxiangda release begin --change add-customer-page --profile dev
-openxiangda resource publish function --only customer_get,customer_save --change add-customer-page --profile dev
-openxiangda runtime activate <reviewedReleaseId> --change add-customer-page --profile dev
+openxiangda resource publish function --only customer_get,customer_save --stage-only --change add-customer-page --profile dev
+openxiangda release app-finalize --staged-resources-json .openxiangda/releases/add-customer-page/staged-resources.json --change add-customer-page --profile dev
 openxiangda release end --profile dev
 openxiangda resource explain public-access --json
 openxiangda inspect app --profile dev --json
@@ -60,7 +60,7 @@ Concurrent development may still upload immutable previews with `--no-activate`,
 
 After a live promotion, merge or fast-forward the exact frozen publish commit into the authoritative default branch and push it before closing the task. `openxiangda release integration-status --profile <name>` checks the live remote tip; normal `release end` keeps the reconciliation evidence and returns `RELEASE_MAIN_MERGE_PENDING` until that exact SHA is present. Squash/rebase does not preserve the published commit and therefore does not pass. The authoritative target is always the live default `main`/`master` of `origin` (or the repository's sole remote); CLI flags, environment variables, local-only branches, and lease expiry cannot bypass it. OpenXiangda's own `npm publish` and the platform image release script apply the stronger pre-release form of the same rule: root and pinned submodule commits must already be in their remote default branches.
 
-Source-triggered Function and Automation publishing is source-only by default. On a current platform, every eligible existing Function and Automation in one command is uploaded, prepared, verified, and activated through one immutable Backend Release transaction; a stale target therefore causes zero resource writes instead of failing halfway through 88 Functions and 11 Automations. 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. Only an older platform whose Backend Release `head` route explicitly returns HTTP 404 uses the compatibility per-resource source PATCH, with a warning on stderr. 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.
+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.
 
 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.
 
@@ -94,7 +94,7 @@ Domestic npm mirrors may lag and return an older OpenXiangda version. `openxiang
 
 Architecture-class requests are plan-gated by default. For new apps, complex pages, login/register, public/no-login access, role/data-scope design, workflow/automation, App Function, connector, notification, and external integration work, AI agents must plan first and implement only after the user confirms the design.
 
-Risk is tiered. Read-only/docs/tests are L0. Narrow reversible copy/style or single existing binding fixes are L1 and use `openxiangda sdd quick` to record exact files/resources plus the user's already-explicit intent; do not add a second proposal/approval ceremony to such a small change. Function quick fixes additionally require the complete negative risk assessment. Schema, business Functions, Automation/Workflow, permissions, auth/public access, data writes, and runtime/config are L2; irreversible production or app-wide changes are L3. L2/L3 use an explicit SDD change from context through plan/check/verify/publish/archive. Run `verify --stage implementation` while developing, `prepublish` before promotion, `postpublish` after live probes, and `archive` only with complete evidence. Emergency releases can still use `--sdd-bypass --reason "..."` and remain auditable.
+Risk is tiered. Read-only/docs/tests are L0. Narrow reversible copy/style or single existing binding fixes are L1 and use `openxiangda sdd quick` to record exact files/resources plus the user's already-explicit intent; do not add a second proposal/approval ceremony to such a small change. Function quick fixes additionally require the complete negative risk assessment. Schema, business Functions, Automation/Workflow, permissions, auth/public access, data writes, and runtime/config are L2; irreversible production or app-wide changes are L3. L2/L3 use an explicit SDD change from context through plan/check/verify/publish/archive. `verify --stage implementation` deliberately does not block coding on unfinished prose/checklists; plain `verify` stops at the prepublish boundary and never demands future postpublish/archive evidence. Exact argv and staged-child scope become strict only at the write/finalize boundary. Emergency releases can still use `--sdd-bypass --reason "..."` and remain auditable.
 
 Every concurrent task should use its own Git worktree/branch. `sdd propose|quick|context` automatically claims the current worktree for the active `CODEX_THREAD_ID`; a second task receives `WORKTREE_OWNED_BY_ANOTHER_TASK` before it can publish through the shared directory. Inspect or explicitly release ownership with `openxiangda workspace ownership status|release`; forced takeover requires a reason. Live `resource publish` requires exact `--only <codes>` or `--code <code>`; an app-wide publish needs explicit `--all --reason`, even when SDD is bypassed. The approved change scope, not the checkout's global dirty set, is the release boundary.
 
@@ -127,7 +127,7 @@ For source-only Function/Automation changes, the final command does not reconstr
 
 Page repair publishing is staged by default. It first freezes `pages/snapshot`, sends the active Page Release parent plus every page revision, and uses revision `0` only for a genuinely new page. Review with `openxiangda page head|releases|detail|diff`; activate an immutable complete release explicitly with `page activate <releaseId> --change <change>`. Historical activation requires `page rollback <releaseId> --rollback --change <change> --reason "..."`. Parent or revision conflicts are never refreshed or retried automatically.
 
-Use `openxiangda release app-capture` to read the platform's transactionally consistent whole-app manifest. For a normal multi-resource release, stage the changed Runtime/Page/Backend/Form child releases, write only their immutable entries (`kind`, `identity.releaseId`, `hash`, plus `identity.formUuid` for forms) to a JSON array, then run `app-finalize --change <change> --staged-resources-json <JSON|file>`. The CLI overlays Runtime/Page/Backend by singleton kind and Form by `formUuid`, preserves every unmodified active child from the read-only capture, and sends the complete frozen manifest through `prepare -> verify -> activate` with `activateStagedChildren=true`. The child heads and App head therefore switch in one database transaction (`atomic_staged_children_v1`); any parent, revision, asset, or hash drift stops with zero root activation and is never refreshed or retried. `app-prepare` accepts the same overlay for a manual reviewed flow, and `app-activate <releaseId> --activate-staged-children` performs the explicit atomic activation. Calling `app-finalize` without an overlay remains a compatibility-only retrospective aggregation of already-active children. `app-rollback <releaseId> --change <change> --reason "..."` prepares the audited rollback manifest.
+Use `openxiangda release app-capture` to read the platform's transactionally consistent whole-app manifest. For a normal multi-resource release, stage the changed Runtime/Page/Backend/Form child releases; commands carrying the same `--change` atomically accumulate their canonical immutable entries in `.openxiangda/releases/<change>/staged-resources.json`. Then run `app-finalize --change <change> --staged-resources-json <JSON|file>`. The CLI overlays Runtime/Page/Backend by singleton kind and Form by `formUuid`, preserves every unmodified active child from the read-only capture, and sends the complete frozen manifest through `prepare -> verify -> activate` with `activateStagedChildren=true`. Runtime staging never rewrites local active Runtime state, and a malformed staged response fails closed. The child heads and App head therefore switch in one database transaction (`atomic_staged_children_v1`); any parent, revision, asset, or hash drift stops with zero root activation and is never refreshed or retried. `app-prepare` accepts the same overlay for a manual reviewed flow, and `app-activate <releaseId> --activate-staged-children` performs the explicit atomic activation. Calling `app-finalize` without an overlay remains a compatibility-only retrospective aggregation of already-active children. `app-rollback <releaseId> --change <change> --reason "..."` prepares the audited rollback manifest.
 
 For small live fixes, diagnosis, or AI command discovery, use first-class resource commands. They all accept `--profile`, `--app-type`, `--json`, `--json-file`, `--dry-run`, and write commands can use `--write-manifest` to avoid repo/platform drift:
 

package/lib/change-baseline.js

@@ -5,6 +5,7 @@ const os = require('os');
 const path = require('path');
 
 const { saveProjectState } = require('./config');
+const { runWorkspaceJsCodeBuildBatch } = require('./js-code-build');
 
 const SOURCE_KIND_BY_RESOURCE_KIND = Object.freeze({
   Function: 'functions',
@@ -262,15 +263,35 @@ function buildGitBaseSourceArtifacts({
     const specs = normalizedTargets
       .map(target => `${target.sourceKind}:${target.code}`)
       .join(',');
-    const batch = runBuildCommand(
-      packageManager,
-      ['build-js-code', '--scripts', specs],
+    const batchProcess = runWorkspaceJsCodeBuildBatch(
       buildRoot,
-      buildEnv
+      normalizedTargets.map(target => ({
+        sourceKind: target.sourceKind,
+        scriptCode: target.code,
+      })),
+      {
+        packageManager,
+        spawnOptions: {
+          env: buildEnv,
+          maxBuffer: 16 * 1024 * 1024,
+        },
+      }
     );
+    const batch = normalizeBuildProcessResult(batchProcess, [
+      packageManager,
+      'build-js-code',
+      '--scripts',
+      specs,
+    ]);
 
-    let buildMode = 'batch';
+    let buildMode =
+      batchProcess.openxiangdaBuildMode === 'canonical-scoped'
+        ? 'canonical-scoped'
+        : 'batch';
     if (!batch.ok) {
+      if (batchProcess.openxiangdaBuildMode === 'canonical-scoped') {
+        throw buildFailureError(normalizedTargets[0], batch);
+      }
       buildMode = 'legacy-fallback';
       for (const target of normalizedTargets) {
         const legacy = runBuildCommand(
@@ -303,6 +324,11 @@ function buildGitBaseSourceArtifacts({
       const artifactPath = path.resolve(buildRoot, ...relativePath.split('/'));
       assertArtifactFileSafe(buildRoot, artifactPath, target);
       const artifactHash = sha256File(artifactPath);
+      const sourceHash = readBuiltSourceHash(
+        buildRoot,
+        target.sourceKind,
+        target.code
+      );
       const key = `${target.kind}:${target.code}`;
       artifacts[key] = {
         kind: target.kind,
@@ -311,6 +337,7 @@ function buildGitBaseSourceArtifacts({
         relativePath,
         artifactHash,
         sha256: artifactHash,
+        ...(sourceHash ? { sourceHash } : {}),
       };
       localBaseArtifactHashes[key] = artifactHash;
     }
@@ -324,6 +351,31 @@ function buildGitBaseSourceArtifacts({
   });
 }
 
+function readBuiltSourceHash(buildRoot, sourceKind, code) {
+  const key = `${sourceKind}/${code}`;
+  for (const filename of [
+    'build-cache.json',
+    'build-cache.cli-v4.json',
+    'build-cache.cli-v3.json',
+  ]) {
+    try {
+      const cache = JSON.parse(
+        fs.readFileSync(
+          path.join(buildRoot, '.openxiangda', filename),
+          'utf8'
+        )
+      );
+      const sourceHash = String(
+        cache?.targets?.[key]?.sourceHash || ''
+      ).toLowerCase();
+      if (/^[a-f0-9]{64}$/.test(sourceHash)) return sourceHash;
+    } catch {
+      // Custom builders are allowed to omit the optional lineage cache.
+    }
+  }
+  return null;
+}
+
 function withGitBaseWorkspace(
   {
     cwd = process.cwd(),
@@ -751,6 +803,20 @@ function runBuildCommand(packageManager, args, cwd, env) {
   };
 }
 
+function normalizeBuildProcessResult(result, fallbackCommand) {
+  return {
+    ok: !result.error && result.status === 0,
+    status: result.status,
+    error: result.error || null,
+    stdout: String(result.stdout || ''),
+    stderr: String(result.stderr || ''),
+    command:
+      Array.isArray(result.spawnargs) && result.spawnargs.length > 0
+        ? result.spawnargs
+        : fallbackCommand,
+  };
+}
+
 function buildIsolatedEnvironment(
   env,
   { currentWorkspaceRoot, buildRoot, repositoryRoot, extractRoot }
@@ -782,7 +848,9 @@ function buildIsolatedEnvironment(
 function buildFailureError(target, batch, legacy) {
   const output = [
     summarizeCommandFailure('batch', batch),
-    summarizeCommandFailure(`legacy ${target.kind}:${target.code}`, legacy),
+    ...(legacy
+      ? [summarizeCommandFailure(`legacy ${target.kind}:${target.code}`, legacy)]
+      : []),
   ].join('\n');
   return changeBaselineError(
     'CHANGE_BASELINE_BUILD_FAILED',