visual-spec 0.1.2 → 0.1.4

package/skills/visual-spec-skill/prompts/harness/post_verify_verify.md

@@ -0,0 +1,43 @@
+你是一名资深原型质量检查员。你的任务是：在 `/vspec:verify` 生成原型工程（`/specs/prototypes/`）之后，检查原型是否充分覆盖关键约束；若发现缺失，必须输出“问题列表”，并停止。
+
+输入产物（必须读取）：
+- 功能清单：`/specs/functions/core.md`
+- 角色与任务：`/specs/background/roles.md`
+- 细节规格：`/specs/details/`（RBAC 与数据权限为主）
+- 外部依赖：`/specs/background/dependencies.md`
+- 原型工程：`/specs/prototypes/`（路由、布局、页面、mock 数据源）
+- 工程约束：`/scheme.yaml`（如存在）
+
+检查项（必须逐条检查并可定位）：
+1. 移动端覆盖：
+   - 若 `core.md` 存在任意 `端=Mobile` 或 `端=Web+Mobile` 的功能行：原型必须包含对应 `/m/*` 路由与页面入口（至少能从移动端 Landing/入口页进入）。
+   - 若 Web 中存在“仅手机端操作”的置灰按钮：必须提供“打开手机端页面/复制链接”的入口。
+2. 审批流入口与交互：
+   - 凡涉及审批/审核/驳回/通过等：必须以列表页作为入口（例如 `/approve` 或模块内审核列表），列表行 Action 放“审批/审核”按钮。
+   - 禁止表格内联审批；审批必须打开抽屉（Drawer）填写必要字段后提交，至少包含“审批意见（必填）”与“审批结果（通过/驳回）”。
+   - 发起类流程（报名/申请/提交等）必须从列表页工具栏“新建”按钮打开抽屉完成创建；禁止独立“新建页面路由”承载表单。
+3. CRUD 覆盖：
+   - 对每个配置/主数据/字典类 CRUD：必须具备列表（含查询条件区）、新建（Drawer）、编辑（Drawer）、详情（Drawer 或详情页）、删除（Popconfirm）。
+   - 若业务涉及启用/停用：必须具备启停操作与状态 Tag 展示。
+4. 配置审批生效：
+   - 若 `core.md` 或 `/specs/details/` 中出现“配置需审批后生效/发布”语义：原型必须体现“配置草稿/待审批/已生效”等状态与审批流程入口（列表→审批抽屉）。
+5. 顶部 Header 与 Avatar：
+   - 所有 Web 业务页面必须有顶部 Header。
+   - Header 右上角必须有 Avatar，下拉中至少包含“切换账号/切换角色”（用于演示权限差异）。
+6. 独立登录能力（非 SSO）：
+   - 若 `dependencies.md` 未体现 SSO/OIDC/LDAP/IDaaS 等统一登录外部依赖：原型必须包含登录相关页面与入口：
+     - Web：`/login`，并包含“登录/忘记密码/修改密码（或重置密码）”的最小闭环入口与页面（允许 mock）。
+     - Mobile：`/m/login`，同样具备上述入口（允许 mock）。
+7. 左侧菜单分组：
+   - Web 左侧菜单必须按“菜单类型/分类→模块→页面”分组（至少 3 组），不允许页面散放为同一级菜单。
+8. RBAC 与数据权限过滤：
+   - 菜单可见性必须随角色切换变化（隐藏/置灰与原因提示二选一，但必须可解释）。
+   - 页面按钮可见/可用必须与 `/specs/details/<module_slug>/rbac/*` 对齐，并能给出不可用原因提示。
+   - 列表默认过滤“与我相关”与数据范围必须与 `/specs/details/<module_slug>/data_permission/*` 对齐（至少 1 个页面可演示差异）。
+
+输出要求（必须）：
+1. 若所有检查均通过：仅输出单行 `PASS`。
+2. 若存在问题：仅输出“问题列表”（不要输出修复方案、不要输出其他内容），格式固定如下：
+   - `问题列表（post-verify-verify）`
+   - 逐条编号：`1. ...`
+   - 每条必须包含：问题类型（Mobile/审批/CRUD/配置审批/布局/登录/菜单分组/RBAC）+ 影响 + 定位信息（路由/页面文件/目录路径/对应 functions 行或 detail 文件）

package/skills/visual-spec-skill/prompts/vspec_detail/auth.md

