openyida 2026.9.13 → 2026.9.15

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

@@ -37,6 +37,7 @@ description: 表单页面创建与更新；支持 19 种业务字段和 Divider
 - update / add-option / bind-datasource / validation / rule 等字段级操作不要求先执行外部 `get-schema`；直接提交 compact JSON 或字段 label/fieldId，CLI 会内部读取 schema、定位字段，并在成功 JSON 中输出 compact `resolved`/`updatedProps` evidence。字段解析失败/歧义时按 `diagnostics[].candidates` 补 `tableLabel`、修正 label 或再执行一次 compact `get-schema`。
 - 字段定义或变更定义需要落盘时，必须使用 agent 的结构化文件写入工具创建到 `<projectRoot>/.cache/openyida/<项目名或任务名>/`，例如 `<projectRoot>/.cache/openyida/pm/pm-fields-team.json`
 - 普通表单分组必须优先使用 `Divider`，多列排版必须通过字段 JSON 中的 `ColumnContainer` 局部表达
+- **重复结构化记录默认使用 `TableField`**：用户未指定具体字段类型时，凡一个业务字段承载多条同构记录，且每条记录由一组固定子字段组成，必须用 `TableField + children` 建模，不以字段名称或业务领域作为判断依据；用户明确指定具体字段类型时按用户要求执行，不将模型推断、跨会话记忆或历史兼容性说法视为用户指定。未在当前应用、当前提交链路验证的限制不能作为字段改型依据。
 - **本技能不读写 memory**：formUuid 等信息输出到 stdout，通过 `.cache/<项目名>-schema.json` 持久化，不依赖跨会话的 memory 状态
 
 ## 适用场景
@@ -109,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` 的空壳表单执行一次保守恢复。每个结果状态只沿表中对应的下一动作推进。
 
 ## 官方表单示例范式
 
@@ -178,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`。
@@ -220,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

@@ -60,7 +60,7 @@
 1. 进度消息使用业务结果和下一步动作。结构化问题紧随其后时，不额外发送内部分析结论；多个问题确需共同背景时，只在整组交互的引导中说明一次，不写入每个问题的 `title` 或 `prompt`。
 2. `title`、`prompt`、`label`、`description` 和普通对话只使用用户能直接理解的业务词。
 3. `interactionId`、`questionType`、`value`、`writeBackPath`、`reason`、状态字段和文件路径仅供内部执行，不进入用户可见内容。
-4. `title` 只写确认主题，`prompt` 只写用户当前需要回答的问题；搭建模式、导航归属保持中性，不标记“推荐”或“默认”，不预选、不按偏好排序，也不在引导或描述中推荐。导航布局和呈现样式根据场景确定，不进入提问选项；用户明确的布局和样式优先。其他问题存在合理默认值时可标记。只有某个选择会产生重要且难以撤销的影响时，才在对应选项的 `description` 中说明影响。
+4. `title` 只写确认主题，`prompt` 只写用户当前需要回答的问题；搭建模式保持中性，不标记“推荐”或“默认”，不预选、不按偏好排序，也不在引导或描述中推荐。导航方式、布局和呈现样式由 AI 根据场景确定，用户明确要求优先。其他问题存在合理默认值时可标记。只有某个选择会产生重要且难以撤销的影响时，才在对应选项的 `description` 中说明影响。
 5. 用户已经提供的信息直接写入内部事实，不重复总结成“缺口分析”或再次追问。
 6. PRD 的业务说明、HTML、进度消息和交付总结使用功能、体验和验收结果描述配置。接口参数、配置键值、内部 ID 和 CLI 选项保留在 Agent 实施交接中；访问链接使用业务名称，链接目标保留必需参数。用户明确询问实现细节时，再解释对应技术内容。
 7. 规划写预期行为，进度写正在进行的动作，完成总结依据实际验证结果。导航方案写“采用自定义导航，支持各业务页面间切换”；完成配置并验证跳转后写“已启用自定义导航，可在各业务页面间切换”。
@@ -100,7 +100,6 @@ Fast / Plan 是面向用户的模式名称，可以展示。已有详细计划
 | ---------------- | ---------------------------------------------- | ---------------------------- | ----------------------------- |
 | 搭建方式 | `single_choice` | 按需求详细程度提供 PRD 是/否或 Fast/Plan | brief 的 `intake.designMode` |
 | 业务模块与页面范围 | `multi_choice` | 具体业务模块、对应页面、表单及用途，可合为一题 | brief 的 `coreFunctions/businessObjects/pageScenes/explicitScope` |
