openyida 2026.9.2 → 2026.9.3

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

@@ -2,7 +2,18 @@
 
 > 本文件定义完整应用的 `prd/<项目名>/design.md` 输出格式。`design.md` 是应用级 UI 视觉设计系统，结构以本文件为准，并参考 `references/style-designs/_design-md-template.md` 的字段完整度：先记录设计风格选择依据和主题换肤结果，再写可复用视觉 DNA、token、布局、组件、状态和自检，最后在“实现适配”里写清宜搭运行时主题契约。PRD 只写主题色和风格摘要，完整 UI 设计以本文件为准。
 
-最终 `design.md` 的依据分四层：结构依据本文件和 `_design-md-template.md`；视觉 DNA、布局机制、组件机制和换肤规则依据选中的设计风格文件；业务内容、页面区块、数据来源和操作路径依据当前 PRD；主题 token 依据 Step 2 的主题色来源和所选风格的 `theme_adaptation`。
+最终 `design.md` 的依据分四层：结构依据本文件和 `_design-md-template.md`；视觉 DNA、布局机制、组件机制和换肤规则依据选中的设计风格文件；业务内容、页面区块、数据来源和操作路径依据当前 PRD；主题 token 依据主题系统中的主题色来源和所选风格的 `theme_adaptation`。
+
+## join 稳定引用契约
+
+`yida-prd` 与 `yida-design` 必须使用同一组可定位锚点，`designRefs` 只允许以下形式：
+
+- `themeProfile`
+- `sceneRecipes.<sceneKey>`
+- `components.<componentName>`
+- `states.<stateName>`
+
+`sceneKey` 必须直接取自共享 `requirement-brief.json` 的对应 `pageScenes`：对象项使用其 `key`，字符串项原样使用；不得由两个 artifact owner 各自改写、翻译或重新生成。`componentName` 和 `stateName` 必须与本文件 frontmatter 中的实际 key 完全一致。join 只校验这些稳定锚点，不使用标题文本或自然语言近似匹配。
 
 ## design.md 输出格式
 
@@ -34,12 +45,12 @@ tone: <视觉气质关键词>
 tags: [<业务领域>, <角色>, <数据形态>]
 avoid: [<不适合场景>]
 themeProfile:
-  name: <平台预置 key 或自定义色盘名称>
+  name: <主题名称>
   themeColorSource: <user-specified / application-theme / business-inferred / template-default>
   themeColorToken: <--color-brand1-6 的字面量值>
-  themeDelivery: <app-custom-theme-file / inherit-runtime>
+  themeDelivery: <app-custom-theme-file / current-app-theme>
   customThemeTemplate: yida-design/references/theme/app-custom-theme-template.css
-  customThemeFile: <生成的 .css 路径；平台预置时留空>
+  customThemeFile: <生成的 .css 路径；沿用当前应用主题时留空>
   themeColor: <#RRGGBB>
   navTheme: <light / dark / white / gray>
   colorMode: <宜搭配色模式，如 gradient；不表示暗黑>
@@ -56,9 +67,7 @@ themeAdaptationResult:
   preservedMechanisms:
     - <画布 / 面板 / 布局 / 深色舞台 / 右侧栏等>
 yidaThemeDelivery:
-  delivery: <customThemeStyle.cssUrl / inherit-runtime>
-  themeConsistency: app, custom pages, normal forms, process forms, submission pages, and formDetail pages share the same themeProfile tokens
-  cliApply: openyida update-app <appType> --theme-file <file.css> --nav-theme light --logo-source appIcon --layout side
+  generatedFile: <.cache/openyida/<项目名>/app-theme.css / inherit-current-app-theme>
   customThemeTemplate: yida-design/references/theme/app-custom-theme-template.css
 tokens:
   --color-brand1-1: <明亮品牌浅色或浅 hover 色>
@@ -155,6 +164,15 @@ components:
     maxHeight: <默认 88-120>
   metric-strip:
     height: <默认 64-88>
+sceneRecipes:
+  <sceneKey>:
+    layoutRecipe: <该页面场景的布局配方>
+    componentRefs: [components.<componentName>]
+    stateRefs: [states.loading, states.empty, states.error]
+states:
+  loading: <加载反馈和骨架规则>
+  empty: <空态说明、主操作和高度规则>
+  error: <错误反馈、恢复动作和信息边界>
 inferred_modules:
   quick_actions:
     required_for: [工作台, 仪表盘, 管理后台, 运营首页]
@@ -174,7 +192,7 @@ inferred_modules:
 
 ## 3. 主题色与换肤结果
 
-说明 `themeProfile` 和 `themeAdaptationResult`：主题色来源、是否命中平台主题 key、是否允许传给 `create-app/update-app --theme`、如何替换所选风格的 `replace_tokens`、派生 `derive_tokens`、保留 `preserve_tokens` 和 `visual_dna.invariant`。必须明确“换 hue，不换 DNA；换 token，不换结构”。
+说明 `themeProfile` 和 `themeAdaptationResult`：主题色来源、如何替换所选风格的 `replace_tokens`、派生 `derive_tokens`、保留 `preserve_tokens` 和 `visual_dna.invariant`。必须明确“换 hue，不换 DNA；换 token，不换结构”。
 
 ## 4. 适用场景
 
@@ -203,13 +221,13 @@ inferred_modules:
 | `--color-brand1-6`  | <主色>                      | 主按钮、链接、选中态、重点标签、图表主序列         |
 | `--color-brand1-9`  | <深主色>                    | 强调文字、深底按钮、深色强调块                     |
 | `--color-brand1-10` | <深色或透明强调档>          | 深色 hover、强强调背景、深色主题补充               |
-| `--color-brand-1`   | <移动端品牌浅/透明档 1>     | 移动端壳层、移动端表单、旧版移动组件浅品牌态       |
+| `--color-brand-1`   | <移动端品牌浅/透明档 1>     | 移动端壳层、移动端表单、移动组件浅品牌态           |
 | `--color-brand-2`   | <移动端品牌浅/中档 2>       | 移动端 hover、轻量强调、移动端组件浅色面           |
 | `--color-brand-3`   | <移动端主品牌档 3>          | 移动端主操作、选中态、原生表单移动主色             |
 | `--color-brand-4`   | <移动端深品牌档 4>          | 移动端 active、深色强调、移动壳层深色态            |
 | `--color-group`     | <色组>                      | 图表、分类、状态序列                               |
 
