visual-spec 0.1.2 → 0.1.4

package/README.md

@@ -29,3 +29,7 @@ This repo provides a requirements analysis and delivery assistant Skill. It offe
 
 - `skills/visual-spec-skill/SKILL.md`: Skill definition and command workflow
 - `skills/visual-spec-skill/prompts/`: prompt files used by each command
+
+## Licensing / Plans
+
+- `prompts/harness/*` (post-run validation commands) is a paid feature and is only available in the Pro edition.

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,28 +25,30 @@ 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
 
 - Initial spec: `/vspec:new`
-  - During execution it generates an open question list (`/specs/background/questions.md`)
-  - Fill in business answers in that file before continuing the workflow
-- Merge Q&A into the canonical requirement: `/vspec:refine-q`
-- Detailed specs: `/vspec:detail`
-- Quick validation (models + prototype): `/vspec:verify` (requires non-empty `/specs/details/`)
-- Acceptance cases: `/vspec:accept`
-- Integrated implementation: `/vspec:impl`
-- Automated tests: `/vspec:test`
-- Change handling: `/vspec:change`
-- Upgrade/redesign (inherit from legacy materials): `/vspec:upgrade`
+  - Midway it generates the canonical requirement file (`/specs/background/original.md`) and asks clarification questions
+  - Answer those questions in chat first, then type “continue” to finish `/vspec:new` (do not write these clarification answers into `questions.md`)
+  - It also generates an open question list (`/specs/background/questions.md`) for later merging
+- Merge Q&A into the canonical requirement: `/vspec:refine-q` (merge answered items from `/specs/background/questions.md` back into `original.md`)
+- Quality check: `/vspec:qc` (run a non-conformance check on generated `/specs/` artifacts and write `/specs/qc_report.md` before refinements/implementation)
+- Detailed specs: `/vspec:detail` (iterate all functions and generate RBAC, data permission, interaction, validation, state machine, etc.)
+- 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)
+- Upgrade/redesign (inherit from legacy materials): `/vspec:upgrade` (normalize legacy/current materials into new specs and selections)
 
 ### 3. Key Directories
 
@@ -57,7 +59,6 @@ yarn dlx -p visual-spec vspec
 Directory structure reference:
 
 - `structure.md`
- - `structure.md`
 
 Next:
 
@@ -67,7 +68,7 @@ Next:
 
 #### Refinements (`refine`)
 
-- Put refinement materials into `/docs/refine/`
+- Put refinement materials into `/docs/refine/refine.md` (use it as the primary entry; add other files under the folder only when needed)
 - Prerequisite: `/specs/details/` must exist and be non-empty, otherwise `refine` does not run
 - Run: `/vspec:refine`
 - Result: appends updates to `/specs/background/original.md` and syncs impacted `/specs/details/` and `/specs/prototypes/`

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,28 +25,30 @@ 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. 推荐流程
 
 - 初始规格：`/vspec:new`
-  - 执行过程中会生成开放问题清单（`/specs/background/questions.md`）
-  - 在继续流程前，把业务答案填写到该文件
-- 合并 Q&A 到需求口径：`/vspec:refine-q`
-- 详细规格：`/vspec:detail`
-- 快速验证（模型 + 原型）：`/vspec:verify`（要求 `/specs/details/` 非空）
-- 验收用例：`/vspec:accept`
-- 集成实现：`/vspec:impl`
-- 自动化测试：`/vspec:test`
-- 变更处理：`/vspec:change`
-- 升级/重构（继承遗留材料）：`/vspec:upgrade`
+  - 执行中会先生成需求口径文件（`/specs/background/original.md`），并在该步骤提出若干澄清问题
+  - 你需要先在对话中回答这些问题，然后输入“继续”才能完成 `/vspec:new` 全流程（这些澄清回答不写入 `questions.md`）
+  - 执行过程中还会生成开放问题清单（`/specs/background/questions.md`），用于后续合并
+- 合并 Q&A 到最新口径：`/vspec:refine-q`（把 `/specs/background/questions.md` 中已回答条目合并回 `original.md`，形成可追溯的口径演进）
+- 质量检查：`/vspec:qc`（对已生成的 `/specs/` 产物做不符合项检查，输出 `/specs/qc_report.md`，用于在进入补充/实现前先补齐质量问题）
+- 详细规格：`/vspec:detail`（遍历所有 functions，生成 RBAC、数据权限、交互、校验、状态机等细节产物）
+- 快速验证（模型 + 原型）：`/vspec:verify`（基于 functions + details + models 生成可运行原型；要求 `/specs/details/` 非空）
+- 验收用例：`/vspec:accept`（把关键场景转成可执行的验收点/检查表）
+- 集成实现：`/vspec:impl`（生成后端/前端的实现输入与工程骨架约束，包含模型/Service/Repository/异常等）
+- 自动化测试：`/vspec:test`（生成可落地的测试计划与自动化用例骨架）
+- 变更处理：`/vspec:change`（基于变更材料做影响分析，并更新受影响产物）
+- 升级/重构（继承遗留材料）：`/vspec:upgrade`（把 legacy/current 材料归一成新的 specs 与选型）
 
 ### 3. 关键目录
 
