visual-spec 0.1.3 → 0.1.4

package/docs/en-US/getting-started.md

@@ -11,13 +11,13 @@ Install the npm package, then install the Skill into your AI editor configuratio
 Install / update (npm):
 
 ```bash
-npm install -g visual-spec
+npm install -g visual-spec@latest
 ```
 
 Install / update (pnpm):
 
 ```bash
-pnpm add -g visual-spec
+pnpm add -g visual-spec@latest
 ```
 
 Install / update (yarn):
@@ -25,13 +25,13 @@ Install / update (yarn):
 Yarn Classic:
 
 ```bash
-yarn global add visual-spec
+yarn global add visual-spec@latest
 ```
 
 Yarn Berry (v2+):
 
 ```bash
-yarn dlx -p visual-spec vspec
+yarn dlx -p visual-spec@latest vspec
 ```
 
 ### 2. Recommended Workflow

package/docs/en-US/installation.md

@@ -9,13 +9,13 @@ This package uses a script to copy the built-in Skill directory into your AI edi
 ### Install / Update (npm)
 
 ```bash
-npm install -g visual-spec
+npm install -g visual-spec@latest
 ```
 
 ### Install / Update (pnpm)
 
 ```bash
-pnpm add -g visual-spec
+pnpm add -g visual-spec@latest
 ```
 
 ### Install / Update (yarn)
@@ -23,13 +23,13 @@ pnpm add -g visual-spec
 Yarn Classic:
 
 ```bash
-yarn global add visual-spec
+yarn global add visual-spec@latest
 ```
 
 Yarn Berry (v2+):
 
 ```bash
-yarn dlx -p visual-spec vspec
+yarn dlx -p visual-spec@latest vspec
 ```
 
 ### Next

package/docs/zh-CN/getting-started.md

@@ -11,13 +11,13 @@
 安装/更新（npm）：
 
 ```bash
-npm install -g visual-spec
+npm install -g visual-spec@latest
 ```
 
 安装/更新（pnpm）：
 
 ```bash
-pnpm add -g visual-spec
+pnpm add -g visual-spec@latest
 ```
 
 安装/更新（yarn）：
@@ -25,13 +25,13 @@ pnpm add -g visual-spec
 Yarn Classic：
 
 ```bash
-yarn global add visual-spec
+yarn global add visual-spec@latest
 ```
 
 Yarn Berry（v2+）：
 
 ```bash
-yarn dlx -p visual-spec vspec
+yarn dlx -p visual-spec@latest vspec
 ```
 
 ### 2. 推荐流程

package/docs/zh-CN/installation.md

@@ -9,13 +9,13 @@
 ### 安装/更新（npm）
 
 ```bash
-npm install -g visual-spec
+npm install -g visual-spec@latest
 ```
 
 ### 安装/更新（pnpm）
 
 ```bash
-pnpm add -g visual-spec
+pnpm add -g visual-spec@latest
 ```
 
 ### 安装/更新（yarn）
@@ -23,13 +23,13 @@ pnpm add -g visual-spec
 Yarn Classic：
 
 ```bash
-yarn global add visual-spec
+yarn global add visual-spec@latest
 ```
 
 Yarn Berry（v2+）：
 
 ```bash
-yarn dlx -p visual-spec vspec
+yarn dlx -p visual-spec@latest vspec
 ```
 
 ### 下一步

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "visual-spec",
-  "version": "0.1.3",
+  "version": "0.1.4",
   "description": "AI skill: visual-spec-skill (/vspec:* commands) for requirement analysis, prototyping, detailing, testing, and planning.",
   "license": "MIT",
   "type": "commonjs",

package/skills/visual-spec-skill/SKILL-zh-CN.md

@@ -146,10 +146,14 @@ description: "将原始需求分析为可评审的视觉规格，并生成相关
 4. 基于 functions/details/models/roles 生成可运行的页面原型；原型技术栈由 `/scheme.yaml` 选择（若缺失则按默认值自动创建）。
    - 加载 `prompts/vspec_verify/prototype.md` 执行原型生成规则（必须遵循 `scheme.yaml` 技术栈；禁止只生成 html-only）。
 5. 将原型工程写入 `/specs/prototypes/`。