-平台实际生成的 `--color-brand1-1/2/3/5/6/9/10` 必须完整输出，是页面和 PC 端主要消费的品牌色阶；不要补造 `--color-brand1-4/7/8`。`--color-brand-*` 是移动端和部分原生表单/壳层桥接仍会消费的品牌色阶，必须保留，不能删掉、改名或替换成其他 token。
+平台实际生成的 `--color-brand1-1/2/3/5/6/9/10` 必须完整输出，是页面和 PC 端主要消费的品牌色阶；不要补造 `--color-brand1-4/7/8`。`--color-brand-*` 是移动端和部分原生表单/壳层消费的品牌色阶，必须保留，不能删掉、改名或替换成其他 token。
 
 ## 8. 字体规则
 
@@ -302,17 +320,14 @@ inferred_modules:
 
 | 项目         | 规则                                                                                                                                                                         |
 | ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| 自定义色盘   | 颜色可任意设计，必须完整输出平台实际生成的 `--color-brand1-1/2/3/5/6/9/10`，不得补造 `4/7/8`；其中 `--color-brand1-6` 写字面量颜色，CLI 自动保存为 `themeColor`                                    |
-| 应用级换肤   | 从 `app-custom-theme-template.css` 生成 CSS，使用 `--theme-file` 上传为 `customThemeStyle.cssUrl`                                                                             |
-| 联合保存     | `--theme-file`、`--nav-theme`、`--logo-source`、`--layout` 在一次创建或更新流程中保存，避免主题色、导航和 CSS 文件短暂不一致                                                   |
-| 表单运行态   | 运行容器将同一应用主题文件分别加载到普通表单、流程表单、提交页和 formDetail 详情页                                                                                           |
-| 详情页样式   | formDetail 通过应用主题文件中的 `--pod-detail-*`、`--pod-field-preview-*` 等 token 适配                                                                               |
-| 页面局部样式 | 自定义页面和 `FormOpenContainer` iframe 使用同一应用主题文件中的变量，页面局部样式直接引用语义 token                                                                            |
-| 配置边界     | 自定义换肤统一更新应用主题文件，由各运行上下文加载并保持主题色、导航、表单和详情页一致                                                                                       |
+| 自定义色盘   | 颜色可任意设计，必须完整输出平台实际生成的 `--color-brand1-1/2/3/5/6/9/10`，不得补造 `4/7/8`；其中 `--color-brand1-6` 写字面量颜色                                   |
+| 应用级换肤   | 执行 `openyida sample yida-design app-theme --output <app-theme.css>` 复制模板，再按主题色修改对应 token |
+| 自定义页面   | 当前页面在自身运行上下文消费应用主题变量                                                                                                                   |
+| 页面局部样式 | 自定义页面使用自身运行上下文中的应用主题变量，页面局部样式直接引用语义 token                                                                            |
 
 ### 自定义页面实现要求
 
-- 主题直接使用运行容器加载的 CSS 变量；需要换肤时更新应用主题文件，各页面上下文会同步使用新变量。
+- 页面直接使用当前运行上下文中的 CSS 变量。
 - `backgroundLayer` 必须落到根节点背景、`::before` 顶部不规则色块或大面积光洗、`::after` 流光/纹理层；内容层使用相对定位和更高 `z-index`，保证背景不盖住操作区。
 - `surfaceContrast` 必须落到页面根背景和卡片/面板样式：白色/浅色背景配有边框卡片，浅灰或浅彩背景配白色无边框卡片，渐变背景配玻璃感卡片。
 - `flowLight` 动效必须写 `@media (prefers-reduced-motion: reduce)` 停止动画。
@@ -320,18 +335,18 @@ inferred_modules:
 
 ### 平台 JSX 组件实现要求
 
-- 平台 JSX 组件页直接使用运行容器加载的应用主题 CSS 变量。
+- 平台 JSX 组件页直接使用当前运行上下文中的应用主题 CSS 变量。
 - 平台 JSX 组件页面发布后落到平台 `Jsx` 组件，不支持 `import/require`。
 - 平台 JSX 组件页面的图标来源仍只允许 `lucide-react` 或 `@ant-design/icons`，默认 `lucide-react`；但加载方式不是 import，而是已验证运行时脚本/global。emoji 报错时按 `iconSystem` 映射到这两类图标来源，不退成 CSS 图形、字母占位、Unicode 符号、iconfont 或临时 SVG。
 - 使用 ES5 写法，避免平台 JSX 组件编译链不支持的语法；若当前平台 JSX 组件运行环境无法稳定加载图标库，必须去掉非必要图标或改用已验证资源，不能绕过图标规范。
 
 ## 19. 必须包含
 
-列出硬性正向要求。每个视觉 DNA 都必须作为明确必选规则出现。必须包含 `styleDesignSelection`、`themeAdaptationResult` 和 `baseDesignSource`。若 `themeDelivery=app-custom-theme-file`，必须包含模板路径、CSS 产物路径以及 `--theme-file/--nav-theme/--logo-source/--layout` 联合保存命令。
+列出硬性正向要求。每个视觉 DNA 都必须作为明确必选规则出现。必须包含 `styleDesignSelection`、`themeAdaptationResult` 和 `baseDesignSource`。若 `themeDelivery=app-custom-theme-file`，必须包含模板路径和 CSS 产物路径。
 
 ## 20. 禁止项
 
-列出硬性负向约束，覆盖会抹掉每个 DNA 的错误做法。必须包含：不得按行业或颜色直接套风格；不得为了还原风格凭空创造 PRD 未要求的模块；自定义主题名或任意色值不得传给 `create-app --theme`。同时写明新版主题由运行容器在各页面上下文加载同一应用主题文件。
+列出硬性负向约束，覆盖会抹掉每个 DNA 的错误做法。必须包含：不得按行业或颜色直接套风格；不得为了还原风格凭空创造 PRD 未要求的模块。
 
 ## 21. 错误 vs 正确
 
@@ -341,13 +356,13 @@ inferred_modules:
 | ------------------------------------ | ---------------------------------------------------------------------- |
 | 看到绿色业务就选 `teal-rail`         | 先推演用户任务、信息拓扑和 requiredVisualDNA，再选风格；绿色只用于换肤 |
 | 为了套时间轴风格新增不存在的阶段模块 | PRD 没有阶段/里程碑时排除时间轴风格                                    |
-| 自定义色盘仍传 `--theme myBrand`     | 从 CSS 模板生成文件，使用 `--theme-file/--nav-theme/--logo-source/--layout` |
-| 页面、表单、导航或详情页主题不一致 | 检查各运行上下文是否加载同一 `customThemeStyle.cssUrl`，并统一使用对应 CSS 变量 |
+| 重新生成或覆盖整份主题 CSS | 先复制模板，再修改对应 token |
+| 自定义页面颜色与设计结果不一致 | 对照 `design.md` 和当前应用主题变量修正页面用色 |
 | PRD 里复制完整视觉规则               | PRD 只写摘要，完整 UI 规则写 design.md                                 |
 
 ## 22. Agent 使用提示
 