@@ -0,0 +1,41 @@
+你是一名资深账号体系/安全分析师。你的任务是：针对“单个功能点”，输出账号体系与登录相关的功能细节，覆盖页面交互、权限、风控与审计，并写入指定输出文件。
+
+输入信息（由上游提供）：
+- 当前功能点：模块/功能/子功能/说明（来自 `/specs/functions/*`）
+- 角色与组织（`/specs/background/roles.md`）
+- 外部依赖（`/specs/background/dependencies.md`）
+- 场景与节点细节（`/specs/background/scenarios.md`、`/specs/background/scenario_details/`）
+- 数据模型（`/specs/models/*.md`，如存在）
+
+触发条件（命中则必须输出；否则跳过，不生成空文档）：
+- 功能/子功能/说明或场景中出现：登录/账号/注册/创建账号/忘记密码/重置密码/修改密码/登出/会话/验证码/多因素 等任一关键词
+- 且未采用 SSO/OIDC/LDAP（若依赖中明确为 SSO，则本文件仅输出“对接口径/回调/会话处理”，不输出注册/改密等本地账号细节）
+
+产出要求（必须中文化，且可落地实现）：
+1. 登录方式与入口：
+   - 明确登录方式：账号密码/手机号验证码/两者组合（二选一或组合）
+   - Web 与 Mobile 的入口路由与跳转口径
+2. 会话模型：
+   - session 需要包含哪些字段（user_id/role/org/过期时间等）
+   - 未登录访问受限路由的行为（跳转登录并回跳）
+3. 注册/创建账号（如适用）：
+   - 最小字段集、校验规则、重复账号处理
+   - 创建成功后的行为（自动登录 or 返回登录页）
+4. 忘记密码/重置密码（如适用）：
+   - 验证方式（短信/邮件/验证码/链接 token 占位）
+   - token 有效期、重放限制、失败与重试策略
+5. 修改密码（如适用）：
+   - 校验规则、提交后是否强制退出会话（默认强制退出）
+6. 风控与安全（必须）：
+   - 失败次数限制、验证码触发阈值、锁定策略、解锁口径
+   - 敏感信息展示与日志脱敏规则（不记录明文密码/验证码）
+7. RBAC 与数据权限（必须）：
+   - 哪些角色可创建账号/重置他人密码/查看登录日志（若适用）
+8. 操作日志与审计（必须）：
+   - 需要记录的关键事件：登录成功/失败、登出、改密、重置密码、账号创建/禁用
+   - 每条日志最小字段：时间、user_id/账号、IP/设备标识占位、结果、失败原因
+9. 提示与文案（必须）：
+   - 所有提示必须为中文完整句子，且与系统语言一致
+
+输出写入：
+- 将结果写入上游指定的 markdown 文件路径（通常在 `/specs/details/<module_slug>/auth/<function_slug>.md`）

package/skills/visual-spec-skill/prompts/vspec_detail/cron_job.md

@@ -8,17 +8,15 @@
 
 产出要求（必须）：
 1. 输出中只包含“定时任务模块”的内容，不要输出其他无关模块或长篇解释。
-2. 每个定时任务用同一套 markdown 表格输出（必须严格用两列：参数/数据；对齐行必须为 `|:--|:--|`），字段固定如下：
-| 参数 | 数据 |
-|:--|:--|
-| 编号 | {JOB-001...} |
-| 名称 | {中文名（英文key）} |
-| 启动时间 | {首次启动时间/运行窗口/时区} |
-| 启动周期 | {cron 表达式/固定间隔/事件触发说明} |
-| 主要逻辑 | {用 3~7 条要点概括处理流程与输入输出/关键数据变更} |
-| 日志处理 | {关键日志点 + 关键字段（trace_id/job_run_id/biz_id 等）+ 日志级别} |
-| 出错处理 | {失败重试/退避/DLQ(如有)/补偿/人工介入/告警通知} |
-3. 若同一模块有多个任务，按任务分段输出（可用二级标题 `## {名称}`），每段仅包含上述表格，不要额外追加其他表格结构。
+2. 每个定时任务必须用“段落 + 字段分行”的方式输出（禁止使用表格）。字段固定如下（每个字段单独一行，冒号后为数据）：
+   - 编号：{JOB-001...}
+   - 名称：{中文名（英文key）}
+   - 启动时间：{首次启动时间/运行窗口/时区}
+   - 启动周期：{cron 表达式/固定间隔/事件触发说明}
+   - 主要逻辑：{用 3~7 条要点概括处理流程与输入输出/关键数据变更}
+   - 日志处理：{关键日志点 + 关键字段（trace_id/job_run_id/biz_id 等）+ 日志级别}
+   - 出错处理：{失败重试/退避/DLQ(如有)/补偿/人工介入/告警通知}
+3. 若同一模块有多个任务，按任务分段输出（必须用二级标题 `## {名称}`）。每段仅包含上述字段行；不得额外追加表格结构。
 
 输出写入：
 - 将结果写入上游指定的 markdown 文件路径（通常在 `/specs/details/<module_slug>/cron_job/<module_slug>.md`）

