visual-spec 0.1.2 → 0.1.3

package/skills/visual-spec-skill/prompts/vspec_new/details_pre_post.md

@@ -10,36 +10,62 @@
 分析范围与输出控制：
 - 先生成“节点清单”（去重并按主流程出现顺序排序）；再按节点逐条分析
 - 默认对所有主流程节点做详解；对明显罕见/仅异常路径出现的节点可简要
-- 审批节点不得跳过：只要在 `/specs/flows/*.puml` 或 `/specs/background/scenarios.md` 中出现 approve/审批（含同义节点），必须输出该节点的 `node_*_approve/pre_post.md`（信息不足可用最小假设补齐，并标注“假设”）
-- 每个节点文件控制在 18 到 45 行；罕见节点可简要至 6 到 12 行
+- 审批节点不得跳过：只要在 `/specs/flows/*.puml` 或 `/specs/background/scenarios.md` 中出现 approve/审批（含同义节点），必须输出该节点的 `??_approve_approve/pre_post.md`（信息不足可用最小假设补齐，并标注“假设”）
+- 多流程拆分（必须）：
+  - 若同一节点出现在多个流程/多个业务域（例如报名/教学/排班/考试/发证等），必须按“流程”分别输出 pre/post；禁止把不同流程的前置/后置合并成一段泛化描述
+  - 每个节点文件可以包含多个“流程小节”；主流程相关的小节写详，罕见流程小节可简要，但不得省略
+- 每个节点文件控制在 24 到 80 行；罕见节点可简要至 8 到 18 行
 
 闭环思维（Pre/Post）细化要求（必须）：
 1. 前置条件（pre）必须覆盖：
    - 数据前置：哪些主数据/基础数据必须存在（例如组织、人员、资源、客户、供应商、合同、额度等）
-   - 数据来源：手工录入/Excel 导入/外部系统同步（明确来源优先级与兜底方案）
+   - 数据来源：手工录入/Excel 导入/外部系统同步（明确来源优先级与兜底方案）；若为本系统内维护，必须明确对应的主数据/配置维护入口（CRUD/配置管理）；若为外部系统同步，则可不做 CRUD 但必须明确同步触发与兜底
    - 权限前置：谁能创建/提交/审批/执行（引用 roles），以及是否需要提前授权/开通权限点
    - 配置前置：字典/枚举、审批流配置、时间窗口、SLA、通知模板、外部系统鉴权配置
+   - 若涉及支付/退款：必须补齐支付参数配置（支付通道/商户号/回调地址/签名校验占位/风控策略/退款策略/对账周期等）
    - 环境前置：外部系统可用性/接口连通性（必要时给出最小可运行假设，并标注“假设”）
 2. 后置处理（post）必须覆盖：
    - 状态落地：状态机变更、轨迹/流水记录、关键字段写回（计划 vs 实际字段分别写入）
    - 审计留痕：哪些关键操作需要留痕（只描述触发点与最小字段）
    - 通知与协同：通知谁、何时通知、通知内容摘要、失败兜底
    - 外部同步：需要推送/拉取/对账/回写的外部系统交互（仅描述触发点与方向）
+   - 若涉及支付/退款：必须写清支付回调/退款回调/对账文件或对账接口的触发点、数据方向、幂等与失败补偿/人工兜底
    - 归档/统计：是否进入报表、归档周期、数据留存要求（如未知写“待确认”）
 
 输出与写入要求：
 1. 输出目录：`/specs/background/scenario_details/`
 2. 如果目录不存在，请先创建
 3. 节点目录命名规则（必须）：
