openyida 2026.9.21 → 2026.9.22-beta.2

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

@@ -1,10 +1,10 @@
 # Step 4：生成交付产物并确认
 
-由 `yida-app` 校验业务/视觉输入、生成产物并确认当前版本。
+输入为业务与视觉片段，或已整理完成的 `build-plan.json`。本步骤由 `yida-app` 校验交接、一次生成文件并确认当前版本。
 
 ## 1. 校验业务与视觉交接
 
-核对范围、场景与设计引用；复用 init 的已确认视觉输入和 pageId/sceneKey。选择缺失、范围变化或特殊设计交给 [Plan 视觉分支](../../../yida-design/sub_skill/yida-design-plan/SKILL.md) 补齐，业务缺项交给 `yida-prd`。
+核对范围、场景和设计引用。标准首版复用 init 预填的已确认视觉输入，页面沿用确认时的 pageId 与 sceneKey；仅视觉选择不完整、页面范围变化或存在特殊视觉要求时由 [Plan 视觉分支](../../../yida-design/sub_skill/yida-design-plan/SKILL.md) 补齐受影响记录，业务缺项交给 `yida-prd` 修正。
 
 ## 2. 通过 CLI 生成产物
 
@@ -22,11 +22,13 @@ openyida design-plan materialize prd/<项目名>/build-plan.json \
 openyida design-plan materialize prd/<项目名>/build-plan.json --from-preview --json
 ```
 
-CLI 完整校验后一起保存源计划、`prd.md`、`design.md`、`build-plan.html` 和 `app-theme.css`。
+CLI 完整校验后一起保存源计划、`prd.md`、`design.md`、`build-plan.html` 和 `app-theme.css`。HTML 使用预置模板，业务内容与 PRD 一致。
 
-执行 init 返回的 `materialize.command`，使用其 `materialize.shell`：Windows 为 PowerShell，其他平台为 POSIX shell。成功结果的 `outputs.html` 用于展示方案，`revision` 仅用于内部确认绑定，不透出给用户。片段职责见 [完整文件合并](../parallel-work.md#plan-的-cli-交接)。直接维护源 JSON 时先设 status=awaiting_confirmation，再运行 `openyida design-plan materialize prd/<项目名>/build-plan.json --json`；诊断加 `--check --json`，正常生成不重复预检。
+标准首版必须直接执行 init 返回的 `materialize.command`；不得先试 `--from-preview`、`preview`、无参数 materialize 或 shell 重定向。成功 JSON 已包含 `outputs.html` 和 `revision`，直接用于下一步同一次结构化提问，不再 Glob 目录，也不额外 Read `prd.md`、`design.md` 或 `build-plan.json`。
 
-HTML 使用预置模板，保留需求总览、数据模型、业务流程、页面规划四章；整体视觉在总览、逐页视觉在详情，业务与 PRD 一致。见 [HTML 内容契约](../../../yida-design/sub_skill/yida-design-plan/assets/README.md#需求总览中的视觉信息)。
+完整文件的职责与版本规则见 [完整文件合并](../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 再重复生成。
+
+HTML 保留“需求总览、数据模型、业务流程、页面规划”四章，完整展示用户需要确认的业务、视觉、数据、顺序和验收内容；整体视觉放在需求总览，逐页视觉放在页面详情。展示范围见 [HTML 内容契约](../../../yida-design/sub_skill/yida-design-plan/assets/README.md#需求总览中的视觉信息)，Markdown 供 Agent 执行。
 
 校验失败时按返回的 `details.issues` 集中修正对应字段后重试。写入失败由 CLI 恢复旧文件；若恢复失败，保留报错给出的备份路径并处理恢复后再继续。
 
@@ -34,35 +36,21 @@ HTML 使用预置模板，保留需求总览、数据模型、业务流程、页
 
 按 [用户交互契约](../../../yida-design/references/ask-human-interaction-contract.md) 执行：
 
-1. 在会话中展示“当前方案”，并用 3–7 条业务摘要说明方案内容；有前后台时说明各入口导航归属，平台导航管理页只实现业务内容。导航随整体方案确认，不另设技术选型确认。
-2. 实际调用 `ask_human` 创建结构化提问。调用对象严格采用交互契约中的唯一 payload schema；`attachments` 携带 `name: "build-plan.html"`、`path: "prd/<项目名>/build-plan.html"`，`revision` 使用当前 `meta.revision`，`options` 固定为 `confirm_build` 和 `continue_editing`。一次成功调用同时建立方案展示、版本绑定和最终选择。
-最终确认直接使用如下顶层字段，不要再包装成 `fields` 问卷；`fields` 用于需求澄清或用户选择“继续调整”后的补充问题。
-
-```json
-{"question":"请确认当前搭建方案","options":[{"label":"确认并开始搭建","value":"confirm_build"},{"label":"继续调整","value":"continue_editing"}],"submitLabel":"提交选择","attachments":[{"name":"build-plan.html","path":"<outputs.html>"}],"revision":"<revision>"}
-```
-
-优先将本次 materialize 或 patch --materialize 返回的 `confirmation` 对象原样传给 ask_human，它已经绑定同调用附件、revision 和固定选项。旧 CLI 没有该字段时，才按上例用实际 `<outputs.html>` 和 `<revision>` 填写，禁止另造值或省略 options/attachments/revision。确认前不创建业务资源。
+1. 在会话中展示“当前这版方案”，并用 3–7 条业务摘要说明方案内容。
+2. 必须实际调用 `ask_human` 创建结构化提问，并通过同一次调用的 `attachments` 携带可打开的 `prd/<项目名>/build-plan.html`；附件对象固定使用 `name: "build-plan.html"`，并将 `revision` 设为当前 `meta.revision`。只输出方案正文或普通 assistant 文本后结束本轮属于未完成，严禁用它替代 `ask_human`；也不得改成项目标题，或先发普通文本附件、再单独提问。
+3. 结构化交互成功创建后内部记录 `presentedRevision=meta.revision`。询问“确认并开始搭建”或“继续调整”，提交时由宿主原样回传 revision，将确认结果绑定到本次展示版本。用户可见版本称为“第 N 版方案”，展示序号与内部 revision 绑定。
 
-3. 结构化交互成功创建后将 `meta.planState.presentedRevision=meta.revision` 写回源 JSON，仅保存展示事实，不重新物化。询问“确认并开始搭建”或“继续调整”，提交时由宿主原样回传 revision，将确认结果绑定到本次展示版本。用户可见标题、摘要、附件名称与确认问题统一使用“搭建方案”或“当前方案”，不展示修订序号。内部 revision、展示记录和确认失效机制照常维护。
-
-只有以下条件同时成立才交接；它们由本轮 ask_human 请求和回传在运行时判定，确认结果可保留在运行时，但展示版本必须写回源文件：
+只有以下条件同时成立才交接；它们由本轮 ask_human 请求和回传在运行时判定，不要求把确认状态写回 workspace 文件：
 
 - `meta.status=confirmed`
 - `meta.planState.planConfirmed=true`
 - `meta.revision=presentedRevision=confirmedRevision`
 
-收到 `confirm_build` 且回传 revision 与展示版本一致后，保存运行时确认并实施同版产物。按 `assetTasks` 派发素材任务、记录编号后继续创建资源和页面，见 [并行调度](../parallel-work.md#素材与页面同时推进)。素材进度沿用确认，业务/视觉变更按下节处理；`explicitScope.allowInferredResources=false` 只实施范围内资源，不改主题、应用设置或导航。
+收到“确认并开始搭建”且回传 revision 等于展示 revision 后，直接进入同版本资源实施。确认之后严禁再次 materialize、patch、Edit 或 Read 计划来“同步确认状态”；不存在可写 `meta.planState.planConfirmed` 的确认命令。`explicitScope.allowInferredResources=false` 时也不执行主题 CSS、应用设置或导航交接，只创建范围内资源并回读、交付。
 
 ## 4. 处理调整
 
-修改已有方案时，从当前 `build-plan.json` 继续，只读本次涉及的字段和相关章节。已有具体修改要求就直接处理；只有用户选择 `continue_editing` 却没有说明改什么时，才在下一次交互收集修改内容。
-
-1. 找到要改的源字段。业务内容由 `yida-prd` 维护，视觉内容由 `yida-design` 维护；只补读相关规则，不重走需求分析、主题选择或初始化。
-2. 将本轮变更合在一次 `patch --materialize` 中。只提交变化的字段；页面任务改变时，同步该页的视觉说明和必要引用。
-3. CLI 校验后更新 PRD、design、Plan HTML 和主题 CSS 的变化部分，保留其他内容；`updated` 返回实际改动的文件。同一次执行中，CLI 复用相同输入的主题结果和校验结果；合并了本地文档修改时仍重新检查。成功后直接用 `outputs.html` 展示修改摘要和当前方案，不再全文读取、重复生成或预检。
-
-例如，同时调整品牌色和圆角：
+按字段更新源事实并重新生成，例如同时调整品牌色和圆角：
 
 ```bash
 openyida design-plan patch prd/<项目名>/build-plan.json \