-6. 加载 `prompts/vspec_verify/validation.md` 生成场景验证网页。
-7. 将验证页面写入 `/specs/prototypes/`，并提供 `scenario.html` 作为访问入口。
-8. 加载 `prompts/vspec_verify/entries.md` 生成全功能入口页，并写入 `/specs/prototypes/entries.html`（禁止在菜单/Header 内提供入口）。
-9. 加载 `prompts/harness/post_verify_verify.md` 检查原型是否覆盖关键约束（移动端/审批/CRUD/布局/登录/RBAC 等）。若输出了问题列表，则提示问题并立即结束。
+6. 加载 `prompts/harness/post_verify_stack_verify.md` 检查原型前端工程是否严格符合 `/scheme.yaml` 中选择的前端栈；若输出了问题列表，则提示问题并立即结束。
+7. 加载 `prompts/vspec_verify/validation.md` 生成场景验证网页。
+8. 将验证页面写入 `/specs/prototypes/`，并提供 `scenario.html` 作为访问入口。
+9. 加载 `prompts/vspec_verify/entries.md` 生成全功能入口页，并写入 `/specs/prototypes/entries.html`（禁止在菜单/Header 内提供入口）。
+10. 加载 `prompts/harness/post_verify_mobile_selection_check.md` 检查移动端数据选择是否使用“选择页（List）选择→返回回填”，而不是下拉框 Select；若输出了问题列表，则提示问题并立即结束。
+11. 加载 `prompts/harness/post_verify_price_format_check.md` 检查价格/金额格式是否统一（右对齐、两位小数、千位分隔符）；若输出了问题列表，则提示问题并立即结束。
+12. 加载 `prompts/harness/post_verify_click_check.md` 检查是否存在“按钮/链接点击无反应”的情况；若输出了问题列表，则提示问题并立即结束。
+13. 加载 `prompts/harness/post_verify_verify.md` 检查原型是否覆盖关键约束（移动端/审批/CRUD/布局/登录/RBAC 等）。若输出了问题列表，则提示问题并立即结束。
 
 ### `/vspec:proto-survey`
 
@@ -208,6 +212,7 @@ description: "将原始需求分析为可评审的视觉规格，并生成相关
 1. 读取 `/specs/functions/*`、`/specs/details/`、`/specs/models/*.md`、`/specs/background/dependencies.md`，并识别当前前后端技术栈与代码约定。
 2. 加载 `prompts/vspec_impl/implement.md` 并按后端优先实现：先在 `/specs/backend/` 生成可运行后端工程（health check + 核心 API/service），再在后端 API 可用后生成前端集成对接。
 3. 仅允许在 `/specs/` 下写代码，并尽量保持差异最小且可审查；后端必须在 `/specs/backend/`，原型前端在 `/specs/prototypes/`。
+4. 加载 `prompts/harness/post_impl_verify.md` 检查后端是否符合 MVC 架构且测试覆盖是否完整；若输出了问题列表，则提示问题并立即结束。
 
 ### `/vspec:upgrade`
 

package/skills/visual-spec-skill/SKILL.md

@@ -147,10 +147,14 @@ Flow:
 4. Generate a runnable page prototype based on functions, details, models, and roles; the prototype tech stack can be selected via `/scheme.yaml` (auto-created with defaults if missing).
    - Load `prompts/vspec_verify/prototype.md` for the prototype generation rules (must follow `scheme.yaml` stack; do not output html-only).
 5. Write the prototype to `/specs/prototypes/`.
-6. Load `prompts/vspec_verify/validation.md` to generate a scenario validation web page.
-7. Write the validation page to `/specs/prototypes/` and provide a `scenario.html` entry for access.
-8. Load `prompts/vspec_verify/entries.md` to generate an entry page and write it to `/specs/prototypes/entries.html` (do not link it from any menu/header).
-9. Load `prompts/harness/post_verify_verify.md` to validate the prototype completeness. If it outputs any issues, show the issue list and stop.
+6. Load `prompts/harness/post_verify_stack_verify.md` to validate whether the prototype frontend stack matches `/scheme.yaml`. If it outputs any issues, show the issue list and stop.
+7. Load `prompts/vspec_verify/validation.md` to generate a scenario validation web page.
+8. Write the validation page to `/specs/prototypes/` and provide a `scenario.html` entry for access.
+9. Load `prompts/vspec_verify/entries.md` to generate an entry page and write it to `/specs/prototypes/entries.html` (do not link it from any menu/header).
+10. Load `prompts/harness/post_verify_mobile_selection_check.md` to ensure mobile data selection uses a picker page (list-based), not dropdown Select. If it outputs any issues, show the issue list and stop.
+11. Load `prompts/harness/post_verify_price_format_check.md` to validate money/price formatting (right aligned, 2 decimals, thousand separators). If it outputs any issues, show the issue list and stop.
+12. Load `prompts/harness/post_verify_click_check.md` to detect clickable UI elements that do nothing. If it outputs any issues, show the issue list and stop.
+13. Load `prompts/harness/post_verify_verify.md` to validate the prototype completeness. If it outputs any issues, show the issue list and stop.
 
 ### `/vspec:proto-survey`
 
