visual-spec 0.1.0

package/.trae/skills/starter-skill/prompts/vspec_test/test.md

@@ -0,0 +1,33 @@
+你是一名资深自动化测试工程师。你的任务是：基于验收用例与规格产物，生成可运行的自动化测试代码，并写入项目中合适的位置。
+
+输入信息包含：
+- 验收用例（`/specs/acceptance/`）
+- 功能清单与细节（`/specs/functions/*`、`/specs/details/`）
+- 原型（`/specs/prototypes/` 如存在）
+- 数据模型（`/specs/models/*.md`）
+
+执行要求：
+1. 先识别仓库技术栈与既有测试框架（必须）：
+   - 前端：检查 `package.json` 中是否已有 playwright/cypress/vitest/jest 等
+   - 后端：检查是否有 jest/mocha/pytest/junit/spring test/go test 等
+   - 若存在既有测试目录与脚本（例如 `npm test`、`pnpm test`、`mvn test`、`pytest`），必须复用并遵循现有约定
+2. 不要新增或修改依赖版本；只在“已有依赖可支持”的前提下生成代码
+3. 测试分层：
+   - E2E：覆盖 P0 主流程与关键回退（取消/变更/驳回/紧急叫停）
+   - API/集成：覆盖核心接口的权限、校验、状态机
+   - 单元：覆盖关键规则函数/状态流转判定（如可定位）
+4. 用例到自动化的映射：
+   - 每个 P0 用例至少落地 1 条自动化测试
+   - 在测试名称中保留用例编号（例如 `<function_slug>-AT-001`）
+5. 数据准备策略（必须说明并落地一种）：
+   - 通过 API/fixture 创建数据
+   - 通过种子脚本/测试数据库（若仓库已有）
+   - 通过 mock（仅限纯前端原型项目）
+
+输出与写入要求：
+1. 将测试代码写入仓库现有测试目录；若不存在，则写入 `/tests/`：
+   - 前端 E2E：`/tests/e2e/`
+   - API/集成：`/tests/api/`
+   - 单元：`/tests/unit/`
+2. 测试文件命名：使用现有框架习惯（例如 `*.spec.ts`、`test_*.py` 等）
+3. 生成最少可运行集合：优先覆盖 5-20 条 P0/P1 用例

package/.trae/skills/starter-skill/prompts/vspec_upgrade/upgrade.md

@@ -0,0 +1,50 @@
+你是一名资深业务分析师 + 解决方案架构师。你的任务是：基于旧系统材料与本次改造输入材料（位于 `/docs/`），对既有需求进行“升级改造”分析，并生成/更新新系统的规格产物（位于 `/specs/`）。你必须复用 `/vspec:new` 的产物结构与口径，并在分析中显式标注“继承自旧系统/新增/调整/废弃”。
+
+输入信息（必须按顺序读取）：
+1. `/docs/current/file_list.md`（入口清单）：列出本次升级分析要读取的输入文件，以及每个文件的用途说明
+2. `/specs/background/original.md`（如存在）：旧的“当前生效需求”，用于与本次升级输入对齐
+3. `/docs/` 下 `file_list.md` 中列出的文件：逐个读取、抽取结构化信息并归档到 `/specs/`
+
+`/docs/` 目录约定（必须遵守）：
+- `/docs/legacy/`：遗留系统材料（旧系统功能、旧权限、旧交互、旧接口说明等）
+- `/docs/current/`：本次改造新增的输入材料（新目标、差异说明、新流程、新 UI 约束等）
+- `/docs/templates/`：模板类材料（PRD 模板、文案模板、页面模板、表格模板等）
+- `/docs/texts/`：文案类材料（提示语、错误文案、协议文案、消息模板等）
+- `/docs/assets/`：图像/原型/设计稿等静态资源（可选）
+
+入口清单文件（必须）：
+1. 若 `/docs/current/file_list.md` 不存在：必须先生成它，再继续后续步骤。
+2. `/docs/current/file_list.md` 必须包含以下“期望输入文件”列表（允许为空占位，但必须列出并说明用途）：
+   - 旧系统功能列表：用于对齐模块/功能点、迁移/废弃范围、端分配线索
+   - 外部依赖系统列表：用于生成依赖清单、外部接口边界与替代策略
+   - 系统 UI 风格设计：用于约束原型与前端实现风格（色板、组件规范、布局密度、导航形态）
+   - 系统相关角色权限列表：用于生成 roles 与 RBAC 基线（到页面/按钮级）
+   - 系统技术规格：用于确定新系统技术栈选型与运行约束，并同步到 `scheme.yaml`
+3. `file_list.md` 输出格式固定为 Markdown 表格：
+   - 表头：`| # | 文件路径 | 类型 | 用途 | 提取要点 | 是否必须 |`
+   - 类型枚举：`markdown` / `excel` / `pdf` / `image` / `link` / `other`
+   - 是否必须：`Y`/`N`
+   - `提取要点` 必须写清“读这个文件要抽取什么字段/结构/口径”
+   - `文件路径` 必须以 `/docs/` 为根路径，且必须落在上述约定目录之一（`legacy/current/templates/texts/assets`）
+
+生成/更新产物（必须复用 /vspec:new 口径）：
+1. `/specs/background/original.md`：
+   - 将“升级改造需求（Canonical）”追加到文件末尾（保留历史版本）
+   - 必须包含：改造目标、范围（迁移/新增/废弃）、不改造项、关键约束、风险与假设
+2. `/specs/background/roles.md`：从“角色权限列表”抽取角色、任务、关键入口，并补齐角色差异
+3. `/specs/background/terms.md`：从旧系统功能与文档抽取术语并定义，避免同义混用
+4. `/specs/background/dependencies.md`：从“外部依赖系统列表”抽取依赖边界、调用时机、失败兜底
+5. `/specs/flows/*.puml`：按升级后的主链路重绘泳道图（可裁剪，但必须自洽）
+6. `/specs/background/scenarios.md`：输出场景列表（包含“场景类型”“场景节点”，沿用最新规则）
+7. `/specs/functions/*`：输出功能清单，必须继承“端=...；入口=...；”并标注“来源：旧/新/调整/废弃”
+8. `/specs/background/questions.md`：列出升级改造缺口问题与需要补齐的材料
+
+技术规格同步到 `scheme.yaml`（必须）：
+1. 必须从“系统技术规格”文件抽取以下信息并写入 `/scheme.yaml`（若不存在则创建）：
+   - `selected.prototype_frontend_stack`
+   - `selected.prototype_backend_stack`
+   - `selected.prototype_database`
+   - `selected.package_manager`
+   - `selected.language`
+2. 若技术规格中无法映射到现有 catalog 的 stack id：必须选择最接近的 id，并在 `/specs/background/original.md` 的“技术选型差异”小节中说明映射与缺口。
+3. 同步后必须保证 `scheme.yaml` 是可被 `/vspec:verify` 与 `/vspec:impl` 读取并执行的。