-提供一段简洁提示词，明确告诉 AI 如何使用该 design.md。必须说明选中 style-design 只是设计风格来源，最终事实源是当前项目 `design.md`；视觉 DNA 在内容替换后也要保留；实现新版自定义色盘时必须读取 `yida-design/references/theme/app-custom-theme-template.css`，默认沿用其中 coffee 咖啡色、大圆角和平台实际色阶；只有 `design.md` 明确选择其他主题时才成套替换品牌相关值，并通过 `update-app` 联合保存。
+提供一段简洁提示词，明确告诉 AI 如何使用该 design.md。实现自定义色盘时先执行 `openyida sample yida-design app-theme --output <app-theme.css>` 复制模板，再按主题色修改对应 token；严禁重新生成或覆盖整份 CSS。
 
 ## 23. 交付自检清单
 
@@ -372,8 +387,7 @@ inferred_modules:
 - [ ] `backgroundLayer` 已说明基础画布、装饰方式和是否使用背景 primitive；若选择近白画布，已说明如何通过渐变、细线、素材或内容密度形成背景感。
 - [ ] `surfaceContrast` 已说明页面背景与卡片背景的明确层次搭配，不存在相近或相同背景。
 - [ ] 若使用 `topIrregularWash`、`flowLight` 或 `organicNoise`，已写清对比度、内容栅格和 reduced motion 静态降级。