-   - `node_<序号两位>_<node_slug>`，例如：`node_01_apply`、`node_02_approve`、`node_03_execute_start`
-   - `node_slug` 优先使用场景节点名的英文键（apply/approve/cancel/change/execute-start/execute-end）；若为中文节点名则转成可读的拼音或英文短语；仍无法稳定命名时用 `node`
-4. 对每个节点，写入一个文件：`/specs/background/scenario_details/<node_key>/pre_post.md`
+   - 目录名必须为：`<序号两位>_<模块>_<节点>`，例如：`01_apply_apply`、`02_approve_approve`、`03_execute_execute_start`
+   - `<节点>`：优先使用场景节点名的英文键（apply/approve/cancel/change/execute-start/execute-end）；若为中文节点名则转成可读的拼音或英文短语；仍无法稳定命名时用 `node`
+   - `<模块>`：由节点归类得到，用于分组而不是业务模块名，口径固定如下（必须按此映射）：
+     - apply → apply
+     - approve → approve
+     - execute-start/execute-end → execute
+     - change → change
+     - cancel → cancel
+     - abort → abort
+     - crud-* → crud
+     - quiz-* → quiz
+     - shop-* → shop
+     - 其他 → misc
+4. 对每个节点，写入一个文件：`/specs/background/scenario_details/<dir_key>/pre_post.md`
 5. `pre_post.md` 文件结构固定如下（必须）：
 
 # 节点：<节点名>
-所在流程/前后节点：<本节点所在流程名（如有）>；<前序节点> → <本节点> → <后续节点>
+## 所在流程/前后节点（必须按流程拆分）
+- 流程：<流程 A 名称或业务域>；<前序节点> → <本节点> → <后续节点>
+- 流程：<流程 B 名称或业务域>；<前序节点> → <本节点> → <后续节点>（如适用）
 
-## 闭环思维（Pre/Post）
+## 闭环思维（Pre/Post）（必须按流程拆分）
+
+### 流程：<流程 A 名称或业务域>
+- pre：<按本文件要求列出要点>
+- post：<按本文件要求列出要点>
+
+### 流程：<流程 B 名称或业务域>（如适用）
+- pre：<按本文件要求列出要点>
+- post：<按本文件要求列出要点>
 
 ## 需要确认的问题（如有）
 - <问题 1>

package/skills/visual-spec-skill/prompts/vspec_new/details_symmetry.md

@@ -12,7 +12,7 @@
 - 主流程节点：至少覆盖 5 类对称操作；罕见节点：覆盖关键对称操作即可
 
 产出方式（必须）：
-1. 遍历 `/specs/background/scenario_details/` 下的所有节点目录（`node_*/`），逐节点生成对应的 `symmetry.md`。
+1. 遍历 `/specs/background/scenario_details/` 下的所有节点目录（按目录名排序），逐节点生成对应的 `symmetry.md`。
 2. 对称操作必须与该节点的状态与时点一致（例如 apply/approve/execute-start/execute-end 前后），并与角色权限一致。
 3. 本小节不允许留空：信息不足时必须基于最小合理闭环补齐（假设），至少覆盖 cancel/change/retry 三类；仅在确实与该节点无关时才写 `Not Applicable：<原因>`。
 
@@ -35,7 +35,7 @@
    - 对称操作必须明确占用释放、冲突重新判定、以及是否需要重新审批
 
 输出与写入要求：
-1. 对每个节点目录写入：`/specs/background/scenario_details/<node_key>/symmetry.md`
+1. 对每个节点目录写入：`/specs/background/scenario_details/<dir_key>/symmetry.md`
 2. 文件结构固定如下（必须）：
 
 # 节点：<节点名>

package/skills/visual-spec-skill/prompts/vspec_new/details_variations.md

@@ -13,7 +13,7 @@
 - 每个维度必须给出“典型取值（2-5 个）”与“差异处理”
 
 产出方式（必须）：
-1. 遍历 `/specs/background/scenario_details/` 下的所有节点目录（`node_*/`），逐节点生成对应的 `variations.md`。
+1. 遍历 `/specs/background/scenario_details/` 下的所有节点目录（按目录名排序），逐节点生成对应的 `variations.md`。
 2. 每个节点最多列 5 个分支维度（宁可少而关键），并与该节点的 Pre/Post、角色权限、场景链条一致。
 3. 本小节不允许留空：信息不足时必须给出“最可能发生的分支维度 + 默认处理”，并用（假设）标注；仅在确实与该节点无关时才写 `Not Applicable：<原因>`。
 