@@ -209,6 +213,7 @@ Flow:
 1. Read `/specs/functions/*`, `/specs/details/`, `/specs/models/*.md`, `/specs/background/dependencies.md`, and detect the current frontend/backend stacks and code conventions.
 2. Load `prompts/vspec_impl/implement.md` and implement backend-first: generate a runnable backend project under `/specs/backend/` (health check + core APIs/services), then generate frontend integration after backend APIs are available.
 3. Write code only under `/specs/` with minimal diffs and keep it reviewable; backend must be under `/specs/backend/` and prototype frontend under `/specs/prototypes/`.
+4. Load `prompts/harness/post_impl_verify.md` to validate backend MVC structure and test coverage. If it outputs any issues, show the issue list and stop.
 
 ### `/vspec:upgrade`
 

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

@@ -0,0 +1,34 @@
+你是一名资深后端架构与测试质量质检员。你的任务是：在 `/vspec:impl` 生成后端代码（通常在 `/specs/backend/`）之后，验证后端工程是否符合 MVC 架构，并验证测试覆盖是否完整；若不满足，必须输出“问题列表”，并停止，要求重构/补测。
+
+输入产物（必须读取）：
+- 后端代码：`/specs/backend/`
+- 功能清单：`/specs/functions/*`
+- 详细规格：`/specs/details/`
+- 验收用例：`/specs/acceptance/`（如存在）
+
+验证规则（必须）：
+0. 基础存在性：
+   - 若 `/specs/backend/` 不存在或为空：输出问题 1 条并停止。
+
+1. MVC 架构（必须）：
+   - 后端工程必须体现清晰的 MVC（或等价分层）目录/模块划分，且至少包含：
+     - Controller（路由/接口层）
+     - Service（业务编排层）
+     - Repository/DAO（数据访问层；若无数据库则为 InMemoryRepository/Adapter）
+     - Model/Entity/DTO（数据结构层）
+   - 若工程将控制器逻辑、业务逻辑、数据访问逻辑混写在单一文件/单一层：判定为不符合，输出问题并要求重构为 MVC。
+
+2. 测试覆盖完整性（必须）：
+   - 必须存在可运行的自动化测试（单元测试或集成测试皆可），并满足“覆盖主要接口/关键业务分支”的最小闭环。
+   - 覆盖口径（必须可核对）：
+     - 从 `/specs/functions/*` 中抽取后端相关能力（`端=Backend`、或支付回调/对账/通知/权限校验等后端逻辑）。
+     - 以及从 `/specs/acceptance/` 中抽取关键验收场景（如存在）。
+     - 对每一类关键接口/能力，必须存在对应测试文件或测试用例描述（同名/同路径/同模块均可，但需可定位）。
+   - 若发现任一关键能力缺少测试覆盖：记录问题（指出缺失的能力与应对应的测试位置）。
+
+输出要求（必须）：
+1. 若所有检查通过：仅输出单行 `PASS`。
+2. 若存在问题：仅输出“问题列表”（不要输出修复方案、不要输出其他内容），格式固定如下：
+   - `问题列表（post-impl-verify）`
+   - 逐条编号：`1. ...`
+   - 每条必须包含：问题类型（MVC 不符合 / 测试覆盖缺失）+ 影响（无法维护/回归风险高/无法验收）+ 定位信息（目录/文件/对应 functions 行或 acceptance 目录）

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