-- [ ] 自定义色盘没有传给 `create-app/update-app --theme`。
-- [ ] 自定义页面、表单、提交页、formDetail 和表单 iframe 加载同一应用主题文件。
+- [ ] 自定义页面消费应用主题变量。
 - [ ] 不依赖原截图，也能指导生成一个新页面。
 ```
 

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

@@ -1,4 +1,6 @@
-# 输出：prd.md
+# 输出：prd.md（兼容入口，owner 已迁移）
+
+> 完整应用的 PRD artifact 由 `yida-prd/workflow/output-prd.md` 负责。本文件只保留旧引用兼容，不得由 `yida-design` 工作流加载或写入 `prd.md`。
 
 > 本文件定义完整应用的 `prd/<项目名>/prd.md` 输出格式。`prd.md` 记录业务语义、产品设计、页面结构、资源创建顺序、页面实现交付顺序和导航顺序。PRD 不写 UI 视觉设计规范，只写应用主题色和风格摘要，并引用 `design.md` 章节。
 
@@ -27,6 +29,7 @@
 | appType | <已有应用填真实 appType；从零创建时写“待创建后回填”> |
 | corpId | <目标组织 corpId；未知时写“待登录态确认”> |
 | baseUrl | <平台地址，如 https://www.aliwork.com 或私有化域名> |
+| 是否隐藏平台导航 | <否 / 是；默认否。仅自绘应用级导航或用户明确要求隐藏时写“是”，并配置 `hideAppNav='y'`；`isRenderNav=false` 只隐藏当前页面导航> |
 
 ## 3. 数据结构（业务语义，不含细节 ID）
 
@@ -60,7 +63,7 @@
 - 页面定位：<主入口页面 / 核心业务页 / 详情页 / 报表页 / 配置页；说明为什么需要这个页面>
 - 页面目标：<这个页面帮助用户完成什么判断或操作>
 - 页面关系：<从哪里进入、下一步去列表 / 看板 / 表单提交 / 详情 / 报表中的哪一个>
-- 设计文件：<display-page 填 `prd/<项目名>/design.md`；普通表单 / 流程表单写“跟随应用主题文件和表单视觉引导”>
+- 设计文件：<display-page 填 `prd/<项目名>/design.md`；普通表单 / 流程表单填写表单结构与填写路径引导>
 - 设计引用：<引用 design.md 中的章节 ID，例如 themeProfile、sceneRecipes.workbench、components.table、states.empty>
 - 风格理由：<一句话说明该页面为什么采用 design.md 中的对应场景规则>
 - 主题关系：<跟随当前应用主题 / 平台预置主题 / 应用自定义主题文件；只写摘要，具体 token 与 UI 规则见 design.md>
@@ -98,7 +101,6 @@
 | 明暗模式 | <light 默认；dark 只在明确暗色/夜间/高对比/黑金时使用；具体色阶见 design.md> |
 | 页面设计引用 | <逐页列出 designRefs，不复制 design.md 内容> |
 | 素材策略摘要 | <官网/品牌页是否需要真实图片或生成图片；具体视觉表达见 design.md> |
-| 表单主题一致性 | <运行容器在普通表单、流程表单、提交页、formDetail 详情页、自定义页面和表单 iframe 中加载同一份应用主题 CSS> |
 | 一致性要求 | <PRD 中主题色和风格摘要必须与 design.md 保持一致；冲突时以 design.md 为准并修正 PRD 摘要> |
 
 ## 6. 业务逻辑与交互状态
@@ -108,8 +110,6 @@
 | 表单提交后 | <刷新列表 / 回到当前工作台 / 触发流程 / 更新状态> |
 | 新增/提交入口 | <PC 侧边抽屉 iframe 承载页面级隐藏导航的 `submission/{formUuid}?isRenderNav=false`，抽屉默认半屏 `50vw`；移动端整页或新页打开；必要时用 `update-form-config` 持久化表单设置 `isRenderNav=false`> |
 | 详情查看 | <PC 侧边抽屉 iframe 承载页面级隐藏导航的 `formDetail/{formUuid}?formInstId={formInstId}&navConfig.layout=1180&isRenderNav=false`，抽屉默认半屏 `50vw`；移动端整页或新页打开；formInstId 来自真实数据记录并优先取 row.formInstId，缺失时禁用详情入口> |
-| 应用主题文件 | <通过 `create-app/update-app --theme-file/--nav-theme/--logo-source/--layout` 联合保存，themeColor 从 CSS 的 --color-brand1-6 自动提取，提交页和详情页由服务端加载同一 CSS> |
-| 详情页样式 | <通过应用主题 CSS 的 `--pod-detail-*`、页面、卡片和字段预览 token 适配，不写表单 Schema JS> |
 | 数据变更 | <自动计算、状态流转、通知或提醒> |
 | 权限规则 | <角色能看、能改、能审批的边界> |
 | 空状态 | <无数据时的说明、主操作入口和下一步> |
@@ -135,9 +135,9 @@
 | --- | --- | --- | --- |
 | 1 | 应用 | 承载所有页面、表单、流程和导航 | `appType` |
 | 2 | 普通表单 / 流程表单 | 自定义页面需要表单 URL、字段语义和数据来源 | `formUuid`、字段映射 |
-| 3 | 应用主题文件配置 | 提交页、详情页、自定义页面和应用主题色必须一致 | `themeColor`、`navTheme`、`customThemeStyle.cssUrl` |
+| 3 | 应用主题与导航配置 | 在应用级统一配置主题，并明确是否隐藏平台导航 | `themeFile`、`themeColor`、`navTheme`、`logoSource`、`layoutDirection`、`hideAppNav` |
 | 4 | 初始示例数据 | 页面需要读取真实表单记录，完整应用默认写入 1-3 条核心业务记录 | 写入数量、抽查结果 |
-| 5 | 主自定义页面 / 业务自定义页面 | 页面消费表单入口、表单数据和主题色配置 | `displayPageFormUuid` |
+| 5 | 主自定义页面 / 业务自定义页面 | 页面消费表单入口和表单数据 | `displayPageFormUuid` |
 | 6 | 报表 / 数据看板数据源 | 看板或大屏需要汇总指标时创建 | `reportId` 或数据源信息 |
 | 7 | 发布与导航排序 | 页面发布成功后再调整导航展示 | 发布 URL、导航状态 |
 
@@ -170,7 +170,7 @@
 | --- | --- |
 | 主页面访问 | <页面发布成功，打开后首屏能完成核心判断> |
 | 数据录入 | <表单能提交，提交后页面能刷新或回到正确入口> |
-| 表单主题和详情页样式 | <应用主题文件已在普通表单、流程表单、提交页、formDetail、自定义页面和表单 iframe 生效，主题色与语义变量一致> |
+| 主题配置与页面消费 | <应用主题文件已配置，自定义页面已消费对应主题变量> |
 | 初始示例数据 | <完整应用默认已为核心普通表单写入 1-3 条业务化示例记录并 query 抽查；跳过时说明原因> |
 | 数据查看 | <默认使用表单数据管理页；自定义列表 / 看板 / 详情显示真实数据或空态> |
 | 权限 / 流程 | <权限规则或流程节点生效> |

package/yida-skills/skills/yida-design/workflow/step-1-read-brief.md

@@ -0,0 +1,14 @@
+# 读取视觉设计输入
+
+完整应用视觉 artifact 只读取 `.cache/openyida/<项目名>/requirement-brief.json`，不等待或读取本轮并行生成的 `prd.md`。
+
+## 检查
+
+1. 文件存在且 JSON 可解析，`schemaVersion=1`。
+2. 读取行业、目标用户、业务目标、核心功能、业务对象、页面场景、品牌和色彩偏好。
+3. `explicitScope` 非空时只为明确范围内的页面场景设计视觉规则，不增加同级页面。
+4. 会改变视觉方向的 `openQuestions` 未解决时，本 artifact 保持未完成。
+
+## 产出
+
+形成视觉输入摘要：主题目标、视觉气质、页面场景候选、信息密度、设备约束和显式范围。随后进入主题、结构、视觉状态和 `design.md` 输出步骤。

package/yida-skills/skills/yida-design/workflow/step-2-theme-system.md

@@ -1,31 +1,37 @@
-# Step 2：选择主题色和 token
+# 选择主题色和 token
 
 > 这一步选择应用主色、辅助色、字体层级、组件基调和宜搭 token 作用域。
 
 视觉方向要从“高级 / 简洁 / 商务”继续落细。PRD 只写应用主题色和风格摘要；`design.md` 写完整 `themeProfile`、主题 token、主色、辅助色、中性色、字体层级和组件基调。
 
-已有应用里的单页重构/美化读取并沿用当前应用主题。用户要求完全不同视觉、独立品牌/活动页、沉浸页、自绘壳或指定新品牌色时，也必须生成或更新应用主题文件，不能在页面代码中创建独立主色。
+已有应用里的单页重构/美化读取并沿用当前应用主题。用户要求更换主色时，更新应用级主题文件，不在页面代码中创建或向上层写入另一套主题。
 
 ## 选择主题色
 
-先确定主题色来源，再确定是否能传给应用主题接口。主题色来源优先级如下：
+先确定主题色来源，再生成应用主题文件。主题色来源优先级如下：
 
 | 优先级 | themeColorSource | 触发条件 | 输出规则 |
 | --- | --- | --- | --- |
 | 1 | `user-specified` | 用户明确给出色值、品牌色、主题 key 或换肤要求 | 原样记录用户意图；命中平台 key 才允许传 `--theme`，任意色值写 token |
-| 2 | `application-theme` | 已有应用、工作区、历史命令输出中能读到 `theme`、`colour`、`themeColor`、`navTheme` 或 `customThemeStyle.cssUrl` | 单页美化和已有应用改造默认跟随；页面主按钮、链接、选中态和图表主序列跟随应用主题 |
+| 2 | `application-theme` | 已有应用或工作区中能读到当前 `theme`、`colour`、`themeColor` 或 `navTheme` | 单页美化和已有应用改造默认跟随；页面主按钮、链接、选中态和图表主序列跟随应用主题 |
 | 3 | `business-inferred` | 无明确主题证据，需要根据行业、品牌气质、业务情绪和视觉目标推导 | 设计任意合法的自定义品牌色盘，写应用主题 token 和文件交付方案 |
-| 5 | `template-default` | 没有任何主题证据且无法稳定推导业务色彩 | 临时使用 Step 5 所选 style-design 的默认 brand token，并明确标记为兜底 |
+| 4 | `template-default` | 没有任何主题证据且无法稳定推导业务色彩 | 临时使用 UI 视觉设计阶段所选 style-design 的默认 brand token，并明确标记为兜底 |
 
 1. 先判断业务气质：行业、目标用户、品牌关键词、业务情绪、视觉目标，以及是否需要亲和/专业/活力/稳重/科技/自然感。
-2. 基于 `../references/theme/app-custom-theme-template.css` 生成完整 CSS。新版主题必须完整声明平台实际生成的 `--color-brand1-1/2/3/5/6/9/10`，同时保留 `--color-brand-1` ~ `--color-brand-4` 和 `--color-group`；不要补造 `--color-brand1-4/7/8`，也不能只声明页面当前直接使用的几个 token。`--color-brand1-6` 必须是字面量颜色，CLI 会校验实际色阶并自动将它保存为 `themeColor`。
-3. 新建应用通过 `create-app --theme-file/--nav-theme/--logo-source/--layout` 联合保存；已有应用使用相同的 `update-app` 参数。运行容器在自定义页面、表单、提交页、formDetail 和表单 iframe 中加载该主题文件。
+2. 在 `design.md` 中记录主题色、`navTheme`、`logoSource` 和 `layoutDirection`。
+3. 实现阶段执行以下命令复制主题模板：
+
+   ```bash
+   openyida sample yida-design app-theme --output .cache/openyida/<项目名>/app-theme.css
+   ```
+
+4. 打开复制后的 `app-theme.css`，按主题色修改对应 token。严禁重新生成或覆盖整份 CSS。主色写入 `--color-brand1-6`；保留 `--color-brand1-1/2/3/5/6/9/10`、`--color-brand-1` ~ `--color-brand-4` 和 `--color-group`；严禁补造 `--color-brand1-4/7/8`。
 5. `podBlue`、`podGreen`、`podOrange` 只是常用浅底候选，不是固定默认。不要因为没有特别说明就自动回到 #1677ff，也不要套用“科技=蓝、宠物=橙、法律=蓝”这类行业刻板配色。
-6. 主题色只作为 Step 5 所选设计风格的换肤输入；除用户明确要求深色/夜间/高对比外，不用主题色反向决定风格。
+6. 主题色只作为后续所选设计风格的换肤输入；除用户明确要求深色/夜间/高对比外，不用主题色反向决定风格。
 
 ## 品牌 token 语义
 
-`design.md` 必须写清 `--color-brand1-*` 与 `--color-brand-*` 的语义。`--color-brand1-1/2/3/5/6/9/10` 是新版主题实际生成且必须具备的品牌色阶，由应用自定义主题文件统一提供；`4/7/8` 不在平台契约内，不得由 AI 猜测补齐。`--color-brand1-*` 是页面和 PC 端主要消费的品牌色阶，`--color-brand-*` 是移动端和部分原生表单/壳层桥接仍会消费的品牌色阶，不能删掉、改名或替换为别的变量。
+`design.md` 必须写清 `--color-brand1-*` 与 `--color-brand-*` 的语义。`--color-brand1-1/2/3/5/6/9/10` 是平台主题契约要求的品牌色阶，由应用自定义主题文件统一提供；`4/7/8` 不在平台契约内，不得由 AI 猜测补齐。`--color-brand1-*` 是页面和 PC 端主要消费的品牌色阶，`--color-brand-*` 是移动端和部分原生表单/壳层消费的品牌色阶，不能删掉、改名或替换为别的变量。
 
 | token | 语义 | 典型用途 |
 | --- | --- | --- |
@@ -36,7 +42,7 @@
 | `--color-brand1-6` | 主品牌色 | 主按钮、链接、选中态、重点标签、图表主序列 |
 | `--color-brand1-9` | 深主色 | 深色强调、深底按钮、强调标题、深色场景锚点 |
 | `--color-brand1-10` | 深色或透明强调档 | 深色 hover、强强调背景、深色主题补充 |
-| `--color-brand-1` | 移动端品牌浅/透明档 1 | 移动端壳层、移动端表单、旧版移动组件浅品牌态 |
+| `--color-brand-1` | 移动端品牌浅/透明档 1 | 移动端壳层、移动端表单、移动组件浅品牌态 |
 | `--color-brand-2` | 移动端品牌浅/中档 2 | 移动端 hover、轻量强调、移动端组件浅色面 |
 | `--color-brand-3` | 移动端主品牌档 3 | 移动端主操作、选中态、原生表单移动主色 |
 | `--color-brand-4` | 移动端深品牌档 4 | 移动端 active、深色强调、移动壳层深色态 |
@@ -50,7 +56,7 @@ AI 默认直接使用模板内 coffee 咖啡色色阶和大圆角层级。若 `d
 
 - 平台导航、顶部壳层或应用菜单可见时，应用主题色是页面主色来源；页面主按钮、链接、选中态、重点标签、图表主序列和表单入口都使用应用主题 `--color-brand1-*`。
 - `design.md` 负责布局配方、信息密度、卡片形态、图表语言和视觉 DNA；当 `design.md` 色相与应用主题不同，把 `design.md` 色相降为辅助色、浅背景、分组色或装饰色。
