@lobehub/chat 1.96.17 → 1.96.19

package/.cursor/rules/i18n/i18n.mdc

@@ -3,52 +3,52 @@ description: i18n workflow and troubleshooting
 globs: 
 alwaysApply: false
 ---
-# LobeChat Internationalization (i18n) Guide
+# LobeChat 国际化指南
 
-## Architecture Overview
+## 架构概览
 
-LobeChat uses **react-i18next** for internationalization with a well-structured namespace approach:
+LobeChat 使用 react-i18next 进行国际化，采用良好的命名空间架构：
 
-- **Default language**: Chinese (zh-CN) - serves as the source language
-- **Supported locales**: 18 languages including English, Japanese, Korean, Arabic, etc.
-- **Framework**: react-i18next with Next.js app router
-- **Translation automation**: [@lobehub/i18n-cli](mdc:package.json) for automated translations, config file: .i18nrc.js
+- 默认语言：中文（zh-CN），作为源语言
+- 支持语言：18 种语言，包括英语、日语、韩语、阿拉伯语等
+- 框架：react-i18next 配合 Next.js app router
+- 翻译自动化：@lobehub/i18n-cli 用于自动翻译，配置文件：.i18nrc.js
 
-## Directory Structure
+## 目录结构
 
 ```
 src/locales/
-├── default/           # Source language files (zh-CN)
-│   ├── index.ts      # Namespace exports
-│   ├── common.ts     # Common translations
-│   ├── chat.ts       # Chat-related translations
-│   ├── setting.ts    # Settings translations
-│   └── ...           # Other namespace files
-└── resources.ts      # Type definitions and locale config
-
-locales/               # Translated files
-├── en-US/            # English translations
-│   ├── common.json   # Common translations
-│   ├── chat.json     # Chat translations
-│   ├── setting.json  # Settings translations
-│   └── ...           # Other namespace JSON files
-├── ja-JP/            # Japanese translations
+├── default/           # 源语言文件（zh-CN）
+│   ├── index.ts      # 命名空间导出
+│   ├── common.ts     # 通用翻译
+│   ├── chat.ts       # 聊天相关翻译
+│   ├── setting.ts    # 设置翻译
+│   └── ...           # 其他命名空间文件
+└── resources.ts      # 类型定义和语言配置
+
+locales/               # 翻译文件
+├── en-US/            # 英语翻译
+│   ├── common.json   # 通用翻译
+│   ├── chat.json     # 聊天翻译
+│   ├── setting.json  # 设置翻译
+│   └── ...           # 其他命名空间 JSON 文件
+├── ja-JP/            # 日语翻译
 │   ├── common.json
 │   ├── chat.json
 │   └── ...
-└── ...               # Other language folders
+└── ...               # 其他语言文件夹
 ```
 
-## Workflow for Adding New Translations
+## 添加新翻译的工作流程
 
-### 1. Add New Translation Keys
+### 1. 添加新的翻译键
 
-**Step 1**: Add translation key to the appropriate namespace file in [src/locales/default/](mdc:src/locales/default)
+第一步：在 src/locales/default 目录下的相应命名空间文件中添加翻译键
 
 ```typescript
-// Example: src/locales/default/common.ts
+// 示例：src/locales/default/common.ts
 export default {
-    // ... existing keys
+    // ... 现有键
     newFeature: {
         title: "新功能标题",
         description: "功能描述文案",
@@ -57,40 +57,40 @@ export default {
 };
 ```
 
-**Step 2**: If creating a new namespace, export it in [src/locales/default/index.ts](mdc:src/locales/default/index.ts)
+第二步：如果创建新命名空间，需要在 src/locales/default/index.ts 中导出
 
 ```typescript
 import newNamespace from "./newNamespace";
 
 const resources = {
-    // ... existing namespaces
+    // ... 现有命名空间
     newNamespace,
 } as const;
 ```
 
-### 2. Translation Process
+### 2. 翻译过程
 
-**Development Mode** (Recommended):
+开发模式：
 
-- Manually add Chinese translations to corresponding JSON files in `locales/zh-CN/namespace.json`, this avoids running slow automation during development
-- Don't auto add translations for other language like English etc, most of developer is Chinese,
+一般情况下不需要你帮我跑自动翻译工具，跑一次很久，需要的时候我会自己跑。
+但是为了立马能看到效果，还是需要先翻译 `locales/zh-CN/namespace.json`，不需要翻译其它语言。
 