@@ -0,0 +1,27 @@
+你是一名资深前端原型交互质检员。你的任务是：在 `/vspec:verify` 生成原型工程后，检查原型中是否存在“按钮/链接点击无反应”的情况；若存在，必须输出问题列表并要求补齐交互逻辑（更新 mock、提示、跳转、关闭抽屉等）。
+
+输入产物（必须读取）：
+- 原型工程：`/specs/prototypes/`（页面、路由、组件、mock）
+
+检查规则（必须）：
+1. 交互定义口径：
+   - 将“按钮/链接”定义为：UI 中可点击元素（Button/Link/Menu.Item/Dropdown.Item/Tab、以及带 onClick/@click 的可交互元素）。
+2. 必须逐文件扫描（可用最小策略，不要求穷尽语义）：
+   - Vue：查找 `@click=`、`onClick=`、`<a`、`<button`、`<Menu.Item` 等，并判断是否绑定了处理函数或跳转。
+   - React：查找 `onClick=`、`<Link`、`navigate(` 等，并判断是否存在空函数/占位函数。
+3. 判定为“无反应”的典型模式（命中则必须报问题）：
+   - `onClick={() => {}}`、`onClick={() => null}`、`onClick={undefined}`、`@click="() => {}"` 等空处理
+   - 点击后既不更新 mock 状态、也不触发 message/notification、也不跳转路由、也不打开/关闭抽屉/弹窗
+   - 明显占位文案：`TODO`、`TBD`、`coming soon`、`not implemented` 出现在点击处理路径中
+4. 允许的最小可用交互（满足其一即可，不视为无反应）：
+   - 更新 mock 并刷新视图（列表/详情/状态 Tag）
+   - 路由跳转（含 query/params）
+   - 打开抽屉/弹窗，并在提交成功后关闭抽屉
+   - message/notification 提示（中文完整句子），并且能解释“发生了什么/下一步是什么”
+
+输出要求（必须）：
+1. 若不存在问题：仅输出单行 `PASS`。
+2. 若存在问题：仅输出“问题列表”（不要输出修复方案、不要输出其他内容），格式固定如下：
+   - `问题列表（post-verify-click-check）`
+   - 逐条编号：`1. ...`
+   - 每条必须包含：问题类型（点击无反应）+ 影响（无法演示/无法验收）+ 定位信息（文件路径 + 组件/函数名 + 触发控件文本或 selector）

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

@@ -0,0 +1,23 @@
+你是一名资深移动端交互质检员。你的任务是：在 `/vspec:verify` 生成原型工程（`/specs/prototypes/`）后，检查移动端页面是否错误使用“下拉框 Select”来选择数据对象；若发现，应输出问题列表并要求改为“选择页（List）选择→返回回填”的交互。
+
+输入产物（必须读取）：
+- 原型工程：`/specs/prototypes/`（移动端页面、组件、路由）
+
+检查规则（必须）：
+1. 检查范围：
+   - 所有移动端页面：路由前缀为 `/m/*` 的页面与其组件（通常在 `src/pages/m/*`、`src/pages/mobile/*`、或路由配置指向的文件）
+2. 判定为“不合规”的情况（命中任一即报问题）：
+   - 在移动端表单/筛选/编辑等页面中，使用 Select 下拉框直接选择“数据对象/字典项/主数据”（例如城市、组织、门店、人员、商品、课程、仓库、渠道等）
+   - 使用任意“下拉弹出选项”的 Select 组件充当主数据选择（不论是 Ant Design（Vue/React）还是其他 UI 库的 Select）
+3. 允许例外（仅限以下情况，不报问题）：
+   - 登录页用于“快速切换角色/账号”的角色下拉框（用于演示 RBAC），不算数据对象选择
+4. 合规交互要求（发现不合规时，问题描述必须引用）：
+   - 必须改为“点选进入选择页（List）→ 搜索/筛选 → 点击条目选中 → 返回上一页并回填字段”
+   - 选择页必须使用移动端 List/Card（禁止 Table），并提供返回与搜索
+
+输出要求（必须）：
+1. 若所有检查通过：仅输出单行 `PASS`。
+2. 若存在问题：仅输出“问题列表”（不要输出修复方案、不要输出其他内容），格式固定如下：
+   - `问题列表（post-verify-mobile-selection-check）`
+   - 逐条编号：`1. ...`
+   - 每条必须包含：问题类型（移动端数据选择不合规）+ 影响（不符合移动端交互规范/不便操作）+ 定位信息（路由 + 文件路径 + 字段/控件名）

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