-- 需要主色明显不同于当前应用主题时，PRD 记录业务原因；`design.md` 写 `themeRelation`、token 和应用主题文件交付方式，后续通过 `update-app --theme-file/--nav-theme/--logo-source/--layout` 统一更新应用。
+- 需要主色明显不同于当前应用主题时，PRD 记录业务原因；`design.md` 写 `themeRelation`、token 和应用主题文件。
 - 若截图或预览中出现左侧导航选中态与页面主操作颜色不一致，优先把页面主操作和高频强调色改回应用主题；只有用户确认要改变整个应用主题时，再调用应用主题配置能力。
 
 ## 写颜色角色
@@ -62,7 +68,7 @@ AI 默认直接使用模板内 coffee 咖啡色色阶和大圆角层级。若 `d
 - 明暗模式：默认 `light`；`design.md` 的 `themeProfile.navTheme` 保持 `light`。
 - `design.md` 的 `themeProfile.colorMode` 是宜搭配色模式，例如 `gradient`，不表示暗黑模式。
 
-新版应用不传 `--theme`。生成应用主题 CSS 后，新建执行 `openyida create-app --name "<应用名>" --theme-file <file.css> --nav-theme light --logo-source appIcon --layout l_shape`，未显式传 `--layout` 时 CLI 也默认使用 L 型导航；已有应用执行 `openyida update-app <appType> --theme-file <file.css> --nav-theme light --logo-source appIcon --layout side`。两条链路都会把系统应用图标同步为 `iconName%%--color-brand1-6 对应 HEX`，外链或上传图片图标保持原值。
+通过 CLI 复制并定点修改应用主题 CSS 后，将主题文件路径、`navTheme`、`logoSource` 和 `layoutDirection` 写入 `design.md`，交给应用创建或更新阶段统一配置。平台负责整套应用的主题一致性；只有 `YidaCodeCanvas` 页面源码需要在组件内部使用主题 token。
 
 ## 写字体层级
 
@@ -82,12 +88,12 @@ AI 默认直接使用模板内 coffee 咖啡色色阶和大圆角层级。若 `d
 
 ## 写组件基调
 
