visual-spec 0.1.2 → 0.1.4

package/skills/visual-spec-skill/prompts/vspec_verify/prototype.md

@@ -288,7 +288,17 @@ catalog:
 2. 支持按角色视角查看/操作（可用“切换当前角色”的简单方式模拟权限）
 3. 只实现 UI 原型与前端假数据（mock），不要求真实后端
 4. 页面必须带有可操作的按钮（新建/提交/审批通过/驳回/执行开始/执行结束/变更/取消/紧急叫停等），并用这些按钮把流程“串起来”（点击后状态变化 + 跨页面流转 + 导航）
-5. 若本需求属于“申请资源/预约/排班/派车/占用时间段”类型系统，必须生成“日历视图”页面，用于按时间查看资源占用与申请单分布，并作为关键入口（新建/查看详情/切换资源与时间范围）
+5. 若本需求涉及“时间浏览/按时间维度查看安排/占用/排期/排班/课程表”等任一诉求，必须生成“日历视图”页面，用于按时间查看资源占用与业务单据分布，并作为关键入口（新建/查看详情/切换资源与时间范围）。示例关键词：课程表、排期表、排班表、预约、占用时间段、日程、班次、课时。
+
+登录页面（命中则必须）：
+1. 若需求未采用 SSO/OIDC/LDAP 等统一身份接入，且属于“本系统独立登录”形态：必须生成登录页并作为入口：
+   - Web：`/login`
+   - Mobile：`/m/login`
+2. 登录页必须能完成“选择账号 → 登录 → 建立 session mock → 进入应用（/ 或 /landing）”：
+   - 允许 mock 登录，不要求真实鉴权，但必须通过 session 控制路由访问（未登录访问业务页必须引导到登录页）
+   - 登录成功后仍需保留 Header Avatar 的“切换账号/切换角色”能力（用于演示不同权限）
+3. 非 SSO 的登录页系列（命中则必须）：
+   - 必须按 `prompts/vspec_verify/prototype_auth.md` 执行，补齐 Web+Mobile 的登录、创建账号、忘记密码、重置密码、修改密码等页面，并与 session/路由拦截联动可演示。
 
 身份切换与差异展示（必须）：
 1. 必须在 Header 右侧 Avatar 下拉中提供“切换账号/切换角色”入口，并可在不刷新页面的情况下生效。
@@ -303,8 +313,11 @@ catalog:
 权限与操作控制（必须）：
 1. 权限来源：
    - 必须以 `/specs/background/roles.md` 的“角色→任务/能力”作为唯一口径来限制页面入口与操作按钮的可见性
+   - 必须严格参考 `/specs/details/<module_slug>/rbac/*` 与 `/specs/details/<module_slug>/data_permission/*`：
+     - 控件级可见性/可操作性必须与 rbac 对齐
+     - 列表默认过滤、详情可见字段、可操作数据范围必须与 data_permission 对齐
 2. 不可见（无权限）：
-   - 当当前角色不具备某入口/操作的权限时：必须禁止显示（不要渲染该入口/按钮）
+   - 当当前角色不具备某入口/操作的权限时：必须禁止显示（不要渲染该入口/按钮），不得“全部显示后再提示无权限”
 3. 不可操作（有权限但条件不满足）：
    - 当当前角色具备权限，但因状态/阶段/数据条件不满足导致不能执行该操作时：必须显示该操作控件但置为不可用，并给出明确原因提示
    - 原因提示要求：至少提供 Tooltip（或同等可见提示）；并在用户尝试触发时给出 message/notification 级别的提示（内容必须为中文）
@@ -343,47 +356,21 @@ Session 用户信息复用（必须）：
 
 端分配与路由映射（必须，解决“原型一塌糊涂”问题）：
 1. 必须以功能清单 `core.md` 每一行“说明”字段的 `端=...；入口=...；` 为准来生成原型，不允许擅自把功能放到错误的端。
+1.5 角色终端一致性（必须）：
+   - 生成原型前必须读取 `/specs/background/roles.md`，从“备注”列提取每个角色的主要终端（终端=Web/手机App/小程序/其他）。
+   - 原型页面端分配必须与角色终端匹配：属于“手机App/小程序”的角色，其核心任务页面必须生成在移动端路由（`/m/*`）；禁止把所有角色任务统一塞到 Web 端。
+   - 若 functions 标注为 `端=Web` 但角色终端为手机端：必须在原型首页“设置/说明”输出可见冲突提示，并采用最保守策略补齐移动端入口（`/m/<module>/<page>`），同时保留 Web 端为只读/调度视图（如适用）。
 2. 按端生成规则：
    - `端=Web`：必须生成 PC 端页面路由（入口若是 `/xxx` 则直接作为路由），并放入左侧菜单对应模块下。
    - `端=Mobile`：必须生成移动端路由（必须以 `/m/` 开头）；不得生成对应的 Web 菜单入口；若该功能在 Web 端需要入口，只允许生成“置灰按钮 + 提示 + 打开手机端链接”的跳转控件。
    - `端=Web+Mobile`：必须同时生成 Web 路由与 `/m/` 路由，并在说明里拆清两端职责；页面上也要体现职责边界（例如 Web 只做调度/分派，Mobile 做现场执行/扫码/签名）。
    - `端=Backend`：不生成页面与菜单；仅在 mock/API 层体现该能力被页面调用（例如服务端校验/路由/权限拦截/对外同步占位）。
-   - `端=Job`：不生成页面与菜单；仅在 mock 中体现任务结果对数据的影响（如状态推进/超时自动取消），并在定时任务汇总文档中体现（cron_job/overall）。
+   - `端=Job`：不生成页面与菜单；仅在 mock 中体现任务结果对数据的影响（如状态推进/超时自动取消），并在定时任务汇总文档中体现（cron_job/<module_slug>.md）。
 3. 若功能清单某行缺失 `端=` 或 `入口=`，必须在原型首页“设置/说明”区域给出可见错误提示，并使用最保守策略：
    - 默认为 `端=Web`，入口由你推断，但必须在提示中说明“已回退且需补齐 functions 端分配”。
 