-**Production Mode**:
+生产模式：
 
 ```bash
-# Generate translations for all languages
+# 为所有语言生成翻译
 npm run i18n
 ```
 
-## Usage in Components
+## 在组件中使用
 
-### Basic Usage with Hooks
+### 基本用法
 
 ```tsx
 import { useTranslation } from "react-i18next";
 
 const MyComponent = () => {
-    const { t } = useTranslation("common"); // namespace
+    const { t } = useTranslation("common");
 
     return (
         <div>
@@ -102,58 +102,56 @@ const MyComponent = () => {
 };
 ```
 
-### With Parameters
+### 带参数的用法
 
 ```tsx
 const { t } = useTranslation("common");
 
-// Translation key with interpolation
 <p>{t("welcome.message", { name: "John" })}</p>;
 
-// Corresponding locale file:
+// 对应的语言文件：
 // welcome: { message: '欢迎 {{name}} 使用!' }
 ```
 
-### Multiple Namespaces
+### 多个命名空间
 
 ```tsx
 const { t } = useTranslation(['common', 'chat']);
 
-// Access different namespaces
 <button>{t('common:save')}</button>
 <span>{t('chat:typing')}</span>
 ```
 
-## Type Safety
+## 类型安全
 
-The project uses TypeScript for type-safe translations with auto-generated types from [src/locales/resources.ts](mdc:src/locales/resources.ts):
+项目使用 TypeScript 实现类型安全的翻译，类型从 src/locales/resources.ts 自动生成：
 
 ```typescript
 import type { DefaultResources, NS, Locales } from "@/locales/resources";
 
-// Available types:
-// - NS: Available namespace keys ('common' | 'chat' | 'setting' | ...)
-// - Locales: Supported locale codes ('en-US' | 'zh-CN' | 'ja-JP' | ...)
+// 可用类型：
+// - NS: 可用命名空间键 ('common' | 'chat' | 'setting' | ...)
+// - Locales: 支持的语言代码 ('en-US' | 'zh-CN' | 'ja-JP' | ...)
 
-// Type-safe namespace usage
-const namespace: NS = "common"; // ✅ Valid
-const locale: Locales = "en-US"; // ✅ Valid
+const namespace: NS = "common";
+const locale: Locales = "en-US";
 ```
 
-## Best Practices
+## 最佳实践
 
-### 1. Namespace Organization
+### 1. 命名空间组织
 
-- **common**: Shared UI elements (buttons, labels, actions)
-- **chat**: Chat-specific features
-- **setting**: Configuration and settings
-- **error**: Error messages and handling
-- **[feature]**: Feature-specific or page specific namespaces
+- common: 共享 UI 元素（按钮、标签、操作）
+- chat: 聊天特定功能
+- setting: 配置和设置
+- error: 错误消息和处理
+- [feature]: 功能特定或页面特定的命名空间
+- components: 可复用组件文案
 
-### 2. Key Naming Conventions
+### 2. 键命名约定
 
 ```typescript
-// ✅ Good: Hierarchical structure
+// ✅ 好：层次结构
 export default {
     modal: {
         confirm: {
@@ -167,17 +165,17 @@ export default {
     },
 };
 
-// ❌ Avoid: Flat structure
+// ❌ 避免：扁平结构
 export default {
     modalConfirmTitle: "确认操作",
     modalConfirmMessage: "确定要执行此操作吗？",
 };
 ```
 
-## Troubleshooting
+## 故障排除
 
-### Missing Translation Keys
+### 缺少翻译键
 
-- Check if the key exists in src/locales/default/namespace.ts
-- Ensure proper namespace import in component
-- Ensure new namespaces are exported in [src/locales/default/index.ts](mdc:src/locales/default/index.ts)
+- 检查键是否存在于 src/locales/default/namespace.ts 中
+- 确保在组件中正确导入命名空间
+- 确保新命名空间已在 src/locales/default/index.ts 中导出

package/.cursor/rules/packages/react-layout-kit.mdc

@@ -5,11 +5,11 @@ alwaysApply: false
 ---
 # React Layout Kit 使用指南
 
