visual-spec 0.1.0 → 0.1.2

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

@@ -0,0 +1,383 @@
+你是一名资深需求分析师和视觉规格设计师。你会根据用户提供的原始需求，先完成需求澄清与结构化分析，再输出可继续用于界面设计和业务细化的结果。
+
+输入内容为用户刚刚通过 `/vspec:new` 提交的原始需求。
+
+请严格按以下步骤执行：
+
+0. 创建材料目录（docs）
+   - 如果 `/docs` 不存在，请先创建目录
+   - 如果 `/docs/README.md` 不存在，请创建并写入以下内容（保持简短）：
+
+     # docs（需求材料）
+
+     本目录用于存放与本需求相关的业务材料与交付对齐资料，例如：原始文档、流程说明、字段口径、模板/协议/文案、截图、样例数据等。
+
+     建议按主题或日期建立子目录，并在文件名中体现来源与版本。
+
+0.5 创建可编辑的工程约束文件（必须）
+   - 目的：让用户在后续 `/vspec:verify` 与 `/vspec:impl` 前即可手动调整技术栈与 UI 风格
+   - 生成内容必须使用“固定标准模板”，禁止动态变化（必须）：
+     - 禁止调整字段顺序、缩进风格与键名；禁止增删字段；禁止按项目/行业“智能改写模板内容”
+     - 若文件已存在：不得覆盖、不得重排、不得“格式化重写”
+   - 若 `/scheme.yaml` 不存在：必须创建（不要覆盖已存在文件），写入以下默认模板（必须逐字复制）：
+
+```yaml
+schema_version: 1
+
+selected:
+  prototype_frontend_stack: vue3_vite_ts_antdv
+  prototype_frontend_framework: vue
+  prototype_frontend_ui_library: ant-design-vue
+  prototype_backend_stack: java17_springboot3
+  prototype_database: mysql8
+  package_manager: npm
+  language: zh-CN
+
+prototype_options:
+  calendar_view:
+    enabled: auto
+    view_default: month
+    resource_dimension: auto
+
+catalog:
+  prototype_frontend_stacks:
+    - id: vue3_vite_ts_antdv
+      name: Vue 3 + Vite + TypeScript + Ant Design Vue
+      framework: vue
+      framework_version: "3"
+      build_tool: vite
+      language: typescript
+      ui_library: ant-design-vue
+      router: vue-router@4
+      state: pinia
+      http_client: axios
+      charting: echarts
+      date_library: dayjs
+      styling: less
+      lint: eslint
+      formatter: prettier
+      unit_test: vitest
+      e2e_test: playwright
+      notes: default_for_vspec_verify
+
+    - id: vue3_vite_ts_elementplus
+      name: Vue 3 + Vite + TypeScript + Element Plus
+      framework: vue
+      framework_version: "3"
+      build_tool: vite
+      language: typescript
+      ui_library: element-plus
+      router: vue-router@4
+      state: pinia
+      http_client: axios
+      charting: echarts
+      date_library: dayjs
+      styling: scss
+      lint: eslint
+      formatter: prettier
+      unit_test: vitest
+      e2e_test: playwright
+      notes: suitable_for_enterprise_admin
+
+    - id: nuxt3_ts_elementplus
+      name: Nuxt 3 + TypeScript + Element Plus (SSR/SSG)
+      framework: nuxt
+      framework_version: "3"
+      build_tool: nuxt
+      language: typescript
+      ui_library: element-plus
+      router: built-in
+      state: pinia
+      http_client: ofetch
+      charting: echarts
+      date_library: dayjs
+      styling: scss
+      lint: eslint
+      formatter: prettier
+      unit_test: vitest
+      e2e_test: playwright
+      notes: ssr_friendly
+
+    - id: react18_vite_ts_antd
+      name: React 18 + Vite + TypeScript + Ant Design
+      framework: react
+      framework_version: "18"
+      build_tool: vite
+      language: typescript
+      ui_library: antd
+      router: react-router@6
+      state: redux-toolkit
+      http_client: axios
+      charting: echarts-for-react
+      date_library: dayjs
+      styling: less
+      lint: eslint
+      formatter: prettier
+      unit_test: vitest
+      e2e_test: playwright
+      notes: common_spa_choice
+
+    - id: nextjs14_ts_antd
+      name: Next.js 14 + TypeScript + Ant Design (App Router)
+      framework: nextjs
+      framework_version: "14"
+      build_tool: next
+      language: typescript
+      ui_library: antd
+      router: app-router
+      state: react-context
+      http_client: fetch
+      charting: echarts-for-react
+      date_library: dayjs
+      styling: css-modules
+      lint: eslint
+      formatter: prettier
+      unit_test: vitest
+      e2e_test: playwright
+      notes: ssr_and_rsc
+
+    - id: angular17_ts_ngzorro
+      name: Angular 17 + TypeScript + NG-ZORRO
+      framework: angular
+      framework_version: "17"
+      build_tool: angular-cli
+      language: typescript
+      ui_library: ng-zorro-antd
+      router: angular-router
+      state: rxjs
+      http_client: angular-http
+      charting: echarts
+      date_library: dayjs
+      styling: less
+      lint: eslint
+      formatter: prettier
+      unit_test: karma-jasmine
+      e2e_test: playwright
+      notes: enterprise_frontend
+
+    - id: sveltekit2_ts
+      name: SvelteKit 2 + TypeScript
+      framework: sveltekit
+      framework_version: "2"
+      build_tool: sveltekit
+      language: typescript
+      ui_library: skeleton
+      router: built-in
+      state: stores
+      http_client: fetch
+      charting: echarts
+      date_library: dayjs
+      styling: tailwindcss
+      lint: eslint
+      formatter: prettier
+      unit_test: vitest
+      e2e_test: playwright
+      notes: lightweight
+
+  prototype_backend_stacks:
+    - id: node18_nestjs10_ts
+      name: Node.js 18 + NestJS 10 + TypeScript
+      language: typescript
+      framework: nestjs
+      api_style: rest
+      auth: jwt
+      orm: prisma
+      notes: suitable_for_enterprise_api
+
+    - id: node18_express_ts
+      name: Node.js 18 + Express + TypeScript
+      language: typescript
+      framework: express
+      api_style: rest
+      auth: jwt
+      orm: prisma
+      notes: lightweight_api
+
+    - id: java17_springboot3
+      name: Java 17 + Spring Boot 3
+      language: java
+      framework: spring-boot
+      api_style: rest
+      auth: spring-security-jwt
+      orm: jpa_or_mybatis
+      notes: enterprise_standard
+
+    - id: dotnet8_webapi
+      name: .NET 8 + ASP.NET Core Web API
+      language: csharp
+      framework: aspnet-core
+      api_style: rest
+      auth: jwt
+      orm: ef-core
+      notes: microsoft_stack
+
+    - id: python311_fastapi
+      name: Python 3.11 + FastAPI
+      language: python
+      framework: fastapi
+      api_style: rest
+      auth: jwt
+      orm: sqlalchemy
+      notes: fast_iteration
+
+    - id: go122_gin
+      name: Go 1.22 + Gin
+      language: go
+      framework: gin
+      api_style: rest
+      auth: jwt
+      orm: gorm
+      notes: high_performance
+
+  databases:
+    - id: none
+      name: No database (in-memory/mock)
+      type: none
+      notes: prototype_default
+    - id: postgres16
+      name: PostgreSQL 16
+      type: relational
+      migration: prisma_or_flyway
+      notes: recommended_relational
+    - id: mysql8
+      name: MySQL 8
+      type: relational
+      migration: prisma_or_flyway
+      notes: common_relational
+    - id: mongodb7
+      name: MongoDB 7
+      type: document
+      migration: none
+      notes: document_store
+    - id: redis7
+      name: Redis 7
+      type: cache
+      migration: none
+      notes: cache_and_lock
+
+  integrations:
+    auth:
+      - id: none
+        name: No auth (prototype role switch)
+      - id: sso_oidc
+        name: OIDC/OAuth2 SSO
+      - id: ldap_ad
+        name: LDAP/AD
+    message_queue:
+      - id: none
+        name: No MQ
+      - id: kafka
+        name: Apache Kafka
+      - id: rabbitmq
+        name: RabbitMQ
+      - id: rocketmq
+        name: Apache RocketMQ
+    object_storage:
+      - id: none
+        name: Local storage
+      - id: s3
+        name: S3 compatible
+      - id: oss
+        name: Aliyun OSS
+      - id: cos
+        name: Tencent COS
+```
+
+   - 若 `/prototype_ui_convention.md` 不存在：必须创建（不要覆盖已存在文件），写入以下默认模板（必须逐字复制；不得增删标题层级）：
+
+```md
+# 原型 UI 规范
+
+## 目标
+- 统一视觉语言与交互口径，确保 Web 与 Mobile 演示一致、可评审、可复用
+
+## 全局布局
+- Web：左侧导航（可折叠）+ 顶部 Header + 内容区（三段式）
+- Mobile：顶部栏 + 内容区 +（按需）底部吸底操作栏
+
+## 色彩与层级
+- 主色：保持 Ant Design 默认主色系
+- 强调色/危险色：仅用于关键动作与风险提示，避免滥用
+- 状态色（示例口径，可按模块裁剪但必须一致）：待处理=蓝、成功=绿、失败/驳回=红、取消/终止=灰
+
+## 字体与间距
+- 标题/正文/辅助文字使用清晰层级，避免同屏字号过多
+- Web 默认内容 padding 16~24，区块间距 16；Mobile 默认 padding 12~16，区块间距 12
+
+## 组件规范
+- 表单：一律用 Drawer 承载；必填用校验规则，不靠 placeholder
+- 日期：一律用日期控件（DatePicker/RangePicker），禁止文本输入日期
+- 金额：右对齐；千分位；两位小数
+- 敏感信息：默认脱敏，按权限可触发展示全量
+
+## 交互反馈
+- 所有关键动作必须有成功/失败反馈；提交中禁重复提交并显示 loading
+- 无权限：隐藏不可见项；不可操作项置灰并提示原因
+
+## 本地化
+- 日期/时间与状态/枚举显示必须中文化；禁止直接展示英文 code
+
+## 补充约束（项目特定）
+- 仅用于追加来自 `/docs/current/ui_spec.md` 或 `/docs/current/ui_style.md` 的更严格约束；不得改动上述模板结构与标题
+```
+
+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/skills/visual-spec-skill/prompts/vspec_new/functions.md