@@ -0,0 +1,26 @@
+你是一名资深前端 UI 质检员。你的任务是：在 `/vspec:verify` 生成原型工程后，检查“价格/金额”展示是否符合统一格式：右对齐、两位小数、千位分隔符；若不满足，输出问题列表并停止。
+
+输入产物（必须读取）：
+- 原型工程：`/specs/prototypes/`
+
+检查规则（必须）：
+1. 检查范围：
+   - 所有页面与组件（含 Web 与 Mobile），重点关注包含“价格/金额/费用/合计/应付/实付/退款金额”等语义的区域。
+2. 价格格式要求（必须同时满足）：
+   - 右对齐：价格文本在其容器中应右对齐（例如样式包含 `text-align: right`、`justify-content: space-between` 且价格在右侧并右对齐等等，按工程实现等价判断）
+   - 两位小数：展示值必须为固定两位小数（例如 `1234.00`）
+   - 千位分隔符：展示值必须包含千位分隔符（例如 `1,234.00`）
+3. 判定为问题的典型模式（命中则必须报问题）：
+   - 直接渲染原始 number/string（例如 `amount`）且未见格式化函数/formatter
+   - 价格展示为 `1234`、`1234.0`、`1234.000`、`1234.5`、`1234.50`（缺少千分位）
+   - 价格展示未右对齐（明显与标题/商品信息混在一列且不在右侧对齐）
+4. 允许例外（仅限以下情况，不报问题）：
+   - 输入态：表单中的 InputNumber 输入框（但其 formatter/parser 仍应保证千分位与两位小数一致）
+   - 无法显示千位的极短金额（例如小于 1000）仍必须保留两位小数，但千分位可无（此例外仅适用于 `< 1000` 的展示）
+
+输出要求（必须）：
+1. 若所有检查通过：仅输出单行 `PASS`。
+2. 若存在问题：仅输出“问题列表”，格式固定如下：
+   - `问题列表（post-verify-price-format-check）`
+   - 逐条编号：`1. ...`
+   - 每条必须包含：问题类型（价格格式不合规）+ 影响（展示不一致/评审困难/易误读）+ 定位信息（路由/组件 + 文件路径 + 相关字段名或 UI 文案）

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

@@ -0,0 +1,43 @@
+你是一名资深前端架构质检员。你的任务是：在 `/vspec:verify` 生成原型工程（`/specs/prototypes/`）之后，检查其前端工程架构是否严格符合 `/scheme.yaml` 中选择的前端栈；若不符合，必须输出“问题列表”，并停止，要求重构为正确栈。
+
+输入产物（必须读取）：
+- 技术选型：`/scheme.yaml`
+- 原型工程：`/specs/prototypes/`（至少包含 package.json、构建配置、src 目录等）
+
+验证规则（必须）：
+0. 基础存在性：
+   - 若 `/scheme.yaml` 不存在：输出问题 1 条并停止。
+   - 若 `/specs/prototypes/` 不存在或为空：输出问题 1 条并停止。
+   - 若 `/specs/prototypes/package.json` 不存在：视为“非工程化原型（可能是 html-only）”，输出问题 1 条并停止。
+
+1. 栈解析（必须）：
+   - 从 `/scheme.yaml` 读取：
+     - `selected.prototype_frontend_stack`
+     - 以及 `catalog.prototype_frontend_stacks` 中对应 id 的条目（必须能找到），获取其 `framework` 与 `build_tool`
+   - 若无法在 catalog 中找到该 stack id：输出问题 1 条并停止（要求修正 scheme.yaml）。
+
+2. 构建工具一致性（必须）：
+   - 若 `build_tool=vite`：
+     - 原型工程必须存在 `vite.config.*` 与 `index.html`
+     - `package.json` 必须包含 `vite` 依赖（devDependencies 或 dependencies）
+   - 若 `build_tool` 为其他值：必须能在工程中找到对应的构建配置与依赖（按该栈条目约定）；找不到则输出问题。
+
+3. 框架一致性（必须）：
+   - 若 `framework=vue`：
+     - `package.json` 必须包含 `vue`
+     - 必须包含 Vite Vue 插件：`@vitejs/plugin-vue`
+     - 必须存在 `src/main.ts` 或 `src/main.js`，且存在 `src/router/`（或等价路由目录）
+   - 若 `framework=react`：
+     - `package.json` 必须包含 `react` 与 `react-dom`
+     - 必须包含 Vite React 插件：`@vitejs/plugin-react`（或等价官方插件）
+     - 必须存在 `src/main.tsx`/`src/main.jsx`（或等价入口），且存在 `src/router/`（或等价路由目录）
+
+4. 反例拦截（必须）：
+   - 若原型仅存在若干 html 文件（例如 `scenario.html`、`entries.html`）但缺少工程化结构（package.json/src/vite 配置）：判定为不合规，输出问题并停止。
+
+输出要求（必须）：
+1. 若所有检查通过：仅输出单行 `PASS`。
+2. 若存在问题：仅输出“问题列表”（不要输出修复方案、不要输出其他内容），格式固定如下：
+   - `问题列表（post-verify-stack-verify）`
+   - 逐条编号：`1. ...`
+   - 每条必须包含：问题类型（stack 不一致 / 缺少工程化结构 / scheme.yaml 不完整）+ 影响（无法构建/无法维护/无法按规范交付）+ 定位信息（文件路径 + 期望值 vs 实际值）

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