-`react-layout-kit` 是一个功能丰富的 React flex 布局组件库，在 lobe-chat 项目中被广泛使用。以下是重点组件的使用方法：
+react-layout-kit 是一个功能丰富的 React flex 布局组件库，在 lobe-chat 项目中被广泛使用。以下是重点组件的使用方法：
 
 ## Flexbox 组件
 
-Flexbox 是最常用的布局组件，用于创建弹性布局，类似于 CSS 的 `display: flex`。
+Flexbox 是最常用的布局组件，用于创建弹性布局，类似于 CSS 的 display: flex。
 
 ### 基本用法
 
@@ -31,16 +31,16 @@ import { Flexbox } from 'react-layout-kit';
 
 ### 常用属性
 
-- `horizontal`: 布尔值，设置为水平方向布局
-- `flex`: 数值或字符串，控制 flex 属性
-- `gap`: 数值，设置子元素之间的间距
-- `align`: 对齐方式，如 'center', 'flex-start' 等
-- `justify`: 主轴对齐方式，如 'space-between', 'center' 等
-- `padding`: 内边距值
-- `paddingInline`: 水平内边距值
-- `paddingBlock`: 垂直内边距值
-- `width/height`: 设置宽高，通常用 `'100%'` 或具体像素值
-- `style`: 自定义样式对象
+- horizontal: 布尔值，设置为水平方向布局
+- flex: 数值或字符串，控制 flex 属性
+- gap: 数值，设置子元素之间的间距
+- align: 对齐方式，如 'center', 'flex-start' 等
+- justify: 主轴对齐方式，如 'space-between', 'center' 等
+- padding: 内边距值
+- paddingInline: 水平内边距值
+- paddingBlock: 垂直内边距值
+- width/height: 设置宽高，通常用 '100%' 或具体像素值
+- style: 自定义样式对象
 
 ### 实际应用示例
 
@@ -60,12 +60,7 @@ import { Flexbox } from 'react-layout-kit';
   </Flexbox>
   
   {/* 中间内容区 */}
-  <Flexbox
-    flex={1}
-    style={{
-      height: '100%',
-    }}
-  >
+  <Flexbox flex={1} style={{ height: '100%' }}>
     {/* 主要内容 */}
     <Flexbox flex={1} padding={24} style={{ overflowY: 'auto' }}>
       <MainContent />
@@ -91,8 +86,6 @@ Center 是对 Flexbox 的封装，使子元素水平和垂直居中。
 ### 基本用法
 
 ```jsx
-import { Center } from 'react-layout-kit';
-
 <Center width={'100%'} height={'100%'}>
   <Content />
 </Center>
@@ -118,9 +111,9 @@ Center 组件继承了 Flexbox 的所有属性，同时默认设置了居中对
 
 ## 最佳实践
 
-1. 使用 `flex={1}` 让组件填充可用空间
-2. 使用 `gap` 代替传统的 margin 设置元素间距
-3. 嵌套 Flexbox 创建复杂布局
-4. 设置 `overflow: 'auto'` 使内容可滚动
-5. 使用 `horizontal` 创建水平布局，默认为垂直布局
-6. 与 `antd-style` 的 `useTheme` hook 配合使用创建主题响应式的布局
+- 使用 flex={1} 让组件填充可用空间
+- 使用 gap 代替传统的 margin 设置元素间距
+- 嵌套 Flexbox 创建复杂布局
+- 设置 overflow: 'auto' 使内容可滚动
+- 使用 horizontal 创建水平布局，默认为垂直布局
+- 与 antd-style 的 useTheme hook 配合使用创建主题响应式的布局

package/.cursor/rules/react-component.mdc

@@ -6,12 +6,14 @@ alwaysApply: false
 # react component 编写指南
 
 - 如果要写复杂样式的话用 antd-style ，简单的话可以用 style 属性直接写内联样式
-- 如果需要 flex 布局或者居中布局应该使用 react-layout-kit
-- 选择组件库中的组件时优先使用 [lobe-ui.mdc](mdc:.cursor/rules/package-usage/lobe-ui.mdc) 有的，然后才是 antd 的，不知道 @lobehub/ui 的组件怎么用，有哪些属性，就自己搜下这个项目其它地方怎么用的，不要瞎猜
+- 如果需要 flex 布局或者居中布局应该使用 react-layout-kit 的 Flexbox 和 Center 组件
+- 选择组件时优先顺序应该是 src/components > 安装的组件 package > lobe-ui > antd
 
-## 访问 theme 的两种方式
+## antd-style token system
 
-### 使用 antd-style 的 useTheme hook
+### 访问 token system 的两种方式
+
+#### 使用 antd-style 的 useTheme hook
 
 ```tsx
 import { useTheme } from 'antd-style';