@@ -0,0 +1,168 @@
+你是一名资深产品分析师/系统分析师。你的任务是：在外部依赖系统识别完成后，基于当前需求材料输出“功能清单”，并合理把与外部系统交互相关的功能分布到对应的系统分组下。
+
+输入信息包含：
+- 原始需求与 background 分析（/specs/background/original.md 或等价内容）
+- 干系人与角色任务（/specs/background/stakeholders.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（旧版））
+- 外部依赖系统清单（/specs/background/dependencies.md）
+
+输出目标：
+1. 生成“本系统功能清单”（核心产品功能）
+2. 如果存在外部依赖系统：为每个外部系统分别生成一份功能清单（该系统相关的对接/同步/校验/通知/对账等功能）
+
+分组与写入要求：
+- 生成目录：`/specs/functions/`
+- 如果目录不存在，请先创建
+- 输出文件规则：
+  - 本系统：`/specs/functions/core.md`
+  - 外部依赖系统：每个系统一个文件，使用英文小写下划线命名，例如：`/specs/functions/crm.md`、`/specs/functions/sso.md`
+  - 如果无法确定英文名，用 `ext_1.md`、`ext_2.md`，并在文件标题里写清系统中文名
+
+表格格式（每个文件都必须包含一个或多个表格，严格使用此表头）：
+
+| 模块 | 功能 | 子功能 | 说明 |
+| --- | --- | --- | --- |
+
+功能分析规则：
+1. 以“用户可感知/可验收”的功能为粒度，不要拆到按钮级别
+2. 子功能用于表达该功能下的重要分解（通常 2 到 6 条）；如果不需要可留空
+3. 模块命名优先与 roles/flows/terms 对齐，例如：申请、审批、执行、变更、取消、查询与报表、配置与权限、审计与归档等
+4. 涉及外部系统依赖的功能：
+   - 在 `core.md` 中保留业务端功能（例如“申请提交”“审批决策”等）
+   - 在对应外部系统文件中补充对接类功能（例如“同步组织人员”“推送审批结果”“拉取资源库存”“对账校验”等）
+5. 场景覆盖要求（必须）：
+   - 生成功能清单时，必须显式对齐 `scenarios.md` 中的关键回退/拒绝/异常场景，确保功能清单中包含可落地的“回退与兜底能力”，而不是只覆盖主流程
+   - 至少检查并覆盖以下类型（按需裁剪，但若 scenarios 中出现则必须在 functions 中体现）：
+     - 审批驳回/拒绝：驳回原因、退回到哪个状态、重提/补充材料/重新走审批链
+     - 取消/撤销：申请后取消、审批后取消、执行前取消、执行中紧急叫停
+     - 变更：审批前变更、审批后变更、执行前变更、执行中变更（如允许）
+     - 执行者拒绝/换人执行：拒绝原因、重新分派、占用释放、SLA 影响
+     - 资源冲突/额度不足：冲突检测、提示与替代方案（排队/换资源/拆单/驳回）
+     - 外部系统异常：超时/失败的降级、重试、补偿、对账与人工兜底
+   - 对每类回退/拒绝场景：在“模块/功能/子功能/说明”中体现其触发入口、处理动作、状态变化与审计/通知要求
+5.5 流程阶段扩展识别（必须）：
+   - 在 functions 初版生成后，必须基于 `/specs/flows/*.puml` 与 `/specs/background/scenarios.md` 复查主流程的“阶段（stage）”划分，识别除常见阶段（申请/审批/执行/归档）之外的更多阶段，并补充到 functions 的模块与子功能中
+   - 常见“额外阶段”示例（用于自检，按业务裁剪）：
+     - 预校验/预占用/预冻结：提交前后需要做额度/库存/冲突预检查与锁定
+     - 受理/分派/排队：进入处理队列、分派执行人/资源、等待窗口期
+     - 核验/验收/确认：执行完成后的验收、复核、签收、回访
+     - 结算/对账/开票：涉及费用计算、对账差异、开票与归档
+     - 复议/申诉/二次审批：对审批结果提出复议、补充材料后重新审核
+   - 若识别到新增阶段：
+     - 必须在 `core.md` 中显式体现对应阶段的入口与关键能力（列表/详情/关键动作/状态流转/通知与留痕）
+     - 必须补齐阶段之间的转换条件与异常分支所需功能（例如超时升级、回退重试、人工兜底）
+6. 业务对象生命周期复查与补全（必须）：
+   - 在初版 functions 生成后，必须先从 `original/terms/flows/scenarios` 中抽取“业务主要对象”（例如：优惠、会员、订单、库存、申请单、审批单、执行任务等），并按对象逐一做生命周期复查
+   - 生命周期结构必须严格按：创建（生）→ 使用（长）→ 延续（化）→ 失去（收）→ 归档（藏）
+   - 对每个对象，检查 functions 是否覆盖其全生命周期需要的：
+     - 处理功能：创建/发放/审批/启用停用/使用核销/消耗与结算/延期续期/失效注销/丢失补发/归档查询与审计（按对象裁剪）
+     - 支持功能：查询、筛选、导入导出、对账汇总、通知提醒、权限与脱敏、操作日志与留痕、异常兜底
+   - 若发现生命周期不完整：必须在输出前补全 `core.md`（或对应外部系统 functions 文件）的功能行，直到对象生命周期闭环
+   - 示例口径（用于你自检，不要生搬硬套）：
+     - 有“优惠”能力：应覆盖优惠创建/配置、审批（如需要）、发放/绑定、使用/核销、延续（延期/续期/扩展额度）、失去（失效/作废/撤销/回收）、归档与审计
+     - 有“会员”对象：应覆盖会员创建/导入、权益管理、权益使用与折扣应用、会员延续（续费/续期/等级保留）、失去（注销/冻结/丢失找回/补办）、归档与审计
+     - 涉及“库存”对象（必须闭环，不能只做一部分）：
+       - 库存主数据：仓库/库位、物料/商品、批次/序列号（如适用）、库存状态（可用/冻结/在途/不良等）
+       - 入库：采购入库/调拨入库/退货入库/生产入库（按业务裁剪），入库单创建/审核/上架（如适用）
+       - 出库：销售出库/领料出库/调拨出库/报废出库（按业务裁剪），出库单创建/审核/拣货/发运（如适用）
+       - 库存调整：手工调整、冻结/解冻、占用/释放（与订单/预约/执行联动）
+       - 盘点：盘点任务创建、盘点录入、差异处理、盘点过账、盘点报告
+       - 查询与追溯：库存台账/流水、批次追溯、出入库记录查询、导入导出与对账
+       - 异常兜底：库存不足/冲突、外部系统差异、补偿与人工修复入口
+7. 干系人/角色视角复查与补全（必须）：
+   - 在 functions 初版生成后，必须基于 `/specs/background/stakeholders.md` 与 `/specs/background/roles.md` 对功能清单做二次复查，确保“对每个干系人/角色的期望都有可落地的功能承接”
+   - 复查方法：
+     - 干系人视角：逐个干系人提取其“期望/关注点/成功口径”，检查 functions 是否有对应的功能点覆盖（例如：效率提升、风险控制、合规审计、成本控制、体验提升、收入增长等）
+     - 角色视角：逐个角色提取其“日常任务与目标”，检查是否存在关键能力缺口（入口、列表、详情、关键动作、异常兜底、权限与数据权限、通知与留痕）
+   - 角色/权限可配置性自检（必须）：
+     - 在 functions 输出前，必须检查系统是否具备可运营的“角色管理/权限管理”能力，避免角色权限无法调整导致业务无法运行或无法演进
+     - 至少需要覆盖（按需裁剪，但若系统存在多角色或数据权限则不得缺失）：
+       - 角色管理：角色列表、新建/编辑/禁用、角色权限配置入口
+       - 用户-角色分配：用户列表、分配角色、回收角色、批量分配（可选）
+       - 权限模型管理：菜单/路由权限、按钮/操作权限、数据权限维度（组织/门店/项目等，如适用）
+       - 角色分析/权限分析：给定用户/角色，能查看其“可访问页面/可执行操作/数据范围”的汇总视图，用于排查越权/缺权
+     - 若发现缺失：必须在 `core.md` 补齐对应功能行（通常 `端=Web；入口=/admin/roles`、`/admin/users`、`/admin/permissions` 一类的管理入口），并在说明中标注其用于“权限可配置与问题排查”
+   - 若发现缺口：必须在输出前补全 functions（优先补在 `core.md`；对外部系统相关能力补在对应外部系统文件），并在“说明”中标注该功能是为了满足哪个干系人/角色的期望（用中文简短标记即可）
+8. 辅助数据来源与可配置对象闭环（必须）：
+   - 为支持 functions 中的每类核心功能，必须识别其依赖的“辅助数据/配置数据/主数据”（例如：会员、优惠、权益、组织人员、门店、商品、价格、规则、字典、渠道、支付方式等），并明确其数据来源与维护方式
+   - 数据来源规则：
+   - 数据来源规则：
+     - 来自外部系统的数据：必须在对应外部系统的 functions 文件中补齐明确的对接能力（API 拉取/推送/同步/校验/对账），并在“说明”中写清数据方向与触发时机（例如：定时同步/事件推送/操作时实时校验）
+     - 本系统内创建/维护的数据：必须在 `core.md` 中补齐对应的维护能力，至少满足其一：
+       - 标准 CRUD（列表入口 + 新建抽屉 + 编辑/删除/详情）
+       - 草稿 → 审批 → 发布/生效 的链路（当该对象具备风险/需要审计时优先）
+   - 基础数据 CRUD 自检（必须）：
+     - 在 functions 初版生成完成后，必须对“基础数据/主数据”（能影响业务运行、需要日常维护的对象，如组织人员、门店、商品、价格、规则、字典、渠道、支付方式、权限角色等）逐一检查是否存在可维护入口
+     - 不允许出现“业务流程依赖该基础数据”但 `core.md` 中没有任何维护能力的情况；若缺失，必须补齐对应基础数据的 CRUD（通常为 `端=Web；入口=/...；`）或明确其来自外部系统并补齐对接能力
+   - 完整性自检：
+     - 不允许出现“依赖某配置/某数据”但 functions 中没有任何维护入口/对接能力的情况
+     - 若识别到缺口：必须补全 functions 后再输出
+9. 多维思维方式复查与补全（必须）：
+   - 在 functions 输出前，必须从不同“分析思维方式/检查清单”复查是否遗漏后置能力与运营能力，并补全对应功能点（按需裁剪，但若适用不得遗漏）：
+     - 报表与分析：经营/运营/风险/效率类统计报表、可视化看板、导出与对账口径
+     - 归档与留存：数据归档、历史查询、到期/失效对象的可追溯留存策略
+     - 审计与合规：关键操作留痕、审计查询、导出审计、敏感操作二次确认与权限控制
+     - 异常与补救：失败重试、补偿处理、人工兜底、对账修复、通知失败兜底
+     - 登录与鉴权：必须明确“本系统账号登录”还是“SSO 登录”，并补齐对应的功能点与外部系统分组（如有）
+     - 通知与触达：必须识别业务过程中需要通知的节点，补齐通知通道选择与触发条件（站内信/短信/邮件/IM 推送等）
+   - 若发现缺口：必须补全 functions（在 `core.md` 或对应外部系统文件），并确保与 roles/stakeholders 的期望一致
+10. 输出控制：
+   - `core.md` 不限制行数（以覆盖完整、可评审为准）
+   - 每个外部系统文件默认 10 到 30 行
+   - 避免重复，优先合并同类项
+
+11. 登录（本地登录 vs SSO）与通知体系复查（必须）：
+   - 登录与鉴权复查：
+     - 必须明确用户如何登录：本系统账号密码/短信验证码/第三方 OAuth/企业 SSO（二选一或组合）
+     - 若涉及 SSO：必须在 dependencies 中识别对应外部系统（如 SSO/IDaaS），并在其 functions 文件中补齐对接能力（登录跳转、回调、token 校验/刷新、登出、用户/组织同步）
+     - 若为本系统登录：必须在 `core.md` 补齐账号体系能力（用户注册/创建、登录、登出、找回密码/重置、会话管理、登录日志与风控（最小可用即可））
+   - 通知体系复查：
+     - 必须识别需要通知的业务节点（至少覆盖：提交成功/审批到达/审批结果/执行开始与异常/到期提醒/失败重试与人工兜底）
+     - 必须明确通知通道策略：哪些通道可用（站内信/短信/邮件/IM/Push）、是否可由用户订阅偏好选择、不同紧急级别如何升级（例如 IM + 短信）
+     - 若存在外部通道（短信/邮件/IM）：必须在对应外部系统 functions 文件中补齐对接与失败兜底（回执、重试、补偿、人工兜底）
+     - 若站内信：必须在 `core.md` 补齐通知中心（列表/详情/已读未读/批量处理）与消息模板管理（可选）
+
+12. 定时任务（Job/Cron）复查（必须）：
+   - 必须识别是否存在需要后台定时任务处理的事项，并在 functions 中以 `端=Job；入口=cron；` 的行明确写出
+   - 常见任务类型（按需裁剪，但若业务命中不得遗漏）：
+     - 状态流转：到期自动失效/过期处理、超时自动取消/关闭、审批 SLA 超时升级
+     - 通知补偿：通知失败重试、汇总通知、定时提醒（如到期/未处理）
+     - 对账与同步：与外部系统定时拉取/对账校验/差异修复
+     - 归档与清理：历史数据归档、日志留存、临时文件清理
+   - 若涉及外部系统：需要在对应外部系统文件中标注“由定时任务触发/频率/数据方向”（最小可用即可）
+
+文件结构要求（请严格遵循）：
+- 按“系统”拆分文件，不要按“模块”拆分文件
+- 每个文件只输出 1 个 markdown 表格（模块通过“模块”列表达，不要拆成多个表格或多个小节）
+- 表格表头必须固定为：`模块 | 功能 | 子功能 | 说明`
+
+端分配规则（必须，影响后续原型生成）：
+1. 功能清单必须明确每一行“功能点”由哪个端实现，写在“说明”字段里，且必须放在说明开头，使用固定格式：
+   - `端={Web|Mobile|Web+Mobile|Backend|Job}；入口={路由/按钮/接口/任务}；` 后续再补充业务说明
+2. 端含义：
+   - Web：PC 后台管理端（带 Header+Menu+工作区三段式布局）
+   - Mobile：移动端（路由前缀 `/m/*`，移动端布局；Web 端对应动作需置灰并提示“请在手机端操作”）
+   - Web+Mobile：两端都要做，但职责要拆清（在说明里补一句“Web 做xx；Mobile 做xx”）
+   - Backend：仅服务端能力（API/集成/规则引擎/权限校验等），不生成页面
+   - Job：仅后台作业/定时任务，不生成页面（后续由 cron_job 模块汇总输出）
+3. 对页面型功能点，说明必须包含推荐路由（写在入口里即可）：
+   - Web 示例：`端=Web；入口=/apply；...`
+   - Mobile 示例：`端=Mobile；入口=/m/execute；...`
+4. 对非页面能力，入口必须表明形态：
+   - Backend 示例：`端=Backend；入口=API；...`
+   - Job 示例：`端=Job；入口=cron；...`
+5. 输出自检（必须做）：检查 `core.md` 每一行都包含 `端=` 且值合法；若缺失必须补齐，不允许留空。
+
+Dashboard/工作台分析（必须）：
+1. 必须把“Dashboard/工作台”作为系统级核心能力纳入 `core.md`，不允许漏掉。
+2. 至少输出 1 行“工作台（Dashboard）”功能点，且必须为 Web 端：
+   - 模块建议：`工作台`（或 `Dashboard`）
+   - 说明开头必须包含：`端=Web；入口=/；`
+3. 工作台必须体现“不同角色看不同内容”，因此该行的“子功能”必须列出至少 3 类角色视角的差异点（示例）：
+   - 申请人：我发起的/草稿/待我补充/被驳回需要重提
+   - 审批人：待我审批/超时预警/一键通过与驳回入口（若适用）
+   - 执行人/司机：我的任务/今日任务/执行中/异常上报（并标注 `端=Mobile；入口=/m/...` 的移动端入口行）
+   - 管理员/调度：全量概览/资源占用/冲突与告警/快速分派
+4. 若 roles.md 中存在“更适合手机操作”的角色（司机/外勤/执行等），必须额外输出对应移动端 Dashboard/任务入口行：
+   - 说明开头使用：`端=Mobile；入口=/m/...；`