@@ -40,7 +40,7 @@
    - 能映射到 models：若分支需要新增字段/枚举值/状态值，标注“建议字段/枚举（待模型阶段确认）”
 
 输出与写入要求：
-1. 对每个节点目录写入：`/specs/background/scenario_details/<node_key>/variations.md`
+1. 对每个节点目录写入：`/specs/background/scenario_details/<dir_key>/variations.md`
 2. 文件结构固定如下（必须）：
 
 # 节点：<节点名>

package/skills/visual-spec-skill/prompts/vspec_new/functions.md

@@ -48,6 +48,7 @@
      - 受理/分派/排队：进入处理队列、分派执行人/资源、等待窗口期
      - 核验/验收/确认：执行完成后的验收、复核、签收、回访
      - 结算/对账/开票：涉及费用计算、对账差异、开票与归档
+     - 支付/退款：支付发起、支付结果回调、失败重试/超时关闭、退款发起/审批（如适用）、退款回调、对账差异与补偿
      - 复议/申诉/二次审批：对审批结果提出复议、补充材料后重新审核
    - 若识别到新增阶段：
      - 必须在 `core.md` 中显式体现对应阶段的入口与关键能力（列表/详情/关键动作/状态流转/通知与留痕）
@@ -58,6 +59,10 @@
    - 对每个对象，检查 functions 是否覆盖其全生命周期需要的：
      - 处理功能：创建/发放/审批/启用停用/使用核销/消耗与结算/延期续期/失效注销/丢失补发/归档查询与审计（按对象裁剪）
      - 支持功能：查询、筛选、导入导出、对账汇总、通知提醒、权限与脱敏、操作日志与留痕、异常兜底
+   - 若存在支付/退款语义（订单/结算/支付/退款/对账等）：必须补齐支付闭环能力（至少在 core.md 中体现）：
+     - 支付：支付下单/发起、支付渠道选择/配置、支付回调处理（幂等/签名校验）、支付失败重试/超时关闭、支付结果查询
+     - 退款：退款申请/审批（如适用）、退款执行/回调处理、部分退款口径（如适用）、退款失败重试/人工兜底
+     - 对账：对账任务（端=Job）或对账页面（端=Web）之一必须具备，包含差异识别与修复入口
    - 若发现生命周期不完整：必须在输出前补全 `core.md`（或对应外部系统 functions 文件）的功能行，直到对象生命周期闭环
    - 示例口径（用于你自检，不要生搬硬套）：
      - 有“优惠”能力：应覆盖优惠创建/配置、审批（如需要）、发放/绑定、使用/核销、延续（延期/续期/扩展额度）、失去（失效/作废/撤销/回收）、归档与审计
@@ -95,6 +100,7 @@
    - 基础数据 CRUD 自检（必须）：
      - 在 functions 初版生成完成后，必须对“基础数据/主数据”（能影响业务运行、需要日常维护的对象，如组织人员、门店、商品、价格、规则、字典、渠道、支付方式、权限角色等）逐一检查是否存在可维护入口
      - 不允许出现“业务流程依赖该基础数据”但 `core.md` 中没有任何维护能力的情况；若缺失，必须补齐对应基础数据的 CRUD（通常为 `端=Web；入口=/...；`）或明确其来自外部系统并补齐对接能力
+     - 当你在 `/specs/background/scenario_details/` 的节点 pre/post 中识别到“数据前置/配置前置”依赖某主数据/配置数据时，必须确保 functions 中存在该对象的维护入口（CRUD/配置管理）或明确其来自外部系统同步（可不做 CRUD 但必须有对接能力）
    - 完整性自检：
      - 不允许出现“依赖某配置/某数据”但 functions 中没有任何维护入口/对接能力的情况
      - 若识别到缺口：必须补全 functions 后再输出
