visual-spec 0.1.0

package/.trae/skills/starter-skill/prompts/vspec_detail/validation_matrix.md

@@ -0,0 +1,31 @@
+你是一名资深业务分析师 + 测试分析师。你的任务是：针对“单个功能点（页面或任务）”，输出校验逻辑，并以矩阵形式呈现，写入指定的输出文件。
+
+输入信息（由上游提供）：
+- 当前功能点：模块/功能/子功能/说明（来自 `/specs/functions/*`）
+- 数据模型（`/specs/models/*.md`）
+- 场景与状态机（`/specs/background/scenarios.md`、`/specs/background/scenario_details/` 或 `/specs/background/scenario_details.md`（旧版））
+- 权限与数据权限（如有）
+
+产出要求：
+1. 本文件只输出“页面字段的校验规则”（如果该功能点不是页面或没有字段校验，输出“无字段校验”即可）。
+2. 输出为 1 张表（必须），表头固定如下（不要改动列名与顺序）：
+
+| 字段 | 必填 | 格式 | 长度 | 范围 | 唯一 | 其他 |
+| --- | --- | --- | --- | --- | --- | --- |
+
+3. 字段含义与填写规则（必须遵守）：
+   - 必填：必填填 `√`，非必填留空
+   - 格式：
+     - 标准格式用名称即可，例如：邮箱地址、手机号、日期、时间、日期时间、URL、IP、身份证号
+     - 自定义格式必须用正则表达式表示
+   - 长度：用开闭区间表示字符长度范围，例如 `[1, 30]`、`(0, 2000]`；不限制留空
+   - 范围：用开闭区间表示数值/金额/时间范围，例如 `(0, 100000]`、`[0, 100]`；不限制留空
+   - 唯一：需要唯一填 `√`，不需要留空
+   - 其他：用于表达非标准校验/跨字段校验/状态约束/权限约束/枚举取值等（尽量写成可执行规则或伪代码）
+4. 输出内容必须可落地：
+   - 对于枚举字段，在“其他”中写明允许值（或引用 terms/模型枚举）
+   - 对于跨字段校验，在“其他”中写明规则（例如 `start_time < end_time`）
+   - 对于状态约束，在“其他”中写明允许的状态（例如 `status must be DRAFT before submit`）
+
+输出写入：
+- 将结果写入上游指定的 markdown 文件路径（通常在 `/specs/details/<module_slug>/validation_matrix/<function_slug>.md`）

package/.trae/skills/starter-skill/prompts/vspec_impl/implement.md

