technical-spec git:20260831.b183037A

Immutable. This exact content never changes and is served at /api/v1/blob/b0b00057ddc2e590.

---
name: technical-spec
description: 定义环境变量、架构设计以及构建/测试命令。在配置环境或设计架构时使用。
---

# 技术设计规则

## 前置条件检测

在应用与技术或命令相关的具体规则之前，先检查清单文件、锁文件、构建/测试配置、CI 定义以及具有代表性的源文件。只有当仓库中的证据明确指出某个工具、脚本、路径别名或运行时，才将其视为已观察到。将从周边模式推断出的结论标注为推断。当某个缺失的决策会影响架构、兼容性、安全性或验证时，停下来明确指出所需的具体配置或用户决策。

## 基础技术栈方针
当仓库配置确认使用 TypeScript 应用栈时，以下规则适用。通过将当前需求与已接受的约束映射到明确的模块职责、依赖方向、数据流和验证边界来选择架构。

## 环境变量管理与安全

### 环境变量管理
- 集中管理环境变量，以及用于保证其类型安全的构建时校验机制
- 通过一个带类型的配置边界读取环境变量；应用代码只使用经过校验的配置值
- 仅当需求中定义了缺省情况下的有效行为时，才为变量设置默认值；否则应在配置校验阶段失败，并给出该变量名称和期望格式

### 安全
- 将本地 `.env` 文件排除在版本控制之外，并为所需的变量名提供不含机密信息的示例文件
- 从已配置的密钥存储或运行时环境边界加载 API 密钥和机密信息
- 仅记录并返回当前信任边界所批准的字段；在跨越不可信边界返回数据前，屏蔽凭据、令牌、个人数据和内部诊断信息

## 架构设计

### 架构设计原则
使用以下可观测的决策来选择架构：

- **职责**：每个模块/层要明确说明自己拥有的行为以及委托出去的行为
- **依赖方向**：导入和运行时调用应遵循在配置或具有代表性的实现中观察到的项目边界规则
- **状态/数据所有权**：每个持久化或可变的值都应有唯一的权威所有者
- **验证边界**：每个公开契约都应有能够观测到它的单元测试、集成测试或 E2E 检查

## 统一数据流原则

#### 基本原则
1. **单一数据源**：同一信息只存放在一个地方
2. **结构化数据优先**：使用解析后的对象而非 JSON 字符串
3. **职责分离**：每一层要明确说明自己拥有的数据或行为，以及其他层使用它的边界

#### 数据流最佳实践
- **输入端校验**：在输入层校验数据，并以类型安全的形式在内部传递
- **集中式转换**：将数据转换逻辑集中到专门的工具函数中
- **结构化日志**：在数据流的每个阶段输出结构化日志

## 构建与测试
按以下优先顺序从 `packageManager` 字段、锁文件或既有的 CI 命令中选择包管理器。只执行所选清单文件中存在的脚本。

### 构建命令
- `build` - TypeScript 构建
- `type-check` - 类型检查（不生成产物）

### 测试命令
- `test` - 运行测试

### 质量保障机制的识别

在执行质量检查之前，先识别变更所涉及区域存在哪些质量机制：
- 主要检测方式：检查变更区域的文件类型、项目清单和配置，识别适用的质量工具
  - 检查 CI 流水线定义中是否有覆盖受影响路径的检查
  - 检查是否存在特定领域的 linter 或校验器配置（例如 schema 校验器、API 规范校验器、配置文件 linter）
  - 检查项目配置中是否存在特定领域的约束（命名规则、长度限制、格式要求）
- 当任务文件提供了 Operation Verification Methods 时，将其作为任务专属检查项运行
- 将发现的特定领域检查项与下述标准阶段一并纳入

### 质量检查要求

实现完成后必须进行质量检查：

**阶段 1-3：代码质量检查**
- 从 package.json 的 scripts 中自动检测并执行以下内容：
  - lint + 格式检查
  - 检测未使用的导出
  - 检测循环依赖
  - TypeScript 构建

**过渡依据**：所有适用的静态/领域检查均成功退出。缺失的必需脚本应连同其清单/配置路径一并报告，并阻塞下一阶段，直到确定等效的既有命令为止。

**阶段 4：测试**
- `test` - 执行测试

**过渡依据**：所有适用的已配置测试套件均通过，或依赖特定环境的套件被记录为受阻，并附带其确切的前置条件。

**阶段 5：代码质量复验**
- `check:code` - 复验代码质量（清理阶段 4 测试修复产生的副作用）

**完成依据**：测试相关修复之后静态/领域检查仍然通过，构建成功，且所有必需测试均已通过或被明确标记为受阻。

### 辅助命令
- `check:all` - 整体综合检查（check:code + test）*用于人工批量验证
- `format` - 格式修复
- `lint:fix` - Lint 修复

### 故障排查
- **依赖错误**：首先记录失败的解析器输出、所选的包管理器、清单文件和锁文件状态。只有在保留锁文件和生成产物的前提下，才使用仓库既有的干净安装命令；在执行会移除或重新生成依赖状态的操作之前，先请求批准