@@ -166,3 +172,9 @@ Dashboard/工作台分析（必须）：
    - 管理员/调度：全量概览/资源占用/冲突与告警/快速分派
 4. 若 roles.md 中存在“更适合手机操作”的角色（司机/外勤/执行等），必须额外输出对应移动端 Dashboard/任务入口行：
    - 说明开头使用：`端=Mobile；入口=/m/...；`
+
+169. 参数配置与审批配置（必须）：
+1. 参数配置（System Config）：
+   - 必须在 `core.md` 补齐“系统参数/字典/枚举/通知模板/时间窗口/SLA”等可配置对象的维护入口（通常为 `端=Web；入口=/admin/config`、`/admin/dict`、`/tools/config` 等）
+2. 审批配置（Approval Config）：
+   - 若系统存在审批链（流程/场景中出现 approve 节点或语义出现审批/通过/驳回等），必须补齐“审批流配置/审批节点配置/审批规则配置”的管理入口（端=Web），确保审批功能可运营、可调整

package/skills/visual-spec-skill/prompts/vspec_new/questions.md

@@ -18,6 +18,16 @@
 2. 强制资料要求（命中则必须提问并列入资料清单）：
    - 若涉及“导入/导出/批量导入/批量导出/报表导出/台账导出”等：必须要求业务方提供对应的模板文件（xlsx/csv），至少包含表头、示例数据、字段口径说明、版本号；若已有历史导出文件，也需提供 1 份样例文件用于对齐口径与格式。
    - 若涉及“协议签署/授权同意/条款确认/隐私协议/用户协议/电子签约”等：必须要求业务方提供协议原文（可脱敏），并明确版本号、生效日期、关键条款摘要口径与签署/同意的法律合规要求。
+   - 若涉及“证书/证书发放/结业证/资格证/成绩单/成绩证明/考试成绩/学分/结业证明”等：必须要求业务方提供证书/成绩单的模板文件（PDF 或截图图片：png/jpg），并至少说明：
+     - 模板版本号与适用范围（哪类证书/哪类考试/课程）
+     - 关键字段与口径（姓名/证件号/课程/分数/等级/发证机构/签章/二维码等）
+     - 是否允许下载/分享/验证（如有防伪二维码/验证链接需提供规则或样例）
+     - 若存在历史证书/成绩单样例：至少提供 1 份（脱敏可）用于对齐样式与字段
+   - 若涉及“支付/退款/结算/对账/支付回调/退款回调/开票”等：必须要求业务方提供支付相关资料，并至少明确：
+     - 支付通道与支付方式清单（微信/支付宝/银联/线下转账等）与适用范围
+     - 退款规则（全额/部分/原路/人工）、退款到账时效、退款失败处理与人工兜底
+     - 回调与对账口径（回调字段/签名规则占位、对账频率、差异处理与修复入口）
+     - 若有历史对账文件/回执样例：至少提供 1 份（脱敏可）用于对齐字段与状态口径
 
 3. 资料清单表达方式：
    - 将“资料需求”也当作一类问题来写，例如“请提供《xx》模板/协议/文案”

package/skills/visual-spec-skill/prompts/vspec_new/roles.md

@@ -17,6 +17,7 @@
    - 用动词开头描述任务，例如：创建、提交、审核、配置、查询、导出、对账、处理异常等
    - 每个角色至少 3 条任务（若确实不足，说明原因）
    - 标注每个任务的触发条件与完成定义（完成后用户得到什么结果）
+   - 必须标注该角色主要使用的终端（必须，影响原型端分配）：Web/手机 App/小程序/其他（可多选；若无法确定写“待确认”）
 
 3. 输出结果到文件
    - 将结果写入：`/specs/background/roles.md`
@@ -32,4 +33,5 @@
 - 每行一个“用户角色 x 任务”的组合（同一个角色可多行）
 - 任务尽量短句，避免空泛，例如不要只写“管理”“处理”
 - 尽量从干系人关注点反推任务，但只保留“直接使用系统”的工作内容