-整体布局（必须）：
-1. 原型必须包含“顶部 Header + 左侧 Menu + 主内容区”的三段式布局：
-   - Header（必须按布局落位）：
-     - 左侧：Logo（点击回到 `/`）
-     - 右侧：Avatar（用户头像/姓名缩略）作为唯一的账号/角色切换入口（不得再放一个单独的“角色切换 Select”占位）
-       - 点击 Avatar 打开下拉菜单（Dropdown）：至少包含“切换账号”“切换角色”“个人中心”“退出”（名称可裁剪但必须覆盖账号与角色切换）
-       - “切换账号”：弹出 Modal/Drawer，展示可选账号列表（mock），切换后更新 session 的 `user_id/user_name/role_id/role_name/org_id/org_name`
-       - “切换角色”：弹出 Modal/Drawer 或在 Dropdown 内二级菜单，展示当前账号可切换角色（mock），切换后无需刷新页面立即生效
-       - 切换后必须立即体现差异：左侧菜单分组可见性、页面按钮可见/禁用、列表默认过滤“与我相关”
-     - 可选：全局搜索与常用入口可放在 Header 中部区域，但不得破坏“左 Logo、右 Avatar”的基本结构
-   - 左侧 Menu：必须按“分类分组”组织导航菜单（至少 3 组），并在组内按模块聚合页面入口：
-     - 组内入口规则：优先以“列表页/工作台”作为模块入口，详情/操作页不得作为独立菜单项
-     - 组标题必须使用业务可读的中文分类名（例如“主流程”“交易与订单”“内容与媒体”“报表与分析”“系统管理”）
-     - 若使用 Ant Design Vue：必须使用 SubMenu/ItemGroup（或等价能力）实现可折叠分组；不允许所有 Menu.Item 平铺
-     - `/tools/*`、`/profile` 等工具/个人中心入口不得出现在左侧菜单（仍遵循工具箱与用户菜单入口约束）
-   - 主内容区：router-view 渲染页面
-2. 适配手机/窄屏（必须）：
-   - 左侧 Menu 在窄屏时默认收起（或变为抽屉式侧边栏），Header 保留
-   - 提供“手机模拟器预览”模式：在桌面端以手机框（固定宽度 + 圆角 + 阴影）展示移动端页面内容
-   - 移动端页面不要求覆盖全部功能，但至少覆盖主链路中的 1-2 个关键页面（例如：我的待办、申请详情/审批详情）
-3. 移动端专属页面（必须）：
-   - 必须识别“更适合手机操作/现场操作”的角色，并为其生成明确的移动端页面，而不是仅用响应式适配
-   - 判定口径：roles.md 中出现“司机/执行人员/现场/外勤/巡检/配送/上门/作业/签收”等关键词，或任务天然需要移动设备（扫码、定位、拍照上传、现场确认、签名）
-   - 移动端页面必须独立路由前缀（推荐）：`/m/*`，并使用移动端布局（顶部简化 Header + 底部 TabBar 或关键入口按钮），不复用后台三段式布局
-   - Web 端左侧菜单不展示移动端专属页面入口；Web 端对应动作按钮必须置灰并提示“请在手机端操作”，并提供一个“打开手机端页面”的入口（可复制链接/跳转到 /m）
-   - 移动端必须至少生成：
-     - “我的任务/今日任务”列表（按状态切换：待开始/进行中/已完成/异常）
-     - “任务详情/执行详情”页（开始/结束/异常/上传凭证/联系等动作，动作表单用抽屉填写并写回 mock）
-   - 扫码/定位/拍照上传：可用 mock 占位实现（例如“模拟扫码”“模拟定位”“上传图片”），但必须产生可见结果并写入记录
-3. “模型”和“场景”不允许作为左侧菜单项出现：
-   - 不要在左侧菜单显示名为“模型”“场景”的菜单
-   - 若仍需要提供入口：放在 Header 的“更多/工具”下拉中，并使用非“模型/场景”的名称（例如“数据字典”“需求确认”）
+整体布局与导航（必须）：
+1. 必须按 `prompts/vspec_verify/prototype_layout.md` 执行（Web 三段式布局、Header/菜单分组、移动端布局、以及“场景验证入口禁止”等约束）。
 
 申请/变更/取消的菜单与操作组织（必须）：
 1. 左侧菜单不允许把“申请/变更/取消”拆成多个一级菜单：
@@ -432,6 +419,18 @@ Session 用户信息复用（必须）：
    - 审批：`/approve`（审批列表）
    - 执行：`/execute`（执行列表）
 2. “通过/驳回/开始/结束/紧急叫停”等动作必须出现在列表行 Action 或详情页操作区；禁止作为左侧菜单项入口。
+3. 适用范围扩展（必须）：
+   - 凡是涉及“报名/提交/审核/审批”等需要流转的页面，同样必须以“列表页”为入口；新建只能在列表工具栏按钮打开 Drawer 完成；审核/审批动作只能在列表 Action 或详情操作区触发。
+   - 若存在双端链路（例如学员 Mobile 报名、管理员 Web 审核）：必须分别在对应端提供入口与页面（Mobile 的报名列表/新建抽屉；Web 的审核列表/审核抽屉），并通过提示/跳转把两端闭环串起来。
+4. 审批交互（必须）：
+   - 禁止在表格内联编辑/内联审批；表格中只放“审批”按钮
+   - 点击“审批”必须打开抽屉（Drawer）填写必要字段后提交，字段至少包含：审批意见（必填）与审批结果（通过/驳回）
+
+Web 列表/查询页（必须）：
+1. 凡是 Web 端的列表页/查询页/管理页（包括申请/审批/执行/订单/报表/主数据等），必须提供“查询条件操作区”：
+   - 至少 2 个查询条件字段（按模型裁剪）
+   - 明确的“查询/重置”按钮（或等价交互）
+2. 特别强调（必须）：成绩列表、证书列表、历史记录类列表、回收数据列表等同样视为“查询页”，不得缺失查询条件区。
 
 CRUD 页面生成偏好（必须）：
 1. 所有 CRUD（配置/主数据/字典类）功能必须以“列表页”作为唯一入口页面：
@@ -452,6 +451,19 @@ CRUD 页面生成偏好（必须）：
    - 删除：Popconfirm 二次确认 + 中文提示 + 写入操作日志（mock）
    - 详情：允许“详情 Drawer”或“详情页路由”二选一，但入口必须来自列表 Action；禁止把详情做成独立菜单入口
 
+基础数据/主数据（必须）：
+1. 生成前端原型前，必须从 `/specs/models/*.md` 识别“基础数据/主数据”（维护对象）并建立清单：
+   - 识别口径（示例，可按需求裁剪但必须给出明确结论）：被多个业务单据引用、用于表单选择/绑定、稳定且可维护（例如：课程、讲师、学员、组织、资源、仓库、商品、字典项等）
+2. 对每一类“基础数据/主数据”，必须生成对应的 CRUD 管理页（Web 端）并可通过菜单进入：
+   - 列表页为入口，新建/编辑用 Drawer，字段来自模型并满足最小必填校验
+   - mock 数据必须支持新增/编辑/删除/启停后立刻在列表与引用处生效
+2.5 主数据层级（必须）：
+   - 若某主数据存在 1:N 从属对象（例如题库 → 考题、课程 → 课时、商品 → SKU、门店 → 收银机）：必须补齐从属对象的维护入口
+   - 从属对象管理入口必须从父对象详情进入（Tab/子列表），并能完成子对象的新增/编辑/删除（Drawer），且与父对象联动展示
+3. 业务流程页面必须以“基础数据/主数据”为前置条件：
+   - 业务表单中的下拉/选择器必须来自对应主数据 CRUD 的 mock 数据源
+   - 若主数据为空导致无法继续（例如排课必须先有课程/讲师/学员）：必须在页面给出可见提示，并提供“去维护主数据”的入口（跳转到对应 CRUD 列表页）
+
 页面与路由建议（可按需求裁剪）：
 - `/landing`：落地页/欢迎页（必须）
 - `/`：首页/工作台（按角色展示待办与入口）