@@ -72,9 +60,7 @@ openyida design-plan patch prd/<项目名>/build-plan.json \
   --materialize --json
 ```
 
-首版从 1 开始，内部补全保持当前版；已展示方案实质变更升一版并清空确认，相同内容及素材进度不升版。可选字段与旧计划兼容规则见 [紧凑计划契约](../../../yida-design/sub_skill/yida-design-plan/references/build-plan-compact-schema.md#可选字段-patch-与完成校验)。
-
-`build-plan.json` 是 Plan 的修改入口。固定标题和排版交给 CLI，不重写整份 `business.json`、`visual.json`、HTML 或 MD。主题文件使用 `outputs.theme` 的实际路径；已有 CSS 中的自定义样式会保留。CLI 自动维护同目录的 `.build-plan-artifacts.json` 作为上次生成记录，不手动修改它。若返回内容冲突，只读取报错文件的对应部分，将本地修改与源事实对齐后重试，不能删除记录或覆盖整份文件绕过冲突。
+CLI 支持首次添加契约允许的可选字段，自动递增 revision、使旧确认失效，并同步源 JSON 与派生产物。字段限制见 [紧凑计划契约](../../../yida-design/sub_skill/yida-design-plan/references/build-plan-compact-schema.md#可选字段-patch-与完成校验)。
 
 | 调整内容 | 负责技能与传播范围 |
 | --- | --- |
@@ -82,4 +68,4 @@ openyida design-plan patch prd/<项目名>/build-plan.json \
 | 页面核心任务、区块或首屏 | `yida-prd` 更新页面，随后 `yida-design` 同步视觉应用 |
 | 主题、品牌色、圆角或阴影 | `yida-design` 更新视觉事实，保持业务范围、页面任务和操作优先级 |
 
-业务方案或视觉方案调整后重新展示并确认当前版本。素材到位、替换同用途图片或更新缺图状态属于实施进度，按 [素材交接](../../../yida-image-assets/SKILL.md#6-交给页面使用) 更新后直接继续。
+每次调整后重新展示并确认当前版本。

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

@@ -2,42 +2,30 @@
 
 由 `yida-app` 在需求确认完成且选择 Plan 后进入。需求与选择明确后并行准备业务和视觉事实，统一生成产物；确认当前方案后进入资源创建。
 
-已有方案需要修改时，直接执行 [局部调整](step-4-deliver.md#4-处理调整)，不重走下面的首版流程。
-
-## 中断恢复与文件缺失
-
-已有方案的继续、调整或确认，先沿用原 `build-plan.json`，通过 patch/materialize 延续其 revision；`init` 仅用于新方案，不能把原文件读取失败当作首次规划。
-
-原文件不存在时，先使用当前运行环境提供的工作区恢复或用户可访问的原方案附件，确认内容和 revision 后继续。不要读取 runtime-internal 路径，不要靠改目录名、反复 init 或手填 revision 伪造恢复成功。
-
-确实无法恢复原方案时，告知用户“原方案文件无法恢复，需要根据已确认需求重建”，请求确认后才能新建；保留已确认需求，不从头重复需求采集。重建产生独立方案，明确标为“重建方案（第 1 版）”，用新的最终确认调用展示，原确认不再适用于新文件。只有用户确认本次重建方案后才能实施；不能将旧确认或旧附件视为新方案已获确认。
-
 ## 当前待办名称
 
 - 规划功能、页面和配色：设计功能和页面
-- 生成方案并等待用户确认：确认搭建方案
-- 方案确认后：读取同一 revision 的 `execution.explicitScope`，为其中非空的资源集合生成对应实施步骤，最后增加“检查范围并交付”
-- `allowInferredResources=true` 的完整应用：按 `yida-app` 完整应用模版生成后续步骤
-- `allowInferredResources=false` 的闭合范围：后续步骤总集等于确认方案中的资源步骤与交付步骤；每完成并回读一个资源，就从内部剩余集合中移除，用户待办保留并标记完成
+- 生成方案并等待用户确认：生成PRD方案&确认
+- 新建应用确认后：创建应用 → 搭建表单与审批流 → 准备示例数据 → 搭建业务页面 → 发布页面与配置导航 → 检查功能并交付
+- 已有应用确认后：搭建表单与审批流 → 准备示例数据 → 搭建业务页面 → 发布页面与配置导航 → 检查功能并交付
 
 沿用已有待办，不把下面的内部执行顺序另建成一份任务列表。
 
 ## 执行顺序
 
-1. 直接复用已确认的 `requirement-brief.json`；若尚未完成 Step 2 的规划准备，先按 [交接契约](../../../yida-requirement-analysis/references/handoff.md#规划阶段补齐) 补齐页面承载、导航与主题，AI 建议保留来源，不重新询问业务或导航；本文件已经包含规划入口，不再额外读取 `step-1-understand.md` 或 `step-2-confirm.md`。
-2. 用户未给出明确完整视觉风格时，先执行 [Plan 视觉分支](../../../yida-design/sub_skill/yida-design-plan/SKILL.md)：按 Fast / Plan 共用规则生成恰好三套候选，并通过 `ask_human` 获得用户选择。不得因用户未主动要求比较而跳过。获得选择或已有明确完整风格后，再继续主题映射和初始化。
-3. 主题映射未确定时，执行一次 `openyida design-plan catalog --json`，从返回的 `themes` 选择 themeId，并复用 `pagePatterns`。已有合法主题 ID 时直接初始化。初始化计划草稿，CLI 返回编写契约与当前主题的精简上下文：
+1. 直接复用已确认的 `requirement-brief.json`；本文件已经包含规划入口，不再额外读取 `step-1-understand.md` 或 `step-2-confirm.md`。
+2. 初始化计划草稿，CLI 返回编写契约与当前主题的精简上下文：
 
    ```bash
    openyida design-plan init .cache/openyida/<项目名>/requirement-brief.json --theme-id <已选主题> --json
    ```
    `requirement-brief.json` 必须复用 `yida-requirement-analysis` 的输出结构，不要自行发明字段层级；`projectName` 位于 JSON 根级，`businessGoals` 等集合字段保持数组，命令第一次就传入 `visualSelection.themeId`。若 CLI 返回字段路径诊断，按 `expectedPath` 集中修正原文件后最多重试一次，不要通过反复更换项目名规避结构错误。
 
-4. 按 init 返回的 `parallelTasks` 和 `dependsOn` 完成待补内容。CLI 预填业务骨架与已选主题；自定义页仍须补齐焦点、布局、主操作、响应式和验收，写入 `visual.json`。业务页面确定后完成视觉任务，可在同一轮中顺序填写两个文件。纯原生资源且两个片段均已就绪时，直接生成方案。
-5. init 已创建并预填 `business.json` 骨架；读取该文件及 `context` 中的类型示例，按 `authoring.pendingFields` 的文件和字段路径补齐内容，保留 `base` 与已有事实。复核需求覆盖后，将已完成片段设为 `ready=true`。`business.json` 的 facts 填写 overview、dataModels、businessFlows、pages 和可选 execution；`visual.json` 的 facts 填写 visualStyle。同一次补齐所有普通表单的 sampleDataPlan（窄范围不造数时写 skipReason）及所有自定义页面的 permissionSummary，然后直接执行 init 返回的 `materialize.command`，只物化一次。标准首版禁止先试 `--from-preview`、`preview`、`--check` 或无参数 materialize；成功 JSON 已返回 HTML 路径和 revision，不再用 Glob、Read 或帮助命令检查产物。只有存在品牌稿、参考图、页面级特殊风格或用户明确要求精修时，才执行 `optionalTasks.visual-refinement` 后再物化。
-6. 读取精确路径 `workflow/plan/step-4-deliver.md`，按其中契约直接展示并确认当前方案。超大需求需要展示中间进展或用户明确要求边生成边查看时，才使用 [按模块更新方案](../incremental-preview.md)；普通首版不逐模块预览和重复渲染。
+3. 执行 init 返回的 `parallelTasks`：普通标准首版只有一个业务规划任务；显式窄范围且表单字段已完整时，CLI 返回 `preparedInputs.businessReady=true` 和空任务列表，直接进入第 4 步，不再 Read/Edit business 或补规划。视觉方向、主题色和导航样式已在需求阶段确定，CLI 将其预填到 `preparedInputs.visual`，并从主题模板确定性补齐页面标准视觉，不再启动“基础视觉 → 等待页面 → 逐页视觉绑定”两段模型任务。
+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` 作为完整执行清单。确认后的每个写操作都对应清单中的一个资源或交付项；清单资源全部回读且真实链接完成交付时，本轮达到完成态。
+明确窄交付时，方案只描述 `explicitScope` 中的资源；确认后裁剪无关步骤，在这些资源回读并交付真实链接后停止。不得因用户使用“应用”一词自行增加 seed records、自定义页面、主题或导航工作。
 
 初次编写只读 CLI 返回的紧凑契约、当前主题上下文及共享需求；模板全文由 CLI 读取。具体组件定制、暗色浮层或复杂页面需要额外规则时，再读取对应章节。
 
