openyida 2026.9.13 → 2026.9.15

package/lib/core/utils.js

@@ -1080,6 +1080,362 @@ function createNonJsonResponseResult(statusCode, data) {
   };
 }
 
+function buildRequestUrl(baseUrl, requestPath, queryParams) {
+  const normalizedBaseUrl = String(baseUrl || '').replace(/\/+$/, '') + '/';
+  const requestUrl = new URL(requestPath, normalizedBaseUrl);
+  if (queryParams) {
+    Object.entries(queryParams).forEach(([key, value]) => {
+      if (value !== undefined && value !== null) {
+        requestUrl.searchParams.set(key, String(value));
+      }
+    });
+  }
+  return requestUrl;
+}
+
+async function fetchWithTimeout(requestUrl, requestOptions, timeout, readResponse) {
+  const controller = new AbortController();
+  const timer = setTimeout(() => controller.abort(), timeout || 30000);
+  try {
+    const response = await fetch(requestUrl, {
+      ...requestOptions,
+      signal: controller.signal,
+    });
+    return readResponse ? await readResponse(response) : response;
+  } catch (error) {
+    if (error && error.name === 'AbortError') {
+      throw new Error(t('common.request_timeout'));
+    }
+    throw error;
+  } finally {
+    clearTimeout(timer);
+  }
+}
+
+async function parseJsonFetchResponse(response, options = {}) {
+  const data = await response.text();
+  if (!options.silentStatus) {
+    warn(t('common.http_status', response.status));
+  }
+  if (isHttpRedirectStatus(response.status) || isHttpAuthStatus(response.status)) {
+    return {
+      __needLogin: true,
+      __httpStatus: response.status,
+      __location: response.headers.get('location') || '',
+    };
+  }
+  try {
+    const parsed = JSON.parse(data);
+    if (isLoginExpired(parsed)) {
+      return { __needLogin: true };
+    }
+    if (isCsrfTokenExpired(parsed)) {
+      return { __csrfExpired: true };
+    }
+    return parsed;
+  } catch {
+    if (!options.silentStatus) {
+      warn(t('common.http_response', data.substring(0, 500)));
+    }
+    return createNonJsonResponseResult(response.status, data);
+  }
+}
+
+function appendMultipartFile(form, fieldName, file) {
+  if (!file || file.content === undefined || file.content === null) {
+    throw new TypeError(`multipart file ${fieldName} is required`);
+  }
+  const content = Buffer.isBuffer(file.content)
+    ? file.content
+    : Buffer.from(String(file.content), 'utf8');
+  form.append(
+    fieldName,
+    new Blob([content], { type: file.contentType || 'application/octet-stream' }),
+    file.fileName || fieldName
+  );
+}
+
+/**
+ * 发送 multipart/form-data POST。Content-Type boundary 由 Node.js FormData 生成。
+ */
+async function httpPostMultipart(baseUrl, requestPath, fields, files, optionsOrLegacyCookies, maybeOptions) {
+  if (typeof fetch !== 'function' || typeof FormData !== 'function' || typeof Blob !== 'function') {
+    throw new Error('当前 Node.js 环境缺少 fetch/FormData/Blob，请使用 Node.js 18+');
+  }
+  const optionsOverride = resolveRequestOptions(optionsOrLegacyCookies, maybeOptions);
+  const authHeaders = await resolveRequestAuthHeaders(optionsOverride);
+  const form = new FormData();
+  Object.entries(fields || {}).forEach(([key, value]) => {
+    if (value !== undefined && value !== null) {
+      form.append(key, String(value));
+    }
+  });
+  Object.entries(files || {}).forEach(([key, file]) => appendMultipartFile(form, key, file));
+
+  const requestUrl = buildRequestUrl(baseUrl, requestPath);
+  return fetchWithTimeout(requestUrl, {
+    method: 'POST',
+    redirect: 'manual',
+    headers: {
+      Accept: 'application/json, text/plain, */*',
+      Origin: requestUrl.origin,
+      Referer: optionsOverride.referer || requestUrl.origin + '/',
+      'x-requested-with': 'XMLHttpRequest',
+      ...authHeaders,
+    },
+    body: form,
+  }, optionsOverride.timeout, response => parseJsonFetchResponse(response, optionsOverride));
+}
+
+async function readFetchResponseBuffer(response, maxBytes, timeout) {
+  const limit = Number(maxBytes);
+  const timeoutMs = Number(timeout) || 30000;
+  const contentLength = Number(response.headers.get('content-length') || 0);
+  if (Number.isFinite(limit) && limit > 0 && contentLength > limit) {
+    const error = new Error(`响应内容超过允许大小 ${limit} bytes`);
+    error.code = 'HTTP_RESPONSE_TOO_LARGE';
+    throw error;
+  }
+
+  if (!response.body || typeof response.body.getReader !== 'function') {
+    let timer;
+    const arrayBuffer = await Promise.race([
+      response.arrayBuffer(),
+      new Promise((resolve, reject) => {
+        void resolve;
+        timer = setTimeout(() => reject(new Error(t('common.request_timeout'))), timeoutMs);
+      }),
+    ]).finally(() => clearTimeout(timer));
+    const buffer = Buffer.from(arrayBuffer);
+    if (Number.isFinite(limit) && limit > 0 && buffer.length > limit) {
+      const error = new Error(`响应内容超过允许大小 ${limit} bytes`);
+      error.code = 'HTTP_RESPONSE_TOO_LARGE';
+      throw error;
+    }
+    return buffer;
+  }
+
+  const chunks = [];
+  let size = 0;
+  const reader = response.body.getReader();
+  let timedOut = false;
+  const timer = setTimeout(() => {
+    timedOut = true;
+    void reader.cancel();
+  }, timeoutMs);
+  try {
+    for (;;) {
+      const { done, value } = await reader.read();
+      if (done) {
+        break;
+      }
+      const chunk = Buffer.from(value);
+      size += chunk.length;
+      if (Number.isFinite(limit) && limit > 0 && size > limit) {
+        await reader.cancel();
+        const error = new Error(`响应内容超过允许大小 ${limit} bytes`);
+        error.code = 'HTTP_RESPONSE_TOO_LARGE';
+        throw error;
+      }
+      chunks.push(chunk);
+    }
+    if (timedOut) {
+      throw new Error(t('common.request_timeout'));
+    }
+  } finally {
+    clearTimeout(timer);
+    reader.releaseLock();
+  }
+  return Buffer.concat(chunks, size);
+}
+
+function normalizeResponseContentType(value) {
+  return String(value || '').split(';')[0].trim().toLowerCase();
+}
+
+function responseRequestId(response) {
+  return response.headers.get('x-request-id') || '';
+}
+
+function buildCodeBundleResponseMetadata(requestUrl, response) {
+  const metadata = {
+    baseUrl: requestUrl.origin,
+    finalHost: requestUrl.host,
+    status: response.status,
+    contentType: normalizeResponseContentType(response.headers.get('content-type')),
+    eagleeyeTraceId: response.headers.get('eagleeye-traceid') || '',
+    requestId: responseRequestId(response),
+  };
+  metadata.context = [
+    `baseUrl=${metadata.baseUrl}`,
+    `finalHost=${metadata.finalHost}`,
+    `status=${metadata.status}`,
+    `contentType=${metadata.contentType || 'missing'}`,
+    metadata.eagleeyeTraceId ? `eagleeyeTraceId=${metadata.eagleeyeTraceId}` : '',
+    metadata.requestId ? `requestId=${metadata.requestId}` : '',
+  ].filter(Boolean).join(', ');
+  return metadata;
+}
+
+function createCodeBundleDownloadError(code, reason, metadata, responsePreview) {
+  const suffix = responsePreview ? `; response=${responsePreview}` : '';
+  const error = new Error(t('common.code_bundle_download_failed', reason, metadata.context) + suffix);
+  error.code = code;
+  error.details = {
+    ...metadata,
+    responsePreview: responsePreview || undefined,
+  };
+  return error;
+}
+
+function compactResponsePreview(buffer) {
+  return buffer.toString('utf8').replace(/\s+/g, ' ').trim().substring(0, 500);
+}
+
+async function readErrorResponsePreview(response, timeout) {
+  try {
+    return compactResponsePreview(await readFetchResponseBuffer(response, 4096, timeout));
+  } catch {
+    return '';
+  }
+}
+
+function looksLikeHtml(buffer) {
+  const prefix = buffer.toString('utf8', 0, Math.min(buffer.length, 256)).trimStart().toLowerCase();
+  return prefix.startsWith('<!doctype html')
+    || prefix.startsWith('<html')
+    || prefix.startsWith('<head')
+    || prefix.startsWith('<body');
+}
+
+function expectedContentTypeMatches(actualContentType, expectedContentTypes) {
+  if (!Array.isArray(expectedContentTypes) || expectedContentTypes.length === 0) {
+    return true;
+  }
+  return expectedContentTypes.some(value => normalizeResponseContentType(value) === actualContentType);
+}
+
+function jsonResponseReason(preview) {
+  if (!preview) {
+    return t('common.code_bundle_json_response', t('common.unknown_error'));
+  }
+  try {
+    const payload = JSON.parse(preview);
+    const message = payload && (payload.errorMsg || payload.message || payload.throwable || payload.errorCode);
+    return t('common.code_bundle_json_response', message || t('common.unknown_error'));
+  } catch {
+    return t('common.code_bundle_json_response', t('common.unknown_error'));
+  }
+}
+
+/**
+ * 从宜搭首方接口直接获取 CodeBundle 文本。
+ */
+async function httpGetCodeBundleText(baseUrl, requestPath, queryParams, optionsOrLegacyCookies, maybeOptions) {
+  if (typeof fetch !== 'function') {
+    throw new Error('当前 Node.js 环境缺少 fetch，请使用 Node.js 18+');
+  }
+  const optionsOverride = resolveRequestOptions(optionsOrLegacyCookies, maybeOptions);
+  const authHeaders = await resolveRequestAuthHeaders(optionsOverride);
+  const requestUrl = buildRequestUrl(baseUrl, requestPath, queryParams);
+  const maxBytes = Number(optionsOverride.maxBytes) || 5 * 1024 * 1024;
+  const response = await fetchWithTimeout(requestUrl, {
+    method: 'GET',
+    redirect: 'manual',
+    headers: {
+      Accept: 'text/plain, application/javascript, */*',
+      Origin: requestUrl.origin,
+      Referer: requestUrl.origin + '/',
+      'x-requested-with': 'XMLHttpRequest',
+      ...authHeaders,
+    },
+  }, optionsOverride.timeout);
+  const metadata = buildCodeBundleResponseMetadata(requestUrl, response);
+
+  if (response.status === 401) {
+    return { __needLogin: true, __httpStatus: response.status };
+  }
+  if (response.status < 200 || response.status >= 300) {
+    const preview = await readErrorResponsePreview(response, optionsOverride.timeout);
+    if (response.status === 403) {
+      throw createCodeBundleDownloadError(
+        'CODE_BUNDLE_DOWNLOAD_FORBIDDEN',
+        t('common.code_bundle_forbidden'),
+        metadata,
+        preview
+      );
+    }
+    if (response.status === 404) {
+      throw createCodeBundleDownloadError(
+        'CODE_BUNDLE_DOWNLOAD_NOT_FOUND',
+        t('common.code_bundle_not_found'),
+        metadata,
+        preview
+      );
+    }
+    throw createCodeBundleDownloadError(
+      'CODE_BUNDLE_DOWNLOAD_HTTP_ERROR',
+      t('common.code_bundle_http_error', response.status),
+      metadata,
+      preview
+    );
+  }
+
+  const contentType = metadata.contentType;
+  const htmlResponse = contentType === 'text/html' || contentType === 'application/xhtml+xml';
+  const jsonResponse = contentType === 'application/json' || contentType.endsWith('+json');
+  if (htmlResponse || jsonResponse
+    || !expectedContentTypeMatches(contentType, optionsOverride.expectedContentTypes)) {
+    const preview = await readErrorResponsePreview(response, optionsOverride.timeout);
+    if (htmlResponse) {
+      throw createCodeBundleDownloadError(
+        'CODE_BUNDLE_DOWNLOAD_HTML_RESPONSE',
+        t('common.code_bundle_html_response'),
+        metadata,
+        preview
+      );
+    }
+    if (jsonResponse) {
+      throw createCodeBundleDownloadError(
+        'CODE_BUNDLE_DOWNLOAD_JSON_RESPONSE',
+        jsonResponseReason(preview),
+        metadata,
+        preview
+      );
+    }
+    throw createCodeBundleDownloadError(
+      'CODE_BUNDLE_DOWNLOAD_UNEXPECTED_CONTENT_TYPE',
+      t('common.code_bundle_unexpected_content_type', contentType || 'missing'),
+      metadata,
+      preview
+    );
+  }
+
+  const buffer = await readFetchResponseBuffer(response, maxBytes, optionsOverride.timeout);
+  if (looksLikeHtml(buffer)) {
+    throw createCodeBundleDownloadError(
+      'CODE_BUNDLE_DOWNLOAD_HTML_RESPONSE',
+      t('common.code_bundle_html_response'),
+      metadata,
+      compactResponsePreview(buffer)
+    );
+  }
+  let value;
+  try {
+    value = new TextDecoder('utf-8', { fatal: true }).decode(buffer);
+  } catch {
+    throw createCodeBundleDownloadError(
+      'CODE_BUNDLE_DOWNLOAD_INVALID_UTF8',
+      t('common.code_bundle_invalid_utf8'),
+      metadata
+    );
+  }
+  if (typeof optionsOverride.onResponseMetadata === 'function') {
+    optionsOverride.onResponseMetadata(metadata);
+  }
+  return value;
+}
+
 /**
  * 发送 HTTP POST 请求（application/x-www-form-urlencoded）
  * @param {string} baseUrl
@@ -1504,8 +1860,10 @@ module.exports = {
   isLoginExpired,
   isCsrfTokenExpired,
   httpPost,
+  httpPostMultipart,
   httpPostJson,
   httpGet,
+  httpGetCodeBundleText,
   requestWithAutoLogin,
   requestNonIdempotentWithAuthPreflight,
   getNpmExecutable,

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "openyida",
-  "version": "2026.9.13",
+  "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`。只输出方案正文或普通 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,10 +46,12 @@ 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. 处理调整
 
+`continue_editing` 把工作流从 `awaiting_confirmation` 转为 `editing`。下一次交互收集变更内容；收到变更后更新当前计划源，物化新 revision，并重新进入最终确认。
+
 按字段更新源事实并重新生成，例如同时调整品牌色和圆角：
 
 ```bash

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

@@ -8,11 +8,11 @@
 
 ## 2.0 先分析并确认需求
 
-调用 `yida-requirement-analysis`，按 [需求分析与首次搭建确认](../../yida-requirement-analysis/workflow/prepare-brief.md) 整理来源、复用资源及用户已有计划，在同一轮一次性确认尚未明确的 Fast / Plan、业务模块、页面与表单、导航归属及风格。导航 `ask_human` 仅提供“宜搭原生导航”和“自定义导航”两个选项，原生导航就是平台导航，并按 [导航选项说明](../../yida-requirement-analysis/workflow/prepare-brief.md#导航选项说明) 备注实现方式，不标记“推荐”。顶部、侧边、L 型等布局在用户所选归属内根据场景确定，不询问布局或样式；用户已明确的要求优先，后续阶段复用归属选择和布局依据。首次搭建在必要回答写回、`intake.confirmed=true` 后继续。
+调用 `yida-requirement-analysis`，按 [需求分析与首次搭建确认](../../yida-requirement-analysis/workflow/prepare-brief.md) 整理来源、复用资源及用户已有计划，在同一轮一次性确认尚未明确的 Fast / Plan、业务模块、页面与表单及风格。导航方式与布局按 [导航设计](../../yida-requirement-analysis/workflow/prepare-brief.md#导航设计) 确定；用户已明确要求优先，后续阶段复用判断和依据。首次搭建在必要回答与导航判断写回、`intake.confirmed=true` 后继续。
 
 回答齐全后直接保存内部需求记录并进入 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` 调整完成条件；跳过写操作时没有伪造已换肤、已修改源码或已发布；
 - [ ] 未把内部文件或每个业务资源分别交付；