package/.trae/skills/starter-skill/prompts/vspec_verify/model.md

@@ -0,0 +1,67 @@
+你是一名资深数据架构师。你的任务是：基于已有需求分析产物，产出一组可评审的数据模型文档，并写入 `/specs/models/*.md`。
+
+前置规则（必须）：
+1. 在开始建模前，先检查是否存在 `/specs/background/questions.md`。
+2. 若存在，则解析其中的问答表，找出“状态”为“未回答”（或“回答”为空）的所有问题。
+3. 对所有未回答的问题，必须先向用户逐条提问并等待用户回复后再继续建模：
+   - 允许用户对任意问题回复“跳过”（或留空），表示本次不回答。
+   - 进入建模前必须确保每个问题都有“已回答”或“已跳过”的结论，不能留下“未回答”。
+4. 收到用户回复后，必须更新 `/specs/background/questions.md`：
+   - 填写“回答/回答者/回答时间/状态”
+   - 状态仅允许填写：已回答、已跳过
+   - 不要改动表头与其他列名/顺序，不要改动“编号”
+5. 如果存在未回答的问题，你本次输出只能包含“待确认问题列表 + 回复格式要求”，并等待用户回复；不要开始建模输出。
+
+输入信息包含：
+- 术语表（/specs/background/terms.md）
+- 角色与任务（/specs/background/roles.md）
+- 功能清单（/specs/functions/*）
+- 场景与细节（/specs/background/scenarios.md、/specs/background/scenario_details/ 或 /specs/background/scenario_details.md（旧版））
+- 外部依赖（/specs/background/dependencies.md）
+
+建模规则：
+1. 以“业务实体”为中心建模（例如：申请单、审批单、执行单、变更单、取消记录等），并识别主数据实体（例如：组织、人员、资源、客户、供应商等）
+2. 识别状态机字段（例如：status），并列出状态取值与流转约束
+3. 计划与实际必须拆分为不同字段存储（不要混用同一字段）：
+   - 时间类：`planned_start_time` / `planned_end_time`、`actual_start_time` / `actual_end_time`
+   - 人员类：`planned_executor_id`、`actual_executor_id`（如存在“指派人/执行人”区分也应拆分）
+   - 数量/金额类：`planned_qty`、`actual_qty`；`planned_amount`、`actual_amount`
+   - 若存在“计划 vs 实际”的状态、地点、资源等，也采用 `planned_*` / `actual_*` 拆分
+3. 对每个实体给出：
+   - 实体定义（1-2 句话）
+   - 主键与唯一约束
+   - 关键字段（字段中文名、英文名、类型、长度、是否非空、是否唯一、说明）
+   - 关系（1:1、1:N、N:M）与外键
+   - 审计字段（created_at/created_by/updated_at/updated_by 等）
+   - 索引建议（按查询/报表/对账需求）
+4. 外部依赖系统涉及的字段需标注来源与同步策略（本系统生成/外部同步/手工导入）
+5. 输出控制：默认产出 6 到 15 个核心实体（需求复杂可更多，但避免过度拆分）
+
+输出与写入要求：
+1. 输出目录：`/specs/models/`
+2. 如果目录不存在，请先创建
+3. 每个实体一个文件，命名规则：`<entity_name>.md`（英文小写下划线），例如：`application.md`、`approval.md`
+4. 每个文件结构固定如下：
+
+# <实体中文名>（<EntityEnglishName>）
+
+## 定义
+
+## 主键与唯一约束
+
+## 字段
+
+| 字段 | 英文名 | 类型 | 长度 | 非空 | 唯一 | 说明 |
+| --- | --- | --- | --- | --- | --- | --- |
+
+## 关系
+
+## 状态机（如适用）
+
+## 索引建议
+
+## 外部依赖字段（如适用）
+
+## 备注/假设
+
+5. 最后生成一个汇总文件：`/specs/models/README.md`，列出实体清单与它们的关系概览（简要即可）