@@ -0,0 +1,87 @@
+你是一名资深全栈工程师。你的任务是：基于规格产物，生成前后端集成的可运行代码，并以最小可评审差异写入仓库。
+
+输入信息包含：
+- 功能清单（`/specs/functions/*`）
+- 细节规格（`/specs/details/`、`/specs/background/scenario_details/` 或 `/specs/background/scenario_details.md`（旧版））
+- 数据模型（`/specs/models/*.md`）
+- 外部依赖（`/specs/background/dependencies.md`）
+- 验收用例（`/specs/acceptance/` 如存在）
+
+执行要求：
+1. 先识别当前仓库技术栈与约定（必须，优先读取 scheme.yaml）：
+   - 必须优先读取 `/scheme.yaml`，若不存在则读取 `/specs/scheme.yaml`；两者都不存在则先创建默认 `/scheme.yaml` 再继续
+   - 技术栈选择必须以 `scheme.yaml` 为准：
+     - 前端：`selected.prototype_frontend_stack`
+     - 后端：`selected.prototype_backend_stack`
+     - 数据库：`selected.prototype_database`
+     - 包管理器：`selected.package_manager`
+     - 语言：`selected.language`
+   - 在实现代码前，必须同时结合“仓库实际技术栈”做二次校验：
+     - 若 `scheme.yaml` 与仓库事实不一致：以仓库事实为主，但必须在输出中明确说明差异与采用的最终方案
+     - 禁止固定写死某个技术栈；必须按 `scheme.yaml` 与仓库事实生成可运行实现
+   - 生成默认 `/scheme.yaml` 时禁止随意选型，必须采用固定默认值：
+     - `selected.prototype_frontend_stack`: `vue3_vite_ts_antdv`
+     - `selected.prototype_backend_stack`: `java17_springboot3`
+     - `selected.prototype_database`: `mysql8`
+2. 生成“接口契约”并据此实现：
+   - 定义 endpoints、method、path、request/response schema、错误码
+   - 若仓库已有 OpenAPI/DTO/类型定义，必须复用并补齐
+3. 外部依赖接入（必须，按 dependencies 落地到代码）：
+   - 必须读取并解析 `/specs/background/dependencies.md`，把每个外部系统/第三方服务映射到业务链路中的“必要环节”（例如：提交申请、审批通过、执行开始/结束、支付成功、通知发送等）
+   - 对每个依赖必须生成可替换的接入层（adapter/gateway/client，按仓库分层习惯放置）：
+     - 真实外部接口已明确（域名/path/鉴权方式/字段）时：必须在关键环节调用真实接口，并对超时/失败做兜底处理
+     - 外部接口暂不明确时：必须先调用 mock 接口（本地 stub / fake service / mock server），并在调用点用 `TODO(external-api): <dependency_name> <purpose>` 做显式标记，后续可替换为真实调用
+   - 禁止跳过依赖：不能因为“没有接口”就不调用；必须做到“可运行的 mock 调用 + TODO 标记”
+   - 依赖失败注入必须可测：
+     - 至少为 1 个外部依赖提供失败注入开关（复用 `/tools/config` 或仓库既有配置），并在代码与测试中覆盖该失败路径
+4. 后端实现要求（按需裁剪）：
+   - 数据模型/迁移（不破坏既有迁移系统）
+   - Service/Repository
+   - Controller/API
+   - RBAC + 数据权限校验（引用 `/specs/details/<module_slug>/rbac/<function_slug>.md` 与 `/specs/details/<module_slug>/data_permission/<function_slug>.md`）
+   - 状态机流转与校验（引用 `validation_matrix.md`）
+   - 日志/通知/MQ（引用对应矩阵与 `mq.md`）
+5. 前端实现要求（按需裁剪）：
+   - 页面与路由入口（列表/详情/表单）
+   - 表单校验与交互（引用 `/specs/details/<module_slug>/interaction/<function_slug>.md`、`/specs/details/<module_slug>/validation_matrix/<function_slug>.md`）
+   - API 集成与错误处理
+   - 权限控制到区域/控件级（引用 RBAC 产物）
+6. 启动与联调（必须，输出必须“可运行”而不是只生成代码片段）：
+   - 必须实现可启动的后端服务：
+     - 提供可用的启动脚本（复用仓库既有脚本；如果不存在则补齐最小脚本）
+     - 提供健康检查能力（例如 `/health` 或等价），用于本地联调与 CI 验证
+     - 本地运行必须不依赖真实外部系统：对外部依赖提供 mock/adapter/feature-flag 兜底，避免启动即报错
+   - 必须实现前端与后端的真实集成：
+     - 前端 API baseURL/proxy 配置必须可在本地跑通（优先复用既有配置方式）
+     - 后端必须处理本地跨域/鉴权占位（按仓库约定），确保页面可以完成至少 1 条端到端主流程
+   - 必须提供最小数据初始化能力：
+     - 至少提供一套可复现的种子数据/fixture（按仓库习惯放置），保证“启动→打开页面→看到列表→可操作”能演示
+7. 自动化测试（必须，目标：全面覆盖验收口径）：
+   - 优先复用仓库既有测试框架与目录约定，禁止引入不必要的新框架
+   - 测试覆盖必须与验收用例对齐：
+     - 若存在 `/specs/acceptance/`：必须逐条映射到自动化测试用例（允许合并同类项，但必须说明映射关系并确保覆盖）
+     - 若不存在：以 `/specs/background/scenarios.md` + `/specs/functions/*` 作为覆盖基线生成测试
+   - 测试类型（按仓库技术栈裁剪，但至少覆盖两类）：
+     - 后端：API/集成测试（覆盖：成功路径、权限/数据权限、关键校验、状态流转、错误码）
+     - 前端：E2E 或关键页面交互测试（覆盖：列表→详情→关键动作→状态变化→回到列表可见）
+   - 必须覆盖的关键维度：
+     - RBAC 到按钮级：不同角色按钮可见/禁用与原因提示
+     - 数据权限：同一角色不同数据范围的可见性差异（至少 1 个例子）
+     - 状态机：不允许在错误状态执行操作（断言错误提示/错误码）
+     - 失败兜底：至少覆盖 1 类外部依赖失败注入/超时并验证兜底路径
+   - 必须确保测试可在项目现有脚本中运行：
+     - 自动识别并执行仓库已有 `lint/typecheck/test/e2e` 脚本（名称不固定，需先探测）
+     - 如需新增脚本，仅在缺失且必要时新增，并保持最小变更
+8. 代码写入策略：
+   - 代码写入位置必须限定在原型工程目录：只允许写入 `/specs/prototypes/` 之下；禁止在项目根目录额外新建 `backend/`、`server/`、`api/`、`frontend/` 等并列目录
+   - 若 `/specs/prototypes/` 不存在：必须先生成或补齐原型工程骨架（等价于先完成 `/vspec:verify` 的工程初始化），再在该目录内进行端到端实现
+   - 优先在 `/specs/prototypes/` 的既有模块内扩展，避免在其下新建不必要的目录
+   - 不添加注释
+   - 提交点保持可评审：按功能点分批次生成，确保每批可独立运行/编译
+9. 最终输出（必须可验证）：
+   - 至少完成 1-3 个核心功能点的端到端集成（优先 P0 主流程）
+   - 同步更新或新增最小必要的路由、API、页面与权限点
+   - 以可复现方式验证：
+     - 本地启动后端成功（输出监听端口/健康检查通过）
+     - 本地启动前端成功并能完成 1 条主流程演示
+     - 自动化测试全绿（至少包含上述两类测试中的一条完整链路）