-统一按钮、卡片、表格、标签、抽屉、弹窗、图标、空态、加载态和错误态。应用级换肤写入自定义主题 CSS 文件，运行容器在页面和表单 iframe 中加载同一文件并提供一致的变量。
+统一按钮、卡片、表格、标签、抽屉、弹窗、图标、空态、加载态和错误态，并写入 `design.md` 与应用主题 CSS。
 
 ## 产出
 
 ```markdown
-PRD 主题摘要：
+供 PRD owner join 的主题摘要：
 - 应用主题色：<平台预置 key 或自定义色盘名称>
 - 风格摘要：<2-3 个业务风格关键词>
 - 主题交付摘要：<平台预置 / 应用自定义主题文件 / 继承当前应用>
@@ -96,9 +102,9 @@ design.md Theme Profile：
 - themeProfile.name：<平台预置 key 或自定义色盘名称>
 - themeColorSource：<user-specified / application-theme / business-inferred / template-default>
 - themeColorToken：<CSS 中 --color-brand1-6 的字面量值>
-- themeDelivery：<app-custom-theme-file / inherit-runtime>
+- themeDelivery：<app-custom-theme-file / current-app-theme>
 - customThemeTemplate：yida-design/references/theme/app-custom-theme-template.css
-- customThemeFile：<生成的 .css 路径；平台预置时留空>
+- customThemeFile：<复制模板并修改 token 后的 .css 路径；平台预置时留空>
 - themeColor：<#RRGGBB>
 - navTheme：<light / dark / white / gray>
 - colorMode：<宜搭配色模式，如 gradient；不表示暗黑>
@@ -108,4 +114,4 @@ design.md Theme Profile：
 
 ## 下一步
 
-→ [Step 3：规划页面和导航](step-3-information-architecture.md)
+→ [页面结构和交互设计](step-4-wireframe-interaction.md)

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

@@ -1,4 +1,4 @@
-# Step 4：页面结构和交互设计
+# 页面结构和交互设计
 
 > 低保真不追求好看，先把结构、区块和操作路径定清楚。
 
@@ -44,9 +44,9 @@
 - 功能契约：<保留的数据源/字段映射/按钮动作/筛选逻辑/提交 URL/权限/状态>
 - 响应式策略：<PC / 移动端差异>
 - 原生表单入口：<新增/提交/编辑打开方式>
-- pageSpecHandoff 草稿：<pageStructure/scene/contentBlocks/themeSummary/designFile/designRefs/dataBinding/primaryAction；视觉源码槽位待 Step 5 写入 design.md>
+- pageSpecHandoff 草稿：<pageStructure/scene/contentBlocks/themeSummary/designFile/designRefs/dataBinding/primaryAction；视觉源码槽位待 UI 视觉设计阶段写入 design.md>
 ```
 
 ## 下一步
 
-→ [Step 5：UI 视觉和状态设计](step-5-visual-states.md)
+→ [UI 视觉和状态设计](step-5-visual-states.md)

package/yida-skills/skills/yida-design/workflow/step-5-visual-states.md

@@ -1,4 +1,4 @@
-# Step 5：UI 视觉和状态设计
+# UI 视觉和状态设计
 
 > 这一步写 `design.md` 草稿。`design.md` 规定所有页面共同遵守的 UI 视觉、组件样式、状态样式和响应式规则。
 
@@ -8,12 +8,12 @@
 
 1. 读取 [design.md 生成规则](../references/style-design-selection.md)。
 2. 读取 [style-design 风格注册表](../references/style-designs/registry.md)，再读取 `_design-md-template.md`。
-3. 从 Step 1-4 产物推演 `inferredUserTask`、`inferredInformationTopology`、`interactionFocus` 和 `requiredVisualDNA`。用户通常不会主动描述视觉结构，agent 必须从业务对象、数据形态、页面区块和操作路径中推演。
+3. 从共享需求简报、主题系统和页面结构产物推演 `inferredUserTask`、`inferredInformationTopology`、`interactionFocus` 和 `requiredVisualDNA`。用户通常不会主动描述视觉结构，agent 必须从业务对象、数据形态、页面区块和操作路径中推演。
 4. 按 `业务任务匹配 30% + 信息拓扑匹配 25% + 视觉 DNA 命中 30% + 实现稳定性 10% - 风险扣分 5%` 选择唯一设计风格，并把对应 `style-designs/*.md` 记录为 `baseDesignSource`；纯表单、长文、品牌营销、移动端单任务、未要求暗色时要过滤明显不合适的风格。
 5. 读取被选中的 style-design 风格文件，抽取 `visual_dna`、`theme_adaptation`、`layout_stability`、`quality_anchors`、`components` 和 `modules`。
-6. 根据 Step 2 的主题色来源和主题色输入执行换肤：替换风格文件中的 `theme_adaptation.replace_tokens`，派生 `derive_tokens`，保留 `preserve_tokens` 和 `visual_dna.invariant`。主题色只换 hue，不换 DNA，不改结构。
+6. 根据主题系统中的主题色来源和主题色输入执行换肤：替换风格文件中的 `theme_adaptation.replace_tokens`，派生 `derive_tokens`，保留 `preserve_tokens` 和 `visual_dna.invariant`。主题色只换 hue，不换 DNA，不改结构。
 7. 需要判断详略时读取唯一示例 `generated-business-design.example.md`；只学习结构和粒度，不复制示例业务、色盘、字段、页面顺序或组件组合。
-8. 读取 [视觉脚手架配方库](../references/visual-scaffold-recipes.md)，把应用内各类页面映射到统一 `visualScaffold` 规则。
+8. 读取 [视觉结构配方库](../references/visual-scaffold-recipes.md)，把应用内各类页面映射到统一 `visualScaffold` 规则。
 9. 读取 [页面质量门禁](../references/page-quality-gates.md)，把质量门禁补进 `acceptanceChecks`。
 10. 写清 `roundedRule`、`densityRule` 与 `breathingRule` 的具体数值；默认业务页是圆润高密且有呼吸感，不得只写“圆润 / 舒适 / 留白合理 / 有呼吸感”。
 11. 完整应用内默认保持同一套主设计系统；页面场景差异很大时，在同一份 `design.md` 里写页面场景变体，不为每个页面另起独立设计文件。
@@ -115,4 +115,4 @@
 
 ## 下一步
 
-→ [Step 6：写入 prd.md 和 design.md](step-6-handoff.md)
+→ [写入 design.md](step-6-handoff.md)

package/yida-skills/skills/yida-design/workflow/step-6-handoff.md

@@ -1,62 +1,29 @@
-# Step 6：写入 prd.md 和 design.md
+# 写入 design.md
 
-> 本流程把业务设计结果分别写入 `prd/<项目名>/prd.md` 和 `prd/<项目名>/design.md`。这里不写 JSX/TSX，也不直接输出 `page-spec.json`；页面实现阶段由 `yida-app` 同时读取 PRD 与 design.md，只有走页面生成器或需要稳定交接时才派生 `page-spec.json`。
+本步骤只写入 `prd/<项目名>/design.md`。完整应用的 `prd.md` 由并行的 `yida-prd` owner 生成；本技能不得等待、读取或覆盖本轮 PRD。
 
-## 写 prd.md
+## 必填内容
 
