visual-spec 0.1.3 → 0.1.7

package/README.md

@@ -7,7 +7,6 @@ This repo provides a requirements analysis and delivery assistant Skill. It offe
 - Detailed design: produce RBAC/data-permission/interaction/validation/logging/notification/MQ/import-export/cron specs per function
 - Acceptance & testing: generate acceptance cases and automated test code
 - Integrated implementation: generate backend + frontend integrated code (aligned with the repo’s actual stack and conventions)
-- Change handling: analyze impacts, update artifacts, and produce a change log
 - Planning: estimate and schedule based on the function list (HTML output)
 
 ## Commands
@@ -18,10 +17,9 @@ This repo provides a requirements analysis and delivery assistant Skill. It offe
 - `/vspec:detail`: Generate per-function detailed specs (writes to `/specs/details/`)
 - `/vspec:verify`: Generate data models and a stack-selected runnable prototype (per `/scheme.yaml`) (writes to `/specs/models/`, `/specs/prototypes/`; requires non-empty `/specs/details/`)
 - `/vspec:accept`: Generate acceptance test cases (writes to `/specs/acceptance/`)
-- `/vspec:test`: Generate automated test code (writes into the repo’s existing test directories or `/tests/`)
+- `/vspec:append-test`: Generate automated test code (writes into the repo’s existing test directories or `/tests/`)
 - `/vspec:impl`: Generate integrated backend + frontend implementation code (writes under `/specs/`)
 - `/vspec:upgrade`: Upgrade/redesign based on legacy + new inputs under `/docs/` (legacy/current/templates/texts/assets), generate/update `/specs/`, and sync technical selections to `/scheme.yaml`
-- `/vspec:change`: Analyze and apply change inputs from `/docs/change/`, update artifacts, and write `/specs/change_log.md` (requires a git snapshot commit before updating)
 - `/vspec:qc`: Run artifact quality checks and write a report (writes to `/specs/qc_report.md`)
 - `/vspec:plan`: Generate estimation and schedule (writes to `/specs/plan/plan_estimate.md`, `/specs/plan/plan_schedule.html`)
 
@@ -33,3 +31,4 @@ This repo provides a requirements analysis and delivery assistant Skill. It offe
 ## Licensing / Plans
 
 - `prompts/harness/*` (post-run validation commands) is a paid feature and is only available in the Pro edition.
+- Pro edition adds broader quality checks across commands (e.g. prototype stack verification, click-no-op detection, mobile UX checks, price formatting checks, and backend MVC/test coverage checks) and requires a paid plan to enable.

package/docs/en-US/commands.md

@@ -8,10 +8,9 @@
 | `/vspec:detail` | Expand per-function detailed specs | `/specs/functions/*` + supporting artifacts (background/flows/roles; models if any) | `/specs/details/<function_slug>/*` (RBAC, interaction, validation, logging, notifications, MQ, import/export, cron, etc.) |
 | `/vspec:verify` | Generate models and prototype for fast validation | Existing `/specs/` artifacts (functions + details + roles) | `/specs/models/*.md`, `/specs/prototypes/` (stack-selected runnable prototype + `scenario.html` review page) |
 | `/vspec:accept` | Generate acceptance test cases | functions/scenarios/details/roles/models | `/specs/acceptance/<function_slug>/acceptance_cases.md`, `/specs/acceptance/index.md` |
-| `/vspec:test` | Generate automated test code | acceptance cases + repo test stack | Writes into existing test directories or `/tests/` |
+| `/vspec:append-test` | Generate automated test code | acceptance cases + repo test stack | Writes into existing test directories or `/tests/` |
 | `/vspec:impl` | Generate integrated backend + frontend implementation | specs/details/models/dependencies | Writes integrated implementation code (API contract, backend, frontend integration) |
 | `/vspec:upgrade` | Analyze and generate new specs based on legacy materials | `/docs/current/file_list.md` + `/docs/legacy/*` (optional templates/texts/assets) + existing `/specs/background/original.md` (if any) | Generate/update `/specs/` in `/vspec:new` structure + sync technical selections to `/scheme.yaml` |
-| `/vspec:change` | Apply change inputs, do impact analysis, and update artifacts | `/docs/change/*` (optional file_list.md) + existing `/specs/` | Update impacted files (prefers `/specs/details/<module_slug>/`) + `/specs/change_log.md` (requires git snapshot commit before updating) |
 | `/vspec:qc` | Run quality checks on `/specs/` artifacts | built-in standard + optional project `quality_standard.md` + `/specs/` | `/specs/qc_report.md` |
 | `/vspec:plan` | Estimation and scheduling | functions/roles/flows/dependencies/details | `/specs/plan/plan_estimate.md`, `/specs/plan/plan_schedule.html` |
 