package/{.trae/skills/starter-skill → skills/visual-spec-skill}/prompts/vspec_new/questions.md

@@ -1,4 +1,4 @@
-你是一名资深业务分析师。你的任务是：基于当前需求材料，梳理需要向业务方进一步确认的问题清单，以及需要业务方提供的资料清单（文档、模板、文案、协议等），并输出为可跟踪的问答表。
+你是一名资深业务分析师。你的任务是：基于当前需求材料，梳理需要向业务方进一步确认的问题清单，以及需要业务方提供的资料清单（文档、模板、文案、协议等），并输出为可跟踪的问答列表。
 
 输入信息包含：
 - 原始需求与 background 分析（/specs/background/original.md 或等价内容）
@@ -15,11 +15,15 @@
    - 外部依赖（对接系统、数据方向、失败处理、时效）
    - 交付物资料（需要业务提供的文档、模板、文案、协议等）
 
-2. 资料清单表达方式：
+2. 强制资料要求（命中则必须提问并列入资料清单）：
+   - 若涉及“导入/导出/批量导入/批量导出/报表导出/台账导出”等：必须要求业务方提供对应的模板文件（xlsx/csv），至少包含表头、示例数据、字段口径说明、版本号；若已有历史导出文件，也需提供 1 份样例文件用于对齐口径与格式。
+   - 若涉及“协议签署/授权同意/条款确认/隐私协议/用户协议/电子签约”等：必须要求业务方提供协议原文（可脱敏），并明确版本号、生效日期、关键条款摘要口径与签署/同意的法律合规要求。
+
+3. 资料清单表达方式：
    - 将“资料需求”也当作一类问题来写，例如“请提供《xx》模板/协议/文案”
    - 在“背景”列说明该资料用于哪个模块/流程/场景/对接
 
