openxiangda 1.0.196 → 1.0.198

package/README.md

@@ -56,11 +56,12 @@ openxiangda environment status --json
 # 仅限投产前环境角色重分类：原子交换两个既有应用的角色，应用数据和 Release Head 不移动
 openxiangda environment swap --reason "投产前将现有业务应用调整为正式应用" --confirm-production --profile dev
 openxiangda studio
-# 环境托管应用日常发布：冻结候选 → 预发 → 测试证据 → 同候选晋级正式
-openxiangda release candidate --change mainline-release --environment preproduction
-openxiangda release deploy --candidate <candidate-id> --environment preproduction
-openxiangda release test --deployment <deployment-id> --environment preproduction --evidence-json ./test-evidence.json
-openxiangda release promote --candidate <candidate-id> --environment production --confirm-production
+# 环境托管应用日常发布：首次命令只部署预发并停止
+openxiangda release ship --change mainline-release --profile dev
+
+# 确认预发结果后，再以同一 candidate 晋级正式；验收备注可选
+openxiangda release ship --change mainline-release --profile dev \
+  --confirm-production
 openxiangda policy check
 openxiangda resource explain public-access --json
 openxiangda inspect app --profile dev --json
@@ -69,7 +70,9 @@ 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 candidate` seals the clean authoritative Git revision, exact changed files, resource targets, SDD change, and test plan into an immutable candidate. `release deploy` can only deploy it to preproduction. `release test` attaches deployment-bound, hash-verified evidence. `release promote` can only promote that exact candidate to production after the platform verifies fresh passing preproduction evidence and zero candidate drift. 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. 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.
 
 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

@@ -359,6 +359,8 @@ function buildCandidateBundle(input) {
     targets: input.targets,
     files,
     testPlanHash: sha256Canonical(testPlan),
+    prepublishVerificationHash:
+      input.prepublishVerificationHash || null,
     openxiangdaVersion: input.openxiangdaVersion,
   };
   return {