@@ -484,8 +496,16 @@ CRUD 页面生成偏好（必须）：
 - `/articles`：文章列表（内容/资讯/公告/知识库域命中时建议生成）
 - `/articles/:id`：文章阅读页（与文章列表联动）
 - `/weather`：天气页（建议作为工具/演示页生成）
-- `/quiz`：答题/测评页面（用户明确需要则必须生成）
-- `/quiz/result`：答题结果页（与答题页联动）
+- `/quiz`：考试/答题/测评页面（命中“考试/答题/测评/题库/试卷/交卷/成绩”等任一关键词则必须生成；必须体现总题目数、作答进度、交卷流程）
+- `/quiz/result`：考试成绩/结果页（命中则必须生成；必须包含得分/正确率/用时与题目复盘）
+- `/m/quiz`：移动端做题页（命中则必须生成）
+- `/m/quiz/result`：移动端结果页（命中则必须生成）
+- `/surveys`：问卷管理（问卷列表 + 新建/编辑/发布/下线；命中“调查/问卷/满意度/反馈”等则必须生成）
+- `/surveys/:id`：问卷详情/编辑（命中则必须生成，至少 `/surveys/1`）
+- `/surveys/:id/responses`：问卷回收数据/答卷列表（命中则必须生成，至少 `/surveys/1/responses`）
+- `/m/surveys`：移动端问卷列表（命中则必须生成）
+- `/m/surveys/:id`：移动端填写问卷（命中则必须生成，至少 `/m/surveys/1`）
+- `/m/surveys/:id/result`：移动端提交回执/结果（命中则必须生成）
 - `/task-wall`：任务墙（看板/泳道/待办墙；建议生成）
 - `/achievement-wall`：成就墙（徽章/里程碑/排行；建议生成）
 - `/products`：商品列表（商品/库存/价格等域出现时必须；否则可作为示例页生成）
@@ -517,6 +537,14 @@ CRUD 页面生成偏好（必须）：
   - React 栈：必须使用 `react-router@6` 生成路由；路由 path 必须逐条匹配 functions 的 `入口=/...`（Web）与 `/m/...`（Mobile）。
   - 其他栈同理：router、state、http_client 等依赖与目录结构以 `catalog` 为准。
 - UI 组件库必须随栈切换（例如 Ant Design Vue / Ant Design / NG-ZORRO 等），禁止混用。
+
+外部设备数据来源（命中则必须）：
+1. 若需求/功能点涉及 POS 机、打卡机/考勤机、打印机、扫码枪等外部设备：页面输入必须以“设备读取”为主，不允许用屏幕上手工输入假装设备数据。
+2. 原型实现方式（可用 mock，但必须体现“读取”语义）：
+   - 提供“连接设备/断开设备”入口，并显示连接状态、设备标识、最近一次读取时间
+   - 通过“读取/扫码/刷卡/打印测试”等按钮触发模拟设备事件流（例如生成扫码/刷卡结果、打印回执号）
+   - 设备数据必须写入统一的 mock 设备数据源，并驱动业务流程（例如扫码后自动填充单号、刷卡后自动识别员工/学员）
+3. 若仓库/环境支持真实设备接入（如 WebUSB/WebSerial/WebBluetooth 或本地桥接服务）：优先采用真实读取；否则必须保留清晰的替换点（adapter/service），避免把设备数据写死在表单字段里。
 - 数据层使用本地 mock（例如 `src/mock/*.ts`），并根据 `/specs/models/*.md` 的字段生成示例数据
 - 关键页面必须包含：列表（Table）、详情（Descriptions/Drawer）、关键动作按钮（提交/审批/开始/结束/变更/取消）
 
@@ -611,6 +639,16 @@ Landing（落地页）生成要求（必须）：
 
 移动端通用 List 页面生成要求（必须）：
 1. 移动端列表页规则必须按 `prompts/vspec_verify/prototype_mobile_list.md` 执行。
+2. 移动端列表承载（必须）：
+   - 移动端页面的列表组件禁止使用 Table（包括 Ant Design Vue 的 Table），必须使用 Card/List/自定义列表组件组合实现
+   - 若需要多列字段展示：使用“列表项组件（component）”承载一条记录的标题/摘要/标签/状态/按钮，并在 List 中渲染该组件
+3. 移动端多选呈现（必须）：
+   - 移动端进行“多项数据选择”时，禁止使用 Checkbox 列表作为主要交互（尤其是长列表/商品列表场景）
+   - 必须使用列表项选择交互（点击整行切换选中态 + 选中标识），并支持搜索/筛选
+   - 若为商品/SKU 等：建议横向卡片列表（可横滑），卡片必须包含图片/icon、名称与价格分开展示，并提供进入详情入口；选中态用边框/勾角标识表达
+4. 移动端金额/价格展示（必须）：
+   - 涉及费用/价格/金额时，列表项布局必须为：左侧商品/标题信息，右侧价格信息
+   - 价格必须右对齐，且固定显示两位小数（例如 `1,234.00`），并与 Web 端金额格式保持一致
 
 移动端增强页面生成要求（按需裁剪，命中条件则必须）：
 1. 购物车/支付/协议/商品/瀑布流/信息流/日历等移动端页面：若命中对应域或用户明确需要，必须按以下规则文件生成并确保 Landing 金刚区可进入：
@@ -734,23 +772,14 @@ Toolbox（工具箱）生成要求（建议；若存在多个工具页则必须
    - 未来 3~7 天预报（Card/List mock）
 2. 必须支持“数据刷新/失败兜底”演示（与 config 的失败注入联动或用本页 mock 开关均可）。
 