+- “备注”列必须包含该角色的终端信息（示例：`终端=Web`、`终端=手机App`、`终端=小程序`、`终端=Web+手机App`、`终端=待确认`）
 - 最后附上一个小节 `# 待确认的角色与任务问题`，列出仍需向用户确认的问题（如有）

package/skills/visual-spec-skill/prompts/vspec_new/scenarios.md

@@ -69,18 +69,55 @@
        - shop-pay-success（支付成功）
        - shop-refund（退款/售后）
        - shop-review（评价/点评）
+     - 登录/账号节点：
+       - auth-login（登录）
+       - auth-logout（退出登录）
+       - auth-forgot-password（忘记密码）
+       - auth-reset-password（重置密码）
+       - auth-change-password（修改密码）
+     - 调查问卷节点：
+       - survey-list（问卷列表/领卷入口）
+       - survey-create（创建问卷）
+       - survey-publish（发布/投放）
+       - survey-fill（填写）
+       - survey-submit（提交）
+       - survey-result（提交回执/结果）
+       - survey-analysis（回收统计/分析）
+     - 支付/退款节点：
+       - pay-init（发起支付）
+       - pay-callback（支付回调/通知）
+       - pay-query（支付结果查询/补偿查询）
+       - pay-timeout-close（支付超时关闭）
+       - refund-apply（发起退款）
+       - refund-approve（退款审核/审批）
+       - refund-callback（退款回调/通知）
+       - reconcile（对账/差异处理）
    - 输出格式必须为（中文名+括号内节点类型，用 `→` 串联）：
      - `申请(apply)→审批(approve)→执行开始(execute-start)→执行结束(execute-end)`
      - `列表(crud-list)→新建(crud-create)→编辑(crud-update)→导出(crud-export)`
      - `开始(step-start)→下一步(step-next)→完成(step-complete)`
+     - `登录(auth-login)→修改密码(auth-change-password)`
+     - `创建问卷(survey-create)→发布(survey-publish)→填写(survey-fill)→提交(survey-submit)→统计(survey-analysis)`
+     - `提交订单(shop-order-submit)→支付(pay-init)→支付回调(pay-callback)→支付成功(pay-success)`
    - 如果存在“拒绝/驳回”类场景：用 `审批(approve)` 节点表示“审批发生”，并在场景名中标明“驳回/拒绝”，节点链条在该处终止或进入 `cancel/abort`（按需求合理选择）
 
 3. 场景粒度与数量控制：
    - 以“业务可讨论、可验证”为粒度，不要把同类场景无限拆分
+   - 若 flows 中存在多个流程/多个业务域（例如报名/教学/排班/考试/发证等）：必须分别为每个流程输出场景，不允许只覆盖其中一个流程
 
 4. 需求范围补齐与用户确认（必须）：
    - 在梳理场景时，必须主动识别原始需求（original）与现有流程图（flows）中可能未提及但常见且必要的能力缺口，并以“待确认范围”方式让用户确认是否纳入本期范围
    - 常见候选能力（按需命中、不要生搬硬套）：预约/排期、回访/跟进、汇总/对账、归档/留存、批量导入导出、通知提醒、到期/超时处理、数据权限/脱敏、异常补救、统计报表
+   - 必须额外考虑“保障系统可运行/可演示”的基础能力场景（命中则必须补齐；不允许遗漏）：
+     - 登录与账号体系（本系统登录/登出/会话、忘记密码/重置密码、修改密码；若为 SSO 则为对接与回调）
+     - 参数与配置管理（系统参数/字典/枚举/通知模板/审批流配置等的维护与生效）
+     - 基础数据/主数据维护（CRUD：列表/新建/编辑/启停/导入导出等；若明确来自外部系统同步，则以“同步/对接”场景替代 CRUD）
+     - 审批与流程配置（存在审批语义时：审批流配置、审批列表处理、审批意见与结果提交）
+     - 支付与退款（出现支付/退款/结算/对账/订单等语义时：必须补齐支付成功/失败/超时关闭/退款/部分退款/退款失败/对账差异等关键场景）
+   - 上述能力的场景在场景表中至少各出现 1 个（若适用），并确保与主业务场景形成可演示闭环（例如：先维护课程/讲师/学员，再发起排课申请）。
+   - 支付与退款场景细化要求（命中则必须在场景表中体现）：
+     - 支付：下单→支付（成功/失败/取消/超时关闭）→支付结果通知/回调→订单状态落地
+     - 退款：发起退款→审核/审批（如适用）→退款成功/失败→原订单/权益回收与对账记录
    - 对每个候选能力，必须给出：
      - 为什么可能需要（对应哪个角色/干系人关注点、哪个流程节点的缺口）
      - 如果纳入，需要补哪些场景节点链条（使用本文件的节点类型清单表达）
