-init:初始化了kiro的规则库，方便ai开发

.kiro/steering/python-后端规范.md

@@ -0,0 +1,116 @@
+---
+description: Python 后端项目的编码标准和最佳实践
+---
+
+# Python 后端开发规范
+
+## 项目结构
+- 所有后端代码位于 `backend` 目录
+- 主应用入口为 `backend/main.py`
+- 数据库模型定义在 `backend/models.py`
+- 数据库连接配置在 `backend/database.py`
+- 遵循既定的目录结构：
+  - `routers/`: API 路由定义
+  - `schemas/`: Pydantic 数据模型和验证
+  - `services/`: 业务逻辑层
+  - `test/`: **所有测试文件必须保存在此文件夹中**
+  - `__pycache__/`: Python 缓存文件（自动生成）
+
+## 测试文件管理
+- **重要：所有测试文件必须保存在 `./backend/test` 文件夹中**
+- 测试文件命名使用 `test_*.py` 格式
+- 测试文件结构应与被测试的模块结构对应
+- 不要在项目其他位置创建测试文件，防止到处拉屎
+- 示例：
+  - 测试 `routers/users.py` → `test/test_routers_users.py`
+  - 测试 `services/annotation.py` → `test/test_services_annotation.py`
+
+## 代码风格
+- 遵循 PEP 8 编码规范
+- 使用 4 个空格缩进，不使用制表符
+- 行长度限制为 88 字符（Black 格式化器标准）
+- 使用有意义的变量和函数名称
+- 类名使用 PascalCase
+- 函数和变量名使用 snake_case
+- 常量使用 UPPER_CASE
+
+## FastAPI 最佳实践
+- 使用路由器（APIRouter）组织 API 端点
+- 使用 Pydantic 模型进行请求和响应验证
+- 使用依赖注入（Depends）管理数据库会话和认证
+- 为所有端点添加适当的 HTTP 状态码
+- 使用类型提示提高代码可读性
+- 添加详细的 API 文档字符串
+
+## 数据库操作
+- 使用 SQLAlchemy ORM 进行数据库操作
+- 在 `models.py` 中定义数据库模型
+- 使用 Alembic 进行数据库迁移
+- 始终使用数据库会话上下文管理器
+- 避免 N+1 查询问题，使用 joinedload 或 selectinload
+- 为查询添加适当的索引
+
+## 错误处理
+- 使用 FastAPI 的 HTTPException 处理 HTTP 错误
+- 创建自定义异常类处理业务逻辑错误
+- 使用 try-except 块捕获和处理异常
+- 记录错误信息以便调试
+- 返回用户友好的错误消息
+- 不要暴露敏感的系统信息
+
+## 安全性
+- 使用环境变量存储敏感配置（参考 `.env.example`）
+- 实现适当的身份验证和授权机制
+- 使用 CORS 中间件控制跨域访问
+- 验证和清理所有用户输入
+- 使用参数化查询防止 SQL 注入
+- 实现速率限制防止滥用
+
+## 依赖管理
+- 在 `requirements.txt` 中列出所有依赖
+- 使用虚拟环境隔离项目依赖
+- 固定依赖版本以确保可重现性
+- 定期更新依赖以修复安全漏洞
+
+## 代码组织
+- 保持函数简短且专注于单一职责
+- 将复杂的业务逻辑提取到 `services` 层
+- 使用 `schemas` 定义数据传输对象（DTO）
+- 路由处理器应该简洁，主要负责请求/响应处理
+- 避免在路由中直接编写业务逻辑
+
+## 异步编程
+- 对 I/O 密集型操作使用 async/await
+- 使用异步数据库驱动（如 asyncpg）
+- 避免在异步函数中使用阻塞操作
+- 使用 asyncio 工具管理并发任务
+
+## 日志记录
+- 使用 Python 的 logging 模块
+- 为不同环境配置不同的日志级别
+- 记录重要的业务操作和错误
+- 避免记录敏感信息（密码、令牌等）
+- 使用结构化日志便于分析
+
+## 性能优化
+- 使用数据库连接池
+- 实现适当的缓存策略
+- 对昂贵的操作使用后台任务
+- 使用分页处理大量数据
+- 监控和优化慢查询
+
+## 文档
+- 为所有公共函数和类添加文档字符串
+- 使用 FastAPI 的自动文档功能
+- 在 README.md 中提供清晰的设置说明
+- 记录 API 端点的用途和参数
+- 保持文档与代码同步更新
+
+## 最佳实践
+- 编写清晰、可读的代码
+- 遵循 DRY（Don't Repeat Yourself）原则
+- 使用类型提示提高代码质量
+- 编写单元测试和集成测试
+- 进行代码审查
+- 使用版本控制（Git）
+- 定期重构改进代码质量

