openyida 2026.9.19 → 2026.9.21

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

@@ -38,12 +38,15 @@
 
 ### themeProfile
 
+`contentTone` 与 `navTheme` 的语义和组合规则统一见[主题明暗双轴](../references/application-style-library.md#主题明暗双轴)。
+
 | 字段 | 规则 |
 | --- | --- |
 | `name` | 项目自己的视觉方向名称，不写主题模板名称 |
 | `themeColor` | 当前主色，使用 6 位 HEX，与 `--color-brand1-6` 的最终值一致 |
 | `themeColorSource` | 实际来源，如 `user-specified`、`application-theme` 或 `business-inferred`；不伪造模板默认品牌色 |
-| `navTheme` | 当前导航明暗 `light` 或 `dark`；与页面画布明暗分开 |
+| `contentTone` | `light` 或 `dark` |
+| `navTheme` | 从所选主题模板派生的导航明暗 `light` 或 `dark`；与页面画布明暗分开，不由 AI 默认填写；自由创意使用项目明确设计的导航明暗 |
 | `themeDelivery` | `app-custom-theme-file` 或 `current-app-theme` |
 | `themeFile` | 当前主题 CSS 的实际交付路径；继承当前应用且没有本地主题文件时为空字符串 |
 | 既有导航配置 | 保留 navigationType、layoutDirection、hideAppNav、logoSource 等已确认配置，不重新推断入口范围 |
@@ -55,12 +58,12 @@
 使用共享主题现有的五章组织，不新增第二套固定模板。标题保持带编号的 H2，例如 `## 1. 风格摘要`，依次到 `## 5. 项目应用与调整规则`；不要省略编号或改成其他标题层级。内容按当前项目实例化：
 
 1. **风格摘要**：当前项目的视觉方向、用户任务、明确约束与需要保留的核心特征；简要说明已选配色和导航，不写候选比较。
-2. **页面视觉系统**：画布、导航、表面、边界、排版、间距、形状和色彩角色。项目配色与导航的覆盖合并到对应规则中，不另起一组相互冲突的“默认”和“适配”说明。
+2. **页面视觉系统**：导航、应用框架、画布、表面、边界、排版、间距、形状和色彩角色，覆盖表单提交、编辑、记录详情与自定义页面。项目配色与导航的覆盖合并到对应规则中，不另起一组相互冲突的“默认”和“适配”说明。
 3. **基础组件表达**：当前项目组件的结构、变量消费与状态。每套规则正文只写一次，索引定位到该段。
 4. **特色表达配方**：保留真实内容可用的配方、启用条件和不适用时处理；不为套用配方新增业务模块。未启用配方可省略细节，不影响基础视觉语言。
 5. **项目应用与调整规则**：每个实际自定义页的具体设计与验收、必要项目差异和素材缺口；不保留“请填入下方”“生成时替换”等编写任务。
 
-主题中的模板维护要求、frontmatter 模板身份要求、占位符替换步骤、色值计算指令及模型编写提示不进入最终正文。导航的最终六项配色写在第 2.2 节，与导航规则放在一起，不在章末追加另一套默认说明。保留的是实例化结果与实现者仍需遵守的消费规则，不是模板作者的操作步骤。
+主题中的模板维护要求、frontmatter 模板身份要求、占位符替换步骤、色值计算指令及模型编写提示不进入最终正文。第 2.2 节统一说明导航与框架的最终表面、状态、边界、形状、文字、间距和消费规则；完整导航 token 保存在 frontmatter。写法见 [导航与应用框架](../references/application-theme-consistency.md#导航与应用框架)。保留的是实例化结果与实现者仍需遵守的消费规则。选中项阴影与导航状态在同一节说明。
 
 按 [页面与导航连续性](../references/page-continuity.md) 逐页交接背景、滚动、切换/返回和异常状态；沉浸页导航叠加首屏，工作区导航占位，页内切换不创建应用导航。
 
@@ -108,7 +111,7 @@ Fast 写入 `design.md`；Plan 写入 `visualStyle.forUser.iconSystem.colorPairs
 
 用户确认的整体氛围高于模板默认灰阶。根据品牌和已确认方向协调页面、卡片、导航、填充、边界和交互，同时保留文字可读性和独立状态语义；不能只改按钮，也不能统一抹掉主题原有层次与材质。
 
-Fast 与 Plan 使用同一主题的颜色推导、组件规则和页面设计标准。主色按主题公式推导，其余变量沿用主题；项目差异直接写入 token。Plan 输入使用 `visualStyle.tokens`，Fast 写入 `design.md.tokens`，最终设计相同。导航六色成组处理，导航明暗不带动内容画布变暗或变白。用户明确保留中性参考或只改强调色时尊重该范围。
+Fast 与 Plan 使用同一主题的颜色推导、组件规则和页面设计标准。主色按主题公式推导，其余变量沿用主题；项目差异直接写入 token。Plan 输入使用 `visualStyle.tokens`，Fast 写入 `design.md.tokens`，最终设计相同。完整导航 token 沿用主题模板，并合入明确的项目差异；`navigationStyle.tone` 表示导航明暗，具体外观由这组 token 表达。导航明暗与内容画布分别设计。用户明确保留中性参考或只改强调色时尊重该范围。`--pod-nav-menu-item-selected-shadow` 作为方向无关的基础外观 Token 独立透传，`none` 表示关闭；CLI 不根据导航明暗生成替代配色。
 
 圆角、padding、gap、密度、背景与卡片关系按选中主题和真实任务执行，通用参考值仅补未定义项。同色画布与面板可通过边界、共容器和留白建立层次；渐变、玻璃、阴影、纹理不互相强制绑定。需要动效时提供 reduced motion 降级，装饰不覆盖内容与操作。
 
@@ -116,7 +119,7 @@ Fast 与 Plan 使用同一主题的颜色推导、组件规则和页面设计标
 
 按 [应用与自定义页面共用主题](../references/application-theme-consistency.md) 将风格承诺落实到变量，再交接页面开发。文字中的“暖色”“纸感”不是 CLI 的色值输入；模板之外的全局风格必须写入 token，不能只在自定义页实现。
 
-平台基础变量是最低契约，不是允许使用的全部变量。项目可按需扩展颜色、材质、布局、字体、动效和组件状态等语义，命名不限定为 `--oyd-*`。基础变量和扩展变量统一生成到主题 CSS；分组不决定运行时作用域，新增变量需有明确的使用组件、CSS 属性或平台映射，详见 [扩展规则](../references/application-theme-consistency.md#平台变量是基础项目主题按需扩展)。
+平台基础变量是最低契约，不是允许使用的全部变量。项目可按需扩展颜色、材质、布局、字体、动效和组件状态等语义，命名不限定为 `--oyd-*`。基础变量和扩展变量统一生成到主题 CSS；分组不决定运行时作用域，新增变量需有明确的使用组件、CSS 属性或平台映射，详见 [扩展规则](../references/application-theme-consistency.md#平台基础变量是应用主题基础框架)。
 
 `app-theme.css` 是当前应用的主题资源产物，承载品牌色阶、语义色、字体、间距、圆角、阴影，以及 Shell、导航、页面、表单、表格和浮层的主题 token 与必要样式覆盖。`app_theme.css` 等其他 `.css` 文件名同样可用；CLI 根据 `--theme-file` 路径读取内容，不靠固定文件名识别用途。Plan 使用 `outputs.theme`，其他流程使用已记录的产物路径，避免生成多份后上传错文件。
 
@@ -128,7 +131,7 @@ Fast 与 Plan 使用同一主题的颜色推导、组件规则和页面设计标
 
 主题准备与表单、页面开发按 [并行依赖](../../yida-app/workflow/parallel-work.md#主题与业务资源的依赖) 调度：计划或主题确认后即生成 CSS，不依赖表单或页面实现；appType 与 CSS 就绪便立即同步应用基础设置。页面先按已确认 token 开发，视觉验收再核对主题加载结果。
 
-页面背景统一使用 `--pod-page-bg-color`，卡片和面板使用 `--pod-card-bg-color`，默认回退 `--color-white`；抽屉整体使用 `--pod-shell-theme-bg-color`，标题栏与正文容器透明承接，不用卡片底色铺满抽屉。导航归属不改变页面底色，隐藏导航不自动透明；深色或明确的应用背景通过同一平台 token 配置。Plan 和 Fast 将设计值写入 design.md 并生成 app-theme.css，Canvas 宿主、页面根和 antd 统一消费；渐变、纹理和素材作为页面局部装饰层。
+页面背景统一使用 `--pod-page-bg-color`，卡片和面板使用 `--pod-card-bg-color`，默认回退 `--color-white`；抽屉外壳使用 `--pod-shell-theme-bg-color`，内部 iframe 继续加载表单或详情页主题，标题栏与正文容器透明承接，不用卡片底色铺满抽屉。导航归属不改变页面底色，隐藏导航不自动透明；深色或明确的应用背景通过同一平台 token 配置。Plan 和 Fast 将设计值写入 design.md 并生成 app-theme.css，Canvas 宿主、页面根和 antd 统一消费；渐变、纹理和素材作为页面局部装饰层。
 
 ### 背景颜色、渐变与图片
 

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

@@ -1,6 +1,6 @@
 # 选择主题色和 token
 
-> 这一步选择应用主色、辅助色、字体层级、组件基调和宜搭 token 作用域。
+> 这一步同时设计导航、应用框架、表单、记录详情和自定义页面，确定配色、字体、形状、间距与状态，并写入应用 token。
 
 视觉方向要从“高级 / 简洁 / 商务”继续落细。PRD 只写应用主题色和风格摘要；`design.md` 写完整 `themeProfile`、主题 token、主色、辅助色、中性色、字体层级和组件基调。
 
@@ -20,7 +20,7 @@
 
 
 1. 先判断业务气质：行业、目标用户、品牌关键词、业务情绪、视觉目标，以及是否需要亲和/专业/活力/稳重/科技/自然感。
-2. 在 `design.md` 中记录主题色、`navTheme`、`logoSource` 和 `layoutDirection`。
+2. 在 `design.md` 中记录主题色、`navTheme`、`logoSource` 和业务已确定的 `layoutDirection`。命名模板继承完整导航 token 和模板派生的 `navTheme`；自由创意明确设计两者。按 [导航与应用框架](../references/application-theme-consistency.md#导航与应用框架) 将导航外观与各类页面一起写入主题。
 3. 主题文件按 [生成与更新规则](output-design.md#cli-token-契约fast--plan-共用) 准备；Plan 复用已生成的主题 CSS。
 4. 主题 CSS 生成后读取并核对目标 token；需要修改变量时回到设计源文件，再通过 CLI 生成并重新上传。只有 CLI 未覆盖且已核实选择器的样式覆盖，才在现有 CSS 末尾小范围追加。按 [共用主题规则](../references/application-theme-consistency.md) 处理，不另写脚本生成或重写主题文件。
 5. 整体暗色时，按 [浮层适配](../references/theme/theme-token-presets.md#暗色主题浮层适配) 补齐组件 token 和必要的 classname 覆盖。
@@ -64,7 +64,8 @@
 - 中性色：背景、文字、边框、分割线，默认保持浅底业务风。
 - 语义色：成功、警告、错误、信息保持稳定，不随意改成品牌色。
 - 界面明暗：默认浅色；用户选择暗色、黑色或夜间主题时，按 [暗色主题浮层适配](../references/theme/theme-token-presets.md#暗色主题浮层适配) 确定浮层 token 与必要的 class 覆盖。
-- 导航明暗：`themeProfile.navTheme` 单独按导航方案记录；深色导航可以搭配浅色界面。
+- 导航明暗：`themeProfile.navTheme` 从所选主题模板的 `navTheme` 派生；深色导航可以搭配浅色内容界面。用户明确要求另一种导航明暗时重新匹配主题，不在项目化阶段改写模板导航 Token。
+- 明暗双轴：按[主题明暗双轴](../references/application-style-library.md#主题明暗双轴)分别填写 `themeProfile.contentTone` 与 `themeProfile.navTheme`。`contentTone` 默认 `light`；自由创意的导航明暗由项目设计明确填写，并配套导航 Token。
 - `design.md` 的 `themeProfile.colorMode` 是宜搭配色模式，例如 `gradient`，不表示暗黑模式。
 
 主题 CSS 就绪后，将主题文件路径、`navTheme`、`logoSource` 和 `layoutDirection` 写入 `design.md`。获取真实 `appType` 后，必须执行 `openyida update-app <appType> --theme-file <CSS路径>` 更新应用基础设置，并以 `themeVerification.verified=true` 确认资源已绑定；后续修改 CSS 也须重新上传保存。平台负责整套应用的主题一致性；只有 `YidaCodeCanvas` 页面源码需要在组件内部使用主题 token。
@@ -89,8 +90,12 @@
 
 统一按钮、卡片、表格、标签、抽屉、弹窗、图标、空态、加载态和错误态，并写入 `design.md` 与应用主题 CSS。
 
+包含表单时，按 [表单样式与提交页背景](../references/native-form-styles.md) 从已选应用风格推导提交、编辑和详情的字体、控件、密度、布局、标签节奏、背景及底栏。修改详情页时，同时设计只读字段数据框的背景、文字、圆角、指示线、阴影、字号、行高、最小高度、内距和元素间距，并将对应 `--pod-field-preview-*` 与 `--form-element-medium-font-size` 写入设计源。布局决策写入 `design.md` 并落实到表单配置；主题变量和经核实的样式规则归同一份应用主题 CSS。应用主题覆盖导航、自定义页面、表单、编辑和详情，形成一致的视觉语言。
+
 指标卡与按钮按[配色规则](../references/application-theme-consistency.md#指标卡与按钮配色)成组设计，明确普通信息、重点信息、主操作与次操作的颜色关系，不能仅写“深色强调”或“跟随主题”。
 
+表单主题同时显式确定 `--pod-page-footer-bg-color` 和 `--pod-sticky-footer-box-shadow`，写入设计源的 token 并生成到应用 CSS；背景及阴影随应用材质选择，不一律透明，也不漏配后沿用默认阴影。
+
 ## 产出
 
 ```markdown
@@ -100,7 +105,7 @@
 - 主题交付摘要：<平台预置 / 应用自定义主题文件 / 继承当前应用>
 
 design.md 的机器字段与正文分工按 output-design.md：
-- themeProfile：项目方向名称、真实主色及来源、navTheme、themeDelivery、themeFile 与既有导航配置。
+- themeProfile：项目方向名称、真实主色及来源、contentTone、navTheme、themeDelivery、themeFile 与既有导航配置。
 - tokens：选中主题的全局和局部变量，以及明确的项目差异。
 - 正文：色彩角色、字体层级和组件规则；不再复制一组 customThemeTemplate/customThemeFile/themeColorToken 交接字段。
 ```
@@ -108,3 +113,6 @@ design.md 的机器字段与正文分工按 output-design.md：
 ## 下一步
 
 → [页面结构和交互设计](step-4-wireframe-interaction.md)
+
+
+应用整体设计可使用[应用风格模板或自由创意](../references/application-style-library.md)。导航、自定义页面、表单与详情继承同一设计语言；自由创意从业务推演，不强制选模板。模板中的表单布局 JSON 提供结构起点，使用时填入真实字段并核对间距和响应式。

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

@@ -7,7 +7,7 @@ Fast 直接维护 `prd/<项目名>/design.md`，Plan 更新计划事实后由 CL
 已有设计文件只修改相关内容。Plan 按 [局部调整](../../yida-app/workflow/plan/step-4-deliver.md#4-处理调整) 更新；Fast 保留未改的章节和 token。下面的结构用于首版编写与完整性核对，不要求每次重写五章。
 
 1. 读取 [唯一输出契约](output-design.md)，按 frontmatter、H1、五章正文组织项目文件。
-2. 保留选中主题的基础语言和完整变量，合入项目配色、导航、组件与逐页设计，清除模板身份和编写说明。
+2. 保留选中主题的基础语言和完整变量，按 [整体主题规则](../references/application-theme-consistency.md#导航与应用框架) 合入导航、应用框架、表单、记录详情和自定义页面设计，清除模板身份和编写说明。
 3. frontmatter 仅维护机器数据与 anchor 索引，完整规则只写在正文一次。每个实际自定义页覆盖输出契约的八项要点，场景和页面标识与共享需求/计划一致。
 4. 检查 [页面质量门禁](../references/page-quality-gates.md)，确认数据、动作、导航、权限与业务事实一致；主题、状态、素材和响应式均可实现。
 

package/yida-skills/skills/yida-form-permission/SKILL.md

@@ -103,6 +103,12 @@ openyida save-permission <appType> <formUuid> --create --name <名称> [选项]
 }
 ```
 
+### 匿名提交的 FREE_LOGIN 门禁
+
+公开访问自定义页面向普通表单匿名提交时，目标表单 `DEFAULT` 权限组的 `dataPermit.rule` 必须包含 `{"type":"FREE_LOGIN","value":"y"}`。它只是三项前置门禁之一；显示页和目标表单还必须分别满足 `isOpen === 'y'`。完整运行时契约见[公开访问（匿名态）提交](../yida-canvas-custom-page/references/data-bridge-guide.md#公开访问匿名态提交)。
+
+配置时必须先查询并锁定 `DEFAULT` 组的 `packageUuid`，复制其完整 `dataPermit`，只在原有 `rule` 中补入 `FREE_LOGIN`，保留 `ORIGINATOR` 及其他已有规则、`customDepartmentData`、`formulaData` 等非目标内容；不得用固定的 `ORIGINATOR + FREE_LOGIN` 模板覆盖现网规则。保存后按同一 `packageUuid` 回读，确认 `FREE_LOGIN` 存在且其他规则未漂移。
+
 ## 操作权限
 
 `operations` 至少有一个值为 true 的操作。当前 CLI 白名单为：

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

@@ -84,7 +84,7 @@ openyida get-form-config <appType> <formUuid> --json
 ## UI 和验收
 
 - 导航表达应用身份、业务层级和当前位置；选中态清晰，图标使用 `lucide-react` 或 `@ant-design/icons`，不用 emoji、字母占位或 CSS 拼图标。
-- 视觉对照 `design.md` 和用户参考检查导航位置、比例及首屏/滚动态。导航消费应用主题 token，不另注全局主题。
+- 视觉按 [导航与应用框架](../yida-design/references/application-theme-consistency.md#导航与应用框架) 落实 `design.md` 的完整导航 token；背景、文字、悬停/选中、边界、形状、字体和间距与表单、详情和内容区协调。对照用户参考检查位置、比例及首屏/滚动态，样式由当前导航组件消费应用主题。
 - 导航选中态已标明当前页时，内容区从业务开始；独立页头只补充对象、任务说明或操作，避免重复菜单标题。
 - 侧栏已验证折叠、恢复宽度、拖拽上下限和内容联动；顶部窄屏可展开菜单，Dock 不遮内容和主要操作。
 - 按范围验收：应用级自定义导航核验应用 `hideAppNav` 与各页 `renderNav=false`；仅前台菜单核验该页独立展示，并确认后台应用导航仍可用。配置均需持久化并回读；菜单可见性、选中态、内容与路由一致，深链、刷新及前进后退正常。

package/yida-skills/skills/yida-nav-shell/references/nav-shell-patterns.md

@@ -265,6 +265,8 @@ hash 的 `view` 保存任务入口 key，刷新及前进后退恢复选中内容
 | 导航表面与标题 | `--pod-shell-theme-bg-color`、`--pod-nav-logo-text` |
 | 普通 / 悬停 / 选中 / 禁用文字 | `--pod-nav-item-text-*` |
 | 悬停 / 选中背景 | `--pod-nav-menu-bg-hover-color`、`--pod-nav-menu-bg-selected-color` |
+| 普通 / 悬停 / 选中边框 | `--pod-nav-menu-item-border`、`--pod-nav-menu-item-hover-border`、`--pod-nav-menu-item-selected-border`，填写完整边框值，各状态保持相同线宽 |
+| 菜单选中标记 | `--pod-nav-menu-item-selected-shadow`；`none` 关闭，其他值使用完整 `box-shadow`，可表达左、右或底部内阴影 |
 | 分隔线、选中指示、焦点 | `--pod-nav-sub-divider-color`、`--pod-nav-tab-line-selected-color` |
 | 菜单高度、圆角、文字、间距 | `--pod-nav-menu-*`、`--pod-nav-top-tab-*` |
 | 悬浮阴影 | `--pod-nav-popup-shadow` |
@@ -272,6 +274,10 @@ hash 的 `view` 保存任务入口 key，刷新及前进后退恢复选中内容
 | 自定义页整页画布 | `--pod-page-bg-color`（与原生页面统一）、`--pod-nav-page-padding` |
 | 业务卡片 | `--pod-card-bg-color`、`--pod-card-border` |
 
+`canvas-nav-side/top/mixed/dock` 共用上述菜单圆角、三种边框和选中阴影。已有自绘导航重新导出对应片段、合入页面源码并发布后生效；`canvas-nav-tabs` 继续使用页内标签样式。
+
+侧栏和 Dock 菜单项使用 `--pod-nav-menu-item-height` 与 `--pod-nav-menu-item-padding`；顶部菜单和混合导航的顶部分组使用 `--pod-nav-top-tab-height`、`--pod-nav-top-tab-item-padding` 与 `--pod-nav-top-tab-item-max-width`。侧栏、顶部和混合导航的菜单间距读取 `--pod-nav-menu-gap`；Dock 使用 `--pod-nav-slide-collapsed-menu-gap`。侧栏外部留白读取 `--pod-nav-slide-aside-padding`，混合导航侧栏读取 `--pod-nav-l-aside-padding`。顶部横向滚动区预留半个菜单间距供阴影展示；外阴影较大时增加间距，并检查长名称截断、折叠态和窄屏菜单。案例取值见 [导航形状与密度](../../yida-design/references/application-theme-consistency.md#导航形状与密度的案例经验)。
+
 主题由 `yida-design` 在应用级生成和配置；导航组件消费已有变量，必要的默认值放在 `var(...)` 回退中。颜色修改在主题文件完成，固定的布局结构留在组件中。导航深浅由导航主题决定，业务内容明暗由页面主题决定，分别验证。
 
 ## 验证

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

@@ -20,6 +20,15 @@ description: 为已有页面设置公开访问、组织内分享，或隐藏该
 
 页面使用哪类数据、是否允许公开、openAuth 对当前页面和组织开放哪些资格，必须来自平台能力、用户确认或实际查询证据。本技能不根据页面类型或数据源猜测资格。
 
+## 匿名（免登）提交前置条件
+
+当用户要求"自定义页面在公开访问下提交数据到表单"或"走免登提交接口"时，作为前置门禁：
+
+1. **显示页和目标表单都需要 `isOpen`**：分别运行 `openyida get-page-config <appType> <显示页formUuid>` 和 `openyida get-page-config <appType> <目标formUuid>`，两者都返回 `isOpen === 'y'` 才承诺匿名提交。缺任一时先启用公开访问或改回登录态方案。
+2. **目标表单权限需包含 `FREE_LOGIN`**：运行 `openyida get-permission <appType> <目标formUuid>`，DEFAULT 权限组的 `dataPermit.rule` 须包含 `{"type":"FREE_LOGIN","value":"y"}`。缺少时按 `yida-form-permission` 锁定 DEFAULT 组 `packageUuid`，在完整现有 `dataPermit` 中只补该规则并保留其他规则，禁止用固定模板覆盖现网权限。
+3. 页面运行时分流是**匿名态**决定的，不是"表单公开"决定的：具体分流写法和 `RECEIPT_SAVE_FORM_DATA` 网关契约见 [`yida-canvas-custom-page/references/data-bridge-guide.md`](../yida-canvas-custom-page/references/data-bridge-guide.md) 的"公开访问（匿名态）提交"章节。
+4. 匿名提交的能力边界（不能发起流程、唯一性校验不生效、成员/部门/关联字段不支持、提交人恒为匿名、附件默认不跨组织）由平台限制决定；需要这些能力时改用登录态页面 + 关闭公开访问。
+
 ## 铁律
 
 1. **目标必须可证明**：appType 和 formUuid 从创建/查询命令或当前项目 config.json 获取；证据冲突时停止。

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

@@ -30,6 +30,7 @@ description: 基于整理好的需求事实编写或修改业务 PRD，负责业
 - 用户存在 `explicitScope` 时，以该范围规划页面、表单、流程、报表和本轮交付。
 - 真实 `appType`、`formUuid`、`fieldId`、`processCode` 以资源证据为准；实现阶段产生的 ID 写入 `.cache/<项目名>-schema.json`。
 - 每个 display 页面提供 `pageSpecHandoff`，包含场景、区块、数据来源、主操作，以及指向对应 `design.md` 的 `designFile` / `designRefs`。视觉细则由 `yida-design` 维护。
+- 导航结构、菜单顺序和默认入口由业务任务确定；导航外观与应用框架、表单、记录详情和自定义页面交给 `yida-design` 统一设计。PRD 保留整体风格摘要与设计引用，完整 token 和消费规则只在 `design.md` 维护。
 
 ## 按需参考
 

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

@@ -105,7 +105,7 @@
 | --- | --- |
 | 设计文件 | `prd/<项目名>/design.md` |
 | 应用主题色 | <平台预置 key 或自定义色盘名称；必须与 design.md 的 Theme Profile 一致> |
-| 风格摘要 | <2-3 个业务风格关键词，例如高效协同、稳重可信、经营洞察；完整 UI 设计见 design.md> |
+| 风格摘要 | <概括导航、应用框架、表单、记录详情与自定义页面共同采用的视觉特点；完整规则见 design.md> |
 | 主题交付 | <平台预置 / 应用自定义主题文件 / 继承当前应用；具体 themeProfile、token、主题文件交付策略见 design.md> |
 | 明暗模式 | <light 默认；dark 只在明确暗色/夜间/高对比/黑金时使用；具体色阶见 design.md> |
 | 页面设计引用 | <逐页列出 designRefs，不复制 design.md 内容> |
@@ -187,7 +187,7 @@
 | 初始示例数据 | <完整应用默认已为核心普通表单写入 1-3 条业务化示例记录并 query 抽查；跳过时说明原因> |
 | 数据查看 | <默认使用表单数据管理页；自定义列表 / 看板 / 详情显示真实数据或空态> |
 | 权限 / 流程 | <权限规则或流程节点生效> |
-| 视觉一致性 | <主题色、布局密度、状态、图标和当前业务一致> |
+| 视觉一致性 | <实际导航、应用框架、表单提交/编辑、记录详情和自定义页面的配色、形状、文字、间距与状态符合 design.md；分别记录已验证页面> |
 | 导航可用 | <导航顺序符合 PRD，主入口靠前，配置/低频资源靠后> |
 ```
 

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

@@ -11,7 +11,7 @@
 3. 导航分组：按角色路径和业务主次确定入口数量、顺序和分组，通常工作台或首页在第一位。自定义导航按这份规划展示，访问态接口仅过滤当前用户不可见的入口。
 4. 表单/流程关系：录入、审批、权限、校验交给原生表单和流程。
 
-按目标用户的主任务分别规划：服务前台默认一个 coding 页面完成浏览、填写和结果等已选视图；后台或统一工作区按操作效率选择原生或 coding，不以“后台”强制原生。计划采用原生能力时，办理任务用提交页，查询维护用数据管理页。同一表单可对应“活动报名”和“报名管理”等不同入口；将用途写入页面 `purpose` 和交互说明，供实现阶段选择路由。
+按目标用户的主任务分别规划：服务前台默认一个 coding 页面完成浏览、填写和结果等已选视图；业务后台或不分前后台的系统按操作效率选择原生或自定义页面，不以“后台”强制原生。计划采用原生能力时，办理任务用提交页，查询维护用数据管理页。同一表单可对应“活动报名”和“报名管理”等不同入口；将用途写入页面 `purpose` 和交互说明，供实现阶段选择路由。
 
 自定义导航将每个入口的用途、目标资源和打开方式写清：管理视图走 `workbench/{formUuid}`，直接填写走 `submission/{formUuid}`；同一表单可对应两个独立入口，不重复创建表单。保留自绘导航时，表单在主内容区 iframe 打开；跨真实页面默认当前标签跳转；页面内新增/详情按钮使用抽屉。参数与路由规则见 [链接参考](../../../references/field-and-url-reference.md)。
 

package/yida-skills/skills/yida-requirement-analysis/references/experience-groups.md

@@ -1,18 +1,54 @@
-# 使用关系与入口建议
+# 判断是否分前后台
 
-收到有效功能选择后，需要新增或修正入口判断时读取。根据谁来使用、完成什么任务，规划实际访问路径。
+收到有效功能选择后，需要新增或修正入口判断时读取。这里的前台和后台都是用户使用系统的页面（访问态）；开发者修改字段、流程和应用配置的 `/admin` 另行交付。
 
 ## 判断依据
 
-- **统一入口**：任务处于同一工作上下文，角色之间主要差异是权限、处理步骤或数据范围，使用同一工作区。为实际在线操作的人规划入口；同一人也可能同时有个人办事和整体管理两种使用体验。
-- **服务/管理双入口**：已选任务同时包含可独立完成的服务使用路径和业务管理路径，两者目标、使用频率或完整操作路径不同。服务使用者能直接办事并查看结果，无需进入管理工作区。
-- **仅服务任务**：已选功能只有自助办理、查询或展示时，规划对应前台入口。
+- **只有访问后台**：本次只给工作人员提供录入、受理、处理或维护业务的页面。办事人通过电话、外部平台或已有入口发起业务，或者本次不需要办事入口。
+- **只有访问前台**：本次只提供办理、查询或展示页面。纯展示、查询可能无需人工处理；提交后需要处理的业务，要明确由已有系统、已有人员入口或自动流程承接。
+- **不分前后台**：大家使用同一套业务页面，按职责看到不同菜单、数据和操作。适合围绕同一批项目、客户或记录开展工作的情况。
+- **分前后台**：办事的人和处理业务的人分别进入适合自己的页面。前台用户能直接办理、查看结果；后台人员处理收到的业务。两边的主要任务、查看内容或操作步骤有明显差异时，建议分开。
 
-例如，用户选择“员工提交报修、查看自己的进度”及“维修人员处理工单”，可以建议独立报修入口和维修工作区；仅选择维修人员登记、处理和统计工单，通常建议统一工作入口。
+不同角色可以使用同一套页面，分别配置权限；同一个人也可以同时使用前台和后台。根据实际任务判断是否分开，系统名称和角色数量只作为背景信息。
+
+“只有访问后台”和“不分前后台”都可以用一套页面加权限实现。前者强调工作人员受理、运营或处理业务，后者强调大家围绕项目、任务等共同工作。需求没有明显的受理或运营关系时，使用“不分前后台”的说法。前后台的划分也不代表公开访问、匿名访问或应用管理权限。
+
+| 已确认的实际用法 | 建议 | 谁使用、看到什么、能做什么 |
+| --- | --- | --- |
+| 项目成员处理任务，负责人分配任务、查看进度 | 不分前后台 | 使用项目和任务页面，按职责显示数据与操作 |
+| 销售维护自己的客户，主管查看团队客户 | 不分前后台 | 使用客户列表和详情，按权限区分数据范围 |
+| 客户自己预约，员工安排和处理预约 | 分前后台 | 客户看可预约服务和自己的预约；员工看待处理预约和排期 |
+| 员工报修、查进度，维修人员接单、处理 | 分前后台 | 员工看“我要报修、我的报修”；维修人员看“待处理工单、我的工单” |
+| 只有维修人员登记、处理和统计外部渠道收到的工单 | 只有访问后台 | 直接使用工单列表、处理页面和所需统计 |
+| 员工登记电话预约，或处理外部商城同步的订单 | 只有访问后台 | 员工登记、排期，或审核订单、发货 |
+| 本次提供活动报名，工作人员在已有入口处理 | 只有访问前台 | 报名人填写、提交信息，处理沿用已有入口 |
+| 本次只展示产品或查询已有进度 | 只有访问前台 | 用户浏览或查询，数据来源按实际需求接入 |
+| 团队成员预订会议室，负责人维护可用资源 | 不分前后台 | 共用会议室和预订页面，按职责显示操作 |
+
+## 判断顺序
+
+1. 列出本次实际使用者和任务，明确哪些办理或处理功能已在其他渠道完成。
+2. 本次只提供业务受理、运营或维护页面，办理发生在别处或不在本次范围内时，选择“只有访问后台”。仅凭“内部员工使用”不足以判断为后台。
+3. 本次只有办理、查询或展示任务时，选择“只有访问前台”。需要处理的提交，须在已有 `entryRecommendation.reason` 和业务流程中说明由谁承接；尚未明确时记入 `openQuestions`，补问实际处理方式，不擅自扩建后台，也不声称业务已完整。
+4. 办理和处理都在本次范围内时，比较双方所需页面：任务和内容明显不同，选择“分前后台”；共用业务页面即可完成工作，选择“不分前后台”。
+5. 没有明确的办事与受理关系，大家共同维护项目、客户或任务时，选择“不分前后台”，按职责配置菜单、数据和操作。
+
+用户明确只交付某一端时沿用范围，说明它与已有业务的关系。四种说法描述本次交付范围，不要求每个应用都搭建两端。
+
+## 向用户怎么说
+
+直接说明是否分前后台，再列出谁使用、看到什么、能做什么。例如：
+
+- “这个项目管理系统不分前后台，成员处理任务，负责人分配任务、查看团队进度，菜单和数据按权限显示。”
+- “这个预约系统分为客户预约前台和员工处理后台，两边共享预约数据。”
+- “这个系统只有员工使用的业务后台，员工登记电话预约并安排时间。”
+- “本次只做活动报名前台，报名人填写并提交信息，工作人员在已有报名管理页面处理。”
+
+用法不明确且会影响页面规划时，补问具体用法，例如“这个预约系统是让客户自己预约、员工处理，还是只供员工内部登记预约？”已有答案直接复用，用户委托决定时说明建议依据。
 
 ## 首页按任务选择
 
-后台和统一工作区先满足实际使用者的高频任务，不因“管理系统”“后台”“暗黑风格”推导出驾驶舱。Fast 与 Plan 使用同一判断：
+业务后台或不分前后台的系统，先满足实际使用者的高频任务，不因“管理系统”“后台”“暗黑风格”推导出驾驶舱。Fast 与 Plan 使用同一判断：
 
 前台也要确定默认页面和菜单顺序：展示、发现、办理或进度查询，按实际首要任务选择。前后台分别记录“进入后先到哪一页、先看到什么、接下来去哪里”，具体交接见 [每个入口都确定首页与菜单顺序](../../yida-app/references/entry-navigation.md#每个入口都确定首页与菜单顺序)。
 
@@ -32,11 +68,11 @@
 
 ## 与导航和资源分开
 
-双入口默认由同一个应用承载，共用业务数据。访问范围与权限按用户要求单独配置。
+分前后台时，默认在同一个应用内提供两套入口，共用业务数据。是否分前后台与是否创建两个应用分别判断；访问范围与权限按用户要求单独配置。
 
 入口建议确定后，下游 AI 按 [导航决策](../../yida-design/references/navigation-decision.md) 选择各入口的页面承载和菜单。
 
-业务管理工作区承载订单处理、维修管理等已选业务任务；`/admin` 用于应用开发管理。
+业务后台处理订单、工单等已选业务；`/admin` 用于应用开发管理。
 
 ## 交接要求
 

package/yida-skills/skills/yida-requirement-analysis/references/handoff.md

@@ -21,7 +21,7 @@
 | `constraints` | 组织、设备、权限、交付限制；`prohibitedActions` 同时保留禁止原文和规范化动作 `theme-file/page-source/publish` |
 | `assumptions` / `openQuestions` | 分别记录可调整的建议，以及影响业务范围或实际用法的关键待答问题 |
 | `userTasks` | `{key,user,functionRefs,source,reason}` 数组；functionRefs 引用有效功能的稳定 key，旧字符串项引用原文，不重复复制功能内容 |
-| `entryRecommendation` | `{mode,source,reason,entries}`；mode 为 `unified/service-management/frontend-only/undetermined`，每项 `{key,name,taskRefs}` 引用 userTasks；可补 `role: service/management/workspace`、`sceneKey` 和 `presentationHint`。旧 unified 单前台记录仍可复用 |
+| `entryRecommendation` | `{mode,source,reason,entries}`；mode 为 `unified`（不分前后台）、`service-management`（分前后台）、`frontend-only`（只有访问前台）、`backend-only`（只有访问后台）、`undetermined`（实际用法待明确），每项 `{key,name,taskRefs}` 引用 userTasks；可补 `role: service/management/workspace`、`sceneKey` 和 `presentationHint`。backend-only 的入口 role 使用 management；新建不分前后台的入口通常使用 workspace。旧 unified 记录保留原值和角色，不自动改分类 |
 | `evidence` | 必要时用 `{path,source,reason}` 数组为旧字段保留简短来源；path 使用 JSON Pointer 指向当前有效值，数组变化后同步更新 |
 
 来源统一区分 `user_explicit`（用户直接说明）、`user_selected`（可见选项的回答）、`ai_inferred`（有业务依据的推导）、`ai_default`（技能默认建议）。导航沿用既有兼容规则：AI 决策写 `ai_default` 并在 reason 说明依据，用户明确指定归属才写 `user_selected`。用户委托的具体方案仍是 AI 推导，reason 保留委托依据。
@@ -39,13 +39,13 @@
 
 由 `yida-app` 按 [规划准备](../../yida-app/workflow/step-2-design.md#规划准备) 补齐页面场景、导航和主题，AI 新增内容记录来源并遵守 explicitScope。
 
-Plan 在 `design-plan init` 前必须补齐合法的导航字段（见下节）及 `visualSelection.themeId`。视觉沿用 `visualSelection` 的 `themeId/visualDirection/colorStrategy/navigationStyle`，AI 补齐颜色或主题时标记 `ai_default`。Fast 共用这些字段。主题 ID 尚未确定时，通过 `openyida design-plan catalog --json` 查询合法主题及页面模式，复用本轮查询结果。
+Plan 在 `design-plan init` 前必须补齐合法的导航结构（见下节）及 `visualSelection.themeId`。视觉沿用 `visualSelection` 的 `themeId/visualDirection/colorStrategy/navigationStyle.structure`，AI 补齐颜色或主题时标记 `ai_default`。`navigationStyle.tone` 不在 brief 中推导，由 CLI 从所选主题模板的 `navTheme` 派生；Fast 共用同一规则。主题 ID 尚未确定时，通过 `openyida design-plan catalog --json` 查询合法主题及页面模式，复用本轮查询结果。
 
-补齐主题和颜色前，按[设计方向比较](../../yida-design/references/theme-selection.md#设计方向比较)完成一次内部比较；保留用户明确的风格，AI 建议记录具体业务依据。
+补齐主题和颜色前，按[设计方向比较](../../yida-design/references/theme-selection.md#设计方向比较)生成共用的三套方向；Fast 内部选择，Plan 在没有明确完整风格时通过 `ask_human` 选择。保留用户明确的风格，AI 建议记录具体业务依据。
 
 `visualSelection.colorStrategy` 使用对象：`primaryColor` 填本项目选定的 6 位 HEX 色值，`primaryColorName` 填对应色名，`usage` 写配色依据及背景、主操作和强调色的关系。只有文字配色要求时也可先保存字符串；CLI 将原文放入 `usage`，并提示补齐 `primaryColor`。
 
-PRD 将 userTasks 与入口建议转为页面的访问路径、任务和权限；Plan 的 business.json 使用现有 facts 契约，视觉设计共用入口和导航记录。
+只有访问前台且提交后需要处理时，在 `entryRecommendation.reason` 和业务流程中记录承接方式，未明确的内容保留在 `openQuestions`；无需新增字段。PRD 将 userTasks 与入口建议转为页面的访问路径、任务和权限；Plan 的 business.json 使用现有 facts 契约，视觉设计共用入口和导航记录。
 
 ## 前后台导航交接
 
@@ -57,7 +57,7 @@ PRD 将 userTasks 与入口建议转为页面的访问路径、任务和权限
 
 管理端采用自定义页面也默认使用 `platform-shell`；其 menu 描述平台任务，不直接渲染为页面导航。只读交接中的 `navigationPolicy` 由 CLI 派生，不写回 brief 或 pageSpecHandoff。导航按[方案讨论与确认](../../yida-design/references/navigation-decision.md#方案讨论与确认)随业务方案说明。
 
-例如：报修前台为 standalone + custom，维修工作区为根级 platform-side。Plan 初始化保留 pageSpecHandoff，PRD、design 和计划分别展示各入口方案。导航执行和验证按 [导航壳配置](../../yida-nav-shell/SKILL.md#必做配置) 完成；页面访问范围和数据权限按用户要求独立配置。
+例如：报修前台为 standalone + custom，维修后台为根级 platform-side。Plan 初始化保留 pageSpecHandoff，PRD、design 和计划分别展示各入口方案。导航执行和验证按 [导航壳配置](../../yida-nav-shell/SKILL.md#必做配置) 完成；页面访问范围和数据权限按用户要求独立配置。
 
 规划阶段按 [访问态入口契约](../../yida-app/references/entry-navigation.md) 补齐 entryRecommendation.entries 的 role、menu、defaultMenuKey 和权限依赖。Plan 初始化保留建议并要求业务片段补齐；Fast PRD 使用同一结构。
 

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

@@ -1,6 +1,19 @@
 # 首轮需求分析
 
-流程：理解需求 → 核心功能候选 → 用户选择或补充 → 使用关系与入口建议 → 整合输出。已有充分信息时跳过相应提问。
+流程：理解需求 → 核心功能候选 → 用户选择或补充 → 判断是否分前后台 → 整合输出。已有充分信息时跳过相应提问。
+
+## 适用阶段与续做
+
+先核对当前需求范围、历史回答和同任务 brief，再决定是否进入下方首轮流程。已有应用或表单不能单独作为需求已确认的依据。
+
+- **首次澄清**：当前范围尚未确认时，按下方流程补齐关键需求；用户已明确的内容直接采用。
+- **继续任务**：有效历史回答或同任务 `intake.confirmed=true` 已覆盖当前范围且未被撤回时，复用答案，返回 `yida-app` 的未完成阶段。刷新、恢复、压缩或“继续”不触发重新首问。
+- **材料缺失**：brief 丢失但历史答案完整时，用已有答案恢复材料。无法核实的内容保持未确认；只有缺失或冲突会影响下一步时才补问，不重新生成已回答的功能候选。
+- **需求变化**：直接更新用户明确新增或撤回的内容，未变化的部分沿用原确认；只补问影响下一步的未决差异。用户明确要求重新设计或从零新建时，按新范围推进。
+
+仅调整方案时保留已有资源；重新设计也不自动授权删除或重建，资源操作仍遵循用户范围和相应权限确认。
+
+`intake.confirmed` 仅表示需求澄清完成，不能替代 Plan 当前 revision 的批准或工具权限确认。
 
 ## 1. 理解需求，形成候选
 
@@ -37,10 +50,10 @@
 更新六个维度，再回答三个内部判断问题：
 
 1. 哪些实际使用者和任务保留了？对应哪项有效需求或用户选择？
-2. 这些任务属于同一工作上下文，还是独立的服务使用与业务管理体验？差异是权限、步骤，还是使用目标与完整操作路径？
-3. 保留的服务任务是否形成独立入口路径？使用者能否从该入口直接办事、查看结果，无需进入管理工作区？
+2. 大家是否使用同一套业务页面、按职责区分菜单和权限？还是办事的人与处理业务的人，需要看到不同内容、完成不同操作？
+3. 本次只需要前台、只需要业务后台，还是两边都需要？只有前台且提交后需要处理时，由哪个已有系统、人员入口或自动流程承接？
 
-需要新增或修正判断时，读取 [使用关系与入口](../references/experience-groups.md)，按有效任务提出统一入口、服务/管理双入口或仅前台建议，并按其中“首页按任务选择”确定打开后先处理什么；既有依据未变时直接复用。双入口可以共用一个应用；前后台均可使用 coding 或原生页面，具体实现由下游规划。
+需要新增或修正判断时，读取 [判断是否分前后台](../references/experience-groups.md)，按有效任务提出“只有访问后台”“只有访问前台”“分前后台”或“不分前后台”的建议，并按其中“首页按任务选择”确定打开后先处理什么；既有依据未变时直接复用。分前后台可以共用一个应用；前后台均可使用自定义页面或原生页面，具体实现由下游规划。
 
 缺少的实际用法证据会改变结论时，补一道能区分用法的问题。下游 AI 根据业务任务确定各入口的导航方式，规划展示、布局和实现方式。根据回答推导的方案标记为 AI 建议，随整体计划展示。
 

package/yida-skills/skills-index.json

@@ -24,7 +24,7 @@
       "path": "skills/yida-app/SKILL.md",
       "display_name": "宜搭完整应用开发",
       "description": "创建完整宜搭应用，或补齐已有应用时使用。先确认核心功能和实际用法；Fast 直接搭建，Plan 先确认方案。由 yida-prd 和 yida-design 同时准备业务与基础视觉，校验后创建或复用资源；表单/流程先于自定义页面。页面 UI 按已确认设计实现，代码示例按需参考；发布后优先按 PRD 导航顺序排序，检查后交付入口。",
-      "done_when": "需求和方案已确认，业务与视觉说明一致；PRD 已写入 prd/<项目名>/prd.md，design.md 已写入 prd/<项目名>/design.md。仅修改单页时，发布成功后返回当前页面 URL；没有 publish 证据只能声明源码已修改，尚未发布。完整应用按实际范围交付一组入口：管理端按默认任务返回 {base_url}/{appType}/workbench 或已验证的 /workbench/{formUuid}（需要时带真实 viewUuid）；独立前台仅在页面配置回读 renderNav=false（仅缺少 renderNav 时兼容 isRenderNav）且访问验证通过后交付 /custom/{formUuid}；完整应用默认提供 create-app 或 app-list 返回的 adminUrl（开发者管理后台），不受宿主或登录方式影响；仅前台时不追加业务后台，交付前台与开发者管理后台；有前后台时交付三个地址，统一工作区交付工作台与开发者管理后台。用户明确排除的入口除外，地址生成不等于已验证访问权限。final 先用 2-3 句业务语言总结创建/复用了哪些表单、页面和流程，再给主入口链接；不默认输出表格、长列表或资源 ID。缺少真实权限或多身份验证时明确说明未完成。",
+      "done_when": "需求和方案已确认，业务与视觉说明一致；PRD 已写入 prd/<项目名>/prd.md，design.md 已写入 prd/<项目名>/design.md。仅修改单页时，发布成功后返回当前页面 URL；没有 publish 证据只能声明源码已修改，尚未发布。完整应用按实际范围交付一组入口：管理端按默认任务返回 {base_url}/{appType}/workbench 或已验证的 /workbench/{formUuid}（需要时带真实 viewUuid）；独立前台仅在页面配置回读 renderNav=false（仅缺少 renderNav 时兼容 isRenderNav）且访问验证通过后交付 /custom/{formUuid}；完整应用默认提供 create-app 或 app-list 返回的 adminUrl（开发者管理后台），不受宿主或登录方式影响；仅业务后台时交付业务后台与开发者管理后台，不追加前台；仅前台时不追加业务后台，交付前台与开发者管理后台；有前后台时交付三个地址，不分前后台时交付系统入口与开发者管理后台。用户明确排除的入口除外，地址生成不等于已验证访问权限。final 先用 2-3 句业务语言总结创建/复用了哪些表单、页面和流程，再给主入口链接；不默认输出表格、长列表或资源 ID。缺少真实权限或多身份验证时明确说明未完成。",
       "category": "yida-skills/app",
       "tags": [
         "宜搭",
@@ -996,7 +996,7 @@
       "name": "yida-nav-group",
       "path": "skills/yida-nav-group/SKILL.md",
       "display_name": "应用左侧导航分组",
-      "description": "整理宜搭已有的导航菜单时使用。支持查看菜单、新建或调整分组、移动和排序页面、隐藏或显示菜单项。 PRD 写明导航顺序时用 order；旧版共用工作区缺少明确顺序时用 auto-order 兜底。",
+      "description": "整理宜搭已有的导航菜单时使用。支持查看菜单、新建或调整分组、移动和排序页面、隐藏或显示菜单项。 PRD 写明导航顺序时用 order；旧版不分前后台的应用缺少明确顺序时用 auto-order 兜底。",
       "category": "yida-skills/app",
       "tags": [
         "导航",