@@ -55,12 +43,6 @@ build-plan.json（业务和视觉的源事实）
   └─ app-theme.css（应用主题）
 ```
 
-草稿按已确定的模块更新，最终校验后统一保存三份文档和主题 CSS。后续业务或视觉调整按 [局部调整](step-4-deliver.md#4-处理调整) 更新并确认；素材进度同步沿用已有确认。
-
-用户交互按 [可见表达契约](../../../yida-design/references/ask-human-interaction-contract.md) 执行。当前展示版本确认后，先按物化返回的 `assetTasks` 启动素材任务，再将 `prd.md`、`design.md` 和 `outputs.theme` 交给主流程 Step 3；搜索与创建应用同时推进。仅完整应用同步主题设置；`explicitScope.allowInferredResources=false` 时忽略主题和导航交接，只创建范围内资源并交付，不重复物化计划。
-
-## 加载失败与内容修复
-
-技能加载失败、限流或换模型后，先成功读取本工作流和当前步骤，再沿用已确认需求继续；未加载成功不得凭记忆生成 HTML 或确认参数。首次物化前只修 business.json/visual.json 对应 facts（菜单与执行规划在 business.facts.execution），不要直接修初始化主计划。字段错误按具体路径修正后重试。
+草稿按已确定的模块更新，最终校验后统一保存三份文档和主题 CSS。调整由对应技能更新源事实，再由编排重新生成并确认，具体命令与版本条件见 [生成与确认](step-4-deliver.md)。
 
-如果已经改动主计划并出现 DESIGN_PLAN_STALE_PART，在原 materialize 命令增加 --rebase-parts。CLI 使用 init 保存的 .build-plan-base.json 做三方核对，保留已完成 facts；冲突按 details.conflicts 明确选择后重试。基线缺失或无法核实时告知阻塞并恢复可信文件，不手填 digest、不删除重建、不重新 init。已物化后调整走 patch --materialize，不继续复用初始化片段。
+用户交互按 [可见表达契约](../../../yida-design/references/ask-human-interaction-contract.md) 执行。当前展示版本确认后，将 `prd.md`、`design.md` 和已生成的 `outputs.theme` 交给应用主流程 Step 3。仅完整应用同步主题设置；`explicitScope.allowInferredResources=false` 时忽略主题和导航交接，只创建范围内资源并交付，不重复物化计划。

package/yida-skills/skills/yida-app/workflow/step-1-resource-context.md

@@ -1,14 +1,12 @@
 # Step 1：解析资源上下文
 
-首轮需求澄清前只沿用用户显式资源引用及已有上下文，先进入 Step 2 的 2.0；不预检环境、不登录、不扫描配置或批量查询资源。已有应用的需求材料确实影响核心功能候选时，只读提问所需内容。
-
-需求澄清完成后，或已有需求足够明确而无需提问时，再按本节确认本轮要操作哪个 app/page/form/process，决定复用、补齐还是创建。不要把 `create-app`、`create-page`、`create-form` 当成默认动作。
+先确认本轮要操作哪个 app/page/form/process，再决定复用、补齐还是创建。不要把 `create-app`、`create-page`、`create-form` 当成默认动作。
 
 ## 只读预检
 
 若根入口已经完成只读预检，沿用结果，不要每个阶段重复跑 env/help/login。
 
-若还没有预检，优先跑一次 `openyida agent-capabilities --summary-json`，将完整 JSON 保存到本轮上下文，按需从同一结果提取字段；组织、登录态或工作目录变化后刷新对应信息。旧版本没有该命令时，退回 `openyida env --json` 和 `openyida login --check-only --json`。只有登录态可用后，才执行会创建、修改或发布宜搭资源的命令。
+若还没有预检，优先跑一次 `openyida agent-capabilities --summary-json`；旧版本没有该命令时，退回 `openyida env --json` 和 `openyida login --check-only --json`。只有登录态可用后，才执行会创建、修改或发布宜搭资源的命令。
 
 ## 资源解析顺序
 

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

@@ -4,38 +4,24 @@
 
 - 需求识别与分析
 - 设计功能和页面
-- 确认搭建方案（仅 Plan）
+- 生成PRD方案&确认（仅 Plan）
 
 ## 2.0 先分析并确认需求
 
-调用 `yida-requirement-analysis`，按 [首轮需求分析](../../yida-requirement-analysis/workflow/prepare-brief.md) 读取必需来源，尽早确认核心功能和关键用法。该技能统一负责提问、答案合并和需求记录；完成后进入规划准备。
+调用 `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` 后继续。
 
-取得 `intake.confirmed=true` 的 brief 后进入规划准备；已有确认记录且需求未变化时直接复用。
+回答齐全后直接保存内部需求记录并进入 2.1；不把“生成需求简报”列为独立任务，不再扩写或展示简报请用户确认。已有确认记录且需求未变化时直接复用。记录粒度、保存和校验规则统一遵守上述需求分析流程。
 
-### 规划准备
-
-澄清结束后，完成以下准备；字段格式按 [交接契约](../../yida-requirement-analysis/references/handoff.md#规划阶段补齐) 写回同一份 brief：
-
-1. 按 Step 1 核验确实需要的资源上下文，保留用户显式目标；纯需求/方案讨论不要求登录，不执行资源写操作。
-2. 按 [模式路由](../../yida-design/references/design-mode.md) 确定执行方式，沿用用户最后一次明确选择。
-3. AI 根据有效功能、`userTasks` 与 `entryRecommendation`，按 [导航决策](../../yida-design/references/navigation-decision.md) 规划各入口的页面和菜单，补齐稳定 `pageScenes` 与主题映射。新增建议标记来源，范围遵守 explicitScope。
-
-Fast / Plan 的主题与配色统一按[设计方向比较](../../yida-design/references/theme-selection.md#设计方向比较)在本轮规划中选定，结果写回 brief，后续直接复用。两种模式使用同一组三方向生成规则：Fast 内部选一套；Plan 在用户未给出明确完整风格时，先由 `yida-design-plan` 生成恰好三套候选并调用 `ask_human`，获得选择后才能继续 Plan 初始化。
-
-进入 2.1 前校验规划字段完整性和 `intake.designMode`。页面、导航、主题等建议随整体搭建方案展示。
+显式搭建方式属于本次任务的粘性输入。若用户在首次消息已选择 Plan，澄清业务模块、页面、导航或风格时不得再次询问模式，也不得在合并回答后改写为 Fast；进入 2.1 前必须以用户最后一次明确选择校验 `intake.designMode`。Fast 同理。
 
 执行规划前读取 `constraints.prohibitedActions`。PRD 与 design 必须把禁止项写成实现门禁：`theme-file` 禁止时沿用现有平台主题且不安排主题文件任务；`page-source` 禁止时只允许只读核查与非源码配置；`publish` 禁止时把发布明确标记为跳过。不得为了满足默认九步流程静默删除这些约束。
 
-按 [访问态入口契约](../references/entry-navigation.md) 为每个入口补齐角色、默认任务、菜单、资源/视图/操作权限。Fast PRD 与 Plan execution.entryRecommendation 共用契约；管理端按 [首页按任务选择](../../yida-requirement-analysis/references/experience-groups.md#首页按任务选择) 确定默认任务；需要汇集办事入口时设计业务工作台，无汇总价值时直接进入业务页。
-
-前台和后台都按 [首页与菜单顺序](../references/entry-navigation.md#每个入口都确定首页与菜单顺序) 确定默认页面、菜单及分组顺序、打开后的首屏任务。顺序写入各入口 `menu`，默认页写入 `defaultMenuKey`；不沿用资源创建顺序，不把前台首页自动放进后台，也不将自定义导航视为无需排序。
-
 ## 2.1 按已确认方式推进
 
 按 [模式路由](../../yida-design/references/design-mode.md) 读取本次选择：
 
 - Fast：继续 2.2–2.3；已有详细需求直接作为规划基础。
-- Plan：执行 [Plan 编排](plan/workflow.md)，用户确认当前方案后，按返回的 `assetTasks` 启动素材任务，同时进入 Step 3 创建应用。
+- Plan：执行 [Plan 编排](plan/workflow.md)，用户确认当前方案后完成主题交接并进入 Step 3。
 
 Plan 分支从已加载 `yida-app` 的 Available Files 读取精确路径 `workflow/plan/workflow.md`；不要把当前文件名当目录拼成 `workflow/step-2-design/plan/workflow.md`，也不要用 Glob 猜路径。
 
@@ -48,13 +34,13 @@ Plan 分支从已加载 `yida-app` 的 Available Files 读取精确路径 `workf
 | 内容 | 负责技能 | 输出 | 完成条件 |
 | --- | --- | --- | --- |
 | Product PRD | `yida-prd` | `prd/<项目名>/prd.md` | 资源蓝图、资源创建顺序、页面实现交付顺序、导航顺序、页面 handoff 和验收标准完整 |