package/skills/visual-spec-skill/prompts/vspec_detail/data_permission.md

@@ -10,7 +10,14 @@
 1. 明确该功能点涉及的数据对象（实体/表），以及主要操作（读/新建/编辑/审批/删除/导出）。
 2. 必须以“矩阵表”输出数据权限（重点是范围/可见性/可操作性），要求如下：
    - 纵轴：角色（来自 `/specs/background/roles.md`）
-   - 横轴：数据（以“数据对象”为主；如需区分，可在列名中附加关键视图/操作，例如“申请单(列表/详情)”或“行程明细(编辑)”）
+   - 横轴：功能与数据的正交组合（必须），以“数据对象”为主并按功能动作拆列，列名必须包含动作与视图，例如：
+     - `申请单-列表(读)`
+     - `申请单-详情(读)`
+     - `申请单-新建(写)`
+     - `申请单-编辑(写)`
+     - `申请单-审批(写)`
+     - `申请单-导出(写)`
+     - `明细行-编辑(写)`（如存在 1:N 明细）
    - 单元格：仅用符号表示范围
 3. 符号含义（必须逐字使用）：
    - `○` 全部

package/skills/visual-spec-skill/prompts/vspec_detail/payment.md

@@ -0,0 +1,56 @@
+你是一名资深支付系统分析师。你的任务是：针对“单个功能点”输出支付与退款的业务与技术细节，确保能覆盖支付/退款相关场景，并可落地实现与验收。
+
+输入信息（由上游提供）：
+- 当前功能点：模块/功能/子功能/说明（来自 `/specs/functions/*`）
+- 角色与权限（`/specs/background/roles.md`）
+- 场景与节点细节（`/specs/background/scenarios.md`、`/specs/background/scenario_details/`）
+- 外部依赖（`/specs/background/dependencies.md`）
+- 数据模型（`/specs/models/*.md`）
+- 需求细节（`/specs/details/` 其他产物，如 state_machine/decision_matrix/notification_matrix 等）
+
+触发条件（命中则必须输出；否则跳过，不生成空文档）：
+- 功能/子功能/说明或场景中出现：支付/收款/结算/下单/订单/退款/售后/对账/回调/支付渠道/发票 等任一关键词
+- 或数据模型中出现：order/pay/payment/refund/transaction/bill/settlement 等语义对象或字段
+
+产出结构（必须按顺序输出，且中文化）：
+1. 支付链路概览：
+   - 支付对象：订单/报名/补考/购买等（明确本功能点对应的业务对象）
+   - 支付方式与通道：列出可选项与适用范围（例如微信/支付宝/线下/余额），并说明是否由配置控制
+   - 关键状态：支付前/支付中/已支付/支付失败/已关闭（必须给状态表）
+2. 支付场景覆盖（必须至少覆盖 6 类）：
+   - 正常支付成功（含回调/轮询/主动查询三选一的策略说明）
+   - 支付失败（含失败原因分类：余额不足/用户取消/风控拒绝/通道异常）
+   - 支付超时关闭（含关闭后再支付的处理口径）
+   - 重复支付/重复点击（幂等口径）
+   - 回调重复/乱序/延迟（幂等口径）
+   - 支付后业务权益落地失败（补偿/重试/人工兜底）
+3. 退款链路（命中则必须）：
+   - 退款触发：用户申请/运营发起/系统自动（超卖补偿/取消订单等）
+   - 退款类型：全额/部分/原路/非原路（按业务裁剪，但必须明确是否支持部分退款）
+   - 退款状态：待申请/待审批（如适用）/退款中/退款成功/退款失败（必须给状态表）
+   - 退款场景覆盖（至少 4 类）：成功、失败、超时、重复提交
+4. 对账与差异处理（命中则必须）：
+   - 对账来源：对账文件/对账接口/后台报表（明确一种主策略）
+   - 对账频率与范围：按日/按小时；覆盖哪些交易
+   - 差异类型：少单/多单/金额不一致/状态不一致
+   - 修复入口：自动补偿/人工处理入口（必须可操作描述）
+5. 幂等与一致性（必须）：
+   - 幂等键设计：支付发起、回调处理、退款发起、退款回调分别给出幂等键口径
+   - 事务边界：资金状态与业务状态如何保证一致（例如先落支付单，再推进业务单；失败回滚/补偿）
+6. 安全与合规（必须）：
+   - 签名校验与回调鉴权：必须说明“校验什么、失败怎么处理、如何记录”
+   - 敏感信息处理：不允许在日志/前端暴露支付敏感信息（只写规则，不写具体密钥）
+7. 权限与数据权限（必须）：
+   - 谁可以发起退款/审批退款/查看对账（引用 rbac 与 data_permission 口径）
+8. 前端交互（必须）：
+   - 支付入口必须从订单/业务单详情进入（说明路由或入口）
+   - 提交成功后跳转到成功页（如 `/payment/success` 或业务 `*/success`），失败必须给出中文完整句子提示与重试入口
+   - 若存在退款：退款成功后订单必须仍保留在订单列表/详情中，并标记为“已退款”，且可追溯退款信息（金额/时间/退款单号 mock）
+9. 发票/开票（命中则必须）：
+   - 若涉及订单/支付且存在开票需求：必须说明发票申请入口、字段（抬头/税号/邮箱/内容类目）、状态流转（未开票/开票中/已开票）、下载/预览与记录查询
+9. 操作日志与通知（必须）：
+   - 支付/退款关键动作必须记录日志（字段：单号/金额/通道/结果/失败原因/操作者/时间）
+   - 通知：支付成功/退款成功/退款失败至少覆盖 3 类，并说明失败兜底
+
+输出写入：
+- 将结果写入上游指定的 markdown 文件路径（通常在 `/specs/details/<module_slug>/payment/<function_slug>.md`）