.kiro/steering/react-组件规范.md

@@ -0,0 +1,139 @@
+---
+description: React 应用的编码标准和最佳实践
+---
+
+# React 最佳实践
+
+## 项目结构
+- 所有前端代码位于 `web` 目录
+- 主应用代码位于 `web/apps/labelstudio`
+- 共享库位于 `web/libs`
+- 遵循既定的目录结构：
+  - `components/`: 可复用的 UI 组件
+  - `pages/`: 顶层页面组件
+  - `utils/`: 工具函数
+  - `hooks/`: 自定义 React Hooks
+  - `atoms/`: Jotai 原子状态定义
+  - `providers/`: Context 提供者
+  - `services/`: API 和其他服务
+  - `types/`: TypeScript 类型定义
+  - `assets/`: 静态资源
+
+## 组件结构
+- 使用函数组件而非类组件
+- 保持组件小而专注
+- 将可复用逻辑提取到自定义 Hooks
+- 使用组合而非继承
+- 使用 TypeScript 实现适当的 prop 类型
+- 将大组件拆分为更小、更专注的组件
+- 遵循一致的文件组织模式：
+  ```
+  component-name/
+    component-name.tsx
+    component-name.module.scss
+    component-name.test.tsx
+    index.ts
+  ```
+
+## Hooks 使用
+- 遵循 Hooks 规则（只在顶层调用、只在 React 函数中调用）
+- 使用自定义 Hooks 实现可复用逻辑
+- 保持 Hooks 专注和简单
+- 除非绝对必要，否则避免使用 useEffect
+- 在 useEffect 中使用适当的依赖数组
+- 在 useEffect 中实现清理逻辑
+- 避免嵌套 Hooks
+
+## 状态管理
+- 使用 useState 管理本地组件状态
+- 使用 Jotai 原子而非 Context API 管理共享状态
+- 使用 atomWithReducer 处理复杂状态逻辑
+- 使用 atomWithQuery 处理任何 API 数据请求
+- 将状态保持在尽可能接近使用位置的地方
+- 通过适当的状态管理避免 prop drilling
+- 仅使用 Jotai 作为全局状态管理的单一数据源
+
+## 性能优化
+- 实现适当的记忆化（useMemo, useCallback）
+- 对昂贵的组件使用 React.memo
+- 避免不必要的重渲染
+- 实现适当的懒加载
+- 在列表中使用适当的 key props
+- 分析和优化渲染性能
+- 避免在渲染函数中创建新对象或函数
+
+## 开发工具
+- 使用 Biome 进行代码检查和格式化
+- 遵循 .stylelintrc.json 中定义的 CSS/SCSS 检查规则
+- 使用 TypeScript 确保类型安全
+- 通过监控导入来控制打包大小
+
+## 表单处理
+- 对表单输入使用受控组件
+- 实现适当的表单验证
+- 正确处理表单提交状态
+- 显示适当的加载和错误状态
+- 对复杂表单使用表单库
+- 为表单实现适当的无障碍功能
+
+## 错误处理
+- 实现错误边界
+- 正确处理异步错误
+- 显示用户友好的错误消息
+- 实现适当的后备 UI
+- 适当记录错误
+- 优雅处理边缘情况
+
+## 测试
+- 为组件编写单元测试
+- 为复杂流程实现集成测试
+- 使用 React Testing Library
+- 测试用户交互
+- 测试错误场景
+- 实现适当的模拟数据
+
+## 无障碍性
+- 确保组件符合 WCAG 2.1 AA 标准
+- 使用语义化 HTML 元素
+- 实现适当的 ARIA 属性
+- 确保键盘导航
+- 使用屏幕阅读器测试
+- 处理焦点管理
+- 为图片提供适当的 alt 文本
+
+## 代码组织
+- 使用适当的文件命名约定，采用 kebab-case，例如 ListItem -> `list-item.tsx`
+- 优先每个文件夹一个组件，但必要时将相关组件分组在一起，确保每个文件只有一个组件
+- 组件文件夹应包含一个 SCSS `.module.scss` 文件，文件名为组件的 kebab-case 形式，例如 ListItem -> `list-item.module.scss`
+- 实现适当的目录结构
+- UI 组件位于 `web/libs/ui`
+- 跨应用共享的应用组件（如某些页面级块）位于 `web/libs/app-common`
+- `web/apps` 中的代码只能从 `web/libs` 导入，`web/libs` 不能从 `web/apps` 导入
+- `web/libs/app-common` 中的代码只能从其他 `web/libs` 或 `web/apps` 导入。其他 `web/libs` 不能从 `web/libs/app-common` 导入
+- 将原子保存在全局 atoms 文件夹中，文件名与实体或状态意图匹配
+- 通过将 story 文件与组件文件放在一起，将所有组件及其状态添加到 Storybook，例如 `list-item.stories.tsx`
+
+## 包导入规范
+- 使用 `@humansignal/ui` 包获取 UI 组件
+- 使用 `@humansignal/icons` 包获取图标
+- 使用 `@humansignal/core` 包获取核心工具/函数
+- 使用 `@humansignal/app-common` 包获取应用组件
+
+## 最佳实践
+- 禁止循环导入
+- 使用适当的导入/导出
+- 遵循既定的导入顺序
+- 组合组件而非扩展组件
+- 保持组件专注于单一职责
+- 用清晰的注释记录复杂逻辑
+- 遵循项目的文件夹结构和命名约定
+- 优先使用受控组件而非非受控组件
+- 保持组件的纯净性，避免副作用
+- 使用 PropTypes 或 TypeScript 进行类型检查
+
+## 组件设计原则
+- 单一职责原则：每个组件只做一件事
+- 可复用性：设计可在多处使用的组件
+- 可组合性：小组件组合成大组件
+- 可测试性：编写易于测试的组件
+- 可维护性：代码清晰易懂，便于维护

