visual-spec 0.1.4 → 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

@@ -46,8 +46,7 @@ yarn dlx -p visual-spec@latest 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/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

@@ -46,8 +46,7 @@ yarn dlx -p visual-spec@latest 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@latest vspec
 #### 变更（`change`）
 
 - 把变更材料放到 `/docs/change/`（可选 `file_list.md`）
-- 运行：`/vspec:change`
 - 结果：做影响分析并更新产物（优先 `/specs/details/<module_slug>/`），同时更新变更日志
 
 #### 升级/重构（`upgrade`）

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

@@ -179,6 +179,8 @@ description: "将原始需求分析为可评审的视觉规格，并生成相关
 
 用于对 `/specs/` 下生成的需求产物进行质量检查。
 
+Note：Pro 版支持更广泛的质量检测能力（例如更完整的原型/实现后校验项等），需要付费开通。
+
 流程：
 1. 读取内置标准 `prompts/vspec_qc/quality_standard.md`。
 2. 若项目 `qc/` 下存在“需求质量错误簿”，则据此生成/更新项目根目录的 `quality_standard.md`。
@@ -195,7 +197,7 @@ description: "将原始需求分析为可评审的视觉规格，并生成相关
 2. 加载 `prompts/vspec_accept/accept.md` 生成验收用例，覆盖主流程、异常、边界、权限与数据范围。
 3. 将结果写入 `/specs/acceptance/`（按功能建子目录），并生成 `/specs/acceptance/index.md` 索引。
 
-### `/vspec:test`
+### `/vspec:append-test`
 
 用于基于验收用例与规格生成自动化测试代码。
 
@@ -203,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`
 
@@ -225,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`
 
 用于把需求拆解为故事地图并进行估算与排期。
@@ -292,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

@@ -180,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.
@@ -196,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.
 
@@ -204,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`
 
@@ -226,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.
@@ -290,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_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/harness/post_impl_verify.md

@@ -1,34 +0,0 @@
-你是一名资深后端架构与测试质量质检员。你的任务是：在 `/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

@@ -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_click_check.md

@@ -1,27 +0,0 @@
-你是一名资深前端原型交互质检员。你的任务是：在 `/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

@@ -1,23 +0,0 @@
-你是一名资深移动端交互质检员。你的任务是：在 `/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

@@ -1,26 +0,0 @@
-你是一名资深前端 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

@@ -1,43 +0,0 @@
-你是一名资深前端架构质检员。你的任务是：在 `/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/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`