@@ -66,7 +68,7 @@ yarn dlx -p visual-spec vspec
 
 #### 补充/澄清（`refine`）
 
-- 把补充材料放到 `/docs/refine/`
+- 把补充材料写到 `/docs/refine/refine.md`（优先使用该文件作为入口；如有多文件再配合目录内其他文件）
 - 前置条件：`/specs/details/` 必须存在且非空，否则 `refine` 不执行
 - 运行：`/vspec:refine`
 - 结果：向 `/specs/background/original.md` 追加更新，并同步更新受影响的 `/specs/details/` 与 `/specs/prototypes/`

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.2",
+  "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

@@ -63,7 +63,8 @@ description: "将原始需求分析为可评审的视觉规格，并生成相关
 26. 将功能清单写入 `/specs/functions/`。
 27. 加载 `prompts/vspec_new/questions.md` 生成问题清单与所需业务材料清单。
 28. 将问题清单写入 `/specs/background/questions.md`（markdown 列表）。
-29. 返回结构化分析结果，并进入下一步需求设计流程。
+29. 加载 `prompts/harness/post_new_verify.md` 验证 functions 与 scenario_details 是否完备（登录/配置/主数据维护/审批等）。若输出了问题列表，则提示问题并立即结束。
+30. 返回结构化分析结果，并进入下一步需求设计流程。
 
 ### `/vspec:refine`
 
@@ -97,8 +98,10 @@ description: "将原始需求分析为可评审的视觉规格，并生成相关
 
 流程：
 1. 读取 `/specs/functions/*` 中的功能清单。
+   - 必须遍历 `/specs/functions/` 目录下所有文件的每一行功能（不仅是 core.md），避免遗漏任何模块/外部系统相关功能点。
 2. 尽可能读取可用的上下文产物：`/specs/background/*`、`/specs/flows/*.puml`、`/specs/background/scenario_details/`、`/specs/background/roles.md`，以及已有的 `/specs/models/*.md`（若存在）。
 3. 对每个功能（页面或非页面任务），先判断哪些详情产物真正涉及，再只生成涉及的部分；对不涉及的部分不得生成空文档。
+   - 覆盖性要求（必须）：对遍历到的每个功能点，必须至少产出 `rbac.md` 与 `data_permission.md`（按规则写入对应路径）；若因信息不足无法产出，必须输出可见错误并停止，而不是静默跳过。
    - 始终生成基础文档：
      - `rbac.md`：RBAC 权限下沉到页面区域与控件级。
      - `data_permission.md`：数据权限规则与范围。
@@ -119,6 +122,8 @@ description: "将原始需求分析为可评审的视觉规格，并生成相关
      - `formula.md`：计算公式与指标语义（存在计算/指标时生成）。
      - `expression_tree.md`：表达式树（HTML）（存在多层嵌套分支逻辑时生成）。
      - `code_rules.md`：编号/编码生成规则（存在编码生成时生成）。
+     - `payment.md`：支付与退款细节（存在支付/退款/结算/对账等资金链路时生成）。
+     - `auth.md`：账号与登录细节（存在非 SSO 的登录/账号/密码相关功能时生成）。
      - `judgemental_matrix.md`：判定矩阵（2+ 因素共同决定结果的多因子分支时生成）。
    - 模块级（每模块最多生成一次，且仅当涉及时生成）：
      - `timeline.md`：时间轴（HTML）用于整体流程影响分析（存在跨较长时间跨度影响决策的逻辑，如生效/失效、截止期、宽限期、跨天规则等时生成）。
@@ -141,8 +146,34 @@ 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` 作为访问入口。
+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`
+
+用于在既有原型工程基础上，单独补齐“调查问卷（Survey）”相关页面（Web 管理端 + Mobile 填写端），用于演示问卷配置、发布投放、填写提交与回收统计的闭环。
+
+流程：
+0. 若 `/specs/prototypes/` 不存在或为空：立即停止，并提示先运行 `/vspec:verify` 生成原型工程。
+1. 读取 `/specs/functions/*`、`/specs/details/`、`/specs/models/*.md`、`/specs/background/roles.md`、`/specs/background/dependencies.md` 与 `/scheme.yaml`（如存在）。
+2. 加载 `prompts/vspec_verify/prototype_survey.md` 生成/更新问卷相关页面、路由与 mock 数据。
+3. 仅写入与问卷相关的原型文件改动（增量修改），保持工程可运行。
+
+### `/vspec:proto-auth`
+
+用于在既有原型工程基础上，单独补齐“本系统账号体系（非 SSO）”相关页面（Web + Mobile）：登录、创建账号、忘记/重置密码、修改密码、会话与路由拦截。
+
+流程：
+0. 若 `/specs/prototypes/` 不存在或为空：立即停止，并提示先运行 `/vspec:verify` 生成原型工程。
+1. 读取 `/specs/functions/*`、`/specs/details/`、`/specs/background/roles.md`、`/specs/background/dependencies.md` 与 `/scheme.yaml`（如存在）。
+2. 加载 `prompts/vspec_verify/prototype_auth.md` 生成/更新登录相关页面、路由、session mock 与路由拦截。
+3. 仅写入与账号体系相关的原型文件改动（增量修改），保持工程可运行。
 
 ### `/vspec:qc`
 