.kiro/steering/tailwind-样式规范.md

@@ -0,0 +1,95 @@
+---
+description: 前端应用的 Tailwind CSS 和 UI 组件最佳实践
+---
+
+# Tailwind CSS 最佳实践
+
+## 组件样式
+- 使用工具类而非自定义 CSS
+- 需要时使用 @apply 将相关工具类分组
+- 仅在必要时使用自定义组件样式作为 SCSS 模块，以提高组件的可读性和可维护性
+- 使用适当的响应式设计工具类
+- 使用适当的状态变体
+- 保持组件样式一致
+
+## 设计令牌（Tokens）
+- 所有来自 Figma 的令牌都是程序化生成的，定义在 `web/libs/ui/src/tokens/tokens.scss` 文件中
+- 可以通过使用 `Figma Variable Exporter` 插件从 Figma 导出，替换 `web/design-tokens.json` 的内容，然后使用 `cd web/ && yarn design-tokens` 命令重新生成令牌
+- 重新生成令牌时，确保运行项目根目录的 `make fmt-all` 命令，以确保所有文件都经过检查和格式化
+- 不要使用未通过 Figma Variable Exporter 插件定义并在 `web/libs/ui/src/tokens/tokens.scss` 文件中建立的令牌
+- 不要使用任何默认的 tailwind css 类，只使用通过 `web/libs/ui/src/tokens/tokens.js` 文件定义的类
+
+## 布局
+- 使用语义化间距工具类，例如 `p-tight` 而非 `p-200` 或 `--spacing-tight` 而非 `--spacing-200`
+- 有效使用 Flexbox 和 Grid 工具类
+- 需要时使用容器查询
+- 实现适当的响应式断点
+- 使用适当的 padding 和 margin 工具类
+- 实现适当的对齐工具类
+
+## 排版
+- 使用语义化排版工具类，例如 `text-body-medium` 而非 `text-16` 或 `--font-size-body-medium` 而非 `--font-size-16`
+- 使用适当的字体大小工具类
+- 实现适当的行高
+- 使用适当的字重工具类
+- 正确配置自定义字体
+- 使用适当的文本对齐
+- 实现适当的文本装饰
+
+## 颜色
+- 仅使用语义化颜色命名，确保深色模式兼容性，例如 `bg-primary-background` 而非 `bg-grape-000` 或 `--color-primary-background` 而非 `--color-grape-000`
+- 实现适当的颜色对比度
+- 有效使用不透明度工具类
+- 正确配置自定义颜色
+- 使用适当的渐变工具类
+- 实现适当的悬停状态
+
+## UI 组件
+- 从 `web/libs/ui/src/shad` 使用可用的 shadcn/ui 组件
+- 仅使用从 `web/libs/ui` 重新导出的 shadcn/ui 组件，而非 `web/libs/ui/src/shad` 中定义的原始组件
+- 在其他 libs 和 apps 中导入这些组件时应使用 `@humansignal/ui`
+- 正确组合组件
+- 保持组件变体一致
+- 实现适当的动画
+- 使用适当的过渡工具类
+- 牢记无障碍性
+- UI 组件应在 `web/libs/ui` 中定义和导出，并遵循代码组织的最佳实践
+
+## 响应式设计
+- 使用移动优先方法
+- 实现适当的断点
+- 有效使用容器查询
+- 正确处理不同屏幕尺寸
+- 实现适当的响应式排版
+- 使用适当的响应式间距
+
+## 性能优化
+- 使用适当的清除配置
+- 最小化自定义 CSS
+- 使用适当的缓存策略
+- 实现适当的代码分割
+- 为生产环境优化
+- 监控打包大小
+
+## 样式组织
+- 按逻辑顺序排列工具类（布局 → 间距 → 排版 → 颜色 → 其他）
+- 使用一致的类名顺序
+- 将复杂的样式组合提取为组件
+- 使用 @layer 指令组织自定义样式
+
+## 无障碍性
+- 确保足够的颜色对比度
+- 使用语义化 HTML 元素
+- 实现键盘导航支持
+- 添加适当的 ARIA 属性
+- 测试屏幕阅读器兼容性
+
+## 最佳实践
+- 遵循命名约定
+- 保持样式有序
+- 使用适当的文档
+- 实现适当的测试
+- 遵循无障碍性指南
+- 使用适当的版本控制
+- 避免内联样式，优先使用工具类
+- 保持样式的可维护性和可读性