@@ -92,17 +129,23 @@
 3. 输出结果必须是标准 Markdown 表格（不要使用 HTML）
 4. 每个场景必须标注“场景类型”，类型只能从下列枚举中选择其一：
    - 审批流
+   - 支付与退款
    - CRUD
+   - 调查问卷
    - 简单步骤
    - 信息展示
+   - 登录与账号
    - 答题
    - 购物
    - 类型判定规则（优先级从高到低，命中即停止）：
      1) 场景节点包含任一审批流节点：`apply/approve/change/cancel/execute-start/execute-end/abort`，或场景名/描述出现“审批/通过/驳回/会签/加签/转交/退回/复核” → 审批流
-     2) 场景节点包含 `crud-` 前缀节点，或场景名/描述出现“新建/创建/编辑/修改/删除/启用/停用/导入/导出/批量/列表管理/配置维护/主数据” → CRUD
-     3) 场景节点包含 `step-` 前缀节点，或场景名/描述出现“步骤/向导/分步/下一步/上一步/完成/草稿”且不涉及审批 → 简单步骤
-     4) 场景节点包含 `info-` 前缀节点，或场景名/描述出现“看板/大屏/报表/统计/详情查看/预览/字典/资料/介绍/公告/文章/天气/通知中心（仅查看）”且无关键提交动作 → 信息展示
-     5) 场景节点包含 `quiz-` 前缀节点，或场景名/描述出现“答题/测评/考试/题库/评分/交卷/错题/解析” → 答题
-     6) 场景节点包含 `shop-` 前缀节点，或场景名/描述出现“商品/购物车/点菜/下单/订单/支付/退款/评价/点评/结算/配送” → 购物
+     2) 场景节点包含 `pay-`/`refund-`/`reconcile` 等支付节点，或场景名/描述出现“支付/退款/结算/对账/回调/收款/退费/补款” → 支付与退款
+     3) 场景节点包含 `survey-` 前缀节点，或场景名/描述出现“调查/问卷/满意度/反馈/回访/调研” → 调查问卷
+     4) 场景节点包含 `quiz-` 前缀节点，或场景名/描述出现“答题/测评/考试/题库/评分/交卷/错题/解析” → 答题
+     5) 场景节点包含 `shop-` 前缀节点，或场景名/描述出现“商品/购物车/点菜/下单/订单/评价/点评/结算/配送” → 购物
+     6) 场景节点包含 `crud-` 前缀节点，或场景名/描述出现“新建/创建/编辑/修改/删除/启用/停用/导入/导出/批量/列表管理/配置维护/主数据” → CRUD
+     7) 场景节点包含 `auth-` 前缀节点，或场景名/描述出现“登录/登出/退出登录/忘记密码/重置密码/修改密码” → 登录与账号
+     8) 场景节点包含 `info-` 前缀节点，或场景名/描述出现“看板/大屏/报表/统计/详情查看/预览/字典/资料/介绍/公告/文章/天气/通知中心（仅查看）”且无关键提交动作 → 信息展示
+     9) 场景节点包含 `step-` 前缀节点，或场景名/描述出现“步骤/向导/分步/下一步/上一步/完成/草稿”且不涉及审批 → 简单步骤
 5. 表头固定为：`| # | 场景名 | 场景类型 | 场景节点 |`
 6. 每行一个场景，编号从 1 开始递增（用 `#` 列承载编号，以便自然缩窄编号列）

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