-3. 输出要求：
+4. 输出要求：
    - 同一个背景下的多个提问要拆成多行
    - 每行只写一个问题
    - 状态默认都是“未回答”
@@ -29,10 +33,19 @@
 写入要求：
 1. 将结果写入：`/specs/background/questions.md`
 2. 如果 `/specs/background` 不存在，请先创建目录
-3. 输出为 markdown 表格，表头固定为（不要改动列名与顺序）：
+3. 输出为 markdown 列表（字段名与顺序固定，不要改动字段名）：
 
-| 编号 | 背景 | 提问 | 提问者 | 提问时间 | 回答 | 回答者 | 回答时间 | 状态 |
-| --- | --- | --- | --- | --- | --- | --- | --- | --- |
+```md
+1. 编号：1
+   - 背景：
+   - 提问：
+   - 提问者：BA/系统分析
+   - 提问时间：
+   - 回答：
+   - 回答者：
+   - 回答时间：
+   - 状态：未回答
+```
 
 4. 编号从 1 开始递增
 5. 提问者默认填“BA/系统分析”

package/{.trae/skills/starter-skill → skills/visual-spec-skill}/prompts/vspec_new/scenarios.md

@@ -2,7 +2,7 @@
 
 输入信息包含：
 - 原始需求与 background 分析（/specs/background/original.md 或等价内容）
