openyida 2026.9.21 → 2026.9.22-beta.1

package/lib/samples/openyida-scaffold/canvas-view-state.jsx

@@ -1,74 +0,0 @@
-import React from 'react';
-
-// Merge this fragment into one Canvas file. Keep config outside YidaComp.
-// For a standalone page without an existing router or unsaved-edit blockers.
-// Only allow public enum filters; never put free text, personal data or drafts in URLs.
-function normalizeCanvasViewState(config, input) {
-  const filters = {};
-  Object.entries(config.filters).forEach(([key, values]) => {
-    filters[key] = values.includes(input.filters?.[key]) ? input.filters[key] : values[0];
-  });
-  const page = Number(input.page);
-  return {
-    view: config.views.includes(input.view) ? input.view : config.views[0],
-    filters,
-    page: Number.isSafeInteger(page) && page > 0 && page <= 100000 ? page : 1,
-  };
-}
-
-function readCanvasViewState(config, href) {
-  const params = new URL(href).searchParams;
-  const filters = {};
-  Object.keys(config.filters).forEach(key => {
-    filters[key] = params.get(`${config.namespace}.filter.${key}`);
-  });
-  return normalizeCanvasViewState(config, {
-    view: params.get(`${config.namespace}.view`),
-    page: params.get(`${config.namespace}.page`),
-    filters,
-  });
-}
-
-function buildCanvasViewStateUrl(config, href, state) {
-  const url = new URL(href);
-  const normalized = normalizeCanvasViewState(config, state);
-  url.searchParams.set(`${config.namespace}.view`, normalized.view);
-  url.searchParams.set(`${config.namespace}.page`, String(normalized.page));
-  Object.entries(normalized.filters).forEach(([key, value]) => {
-    url.searchParams.set(`${config.namespace}.filter.${key}`, value);
-  });
-  return url.href;
-}
-
-function useCanvasViewState(config) {
-  const [state, setState] = React.useState(() => readCanvasViewState(config, window.location.href));
-  React.useEffect(() => {
-    const restore = () => setState(readCanvasViewState(config, window.location.href));
-    restore();
-    window.addEventListener('popstate', restore);
-    window.addEventListener('hashchange', restore);
-    window.addEventListener('pageshow', restore);
-    return () => {
-      window.removeEventListener('popstate', restore);
-      window.removeEventListener('hashchange', restore);
-      window.removeEventListener('pageshow', restore);
-    };
-  }, [config]);
-
-  function update(patch, { replace = false } = {}) {
-    // Read the current URL, so consecutive events do not reuse an old render's state.
-    const current = readCanvasViewState(config, window.location.href);
-    const next = normalizeCanvasViewState(config, {
-      ...current, ...patch, filters: { ...current.filters, ...patch.filters },
-    });
-    if (next.view !== current.view || Object.keys(config.filters).some(key => next.filters[key] !== current.filters[key])) {
-      next.page = 1;
-    }
-    if (JSON.stringify(next) === JSON.stringify(current)) { return; }
-    const href = buildCanvasViewStateUrl(config, window.location.href, next);
-    // Preserve platform history metadata, unrelated query parameters and the entire hash.
-    window.history[replace ? 'replaceState' : 'pushState'](window.history.state, '', href);
-    setState(next);
-  }
-  return [state, update];
-}

package/yida-skills/skills/yida-app/references/entry-navigation.md