@@ -0,0 +1,25 @@
+你是一名资深前端原型工程师。你的任务是：在原型工程生成完成后，额外生成一个“全功能入口页”`entries.html`，用于直接访问各个页面入口，便于评审与快速跳转。
+
+输入信息包含：
+- 功能清单（`/specs/functions/*`）
+- 原型工程路由（以工程实际路由为准：`src/router/*` 或等价文件）
+- 原型工程页面（`src/pages/*` 或等价文件）
+
+生成要求（必须）：
+1. 在原型工程根目录新增：`/specs/prototypes/entries.html`，可直接访问。
+2. 页面内容必须包含：
+   - Web 入口区：列出所有 `端=Web` 的页面路由（按“分类→模块→页面”分组展示），每条为可点击链接。
+   - Mobile 入口区：列出所有 `/m/*` 路由（按模块分组），每条为可点击链接。
+   - Tools/特殊页：列出 `/tools/*`、`/profile`、`/agreement/confirm`、`/login*` 等入口（如存在）。
+3. 入口生成口径：
+   - 以“路由列表”为准（优先解析 router 配置）；若无法解析，则退化为从 functions 的 `入口=` 推导，并保证可访问。
+   - 对带参数路由必须提供至少 1 个可访问示例（例如 `/:id` 用 `1` 代替）。
+4. 入口页不得被集成进任何导航：
+   - 不允许出现在左侧菜单、Header 下拉、工具箱、工作台卡片、任何业务页面按钮/链接中。
+   - 访问方式仅保留“直接访问 URL（/entries.html）”。
+5. 技术要求：
+   - 若使用 Vite 多入口（multi-page）方式：必须同步更新 `vite.config.*` 以支持 `index.html`、`scenario.html`（如存在）与 `entries.html` 同时构建与开发访问。
+   - 若工程当前不是 multi-page：必须采用与 `scenario.html` 相同的接入方式，保证 dev/build 都能访问 `entries.html`。
+
+输出要求：
+- `entries.html` 必须为中文界面，分组标题与说明为完整句子。

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）、关键动作按钮（提交/审批/开始/结束/变更/取消）
 
@@ -734,23 +762,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` 页面，至少包含：
@@ -791,16 +810,23 @@ Steps（步骤条）使用要求（必须）：
 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 +870,7 @@ Steps（步骤条）使用要求（必须）：
 3. 动作按钮必须真实生效（不只是 UI）：
    - 点击后更新 mock 数据中的状态/关键字段，并刷新列表
    - 通过状态控制按钮可用性（例如只有待审批状态才显示“通过/驳回”）
+   - 状态限制必须在系统中可见且可解释：按钮禁用时必须展示中文原因提示（Tooltip/Help 文案），且为完整句子
 4. 审批环节必须支持“补充信息后再决策”（必须可演示）：
    - 点击“通过/驳回”不能直接改状态，必须先弹出抽屉填写必要信息后提交
    - 抽屉字段至少包含：审批意见（必填）、审批结果（通过/驳回）、可选附件/备注（按需）
@@ -859,10 +886,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,53 @@
+你是一名资深前端原型工程师。你的任务是：在“原型工程（/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`
+2. 路由访问控制（必须）：
+   - 未登录访问任意业务路由（非 `/login*`、`/m/login*`）：必须引导到对应端登录页，并在登录成功后回跳
+3. 登录成功后必须进入应用首页（`/` 或 `/landing`），并渲染完整的 Web 三段式布局（Header + Menu + 内容区）。
+
+页面要求（必须）：
+1. 登录页（Web + Mobile）：
+   - 支持“选择账号”或“账号+密码”两种 mock 登录方式之一（按需求裁剪但必须可用）
+   - 提供入口：创建账号、忘记密码
+   - 提示文案必须中文化且为完整句子
+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 个字段，按模型裁剪）