docs: 整合 openspec 规范，合并配置和前端相关独立 spec
将 cli-config、config-priority、env-config 合并入 config-management； 将 tdesign-integration、recharts-integration、frontend-config-ui、 frontend-testing、stats-dashboard 合并入新的 frontend/spec.md； 清理其余 spec 中的冗余标记，补充缺失场景。
This commit is contained in:
@@ -1,6 +1,10 @@
|
||||
# Anthropic Protocol Proxy
|
||||
|
||||
## MODIFIED Requirements
|
||||
## Purpose
|
||||
|
||||
定义 Anthropic Messages API 端点的协议代理行为，包括请求处理流程、同协议透传和双向协议转换。
|
||||
|
||||
## Requirements
|
||||
|
||||
### Requirement: 支持 Anthropic Messages API 端点
|
||||
|
||||
@@ -38,50 +42,10 @@
|
||||
- **THEN** SHALL 将 OpenAI ChatCompletionResponse 解码为 CanonicalResponse
|
||||
- **THEN** SHALL 将 CanonicalResponse 编码为 Anthropic MessagesResponse
|
||||
|
||||
#### Scenario: OpenAI 客户端 → Anthropic 供应<EFBFBD><EFBFBD>
|
||||
#### Scenario: OpenAI 客户端 → Anthropic 供应商
|
||||
|
||||
- **WHEN** 客户端使用 OpenAI 协议且供应商使用 Anthropic 协议
|
||||
- **THEN** SHALL 将 OpenAI ChatCompletionRequest 解码为 CanonicalRequest
|
||||
- **THEN** SHALL 将 CanonicalRequest 编码为 Anthropic MessagesRequest
|
||||
- **THEN** SHALL 将 Anthropic MessagesResponse 解码为 CanonicalResponse
|
||||
- **THEN** SHALL 将 CanonicalResponse 编码为 OpenAI ChatCompletionResponse
|
||||
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: 使用 service 层处理请求
|
||||
|
||||
Handler SHALL 通过 service 层处理业务逻辑。
|
||||
|
||||
#### Scenario: 调用 routing service
|
||||
|
||||
- **WHEN** ProxyHandler 收到 Anthropic 协议请求
|
||||
- **THEN** SHALL 调用 RoutingService.Route() 获取路由结果
|
||||
- **THEN** SHALL 从路由结果获取 Provider（含 protocol 字段）
|
||||
|
||||
#### Scenario: 调用 stats service
|
||||
|
||||
- **WHEN** 请求成功完成
|
||||
- **THEN** SHALL 调用 StatsService.Record() 记录统计
|
||||
- **THEN** SHALL 异步记录统计（不阻塞响应）
|
||||
|
||||
### Requirement: 使用结构化错误处理
|
||||
|
||||
ProxyHandler SHALL 使用 ConversionError 和 Anthropic 的 encodeError 处理错误。
|
||||
|
||||
#### Scenario: 协议转换错误
|
||||
|
||||
- **WHEN** ConversionEngine 返回 ConversionError
|
||||
- **THEN** SHALL 使用 Anthropic 的 Adapter.encodeError 编码错误响应
|
||||
- **THEN** SHALL 使用 Anthropic 错误格式（`{type: "error", error: {type, message}}`）
|
||||
|
||||
#### Scenario: 路由错误处理
|
||||
|
||||
- **WHEN** RoutingService 返回错误
|
||||
- **THEN** SHALL 转换为 ConversionError
|
||||
- **THEN** SHALL 使用 Anthropic 错误格式返回
|
||||
|
||||
#### Scenario: 供应商错误处理
|
||||
|
||||
- **WHEN** ProviderClient 返回错误
|
||||
- **THEN** SHALL 包装为 ConversionError
|
||||
- **THEN** SHALL 使用 Anthropic 错误格式返回
|
||||
|
||||
@@ -1,106 +0,0 @@
|
||||
# CLI Config
|
||||
|
||||
## Purpose
|
||||
|
||||
提供命令行参数配置支持，允许用户通过 CLI 参数临时覆盖配置，方便测试、调试和一次性使用场景。
|
||||
|
||||
## Requirements
|
||||
|
||||
### Requirement: 命令行参数配置支持
|
||||
|
||||
系统 SHALL 支持通过命令行参数设置所有配置项。
|
||||
|
||||
#### Scenario: 基本参数解析
|
||||
|
||||
- **WHEN** 应用启动时传入命令行参数
|
||||
- **THEN** SHALL 解析所有 CLI 参数
|
||||
- **THEN** SHALL 将参数值应用到对应配置项
|
||||
|
||||
#### Scenario: 参数命名规范
|
||||
|
||||
- **WHEN** 使用命令行参数
|
||||
- **THEN** SHALL 使用 kebab-case 命名（如 `--server-port`）
|
||||
- **THEN** SHALL 保持完整的层次结构（如 `--database-max-idle-conns`）
|
||||
- **THEN** SHALL 与配置文件路径对应（`database.max_idle_conns` → `--database-max-idle-conns`）
|
||||
|
||||
#### Scenario: 参数类型支持
|
||||
|
||||
- **WHEN** 解析不同类型的参数
|
||||
- **THEN** SHALL 支持 int 类型（如 `--server-port 9000`）
|
||||
- **THEN** SHALL 支持 string 类型（如 `--database-path /data/nex.db`）
|
||||
- **THEN** SHALL 支持 duration 类型（如 `--server-read-timeout 60s`）
|
||||
- **THEN** SHALL 支持 bool 类型（如 `--log-compress`）
|
||||
|
||||
### Requirement: 配置文件路径参数
|
||||
|
||||
系统 SHALL 支持通过 CLI 参数指定配置文件路径。
|
||||
|
||||
#### Scenario: 自定义配置文件路径
|
||||
|
||||
- **WHEN** 启动时指定 `--config /path/to/custom.yaml`
|
||||
- **THEN** SHALL 从指定路径加载配置文件
|
||||
- **THEN** SHALL NOT 使用默认路径 `~/.nex/config.yaml`
|
||||
|
||||
#### Scenario: 未指定配置文件路径
|
||||
|
||||
- **WHEN** 启动时未指定 `--config` 参数
|
||||
- **THEN** SHALL 使用默认路径 `~/.nex/config.yaml`
|
||||
|
||||
### Requirement: 完整配置覆盖
|
||||
|
||||
系统 SHALL 支持通过 CLI 参数覆盖所有配置项。
|
||||
|
||||
#### Scenario: 服务器配置参数
|
||||
|
||||
- **WHEN** 使用服务器相关参数
|
||||
- **THEN** SHALL 支持 `--server-port`
|
||||
- **THEN** SHALL 支持 `--server-read-timeout`
|
||||
- **THEN** SHALL 支持 `--server-write-timeout`
|
||||
|
||||
#### Scenario: 数据库配置参数
|
||||
|
||||
- **WHEN** 使用数据库相关参数
|
||||
- **THEN** SHALL 支持 `--database-path`
|
||||
- **THEN** SHALL 支持 `--database-max-idle-conns`
|
||||
- **THEN** SHALL 支持 `--database-max-open-conns`
|
||||
- **THEN** SHALL 支持 `--database-conn-max-lifetime`
|
||||
|
||||
#### Scenario: 日志配置参数
|
||||
|
||||
- **WHEN** 使用日志相关参数
|
||||
- **THEN** SHALL 支持 `--log-level`
|
||||
- **THEN** SHALL 支持 `--log-path`
|
||||
- **THEN** SHALL 支持 `--log-max-size`
|
||||
- **THEN** SHALL 支持 `--log-max-backups`
|
||||
- **THEN** SHALL 支持 `--log-max-age`
|
||||
- **THEN** SHALL 支持 `--log-compress`
|
||||
|
||||
### Requirement: 参数帮助信息
|
||||
|
||||
系统 SHALL 提供完整的参数帮助信息。
|
||||
|
||||
#### Scenario: 帮助文档生成
|
||||
|
||||
- **WHEN** 使用 `--help` 参数
|
||||
- **THEN** SHALL 显示所有支持的参数
|
||||
- **THEN** SHALL 按功能分组展示参数（服务器、数据库、日志）
|
||||
- **THEN** SHALL 显示每个参数的默认值
|
||||
- **THEN** SHALL 显示每个参数的说明
|
||||
|
||||
### Requirement: 参数错误处理
|
||||
|
||||
系统 SHALL 正确处理参数错误。
|
||||
|
||||
#### Scenario: 无效参数值
|
||||
|
||||
- **WHEN** 传入无效的参数值（如 `--server-port abc`）
|
||||
- **THEN** SHALL 返回明确的错误信息
|
||||
- **THEN** SHALL 指示参数名称和期望类型
|
||||
- **THEN** SHALL NOT 启动应用
|
||||
|
||||
#### Scenario: 未知参数
|
||||
|
||||
- **WHEN** 传入未定义的参数（如 `--unknown-param value`）
|
||||
- **THEN** SHALL 返回错误信息
|
||||
- **THEN** SHALL 指示未知参数名称
|
||||
- **THEN** SHALL NOT 启动应用
|
||||
@@ -1,6 +1,10 @@
|
||||
# Config Management
|
||||
|
||||
## ADDED Requirements
|
||||
## Purpose
|
||||
|
||||
统一配置管理系统，支持 YAML 配置文件、CLI 参数、环境变量和默认值四种配置源，提供优先级管理、来源追踪和配置验证。
|
||||
|
||||
## Requirements
|
||||
|
||||
### Requirement: 使用 YAML 配置文件
|
||||
|
||||
@@ -66,6 +70,21 @@
|
||||
- **THEN** SHALL 指示哪些字段无效
|
||||
- **THEN** SHALL 应用 SHALL NOT 启动
|
||||
|
||||
#### Scenario: 验证规则定义
|
||||
|
||||
- **WHEN** 定义配置结构体
|
||||
- **THEN** SHALL 使用 `validate` tag 定义验证规则
|
||||
- **THEN** SHALL 支持 `required` 规则
|
||||
- **THEN** SHALL 支持 `min`、`max` 规则
|
||||
- **THEN** SHALL 支持 `oneof` 规则
|
||||
|
||||
#### Scenario: 验证执行
|
||||
|
||||
- **WHEN** 加载配置后
|
||||
- **THEN** SHALL 自动执行结构体验证
|
||||
- **THEN** SHALL 返回验证错误
|
||||
- **THEN** SHALL NOT 启动应用（如果验证失败）
|
||||
|
||||
### Requirement: 配置结构定义
|
||||
|
||||
系统 SHALL 定义清晰的配置结构。
|
||||
@@ -117,37 +136,6 @@
|
||||
- **THEN** log.max_age SHALL 为 30 (days)
|
||||
- **THEN** log.compress SHALL 为 true
|
||||
|
||||
### Requirement: 配置重载支持
|
||||
|
||||
系统 SHALL 支持配置重载（未来扩展）。
|
||||
|
||||
#### Scenario: 配置热重载
|
||||
|
||||
- **WHEN** 配置文件修改（未来功能）
|
||||
- **THEN** SHALL 支持重新加载配置
|
||||
- **THEN** SHALL 应用新配置到可动态调整的参数
|
||||
|
||||
注：当前版本不支持，仅为未来扩展预留接口。
|
||||
|
||||
### Requirement: 多层配置源支持
|
||||
|
||||
系统 SHALL 支持多种配置源。
|
||||
|
||||
#### Scenario: 配置源类型
|
||||
|
||||
- **WHEN** 加载配置
|
||||
- **THEN** SHALL 支持命令行参数配置源
|
||||
- **THEN** SHALL 支持环境变量配置源
|
||||
- **THEN** SHALL 支持配置文件配置源
|
||||
- **THEN** SHALL 支持默认值配置源
|
||||
|
||||
#### Scenario: 配置源合并
|
||||
|
||||
- **WHEN** 多个配置源同时存在
|
||||
- **THEN** SHALL 合并所有配置源
|
||||
- **THEN** SHALL 按优先级处理冲突
|
||||
- **THEN** SHALL 生成最终配置
|
||||
|
||||
### Requirement: 配置加载流程
|
||||
|
||||
系统 SHALL 实现标准化的配置加载流程。
|
||||
@@ -173,6 +161,93 @@
|
||||
- **THEN** SHALL 指示失败步骤
|
||||
- **THEN** SHALL NOT 启动应用
|
||||
|
||||
### Requirement: 配置优先级管理
|
||||
|
||||
系统 SHALL 实现明确的配置优先级机制。
|
||||
|
||||
#### Scenario: 优先级顺序
|
||||
|
||||
- **WHEN** 同一配置项在多个配置源中设置
|
||||
- **THEN** SHALL 按以下优先级顺序（从高到低）：
|
||||
1. CLI 参数
|
||||
2. 环境变量
|
||||
3. 配置文件
|
||||
4. 默认值
|
||||
|
||||
#### Scenario: CLI 参数最高优先级
|
||||
|
||||
- **WHEN** 配置文件设置 `server.port: 9826`
|
||||
- **AND** 环境变量设置 `NEX_SERVER_PORT=9000`
|
||||
- **AND** CLI 参数设置 `--server-port 8080`
|
||||
- **THEN** SHALL 使用 CLI 参数值 8080
|
||||
|
||||
#### Scenario: 环境变量次高优先级
|
||||
|
||||
- **WHEN** 配置文件设置 `server.port: 9826`
|
||||
- **AND** 环境变量设置 `NEX_SERVER_PORT=9000`
|
||||
- **AND** 未设置 CLI 参数
|
||||
- **THEN** SHALL 使用环境变量值 9000
|
||||
|
||||
#### Scenario: 配置文件次低优先级
|
||||
|
||||
- **WHEN** 配置文件设置 `server.port: 9826`
|
||||
- **AND** 未设置环境变量
|
||||
- **AND** 未设置 CLI 参数
|
||||
- **THEN** SHALL 使用配置文件值 9826
|
||||
|
||||
#### Scenario: 默认值最低优先级
|
||||
|
||||
- **WHEN** 配置文件中未设置某配置项
|
||||
- **AND** 未设置环境变量
|
||||
- **AND** 未设置 CLI 参数
|
||||
- **THEN** SHALL 使用默认值
|
||||
|
||||
#### Scenario: 部分配置覆盖
|
||||
|
||||
- **WHEN** 配置文件设置完整配置
|
||||
- **AND** CLI 参数仅覆盖部分配置项
|
||||
- **THEN** SHALL 合并所有配置源
|
||||
- **THEN** SHALL 使用高优先级源覆盖指定项
|
||||
- **THEN** SHALL 保留其他配置源中的未覆盖项
|
||||
|
||||
#### Scenario: 配置项独立覆盖
|
||||
|
||||
- **WHEN** 仅通过 CLI 参数设置 `--server-port 9000`
|
||||
- **THEN** SHALL 仅覆盖 server.port 配置项
|
||||
- **THEN** SHALL NOT 影响其他配置项
|
||||
- **THEN** SHALL 其他配置项使用配置文件或默认值
|
||||
|
||||
#### Scenario: 启动后配置锁定
|
||||
|
||||
- **WHEN** 应用启动完成
|
||||
- **THEN** SHALL 锁定配置值
|
||||
- **THEN** SHALL NOT 支持运行时修改配置优先级
|
||||
- **THEN** SHALL NOT 支持运行时添加新配置源
|
||||
|
||||
### Requirement: 配置来源追踪
|
||||
|
||||
系统 SHALL 追踪每个配置值的来源，提供配置覆盖的透明信息。
|
||||
|
||||
#### Scenario: 来源记录
|
||||
|
||||
- **WHEN** 加载配置完成
|
||||
- **THEN** SHALL 记录每个配置项的来源（CLI/ENV/File/Default）
|
||||
- **THEN** SHALL 在配置摘要中显示来源信息
|
||||
|
||||
#### Scenario: 来源统计
|
||||
|
||||
- **WHEN** 打印配置摘要
|
||||
- **THEN** SHALL 统计来自 CLI 参数的配置项数量
|
||||
- **THEN** SHALL 统计来自环境变量的配置项数量
|
||||
- **THEN** SHALL 统计来自配置文件的配置项数量
|
||||
- **THEN** SHALL 统计使用默认值的配置项数量
|
||||
|
||||
#### Scenario: 覆盖提示
|
||||
|
||||
- **WHEN** CLI 参数覆盖配置文件值
|
||||
- **THEN** SHALL 在日志中记录覆盖信息
|
||||
- **THEN** SHALL 显示被覆盖的配置项名称
|
||||
|
||||
### Requirement: 配置摘要输出
|
||||
|
||||
系统 SHALL 在启动时输出配置摘要。
|
||||
@@ -192,21 +267,105 @@
|
||||
- **THEN** SHALL 使用分隔线和分组
|
||||
- **THEN** SHALL 易于阅读和理解
|
||||
|
||||
### Requirement: 配置结构体验证
|
||||
### Requirement: CLI 参数配置支持
|
||||
|
||||
系统 SHALL 使用结构体 tag 进行配置验证。
|
||||
系统 SHALL 支持通过命令行参数设置所有配置项。
|
||||
|
||||
#### Scenario: 验证规则定义
|
||||
#### Scenario: 基本参数解析
|
||||
|
||||
- **WHEN** 定义配置结构体
|
||||
- **THEN** SHALL 使用 `validate` tag 定义验证规则
|
||||
- **THEN** SHALL 支持 `required` 规则
|
||||
- **THEN** SHALL 支持 `min`、`max` 规则
|
||||
- **THEN** SHALL 支持 `oneof` 规则
|
||||
- **WHEN** 应用启动时传入命令行参数
|
||||
- **THEN** SHALL 解析所有 CLI 参数
|
||||
- **THEN** SHALL 将参数值应用到对应配置项
|
||||
|
||||
#### Scenario: 验证执行
|
||||
#### Scenario: 参数命名规范
|
||||
|
||||
- **WHEN** 加载配置后
|
||||
- **THEN** SHALL 自动执行结构体验证
|
||||
- **THEN** SHALL 返回验证错误
|
||||
- **THEN** SHALL NOT 启动应用（如果验证失败）
|
||||
- **WHEN** 使用命令行参数
|
||||
- **THEN** SHALL 使用 kebab-case 命名（如 `--server-port`）
|
||||
- **THEN** SHALL 保持完整的层次结构（如 `--database-max-idle-conns`）
|
||||
- **THEN** SHALL 与配置文件路径对应（`database.max_idle_conns` → `--database-max-idle-conns`）
|
||||
|
||||
#### Scenario: 参数类型支持
|
||||
|
||||
- **WHEN** 解析不同类型的参数
|
||||
- **THEN** SHALL 支持 int 类型（如 `--server-port 9000`）
|
||||
- **THEN** SHALL 支持 string 类型（如 `--database-path /data/nex.db`）
|
||||
- **THEN** SHALL 支持 duration 类型（如 `--server-read-timeout 60s`）
|
||||
- **THEN** SHALL 支持 bool 类型（如 `--log-compress`）
|
||||
|
||||
#### Scenario: 完整配置覆盖
|
||||
|
||||
- **WHEN** 使用服务器相关参数
|
||||
- **THEN** SHALL 支持 `--server-port`、`--server-read-timeout`、`--server-write-timeout`
|
||||
- **WHEN** 使用数据库相关参数
|
||||
- **THEN** SHALL 支持 `--database-path`、`--database-max-idle-conns`、`--database-max-open-conns`、`--database-conn-max-lifetime`
|
||||
- **WHEN** 使用日志相关参数
|
||||
- **THEN** SHALL 支持 `--log-level`、`--log-path`、`--log-max-size`、`--log-max-backups`、`--log-max-age`、`--log-compress`
|
||||
|
||||
#### Scenario: 参数帮助信息
|
||||
|
||||
- **WHEN** 使用 `--help` 参数
|
||||
- **THEN** SHALL 显示所有支持的参数
|
||||
- **THEN** SHALL 按功能分组展示参数（服务器、数据库、日志）
|
||||
- **THEN** SHALL 显示每个参数的默认值和说明
|
||||
|
||||
#### Scenario: 参数错误处理
|
||||
|
||||
- **WHEN** 传入无效的参数值（如 `--server-port abc`）
|
||||
- **THEN** SHALL 返回明确的错误信息，指示参数名称和期望类型
|
||||
- **THEN** SHALL NOT 启动应用
|
||||
- **WHEN** 传入未定义的参数（如 `--unknown-param value`）
|
||||
- **THEN** SHALL 返回错误信息，指示未知参数名称
|
||||
- **THEN** SHALL NOT 启动应用
|
||||
|
||||
### Requirement: 环境变量配置支持
|
||||
|
||||
系统 SHALL 支持通过环境变量设置所有配置项，符合 12-Factor App 原则。
|
||||
|
||||
#### Scenario: 环境变量读取
|
||||
|
||||
- **WHEN** 应用启动时存在环境变量
|
||||
- **THEN** SHALL 自动读取所有 `NEX_` 前缀的环境变量
|
||||
- **THEN** SHALL 将环境变量值应用到对应配置项
|
||||
|
||||
#### Scenario: 环境变量命名规范
|
||||
|
||||
- **WHEN** 使用环境变量配置
|
||||
- **THEN** SHALL 使用 `NEX_` 前缀
|
||||
- **THEN** SHALL 使用大写字母和下划线分隔（如 `NEX_SERVER_PORT`）
|
||||
- **THEN** SHALL 保持完整层次结构（如 `NEX_DATABASE_MAX_IDLE_CONNS`）
|
||||
- **THEN** SHALL 与配置文件路径对应（`database.max_idle_conns` → `NEX_DATABASE_MAX_IDLE_CONNS`）
|
||||
|
||||
#### Scenario: 环境变量类型转换
|
||||
|
||||
- **WHEN** 解析不同类型的环境变量
|
||||
- **THEN** SHALL 支持 int 类型（如 `NEX_SERVER_PORT=9000`）
|
||||
- **THEN** SHALL 支持 string 类型（如 `NEX_DATABASE_PATH=/data/nex.db`）
|
||||
- **THEN** SHALL 支持 duration 类型（如 `NEX_SERVER_READ_TIMEOUT=60s`）
|
||||
- **THEN** SHALL 支持 bool 类型（如 `NEX_LOG_COMPRESS=true`）
|
||||
|
||||
#### Scenario: 完整环境变量覆盖
|
||||
|
||||
- **WHEN** 设置服务器相关环境变量
|
||||
- **THEN** SHALL 支持 `NEX_SERVER_PORT`、`NEX_SERVER_READ_TIMEOUT`、`NEX_SERVER_WRITE_TIMEOUT`
|
||||
- **WHEN** 设置数据库相关环境变量
|
||||
- **THEN** SHALL 支持 `NEX_DATABASE_PATH`、`NEX_DATABASE_MAX_IDLE_CONNS`、`NEX_DATABASE_MAX_OPEN_CONNS`、`NEX_DATABASE_CONN_MAX_LIFETIME`
|
||||
- **WHEN** 设置日志相关环境变量
|
||||
- **THEN** SHALL 支持 `NEX_LOG_LEVEL`、`NEX_LOG_PATH`、`NEX_LOG_MAX_SIZE`、`NEX_LOG_MAX_BACKUPS`、`NEX_LOG_MAX_AGE`、`NEX_LOG_COMPRESS`
|
||||
|
||||
#### Scenario: 12-Factor App 合规
|
||||
|
||||
- **WHEN** 应用部署到不同环境
|
||||
- **THEN** SHALL 通过环境变量区分环境配置
|
||||
- **THEN** SHALL NOT 修改代码或配置文件
|
||||
- **WHEN** 配置包含敏感信息（如密钥、密码）
|
||||
- **THEN** SHALL 通过环境变量传递
|
||||
- **THEN** SHALL NOT 存储在配置文件中
|
||||
|
||||
#### Scenario: 环境变量错误处理
|
||||
|
||||
- **WHEN** 环境变量值格式无效（如 `NEX_SERVER_PORT=abc`）
|
||||
- **THEN** SHALL 返回明确的错误信息，指示环境变量名称和期望类型
|
||||
- **THEN** SHALL NOT 启动应用
|
||||
- **WHEN** 必需配置项既无配置文件也无环境变量
|
||||
- **THEN** SHALL 使用默认值
|
||||
- **THEN** SHALL 正常启动应用
|
||||
|
||||
@@ -1,117 +0,0 @@
|
||||
# Config Priority
|
||||
|
||||
## Purpose
|
||||
|
||||
实现配置优先级管理，确保多层配置源的正确合并和覆盖，提供配置来源追踪和透明性。
|
||||
|
||||
## Requirements
|
||||
|
||||
### Requirement: 配置优先级管理
|
||||
|
||||
系统 SHALL 实现明确的配置优先级机制。
|
||||
|
||||
#### Scenario: 优先级顺序
|
||||
|
||||
- **WHEN** 同一配置项在多个配置源中设置
|
||||
- **THEN** SHALL 按以下优先级顺序（从高到低）：
|
||||
1. CLI 参数
|
||||
2. 环境变量
|
||||
3. 配置文件
|
||||
4. 默认值
|
||||
|
||||
#### Scenario: CLI 参数最高优先级
|
||||
|
||||
- **WHEN** 配置文件设置 `server.port: 9826`
|
||||
- **AND** 环境变量设置 `NEX_SERVER_PORT=9000`
|
||||
- **AND** CLI 参数设置 `--server-port 8080`
|
||||
- **THEN** SHALL 使用 CLI 参数值 8080
|
||||
|
||||
#### Scenario: 环境变量次高优先级
|
||||
|
||||
- **WHEN** 配置文件设置 `server.port: 9826`
|
||||
- **AND** 环境变量设置 `NEX_SERVER_PORT=9000`
|
||||
- **AND** 未设置 CLI 参数
|
||||
- **THEN** SHALL 使用环境变量值 9000
|
||||
|
||||
#### Scenario: 配置文件次低优先级
|
||||
|
||||
- **WHEN** 配置文件设置 `server.port: 9826`
|
||||
- **AND** 未设置环境变量
|
||||
- **AND** 未设置 CLI 参数
|
||||
- **THEN** SHALL 使用配置文件值 9826
|
||||
|
||||
#### Scenario: 默认值最低优先级
|
||||
|
||||
- **WHEN** 配置文件中未设置某配置项
|
||||
- **AND** 未设置环境变量
|
||||
- **AND** 未设置 CLI 参数
|
||||
- **THEN** SHALL 使用默认值
|
||||
|
||||
### Requirement: 配置来源追踪
|
||||
|
||||
系统 SHALL 追踪每个配置值的来源。
|
||||
|
||||
#### Scenario: 来源记录
|
||||
|
||||
- **WHEN** 加载配置完成
|
||||
- **THEN** SHALL 记录每个配置项的来源（CLI/ENV/File/Default）
|
||||
- **THEN** SHALL 在配置摘要中显示来源信息
|
||||
|
||||
#### Scenario: 来源统计
|
||||
|
||||
- **WHEN** 打印配置摘要
|
||||
- **THEN** SHALL 统计来自 CLI 参数的配置项数量
|
||||
- **THEN** SHALL 统计来自环境变量的配置项数量
|
||||
- **THEN** SHALL 统计来自配置文件的配置项数量
|
||||
- **THEN** SHALL 统计使用默认值的配置项数量
|
||||
|
||||
### Requirement: 配置覆盖透明性
|
||||
|
||||
系统 SHALL 提供配置覆盖的透明信息。
|
||||
|
||||
#### Scenario: 覆盖提示
|
||||
|
||||
- **WHEN** CLI 参数覆盖配置文件值
|
||||
- **THEN** SHALL 在日志中记录覆盖信息
|
||||
- **THEN** SHALL 显示被覆盖的配置项名称
|
||||
|
||||
#### Scenario: 配置摘要展示
|
||||
|
||||
- **WHEN** 应用启动完成
|
||||
- **THEN** SHALL 打印配置摘要
|
||||
- **THEN** SHALL 显示关键配置项的最终值
|
||||
- **THEN** SHALL 显示配置文件路径
|
||||
- **THEN** SHALL 显示环境变量数量
|
||||
- **THEN** SHALL 显示 CLI 参数数量
|
||||
|
||||
### Requirement: 部分配置覆盖
|
||||
|
||||
系统 SHALL 支持部分配置覆盖。
|
||||
|
||||
#### Scenario: 混合配置源
|
||||
|
||||
- **WHEN** 配置文件设置完整配置
|
||||
- **AND** CLI 参数仅覆盖部分配置项
|
||||
- **THEN** SHALL 合并所有配置源
|
||||
- **THEN** SHALL 使用 CLI 参数覆盖指定项
|
||||
- **THEN** SHALL 保留配置文件中的其他配置项
|
||||
|
||||
#### Scenario: 配置项独立覆盖
|
||||
|
||||
- **WHEN** 仅通过 CLI 参数设置 `--server-port 9000`
|
||||
- **THEN** SHALL 仅覆盖 server.port 配置项
|
||||
- **THEN** SHALL NOT 影响其他配置项
|
||||
- **THEN** SHALL 其他配置项使用配置文件或默认值
|
||||
|
||||
### Requirement: 配置优先级不可变性
|
||||
|
||||
系统 SHALL 确保配置优先级在运行时不可变。
|
||||
|
||||
#### Scenario: 启动后配置锁定
|
||||
|
||||
- **WHEN** 应用启动完成
|
||||
- **THEN** SHALL 锁定配置值
|
||||
- **THEN** SHALL NOT 支持运行时修改配置优先级
|
||||
- **THEN** SHALL NOT 支持运行时添加新配置源
|
||||
|
||||
注：配置热重载为未来扩展功能，当前版本不支持。
|
||||
@@ -1,6 +1,8 @@
|
||||
# Conversion Engine
|
||||
|
||||
## ADDED Requirements
|
||||
## Purpose
|
||||
|
||||
定义协议无关的 Canonical Model 和 ConversionEngine 转换引擎，作为所有协议间请求/响应转换的统一枢纽。
|
||||
|
||||
### Requirement: 定义 CanonicalRequest 规范模型
|
||||
|
||||
|
||||
@@ -1,6 +1,8 @@
|
||||
# Database Migration
|
||||
|
||||
## ADDED Requirements
|
||||
## Purpose
|
||||
|
||||
使用 goose 管理数据库迁移，支持自动执行、回滚和版本化管理。
|
||||
|
||||
### Requirement: 使用 goose 迁移工具
|
||||
|
||||
|
||||
@@ -1,111 +0,0 @@
|
||||
# Env Config
|
||||
|
||||
## Purpose
|
||||
|
||||
提供环境变量配置支持，符合 12-Factor App 原则，便于容器化部署和多环境配置管理。
|
||||
|
||||
## Requirements
|
||||
|
||||
### Requirement: 环境变量配置支持
|
||||
|
||||
系统 SHALL 支持通过环境变量设置所有配置项。
|
||||
|
||||
#### Scenario: 环境变量读取
|
||||
|
||||
- **WHEN** 应用启动时存在环境变量
|
||||
- **THEN** SHALL 自动读取所有 `NEX_` 前缀的环境变量
|
||||
- **THEN** SHALL 将环境变量值应用到对应配置项
|
||||
|
||||
#### Scenario: 环境变量命名规范
|
||||
|
||||
- **WHEN** 使用环境变量配置
|
||||
- **THEN** SHALL 使用 `NEX_` 前缀
|
||||
- **THEN** SHALL 使用大写字母和下划线分隔（如 `NEX_SERVER_PORT`）
|
||||
- **THEN** SHALL 保持完整层次结构（如 `NEX_DATABASE_MAX_IDLE_CONNS`）
|
||||
- **THEN** SHALL 与配置文件路径对应（`database.max_idle_conns` → `NEX_DATABASE_MAX_IDLE_CONNS`）
|
||||
|
||||
#### Scenario: 环境变量类型转换
|
||||
|
||||
- **WHEN** 解析不同类型的环境变量
|
||||
- **THEN** SHALL 支持 int 类型（如 `NEX_SERVER_PORT=9000`）
|
||||
- **THEN** SHALL 支持 string 类型（如 `NEX_DATABASE_PATH=/data/nex.db`）
|
||||
- **THEN** SHALL 支持 duration 类型（如 `NEX_SERVER_READ_TIMEOUT=60s`）
|
||||
- **THEN** SHALL 支持 bool 类型（如 `NEX_LOG_COMPRESS=true`）
|
||||
|
||||
### Requirement: 完整配置覆盖
|
||||
|
||||
系统 SHALL 支持通过环境变量覆盖所有配置项。
|
||||
|
||||
#### Scenario: 服务器配置环境变量
|
||||
|
||||
- **WHEN** 设置服务器相关环境变量
|
||||
- **THEN** SHALL 支持 `NEX_SERVER_PORT`
|
||||
- **THEN** SHALL 支持 `NEX_SERVER_READ_TIMEOUT`
|
||||
- **THEN** SHALL 支持 `NEX_SERVER_WRITE_TIMEOUT`
|
||||
|
||||
#### Scenario: 数据库配置环境变量
|
||||
|
||||
- **WHEN** 设置数据库相关环境变量
|
||||
- **THEN** SHALL 支持 `NEX_DATABASE_PATH`
|
||||
- **THEN** SHALL 支持 `NEX_DATABASE_MAX_IDLE_CONNS`
|
||||
- **THEN** SHALL 支持 `NEX_DATABASE_MAX_OPEN_CONNS`
|
||||
- **THEN** SHALL 支持 `NEX_DATABASE_CONN_MAX_LIFETIME`
|
||||
|
||||
#### Scenario: 日志配置环境变量
|
||||
|
||||
- **WHEN** 设置日志相关环境变量
|
||||
- **THEN** SHALL 支持 `NEX_LOG_LEVEL`
|
||||
- **THEN** SHALL 支持 `NEX_LOG_PATH`
|
||||
- **THEN** SHALL 支持 `NEX_LOG_MAX_SIZE`
|
||||
- **THEN** SHALL 支持 `NEX_LOG_MAX_BACKUPS`
|
||||
- **THEN** SHALL 支持 `NEX_LOG_MAX_AGE`
|
||||
- **THEN** SHALL 支持 `NEX_LOG_COMPRESS`
|
||||
|
||||
### Requirement: 环境变量优先级
|
||||
|
||||
系统 SHALL 确保环境变量优先级高于配置文件但低于 CLI 参数。
|
||||
|
||||
#### Scenario: 环境变量覆盖配置文件
|
||||
|
||||
- **WHEN** 配置文件设置 `server.port: 9826`
|
||||
- **AND** 环境变量设置 `NEX_SERVER_PORT=9000`
|
||||
- **THEN** SHALL 使用环境变量值 9000
|
||||
|
||||
#### Scenario: CLI 参数覆盖环境变量
|
||||
|
||||
- **WHEN** 环境变量设置 `NEX_SERVER_PORT=9000`
|
||||
- **AND** CLI 参数设置 `--server-port 8080`
|
||||
- **THEN** SHALL 使用 CLI 参数值 8080
|
||||
|
||||
### Requirement: 12-Factor App 合规
|
||||
|
||||
系统 SHALL 符合 12-Factor App 配置原则。
|
||||
|
||||
#### Scenario: 配置与代码分离
|
||||
|
||||
- **WHEN** 应用部署到不同环境
|
||||
- **THEN** SHALL 通过环境变量区分环境配置
|
||||
- **THEN** SHALL NOT 修改代码或配置文件
|
||||
|
||||
#### Scenario: 敏感信息保护
|
||||
|
||||
- **WHEN** 配置包含敏感信息（如密钥、密码）
|
||||
- **THEN** SHALL 通过环境变量传递
|
||||
- **THEN** SHALL NOT 存储在配置文件中
|
||||
|
||||
### Requirement: 环境变量错误处理
|
||||
|
||||
系统 SHALL 正确处理环境变量错误。
|
||||
|
||||
#### Scenario: 无效环境变量值
|
||||
|
||||
- **WHEN** 环境变量值格式无效（如 `NEX_SERVER_PORT=abc`）
|
||||
- **THEN** SHALL 返回明确的错误信息
|
||||
- **THEN** SHALL 指示环境变量名称和期望类型
|
||||
- **THEN** SHALL NOT 启动应用
|
||||
|
||||
#### Scenario: 环境变量缺失
|
||||
|
||||
- **WHEN** 必需配置项既无配置文件也无环境变量
|
||||
- **THEN** SHALL 使用默认值
|
||||
- **THEN** SHALL 正常启动应用
|
||||
@@ -1,6 +1,8 @@
|
||||
# Error Handling
|
||||
|
||||
## ADDED Requirements
|
||||
## Purpose
|
||||
|
||||
定义结构化错误类型和统一错误响应机制，支持错误包装、类型安全判断和协议级错误编码，确保全链路错误处理的一致性和可追踪性。
|
||||
|
||||
### Requirement: 定义结构化错误类型
|
||||
|
||||
@@ -169,8 +171,6 @@
|
||||
- **THEN** SHALL 使用 errors.Is 进行链式判断
|
||||
- **THEN** SHALL 使用 errors.As 提取特定类型错误
|
||||
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: 定义 ConversionError 错误类型
|
||||
|
||||
系统 SHALL 定义 ConversionError 结构体和 ErrorCode 枚举。
|
||||
|
||||
@@ -1,213 +0,0 @@
|
||||
# 前端测试体系
|
||||
|
||||
## Purpose
|
||||
|
||||
建立前端测试体系，覆盖单元测试、组件测试和 E2E 测试，确保前端代码质量和功能正确性。
|
||||
|
||||
## Requirements
|
||||
|
||||
### Requirement: 建立前端单元测试体系
|
||||
|
||||
前端 SHALL 使用 Vitest 建立单元测试体系，覆盖 API 层和自定义 Hooks。
|
||||
|
||||
#### Scenario: API 客户端单测
|
||||
|
||||
- **WHEN** 运行 api/client.ts 的单元测试
|
||||
- **THEN** SHALL 覆盖 request<T>() 的正常响应解析
|
||||
- **THEN** SHALL 覆盖 HTTP 错误状态码（4xx、5xx）的 ApiError 抛出
|
||||
- **THEN** SHALL 覆盖网络错误的错误处理
|
||||
- **THEN** SHALL 覆盖 snake_case → camelCase 响应字段转换
|
||||
- **THEN** SHALL 覆盖 camelCase → snake_case 请求字段转换
|
||||
|
||||
#### Scenario: API 模块单测
|
||||
|
||||
- **WHEN** 运行 api/providers.ts、api/models.ts、api/stats.ts 的单元测试
|
||||
- **THEN** SHALL 覆盖所有 CRUD 函数的正确调用
|
||||
- **THEN** SHALL 覆盖参数传递和返回值类型
|
||||
|
||||
#### Scenario: 自定义 Hooks 单测
|
||||
|
||||
- **WHEN** 运行 hooks/ 目录下的单元测试
|
||||
- **THEN** SHALL 使用 @tanstack/react-query 的 renderHook 测试工具
|
||||
- **THEN** SHALL 覆盖 useQuery 数据获取（成功和失败）
|
||||
- **THEN** SHALL 覆盖 useMutation 写操作后的缓存失效
|
||||
- **THEN** SHALL 使用独立的测试 QueryClient（关闭 retry 和缓存）
|
||||
|
||||
### Requirement: 建立前端组件测试体系
|
||||
|
||||
前端 SHALL 使用 React Testing Library 建立组件测试体系。
|
||||
|
||||
#### Scenario: ProviderTable 组件测试
|
||||
|
||||
- **WHEN** 运行 ProviderTable 组件测试
|
||||
- **THEN** SHALL 验证供应商列表正确渲染
|
||||
- **THEN** SHALL 验证点击"添加"按钮弹出 Modal
|
||||
- **THEN** SHALL 验证点击"编辑"按钮弹出预填充的 Modal
|
||||
- **THEN** SHALL 验证删除操作触发 Popconfirm 确认
|
||||
|
||||
#### Scenario: ProviderForm 组件测试
|
||||
|
||||
- **WHEN** 运行 ProviderForm 组件测试
|
||||
- **THEN** SHALL 验证表单校验规则（必填字段、URL 格式）
|
||||
- **THEN** SHALL 验证提交成功后调用 onSave 回调
|
||||
- **THEN** SHALL 验证编辑模式下字段预填充
|
||||
|
||||
#### Scenario: StatsTable 组件测试
|
||||
|
||||
- **WHEN** 运行 StatsTable 组件测试
|
||||
- **THEN** SHALL 验证筛选条件交互（供应商选择、日期范围）
|
||||
- **THEN** SHALL 验证统计数据正确展示
|
||||
|
||||
### Requirement: 建立 E2E 测试体系
|
||||
|
||||
前端 SHALL 使用 Playwright 建立端到端测试体系。
|
||||
|
||||
#### Scenario: 供应商管理 E2E 测试
|
||||
|
||||
- **WHEN** 运行供应商管理的 E2E 测试
|
||||
- **THEN** SHALL 测试完整的供应商创建流程
|
||||
- **THEN** SHALL 测试供应商编辑流程
|
||||
- **THEN** SHALL 测试供应商删除流程（含确认弹窗）
|
||||
- **THEN** SHALL 测试供应商展开后的模型管理
|
||||
|
||||
#### Scenario: 统计查询 E2E 测试
|
||||
|
||||
- **WHEN** 运行统计查询的 E2E 测试
|
||||
- **THEN** SHALL 测试页面加载和默认数据展示
|
||||
- **THEN** SHALL 测试按供应商筛选
|
||||
- **THEN** SHALL 测试按日期范围筛选
|
||||
|
||||
### Requirement: 使用 MSW 进行 API Mock
|
||||
|
||||
前端测试 SHALL 使用 MSW (Mock Service Worker) 模拟后端 API 响应。
|
||||
|
||||
#### Scenario: 测试环境 MSW 配置
|
||||
|
||||
- **WHEN** 初始化测试环境
|
||||
- **THEN** SHALL 配置 MSW server 处理所有 /api/* 请求
|
||||
- **THEN** SHALL 在 setup.ts 中全局启动和清理 MSW server
|
||||
|
||||
#### Scenario: Mock 响应定义
|
||||
|
||||
- **WHEN** 编写需要 API 交互的测试
|
||||
- **THEN** SHALL 使用 MSW handler 定义期望的 API 响应
|
||||
- **THEN** SHALL 支持成功和失败两种响应场景
|
||||
- **THEN** SHALL 在每个测试用例后重置 handler
|
||||
|
||||
### Requirement: 测试文件组织
|
||||
|
||||
前端测试文件 SHALL 按层级组织在 src/__tests__/ 目录下。
|
||||
|
||||
#### Scenario: 目录结构
|
||||
|
||||
- **WHEN** 组织测试文件
|
||||
- **THEN** src/__tests__/setup.ts SHALL 包含全局测试配置
|
||||
- **THEN** src/__tests__/api/ SHALL 包含 API 层单测
|
||||
- **THEN** src/__tests__/hooks/ SHALL 包含 Hooks 单测
|
||||
- **THEN** src/__tests__/components/ SHALL 包含组件测试
|
||||
- **THEN** e2e/ 目录（项目根目录下）SHALL 包含 Playwright E2E 测试
|
||||
|
||||
### Requirement: Vitest 配置
|
||||
|
||||
前端 SHALL 配置 Vitest 作为测试运行器。
|
||||
|
||||
#### Scenario: 测试环境配置
|
||||
|
||||
- **WHEN** 运行 vitest
|
||||
- **THEN** SHALL 使用 jsdom 作为测试环境
|
||||
- **THEN** SHALL 配置 setupFiles 指向 src/__tests__/setup.ts
|
||||
- **THEN** SHALL 配置路径别名 @/ 与 tsconfig 一致
|
||||
- **THEN** SHALL 配置 @testing-library/jest-dom 匹配器
|
||||
|
||||
#### Scenario: 覆盖率配置
|
||||
|
||||
- **WHEN** 运行覆盖率报告
|
||||
- **THEN** SHALL 使用 @vitest/coverage-v8 提供者
|
||||
- **THEN** SHALL 覆盖 src/ 下的所有源文件
|
||||
|
||||
### Requirement: 建立前端单元测试覆盖
|
||||
|
||||
前端代码 SHALL 建立单元测试覆盖，纳入整体测试覆盖率统计。
|
||||
|
||||
#### Scenario: API 层测试覆盖
|
||||
|
||||
- **WHEN** 运行前端 API 层的单元测试
|
||||
- **THEN** SHALL 覆盖 api/client.ts 的请求封装和字段转换逻辑
|
||||
- **THEN** SHALL 覆盖 api/providers.ts、api/models.ts、api/stats.ts 的所有函数
|
||||
- **THEN** SHALL 使用 MSW mock API 响应
|
||||
|
||||
#### Scenario: Hooks 测试覆盖
|
||||
|
||||
- **WHEN** 运行前端 Hooks 的单元测试
|
||||
- **THEN** SHALL 覆盖 useProviders、useModels、useStats 的查询和变更逻辑
|
||||
- **THEN** SHALL 验证缓存失效和自动刷新行为
|
||||
|
||||
### Requirement: 统计仪表盘组件测试
|
||||
|
||||
前端 SHALL 为统计仪表盘的新增组件建立测试覆盖。
|
||||
|
||||
#### Scenario: StatCards 组件测试
|
||||
|
||||
- **WHEN** 运行 StatCards 组件测试
|
||||
- **THEN** SHALL 验证统计数据正确渲染（总请求量、活跃模型数、活跃供应商数、今日请求量）
|
||||
- **THEN** SHALL 验证空数据时的渲染行为
|
||||
|
||||
#### Scenario: UsageChart 组件测试
|
||||
|
||||
- **WHEN** 运行 UsageChart 组件测试
|
||||
- **THEN** SHALL 验证图表组件正确渲染
|
||||
- **THEN** SHALL 验证空数据时的渲染行为
|
||||
|
||||
### Requirement: 建立前端组件测试覆盖
|
||||
|
||||
前端 SHALL 使用 React Testing Library 建立组件测试覆盖。
|
||||
|
||||
#### Scenario: 页面组件测试覆盖
|
||||
|
||||
- **WHEN** 运行前端组件测试
|
||||
- **THEN** SHALL 覆盖 ProviderTable 的列表渲染和交互操作
|
||||
- **THEN** SHALL 覆盖 ProviderForm 的表单校验和提交
|
||||
- **THEN** SHALL 覆盖 ModelForm 的表单校验和提交
|
||||
- **THEN** SHALL 覆盖 StatsTable 的筛选和数据展示
|
||||
- **THEN** SHALL 覆盖 StatCards 的统计摘要渲染
|
||||
- **THEN** SHALL 覆盖 UsageChart 的趋势图表渲染
|
||||
|
||||
### Requirement: 建立前端 E2E 测试覆盖
|
||||
|
||||
前端 SHALL 使用 Playwright 建立 E2E 测试覆盖。
|
||||
|
||||
#### Scenario: 供应商管理 E2E 覆盖
|
||||
|
||||
- **WHEN** 运行 E2E 测试
|
||||
- **THEN** SHALL 覆盖供应商创建、编辑、删除的完整用户流程
|
||||
- **THEN** SHALL 覆盖模型创建、编辑、删除的完整用户流程
|
||||
|
||||
#### Scenario: 统计查询 E2E 覆盖
|
||||
|
||||
- **WHEN** 运行 E2E 测试
|
||||
- **THEN** SHALL 覆盖统计页面的加载和筛选查询流程
|
||||
- **THEN** SHALL 覆盖页面间的导航切换
|
||||
- **THEN** SHALL 覆盖统计摘要卡片的展示
|
||||
|
||||
#### Scenario: 侧边栏导航 E2E 覆盖
|
||||
|
||||
- **WHEN** 运行 E2E 测试
|
||||
- **THEN** SHALL 覆盖侧边栏菜单导航的页面切换
|
||||
- **THEN** SHALL 覆盖侧边栏折叠和展开操作
|
||||
|
||||
### Requirement: 前端测试集成到构建流程
|
||||
|
||||
前端测试 SHALL 集成到项目的构建和验证流程中。
|
||||
|
||||
#### Scenario: 运行前端测试命令
|
||||
|
||||
- **WHEN** 在 frontend/ 目录执行测试命令
|
||||
- **THEN** SHALL 运行所有 Vitest 单元测试和组件测试
|
||||
- **THEN** SHALL 显示测试结果
|
||||
- **THEN** SHALL 在测试失败时返回非零退出码
|
||||
|
||||
#### Scenario: 运行前端 E2E 测试命令
|
||||
|
||||
- **WHEN** 在 frontend/ 目录执行 E2E 测试命令
|
||||
- **THEN** SHALL 启动 Playwright 运行 E2E 测试
|
||||
- **THEN** SHALL 在测试失败时返回非零退出码
|
||||
@@ -138,6 +138,20 @@ TBD - 提供供应商、模型配置和用量统计的前端管理界面
|
||||
- **THEN** 前端 SHALL 自动查询并过滤统计
|
||||
- **THEN** 统计摘要卡片和趋势图表 SHALL 同步更新
|
||||
|
||||
#### Scenario: 仪表盘区域排列
|
||||
|
||||
- **WHEN** 渲染统计页面
|
||||
- **THEN** 页面 SHALL 按以下顺序从上到下排列：统计摘要卡片、趋势图表、筛选栏和数据表格
|
||||
- **THEN** 各区域之间 SHALL 有合理的垂直间距
|
||||
- **THEN** 筛选栏和数据表格 SHALL 保持在同一个卡片中
|
||||
|
||||
#### Scenario: 数据联动
|
||||
|
||||
- **WHEN** 用户通过筛选栏修改筛选条件
|
||||
- **THEN** 统计摘要卡片和趋势图表 SHALL 随筛选条件变化更新
|
||||
- **THEN** 数据表格 SHALL 同步更新
|
||||
- **THEN** 所有区域 SHALL 共享同一份筛选后的数据
|
||||
|
||||
### Requirement: 优雅处理 API 错误
|
||||
|
||||
前端 SHALL 处理 API 错误并显示用户友好的消息。
|
||||
@@ -224,13 +238,6 @@ TBD - 提供供应商、模型配置和用量统计的前端管理界面
|
||||
- **WHEN** 用户点击导航中的"设置"
|
||||
- **THEN** 前端 SHALL 导航到 `/settings` 并高亮当前菜单项
|
||||
|
||||
#### Scenario: 导航菜单交互
|
||||
|
||||
- **WHEN** 用户点击导航中的"供应商管理"
|
||||
- **THEN** 前端 SHALL 导航到 `/providers` 并高亮当前菜单项
|
||||
- **WHEN** 用户点击导航中的"用量统计"
|
||||
- **THEN** 前端 SHALL 导航到 `/stats` 并高亮当前菜单项
|
||||
|
||||
### Requirement: 提供导航
|
||||
|
||||
前端 SHALL 使用 React Router v7 提供导航。
|
||||
@@ -1,6 +1,8 @@
|
||||
# Layered Architecture
|
||||
|
||||
## ADDED Requirements
|
||||
## Purpose
|
||||
|
||||
实现 handler → service → repository 三层架构，并在 handler 和 provider 之间新增 conversion 层，通过依赖注入和清晰的接口边界提高代码可维护性和可测试性。
|
||||
|
||||
### Requirement: 实现三层架构
|
||||
|
||||
|
||||
@@ -1,6 +1,8 @@
|
||||
# Middleware System
|
||||
|
||||
## ADDED Requirements
|
||||
## Purpose
|
||||
|
||||
实现 HTTP 中间件体系，包括请求 ID、日志记录、错误恢复和 CORS 处理，确保请求的可追踪性、稳定性和跨域支持。
|
||||
|
||||
### Requirement: 实现请求 ID 中间件
|
||||
|
||||
|
||||
@@ -1,6 +1,8 @@
|
||||
# Model Management
|
||||
|
||||
## MODIFIED Requirements
|
||||
## Purpose
|
||||
|
||||
管理模型的增删改查，通过 handler → service → repository 分层实现业务逻辑和数据访问，支持供应商关联验证。
|
||||
|
||||
### Requirement: 创建模型配置
|
||||
|
||||
@@ -74,8 +76,6 @@
|
||||
|
||||
**变更说明：** 通过 ModelService 和 ModelRepository 实现。API 接口保持不变。
|
||||
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: 使用 service 层处理业务逻辑
|
||||
|
||||
Handler SHALL 通过 ModelService 处理业务逻辑。
|
||||
|
||||
@@ -1,6 +1,10 @@
|
||||
# OpenAI Protocol Proxy
|
||||
|
||||
## MODIFIED Requirements
|
||||
## Purpose
|
||||
|
||||
定义 OpenAI Chat Completions API 端点的协议代理行为，包括请求处理流程、模型路由、同协议透传和跨协议转换。
|
||||
|
||||
## Requirements
|
||||
|
||||
### Requirement: 支持 OpenAI Chat Completions API 端点
|
||||
|
||||
@@ -47,9 +51,9 @@
|
||||
- **WHEN** 请求包含已禁用模型的 `model` 字段
|
||||
- **THEN** 网关 SHALL 使用 OpenAI 格式返回错误响应
|
||||
|
||||
### Requirement: 对 OpenAI 兼容供应商透明代理
|
||||
### Requirement: 跨协议请求转换
|
||||
|
||||
网关 SHALL 对 OpenAI 兼容供应商的请求和响应通过 ConversionEngine 进行转换处理。
|
||||
网关 SHALL 对非 OpenAI 兼容供应商的请求和响应通过 ConversionEngine 进行转换处理。
|
||||
|
||||
#### Scenario: 跨协议请求转发
|
||||
|
||||
@@ -61,59 +65,3 @@
|
||||
|
||||
- **WHEN** 网关收到 `/openai/v1/models` 等 GET 请求
|
||||
- **THEN** 网关 SHALL 通过 ConversionEngine 转换扩展层接口的响应格式
|
||||
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: 使用 service 层处理请求
|
||||
|
||||
Handler SHALL 通过 service 层处理业务逻辑。
|
||||
|
||||
#### Scenario: 调用 routing service
|
||||
|
||||
- **WHEN** handler 收到请求
|
||||
- **THEN** SHALL 调用 RoutingService.Route() 获取路由结果
|
||||
- **THEN** SHALL 使用路由结果中的供应商信息
|
||||
|
||||
#### Scenario: 调用 stats service
|
||||
|
||||
- **WHEN** 请求成功完成
|
||||
- **THEN** SHALL 调用 StatsService.Record() 记录统计
|
||||
- **THEN** SHALL 异步记录统计（不阻塞响应）
|
||||
|
||||
### Requirement: 使用 service 层处理请求
|
||||
|
||||
Handler SHALL 通过 service 层处理业务逻辑。
|
||||
|
||||
#### Scenario: 调用 routing service
|
||||
|
||||
- **WHEN** ProxyHandler 收到请求
|
||||
- **THEN** SHALL 调用 RoutingService.Route() 获取路由结果
|
||||
- **THEN** SHALL 从路由结果获取 Provider（含 protocol 字段）
|
||||
|
||||
#### Scenario: 调用 stats service
|
||||
|
||||
- **WHEN** 请求成功完成
|
||||
- **THEN** SHALL 调用 StatsService.Record() 记录统计
|
||||
- **THEN** SHALL 异步记录统计（不阻塞响应）
|
||||
|
||||
### Requirement: 使用结构化错误处理
|
||||
|
||||
ProxyHandler SHALL 使用 ConversionError 和协议对应的 encodeError 处理错误。
|
||||
|
||||
#### Scenario: 转换错误
|
||||
|
||||
- **WHEN** ConversionEngine 返回 ConversionError
|
||||
- **THEN** SHALL 使用 clientProtocol 的 Adapter.encodeError 编码错误响应
|
||||
- **THEN** SHALL 使用 OpenAI 错误格式（`{error: {message, type, code}}`）
|
||||
|
||||
#### Scenario: 路由错误处理
|
||||
|
||||
- **WHEN** RoutingService 返回错误
|
||||
- **THEN** SHALL 转换为 ConversionError
|
||||
- **THEN** SHALL 使用 OpenAI 错误格式返回
|
||||
|
||||
#### Scenario: 供应商错误处理
|
||||
|
||||
- **WHEN** ProviderClient 返回错误
|
||||
- **THEN** SHALL 包装为 ConversionError
|
||||
- **THEN** SHALL 使用 OpenAI 错误格式返回
|
||||
|
||||
@@ -1,6 +1,8 @@
|
||||
# Protocol Adapter - Anthropic
|
||||
|
||||
## ADDED Requirements
|
||||
## Purpose
|
||||
|
||||
实现 Anthropic 协议的完整 ProtocolAdapter，支持请求/响应编解码、流式转换和错误处理，遵循 Anthropic Messages API 规范。
|
||||
|
||||
### Requirement: 实现 Anthropic ProtocolAdapter
|
||||
|
||||
|
||||
@@ -1,6 +1,8 @@
|
||||
# Protocol Adapter - OpenAI
|
||||
|
||||
## ADDED Requirements
|
||||
## Purpose
|
||||
|
||||
实现 OpenAI 协议的完整 ProtocolAdapter，支持请求/响应编解码、流式转换和错误处理，遵循 OpenAI Chat Completions API 规范。
|
||||
|
||||
### Requirement: 实现 OpenAI ProtocolAdapter
|
||||
|
||||
|
||||
@@ -1,6 +1,10 @@
|
||||
# Provider Management
|
||||
|
||||
## MODIFIED Requirements
|
||||
## Purpose
|
||||
|
||||
管理 AI 供应商的完整生命周期，包括创建、查询、更新、删除供应商配置，通过分层架构（Handler -> Service -> Repository）处理业务逻辑和数据访问。
|
||||
|
||||
## Requirements
|
||||
|
||||
### Requirement: 创建供应商配置
|
||||
|
||||
@@ -84,8 +88,6 @@
|
||||
|
||||
**变更说明：** 通过 ProviderService 和 ProviderRepository 实现。API 接口保持不变。
|
||||
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: 使用 service 层处理业务逻辑
|
||||
|
||||
Handler SHALL 通过 ProviderService 处理业务逻辑。
|
||||
|
||||
@@ -1,114 +0,0 @@
|
||||
# Recharts Integration
|
||||
|
||||
## Purpose
|
||||
|
||||
TBD - 集成Recharts图表库，实现数据可视化功能，替代@ant-design/charts。
|
||||
|
||||
## Requirements
|
||||
|
||||
### Requirement: Recharts依赖集成
|
||||
系统SHALL正确集成Recharts图表库，作为数据可视化的基础依赖。
|
||||
|
||||
#### Scenario: 安装Recharts依赖
|
||||
- **WHEN** 依赖安装完成
|
||||
- **THEN** package.json中SHALL存在recharts依赖
|
||||
- **AND** recharts版本SHALL为2.x最新稳定版
|
||||
- **AND** Recharts组件SHALL可正常导入使用
|
||||
|
||||
### Requirement: UsageChart图表重写
|
||||
系统SHALL使用Recharts重新实现UsageChart组件，保持原有功能。
|
||||
|
||||
#### Scenario: 折线图渲染
|
||||
- **WHEN** UsageChart组件接收统计数据
|
||||
- **THEN** SHALL使用Recharts的LineChart组件渲染
|
||||
- **AND** X轴SHALL显示日期数据
|
||||
- **AND** Y轴SHALL显示请求数据
|
||||
- **AND** 图表SHALL支持鼠标悬停显示详情（Tooltip）
|
||||
- **AND** 图表SHALL包含网格线（CartesianGrid）
|
||||
|
||||
#### Scenario: 响应式图表容器
|
||||
- **WHEN** 图表渲染
|
||||
- **THEN** SHALL使用ResponsiveContainer包裹
|
||||
- **AND** 图表宽度SHALL自适应容器宽度
|
||||
- **AND** 图表高度SHALL为固定300px
|
||||
|
||||
#### Scenario: 空数据状态处理
|
||||
- **WHEN** 统计数据为空数组
|
||||
- **THEN** SHALL显示"暂无数据"提示
|
||||
- **AND** 不SHALL渲染图表组件
|
||||
|
||||
#### Scenario: 数据格式转换
|
||||
- **WHEN** 接收UsageStats数组数据
|
||||
- **THEN** SHALL按日期聚合计数
|
||||
- **AND** 数据SHALL按日期升序排序
|
||||
- **AND** 数据格式SHALL适配Recharts要求
|
||||
|
||||
### Requirement: 图表样式配置
|
||||
系统SHALL配置Recharts图表样式，确保视觉一致性。
|
||||
|
||||
#### Scenario: 图表颜色配置
|
||||
- **WHEN** 图表渲染
|
||||
- **THEN** 折线颜色SHALL为TDesign主色（#0052D9）
|
||||
- **AND** 线条宽度SHALL为2px
|
||||
- **AND** 数据点样式SHALL正常显示
|
||||
|
||||
#### Scenario: 网格线配置
|
||||
- **WHEN** 图表渲染
|
||||
- **THEN** 网格线SHALL使用虚线样式（strokeDasharray="3 3"）
|
||||
- **AND** 网格线SHALL不遮挡数据线
|
||||
|
||||
### Requirement: 移除Ant Design Charts
|
||||
系统SHALL完全移除@ant-design/charts的使用。
|
||||
|
||||
#### Scenario: 移除Line组件
|
||||
- **WHEN** 迁移完成
|
||||
- **THEN** UsageChart中SHALL不存在@ant-design/charts的Line组件
|
||||
- **AND** UsageChart中SHALL不存在任何@ant-design/charts导入
|
||||
|
||||
#### Scenario: 移除配置对象模式
|
||||
- **WHEN** 图表实现
|
||||
- **THEN** SHALL使用Recharts声明式组件模式
|
||||
- **AND** 不SHALL使用Ant Design Charts的配置对象模式（xField、yField等）
|
||||
|
||||
### Requirement: 图表交互功能
|
||||
系统SHALL保持图表的基本交互功能。
|
||||
|
||||
#### Scenario: 鼠标悬停提示
|
||||
- **WHEN** 用户鼠标悬停在数据点上
|
||||
- **THEN** SHALL显示Tooltip提示框
|
||||
- **AND** 提示框SHALL显示日期和请求数
|
||||
- **AND** 提示框SHALL不遮挡图表内容
|
||||
|
||||
#### Scenario: 平滑曲线效果
|
||||
- **WHEN** 折线渲染
|
||||
- **THEN** SHALL使用monotone类型平滑曲线
|
||||
- **AND** 曲线SHALL自然流畅
|
||||
- **AND** 数据点SHALL准确对应
|
||||
|
||||
### Requirement: 图表性能
|
||||
系统SHALL确保图表渲染性能满足要求。
|
||||
|
||||
#### Scenario: 大数据量渲染
|
||||
- **WHEN** 统计数据包含大量数据点（>100）
|
||||
- **THEN** 图表SHALL在1秒内完成渲染
|
||||
- **AND** 交互响应SHALL流畅无卡顿
|
||||
|
||||
#### Scenario: 组件重渲染优化
|
||||
- **WHEN** 父组件重新渲染
|
||||
- **THEN** 图表组件SHALL避免不必要的重渲染
|
||||
- **AND** 数据未变化时SHALL保持稳定
|
||||
|
||||
### Requirement: 图表测试覆盖
|
||||
系统SHALL为Recharts图表组件提供完整的测试覆盖。
|
||||
|
||||
#### Scenario: 组件渲染测试
|
||||
- **WHEN** 运行单元测试
|
||||
- **THEN** UsageChart测试SHALL验证正常渲染
|
||||
- **AND** UsageChart测试SHALL验证空数据状态
|
||||
- **AND** UsageChart测试SHALL验证数据格式转换
|
||||
|
||||
#### Scenario: 数据处理测试
|
||||
- **WHEN** 运行单元测试
|
||||
- **THEN** 测试SHALL覆盖日期聚合逻辑
|
||||
- **AND** 测试SHALL覆盖数据排序逻辑
|
||||
- **AND** 测试SHALL验证边界情况
|
||||
@@ -1,6 +1,10 @@
|
||||
# Request Validation
|
||||
|
||||
## ADDED Requirements
|
||||
## Purpose
|
||||
|
||||
定义请求验证规范，覆盖 AI 协议请求（OpenAI、Anthropic）和管理 API 请求的验证规则，确保输入数据的合法性和安全性。
|
||||
|
||||
## Requirements
|
||||
|
||||
### Requirement: 使用 validator 库
|
||||
|
||||
|
||||
@@ -1,77 +0,0 @@
|
||||
# 统计仪表盘
|
||||
|
||||
## Purpose
|
||||
|
||||
TBD - 提供统计仪表盘页面，展示统计摘要卡片、请求趋势图表和详细数据表格
|
||||
|
||||
## Requirements
|
||||
|
||||
### Requirement: 提供统计摘要卡片
|
||||
|
||||
前端 SHALL 在统计页面顶部展示统计摘要卡片行，展示关键指标的聚合数据。
|
||||
|
||||
#### Scenario: 显示统计摘要
|
||||
|
||||
- **WHEN** 加载统计页面
|
||||
- **THEN** 前端 SHALL 在页面顶部使用 Ant Design `Row` + `Col` 栅格布局展示统计卡片
|
||||
- **THEN** 每个卡片 SHALL 使用 Ant Design `Card` + `Statistic` 组件
|
||||
- **THEN** 卡片 SHALL 展示以下指标：总请求量、活跃模型数、活跃供应商数、今日请求量
|
||||
- **THEN** 指标数据 SHALL 从 `useStats` 返回的 `UsageStats[]` 数据中前端聚合计算
|
||||
|
||||
#### Scenario: 统计数据聚合计算
|
||||
|
||||
- **WHEN** 前端接收到 stats 数据
|
||||
- **THEN** 总请求量 SHALL 为所有记录的 requestCount 之和
|
||||
- **THEN** 活跃模型数 SHALL 为去重后不同 modelName 的数量
|
||||
- **THEN** 活跃供应商数 SHALL 为去重后不同 providerId 的数量
|
||||
- **THEN** 今日请求量 SHALL 为 date 等于当日日期的记录的 requestCount 之和
|
||||
|
||||
#### Scenario: 统计卡片响应式布局
|
||||
|
||||
- **WHEN** 在不同屏幕宽度下查看统计卡片
|
||||
- **THEN** 卡片 SHALL 使用 Ant Design `Col` 的响应式 span 适配不同宽度
|
||||
- **THEN** 卡片之间 SHALL 有合理的间距（Row 的 gutter）
|
||||
|
||||
### Requirement: 提供请求趋势图表
|
||||
|
||||
前端 SHALL 在统计页面展示请求量随时间变化的趋势图表。
|
||||
|
||||
#### Scenario: 显示趋势图表
|
||||
|
||||
- **WHEN** 加载统计页面
|
||||
- **THEN** 前端 SHALL 在统计摘要卡片下方展示趋势图表
|
||||
- **THEN** 图表 SHALL 使用 `@ant-design/charts` 的 `Line` 组件
|
||||
- **THEN** 图表 SHALL 包裹在 Ant Design `Card` 组件中
|
||||
- **THEN** 图表 SHALL 展示请求量随日期的变化趋势
|
||||
|
||||
#### Scenario: 图表数据格式
|
||||
|
||||
- **WHEN** 准备图表数据
|
||||
- **THEN** X 轴 SHALL 为日期（date 字段）
|
||||
- **THEN** Y 轴 SHALL 为请求计数（requestCount）
|
||||
- **THEN** 数据 SHALL 按日期聚合，同一天的请求量求和
|
||||
- **THEN** 数据 SHALL 按日期升序排列
|
||||
|
||||
#### Scenario: 图表主题适配
|
||||
|
||||
- **WHEN** 用户切换亮色/暗色主题
|
||||
- **THEN** 图表 SHALL 自动适配当前主题
|
||||
- **THEN** 图表文字和背景 SHALL 与当前主题协调
|
||||
|
||||
### Requirement: 仪表盘页面布局
|
||||
|
||||
前端 SHALL 将统计页面组织为仪表盘布局，按从上到下的顺序排列各区域。
|
||||
|
||||
#### Scenario: 仪表盘区域排列
|
||||
|
||||
- **WHEN** 渲染统计页面
|
||||
- **THEN** 页面 SHALL 按以下顺序从上到下排列：统计摘要卡片、趋势图表、筛选栏和数据表格
|
||||
- **THEN** 各区域之间 SHALL 有合理的垂直间距
|
||||
- **THEN** 筛选栏和数据表格 SHALL 保持在同一个 `Card` 中
|
||||
|
||||
#### Scenario: 数据联动
|
||||
|
||||
- **WHEN** 用户通过筛选栏修改筛选条件
|
||||
- **THEN** 统计摘要卡片和趋势图表 SHALL 随筛选条件变化更新
|
||||
- **THEN** 数据表格 SHALL 同步更新
|
||||
- **THEN** 所有区域 SHALL 共享同一份筛选后的数据
|
||||
@@ -1,6 +1,10 @@
|
||||
# Structured Logging
|
||||
|
||||
## ADDED Requirements
|
||||
## Purpose
|
||||
|
||||
定义结构化日志规范，使用 zap 日志库提供 JSON 格式日志输出、日志文件滚动、请求 ID 追踪和多级别日志控制。
|
||||
|
||||
## Requirements
|
||||
|
||||
### Requirement: 使用 zap 结构化日志
|
||||
|
||||
|
||||
@@ -1,122 +0,0 @@
|
||||
# TDesign Integration
|
||||
|
||||
## Purpose
|
||||
|
||||
TBD - 集成TDesign React组件库，提供统一的UI设计系统和组件支持，替代Ant Design。
|
||||
|
||||
## Requirements
|
||||
|
||||
### Requirement: TDesign全局配置
|
||||
系统SHALL正确配置TDesign ConfigProvider作为全局配置容器，确保所有TDesign组件使用统一的配置。
|
||||
|
||||
#### Scenario: 应用启动时加载TDesign配置
|
||||
- **WHEN** 应用初始化启动
|
||||
- **THEN** ConfigProvider组件SHALL包裹整个应用
|
||||
- **AND** TDesign全局样式SHALL被正确引入
|
||||
- **AND** 所有TDesign组件SHALL使用统一配置
|
||||
|
||||
#### Scenario: 移除Ant Design配置
|
||||
- **WHEN** 迁移完成
|
||||
- **THEN** 应用中SHALL不存在Ant Design的ConfigProvider
|
||||
- **AND** 应用中SHALL不存在ThemeProvider
|
||||
- **AND** 应用中SHALL不存在任何Ant Design全局配置
|
||||
|
||||
### Requirement: TDesign组件替换
|
||||
系统SHALL将所有Ant Design组件替换为对应的TDesign组件，保持功能完整性。
|
||||
|
||||
#### Scenario: 布局组件替换
|
||||
- **WHEN** 使用Layout组件
|
||||
- **THEN** SHALL使用TDesign的Layout组件
|
||||
- **AND** Layout.Sider SHALL替换为Layout.Aside
|
||||
- **AND** Layout.Header SHALL保持不变
|
||||
- **AND** Layout.Content SHALL保持不变
|
||||
|
||||
#### Scenario: 表单组件替换
|
||||
- **WHEN** 使用表单相关组件
|
||||
- **THEN** Modal SHALL替换为Dialog
|
||||
- **AND** Form.Item SHALL替换为Form.FormItem
|
||||
- **AND** Input、Select、Switch SHALL使用TDesign版本
|
||||
- **AND** 表单验证功能SHALL保持完整
|
||||
|
||||
#### Scenario: 数据展示组件替换
|
||||
- **WHEN** 使用数据展示组件
|
||||
- **THEN** Table、Card、Statistic、Tag SHALL使用TDesign版本
|
||||
- **AND** 组件功能SHALL保持不变
|
||||
- **AND** 组件API SHALL兼容原有使用方式
|
||||
|
||||
#### Scenario: 导航组件替换
|
||||
- **WHEN** 使用导航组件
|
||||
- **THEN** Menu SHALL使用TDesign版本
|
||||
- **AND** 菜单项配置SHALL正确映射
|
||||
- **AND** 路由导航功能SHALL保持正常
|
||||
|
||||
### Requirement: TDesign图标系统
|
||||
系统SHALL使用tdesign-icons-react作为图标库，替换@ant-design/icons。
|
||||
|
||||
#### Scenario: 图标导入替换
|
||||
- **WHEN** 使用图标组件
|
||||
- **THEN** SHALL从tdesign-icons-react导入
|
||||
- **AND** SHALL不从@ant-design/icons导入任何图标
|
||||
- **AND** 图标显示SHALL正常
|
||||
|
||||
#### Scenario: 图标语义匹配
|
||||
- **WHEN** 替换图标
|
||||
- **THEN** 新图标SHALL与原图标语义相近
|
||||
- **AND** CloudServerOutlined SHALL替换为语义相近的TDesign图标
|
||||
- **AND** BarChartOutlined SHALL替换为语义相近的TDesign图标
|
||||
- **AND** SettingOutlined SHALL替换为语义相近的TDesign图标
|
||||
|
||||
### Requirement: 栅格系统兼容
|
||||
系统SHALL保持Row/Col栅格系统的使用，确保响应式布局功能正常。
|
||||
|
||||
#### Scenario: 栅格组件替换
|
||||
- **WHEN** 使用Row和Col组件
|
||||
- **THEN** SHALL使用TDesign的Row和Col组件
|
||||
- **AND** 响应式配置（xs、sm、md、lg、xl）SHALL保持有效
|
||||
- **AND** gutter配置SHALL正常工作
|
||||
- **AND** 布局效果SHALL与迁移前一致
|
||||
|
||||
### Requirement: 主题系统移除
|
||||
系统SHALL完全移除多主题系统，使用TDesign默认主题。
|
||||
|
||||
#### Scenario: 删除主题相关代码
|
||||
- **WHEN** 迁移完成
|
||||
- **THEN** ThemeContext SHALL被删除
|
||||
- **AND** themes目录 SHALL被删除
|
||||
- **AND** 所有主题相关导入SHALL被移除
|
||||
|
||||
#### Scenario: 使用TDesign默认主题
|
||||
- **WHEN** 应用运行
|
||||
- **THEN** SHALL使用TDesign默认视觉风格
|
||||
- **AND** 不SHALL提供主题切换功能
|
||||
- **AND** UI风格SHALL统一一致
|
||||
|
||||
### Requirement: 依赖管理
|
||||
系统SHALL正确管理npm依赖，确保无冗余依赖。
|
||||
|
||||
#### Scenario: 移除Ant Design依赖
|
||||
- **WHEN** 依赖安装完成
|
||||
- **THEN** package.json中SHALL不存在antd
|
||||
- **AND** package.json中SHALL不存在@ant-design/icons
|
||||
- **AND** package.json中SHALL不存在@ant-design/charts
|
||||
- **AND** package.json中SHALL不存在antd-style
|
||||
|
||||
#### Scenario: 添加TDesign依赖
|
||||
- **WHEN** 依赖安装完成
|
||||
- **THEN** package.json中SHALL存在tdesign-react
|
||||
- **AND** package.json中SHALL存在tdesign-icons-react
|
||||
- **AND** 依赖版本SHALL为最新稳定版
|
||||
|
||||
### Requirement: Settings页面简化
|
||||
系统SHALL保留Settings页面路由，但简化页面内容为空状态。
|
||||
|
||||
#### Scenario: Settings页面访问
|
||||
- **WHEN** 用户访问/settings路由
|
||||
- **THEN** 页面SHALL正常加载
|
||||
- **AND** 页面SHALL显示空状态提示
|
||||
- **AND** 不SHALL显示主题设置相关内容
|
||||
|
||||
#### Scenario: Settings路由保留
|
||||
- **WHEN** 应用路由配置
|
||||
- **THEN** /settings路由SHALL存在
|
||||
- **AND** Settings页面组件SHALL存在
|
||||
@@ -1,6 +1,10 @@
|
||||
# Test Coverage
|
||||
|
||||
## ADDED Requirements
|
||||
## Purpose
|
||||
|
||||
定义测试覆盖规范，建立后端和前端的单元测试、集成测试及 E2E 测试体系，确保核心业务逻辑的测试覆盖率达到目标水平。
|
||||
|
||||
## Requirements
|
||||
|
||||
### Requirement: 建立单元测试体系
|
||||
|
||||
|
||||
@@ -1,6 +1,10 @@
|
||||
# Unified Proxy Handler
|
||||
|
||||
## ADDED Requirements
|
||||
## Purpose
|
||||
|
||||
实现统一的代理处理器（ProxyHandler），替代独立的 OpenAI 和 Anthropic Handler，通过 ConversionEngine 和 RoutingService 支持多协议的请求转换与转发。
|
||||
|
||||
## Requirements
|
||||
|
||||
### Requirement: 实现统一代理 Handler
|
||||
|
||||
|
||||
@@ -1,6 +1,10 @@
|
||||
# Usage Statistics
|
||||
|
||||
## MODIFIED Requirements
|
||||
## Purpose
|
||||
|
||||
定义 API 使用统计规范，支持请求统计记录、按供应商/模型/日期范围查询统计、统计聚合以及并发安全的统计记录。
|
||||
|
||||
## Requirements
|
||||
|
||||
### Requirement: 记录请求统计
|
||||
|
||||
@@ -78,8 +82,6 @@
|
||||
|
||||
**变更说明：** 并发控制在 StatsRepository 中通过数据库事务实现。API 接口保持不变。
|
||||
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: 使用 service 层处理业务逻辑
|
||||
|
||||
Handler SHALL 通过 StatsService 处理业务逻辑。
|
||||
|
||||
Reference in New Issue
Block a user