@@ -1,193 +0,0 @@
-# 前台、管理端的菜单与权限
-
-本说明用于用户使用系统时的页面入口、菜单和权限规划。先按[判断是否分前后台](../../yida-requirement-analysis/references/experience-groups.md)确定“只有访问后台”“只有访问前台”“分前后台”或“不分前后台”。这里的前台和业务后台都是访问态页面；开发者修改应用配置的后台另行交付。
-
-例如报修应用：访客使用“我要报修、我的报修”，管理者使用“待处理工单、全部工单”。两端共享报修数据，但菜单名称、数量、顺序和打开后首先显示的内容可以不同。管理端可直接打开待处理列表，无需另建首页，也不必把访客首页放进管理菜单。
-
-## 先确定这四件事
-
-1. **谁来用**：哪些人使用同一套业务页面，哪些人需要分别进入前台和后台？多种角色也可以不分前后台，按职责配置菜单和权限。
-2. **各自做什么**：逐项列出菜单任务，并按 [首页按任务选择](../../yida-requirement-analysis/references/experience-groups.md#首页按任务选择) 确定默认落点；管理端不自动使用驾驶舱。
-3. **在哪里做**：访客端通常在一个自定义页面内完成任务；管理端按需要使用宜搭原生列表、表单或自定义页面。
-4. **能看和能改哪些数据**：分别写清本人、本部门或其他明确范围，以及查看、提交、编辑等操作。
-
-Fast（直接搭建）与 Plan（先确认方案）使用同一份入口规划。只修改指定表单或页面时，不额外创建入口，也不调整无关导航。
-
-管理端选择自定义页面默认仍使用平台导航；管理 `menu` 用于组织平台入口，不直接变成页面内的导航栏。页面只实现当前任务内容，按[管理页面边界](../../yida-canvas-custom-page/references/navigation-and-entry-guide.md#平台导航下的管理页面)区分跨模块菜单、同任务 Tab 与上下文动作。
-
-## 每个入口都确定首页与菜单顺序
-
-无论是否分前后台，每个入口都要完成菜单排序。逐入口确定以下内容，写入已有 `menu`、`defaultMenuKey` 和需求依据，不新增另一份顺序清单：
-
-- **默认打开什么**：依据该角色进入应用后的首要任务选择页面或业务视图；写清真实资源、视图与入口链接。用户已指定首页时沿用，不因页面名称、创建先后或是否为自定义页面改选。
-- **菜单怎么排**：`menu[]` 及 `children[]` 的数组顺序就是展示顺序。按任务优先级、使用频率和业务流程组织；详情、填写、配置等是否成为顶级入口取决于实际用途，不把所有创建出的资源平铺进菜单。
-- **首屏先呈现什么**：默认页打开后，先展示用户当前要读、要选或要处理的内容及主操作。首页选择交给业务规划，页内焦点与布局写入页面设计，不能只把菜单改名或拖到第一项。
-
-| 入口的主要用途 | 默认页面的选择依据 |
-| --- | --- |
-| 前台展示、内容发现或选购 | 能让用户理解服务并开始浏览、搜索或选择的首页、目录或商品列表 |
-| 前台自助办理、查询进度 | 服务办理入口或“我的事项”；根据新办与跟踪哪个是首要任务决定 |
-| 后台处理多类待办 | 业务工作台或操作队列，突出待处理事项与办理入口 |
-| 后台维护单类业务 | 直接进入对应管理列表或业务视图，无需额外创建首页 |
-| 以经营判断为主要任务 | 有明确需求依据的分析页；不因后台身份默认使用驾驶舱 |
-
-默认页通常排在入口菜单前部；用户明确要求菜单位置与默认页不同，或分组有业务顺序时分别保留两项决定。默认页只决定首次进入、没有有效任务链接或恢复状态时的落点；直接链接、刷新与返回仍恢复用户当前任务。默认项无权限时，按已排好的菜单选择首个可访问任务，全部不可用则显示无权限状态。
-
-平台导航通过 `nav-group order` 落实资源顺序；前台或后台的自定义导航在页面菜单数据中落实顺序和默认选择。**跳过平台排序命令，不代表跳过自定义菜单排序与首页验收。** 只有一个任务时可以不显示菜单，但仍需明确默认页面。局部修改只处理授权范围内的入口。
-
-## 导航设置和访问路径
-
-### 分清四种设置
-
-| 要改变什么 | 对应设置 | 同时有前台和管理端时怎么做 |
-| --- | --- | --- |
-| 整个应用是否显示平台导航 | `hideAppNav` | 保留 `n`，让管理端继续使用平台导航 |
-| 某一页是否显示平台导航 | `isRenderNav` | 独立前台页设为 `false`，其他页面按需配置 |
-| 某个菜单项是否显示 | `hidden/mobileHidden` | 分别设置电脑端、移动端的显示范围 |
-| 某个人能访问和操作什么 | 页面、数据、视图和操作权限 | 按业务角色配置，并重新查询确认 |
-
-隐藏菜单不会撤销权限；显示菜单也不会授予权限。页面隐藏导航后，仍需满足原有登录和访问要求。公开访问或组织内分享要单独配置。
-
-### 使用正确的入口链接
-
-以下路径均接在当前应用地址后：
-
-- **独立前台**：使用 `/custom/{formUuid}`。先查询页面配置，确认 `isRenderNav=false`，再打开链接检查效果。
-- **业务管理端**：使用 `/workbench`，或指定任务的 `/workbench/{formUuid}?viewUuid=...`。使用应用根入口时，要确认它确实打开了预期任务。
-- **管理端的“查看前台”**：如有需要，使用独立前台链接。不要把带有另一套导航的完整页面嵌进管理端内容区。
-- **前台嵌入共用表单**：只设置本次打开链接的嵌入参数，不永久隐藏该表单在管理端的导航。
-
-页面设置和访问路径都可能影响显示效果。保存后既要重新查询配置，也要打开准备交付的链接检查；不能用 `/workbench/{formUuid}` 代替独立前台链接。
-
-### 整理管理菜单
-
-有独立入口规划时，从业务后台或不分前后台的系统菜单生成平台导航顺序：默认任务在前，同一资源只排一次。访客菜单不自动加入。
-
-- 已有 `navigationOrder` 与入口规划冲突时，先修正规划，再生成产物。
-- 整个应用使用自定义导航或只交付前台时，仍按本入口的 `menu` 顺序和 `defaultMenuKey` 实现、发布并验收自定义导航；跳过的是平台排序命令。只改指定资源时保留无关入口的已有顺序。
-- 同一表单的不同视图可能对应不同任务。排序只决定资源顺序，具体视图仍需真实 `viewUuid` 和入口链接。
-
-## 权限实施
-
-取得真实资源 ID 后，按以下顺序处理：
-
-1. 列出每类用户需要的菜单、操作和数据范围。
-2. 查询现有权限，说明需要改变的配置。
-3. 按权限技能要求完成授权、保存，再重新查询确认；保留本次未涉及的权限。
-4. 使用实际访客和管理者账号检查结果。业务管理者需要的是业务权限，不要自动给他应用管理员身份。
-
-`yida-form-permission` 当前只管理 `FORM_PACKAGE_VIEW`。提交权限包 `FORM_PACKAGE_START`、视图权限绑定和页面人员白名单尚不属于该技能已支持的能力。遇到这些需求，记录具体任务、缺少的权限和平台处理入口，不能靠放宽其他权限完成。
-
-菜单隐藏、方案里的权限说明和页面上的筛选，都不能作为权限配置成功的证据。单条记录的操作权限也不能用来判断整个菜单或管理视图是否允许访问。
-
-## 自定义菜单过滤
-
-页面可使用 `canvas-nav-data`，根据当前用户的实际权限决定显示哪些菜单。
-
-### 选择过滤方式
-
-| 方式 | 什么时候使用 | 判断依据 |
-| --- | --- | --- |
-| `mode=local` | 纯本页公开展示内容 | key/viewKey/targetType=local，不请求平台导航；显式 access 仍核验 |
-| `mode=platform`，默认方式 | 自定义菜单沿用平台菜单的展示范围 | 当前用户的 `getAccessableNavs` 结果，加上 `hidden/hiddenNav` 设置 |
-| `mode=independent` | 独立组织受权限保护的资源任务 | 本入口的任务清单，加上当前用户的真实资源、操作和视图权限 |
-
-平台菜单可见不代表允许提交、编辑或删除。菜单声明了 `access` 权限要求时，即使使用 platform 模式，也要额外查询权限。
-
-独立模式不直接沿用平台菜单的隐藏设置。每个可点击菜单必须声明 `access`，并接入 `resolveAccess`——这是调用实际权限服务的函数，当前未内置，需要按服务能力实现。
-
-### 查询权限后再显示内容
-
-1. 创建资源后，把规划中的资源名称换成真实 `formUuid`，将菜单的权限要求填入 `access`。本页内的业务视图要同时检查承载页面和所用业务数据的权限。
-2. 用当前访问者的登录身份查询权限。不能根据角色名称、管理员预览、静态数组或平台菜单中存在某个节点，就认定允许访问。
-3. 权限服务尚未接入时，不启用独立模式，明确说明功能未接通。查询失败时显示重试提示，不显示未经授权的全量菜单。
-4. 切换应用或账号时，清空旧菜单和内容，取消旧请求。
-5. 权限查询成功后，用 `selectCanvasNavigation(items, requestedKey, defaultMenuKey)` 选择内容：当前请求的任务可用则打开它，否则选默认任务，再选首个可用任务；全部不可用时显示无权限提示。
-
-数据列表、详情和写入接口仍由平台检查数据范围、字段及操作权限。菜单过滤只控制页面展示。
-
-## 验收与已知边界
-
-分别用访客、业务管理者、同时拥有两种身份的用户检查：
-
-- 从本轮交付的每个业务入口首次打开，核对默认页面、具体视图和首屏任务；菜单及分组顺序与规划一致。排序回读只证明资源顺序，不能替代实际首页验证。
-- 同一表单的填写、本人记录、管理视图分别遵守对应权限。
-- 无权限用户直接打开链接也不能访问；本人数据范围确实生效。
-- 刷新、直接打开子页面、浏览器前进后退后，菜单与内容仍然一致。
-- 平台菜单隐藏而前台需要的资源，按真实权限正确显示。
-- 电脑端和移动端的隐藏设置分别生效。
-
-导航列表中缺少节点时，分别检查显示设置和用户权限，不能只凭列表判断原因。导航预览或应用创建者账号不能代替实际用户验证。
-
-缺少测试应用、账号或权限服务时，可以完成本地检查，但交付必须标记“多身份在线验收未完成”。
-
-## 规划字段速查（Fast / Plan）
-
-需求文件中的 `entryRecommendation` 在 Plan 初始化后保存在 `execution.entryRecommendation`；Fast 在 PRD 中使用同一结构。旧计划没有此字段时仍可使用；首次完整生成时应明确入口规划。保留已有 `source/reason/taskRefs` 等需求依据。
-
-| 字段 | 含义和要求 |
-| --- | --- |
-| `mode` | `unified`：不分前后台；`service-management`：分前后台；`frontend-only`：只有访问前台；`backend-only`：只有访问后台。实施前必须选定，不能为 `undetermined`；旧 unified 计划保留原字段、值和角色，不自动改分类 |
-| `entries[]` | backend-only 的每个入口 role 必须为 management；新建 unified 入口通常使用 workspace。每个入口填写 `key/name/role/menu/defaultMenuKey`；访客入口或包含 `local` 菜单的任意入口还需 `sceneKey` |
-| `role` | `service`：前台使用者，如客户或报修员工，不表示匿名访问；`management`：业务处理人员；`workspace`：不分前后台时的使用者。实际数据和操作按权限配置 |
-| `sceneKey` | 关联唯一承载页面的顶层 `sceneKey`；service 入口必须关联 `entryMode=standalone`；management/workspace 含 local 菜单时也必须填写 |
-| `menu[]` | 数组及 children 的先后就是本入口展示顺序；分组用 `{key,label,children}`；可点击菜单用 `{key,label,resource,targetType,viewUuid?,viewKey?,access}` |
-| `resource` | 规划中的资源名称；实施时创建或查询资源，换成真实 ID |
-| `targetType` | `local`：本页业务视图，入口 sceneKey 关联承载页面、resource 等于页面 name、viewKey 非空；`submission`：原生填写页；`page`：原生管理工作区；`custom`：独立自定义页面 |
-| `viewUuid` | 仅用于 `page`，填写已查询到的真实视图 ID；尚未取得时省略，实施时补齐，不编造占位 ID |
-| `access[]` | 所有身份的每个叶子菜单必填 `{resource,operation,dataScope,viewUuid?}`；填写需要 `OPERATE_CREATE`，打开页面或视图需要 `OPERATE_VIEW`；声明不等于实际授权，编辑、删除等要求另列 |
-| `dataScope` | 用业务语言写明本人、本部门或具体管理范围；实际限制由平台权限配置执行 |
-| `defaultMenuKey` | 入口打开后首先显示的可点击菜单。只有一个任务时也填写，但无需绘制菜单 UI |
-
-## CLI 与运行时参数边界
-
-例如管理端在同一个自定义页面内切换业务视图时，承载页面为 `{ "sceneKey": "management", "name": "业务管理" }`，入口应写成：
-
-```json
-{
-  "key": "management", "name": "业务管理端", "role": "management",
-  "sceneKey": "management", "defaultMenuKey": "orders",
-  "menu": [{
-    "key": "orders", "label": "订单管理", "targetType": "local",
-    "resource": "业务管理", "viewKey": "orders",
-    "access": [{ "resource": "业务管理", "operation": "OPERATE_VIEW", "dataScope": "已授权管理范围" }]
-  }]
-}
-```
-
-上述资源必须在计划中真实存在，页面需实现 `orders` 视图；其订单数据另列真实数据资源权限。管理端直接打开原生业务页面时使用 `page`，填写时使用 `submission`，这两种情况不要求为入口新增自定义承载页面。
-
-`entryModeSummary` 是 CLI 根据 mode 生成的交接说明，供 PRD 和预览使用，不写入 build-plan.json。只有访问前台且提交后需要处理时，按需求分析记录的承接方式核验，不额外补建业务后台。
-
-### 传入入口规划
-
-可以通过需求 JSON、Plan JSON，或以下命令更新：
-
-```bash
-openyida design-plan patch <build-plan.json> --set 'execution.entryRecommendation=<JSON>'
-openyida design-plan materialize <build-plan.json> --check --json
-```
-
-这里的 `<JSON>` 需替换为完整入口规划；没有 `--entryRecommendation` 参数。标准业务/视觉文件合并支持 `business.execution`；增量 preview 的 facts 不接收 execution，需要通过完整文件合并交接。`commands --json` 和 `agent-capabilities --summary-json` 提供相同的 `entry_navigation_contract` 字段说明。
-
-### 配置导航显示
-
-```bash
-openyida update-app <appType> --layout <side|top|l_shape> --show-app-nav
-openyida update-form-config <appType> <formUuid> <true|false|keep> "<页面标题>"
-```
-
-导航项显示与隐藏使用 `nav-group show|hide`。应用导航、页面导航、菜单项分别设置和重新查询，不能互相替代。
-
-纯页内公开内容可直接用本地数组或 `mode=local`（key/viewKey/targetType=local），不依赖平台导航树；有 access 的本地业务视图仍需实时权限查询，业务操作权限不变。规划层的 sceneKey/resource/access 不得因此删除。platform 叶子必须绑定真实 formUuid/navUuid；误把 local 交给平台过滤会报错，禁止空菜单或接口失败时回退全量放行。
-
-### 接入页面权限查询
-
-页面函数的 `mode=local|platform|independent` 表示菜单过滤方式，与规划字段 mode 的四种入口方案不同。
-
-`resolveAccess({appType,requirements,signal})` 接收当前应用、权限要求和取消请求信号：
-
-- `requirements`：`[{formUuid,operation,viewUuid?}]`。
-- 返回值：`{appType,grants:[{formUuid,operation,viewUuid?,allowed}]}`。
-- 只有应用、资源、操作、视图匹配且 `allowed` 严格为 `true` 时允许显示；不同视图或操作不能共用一个判断结果。
-- `dataScope` 用于规划和配置平台权限，不是该函数的授权字段。

package/yida-skills/skills/yida-canvas-custom-page/references/view-state-recovery.md

@@ -1,52 +0,0 @@
-# 页面状态恢复
-
-编码前在当前页面实现计划中列出：哪些状态需要恢复、保存位置、有效范围和清除时机。URL 只是显示状态，不提供访问权限；服务端查询仍按当前访问者授权。沿用现有路由，不在同一页面再建立第二套路由。
-
-## 默认恢复规则
-
-| 状态 | 页内切换、列表详情返回 | 刷新、跨页返回 | 保存与清除 |
-| --- | --- | --- | --- |
-| 本地视图、非敏感枚举筛选、页码 | 恢复原任务；改变筛选后回第 1 页 | 从当前路由恢复，非法值回默认值 | URL 使用页面专属前缀和白名单；不覆盖平台参数 |
-| 搜索文本、成员、手机号等敏感筛选 | 稳定父层按任务 key 保留 | 默认不恢复；有明确需求再设计受控存储 | 不放 URL、localStorage 或日志 |
-| 已加载数据、滚动位置、焦点 | 同任务保留，详情关闭后焦点回入口 | 重新鉴权取数；数据就绪后按实际滚动容器恢复位置 | 内存缓存按应用、用户和任务隔离；切换身份清除 |
-| 未提交草稿 | 放稳定父层，按任务/记录 key 保存；切换不可静默丢失 | 仅通过已验证的草稿服务恢复；无保存能力时明确离开策略 | 成功提交、明确放弃后清除；过期草稿须提示，不自动提交 |
-
-不同任务的筛选各自保存；同一列表的状态分类 Tab 可以共享筛选。先决定语义，再决定是否重置页码。浏览器刷新与列表“刷新数据”不同：后者保留筛选、页码、旧数据和未提交输入，失败时显示局部错误。
-
-## 可提取的最小片段
-
-没有现成路由、没有未保存编辑拦截需求的独立页面，可提取：
-
-```bash
-openyida sample openyida-page-template canvas-view-state --output .cache/samples/canvas-view-state.jsx
-```
-
-将片段整体合并到业务源码并合并 React import；在 YidaComp 外声明稳定配置。视图数组和每个筛选数组必须非空、由字符串组成，第一项是默认值；namespace 使用当前页面唯一的稳定名称。
-
-```jsx
-const REGISTRATION_VIEW_STATE = {
-  namespace: 'registrationList',
-  views: ['list', 'calendar'],
-  filters: { status: ['all', 'pending', 'confirmed'] },
-};
-
-function YidaComp() {
-  const [route, changeRoute] = useCanvasViewState(REGISTRATION_VIEW_STATE);
-  // Tabs.activeKey = route.view
-  // Tabs.onChange = view => changeRoute({ view })
-  // Select.value = route.filters.status
-  // Select.onChange = status => changeRoute({ filters: { status } })
-  // Pagination.current = route.page
-  // Pagination.onChange = page => changeRoute({ page })
-  // 查询依赖 route.view / route.filters.status / route.page，取消或忽略过期请求。
-  return <div>{route.view}</div>;
-}
-```
-
-片段恢复当前任务的视图、白名单筛选和页码，监听前进后退及页面返回，保留无关 query、完整 hash 和 history.state；重复选择不增加历史。它不管理跨任务缓存、滚动、权限或草稿，也不拦截浏览器离开。已有路由时把同样的白名单、编码与恢复规则接入现有路由，不再调用片段写 history。iframe 中仅操作当前页面窗口；须实测平台刷新和顶层返回能否恢复当前地址，平台未保留 iframe 地址时不能宣称支持跨页恢复。
-
-有编辑区时，先实现保存/放弃/取消策略，再允许页面切换；浏览器返回沿用现有路由的离开拦截能力，取消须保持地址、选中态与内容一致。浏览器关闭/刷新只能使用其支持的 beforeunload 提醒，不能保证自定义弹窗或自动保存。缺少可靠离开拦截时，优先使用有已验证草稿能力的原生表单，不把无保护的编辑器接到这个片段上。
-
-## 验收
-
-验证筛选后翻页 → 详情 → 返回、刷新、前进后退、重复选择、快速连续切换、非法 URL、权限变化和草稿取消离开。跨任务、跨用户不能复用旧草稿或数据；没有真实浏览器验证时明确记录待验证范围。

package/yida-skills/skills/yida-canvas-data-binding/references/business-action-permissions.md

@@ -1,31 +0,0 @@
-# 业务动作的授权与状态约束
-
-隐藏按钮、禁用控件、isAppAdmin、前端角色判断和 URL 都只是界面控制。确认报名、取消、签到、删除等写操作，必须由平台权限配置或真实服务端动作校验当前访问者、目标记录、可修改字段及允许的状态变化。不能把“管理员按钮已隐藏”作为权限验收结果。
-
-## 先建立动作清单，再接按钮
-
-在现有 PRD 或页面实现计划中逐动作记录：业务角色、真实资源和操作、数据范围、可写字段、前置状态、成功状态、实际调用、权限配置/服务端实现位置和验证结果。不新增虚构的权限 API，不把应用管理员身份自动视为业务运营角色。
-
-活动报名示例（最终以真实业务需求为准）：
-
-| 动作 | 授权与数据范围 | 服务端约束 |
-| --- | --- | --- |
-| 确认报名 | 运营角色，只操作被授权活动的报名记录 | 仅待确认可转已确认；普通参与者不能写确认字段 |
-| 取消报名 | 参与者只取消本人记录；代取消需独立授权 | 校验当前状态与取消时限；不能靠请求传入的 userId 判断本人 |
-| 签到 | 被授权签到人员，只操作负责活动的记录 | 校验可签到状态；重复请求不能重复计数或产生重复副作用 |
-
-平台通用 updateFormData 可调用，不代表上述业务规则已经满足。核对实际表单权限、字段可写范围和流程规则能否覆盖每一条约束；不能覆盖时，通过已验证的服务端动作或原生审批流程实现。只在前端查询“未重复”再提交存在并发窗口，幂等、版本/状态前置条件须由服务端原子执行。连接器保存凭证也不自动保证记录级授权，不能暴露可让普通访问者任意更新数据的特权接口。
-
-如果真实能力尚不具备，保留说明并禁用对应业务动作，将缺口列为未完成；不要用前端 if、按钮隐藏或成功提示冒充授权完成。页面不携带 CLI 管理员 token，不复制管理员身份执行访问者操作。
-
-## 请求与反馈
-
-客户端只发送动作所需字段，不把整行数据回写；服务端从认证上下文确定操作者并检查目标记录归属。点击后防重复只是体验保护，不能替代服务端幂等。成功后回读权威状态再更新列表和统计；失败不把界面推进到成功状态，保留原数据和可恢复输入。
-
-按接口真实错误契约区分无权限与状态冲突，不假设所有 API 都使用相同 HTTP 状态码。无权限时更新入口可用态、提示原因；状态冲突时重新读取记录并提示刷新，不自动重放写请求。前端不知道权限时先禁用或隐藏，不用乐观放行。
-
-## 多身份验收
-
-使用当前真实访问者的凭证逐项验证：管理员或业务角色的合法操作、普通用户直接调用隐藏动作、替换他人记录 ID、写入未授权字段、过期状态、重复与并发提交。对拒绝用例回读数据和副作用，确认确实未修改。测试普通用户时不能复用 CLI 管理员凭证；匿名仅在页面支持匿名访问时纳入验证。
-
-记录角色、目标、预期、实际返回与回读结果。只有编译、发布、配置回读或管理员正向测试时，权限验收仍为待验证；样例与静态检查不证明线上授权有效。

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

@@ -1,93 +0,0 @@
-# 应用风格模板与自由创意
-
-先决定应用的整体设计语言，再让导航、应用框架、首页、自定义页面、提交/编辑表单与记录详情共同使用它。按 [导航与应用框架](application-theme-consistency.md#导航与应用框架) 同时设计表面、状态、边界、形状、文字和间距。模板提供可执行的起点；**自由创意是同等可用的独立路径**，从业务推演，不要求先匹配模板。已有应用沿用其设计，不为单页重选风格。
-
-## 找到和导出
-
-`openyida design-plan catalog --json` 返回模板 `themes` 与独立的 `creativeOption`。全部 34 个主题入口统一采用三文件目录，均可用 `application-style` 导出；其中 18 套应用风格与自由创意仍保留 `collection: application-styles` 分类。目录元数据提供完整设计、CSS 和原生布局的相对路径，可直接定位对应文件。
-
-```bash
-openyida sample yida-design application-style --style-id app-executive --output prd/my-app/style-start
-openyida sample yida-design application-style --style-id free-creative --output prd/my-app/creative-start
-```
-
-每套导出 `design.md`、`app_theme.css`、`form-layout.json`；目标目录中任一同名文件已存在时，CLI 报错并保留原文件。每份 `design.md` 同时包含自定义页面的逐页设计引导，以及表单的组件位置、布局、样式、状态和响应式引导。设计与 CSS 中的品牌颜色保留占位：`--color-brand1-6` 使用 `{{PRIMARY_COLOR}}`，`--color-brand1-1` 按主色生成悬停色，其余品牌档位保持同源。项目占位符与空字段布局是项目化起点；使用时替换真实项目内容、完成最终设计并生成项目主题与表单布局。上传主题时使用项目实际生成的 CSS 路径，`app-theme.css` 与 `app_theme.css` 均可。
-
-## 命令与参数
-
-| 步骤 | 命令与参数 | 输入与结果 |
-| --- | --- | --- |
-| 查询主题 | `openyida design-plan catalog --json` | 从 `themes[].themeId` 或 `creativeOption.themeId` 取值 |
-| 导出三文件 | `openyida sample yida-design application-style --style-id <themeId> --output <目录>` | `--style-id` 必填，支持目录中的全部主题；`--output` 缺省为当前目录下 `.cache/samples/application-style` |
-| 生成或更新 CSS | `openyida sample yida-design app-theme --design-file <design.md> --output <CSS路径>` | 设计中的品牌色和派生颜色先填成实际值；同路径更新保留自定义 CSS，并维护旁边的 `<CSS路径>.tokens.md` 更新记录 |
-| 绑定应用 | `openyida update-app <appType> --theme-file <CSS路径> --nav-theme <light或dark> --layout <side或top或l_shape> --show-app-nav` | 上传后分别核对主题和导航回读，再检查页面实际效果；应用级自绘导航改用 `--hide-app-nav` |
-
-`--style-id` 只用于三文件导出，`--design-file` 只用于主题生成。`--var KEY=VALUE` 用于其他代码示例的占位替换；应用主题的品牌色和导航值写入 `design.md`。`app-theme` 的 `--output` 缺省为 `.cache/samples/app-theme.css`；省略 `--design-file` 会用公共模板重置目标 CSS。三文件导出中的占位 CSS 先经过主题生成，再上传。
-
-`--nav-theme` 选择平台导航明暗，`--layout` 选择结构。平台兼容参数还接受 `white` / `gray`，正式设计使用模板派生的 `light` / `dark`。菜单圆角、普通/悬停/选中边框、选中阴影、项高、内距与间距是[导航 token](application-theme-consistency.md#导航与应用框架)，在 Fast 的设计 token 或 Plan 的 `visualStyle.tokens` 中填写。CLI 读取设计文件后生成消费样式；这些值没有单独的命令行开关。较早的 CSS 在设计提供菜单边框 token 后会补齐缺失的菜单形状规则。四种差异明显的组合及访问态验收方式见[案例经验](application-theme-consistency.md#导航形状与密度的案例经验)。
-
-## 主题明暗双轴
-
-`contentTone` 表示页面画布、卡片、表单、详情、自定义页面和浮层采用浅色或暗色界面；`navTheme` 表示平台导航框架采用浅色或深色。两者是独立维度；命名模板从模板元数据派生导航明暗，自由创意由项目明确设计并配套导航 Token。两者独立选择：深色导航可以搭配浅色内容，浅色导航也可以搭配暗色内容。模板名中的“深色侧栏”描述 `navTheme`，应用整体明暗以 `contentTone` 为准。
-
-## 18 个应用方向
-
-| ID | 风格 | 构图与表单差异 |
-| --- | --- | --- |
-| app-wire | 精密线框 | 工具带、细边界、稳定双列 |
-| app-paper | 奶油手账 | 窄幅纸页、题签、单列长阅读 |
-| app-sage | 植物浮雕 | 柔绿分区、轻内凹、宽松双列 |
-| app-pop | 波普印刷 | 大标题、粗边与硬阴影、二比一布局 |
-| app-neon | 午夜霓虹 | 暗色技术工作区、局部微光、双列 |
-| app-line | 极简下划线 | 窄单列、纯文字标题、强调线 |
-| app-glass | 雾面玻璃 | 雾紫衬底、轻透层次、舒展双列 |
-| app-ticket | 复古票据 | 票据抬头、双线、窄幅键值阅读 |
-| app-editorial | 杂志编辑 | 左侧衬线大标题与导语、右侧正文 |
-| app-terminal | 终端像素 | 等宽标题、点线、紧凑记录集合 |
-| app-platinum | 铂金商务 | 铂灰细线、合同摘要、均衡双列 |
-| app-executive | 墨金行政 | 香槟金标题、左介绍栏、右单列章节 |
-| app-finance | 金融蓝图 | 编号章节、水平标签、紧凑双列 |
-| app-nordic | 北欧云白 | 大段间距、柔白、单列服务流程 |
-| app-teal | 青岚运营 | 状态带、主次二比一、任务流 |
-| app-amber | 琥珀工单 | 三列短字段、长字段跨栏、紧凑工单 |
-| app-graphite | 石墨数据 | 暗色连续表格、细行线、双列 |
-| app-plum | 绛紫咨询 | 衬线导语、双线章节、七比五分栏 |
-
-按业务任务、品牌和使用环境选择风格。暗色方向仅在用户或使用环境明确需要时选择。单行控件的半径、高度、边界、状态与布局一起设计。装饰使用平台已验证的组件和样式能力。
-
-## Fast 与 Plan 如何消费
-
-- **Fast**：选定方向后导出一套起点，按唯一输出契约补成最终 `design.md`；保留模板已有的 `applicationStyle` 消费标记，删除模板 `themeId`，填入真实项目、颜色、页面与引用，完成 `check-design`。然后运行 `openyida sample yida-design app-theme --design-file <design.md> --output <app_theme.css>`。共享生成器会携带这组应用风格的语义类配方，后续重生成保留配方之外的自定义 CSS。
-- **Plan**：`design-plan init` 使用目录中的 `themeId`（`--theme-id`），项目差异放 `visualStyle.tokens`，各页布局写入已有逐页设计。CLI 物化时生成正式 `design.md` 与返回路径中的 `app-theme.css`；文件名沿用 Plan 契约，不另生成第二份应用主题。
-- **实现**：应用级上传一次项目 CSS。导航读取完整的 `tokens.application-global.appearance.navigation`，平台导航保留原变量消费关系，自定义导航由组件明确引用。Canvas 读取设计里的 Token，并可使用 `.oyd-style-workspace`、`.oyd-style-intro`、`.oyd-style-section`；框架、表单和详情应用同一主题。自定义页面落实具体构图。
-- **表单**：先在 `design.md` 写清各区域使用的组件、列比例、间距、长字段整行和移动端重排。`form-layout.json` 提供字段与分栏的初始结构；在各列填入 PRD 字段，并按设计调整布局。`--theme compact` 等参数只设置密度，应用 CSS 负责视觉样式。
-
-表单支持在顶部、左侧、主体、右侧和字段之间放置 Tab、按钮组、图片或图形、标题与 `Divider`、分栏、状态区、辅助内容和字段。各组件分别负责导航切换、操作入口、视觉焦点、状态反馈、内容组织或数据采集。普通业务分组和章节分隔使用 `Divider`，横向字段组合使用 `ColumnContainer`。
-
-编辑已有表单时保留现有组件。列比例按内容与宽度确定；抽屉和 iframe 按实际宽度重排。
-
-## 自由创意必须能独立完成
-
-选择 `free-creative` 表示**不选择任何现成视觉模板**。基础文件只是平台合法 Token 的编写骨架，没有被选中的风格；不要把模板改名充当自由设计。比较候选时必须提供“自由创意：根据这项业务重新推演”这一项；已委托 AI 的 Fast 可直接采用它，不追加无必要确认。
-
-Plan 将下列对象写入 `visualStyle.creativeDirection`；Fast 写入最终设计 frontmatter 的 `creativeDirection`。用真实、具体的项目决策替换说明文字：
-
-```json
-{
-  "businessRationale": "用户、使用频率、业务重点，以及为何采用此视觉方向",
-  "composition": "导航、标题区、主体、上下文区域的位置和宽度",
-  "typography": "正文、标题、数字的字体、层级和对齐关系",
-  "material": "画布、内容面、边界、阴影与状态的关系",
-  "formLayout": "提交、编辑、详情的组件树、顶部/左侧/主体/右侧区域、列比例、间距、底栏和窄屏重排"
-}
-```
-
-Plan 的 `visualStyle.tokens` 必须显式提供：画布 `--pod-page-bg-color`、表面 `--pod-card-bg-color`、文字 `--color-text1-4`、控件 `--form-element-medium-corner` / `--form-element-medium-height`、底栏 `--pod-page-footer-bg-color` / `--pod-sticky-footer-box-shadow`，以及自定义页面 `--oyd-content-width` / `--oyd-content-padding` / `--oyd-field-gap` / `--oyd-heading-font` / `--oyd-heading-size` / `--oyd-rule-style`。其余角色同样按完整设计配套，数据管理外层底栏与按钮内层分别决定。Fast 将这些值写入设计的 Token 分组。缺少决策或关键值时生成器报错，不自动选一套模板。
-
-自由创意还需显式写入 [六个基础导航色](application-theme-consistency.md#导航与应用框架) 与 `navTheme`，并按业务布局设计框架、菜单形状、文字、间距及状态。Fast 与 Plan 使用同一完整主题文件。
-
-## 验收与维护
-
-看应用整体，覆盖导航、自定义页、提交、编辑、详情、数据管理内嵌、抽屉和移动端，核对正文/底栏对齐、背景连续、hover/focus、禁用/错误和窄屏布局。应用主题与表单组件树共同作为验收基线。
-
-维护既有主题时修改对应目录的 `design.md` 与 `form-layout.json`；维护导航时修改 `templates/navigation-styles.json`，维护应用风格预设时修改 `templates/application-styles.json` 与共用配方，再运行 `node scripts/build-application-styles.js`；随后运行模板、Plan/Fast、原生布局测试及 `check:skills`。该脚本仅用于仓库维护，应用搭建使用上述 CLI。

package/yida-skills/skills/yida-design/references/application-theme-consistency.md

@@ -1,150 +0,0 @@
-# 应用各页面共用主题
-
-Fast、Plan 和单页开发使用同一条链路：设计源文件 → `design.md` 的 token → `app-theme.css` → 导航、应用框架、原生表单、记录详情与自定义页面。页面代码负责布局、业务交互和局部装饰，基础配色与组件风格统一读取应用主题。
-
-## 导航与应用框架
-
-设计应用时，同时确定导航、应用框架、提交与编辑表单、记录详情、自定义页面的视觉关系。导航负责说明应用身份、业务层级和当前位置；框架负责组织内容宽度、背景与滚动区域。它们与业务内容共用字体、形状、间距和状态语言，各区域按用途选择表面与强调程度。
-
-先按 [导航决策](navigation-decision.md) 确定菜单、层级、顺序、默认页面及顶部、侧边或 L 型布局，再将外观写入主题。三个设置各管一件事：`navigationType` / `layoutDirection` 表示入口组织和布局，`navTheme` 表示导航明暗模式，导航 token 表示实际颜色、边界、形状、文字与间距。业务布局保持已确认的选择；主题模板为该布局提供视觉样式。
-
-| 设计对象 | 写清的内容 | 与其他页面的关系 |
-| --- | --- | --- |
-| 导航和框架表面 | 导航背景、应用外衬、内容画布及交界处的边框、阴影 | 分清应用外衬、页面、卡片与表单的背景层次 |
-| 菜单状态 | 默认、悬停、选中的文字、图标、背景和标记；实际实现中的焦点、禁用与展开状态 | 选中态表达当前位置，按钮表达操作，分别保证可读性 |
-| 形状与边界 | 菜单项圆角、边框、选中标记、分组分隔及阴影 | 与表单控件、详情数据框和内容容器使用同一套形状规则 |
-| 文字与间距 | 菜单字体、字号、字重、行高、项高、内距和分组间距 | 与页面标题、字段标签、正文和数据密度协调 |
-| 布局与交互 | 导航占位或叠加、内容宽度、滚动、折叠及窄屏菜单 | 按 [连续性规则](page-continuity.md) 保持内容对齐与往返状态 |
-
-命名模板在 `tokens.application-global.appearance.navigation` 提供完整导航 token，并提供对应 `navTheme`。这组变量是导航外观的唯一取值来源，覆盖基础六色，以及模板定义的页头、Logo、分组、搜索、弹层、菜单尺寸、文字、工具按钮、顶部选中线和 L 型框架等角色。项目保留这组变量及其消费规则，将主色和已确认的项目差异合入同一主题；浅色导航可以呈现暖纸、柔绿、雾紫或精密线框，深色导航也按模板保留自己的材质、边界和选中方式。`light` / `dark` 用于选择平台导航模式，具体外观以主题 token 为准。
-
-`free-creative` 按业务独立设计上述关系，并在设计源中显式填写导航明暗与六个基础导航色：导航背景、菜单文字、悬停文字、选中文字、悬停背景和选中背景；其余导航变量按实际设计补齐。变量名以 [基础变量契约](../templates/design-themes/basic-tokens.json) 和当前模板为准，平台变量保留原名，扩展变量说明实际消费位置。项目用到的形状、文字与间距也写入 token，正文解释怎样使用。
-
-平台导航由应用主题及已有平台消费关系实现；自定义导航读取同一份导航 token，并在自身组件内实现形状、布局与交互。只有自定义组件实际引用、或经过核实的平台选择器使用的变量才会改变外观。自定义菜单的聚焦、折叠、拖拽与返回等交互按 `yida-nav-shell` 实现；导航隐藏、权限和页面范围沿用 PRD。
-
-菜单形状使用 `--pod-nav-menu-item-radius`；普通、悬停、选中边框分别使用 `--pod-nav-menu-item-border`、`--pod-nav-menu-item-hover-border`、`--pod-nav-menu-item-selected-border`。三项边框由 OpenYida 主题 CSS 的导航选择器消费，覆盖侧栏、L 型侧栏和顶部菜单。边框填写完整 CSS 值，例如 `none`、`1px solid #AAB7AE`、`3px double #A7744D`；各状态保持同一宽度，避免文字位置跳动。选中阴影继续使用 `--pod-nav-menu-item-selected-shadow`，可与边框组合。验收时查看菜单的实际圆角、线宽、线型和选中标记，分别核对侧栏与顶栏。
-
-Fast 在 `design.md` 的第 2.2 节说明最终导航与框架规则，token 写入 frontmatter；Plan 在 `visualStyle.tokens` 保存项目差异，由 CLI 生成同一设计与主题文件。导航 token 随应用主题一次生成、上传和校验，各页继续消费同一份主题。
-
-### 导航形状与密度的案例经验
-
-比较导航时，把圆角、三态边框、选中阴影、菜单高度、内距和间距作为一组设计。先让菜单轮廓和疏密有清楚的区别，再配合颜色与文字层级。下面四种做法已用于案例应用，并沉淀到对应主题的设计与 CSS；它们提供外观参考，顶部、侧边或 L 型布局仍由业务入口决定。
-
-| 风格 | 轮廓与选中方式 | 密度与框架 |
-| --- | --- | --- |
-| 波普印刷 | 方角、3px 粗墨线，黑底黄字搭配 5px 粉色硬阴影 | 顶部菜单 44px，间距 16px，68px 顶栏给菜单和阴影留空 |
-| 北欧云白 | 999px 胶囊，2px 透明边框预留位置，选中深绿底白字与轻阴影 | 菜单 52px，内距 12px 18px，间距 14px，柔绿侧栏保持舒展 |
-| 复古票据 | 方角、5px 棕色双线，浅纸底选中项配 4px 硬阴影 | 菜单 50px，内距 10px 14px，间距 14px，双线和纸张层次延续到内容 |
-| 终端像素 | 方角、1px 虚线，暗底亮字，左右各 5px 内阴影标记当前位置 | 菜单 36px、间距 4px，紧凑顶栏与侧栏延续日志节奏 |
-
-项目调整时，把具体取值写回设计源，正文说明选择理由和消费位置。品牌色继续使用项目输入；装饰阴影、纸张底色和边框色按各自角色配套。Fast 修改 `design.md`，Plan 修改 `visualStyle.tokens` 后重新生成；维护公共模板时，同时修改导航维护源、生成三文件和索引摘要。项目覆盖某个值后，以生成的项目取值表为准。
-
-验收先看访问态的数据管理页，再看自定义页、提交页和详情页：普通、悬停、选中状态的边框都应可辨；选中状态遇到悬停仍保持当前位置标记。粗边框采用 border-box，并检查内层行高、文字居中和点击区域。外阴影需有周围留白，内阴影保持文字可读；长菜单名、折叠菜单和窄屏也要检查。应用 `/admin` 是开发配置后台，业务使用者看到的导航在访问态验收。
-
-## 平台基础变量是应用主题基础框架
-
-宜搭平台基础变量是平台提供的应用主题基础变量框架，供原生导航、表单、详情页、表格和浮层消费。项目主题保留这些变量的名称与用途，并按用户需求扩展材质、布局、字体、动效和组件状态变量。`app-theme.css` 承载平台基础变量、项目扩展变量及有明确消费对象的共享样式。
-
-- **平台基础**：保留平台变量的名称、用途和必要桥接，给原生导航、表单、表格及浮层使用；项目可以按这些角色调整取值。
-- **项目扩展**：按实际设计补充渐变、纹理、字体层级、内容宽度、栅格间距、材质、阴影、动效和组件状态等变量。这些是可选例子，不是新增必填清单。使用项目或组件语义命名空间；`--oyd-*` 是现有约定，也可使用 `--magazine-*` 等明确前缀，不伪装成平台已支持的变量。
-- **消费关系**：在设计正文就近说明变量服务哪个组件、用在哪个 CSS 属性或适配配置上。新增变量可供多个自定义页、组件及应用级样式共用；若需影响原生组件，映射到其已有平台变量，或在核实 DOM 后编写范围明确的 CSS 规则。定义变量本身不会改变任何组件。
-- **值的类型**：颜色、渐变/图片、长度、字体、阴影、时间和缓动分别用于匹配的 CSS 属性。共享渐变可以存入主题变量，由页面的 `background-image` 消费；用于 `background-color` 的平台变量仍保持颜色值。
-- **范围与复用**：稳定的主题值和复用组件参数进入主题；一次性的布局尺寸、局部状态和装饰可留在页面。避免为同一角色重复命名，也不要求把每个 CSS 常量都变成 token。
-
-`application-global` 与 `custom-page` 是设计文档的组织分组，不是 CSS 隔离作用域。两组声明都会写入应用主题的 `:root`，扩展变量可跨页使用，也可被平台变量引用；引用必须已声明且无循环。仅在某个页面选择器内定义的局部变量不能充当全应用依赖。保留现有分组即可，不另加一套文件或交接字段。
-
-## 先把风格落到变量
-
-“杂志风、暖色纸感、橙红点缀”等文字不会被 CLI 自动转换成 CSS。主色只影响主题公式指定的色阶，不能代表画布、卡片、字体和辅助色已经完成设计。选定方向后，对照模板的实际 token，将承诺的项目差异写入设计源文件；即使用户没给色值，也由设计者补齐，不留给页面作者临场配色。
-
-| 风格决定 | 存放位置 |
-| --- | --- |
-| 应用主色及交互色阶 | Plan 的 `forUser.colorStrategy.primaryColor`；Fast 的品牌 token |
-| 页面底、卡片底、文字、填充、边界、全局字体和圆角 | 已有平台语义 token，原生页和自定义页共同消费 |
-| 导航、应用框架与菜单状态 | 完整导航 token 与框架变量，按 [导航与应用框架](#导航与应用框架) 记录消费位置 |
-| 原生表单控件、提交页背景及详情页只读字段数据框 | [原生表单变量、详情只读态与背景分层](native-form-styles.md)，沿用同一主题生成链路 |
-| 平台没有对应角色的色彩、字体、材质、尺寸、动效和组件状态 | 项目扩展 token，由主题 CSS 提供，使用者显式引用 |
-| 分栏、大标题位置、封面构图、单页纹理 | 页面设计与页面代码；需共享或随主题变化的参数引用扩展 token |
-
-例如主色为墨黑 `#1B1B1B`，并已确认奶油画布、暖白面板、橙红装饰标签时，Plan 在 `visualStyle.tokens` 写入以下项目差异；Fast 将同样的变量写入 `design.md.tokens` 对应分组。这个例子只展示当前项目的内容配色，导航仍按完整应用设计配套。选中项阴影由 `--pod-nav-menu-item-selected-shadow` 独立控制。
-
-```json
-{
-  "--magazine-surface-paper": "#F6F1E8",
-  "--pod-app-root-bg-color": "var(--magazine-surface-paper)",
-  "--pod-page-bg-color": "var(--magazine-surface-paper)",
-  "--pod-card-bg-color": "#FFFCF6",
-  "--color-text1-4": "#1B1B1B",
-  "--color-fill1-1": "#FFFCF6",
-  "--color-fill1-2": "#EFE7DA",
-  "--color-line1-1": "#E5DCCD",
-  "--oyd-editorial-accent": "#C1451D",
-  "--oyd-editorial-heading-font": "Georgia, 'Songti SC', serif",
-  "--magazine-cover-image": "linear-gradient(135deg, var(--magazine-surface-paper), #EFE7DA)",
-  "--magazine-content-max-width": "1200px",
-  "--magazine-panel-shadow": "0 6px 24px rgb(27 27 27 / 8%)",
-  "--magazine-motion-duration": "180ms"
-}
-```
-
-保留 `--color-white`、表格表面与移动品牌的既有桥接。不要把品牌色阶改成奶油色来代替页面背景。装饰色不自动充当错误或成功色；需要用作操作色时，先在项目设计中明确角色、状态和前景，再写入共享变量。
-
-## 指标卡与按钮配色
-
-先看页面的画布、卡片、图片和导航已经用了哪些颜色，再确定用户最需要看见的信息和操作。结合这些背景的冷暖、明暗、饱和度与面积，选择同色系的温和搭配，或用少量对比色突出重点；大面积背景宜克制，小面积操作可以更鲜明。品牌色、邻近色、协调的对比色和中性色都可使用，不把“与主题协调”理解成“全部使用主题主色”，也不默认选黑色。已确认的暗色、黑白品牌或用户参考仍按原方向设计。
-
-| 对象 | 配色方式 |
-| --- | --- |
-| 普通指标 | 使用卡片底和正文色，辅助说明降低强调程度；同组指标保持一致，不按序号轮换彩色背景 |
-| 重点指标 | 选择与画布协调的浅彩底，或只强调数字、图标和短色带；颜色可与品牌不同，但要服务信息分组。需要实色面板时单独配套前景，不因“有指标”就把整条摘要染深，也不抢过当前主操作 |
-| 主按钮 | 根据所在背景和整页配色选择操作强调色，可用品牌色、协调的辅助色或中性色。先保证容易找到、文字清晰，再看它与指标、图片和导航是否协调；同一操作组突出一个主要动作，不要求按钮与导航选中态同色 |
-| 次按钮与工具 | 使用中性底、文字和边框，刷新、筛选、详情不自动变成实色主按钮；形状与颜色分别决定，胶囊形不代表近黑色 |
-| 状态与危险操作 | 逾期、失败、成功和删除使用对应语义色，并保留文字说明；普通待办不自动算警告，普通总数不自动算成功 |
-
-每种实际使用的表面都成对确定背景、文字、图标及边界；按钮同时确定 hover、pressed、focus 和 disabled。普通文字对比度至少 4.5:1，传达信息的图标及必要控件边界至少 3:1；白字不一定适合亮品牌色，按实际对比选择深色前景或可读的品牌变体。不能只换背景而沿用原来的白字，也不能让图标与底盒共用同一个实色。
-
-将配色和搭配理由写入现有组件规则及页面的 `surface`、`primaryAction`，对应值写入已有 token；只有缺少语义时才补项目变量，不增加文件或必填字段。相同角色的操作跨页面保持一致，特殊背景上的变体成组定义；操作色和信息色可以不同，不能每张卡、每个按钮临时选色。模板中的固定配色服从当前项目的配色决定。没有声明的旧主题变量不能靠黑色 fallback 继续生效；跨应用复用代码时，逐项替换指标与按钮的颜色角色。
-
-## 分组标题与分割线
-
-分割线按页面用途选择，不跟随主题模板固定成一种。高频录入重扫描效率，可用圆点、简线或浅底；资料审核重分组识别，可用带条浅底；活动、品牌专题才考虑居中标签或几何装饰。这些是候选方向，不是行业到样式的一一映射。
-
-同页同层级的分组标题尽量保持线型、装饰、对齐和配色一致；不同业务页面优先选择不同且合适的类型。先比较用途、密度、标题长度和主题，再决定差异；相同任务可以复用；场景不明确或候选同样合适时，将候选随机打乱后按页面轮换，优先用本轮未使用的样式，用完再重排。没有场景判断依据时，从全部 23 种中轮换；每页只选一次，同页复用，后续修改和重试不重新抽签。普通表格网格、卡片边框和章节分割线分别处理，不为了差异把整页边框都换成装饰线。
-
-在现有 `design.md` 的页面说明中写“页面、分割线样式、选择理由”，无需增加文档或必填机器字段。原生表单从 `yida-create-form-page/references/form-field-properties.md#divider` 的 23 个可见样式中选型，排除 `none`，通过 `Divider.dividerType` 配置；Canvas 按相同原则实现分组标题，不假定可直接使用平台 Divider 组件。Fast 与 Plan 均按页面选择。
-
-同一应用保持字体、间距和整体配色协调，差异主要来自分组形态与视觉轻重。平台主题模式使用品牌主色、浅色和正文色；`dark-bar` 表示实底标题条，并非固定黑色。强色底需检查文字可读性，长标题和窄屏优先使用简单形态。已有页面的局部修改保持原样式，只有本次明确调整分组设计时才更换。
-
-## 页面只引用设计值
-
-普通 DOM 直接使用 CSS 变量，不需要为了换肤强加 antd 或 Provider。页面局部别名可以简化代码，但应引用主题变量：
-
-```css
-.editorial-shell {
-  --ink: var(--color-text1-4, #1B1B1B);
-  --canvas: var(--pod-page-bg-color, #F6F1E8);
-  --accent: var(--oyd-editorial-accent, #C1451D);
-  color: var(--ink);
-  background-color: var(--canvas);
-}
-.editorial-panel { background-color: var(--pod-card-bg-color, #FFFCF6); }
-.editorial-heading { font-family: var(--oyd-editorial-heading-font, Georgia, serif); }
-.editorial-content { max-width: var(--magazine-content-max-width); margin-inline: auto; }
-.editorial-cover { background-image: var(--magazine-cover-image); }
-.editorial-panel { box-shadow: var(--magazine-panel-shadow); }
-.editorial-action { transition: background-color var(--magazine-motion-duration) ease; }
-@media (prefers-reduced-motion: reduce) { .editorial-action { transition: none; } }
-```
-
-fallback 只用于变量暂不可用的兜底，不能作为线上主题已加载的证据。不要在页面根写 `--canvas: #F6F1E8` 等固定基础色盘，也不要重新声明平台 token 覆盖应用主题。局部插画、照片和装饰允许有独立颜色，不强制把所有色值归为品牌色。
-
-antd 控件按 Canvas 技能接入 `CanvasThemeProvider`，由适配层读取当前根容器的计算样式；Provider 不会替换页面中写死的 CSS，也不代表每种字体、圆角和组件参数都已自动适配。实际控件仍需核对消费关系。
-
-发现已确认的全局风格没有对应变量时，先补设计源：Plan 修改 `visualStyle.tokens` 后重新 `materialize`；Fast 更新 `design.md` 后运行带 `--design-file` 的 `sample`。读取生成的 token，上传返回的同一份主题文件，再检查页面。不要只改生成后的 CSS，也不要靠复制色盘到各页补救。
-
-## 验证主题是否真正一致
-
-1. **设计与文件**：逐项对照已确认的导航、框架、主色、页面底、面板、文字、字体及特色强调，确认它们出现在生成的主题 token 中，页面用的是同一角色。导航明暗与模板或自由创意决策一致，导航状态、形状与密度保留本项目设计。文件名叫 `app_theme.css` 或 `app-theme.css` 不影响契约，以本次输出路径为准。
-2. **绑定**：`themeVerification.verified=true` 仅证明应用设置绑定了主题资源。`iframePropagation` 是配置字段，不是当前页面主题加载的检测结果；不能凭它为 `false` 就断言 Canvas 收不到变量，更不能据此改成固定色盘。
-3. **运行态**：检查实际导航及其默认、悬停和选中状态，并对照应用框架、原生列表、提交/编辑表单、记录详情、自定义页及实际存在的抽屉。逐类检查实际存在的页面，核对主题资源、容器计算变量、背景、文字、形状、间距和主操作；iframe 单独检查其文档。变量缺失查资源加载与作用域，变量正确但外观不对查页面硬编码与样式覆盖。
-4. **交付**：原生页共享其组件支持的配色、字体、圆角等主题能力；杂志封面、分栏与特色版式只在有相应布局实现的页面出现。没有运行态证据时明确标记“主题已绑定，跨页面视觉待验证”，不能用编译成功、资源齐全或 fallback 看起来正确代替验收。