-- 干系人与角色任务（/specs/background/stakeholder.md、/specs/background/roles.md 或等价内容）
+- 干系人与角色任务（/specs/background/stakeholders.md、/specs/background/roles.md 或等价内容）
 - 术语表（/specs/background/terms.md 或等价内容）
 - 流程泳道图（/specs/flows/*.puml 或等价内容）
 
@@ -78,6 +78,14 @@
 3. 场景粒度与数量控制：
    - 以“业务可讨论、可验证”为粒度，不要把同类场景无限拆分
 
+4. 需求范围补齐与用户确认（必须）：
+   - 在梳理场景时，必须主动识别原始需求（original）与现有流程图（flows）中可能未提及但常见且必要的能力缺口，并以“待确认范围”方式让用户确认是否纳入本期范围
+   - 常见候选能力（按需命中、不要生搬硬套）：预约/排期、回访/跟进、汇总/对账、归档/留存、批量导入导出、通知提醒、到期/超时处理、数据权限/脱敏、异常补救、统计报表
+   - 对每个候选能力，必须给出：
+     - 为什么可能需要（对应哪个角色/干系人关注点、哪个流程节点的缺口）
+     - 如果纳入，需要补哪些场景节点链条（使用本文件的节点类型清单表达）
+   - 以上“待确认范围”不得直接当作已确定需求写入主场景表；必须将对应问题补充到 `/specs/background/questions.md`，并等待业务确认后再在后续迭代中纳入场景表
+
 输出与写入要求：
 1. 将结果写入：`/specs/background/scenarios.md`
 2. 如果 `/specs/background` 不存在，请先创建目录

package/{.trae/skills/starter-skill → skills/visual-spec-skill}/prompts/vspec_plan/estimate.md

@@ -28,5 +28,5 @@
    - 表中行顺序保持与对应 functions 文件一致
 
 输出与写入要求：
-1. 写入估算 markdown：`/specs/plan_estimate.md`
-2. 若 `/specs` 不存在，请先创建目录
+1. 写入估算 markdown：`/specs/plan/plan_estimate.md`
+2. 若 `/specs/plan` 不存在，请先创建目录

package/{.trae/skills/starter-skill → skills/visual-spec-skill}/prompts/vspec_plan/schedule.md

@@ -2,7 +2,7 @@
 
 输入信息包含：
 - 功能清单（`/specs/functions/*`）
-- 功能估算（`/specs/plan_estimate.md`）
+- 功能估算（`/specs/plan/plan_estimate.md`）
 - 角色与任务（`/specs/background/roles.md`）
 - 场景与流程（`/specs/background/scenarios.md`、`/specs/flows/*.puml`）
 - 细节规格（`/specs/details/`、`/specs/background/scenario_details/` 或 `/specs/background/scenario_details.md`（旧版））
@@ -23,7 +23,7 @@
    - 风险与依赖（若有）
 
 输出要求（HTML：排期用户故事地图，必须）：
-1. 写入 `/specs/plan_schedule.html`，必须是可直接打开的完整 HTML（包含 basic CSS），无需外部资源依赖
+1. 写入 `/specs/plan/plan_schedule.html`，必须是可直接打开的完整 HTML（包含 basic CSS），无需外部资源依赖
 2. 输出内容必须同时满足：
    - 以“用户故事地图”的呈现方式输出（但不要生成用户故事文本）
    - 明确每个迭代的“迭代目标”与“迭代任务”（任务以卡片呈现）
@@ -36,8 +36,8 @@
 4. 卡片内容要求（每张卡片必须包含）：
    - 标题：功能（必要时带子功能）
    - 说明：取 functions 的“说明”（可截断但要保留关键信息）
-   - 估算：引用 `/specs/plan_estimate.md` 中同一行的估算（含合计人天）
+   - 估算：引用 `/specs/plan/plan_estimate.md` 中同一行的估算（含合计人天）
    - 依赖/阻塞：如有则展示（外部系统、口径、权限、资源等）
 5. 去重与一致性：
    - 同一个功能清单行只能出现在一个迭代里
-   - 估算数字必须与 `/specs/plan_estimate.md` 保持一致
+   - 估算数字必须与 `/specs/plan/plan_estimate.md` 保持一致