@@ -32,7 +34,7 @@ const MyComponent = () => {
 }
 ```
 
-### 使用 antd-style 的 createStyles
+#### 使用 antd-style 的 createStyles
 
 ```tsx
 const useStyles = createStyles(({ css, token }) => {
@@ -65,4 +67,87 @@ const Card: FC<CardProps> = ({ title, content }) => {
     </Flexbox>
   );
 };
-```
+```
+
+### 一些你经常会忘记使用的 token
+
+请注意使用下面的 token 而不是 css 字面值。可以访问 https://ant.design/docs/react/customize-theme-cn 了解所有 token
+
+- 动画类
+    - token.motionDurationMid
+    - token.motionEaseInOut
+- 包围盒属性
+    - token.paddingSM
+    - token.marginLG
+
+
+## Lobe UI 包含的组件
+
+- 不知道 @lobehub/ui 的组件怎么用，有哪些属性，就自己搜下这个项目其它地方怎么用的，不要瞎猜，大部分组件都是在 antd 的基础上扩展了属性
+- 具体用法不懂可以联网搜索，例如 ActionIcon 就爬取 https://ui.lobehub.com/components/action-icon
+
+- General
+  ActionIcon
+  ActionIconGroup
+  Block
+  Button
+  Icon
+- Data Display
+  Avatar
+  Collapse
+  FileTypeIcon
+  FluentEmoji
+  GuideCard
+  Highlighter
+  Hotkey
+  Image
+  List
+  Markdown
+  MaterialFileTypeIcon
+  Mermaid
+  Segmented
+  Snippet
+  SortableList
+  Tag
+  Tooltip
+  Video
+- Data Entry
+  AutoComplete
+  CodeEditor
+  ColorSwatches
+  CopyButton
+  DatePicker
+  EditableText
+  EmojiPicker
+  Form
+  FormModal
+  HotkeyInput
+  ImageSelect
+  Input
+  SearchBar
+  Select
+  SliderWithInput
+  ThemeSwitch
+- Feedback
+  Alert
+  Drawer
+  Modal
+- Layout
+  DraggablePanel
+  Footer
+  Grid
+  Header
+  Layout
+  MaskShadow
+  ScrollShadow
+- Navigation
+  Burger
+  Dropdown
+  Menu
+  SideNav
+  Tabs
+  Toc
+- Theme
+  ConfigProvider
+  FontLoader
+  ThemeProvider

package/.cursor/rules/rules-attach.mdc

@@ -0,0 +1,76 @@
+---
+description: 
+globs: 
+alwaysApply: true
+---
+# LobeChat Cursor Rules System Guide
+
+This document explains how the LobeChat project's Cursor rules system works and serves as an index for manually accessible rules.
+
+## 🎯 Core Principle
+
+**All rules are equal** - there are no priorities or "recommendations" between different rule sources. You should follow all applicable rules simultaneously.
+
+## 📚 Four Ways to Access Rules
+
+### 1. **Always Applied Rules** - `always_applied_workspace_rules`
+- **What**: Core project guidelines that are always active
+- **Content**: Project tech stack, basic coding standards, output formatting rules
+- **Access**: No tools needed - automatically provided in every conversation
+
+### 2. **Dynamic Context Rules** - `cursor_rules_context`
+- **What**: Rules automatically matched based on files referenced in the conversation
+- **Trigger**: Only when user **explicitly @ mentions files** or **opens files in Cursor**
+- **Content**: May include brief descriptions or full rule content, depending on relevance
+- **Access**: No tools needed - automatically updated when files are referenced
+
+### 3. **Agent Requestable Rules** - `agent_requestable_workspace_rules`
+- **What**: Detailed operational guides that can be requested on-demand
+- **Access**: Use `fetch_rules` tool with rule names
+- **Examples**: `debug`, `i18n/i18n`, `code-review`
+
+### 4. **Manual Rules Index** - This file + `read_file`
+- **What**: Additional rules not covered by the above mechanisms
+- **Why needed**: Cursor's rule system only supports "agent request" or "auto attach" modes
+- **Access**: Use `read_file` tool to read specific `.mdc` files
+
+## 🔧 When to Use `read_file` for Rules
+
+Use `read_file` to access rules from the index below when:
+
+1. **Gap identification**: You determine a rule is needed for the current task
+2. **No auto-trigger**: The rule isn't provided in `cursor_rules_context` (because relevant files weren't @ mentioned)
+3. **Not agent-requestable**: The rule isn't available via `fetch_rules`
+
+## 📋 Available Rules Index
+
+The following rules are available via `read_file` from the `.cursor/rules/` directory:
+
+- `backend-architecture.mdc` – Backend layer architecture and design guidelines
+- `zustand-action-patterns.mdc` – Recommended patterns for organizing Zustand actions
+- `zustand-slice-organization.mdc` – Best practices for structuring Zustand slices
+- `drizzle-schema-style-guide.mdc` – Style guide for defining Drizzle ORM schemas
+- `react-component.mdc` – React component style guide and conventions
+
+## ❌ Common Misunderstandings to Avoid
+
+1. **"Priority confusion"**: There's no hierarchy between rule sources - they're complementary, not competitive
+2. **"Dynamic expectations"**: `cursor_rules_context` only updates when you @ files - it won't automatically include rules for tasks you're thinking about
+3. **"Tool redundancy"**: Each access method serves a different purpose - they're not alternatives to choose from
+
+## 🛠️ Practical Workflow
+
+```
+1. Start with always_applied_workspace_rules (automatic)
+2. Check cursor_rules_context for auto-matched rules (automatic) 
+3. If you need specific guides: fetch_rules (manual)
+4. If you identify gaps: consult this index → read_file (manual)
+```
+
+## Example Decision Flow
+
+**Scenario**: Working on a new Zustand store slice
+1. Follow always_applied_workspace_rules ✅
+2. If store files were @ mentioned → use cursor_rules_context rules ✅  
+3. Need detailed Zustand guidance → `read_file('.cursor/rules/zustand-slice-organization.mdc')` ✅
+4. All rules apply simultaneously - no conflicts ✅