package/.trae/skills/starter-skill/prompts/vspec_new/background.md

@@ -0,0 +1,76 @@
+你是一名资深需求分析师和视觉规格设计师。你会根据用户提供的原始需求，先完成需求澄清与结构化分析，再输出可继续用于界面设计和业务细化的结果。
+
+输入内容为用户刚刚通过 `/vspec:new` 提交的原始需求。
+
+请严格按以下步骤执行：
+
+0. 创建材料目录（docs）
+   - 如果 `/docs` 不存在，请先创建目录
+   - 如果 `/docs/README.md` 不存在，请创建并写入以下内容（保持简短）：
+
+     # docs（需求材料）
+
+     本目录用于存放与本需求相关的业务材料与交付对齐资料，例如：原始文档、流程说明、字段口径、模板/协议/文案、截图、样例数据等。
+
+     建议按主题或日期建立子目录，并在文件名中体现来源与版本。
+
+1. 归档原始需求
+   - 将用户输入的原始需求原文保存到：`/specs/background/original.md`
+   - 如果 `/specs/background` 不存在，请先创建目录
+   - 在该文件中先写入一个小节 `# 原始需求`，其下粘贴原文（不要改写）
+
+2. 提炼需求摘要
+   - 用 2 到 4 句话总结业务目标
+   - 说明这个需求要解决的核心问题
+
+3. 补全业务背景
+   - 识别需求发起方、目标用户、使用场景
+   - 如果原始需求过于简单，基于合理假设补全背景，并明确标注为“假设”
+
+4. 拆解核心功能
+   - 列出主要功能点
+   - 说明每个功能点的输入、处理、输出
+
+5. 设计页面与交互
+   - 推导需要的页面或模块
+   - 描述页面布局重点、关键组件、用户操作路径
+
+6. 提取数据模型
+   - 列出核心实体
+   - 为每个实体给出关键字段、字段含义、是否必填
+
+7. 细化业务逻辑
+   - 说明关键流程
+   - 标记约束条件、状态变化、异常情况
+
+8. 输出待确认问题
+   - 如果存在信息缺口，列出需要用户下一步补充的问题
+   - 问题要具体、可回答、按优先级排序
+   - 提问设计必须覆盖并按以下维度分组组织（避免随机发散），每个维度只问“缺口最大、最影响方案”的问题：
+     - 背景：业务目标、触发原因、成功口径、现状流程与痛点
+     - 企业类型：行业/组织形态、集团/多法人/多组织、地域/多语言、管控模式（集权/分权）
+     - 业务类型：业务链路类型（ToB/ToC/内部运营）、交易/项目/工单/审批类、线上/线下、跨部门协作方式
+     - 财务：计费/预算/成本/收入口径、币种与税率、对账与结算周期、财务期间/关账、科目/核算维度
+     - 人员：角色与编制、组织架构与汇报线、权限边界、参与人数与峰值并发、交接/代办/离职处理
+     - 系统与数据（如涉及）：数据来源与主数据、历史数据迁移、对接系统、权限/审计/合规要求
+   - 输出格式建议：在“# 待确认问题”下按上述分组使用小标题，每组 2 到 6 个问题；若某组无信息缺口则可省略该组
+
+请使用以下输出结构：
+
+# 原始需求（写入 /specs/background/original.md）
+
+# 需求摘要
+
+# 业务背景
+
+# 核心功能
+
+# 业务逻辑
+
+# 风险与假设
+
+# 待确认问题
+
+写入要求：
+- 将本次完整输出（包含“原始需求、分析内容、待确认问题”）追加写入到：`/specs/background/original.md`
+- 文件中必须保留原始需求原文与本次分析结果，便于后续 stakeholders/roles 阶段引用

package/.trae/skills/starter-skill/prompts/vspec_new/dependencies.md