@@ -55,24 +54,17 @@
 - When to use: align delivery and acceptance with an executable set of cases
 - Key outputs: per-function acceptance case tables covering happy path, exceptions, boundaries, RBAC, and data permissions
 
-## `/vspec:test`
+## `/vspec:append-test`
 
 - When to use: turn acceptance cases into runnable automated tests (E2E/API/unit)
 - Key outputs: reuse the repo’s existing test frameworks and scripts; avoid introducing new dependencies
+- Note: `/vspec:append-test` generates/adds test code to improve coverage; it does not run test commands (e.g. mvn test/pytest/go test).
 
 ## `/vspec:impl`
 
 - When to use: convert spec artifacts into runnable integrated backend + frontend code
 - Key outputs: API contract, backend implementation, frontend pages and API integration, RBAC/state machine enforcement
 
-## `/vspec:change`
-
-- When to use: explicit change requests arrive and you need traceable updates and impact assessment
-- Inputs: read from `/docs/change/` (optional `/docs/change/file_list.md` as an ordered entry list; compatible with legacy path `/docs/changes/`)
-- Update strategy: prioritize the impacted module directory `/specs/details/<module_slug>/` and sync models/functions/prototypes/acceptance as needed
-- Pre-update snapshot: if the target repo is a git repo, create a snapshot commit before writing any updates so diffs are reviewable
-- Key outputs: structured change list, impact analysis table, change log, and corresponding artifact updates
-
 ## `/vspec:upgrade`
 
 - When to use: do an “upgrade/redesign/migration” analysis based on legacy system materials, inherit what is needed, and generate new spec artifacts

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
@@ -46,8 +46,7 @@ yarn dlx -p visual-spec vspec
 - Quick validation (models + prototype): `/vspec:verify` (build runnable prototypes from functions + details + models; requires non-empty `/specs/details/`)
 - Acceptance cases: `/vspec:accept` (turn key scenarios into reviewable acceptance checklists)
 - Integrated implementation: `/vspec:impl` (implementation inputs and structure constraints: models/services/repositories/exceptions, etc.)
-- Automated tests: `/vspec:test` (test plan and automation skeletons)
-- Change handling: `/vspec:change` (impact analysis and artifact updates)
+- Automated tests: `/vspec:append-test` (test plan and automation skeletons)
 - Upgrade/redesign (inherit from legacy materials): `/vspec:upgrade` (normalize legacy/current materials into new specs and selections)
 
 ### 3. Key Directories
@@ -76,7 +75,6 @@ Next:
 #### Changes (`change`)
 
 - Put change materials into `/docs/change/` (optional `file_list.md`)
-- Run: `/vspec:change`
 - Result: performs impact analysis, updates artifacts (prefers `/specs/details/<module_slug>/`), and updates the change log
 
 #### Upgrade/Redesign (`upgrade`)

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/en-US/structure.md

@@ -14,7 +14,7 @@ The Skill generates artifacts under `/specs/` (incrementally by command stage) a
 │  ├─ legacy/                             # Legacy system materials (features, permissions, interactions, APIs, etc.)
 │  ├─ current/                            # New/additional materials for this iteration (goals, deltas, flows, UI constraints, etc.)
 │  │  └─ file_list.md                     # Upgrade entry list (/vspec:upgrade reads/generates)
-│  ├─ change/                             # Change inputs (/vspec:change reads)
+│  ├─ change/                             # Change inputs archive (optional)
 │  │  └─ file_list.md                     # Optional ordered input list
 │  ├─ refine/                             # Refinement inputs (/vspec:refine reads)
 │  │  └─ file_list.md                     # Optional ordered input list
@@ -62,7 +62,7 @@ The Skill generates artifacts under `/specs/` (incrementally by command stage) a
    ├─ plan/                                # Planning outputs (/vspec:plan output)
    │  ├─ plan_estimate.md                  # Estimation
    │  └─ plan_schedule.html                # Schedule page