package/.cursor/rules/system-role.mdc

@@ -14,9 +14,9 @@ You are an expert in UI/UX design, proficient in web interaction patterns, respo
 
 ## Problem Solving
 
+- Before formulating any response, you must first gather context by using tools like codebase_search, grep_search, file_search, web_search, fetch_rules, context7, and read_file to avoid making assumptions.
 - When modifying existing code, clearly describe the differences and reasons for the changes
 - Provide alternative solutions that may be better overall or superior in specific aspects
-- Always consider using the latest technologies, standards, and APIs to strive for code optimization, not just the conventional wisdom
 - Provide optimization suggestions for deprecated API usage
 - Cite sources whenever possible at the end, not inline
 - When you provide multiple solutions, provide the recommended solution first, and note it as `Recommended`
@@ -25,18 +25,14 @@ You are an expert in UI/UX design, proficient in web interaction patterns, respo
 
 ## Code Implementation
 
-- Write minimal code changes that are ONLY directly related to the requirements
 - Write correct, up-to-date, bug-free, fully functional, secure, maintainable and efficient code
 - First, think step-by-step: describe your plan in detailed pseudocode before implementation
 - Confirm the plan before writing code
 - Focus on maintainable over being performant
 - Leave NO TODOs, placeholders, or missing pieces
 - Be sure to reference file names
-- Please respect my prettier preferences when you provide code
 - When you notice I have manually modified the code, that was definitely on purpose and do not revert them
-- Don't remove meaningful code comments, be sure to keep original comments when providing applied code
-- Update the code comments when needed after you modify the related code
 - If documentation links or required files are missing, ask for them before proceeding with the task rather than making assumptions
 - If you're unable to access or retrieve content from websites, please inform me immediately and request the specific information needed rather than making assumptions
-- Sometimes ESLint errors may not be reasonable, and making changes could introduce logical bugs. If you find an ESLint rule unreasonable, disable it directly. For example, with the 'prefer-dom-node-text-content' rule, there are actual differences between innerText and textContent
 - You can use emojis, npm packages like `chalk`/`chalk-animation`/`terminal-link`/`gradient-string`/`log-symbols`/`boxen`/`consola`/`@clack/prompts` to create beautiful terminal output
+- Don't run `tsc --noEmit` to check ts syntax error, because our project is very large and the validate very slow