@@ -181,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

@@ -64,7 +64,8 @@ Flow:
 26. Write the function lists to `/specs/functions/`.
 27. Load `prompts/vspec_new/questions.md` to generate question lists and required business materials.
 28. Write the questions result to `/specs/background/questions.md` (markdown list).
-29. Return the structured analysis result and continue to the next requirement-design step.
+29. Load `prompts/harness/post_new_verify.md` to validate whether functions and scenario_details are complete (login/config/master-data/approval). If it outputs any issues, show the issue list and stop.
+30. Return the structured analysis result and continue to the next requirement-design step.
 
 ### `/vspec:refine`
 
@@ -98,8 +99,10 @@ Use this command to expand requirement details based on the function list.
 
 Flow:
 1. Read the feature/function list from `/specs/functions/*`.
+   - You must iterate every function row across all files under `/specs/functions/` (not just core.md), so no module or external-system function is missed.
 2. Read supporting artifacts when available: `/specs/background/*`, `/specs/flows/*.puml`, `/specs/background/scenario_details/`, `/specs/background/roles.md`, and existing `/specs/models/*.md` (if any).
 3. For each function (page or non-page job), first determine which detail artifacts are actually involved, then only generate those artifacts; do not generate documents for non-involved parts.
+   - Coverage requirement: for every function row you iterate, you must generate at least `rbac.md` and `data_permission.md`. If you cannot, output an explicit error and stop (do not silently skip).
    - Always generate the baseline docs:
      - `rbac.md`: RBAC permissions down to page areas and controls.
      - `data_permission.md`: data permission rules and scope.
@@ -119,8 +122,10 @@ Flow:
      - `file_export.md`: file export details (if there is any export entry/requirement).
      - `formula.md`: calculation formulas and metric semantics (if there are any calculations/metrics).
      - `expression_tree.md`: expression tree (HTML) (if there is multi-level nested branching logic).
-     - `code_rules.md`: numbering/code generation rules (if any codes/serial numbers are generated/assigned).
-     - `judgemental_matrix.md`: judgemental matrix (判定矩阵) for multi-factor logic branching (if 2+ factors jointly decide outcomes).
+    - `code_rules.md`: numbering/code generation rules (if any codes/serial numbers are generated/assigned).
+    - `payment.md`: payment and refund details (if there is any payment/refund/settlement/reconciliation logic).
+    - `auth.md`: account/login details (if there is any non-SSO login/account/password flow).
+    - `judgemental_matrix.md`: judgemental matrix (判定矩阵) for multi-factor logic branching (if 2+ factors jointly decide outcomes).
    - Module-level (generate at most once per module, and only if involved):
      - `timeline.md`: time-axis visualization (HTML) for overall flow impact analysis (only when there is long time-span logic that affects flow decisions, e.g. effective/expiry, deadlines, grace periods, cross-day rules).
       - `state_machine.md`: status list + transitions + PlantUML state diagram (overall; not per function).
@@ -142,8 +147,34 @@ 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.
+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`
+
+Use this command to generate a complete Survey (questionnaire) prototype (Web admin + Mobile filling) on top of an existing prototype project.
+
+Flow:
+0. If `/specs/prototypes/` is missing or empty, stop and ask the user to run `/vspec:verify` first.
+1. Read `/specs/functions/*`, `/specs/details/`, `/specs/models/*.md`, `/specs/background/roles.md`, `/specs/background/dependencies.md`, and `/scheme.yaml` (if any).
+2. Load `prompts/vspec_verify/prototype_survey.md` to generate/update survey pages, routes, and mock data.
+3. Write only survey-related incremental changes and keep the prototype runnable.
+
+### `/vspec:proto-auth`
+
+Use this command to generate a complete non-SSO auth/account page set (Web + Mobile) on top of an existing prototype project.
+
+Flow:
+0. If `/specs/prototypes/` is missing or empty, stop and ask the user to run `/vspec:verify` first.
+1. Read `/specs/functions/*`, `/specs/details/`, `/specs/background/roles.md`, `/specs/background/dependencies.md`, and `/scheme.yaml` (if any).
+2. Load `prompts/vspec_verify/prototype_auth.md` to generate/update auth pages, routes, session mock, and route guards.
+3. Write only auth-related incremental changes and keep the prototype runnable.
 
 ### `/vspec:qc`
 
@@ -182,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_new_verify.md

@@ -0,0 +1,55 @@
+你是一名资深需求分析质检员。你的任务是：在 `/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_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 实际值）