package/skills/visual-spec-skill/prompts/vspec_impl/implement.md

@@ -60,6 +60,10 @@
    - 表单校验与交互（引用 `/specs/details/<module_slug>/interaction/<function_slug>.md`、`/specs/details/<module_slug>/validation_matrix/<function_slug>.md`）
    - API 集成与错误处理
    - 权限控制到区域/控件级（引用 RBAC 产物）
+   - 基础数据/主数据 CRUD（必须）：
+     - 必须从 `/specs/models/*.md` 中识别“基础数据/主数据”（维护对象），并为其提供可维护的 CRUD 能力（后端接口 + 前端管理页）
+     - 业务流程页面必须以主数据为前置：表单选择项来自主数据；若为空必须提示并引导先维护（例如排课需先维护课程/讲师/学员）
+     - 必须提供最小种子数据/fixture，保证主数据 CRUD 与至少 1 条主流程可端到端演示
 7. 启动与联调（必须，输出必须“可运行”而不是只生成代码片段）：
    - 必须实现可启动的后端服务：
      - 提供可用的启动脚本（复用仓库既有脚本；如果不存在则补齐最小脚本）

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

@@ -1,5 +1,9 @@
 你是一名资深业务分析师。你的任务是：基于流程节点（来自 `/specs/flows/*.puml` 与 `/specs/background/scenarios.md` 的节点链条去重）逐节点细化细节，并将分析过程拆解为多个“思维方式”提示词文件，以便按“节点”分别输出独立的 markdown 文件。
 
+分析基线（必须）：
+0. 在生成任何节点细节前，必须先遍历并理解 `/specs/functions/` 目录下所有 functions 文件（包括 core.md 与外部系统相关文件），将每一行功能点视为“必须覆盖”的分析清单，避免仅基于 flows/scenarios 造成遗漏。
+1. 对每个节点的 pre/post、约束、边界等内容，必须能回溯到至少 1 条 functions 证据（对应的功能点或维护入口）；若发现节点依赖的主数据/配置/登录/审批能力在 functions 中缺失，必须输出可见错误并停止，而不是继续产出细节文件。
+
 执行顺序（必须）：
 1. 先加载 `prompts/vspec_new/details_pre_post.md`：创建节点目录并为每个节点生成 `pre_post.md`
 2. 再加载 `prompts/vspec_new/details_constraints.md`：为每个节点生成 `constraints.md`