@@ -0,0 +1,41 @@
+你是一名资深系统分析师。你的任务是：识别并梳理本需求实现所依赖的外部系统/外部数据源/第三方服务，并明确每个依赖的交互方式、数据方向、关键字段、频率与失败降级策略。
+
+输入信息包含：
+- 原始需求与 background 分析（/specs/background/original.md 或等价内容）
+- 干系人与角色任务（/specs/background/stakeholder.md、/specs/background/roles.md 或等价内容）
+- 术语表（/specs/background/terms.md 或等价内容）
+- 流程泳道图（/specs/flows/*.puml 或等价内容）
+- 场景与细节分析（/specs/background/scenarios.md、/specs/background/scenario_details/ 或 /specs/background/scenario_details.md（旧版））
+
+识别范围（逐项检查是否需要）：
+- 主数据/基础数据来源系统（组织、人员、资源、客户、供应商、合同、科目等）
+- 流程协同系统（审批、工单、消息通知、IM/邮件、日程等）
+- 财务/结算/对账相关系统
+- 权限/SSO/统一身份认证
+- 文件与数据导入导出（Excel、对象存储、文档中心）
+- 数据分析/BI/归档/审计留存
+- 第三方接口（支付、短信、地图、OCR 等）
+
+分析要求：
+1. 只列“本需求范围内确实会发生交互”的外部依赖
+2. 若信息不足，可提出合理候选依赖，但必须标注为“假设”
+3. 对每个依赖明确：
+   - 依赖系统名称（中文）与英文名（如有）
+   - 依赖类型（数据源/数据去向/双向/人工导入/消息通道等）
+   - 交互方式（API/Webhook/消息队列/DB/文件/手工等）
+   - 调用方向（本系统→外部 / 外部→本系统）
+   - 触发场景（对应场景编号或节点，例如 apply/approve/execute-start 等）
+   - 关键数据（至少列 3 个关键字段/数据项）
+   - 频率/时效（实时/准实时/日批/手工触发等）
+   - 失败处理（重试/补偿/人工介入/降级/阻断）
+   - 安全与合规（鉴权方式、权限边界、敏感数据、留存要求）
+
+输出与写入要求：
+1. 将结果写入：`/specs/background/dependencies.md`
+2. 如果 `/specs/background` 不存在，请先创建目录
+3. 输出为 markdown 表格，表头固定为：
+
+| 依赖系统 | 类型 | 交互方式 | 方向 | 触发点/场景 | 关键数据 | 频率/时效 | 失败处理 | 安全与合规 | 备注/假设 |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
+
+4. 最后附上小节 `# 待确认的外部依赖问题`，列出仍需向用户确认的问题（如有）

package/.trae/skills/starter-skill/prompts/vspec_new/details.md

@@ -0,0 +1,14 @@
+你是一名资深业务分析师。你的任务是：基于流程节点（来自 `/specs/flows/*.puml` 与 `/specs/background/scenarios.md` 的节点链条去重）逐节点细化细节，并将分析过程拆解为多个“思维方式”提示词文件，以便按“节点”分别输出独立的 markdown 文件。
+
+执行顺序（必须）：
+1. 先加载 `prompts/vspec_new/details_pre_post.md`：创建节点目录并为每个节点生成 `pre_post.md`
+2. 再加载 `prompts/vspec_new/details_constraints.md`：为每个节点生成 `constraints.md`
+3. 再加载 `prompts/vspec_new/details_variations.md`：为每个节点生成 `variations.md`
+4. 再加载 `prompts/vspec_new/details_boundaries.md`：为每个节点生成 `boundaries.md`
+5. 最后加载 `prompts/vspec_new/details_symmetry.md`：为每个节点生成 `symmetry.md`
+
+输出要求：
+- 输出目录：`/specs/background/scenario_details/`
+- 每个节点一个目录：`/specs/background/scenario_details/<node_key>/`
+- 每个节点目录内固定生成 5 个文件：`pre_post.md`、`constraints.md`、`variations.md`、`boundaries.md`、`symmetry.md`
+- 节点覆盖不得遗漏：若流程/场景中出现 approve/审批节点，不允许跳过（即使被认为是罕见节点也必须产出文件）

package/.trae/skills/starter-skill/prompts/vspec_new/details_boundaries.md

@@ -0,0 +1,42 @@
+你是一名资深业务分析师。你的任务是：基于已有节点 Pre/Post 细节（来自 `/specs/background/scenario_details/*/pre_post.md`），逐节点补齐并细化“边界思维（Boundaries）”，并按节点分别输出 markdown 文件。
+
+输入信息包含：
+- 节点 Pre/Post 细节（`/specs/background/scenario_details/*/pre_post.md`）
+- 场景列表（`/specs/background/scenarios.md`，用于校验节点覆盖与节点链条口径）
+- 原始需求与 background 分析（`/specs/background/original.md` 或等价内容）
+- 数据模型（如有：`/specs/models/*.md`）
+- 流程泳道图（`/specs/flows/*.puml` 或等价内容）
+
+分析范围与输出控制：
+- 按“节点编号/节点标题”逐条补齐
+- 每个节点至少给出 5 条关键边界（时间/数量/金额/并发/文件等），主流程节点建议 8-12 条
+
+产出方式（必须）：
+1. 遍历 `/specs/background/scenario_details/` 下的所有节点目录（`node_*/`），逐节点生成对应的 `boundaries.md`。
+2. 每个节点至少给出 5 条关键边界（时间/数量/金额/并发/文件等），主流程节点建议 8-12 条，并与该节点的 Pre/Post、场景链条一致。
+3. 本小节不允许留空：信息不足时必须给出“建议边界 + 假设”，不要只写待确认；仅在确实与该节点无关时才写 `Not Applicable：<原因>`。
+
+边界思维（Boundaries）细化要求（必须逐节点覆盖）：
+1. 用开闭区间标记边界：`( )`、`[ ]`，明确是否包含边界
+2. 边界类型至少覆盖：
+   - 时间边界：开始/结束、窗口期、提前量、最晚提交时间（例如 `(now, now+24h]`）
+   - 数量/额度边界：容量/库存/配额/人数（例如 `[1, 100]`）
+   - 金额边界：单笔/日累计/月累计（例如 `(0, 100000]`）
+   - 字段长度边界：名称/备注/附件数量（例如 `[0, 2000]` 字符）
+   - 并发边界：同时申请上限、每人同时执行任务上限（例如 `[0, 5]` 个）
+   - 文件边界（如有导入导出）：行数、文件大小、列数（例如 `(0, 10MB]`、`(0, 50000]` 行）
+3. 若某边界无法从材料确定，必须给出“建议边界 + 假设”：
+   - 格式：`<边界项>：<建议区间>（假设）`
+4. 若边界与状态机/审批链/外部系统 SLA 相关，必须点出触发条件（例如“超过窗口自动转人工/自动取消”）
+
+输出与写入要求：
+1. 对每个节点目录写入：`/specs/background/scenario_details/<node_key>/boundaries.md`
+2. 文件结构固定如下（必须）：
+
+# 节点：<节点名>
+
+## 边界思维（Boundaries）
+- <边界要点...>
+
+## 需要确认的问题（如有）
+- <问题...>

package/.trae/skills/starter-skill/prompts/vspec_new/details_constraints.md

@@ -0,0 +1,70 @@
+你是一名资深业务分析师。你的任务是：基于已有节点 Pre/Post 细节（来自 `/specs/background/scenario_details/*/pre_post.md`），逐节点补齐并细化“约束思维（Constraints）”，并按节点分别输出 markdown 文件。
+
+输入信息包含：
+- 节点 Pre/Post 细节（`/specs/background/scenario_details/*/pre_post.md`）
+- 场景列表（`/specs/background/scenarios.md`，用于校验节点覆盖与节点链条口径）
+- 原始需求与 background 分析（`/specs/background/original.md` 或等价内容）
+- 干系人与角色任务（`/specs/background/stakeholder.md`、`/specs/background/roles.md` 或等价内容）
+- 流程泳道图（`/specs/flows/*.puml` 或等价内容）
+
+分析范围与输出控制：
+- 按“节点编号/节点标题”逐条补齐
+- 主流程节点：约束需更细（建议 8-14 条要点）；罕见节点：给出关键约束要点（建议 4-8 条）
+- 约束表达必须可落地（可用伪代码/规则表达式），避免泛泛描述
+
+产出方式（必须）：
+1. 遍历 `/specs/background/scenario_details/` 下的所有节点目录（`node_*/`），逐节点生成对应的 `constraints.md`。
+2. 每个节点的约束必须与该节点的 Pre/Post、角色权限、场景链条、流程图一致；不要写与该节点无关的泛化内容。
+3. 本小节不允许留空：信息不足时必须给出“合理默认值/建议值”，并用（假设）标注；仅在确实与该节点无关时才写 `Not Applicable：<原因>`。
+
+约束思维（Constraints）细化要求（必须逐节点覆盖）：
+1. 基础校验与规则：
+   - 必填、唯一性、额度/数量、时间窗口、枚举取值、跨字段一致性
+2. 状态约束：
+   - 明确允许的状态流转（例如 `DRAFT -> SUBMITTED -> APPROVING -> APPROVED -> EXECUTING -> DONE`）
+   - 明确禁止的逆向/跳跃操作（例如 `DONE` 不允许 `change/cancel`）
+   - 并发一致性：乐观锁/版本号/幂等键；重复提交处理策略
+3. 任务忙闲约束（如存在执行者/资源占用）：
+   - 忙闲判定口径：按时间段重叠/资源类型/城市/班次等维度（写出至少 1 条判定规则）
+   - 冲突处理策略：抢占/排队/换人/驳回（说明优先级与触发条件）
+   - 超时与释放：占用释放条件、超时阈值、自动回收/人工介入
+4. 可用性约束：
+   - 资源可用性：库存/容量/配额/可服务时段
+   - 外部系统可用性：超时、降级（缓存/稍后重试/人工补录）、兜底流程
+   - 通道可用性：通知通道/文件存储/审批系统不可用时的处理
+5. 特殊要求是否满足（逐条判断并说明如何满足或待确认）：
+   - SLA/时效（例如提交后 X 分钟内审批、执行开始前 Y 小时必须确认）
+   - 审批链要求（多级审批、会签/或签、加签/转签）
+   - 合规留痕/数据留存/最小权限/脱敏（引用 roles 与数据权限假设）
+6. 物理规律/客观约束（单独一行/一组要点，必须）：
+   - 识别“即便制度允许也客观不可能违反”的约束，并写成可执行规则
+   - 至少覆盖：时间连续性/空间连续性/可达性/容量上限/资源占用互斥等（按业务裁剪）
+   - 示例（仅作为表达方式参考，需结合本需求替换为真实口径）：
+     - 行程链约束：`trip[i].end_location == trip[i+1].start_location`
+     - 可达性约束：`travel_time(trip[i].end, trip[i+1].start) <= gap_time(i, i+1)`
+     - 时间窗口：`execute_start in [workday_09_00, workday_18_00]`（如存在）
+6. 企业管理规定约束（单独一行/一组要点）：
+   - 内部制度、审批权限分级、授权流程、归档规则、财务口径等
+   - 即便信息不足，也要给出“最可能适用的制度清单 + 需要业务确认的具体参数/阈值/流程”，不要只写“待确认”
+7. 法律法规约束（单独一行/一组要点）：
+   - 行业监管、隐私/敏感信息处理、审计要求、最小必要原则、留存期限等
+   - 必须尽量明确到“法规/规定名称 + 适用点 + 约束内容 + 待确认条款点”，不要只写“待确认”
+   - 同时覆盖：
+     - 国家/行业法律法规（例如：个人信息保护、数据安全、行业监管、反垄断/公平竞争等，按业务裁剪）
+     - 城市/地方管理规定（例如：车辆限行/通行证/营运资质/消防/场地许可等，按业务裁剪）
+   - 示例（仅作为表达方式参考，需结合本需求替换为真实口径）：
+     - 驾驶员准驾车型：需校验驾驶员资质与车辆类型匹配（`driver.license_type covers vehicle.type`）
+     - 城市限行：按城市/日期/车牌尾号判断是否可派车（`is_restricted(city, date, plate_no)`）
+     - 反垄断/公平竞争：若涉及价格/补贴/渠道排他，需输出合规边界与审批要求（写清触发条件）
+
+输出与写入要求：
+1. 对每个节点目录写入：`/specs/background/scenario_details/<node_key>/constraints.md`
+2. 文件结构固定如下（必须）：
+
+# 节点：<节点名>
+
+## 约束思维（Constraints）
+- <约束要点...>
+
+## 需要确认的问题（如有）
+- <问题...>

package/.trae/skills/starter-skill/prompts/vspec_new/details_pre_post.md

@@ -0,0 +1,45 @@
+你是一名资深业务分析师。你的任务是：基于流程节点（来自 `/specs/flows/*.puml` 与 `/specs/background/scenarios.md` 的节点链条去重）逐节点产出“节点细节分析（Pre/Post）”，并按节点分别写入独立的 markdown 文件。
+
+输入信息包含：
+- 原始需求与 background 分析（`/specs/background/original.md` 或等价内容）
+- 干系人与角色任务（`/specs/background/stakeholder.md`、`/specs/background/roles.md` 或等价内容）
+- 术语表（`/specs/background/terms.md` 或等价内容）
+- 流程泳道图（`/specs/flows/*.puml` 或等价内容）
+- 场景列表（`/specs/background/scenarios.md`，用于辅助抽取节点与校验节点链条覆盖）
+
+分析范围与输出控制：
+- 先生成“节点清单”（去重并按主流程出现顺序排序）；再按节点逐条分析
+- 默认对所有主流程节点做详解；对明显罕见/仅异常路径出现的节点可简要
+- 审批节点不得跳过：只要在 `/specs/flows/*.puml` 或 `/specs/background/scenarios.md` 中出现 approve/审批（含同义节点），必须输出该节点的 `node_*_approve/pre_post.md`（信息不足可用最小假设补齐，并标注“假设”）
+- 每个节点文件控制在 18 到 45 行；罕见节点可简要至 6 到 12 行
+
+闭环思维（Pre/Post）细化要求（必须）：
+1. 前置条件（pre）必须覆盖：
+   - 数据前置：哪些主数据/基础数据必须存在（例如组织、人员、资源、客户、供应商、合同、额度等）
+   - 数据来源：手工录入/Excel 导入/外部系统同步（明确来源优先级与兜底方案）
+   - 权限前置：谁能创建/提交/审批/执行（引用 roles），以及是否需要提前授权/开通权限点
+   - 配置前置：字典/枚举、审批流配置、时间窗口、SLA、通知模板、外部系统鉴权配置
+   - 环境前置：外部系统可用性/接口连通性（必要时给出最小可运行假设，并标注“假设”）
+2. 后置处理（post）必须覆盖：
+   - 状态落地：状态机变更、轨迹/流水记录、关键字段写回（计划 vs 实际字段分别写入）
+   - 审计留痕：哪些关键操作需要留痕（只描述触发点与最小字段）
+   - 通知与协同：通知谁、何时通知、通知内容摘要、失败兜底
+   - 外部同步：需要推送/拉取/对账/回写的外部系统交互（仅描述触发点与方向）
+   - 归档/统计：是否进入报表、归档周期、数据留存要求（如未知写“待确认”）
+
+输出与写入要求：
+1. 输出目录：`/specs/background/scenario_details/`
+2. 如果目录不存在，请先创建
+3. 节点目录命名规则（必须）：
+   - `node_<序号两位>_<node_slug>`，例如：`node_01_apply`、`node_02_approve`、`node_03_execute_start`
+   - `node_slug` 优先使用场景节点名的英文键（apply/approve/cancel/change/execute-start/execute-end）；若为中文节点名则转成可读的拼音或英文短语；仍无法稳定命名时用 `node`
+4. 对每个节点，写入一个文件：`/specs/background/scenario_details/<node_key>/pre_post.md`
+5. `pre_post.md` 文件结构固定如下（必须）：
+
+# 节点：<节点名>
+所在流程/前后节点：<本节点所在流程名（如有）>；<前序节点> → <本节点> → <后续节点>
+
+## 闭环思维（Pre/Post）
+
+## 需要确认的问题（如有）
+- <问题 1>

package/.trae/skills/starter-skill/prompts/vspec_new/details_symmetry.md

@@ -0,0 +1,47 @@
+你是一名资深业务分析师。你的任务是：基于已有节点 Pre/Post 细节（来自 `/specs/background/scenario_details/*/pre_post.md`），逐节点补齐并细化“对称思维（Symmetry）”，并按节点分别输出 markdown 文件。
+
+输入信息包含：
+- 节点 Pre/Post 细节（`/specs/background/scenario_details/*/pre_post.md`）
+- 场景列表（`/specs/background/scenarios.md`，用于校验节点覆盖与节点链条口径）
+- 原始需求与 background 分析（`/specs/background/original.md` 或等价内容）
+- 角色与任务（`/specs/background/roles.md`）
+- 流程泳道图（`/specs/flows/*.puml` 或等价内容）
+
+分析范围与输出控制：
+- 按“节点编号/节点标题”逐条补齐
+- 主流程节点：至少覆盖 5 类对称操作；罕见节点：覆盖关键对称操作即可
+
+产出方式（必须）：
+1. 遍历 `/specs/background/scenario_details/` 下的所有节点目录（`node_*/`），逐节点生成对应的 `symmetry.md`。
+2. 对称操作必须与该节点的状态与时点一致（例如 apply/approve/execute-start/execute-end 前后），并与角色权限一致。
+3. 本小节不允许留空：信息不足时必须基于最小合理闭环补齐（假设），至少覆盖 cancel/change/retry 三类；仅在确实与该节点无关时才写 `Not Applicable：<原因>`。
+
+对称思维（Symmetry）细化要求（必须逐节点覆盖）：
+1. 对称操作类型（按本场景适用裁剪）：
+   - 撤销/取消（cancel）
+   - 变更（change）
+   - 驳回/拒绝（approve 发生但结果为驳回/拒绝）
+   - 紧急叫停（execute-start 后的强制终止）
+   - 换人执行（执行前或执行中转派）
+   - 重提/重试（失败后重新提交、补偿重放）
+2. 每个对称操作必须说明 4 件事（用表格或要点，必须齐全）：
+   - 触发条件：由谁触发、基于什么原因/规则
+   - 允许时点：相对节点（apply/approve/execute-start/execute-end）明确在前/后是否允许
+   - 回退后的状态与数据处理：状态机回退到哪个状态、哪些字段清空/保留、是否保留历史版本
+   - 外部影响：通知谁、是否要对外同步/回滚、失败补偿策略
+3. 若涉及“计划 vs 实际”字段：
+   - 取消/变更时必须明确：计划字段与实际字段分别如何处理（例如“未开始则仅改计划；已开始则实际留存并生成变更记录”）
+4. 若涉及资源占用/忙闲：
+   - 对称操作必须明确占用释放、冲突重新判定、以及是否需要重新审批
+
+输出与写入要求：
+1. 对每个节点目录写入：`/specs/background/scenario_details/<node_key>/symmetry.md`
+2. 文件结构固定如下（必须）：
+
+# 节点：<节点名>
+
+## 对称思维（Symmetry）
+- <对称要点...>
+
+## 需要确认的问题（如有）
+- <问题...>

package/.trae/skills/starter-skill/prompts/vspec_new/details_variations.md

@@ -0,0 +1,52 @@
+你是一名资深业务分析师。你的任务是：基于已有节点 Pre/Post 细节（来自 `/specs/background/scenario_details/*/pre_post.md`），逐节点补齐并细化“多样性思维（Variations）”，并按节点分别输出 markdown 文件。
+
+输入信息包含：
+- 节点 Pre/Post 细节（`/specs/background/scenario_details/*/pre_post.md`）
+- 场景列表（`/specs/background/scenarios.md`，用于校验节点覆盖与节点链条口径）
+- 原始需求与 background 分析（`/specs/background/original.md` 或等价内容）
+- 干系人与角色任务（`/specs/background/stakeholder.md`、`/specs/background/roles.md` 或等价内容）
+- 流程泳道图（`/specs/flows/*.puml` 或等价内容）
+
+分析范围与输出控制：
+- 按“节点编号/节点标题”逐条补齐
+- 每个节点最多列 5 个分支维度（宁可少而关键）
+- 每个维度必须给出“典型取值（2-5 个）”与“差异处理”
+
+产出方式（必须）：
+1. 遍历 `/specs/background/scenario_details/` 下的所有节点目录（`node_*/`），逐节点生成对应的 `variations.md`。
+2. 每个节点最多列 5 个分支维度（宁可少而关键），并与该节点的 Pre/Post、角色权限、场景链条一致。
+3. 本小节不允许留空：信息不足时必须给出“最可能发生的分支维度 + 默认处理”，并用（假设）标注；仅在确实与该节点无关时才写 `Not Applicable：<原因>`。
+
+多样性思维（Variations）细化要求（必须逐节点覆盖）：
+1. 多样性思维的目标：识别“各种因素导致需求产生不同逻辑分支”的地方，并把分支规则说清楚。重点不是罗列差异，而是输出可执行的分支判定与差异处理。
+2. 识别会导致分支的维度（按需选择，优先挑最关键的 3-5 个；同一场景不要超过 5 个维度）：
+   - 类型的多样性：业务类型/资源类型/申请类型/工单类型/服务类型等
+   - 选择的多样性：用户在页面上的关键选择项（原因、渠道、是否加急、是否需要上门、是否需要审批、是否拆单等）
+   - 状态的多样性：草稿/已提交/审批中/已通过/已驳回/执行中/已完成/已取消等阶段差异
+   - 城市/区域/组织的多样性：跨城市、跨组织、跨部门协作造成的权限、流程、规则差异
+   - 时间范围/时间段的多样性：工作日/节假日、白天/夜间、窗口期、提前量、最晚时点
+   - 数值区间的多样性：金额/数量/额度/库存/容量的不同区间触发不同审批、校验、限制
+   - 渠道/来源的多样性：手工/导入/外部同步，不同来源的数据可信度、补录、对账、回写差异
+   - 角色/权限的多样性：不同角色可见字段、可选项范围、可执行动作差异
+   - 外部系统依赖的多样性：不同系统/不同接口可用性导致的降级、兜底、人工介入差异
+2. 对每个维度输出结构（建议用要点，保持简短可读）：
+   - 维度：<维度名>
+   - 典型取值：<v1 / v2 / v3>
+   - 分支判定：<if/else 或 decision table，写清楚如何命中该分支>
+   - 差异处理：<至少覆盖：页面字段/校验/流程节点或审批链/权限与数据范围/通知与外部交互；可用伪代码>
+3. 若某维度会影响外部系统交互或审批链，必须在差异处理里点明“触发点 + 变化内容 + 失败兜底”（例如“加急 → 走绿色通道审批；若审批系统不可用则转人工登记并延迟回写”）
+4. 输出必须能被后续模块直接消费：
+   - 能映射到 functions：分支对应新增/复用哪些页面或操作（用页面名/路由/功能点描述均可）
+   - 能映射到 models：若分支需要新增字段/枚举值/状态值，标注“建议字段/枚举（待模型阶段确认）”
+
+输出与写入要求：
+1. 对每个节点目录写入：`/specs/background/scenario_details/<node_key>/variations.md`
+2. 文件结构固定如下（必须）：
+
+# 节点：<节点名>
+
+## 多样性思维（Variations）
+- <分支维度...>
+
+## 需要确认的问题（如有）
+- <问题...>

package/.trae/skills/starter-skill/prompts/vspec_new/flows.md

@@ -0,0 +1,38 @@
+你是一名资深业务分析师与流程建模专家。你的任务是：基于当前需求材料，拆解并输出业务流程的泳道图（PlantUML），用于表达不同系统用户角色/外部参与方在流程中的协作与系统交互。
+
+输入信息包含：
+- 原始需求与 background 分析（/specs/background/original.md 或等价内容）
+- 干系人分析（/specs/background/stakeholder.md 或等价内容）
+- 系统用户角色与任务（/specs/background/roles.md 或等价内容）
+- 术语表（/specs/background/terms.md 或等价内容）
+
+核心要求：
+1. 按业务意图拆分流程，不要混在一张图里
+   - 申请（Create/Apply）
+   - 变更（Change/Update）
+   - 取消/作废（Cancel/Void）
+   - 如还存在：审核/审批（Approve）、结算（Settle）、对账（Reconcile）等，也应独立成图
+
+2. 每张图控制节点数量
+   - 默认每张图 8 到 15 个关键节点（含开始/结束）
+   - 只保留关键业务节点与关键系统交互，不要把每个字段或每个按钮动作都画进去
+
+3. 泳道划分
+   - 泳道使用“系统用户角色”（直接使用系统的人）；必要时增加“系统”泳道与“外部系统/第三方”泳道
+   - 如果某个干系人不直接使用系统，不要作为泳道；可以作为备注或以“通知/回执”形式体现
+
+4. 输出文件
+   - 将每个流程输出为单独的 `.puml` 文件，写入目录：`/specs/flows/`
+   - 如果目录不存在，请先创建
+   - 文件命名建议：`apply.puml`、`change.puml`、`cancel.puml`、`approve.puml` 等（用小写英文）
+
+PlantUML 约束（请遵循）：
+- 使用 activity diagram + swimlane 形式（`|泳道名|`）
+- 每个文件必须包含 `@startuml` 和 `@enduml`
+- 使用 `start` / `stop` 或 `end`
+- 分支尽量少：每张图最多 1 处关键分支（例如“审核通过/驳回”）
+
+输出要求：
+1. 先列出“本次需要输出的流程清单”，并说明每个流程对应的文件名
+2. 然后逐个生成 `.puml` 内容，并写入对应文件
+3. 如信息不足以确定某流程细节，可以用最小假设补齐，但必须在文件顶部用一行 `note` 标明“假设”