## 通用原则

- 优先保持现有代码风格与架构模式，不要无理由重构。
- 任何功能或修复变更，需确保现有测试通过，必要时补充新测试。
- 所有输出（代码、注释、文档、提交信息）默认使用**简体中文**，专有名词或技术术语可保留英文。

## 编码规范

### 文件与编码
- 所有文件必须保持 UTF-8编码。
- 修改包含中文的文件时，不得造成中文注释、中文文案、错误提示乱码。
- 如果发现文件已有乱码，不要擅自猜测业务含义，应标记出来让人工确认。

## 测试要求

- 新增功能必须编写对应的单元测试或集成测试。
- 修复 Bug 时，先添加能复现问题的测试用例，再修复。
- 测试覆盖率不应低于当前项目基线（若未设置，尽量保持 ≥80%）。
- 测试命名清晰，能描述场景，如 should return error when user not found。

## 注释与文档

### 注释要求
- **保留**已有的重要注释（如文件头说明、JSDoc、业务解释）。
- 新增复杂逻辑、公共 API、关键算法时，必须补充**简洁的中文注释**，解释“为什么这么做”而非“做了什么”。
- 不要为了注释而注释，避免冗余的废话（例如 `i++; // 自增 i`）。
- 多行 JSDoc/文档注释保持可读性，**不要压缩成单行**。

## Never 规则

- Never 修改 dist/ 目录
- Never 使用内联样式，除非需要动态计算
- Never 在渲染路径中执行耗时操作
- Never 在列表渲染中省略 key 属性
- Never 修改 lock 文件
- Never 使用 git stash
- Never 切换分支
- Never 过度封装，保持代码简洁明了

## Requirements

- 代码提交前检查代码，包括但不限于代码格式、注释、测试覆盖率等。