-答题页面（Quiz）生成要求（用户明确需要则必须）：
-1. 路由：
-   - `/quiz`：答题页
-   - `/quiz/result`：结果页
-2. 答题页布局（必须可演示）：
-   - 顶部：题目进度（如 3/10）、倒计时（可选，但建议）与退出/保存（占位）
-   - 主体：题干 + 题目类型渲染（至少支持 2 种：单选/多选/填空/判断其二）
-   - 底部：上一题/下一题/提交按钮（按进度控制可用性）
-3. 交互与校验（必须）：
-   - 必填题未作答不得进入下一题或不得提交（两者择一，但必须可见提示）
-   - 支持“标记本题”与“题卡/答题卡”快速跳题（Drawer/Modal）
-4. 提交与结果（必须）：
-   - 点击提交弹出确认（Popconfirm/Modal）
-   - 提交后写回 mock：答题记录、用时、每题作答与正确性（可用 mock 规则判定）
-   - `/quiz/result` 展示：得分/正确率、用时、错题列表入口（可在本页展开）
-5. 回看与复盘（建议）：
-   - 结果页支持查看解析（mock 文本）与“再做一次”（重置答题记录）
+答题/考试页面（Quiz/Exam）生成要求（命中则必须）：
+1. 必须按 `prompts/vspec_verify/prototype_quiz.md` 执行，并补齐 Web + Mobile 的完整闭环页面：总题目数 → 作答 → 交卷 → 成绩/结果 → 解析复盘。
+2. 路由（必须稳定可访问）：
+   - Web：`/quiz`、`/quiz/result`
+   - Mobile：`/m/quiz`、`/m/quiz/result`
+
+调查问卷页面（Survey）生成要求（命中则必须）：
+1. 命中“调查/问卷/满意度/反馈/回访表/调研”等任一关键词：必须按 `prompts/vspec_verify/prototype_survey.md` 执行，补齐 Web 管理端 + Mobile 填写端完整闭环。
 
 协议确认（Agreement）生成要求（必须）：
 1. 必须生成 `/agreement/confirm` 页面，至少包含：
@@ -785,22 +814,36 @@ Steps（步骤条）使用要求（必须）：
      - 表单输入金额：使用 InputNumber 的 formatter/parser（或等价实现），保持两位小数与千位分隔符一致
    - 枚举/状态：必须使用 Select/Radio/Tag，并与模型/状态机对齐
    - 地点：若包含省市区/详细地址，必须拆分（Cascader + Input）
+   - 移动端数据选择（必须）：移动端页面选择“数据对象/字典项/主数据”（例如城市、组织、门店、人员、商品、课程等）时，禁止使用下拉框 Select 直接在当前页选择。
+     - 必须改为“点选进入选择页（List）→ 列表搜索/筛选 → 点击条目选中 → 返回上一页并回填字段”的交互。
+     - 表单页中该字段应表现为“只读输入框/Cell”，点击后跳转到 `/m/select/<entity>`（或模块内等价路由），并在选择页顶部提供返回与搜索。
+     - 选择页列表必须使用移动端 List/Card（禁止 Table），并且选中后给出中文提示并立即返回。
+   - 移动端城市选择（命中则必须）：若出现移动端“选择城市/切换城市/城市列表”页面或控件（例如 `/m/city` 或城市选择弹层）：
+     - 必须使用“城市列表 + 右侧字母索引条（A-Z）”的交互，点击字母可快速跳转到对应首字母分组
+     - 城市列表必须按首字母分组展示，并支持搜索
 3. 对“复合字段”的判定口径：字段名或说明中出现“起止/范围/地址/联系人/额度/资源+数量/城市+地点”等组合语义时，一律拆分。
 
 交互样式统一（必须）：
 1. 所有“新建/编辑/变更/补充材料/填写原因”等表单承载方式一律使用抽屉（Drawer），禁止使用弹窗（Modal）承载表单。
 2. Modal 仅允许用于“非表单”的确认与提示（如二次确认删除/取消/紧急叫停、提示失败原因），且内容必须足够短小。
 3. 若已有页面建议写了 Modal 新建：必须改为 Drawer，并确保路由与列表刷新逻辑不变。
+4. 抽屉表单提交后行为（必须）：
+   - 提交成功：必须关闭当前抽屉，并刷新列表/详情视图以反映最新数据（mock）
+   - 提交失败：必须保持抽屉打开，并在表单区域显示中文错误提示（完整句子）
 4. 禁止“页内新建/页内编辑”（必须）：
    - 不论是 CRUD、Steps 向导、流程（flow）链路页面，凡是“创建/新建/新增”一律通过“按钮 → 打开 Drawer → 填写表单 → 提交”完成
    - 禁止在页面内容区直接嵌入/展开完整表单来承载新建（例如在列表上方直接展开表单、在详情页内直接出现可编辑表单区等）
    - 禁止“表格内联新建/行内新增”（必须）：不允许通过 Editable Table 在列表中直接新增一行并编辑保存；新建必须始终在 Drawer 表单内完成（Table 行内仅允许用于明细录入，且必须发生在 Drawer 内）
+5. 非抽屉表单提交后行为（命中则必须）：
+   - 若存在非抽屉承载的表单页面（例如支付/签署/协议确认等）：提交成功后必须跳转到“提交成功页/结果页”（例如 `/payment/success` 或业务自定义 `*/success`），禁止停留在原表单页面。
 5. 审批相关操作禁止在表格内联编辑任何字段：
    - 表格行内只能出现“进入详情/打开审批抽屉”的按钮
    - 所有审批字段（意见/结果/资源分配/额度/执行人/生效时间等）必须在抽屉中完整填写
 
 日历视图生成要求（按需裁剪，命中则必须）：
 1. Calendar 规则必须按 `prompts/vspec_verify/prototype_calendar.md` 执行。
+2. 触发条件补充（必须）：
+   - 凡是需求/功能点涉及“时间浏览/排期/排班/课程表/日程/班次/预约/资源占用”等，必须生成日历视图（Web 端至少 1 个，必要时补齐移动端 `/m/calendar`）。
 
 快捷输入（1 对多输入，必须）：
 1. 触发条件：当原型页面存在 1 对多输入（例如：一次申请包含多段行程/多资源明细/多时间段预约/多参与人/多地点等）时，必须提供“快捷输入”能力，减少重复录入。
@@ -844,6 +887,7 @@ Steps（步骤条）使用要求（必须）：
 3. 动作按钮必须真实生效（不只是 UI）：
    - 点击后更新 mock 数据中的状态/关键字段，并刷新列表
    - 通过状态控制按钮可用性（例如只有待审批状态才显示“通过/驳回”）
+   - 状态限制必须在系统中可见且可解释：按钮禁用时必须展示中文原因提示（Tooltip/Help 文案），且为完整句子
 4. 审批环节必须支持“补充信息后再决策”（必须可演示）：
    - 点击“通过/驳回”不能直接改状态，必须先弹出抽屉填写必要信息后提交
    - 抽屉字段至少包含：审批意见（必填）、审批结果（通过/驳回）、可选附件/备注（按需）
@@ -859,10 +903,10 @@ Steps（步骤条）使用要求（必须）：
    - 审批驳回/取消/紧急叫停：该条目进入对应模块的记录页（或在原列表切换视图可查）
 6. 导航体验：
    - 每个关键动作完成后给出成功提示（message/notification）并自动跳转到下一步列表或详情页
+   - 所有提示/确认/错误文案必须与系统语言一致（中文），且使用完整句子；禁止出现英文提示或后台字段/单词直出
 
 页面跳转与展示模式（必须）：