-| Visual Design | `yida-design` | `prd/<项目名>/design.md` | 导航、应用框架、表单、详情与自定义页面共用完整主题 token；布局、材质、形状、密度、组件、状态、响应式和页面场景引用完整 |
+| Visual Design | `yida-design` | `prd/<项目名>/design.md` | 主题 token、视觉 DNA、布局、材质、圆角、密度、组件、状态、响应式和页面场景引用完整 |
 
 两个技能读取同一份已确认需求，业务规划与基础视觉同时准备；页面任务、区块和 sceneKey 确定后补齐逐页视觉绑定。各自维护职责内的文件。某一份生成失败时只重跑对应技能，不覆盖已经完成的另一份。
 
 ## 2.3 校验两份结果
 
-`yida-app` 必须等待两个文件都生成完成，再执行 `openyida check-design prd/<项目名>/design.md --prd prd/<项目名>/prd.md --json`。Fast 的设计步骤先完成单文件检查，合并时补上述关联检查；Plan 物化内部调用同一校验。检查：
+`yida-app` 必须等待两个文件都生成完成，再执行一致性校验：
 
 - 两个文件路径存在且非空；
 - PRD 每个 display 页面的 `designFile` 指向当前 `design.md`；
@@ -72,11 +58,11 @@ Plan 分支从已加载 `yida-app` 的 Available Files 读取精确路径 `workf
 - 门户、工作台、档案、知识库和引导页有图片槽位时为 `beneficial`；
 - 表单、审批、台账、设置和库存流水默认 `none`。
 
-Fast 设计就绪后按 [素材调度](parallel-work.md#素材与页面同时推进) 派发 `yida-image-assets` 后台任务，记录任务编号后主流程继续创建应用、表单和页面，有图页面先做布局、数据绑定和交互。Plan 在方案确认后启动同一流程。各页及同页各图片位置并发搜索，每个位置一张、最多两轮。每页草稿就绪即执行 `asset resolve --design design.md --page-id <pageId>`；允许外链的图片直接交付，上传时追加 `--app-type <真实appType>`，写入独立清单；页面按自身状态接图并验收。
+存在 `required` 或带槽位的 `beneficial` 时启动 `yida-image-assets`，先选图并保存 `prd/<项目名>/manifest-draft.json`。宜搭附件上传需要真实 `appType`；已有应用可直接上传，否则等 Step 3 创建应用后再落地，不因缺少 appType 阻塞应用创建。素材只阻塞使用它的页面；Step 7 通过 `--design design.md --app-type <真实appType>` 上传并校验，以输出清单的页面级状态判断能否继续。
 
 ## 主题文件实现指令
 
-在设计中同时确定导航、应用框架、表单、详情与自定义页面的整体风格。命名模板提供完整导航 token 与派生的导航明暗，自由创意明确填写；布局沿用业务规划。未禁止 `theme-file` 时，Plan 使用 CLI 返回的 `outputs.theme`，Fast 按 [主题文件生成与更新](../../yida-design/workflow/output-design.md#cli-token-契约fast--plan-共用) 准备主题 CSS；用户确认计划或主题后即可启动 CSS 生成，不等待表单或页面开发。Plan 已生成当前版本的 CSS 时直接复用。拿到真实 appType 后，在应用级配置同一份主题文件，与表单创建和页面开发并行；页面组件按已确认契约消费主题 token。若 `theme-file` 被禁止，跳过生成、复制、修改和上传，沿用现有平台主题并在交付中说明未更改主题。详见 [主题与业务资源的依赖](parallel-work.md#主题与业务资源的依赖)。
+在设计中确定配色、导航明暗和布局。未禁止 `theme-file` 时，Plan 使用 CLI 返回的 `outputs.theme`，Fast 按 [主题文件生成与更新](../../yida-design/workflow/output-design.md#cli-token-契约fast--plan-共用) 准备主题 CSS；用户确认计划或主题后即可启动 CSS 生成，不等待表单或页面开发。Plan 已生成当前版本的 CSS 时直接复用。拿到真实 appType 后，在应用级配置同一份主题文件，与表单创建和页面开发并行；页面组件按已确认契约消费主题 token。若 `theme-file` 被禁止，跳过生成、复制、修改和上传，沿用现有平台主题并在交付中说明未更改主题。详见 [主题与业务资源的依赖](parallel-work.md#主题与业务资源的依赖)。
 
 ## 产出
 

package/yida-skills/skills/yida-app/workflow/step-3-create-or-reuse-app.md

@@ -42,11 +42,9 @@
 
 按 PRD 的 [导航类型](../../yida-prd/workflow/output-prd.md#agent-导航实施映射) 设置布局。已有应用切换平台导航时执行 `openyida update-app <appType> --layout <l_shape|top|side> --show-app-nav`；自定义导航执行 `openyida update-app <appType> --hide-app-nav`，并将逐页隐藏清单交给 Step 4 与 Step 6，在各页面创建后立即配置，Step 8 只做发布后核对。新建应用也在主题文件生成后的同一次 `update-app --theme-file` 中传入布局和 `--hide-app-nav` / `--show-app-nav`，不要提前单独更新导航或在创建时传入布局。用户已确认的应用导航隐藏随这次设置更新一起生效，不等待自定义页面创建、代码开发或发布。
 
-当前步骤只读取应用工作区的 `execution.appConfig.navigationType`。独立前台页面的 `pageSpecHandoff.navigation.type=custom` 不代表应用级 custom；不得据此前台菜单传入 `--hide-app-nav`。前台自定义、后台平台导航时，应用保持 `--show-app-nav`，页面在 Step 6 单独配置。
-
 ### 平台导航参数
 
-`updateApp.json` 接收的布局字段名是 **`layoutDirection`**。CLI 使用 `--layout` 传入，按下表逐项对应：
+与 `yida-next` 的 ThemeNavSetting 一致：`updateApp.json` 接收的字段名是 **`layoutDirection`**。CLI 使用 `--layout` 传入，按下表逐项对应：
 
 | PRD 导航方案 | CLI 参数 | 请求中的 `layoutDirection` | 请求中的 `hideAppNav` |
 | --- | --- | --- | --- |
@@ -56,13 +54,13 @@
 
 例如，仅将已有应用切换为平台顶部导航：`openyida update-app <appType> --layout top --show-app-nav`。联合更新主题时，将这两个参数合并到同一次 `update-app --theme-file` 调用。
 
-Agent 必须显式传入场景选择对应的布局，不依赖 CLI 默认值。`navigationType=platform-top` 是计划内部标识，不能作为 `--layout` 的值；也不能用旧 Shell 的 `navType`、`hoz/ver/slide` 或 `top_fold/top_side/side_only` 代替上述参数。`navTheme` 选择导航明暗模式，完整导航 token 决定实际配色、边界、形状、文字和间距；圆角、三种状态边框和选中阴影先写入设计，再按 [命令与参数](../../yida-design/references/application-style-library.md#命令与参数) 重新生成 CSS 并上传；布局仍由 `--layout` 设置。自定义导航的 `variant=top/side/mixed/dock` 描述页面内菜单，不用于设置平台布局；自定义导航仍使用 `--hide-app-nav`。
+Agent 必须显式传入场景选择对应的布局，不依赖 CLI 默认值。`navigationType=platform-top` 是计划内部标识，不能作为 `--layout` 的值；也不能用旧 Shell 的 `navType`、`hoz/ver/slide` 或 `top_fold/top_side/side_only` 代替上述参数。`navTheme` 只控制导航配色，不控制布局。自定义导航的 `variant=top/side/mixed/dock` 描述页面内菜单，不用于设置平台布局；自定义导航仍使用 `--hide-app-nav`。
 
-`navType` 是兼容字段：CLI 查询应用后将已有值原样带回；缺失时不补造，也不根据新布局改写。没有 `--nav-type` 参数。未传 `--layout` 时，CLI 保留原布局：现代 `side/top/l_shape` 优先；旧 `hoz + top_side` 为 L 型，其他 `hoz` 为顶部，`ver` 为侧边；布局缺失时用 `navType=top_fold/top_side` 分别恢复顶部/L 型，其余回退侧边。
+`navType` 仍是兼容字段：与 `yida-next` 一致，CLI 查询应用后将已有值原样带回；缺失时不补造，也不根据新布局改写。没有新增 `--nav-type` 参数。未传 `--layout` 时，CLI 按 `yc-utils` 的应用配置规则保留原布局：现代 `side/top/l_shape` 优先；旧 `hoz + top_side` 为 L 型，其他 `hoz` 为顶部，`ver` 为侧边；布局缺失时用 `navType=top_fold/top_side` 分别恢复顶部/L 型，其余回退侧边。
 
 Shell 渲染阶段才把顶部、侧边、L 型转换为 `top_fold`、`side_only`、`top_side`。详情/提交页的 `top_fold` 强制顶部、`none` 保持无导航属于页面运行态规则，不能反向写入应用配置。
 
-保存后读取 CLI 的 `navigationVerification`：`verified=true` 且其中本次请求的 `navTheme`、`layoutDirection`、`hideAppNav`、`logoSource` 与目标一致，表示导航设置回读通过。旧布局字段由 CLI 归一化后比较；缺少回读证据时保持未验证。CLI 最多重试三次只读查询，失败返回 `APP_NAVIGATION_NOT_PERSISTED`，按返回的期望值、实际值和查询错误核实应用设置。`updatedFields` 仍是提交值，`themeVerification` 仍只验证主题资源。发布后刷新应用，检查实际导航、内容布局与状态；设置回读通过与页面视觉验收分别记录。
+保存后核对应用详情中的 `layoutDirection` 与 `hideAppNav` 是否等于目标值，可通过应用设置页或 `/<appType>/query/app/getAppIncludingAecpInfo.json` 回读。CLI 输出的 `updatedFields` 是提交值，`themeVerification` 只验证主题资源，两者都不能单独证明导航配置已生效。发布后再刷新应用，检查实际布局；未完成回读时明确标记未验证。
 
 ## 产出
 

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`。成功结果中的 `url`/`formUrl` 是表单入口，`appUrl` 是应用工作台入口。将该表单标记为已完成并计算 `remainingScope`；为空时按用户要求的入口层级交付并完成本轮范围。普通表单保存成功后进入可用状态，自定义展示页遵循页面发布生命周期；验收证据缺失时执行一次针对性只读回查。
+`explicitScope.allowInferredResources=false` 且本轮只有一个普通表单时走最短路径：Write 一份字段文件后调用一次 `openyida create-form create`。Write 会创建父目录，禁止先用 `ls` 或 Bash 检查缓存目录。成功结果已包含真实 formUuid/链接时，直接交付并停止；不得继续 `get-schema`、写 schema evidence、加载数据管理技能、造示例数据、更新主题或排序导航。只有创建结果缺少本次明确验收所需字段时才做一次针对性回读。
 
 拿到真实 `appType` 和已确认的业务契约即可开始本步骤，不等待主题 CSS 上传或应用主题设置回读。主题分支与本步骤并行，按 [主题与业务资源的依赖](parallel-work.md#主题与业务资源的依赖) 汇合。
 
@@ -71,15 +71,9 @@
 }
 ```
 
-## 业务权限配置
-
-资源 ID 就绪后，按 [访问态入口契约](../references/entry-navigation.md#权限实施) 将菜单 access 和业务角色映射到真实权限。执行 yida-form-permission 的查询、差异、保存与回读流程，保留非目标配置。FORM_PACKAGE_START、视图绑定和页面白名单等未支持项单独记录能力缺口；不得用 app-permission 管理员授权或导航隐藏替代。权限未核验的入口不能宣称业务可用。
-
 ## 页面导航配置
 
-只有 PRD 的应用工作区导航 `execution.appConfig.navigationType=custom` 时，对本轮创建或复用的每个表单、流程表单及其他业务页面，按 [导航壳必做配置](../../yida-nav-shell/SKILL.md#必做配置) 调用 `update-form-config` 并回读 `renderNav=false`。以 PRD 清单及真实 formUuid 逐项记录结果。
-
-仅前台页面自定义菜单时，不修改这些后台表单、流程或报表的导航；共用数据不等于共用页面显示设置。
+PRD 导航类型为自定义导航时，对本轮创建或复用的每个表单、流程表单及其他业务页面，按 [导航壳必做配置](../../yida-nav-shell/SKILL.md#必做配置) 调用 `update-form-config` 并回读 `isRenderNav=false`。以 PRD 清单及真实 formUuid 逐项记录结果。
 
 ## 产出
 
@@ -90,16 +84,11 @@
 
 ## Checklist
 
-- [ ] 字段结构有 Divider 分组；按各表单用途显式选择 `dividerType`，同页同层级尽量一致，不同业务页面优先使用不同且合适的类型，具体外观见 [Divider 选型表](../../yida-create-form-page/references/form-field-properties.md#divider)；
+- [ ] 字段结构有 Divider 分组；
 - [ ] 表单/流程资源在自定义页面之前创建或确认；
 - [ ] 必要 `fieldId` 已写入 `.cache/<项目名>-schema.json`；
 - [ ] 表单 Schema 只包含字段、布局和业务动作。
 
-`remainingScope` 是 Agent 运行时维护的剩余任务集合，依据已确认范围和成功结果更新。
-
 ## 下一步
 
-- `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)
-- 其他资源：继续执行本步骤中与该资源类型对应的能力，直到资源集合完成
+→ [Step 5：写入初始表单数据](step-5-seed-records.md)