@@ -45,6 +45,9 @@
 8. 前端交互（必须）：
    - 支付入口必须从订单/业务单详情进入（说明路由或入口）
    - 提交成功后跳转到成功页（如 `/payment/success` 或业务 `*/success`），失败必须给出中文完整句子提示与重试入口
+   - 若存在退款：退款成功后订单必须仍保留在订单列表/详情中，并标记为“已退款”，且可追溯退款信息（金额/时间/退款单号 mock）
+9. 发票/开票（命中则必须）：
+   - 若涉及订单/支付且存在开票需求：必须说明发票申请入口、字段（抬头/税号/邮箱/内容类目）、状态流转（未开票/开票中/已开票）、下载/预览与记录查询
 9. 操作日志与通知（必须）：
    - 支付/退款关键动作必须记录日志（字段：单号/金额/通道/结果/失败原因/操作者/时间）
    - 通知：支付成功/退款成功/退款失败至少覆盖 3 类，并说明失败兜底

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

@@ -63,6 +63,10 @@
      - 支付：支付下单/发起、支付渠道选择/配置、支付回调处理（幂等/签名校验）、支付失败重试/超时关闭、支付结果查询
      - 退款：退款申请/审批（如适用）、退款执行/回调处理、部分退款口径（如适用）、退款失败重试/人工兜底
      - 对账：对账任务（端=Job）或对账页面（端=Web）之一必须具备，包含差异识别与修复入口
+   - 若存在订单/支付语义：必须补齐“发票/开票”能力（至少在 core.md 中体现）：
+     - 开票申请入口（端=Web；入口=/orders 或 /invoices）
+     - 发票信息维护（抬头/税号/邮箱/发票内容），以及发票状态（未开票/开票中/已开票）
+     - 发票下载/预览（PDF）与开票记录查询
    - 若发现生命周期不完整：必须在输出前补全 `core.md`（或对应外部系统 functions 文件）的功能行，直到对象生命周期闭环
    - 示例口径（用于你自检，不要生搬硬套）：
      - 有“优惠”能力：应覆盖优惠创建/配置、审批（如需要）、发放/绑定、使用/核销、延续（延期/续期/扩展额度）、失去（失效/作废/撤销/回收）、归档与审计