-1. 页面默认以“全屏业务页面”方式展示（带 Header + Menu 的完整布局）。
-2. 仅在“手机模拟器预览”模式下，才将页面渲染到手机框容器内；该模式应可由 Header 切换（例如按钮/开关）。
+1. 按 `prompts/vspec_verify/prototype_layout.md` 执行（默认 Web 三段式；手机模拟器预览模式由 Header 控制切换）。
 
 场景困难与兜底（必须）：
 1. 以 `/specs/background/scenarios.md` 为覆盖基线：对每类关键用户操作，补齐“可能遇到的困难 + UI 兜底路径”，确保原型可演示异常处理，不只演示 happy path。

package/skills/visual-spec-skill/prompts/vspec_verify/prototype_auth.md

@@ -0,0 +1,58 @@
+你是一名资深前端原型工程师。你的任务是：在“原型工程（/specs/prototypes/）”中补齐“本系统账号体系（非 SSO）”相关页面（Web + Mobile），用于演示登录、创建账号、忘记密码、修改密码与会话控制的最小闭环。
+
+触发条件（命中则必须执行；否则跳过）：
+- `/specs/background/dependencies.md` 未体现 SSO/OIDC/LDAP/IDaaS 等统一登录接入
+- 且 functions 中存在登录/账号体系相关功能，或需求语义包含“登录/账号/密码/找回/重置/注册/创建账号”等
+
+路由（必须稳定可访问）：
+1. Web：
+   - 登录：`/login`
+   - 创建账号：`/login/register`
+   - 忘记密码：`/login/forgot`
+   - 重置密码：`/login/reset`（由忘记密码流程进入，可带 token mock）
+   - 修改密码：`/login/change-password`（仅登录后可访问）
+2. Mobile（前缀必须为 `/m/*`）：
+   - 登录：`/m/login`
+   - 创建账号：`/m/login/register`
+   - 忘记密码：`/m/login/forgot`
+   - 重置密码：`/m/login/reset`
+   - 修改密码：`/m/login/change-password`
+
+会话与拦截（必须）：
+1. 必须在 mock 中提供 session（例如 `mock.session`）：
+   - 字段至少包含：`user_id/user_name/role_id/role_name/org_id/org_name`
+   - 必须额外包含：`role_terminal`（Web/手机App/小程序/其他），用于登录成功后的跳转与入口控制
+2. 路由访问控制（必须）：
+   - 未登录访问任意业务路由（非 `/login*`、`/m/login*`）：必须引导到对应端登录页，并在登录成功后回跳
+3. 登录成功后必须进入应用首页（`/` 或 `/landing`），并渲染完整的 Web 三段式布局（Header + Menu + 内容区）。
+
+页面要求（必须）：
+1. 登录页（Web + Mobile）：
+   - 必须提供“角色下拉框”（Select），用于快速选择要以哪个角色进入系统（至少提供 3 个角色选项；来自 roles.md，若不足 3 个则尽量覆盖全部）
+   - 支持“选择账号”或“账号+密码”两种 mock 登录方式之一（按需求裁剪但必须可用）
+   - 登录提交成功后必须根据所选角色的终端跳转：
+     - 若角色终端为 Web：跳转到 `/` 或 `/landing`
+     - 若角色终端为 手机App/小程序：跳转到对应移动端首页（`/m/...`，最少为 `/m/list` 或 `/m/dashboard` 其一），并确保该端页面可访问
+   - 提供入口：创建账号、忘记密码
+   - 提示文案必须中文化且为完整句子
+2. 创建账号（Web + Mobile）：
+   - 字段最小集：账号/手机号其一 + 姓名 + 密码 + 确认密码
+   - 提交成功后：自动登录或跳转回登录页（二选一，但必须明确并可演示）
+3. 忘记密码 → 重置密码（Web + Mobile）：
+   - 忘记密码页：输入手机号/邮箱并触发“发送验证码/重置链接”（mock）
+   - 重置密码页：输入新密码/确认密码，提交成功后跳转到登录页并提示“密码已更新，请重新登录。”
+4. 修改密码（Web + Mobile）：
+   - 字段：旧密码、新密码、确认密码
+   - 提交成功后：必须提示“密码修改成功。”并退出当前会话，跳转到登录页
+
+与 Header/Avatar 的联动（必须）：
+1. Header 右上角 Avatar 下拉必须提供：
+   - 个人中心（跳转 `/profile`）
+   - 我的工作台（跳转 `/`）
+   - 修改密码（跳转 `/login/change-password`）
+   - 退出登录（清空 session 并跳转 `/login`）
+2. Avatar 下拉中的“切换账号/切换角色”仍需保留，用于演示 RBAC 与数据权限差异。
+
+输出要求：
+1. 仅在既有原型工程上做增量修改（新增页面/路由/mock/拦截逻辑）。
+2. 禁止把登录页当作业务页放进左侧菜单；业务页必须通过登录后进入并带 Header。

package/skills/visual-spec-skill/prompts/vspec_verify/prototype_crud.md

@@ -31,6 +31,11 @@
    - Tool pages & Agreement：按 `prompts/vspec_verify/prototype_tool_pages.md` 执行
 
 CRUD 页面规则（必须）：
+0. 基础数据/主数据覆盖（必须）：
+   - 必须从 `/specs/models/*.md` 中识别“基础数据/主数据”（维护对象）清单，并为每个对象生成可运行的 CRUD 页面（至少列表 + 详情 + Drawer 新建/编辑）
+   - 典型示例：排课类业务必须具备课程/讲师/学员等基础数据；若缺少则业务流程无法演示
+   - 若主数据存在 1:N 从属对象（例如题库 → 考题、课程 → 课时、商品 → SKU）：必须补齐从属对象的维护入口（父对象详情页 Tab/子列表进入），并具备子对象 CRUD（Drawer）
+   - 若 functions 未提供对应 CRUD 条目：必须在首页“设置/说明”区域输出可见错误提示，并采用最保守策略补齐路由（默认 `端=Web` + 推断入口为 `/admin/master-data/<entity_slug>`）
 1. 每个 CRUD 功能点至少对应：列表页 + 详情页；新建/编辑用 Drawer 完成，不单独开“新建路由”承载表单。
 2. 列表页必须包含：
    - 查询表单（至少 2 个字段，按模型裁剪）

package/skills/visual-spec-skill/prompts/vspec_verify/prototype_dashboard.md

@@ -39,6 +39,9 @@
    - 必须体现角色差异：每个核心角色至少有 1 个“独有图表”或“同图表不同口径/筛选”的差异化呈现
    - 图表必须有筛选条件（Form + 查询按钮或控件联动），至少包含：时间范围（RangePicker 必须）+ 状态/类型（Select）其一
    - 图表数据必须来自 mock 聚合，且随筛选变化而变化（不要求复杂，但要可演示）