package/yida-skills/skills/yida-app/workflow/step-6-main-page.md

@@ -1,6 +1,6 @@
 # Step 6：创建或复用主页面
 
-按 [访问态入口契约](../references/entry-navigation.md) 创建或复用 PRD 明确需要的 display 页面。管理端可以直接使用原生管理列表，无首页需求时跳过本步骤和无源码任务的 Step 7，不为凑齐流程创建首页。
+确定完整应用的主入口 display 页面。已有主页面直接复用；缺少主页面且允许创建时才创建。
 
 ## 输入
 
@@ -12,15 +12,13 @@
 ## 操作
 
 1. 已有页面 URL、`formUuid` 或已绑定 display 页面 → 直接作为主页面，不执行 `use_skill("yida-create-page")`。
-2. PRD 明确需要自定义业务页面、该页缺失，且 Step 1 允许创建 → 执行 `use_skill("yida-create-page", "创建主入口自定义页面")`。
+2. 缺少首页、工作台、智能助手或门户门面，且 Step 1 允许创建 → 执行 `use_skill("yida-create-page", "创建主入口自定义页面")`。
 3. 创建页面前核对 PRD/resource context 与 auth snapshot 的 `corpId`。
 4. `corpId` 不一致 → 先确认重新登录到目标组织，或确认在当前组织继续。
 5. 创建 display 页面后记录真实主页面 `formUuid`。
-6. PRD 的应用工作区采用自定义导航，或该页已确定 `entryMode=standalone` / 页面隐藏导航时，取得真实 `formUuid` 后立即执行 `openyida update-form-config <appType> <formUuid> false "<页面标题>"` 并 `get-form-config --json` 回读 `renderNav=false`；已有页面按同样规则处理，`create-page --hide-nav` 已配置成功时直接回读即可。该任务与 Step 7 的源码开发并行，不等待代码或发布完成。
+6. PRD 采用自定义导航，或该页已确定 `entryMode=standalone` / 页面隐藏导航时，取得真实 `formUuid` 后立即执行 `openyida update-form-config <appType> <formUuid> false "<页面标题>"` 并 `get-form-config --json` 回读 `isRenderNav=false`；已有页面按同样规则处理，`create-page --hide-nav` 已配置成功时直接回读即可。该任务与 Step 7 的源码开发并行，不等待代码或发布完成。
 7. 将页面导航配置结果交给 Step 8 做发布后核对。其余自定义页面同样在各自创建/复用成功后配置，不只处理主页面。
 
-同一 sceneKey 的前台业务视图共用一个自定义页面；将全部视图交给 Step 7 实现。
-
 ## 产出
 
 - 主页面 display `formUuid`；
@@ -30,7 +28,7 @@
 ## Checklist
 
 - [ ] 已确认不会重复创建主页面；
-- [ ] 已拿到本轮需要的真实 display `formUuid`；无需自定义页面时已记录跳过；
+- [ ] 已拿到真实 display `formUuid`；
 - [ ] 创建或发布前已核对 `corpId`；
 - [ ] `corpId` 不一致时已等待用户确认。
 

