openyida 2026.9.21 → 2026.9.22-beta.1

package/yida-skills/skills/yida-design/references/native-form-styles.md

@@ -1,208 +0,0 @@
-# 表单样式与提交页背景
-
-表单通过平台已有变量表达不同风格。按 [整体主题规则](application-theme-consistency.md#导航与应用框架) 将提交、编辑和记录详情与导航、应用框架、自定义页面一起设计，补齐控件、标签、分组、背景和状态。先沿用选中主题，再按填写场景确定具体值，同类表单保持一致。
-
-## 应用风格先于表单选型
-
-**表单支持可组合组件布局，并沿用应用视觉风格。** 顶部、左侧、主体、右侧和字段之间都可放置组件。Tab/切换负责内容切换，按钮组提供操作入口，图片或图形建立视觉焦点，标题与 `Divider`、分栏和状态区组织层级与节奏，字段负责数据采集。每个组件都要有明确作用。普通业务分组和章节分隔使用 `Divider`，横向字段组合使用 `ColumnContainer`。
-
-左侧栏、顶部区、主次分栏和字段间组件都是可用版式。表单支持组合 Tab、按钮、图片、状态区、`Divider`、`ColumnContainer` 和业务字段。为每张表单在 `design.md` 写清组件、区域位置、业务或视觉作用、列宽与窄屏重排，并按抽屉或 iframe 的实际宽度调整。
-
-先读取当前 `design.md` 中已确认的应用风格、字体、表面、线条、圆角、密度与状态规则，再设计提交、编辑和详情页。表单是应用风格的延续，不单独抽取另一套配色或风格；多样性来自不同应用的设计方向，以及同一应用内不同业务任务的合理布局差异，不是让每张表单随机换肤。
-
-| 应用方向示例 | 表单与详情的延续方式 |
-| --- | --- |
-| 杂志编辑风 | 延续标题字体、纸面底色、细线或强调侧线、章节层级和舒展留白；长说明单列，短字段可用主次分栏，详情保留相同阅读节奏 |
-| 精密商务风 | 延续克制圆角、细边界、稳定对齐和紧凑间距，适合成组双列和清晰章节 |
-| 柔和服务风 | 延续低对比表面、柔圆控件和宽松标签间距，优先易读单列或舒展双列 |
-| 高密度运营风 | 延续紧凑控件、明确网格与分组，按字段长度使用多列或横向标签，窄屏收拢 |
-
-这些是推导示例，不是固定行业映射或新增 preset。不能把杂志风等同于某个固定颜色，也不能让所有风格最后都变成相同白卡、相同圆角和相同间距。
-
-在现有 `design.md` 的组件规则及相关页面说明中写清：表单继承了哪些应用特征、主体宽度、列数/比例、标签位置、字段与组间距、分割线、背景层次、底部操作区和响应式，以及详情如何保持一致。无需新增文档或必填机器字段。
-
-## 实现职责与主题交付
-
-- **设计文件**：风格与页面布局写入 `design.md`；Fast 将 token 写入 `tokens.application-global`，Plan 通过 `visualStyle.tokens` 生成同一份 `design.md`。
-- **应用样式**：颜色、字体、控件、状态、背景、详情表面与底栏样式统一进入当前应用的 `app_theme.css` / `app-theme.css`，以实际生成路径为准，通过应用主题设置加载。已有变量优先；需要边框形式、伪元素等额外表达时，仅在核实平台 DOM 后向同一应用 CSS 添加有限作用域规则，并在设计源记录用途。装饰不遮挡输入、不承载必要信息，不用全局 `.next-*` 覆盖所有组件。
-- **表单结构**：列数、字段排列和标签位置使用表单属性、`ColumnContainer` 和 `Divider` 配置；不同控件遵守自身能力。应用 CSS 不替代字段结构，也不重排 DOM、伪造字段或改变提交行为。
-
-表单样式使用已验证的平台变量和组件。修改风格时更新设计源和同一份应用主题文件，所有表单复用该主题文件。
-
-## 控件和标签
-
-| 变量 | 平台消费位置 | 未配置时的消费回退 |
-| --- | --- | --- |
-| `--form-element-medium-corner` | 控件 `border-radius` | `8px` |
-| `--form-element-medium-height` | 单行控件 `height`，部分控件的 `line-height` | `32px` |
-| `--form-element-medium-font-size` | 控件 `font-size` | `14px` |
-| `--input-bg-color` | 输入表面 `background-color` | `#fff` |
-| `--input-border-width` | 输入边框宽度 | `1px` |
-| `--input-border-color` | 输入边框颜色 | `rgba(24, 28, 31, .12)` |
-| `--pod-form-label-color` | 字段标签 `color` | `var(--color-text1-10, rgba(24, 28, 31, .8))` |
-| `--form-top-label-margin-b` | 顶部标签 `margin-bottom` | `0` |
-
-表中的回退不是必须写死的设计值。模板将圆角连接到 `--corner-2`，填充连接到 `--pod-card-bg-color`，边框连接到 `--color-line1-2`，标签连接到 `--color-text1-10`；项目可以按语义单独调整。高度和使用同一变量的行高一起变化，不再增加一个平行行高变量。
-
-以下是不同方向的起点，按主题和真实业务选择，不随机逐字段切换，也不作为 CLI preset：
-
-| 方向 | 控件圆角 / 高度 / 字号 | 填充与边框 | 顶部标签间距 |
-| --- | --- | --- | --- |
-| 紧凑工具表单 | `4px` / `32px` / `14px` | 内容底色、清晰的 `1px` 细边界 | `4px` |
-| 舒展线框表单 | `8px` / `40px` / `14px` | 透明或内容底色、`1px` 细边界 | `8px` |
-| 柔和填充表单 | `12px` / `40px` / `14px` | 与内容表面可辨的弱填充、轻边界 | `8px` |
-| 暖纸登记表单 | `6px` / `40px` / `14px` | 暖白输入、暖灰边界、深色标签 | `6px` |
-
-多行文本、附件、成员选择和子表保留自身布局，不用全局 `input/textarea/.next-*` 规则强制同一高度。顶部标签间距不代表所有字段的行间距。
-
-默认、hover、focus 和只读详情应成套设计，不能只改默认边框后让聚焦跳回另一套风格。核实当前运行时对 `--input-hover-border-color`、`--input-focus-border-color`、`--input-hover-bg-color`、`--input-focus-bg-color` 等变量的消费与作用域后，写入应用主题；不能假定声明在根部就覆盖组件局部变量。焦点保持可辨，错误、警告、禁用保留独立语义。
-
-## 详情页只读字段数据框
-
-表单详情页使用只读字段数据框展示已提交的数据。修改详情页风格时，将以下 token 与表单控件、卡片和页面画布一起设计，并写入同一份应用主题。背景与卡片形成可辨层次，文字沿用正文色，圆角沿用控件或卡片的形状体系；字号、行高、最小高度、内距和字段间距共同决定信息密度。左侧指示线由指示色与内阴影共同表达，可按当前主题保留、弱化或关闭。
-
-| token | 控制的样式 | 推荐关系 |
-| --- | --- | --- |
-| `--pod-field-preview-bg-color` | 数据框 `background` | 从当前内容面或弱填充色推导，与 `--pod-card-bg-color` 保持层次 |
-| `--pod-field-preview-border-radius` | 数据框 `border-radius` | 与表单控件、卡片使用同一圆角体系 |
-| `--pod-field-preview-indicator-color` | 左侧指示线颜色 | 使用当前边界色或主题强调色 |
-| `--pod-field-preview-shadow` | 数据框 `box-shadow` 和左侧指示线 | 需要指示线时使用 `inset 2px 0 0 0 var(--pod-field-preview-indicator-color)`；平面风格可用 `none` |
-| `--pod-field-preview-text-color` | 数据值 `color` | 使用当前正文色并保证与数据框背景的对比度 |
-| `--form-element-medium-font-size` | 数据值 `font-size` | 与编辑态表单值保持同一字号层级 |
-| `--pod-field-preview-gap` | 数据框内部元素间距 | 按图标、文本、标签的组合密度确定 |
-| `--pod-field-preview-line-height` | 数据值 `line-height` | 与字号配套，保证单行和多行内容可读 |
-| `--pod-field-preview-min-height` | 数据框 `min-height` | 与编辑态单行控件高度协调 |
-| `--pod-field-preview-padding` | 数据框 `padding` | 与最小高度、行高共同形成垂直和水平留白 |
-
-独立详情页、数据管理详情、抽屉或 iframe 详情都使用这组应用主题 token。设计时在 `design.md` 记录最终值，通过主题生成命令写入 `app-theme.css`，再上传同一份主题文件；验收时分别检查普通文本、关联记录、日期、人员、长文本和空值，并核对 PC、窄屏和抽屉宽度下的计算样式。
-
-## 底部操作区与宽度对齐
-
-`--pod-page-footer-bg-color` 根据应用主题选择与画布或内容表面协调的实色、半透明或透明；不统一强制透明，也不默认白底。`--pod-sticky-footer-box-shadow` 根据材质和层次选取，可为 `none`。区分外层固定区域与内层按钮容器，避免重复背景、双重阴影和无设计依据的边线。
-
-设计表单主题时，这两个变量必须与控件变量一起显式写入设计源并生成到应用 CSS，不能只在正文写“跟随主题”后沿用模板默认值。Fast 写入 `design.md` 的 `tokens.application-global`；Plan 写入 `visualStyle.tokens` 并物化到 `design.md`。正文说明底栏采用哪个表面及是否需要阴影。
-
-| 变量 | 设计决策 | 示例含义 |
-| --- | --- | --- |
-| `--pod-page-footer-bg-color` | 选择与页面或内容面板协调的底色 | `var(--pod-card-bg-color)` 表示跟随面板；透明仅用于设计需要背景透出的情况 |
-| `--pod-sticky-footer-box-shadow` | 按主题选择平面、柔和悬浮或明确层次 | 平面纸张可用 `none`，浮层可用与主题协调的柔影；不统一套用默认黑色双层阴影 |
-
-主体和底栏使用同一内容宽度与水平对齐基准。不能仅为两者设置相同 `max-width` 就认为已对齐；同时检查包含块、百分比宽度、内边距、边框盒、左右 margin、滚动条和平台规则优先级。应用 CSS 的适配限定在已核实的页面/主题作用域，不把实验中的固定尺寸和高优先级覆盖作为所有应用默认值。
-
-当前灰度源码中，居中模式 `.vc-page-content-1180` 的正文与提交按钮栏共同消费 `--pod-page-content-max-width`；自动宽度使用 `--pod-page-auto-width-margin`。优先调整这两个已有变量，不另写两份 `width:calc(...)` 或实验固定宽度。`--pod-page-padding` 控制 PC 正文内距，`--pod-page-inner-group-spacing` 控制居中模式上下留白；移动端另用 `--pod-page-mobile-margin` / `--pod-page-mobile-padding`。宽度 token 不会自动切换页面的布局模式。
-
-底栏变量按实际渲染场景选择，**导航显隐与底栏类型是两个独立维度**。不能用 `isRenderNav=false`、URL 名称或是否在 iframe 中代替运行态判定。变量名保留平台实际大小写 `--pod-formView-stickyFooter-*`，不另造 `form-view-*` 别名。
-
-`factory.js` 根据 `__formRenderEnv__ === 'DATA_MANAGE'` 添加 `.is-data-manage-footer`；新版提交页且在 iframe 抽屉中另加 `.is-in-drawer-submit-footer`。两者可能同时出现，后者在提交页按钮容器样式中有显式适配。`.is-sticky-v2` 是容器内定位，不能套用固定栏的视口偏移和占位规则。
-
-| 场景 | 背景与阴影 | 其他消费项 |
-| --- | --- | --- |
-| 普通提交（有导航或无导航）/ 抽屉提交的内层按钮容器、详情按钮栏 | `--pod-page-footer-bg-color`、`--pod-sticky-footer-box-shadow` | `--pod-page-footer-border-radius`；该分支外层 `.stickyFooter` 在平台源码中保持透明且无阴影 |
-| 管理页表单视图及 `.is-data-manage-footer` | `--pod-formView-stickyFooter-bg-color`、`--pod-formView-stickyFooter-box-shadow` | `--pod-formView-stickyFooter-border`、`--pod-formView-stickyFooter-border-top`、`--pod-formView-stickyFooter`（圆角） |
-
-需要管理页和独立页一致时，在设计源分别配置对应变量，不能通过一条全局 `.stickyFooter` 覆盖抹平场景差异。两类容器有不同层级，阴影不必相同。
-
-应用包含数据管理内的表单视图时，显式确定 `--pod-formView-stickyFooter-bg-color`、`--pod-formView-stickyFooter-box-shadow`、`--pod-formView-stickyFooter-border`、`--pod-formView-stickyFooter-border-top` 及 `--pod-formView-stickyFooter`（圆角）。高度 `--pod-formView-stickyFooter-height` 同时影响外层、按钮行和占位，改变时检查全部三处。`--pod-formView-stickyFooter-bottom` 用于普通固定提交栏；管理页吸底还消费 `--pod-shell-padding`，不能统一强制 bottom 或 left 为零。`--pod-inDrawer-stickyFooter-*` 虽存在于公共定义中，本轮在该仓库的上述分支未发现直接消费，不能仅凭名称认定它能控制 iframe 提交栏。
-
-底部占位在背景连续的布局内处理，避免底部 margin 露出 body 底色；确需从 margin 改成 padding 时，根据实际固定栏高度保留空间，不盲目复制某个固定值。分别检查独立页面、实际 iframe/抽屉宽度与窄屏，左右边缘需符合设计，最后一个字段及错误提示可完整滚动到操作栏上方。
-
-## 提交页的背景分层
-
-`submission/{formUuid}?isRenderNav=false` 隐藏导航，不会取消应用主题，也不要求纯白背景。PC 抽屉里的 iframe 与独立提交页都需要检查；父页面的 CSS 变量不会自动继承进 iframe。
-
-| 层级 | 既有配置 | 作用范围 |
-| --- | --- | --- |
-| 应用外衬、无导航壳层 | `--pod-app-root-bg-color`、`--pod-app-root-bg-image` | 颜色与图片分开；图片值可为 `none`、渐变或真实 `url(...)` |
-| 页面画布、表单内容区 | `--pod-page-bg-color` | 只接受颜色；新版表单可通过 `--yida-form-content-bgcolor` 消费它 |
-| 卡片表面 | `--pod-card-bg-color` | 控制卡片及引用它的控件，不替代页面背景 |
-| 输入控件内部 | `--input-bg-color` | 独立于外层背景，保证填写内容可读 |
-
-模板通过 `body.pod-premium.page-type-submit .vc-shell-without-nav.pod-premium` 将外衬变量用于新版无导航提交页；平台默认壳层取导航背景，单独声明根背景图变量并不足以显示图片。该规则不修改有导航页面、旧主题或表单字段。渐变或背景图放在外层，内容表面保留可读底色。背景素材必须来自已确定的真实资源，不能让图像妨碍字段阅读；长表单、窄屏和滚动到底部时均应保持连续背景。默认居中靠上、cover、不重复，需要其他铺放方式时在已核实的作用范围调整。
-
-已有表单的 `Page.props.pageStyle`、`contentBgColor` 和 `contentBgColorMobile` 可能保留历史底色；不同运行版本的优先级也可能不同。先查看实际 body、壳层、`.vc-rootcontent` 和控件的计算样式，再通过应用主题或结构化页面属性调整。新表单的透明 `pageStyle` 只是一层默认值，不会自动改变已有表单；表单与详情页视觉统一由应用全局样式管理。
-
-模板显式将 `--yida-form-content-bgcolor` 接到 `--pod-page-bg-color`，避免 DeepContainer 的 inline 变量消费回退到白色。新版 AppThemePage 会过滤 `props.style` 中的自定义属性；因此不能把主题变量写进页面 style 代替应用主题。旧版 LegacyPage 则会在页面局部声明变量，根部设置不保证覆盖它。旧 `.vc-yida-shell-new` 还使用局部 `--vc-form-top-label-margin-b`，并非同名的 `--form-top-label-margin-b`；不要承诺一套 token 改遍所有历史布局。
-
-模板的 hover/focus 边框和 focus 底色已有源码消费者。富文本编辑器使用白色普通背景和固定蓝色焦点阴影时，先核实实际控件，再添加作用域明确的应用级适配，并在验收清单中检查默认、hover 和 focus 状态。
-
-## 写入现有主题源
-
-Fast 将以下变量合并到 `design.md` 的 `tokens.application-global`；Plan 合并到 `build-plan.json` 的 `visualStyle.tokens`，重新物化生成 `design.md` 和 CSS。原有品牌、导航、文字等 token 保留。以下只示范暖纸表单的项目差异，不是所有应用的默认主题：
-
-```json
-{
-  "--form-element-medium-corner": "6px",
-  "--form-element-medium-height": "40px",
-  "--form-element-medium-font-size": "14px",
-  "--input-bg-color": "#FFFCF6",
-  "--input-border-width": "1px",
-  "--input-border-color": "#D8CDBD",
-  "--pod-form-label-color": "#554B40",
-  "--form-top-label-margin-b": "6px",
-  "--pod-field-preview-bg-color": "#F7F1E7",
-  "--pod-field-preview-border-radius": "6px",
-  "--pod-field-preview-indicator-color": "#D8CDBD",
-  "--pod-field-preview-shadow": "inset 2px 0 0 0 var(--pod-field-preview-indicator-color)",
-  "--pod-field-preview-text-color": "#554B40",
-  "--pod-field-preview-gap": "4px",
-  "--pod-field-preview-line-height": "20px",
-  "--pod-field-preview-min-height": "32px",
-  "--pod-field-preview-padding": "0 8px",
-  "--pod-app-root-bg-color": "#F3EBDD",
-  "--pod-app-root-bg-image": "linear-gradient(135deg, #F3EBDD, #E8DDCB)",
-  "--pod-page-bg-color": "#FFFCF6",
-  "--pod-card-bg-color": "#FFFCF6",
-  "--pod-page-footer-bg-color": "var(--pod-card-bg-color)",
-  "--pod-sticky-footer-box-shadow": "none",
-  "--pod-page-footer-border-radius": "6px",
-  "--pod-formView-stickyFooter-bg-color": "var(--pod-page-bg-color)",
-  "--pod-formView-stickyFooter-box-shadow": "none",
-  "--pod-formView-stickyFooter-border": "none",
-  "--pod-formView-stickyFooter-border-top": "1px solid var(--input-border-color)",
-  "--pod-formView-stickyFooter": "0 0 6px 6px"
-}
-```
-
-Fast 更新使用 `openyida sample yida-design app-theme --design-file <design.md> --output <app-theme.css>`；Plan 使用物化结果中的 `outputs.theme`。两条路径都复用现有主题生成器，不新增表单专属主题文件、CLI 参数或一套 preset。已有主题增量更新时保留未修改的变量和定制 CSS。
-
-增量更新不会将新版模板的所有选择器自动合并到旧 CSS。已有主题缺少上述提交页背景规则时，先确认实际 DOM，再将模板中的这一小段规则补入原主题文件；不能省略 `--design-file` 重置整份主题。新建主题已包含该规则。
-
-通过 `openyida update-app <appType> --theme-file <app-theme.css>` 上传并绑定后，读回资源并检查实际页面；本地生成不代表线上生效。已有表单的字段更新不需要重新建表。
-
-## 验证
-
-### 新主题页面消费清单
-
-以下按 `vc-deep-yida` 中的实际消费分组；已有模板变量优先配置，不重复添加同名声明，也不把旧分支或注释里的变量算作新主题能力。
-
-| 页面 / 区域 | 已确认消费的 token | 检查范围 |
-| --- | --- | --- |
-| 提交 / 编辑原生表单 | `--pod-form-label-color`、`--yida-form-content-bgcolor`、控件自身的 `--form-element-medium-*` / `--input-*` | 新版 AppThemePage 不接收页面 style 中的变量；控件逐项核对，不能沿用 LegacyPage 密度映射的假设 |
-| 管理页标题及内容 | `--pod-data-manager-title-padding`、`--pod-page-data-manage-top-padding`、`--pod-page-padding` | 消费在管理页容器，Shell 也有覆盖；不是单张表单字段间距 |
-| 管理页表单视图底栏 | `--pod-formView-stickyFooter-*` | 核对 DATA_MANAGE、抽屉提交标记，以及 fixed / sticky-v2 模式 |
-| 详情页只读字段数据框 | `--pod-field-preview-bg-color`、`--pod-field-preview-border-radius`、`--pod-field-preview-indicator-color`、`--pod-field-preview-shadow`、`--pod-field-preview-text-color`、`--form-element-medium-font-size`、`--pod-field-preview-gap`、`--pod-field-preview-line-height`、`--pod-field-preview-min-height`、`--pod-field-preview-padding` | 核对数据框与卡片、编辑态控件的色彩、形状、排版和密度关系，并检查长文本与空值 |
-| 详情卡片 / 自定义详情 | `--pod-card-bg-color`、`--pod-card-border`、`--pod-card-border-radius`、`--pod-page-inner-group-spacing`、`--pod-page-auto-width-margin` | PC 详情仍有固定最小宽度，不把提交页断点视为详情已支持移动布局 |
-| 详情记录历史 | `--pod-card-padding`、`--pod-card-bg-color`、`--pod-card-border`、`--pod-card-border-radius` | 历史面板仍有固定 max-width，源码中注释掉的内容宽度 token 不算有效消费 |
-| 门户 / 展示页卡片 | `--pod-card-*`、`--pod-page-inner-group-spacing` | 门户会在特定场景局部重新声明卡片边框，需检查实际作用域 |
-| 移动表单 / 移动详情 | `--pod-form-label-color`、`--pod-page-mobile-margin`、`--pod-page-mobile-padding`；详情还用页面背景、组间距和外边距 | 移动端 Meet 控件与安全区有自己的消费路径，不把 PC StickyFooter 规则复制过去 |
-
-公共定义中的 `--pod-detail-*`、`--pod-field-preview-*` 继续保留，但完整只读详情还涉及访问态 owner；不能仅凭本仓库的卡片样式就宣布所有详情字段已覆盖。同样，`--form-element-table-padding`、`--form-icon-scale` 等在本次页面扫描中落在 legacy 路径，不为“补齐 token”而迁到全局新主题。
-
-### 场景验收
-
-- 查看控件包装层、输入文字和标签的计算样式，确认圆角、高度、字号、填充、边框和标签间距实际生效，不能只检查 `:root` 中是否出现变量。
-- 分别查看外层背景、表单内容底色和控件填充；外层渐变不能写入 `background-color`。遇到历史 inline 样式，查清来源后只改目标配置。
-- 核对长标签、多行文本、选择器、日期、附件、子表，以及焦点、错误和禁用状态；单行行高不能截断内容。
-- 检查设计源与生成的应用 CSS 均含显式的 `--pod-page-footer-bg-color`、`--pod-sticky-footer-box-shadow`；再检查底栏实际计算的背景和阴影，排除组件局部变量或旧 CSS 覆盖，不能只检查根变量存在。
-- 检查独立提交页、PC 抽屉 iframe、移动端及底部操作区；固定提交按钮不能遮挡最后一个字段。移动端按其实际组件能力验证，不声称 PC token 全部等效。
-- PC 分别检查有导航提交、无导航提交、数据管理表单视图、iframe 抽屉提交和详情；有导航时检查侧栏展开/折叠，不手写固定 left 补偿；管理页分别检查 fixed 与 sticky-v2。模板底部 padding 适配按实际固定底栏标记命中，不再依赖无导航 Shell。
-- 新版主题、旧版主题与已保存页面分别验证。没有运行态证据时，交付注明“主题已生成/绑定，视觉待验证”。
-
-### 本轮源码核对依据
-
-2026-09-19 拉取的 `origin/trunk-theme-gray`：`yc-common` 为 `5b1a7e0`，`yida-shell` 为 `ec03a98`，`vc-deep-yida` 为 `63d0d5977`。后续适配需重新核对分支，不将此快照视为永久契约。
-
-- `yc-common/styles/_pod_common.scss`：Pod 变量定义；模板已覆盖该文件的变量名，不因默认颜色不同就批量替换主题设计值。
-- `yida-shell/src/YidaShell/yida-app-theme.scss`：正文宽度、margin、padding 与无导航容器；`src/Basic/pc.scss`：旧 Shell 标签间距的局部变量。
-- `vc-deep-yida/src/vc-form-container/view.less`：两类底栏；`src/vc-page-yida/form/view.less`：提交页底部占位；`src/vc-page-yida/detail/view.less`：详情按钮栏。
-- `vc-deep-yida/src/components/deep-container/index.tsx`、`src/vc-page-yida/component/container/{appTheme,legacy}/page.jsx`：内容背景与变量来源；`src/components/deep-editor-field/main.scss`：富文本状态及硬编码边界。

package/yida-skills/skills/yida-design/references/navigation-decision.md

@@ -1,53 +0,0 @@
-# 平台导航与自定义导航决策
-
-首轮需求澄清完成后读取本文。Fast 与 Plan 均由 AI 根据 brief 中的有效任务和入口建议确定导航方式、布局和菜单样式；入口尚待判断时，先按 [判断是否分前后台](../../yida-requirement-analysis/references/experience-groups.md) 补齐。
-
-## 先判断入口，再分别选择菜单
-
-- 服务前台：默认在一个自定义页面内完成已选任务，并设计自己的菜单；只有一个任务时可不设菜单。用户明确要求使用原生页面时优先沿用。
-- 业务后台或不分前后台的系统：按操作效率选择自定义页面或宜搭原生页面；默认由平台导航组织跨模块入口。自定义页面只实现业务内容，同任务分类使用页内 Tab，不因此再生成一套管理菜单。
-- 首页承载按 [首页按任务选择](../../yida-requirement-analysis/references/experience-groups.md#首页按任务选择) 决定：可用门户式业务工作台或直接进入原生业务页；驾驶舱需要独立的分析任务依据。
-- 为每个入口写出用户、任务、访问方式和菜单，并按下表确定配置范围。
-
-| 应用工作区 | 当前入口 | 配置范围 |
-| --- | --- | --- |
-| 平台导航 | 普通工作区页面 | 保留应用和页面导航 |
-| 平台导航 | 独立前台，自定义菜单或无菜单 | 只配置前台页面独立展示；应用导航继续显示 |
-| 自定义应用导航 | 应用内工作区页面 | 按应用级方案隐藏平台应用导航，并处理范围内页面 |
-
-执行时按 [导航壳配置](../../yida-nav-shell/SKILL.md#必做配置) 应用对应范围，并打开各入口链接验证实际效果。
-
-按 [访问态入口契约](../../yida-app/references/entry-navigation.md#每个入口都确定首页与菜单顺序) 保存每个业务入口的菜单顺序、默认页面及首屏任务。平台导航与自定义导航都必须落实排序；管理端不强制创建首页，前台页面不自动进入管理菜单。隐藏设置、入口路径、实际默认页面和权限分别验证。
-
-## 应用工作区的选择依据
-
-1. 用户已明确要求宜搭原生导航、自定义导航或具体布局时优先沿用；只说“平台导航”视为宜搭原生导航，只指定顶部、侧边或 L 型时保留布局，由 AI 补齐导航方式。后续阶段沿用同一决策。
-2. 已有业务应用的局部增改沿用现有导航；显式窄范围按 `explicitScope.allowInferredResources=false` 执行，只处理用户指定的资源和设置。
-3. 新建完整应用默认采用宜搭原生导航，组织表单、审批、数据管理等业务入口。只有明确的应用级品牌菜单或特殊导航交互需求时才采用自定义导航，并在 `reason` 写明具体需求依据。保留筛选、分页、草稿或做同任务 Tab 不是替换平台导航的理由。
-
-菜单与布局明确后，按 [导航与应用框架](application-theme-consistency.md#导航与应用框架) 将外观纳入整体应用设计。模板提供导航 token 和导航明暗，业务规划决定菜单结构和布局；前台、后台、表单、详情与自定义页面保持同一设计语言。
-
-## 根据场景确定导航布局
-
-AI 在已确定的导航方式内，结合业务模块数量、层级、切换频率、内容宽度和目标设备确定布局；用户已明确布局或提供参考时优先沿用。
-
-| 场景 | 宜搭原生导航（平台导航） | 自定义导航 |
-| --- | --- | --- |
-| 模块少、层级浅，表格或看板需要较宽内容区 | 顶部：`platform-top` | 顶部：`custom` + `variant: top` |
-| 模块或分组多，需要频繁跨模块操作 | 侧边：`platform-side` | 左侧：`custom` + `variant: side` |
-| 业务域与域内模块形成两级导航 | L 型：`platform-l-shape` | 顶部＋侧边：`custom` + `variant: mixed` |
-| 少量高频入口的移动端轻量门户或沉浸展示 | 按实际层级选顶部或侧边 | 可选底部悬浮菜单：`custom` + `variant: dock` |
-
-按已确认的业务模块和导航方式选择合适布局。自定义形态细化参考 [导航壳形态目录](../../yida-nav-shell/references/nav-shell-patterns.md)，按 [页面与导航连续性](page-continuity.md) 确定首屏共同背景、导航占位/叠加、滚动及切换状态；顶部默认贴顶通栏，悬浮仅按明确设计选用。侧边及顶部＋侧边在 PRD/design 中写入折叠/展开和拖拽调宽。
-
-## 方案讨论与确认
-
-导航作为业务方案的一部分说明：例如“客户在前台预约，员工通过后台菜单维护商品、资讯和处理预约”。默认方案明确时不另设“平台还是自绘”的强制技术选择题；用户主动讨论或明确选择时，保留其要求并说明影响范围。
-
-- Plan：在整体方案中展示各入口的导航归属与管理页只实现业务内容的边界，随整体方案确认；已展示方案的导航归属发生实质变更时，按现有修订与确认流程处理。
-- Fast：说明并实施已记录的选择，不新增导航审批环节；保留既有明确要求和局部修改范围。
-- 实施中发现重复导航属于修正实现偏差，移除重复页面菜单即可，不自动改成应用级自绘导航，也不重新讨论已确认的方案。
-
-## 写回与下游复用
-
-由 `yida-app` 按 [前后台导航交接](../../yida-requirement-analysis/references/handoff.md#前后台导航交接) 写回 brief，供 PRD 与视觉设计共用。AI 决策标记 `ai_default`，用户明确指定的导航方式标记 `user_selected`，reason 写明依据。Plan 随整体搭建方案确认；Fast 按记录继续实施。

package/yida-skills/skills/yida-design/references/page-continuity.md

@@ -1,42 +0,0 @@
-## 页面与导航连续性
-
-适用于自定义页面的导航、锚点、tab、列表详情和原生任务切换。已有设计与业务权限优先；页内切换不因此创建应用导航或隐藏平台导航。
-
-### 导航归属先于布局
-
-平台导航下的管理页只实现业务内容：平台负责跨模块切换，当前页只保留同任务分类、筛选与上下文动作。下文共同背景、导航占位和导航壳规则仅在当前页面确实拥有自绘导航时应用，不要求每个工作台再写一套顶部或侧边菜单。
-
-### 画布与滚动
-
-- 官网、品牌、活动等连续展示页：沉浸首屏的图片/渐变从局部画布顶部开始，覆盖导航背后和四周；文字单独留导航安全区，沿用宿主页面滚动。
-- 工作台、列表、表单等业务工作区：导航占位，内容撑满剩余高度；本地内容区或 iframe 内滚动，同一轴只有一个主滚动容器。
-
-顶部导航默认贴顶通栏，无外侧悬空留白或胶囊轮廓；悬浮样式仅按用户参考或明确设计选用。有首屏背景图时，导航叠加背景、初始透明，滚动后增加遮罩底色，回到顶部恢复透明；展开菜单始终有可读底色。文字、图标及选中态随背景保持对比。
-
-背景从画布顶部开始，安全区只留在首屏文字内部，禁止白底导航占一行后才开始图片。固定定位与悬浮外观分开决定：核实实际滚动容器、祖先 overflow/transform 和宿主边界，再选 sticky 或 fixed；不能默认监听 window、跨父页面改 CSS 或用负 margin 掩盖断层。
-
-长页使用 canvas-nav-content 的 document 布局：根为自然高度，main 为 block，main/content 不带工作区的 flex 零基准与 min-height:0。不可只把 overflow 改为 visible 而保留定高工作区结构；宿主裁切时会让整页只剩导航高度。顶部组件以 headerOnly 接入，有首屏背景时传 overlay，不叠第二层内容壳。
-
-各视图共享品牌、对齐线、宽度和外侧留白，不要求铺同一张图；宽表格等例外在设计中说明，不无意增加白卡、双导航或改变边距。
-
-### 操作与状态
-
-| 操作 | 保留与切换 |
-| --- | --- |
-| 同页锚点 | 不卸载页面；滚动与选中态同步，避开导航，尊重 reduced motion |
-| tab / 本地视图 | 只切内容；筛选、分页、已载数据、草稿放在稳定父层并按任务 key 保存，首次进入到顶部，返回按设计恢复位置 |
-| 列表详情往返 | 抽屉或同壳视图；保留筛选、页码、列表位置，关闭后焦点回到入口 |
-| 原生任务 | 真实 submission/workbench、保留壳与返回路径；不嵌套壳，iframe 状态只通过平台支持的通信判断 |
-| 外链 / 跨页 | 真实链接，保留新窗口和修饰键；同标签跨页须确认目标保留同一导航壳 |
-
-同一任务 key 驱动 URL、选中态和内容。沿用现有路由；hash 参数模式保留其余 query/hash 和 history.state，监听返回事件并 cleanup。权限查询完成后，不可用入口回退并 replaceState 校正地址，不新增无效历史。
-
-重复点击当前项不重载、不重置位置、不重复写历史。不要给导航、Provider 或根节点设置随菜单变化的 key；contentKey 只卸载内容，不缓存草稿或 iframe。未保存输入的菜单切换、浏览器返回共用离开策略；取消后地址、选中态与内容均保持原任务。
-
-loading/empty/error/无权限只替换内容区，保留导航和画布。快速切换取消旧请求或校验归属，旧响应不能覆盖当前任务；不把旧数据冒充新任务。失败提供局部重试与返回，iframe load 不证明业务成功。普通刷新保留内容和位置，提交后按需更新关联数据。
-
-### 交接与验收
-
-状态交接应区分刷新、页内切换与跨页返回：非敏感枚举筛选及页码可由路由恢复；敏感筛选留在内存；未提交草稿单独约定保存、放弃和取消离开策略。按 `yida-canvas-custom-page` 的状态恢复规则落地，需要最小片段时提取 `canvas-view-state`；片段不负责跨任务缓存、草稿或离开拦截。业务动作还须按 `yida-canvas-data-binding` 的授权清单验证服务端规则，导航可见性不能替代授权。
-
-实际验证首屏、第二屏、宽窄屏展开态：无背景断带、遮挡、双滚动、横向溢出或滚动锁残留，键盘焦点可见；实际滚动到页脚并回顶，比较根/main 高度与正文、导航高度，不能只看到首屏就认定底部可达。逐项测试菜单往返、直接链接、刷新、前进后退、重复/快速点击；再测慢加载、失败、空数据、无权限、未保存输入，无整页闪白、串数据或静默丢草稿。编译和静态检查不能代替视觉与交互验收，只报告实际验证范围。

package/yida-skills/skills/yida-design/references/theme/application-style-recipes.css

@@ -1,58 +0,0 @@
-/* OPENYIDA APPLICATION STYLE RECIPES START
- * Opt-in semantic classes for custom pages. Native form structure stays in Schema.
- * Never target platform field wrappers to impose a fake grid or fixed height.
- */
-.pod-premium .oyd-style-workspace {
-  container-type: inline-size;
-  max-width: var(--oyd-content-width);
-  margin-inline: auto;
-  padding: var(--oyd-content-padding);
-  color: var(--oyd-ink);
-  font-family: var(--font-family-base);
-  background-color: var(--oyd-page-bg);
-  background-image: var(--oyd-canvas-image);
-}
-.pod-premium .oyd-style-layout {
-  display: grid;
-  grid-template-columns: var(--oyd-layout-columns);
-  gap: var(--oyd-field-gap);
-  align-items: start;
-}
-.pod-premium .oyd-style-layout > * { min-width: 0; }
-.pod-premium .oyd-style-wide { grid-column: 1 / -1; }
-.pod-premium .oyd-style-layout > .oyd-style-intro {
-  padding-inline-end: var(--oyd-field-gap);
-}
-.pod-premium .oyd-style-intro {
-  color: var(--oyd-ink);
-  border-block-end: 1px var(--oyd-rule-style) var(--oyd-border);
-  padding-block-end: var(--oyd-field-gap);
-  margin-block-end: var(--oyd-section-gap);
-}
-.pod-premium .oyd-style-intro h1 {
-  font-family: var(--oyd-heading-font);
-  font-size: var(--oyd-heading-size);
-  line-height: 1.2;
-  overflow-wrap: anywhere;
-}
-.pod-premium .oyd-style-section {
-  padding: var(--oyd-content-padding);
-  margin-block-end: var(--oyd-section-gap);
-  background: var(--oyd-surface);
-  border: var(--input-border-width) var(--oyd-rule-style) var(--oyd-border);
-  border-radius: var(--oyd-radius);
-  box-shadow: var(--oyd-surface-shadow);
-}
-.pod-premium .oyd-style-section > h2::after {
-  content: "";
-  display: block;
-  width: 3rem;
-  margin-block-start: .5rem;
-  border-block-end: 2px var(--oyd-rule-style) var(--oyd-accent);
-}
-@container (max-width: 640px) {
-  .pod-premium .oyd-style-layout { grid-template-columns: minmax(0, 1fr); }
-  .pod-premium .oyd-style-section { padding: 16px; }
-  .pod-premium .oyd-style-intro h1 { font-size: min(32px, var(--oyd-heading-size)); }
-}
-/* OPENYIDA APPLICATION STYLE RECIPES END */

package/yida-skills/skills/yida-design/references/theme-selection.md

@@ -1,67 +0,0 @@
-# 共享主题选择与项目化规则
-
-Fast、Plan 和单页设计共用 [主题索引](../templates/design-themes/index.json) 与其中列出的完整主题。命名模板共用这一主题库；另有独立的自由创意路径，不要求匹配模板。详见[应用风格模板与自由创意](application-style-library.md)。
-
-## 输入与优先级
-
-先读取已确认需求、现有应用主题和视觉证据；页面内容、导航类型、数据、字段、流程和权限沿用业务规划。视觉证据按以下顺序处理：
-
-```text
-用户明确视觉要求
-> 品牌规范、Logo、官网、参考图和已有设计
-> 业务场景、使用频率、信息密度和主要终端
-> AI 补齐
-```
-
-将“简洁、专业”等描述落实为导航、应用框架、表单、记录详情和自定义页面的表面层次、边界强度、形状分工、文字节奏、色彩强调和组件状态。行业、颜色、主题名称或“有图表/表格/右栏”等公共组件不能单独决定主题。索引摘要用“深色/浅色导航”和“深色/浅色内容界面”自然描述明暗关系；默认选择浅色内容主题，已明确暗色、夜间或同等视觉要求时选择对应暗色内容主题。导航明暗采用最终主题模板的 `navTheme`，用户明确的导航明暗作为主题筛选约束，不在主题选定后独立猜测或覆盖。
-
-## 先读摘要，再读选中主题
-
-1. 比较前只读取索引的 `themes[].styleSummary`，也可用 `openyida design-plan catalog --json` 获取同一摘要。主题名称用于识别，不代替摘要中的视觉事实；不预读候选模板全文。
-2. 对照摘要中的表面、轮廓、形状、文字、强调方式及偏离风险，选择最符合当前视觉要求的主题。不按关键词数量打分，不维护另一套权重或风格注册表。
-3. 保留摘要中的适用条件。图表、量表、记录栈等仅按真实内容启用；没有某种内容不代表主题不适用，也不能为体现风格新增业务模块。未写明的实现细节留到主题确定后处理。
-4. 选定后通过该索引记录的 `templatePath`，相对 `yida-design/` 读取一份完整主题。沿用已确认选择，不再重新推荐；用户要求比较时，按所在流程完成选择后再读全文。
-5. 项目要求与主题核心特征冲突时，可以选择自由创意，也可重新匹配摘要中的其他主题；品牌色等允许的项目输入不构成更换主题的理由。用户明确的导航明暗与候选主题 `navTheme` 冲突时，改选符合要求的主题，不覆盖模板的导航明暗。
-
-主题 ID、模板路径和候选比较保留在内部实施记录；Plan 写 `visualStyle.internal.selectedTheme`，Fast 沿用 brief 的视觉选择。最终文档正文和用户可见方案只写当前项目的视觉效果、配色和使用理由，不展示模板路径或内部选择过程；design.md frontmatter 只保留 applicationStyle 配方版本与模式，不携带模板身份。
-
-## 设计方向比较
-
-比较过程只使用索引摘要，遵守上述完整模板读取边界。
-
-Fast 与 Plan 使用下面同一套三方向生成规则和候选字段，不得分别发明候选。已有明确完整风格、可信品牌规范、参考材料或应用主题时直接在其范围内完善构图与细节，不生成无意义的替代项；否则恰好生成三套完整方向：两个命名模板方向和一个独立自由创意方向。
-
-1. **形成三套方向**：第一套以最直接、稳妥的业务解法为参照，另外两套围绕相同业务任务发展更有表现力但仍可实现的方案。每套都写 `directionId`、`directionLabel`、`description`、`recommendationReason`、`themeId`、`primaryColor` 和 `primaryColorName`；导航结构沿用业务规划，命名模板的导航明暗不作为候选输入；自由创意选定后按项目设计明确填写导航明暗与配套 Token。
-2. **保证真实差异**：每个方向在构图、字体层级、表面层次、色彩关系中至少两项有明显差异；用已有内容建立重点，保留字段、操作、权限和状态。三套方向分别绑定三个不同的合法主题，其中第三项使用 free-creative 独立推演，主题索引摘要负责说明导航和内容界面的明暗。
-3. **按流程选择**：Fast 在内部比较三套方向并选择更适合的一套；Plan 在用户没有明确完整风格时必须展示同样三套方向并通过 `ask_human` 选择。
-4. **把质感写成具体做法**：说明主次区域、数字与标题层级、背景与容器关系、间距与对齐、主操作与状态色的用法。高级感来自这些细节的一致性；表格、批量操作和异常识别保持清晰高效。
-5. **一次交接**：将选定风格及业务理由写入 `visualDirection.description`，主色、背景和强调色的关系写入 `colorStrategy.usage`；AI 决定标记 `ai_default`。比较在本轮规划内完成，后续直接复用。Fast 只对用户展示选定风格和适用场景；Plan 在无明确完整风格时展示三套候选并请用户选择。
-
-主色优先采用用户要求、品牌和参考图中的依据。缺少明确依据时，结合使用环境和整体构图确定配色；业务类型用于判断任务和密度，具体颜色由本项目设计确定。已确认的主色可以保留，创意也可通过构图、层级和材质表达。
-
-## 三种流程的消费方式
-
-| 流程 | 选择与执行 |
-| --- | --- |
-| Fast | 按上面的共用规则生成三套方向，在内部选出推荐项并写入 brief；命名模板读取选中模板，自由创意独立编写设计与 Token，直接维护项目 `design.md`，不增加方案确认步骤 |
-| Plan | 按 [Plan 视觉候选规则](../sub_skill/yida-design-plan/references/visual-theme-selection.md) 展示同一组三套方向（两个模板方向和一个独立自由创意选项）；没有明确完整风格时固定通过 `ask_human` 选择；由 CLI 派生项目文档 |
-| 单页设计 | 先读当前应用 `design.md` 和主题证据；沿用已确认主题，只补当前页面。尚无主题契约且需选型时读取同一索引，保持现有业务功能与应用主题 |
-
-## 将主题写成项目设计
-
-完整主题是设计底稿，按 [唯一输出契约](../workflow/output-design.md) 保留现有五章生成项目 `design.md`，不另设第二模板。阅读主题中的风格摘要、视觉系统、组件、按内容启用的特色配方及约束，再合入以下项目事实：
-
-- 以项目名称和实际主色替换占位符，并将全部色值推导指令计算为具体 CSS 值。
-- `tokens.application-global` 提供平台与页面共享的基础变量；保留 `tokens.custom-page` 中已有的独立页面语义变量，不能清空。分组仅用于组织，CSS 变量取递归叶子的原名。
-- 字号、字重、行高与间距的默认值及 Tooltip 等基础契约按 [基础变量契约](../templates/design-themes/basic-tokens.json) 执行；组件选择哪些变量、圆角档位、表面和留白节奏由选中主题决定。
-- 品牌色与整体氛围按 [主题与 token](../workflow/step-2-theme-system.md) 和 [用户配色优先级](../workflow/output-design.md#用户配色与模板的优先级) 处理。保留主题中可复用的层次、形状与组件机制，不能以固定灰阶覆盖用户整体配色。
-- 导航按 [整体主题规则](application-theme-consistency.md#导航与应用框架) 保留完整 token、状态和消费关系；命名模板的导航明暗随模板派生，自由创意明确设计。
-- 页面任务和布局来自当前业务事实，主题负责呈现。没有真实内容支撑的图形、指标、侧栏或特色配方不启用；同一应用通过页面局部变体保持统一基础语言。
-- 按[指标卡与按钮配色](application-theme-consistency.md#指标卡与按钮配色)决定信息和操作的主次，将搭配写入项目组件规则。按钮和指标可用与品牌不同但协调的颜色；主题里的深色面板、近黑按钮都是可选表达，不能覆盖项目配色决定。
-- 按 [视觉结构配方](visual-scaffold-recipes.md) 把真实区块映射为页面布局与八项设计要点，按 [页面质量门禁](page-quality-gates.md) 写验收条件。配方是交接辅助，不能覆盖主题节奏或生成新的业务模块。
-
-## 交接
-
-[输出契约](../workflow/output-design.md) 规定 token、主题 CSS、素材清单、稳定引用与运行时消费方式。最终项目文档应自包含：实现阶段只读取 PRD 和 `design.md`，不再返回主题库推断规则。
-
-PRD 每个自定义页保留 `designFile`、`designRefs` 和一句话风格理由；完整视觉系统、具体页面设计、组件与状态规则只在 `design.md` 正文维护；frontmatter 索引用 anchor 定位。数据来源、表单入口、详情链接、权限和业务状态始终由业务契约决定。