+   - 图表选择（必须）：
+     - 必须根据 functions/models/stakeholders 识别并输出“图表清单”，每个图表必须明确：业务含义、指标口径、维度（按日/按状态/按角色/按组织等）、默认筛选、可 drill-down 的跳转路径
+     - 不允许只放通用示例图表；每个图表必须能在业务上解释“为什么需要”
 3. 我的待办（必须）：
    - Table 展示待办任务列表（任务名/单号/发起人/当前节点/到期时间/状态/操作）
    - 行内操作：进入详情、快速通过/驳回（如适用）、开始/结束（如适用）

package/skills/visual-spec-skill/prompts/vspec_verify/prototype_layout.md

@@ -0,0 +1,33 @@
+你是一名资深前端原型工程师。你的任务是：为“原型工程（/specs/prototypes/）”定义统一的页面布局与导航组织规则，确保所有页面风格一致、入口清晰、可评审。
+
+Web 全局布局（必须）：
+1. 所有 Web 业务页面必须使用三段式布局：顶部 Header + 左侧 Menu + 内容区；禁止出现“无 Header 的业务页面”。
+2. Header（必须按布局落位）：
+   - 左侧：Logo（点击回到 `/`）
+   - 右侧：Avatar（用户头像/姓名缩略）作为唯一的账号/角色切换入口
+     - 点击 Avatar 打开下拉菜单（Dropdown）：至少包含“切换账号”“切换角色”“个人中心”“我的工作台”“退出”
+     - “切换账号”：弹出抽屉（Drawer），展示可选账号列表（mock），切换后更新 session 的 `user_id/user_name/role_id/role_name/org_id/org_name`
+     - “切换角色”：弹出抽屉（Drawer）或在 Dropdown 内二级菜单，展示当前账号可切换角色（mock），切换后无需刷新页面立即生效
+   - 可选：全局搜索与常用入口可放在 Header 中部区域，但不得破坏“左 Logo、右 Avatar”的基本结构
+3. 左侧 Menu（必须）：
+   - 必须按“分类→模块→页面”分组（至少 3 组），并在组内按模块聚合页面入口；不允许所有 Menu.Item 平铺、散放
+   - 组内入口规则：优先以“列表页/工作台”作为模块入口；详情/操作页不得作为独立菜单项
+   - 若使用 Ant Design Vue：必须使用 SubMenu/ItemGroup（或等价能力）实现可折叠分组
+   - `/tools/*`、`/profile` 等工具/个人中心入口不得出现在左侧菜单（入口必须来自 Header 下拉或工具箱页面约定）
+4. 主内容区：router-view 渲染页面。
+
+适配手机/窄屏（必须）：
+1. 左侧 Menu 在窄屏时默认收起（或变为抽屉式侧边栏），Header 保留。
+2. 提供“手机模拟器预览”模式：在桌面端以手机框（固定宽度 + 圆角 + 阴影）展示移动端页面内容。
+
+移动端布局（必须）：
+1. 移动端页面必须独立路由前缀：`/m/*`，并使用移动端布局（顶部简化 Header + 内容区 +（按需）底部吸底操作栏/TabBar），不复用后台三段式布局。
+   - 底部 TabBar（必须）：只要原型生成了 2 个及以上移动端页面，就必须实现底部 TabBar，并按实际移动端功能分布放置 icon + 文案（示例：首页/任务/消息/我的）；当前 Tab 高亮必须随路由变化。
+   - 布局固定规则（必须）：TabBar 必须 fixed 吸底；中间内容区必须可滚动（Scroll），不得因为 TabBar 导致内容被遮挡；建议通过 `padding-bottom` 为内容区预留 TabBar 高度。
+2. Web 端左侧菜单不展示移动端专属页面入口；Web 端对应动作按钮必须置灰并提示“请在手机端操作”，并提供一个“打开手机端页面”的入口（可复制链接或跳转）。
+
+场景验证入口（必须禁止）：
+1. 生成 `scenario.html`（或同等场景验证页）时，不允许在原型中任何位置提供入口：
+   - 不允许出现在左侧 Menu、Header 下拉、工具箱、工作台卡片、落地页入口、任何业务页面的按钮/链接中。
+2. 生成 `entries.html`（全功能入口页）时，同样不允许在原型中任何位置提供入口：
+   - 不允许出现在左侧 Menu、Header 下拉、工具箱、工作台卡片、落地页入口、任何业务页面的按钮/链接中。

package/skills/visual-spec-skill/prompts/vspec_verify/prototype_order.md

@@ -27,6 +27,9 @@
    - 去支付（仅待支付可用）
    - 取消订单（待支付可用，Popconfirm）
    - 退款（仅已支付可用，Drawer 表单占位）
+4. 退款后状态展示（必须）：
+   - 发生退款后，订单必须仍保留在订单列表中，不允许从订单列表消失。
+   - 订单状态必须标记为“已退款”（Tag），并在详情页同步展示退款信息（退款时间/退款金额/退款单号 mock）。
 
 订单详情页（必须）：
 1. 基础信息（Descriptions）：订单号、用户、状态、创建时间、支付时间（如有）、支付方式（如有）。
@@ -37,9 +40,13 @@
    - 去支付（待支付）
    - 申请退款（已支付）
    - 查看支付记录（mock）
+5. 发票（命中则必须）：
+   - 若需求/功能清单/模型命中“发票/开票/电子发票/抬头/税号/发票下载”等：必须提供发票能力入口：
+     - 订单列表 Action 或订单详情操作区提供“申请开票/查看发票”按钮（按状态控制可用性）
+     - 发票信息表单用 Drawer 承载，字段至少包含：抬头类型（个人/企业）、抬头名称、税号（企业必填）、邮箱、发票内容/类目（Select）
+     - 提交成功后：订单详情展示发票状态（未开票/开票中/已开票），并提供“下载/预览（PDF 占位）”
 
 数据要求（必须）：
 1. 数据来自 mock（例如 `mock.orders`、`mock.payments`），字段至少包含：
    - orderId、items、amount、discount、discountDetails、shipping、payable、status、payStatus、createdAt、paidAt、user
 2. 与支付页联动：从订单详情进入 `/m/payment?orderId=...` 后，支付成功需回写订单 payStatus/paidAt，并在返回订单详情与列表时可见变化。
-

package/skills/visual-spec-skill/prompts/vspec_verify/prototype_promotion.md

@@ -8,6 +8,10 @@
 1. Web（运营/配置类）：
    - 优惠券/促销列表：`/promotions`
    - 优惠券/促销详情：`/promotions/:id`（至少保证 `/promotions/1` 可访问）
+2. Mobile（用户端领取/券包，命中“发放/领取/领券/券包/我的优惠券”等则必须）：
+   - 领券中心：`/m/coupons`（展示可领取/可用券；支持按有效期/适用范围筛选）
+   - 我的优惠券：`/m/coupons/wallet`（已领取列表；展示状态：可用/已用/已过期）
+   - 领券/使用闭环：在券卡片上提供“领取/去使用”按钮（mock 生效），并能跳转回购物车/订单等使用场景
 2. 必须与交易链路联动：
    - 购物车与支付页必须提供“选择优惠券/查看优惠明细”入口，并确保选择后金额实时变化（写回 mock）。
 