package/yida-skills/skills/yida-app/workflow/step-7-page-code.md

@@ -2,12 +2,10 @@
 
 按 `prd.md` 和 `design.md` 实现页面。页面源码通过本地校验只表示“可发布”，不表示远端页面已更新。
 
-页面开发消费已确认的设计与 token 契约，不等待主题文件上传或页面导航配置请求。页面创建/复用取得 formUuid 后，仅已规划独立展示或应用级自绘导航的页面执行导航隐藏并回读；平台导航管理页保留导航。配置与本步骤并行。主题任务应在 CSS 和 appType 就绪时立即更新应用设置；视觉验收前核对其回读结果，不在本步骤结束后才启动主题更新。
+页面开发消费已确认的设计与 token 契约，不等待主题文件上传或页面导航配置请求。页面创建/复用取得 formUuid 后，页面导航隐藏应由独立配置任务立即执行并回读，与本步骤并行。主题任务应在 CSS 和 appType 就绪时立即更新应用设置；视觉验收前核对其回读结果，不在本步骤结束后才启动主题更新。
 
 无直接依赖的页面按 [页面并行规则](parallel-work.md#页面按实际依赖并行) 同时开发，每页只等待自身需要的资源，不按导航顺序串行。共享主题或同一已就绪表单不构成页面间依赖；当前页就绪即可进入发布步骤，导航排序等待全部页面完成。
 
-独立前台只实现本入口的菜单与任务，多视图共用同一页面时按状态或 hash 切换。普通表单新增、填写提交和详情按第 9 条接入提供的 iframe 抽屉模板；全码前台也不另写一套填写与提交 API 逻辑。已有计划若写成自绘普通提交表单，先局部对齐交互描述，保留业务字段、权限与结果刷新。后台按自己的任务和导航实现，不被前台菜单影响。平台导航下的自定义后台默认只写业务内容，不渲染整份管理菜单；跨模块用平台菜单，同任务分类才用页内 Tab。派发任务时传递该页 `navigationPolicy` 与 `pageSpecHandoff`，Fast 也明确同样边界，详见[管理页面边界](../../yida-canvas-custom-page/references/navigation-and-entry-guide.md#平台导航下的管理页面)。
-
 ## 输入
 
 - `prd/<项目名>/prd.md`；
@@ -15,27 +13,25 @@
 - 真实 `appType`、当前页面 `formUuid`；
 - `.cache/<项目名>-schema.json`；
 - Step 5 写入的 seed records 或跳过原因。
-- 需要图片时读取 `prd/<项目名>/asset-manifests/<pageId>.json`；已有总清单按 pageId 读取。
+- 需要图片时读取 `prd/<项目名>/asset-manifest.json`。
 
 ## 操作
 
-**先接通主题与动作**：给页面实现者传入真实资源映射（appType、目标类型、formUuid/navUuid；详情另带 formInstId 的数据来源）。含 antd 控件先提取并合并 `canvas-theme`；跨页入口先提取 `canvas-navigation`，按 [动作与目标清单](../../yida-canvas-custom-page/references/navigation-and-entry-guide.md#先建立动作与目标清单) 实现。页面内 Tab 使用状态，不拼平台路由；暂缺资源的动作禁用，独立页面布局继续开发。完成后逐项核对 Tab/按钮/链接各交互状态的主题色及最终地址，不把编译通过当作换肤或跳转验收。
-
 **编码前置条件（MUST）**：新建 Canvas 页面或调整视觉时，执行页面开发的模型必须先完整读取 [canvas-style-implementation-guide.md](../../yida-canvas-custom-page/references/canvas-style-implementation-guide.md)，按 [编码前必读](../../yida-canvas-custom-page/SKILL.md#编码前必读must) 记录适用规则与落点，再写源码。派发页面任务时必须带上这个文件路径和读取要求；不能只传递设计摘要或认为主流程读过就等于页面实现者读过。
 
 先读取 `constraints.prohibitedActions`。命中 `page-source` 时，本步骤只能做 Read、编译/静态检查等只读诊断，不得 Write/Edit/Create 页面源码，也不得用脚本、格式化器或生成器间接改写；输出应明确“源码未修改”并跳过依赖源码变更的发布。未命中时才执行下列源码实现动作。
 
-当前页需要图片时，先查看已有素材任务状态，同时编写布局、文字、真实数据绑定和交互。尚未启动时，按 [后台启动与接收](../../yida-image-assets/SKILL.md#后台启动与接收) 派发 `yida-image-assets`，随后继续页面开发。接图时读取所属页结果，独立工作完成后才等待该页图片。使用 `--design design.md --page-id <pageId>` 核对当前页槽位并发检查图片，允许外链就直接使用；上传时追加 `--app-type <真实appType>`。结果写入独立的 `asset-manifests/<pageId>.json`，上传失败时保留已验证且允许外链的原地址。读取 manifest 中当前页 `pages[].materialStatus`；该页为 `final` 时只使用 `assets[].materialStatus=final` 的图片。必需槽位缺口只阻塞当前页接图与验收，总状态 `draft` 不阻塞其他已就绪页面。
+当前页为 `required`，或为带槽位的 `beneficial` 时，先执行 `use_skill("yida-image-assets", "准备当前页图片")`。使用 `--design design.md --app-type <真实appType>` 核对槽位、默认上传宜搭图片附件，输出 `asset-manifest.json`；超过 20 MiB 的外链保留原地址。读取 manifest 中当前页 `pages[].materialStatus`；该页为 `final` 时只使用 `assets[].materialStatus=final` 的图片。必需槽位缺口只阻塞当前页，总状态 `draft` 不阻塞其他已就绪页面。
 
 1. 自定义页面开发执行 `use_skill("yida-canvas-custom-page", "生成当前页面源码")`。根据 PRD 和 `design.md` 直接编写 `.canvas.jsx` / `.canvas.tsx`；允许从空文件实现完整 UI。内置整页示例按需用于理解数据接入和导航；表单抽屉片段必须按第 9 条整体合并，不要求复制整页，也不能用示例默认外观替代已确认的设计。已有符合设计的页面可继续迭代。
-2. 按 PRD 的主任务和 scene 选用专项技能：经营分析或投屏监控页执行 `use_skill("yida-dashboard", "实现已规划的指标分析与监控")`；工作台、门户、操作队列继续使用 `yida-canvas-custom-page`，按 [首页按任务选择](../../yida-requirement-analysis/references/experience-groups.md#首页按任务选择) 落实办理路径。少量任务统计或辅助图表不触发整页看板流程。
+2. PRD 或页面名包含看板、工作台、驾驶舱、Dashboard 时，必须执行 `use_skill("yida-dashboard", "实现真实业务看板")`。
 3. 页面读取任一表单数据时，必须执行 `use_skill("yida-canvas-data-binding", "为页面接入真实表单数据")`；不得以“页面已经能发布”为由跳过。
 4. 页面结构已明确且适合生成器时，从 PRD + `design.md` 派生当前业务自己的 `page-spec.json`。
 5. `page-spec.json` 写 `sourceOfTruth`、`prdFile`、`designFile`、`designRefs` 和 `conflictPolicy: "prd-design-win"`。
 6. 列表、看板、详情页读取真实表单数据时，写 `dataBinding.mode=form`、真实 `appType/formUuid/fieldId` 和字段映射；禁止静态 0 或 mock 数据作为交付值。
 7. 页面代码默认消费发布层自动注入的 `window.__OPENYIDA_YIDA_API__` 和 `window.__OPENYIDA_UTILS__`：表单/流程/表单设计 API 走 yida API 桥，`toast/dialog/openPage/router.push/isMobile` 走 utils 桥；`YidaComp` 内不得直接调用 `this.utils.yida.*` 或 `this.utils.*`。
 8. 表单、流程、任务、成员等分页查询一般显式写 `pageSize: 50` 或 `pageSize: '50'`，除非用户明确要求其他页大小。
-9. **MUST**：含普通表单新增/提交/详情入口的 Canvas 页面，先执行 `openyida sample openyida-page-template form-open-container --output .cache/samples/form-open-container.jsx`，整体合并 `CanvasDrawer` / `FormOpenContainer` / `useYidaFormOpen` 及其 import、辅助函数。必须调用 `openForm` 并渲染 `formOpenContainer`，不能只复制定义或类名；PC 端使用提供的 iframe 抽屉，移动端由模板处理。禁止自绘 fixed 遮罩、替代弹窗或普通链接；详情从真实行解析 `formInstId`，缺失时禁用或提示。应用级办理导航已明确在主内容区嵌入原生页时仍按导航规范处理；搜索筛选和专用表格批量录入不套普通表单提交规则。
+9. **MUST**：含页面内表单新建/提交/详情打开入口的 Canvas 页面，必须先执行 `openyida sample openyida-page-template form-open-container --output .cache/samples/form-open-container.jsx` 拉取当前模板，整体合并 `CanvasDrawer` / `FormOpenContainer` / `useYidaFormOpen` 及依赖的 import、辅助函数。禁止自绘 fixed 遮罩 + iframe 抽屉壳；以源码及打开后的 DOM 存在 `.openyida-form-drawer` 为必要检查项，不能只加类名。入口统一使用 `FormOpenContainer`，PC 端右侧抽屉 iframe，移动端整页或新页打开；详情必须从真实行解析 `formInstId`，缺失时禁用入口或提示。应用级办理导航在主内容区嵌入提交页的场景仍按导航规范处理，不强制改成抽屉。
 10. 页面源码默认不自绘应用级侧边导航、顶部应用导航或同级模块菜单；PRD 的导航顺序交给 Step 8 的平台导航排序处理。PRD 导航类型为自定义导航，或用户显式要求在自定义页面内实现自己的应用级导航、隐藏应用导航或独立全屏应用壳时，执行 `use_skill("yida-nav-shell")`。
 11. 没有真实数据时，页面展示空态、表单入口、刷新或登记按钮。
 12. 页面源码用 `.canvas.jsx` / `.canvas.tsx`、`YidaComp`、页面生成器或本地快检。
@@ -50,7 +46,7 @@
 | `page-spec.json` 缺少 sourceOfTruth、design 指针、dataBinding，或与 PRD/design.md 不一致 | 丢弃并从最新 PRD + `design.md` 重生成 |
 | PRD、design.md 和 spec 都完整，但源码有 className、布局比例、字段映射、响应式、loading/empty/error 或编译错误 | 小范围 patch 源码 |
 
-Plan 模式下，业务方案或视觉方案变化时，由对应技能更新 `build-plan.json` 源事实，再物化并确认变更。素材采集结果按 [素材交接](../../yida-image-assets/SKILL.md#6-交给页面使用) 更新后直接继续，沿用已有方案确认。主题 token 变化时，Plan 重新物化并使用 `outputs.theme`，Fast 更新 `design.md` 后运行带 `--design-file` 的 sample；随后重新上传主题。按 [共用主题规则](../../yida-design/references/application-theme-consistency.md) 核对页面引用，不只修改页面中的固定色值。
+Plan 模式下，上表涉及 PRD/design 的修正均由对应技能更新 `build-plan.json` 源事实，再物化并重新确认；不得直接编辑派生产物。主题 token 变化后重新运行带 `--design-file` 的 sample 命令生成 CSS。
 
 ## 产出
 
@@ -61,17 +57,15 @@ Plan 模式下，业务方案或视觉方案变化时，由对应技能更新 `b
 
 ## Checklist
 
-- [ ] 独立前台需要管理员入口时，已用 canvas-admin-entry 对接当前应用访问者身份与真实业务工作台；普通/匿名/未知身份隐藏，未复制 CLI 管理员名单或跳转开发后台；
 - [ ] 页面实现已读取 PRD 和 `design.md`；
 - [ ] 需要图片时只使用 manifest 中已验证的素材；
 - [ ] 新建页面或调整视觉前，实际实现者已完整读取 `canvas-style-implementation-guide.md`；检查记录包含文件路径、适用章节和页面落点，工具读取结果未遗漏截断部分；仅改数据逻辑时说明不适用原因；
 - [ ] 页面没有默认自绘应用级侧边导航 / 顶部导航；如有页面内自绘导航，已有用户显式要求和 `yida-nav-shell` 依据；
-- [ ] 自定义导航已提取 `canvas-nav-content` 并合并 `CanvasNavigationContent`；业务工作区使用 workspace，实际测量内容撑满剩余空间、iframe 与视口等高；连续展示页使用 document，背景覆盖导航背后、内容留实测安全区、沿用页面滚动；源码和 DOM 存在 `.openyida-nav-layout`、`.openyida-nav-content`，只加类名不算通过；
+- [ ] 自定义导航已提取 `canvas-nav-content` 并合并 `CanvasNavigationContent`；源码和 DOM 存在 `.openyida-nav-layout`、`.openyida-nav-content`，且实际测量内容撑满剩余空间、iframe 与视口等高、底部按钮可到达；只加类名不算通过；
 - [ ] 自定义应用导航默认只切主内容区；原生提交/管理入口嵌入 iframe，整页跳转仅用于已确认保留同一导航壳的目标，不直接离开到无导航的原生页面；
-- [ ] 自定义导航页已明确画布、导航与卡片搭配；沉浸首屏与导航共同构图，首屏、第二屏和移动菜单的文字均可读；局部背景未修改平台宿主或全局变量；
-- [ ] 已按 [页面与导航连续性](../../yida-design/references/page-continuity.md) 实现锚点、tab、菜单和列表详情往返：壳保持挂载，URL/选中态/内容一致，加载失败不清空整页，快速切换不串数据，返回状态与未保存内容按设计处理；
+- [ ] 自定义导航页已明确画布、浮导与卡片搭配；浅色非白或渐变画布默认白色浮导、白色无框卡片，局部背景未修改平台宿主或全局变量；
 - [ ] 页面数据优先接真实表单；
-- [ ] 经营分析或监控页已加载 `yida-dashboard`；工作台已验证从待办或队列进入实际办理、完成后更新状态；读取表单数据时已加载 `yida-canvas-data-binding`；
+- [ ] 看板/工作台/驾驶舱已加载 `yida-dashboard`，读取表单数据时已加载 `yida-canvas-data-binding`；
 - [ ] Canvas 页面消费 `window.__OPENYIDA_YIDA_API__` / `window.__OPENYIDA_UTILS__`，没有直接调用 `this.utils.*`；
 - [ ] 含页面内表单打开入口时，已成功执行 `openyida sample openyida-page-template form-open-container --output .cache/samples/form-open-container.jsx` 并记录输出路径；没有此类入口时明确标记不适用；
 - [ ] 已整体合并 `CanvasDrawer` / `FormOpenContainer` / `useYidaFormOpen`、import 和辅助函数，各保留一份定义；源码搜索命中 `openyida-form-drawer`，入口实际调用 `openForm` 并渲染 `formOpenContainer`，未自绘 fixed 遮罩 + iframe 外壳；

package/yida-skills/skills/yida-app/workflow/step-8-publish-navigation.md

@@ -1,6 +1,6 @@
 # Step 8：发布页面并排序导航
 
-发布本轮修改过的页面源码到真实 display 页面，并执行轻量导航排序。平台导航排序必须等待本轮全部页面开发、发布和相关资源创建完成；逐页发布期间不触发平台排序，主页面先完成也不能提前触发排序。自定义菜单在页面开发时按已确认顺序实现，发布后统一验收。
+发布本轮修改过的页面源码到真实 display 页面，并执行轻量导航排序。导航排序必须等待本轮全部页面开发、发布和相关资源创建完成；逐页发布期间不排序，主页面先完成也不能提前触发排序。
 
 ## 输入
 
@@ -12,11 +12,9 @@
 
 ## 自定义导航分支
 
-无论是否分前后台，自定义导航均按 [首页与菜单顺序](../references/entry-navigation.md#每个入口都确定首页与菜单顺序) 实施：发布前核对每个入口菜单数组及分组顺序、`defaultMenuKey` 对应的页面/视图，发布后从实际入口验证首屏。`frontend-only` 不调用平台排序命令，但必须完成上述排序和验收。
+PRD 为自定义导航时，页面导航已在 Step 4 / Step 6 创建或复用页面后按 [导航壳必做配置](../../yida-nav-shell/SKILL.md#必做配置) 隐藏并回读，与源码开发并行。本步骤发布并检查本轮全部自定义页面，再回读核对 `isRenderNav=false`；缺失或被发布改变时才补写修复，不把首次隐藏推迟到发布后。导航顺序由自定义导航实现；汇总 Step 4 / Step 6 的配置结果与发布后回读结果，覆盖 PRD 全部页面后进入 Step 9。下方平台导航排序仅适用于三种平台导航类型。
 
-PRD 的应用工作区导航 `execution.appConfig.navigationType=custom` 时，页面导航已在 Step 4 / Step 6 创建或复用页面后按 [导航壳必做配置](../../yida-nav-shell/SKILL.md#必做配置) 隐藏并回读，与源码开发并行。本步骤发布并检查本轮全部自定义页面，再回读核对 `renderNav=false`；缺失或被发布改变时才补写修复，不把首次隐藏推迟到发布后。导航顺序由自定义导航实现；汇总 Step 4 / Step 6 的配置结果与发布后回读结果，覆盖 PRD 全部页面后进入 Step 9。下方平台导航排序仅适用于三种平台导航类型。
-
-运行态按 [导航验收](../../yida-nav-shell/references/nav-shell-patterns.md#验证) 检查实际外观与交互：顶部导航形态与首屏/滚动态符合设计，侧导可折叠、恢复宽度和拖拽；管理与填写入口分别落到 workbench/submission，主内容 iframe 与当前标签跨页按规划工作，完整地址没有重复应用前缀，query/hash 保留。抽屉 iframe 同时检查填满剩余高度、外层无重复滚动和内页可滚动性，不能仅凭编译通过验收。
+运行态按 [导航验收](../../yida-nav-shell/references/nav-shell-patterns.md#验证) 检查实际外观与交互：顶部浮导符合已确认设计，侧导可折叠、恢复宽度和拖拽；管理与填写入口分别落到 workbench/submission，主内容 iframe 与当前标签跨页按规划工作，完整地址没有重复应用前缀，query/hash 保留。抽屉 iframe 同时检查填满剩余高度、外层无重复滚动和内页可滚动性，不能仅凭编译通过验收。
 
 ## 操作
 
@@ -29,7 +27,7 @@ openyida publish <source> <appType> <displayPageFormUuid> --canvas --health-chec
 ```
 
 2. 主流程核对本轮全部页面已开发完成并发布成功、表单/流程等导航目标已创建。仍有任务未完成或失败时，继续处理对应任务，暂不排序。
-3. 全部页面与资源汇合后，仅需配置平台导航时，根据 PRD 选择下列一个分支；只使用自定义导航的入口继续做页面排序验收，不调用平台排序命令：
+3. 全部页面与资源汇合后，根据 PRD 只选择一个互斥分支：
 
 PRD 写明页面/表单清单顺序：
 
@@ -39,7 +37,7 @@ openyida nav-group order <appType> <页面/表单...>
 
 显式排序只执行一次。
 
-完整应用的 PRD 缺少明确顺序时，先按各角色的首要任务补齐入口 `menu` 和 `defaultMenuKey`，再执行显式排序。不能用页面名称、创建顺序或自动猜测代替首页决定。用户明确要求自动整理平台菜单时可使用：
+PRD 缺少明确页面清单：
 
 ```text
 openyida nav-group auto-order <appType>
@@ -48,26 +46,16 @@ openyida nav-group auto-order <appType>
 此分支只执行一次 `auto-order`，不再执行显式 `order`。完整应用逐页发布均不带 `--auto-nav-order`；存量平台 JSX 页面发布去掉 `--canvas`。
 
 4. 同一搭建 Run 不得同时执行显式排序与自动排序，不生成逐项 `move` 的 Bash/Python 循环。
-5. 逐入口落实任务顺序与默认页：平台菜单消费 entryRecommendation 派生的 navigationOrder；自定义菜单消费该入口的 menu 和 defaultMenuKey。前台首页不自动进入后台，frontend-only 仍需完成前台菜单排序。
-6. 从本轮交付的每个业务入口检查实际菜单顺序、默认页面、具体视图和首屏内容。平台排序 `readbackVerified=true` 不证明首页已正确；根入口仍打开错误任务时，继续处理平台支持的默认页配置，能力未验证时交付明确任务链接并标记根入口待验证。平台导航管理页只保留一套跨模块导航，重复时修正页面源码。
-7. 本步骤配置宜搭平台导航，不要求页面源码实现侧边栏或顶部应用导航；只有 PRD 已规划该入口自己的菜单时才实现，不因平台排序再回头补导航壳。
-7. 本轮任一页面 `entryMode=standalone` 时，Step 6 已在取得页面 ID 后隐藏页面导航；发布和健康检查通过后执行 `openyida get-form-config <appType> <displayPageFormUuid> --json` 核对。配置缺失或变化时才执行 `openyida update-form-config <appType> <displayPageFormUuid> false "<页面标题>"` 并再次回读。只有回读明确为 `renderNav=false` 时，才把干净的 `{base_url}/{appType}/custom/{displayPageFormUuid}` 交给 Step 9 作为独立业务入口；写入或回读失败时只保留工作台入口，不用 `?isRenderNav=false` 猜测成功。
+5. 兜底顺序为：门户/首页/工作台入口、业务办理、数据管理、经营分析、系统配置。
+6. 本步骤配置宜搭平台导航，不要求页面源码实现侧边栏或顶部应用导航；除非用户显式要求页面内自绘导航，否则不要回头在自定义页面中补导航壳。
+7. 主页面 `entryMode=standalone` 时，Step 6 已在取得页面 ID 后隐藏页面导航；发布和健康检查通过后执行 `openyida get-form-config <appType> <displayPageFormUuid> --json` 核对。配置缺失或变化时才执行 `openyida update-form-config <appType> <displayPageFormUuid> false "<页面标题>"` 并再次回读。只有回读明确为 `isRenderNav=false` 时，才把干净的 `{base_url}/{appType}/custom/{displayPageFormUuid}` 交给 Step 9 作为独立业务入口；写入或回读失败时只保留工作台入口，不用 `?isRenderNav=false` 猜测成功。
 8. 主页面 `entryMode=platform-shell` 或缺失时，不修改页面导航配置，也不输出独立业务入口。
 
-## 无自定义页面的管理端
-
-没有本轮源码时跳过 publish，继续核对真实资源、权限、管理菜单和默认入口。缺少 display 主页面不构成失败，不追加自定义首页。新版双入口按 [访问态入口契约](../references/entry-navigation.md) 处理，显式排序不会删除未列出的导航项；需精简平台菜单时单独规划 hide/show 并回读。
-
-## 混合导航验收
-
-应用保留平台导航、前台单独自定义菜单时：只配置 PRD 标记 standalone 的页面；平台导航排序继续服务后台。逐个核对前台页面 URL 与后台 workbench URL：前台可独立办事、菜单不混入管理任务；后台菜单可见、切换可用。任何一边未验证都不能宣称前后台交付完成。不能为修复前台显示而调用全局隐藏。
-
-
 ## 产出
 
 - 成功的 `openyida publish` 命令结果；
 - 可访问主页面 URL；
-- 各入口的默认页、菜单顺序与验收结果；平台排序附结构化回读，自定义导航附实际页面验证，失败时保留发布结果和可恢复诊断；
+- 导航排序的结构化结果；失败时保留发布结果和可恢复诊断；
 - `standalone` 页面导航配置的写后回读结果，或明确未启用独立入口。
 
 ## Checklist
@@ -76,13 +64,11 @@ openyida nav-group auto-order <appType>
 - [ ] 发布目标是已解析的 display 页面；
 - [ ] Canvas 发布结果为 `publishMode=canvas`，且 `healthCheck.ok=true`、`healthCheck.readback.hasYidaCodeCanvas=true`、`runtimeCodeBytes>0`；
 - [ ] 已获得可访问 URL；
-- [ ] 本轮每个业务入口都已核对默认页面、菜单及分组顺序和首屏任务；自定义导航没有因跳过平台排序命令而漏验；
-- [ ] 自定义导航业务工作区切换后的 main 和 iframe 撑满剩余空间；连续展示页的首屏背景覆盖导航背后，滚动进入第二屏及窄屏展开菜单仍可读；检查短/长内容、窗口高度变化和底部操作可达性，无双滚动、背景断带或意外边距变化；
-- [ ] 按 [页面与导航连续性](../../yida-design/references/page-continuity.md) 验证菜单往返、直接链接、刷新、前进后退、重复/快速点击及加载失败；保留约定的筛选、分页、位置和未保存输入，URL、选中态与内容一致；
+- [ ] 自定义导航切换后的 main 和 iframe 撑满剩余空间；检查短/长内容、窗口高度变化、窄屏和底部操作可达性，无双滚动；工作台与原生页内容边界和外侧留白连续；
 - [ ] 使用自定义导航时逐项点击，导航仍可见、可操作，选中项与主内容一致且能返回工作台；刷新、前进后退恢复任务，无双导航和双滚动条，不能仅以目标页打开成功验收；
 - [ ] 含页面内表单打开入口时，PC 打开后 DOM 存在 `.openyida-form-drawer`；实测新窗口打开、全屏/退出全屏、关闭三个图标按钮、左边缘拖拽调宽及关闭刷新；详情和提交 iframe 填满剩余空间，外层无多余卡片和滚动条。无此类入口时标记不适用；
 - [ ] 全部页面开发与发布、相关资源创建均已完成后才执行排序；显式排序和自动排序只执行其一；成功结果 `readbackVerified=true`。
-- [ ] `standalone` 主页面已回读确认 `renderNav=false`；否则没有声明独立业务入口。
+- [ ] `standalone` 主页面已回读确认 `isRenderNav=false`；否则没有声明独立业务入口。
 
 ## 下一步