-| 模块 | 必填内容 |
-| --- | --- |
-| 应用基本信息 | 应用名称、应用类型、业务目标、核心用户、使用场景、核心对象、主题色、权限口径 |
-| 应用配置 | `appType`、`corpId`、`baseUrl`；已有应用填真实值，从零创建时写待创建/待确认 |
-| 数据结构 | 普通表单、流程表单、字段语义、Divider 分组、流程节点 |
-| 页面与功能设计 | 按页面逐节写清页面类型、页面定位、页面目标、页面关系、关联表单/流程/报表/详情页、需要设计的区块、布局骨架、核心组件、主操作、PC/移动端差异；自定义页面逐区块写清目的、数据来源、主操作和状态 |
-| 应用主题与风格摘要 | 只写 design.md 引用、应用主题色、风格关键词和业务理由；完整 UI 设计系统放在 `design.md` |
-| 业务逻辑与状态 | 表单提交后行为、新增/提交入口、详情查看、权限、空/载/错态 |
-| 资源蓝图 | 应用、表单、流程、自定义页面、报表等资源清单和创建策略 |
-| 资源创建顺序 | 先应用，再表单/流程，再自定义页面，再报表/数据源，最后发布与导航排序 |
-| 页面实现交付顺序 | 按页面开发和验收顺序排列，主页面先交付，核心业务页随后，辅助页靠后 |
-| 导航顺序 | 按用户入口排序，主入口靠前，业务办理/数据管理/经营分析/系统配置分组明确，并写清导航呈现方式 |
-| 验收标准 | 主页面访问、数据录入、数据查看、权限/流程、视觉一致性、导航可用 |
+- frontmatter：version、design_id、themeProfile、tokens、visual_dna、scenes、density、layout、tone；
+- 设计风格选择依据、主题色与换肤结果、视觉 DNA；
+- `visualScaffold`、`backgroundLayer`、`surfaceMaterial`、`surfaceContrast`；
+- `colorRoles`、`depthRule`、`roundedRule`、`densityRule`、`breathingRule`；
+- 组件 default/hover/active/focus/disabled/loading/selected/error 状态；
+- 各 `pageScenes` 对应的 `sceneRecipes` 和稳定 `designRefs`；
+- loading、empty、error、mobile、reduced motion、焦点与对比度；
+- CSS 变量和 Yida Application Theme Delivery Contract。
 
-## 写三种顺序
+## 写入前检查
 
-| 顺序类型 | 含义 | 默认规则 |
-| --- | --- | --- |
-| 资源创建顺序 | `yida-app` 真正创建资源的依赖顺序 | 应用 → 表单/流程 → 自定义页面 → 报表/数据源 → 发布/导航 |
-| 页面实现交付顺序 | 页面开发和验收的先后顺序 | 主页面 / 工作台 / 官网首页 → 核心列表/管理页 → 详情/看板/大屏 → 辅助页 |
-| 导航顺序 | 用户在应用导航中看到的展示顺序 | 门户/首页 → 业务办理 → 数据管理 → 经营分析 → 系统配置 |
+1. 已读取共享需求简报及 [design.md 输出格式](output-design.md)。
+2. 已读取 [页面质量门禁](../references/page-quality-gates.md)。
+3. 视觉规则只覆盖 `explicitScope` 或简报中的页面场景，不添加业务资源。
+4. `designRefs` 使用稳定章节 ID，供 join owner 与页面实现阶段引用。
 
-## 写 design.md
+## 完成条件
 
-| 模块 | 必填内容 |
-| --- | --- |
-| frontmatter | version、design_id、baseDesignSource、styleDesignSelection、themeProfile、themeAdaptationResult、yidaThemeDelivery、tokens、visual_dna、scenes、density、layout、tone |
-| 总览 / 设计风格选择依据 / 主题色与换肤结果 / 适用场景 / 视觉氛围 | 可复用设计意图、选中风格和排除风格、主题色来源、换肤策略、适合与不适合场景、密度、气质和页面组织方式 |
-| 视觉 DNA / 设计母体 | 所有页面都必须保留的 2-5 个视觉 DNA，每个包含证据、规则、实现钩子、失败表现和置信度 |
-| 色彩角色 / 字体 / 布局 / 深度 / 形状 | token、字体栈、字号、网格、间距、层级、圆角和材质规则 |
-| 组件样式 / 快捷入口区域 | 按组件写 default、hover、active、focus、disabled、loading、selected、error；工作台等必须写快捷入口区域 |
-| 页面结构配方 | 中性槽位、`visualScaffold`、`surfaceMap`、`componentRecipe` |
-| 状态与交互 / 响应式 / 可访问性 | loading、empty、error、mobile、reduced motion、焦点和对比度 |
-| 实现适配 | CSS 变量、Yida / YidaCodeCanvas 容器重置、`Yida Application Theme Delivery Contract`、YidaCodeCanvas / 平台 JSX 组件消费规则 |
-| 包含项 / 禁止项 / 错误 vs 正确 / Agent 使用提示 / 交付自检 | 保护视觉 DNA、contentBlocks 推荐 8-10 个区块以上、禁大白卡、应用自定义主题文件交付、实现前读取双文件 |
-
-## 写文件前检查
-
-1. 读取 [PRD 输出格式](output-prd.md)。
-2. 读取 [design.md 输出格式](output-design.md)。
-3. 读取 [页面质量门禁](../references/page-quality-gates.md)，确认每个 display 页面都有薄 `pageSpecHandoff`，并且 `design.md` 视觉契约完整。
-4. 用 Step 1-4 的产物填充 `prd.md`，只写业务、资源、页面结构和 design 引用。
-5. 用 Step 2 和 Step 5 的产物填充 `design.md`，写完整视觉系统、场景配方、组件规则和状态规则。
-6. 将 PRD 写入 `prd/<项目名>/prd.md`，将设计契约写入 `prd/<项目名>/design.md`。
-7. 确认 PRD 已写应用级上下文 `appType/corpId/baseUrl`；表单、字段、页面等创建后的细节 ID 由实现阶段写入 `.cache/<项目名>-schema.json`。
-
-## 完成标准
-
-- `prd/<项目名>/prd.md` 包含 PRD 必填内容。
-- `prd/<项目名>/design.md` 包含 design.md 必填内容。
-- 表单/流程在资源创建顺序中位于自定义页面之前。
-- 页面实现交付顺序写清每个页面的实现重点、依赖资源和验收点。
-- 导航顺序写清分组和页面展示顺序。
-- 表单提交入口保留原生表单能力，并说明 PC/移动端打开方式。
-- 每个 display 页面都有 `pageSpecHandoff`，包含 `pageStructure`、`scene`、`contentBlocks`、`themeProfile`、`designFile`、`designRefs`、数据来源和主操作。
-- 页面实现交付说明明确：创建或更新页面前必须同时读取 `prd.md` 与 `design.md`。
+- `prd/<项目名>/design.md` 存在且非空。
+- frontmatter 包含 version、design_id、baseDesignSource、styleDesignSelection、themeProfile、themeAdaptationResult、yidaThemeDelivery、tokens、visual_dna、scenes、density、layout、tone。
+- 主题、应用主题文件交付、视觉、布局、材质、圆角、密度、呼吸感、组件、状态和响应式契约完整。
+- 每个目标 display 页面场景都有 `sceneRecipes` 或可定位 `designRefs`。
+- 没有写入 `prd.md`、页面源码或真实资源 ID。

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

