openyida 2026.9.14 → 2026.9.15

package/lib/app/create-form/batch.js

@@ -225,6 +225,25 @@ function readbackMismatch(formUuid, form, schema) {
   });
 }
 
+function buildPartialFailureRecovery(results) {
+  const items = Object.values(results || {});
+  const hasUnknownWrite = items.some(item =>
+    item && (item.status === 'running' || (item.status === 'failed' && !item.formUuid))
+  );
+  const recoveryAction = hasUnknownWrite
+    ? 'inspect_unknown_write_then_reconcile'
+    : 'rerun_unchanged_plan';
+  return { recoveryAction, nextAction: recoveryAction };
+}
+
+function buildDeliveryUrls(baseUrl, appType, formUuid) {
+  const normalizedBaseUrl = String(baseUrl || '').replace(/\/+$/, '');
+  if (!normalizedBaseUrl || !appType || !formUuid) { return {}; }
+  const appUrl = `${normalizedBaseUrl}/${appType}/workbench`;
+  const formUrl = `${appUrl}/${formUuid}`;
+  return { url: formUrl, formUrl, appUrl };
+}
+
 function execute(args, { execFile: execFileImpl = execFile } = {}) {
   return new Promise((resolve, reject) => {
     execFileImpl(process.execPath, [path.resolve(__dirname, '../../../bin/yida.js'), ...args, '--quiet'], {
@@ -317,13 +336,15 @@ async function run(args, dependencies = {}) {
   try {
     const state = fs.existsSync(stateFile) ? JSON.parse(fs.readFileSync(stateFile, 'utf8')) : { fingerprint, appType: options.appType, results: {} };
     if (state.fingerprint !== fingerprint) { invalid('state belongs to a different plan; reconcile existing resources before preparing a new batch'); }
-    await call(['login', '--check-only', '--json']);
+    const loginStatus = await call(['login', '--check-only', '--json']);
+    const baseUrl = loginStatus?.base_url || loginStatus?.baseUrl || '';
     // Read back completed resources before their IDs can be used by dependent forms.
     for (const form of forms.filter(item => state.results[item.key]?.status === 'success')) {
       const item = state.results[form.key];
       const schema = await call(['get-schema', options.appType, item.formUuid, '--field-map-json']);
       if (schema.formUuid !== item.formUuid || !Array.isArray(schema.fields)) { invalid(`schema: ${form.key}`); }
       item.fields = schema.fields;
+      Object.assign(item, buildDeliveryUrls(baseUrl, options.appType, item.formUuid));
     }
     const resolve = (key, field) => {
       const item = state.results[key];
@@ -336,6 +357,7 @@ async function run(args, dependencies = {}) {
     await schedule(forms, options.concurrency, state.results, async form => {
       let formUuid = form.formUuid || state.results[form.key]?.formUuid;
       let shouldResume = Boolean(!form.formUuid && formUuid);
+      let delivery = buildDeliveryUrls(baseUrl, options.appType, formUuid);
       const resolvedFields = mapReferences(form.fields, resolve);
       if (!formUuid) {
         const argv = ['create-form', 'create', options.appType, form.title, JSON.stringify(resolvedFields), '--no-open'];
@@ -344,6 +366,12 @@ async function run(args, dependencies = {}) {
           const created = await call(argv);
           if (typeof created.formUuid !== 'string' || !created.formUuid.startsWith('FORM')) { invalid(`create result: ${form.key}`); }
           formUuid = created.formUuid;
+          delivery = {
+            ...buildDeliveryUrls(baseUrl, options.appType, formUuid),
+            ...(created.url ? { url: created.url } : {}),
+            ...(created.formUrl ? { formUrl: created.formUrl } : {}),
+            ...(created.appUrl ? { appUrl: created.appUrl } : {}),
+          };
         } catch (error) {
           const createdFormUuid = error.output?.formUuid || error.output?.details?.formUuid;
           if (typeof createdFormUuid !== 'string' || !createdFormUuid.startsWith('FORM')) {
@@ -357,25 +385,43 @@ async function run(args, dependencies = {}) {
       save(state);
       let resumed = false;
       if (shouldResume) {
-        await call(['create-form', 'resume', options.appType, formUuid, JSON.stringify(resolvedFields), '--json']);
+        const resumeOutput = await call(['create-form', 'resume', options.appType, formUuid, JSON.stringify(resolvedFields), '--json']);
+        delivery = {
+          ...buildDeliveryUrls(baseUrl, options.appType, formUuid),
+          ...(resumeOutput.url ? { url: resumeOutput.url } : {}),
+          ...(resumeOutput.formUrl ? { formUrl: resumeOutput.formUrl } : {}),
+          ...(resumeOutput.appUrl ? { appUrl: resumeOutput.appUrl } : {}),
+        };
         resumed = true;
       }
       let schema = await call(['get-schema', options.appType, formUuid, '--field-map-json']);
       if (!readbackMatchesExpectedFields(schema, resolvedFields) && !resumed && !form.formUuid) {
-        await call(['create-form', 'resume', options.appType, formUuid, JSON.stringify(resolvedFields), '--json']);
+        const resumeOutput = await call(['create-form', 'resume', options.appType, formUuid, JSON.stringify(resolvedFields), '--json']);
+        delivery = {
+          ...buildDeliveryUrls(baseUrl, options.appType, formUuid),
+          ...(resumeOutput.url ? { url: resumeOutput.url } : {}),
+          ...(resumeOutput.formUrl ? { formUrl: resumeOutput.formUrl } : {}),
+          ...(resumeOutput.appUrl ? { appUrl: resumeOutput.appUrl } : {}),
+        };
         resumed = true;
         schema = await call(['get-schema', options.appType, formUuid, '--field-map-json']);
       }
       if (schema.formUuid !== formUuid || !readbackMatchesExpectedFields(schema, resolvedFields)) {
         throw readbackMismatch(formUuid, { ...form, fields: resolvedFields }, schema);
       }
-      return { formUuid, fields: schema.fields };
+      return { formUuid, fields: schema.fields, ...delivery };
     }, () => save(state));
     const success = Object.values(state.results).every(item => item.status === 'success');
-    const output = { success, groups, stateFile, results: state.results };
+    const output = {
+      success,
+      groups,
+      stateFile,
+      results: state.results,
+      ...((baseUrl && options.appType) ? { appUrl: `${String(baseUrl).replace(/\/+$/, '')}/${options.appType}/workbench` } : {}),
+    };
     if (!success) {
       output.errorCode = 'FORM_BATCH_PARTIAL_FAILURE';
-      output.nextAction = 'Inspect the saved state and child error, then fix the batch input or recover known formUuid values. Do not fall back to create-form create.';
+      Object.assign(output, buildPartialFailureRecovery(state.results));
     }
     console.log(JSON.stringify(output));
     if (!output.success) { process.exitCode = 1; }
@@ -397,5 +443,7 @@ module.exports = {
   execute,
   expectedReadbackFields,
   readbackMatchesExpectedFields,
+  buildPartialFailureRecovery,
+  buildDeliveryUrls,
   validateStaticDefinition,
 };

package/lib/app/create-form.js

@@ -4858,7 +4858,10 @@ async function saveFormSchema(authRef, appType, formUuid, schema, version, stepO
       formUuid,
       result: sanitizeFailureResult(saveResult),
     });
-    if (failureContext) {
+    if (failureContext && failureContext.deferFailureOutput) {
+      // Resume may safely resolve an HTTP 5xx by exact readback. Defer the
+      // failure payload so a recovered command emits one authoritative result.
+    } else if (failureContext) {
       emitCreateFormPostCreateFailure(Object.assign({}, failureContext, {
         stage: 'saveFormSchema',
         error: saveError,
@@ -4879,6 +4882,13 @@ async function saveFormSchema(authRef, appType, formUuid, schema, version, stepO
 
 // ── create 模式主流程 ─────────────────────────────────
 
+function buildFormDeliveryUrls(baseUrl, appType, formUuid) {
+  return {
+    appUrl: baseUrl + '/' + appType + '/workbench',
+    formUrl: baseUrl + '/' + appType + '/workbench/' + formUuid,
+  };
+}
+
 async function mainValidateFields(parsedArgs) {
   const { fieldsJsonOrFile } = parsedArgs;
   assertNoEmojiInDefinitionFileName(fieldsJsonOrFile);
@@ -5034,13 +5044,13 @@ async function mainCreate(parsedArgs, authRef) {
   }
 
   // 输出结果
-  const formUrl = authRef.baseUrl + '/' + appType + '/workbench/' + formUuid;
+  const { appUrl, formUrl } = buildFormDeliveryUrls(authRef.baseUrl, appType, formUuid);
   result(true, t('create_form.create_success'), [
     ['Form UUID', formUuid],
     ['URL', formUrl],
   ]);
   console.log(JSON.stringify(withBrowserHandoff(
-    { success: true, formUuid, formTitle, appType, fieldCount, icon: formIcon, iconSource: iconResolution.source, url: formUrl },
+    { success: true, formUuid, formTitle, appType, fieldCount, icon: formIcon, iconSource: iconResolution.source, url: formUrl, formUrl, appUrl },
     formUrl,
     { stage: 'create_form_success', title: formTitle },
     parsedArgs.browserOpenMode
@@ -5127,6 +5137,7 @@ async function createFormForLegacyProcessQuiet(context, input) {
   }
   const saveResult = await saveFormSchema(authRef, appType, formUuid, schema, serverRevision, 4);
   const navIconResult = await updateCreatedFormNavigationIcon(authRef, appType, formUuid, formIcon);
+  const { appUrl, formUrl } = buildFormDeliveryUrls(authRef.baseUrl, appType, formUuid);
   return {
     success: true,
     appType,
@@ -5138,7 +5149,9 @@ async function createFormForLegacyProcessQuiet(context, input) {
     navIconResult,
     icon: formIcon,
     iconSource: iconResolution.source,
-    url: authRef.baseUrl + '/' + appType + '/workbench/' + formUuid,
+    url: formUrl,
+    formUrl,
+    appUrl,
   };
 }
 
@@ -5319,7 +5332,7 @@ async function mainAddOption(parsedArgs, authRef) {
   // Step 4: 保存 Schema
   await saveFormSchema(authRef, appType, formUuid, schema, version, 4);
 
-  const formUrl = authRef.baseUrl + '/' + appType + '/workbench/' + formUuid;
+  const { appUrl, formUrl } = buildFormDeliveryUrls(authRef.baseUrl, appType, formUuid);
   result(true, '选项追加成功', [
     ['Form UUID', formUuid],
     ['Field', fieldLabel],
@@ -5339,6 +5352,8 @@ async function mainAddOption(parsedArgs, authRef) {
     skipped: skippedOptions,
     totalOptions: existingDataSource.length,
     url: formUrl,
+    formUrl,
+    appUrl,
   }));
 }
 
@@ -5438,7 +5453,7 @@ async function mainBindDataSource(parsedArgs, authRef) {
 
   await saveFormSchema(authRef, appType, formUuid, schema, version, 4);
 
-  const formUrl = authRef.baseUrl + '/' + appType + '/workbench/' + formUuid;
+  const { appUrl, formUrl } = buildFormDeliveryUrls(authRef.baseUrl, appType, formUuid);
   result(true, '字段数据源保存成功', [
     ['Form UUID', formUuid],
     ['Field', fieldLabel],
@@ -5459,6 +5474,8 @@ async function mainBindDataSource(parsedArgs, authRef) {
       options: normalized.options.length,
       filterLocal: targetComponent.props.filterLocal,
       pageUrl: formUrl,
+      formUrl,
+      appUrl,
     },
     formUrl,
     { stage: 'bind_datasource_success', title: formUuid },
@@ -6109,6 +6126,59 @@ async function readResumeSchema(authRef, appType, formUuid) {
   return { schemaResult, schema, version: extractSchemaServerRevision(schemaResult) };
 }
 
+function isRetryableResumeSaveServerFailure(errorObject) {
+  const status = Number(errorObject?.details?.result?.__httpStatus);
+  return errorObject?.code === 'CREATE_FORM_SAVE_SCHEMA_FAILED' &&
+    Number.isInteger(status) && status >= 500 && status <= 599;
+}
+
+async function saveResumeSchemaWithSafeRetry(authRef, appType, formUuid, schema, version, fields) {
+  const save = (value, revision) => saveFormSchema(
+    authRef, appType, formUuid, value, revision, 4, { deferFailureOutput: true }
+  );
+  try {
+    await save(schema, version);
+    return '';
+  } catch (originalError) {
+    if (!isRetryableResumeSaveServerFailure(originalError)) { throw originalError; }
+
+    let readback;
+    try { readback = await readResumeSchema(authRef, appType, formUuid); } catch (_) { throw originalError; }
+    const root = readback.schema.pages[0].componentsTree && readback.schema.pages[0].componentsTree[0];
+    const container = root ? findFormContainer(root) : null;
+    if (!container) { throw originalError; }
+    const evidence = collectResumeFieldEvidence(container.children);
+    const verified = buildResumeChanges(
+      evidence,
+      collectResumeDesiredFields(fields, { verifyNestedFields: true })
+    );
+    if (verified.conflicts.length > 0) { throw originalError; }
+    if (verified.missing.length === 0) { return 'save_schema_recovered_by_readback'; }
+    const retryPlan = buildResumeChanges(evidence, collectResumeDesiredFields(fields));
+    if (retryPlan.conflicts.length > 0 || retryPlan.missing.length === 0) { throw originalError; }
+    const applied = applyChangesToSchema(
+      readback.schema,
+      retryPlan.missing.map(function (field) { return { action: 'add', field }; }),
+      { verbose: true }
+    );
+    if ((applied.diagnostics || []).length > 0) { throw originalError; }
+    const updatedContainer = findFormContainer(readback.schema.pages[0].componentsTree[0]);
+    fillSerialNumberFormulas(updatedContainer.children, resolveCorpId(authRef.authData), appType, formUuid);
+
+    try {
+      await save(readback.schema, readback.version);
+    } catch (retryError) {
+      originalError.details = Object.assign({}, originalError.details, {
+        safeRetryAttempted: true,
+        retryErrorCode: retryError?.code || 'CREATE_FORM_SAVE_SCHEMA_FAILED',
+        retryResult: sanitizeFailureResult(retryError?.details?.result),
+      });
+      throw originalError;
+    }
+    return 'save_schema_retried';
+  }
+}
+
 async function mainResume(parsedArgs, authRef) {
   const { appType, formUuid, fieldsJsonOrFile } = parsedArgs;
   assertNoEmojiInDefinitionFileName(fieldsJsonOrFile);
@@ -6139,8 +6209,11 @@ async function mainResume(parsedArgs, authRef) {
     if (resumeValidationRules.length > 0) {
       applySmartValidations(firstRead.schema, resumeValidationRules);
     }
-    await saveFormSchema(authRef, appType, formUuid, firstRead.schema, firstRead.version, 4);
+    const saveRecoveryStage = await saveResumeSchemaWithSafeRetry(
+      authRef, appType, formUuid, firstRead.schema, firstRead.version, fields
+    );
     completedStages.push('rebuild_blank_schema', 'save_schema');
+    if (saveRecoveryStage) { completedStages.push(saveRecoveryStage); }
     recoveredBlankShell = true;
     plan = {
       existing: [],
@@ -6189,8 +6262,11 @@ async function mainResume(parsedArgs, authRef) {
     const corpId = resolveCorpId(authRef.authData);
     const updatedContainer = findFormContainer(firstRead.schema.pages[0].componentsTree[0]);
     fillSerialNumberFormulas(updatedContainer.children, corpId, appType, formUuid);
-    await saveFormSchema(authRef, appType, formUuid, firstRead.schema, firstRead.version, 4);
+    const saveRecoveryStage = await saveResumeSchemaWithSafeRetry(
+      authRef, appType, formUuid, firstRead.schema, firstRead.version, fields
+    );
     completedStages.push('add_missing_fields', 'save_schema');
+    if (saveRecoveryStage) { completedStages.push(saveRecoveryStage); }
   }
 
   const finalRead = await readResumeSchema(authRef, appType, formUuid);
@@ -6211,7 +6287,7 @@ async function mainResume(parsedArgs, authRef) {
     });
   }
   completedStages.push('verify_final_schema');
-  const formUrl = authRef.baseUrl + '/' + appType + '/workbench/' + formUuid;
+  const { appUrl, formUrl } = buildFormDeliveryUrls(authRef.baseUrl, appType, formUuid);
   const output = {
     success: true,
     appType,
@@ -6223,6 +6299,8 @@ async function mainResume(parsedArgs, authRef) {
     finalFieldCount: collectResumeFieldEvidence(finalContainer.children).length,
     recoveredBlankShell,
     url: formUrl,
+    formUrl,
+    appUrl,
   };
   console.log(JSON.stringify(withBrowserHandoff(
     output,
@@ -6384,14 +6462,14 @@ async function mainUpdate(parsedArgs, authRef) {
   await saveFormSchema(authRef, appType, formUuid, schema, version, 6);
 
   // 输出结果
-  const formUrl = authRef.baseUrl + '/' + appType + '/workbench/' + formUuid;
+  const { appUrl, formUrl } = buildFormDeliveryUrls(authRef.baseUrl, appType, formUuid);
   result(true, t('create_form.update_success'), [
     ['Form UUID', formUuid],
     ['URL', formUrl],
     ['Changes', String(appliedChanges.length)],
   ]);
   console.log(JSON.stringify(withBrowserHandoff(
-    { success: true, formUuid, appType, changesApplied: appliedChanges.length, changes: appliedChanges, url: formUrl },
+    { success: true, formUuid, appType, changesApplied: appliedChanges.length, changes: appliedChanges, url: formUrl, formUrl, appUrl },
     formUrl,
     { stage: 'update_form_success', title: formUuid },
     parsedArgs.browserOpenMode

package/lib/core/agent-capabilities.js

@@ -477,22 +477,21 @@ function buildFullAppArtifactRoute(manifest) {
 }
 
 function buildApplicationEntryPolicy(builderPath, env = process.env) {
-  const runtime = builderPath.runtime || {};
-  const managedRuntime = String(env.OPENYIDA_MANAGED_RUNTIME || '').trim().toLowerCase();
-  const managedCloudAgent = managedRuntime === 'cloud' ||
-    runtime.runtime === 'web_sandbox' ||
-    runtime.tool === 'mulerun';
+  void env;
+  const auth = builderPath.auth || {};
+  const injectedAuthUsable = auth.auth_runtime === 'env_token_bootstrap' &&
+    auth.can_auto_use === true;
 
   return {
     schema_version: 1,
-    environment: managedCloudAgent ? 'managed_cloud_agent' : 'non_cloud_agent',
+    environment: injectedAuthUsable ? 'managed_cloud_agent' : 'non_cloud_agent',
     delivery_unit: 'single_application_entry_group',
     resource_delivery: 'summary_only',
     internal_artifact_delivery: 'never',
     entries: {
       workbench: 'always',
       custom: 'when_entry_mode_standalone_and_is_render_nav_false_readback',
-      admin: managedCloudAgent ? 'omit' : 'include',
+      admin: injectedAuthUsable ? 'omit' : 'include',
     },
   };
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "openyida",
-  "version": "2026.9.14",
+  "version": "2026.9.15",
   "description": "OpenYida CLI - 宜搭低代码 AI 开发工具（安装即用，零配置）",
   "bin": {
     "openyida": "bin/yida.js",

package/yida-skills/skills/yida-app/SKILL.md

@@ -9,11 +9,17 @@ description: 宜搭完整应用开发编排技能。对普通 OpenYida 应用做
 
 ## 模式入口（先按这里路由）
 
+`intake.designMode` 是整轮搭建工作流的模式状态，随 intake、需求记录、PRD/视觉设计、方案确认和实施阶段持续传递。它的初始值来自用户的明确选择，后续也只由用户新的明确模式选择更新；其余未决 intake 字段按当前模式的稳定默认策略补齐。Plan 依次产出需求事实、`build-plan.html` / `build-plan.json` 和带 revision 的最终确认；与当前 revision 匹配的 `confirm_build` 是进入真实资源实施阶段的状态转换。在此转换发生前，工作范围保持在需求、设计、方案产物和只读资源检查。
+
+`continue_editing` 使当前计划沿既有 lineage 继续演进。根据变更粒度使用 `design-plan patch`，或编辑当前计划源后 materialize，产出单调递增的新 revision 并再次展示最终确认卡。最近一次获确认的 revision 是后续实施阶段的唯一方案输入。
+
 Plan 模式只读取 `workflow/step-1-resource-context.md`、`workflow/step-2-design.md` 和精确路径 `workflow/plan/workflow.md`；后者已经包含完整 Plan 入口。禁止用 Glob 查找 Plan 文件，也不要额外读取 `workflow/plan/step-1-understand.md` 或 `workflow/plan/step-2-confirm.md`。Plan 确认恢复后，若 `explicitScope.allowInferredResources=false`，直接读取 `workflow/step-4-forms-processes.md` 实施范围内资源，不再重读 Step 1、调用 list-forms 或做应用设置预检。
 
-## 步骤模版（进行时展示给用户看的步骤）
+## 执行步骤（进行时展示给用户）
+
+先从已经确认的 `execution.explicitScope` 生成本轮步骤，再开始资源实施。步骤只对应范围内尚未完成的资源和交付；资源成功回读后从剩余步骤中移除。`allowInferredResources=true` 表示完整应用交付，可使用下面的完整应用模版；`allowInferredResources=false` 表示边界已闭合，使用“需求识别与分析 / 设计功能和页面 / 生成PRD方案&确认（Plan）+ 范围内资源步骤 + 检查范围并交付”的精简步骤。
 
-完整应用搭建时，直接使用对应模式的步骤名称。
+完整应用搭建时使用对应模式的步骤名称。
 
 **Plan 模式**
 
@@ -38,11 +44,11 @@ Plan 模式只读取 `workflow/step-1-resource-context.md`、`workflow/step-2-de
 7. 发布页面与配置导航
 8. 检查功能并交付
 
-已有应用时，直接省略“创建应用”，不另列“复用现有应用”待办，后续步骤重新编号；无需示例数据时跳过对应步骤。步骤状态按真实进度更新，有独立输入的工作可同时进行。
+已有应用时省略“创建应用”，后续步骤重新编号。步骤状态按真实进度更新，有独立输入的工作可同时进行。
 
 用户明确把本轮交付限定为一个或若干具体表单、流程、报表或页面时，按 `explicitScope` 只保留达到该交付所需的步骤；即使需求背景使用“应用/系统”，也不自动补示例数据、自定义工作台、主题设置、导航排序或其他资源。Plan 模式仍生成并确认方案，但确认后只执行该窄范围。
 
-若窄范围只要求创建一个普通表单并交付链接，成功的 `create-form create` 结果就是本轮资源回读证据：立即交付其中的真实链接并停止。不要再调用 `get-schema`、`list-forms`、数据管理技能、示例数据、主题或导航命令，除非创建结果明确缺少 ID/链接或用户另外要求这些内容。
+若窄范围只要求创建一个普通表单并交付链接，成功的 `create-form create` 结果就是本轮资源回读证据。`url` 是兼容字段，与 `formUrl` 表示同一表单入口；`appUrl` 表示应用工作台入口。按用户要求的入口层级选择权威字段，资源保存成功且证据齐全后完成当前范围；证据缺失时执行一次针对性只读回查。普通表单保存成功后进入可用状态，自定义展示页遵循页面发布生命周期。
 
 禁区：待办标题、说明和进度不出现技能名、命令、文件路径、登录账号、内部资源 ID；这些留在工具调用里。用户明确询问技术细节时再解释。
 
@@ -81,7 +87,7 @@ Plan 模式只读取 `workflow/step-1-resource-context.md`、`workflow/step-2-de
 7. **删除必须确认**：用户要求删除应用时，先展示应用名称、应用 ID 和影响范围，等待明确“确认删除”后才能执行。
 8. **列表页选择**：默认使用普通表单的数据管理页；用户明确要求自定义列表页时才创建 display 页面。
 9. **交付物收口**：Step 2 的三个文件和 Step 9 的 build manifest 都是内部文件，不是用户交付物。表单、流程、报表和页面只在业务总结中概述，不逐项生成用户可见附件；宿主支持交付工具时，final 只交付一次“应用访问入口”组。
-10. **窄范围停止点**：完成 `explicitScope` 中的资源回读与真实链接交付后立即停止；不得为了满足完整应用默认完成条件继续进入被裁剪的 Step 5-8。
+10. **范围完成点**：以 `explicitScope` 的资源集合为任务队列；集合清空且真实链接已交付时，本轮完成。完整应用默认完成条件只在 `allowInferredResources=true` 时生效。
 
 ## 关键决策树
 

package/yida-skills/skills/yida-app/workflow/plan/step-4-deliver.md

@@ -24,7 +24,7 @@ openyida design-plan materialize prd/<项目名>/build-plan.json --from-preview
 
 CLI 完整校验后一起保存源计划、`prd.md`、`design.md`、`build-plan.html` 和 `app-theme.css`。HTML 使用预置模板，业务内容与 PRD 一致。
 
-标准首版必须直接执行 init 返回的 `materialize.command`；不得先试 `--from-preview`、`preview`、无参数 materialize 或 shell 重定向。成功 JSON 已包含 `outputs.html` 和 `revision`，直接用于下一步同一次结构化提问，不再 Glob 目录，也不额外 Read `prd.md`、`design.md` 或 `build-plan.json`。
+标准首版的生成入口是 init 返回的 `materialize.command`。成功 JSON 中的 `outputs.html` 和 `revision` 直接构成下一步结构化确认的附件与版本输入。按模块更新过的草稿使用本节单列的 `--from-preview` 命令；诊断使用下方 `--check` 命令。
 
 完整文件的职责与版本规则见 [完整文件合并](../parallel-work.md#plan-的-cli-交接)。直接维护源计划时先设 `meta.status=awaiting_confirmation`，再执行 `openyida design-plan materialize prd/<项目名>/build-plan.json --json`；仅做诊断时使用 `openyida design-plan materialize prd/<项目名>/build-plan.json --check --json`。正常生成已经包含完整校验，不先运行一次 --check 再重复生成。
 
@@ -37,7 +37,7 @@ HTML 保留“需求总览、数据模型、业务流程、页面规划”四章
 按 [用户交互契约](../../../yida-design/references/ask-human-interaction-contract.md) 执行：
 
 1. 在会话中展示“当前这版方案”，并用 3–7 条业务摘要说明方案内容。
-2. 必须实际调用 `ask_human` 创建结构化提问，并通过同一次调用的 `attachments` 携带可打开的 `prd/<项目名>/build-plan.html`；附件对象固定使用 `name: "build-plan.html"`，并将 `revision` 设为当前 `meta.revision`。调用必须遵守交互契约中的实际参数模板：一个顶层 `question`、恰好两个顶层 `options`（value 只能是 `confirm_build`、`continue_editing`）、同次调用的 `attachments`、`revision` 和 `submitLabel`。禁止使用 `fields`、`text`、`textarea`，禁止增加“调整说明”或其他条件式输入。只输出方案正文或普通 assistant 文本后结束本轮属于未完成，严禁用它替代 `ask_human`；也不得改成项目标题，或先发普通文本附件、再单独提问。
+2. 实际调用 `ask_human` 创建结构化提问。调用对象严格采用交互契约中的唯一 payload schema；`attachments` 携带 `name: "build-plan.html"`、`path: "prd/<项目名>/build-plan.html"`，`revision` 使用当前 `meta.revision`，`options` 固定为 `confirm_build` 和 `continue_editing`。一次成功调用同时建立方案展示、版本绑定和最终选择。
 3. 结构化交互成功创建后内部记录 `presentedRevision=meta.revision`。询问“确认并开始搭建”或“继续调整”，提交时由宿主原样回传 revision，将确认结果绑定到本次展示版本。用户可见版本称为“第 N 版方案”，展示序号与内部 revision 绑定。
 
 只有以下条件同时成立才交接；它们由本轮 ask_human 请求和回传在运行时判定，不要求把确认状态写回 workspace 文件：
@@ -46,11 +46,11 @@ HTML 保留“需求总览、数据模型、业务流程、页面规划”四章
 - `meta.planState.planConfirmed=true`
 - `meta.revision=presentedRevision=confirmedRevision`
 
-收到“确认并开始搭建”且回传 revision 等于展示 revision 后，直接进入同版本资源实施。确认之后严禁再次 materialize、patch、Edit 或 Read 计划来“同步确认状态”；不存在可写 `meta.planState.planConfirmed` 的确认命令。`explicitScope.allowInferredResources=false` 时也不执行主题 CSS、应用设置或导航交接，只创建范围内资源并回读、交付。
+收到 `confirm_build` 且回传 revision 等于展示 revision 后，以该版本计划作为实施阶段的唯一方案输入并直接创建范围内资源。`explicitScope.allowInferredResources=false` 时，实施范围由 `explicitScope` 决定，完成资源创建、回读和交付。
 
 ## 4. 处理调整
 
-用户选择“继续调整”后保持在 Plan Design，本轮不创建应用、表单、流程或页面。下一轮再单独询问需要修改的内容；不要把调整说明、自由文本或 textarea 塞进最终确认卡。收到具体调整后才执行下面的 patch，物化新 revision 并重新展示最终确认。
+`continue_editing` 把工作流从 `awaiting_confirmation` 转为 `editing`。下一次交互收集变更内容；收到变更后更新当前计划源，物化新 revision，并重新进入最终确认。
 
 按字段更新源事实并重新生成，例如同时调整品牌色和圆角：
 

package/yida-skills/skills/yida-app/workflow/plan/workflow.md

@@ -6,8 +6,9 @@
 
 - 规划功能、页面和配色：设计功能和页面
 - 生成方案并等待用户确认：生成PRD方案&确认
-- 新建应用确认后：创建应用 → 搭建表单与审批流 → 准备示例数据 → 搭建业务页面 → 发布页面与配置导航 → 检查功能并交付
-- 已有应用确认后：搭建表单与审批流 → 准备示例数据 → 搭建业务页面 → 发布页面与配置导航 → 检查功能并交付
+- 方案确认后：读取同一 revision 的 `execution.explicitScope`，为其中非空的资源集合生成对应实施步骤，最后增加“检查范围并交付”
+- `allowInferredResources=true` 的完整应用：按 `yida-app` 完整应用模版生成后续步骤
+- `allowInferredResources=false` 的闭合范围：后续步骤总集等于确认方案中的资源步骤与交付步骤；每完成并回读一个资源，就从剩余集合中移除
 
 沿用已有待办，不把下面的内部执行顺序另建成一份任务列表。
 
@@ -25,7 +26,7 @@
 4. init 已创建并预填 `business.json` 骨架；先 Read 该文件，保留 `base`，一次补完后再 Write/Edit，避免覆盖保护失败。`facts` 只允许 overview、dataModels、businessFlows、pages 和可选 execution，绝不写 `visualStyle`。同一次补齐所有普通表单的 sampleDataPlan（窄范围不造数时写 skipReason）及所有自定义页面的 permissionSummary，然后直接执行 init 返回的 `materialize.command`，只物化一次。标准首版禁止先试 `--from-preview`、`preview`、`--check` 或无参数 materialize；成功 JSON 已返回 HTML 路径和 revision，不再用 Glob、Read 或帮助命令检查产物。只有存在品牌稿、参考图、页面级特殊风格或用户明确要求精修时，才执行 `optionalTasks.visual-refinement` 后再物化。
 5. 读取精确路径 `workflow/plan/step-4-deliver.md`，按其中契约直接展示并确认当前方案。超大需求需要展示中间进展或用户明确要求边生成边查看时，才使用 [按模块更新方案](../incremental-preview.md)；普通首版不逐模块预览和重复渲染。
 
-明确窄交付时，方案只描述 `explicitScope` 中的资源；确认后裁剪无关步骤，在这些资源回读并交付真实链接后停止。不得因用户使用“应用”一词自行增加 seed records、自定义页面、主题或导航工作。
+明确范围的方案以 `explicitScope` 作为完整执行清单。确认后的每个写操作都对应清单中的一个资源或交付项；清单资源全部回读且真实链接完成交付时，本轮达到完成态。
 
 初次编写只读 CLI 返回的紧凑契约、当前主题上下文及共享需求；模板全文由 CLI 读取。具体组件定制、暗色浮层或复杂页面需要额外规则时，再读取对应章节。
 

package/yida-skills/skills/yida-app/workflow/step-2-design.md

@@ -12,7 +12,7 @@
 
 回答齐全后直接保存内部需求记录并进入 2.1；不把“生成需求简报”列为独立任务，不再扩写或展示简报请用户确认。已有确认记录且需求未变化时直接复用。记录粒度、保存和校验规则统一遵守上述需求分析流程。
 
-显式搭建方式属于本次任务的粘性输入。若用户在首次消息已选择 Plan，澄清业务模块、页面或风格时不得再次询问模式，也不得在合并回答后改写为 Fast；进入 2.1 前必须以用户最后一次明确选择校验 `intake.designMode`。Fast 同理。
+`intake.designMode` 是本次搭建的权威路由输入。进入 intake 和每次 `ask_human` 恢复后都读取该状态：未初始化时收集明确模式选择，已初始化时按问题声明的写回字段合并回答，新的明确模式选择负责更新模式状态。进入 2.1 时直接按合并后的当前状态路由。
 
 执行规划前读取 `constraints.prohibitedActions`。PRD 与 design 必须把禁止项写成实现门禁：`theme-file` 禁止时沿用现有平台主题且不安排主题文件任务；`page-source` 禁止时只允许只读核查与非源码配置；`publish` 禁止时把发布明确标记为跳过。不得为了满足默认九步流程静默删除这些约束。
 

package/yida-skills/skills/yida-app/workflow/step-4-forms-processes.md

@@ -2,7 +2,7 @@
 
 按 PRD 的依赖创建或复用表单和流程。同一轮需要新建两个及以上普通表单时，把独立表单和关联表单写入同一个 `forms.json`，通过 `dependsOn` / `$form` 表达依赖，并且只调用一次 `openyida create-form batch`；由 CLI 内部完成分组、真实 ID 回读和依赖调度，不逐个 create，也不由模型拆成多次 batch。调用前确认实际项目根，让 Write 的绝对路径与 Bash 从项目根使用的 `.cache/openyida/<项目名>/forms.json` 指向同一个物理文件，并用 Read 确认任务文件存在；不要用 batch 探测路径，收到 background pending 后也不要重试 batch。某页所需表单、流程就绪后即可接入该页；不要因其他页面的资源未完成而阻塞无依赖页面开发。
 
-`explicitScope.allowInferredResources=false` 且本轮只有一个普通表单时走最短路径：Write 一份字段文件后调用一次 `openyida create-form create`。Write 会创建父目录，禁止先用 `ls` 或 Bash 检查缓存目录。成功结果已包含真实 formUuid/链接时，直接交付并停止；不得继续 `get-schema`、写 schema evidence、加载数据管理技能、造示例数据、更新主题或排序导航。只有创建结果缺少本次明确验收所需字段时才做一次针对性回读。
+`explicitScope.allowInferredResources=false` 且本轮只有一个普通表单时走最短路径：以 Write 创建字段文件及其父目录，随后调用一次 `openyida create-form create`。成功结果中的 `url`/`formUrl` 是表单入口，`appUrl` 是应用工作台入口。将该表单标记为已完成并计算 `remainingScope`；为空时按用户要求的入口层级交付并完成本轮范围。普通表单保存成功后进入可用状态，自定义展示页遵循页面发布生命周期；验收证据缺失时执行一次针对性只读回查。
 
 拿到真实 `appType` 和已确认的业务契约即可开始本步骤，不等待主题 CSS 上传或应用主题设置回读。主题分支与本步骤并行，按 [主题与业务资源的依赖](parallel-work.md#主题与业务资源的依赖) 汇合。
 
@@ -91,4 +91,7 @@ PRD 导航类型为自定义导航时，对本轮创建或复用的每个表单
 
 ## 下一步
 
-→ [Step 5：写入初始表单数据](step-5-seed-records.md)
+- `remainingScope` 为空：→ [Step 9：按确认范围输出与收尾](step-9-output-finish.md)
+- `remainingScope` 包含 seed records：→ [Step 5：写入初始表单数据](step-5-seed-records.md)
+- `remainingScope` 包含自定义页面：→ [Step 6：创建或复用主页面](step-6-main-page.md)
+- 其他资源：继续执行本步骤中与该资源类型对应的能力，直到资源集合完成

package/yida-skills/skills/yida-app/workflow/step-9-output-finish.md

@@ -16,8 +16,12 @@
 
 主入口与页面入口必须取自本轮 CLI 成功结果返回的 `appUrl`、`workbenchUrl` 或 `url`，并在后续只读回查中保持一致。不得由模型根据 `appType` 自行拼接或猜测链接；下文 URL 规则仅用于校验服务端/CLI 返回值，不是缺失链接时的生成规则。若成功结果没有权威 URL，必须明确交付失败并执行只读回查，不能交付空卡片或用模板补齐。
 
+入口层级由用户的交付目标决定：应用访问、应用入口或应用工作台使用成功结果的 `appUrl`；具体表单、流程、报表或页面入口使用对应资源结果的 `url` / `workbenchUrl`。同一结果同时提供两种入口时，优先满足用户明确点名的层级。
+
 ## 完成条件核对
 
+`execution.explicitScope.allowInferredResources=false` 时走范围完成路径：逐项核对清单内资源的成功结果或只读回读、用户要求的入口层级和交付状态；`remainingScope` 为空且真实链接已交付即为完成。下方完整应用检查表仅适用于 `allowInferredResources=true`。
+
 完整应用默认完成需要同时满足：
 
 1. 主页面发布成功；
@@ -67,17 +71,17 @@
 
 ## 结果输出格式
 
-- 先写 2-3 句业务交付总结，再给一个名为“应用访问入口”的入口组。
-- 调用 `notify_human` 前必须先输出上述正文总结；用户明确要求记录数、资源 ID、发布状态或核验结果时，先在正文写完经 readback 支撑的简洁清单，再调用交付工具。链接卡或平台产物卡不能替代正文总结与显式要求的清单。
-- 一次完整应用搭建只产生这一组用户可见交付，不把表单、流程、报表、页面、资源清单或内部文件分别登记为附件、链接卡或下载卡。
-- 业务资源只在总结中按能力或数量概述是默认规则，例如“已完成 4 张业务表单、1 条审批流程和 1 个经营看板”；不默认输出资源 ID 表格、资源清单、长列表、appType、formUuid、pageId、reportId。
-- 用户或调用方明确要求资源清单、资源 UUID/ID、发布状态或测试数据摘要时，final 必须在业务总结与唯一入口组之间补充一个简洁的“交付清单”。清单只列本轮已通过真实返回值或只读 readback 核验的资源名称、类型和 ID，并同时写明主页面发布状态及 seed records 写入/抽查摘要；不得遗漏已创建或发布的资源，不得用链接卡代替正文清单，也不得编造未知 ID。
-- 即使用户没有要求技术清单，业务总结中的资源数量、seed records 数量以及“已写入/已验证/已就绪”等完成状态也必须逐资源来自真实返回值或只读 readback。证据不完整时缩小表述范围并明确未核验项，禁止为了让总结完整而补齐推测数字。
-- 新增、修改或发布单个具体页面时，仍只交付当前页面，不扩展成完整应用入口组。
-- 完整应用的入口组始终包含“应用工作台” `{base_url}/{appType}/workbench`。
-- 主页面在 PRD 中为 `entryMode=standalone`，且 Step 8 回读确认 `isRenderNav=false` 时，入口组额外包含“独立业务入口” `{base_url}/{appType}/custom/{formUuid}`；否则不得输出。
-- 先读取 `openyida agent-capabilities --summary-json` 的 `application_entry_policy.entries.admin`：值为 `include` 时，入口组额外包含“应用开发后台” `{base_url}/{appType}/admin`；值为 `omit` 时不得输出。不要根据 Agent 名称或自然语言猜测云端/非云端。
-- 三个入口属于同一个应用入口组，不得各自连同业务资源再生成多组交付。
+- 准备 2-3 句业务交付总结，并给一个名为“应用访问入口”的入口组。
+- `notify_human` 是终态交付动作，其终态 artifact 的可见 `description` 是本轮业务总结、readback 事实和必要上下文的统一载体；用户要求的记录数、资源 ID、发布状态或核验结果也写入这里。调用成功即完成本轮交付。
+- 一次完整应用 run 交付一组用户可见的“应用访问入口”。同一应用的后续交付从已有资源和已验证 URL 生成当前 run 的入口组；资源变更由用户本轮明确要求的变更范围驱动。
+- 业务资源在总结中按能力或数量概述，例如“已完成 4 张业务表单、1 条审批流程和 1 个经营看板”。
+- 用户或调用方明确要求资源清单、资源 UUID/ID、发布状态或测试数据摘要时，终态 artifact 的 `description` 包含简洁的“交付清单”。清单是本轮真实返回值和只读 readback 的投影，覆盖已创建或发布资源的名称、类型、ID、主页面发布状态及 seed records 写入/抽查摘要；未知信息标记为未核验。
+- 业务总结中的资源数量、seed records 数量和完成状态与逐资源真实返回值/readback 一一对应；证据不完整的资源标记为未核验。
+- 新增、修改或发布单个具体页面时，交付当前页面并保持单页范围。
+- 完整应用的入口组包含“应用工作台” `{base_url}/{appType}/workbench`。
+- 主页面在 PRD 中为 `entryMode=standalone`，且 Step 8 回读确认 `isRenderNav=false` 时，入口组包含“独立业务入口” `{base_url}/{appType}/custom/{formUuid}`。
+- “应用开发后台”的入口谓词是 `application_entry_policy.entries.admin=include`；命中时加入 `{base_url}/{appType}/admin`，值为 `omit` 时入口组保持已有入口。该策略的事实源是 `openyida agent-capabilities --summary-json`，其中 include 由已注入可用鉴权 `builder_path.auth.auth_runtime=env_token_bootstrap && can_auto_use=true` 推导。
+- 工作台、符合条件的独立业务入口和开发后台共同组成同一个应用入口组。
 - 不把 `g.alicdn.com` 的 `index.css`、`index.js`、`index.html`、`locales/*.json`、构建产物 URL、CDN 资源 URL 或中间文件链接当成最终结果展示。
 - 调用方或评测要求结构化结果时，额外输出顶层 `skillsUsed`，只填写本轮实际读取并使用的 `yida-*` 子技能名；不得把计划使用或未加载的技能写入。
 
@@ -132,10 +136,10 @@
 
 ## Checklist
 
-- [ ] final 先写业务总结，再给唯一一组“应用访问入口”；
-- [ ] `notify_human` 在正文总结与用户显式要求的事实清单之后调用，未把链接卡当成正文替代品；
+- [ ] 唯一一组“应用访问入口”的终态 artifact `description` 已包含业务总结；
+- [ ] `notify_human` 作为最后一个动作调用，用户显式要求的事实清单和资源 ID 已进入可见 `description`；
 - [ ] final 中每个资源数量和数据完成声明都有对应资源自己的成功返回值/readback；未把一张表单的记录数套用到其他表单；
-- [ ] 用户或调用方显式要求资源清单/UUID/发布状态/测试数据摘要时，正文已完整列出经核验的交付清单，未只返回链接卡；
+- [ ] 用户或调用方显式要求资源清单/UUID/发布状态/测试数据摘要时，终态 artifact `description` 已完整列出经核验的交付清单；
 - [ ] 已写入轻量 build-manifest 并运行页面/资源数量完整性风险检查；未通过时没有声称“已按 PRD 完成搭建”；
 - [ ] 已按 `constraints.prohibitedActions` 调整完成条件；跳过写操作时没有伪造已换肤、已修改源码或已发布；
 - [ ] 未把内部文件或每个业务资源分别交付；

package/yida-skills/skills/yida-create-form-page/SKILL.md

@@ -110,7 +110,15 @@ description: 表单页面创建与更新；支持 19 种业务字段和 Divider
 
 关联字段必须把引用放在 `associationForm` 内。推荐使用紧凑写法 `"associationForm": { "$form": "customer", "field": "客户名称" }`；batch 会将其规范化为 `associationForm.formUuid` 和 `associationForm.mainFieldId`。完整写法则分别在 `formUuid` 使用 `{ "$form": "customer" }`、在 `mainFieldId` 使用 `{ "$form": "customer", "field": "客户名称" }`。不要把 `$form` 放在 `AssociationFormField` 顶层，也不要用 `batch --help`、空参数或临时计划探索格式；技能中的结构就是正式契约。
 
-批量命令超过前台时限进入后台属于正常行为。此时必须保留原任务和 `<forms.json>.state.json`，等待运行时自动回传结果；禁止调用 `ToolStop`，禁止删除 `.state.json`/`.lock`，禁止改变参数再次调用 batch。若最终返回 `FORM_BATCH_PARTIAL_FAILURE`，在本轮原样保留结构化错误并停止；禁止模型侧再调用 `create-form create`、`update` 或 `resume` 补洞。CLI 会在同一次 batch 内对已取得真实 `formUuid` 的空壳表单执行一次保守恢复。
+Batch 以任务文件指纹和 `<forms.json>.state.json` 共同标识一次批量操作，恢复动作由结果中的 `recoveryAction` 唯一决定：
+
+| 当前结果 | 状态事实 | 下一动作 |
+| --- | --- | --- |
+| background pending | 原任务仍在执行，task/state/lock 保持为同一操作 | 保持当前执行单元，后续只接收该任务的最终结果 |
+| `FORM_BATCH_PARTIAL_FAILURE` + `rerun_unchanged_plan` | 已知 `formUuid` 已记录在 state，原任务指纹可安全恢复 | 后续使用原任务文件和原参数重新执行同一 batch，由 CLI 从 state 复用已知资源 |
+| `FORM_BATCH_PARTIAL_FAILURE` + `inspect_unknown_write_then_reconcile` | 至少一个远端写结果缺少资源 ID，当前指纹进入待核对状态 | 先回读远端资源；核对完成后建立新的 reconcile 任务，用已确认 `formUuid` 表示已有表单，仅保留确定尚未创建的任务 |
+
+CLI 在同一次 batch 内对已取得真实 `formUuid` 的空壳表单执行一次保守恢复。每个结果状态只沿表中对应的下一动作推进。
 
 ## 官方表单示例范式
 
@@ -179,9 +187,11 @@ openyida create-form create <appType> <formTitle> <fieldsJsonOrFile> [--layout d
 输出：
 
 ```json
-{"success":true,"formUuid":"FORM-XXX","formTitle":"用户信息表","appType":"APP_xxx","fieldCount":4,"icon":"name-card","iconSource":"auto","url":"{base_url}/APP_xxx/workbench/FORM-XXX"}
+{"success":true,"formUuid":"FORM-XXX","formTitle":"用户信息表","appType":"APP_xxx","fieldCount":4,"icon":"name-card","iconSource":"auto","url":"{base_url}/APP_xxx/workbench/FORM-XXX","formUrl":"{base_url}/APP_xxx/workbench/FORM-XXX","appUrl":"{base_url}/APP_xxx/workbench"}
 ```
 
+`url` 是兼容字段，与 `formUrl` 表示同一表单入口；`appUrl` 表示应用工作台入口。普通表单保存成功后进入可用状态，自定义展示页使用 `publish-page` 生命周期。终态交付按用户请求的层级选择对应权威入口和 `resourceType`/`resourceId`：应用级使用 `appUrl`、`app_home`、`appType`，表单级使用 `formUrl`、`form`、`formUuid`。
+
 完整应用模式下的下一步：
 
 1. 将 `formUuid`、字段摘要和字段 JSON 路径写入 `.cache/<项目名>-schema.json`。
@@ -221,12 +231,16 @@ openyida create-form resume <appType> <formUuid> <fieldsJsonOrFile> --json
 该命令先回读目标表单并核对字段，只添加可唯一判定的缺失字段，保存后再次回读；同名异类型、重复
 目标字段、归属不匹配或回读不确定时均停止且不写入。它不会新建替代表单，也不会覆盖已有字段。
 
+`resume` 的保存端 HTTP 5xx 恢复流程固定为：精确回读目标表单；目标字段已存在时收口为成功，目标字段缺失且无冲突时绑定最新服务端 revision 执行一次保存，再做最终回读。成功 JSON 提供真实 `formUuid`、表单入口 `url`/`formUrl` 和应用工作台入口 `appUrl`，据此完成终态交付；用户要求资源 ID 时，将已验证的 `formUuid` 写入终态 artifact 的可见 `description`。
+
 输出：
 
 ```json
-{"success":true,"formUuid":"FORM-YYY","appType":"APP_XXX","changesApplied":1,"changes":[{"action":"update","label":"备注","changedProps":"required","resolved":{"label":"备注","fieldId":"textField_xxx","componentName":"TextField"},"updatedProps":{"required":true}}],"url":"{base_url}/APP_XXX/workbench/FORM-YYY"}
+{"success":true,"formUuid":"FORM-YYY","appType":"APP_XXX","changesApplied":1,"changes":[{"action":"update","label":"备注","changedProps":"required","resolved":{"label":"备注","fieldId":"textField_xxx","componentName":"TextField"},"updatedProps":{"required":true}}],"url":"{base_url}/APP_XXX/workbench/FORM-YYY","formUrl":"{base_url}/APP_XXX/workbench/FORM-YYY","appUrl":"{base_url}/APP_XXX/workbench"}
 ```
 
+`resume` 的终态交付沿用相同入口映射：应用级交付选择 `appUrl` / `app_home`，表单级交付选择 `formUrl` / `form`；`url` 继续兼容表单入口。
+
 常见 compact changes：
 
 ```json

package/yida-skills/skills/yida-create-form-page/references/batch-forms.md

@@ -63,9 +63,10 @@ batch 会在预校验前把紧凑写法规范化为下面的完整结构；前
 - `--concurrency 1..4` 设置并发上限，默认 3。
 - 结果保存在任务文件旁的 `.state.json`，包含每张表单的 ID、字段和状态。主流程从中汇总资源上下文，再配置导航。
 - 相同任务再次执行时，成功表单回读复用。失败及中断任务保留原状态，其依赖标记为 blocked；独立任务继续。
-- 当前批次返回 `success:false` 时，以返回的 `results`、子命令诊断和 `.state.json` 为准停止本轮创建；不得为补齐失败项改用单条 `create-form create`，也不得把剩余项拆成新的 batch。修正输入或为已知资源补入 `formUuid` 后，后续恢复仍使用原任务文件执行 batch。
-- 恢复失败任务前，核对已创建资源并修复。准备新任务文件时，用 `formUuid` 复用完整表单，仅为确认尚未创建的表单保留创建任务。
+- `success:false` 时，`results`、子命令诊断、`.state.json` 和 `recoveryAction` 共同描述本轮终态及下一步。
+- `rerun_unchanged_plan` 表示原任务指纹可安全恢复：后续使用原任务文件和原参数执行同一 batch，CLI 从 state 读取已知 ID 并复用成功表单。
+- `inspect_unknown_write_then_reconcile` 表示当前指纹进入待核对状态：先回读远端资源；核对完成后建立新的 reconcile 任务，用已确认 `formUuid` 表示已有表单，仅保留确定尚未创建的任务。
 - `.lock` 防止同一任务重复启动。进程异常退出遗留锁时，确认原进程已结束、核对已创建资源后再清理。
-- 首次 batch 返回 background pending 时等待运行时自动投递完成结果；pending 不是失败，也不是重试信号，不得再次调用 batch。
+- background pending 表示原 batch 仍在执行；task/state/lock 继续代表同一执行单元，后续只接受该任务的最终结果。
 
 已有表单的字段修改仍使用 update/patch 等命令；不同表单可分别更新，同一张表单由一个任务维护。流程审批按 `yida-create-process` 执行，等待其依赖的表单就绪后再配置。

package/yida-skills/skills/yida-design/references/ask-human-interaction-contract.md

@@ -140,41 +140,9 @@ Plan Design 完成当前版本后，按以下顺序与用户交互：
 
 `build-plan.html` 不承载对话控件或确认按钮；用户在会话中完成确认。
 
-最终确认是一个 `single_select` 语义问题：只使用一个顶层 `question` 和恰好两个顶层 `options`，附件与版本必须放在同一次调用中。下面先记录内部逻辑身份；`interactionId`、`questionType`、`prompt`、`allowCustom` 和 `writeBackPath` 只用于状态理解，不是可传给工具的参数：
+最终确认是一个 `single_select` 语义问题。它只有下面这一份可调用 schema；顶层字段集合固定为 `question`、`title`、`options`、`attachments`、`revision`、`submitLabel`。将路径和 `{revision}` 替换为本次 materialize 返回的真实值：
 
-```json
-{
-  "interactionId": "plan_confirm_r{revision}",
-  "questionType": "confirm",
-  "title": "确认整体方案",
-  "prompt": "是否按当前这版方案开始搭建？",
-  "options": [
-    {
-      "value": "confirm_build",
-      "label": "确认并开始搭建",
-      "description": "按当前方案创建应用、表单、流程和页面。"
-    },
-    {
-      "value": "continue_editing",
-      "label": "继续调整",
-      "description": "继续完善当前方案，确认后再开始搭建。"
-    }
-  ],
-  "allowCustom": false,
-  "writeBackPath": "meta.planState",
-  "attachments": [
-    {
-      "name": "当前搭建方案",
-      "path": "prd/<项目名>/build-plan.html"
-    }
-  ],
-  "revision": "{revision}"
-}
-```
-
-#### 实际 `ask_human` 调用参数
-
-模型必须直接复制下面的可调用结构，并将路径、`{revision}` 替换为本次 materialize 返回的真实值：
+#### 最终确认 `ask_human` payload
 
 ```json
 {
@@ -203,9 +171,7 @@ Plan Design 完成当前版本后，按以下顺序与用户交互：
 }
 ```
 
-最终确认 payload 禁止使用 `fields`、`text`、`textarea`，也禁止增加“调整说明”或其他条件式补充问题；`options` 的 value 集合必须恰好为 `confirm_build`、`continue_editing`。确认与调整内容不能合并收集。
-
-用户选择 `continue_editing` 后保持在 Plan Design，本次确认恢复不创建任何应用资源；在下一轮用新的问题单独收集要修改的内容，完成 patch/materialize、生成新 revision 后，再展示同样结构的最终确认。用户选择 `confirm_build` 且回传 revision 匹配时，才进入资源实施。
+`options` 固定为 `confirm_build`、`continue_editing` 两项。最终确认只收集当前 revision 的去向；调整内容由进入 editing 状态后的下一次交互收集。内部交互身份使用 `plan_confirm_r{revision}`，回答写入 `meta.planState`。
 
 ## 版本与确认状态
 
@@ -225,11 +191,14 @@ Plan Design 完成当前版本后，按以下顺序与用户交互：
 }
 ```
 
-状态更新规则：
+状态转换规则：
+
+| 当前状态 | 事件 | 下一状态与产出 |
+| --- | --- | --- |
+| 初始 | 首次生成计划 | 创建 `meta.revision`，进入 `draft` |
+| `draft` / `editing` | materialize 成功并展示计划 | 进入 `awaiting_confirmation`，`presentedRevision=meta.revision` |
+| `awaiting_confirmation` | `confirm_build` 且回传 revision 匹配 | 进入 `confirmed`，记录 `planConfirmed=true`、`confirmedRevision`、交互 ID 和确认时间，并以该 revision 进入资源实施 |
+| `awaiting_confirmation` | `continue_editing` | 进入 `editing`；下一次交互收集变更，生成新 revision 后重新 materialize 和确认 |
+| 任意非终态 | 用户取消或关闭交互 | 进入 `stopped`，保留当前计划产物 |
 
-1. 首次生成计划时创建 `meta.revision`，设置 `meta.status=draft`、`meta.planState.planConfirmed=false`。
-2. 每次修改影响搭建计划事实时生成新的 `meta.revision`，并清空旧确认信息。
-3. 计划展示完成后设置 `meta.status=awaiting_confirmation` 和 `presentedRevision=meta.revision`。
-4. 用户在最终确认交互中选择“确认并开始搭建”时，设置 `meta.status=confirmed`、`planConfirmed=true`、`confirmedRevision=meta.revision`，同时记录交互 ID 和确认时间。
-5. 只有 `meta.status=confirmed`、`planConfirmed=true` 且 `meta.revision=presentedRevision=confirmedRevision` 时，Plan Design 才能返回 `yida-app` Step 3。
-6. 用户选择“继续调整”时保持在 Plan Design，本轮不创建应用资源；下一轮单独收集调整内容，生成新 revision 并重新确认。用户取消或关闭交互时停止执行，不创建应用资源。
+资源实施的进入条件是 `meta.status=confirmed`、`planConfirmed=true` 且 `meta.revision=presentedRevision=confirmedRevision`。

package/yida-skills/skills/yida-design/references/design-mode.md

@@ -9,6 +9,6 @@
 
 用户同时要求先出计划和少提问时采用 Plan，复用已知信息。用户指定的详细计划作为规划基础，补齐实施所需的缺项。
 
-同一目标、同一次搭建复用已确认方式；该选择在需求澄清、`ask_human` 恢复和 brief 合并中保持粘性，回答未重复提到模式不代表改选。只有用户明确要求改用另一方式时才更新 `intake.designMode`。切换目标时重新判断。已有应用的局部增改、单页美化和主题调整直接处理本次任务，遇到会改变范围的问题再澄清。
+同一目标、同一次搭建以 `intake.designMode` 作为权威模式状态。需求澄清、`ask_human` 恢复和 brief 合并都携带该状态；用户新的明确模式选择触发状态转换，其他回答只更新各自声明的字段。新目标重新初始化模式判断。已有应用的局部增改、单页美化和主题调整直接处理本次任务，遇到会改变范围的问题再澄清。
 
 两种方式共用业务和视觉契约；Plan 额外展示方案并绑定当前版本确认。面向用户的表达与宿主适配见 [用户交互契约](ask-human-interaction-contract.md)。

package/yida-skills/skills/yida-requirement-analysis/workflow/prepare-brief.md

@@ -14,11 +14,13 @@
 
 ## 2. 确认首次搭建的未决事项
 
-先分析再提问。用户已明确的信息直接采用；同一次搭建已回答的问题直接复用。首次提问必须在同一轮一次性收集所有尚未明确的搭建方式（Fast / Plan）、业务模块、页面与表单范围和设计风格。不要先问模块和风格，收到回答后再另起一轮补问模式或页面。导航方式及布局由 AI 按下方规则判断。
+先分析再提问。用户已明确的信息直接采用；同一次搭建已回答的问题直接复用。首次结构化提问以一次原子交互收集全部未决的搭建方式（Fast / Plan）、业务模块、页面与表单范围和设计风格，回答完成后统一写回。导航方式及布局由 AI 按下方规则判断。
 
-先锁定用户已经明确的搭建方式：用户写明 `Plan`、先出 PRD/方案并确认后搭建时，立即把草稿的 `intake.designMode` 设为 `plan`；用户写明 `Fast` 或直接快速搭建时设为 `fast`。已锁定的搭建方式不再进入提问选项。后续 `ask_human` 只补齐其他未决事项，合并回答时必须保留已有 `intake.designMode`；不能因为回答里没有重复提到模式、结构化问题被合并、上下文压缩或重新生成 brief 而回退到 Fast。只有用户明确说“改用 Fast/Plan”时才能切换，并以最后一次明确选择为准。
+`intake.designMode` 是搭建方式的权威状态。初始化时把用户明确选择的 Plan / Fast 意图分别映射为 `plan` / `fast`；状态未确定时才把搭建方式纳入提问，用户明确选择后完成初始化。后续结构化回答按各问题声明的写回字段合并，搭建方式只在用户给出新的明确模式选择时发生状态转换，并以该选择作为后续路由依据。
 
-将整组问题放在一次结构化提问调用中。宿主限制问题数量时，合并为“搭建方式”“业务模块、页面与风格”等复合问题；选项数量或多选能力不足时，用允许自由输入的同组问题列出完整选择。不得因为工具数量限制而拆成多轮。只有回答遗漏、互相冲突或产生新的关键业务疑问时才针对性追问。
+`intake.designMode` 与其他 intake 字段分开演进：搭建方式保持当前明确选择，尚未确定的模块、页面、风格等字段由该模式的稳定默认策略补齐。Plan 的 intake 完成后进入方案生成；与当前 revision 匹配的最终确认使工作流进入实施阶段。每次合并 `ask_human` 回答或重建 brief 都按这一状态转换规则写回。
+
+将整组问题放在一次结构化提问调用中。宿主限制问题数量时，合并为“搭建方式”“业务模块、页面与风格”等复合问题；选项数量或多选能力不足时，用允许自由输入的同组问题列出完整选择。回答遗漏、互相冲突或产生新的关键业务疑问时，再开启一次针对性补充交互。
 
 | 事项 | 何时询问 | 用户可见问题与选项 |
 | --- | --- | --- |
@@ -63,7 +65,7 @@ AI 在已确定的导航方式内，结合业务模块数量、层级、切换
 本步骤是保存答案，不是重新撰写需求文档：
 
 - 合并已读取的需求、资源信息和本轮回答，完成必要确认后一次写入；中断恢复可保存未确认草稿，但不得把草稿当作已确认输入。
-- 合并采用保留式更新：未被本轮提问的已确认字段不得用默认值覆盖。尤其 `intake.designMode` 是同一次搭建的粘性选择；若本轮没有询问搭建方式，写回值必须与提问前一致。
+- 合并采用字段级保留式更新：本轮问题声明的写回字段使用新回答，其余已确认字段沿用现值；`intake.designMode` 按上面的模式状态转换规则写回。
 - 简短需求使用简短事实、列表和必要的页面标识，不扩写背景、价值分析、完整字段表、页面区块或验收标准；这些设计工作由后续 PRD 与视觉设计负责。用户已提供的字段、关系、流程和页面细项必须保留，不为精简而丢弃，也不重复改写成多份摘要。
 - 不另建 `brief.md`、简报 HTML 或简报附件，不为保存 JSON 单独安排一次模型扩写或用户确认。用户回答清楚后直接记录，不能再展示整份简报询问“是否确认需求”。
 - 已有确认记录且需求未变化时直接复用；后续只补充已确定的视觉映射或更新用户变更涉及的字段，不因阶段切换重写全文或重新生成页面 key。