.kiro/steering/typescript-前端规范.md

@@ -0,0 +1,81 @@
+---
+description: 前端应用的 TypeScript 编码标准和最佳实践
+---
+
+# TypeScript 最佳实践
+
+## 类型系统
+- 对对象定义优先使用 interface 而非 type
+- 对联合类型、交叉类型和映射类型使用 type
+- 避免使用 `any`，对未知类型优先使用 `unknown`
+- 使用严格的 TypeScript 配置
+- 利用 TypeScript 的内置工具类型
+- 对可复用的类型模式使用泛型
+
+## 命名约定
+- 对类型名称和接口使用 PascalCase
+- 对变量和函数使用 camelCase
+- 对常量使用 UPPER_CASE
+- 使用带辅助动词的描述性名称（例如 isLoading, hasError）
+- React props 的接口前缀使用 'Props'（例如 ButtonProps）
+
+## 代码组织
+- 将类型定义保持在使用位置附近
+- 共享时从专用类型文件导出类型和接口
+- 使用桶导出（index.ts）组织导出
+- 将共享类型放在 `types` 目录中
+- 将组件 props 与其组件放在一起
+
+## 函数
+- 对公共函数使用显式返回类型
+- 对回调和方法使用箭头函数
+- 使用自定义错误类型实现适当的错误处理
+- 对复杂类型场景使用函数重载
+- 优先使用 async/await 而非 Promises
+
+## 最佳实践
+- 在 tsconfig.json 中启用严格模式
+- 对不可变属性使用 readonly
+- 利用可辨识联合类型确保类型安全
+- 使用类型守卫进行运行时类型检查
+- 实现适当的 null 检查
+- 除非必要，否则避免类型断言
+
+## 错误处理
+- 为特定领域的错误创建自定义错误类型
+- 对可能失败的操作使用 Result 类型
+- 实现适当的错误边界
+- 使用带类型的 catch 子句的 try-catch 块
+- 正确处理 Promise 拒绝
+
+## 设计模式
+- 对复杂对象创建使用建造者模式
+- 对数据访问实现仓储模式
+- 对对象创建使用工厂模式
+- 利用依赖注入
+- 使用模块模式进行封装
+
+## 类型安全
+- 使用严格的 null 检查
+- 避免使用类型断言（as），除非绝对必要
+- 使用类型守卫函数进行运行时验证
+- 利用 TypeScript 的控制流分析
+- 使用 const 断言提高类型推断
+
+## 泛型使用
+- 为可复用组件和函数使用泛型
+- 为泛型参数使用有意义的名称
+- 使用泛型约束限制类型参数
+- 避免过度使用泛型导致代码复杂化
+
+## 导入和导出
+- 使用命名导出而非默认导出
+- 按逻辑分组组织导入语句
+- 使用路径别名简化导入路径
+- 避免循环依赖
+
+## 性能考虑
+- 使用适当的类型推断减少类型注解
+- 避免过度复杂的类型计算
+- 使用类型缓存优化编译性能
+- 合理使用类型断言避免性能损失

web/tes

@@ -1 +0,0 @@
-123123