chore: 停止追踪trae配置

.gitignore

@@ -21,3 +21,5 @@ data.json
 # Exclude macOS Finder (System Explorer) View States
 .DS_Store
 dist
+
+.trae/

.trae/rules/project_rules.md

@@ -1,42 +0,0 @@
-# Obsidian 插件开发项目规则
-
-## 1. 目录结构
-- 插件主入口文件建议为 `main.ts`，设置相关配置和初始化逻辑。
-- 组件、工具函数、类型定义等应分别放在 `components/`、`utils/`、`models/` 等目录下，保持结构清晰。
-
-## 2. 命名规范
-- 文件、文件夹、变量、函数、类名均采用有意义的英文单词，遵循 camelCase（小驼峰）或 PascalCase（大驼峰）风格。
-- 组件文件以大写字母开头（如 `MyComponent.tsx`），工具函数以小写字母开头（如 `folderUtils.ts`）。
-
-## 3. 代码风格
-- 使用 TypeScript 进行开发，类型声明完整。
-- 遵循 ESLint 规则，避免未使用变量、空函数等问题。
-- 每个函数、类、组件不必有注释，除非是重要函数或接口才用注释来说明用途和参数。
-- 统一使用单引号（'）作为字符串定界符。
-- 每行代码不超过 120 字符。
-- 遵循 Obsidian 插件开发最佳实践，参考官方文档。
-
-## 4. 提交规范
-- 使用英文提交信息，格式为：`[类型]: 模块 - 描述`，如 `feat: 卡片面板 - 新增搜索功能`、`fix: 卡片面板 - 修复启动时面板未自动打开的问题`。
-- 常见类型：feat（新功能）、fix（修复）、opt(小优化)、docs（文档）、refactor（重构）、test（测试）、misc（杂项）。
-
-## 5. 开发流程
-
-- 合并前请确保本地通过所有 lint 检查和测试。
-- 重要变更需在 `README.md` 或相关文档中说明。
-
-## 6. 依赖管理
-- 依赖包统一使用 `npm` 管理，避免重复和无用依赖。
-- 安装新依赖需说明用途，避免包膨胀。
-
-## 7. 代码审查
-
-- 审查重点：功能实现、代码规范、可读性、潜在 bug。
-
-## 8. 代码复用与可读性
-- 鼓励模块化设计，功能拆分为独立、可复用的组件或函数。
-- 组件、函数应遵循单一职责原则，避免过多逻辑耦合。
-- 合理抽象公共逻辑，避免重复代码，优先复用已有模块。
-- 命名需准确表达用途，提升可读性和维护性。
-- 复杂逻辑建议适当补充注释或文档说明，便于团队协作。
-- 保持代码整洁，及时清理无用代码和注释。