openyida 2026.9.24 → 2026.10.8

package/lib/design-plan/init.js

@@ -233,7 +233,8 @@ function initialize(inputPath, options = {}) {
     '# 计划编写上下文', '', `需求事实：${input}`, `计划目录：${outputDir}`, '',
     `读取本上下文、编写契约和 business.json；按 authoring.pendingFields 补齐事实，保留 base 与已有需求。business facts 填写 overview、dataModels、businessFlows、pages 和可选 execution；视觉填写 visual.json。复核业务覆盖后设置片段 ready=true，再执行：${materializeCommand}。使用成功结果中的 HTML 路径展示“当前方案”，revision 仅放在内部确认字段，不写入用户可见标题、摘要或问题。视觉片段按每页实际任务补齐焦点、布局、主操作、响应式与验收；已完成的选择直接复用。`, '',
     '## 本轮编写重点', '设计功能范围、数据与规则、页面组织、关键交互和业务验收。页面 blocks 按优先顺序填写 {name,purpose}；CLI 派生默认内容优先级与内容层次，保留明确填写的独立设计。通用状态和验收检查由 CLI 补齐，interactionStates 与 acceptanceCriteria 填写项目差异。', '',
-    '首页按使用者的主要任务选择：集中办事可用门户式工作台（workbench），单项任务可直达原生业务页；只有已确认的指标分析或投屏监控任务才规划 dashboard/screen。工作台按需求组织待办、操作队列、业务列表和常用入口，辅助统计不改变页面主任务。不得从后台身份、系统名称或暗色风格自动增加驾驶舱。完整规则见 yida-requirement-analysis/references/experience-groups.md 的“首页按任务选择”。', '',
+    '首页按使用者的主要任务选择：集中办事可用门户式工作台（workbench），单项任务可直达原生业务页；只有已确认的指标分析或投屏监控任务才规划 dashboard/screen。工作台是围绕应用核心业务，把全局概况、业务管理、分析判断、异常处理和常用快捷入口组织在一起的综合工作空间；包含分析区块不自动改变整页主任务。不得从后台身份、系统名称或暗色风格自动增加驾驶舱。完整规则见 yida-requirement-analysis/references/experience-groups.md 的“首页按任务选择”。', '',
+    '工作台按角色与业务关系规划，参考 8-10 个有独立价值的区块；采用适合信息特点的表现形式，数据和洞察有依据，操作与快捷入口可用，不套固定列表组合。', '',
     '无论是否分前后台，每个业务入口都要确定默认页面、菜单及分组顺序、打开后的首屏任务。menu 数组记录展示顺序，defaultMenuKey 记录默认任务；按角色需求决定，不按资源创建先后排列。平台导航通过排序命令落实，自定义导航通过页面菜单落实，frontend-only 也必须完成入口排序与首页验收。', '',
     '入口方案沿用 execution.entryRecommendation：unified 表示不分前后台，service-management 表示分前后台，frontend-only 表示只有访问前台，backend-only 表示只有访问后台。向用户说明谁使用、看到什么、能做什么；只有前台且提交后需要处理时，在 reason 和业务流程中说明承接方式；逐入口补齐 role、menu 和 defaultMenuKey，前台关联独立页面 sceneKey。任何身份的入口含 local 菜单时，entry.sceneKey 必须关联承载页面，menu.resource 等于页面 name，viewKey 非空。管理端可直接落到原生业务视图，不强制创建首页。所有叶子菜单按资源、视图和操作记录 access 权限依赖，平台导航排序从管理菜单派生。详见 yida-app/references/entry-navigation.md。', '',
     theme.mode === 'creative'

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "openyida",
-  "version": "2026.9.24",
+  "version": "2026.10.8",
   "description": "OpenYida CLI - 宜搭低代码 AI 开发工具（安装即用，零配置）",
   "bin": {
     "openyida": "bin/yida.js",

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

@@ -108,7 +108,7 @@ Plan 规划阶段的工作流入口只读取 `workflow/step-1-resource-context.m
 - 需要收集或存储数据：先创建或复用核心普通表单，再生成页面；纯展示或静态内容可跳过表单创建。
 - 需要审批、申请、审核、工单流转：先创建或复用流程表单，再生成页面。
 - 需要标准统计：优先创建原生报表；明确高级图表或大屏时，再选择 `yida-rechart` / `yida-chart`。
-- 按页面主任务选技能：经营分析、指标判断或投屏监控页面加载 `yida-dashboard`；待办、操作队列、业务列表和门户式工作台由 `yida-canvas-custom-page` 实现，不能仅凭“工作台”或“看板”名称加载经营看板技能。页面读取任何表单业务数据时继续加载 `yida-canvas-data-binding`。
+- 按页面主任务选技能：经营分析、指标判断或投屏监控页面加载 `yida-dashboard`；综合工作台由 `yida-canvas-custom-page` 实现，按 PRD 组织内容；其中的分析、洞察及快捷操作按实际需要实现，不能仅凭“工作台”或“看板”名称加载经营看板技能。页面读取任何表单业务数据时继续加载 `yida-canvas-data-binding`。
 - PRD 明确包含报表或集成自动化时，它们属于 Step 4 主流程资源，不得推迟到 final 后置建议；自动化动作必须按通知、数据新增/更新、审批完成、定时或手动触发分别建模，不得统一退化成新增通知。
 
 ## 页面数据契约

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

@@ -28,7 +28,7 @@
 当前页需要图片时，先查看已有素材任务状态，同时编写布局、文字、真实数据绑定和交互。尚未启动时，按 [后台启动与接收](../../yida-image-assets/SKILL.md#后台启动与接收) 派发 `yida-image-assets`，随后继续页面开发。接图时读取所属页结果，独立工作完成后才等待该页图片。使用 `--design design.md --page-id <pageId>` 核对当前页槽位并发检查图片，允许外链就直接使用；上传时追加 `--app-type <真实appType>`。结果写入独立的 `asset-manifests/<pageId>.json`，上传失败时保留已验证且允许外链的原地址。读取 manifest 中当前页 `pages[].materialStatus`；该页为 `final` 时只使用 `assets[].materialStatus=final` 的图片。必需槽位缺口只阻塞当前页接图与验收，总状态 `draft` 不阻塞其他已就绪页面。
 
 1. 自定义页面开发执行 `use_skill("yida-canvas-custom-page", "生成当前页面源码")`。根据 PRD 和 `design.md` 直接编写 `.canvas.jsx` / `.canvas.tsx`；允许从空文件实现完整 UI。内置整页示例按需用于理解数据接入和导航；表单抽屉片段必须按第 9 条整体合并，不要求复制整页，也不能用示例默认外观替代已确认的设计。已有符合设计的页面可继续迭代。
-2. 按 PRD 的主任务和 scene 选用专项技能：经营分析或投屏监控页执行 `use_skill("yida-dashboard", "实现已规划的指标分析与监控")`；工作台、门户、操作队列继续使用 `yida-canvas-custom-page`，按 [首页按任务选择](../../yida-requirement-analysis/references/experience-groups.md#首页按任务选择) 落实办理路径。少量任务统计或辅助图表不触发整页看板流程。
+2. 按 PRD 的主任务和 scene 选用专项技能：经营分析或投屏监控页执行 `use_skill("yida-dashboard", "实现已规划的指标分析与监控")`；工作台、门户、操作队列继续使用 `yida-canvas-custom-page`，按 [首页按任务选择](../../yida-requirement-analysis/references/experience-groups.md#首页按任务选择) 落实办理路径。工作台按 PRD 落实管理、分析、洞察与快捷操作；区块内常规图表使用 `yida-rechart`，不因包含图表而触发整页看板流程。
 3. 页面读取任一表单数据时，必须执行 `use_skill("yida-canvas-data-binding", "为页面接入真实表单数据")`；不得以“页面已经能发布”为由跳过。
 4. 页面结构已明确且适合生成器时，从 PRD + `design.md` 派生当前业务自己的 `page-spec.json`。
 5. `page-spec.json` 写 `sourceOfTruth`、`prdFile`、`designFile`、`designRefs` 和 `conflictPolicy: "prd-design-win"`。

package/yida-skills/skills/yida-canvas-custom-page/references/canvas-style-implementation-guide.md

@@ -51,14 +51,15 @@ body.pod-premium.page-type-workbench .vc-page-yida-pure-container:has(> .vc-root
 
 ## 工作台卡片密度红线
 
-工作台、门户首页、业务首页默认是“进入应用后马上处理事情”的工具页，不是通用 SaaS 展示页。实现工作台页面时：
+工作台按 PRD 与 design.md 实现已确定的业务内容及表现形式。列表是可选表达，不是工作台成立的条件。实现工作台页面时：
 
 - 禁止使用“4 个等宽大 KPI 白卡 + 彩色图标盒 + 大数字 0”作为首屏主体；统计摘要按主题采用紧凑条、分段摘要或实际需要的小面板，未定义时可参考 64-88px。
 - 禁止把状态摘要做成横跨整页但内容稀疏的空矩形；如果占满宽度，必须放入趋势、更新时间、筛选、主操作或风险状态。
-- 禁止用 160px 以上的大空态白卡显示“暂无数据”；空态应是薄行、列表内空态或右侧提示条，并带登记/发布/刷新等下一步动作。
+- 禁止用 160px 以上的大空态白卡显示“暂无数据”；空态保留当前视图的必要上下文，并带登记/发布/刷新等下一步动作，不强制转为列表。
 - 快捷入口不要做孤立图标大卡片阵列；高频动作放按钮组、工具条或 40-56px 的紧凑入口，低频动作折叠到更多。
-- 首屏必须至少有一个任务/动态/最近记录/待处理列表承接真实工作流；若当前没有记录，显示可执行空态，而不是把空白面积留给装饰。
-- 页面整体推荐包含 8-10 个有业务目的的区块以上；这些区块应通过密度、主次、分栏和列表节奏形成丰富度，不通过重复大卡片形成面积。区块数量不是实现准出硬门槛，窄场景或用户要求精简时可以更少。计数按区块组算，KPI 子项、快捷入口子项和列表行不能分别计数。
+- 首屏突出 PRD 指定的业务焦点与行动；按信息关系实现时间轴、阶段视图、矩阵、图表、对象总览或办理队列，不能将它们统一降级为记录列表。
+- 综合工作台参考 8-10 个独立业务区块，沿用 PRD 已推导的内容；通过信息增量、主次与适合的表达形成丰富度，不在实现阶段为数量补模块。
+- 区块筛选、对象选择、处理后更新与快捷操作遵循 PRD 的联动范围；数据不足时采用已设计的降级，不编造分析结论。
 
 ## 主题形状、密度与呼吸感落地
 

package/yida-skills/skills/yida-canvas-custom-page/references/page-generation-guide.md

@@ -23,7 +23,7 @@ PRD 写有 `pageSpecHandoff` 时，可以把 `pageSpecHandoff` 转成 `page-spec
 - `sourceOfTruth` 填写 `prdFile`、`designFile`、`designRefs` 和 `conflictPolicy = "prd-design-win"`。
 - spec 与 PRD/design.md 冲突时，按这两份文件重新生成 spec。
 
-按页面任务组织内容：工作台通常包含状态摘要、高频动作、待办、动态和上下文信息；列表页通常包含搜索筛选、列表或表格、详情预览，以及空态和错误时的下一步操作。工作台、首页、门户、看板和展示页推荐 8-10 个有业务目的的区块，窄场景或精简需求按实际任务减少。KPI 子项、快捷入口子项和列表行计入各自所属区块。
+按页面任务组织内容：工作台按 PRD 与 design.md 落实内容、表现形式与操作联动。综合工作台参考 8-10 个独立业务区块，不用固定列表组合或区块数替代业务规划。列表页按实际需要安排筛选、记录、详情及状态反馈。
 
 如果当前页面正文没有具体布局、表面与组件、状态、响应式或验收安排，先补设计事实再实现。圆角、padding、gap 和密度采用选中主题与当前页决定，不能用固定大圆角或统一间距覆盖主题。状态、列表、动作与空态按真实内容组织，不用空白容器撑满首屏。
 
@@ -71,7 +71,7 @@ PRD 写有 `pageSpecHandoff` 时，可以把 `pageSpecHandoff` 转成 `page-spec
 | 官网首页、品牌官网、律所官网、茶叶官网、落地页、门户官网 | `official-homepage` | `landing` | 首屏叙事、可信视觉面板、服务矩阵、信任背书 |
 | 数据大屏、实时监控、预警系统、指挥舱、态势屏 | `data-screen` | `screen` | 中心态势图、左右信息塔、趋势、排行、预警 |
 | 数据看板、经营看板、管理驾驶舱 | `dashboard-overview`，复杂经营大屏切 `data-screen` | `dashboard` | KPI、图表、明细、排行、洞察 |
-| 工作台、运营台、任务中心、业务首页 | `data-management` 或按 `design.md` 自定义结构 | `workbench` | 入口、待办、状态、流程闭环，必须由 `contentBlocks` 驱动 |
+| 工作台、运营台、任务中心、业务首页 | 按 PRD 与 `design.md` 的业务关系自定义结构 | `workbench` | 综合内容与快捷操作由 `contentBlocks` 驱动，队列处理仅在适用时选择 `data-management` |
 | 列表、管理页、订单管理、客户列表、工单池 | `business-list` | `list` | 搜索筛选、表格、状态标签、详情抽屉 |
 | 详情页、客户档案、订单详情、项目详情 | `detail-profile` | `detail` | 单对象摘要、章节、侧栏元信息、时间线 |
 | 主从分栏、工单处理台、左列表右详情 | `split-pane-detail` | `list` | 左侧队列、右侧详情、时间线、动作区 |
@@ -136,11 +136,11 @@ antd 页面按 [CanvasThemeProvider 指南](canvas-theme-provider.md) 统一接
 | `archetype` | 页面类型，如 `overview/analysis/monitor/profile` | 按 scene 推断 |
 | `interactionProfile` | 主操作、详情方式、批量动作、空/载/错状态 | 按 scene 推断 |
 | `functionContract` | 页面美感提升时保留的数据源、字段映射、按钮动作、筛选逻辑、提交 URL、权限、状态 | 现有页面契约 |
-| `insights` | 看板/报告/工作台的数据洞察 | 无则空数组或场景默认洞察 |
+| `insights` | 看板/报告/工作台的数据洞察 | 没有数据和规则依据时使用空数组，不生成场景默认结论 |
 | `designFile` | 当前项目设计契约路径 | 来自 `yida-design` Step 5 |
 | `designRefs` | 当前页面引用的 design.md 章节 ID | 来自 PRD 的 pageSpecHandoff |
 | `themeSummary` | 应用主题色、风格关键词、主题交付方式摘要 | 来自 PRD 摘要，必须与 design.md 一致 |
-| `contentBlocks` | 页面区块清单，工作台/首页/门户/看板/展示页/业务入口页推荐 8-10 个有业务目的的区块以上，但不作为硬门槛；KPI 组、快捷入口组、列表组各只算 1 个区块 | 来自 `yida-design` Step 4 |
+| `contentBlocks` | 页面区块清单，由业务任务与信息关系推导；综合工作台参考 8-10 个独立业务区块，不作为硬门槛，不用子项凑数 | 来自 `yida-design` Step 4 |
 | `domainFidelity` | 实现后由 CLI 回填，标记业务化程度 | 无需手写 |
 
 示例：
@@ -201,9 +201,9 @@ antd 页面按 [CanvasThemeProvider 指南](canvas-theme-provider.md) 统一接
 | `official-homepage` | Real-scene hero、Product/service visual、Process/space story、Visit/service section、CTA |
 | `data-screen` | Command map、Metric grid、Rank panel、Screen insight header |
 
-工作台状态摘要按主题保持紧凑，未定义时可参考 64-88px；不使用横跨整页但内容稀疏的空矩形；快捷入口必须有分组和主次，不能平铺成图标卡阵列；待办、动态、最近记录、洞察、提醒和右侧上下文推荐组合成 8-10 个业务目的区块以上，但不作为硬门槛。空数据也用薄空态行 + 主操作入口，不渲染大块空白卡片。
+工作台状态摘要按主题和真实内容确定尺寸，不使用横跨整页但内容稀疏的空矩形；快捷入口按角色、高频程度和业务关联组织。不同区块依据信息关系实现各自的表达，不套固定摘要、列表和侧栏组合。空数据保留适用视图与下一步动作，不渲染大块空白卡片。
 
-展示型自定义页面验收时检查 `contentBlocks` 或源码结构：工作台、首页、门户、看板、展示页和业务入口页应有足够多有业务目的的区块；每个区块承担不同任务，例如判断状态、发起动作、筛选、处理待办、查看动态、看洞察、看异常、进入详情、处理空态或补充上下文。区块数量不作为阻塞实现的硬门槛。若 PRD 只写“`KPI 卡片: 学生总数, 课程总数, 本月出勤率, 平均分`、`快捷入口: 录入学生/登记成绩/记录考勤/管理课程`、`最近成绩列表`、`最近考勤记录`”，实现前建议补充 `contentBlocks`；若业务确实是窄场景，可以继续实现并说明取舍。
+展示型自定义页面验收时检查 `contentBlocks` 和实际页面：区块是否有独立业务价值、表现是否适合信息关系、操作是否承接到真实对象。工作台按 PRD 验收覆盖和联动，区块数量不作为阻塞实现的硬门槛。业务问题、数据口径或操作承接不清楚时，实现前建议补充 `contentBlocks`，回写 PRD 后再实现，不用增加通用列表补齐数量。
 
 所有展示型页面都按当前项目 `design.md` 的页面八项要点与共享规则实现。若只有业务区块和视觉形容词，没有实际布局、表面、组件和响应式决定，先补设计源事实：
 

package/yida-skills/skills/yida-canvas-data-binding/SKILL.md

@@ -25,6 +25,12 @@ description: 自定义页面真实数据接入技能。用于在使用 `YidaCode
 - `mode=form` 读取宜搭表单数据时，默认调用 `window.__OPENYIDA_YIDA_API__.searchFormDatas(params)`，它底层来自官方 `this.utils.yida.searchFormDatas(params)`。发布层同一个桥也同步 `this.utils.yida` 的表单、流程、表单设计与运行态方法，例如 `saveFormData`、`updateFormData`、`startProcessInstance`、`getProcessInstances`、`request`、`searchUserList`。参数至少包含 `formUuid`、`currentPage`、`pageSize` 和 `searchFieldJson`，`pageSize` 一般显式写 `50`，字段 ID 必须来自真实 schema。
 - 只有 yida JS-API 桥不存在时，才允许降级同源直连 `/dingtalk/web/<appType>/v1/form/searchFormDatas.json`。直连请求必须带 `credentials: 'include'`，并从 `window.g_config`、`window.pageConfig`、`window.__YIDA__`、meta 或同源 cookie 读取 CSRF，同时写入 `_csrf_token` query 和 `global_csrf_token` 请求头。`/query/form/searchFormDatas.json` 不是可用表单数据端点。
 
+## 业务记录图片
+
+页面需要展示真实对象图片时，按[任务驱动的视觉设计](../yida-design/references/task-driven-visual-design.md)绑定真实图片/附件字段。先读 Schema 与实际返回样本，确认值是地址、对象还是附件数组后再映射，不猜字段 ID 或返回结构；列表与详情使用相同记录 ID 关联图片。图片来自关联对象表时优先使用已有联查或批量查询能力，避免每行单独请求；当前接口不支持时只读取当前页所需对象并限制并发，不拉全库。
+
+图片地址沿用平台或数据源支持的访问方式，保留访问权限，不把鉴权信息拼入公开 URL。缺失或加载失败时局部降级，不让图片失败清空已取得的业务数据、不自动换成网络同类对象图。图片字段随筛选、分页和刷新一起更新；固定页面素材继续走素材清单，二者不混用。
+
 ## dataBinding 契约
 
 `page-spec.json` 或生成命令中优先携带 `dataBinding`。没有真实数据时只能标记为 `seed`，不能声称已经接入线上数据。

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

@@ -30,7 +30,7 @@ metadata:
 - 已确认的经营分析、指标比较、趋势判断或投屏监控需求。
 - 现有经营看板的指标卡截图、分析分享或派单闭环。
 
-按任务判断，不按名称触发：待办、操作队列、业务列表、门户式工作台以及处理任务的看板由 `yida-canvas-custom-page` 实现；少量任务计数、辅助图表、管理者身份或隐藏导航都不足以触发本技能。首页选择遵循 [首页按任务选择](../yida-requirement-analysis/references/experience-groups.md#首页按任务选择)。
+按页面主任务判断，不按名称触发：综合工作台由 `yida-canvas-custom-page` 实现，可包含业务分析、洞察与快捷操作；这些区块按 PRD 组织，常规图表使用 `yida-rechart`。含图表、管理者身份或隐藏导航不足以触发整页 Dashboard 流程；经营分析本身为页面主任务时使用本技能。首页选择遵循 [首页按任务选择](../yida-requirement-analysis/references/experience-groups.md#首页按任务选择)。
 
 单个普通统计报表优先 `yida-report`；只解决单张图的实现问题时按“图表路由边界”选择 `yida-rechart` 或 `yida-chart`。
 

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

@@ -14,13 +14,15 @@ description: >
 
 导航默认沿用平台样式，像连续目录一样排列。只调整需要改变的颜色、尺寸和状态；边框、阴影可不设置，不要把每个菜单项做成输入框、按钮或卡片。改完后打开实际的数据管理页和业务页面检查，见 [导航形状与密度的案例经验](references/application-theme-consistency.md#导航形状与密度的案例经验)。
 
+所有页面按[任务驱动的视觉设计](references/task-driven-visual-design.md)从主要任务和信息关系推导表达、构图与视觉重点，主动判断图片的识别、解释和氛围价值，再确定密度与降级。
+
 固定主题只写一套 token。CLI 让全局与平台 light、dark、white、gray 选择器共用同一个声明块，不为 is-light/is-dark 另配颜色。`navTheme` 按设计保存为应用配置，不能按主题名称猜测。
 
 配色要按“文字＋所在背景”成对设计。正文、说明、表单标签、详情和搜索必须清楚；禁用色不能用于正常提示，品牌色不能直接当通用文字色。大面积画布和导航控制亮度、饱和度，强色留给局部重点。`check-design` 和带设计文件的主题生成会拦截已知低于 4.5:1 的文字组合，返回具体角色和 token；修复设计源后再生成，不自动改色。JSON 中 `paletteContrast.unresolved` 非空表示尚未确认，复杂颜色、图片与渐变仍需浏览器检查。
 
 **品牌变量必须完整，导航装饰可以省略。** `design.md` 提供 PC 品牌色阶 `--color-brand1-1/2/3/5/6/9/10`，CLI 同时生成移动端 `--color-brand-1`、`--color-brand-2`、`--color-brand-3`、`--color-brand-4`。最终 CSS 必须在全局 `:root` 中提供这 11 个可用颜色；移动端映射不必在 design.md 重复填写。生成和上传都会检查缺失、无效颜色及循环引用。报错时修复设计后重新生成，不能只替换主色后上传模板。
 
-确定风格前，按[设计方向比较](references/theme-selection.md#设计方向比较)以第一直觉为参照，发展两个更有表现力的方向，在当前规划轮次内选定。已有明确视觉要求时，在其范围内完善设计。
+确定风格前，按[设计方向比较](references/theme-selection.md#设计方向比较)以第一直觉为参照，发展两个在构图和信息表达上有实质差异的方向，按任务适配性选择，在当前规划轮次内选定。已有明确视觉要求时，在其范围内完善设计。
 
 向用户说明设计时，写风格和适用场景：“设计主题风格为轻盈媒体栅格，适合产品展示型品牌官网。”风格名称与场景按当前项目填写；建议阶段使用“建议采用……风格”。
 
@@ -75,10 +77,10 @@ Fast、Plan 和单页设计使用相同的 UI 设计规则、主题变量和质
 4. **同应用页面入口归导航**：同应用页面优先放入平台导航或导航分组；自定义页内容区放当前页动作、原生表单新建/查看、外部链接和跨应用资源。
 5. **表单入口响应式**：新增/提交页 URL 默认使用页面级隐藏导航的 `submission/{formUuid}?isRenderNav=false`；详情页 URL 默认使用 `formDetail/{formUuid}?formInstId={formInstId}&navConfig.layout=1180&isRenderNav=false`，且 `formInstId` 必须来自真实数据记录并优先取 `row.formInstId`；PC 端默认在侧边抽屉中用 iframe 承载宜搭原生表单，抽屉默认半屏 `50vw`，提交页和详情页使用同一宽度规则；移动端整页或新页打开。
 6. **主题文件**：主题目录统一包含设计、CSS、表单布局三个文件，导出和生成参数见 [命令与参数](references/application-style-library.md#命令与参数)。Plan 使用 CLI 返回的 `outputs.theme`；Fast 和已有主题调整按 [主题文件生成与更新](workflow/output-design.md#cli-token-契约fast--plan-共用) 执行。按 [共用主题规则](references/application-theme-consistency.md) 将已选风格落实为 token，并核对生成的 CSS。修改变量要回到设计源后重新生成、上传；仅 CLI 未覆盖且已核实选择器的样式覆盖可在 CSS 末尾小范围追加，不另写脚本生成或重写主题文件。
-7. **默认主题先做业务判断**：工作台、门户、列表、详情、普通看板和数据大屏默认都是浅底 / light 模式，但主色不固定为 `podBlue` 或 #1677ff；先根据行业、品牌、业务情绪和视觉目标做创意色彩判断，主题色可以是任意合法 CSS 颜色。只有用户明确说暗色/深色/夜间/高对比时才用深色沉浸。
+7. **默认主题先做业务判断**：工作台、门户、列表、详情、普通看板和数据大屏默认都是浅底 / light 模式，但主色不固定为 `podBlue` 或 #1677ff；先按主要任务、使用频率和信息密度判断适配性，再结合品牌证据和视觉目标做色彩判断；行业名词不能直接决定配色或材质，主题色可以是任意合法 CSS 颜色。只有用户明确说暗色/深色/夜间/高对比时才用深色沉浸。
 8. **页面布局要到可实现粒度**：每个页面至少写清顶部/左侧/主体/右侧/底部区域、核心组件、信息密度、主操作位置、PC/移动端差异和空/载/错态。
-9. **页面丰富度建议**：工作台、首页、门户、看板、展示页和业务入口页推荐规划 8-10 个有业务目的的区块以上，例如上下文标题、状态摘要、主操作、筛选、任务列表、最近记录、动态流、洞察、提醒、空态行动、右侧上下文和底部辅助信息。区块数量不是硬门槛，窄场景、单任务页面或用户明确要求精简时可以更少，但要写清每个区块的业务目的和取舍原因。计数按“区块组”算，不按子项算：`KPI 卡片: 学生总数, 课程总数, 出勤率, 平均分` 只能算 1 个状态摘要区块，`快捷入口: 录入学生/登记成绩/记录考勤/管理课程` 只能算 1 个动作区块；不能用重复 KPI 卡、重复快捷入口或大空白卡凑数量。
-10. **工作台禁低密大卡片套路**：工作台 / 业务首页不能用“标题 + 4 个等宽大 KPI 白卡 + 图标快捷卡 + 大空态白卡”撑首屏。默认改成紧凑状态摘要条、任务/动态列表、最近记录、右侧上下文面板和高频动作；没有真实数据时也展示薄空态行 + 登记入口，不铺大块空白卡片。
+9. **页面丰富度建议**：工作台沿用 PRD 已确定的内容和业务关系。综合工作台参考 8-10 个有独立业务价值的区块，不作为硬门槛；按任务覆盖和信息增量衡量丰富度，不用重复记录、入口或装饰凑数。区块依据信息关系采用不同且合适的表现形式，不要求每块换一种组件。
+10. **工作台禁低密大卡片套路**：工作台 / 业务首页不能用“标题 + 4 个等宽大 KPI 白卡 + 图标快捷卡 + 大空态白卡”撑首屏。按已确定的业务内容和信息关系安排主视图、分析区、操作区及快捷入口，不指定统一列表组合或固定双栏。空态保留该视图所需的上下文与可执行下一步，不铺大块空白卡片。
 11. **按主题保持形状、密度与呼吸感**：`design.md` 正文写清圆角、密度与呼吸节奏的具体消费方式和必要数值，优先采用选中主题的容器/控件形状与内距、组间距、列表行高。通用业务页参考值只补主题未定义项，不能用固定大圆角、padding 或 gap 覆盖主题。呼吸感来自对齐、分组、层级和节奏，不来自超宽空 KPI 框或空白卡。
 12. **背景与内容层次清晰**：正文说明主题如何用色差、细边界、共容器、留白或材质区分内容。同色画布与面板可通过明确边界和分组成立；渐变、玻璃、阴影按主题规则启用，不强制添加。
 13. **模板与自由创意并列**：始终支持[自由创意](references/application-style-library.md)，根据业务独立推演，不要求从模板选择。使用模板时，先按业务任务、信息拓扑选择风格，再按用户确认的色彩氛围协调页面、卡片、导航、填充、边界和交互。布局、圆角与材质可保留，模板固定灰阶和品牌色面积限制不能覆盖用户要求。“自然绿意”等整体风格不能缩减成只有按钮和 logo 变绿；明确只改强调色或忠实中性参考时才保持原画布。文字保留可读的中性层级，状态保留独立语义。

package/yida-skills/skills/yida-design/references/application-style-library.md

@@ -4,7 +4,7 @@
 
 ## 找到和导出
 
-`openyida design-plan catalog --json` 返回模板 `themes` 与独立的 `creativeOption`。全部 34 个主题入口统一采用三文件目录，均可用 `application-style` 导出；其中 18 套应用风格与自由创意仍保留 `collection: application-styles` 分类。目录元数据提供完整设计、CSS 和原生布局的相对路径，可直接定位对应文件。
+`openyida design-plan catalog --json` 返回模板 `themes` 与独立的 `creativeOption`。全部 33 个主题入口统一采用三文件目录，均可用 `application-style` 导出；其中 18 套应用风格与自由创意仍保留 `collection: application-styles` 分类。目录元数据提供完整设计、CSS 和原生布局的相对路径，可直接定位对应文件。
 
 ```bash
 openyida sample yida-design application-style --style-id app-executive --output prd/my-app/style-start

package/yida-skills/skills/yida-design/references/page-quality-gates.md

@@ -4,11 +4,13 @@
 
 ## 1. 区块丰富度建议
 
-- 工作台、首页、门户、看板、展示页和业务入口页推荐有 8-10 个有业务目的的 `contentBlocks` 以上，但不作为准出硬门槛。
+- 综合工作台参考 8-10 个有独立业务价值的 `contentBlocks`，按 PRD 核对内容覆盖，不作为准出硬门槛。
 - 计数按区块组算：KPI 组、快捷入口组、列表组、图表组各只算 1 个区块。
-- 每个区块必须写清目的、数据来源、主操作和状态。
+- 每个区块写清业务问题、信息关系、数据依据、表现形式、操作联动和状态；沿用已有文档字段。
 - 重复指标、重复入口、列表行、图表点、装饰块、空白容器不计数；窄场景可以少于参考数量，并说明业务取舍。
 
+工作台按 PRD 核对内容价值、表现适配和真实操作，不能以区块数量或换色代替业务验收。
+
 ## 2. 可实现页面门禁
 
 每个实际自定义页须按 [输出契约的八项要点](../workflow/output-design.md#页面设计的八项要点) 写出具体设计。页面外壳、焦点、主内容、动作、上下文、状态与移动端关系都应清楚，但不要求对应同名英文字段。
@@ -31,7 +33,7 @@
 
 - KPI 改成 64-88px 紧凑摘要条、分段摘要或侧栏小面板；如果横向占满宽度，必须补充趋势、更新时间、筛选、主操作或风险状态，不能只有稀疏数字。
 - 高频动作改成按钮组、工具条或紧凑入口，低频动作折叠。
-- 空态放在列表、表格或上下文面板内，并提供登记、刷新、补录或查看配置动作。
+- 空态保留当前业务视图的必要上下文，并提供登记、刷新、补录或查看配置动作；不要求改成列表。
 - 业务已有风险、提醒、负责人、最近动态、洞察或下一步建议时可以用于右侧；没有这些内容则收窄或移除空栏。
 
 圆角、间距与呼吸感门禁：
@@ -87,6 +89,10 @@
 - 卡片、列表、图表和右侧上下文的容器形态要有差异，不能全部是同一种白卡片。
 - 已确定玻璃材质时保持半透明关系；其他主题中的渐变可以搭配主题指定的实色表面。
 
+## 业务图片与场景门禁
+
+所有页面按[任务驱动的视觉设计](task-driven-visual-design.md)检查：图片是否帮助识别实际对象，记录与图片是否匹配，有图/缺图/加载失败时主操作是否完整，图片是否挤占关键数字。固定素材和动态记录图片分别走素材清单与数据绑定，不以装饰图数量判断完成度。没有图片不自动判失败，但有可用图片且能帮助识别、解释或传达氛围却全部忽略时应说明任务依据；用网络或生成图片冒充真实对象照片不通过。
+
 ## 6. 双文件输出门禁
 
 每个完整应用设计必须输出两份文件：
@@ -100,7 +106,7 @@
 - pageSpecHandoff：
   - pageStructure：<workbench / dashboard-overview / business-list / detail-profile / split-pane-detail / portal-shell-home / official-homepage / data-screen>
   - scene：<workbench / dashboard / list / detail / landing / screen>
-  - contentBlocks：<推荐 8-10 个区块以上；KPI/快捷入口/列表/图表子项不分别计数>
+  - contentBlocks：<业务推导的区块与用途；综合工作台参考 8-10 个独立业务区块，子项不分别计数>
   - themeSummary：<应用主题色 / 风格关键词 / 主题交付方式摘要；必须与 design.md 一致>
   - designFile：<prd/<项目名>/design.md>
   - designRefs：<themeProfile / sceneRecipes.<scene> / components.<name> / states.<name>>

package/yida-skills/skills/yida-design/references/task-driven-visual-design.md

@@ -0,0 +1,59 @@
+# 从任务和内容推导视觉设计
+
+Fast、Plan 和已有页面优化共用这套推导方法。先读取真实需求、角色、内容、数据与已有视觉证据，再决定页面的表达方式。行业名和应用名不直接对应某个主题、布局或图片数量。已有页面优化保留业务功能，缺失的业务事实交回 PRD，不通过装饰补造内容。
+
+## 1. 先确定用户在本页要完成什么
+
+每页先明确：用户首先需要认出什么、判断什么、完成哪个动作，以及完成动作前必须看见哪些信息。多任务页面确定一个主任务，其余作为上下文或次要入口。用一句具体描述写入现有的页面任务与首屏焦点，不另建问卷或配置字段。
+
+例如，同一个对象可以有不同页面：选择对象时重视识别和比较，处理记录时重视状态与动作，查看详情时重视证据与上下文。不能因为它们属于同一个应用，就都生成相同的表格、卡片或大标题。
+
+## 2. 按信息关系选择表达
+
+以下是推导依据，可以在同一页面组合，不是互斥页面类型，也不是固定布局模板。
+
+| 用户需要理解的关系 | 优先考虑的表达 | 取舍依据 |
+| --- | --- | --- |
+| 识别对象、区分外观 | 图片与名称/标识组合、图文列表、详情主图 | 外观是否有助识别？有无可信素材？仅靠文字已足够时可不用图片 |
+| 对比多个对象或数值 | 对齐表格、比较列、紧凑列表 | 保留统一单位、口径和属性位置；缩略图辅助识别，不挤占比较字段 |
+| 判断变化、分布与构成 | 趋势图、分布图、构成图及简短解释 | 必须有对应数据维度和足够数据；单个数值不强行画趋势 |
+| 推进任务与处理异常 | 按优先级或状态组织的任务列表、动作区、必要时状态分栏 | 当前状态、责任与下一步清楚；状态数量和操作频率决定布局 |
+| 理解过程、关系与证据 | 时间线、主从详情、关联信息、文档或图片预览 | 按因果、时间或对象关系组织，不拆成互不相关的装饰卡 |
+| 感受品牌、理解故事或场景 | 大图与文字构图、章节节奏、案例展示 | 图片能承载含义、氛围或信任；首屏仍要清楚传达目的和下一步 |
+
+先写内容之间的关系，再选容器。相同属性的记录保持对齐，紧密关联的信息共享容器，不相关层次用间距、细线或表面变化区分。内容少时收敛宽度与高度，内容多时通过主次、筛选与渐进展开控制密度。
+
+## 3. 主动判断图片的价值
+
+不能把“业务页”理解成只能有表格，也不能把“好看”理解成必须有大图。对现有内容主动判断三种价值：图片是否帮助识别对象、提供证据或解释、传达需要的品牌与场景感。存在价值且有可靠来源时，将图片融入内容构图；没有价值时，用文字节奏、图表、对齐与层次完成设计。
+
+图片的尺寸由信息职责决定：辅助识别用缩略图，外观比较给足辨识面积，证据支持按需放大，叙事或品牌内容可以成为主视觉。不要把全部图片缩成小图标，也不要把辅助图片放大成横幅。移除图片后若用户判断完全不受影响，且它也不承担明确的氛围目标，应重新考虑它是否值得占据首屏。
+
+### 真实记录图片与固定素材
+
+- 真实对象的照片、附件或证据走数据绑定，核对对象 ID 与图片关系；不能用相似搜索图或生成图冒充实际对象。缺少字段时记录缺口，业务模型变动由 PRD 按授权范围处理。
+- 动态记录图片不逐行创建静态 slot，不在源码中硬编码一组照片。仅有动态图片时 `assetStrategy.pages[].imageNeed=none`、`slots=[]` 表示没有固定素材采集任务；数据来源和图片表现仍写入数据绑定与设计正文。
+- 固定页面素材走现有 `assetStrategy` 与 `yida-image-assets`，说明用途、来源、尺寸、裁切与缺图降级。示意图明确标注；允许无图降级用 beneficial，确实不可缺少才用 required。
+- 图片容器预留比例；需要完整轮廓时用 contain，场景构图可用 cover 并核对焦点。缩略图与详情图按当前显示尺寸选择，非首屏按需加载。
+- 缺图或失败时保留对象名称及关键属性，局部降级并收敛空区域。图片 alt、放大预览、键盘操作和移动端阅读顺序随内容设计；图片加载不阻塞主任务。
+
+## 4. 将内容组织成有重点的画面
+
+选定主题后，在同一套视觉语言内为每页安排明确的主次，不把换色作为设计完成。
+
+1. **首屏焦点**：用户第一眼看哪里、第二眼看哪里、在哪里行动。焦点可以是对象、关键变化、待处理事项、标题或主视觉，依任务决定；避免所有卡片、按钮和标题一样重。
+2. **构图比例**：按内容长短和关系确定主次区、列宽和信息顺序，视觉重心与主要任务一致。不要先铺等宽卡片再填内容。
+3. **表面层次**：画布、导航、主内容、浮层的明度与色温协调，用必要的色差、边界或留白区分；避免大面积同色发闷，也避免无依据的冷暖割裂。
+4. **色彩面积**：区分环境底色、正文、强调与状态。品牌色的面积由用户视觉目标和内容决定，不能同时把导航、文字、卡片和主操作都染成强色。
+5. **排版节奏**：标题、核心数值、正文、元信息有可辨层级；同类信息对齐，组内紧凑、组间清楚。密度随阅读、比较或操作任务变化。
+6. **视觉特征**：从已有内容发展一处有意义的特色，例如对象图文组合、关键变化对比或连贯的章节排版。特色服务当前任务，不靠增加业务模块、随机装饰或重复大卡片制造丰富感。
+
+已有品牌或明确风格时在其范围内完成这些决策，不自动统一成浅色商务风。没有独立图片的页面也应通过构图和排版成立。
+
+## 5. 交接具体决策并验证
+
+复用逐页设计的任务、首屏焦点、布局、组件、动作、状态、响应式和验收八项要点。写清“选用什么表达、为什么适合、在当前内容上怎样实现”，避免只有“高级、简洁、丰富、统一主题”等形容词。动态图片归数据绑定，固定素材归清单，颜色与表面归同一份主题 Token，不重复造配置。
+
+设计完成后先自查三件事：用户能否一眼理解本页目的；最重要的信息与动作是否突出；图片和装饰是否值得占据当前位置。不能通过时回改具体布局或表现，不只换主题名称。
+
+实现后检查真实截图：首屏视觉重心、信息对齐、素材与对象对应、颜色面积、文字可读性，以及有图/缺图、空数据、长内容和窄屏状态。同时验证筛选、批量处理和详情入口等原有操作。原生页使用已支持的字段与配置，不通过全局 CSS 强造结构。只有文档规则或本地示意时，明确真实生成效果仍待验收。