@@ -9,6 +13,7 @@
 
 输出要求：
 - 输出目录：`/specs/background/scenario_details/`
-- 每个节点一个目录：`/specs/background/scenario_details/<node_key>/`
+- 每个节点一个目录：`/specs/background/scenario_details/<dir_key>/`
 - 每个节点目录内固定生成 5 个文件：`pre_post.md`、`constraints.md`、`variations.md`、`boundaries.md`、`symmetry.md`
 - 节点覆盖不得遗漏：若流程/场景中出现 approve/审批节点，不允许跳过（即使被认为是罕见节点也必须产出文件）
+- 多流程要求（必须）：若存在多个流程/业务域，同一节点的 `pre_post.md` 必须按流程拆分输出（由 `details_pre_post.md` 负责），避免把不同流程的前置/后置合并在一起

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

@@ -12,7 +12,7 @@
 - 每个节点至少给出 5 条关键边界（时间/数量/金额/并发/文件等），主流程节点建议 8-12 条
 
 产出方式（必须）：
-1. 遍历 `/specs/background/scenario_details/` 下的所有节点目录（`node_*/`），逐节点生成对应的 `boundaries.md`。
+1. 遍历 `/specs/background/scenario_details/` 下的所有节点目录（按目录名排序），逐节点生成对应的 `boundaries.md`。
 2. 每个节点至少给出 5 条关键边界（时间/数量/金额/并发/文件等），主流程节点建议 8-12 条，并与该节点的 Pre/Post、场景链条一致。
 3. 本小节不允许留空：信息不足时必须给出“建议边界 + 假设”，不要只写待确认；仅在确实与该节点无关时才写 `Not Applicable：<原因>`。
 
@@ -30,7 +30,7 @@
 4. 若边界与状态机/审批链/外部系统 SLA 相关，必须点出触发条件（例如“超过窗口自动转人工/自动取消”）
 
 输出与写入要求：
-1. 对每个节点目录写入：`/specs/background/scenario_details/<node_key>/boundaries.md`
+1. 对每个节点目录写入：`/specs/background/scenario_details/<dir_key>/boundaries.md`
 2. 文件结构固定如下（必须）：
 
 # 节点：<节点名>

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

@@ -13,7 +13,7 @@
 - 约束表达必须可落地（可用伪代码/规则表达式），避免泛泛描述
 
 产出方式（必须）：
-1. 遍历 `/specs/background/scenario_details/` 下的所有节点目录（`node_*/`），逐节点生成对应的 `constraints.md`。
+1. 遍历 `/specs/background/scenario_details/` 下的所有节点目录（按目录名排序），逐节点生成对应的 `constraints.md`。
 2. 每个节点的约束必须与该节点的 Pre/Post、角色权限、场景链条、流程图一致；不要写与该节点无关的泛化内容。
 3. 本小节不允许留空：信息不足时必须给出“合理默认值/建议值”，并用（假设）标注；仅在确实与该节点无关时才写 `Not Applicable：<原因>`。
 
@@ -58,7 +58,7 @@
      - 反垄断/公平竞争：若涉及价格/补贴/渠道排他，需输出合规边界与审批要求（写清触发条件）
 
 输出与写入要求：
-1. 对每个节点目录写入：`/specs/background/scenario_details/<node_key>/constraints.md`
+1. 对每个节点目录写入：`/specs/background/scenario_details/<dir_key>/constraints.md`
 2. 文件结构固定如下（必须）：
 
 # 节点：<节点名>

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,14 @@
    - 对每个对象，检查 functions 是否覆盖其全生命周期需要的：
      - 处理功能：创建/发放/审批/启用停用/使用核销/消耗与结算/延期续期/失效注销/丢失补发/归档查询与审计（按对象裁剪）
      - 支持功能：查询、筛选、导入导出、对账汇总、通知提醒、权限与脱敏、操作日志与留痕、异常兜底