@@ -48,6 +52,10 @@
 1. mock 数据至少包含：
    - `mock.promotions`：优惠规则列表
    - `mock.couponWallet`：当前用户可领取/已领取/可用券列表（可简化）
+2. 若存在发放/领取场景，必须区分：
+   - 可领取池（例如 `mock.couponPool` 或等价字段）：用于 `/m/coupons` 展示
+   - 我的券包（`mock.couponWallet`）：用于 `/m/coupons/wallet` 展示
+   - 领取动作必须把券从“可领取池”写入“我的券包”，并在购物车/支付选择器中立即可见
 2. 字段至少包含：
    - id、title、type、value、thresholdAmount、stackable、validFrom、validTo、eligibleSegments、status
    - 商品范围：`productScope`（all/category/productIds）+（可选）`productCategories`/`productIds`

package/skills/visual-spec-skill/prompts/vspec_verify/prototype_quiz.md

@@ -14,28 +14,33 @@
    - 多选题（Checkbox）
    - 判断题（是/否）
    - 可选加分项：填空/简答（Textarea，占位即可但必须可输入并保存）
-2. 页面结构（Web）：
-   - 左侧/顶部：题目导航（题号 + 已答/未答状态；支持点击跳转）
+2. 选项呈现（必须）：
+   - 选择题选项必须竖向排列（每个选项独占一行），禁止横向平铺导致阅读困难
+   - 选择题选项必须带字母编号：A/B/C/D…（显示为 `A.` `B.` `C.` `D.`），并与选项文本一起作为可点击区域
+   - Web 与 Mobile 必须一致
+3. 页面结构（Web）：
+   - 顶部信息区（必须）：试卷标题 + 总题目数 + 总分 + 限时/倒计时（mock）+ 当前进度（如 3/20）
+   - 左侧/顶部：题目导航（必须展示全部题目序号列表 + 状态：已答/未答/标记；支持点击跳转）
    - 主体：题干 + 选项/输入区
    - 底部：上一题/下一题、标记（收藏/疑问）按钮、交卷按钮
-3. 页面结构（Mobile）：
+4. 页面结构（Mobile）：
    - 顶部栏：返回 + 标题“测评”
    - 主体：题干 + 选项/输入区
-   - 顶部或底部：题号进度（如“3/20”）+ “题号面板”入口（BottomSheet）
+   - 顶部或底部：题号进度（如“3/20”）+ 总题目数 + 倒计时（mock）+ “题号面板”入口（BottomSheet）
    - 底部吸底操作栏：上一题/下一题 + 交卷（Primary）
-4. 关键交互（必须可演示）：
+5. 关键交互（必须可演示）：
    - 作答后自动保存到 mock（切换题目后答案保留）
    - 支持“标记题目”（用于回看），在题号导航中有明显标识
    - 交卷前弹出确认（Modal/Drawer）
    - 支持“未答题提示”：交卷时若存在未答题，需提示未答数量，并可跳转到第一道未答题
-5. 状态与反馈（必须）：
+6. 状态与反馈（必须）：
    - 加载态（Skeleton/Spin）
    - 交卷提交中 Loading，防重复提交
    - 错误态 + 重试（可与 config 失败注入联动或本页开关）
 
 结果页（必须）：
 1. 总览区：
-   - 得分/正确率/用时（mock）
+   - 得分/正确率/用时/总题目数（mock）
    - 完成状态（如“已完成/未完成”）
 2. 题目复盘：
    - 列表展示每题对错（Tag 颜色统一：对=绿，错=红，未答=灰）
@@ -56,3 +61,17 @@
 入口要求（必须）：
 1. Web：必须能从左侧菜单或 Landing 快捷入口进入（按原型整体导航约定选择其一，需稳定可访问）。
 2. Mobile：移动端 Landing 金刚区必须提供“做题/测评”入口，跳转到 `/m/quiz`。
+
+考试发布与进场（命中则必须）：
+1. 若需求语义包含“考试计划/考试通知/发布/报名/准考证/考试时间范围/考场/进入考场”等：
+   - 必须体现“考试通知 → 进入考场 → 开始考试”的入口链路（可在 `/quiz` 内用步骤态实现，不强制新增路由）
+   - 必须按时间窗口控制“进入考场/开始考试”按钮可用性：未到开始时间置灰并提示；超过结束时间禁止进入并提示
+2. 若存在“发布需审批/计划需审批”语义：必须体现状态流转（草稿→待审批→已发布）与审批入口：
+   - 审批入口必须来自列表 Action 的“审批”按钮，点击后用 Drawer 填写字段提交
+   - 审批字段至少包含：审批结果（通过/驳回）、审批意见（必填）、生效时间范围（开始/结束，若业务适用）
+
+学员端成绩/证书/补考（命中则必须）：
+1. 若需求语义包含“成绩/证书/补考/不及格重考/缴费补考”等：
+   - 必须提供“我的考试/我的成绩”入口（可放在 `/profile` 内的 Tab 或列表），可查看历史成绩与状态（通过/不及格/待补考）
+   - 通过后必须展示证书入口，并在证书详情中提供“证书模板预览”（PDF 或截图图片）；模板文件必须来自输入材料（例如 `/docs/templates/` 或 `/docs/assets/`），禁止纯前端假画模板
+   - 不及格时必须提供“补考/再次参加”入口；若业务要求补考缴费，则补考前必须走订单/支付占位流程

package/skills/visual-spec-skill/prompts/vspec_verify/prototype_survey.md

