openxiangda 1.0.176 → 1.0.178

package/lib/task-status.js

@@ -1,5 +1,6 @@
 function buildTaskStatus(input = {}) {
   const execution = object(input.execution);
+  const directPublish = object(input.directPublish);
   const steps = Array.isArray(execution?.steps) ? execution.steps : [];
   const completed = steps.filter(step => step.status === 'completed');
   const failed = steps.find(step => step.status === 'failed') || null;
@@ -7,12 +8,28 @@ function buildTaskStatus(input = {}) {
     steps.find(step => ['running', 'write-started'].includes(step.status)) ||
     null;
   const pending = steps.filter(step => step.status === 'pending');
-  const releaseState = execution?.status || 'not-started';
+  const releaseState =
+    execution?.status ||
+    (directPublish?.status === 'completed'
+      ? 'direct-publish-completed'
+      : 'not-started');
   const postCommit = object(input.postCommit);
   const remoteLease = object(input.remoteLease);
   const taskResult = object(input.taskResult);
   const integration = object(input.integration);
   const change = object(input.change);
+  const sourceRevision =
+    object(input.sourceRevision) ||
+    object(directPublish?.sourceRevision) ||
+    object(execution?.releaseSourceRevision) ||
+    object(execution?.releaseContext?.releaseSourceRevision);
+  const changeId =
+    input.changeId || change?.id || execution?.changeId || null;
+  const leaseBlocked = isRemoteLeaseBlocking({
+    remoteLease,
+    execution,
+    changeId,
+  });
   const phase = inferPhase({
     releaseState,
     steps,
@@ -29,14 +46,19 @@ function buildTaskStatus(input = {}) {
     remoteLease,
     integration,
     postCommit,
+    leaseBlocked,
   });
   const startedAt =
     execution?.createdAt ||
+    directPublish?.completedAt ||
     change?.createdAt ||
     taskResult?.recordedAt ||
     null;
   const endedAt =
     execution?.completedAt ||
+    (releaseState === 'direct-publish-completed'
+      ? directPublish?.completedAt
+      : null) ||
     (phase === 'integration-ready' ? taskResult?.recordedAt : null);
   const now = Number.isFinite(Number(input.now))
     ? Number(input.now)
@@ -49,17 +71,18 @@ function buildTaskStatus(input = {}) {
     running,
   );
   const wrotePlatform = Boolean(
-    execution?.writeAttempted ||
+    directPublish?.writeAttempted ||
+      execution?.writeAttempted ||
       execution?.stagedWriteOccurred ||
       completed.some(step => step.id !== 'lease-and-capture'),
   );
   const healthy =
-    releaseState === 'completed' &&
+    ['completed', 'direct-publish-completed'].includes(releaseState) &&
     (!postCommit || postCommit.status === 'completed');
 
   return {
     schemaVersion: 'openxiangda_task_status_v1',
-    changeId: input.changeId || change?.id || execution?.changeId || null,
+    changeId,
     phase,
     healthy,
     wrotePlatform,
@@ -73,8 +96,8 @@ function buildTaskStatus(input = {}) {
     },
     source: {
       changeStatus: change?.status || null,
-      taskCommit: taskResult?.commit || null,
-      taskReady: Boolean(taskResult),
+      taskCommit: taskResult?.commit || sourceRevision?.baseCommit || null,
+      taskReady: Boolean(taskResult || sourceRevision),
       integrated: inferIntegrated(integration),
     },
     release: {
@@ -86,6 +109,10 @@ function buildTaskStatus(input = {}) {
         remoteLease?.holder?.changeId ||
         remoteLease?.holder?.clientSessionId ||
         remoteLease?.changeId ||
+        remoteLease?.clientSessionId ||
+        (typeof remoteLease?.holder === 'string'
+          ? remoteLease.holder
+          : null) ||
         null,
     },
     blocker: blockingLayer
@@ -100,7 +127,7 @@ function buildTaskStatus(input = {}) {
           message:
             failed?.error?.message ||
             failed?.error ||
-            blockerMessage(blockingLayer),
+            blockerMessage(blockingLayer, remoteLease),
         }
       : null,
     nextAction: nextAction({
@@ -111,6 +138,7 @@ function buildTaskStatus(input = {}) {
       postCommit,
       taskResult,
       integration,
+      leaseBlocked,
     }),
   };
 }
@@ -124,6 +152,7 @@ function inferPhase(input) {
     return 'health';
   }
   if (input.releaseState === 'completed') return 'healthy';
+  if (input.releaseState === 'direct-publish-completed') return 'healthy';
   if (input.releaseState === 'write-review-required') return 'write-review';
   if (input.failed) return 'failed';
   if (input.running) return phaseFromStep(input.running.id);
@@ -163,13 +192,7 @@ function inferBlockingLayer(input) {
   if (input.postCommit?.status && input.postCommit.status !== 'completed') {
     return 'post-commit';
   }
-  if (
-    input.remoteLease?.active &&
-    input.releaseState !== 'running' &&
-    input.releaseState !== 'staged-resumable'
-  ) {
-    return 'lease';
-  }
+  if (input.leaseBlocked) return 'lease';
   if (input.integration && inferIntegrated(input.integration) === false) {
     return 'git-mainline';
   }
@@ -231,13 +254,26 @@ function nextAction(input) {
   if (input.failed) {
     return `修复 ${input.failed.id || '失败步骤'} 后重跑同一条 release publish。`;
   }
-  if (input.remoteLease?.active && input.releaseState === 'not-started') {
-    return '等待当前应用发布租约释放；开发与测试可继续并行。';
+  if (input.leaseBlocked) {
+    const holder =
+      input.remoteLease?.changeId ||
+      input.remoteLease?.clientSessionId ||
+      input.remoteLease?.holder?.changeId ||
+      input.remoteLease?.holder?.clientSessionId ||
+      input.remoteLease?.holder ||
+      '另一发布任务';
+    const expiry = input.remoteLease?.expiresAt
+      ? `，最晚 ${input.remoteLease.expiresAt} 到期`
+      : '';
+    return `等待 ${holder} 释放当前应用租约${expiry}；本任务尚未写平台，可继续本地开发与测试。`;
   }
   if (input.releaseState === 'staged-resumable') {
     return '重跑同一条 release publish，从已验证的 staged child 继续。';
   }
   if (input.releaseState === 'completed') return '执行业务验收并归档 change。';
+  if (input.releaseState === 'direct-publish-completed') {
+    return '直接发布已完成；执行业务验收并归档 change。';
+  }
   if (input.taskResult && inferIntegrated(input.integration) === false) {
     return '把 task commit 合并并推送到权威主分支，再创建 mainline bundle。';
   }
@@ -245,9 +281,11 @@ function nextAction(input) {
   return '完成实现和聚焦测试，提交后运行 sdd ready。';
 }
 
-function blockerMessage(layer) {
+function blockerMessage(layer, remoteLease) {
   const messages = {
-    lease: '另一个发布任务持有应用租约。',
+    lease: remoteLease?.changeId
+      ? `发布任务 ${remoteLease.changeId} 持有应用租约。`
+      : '另一个发布任务持有应用租约。',
     'git-mainline': '任务提交尚未完整进入权威主分支。',
     'post-commit': '发布已激活，提交后动作仍在自动重试。',
     'write-result': '上次写请求结果不确定，需要只读核对。',
@@ -255,6 +293,31 @@ function blockerMessage(layer) {
   return messages[layer] || '当前阶段需要处理失败后才能继续。';
 }
 
+function isRemoteLeaseBlocking(input = {}) {
+  const remote = object(input.remoteLease);
+  if (!remote?.active) return false;
+  const execution = object(input.execution);
+  const context = object(execution?.releaseContext);
+  if (
+    remote.leaseId &&
+    context?.leaseId &&
+    String(remote.leaseId) === String(context.leaseId)
+  ) {
+    return false;
+  }
+  if (
+    remote.clientSessionId &&
+    context?.clientSessionId &&
+    String(remote.clientSessionId) === String(context.clientSessionId) &&
+    (!remote.changeId ||
+      !input.changeId ||
+      String(remote.changeId) === String(input.changeId))
+  ) {
+    return false;
+  }
+  return true;
+}
+
 function object(value) {
   return value && typeof value === 'object' && !Array.isArray(value)
     ? value

package/openxiangda-skills/SKILL.md

@@ -10,6 +10,13 @@ OpenXiangda connects an AI coding workspace to the private low-code platform thr
 
 This file is a router and safety card. Read only the one or two subskills selected below; do not load every OpenXiangda reference into the same turn.
 
+## Keep the agent loop small
+
+- Start with one broad CodeGraph exploration that names the complete flow or feature. Use at most one focused follow-up when the first result explicitly omits a required symbol; do not repeat overlapping surveys.
+- Ordinary work uses this router plus one domain subskill. Add a second domain subskill only when the accepted scope genuinely crosses domains; three or more OpenXiangda subskills require stopping and narrowing the task.
+- When the user already supplied concrete requirements and acceptance criteria, record the structured SDD scope and implement. Do not turn a resolved request into a long design essay or ask for a duplicate confirmation.
+- During an unchanged lease/build wait, report the first blocker and then only material state changes. Prefer `openxiangda task status --watch` over repeated narrative updates.
+
 ## Decide the track
 
 | Intent | Read next | First action |
@@ -27,7 +34,7 @@ This file is a router and safety card. Read only the one or two subskills select
 ## Scope before work
 
 1. Work from the app workspace root and pass `--profile <name>` to every write or release command.
-2. In a shared or dirty checkout, use an isolated Git worktree/branch for development. Merge approved task commits into the authoritative remote default branch before any live release. Formal publish runs once from a clean local `main`/`master` that exactly equals the remote tip; feature worktrees never publish.
+2. In a shared app repository, reserve the canonical `main`/`master` checkout for integration and release. Every development task uses an isolated Git worktree/branch from the latest remote mainline; never stash, restore, or overwrite another task's changes to make the canonical checkout publishable. Merge approved task commits into the authoritative remote default branch before any live release. Formal publish runs once from a clean local `main`/`master` that exactly equals the remote tip; feature worktrees never publish.
 3. Give the task one stable SDD change id. Use `--change <id>` on context, plan, check, verify, publish, and archive commands when supported.
 4. Plan and publish exact resource codes with `--only <codes>` or `--code <code>`; a type-only or full-resource publish is allowed only when the dependency closure intentionally contains the whole type/application.
 5. A React SPA page change rebuilds one application runtime. Commit the complete build input first, upload/preview with `runtime deploy --no-activate`, and promote only from a clean merged release head that descends from the online Runtime source revision.

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

@@ -24,7 +24,9 @@ openxiangda sdd context --change <change> --changed --json
 
 Run `openxiangda update check --json` once per substantial task, on a suspected mismatch, or when the cached check is older than one day. If an update is installed, refresh skills once with `openxiangda skill install --force`.
 
-Every write/release command must include `--profile <name>`. Parallel tasks develop in isolated Git worktrees/branches, but do not publish there. Merge approved commits into the authoritative remote default branch, create one `sdd bundle` for the intended changes, commit/push it, and publish once from a clean local `main`/`master` that exactly equals the remote tip.
+Every write/release command must include `--profile <name>`. In a shared app repository the canonical main checkout is integration/release-only; parallel tasks develop in isolated Git worktrees/branches and never stash or restore another task's files. Merge approved commits into the authoritative remote default branch, create one `sdd bundle` for the intended changes, commit/push it, and publish once from a clean local `main`/`master` that exactly equals the remote tip.
+
+Keep investigation proportional: one complete CodeGraph survey plus at most one focused follow-up, normally one domain subskill, and no optional prose for a request whose requirements and acceptance criteria are already explicit. Unchanged lease waits should use `task status --watch` and emit only material transitions.
 
 SDD is structured-first by default: only `change.json`, `coverage.json`, and `release.json` are created. Generate optional prose with `openxiangda sdd render <change>`; missing checklist/evidence/spec prose is a warning, while approval, exact structured scope, actual argv, mainline identity, child CAS, lease, and atomic activation remain hard gates. Set `strictDocumentation: true` only when prose completion must intentionally block a workspace.
 
@@ -57,6 +59,8 @@ openxiangda resource publish function --only function_a,function_b --profile <na
 
 Selectors apply before manifest parsing, source dependency analysis, and JS_CODE typecheck/build. A scoped Function/Automation plan must touch only the selected targets plus their transitive/shared/ambient dependencies; an unscoped plan intentionally retains full-workspace behavior. Resource commands use the canonical scoped builder packaged with the installed CLI for standard workspaces, so old checked-in builders still receive the optimization; refresh/bootstrap the workspace script only for equivalent manual `pnpm build-js-code` behavior. Nonstandard custom builders remain an explicit compatibility fallback.
 
+Function/Automation source analysis also extracts statically declared Form filter and order fields. `resource plan` compares them with each bound Form's frozen online schema and reports `formFieldContracts`; publish fails before lease/write when a binding or field is missing. Fix the source or stage the Form schema in the same reviewed release instead of waiting for a production SQL-column error. Dynamic field names remain runtime-validated by the platform and return `FORM_FIELD_NOT_FOUND` as a configuration error.
+
 Source-triggered Function/Automation targets use Backend Release v2 when the platform exposes that capability. One child may mix create, source-only update, and manifest replacement update through explicit per-resource `operation/mode`; the CLI freezes the current Backend Release parent plus Git/change baseline, then runs `prepare -> verify -> activate` or stops verified for `--stage-only`. Activation CAS-checks the entire set and applies all updates in one transaction. `--stage-only` and Secret-bound Function publishing fail closed when Backend Release v2 is unavailable; compatibility fallback is limited to non-staged, non-Secret publishing after an explicit Backend head 404. Existing online bindings, contracts, metadata, trigger/view configuration, and enabled/published state remain unchanged; noops do not advance versions/timestamps. A deliberate whole-definition replacement requires exact `--only/--code` and `--replace-manifest --reason "<why>"`; SDD bypass does not imply replacement authority.
 
 Functions with a top-level `secretRefs` field use `backend_release_v2`, including an explicit empty list that removes bindings. This path never falls back to source PATCH. It requires the per-app Secret capability probe to grant `app_function_secrets_v1`, `trusted_node_v2`, `backend_release_v2`, and `atomic_staged_children_v2`; otherwise plan/publish fails closed.

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

@@ -84,7 +84,7 @@ For a single form edit, still keep the child staged until Root App finalize:
 openxiangda resource publish form-setting --only <formCode> --change <change> --profile <name>
 ```
 
-The Form resource bundle carries schema, settings, indexes, data-management, runtime-write, and public-access configuration under one CAS parent. It returns a canonical staged FormRelease and the CLI records it in the change-scoped staged-resources file. `workspace publish --form` is limited to an intentional first-time bootstrap or isolated repair outside a governed multi-resource release; it is not the normal release path.
+The Form resource bundle carries schema, settings, indexes, data-management, runtime-write, public-access configuration, and changed form permission groups under one CAS parent. It returns a canonical staged FormRelease and the CLI records it in the change-scoped staged-resources file. `workspace publish --form` is limited to an intentional first-time bootstrap or isolated repair outside a governed multi-resource release; it is not the normal release path.
 
 For Phase 6 React SPA workspaces, `app-workspace.config.ts` should declare
 `runtimeMode: "react-spa"`. In that mode, `workspace publish --form <code>` is
@@ -110,7 +110,7 @@ Do not use `openxiangda form create` as the normal way to generate a user-facing
 ## Form Release / CAS Safety
 
 - Treat all Form configuration as one immutable release stream. Freeze `revision`, `etag`, and `activeFormReleaseHead` from one snapshot before writing.
-- Publish declared schema, packages, settings, indexes, data-management, runtime-write, and public-access configuration through one `resource publish form-setting --only <codes> --change <change>` Form `bundle` mutation. Resource Form bundles are stage-only by default and return immutable `contentHash` plus a canonical `stagedResource` (stable identity is `formUuid`); the CLI merges each entry into `.openxiangda/releases/<change>/staged-resources.json`. Root `app-finalize` atomically switches all child heads plus the App head. Use direct `--activate` only for an intentional form-only repair outside a governed multi-resource release; never use `workspace publish --form` inside an atomic React SPA release.
+- Publish declared schema, packages, settings, indexes, data-management, runtime-write, public-access configuration, and `formPermissionGroups` through one Form `bundle` mutation. `resource publish form-setting,form-permission-group --only <codes> --change <change>` groups changes by `formUuid`, stages one immutable FormRelease per form, and never falls back to direct live permission-group writes. Resource Form bundles return immutable `contentHash` plus a canonical `stagedResource` (stable identity is `formUuid`); the CLI merges each entry into `.openxiangda/releases/<change>/staged-resources.json`. Root `app-finalize` atomically switches all child heads plus the App head. Use direct `--activate` only for an intentional form-only repair outside a governed multi-resource release; never use `workspace publish --form` inside an atomic React SPA release.
 - Every mutation must carry `If-Match`, `expectedRevision`, `expectedParent`, and a stable artifact ID. Creation starts at revision `0`.
 - A revision/head conflict is not retryable. Stop with zero later writes, re-plan, and explicitly merge the competing change; never silently adopt the newer live head.
 - Use `openxiangda form release-head|release-list|release-detail|release-diff` for inspection and `release-activate|release-rollback|release-abort` for controlled recovery. See `docs/openxiangda-form-releases.md` in the OpenXiangda tool repository.

package/openxiangda-skills/skills/openxiangda-permission-settings/SKILL.md

@@ -159,6 +159,14 @@ openxiangda permission form-group-create sales_limited \
 for real backend read/write field access (`edit`, `readonly`, `hidden`) with
 `defaultAccess` plus field-ID exceptions.
 
+For governed application publishing, declare groups under
+`src/resources/formPermissionGroups` and publish them through exact
+`resource publish ... --only ... --change ...` scope. The CLI folds changed
+groups into the owning Form's immutable FormRelease, freezes a permission-group
+parent hash, and keeps live rows unchanged until Root App finalize. The
+low-level `permission form-group-create/update/delete` commands are for
+intentional maintenance and diagnostics, not an atomic multi-resource release.
+
 ## Inspection
 
 ```bash

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "openxiangda",
-  "version": "1.0.176",
+  "version": "1.0.178",
   "description": "OpenXiangda CLI, workspace build tools, runtime SDK, and form components.",
   "private": false,
   "bin": {
@@ -100,6 +100,7 @@
     "test:publish-lease-heartbeat": "node scripts/publish-lease-heartbeat-smoke.mjs",
     "test:release-telemetry": "node scripts/release-telemetry-smoke.mjs",
     "test:release-explain": "node scripts/release-explain-smoke.mjs",
+    "test:release-error-classification": "node scripts/release-error-classification-smoke.mjs",
     "test:task-status": "node scripts/task-status-smoke.mjs",
     "test:policy": "node scripts/policy-smoke.mjs",
     "test:release-plan": "node scripts/release-plan-smoke.mjs",
@@ -111,6 +112,7 @@
     "test:app-release-cli": "node scripts/app-release-cli-smoke.mjs",
     "test:form-release-cas": "node scripts/form-release-cas-smoke.mjs",
     "test:source-dependencies": "node scripts/source-dependencies-smoke.mjs",
+    "test:form-field-contract": "node scripts/form-field-contract-smoke.mjs",
     "test:package-runtime-dependencies": "node scripts/package-runtime-dependencies-smoke.mjs",
     "test:packed-cli": "node scripts/packed-cli-smoke.mjs",
     "test:runtime-deploy": "node scripts/runtime-deploy-smoke.mjs",

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

@@ -5,10 +5,11 @@
 
 ## 开发原则
 
-- 架构类需求默认只规划、不实现。新应用、复杂页面、登录注册、公开访问、权限数据范围、流程自动化、连接器/通知等需求，先运行 `openxiangda doctor --json` 和 `openxiangda design gates --topic <code> --json`，输出设计并等用户确认；确认前只允许读取、快照、dry-run、提问和写设计文档，不允许改源码、写平台、发布或发送通知。
+- 架构类需求先运行 `openxiangda doctor --json` 和 `openxiangda design gates --topic <code> --json`。只有仍存在会改变实现方向的业务、安全或数据选择时才输出设计并等待确认；用户已经给出具体需求与验收标准时，直接记录结构化 SDD 范围并实现，不再写长篇设计或重复确认。
 - 先按风险分级：只读/文档/测试为 L0；纯文案样式或单一既有资源绑定等可逆窄改为 L1，可用受限的 `openxiangda sdd quick` 记录精确范围；表单结构、业务函数、自动化/流程、权限、登录/公开访问、数据写入和 runtime/config 为 L2；不可逆、生产迁移或应用级扩权为 L3。L2/L3 必须挂完整 SDD，并由 `coverage.json` 把需求与场景映射到精确的文件、表单、页面及工程资源范围。
 - 一个开发任务只使用一个显式 change，并从 `openxiangda sdd context --change <change> --changed --json` 开始；默认只维护 change/coverage/release 三份结构化事实源，需要文档时才执行 `openxiangda sdd render <change>`。结构化 approval、资源和文件范围是硬约束，任务/证据/规格文案默认只告警。只有明确配置 `strictDocumentation: true` 才把文案完成度恢复为门禁。
-- 多会话开发使用独立 Git worktree/branch，但 feature worktree 不发布。把已批准提交合并并 push 到权威默认主分支后，用 `sdd bundle <release-change> --changes ...` 聚合范围；只从与远端 tip 完全一致的 clean `main`/`master` 一次发布。
+- 多会话开发把规范的 `main`/`master` 检出专用于集成和发布；每个开发任务从最新远端主线使用独立 Git worktree/branch，禁止为了发布 stash/restore 或覆盖其他任务的文件。feature worktree 不发布。把已批准提交合并并 push 到权威默认主分支后，用 `sdd bundle <release-change> --changes ...` 聚合范围；只从与远端 tip 完全一致的 clean `main`/`master` 一次发布。
+- 调查预算默认为一次覆盖完整调用链的 CodeGraph 查询，只有明确缺失符号时再补一次精确查询；普通任务只加载一个领域技能。租约、构建或部署状态未变化时不重复输出相同进度，使用 `openxiangda task status --watch` 等待状态变化。
 - 账号、角色、权限、数据范围、组织账号、RBAC、查询参数授权需求必须先运行 `openxiangda design gates --topic permissions --json`，选择 `managed-platform-account` / `existing-platform-user-assignment` / `static-role-permission` / `query-param-context`，输出权限矩阵后再实现。
 - 应用角色只读查询组织账号时声明 `app:organization:read`；创建、修改账号/部门或重置密码时声明 `app:organization:manage`。创建角色、分配成员或维护权限组也必须在角色资源的 `apiPermissionCodes` 声明对应的 `app:role:manage`、`app:page-permission-group:manage`、`app:form-permission-group:manage`。
 - 默认用户界面保持克制：左侧应用导航、顶部账号信息、首页内容区域。

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

@@ -8,7 +8,9 @@
 
 **所有"发布 / 上线 / 部署 / publish / deploy / ship / release"请求，唯一正确入口是 `openxiangda workspace publish --profile <name>`，不要直接 `pnpm publish:all`。**
 
-**架构类需求默认只规划、不实现。** 新应用、复杂页面、登录注册、公开访问、权限数据范围、流程自动化、连接器/通知等需求，先 `openxiangda doctor --json` + `openxiangda design gates --topic <code> --json`，输出设计并等待用户确认；确认前只允许读取、快照、dry-run、提问和写设计文档，不允许改源码、写平台、发布、部署或发送通知。
+**架构类需求先过设计门。** 新应用、复杂页面、登录注册、公开访问、权限数据范围、流程自动化、连接器/通知等需求，先 `openxiangda doctor --json` + `openxiangda design gates --topic <code> --json`。只有仍存在会改变实现方向的业务、安全或数据选择时才输出设计并等待确认；用户已经给出具体需求与验收标准时，直接记录结构化 SDD 范围并实现，不再写长篇设计或重复确认。
+
+共享应用仓库把规范 `main`/`master` 检出专用于集成和发布；每个开发任务从最新远端主线使用独立 Git worktree/branch，禁止为了发布 stash/restore 或覆盖其他任务文件。调查默认只做一次完整 CodeGraph 查询，明确缺失时最多补一次精确查询；普通任务只加载一个领域技能。等待状态未变化时使用 `openxiangda task status --watch`，不要重复输出相同进度。
 
 **按风险分级治理。** 只读/文档/测试为 L0；纯文案样式或单一既有资源绑定等窄小可逆改动为 L1，可用受限的 `openxiangda sdd quick` 记录精确范围；表单结构、业务 Function、Automation/Workflow、权限、登录/公开访问、数据写入和 runtime/config 为 L2；不可逆、生产迁移或应用级扩权为 L3。L2/L3 必须挂完整 SDD，并由 `coverage.json` 把需求与场景映射到精确的文件、表单、页面及工程资源范围。