-| 导航归属 | `single_choice` | 仅“宜搭原生导航”和“自定义导航”两个选项；原生导航就是平台导航，布局根据场景确定 | brief 的 `navigation`（按场景补齐 `type`，自定义含 `variant`，`reason` 区分用户归属选择与布局依据） |
 | 应用设计风格 | `single_choice` | 面向业务的风格选项与自定义偏好 | brief 的 `visualSelection` |
 | 来源补齐         | `free_text`                                    | 可读正文、链接或附件         | `meta.source`                 |
 | 最新搭建计划确认 | `confirm`                                      | 当前版本、确认生成、继续调整 | `meta.planState`              |
@@ -124,9 +123,9 @@ Fast / Plan 是面向用户的模式名称，可以展示。已有详细计划
 
 ## 首次搭建确认
 
-先完成需求分析，再按 [首次搭建确认表](../../yida-requirement-analysis/workflow/prepare-brief.md#2-确认首次搭建的未决事项) 询问尚未明确的事项。该表统一维护详细计划复用、搭建方式、业务模块、导航归属、风格和页面范围；已有业务应用的局部增改按本次疑问澄清。
+先完成需求分析，再按 [首次搭建确认表](../../yida-requirement-analysis/workflow/prepare-brief.md#2-确认首次搭建的未决事项) 询问尚未明确的事项。该表统一维护详细计划复用、搭建方式、业务模块、风格和页面范围；已有业务应用的局部增改按本次疑问澄清。
 
-首次搭建的全部未决事项在一次结构化提问调用中呈现并一次性作答，Fast / Plan、导航归属、业务模块和页面范围不得分轮收集。导航仅提供“宜搭原生导航”和“自定义导航”两个选项，按 [导航选项说明](../../yida-requirement-analysis/workflow/prepare-brief.md#导航选项说明) 附带实现方式说明；宜搭原生导航就是平台导航。支持 `description` 时写入该字段，否则在选项后括号备注。顶部、侧边、L 型、浮导、底部菜单等布局或样式不进入 `ask_human`；Agent 在已选归属内根据场景确定，记录布局依据并交给后续规划，不补问位置。用户已明确的归属、布局或样式直接沿用。工具限制问题数量时合并为复合问题，多选能力不足时使用同组自由输入；没有可用结构化工具时，在一条消息中展示全部问题。具体合并方式遵守首次搭建确认表，全部必要回答写回后才开始后续规划。
+首次搭建的全部未决事项在一次结构化提问调用中呈现并一次性作答，Fast / Plan、业务模块和页面范围不得分轮收集。导航按 [导航设计](../../yida-requirement-analysis/workflow/prepare-brief.md#导航设计) 确定，用户已明确的方式、布局或样式直接沿用。工具限制问题数量时合并为复合问题，多选能力不足时使用同组自由输入；没有可用结构化工具时，在一条消息中展示全部问题。具体合并方式遵守首次搭建确认表，全部必要回答写回后才开始后续规划。
 
 视觉映射统一写入 brief 的 `visualSelection`，由后续计划沿用 visualDirection、selectedTheme、colorStrategy、navigationStyle；未选候选保留在会话中。
 
@@ -141,14 +140,14 @@ Plan Design 完成当前版本后，按以下顺序与用户交互：
 
 `build-plan.html` 不承载对话控件或确认按钮；用户在会话中完成确认。
 
-最终确认使用以下逻辑问题，其中 `{revision}` 替换为当前版本号：
+最终确认是一个 `single_select` 语义问题。它只有下面这一份可调用 schema；顶层字段集合固定为 `question`、`title`、`options`、`attachments`、`revision`、`submitLabel`。将路径和 `{revision}` 替换为本次 materialize 返回的真实值：
+
+#### 最终确认 `ask_human` payload
 
 ```json
 {
-  "interactionId": "plan_confirm_r{revision}",
-  "questionType": "confirm",
+  "question": "是否按当前这版方案开始搭建？",
   "title": "确认整体方案",
-  "prompt": "是否按当前这版方案开始搭建？",
   "options": [
     {
       "value": "confirm_build",
@@ -161,18 +160,19 @@ Plan Design 完成当前版本后，按以下顺序与用户交互：
       "description": "继续完善当前方案，确认后再开始搭建。"
     }
   ],
-  "allowCustom": false,
-  "writeBackPath": "meta.planState",
   "attachments": [
     {
-      "name": "当前搭建方案",
+      "name": "build-plan.html",
       "path": "prd/<项目名>/build-plan.html"
     }
   ],
-  "revision": "{revision}"
+  "revision": "{revision}",
+  "submitLabel": "提交选择"
 }
 ```
 
+`options` 固定为 `confirm_build`、`continue_editing` 两项。最终确认只收集当前 revision 的去向；调整内容由进入 editing 状态后的下一次交互收集。内部交互身份使用 `plan_confirm_r{revision}`，回答写入 `meta.planState`。
+
 ## 版本与确认状态
 
 `build-plan.json` 使用 `meta.revision`、`meta.status` 和 `meta.planState` 共同记录当前计划状态：
@@ -191,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；用户取消或关闭交互时停止执行，不创建应用资源。
+资源实施的进入条件是 `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-design/sub_skill/yida-design-plan/references/build-plan-schema.md

@@ -142,7 +142,7 @@
 
 约束：
 
-- 计划生成前先确定应用范围与导航类型，再选择视觉方向。范围和导航归属不明时可合并询问，导航选项仅为“宜搭原生导航”和“自定义导航”；原生导航即平台导航，顶部、侧边、L 型等布局由 Agent 按场景确定，不进入 `ask_human`。回答后生成遵守导航决策的视觉候选；每个问题必须有 `interactionId` 和 `writeBackPath`。
+- 计划生成前先确定应用范围，导航方式与布局按 [导航设计](../../../../yida-requirement-analysis/workflow/prepare-brief.md#导航设计) 写入 brief，用户明确要求优先。视觉候选沿用该导航决策，随整体方案确认。其余必要问题必须有 `interactionId` 和 `writeBackPath`。
 - `questionType` 只取 `single_choice`、`multi_choice`、`free_text` 或最终计划使用的 `confirm`，不设置 AI 代填项中间确认类型。
 - 只有宽泛应用名称且缺少模块、场景、任务、流程和可读需求时才问应用范围。
 - 审批、角色权限、字段、首页、看板、页面和常规流程细节不进入 `ask_human`；用户已提供时承接，未提供时基于业务推断并在最终计划统一呈现。

package/yida-skills/skills/yida-design/workflow/step-4-wireframe-interaction.md

@@ -13,7 +13,7 @@
 
 ## 自定义导航设计
 
-沿用需求阶段用户选择的导航归属，以及根据场景确定或用户指定的布局；不再询问顶部、侧边等布局选项。参考 [导航壳形态目录](../../yida-nav-shell/references/nav-shell-patterns.md) 设计位置、比例、留白与选中态，代码示例只按需参考。顶部默认浮导；侧导及顶部＋侧边布局写清折叠/展开、恢复宽度、拖拽边界、内容区联动和移动端收起方式。已有满意的导航保留外观，只补缺失交互。
+沿用 brief 中 AI 判断或用户明确指定的导航方式与布局。参考 [导航壳形态目录](../../yida-nav-shell/references/nav-shell-patterns.md) 设计位置、比例、留白与选中态，代码示例只按需参考。顶部默认浮导；侧导及顶部＋侧边布局写清折叠/展开、恢复宽度、拖拽边界、内容区联动和移动端收起方式。已有满意的导航保留外观，只补缺失交互。
 
 区分三种操作：本页视图切换、保留导航并更新主内容 iframe、当前标签跨页跳转。管理入口使用 workbench，办理入口使用 submission；不要把应用级办理导航设计为每次弹抽屉。页面内新增/详情按钮才采用下面的抽屉规则。设计结果写入当前 `design.md`；Plan 模式先更新计划源事实再物化。
 

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

@@ -421,6 +421,7 @@ openyida integration diagnose --file project/tickets/automation-error.txt --json
 - 流水号：新增/编辑触发时，触发 payload 中的流水号可能为空或不是最新值；需要先获取自身，再引用获取节点里的流水号。
 - 定时自动化：定时触发值可能是历史数据；需要最新值时先获取自身或获取目标数据。
 - 直接更新：匹配字段只能消费当前触发表字段，不能随意匹配前置节点字段；文本字段不要匹配单选/多选字段。直接更新不会触发被更新表单上的集成自动化。
+- 跨应用写入不级联触发（阻塞项）：A 应用表单的集成自动化通过内置新增/编辑/删除数据节点写 B 应用表单（跨应用）时，B 表单上已配置的新增/编辑/删除自动触发集成业务流不会生效。涉及跨应用链式联动时这是阻塞项，不得假设 B 表自动化会被接力触发。
 - 条件分支：空值判断优先用公式 `ISEMPTY()`，不要只依赖“没有值”选项。
 - 异常重试：重试通常会从头执行，已执行过的新增/更新节点可能再次写入或覆盖数据；重试前先确认幂等性。
 

package/yida-skills/skills/yida-nav-shell/SKILL.md

@@ -1,13 +1,13 @@
 ---
 name: yida-nav-shell
-description: 自定义页明确要自绘应用级导航时使用；先隐藏应用导航 hideAppNav。页面级 isRenderNav=false 不等于应用导航隐藏。
+description: 需求规划采用自定义应用导航或用户明确要求自绘时使用；先隐藏应用导航 hideAppNav。页面级 isRenderNav=false 不等于应用导航隐藏。
 ---
 
 # yida-nav-shell
 
 ## 先判断
 
-默认不用本技能。宜搭应用的页面切换优先交给平台导航和 `yida-nav-group`。
+按 brief/PRD 的导航决策路由：采用自定义应用导航时使用本技能；采用宜搭原生导航时使用 `yida-nav-group`。导航方式由 [需求分析](../yida-requirement-analysis/workflow/prepare-brief.md#导航设计) 判断，用户明确要求优先。
 
 | 用户需求 | 怎么处理 |
 | --- | --- |
@@ -26,7 +26,7 @@ description: 自定义页明确要自绘应用级导航时使用；先隐藏应
 
 ## 必做配置
 
-用户确认自定义导航后，就将应用导航隐藏纳入应用基础设置更新：新建应用时，等 `app-theme.css` 生成后，将 `--hide-app-nav` 与主题、Logo、布局等设置合并到同一次 `update-app`，按 [应用设置同步](../yida-app/workflow/step-3-create-or-reuse-app.md) 执行并回读。已有应用只需切换导航时执行：
+需求规划采用自定义导航后，就将应用导航隐藏纳入应用基础设置更新：新建应用时，等 `app-theme.css` 生成后，将 `--hide-app-nav` 与主题、Logo、布局等设置合并到同一次 `update-app`，按 [应用设置同步](../yida-app/workflow/step-3-create-or-reuse-app.md) 执行并回读。已有应用只需切换导航时执行：
 
 ```bash
 openyida update-app <appType> --hide-app-nav
@@ -50,7 +50,7 @@ openyida get-form-config <appType> <formUuid> --json
 - **画布与浮导间距**：平台宿主继续消费 `--pod-page-bg-color`；自绘导航页的内部画布由 `design.md` 定义，可采用浅灰、浅彩、渐变或局部纹理，不强制跟随白色平台底色。浅色非白画布上，顶部浮导默认白色或近白半透明，卡片默认白色无框；品牌色集中于选中态和主操作，深色方案单独设计。只作用于当前页面选择器，不修改应用全局变量。根节点使用 `display:flow-root` 或 flex/grid，让浮导上边距留在根节点内。
 
 - **先选形态，再写 UI**：根据已确认的 PRD、`design.md` 和用户参考确定布局。模块多用侧栏，模块少且内容需要宽度用顶部，两级业务用顶部＋侧边，沉浸展示可用悬浮 Dock，同模块视图用标签。已确认的选择直接沿用，不重新提问。
-- 自定义顶部导航默认推荐浮导，可按内容宽度设计为紧凑胶囊或悬浮栏；“顶部导航”不等于贴边通栏。位置、比例、留白、材质和选中态根据业务与设计实现，不由现成组件决定。此推荐只针对顶部样式，“平台导航 / 自定义导航”选项保持中性。
+- 自定义顶部导航默认推荐浮导，可按内容宽度设计为紧凑胶囊或悬浮栏；“顶部导航”不等于贴边通栏。位置、比例、留白、材质和选中态根据业务与设计实现，不由现成组件决定。此推荐只针对顶部样式，不改变已确定的导航方式。
 - 需要布局方向和小段代码时读 [导航壳形态目录](references/nav-shell-patterns.md)。按场景设计和手写实现，不强制复制任何导航组件。已有导航符合设计时直接复用，只补缺失功能；不能仅因存在新示例而替换现有外观。
 - 自定义侧边导航（含顶部＋侧边）的 PC 端必须支持折叠/展开和拖拽调宽；展开恢复折叠前宽度，宽度变化时内容区同步调整。移动端改为可展开/收起的菜单，详见 [侧栏交互](references/nav-shell-patterns.md#侧栏交互)。
 - 菜单数量、名称、顺序、分组和入口用途来自 PRD，通常工作台在首位；用当前访问者的 `getAccessableNavs.json` 过滤可见范围，详见 [导航数据来源](references/nav-shell-patterns.md#导航数据来源)。数据逻辑可直接复用，不要求采用同一套 UI。

package/yida-skills/skills/yida-prd/workflow/output-prd.md

@@ -24,11 +24,11 @@
 
 | 配置项 | 值 |
 | --- | --- |
-| 导航类型 | <平台L型导航 / 平台顶部导航 / 平台侧边导航 / 自定义导航；按用户选择的归属和场景确定具体布局> |
+| 导航类型 | <平台L型导航 / 平台顶部导航 / 平台侧边导航 / 自定义导航；沿用需求阶段的导航判断和用户明确要求> |
 | 是否使用平台应用导航 | <前三种为是，自定义导航为否> |
 | 页面导航配置 | <自定义导航：列出本轮全部表单、流程表单、自定义页面及需配置的其他页面，统一隐藏平台页面导航；平台导航：保留页面设置，明确独立入口例外> |
 
-用户仅选择宜搭原生导航（即平台导航）或自定义导航；上表记录可执行方案，平台顶部、侧边、L 型以及自定义布局由 Agent 根据场景确定，用户已指定的布局优先。导航方案区分用户选择的归属与布局判断依据，说明页面入口和跨页切换方式；导航配色单独说明深色或浅色。
+导航方式与布局沿用 brief 中的决策，判断规则见 [导航设计](../../yida-requirement-analysis/workflow/prepare-brief.md#导航设计)。上表记录可执行方案和依据，区分用户明确要求与 AI 判断，说明页面入口和跨页切换方式；导航配色单独说明深色或浅色。
 
 ## 3. 数据结构（业务语义，不含细节 ID）
 

package/yida-skills/skills/yida-prd/workflow/step-2-information-architecture.md

@@ -13,7 +13,7 @@
 
 自定义导航将每个入口的用途、目标资源和打开方式写清：管理视图走 `workbench/{formUuid}`，直接填写走 `submission/{formUuid}`；同一表单可对应两个独立入口，不重复创建表单。保留自绘导航时，表单在主内容区 iframe 打开；跨真实页面默认当前标签跳转；页面内新增/详情按钮使用抽屉。参数与路由规则见 [链接参考](../../../references/field-and-url-reference.md)。
 
-已确认的自定义顶部导航默认浮导，侧边或顶部＋侧边导航必须支持折叠/展开、恢复宽度和拖拽调宽；将这些交互写入 PRD，视觉细节交给 `design.md`。按 [导航壳形态目录](../../yida-nav-shell/references/nav-shell-patterns.md) 的场景与骨架引导设计，不把 CLI 导航组件当作固定 UI，不追加导航样式确认。
+已确认的自定义顶部导航默认浮导，侧边或顶部＋侧边导航必须支持折叠/展开、恢复宽度和拖拽调宽；将这些交互写入 PRD，视觉细节交给 `design.md`。按 [导航壳形态目录](../../yida-nav-shell/references/nav-shell-patterns.md) 的场景与骨架引导设计，代码示例按需参考。
 
 ## 列资源清单
 
@@ -63,7 +63,7 @@
 
 默认规则：
 
-- 默认保留平台应用导航。
+- 沿用 brief 的导航决策；未明确时按 [导航设计](../../yida-requirement-analysis/workflow/prepare-brief.md#导航设计) 补齐。
 - 页面内 tab、分段、筛选、卡片切换只是当前页内容结构。
 - 只说「工作台 / 门户 / 看板 / 大屏 / 首页」不是隐藏导航信号。
 - 同应用跨页面入口优先进入平台导航或导航分组。

package/yida-skills/skills/yida-requirement-analysis/SKILL.md

@@ -32,7 +32,7 @@ description: 识别并读取需求来源，理解和澄清用户需求，输出
 | `pageScenes` | 已确认的页面与表单范围，数组；记录稳定 key、name、kind、purpose 及已有细项 |
 | `intake` | 首次搭建判断、来源详细程度、搭建方式和需求确认状态 |
 | `visualSelection` | 已确认风格及其主题、主色、导航明暗映射；Plan 初始化前必须含非空 `themeId` |
-| `navigation` | 用户仅选择宜搭原生导航（即平台导航）或自定义导航；Agent 按场景确定布局并在 `reason` 区分选择与推断。应用导航决策：`type` 只能是 `platform-l-shape/platform-top/platform-side/custom`，并记录 `source/reason`；自定义导航增加 `variant: side/top/mixed/dock`；未决时 type 为 null，规划前补齐 |
+| `navigation` | AI 按场景判断导航方式与布局，用户明确要求优先。判断规则见 [整理需求事实](workflow/prepare-brief.md#导航设计)，`source` 区分 `ai_default` 与 `user_selected`。应用导航决策：`type` 只能是 `platform-l-shape/platform-top/platform-side/custom`，并记录 `source/reason`；自定义导航增加 `variant: side/top/mixed/dock`；未决时 type 为 null，规划前补齐 |
 | `resourceContext` | 已确认可复用的 app/page/form/process 业务上下文，不写猜测 ID |
 | `explicitScope` | 用户明确指定的页面、表单、流程、报表、导航项和本轮交付；明确窄范围时写对应数组及 `allowInferredResources:false`，没有时为 `null` |
 | `brandHints` / `colorHints` | 明确的品牌、参考页面、已有主题、偏好色与避用色 |

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

@@ -14,37 +14,36 @@
 
 ## 2. 确认首次搭建的未决事项
 
-先分析再提问。用户已明确的信息直接采用；同一次搭建已回答的问题直接复用。首次提问必须在同一轮一次性收集所有尚未明确的搭建方式（Fast / Plan）、业务模块、页面与表单范围、导航归属（宜搭原生导航或自定义导航）和设计风格。不要先问模块、导航和风格，收到回答后再另起一轮补问模式、导航位置或页面。
+先分析再提问。用户已明确的信息直接采用；同一次搭建已回答的问题直接复用。首次结构化提问以一次原子交互收集全部未决的搭建方式（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 都按这一状态转换规则写回。
+
+将整组问题放在一次结构化提问调用中。宿主限制问题数量时，合并为“搭建方式”“业务模块、页面与风格”等复合问题；选项数量或多选能力不足时，用允许自由输入的同组问题列出完整选择。回答遗漏、互相冲突或产生新的关键业务疑问时，再开启一次针对性补充交互。
 
 | 事项 | 何时询问 | 用户可见问题与选项 |
 | --- | --- | --- |
 | 搭建方式 | 用户未选择方式，且已提供详细计划 | “是否根据你提供的需求，整理一份应用 PRD 计划供你确认？” 是：计划更清晰详细，耗时更长；否：按现有需求快速搭建 |
 | 搭建方式 | 用户未选择方式，且需求细节不足 | “希望用哪种方式搭建？” Fast（快速搭建）；Plan（先生成 PRD，确认后再搭建，耗时更长） |
-| 导航归属 | 用户未明确宜搭原生导航或自定义导航 | “你希望应用使用哪种导航菜单？” 仅提供“宜搭原生导航”和“自定义导航”两个选项，并附下表说明。宜搭原生导航就是平台导航；归属已明确时不再询问，顶部、侧边、L 型等布局根据场景选择，不进入 `ask_human` |
 | 业务模块 | 用户未明确业务范围 | “应用需要包含哪些业务模块？” 根据业务列出具体模块及用途，支持多选或自行补充；不要只用“标准4-5模块”代替具体模块清单 |
 | 应用设计风格 | 用户未提及 | 根据业务提供简短的配色与界面风格选项，并允许描述自己的偏好；已有品牌或参考图时沿用 |
 | 页面范围 | 用户未明确页面与表单 | “这次需要哪些页面和表单？” 同轮按候选业务模块列出页面和表单及用途，支持多选或自行补充，例如“工作台：汇总待办”“活动报名表：填写报名信息”；可与业务模块合成一题，不等模块回答后再问，也不要只用“标准4页”代替页面清单 |
 
-### 导航选项说明
-
-导航 `ask_human` 仅有以下两个选项，不把布局或呈现样式拆成选项，也不追加布局问题。选项名称与说明一起呈现；支持 `description` 时写入该字段，否则在选项名称后用括号备注。
+搭建模式选项平等说明，不推荐、不预选，不添加“（推荐）”或“默认”。详细计划问题的“是”对应 Plan，“否”对应 Fast；两者都复用已有需求。用户明确要求代为决定模式时，记录选择和依据。
 
-| 导航选项 | 必须附带的说明 |
-| --- | --- |
-| 宜搭原生导航 | 使用宜搭自带的导航菜单。 |
-| 自定义导航 | 在自定义页面里定制菜单的样式和操作方式，替代宜搭自带的导航菜单。 |
+### 导航设计
 
-需要解释布局时，统一使用：“菜单放在顶部、左侧，还是顶部加左侧，会根据应用场景安排，你不用再选。” 面向用户不使用“导航归属”“布局枚举”等内部术语。
+Fast 与 Plan 均由 AI 根据业务场景确定导航方式、布局和呈现样式。
 
-模式和导航归属选项平等说明，不推荐、不预选，不添加“（推荐）”或“默认”。详细计划问题的“是”对应 Plan，“否”对应 Fast；两者都复用已有需求。用户明确要求代为决定时，记录选择和依据。
+1. 用户已明确要求宜搭原生导航、自定义导航或具体布局时优先沿用；只说“平台导航”视为宜搭原生导航，只指定顶部、侧边或 L 型时保留布局，由 AI 补齐导航方式。后续阶段沿用同一决策，不因默认规则覆盖用户要求。
+2. 已有业务应用的局部增改沿用现有导航；显式窄范围遵守上文执行边界，不因 AI 判断扩大资源范围或修改应用设置。
+3. 新建完整应用以原生表单、审批、数据管理和多模块业务操作为主，且平台导航能满足入口组织时，采用宜搭原生导航。需要在同一自定义页面中持续保留菜单和内容状态，或业务要求品牌化菜单、特殊导航交互时，可采用自定义导航，并在 `reason` 写明需求依据。仅出现“门户 / 看板 / 首页”或页面内 tab 不足以判定需要自定义应用导航；信息不足以支持自绘时采用宜搭原生导航。
+4. 将导航方式、布局和判断依据写入 brief，交给 PRD 与视觉设计共用。Plan 将导航方案纳入整体方案展示和最终确认；Fast 按已记录的判断继续实施。
 
 ### 根据场景确定导航布局
 
-用户只选择导航归属。Agent 在该归属内，结合业务模块数量、层级、切换频率、内容宽度和目标设备确定布局；用户已明确布局或提供参考时优先沿用。用户只说“平台导航”视为已选“宜搭原生导航”；只指定顶部、侧边或 L 型但未明确归属时，保留布局要求，仅询问上述两个归属选项。
+AI 在已确定的导航方式内，结合业务模块数量、层级、切换频率、内容宽度和目标设备确定布局；用户已明确布局或提供参考时优先沿用。
 
 | 场景 | 宜搭原生导航（平台导航） | 自定义导航 |
 | --- | --- | --- |
@@ -53,7 +52,7 @@
 | 业务域与域内模块形成两级导航 | L 型：`platform-l-shape` | 顶部＋侧边：`custom` + `variant: mixed` |
 | 少量高频入口的移动端轻量门户或沉浸展示 | 按实际层级选顶部或侧边 | 可选底部悬浮菜单：`custom` + `variant: dock` |
 
-这些是布局判断依据，不是固定模板或用户问卷；不得为适配布局增删业务模块，也不能因布局偏好改变已选导航归属。自定义形态细化参考 [导航壳形态目录](../../yida-nav-shell/references/nav-shell-patterns.md)。自定义顶部未指定样式时默认浮导；侧边及顶部＋侧边在 PRD/design 中写入折叠/展开和拖拽调宽，不另行提问。
+这些是布局判断依据，不是固定模板或用户问卷；不得为适配布局增删业务模块，也不能因布局偏好改变已选导航归属。自定义形态细化参考 [导航壳形态目录](../../yida-nav-shell/references/nav-shell-patterns.md)。自定义顶部未指定样式时默认浮导；侧边及顶部＋侧边在 PRD/design 中写入折叠/展开和拖拽调宽。
 
 额外只补问影响搭建的关键疑问：给谁使用、主要解决什么问题、创建还是复用应用、数据可见范围、关键审批规则、必要的外部数据来源。能够从需求和资源上下文确定的内容直接记录；一般字段和布局细节交给后续规划。
 
@@ -66,13 +65,13 @@
 本步骤是保存答案，不是重新撰写需求文档：
 
 - 合并已读取的需求、资源信息和本轮回答，完成必要确认后一次写入；中断恢复可保存未确认草稿，但不得把草稿当作已确认输入。
-- 合并采用保留式更新：未被本轮提问的已确认字段不得用默认值覆盖。尤其 `intake.designMode` 是同一次搭建的粘性选择；若本轮没有询问搭建方式，写回值必须与提问前一致。
+- 合并采用字段级保留式更新：本轮问题声明的写回字段使用新回答，其余已确认字段沿用现值；`intake.designMode` 按上面的模式状态转换规则写回。
 - 简短需求使用简短事实、列表和必要的页面标识，不扩写背景、价值分析、完整字段表、页面区块或验收标准；这些设计工作由后续 PRD 与视觉设计负责。用户已提供的字段、关系、流程和页面细项必须保留，不为精简而丢弃，也不重复改写成多份摘要。
 - 不另建 `brief.md`、简报 HTML 或简报附件，不为保存 JSON 单独安排一次模型扩写或用户确认。用户回答清楚后直接记录，不能再展示整份简报询问“是否确认需求”。
 - 已有确认记录且需求未变化时直接复用；后续只补充已确定的视觉映射或更新用户变更涉及的字段，不因阶段切换重写全文或重新生成页面 key。
 
 - `intake` 记录 `firstBuild`、`sourceDetail`（`detailed/brief`）、`designMode`（`fast/plan`）、`confirmed`。未决事项处理完毕后才将 confirmed 设为 true。
-- `navigation` 记录 `type/source/reason`；归属由用户选择时 `source` 为 `user_selected`，`reason` 分别写清用户选择的归属、Agent 根据场景确定的布局及依据，不将推断布局记成用户指定。归属也由用户授权代选时标记 `ai_default`。保存 confirmed brief 前按上表补齐可执行的布局枚举，不把中文选项名或笼统的 `platform` 写入 `type`，不因缺少布局再次提问；自定义导航的 `variant` 为 `side/top/mixed/dock`。顶部浮导使用 `top`，默认浮导或用户指定的通栏样式写入 `reason`，PRD 与视觉设计共同沿用；`dock` 表示底部悬浮胶囊。导航明暗由视觉选择记录。
+- `navigation` 记录 `type/source/reason`；用户明确指定导航方式时 `source` 为 `user_selected`；AI 判断方式时标记 `ai_default`。`reason` 区分用户明确要求与 AI 对方式、布局的判断依据，不将推断记成用户指定。保存 confirmed brief 前按上表补齐可执行的布局枚举，`type` 使用精确枚举；自定义导航的 `variant` 为 `side/top/mixed/dock`。顶部浮导使用 `top`，默认浮导或用户指定的通栏样式写入 `reason`，PRD 与视觉设计共同沿用；`dock` 表示底部悬浮胶囊。导航明暗由视觉选择记录。
 - 业务模块答案写入 `coreFunctions/businessObjects/explicitScope`；与页面范围合问时，分别保存模块事实与 `pageScenes`，不要只保留模块或页面数量。
 - `targetUsers/businessGoals/coreFunctions/businessObjects/pageScenes` 一律保持数组类型；单个目标也写成单元素数组。Plan 的 `visualSelection.themeId` 在保存 confirmed brief 前补齐；导航 type 使用 `platform-l-shape/platform-top/platform-side/custom` 精确枚举。
 - 用户先用“应用/系统”描述背景、后续又明确“只完成/随后完成一个”具体资源并交付时，以具体资源作为本轮执行边界。`explicitScope` 写对应的 forms/processes/reports/pages/delivery 数组并设置 `allowInferredResources:false`；不把“应用”自动扩展为示例数据、工作台、自定义列表或其他未点名资源。
@@ -88,7 +87,7 @@ Plan 的视觉选择直接使用下面的对象结构，不另写 `styleDescript
   "themeId": "airy-structured-clarity",
   "visualDirection": {"label": "轻盈结构", "description": "清晰、简洁、适合持续业务操作", "source": "requirement"},
   "colorStrategy": {"primaryColor": "#1677FF", "primaryColorName": "专业蓝", "source": "requirement", "usage": "主操作与选中态", "surfaceTone": "brand-tinted"},
-  "navigationStyle": {"structure": "side", "tone": "light", "source": "ai_default", "selectionReason": "用户选择宜搭原生导航；模块分组较多，采用平台侧边布局与浅色导航"}
+  "navigationStyle": {"structure": "side", "tone": "light", "source": "ai_default", "selectionReason": "以原生表单操作为主且模块分组较多，AI 采用平台侧边布局与浅色导航"}
 }
 ```