+   - 若存在支付/退款语义（订单/结算/支付/退款/对账等）：必须补齐支付闭环能力（至少在 core.md 中体现）：
+     - 支付：支付下单/发起、支付渠道选择/配置、支付回调处理（幂等/签名校验）、支付失败重试/超时关闭、支付结果查询
+     - 退款：退款申请/审批（如适用）、退款执行/回调处理、部分退款口径（如适用）、退款失败重试/人工兜底
+     - 对账：对账任务（端=Job）或对账页面（端=Web）之一必须具备，包含差异识别与修复入口
+   - 若存在订单/支付语义：必须补齐“发票/开票”能力（至少在 core.md 中体现）：
+     - 开票申请入口（端=Web；入口=/orders 或 /invoices）
+     - 发票信息维护（抬头/税号/邮箱/发票内容），以及发票状态（未开票/开票中/已开票）
+     - 发票下载/预览（PDF）与开票记录查询
    - 若发现生命周期不完整：必须在输出前补全 `core.md`（或对应外部系统 functions 文件）的功能行，直到对象生命周期闭环
    - 示例口径（用于你自检，不要生搬硬套）：
      - 有“优惠”能力：应覆盖优惠创建/配置、审批（如需要）、发放/绑定、使用/核销、延续（延期/续期/扩展额度）、失去（失效/作废/撤销/回收）、归档与审计
@@ -95,6 +104,7 @@
    - 基础数据 CRUD 自检（必须）：
      - 在 functions 初版生成完成后，必须对“基础数据/主数据”（能影响业务运行、需要日常维护的对象，如组织人员、门店、商品、价格、规则、字典、渠道、支付方式、权限角色等）逐一检查是否存在可维护入口
      - 不允许出现“业务流程依赖该基础数据”但 `core.md` 中没有任何维护能力的情况；若缺失，必须补齐对应基础数据的 CRUD（通常为 `端=Web；入口=/...；`）或明确其来自外部系统并补齐对接能力
+     - 当你在 `/specs/background/scenario_details/` 的节点 pre/post 中识别到“数据前置/配置前置”依赖某主数据/配置数据时，必须确保 functions 中存在该对象的维护入口（CRUD/配置管理）或明确其来自外部系统同步（可不做 CRUD 但必须有对接能力）
    - 完整性自检：
      - 不允许出现“依赖某配置/某数据”但 functions 中没有任何维护入口/对接能力的情况
      - 若识别到缺口：必须补全 functions 后再输出
@@ -120,6 +130,11 @@
    - 通知体系复查：
      - 必须识别需要通知的业务节点（至少覆盖：提交成功/审批到达/审批结果/执行开始与异常/到期提醒/失败重试与人工兜底）
      - 必须明确通知通道策略：哪些通道可用（站内信/短信/邮件/IM/Push）、是否可由用户订阅偏好选择、不同紧急级别如何升级（例如 IM + 短信）
+    - 若业务涉及通知：必须在 functions 中生成“通知功能与通知通道”相关功能点（不允许只写一句‘会通知’）：
+      - 通知中心（站内信/消息中心）：列表/详情/已读未读/批量处理（端=Web；入口=/tools/notify-center 或 /notifications）
+      - 通知模板管理：按业务事件维护模板（端=Web；入口=/admin/notify-templates 或等价）
+      - 通知通道配置：企业微信/钉钉/短信/邮件等通道开关与参数占位（端=Web；入口=/tools/notify-center）
+      - 通知发送记录与重试：发送日志、失败原因、重试/改用通道（端=Web；入口=/tools/notify-center）
      - 若存在外部通道（短信/邮件/IM）：必须在对应外部系统 functions 文件中补齐对接与失败兜底（回执、重试、补偿、人工兜底）
      - 若站内信：必须在 `core.md` 补齐通知中心（列表/详情/已读未读/批量处理）与消息模板管理（可选）
 
@@ -166,3 +181,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

@@ -45,6 +45,7 @@
        - step-next（下一步）
        - step-prev（上一步）
        - step-save-draft（保存草稿）
+       - step-publish（发布/生效）
        - step-complete（完成）
      - 信息展示节点：
        - info-list（列表展示）
@@ -69,18 +70,74 @@
        - 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（对账/差异处理）
+     - MQ 排队节点：
+       - mq-enqueue（进入队列/排队）
+       - mq-consume（消费处理）
+       - mq-retry（重试/退避）
+       - mq-dlq（死信/人工兜底）
+     - 定时任务节点：
+       - cron-scan（定时扫描/批处理）
+       - cron-expire（到期/超时处理）
+       - cron-notify（定时通知/汇总通知）
+       - cron-reconcile（定时对账）
    - 输出格式必须为（中文名+括号内节点类型，用 `→` 串联）：
      - `申请(apply)→审批(approve)→执行开始(execute-start)→执行结束(execute-end)`
      - `列表(crud-list)→新建(crud-create)→编辑(crud-update)→导出(crud-export)`
      - `开始(step-start)→下一步(step-next)→完成(step-complete)`