@@ -126,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` 补齐通知中心（列表/详情/已读未读/批量处理）与消息模板管理（可选）
 

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（列表展示）
@@ -92,13 +93,26 @@
        - 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. 场景粒度与数量控制：
@@ -114,7 +128,13 @@
      - 基础数据/主数据维护（CRUD：列表/新建/编辑/启停/导入导出等；若明确来自外部系统同步，则以“同步/对接”场景替代 CRUD）
      - 审批与流程配置（存在审批语义时：审批流配置、审批列表处理、审批意见与结果提交）
      - 支付与退款（出现支付/退款/结算/对账/订单等语义时：必须补齐支付成功/失败/超时关闭/退款/部分退款/退款失败/对账差异等关键场景）
+     - 草稿与发布（出现草稿/发布/上架/下架/生效/失效/投放等语义时：必须补齐“草稿→发布/生效→下线/失效→归档”的场景）
+     - MQ 排队（出现队列/MQ/异步/排队/批处理/削峰等语义时：必须补齐入队、消费、重试、死信与人工兜底场景）
+     - 定时任务（出现定时/cron/到期/超时/SLA/自动关闭/自动失效/自动通知/对账等语义时：必须补齐定时扫描、到期处理、通知补偿、对账与差异修复场景）
    - 上述能力的场景在场景表中至少各出现 1 个（若适用），并确保与主业务场景形成可演示闭环（例如：先维护课程/讲师/学员，再发起排课申请）。
+   - 登录场景补齐要求（命中则必须在场景表中体现）：
+     - 至少包含 3 条：登录成功、登录失败（密码错误/验证码错误）、退出登录
+     - 若需求出现“忘记密码/重置密码/修改密码/注册/创建账号”任一语义：对应场景必须补齐
    - 支付与退款场景细化要求（命中则必须在场景表中体现）：
      - 支付：下单→支付（成功/失败/取消/超时关闭）→支付结果通知/回调→订单状态落地
      - 退款：发起退款→审核/审批（如适用）→退款成功/失败→原订单/权益回收与对账记录

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

@@ -639,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 金刚区可进入：
@@ -804,6 +814,13 @@ Steps（步骤条）使用要求（必须）：
      - 表单输入金额：使用 InputNumber 的 formatter/parser（或等价实现），保持两位小数与千位分隔符一致
    - 枚举/状态：必须使用 Select/Radio/Tag，并与模型/状态机对齐
    - 地点：若包含省市区/详细地址，必须拆分（Cascader + Input）
+   - 移动端数据选择（必须）：移动端页面选择“数据对象/字典项/主数据”（例如城市、组织、门店、人员、商品、课程等）时，禁止使用下拉框 Select 直接在当前页选择。
+     - 必须改为“点选进入选择页（List）→ 列表搜索/筛选 → 点击条目选中 → 返回上一页并回填字段”的交互。
+     - 表单页中该字段应表现为“只读输入框/Cell”，点击后跳转到 `/m/select/<entity>`（或模块内等价路由），并在选择页顶部提供返回与搜索。
+     - 选择页列表必须使用移动端 List/Card（禁止 Table），并且选中后给出中文提示并立即返回。
+   - 移动端城市选择（命中则必须）：若出现移动端“选择城市/切换城市/城市列表”页面或控件（例如 `/m/city` 或城市选择弹层）：
+     - 必须使用“城市列表 + 右侧字母索引条（A-Z）”的交互，点击字母可快速跳转到对应首字母分组
+     - 城市列表必须按首字母分组展示，并支持搜索
 3. 对“复合字段”的判定口径：字段名或说明中出现“起止/范围/地址/联系人/额度/资源+数量/城市+地点”等组合语义时，一律拆分。
 
 交互样式统一（必须）：

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

@@ -21,13 +21,18 @@
 会话与拦截（必须）：
 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）：

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

@@ -22,6 +22,8 @@ Web 全局布局（必须）：
 
 移动端布局（必须）：
 1. 移动端页面必须独立路由前缀：`/m/*`，并使用移动端布局（顶部简化 Header + 内容区 +（按需）底部吸底操作栏/TabBar），不复用后台三段式布局。
+   - 底部 TabBar（必须）：只要原型生成了 2 个及以上移动端页面，就必须实现底部 TabBar，并按实际移动端功能分布放置 icon + 文案（示例：首页/任务/消息/我的）；当前 Tab 高亮必须随路由变化。
+   - 布局固定规则（必须）：TabBar 必须 fixed 吸底；中间内容区必须可滚动（Scroll），不得因为 TabBar 导致内容被遮挡；建议通过 `padding-bottom` 为内容区预留 TabBar 高度。
 2. Web 端左侧菜单不展示移动端专属页面入口；Web 端对应动作按钮必须置灰并提示“请在手机端操作”，并提供一个“打开手机端页面”的入口（可复制链接或跳转）。
 
 场景验证入口（必须禁止）：

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，并在返回订单详情与列表时可见变化。
-