openxiangda 1.0.202 → 1.0.204

package/README.md

@@ -66,6 +66,11 @@ openxiangda studio
 # 环境托管应用日常发布：首次命令只部署预发并停止
 openxiangda release ship --change mainline-release --profile dev
 
+# 仅限已审计的多历史 lineage、精确非删除恢复；仍保留冻结 Head、CAS、租约和原子 finalize
+openxiangda release ship --change mainline-release --profile dev \
+  --adopt-online-baseline \
+  --adoption-reason "已合入主线的目标来自多次历史发布，无法对应单一 Git 基线"
+
 # 确认预发结果后，再以同一 candidate 晋级正式；验收备注可选
 openxiangda release ship --change mainline-release --profile dev \
   --confirm-production
@@ -77,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. 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. 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.
 

package/lib/application-environments.js

@@ -532,13 +532,12 @@ function withManagedReleaseForwardedFlags(stepId, args = [], flags = {}) {
   ) {
     forwarded.push('--include-noop');
   }
-  const baselineAdoptionStages = new Set([
-    'form-stage',
-    'backend-stage',
-    'workflow-stage',
-  ]);
+  const isExactResourcePublish =
+    forwarded[0] === 'resource' &&
+    forwarded[1] === 'publish' &&
+    (forwarded.includes('--only') || forwarded.includes('--code'));
   if (
-    !baselineAdoptionStages.has(stepId) ||
+    !isExactResourcePublish ||
     !flags['adopt-online-baseline']
   ) {
     return forwarded;

package/lib/change-baseline.js

@@ -976,6 +976,10 @@ function buildIsolatedEnvironment(
   }
   return {
     ...isolated,
+    // Git-base builds are always non-interactive. Force CI even when the
+    // parent shell explicitly carries CI=false so pnpm never prompts to purge
+    // a linked node_modules directory and then aborts because no TTY exists.
+    CI: 'true',
     INIT_CWD: buildRoot,
     LOWCODE_WORKSPACE_ROOT: buildRoot,
     OPENXIANGDA_WORKSPACE_ROOT: buildRoot,

package/lib/cli.js

@@ -68,6 +68,7 @@ const {
   buildWorkspaceReleaseCommands,
   buildWorkspaceReleaseSteps,
   commandFromArgs,
+  directResourceTypeForKey,
   normalizeReleaseTargets,
   releasePlanHash,
 } = require('./release-plan');
@@ -302,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] [--json]
+  openxiangda release ship|candidate|deploy|test|promote|rollback [--candidate id] [--environment target] [--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]
@@ -3086,6 +3087,8 @@ const RELEASE_SHIP_SUPPORTED_FLAGS = new Set([
   'app-type',
   'since',
   'expand-dependencies',
+  'adopt-online-baseline',
+  'adoption-reason',
   'confirm-production',
   'acceptance-note',
   'evidence-json',
@@ -3106,6 +3109,22 @@ function assertReleaseShipFlags(flags = {}) {
     error.unsupportedFlags = unsupported;
     throw error;
   }
+  const adoptionRequested = Boolean(flags['adopt-online-baseline']);
+  const adoptionReason = String(flags['adoption-reason'] || '').trim();
+  if (!adoptionRequested && adoptionReason) {
+    const error = new Error(
+      'RELEASE_SHIP_ADOPTION_FLAG_REQUIRED: --adoption-reason 必须与 --adopt-online-baseline 一起使用；命令已在任何 candidate/deployment 写入前终止'
+    );
+    error.code = 'RELEASE_SHIP_ADOPTION_FLAG_REQUIRED';
+    throw error;
+  }
+  if (adoptionRequested && adoptionReason.length < 8) {
+    const error = new Error(
+      'RELEASE_SHIP_ADOPTION_REASON_REQUIRED: --adopt-online-baseline 必须提供至少 8 个字符的 --adoption-reason；命令已在任何 candidate/deployment 写入前终止'
+    );
+    error.code = 'RELEASE_SHIP_ADOPTION_REASON_REQUIRED';
+    throw error;
+  }
 }
 
 async function runApplicationShipCommand(
@@ -3119,7 +3138,7 @@ async function runApplicationShipCommand(
     readStringFlag(flags, 'change') || positional[0];
   if (!changeId) {
     fail(
-      '用法: openxiangda release ship --change <id> [--confirm-production] [--acceptance-note "..."]'
+      '用法: openxiangda release ship --change <id> [--adopt-online-baseline --adoption-reason "..."] [--confirm-production] [--acceptance-note "..."]'
     );
   }
   const logicalApp = requireLogicalApplication(initialTarget);
@@ -3550,11 +3569,12 @@ 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] [--confirm-production] [--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 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 "已审计目标来自多次历史发布"',
       '  # 确认预发结果后；可选 --acceptance-note 留下人工验收记录：',
       '  openxiangda release ship --change <id> --profile <name> --confirm-production',
       '  openxiangda release publish --change <id> --profile <name>',
@@ -3569,6 +3589,7 @@ async function release(args) {
       '  openxiangda release app-finalize --change <id> --staged-resources-json <JSON|file> --profile <name>',
       '说明:',
       '  - ship 是环境托管应用的两段式快车道：首次只部署预发并停止；确认预发结果后，第二次以同一 candidate 晋级正式。人工验收备注可选。',
+      '  - 已合入主线但线上来自多次历史 lineage 的精确非删除恢复可显式使用 --adopt-online-baseline 与 --adoption-reason；仍保留冻结 Head、CAS、租约、staged children 和单次 App finalize。',
       '  - ship 当前不支持 --dry-run；任何未声明参数都会在 candidate/deployment 写入前 fail-closed。需要只读检查时使用 environment status/diff 与 release status。',
       '  - publish 默认等待租约并按私有执行日志恢复；上次写结果不确定时必须只读核对后显式 --resume-after-review。',
       '  - app-head 默认只输出紧凑 head 摘要；需要完整 manifest 时显式追加 --full。',
@@ -12901,8 +12922,21 @@ function buildResourceManifestSddTargets(manifest, planActions = []) {
     'workflows',
     'formSettings',
   ]);
+  const resourceSelectors = Object.fromEntries(
+    RESOURCE_SPECS
+      .filter(
+        spec =>
+          !codeResourceKeys.has(spec.key) &&
+          directResourceTypeForKey(spec.key)
+      )
+      .map(spec => [spec.key, codes(spec.key)])
+      .filter(([, selectedCodes]) => selectedCodes.length > 0)
+  );
   const hasGenericResources = RESOURCE_SPECS.some(
-    spec => !codeResourceKeys.has(spec.key) && (manifest[spec.key] || []).length > 0
+    spec =>
+      !codeResourceKeys.has(spec.key) &&
+      !directResourceTypeForKey(spec.key) &&
+      (manifest[spec.key] || []).length > 0
   ) || (planActions || []).some(
     action =>
       action?.action === 'delete' &&
@@ -12919,6 +12953,7 @@ function buildResourceManifestSddTargets(manifest, planActions = []) {
     workflows: unique([...codes('workflows'), ...deletedCodes('workflow')]).sort(),
     jsCodeNodes: [],
     resources: hasGenericResources,
+    resourceSelectors,
     runtime: false,
     other: [],
   };
@@ -26887,5 +26922,6 @@ function buildWorkspacePublishEnv(
 }
 
 module.exports = {
+  buildResourceManifestSddTargets,
   main,
 };

package/lib/release-plan.js

@@ -21,6 +21,14 @@ function normalizeReleaseTargets(targets = {}, runtimeMode = 'legacy') {
       .map(([type, values]) => [type, uniqueSorted(values || [])])
       .filter(([, values]) => values.length > 0)
   );
+  const hasExactDirectResourceScope =
+    Object.entries(resourceSelectors).length > 0 &&
+    Object.entries(resourceSelectors).every(
+      ([type, selectors]) =>
+        directResourceTypeForKey(type) &&
+        type !== 'unknown' &&
+        (selectors || []).every(selector => selector !== '*')
+    );
   const logicalTargets = {
     forms: uniqueSorted(targets.forms || []),
     pages: uniqueSorted(targets.pages || []),
@@ -28,7 +36,11 @@ function normalizeReleaseTargets(targets = {}, runtimeMode = 'legacy') {
     automations: uniqueSorted(targets.automations || []),
     workflows: uniqueSorted(targets.workflows || []),
     jsCodeNodes: uniqueSorted(targets.jsCodeNodes || []),
-    resources: Boolean(targets.resources),
+    // Older SDD records used resources=true as a category marker even when
+    // they also carried an exact selector. Exact supported selectors are the
+    // authoritative boundary; only an unscoped/unknown/wildcard declaration
+    // remains a generic resource closure.
+    resources: Boolean(targets.resources) && !hasExactDirectResourceScope,
     resourceSelectors,
     resourceDeletes,
     runtime: Boolean(targets.runtime),
@@ -56,7 +68,9 @@ function unsupportedAtomicReleaseTargets(targets = {}) {
   )) {
     if (
       (selectors || []).length > 0 &&
-      (!DIRECT_RESOURCE_TYPE_BY_KEY[type] || type === 'unknown')
+      (!directResourceTypeForKey(type) ||
+        type === 'unknown' ||
+        selectors.includes('*'))
     ) {
       unsupported.push(`${type}:${selectors.join(',')}`);
     }
@@ -114,6 +128,10 @@ const DIRECT_RESOURCE_RELEASE_ORDER = Object.freeze([
   'notifications',
 ]);
 
+function directResourceTypeForKey(key) {
+  return DIRECT_RESOURCE_TYPE_BY_KEY[key] || null;
+}
+
 function assertAtomicReleaseTargetsSupported(targets) {
   const unsupported = unsupportedAtomicReleaseTargets(targets);
   if (unsupported.length === 0) return;
@@ -238,7 +256,7 @@ function buildDirectConfigurationReleaseSteps(
   return Object.entries(targets.resourceSelectors || {})
     .filter(
       ([type, selectors]) =>
-        DIRECT_RESOURCE_TYPE_BY_KEY[type] &&
+        directResourceTypeForKey(type) &&
         uniqueSorted(selectors || []).length > 0
     )
     .sort(
@@ -248,12 +266,12 @@ function buildDirectConfigurationReleaseSteps(
     )
     .map(([type, selectors]) =>
       createStep(
-        `config-${DIRECT_RESOURCE_TYPE_BY_KEY[type]}`,
+        `config-${directResourceTypeForKey(type)}`,
         appendProfileAndChange(
           [
             'resource',
             'publish',
-            DIRECT_RESOURCE_TYPE_BY_KEY[type],
+            directResourceTypeForKey(type),
             '--only',
             uniqueSorted(selectors).join(','),
           ],
@@ -476,6 +494,7 @@ module.exports = {
   buildWorkspaceReleaseCommands,
   buildWorkspaceReleaseSteps,
   commandFromArgs,
+  directResourceTypeForKey,
   normalizeReleaseTargets,
   releasePlanHash,
   unsupportedAtomicReleaseTargets,

package/openxiangda-skills/SKILL.md

@@ -106,12 +106,16 @@ openxiangda release ship --change <release-change> --profile <name> \
 
 For a workspace registered by `openxiangda environment init` or connected to an existing set with `openxiangda environment attach`, production is never a direct publish target. Use the two-phase `release ship` fast path by default. Its first invocation creates/deploys the immutable candidate to preproduction and always returns `awaiting_production_confirmation`; it cannot promote. A second invocation with `--confirm-production` promotes the exact same candidate hash. Real human acceptance is the recommended normal practice and can be recorded with optional `--acceptance-note`, but do not invent an acceptance note and do not treat it as a universal hard platform gate when the user explicitly authorizes a low-risk or emergency promotion. The lower-level candidate/deploy/test/promote commands are recovery primitives, not the normal agent loop. Preproduction and production keep independent app/resource/data identities in `.openxiangda/state.json`; do not copy IDs between targets. `environment attach` may seed only the matching legacy app binding into preproduction and must leave production empty. Only during authorized commissioning/reclassification may `environment swap --reason "..." --confirm-production` atomically exchange the two existing roles; it preserves each app's data and Release Heads, remaps local resource IDs by appType, and does not enable production side effects by default. To change only one environment's side-effect policy, run `environment policy update <kind|id> --side-effect-policy-json <JSON|file> --reason "..." --dry-run` first, then repeat without `--dry-run`; never use swap for this. Policy reads are forward-compatible: patch mode validates only caller-supplied fields and preserves unrecognized historical fields, while `--full-replace` validates the supplied complete target and intentionally removes omissions. The update is revision-CAS, production needs `--confirm-production`, and `organizationWrites=explicit_capability_only` still requires `app:organization:manage`. Keep release hard gates limited to explicit scope/profile/target, authorization, clean pushed mainline, immutable identity, CAS/lease, and production confirmation; prose and human acceptance notes are advisory unless strict mode was intentionally configured. Use `openxiangda studio` for the loopback-only developer view of bindings, drift, evidence, and safe next actions.
 
+For an audited catch-up whose exact non-delete targets are already merged but whose active resources combine multiple historical release lineages, the first ship invocation may add `--adopt-online-baseline --adoption-reason "..."`. Ship validates the pair before candidate/deployment creation and forwards it only to exact scoped resource stages; frozen online heads, change/lease ownership, delete/prune/force rejection, server CAS, staged-child verification, and the single atomic App finalize remain mandatory.
+
 `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.
 
 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 are logical coverage targets and activate through one Runtime child; they do not require PageRelease. `release app-head` and `runtime releases` are compact by default; use `--full` only when the complete manifest is required.
 
+Exact `resourceSelectors` are authoritative for supported configuration resources such as `publicAccessPolicies`. A legacy `resources=true` category marker is narrowed by those exact selectors and must not become an app-wide generic-resource release. Missing selectors, unknown resource types, wildcard `*`, deletes, and genuine app-wide resource closures remain fail closed.
+
 `release begin --change` freezes a clean committed `HEAD` only when the current branch is the authoritative default `main`/`master` and its commit exactly equals the live remote tip. Before any live write, the CLI preflights the complete target set and rejects source changes during the release. A feature worktree or unpushed main receives `RELEASE_SOURCE_MAINLINE_REQUIRED` / `RELEASE_SOURCE_MAINLINE_NOT_PUSHED`; merge, test, push, and start the one mainline release instead of forcing it. Optional `.git` remote suffix differences are aliases of the same repository; genuinely different remotes still fail closed.
 
 Because promotion begins from the already-pushed authoritative mainline, `release integration-status` should pass immediately after activation. Run it, then `release end`; no post-release branch merge is required.

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

@@ -107,10 +107,14 @@ openxiangda release ship --change <release-change> --profile <name> \
 
 Once `environment init` registers a logical application, or `environment attach` connects an existing workspace, `preproduction` and `production` are separate target bindings with separate app/resource/data IDs. Never copy IDs between them. Existing legacy resource mappings may seed only the target whose appType matches (normally preproduction); production stays empty. The normal path is the two-phase `release ship`. Its first invocation creates and deploys the immutable candidate only to preproduction and stops at `awaiting_production_confirmation`. A different, later invocation with `--confirm-production` promotes the exact same candidate and fresh deployment-bound evidence. Human acceptance is recommended and an optional `--acceptance-note` records it, but it is not a universal hard platform gate for explicitly authorized low-risk or emergency releases. Direct `release publish` to either managed target fails closed. Only authorized commissioning/reclassification may run `environment swap --reason "..." --confirm-production`; the atomic operation preserves each app's data and Release Heads, remaps local resources by appType, and keeps existing side-effect restrictions unless explicit replacement policies are supplied. A single environment policy change uses `environment policy update <kind|id>` with a GET-only `--dry-run` first; patch mode validates only caller-supplied fields and preserves unrecognized historical fields, while `--full-replace` validates the supplied complete target and intentionally removes omissions. It uses revision CAS and never swaps roles or Release Heads. Production writes require `--confirm-production`. `organizationWrites=explicit_capability_only` only removes the environment deny and never bypasses `app:organization:manage`. Keep release hard gates limited to explicit scope/profile/target, authorization, clean pushed mainline, immutable identity, CAS/lease, and production confirmation; prose and human acceptance notes are advisory unless strict mode was intentionally configured. `openxiangda studio` is the local loopback-only developer view and exposes only registered safe actions.
 
+When a reviewed catch-up contains exact non-delete targets that are already on authoritative mainline but the active application combines several historical release lineages, the first ship invocation may add `--adopt-online-baseline --adoption-reason "..."`. Ship validates the pair before candidate/deployment creation and forwards it only to exact scoped resource stages. It does not relax frozen online heads, change/lease ownership, delete/prune/force rejection, server CAS, staged-child verification, or the single atomic App finalize.
+
 `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.
 
+Exact `resourceSelectors` are authoritative for supported configuration resources such as `publicAccessPolicies`. A legacy `resources=true` category marker is narrowed by those exact selectors and must not become an app-wide generic-resource release. Missing selectors, unknown resource types, wildcard `*`, deletes, and genuine app-wide resource closures remain fail closed.
+
 `runtime deploy --no-activate` uploads an immutable preview release from a clean committed mainline `HEAD`. It reads a narrow Runtime head instead of the full app snapshot. Before acquiring a lease, the CLI confirms `package.json#scripts.build` and existing dependencies; it uses `npm run build` to execute the declared script so pnpm worktree symlinks do not trigger a reinstall. Immutable Git-base artifact hashes are cached under the Git common directory. `release begin` requires local main/master and the live remote default tip to be identical, so `integration-status` is already satisfied after activation and `release end` does not wait for a later merge.
 
 `release app-head` and `runtime releases` return compact summaries by default. Use `--full` only when the complete manifest is required.

package/package.json

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

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

@@ -55,6 +55,10 @@ openxiangda commands --json
 
 工作区一旦通过 `environment init` 登记，或通过 `environment attach` 接入已有环境组，`release publish` 即不再是入口。日常使用两段式 `release ship`：第一次冻结不可变 candidate 并只部署到 preproduction，停止在 `awaiting_production_confirmation`；确认预发结果后，第二次命令提供 `--confirm-production`，把同一 candidate 晋级 production，不会重新构建。真实人工验收是默认建议，可用可选的 `--acceptance-note` 留痕；但用户明确授权的低风险或紧急发布不受僵硬审批门禁阻塞。两套环境的 appType、资源 ID、数据和副作用策略完全独立；旧单目标资源映射只允许迁移到 appType 相同的预发 target，正式 target 必须为空。仅在用户明确授权的投产前重分类中使用 `environment swap --reason "..." --confirm-production` 原子交换两个既有应用的环境角色；数据和 Release Head 不移动，副作用默认不放开。单独调整某个环境的副作用策略时，先运行 `environment policy update <kind|id> ... --dry-run` 查看差异，再按 CAS revision 写入；patch 只校验本次提交字段并原样保留未知历史字段，`--full-replace` 才按完整目标删除遗漏字段。不得借用 swap，正式写入另需 `--confirm-production`。`organizationWrites=explicit_capability_only` 仍强制 `app:organization:manage`。发布硬门禁只保留明确 scope/profile/target、权限、干净且已推送主线、不可变版本、CAS/租约与生产确认；文案和人工验收说明默认是建议，只有显式 strict 模式才阻断。`openxiangda studio` 提供仅本机访问的开发者页面，用于查看绑定、漂移、候选、部署、证据和下一安全动作。
 
+只有已审计代码早已进入权威主线、而精确非删除目标在线上来自多次历史发布且无法对应单一 Git 基线时，第一次 `release ship` 才可增加 `--adopt-online-baseline --adoption-reason "..."`。该参数不会放松冻结 online heads、change/lease、删除/全量拒绝、服务端 CAS、staged children 或单次 App finalize 原子激活。
+
+受支持的配置资源（如 `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。
 
 完整发布顺序：

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

@@ -58,6 +58,8 @@
 - ✅ Function/Automation 使用 Backend Release v2；正式多资源发布用精确 `--only/--code` 加 `--stage-only` 暂存，同一 child 可混合 create、source-only update 和显式 manifest replacement，再由 Root App finalize 原子激活。整包 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 仍是硬门禁。
+- ✅ 受支持的配置资源（如 `publicAccessPolicies`）以精确 `resourceSelectors` 为边界；历史 `resources=true` 类别标记会被精确 selector 收窄。缺失 selector、未知类型、通配符 `*`、删除和真正全量资源仍 fail closed。
 - ✅ 本地开发者可运行 `openxiangda studio` 查看两套环境、差异、候选、部署和测试证据；该页面只监听回环地址且只暴露注册动作，生产操作仍需显式确认。
 
 ## 严禁