@@ -10,7 +10,7 @@ description: 宜搭应用左侧导航分组管理。查询导航树、新建/重
 - 操作前必须已知 `appType`；不要编造。
 - 移动页面前先执行 `openyida nav-group list <appType>` 确认 `navUuid` / `formUuid` 和目标分组。
 - 完整应用首次生成后，基于 PRD 的导航顺序决定根导航顺序，页面实现交付顺序和资源创建顺序不直接等同于导航顺序。
-- **PRD 导航优先**：PRD 写明页面/表单清单顺序时，使用 `openyida nav-group order <appType> <页面/表单...>`；PRD 只写宽泛分组或缺少导航顺序时，使用 `openyida nav-group auto-order <appType>` 兜底。
+- **PRD 导航优先**：PRD 写明页面/表单清单顺序时，使用 `openyida nav-group order <appType> <页面/表单...>`；PRD 只写宽泛分组或缺少导航顺序时，使用 `openyida nav-group auto-order <appType>` 或发布命令的 `--auto-nav-order` 兜底。两种排序互斥，同一 Run 只执行一次，不生成逐项 `move` 循环。
 - **兜底自动排序优先级**：门户/首页/工作台入口 > 自定义展示页面 > 流程表单 > 普通表单。这是工具兜底顺序，不替代 PRD 导航顺序。
 - **默认原则：面向决策者的总览/驾驶舱看板作为应用门面靠前，数据录入/明细表单在其后。** 判断某个看板是否靠前，看它是不是主要「查看/决策」入口：
   - 有独立总览首页看板时：`总览首页看板 → 专题看板 → 核心业务表单 → 明细/配置表单`。
@@ -75,6 +75,8 @@ openyida nav-group auto-order <appType>
 
 `auto-order` 会读取当前根导航并按默认优先级排序：门户/首页/工作台入口 > 自定义展示页面 > 流程表单 > 普通表单；系统导航保持在系统区域，未识别分组和其他项排在后面。适合 PRD 没有明确页面清单时做轻量兜底。
 
+`order` 和 `auto-order` 写前会比较完整导航结构；顺序已正确时返回 `changed=false` 且不写入。写入后只有完整回读一致才成功，并返回 `readbackVerified=true`。结果不确定时不要重试，只执行返回的 `nextStep` 查询当前导航。
+
 示例 A：电商销售系统只有「销售数据表单 + 双11看板 + 618看板」，看板是运营主管的主要决策视图，把看板作为门面靠前、录入表单在后：
 
 ```bash

package/yida-skills/skills/yida-page-config/SKILL.md

@@ -66,7 +66,7 @@ openyida save-share-config <appType> <formUuid> <url> <isOpen> [openAuth]
 
 ## 页面级导航
 
-用户明确要求页面隐藏导航、无导航或全屏无框时执行：
+用户明确要求页面隐藏导航、无导航或全屏无框，或者 `yida-app` 的 PRD 已把主页面明确标记为 `entryMode=standalone` 时执行：
 
 ```bash
 openyida update-form-config <appType> <formUuid> false "<页面标题>"
@@ -74,6 +74,8 @@ openyida update-form-config <appType> <formUuid> false "<页面标题>"
 
 这条命令只设置页面级 `isRenderNav=false`。自定义页要自绘应用侧边或顶部导航时，先使用 `openyida update-app <appType> --hide-app-nav` 隐藏应用导航；两者不是同一配置。
 
+完整应用的独立入口必须在写入后再执行 `openyida get-form-config <appType> <formUuid> --json`。只有回读确认 `isRenderNav=false` 后，才输出不带查询参数的 `/custom/{formUuid}`；失败时保留 `/workbench`，不把 URL 参数当作持久配置成功证据。
+
 创建 dashboard 页面时，只有用户明确要求隐藏页面导航才使用：
 
 ```bash

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

@@ -0,0 +1,48 @@
+---
+name: yida-prd
+description: 读取完整应用共享需求简报，独立生成 prd/<项目名>/prd.md，负责业务、资源、页面、顺序和验收契约。
+---
+
+# yida-prd
+
+本技能是完整应用 PRD artifact 的唯一 owner。它读取 `yida-requirement-analysis` 生成的共享简报，生成 `prd/<项目名>/prd.md`；不生成 `design.md` 或页面源码。
+
+## 使用场景
+
+- 从零搭建或补齐完整应用：共享简报 ready 后启动，可与 `yida-design` 并行。
+- 已有会议需求稿，需要整理成完整应用 PRD：先形成共享简报，再运行本技能。
+- 只做视觉美化、页面实现、字段或权限操作：使用对应单点技能。
+
+## 产物生命周期
+
+- start：`.cache/openyida/<项目名>/requirement-brief.json` 已存在且可解析。
+- end：`prd/<项目名>/prd.md` 已写入并通过下方完成条件；只写完部分章节不算结束。
+- failure：PRD 不完整时只重跑本技能，不重跑或覆盖已经完成的 `design.md`。
+
+## 标准流程
+
+1. 读取 [共享需求简报](workflow/step-1-read-brief.md)。
+2. 按 [页面与导航规划](workflow/step-2-information-architecture.md) 形成业务资源蓝图。
+3. 按 [PRD 输出格式](workflow/output-prd.md) 写入 `prd/<项目名>/prd.md`。
+
+## 核心规则
+
+1. PRD 只写业务目标、角色、对象、字段语义、资源、页面结构、数据来源、业务逻辑、三种顺序和验收标准。
+2. 视觉规则只写主题色和风格摘要，并通过 `designFile` / `designRefs` 引用并行产出的 `design.md`。
+3. 用户存在 `explicitScope` 时，页面、表单、流程、报表和本轮交付范围不得扩展。
+4. `appType`、`formUuid`、`fieldId`、`processCode` 等真实 ID 不得编造；运行 ID 由实现阶段写入 `.cache/<项目名>-schema.json`。
+5. 每个 display 页面必须有 `pageSpecHandoff`，明确场景、区块、数据来源、主操作、`designFile` 和 `designRefs`。
+
+## 完成条件
+
+- `prd/<项目名>/prd.md` 存在。
+- PRD 包含资源创建顺序、页面实现交付顺序、导航顺序和验收标准。
+- 资源蓝图覆盖必要表单、流程、页面及明确要求的报表/集成/权限。
+- 每个 display 页面都有可供 join 校验的 `pageSpecHandoff`。
+- 没有写入 `design.md` 或页面源码。
+
+## 参考
+
+- [应用结构参考](references/app/blueprint.md)
+- [导航模式参考](references/app/navigation-patterns.md)
+- [角色旅程参考](references/app/role-journey.md)