-   └─ change_log.md                        # Change log (/vspec:change output)
+   └─ change_log.md                        # Change log (optional)
 ```
 
 Notes:

package/docs/en-US/workflows.md

@@ -36,10 +36,11 @@ Optional: segmented prototype generation
 - Generate acceptance cases into `/specs/acceptance/`
 - Goal: define acceptance criteria and coverage (happy path, exceptions, boundaries, RBAC, data permissions)
 
-### 5. Automated Tests (`/vspec:test`)
+### 5. Automated Tests (`/vspec:append-test`)
 
 - Read acceptance cases and the repo’s existing test stack
 - Generate a minimal runnable set of E2E/API/unit tests
+- Note: this step only generates/adds test code to improve coverage; it does not run test commands (e.g. mvn test).
 
 ### 6. Integrated Implementation (`/vspec:impl`)
 
@@ -53,11 +54,6 @@ Optional: segmented prototype generation
   - `/specs/plan/plan_estimate.md`
   - `/specs/plan/plan_schedule.html`
 
-### 8. Change Handling (`/vspec:change`)
-
-- Provide change inputs
-- Output impact analysis and change log, and update impacted artifacts and cases
-
 ## Installation (npm)
 
 - Recommended at your project root: `npm install <git-url>`

package/docs/zh-CN/commands.md

@@ -8,10 +8,9 @@
 | `/vspec:detail` | 展开到“可实现”的单功能详细规格 | `/specs/functions/*` + 支撑产物（background/flows/roles；models 若已存在） | `/specs/details/<function_slug>/*`（RBAC、交互、校验、日志、通知、MQ、导入导出、定时任务等） |
 | `/vspec:verify` | 快速验证：生成模型与可运行原型用于评审 | 现有 `/specs/` 产物（functions + details + roles） | `/specs/models/*.md`、`/specs/prototypes/`（按 `scheme.yaml` 选栈生成可运行原型 + `scenario.html` 评审页） |
 | `/vspec:accept` | 生成验收用例 | functions/scenarios/details/roles/models | `/specs/acceptance/<function_slug>/acceptance_cases.md`、`/specs/acceptance/index.md` |
-| `/vspec:test` | 生成自动化测试代码 | 验收用例 + 仓库测试技术栈 | 写入既有测试目录或 `/tests/` |
+| `/vspec:append-test` | 生成自动化测试代码 | 验收用例 + 仓库测试技术栈 | 写入既有测试目录或 `/tests/` |
 | `/vspec:impl` | 生成后端 + 前端联调实现代码 | specs/details/models/dependencies | 写入集成实现代码（API 合同、后端、前端对接） |
 | `/vspec:upgrade` | 基于遗留材料做升级/重构分析并生成新规格 | `/docs/current/file_list.md` + `/docs/legacy/*`（可选 templates/texts/assets）+ 既有 `/specs/background/original.md`（可选） | 生成/更新 `/specs/`（沿用 `/vspec:new` 结构）+ 同步技术选型到 `/scheme.yaml` |
-| `/vspec:change` | 处理变更：影响分析并更新产物 | `/docs/change/*`（可选 file_list.md）+ 既有 `/specs/` | 更新受影响文件（优先 `/specs/details/<module_slug>/`）+ `/specs/change_log.md`（更新前需要 git 快照提交） |
 | `/vspec:qc` | 对 `/specs/` 产物做质量检查 | 内置标准 + 可选 `quality_standard.md` + `/specs/` | `/specs/qc_report.md` |
 | `/vspec:plan` | 估算与排期 | functions/roles/flows/dependencies/details | `/specs/plan/plan_estimate.md`、`/specs/plan/plan_schedule.html` |
 
@@ -55,24 +54,17 @@
 - 适用场景：用“可执行用例”对齐交付与验收
 - 关键输出：每功能点验收用例表，覆盖主流程、异常、边界、RBAC、数据权限
 
-## `/vspec:test`
+## `/vspec:append-test`
 
 - 适用场景：将验收用例转化为可运行的自动化测试（E2E/API/单测）
 - 关键输出：优先复用仓库现有测试框架与脚本，避免引入新依赖
+- Note：`/vspec:append-test` 只生成/补齐测试代码以提升覆盖率，不负责执行测试命令（例如 mvn test/pytest/go test 等）。
 
 ## `/vspec:impl`
 
 - 适用场景：把规格产物转成可运行的后端 + 前端联调实现
 - 关键输出：API 合同、后端实现、前端页面与 API 对接、RBAC/状态机约束落地
 
-## `/vspec:change`
-
-- 适用场景：收到明确变更请求，需要可追溯的影响评估与更新
-- 输入：从 `/docs/change/` 读取（可选 `/docs/change/file_list.md` 作为有序输入清单；兼容旧路径 `/docs/changes/`）
-- 更新策略：优先更新受影响模块目录 `/specs/details/<module_slug>/`，并同步 models/functions/prototypes/acceptance 等
-- 更新前快照：若目标仓库是 git 仓库，更新前先做一次快照提交，保证差异可审查
-- 关键输出：结构化变更清单、影响分析表、变更日志以及对应产物更新
-
 ## `/vspec:upgrade`
 
 - 适用场景：基于遗留系统材料做“升级/重构/迁移”分析，继承必要部分并生成新规格

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. 推荐流程
@@ -46,8 +46,7 @@ yarn dlx -p visual-spec vspec
 - 快速验证（模型 + 原型）：`/vspec:verify`（基于 functions + details + models 生成可运行原型；要求 `/specs/details/` 非空）
 - 验收用例：`/vspec:accept`（把关键场景转成可执行的验收点/检查表）
 - 集成实现：`/vspec:impl`（生成后端/前端的实现输入与工程骨架约束，包含模型/Service/Repository/异常等）
-- 自动化测试：`/vspec:test`（生成可落地的测试计划与自动化用例骨架）
-- 变更处理：`/vspec:change`（基于变更材料做影响分析，并更新受影响产物）
+- 自动化测试：`/vspec:append-test`（生成可落地的测试计划与自动化用例骨架）
 - 升级/重构（继承遗留材料）：`/vspec:upgrade`（把 legacy/current 材料归一成新的 specs 与选型）
 
 ### 3. 关键目录
@@ -76,7 +75,6 @@ yarn dlx -p visual-spec vspec
 #### 变更（`change`）
 
 - 把变更材料放到 `/docs/change/`（可选 `file_list.md`）
-- 运行：`/vspec:change`
 - 结果：做影响分析并更新产物（优先 `/specs/details/<module_slug>/`），同时更新变更日志
 
 #### 升级/重构（`upgrade`）

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/docs/zh-CN/structure.md

@@ -13,7 +13,7 @@ Skill 会按命令阶段逐步在 `/specs/` 下生成产物，并维护少量项
 │  ├─ legacy/                             # 遗留系统材料（功能、权限、交互、API 等）
 │  ├─ current/                            # 本次迭代新增/补充材料（目标、差异、流程、UI 约束等）
 │  │  └─ file_list.md                     # upgrade 入口清单（/vspec:upgrade 读取/生成）
-│  ├─ change/                             # 变更输入（/vspec:change 读取）
+│  ├─ change/                             # 变更输入归档（可选）
 │  │  └─ file_list.md                     # 可选：有序输入清单
 │  ├─ refine/                             # 补充/澄清输入（/vspec:refine 读取）
 │  │  └─ file_list.md                     # 可选：有序输入清单
@@ -61,7 +61,7 @@ Skill 会按命令阶段逐步在 `/specs/` 下生成产物，并维护少量项
    ├─ plan/                               # 规划输出（/vspec:plan 输出）
    │  ├─ plan_estimate.md                 # 估算
    │  └─ plan_schedule.html               # 排期页面
-   └─ change_log.md                       # 变更日志（/vspec:change 输出）
+   └─ change_log.md                       # 变更日志（可选）
 ```
 
 说明：

package/docs/zh-CN/workflows.md

@@ -36,10 +36,11 @@
 - 在 `/specs/acceptance/` 下生成验收用例
 - 目标：定义验收口径与覆盖范围（主流程、异常、边界、RBAC、数据权限）
 
-### 5. 自动化测试（`/vspec:test`）
+### 5. 自动化测试（`/vspec:append-test`）
 
 - 读取验收用例与仓库现有测试技术栈
 - 生成最小可运行的一组 E2E/API/单测
+- Note：该步骤只生成/补齐测试代码以提升覆盖率，不负责执行测试命令（例如 mvn test）。
 
 ### 6. 集成实现（`/vspec:impl`）
 
@@ -53,11 +54,6 @@
   - `/specs/plan/plan_estimate.md`
   - `/specs/plan/plan_schedule.html`
 
-### 8. 变更处理（`/vspec:change`）
-
-- 提供变更输入
-- 输出影响分析与变更日志，并更新受影响的产物与用例
-
 ## 安装（npm）
 
 - 推荐在目标项目根目录安装：`npm install <git-url>`

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "visual-spec",
-  "version": "0.1.3",
+  "version": "0.1.7",
   "description": "AI skill: visual-spec-skill (/vspec:* commands) for requirement analysis, prototyping, detailing, testing, and planning.",
   "license": "MIT",
   "type": "commonjs",
@@ -13,7 +13,18 @@
     "dry-run": "node scripts/postinstall.cjs --dry-run"
   },
   "files": [
-    "skills/visual-spec-skill/",
+    "skills/visual-spec-skill/SKILL.md",
+    "skills/visual-spec-skill/SKILL-zh-CN.md",
+    "skills/visual-spec-skill/prompts/vspec_accept/",
+    "skills/visual-spec-skill/prompts/vspec_detail/",
+    "skills/visual-spec-skill/prompts/vspec_impl/",
+    "skills/visual-spec-skill/prompts/vspec_new/",
+    "skills/visual-spec-skill/prompts/vspec_plan/",
+    "skills/visual-spec-skill/prompts/vspec_qc/",
+    "skills/visual-spec-skill/prompts/vspec_refine/",
+    "skills/visual-spec-skill/prompts/vspec_test/",
+    "skills/visual-spec-skill/prompts/vspec_upgrade/",
+    "skills/visual-spec-skill/prompts/vspec_verify/",
     "bin/",
     "docs/",
     "scripts/",

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`
 
@@ -175,6 +179,8 @@ description: "将原始需求分析为可评审的视觉规格，并生成相关
 
 用于对 `/specs/` 下生成的需求产物进行质量检查。
 
+Note：Pro 版支持更广泛的质量检测能力（例如更完整的原型/实现后校验项等），需要付费开通。
+
 流程：
 1. 读取内置标准 `prompts/vspec_qc/quality_standard.md`。
 2. 若项目 `qc/` 下存在“需求质量错误簿”，则据此生成/更新项目根目录的 `quality_standard.md`。
@@ -191,7 +197,7 @@ description: "将原始需求分析为可评审的视觉规格，并生成相关
 2. 加载 `prompts/vspec_accept/accept.md` 生成验收用例，覆盖主流程、异常、边界、权限与数据范围。
 3. 将结果写入 `/specs/acceptance/`（按功能建子目录），并生成 `/specs/acceptance/index.md` 索引。
 
-### `/vspec:test`
+### `/vspec:append-test`
 
 用于基于验收用例与规格生成自动化测试代码。
 
@@ -199,6 +205,10 @@ description: "将原始需求分析为可评审的视觉规格，并生成相关
 1. 读取 `/specs/acceptance/`、`/specs/functions/*`、`/specs/details/`，并识别仓库中已有的测试框架。
 2. 加载 `prompts/vspec_test/test.md`，按既有框架与约定生成自动化测试。
 3. 将测试代码写入项目测试目录（若不存在标准目录则写入 `/tests/`），并确保能通过已有脚本运行。
+4. 加载 `prompts/harness/post_append_test_coverage_check.md` 检查测试覆盖率是否足够完整；若输出了问题列表，则继续执行下一步。
+5. 若存在问题列表：基于缺失项再次运行一次 `/vspec:append-test`（只补缺失项），然后再次运行覆盖检查。
+6. 若第二次覆盖检查仍输出问题列表：提示问题并立即结束。
+7. 本指令用于补齐测试代码以提升覆盖率，不负责执行测试命令（例如 mvn test）。
 
 ### `/vspec:impl`
 
@@ -208,6 +218,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`
 
@@ -220,17 +231,6 @@ description: "将原始需求分析为可评审的视觉规格，并生成相关
 4. 加载 `prompts/vspec_upgrade/upgrade.md`，按 `/vspec:new` 产物约定生成/更新 `/specs/`。
 5. 将抽取到的技术规格同步到 `/scheme.yaml`，供 `/vspec:verify` 与 `/vspec:impl` 使用。
 
-### `/vspec:change`
-
-用于响应需求变更并更新受影响产物。
-
-流程：
-1. 读取 `/docs/change/` 下的变更输入（若存在优先用 `/docs/change/file_list.md` 作为入口；若仅存在 `/docs/changes/` 则兼容读取）。
-2. 若目标仓库为 git 仓库，在写入任何更新前先创建变更前快照提交，保证 diff 可审查。
-3. 读取已存在的 `/specs/` 产物（包括 `/specs/details/`、`/specs/models/`、`/specs/prototypes/`）。
-4. 加载 `prompts/vspec_change/change.md` 做影响分析并更新受影响文档，优先更新 `/specs/details/<module_slug>/` 下的模块详情文档。
-5. 写入更新后的产物，并将变更日志写入 `/specs/change_log.md`。
-
 ### `/vspec:plan`
 
 用于把需求拆解为故事地图并进行估算与排期。
@@ -287,5 +287,4 @@ description: "将原始需求分析为可评审的视觉规格，并生成相关
 - `prompts/vspec_test/test.md`：生成自动化测试的提示词。
 - `prompts/vspec_impl/implement.md`：生成前后端集成实现的提示词。
 - `prompts/vspec_upgrade/upgrade.md`：生成升级/改造规格的提示词。
-- `prompts/vspec_change/change.md`：处理变更的提示词。
 - `prompts/vspec_plan/estimate.md`：生成估算的提示词。

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`
 
@@ -176,6 +180,8 @@ Flow:
 
 Use this command to run a quality check on the generated requirement artifacts under `/specs/`.
 
+Note: The Pro edition supports broader quality checks (e.g. more post-run prototype/implementation verifications) and requires a paid plan.
+
 Flow:
 1. Read built-in standard at `prompts/vspec_qc/quality_standard.md`.
 2. If a requirement quality error book exists under project `qc/`, generate/update project root `quality_standard.md` based on it.
@@ -192,7 +198,7 @@ Flow:
 2. Load `prompts/vspec_accept/accept.md` to generate acceptance test cases covering core flows, exceptions, boundary, permissions, and data scope.
 3. Write results to `/specs/acceptance/` (one subfolder per function) and generate an index at `/specs/acceptance/index.md`.
 
-### `/vspec:test`
+### `/vspec:append-test`
 
 Use this command to generate automation test code based on acceptance cases and specs.
 
@@ -200,6 +206,10 @@ Flow:
 1. Read `/specs/acceptance/`, `/specs/functions/*`, `/specs/details/`, and detect the existing test frameworks in the repository.
 2. Load `prompts/vspec_test/test.md` to generate automation tests using the existing frameworks and conventions.
 3. Write test code to the project test directories (or `/tests/` if no standard exists) and ensure it can run with existing scripts.
+4. Load `prompts/harness/post_append_test_coverage_check.md` to verify whether test coverage is sufficiently complete; if it outputs any issues, continue.
+5. If issues exist, rerun `/vspec:append-test` once focusing only on the missing items from the issue list, then rerun the coverage check.
+6. If issues still exist after the second coverage check, show the issue list and stop.
+7. This command generates/adds tests to improve coverage; it does not execute test commands.
 
 ### `/vspec:impl`
 
@@ -209,6 +219,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`
 
@@ -221,17 +232,6 @@ Flow:
 4. Load `prompts/vspec_upgrade/upgrade.md` and generate/update artifacts under `/specs/`, reusing `/vspec:new` output conventions.
 5. Sync extracted technical spec into `/scheme.yaml` so it can be used by `/vspec:verify` and `/vspec:impl`.
 
-### `/vspec:change`
-
-Use this command to respond to requirement changes and update impacted artifacts.
-
-Flow:
-1. Read change inputs under `/docs/change/` (prefer `/docs/change/file_list.md` as the entry if present; if only `/docs/changes/` exists, read from there for compatibility).
-2. If the target repository is a git repo, create a pre-change snapshot commit before writing any updates, so diffs are reviewable.
-3. Read existing artifacts under `/specs/` (including `/specs/details/`, `/specs/models/`, `/specs/prototypes/`) if present.
-4. Load `prompts/vspec_change/change.md` to analyze impact and update affected documents, focusing on updating impacted module detail docs under `/specs/details/<module_slug>/`.
-5. Write updated artifacts and a change log to `/specs/change_log.md`.
-
 ### `/vspec:plan`
 
 Use this command to break down requirements, estimate efforts, and schedule via a user story map.
@@ -285,10 +285,9 @@ Flow:
 - `prompts/vspec_detail/file_export.md`: the prompt used by `/vspec:detail` to generate file export docs.
 - `prompts/vspec_detail/cron_job.md`: the prompt used by `/vspec:detail` to generate scheduled job docs.
 - `prompts/vspec_accept/accept.md`: the prompt used by `/vspec:accept` to generate acceptance test cases.
-- `prompts/vspec_test/test.md`: the prompt used by `/vspec:test` to generate automation test code.
+- `prompts/vspec_test/test.md`: the prompt used by `/vspec:append-test` to generate automation test code.
 - `prompts/vspec_impl/implement.md`: the prompt used by `/vspec:impl` to generate integrated frontend/backend code.
 - `prompts/vspec_upgrade/upgrade.md`: the prompt used by `/vspec:upgrade` to generate upgraded specs from `/docs/` inputs.
-- `prompts/vspec_change/change.md`: the prompt used by `/vspec:change` to handle requirement changes.
 - `prompts/vspec_plan/estimate.md`: the prompt used by `/vspec:plan` to generate `/specs/plan/plan_estimate.md`.
 - `prompts/vspec_plan/schedule.md`: the prompt used by `/vspec:plan` to generate `/specs/plan/plan_schedule.html`.
 - `prompts/vspec_qc/qc.md`: the prompt used by `/vspec:qc` to generate `/specs/qc_report.md`.

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_test/test.md

@@ -12,17 +12,34 @@
    - 后端：检查是否有 jest/mocha/pytest/junit/spring test/go test 等
    - 若存在既有测试目录与脚本（例如 `npm test`、`pnpm test`、`mvn test`、`pytest`），必须复用并遵循现有约定
 2. 不要新增或修改依赖版本；只在“已有依赖可支持”的前提下生成代码
-3. 测试分层：
+3. 本指令只负责“补齐测试代码/提升覆盖率”，不负责执行测试命令：
+   - 禁止调用或要求用户执行 `mvn test`、`gradle test`、`pytest`、`go test`、`npm test` 等命令作为本指令输出的一部分
+   - 允许在输出中给出“可选的验证命令”供用户自行运行，但不得将其作为必做步骤来阻塞产出
+4. 测试分层：
    - E2E：覆盖 P0 主流程与关键回退（取消/变更/驳回/紧急叫停）
    - API/集成：覆盖核心接口的权限、校验、状态机
    - 单元：覆盖关键规则函数/状态流转判定（如可定位）
-4. 用例到自动化的映射：
+   - 追加要求（必须）：
+     - 集成测试：必须创建“端到端业务链路”的集成测试用例（对后端为主：Controller→Service→Repository 的真实调用；必要时用测试数据库/内存存储），用于验证主流程闭环
+     - domain 单元测试：必须补齐各个 domain 下函数/聚合/领域服务的单元测试，覆盖核心分支与边界
+     - util 单元测试：必须补齐 util 下工具函数的单元测试（包含格式化、校验、计算、日期/金额处理等）
+     - service mock 测试：必须为 service 层补齐 mock 依赖的测试（例如 mock repository/adapter/external client），覆盖异常与重试等分支
+     - API mock 测试：必须为外部 API/回调/第三方依赖补齐 mock 测试（mock HTTP client/SDK），覆盖成功/失败/超时/重试与幂等
+5. 用例到自动化的映射：
    - 每个 P0 用例至少落地 1 条自动化测试
    - 在测试名称中保留用例编号（例如 `<function_slug>-AT-001`）
-5. 数据准备策略（必须说明并落地一种）：
+6. 数据准备策略（必须说明并落地一种）：
    - 通过 API/fixture 创建数据
    - 通过种子脚本/测试数据库（若仓库已有）
    - 通过 mock（仅限纯前端原型项目）
+7. 后端覆盖率补齐（命中则必须）：
+   - 若存在 `/specs/backend/`（由 `/vspec:impl` 生成后端工程）：优先在 `/specs/backend/` 内按其框架约定写入测试代码（而不是写到仓库根 `/tests/`）
+   - 重点补齐：Controller 接口、Service 核心分支、权限校验、状态机流转、支付/退款回调等关键路径
+   - 目录对齐要求（命中则必须，按现有工程结构裁剪）：
+     - `domain/`：补齐 domain 单元测试（核心分支 + 边界）
+     - `util/`：补齐 util 单元测试（金额/日期/字符串等）
+     - `service/`：补齐 service mock 测试（mock repository/adapter）
+     - `api/` 或 `controller/`：补齐 API mock 测试（mock 外部依赖/回调）
 
 输出与写入要求：
 1. 将测试代码写入仓库现有测试目录；若不存在，则写入 `/tests/`：

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

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

@@ -1,55 +0,0 @@
-你是一名资深需求分析质检员。你的任务是：在 `/vspec:new` 执行完成后，对“功能清单（functions）”与“节点细节（scenario_details）”做一致性与完备性验证；若发现缺失，必须输出“问题列表”，并停止。
-
-输入产物（必须读取）：
-- 功能清单：`/specs/functions/core.md`（以及 `/specs/functions/*.md` 中的外部系统文件）
-- 外部依赖：`/specs/background/dependencies.md`
-- 场景：`/specs/background/scenarios.md`
-- 节点细节目录：`/specs/background/scenario_details/`
-
-验证目标：
-1. 功能清单是否包含充分的：登录、参数/配置、基础数据/主数据维护（CRUD 或配置管理）、审批（含审批配置）等能力。
-2. 节点细节是否对这些能力给出充分分析（至少在 pre/post 中体现数据前置、配置前置、权限前置、外部同步/兜底）。
-
-验证规则（必须）：
-0. 产物存在性：
-   - 若 `core.md` 不存在：输出问题 1 条并停止。
-   - 若 `scenario_details/` 不存在或为空：输出问题 1 条并停止。
-
-1. 目录命名与文件齐全性（scenario_details）：
-   - 每个节点目录名必须匹配：`^[0-9]{2}_.+_.+$`（即 `01_模块_节点`）。
-   - 每个节点目录必须同时包含 5 个文件：`pre_post.md`、`constraints.md`、`variations.md`、`boundaries.md`、`symmetry.md`。
-   - 若任一目录不满足：记录问题（指出目录名或缺失文件）。
-
-2. 节点细节完备性（detail 分析）：
-   - 对每个 `pre_post.md`，必须覆盖以下四类信息（允许信息不足但不得空缺；信息不足时必须明确写“待确认/假设/Not Applicable”并给原因）：
-     - 数据前置：至少 1 个“主数据/基础数据/配置数据”依赖或明确写“无”
-     - 数据来源：明确“本系统维护/Excel 导入/外部系统同步”其一；若为外部系统同步，必须写明同步触发与兜底
-     - 权限前置：至少 1 个角色/任务引用或明确写“无”
-     - 配置前置：至少覆盖：字典/枚举 或 审批流配置 或 通知模板 或 时间窗口/SLA 其一（按节点适用）
-   - 若任一节点缺失上述任一类：记录问题（指出节点目录与缺失项）。
-
-3. functions（core.md）完备性：
-   - 先判断是否存在“审批语义”：
-     - 若 `scenarios.md` 的场景节点中包含 `approve(approve)`，或 flows/scenarios 文案出现“审批/通过/驳回/会签/加签/转交/复核”等，视为存在审批。
-   - 登录能力（必须）：
-     - 若 dependencies 中存在 SSO/OIDC/LDAP/IDaaS 等：必须存在对应外部系统 functions 文件（例如 `sso.md` 或等价命名）且包含登录相关对接能力；否则记录问题。
-     - 若不存在 SSO 等外部依赖：`core.md` 必须包含本系统登录能力（至少：登录、登出、会话/账号管理的最小闭环）；否则记录问题。
-   - 参数/配置能力（必须）：
-     - `core.md` 必须包含“系统参数/字典/枚举/通知模板/时间窗口/SLA”等至少 2 类可配置对象的维护入口；否则记录问题。
-   - 审批能力（命中则必须）：
-     - 若存在审批语义：`core.md` 必须包含审批列表/审批处理入口（端=Web）；
-     - 且必须包含“审批流配置/审批规则配置”入口（端=Web）；否则分别记录问题。
-   - 基础数据/主数据维护（必须）：
-     - 从 `scenario_details/*/pre_post.md` 的“数据前置/配置前置”中抽取候选“基础数据/主数据”对象清单（例如课程、讲师、学员、组织、资源、商品、仓库、字典项等）。
-     - 对每个对象，判断其数据来源：
-       - 若被明确标注为“外部系统同步/由某外部系统提供”：可不要求 core 里出现 CRUD，但必须在对应外部系统 functions 文件中出现同步/对接能力；否则记录问题。
-       - 否则：必须在 `core.md` 中存在该对象的维护入口（CRUD 或配置管理，端=Web）；否则记录问题。
-
-输出要求（必须）：
-1. 若不存在任何问题：仅输出单行 `PASS`。
-2. 若存在问题：仅输出“问题列表”（不要输出修复方案、不要输出其他内容），格式固定如下：
-   - `问题列表（post-new-verify）`
-   - 逐条编号：`1. ...`，每条必须包含：
-     - 问题类型（functions 缺失 / detail 缺失 / 命名不符合 / 外部同步缺失）
-     - 影响（会导致无法运行/无法演示/无法评审）
-     - 定位信息（文件路径或节点目录名）

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

@@ -1,43 +0,0 @@
-你是一名资深原型质量检查员。你的任务是：在 `/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_change/change.md