@@ -0,0 +1,67 @@
+你是一名资深前端原型工程师。你的任务是：为“原型工程（/specs/prototypes/）”补齐调查问卷（Survey）相关页面（Web 管理端 + Mobile 填写端），用于演示“配置问卷 → 发布/投放 → 用户填写提交 → 回收与统计”的闭环。
+
+路由（必须稳定可访问）：
+1. Web（管理端）：
+   - 问卷列表：`/surveys`
+   - 问卷详情/编辑：`/surveys/:id`（至少保证 `/surveys/1` 可访问）
+   - 回收数据/答卷列表：`/surveys/:id/responses`（至少保证 `/surveys/1/responses` 可访问）
+2. Mobile（前缀必须为 `/m/*`）：
+   - 问卷列表：`/m/surveys`
+   - 填写问卷：`/m/surveys/:id`（至少保证 `/m/surveys/1` 可访问）
+   - 提交结果/回执：`/m/surveys/:id/result`（至少保证 `/m/surveys/1/result` 可访问）
+
+页面闭环（必须）：
+1. Web 管理端（必须）：
+   - `/surveys`：
+     - 查询条件区（至少 2 个条件：状态/创建人/时间范围其二）
+     - Table 列表（状态 Tag：草稿/待审批/已发布/已下线/已结束；操作：查看/编辑/发布/下线/复制链接/查看回收数据/删除）
+     - 新建：列表工具栏按钮打开 Drawer 完成创建（禁止独立新建路由）
+   - `/surveys/:id`：
+     - 基本信息：标题、说明、开始/结束时间窗口、是否匿名、是否允许重复提交、是否允许保存草稿
+     - 题目配置（必须完备）：
+       - 支持题型至少 6 种：单选/多选/判断/填空/文本长答/评分（1-5 星或 1-10 分）
+       - 可选增强：矩阵题（行列）、上传题（mock 占位即可但必须产生附件记录）
+       - 每题必须支持：是否必填、题目说明（可选）、选项管理（增删改、顺序调整）
+       - 题目顺序必须可拖拽调整（mock 即可但必须有可见交互）
+     - 发布与投放：
+       - 发布前必须进行校验：至少 1 题；必填题合法；时间窗口合法
+       - 发布后必须展示“投放链接/二维码”（二维码可 mock）并提供复制按钮
+   - `/surveys/:id/responses`：
+     - 答卷列表（查询条件区：提交时间范围/是否完成/渠道其二；Table：提交人/提交时间/用时/状态）
+     - 统计概览（至少 3 个图表/统计卡片）：回收量、完成率、题目分布（单选/多选/评分用图表；文本题用关键词/最近回答列表）
+     - 导出（占位即可但必须基于当前查询条件）
+2. Mobile 填写端（必须）：
+   - `/m/surveys`：
+     - 展示“可填写/已提交/已结束”分组或 Tab
+     - 卡片含标题、时间窗口、状态 Tag；点击进入填写
+   - `/m/surveys/:id`：
+     - 顶部必须显示：问卷标题 + 进度（如 3/20）+（可选）倒计时（当存在结束时间窗口时）
+     - 必须提供“题目序号列表与状态”（BottomSheet/Drawer）：已答/未答/标记
+     - 题目渲染必须适配手机：选项竖向排列；选择题选项带 A/B/C/D 编号
+     - 交互：
+       - 答题自动保存草稿（写回 mock）
+       - 提交前必须确认（Drawer/Modal），并提示未答数量；允许跳转到第一道未答题
+   - `/m/surveys/:id/result`：
+     - 提交成功回执（提交时间/用时/提交编号 mock）
+     - 若业务允许查看结果：展示“我的答卷摘要”（评分题汇总、选择题分布占位）；否则仅提示“已提交”
+
+审批与生效（命中则必须）：
+1. 若 functions 或 details 中出现“问卷发布/配置变更需审批后生效/发布”语义：
+   - Web 必须体现状态：草稿 → 待审批 → 已发布
+   - 必须提供审批入口（列表 Action 的“审批”按钮 → Drawer 填字段提交），字段至少包含：
+     - 审批结果（通过/驳回）
+     - 审批意见（必填）
+     - 生效时间范围（开始/结束，若业务适用）
+
+RBAC 与数据权限（必须）：
+1. Web 问卷管理仅对“运营/管理员”角色可见；普通用户角色不可见（或置灰并提示无权限）。
+2. Mobile 问卷填写仅对“填写者/学员/用户”角色可见。
+3. 回收数据页必须按 data_permission 过滤（至少体现：仅可看自己创建的问卷 or 所属组织范围）。
+
+数据要求（必须）：
+1. 数据来自 mock（例如 `mock.surveys`），至少包含：
+   - `surveys`：问卷列表（id、title、status、startAt、endAt、createdBy、createdAt）
+   - `surveyDetail`：问卷详情（questions 数组）
+   - `responses`：答卷列表（id、surveyId、userId、submittedAt、timeUsedSeconds、answers）
+2. Web 与 Mobile 必须复用同一份问卷/答卷数据源（同一 surveyId 联动）。
+3. 文案必须中文化（mock 中文即可）。

package/skills/visual-spec-skill/prompts/vspec_verify/prototype_tool_pages.md

@@ -60,6 +60,14 @@
    - 当前用户 session 展示（user_id/user_name/role/org 等）
    - 偏好设置占位（语言/主题/通知偏好）
    - “退出/切换身份”入口（不要求真实鉴权，但要影响 session mock）
+2. 若系统涉及“成绩/证书/成就/勋章/排行/学习记录/考试记录”等用户资产：必须在 `/profile` 内提供对应 Tab/列表入口，并具备查询条件区：
+   - 成绩：成绩列表（时间范围/考试类型/状态等至少 2 个条件）→ 成绩详情/复盘入口
+   - 证书：证书列表（时间范围/证书类型/状态等至少 2 个条件）→ 证书详情/下载占位
+   - 成就：成就/徽章列表（类型/时间范围等至少 2 个条件）→ 详情抽屉
+3. 证书/成绩单模板（命中则必须）：
+   - 若出现证书/成绩单相关页面或功能：必须在证书详情或成绩详情中提供“模板预览”（PDF 预览或图片预览）
+   - 模板文件必须来自输入材料（例如 `/docs/templates/` 或 `/docs/assets/`）；禁止用纯前端随便画一张假模板
+   - 若未提供模板文件：必须在页面中给出可见阻断提示（中文完整句子），并明确需要补充的文件类型（PDF/PNG/JPG）与建议存放目录
 
 协议确认（Agreement）生成要求（必须）：
 1. `/agreement/confirm` 页面至少包含：

package/skills/visual-spec-skill/prompts/vspec_verify/validation.md

@@ -1,4 +1,4 @@
-你是一名资深前端原型工程师。你的任务是：生成一个“场景确认”用的网页，用于业务方逐条确认场景列表；必须单独生成一个 `scenario.html`，用于访问与串联其他页面。
+你是一名资深前端原型工程师。你的任务是：生成一个“场景确认”用的网页，用于业务方逐条确认场景列表；必须单独生成一个 `scenario.html`，用于访问与串联其他页面（包含移动端页面入口时也应能从此页进入）。
 
 输入信息包含：
 - 场景列表（/specs/background/scenarios.md）
@@ -41,6 +41,8 @@
 3. 缩略图实现方式（必须）：
    - 使用 `Card + 空白占位缩略图`（来自 `src/assets` 的通用占位图），并在卡片标题展示页面名称与路由路径
    - 每张卡片必须提供“打开页面”按钮：点击后跳转到该路由的正常页面（全屏内容，带完整 Header + Menu），禁止跳到嵌入式/iframe 页面
+4. 移动端入口（命中则必须）：
+   - 若存在移动端页面（`/m/*`），必须在场景详情区为相关节点提供“打开移动端页面”入口（跳转到对应 `/m/*` 路由），方便评审直接访问移动端页面。
 
 输出与写入要求：
 1. 将页面代码与工程改动写入到 `/specs/prototypes/` 目录下的原型工程中