+     - `保存草稿(step-save-draft)→发布(step-publish)`
+     - `登录(auth-login)→修改密码(auth-change-password)`
+     - `创建问卷(survey-create)→发布(survey-publish)→填写(survey-fill)→提交(survey-submit)→统计(survey-analysis)`
+     - `提交订单(shop-order-submit)→支付(pay-init)→支付回调(pay-callback)→支付成功(pay-success)`
+     - `排队(mq-enqueue)→消费(mq-consume)→重试(mq-retry)→死信(mq-dlq)`
+     - `定时扫描(cron-scan)→到期处理(cron-expire)`
    - 如果存在“拒绝/驳回”类场景：用 `审批(approve)` 节点表示“审批发生”，并在场景名中标明“驳回/拒绝”，节点链条在该处终止或进入 `cancel/abort`（按需求合理选择）
 
 3. 场景粒度与数量控制：
    - 以“业务可讨论、可验证”为粒度，不要把同类场景无限拆分
+   - 若 flows 中存在多个流程/多个业务域（例如报名/教学/排班/考试/发证等）：必须分别为每个流程输出场景，不允许只覆盖其中一个流程
 
 4. 需求范围补齐与用户确认（必须）：
    - 在梳理场景时，必须主动识别原始需求（original）与现有流程图（flows）中可能未提及但常见且必要的能力缺口，并以“待确认范围”方式让用户确认是否纳入本期范围
    - 常见候选能力（按需命中、不要生搬硬套）：预约/排期、回访/跟进、汇总/对账、归档/留存、批量导入导出、通知提醒、到期/超时处理、数据权限/脱敏、异常补救、统计报表
+   - 必须额外考虑“保障系统可运行/可演示”的基础能力场景（命中则必须补齐；不允许遗漏）：
+     - 登录与账号体系（本系统登录/登出/会话、忘记密码/重置密码、修改密码；若为 SSO 则为对接与回调）
+     - 参数与配置管理（系统参数/字典/枚举/通知模板/审批流配置等的维护与生效）
+     - 基础数据/主数据维护（CRUD：列表/新建/编辑/启停/导入导出等；若明确来自外部系统同步，则以“同步/对接”场景替代 CRUD）
+     - 审批与流程配置（存在审批语义时：审批流配置、审批列表处理、审批意见与结果提交）
+     - 支付与退款（出现支付/退款/结算/对账/订单等语义时：必须补齐支付成功/失败/超时关闭/退款/部分退款/退款失败/对账差异等关键场景）
+     - 草稿与发布（出现草稿/发布/上架/下架/生效/失效/投放等语义时：必须补齐“草稿→发布/生效→下线/失效→归档”的场景）
+     - MQ 排队（出现队列/MQ/异步/排队/批处理/削峰等语义时：必须补齐入队、消费、重试、死信与人工兜底场景）
+     - 定时任务（出现定时/cron/到期/超时/SLA/自动关闭/自动失效/自动通知/对账等语义时：必须补齐定时扫描、到期处理、通知补偿、对账与差异修复场景）
+   - 上述能力的场景在场景表中至少各出现 1 个（若适用），并确保与主业务场景形成可演示闭环（例如：先维护课程/讲师/学员，再发起排课申请）。
+   - 登录场景补齐要求（命中则必须在场景表中体现）：
+     - 至少包含 3 条：登录成功、登录失败（密码错误/验证码错误）、退出登录
+     - 若需求出现“忘记密码/重置密码/修改密码/注册/创建账号”任一语义：对应场景必须补齐
+   - 支付与退款场景细化要求（命中则必须在场景表中体现）：
+     - 支付：下单→支付（成功/失败/取消/超时关闭）→支付结果通知/回调→订单状态落地
+     - 退款：发起退款→审核/审批（如适用）→退款成功/失败→原订单/权益回收与对账记录
    - 对每个候选能力，必须给出：
      - 为什么可能需要（对应哪个角色/干系人关注点、哪个流程节点的缺口）
      - 如果纳入，需要补哪些场景节点链条（使用本文件的节点类型清单表达）
@@ -92,17 +149,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` 必须为中文界面，分组标题与说明为完整句子。