@@ -1,40 +0,0 @@
-你是一名资深产品经理 + 系统分析师。你的任务是：响应需求变更，做影响分析，并更新相关规格/模型/原型/测试产物，最后产出变更日志。
-
-输入信息包含：
-- 变更材料：`/docs/change/` 下的文件（必须读取并结构化；若仅存在 `/docs/changes/`，则兼容读取）
-- 用户提供的补充变更描述（如有）
-- 现有产物：`/specs/`（含 `/specs/models/`、`/specs/prototypes/`）
-
-执行步骤：
-0. 读取变更输入（必须）：
-   - 必须读取 `/docs/change/` 目录下的文件作为变更来源（若仅存在 `/docs/changes/`，则从 `/docs/changes/` 读取）
-   - 若存在 `file_list.md`：必须按其顺序逐个读取；否则按文件名排序读取
-   - 读取时必须抽取：变更背景、目标、影响范围、功能变更点、规则/字段变更、角色权限变更、接口/依赖变更、迁移/兼容性要求
-1. 更新前版本快照（必须）：
-   - 若当前项目处于 git 仓库中：在写入任何更新之前，必须先提交一次快照，以便清晰对比本次变更
-   - 快照提交要求：
-     - 提交内容：仅包含本次变更应用前的当前状态（禁止把本次变更的更新混入该提交）
-     - 提交信息建议：`chore: pre-change snapshot`（可附加变更编号/日期）
-2. 结构化变更输入（必须输出表格）：
-| 变更项 | 类型（新增/修改/删除） | 原行为/原规则 | 新行为/新规则 | 影响角色 | 影响数据对象 | 备注 |
-| --- | --- | --- | --- | --- | --- | --- |
-3. 影响分析（必须输出表格）：
-| 产物/模块 | 文件路径 | 影响类型（更新/新增/废弃） | 影响说明 | 风险 | 对应验收用例变更 |
-| --- | --- | --- | --- | --- | --- |
-4. 更新策略：
-   - 优先更新已有文件，避免不必要的新文件
-   - 对被废弃的规则/功能点，标记为废弃但保留可追溯
-   - 变更落地优先级：
-     - 优先更新 `/specs/details/<module_slug>/` 下受影响的明细规格（RBAC、数据权限、交互、校验矩阵、决策矩阵、状态机等）
-     - 若变更影响功能清单/场景：同步更新 `/specs/functions/*` 与 `/specs/background/scenarios.md`
-     - 若变更影响数据结构：同步更新 `/specs/models/*.md`
-     - 若变更影响原型：同步更新 `/specs/prototypes/`
-5. 产出变更日志（写入 `/specs/change_log.md`，表头固定）：
-| 日期 | 变更摘要 | 影响范围 | 产物更新清单 | 待确认问题 |
-| --- | --- | --- | --- | --- |
-6. 若变更影响到测试：
-   - 更新 `/specs/acceptance/` 中相关用例
-   - 标记受影响的自动化测试用例编号
-
-输出写入：
-- 更新相关规格文件并写入 `/specs/change_log.md`