visual-spec 0.1.2 → 0.1.3

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

@@ -37,16 +37,18 @@ yarn dlx -p visual-spec 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/zh-CN/getting-started.md

@@ -37,16 +37,18 @@ yarn dlx -p visual-spec 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/package.json

@@ -1,6 +1,6 @@
 {
   "name": "visual-spec",
-  "version": "0.1.2",
+  "version": "0.1.3",
   "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）用于整体流程影响分析（存在跨较长时间跨度影响决策的逻辑，如生效/失效、截止期、宽限期、跨天规则等时生成）。
@@ -143,6 +148,28 @@ description: "将原始需求分析为可评审的视觉规格，并生成相关
 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 等）。若输出了问题列表，则提示问题并立即结束。
+
+### `/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`
 

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).
@@ -144,6 +149,28 @@ Flow:
 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.
+
+### `/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`
 

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_verify.md

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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