Awesome Cursor Rules Collection

# Project Instructions

Use the project specification and guidelines as you build the app.

Write the complete code for every step. Do not get lazy.

Your goal is to completely finish whatever I ask for.

## Overview

This is an IDE for ideas.

## Tech Stack

- Frontend: Next.js 13 with TypeScript
- Styling: Tailwind CSS
- State Management: React Server Components
- UI Components: Server and Client Components as appropriate

## Project Structure

### General Structure

```
/
├── app/                    # Next.js app directory
│   ├── layout.tsx         # Root layout
│   ├── page.tsx           # Home page
│   └── _components/       # Route-specific components
├── components/            # Shared components
├── types/                 # TypeScript types
├── scripts/              # Python scripts for XML processing
├── docs/                 # Architecture documentation
├── public/               # Static assets
└── styles/               # Global styles
```

## Rules

Follow these rules when building the project.

### General Rules

- Each file must begin with an "AI Context" comment describing its purpose
- Keep files small and single-purpose
- Use `@` to import anything from the project unless otherwise specified
- Use kebab case for all files and folders unless otherwise specified
- Document core architecture decisions in /docs

#### Env Rules

- If you update environment variables, update the `.env.example` file
- All environment variables should go in `.env.local`
- Do not expose environment variables to the frontend
- Use `NEXT_PUBLIC_` prefix for environment variables that need to be accessed from the frontend
- You may import environment variables in server actions and components by using `process.env.VARIABLE_NAME`

#### Type Rules

Follow these rules when working with types.

- When importing types, use `@/types`
- Name files like `example-types.ts`
- All types should go in `types`
- Make sure to export the types in `types/index.ts`
- Keep TypeScript strict to encourage type safety
- Prefer interfaces over type aliases

An example of a type:

`types/actions-types.ts`
```ts
export type ActionState<T> = { isSuccess: true; message: string; data: T } | { isSuccess: false; message: string; data?: never };
```

And exporting it:

`types/index.ts`
```ts
export * from "./actions-types";
```

### Frontend Rules

Follow these rules when working on the frontend.

It uses Next.js, Tailwind, and Server/Client Components.

#### General Rules

- Use `lucide-react` for icons
- Use Tailwind CSS for styling, referencing the tailwind.config.js

#### Components

- Use divs instead of other html tags unless otherwise specified
- Separate the main parts of a component's html with an extra blank line for visual spacing
- Use actions, not queries, in the app
- Always tag a component with either `use server` or `use client` at the top, including layouts and pages
- Use PascalCase for React components and TypeScript interfaces

##### Organization

- All components be named using kebab case like `example-component.tsx` unless otherwise specified
- Put components in `/_components` in the route if one-off components
- Put components in `/components` from the root if shared components

##### Data Fetching

- Fetch data in server components and pass the data down as props to client components
- Use server actions from `/actions` to mutate data

##### Server Components

- Use `"use server"` at the top of the file
- Implement Suspense for asynchronous data fetching to show loading states while data is being fetched
- If no asynchronous logic is required for a given server component, you do not need to wrap the component in `<Suspense>`
- If asynchronous fetching is required, use a `<Suspense>` boundary and a fallback to indicate a loading state

Example of a server layout:

```tsx
"use server";

export default async function ExampleServerLayout({ children }: { children: React.ReactNode }) {
  return children;
}
```

##### Client Components

- Use `"use client"` at the top of the file
- Client components can safely rely on props passed down from server components

Example of a client component:

```tsx
"use client";

interface ExampleClientComponentProps {
  initialData: any[];
}

export default function ExampleClientComponent({ initialData }: ExampleClientComponentProps) {
  return <div>{initialData.length} items</div>;
}
``` 

# Design choices and conventions for the api-key-checker project

code_organization:
  - Use Typer for CLI interface to leverage type hints and automatic help generation
  - Keep core functionality in APIKeyChecker class, separate from CLI handling
  - Use pathlib.Path throughout for file handling
  - Use loguru for logging instead of standard library logging

type_hints:
  - All function parameters and return values must be type-hinted
  - Use Optional[] for optional parameters
  - Use List[], Dict[] for collection types
  - Use Pattern type from typing for compiled regex patterns

configuration:
  - Primary configuration through pre-commit-config.yaml using YAML block scalars
  - Support both list and dict formats for pattern specification
  - Maintain backward compatibility with --patterns CLI option
  - Default to a sensible pattern if none specified

error_handling:
  - Skip binary files gracefully with warning message
  - Return non-zero exit code if violations found
  - Provide detailed error messages with file location and line numbers
  - Use loguru.error() for violation reporting

testing:
  - Use pytest fixtures for temporary file handling
  - Test both success and failure cases
  - Test binary file handling
  - Test all configuration methods
  - Clean up temporary files in fixtures

patterns:
  - Store patterns as Dict[str, Pattern] for efficient reuse
  - Compile patterns once at initialization
  - Support multiple patterns per check
  - Include pattern in violation messages for debugging

pre_commit_integration:
  - Run on text files only
  - Support YAML block scalar syntax for better readability
  - Allow inline comments in pattern definitions
  - Keep configuration in pre-commit-config.yaml for simplicity

// HTMX with Go and Fiber .cursorrules

// HTMX, Go, and Fiber best practices
const htmxGoFiberBestPractices = [
  "Use Fiber's HTML rendering for server-side templates",
  "Implement Fiber's routing system for HTMX requests",
  "Utilize Fiber's middleware for request processing",
  "Use Fiber's JSON methods for API responses",
  "Implement proper error handling with Fiber's error handling",
  "Utilize Fiber's static file serving for assets",
];

// Folder structure
const folderStructure = `
cmd/
  main.go
internal/
  handlers/
  models/
  templates/
static/
  css/
  js/
go.mod
go.sum
`;

// Additional instructions
const additionalInstructions = `
1. Use Fiber's App.Get/Post/etc for routing HTMX requests
2. Implement CSRF protection with Fiber middleware
3. Utilize Fiber's Context for handling HTMX-specific headers
4. Use Fiber's template engine for server-side rendering
5. Implement proper logging with Fiber's Logger middleware
6. Follow Fiber's best practices for project structure
7. Use environment variables for configuration
`;

    You are an expert full-stack developer proficient in TypeScript, React, Next.js, and modern UI/UX frameworks (e.g., Tailwind CSS, Shadcn UI, Radix UI). Your task is to produce the most optimized and maintainable Next.js code, following best practices and adhering to the principles of clean code and robust architecture.

    ### Objective
    - Create a Next.js solution that is not only functional but also adheres to the best practices in performance, security, and maintainability.

    ### Code Style and Structure
    - Write concise, technical TypeScript code with accurate examples.
    - Use functional and declarative programming patterns; avoid classes.
    - Favor iteration and modularization over code duplication.
    - Structure files with exported components, subcomponents, helpers, static content, and types.
    - Always declare the type of each variable and function (parameters and return value).
    - Avoid using any.
    - Create necessary types.
    - Use JSDoc to document public classes and methods.
    - Don't leave blank lines within a function.
    - One export per file.

    ### Nomenclature
    - Use PascalCase for classes.
    - Use camelCase for variables, functions, and methods.
    - Use kebab-case for file and directory names.
    - Use UPPERCASE for environment variables.
    - Avoid magic numbers and define constants.
    - Start each function with a verb.
    - Use verbs for boolean variables. Example: isLoading, hasError, canDelete, etc.
    - Use complete words instead of abbreviations and correct spelling.
    - Except for standard abbreviations like API, URL, etc.
    - Except for well-known abbreviations:
        - i, j for loops
        - err for errors
        - ctx for contexts
        - req, res, next for middleware function parameters.
        
    ### Functions
    - Write short functions with a single purpose. Less than 20 instructions.
    - Name functions with a verb and something else.
    - If it returns a boolean, use isX or hasX, canX, etc.
    - If it doesn't return anything, use executeX or saveX, etc.
    - Avoid nesting blocks by:
    - Early checks and returns.
    - Extraction to utility functions.
    - Use higher-order functions (map, filter, reduce, etc.) to avoid function nesting.
    - Use arrow functions for simple functions (less than 3 instructions).
    - Use named functions for non-simple functions.
    - Use default parameter values instead of checking for null or undefined.
    - Reduce function parameters using RO-RO:
    - Use an object to pass multiple parameters.
    - Use an object to return results.
    - Declare necessary types for input arguments and output.
    - Use a single level of abstraction.

    ### Optimization and Best Practices
    - Minimize the use of `'use client'`, `useEffect`, and `setState`; favor React Server Components (RSC) and Next.js SSR features.
    - Implement dynamic imports for code splitting and optimization.
    - Use responsive design with a mobile-first approach.
    - Optimize images: use WebP format, include size data, implement lazy loading.

    ### Error Handling and Validation
    - Prioritize error handling and edge cases:
      - Use early returns for error conditions.
      - Implement guard clauses to handle preconditions and invalid states early.
      - Use custom error types for consistent error handling.

    ### UI and Styling
    - Use modern UI frameworks (e.g., Tailwind CSS, Shadcn UI, Radix UI) for styling.
    - Implement consistent design and responsive patterns across platforms.

    ### State Management and Data Fetching
    - Use modern state management solutions (e.g., Zustand, TanStack React Query) to handle global state and data fetching.
    - Implement validation using Zod for schema validation.

    ### Security and Performance
    - Implement proper error handling, user input validation, and secure coding practices.
    - Follow performance optimization techniques, such as reducing load times and improving rendering efficiency.

    ### Testing and Documentation
    - Write unit tests for components using Jest and React Testing Library.
    - Provide clear and concise comments for complex logic.
    - Use JSDoc comments for functions and components to improve IDE intellisense.

    ### Methodology
    1. **System 2 Thinking**: Approach the problem with analytical rigor. Break down the requirements into smaller, manageable parts and thoroughly consider each step before implementation.
    2. **Tree of Thoughts**: Evaluate multiple possible solutions and their consequences. Use a structured approach to explore different paths and select the optimal one.
    3. **Iterative Refinement**: Before finalizing the code, consider improvements, edge cases, and optimizations. Iterate through potential enhancements to ensure the final solution is robust.

    **Process**:
    1. **Deep Dive Analysis**: Begin by conducting a thorough analysis of the task at hand, considering the technical requirements and constraints.
    2. **Planning**: Develop a clear plan that outlines the architectural structure and flow of the solution, using <PLANNING> tags if necessary.
    3. **Implementation**: Implement the solution step-by-step, ensuring that each part adheres to the specified best practices.
    4. **Review and Optimize**: Perform a review of the code, looking for areas of potential optimization and improvement.
    5. **Finalization**: Finalize the code by ensuring it meets all requirements, is secure, and is performant.
    

当前系统是mac，使用python编程，命令是python3 pip命令是pip3
当前目录下每个文件夹代表一个项目，请在项目目录下创建文件夹
每次有新的依赖，添加到requirements.txt文件中,并且创建或更新 初始化安装依赖的脚本 init.py

## Development Patterns

### Component Structure
- Use functional components with TypeScript
- Props interfaces should be prefixed with 'I'
- Export components as named exports
- Place components in feature-based folders

### State Management
- Use React Query for server state
- Use Zustand for global client state
- Prefer composition over inheritance

### File Organization
- Feature-based folder structure
- Shared components in /components
- Business logic in /hooks and /utils

You must rewrite the file according to the user's instructions

Code Style and Structure
- Write concise, technical TypeScript code with accurate examples.
- Use functional and declarative programming patterns; avoid classes.
- Prefer iteration and modularization over code duplication.
- Use descriptive variable names with auxiliary verbs (e.g., isLoading, hasError).
- Structure files: exported component, subcomponents, helpers, static content, types.

Naming Conventions
- Use lowercase with dashes for directories (e.g., components/auth-wizard).
- Favor named exports for components.

TypeScript Usage
- Use TypeScript for all code; prefer interfaces over types.
- Avoid enums; use maps instead.
- Use functional components with TypeScript interfaces.

Syntax and Formatting
- Use the "function" keyword for pure functions.
- Avoid unnecessary curly braces in conditionals; use concise syntax for simple statements.
- Use declarative JSX.

UI and Styling
- Use style modules with sass to stylize components (e.g Button.module.scss), use tailwind for global styles.
- Implement responsive design; use a mobile-first approach.
- Use framer motion and gsap for animations always try to be performant and efficient.

Performance Optimization
- Minimize 'use client', 'useEffect', and 'setState'; favor React Server Components (RSC).
- Wrap client components in Suspense with fallback.
- Use dynamic loading for non-critical components.
- Optimize images: use WebP format, include size data, implement lazy loading.

Folder Structure
- components: ui, layout, booking, etc; ui and sections have an entry point index.ts file that exports the component.
- app: (pages, api, layout, loading, not-found, etc)
- src: (assets, components, app, hooks, constants, lib, styles, types, utils, validations, etc)

Key Conventions
- Use 'nuqs' for URL search parameter state management.
- Optimize Web Vitals (LCP, CLS, FID).
- Limit 'use client':
  - Favor server components and Next.js SSR.
  - Use only for Web API access in small components.
  - Avoid for data fetching or state management.

Follow Next.js docs for Data Fetching, Rendering, and Routing.

React SOLID Principles and Best Practices
- Single Responsibility Principle (SRP):
  - Create focused components with a single purpose.
  - Extract complex logic into custom hooks (e.g., useDataFetching, useFormValidation).
  - Separate UI rendering from business logic.

- Open-Closed Principle (OCP):
  - Design components to be easily extendable without modifying existing code.
  - Use composition and higher-order components for reusability.

- Liskov Substitution Principle (LSP):
  - Ensure child components can replace parent components without breaking the application.
  - Use TypeScript to enforce proper prop types and interfaces.

- Interface Segregation Principle (ISP):
  - Create small, specific interfaces rather than large, general ones.
  - Use TypeScript to define clear prop interfaces for components.

- Dependency Inversion Principle (DIP):
  - Depend on abstractions, not concretions.
  - Use dependency injection to provide services to components.

Custom Hooks Best Practices
- Create custom hooks to encapsulate and reuse stateful logic.
- Name custom hooks with the 'use' prefix (e.g., useAuth, useCart).
- Keep hooks focused on a single concern or feature.
- Use TypeScript to define clear return types for custom hooks.

Component Structure
- Separate presentational and container components when appropriate.
- Use custom hooks to manage component logic and state.
- Keep components small and focused on a single responsibility.
- Extract reusable logic into utility functions or custom hooks.

agents:
  - reference: "./architect_agent.cursornb"
  - reference: "./devops_agent.cursornb"
  - reference: "./frontend_agent.cursornb"
  - reference: "./backend_agent.cursornb"
  - reference: "./database_agent.cursornb"
  - reference: "./testing_agent.cursornb"
  - reference: "./scrum_master_agent.cursornb"
  - reference: "./docs_agent.cursornb"

workflows:
  - reference: "./workflows.cursornb"

tech_stack:
  - reference: "./tech_stack.cursornb"

recommendations:
  - "Follow the user’s requirements carefully and to the letter."
  - "Plan development tasks in detail using pseudocode before writing actual code."
  - "Ensure the code follows best practices, DRY principles, and is bug-free."
  - "Write complete, thoroughly verified, and fully functional code with no placeholders."
  - "Use descriptive variable and function names, including handle prefixes for events."
  - "Prioritize code readability over performance."
  - "Always include required imports and name components properly."
  - "Avoid guessing if an answer is unclear—state it explicitly."

logging_instructions:
  - "All agents must maintain a log file in the './docs/agents/' directory."
  - "Logs must include progress updates, design choices, issues encountered, and resolutions."
  - "Document issues to prevent them from recurring in future development cycles."
  - "Maintain a clear list of ToDos and unresolved tasks requiring future attention."

code_guidelines:
  languages:
    - ReactJS
    - NextJS
    - JavaScript
    - TypeScript
    - TailwindCSS
    - HTML
    - CSS

  implementation_rules:
    - "Use early returns for readability."
    - "Prefer Tailwind classes for HTML styling; avoid CSS files."
    - "Use descriptive names for constants, functions, and events (prefix events with 'handle')."
    - "Implement accessibility features like tabindex, aria-labels, and keyboard events."
    - "Use TypeScript types and constants instead of functions where appropriate."

# Cursor Rules for File Renaming Strategy

## Overview
This ruleset defines the approach to renaming files in the ClaudeMetaResearch project,
focusing on enhancing cognitive understanding and traceability of research documentation.

## Naming Conventions
- Use descriptive, meaningful names that reflect document content
- Prioritize cognitive processes and meta-reflection in naming
- Maintain a consistent naming pattern across files
- Include version information when applicable
- Use hyphen-separated lowercase words

## File Naming Principles
1. Cognitive Process Emphasis
   - Highlight meta-cognitive aspects
   - Capture iterative and adaptive design approaches
   - Reflect conceptual emergence and flexibility

2. Structural Clarity
   - Provide clear indication of document purpose
   - Use prefixes that describe the primary focus

3. Version and Iteration Tracking
   - Include version numbers (e.g., `-v1`, `-v2`)
   - Use suffixes to indicate document type or focus

## Recommended Prefixes
- `prompt-engineering-`: Prompt design and refinement documents
- `meta-cognitive-`: Meta-analysis and reflective documents
- `cognitive-monitoring-`: Documents related to cognitive process monitoring
- `yaml-`: Documents focusing on YAML structure or representation
- `framework-`: Documents describing conceptual or technical frameworks

## Rationale
The renaming strategy aims to:
- Improve document discoverability
- Enhance understanding of document content at a glance
- Facilitate knowledge management
- Support recursive and meta-cognitive research approaches

## Future Improvements
- Regularly review and refine naming conventions
- Develop a comprehensive taxonomy for document naming
- Create guidelines for naming across different research domains

## Contact
For questions or suggestions about the file naming strategy,
contact the project lead or documentation team.

{
  "microservices": {
    "paths": [
      "services/*"
    ],
    "rules": {
      "api": {
        "baseUrl": "https://api.zibal.ir/v1",
        "patterns": [
          "services/api/**/*.ts"
        ]
      },
      "models": {
        "patterns": [
          "services/models/**/*.ts"
        ]
      },
      "controllers": {
        "patterns": [
          "services/controllers/**/*.ts"
        ]
      },
      "validators": {
        "patterns": [
          "services/validators/**/*.ts"
        ]
      }
    }
  },
  "shared": {
    "paths": [
      "shared/*"
    ]
  },
  "dependencies": {
    "rules": {
      "allowedDependencies": {
        "services/*": [
          "lib/*"
        ]
      },
      "forbiddenDependencies": {
        "services/*": [
          "services/*"
        ]
      }
    }
  },
  "naming": {
    "services": "^[a-z]+(-service)?$",
    "controllers": "^[A-Z][a-zA-Z]+Controller$",
    "models": "^[A-Z][a-zA-Z]+$"
  }
} 

# 项目架构
- 分层架构: 
  gw(网关) -> module(业务模块) -> core(核心逻辑) -> model(数据模型)
  - gw: 处理HTTP请求,路由分发 (src/gw/gw.go, src/gw/routes.go)
  - module: 实现具体业务逻辑 (src/module/*)
  - core: 提供核心服务和通用逻辑 (src/core/*)
  - model: 定义数据结构和数据库操作 (src/model/*)
- 依赖注入: 
  通过构造函数或Init方法实现,避免全局状态
  例: src/core/init.go中的Init函数初始化核心服务
- 缓存策略: 
  使用Redis作为缓存,通过cachekey管理键
  例: src/model/book.go中使用CKBook定义和管理缓存键
- 异步处理: 
  使用redismq进行异步任务处理(如标签更新)
  实现: pkg/tags/async_updater.go和pkg/tags/redismq.go

# 项目结构
src/
  core/ # 核心业务逻辑
    analytics/ # 分析相关逻辑
    handlers.go # API请求处理器
    init.go # 初始化逻辑
    interfaces/ # 接口定义
    model/ # 数据模型
    reminder/ # 提醒服务
    review/ # 复习逻辑
  def/ # 常量和枚举定义
  gw/ # 网关和路由
    event.go # 事件处理
    gw.go # 网关主逻辑
    routes.go # 路由定义
    shorturl.go # 短URL服务
  model/ # 数据模型定义
    book.go # 书籍模型
    dungeon.go # 地牢模型
    item.go # 物品模型
  module/ # 功能模块
    achievement/ # 成就系统
    analytic/ # 数据分析
    book/ # 书籍管理
    campaign/ # 活动管理
    dungeon/ # 地牢(复习)系统
    item/ # 物品管理
    nft/ # NFT相关
    operation/ # 运营管理
    profile/ # 用户档案
    system/ # 系统管理
    tag/ # 标签管理
pkg/ # 特殊功能包
  tags/ # 标签相关功能
    async_updater.go # 异步更新器
    redismq.go # Redis消息队列
    service.go # 标签服务
    types.go # 类型定义

# 规范
- 文件名小写,下划线连接 (例: gw/short_url.go)
- 结构体、接口、函数驼峰命名 (例: type UserProfile struct{}, func GetUserByID())
- 常量全大写,下划线连接 (例: const MAX_RETRY_COUNT = 3)
- 包级注释,导出项注释,复杂逻辑内联注释 (例: 见 pkg/tags/service.go)
- 使用github.com/khicago/irr包装错误 (例: return irr.Wrap(err, "failed to create user"))
- 使用github.com/bagaking/goulp/wlog记录日志 (例: wlog.ByCtx(ctx, "CreateUser").Info("User created successfully"))
- GORM操作数据库,模型在model/目录 (例: 见 src/model/book.go)
- github.com/khgame/memstore/cachekey管理缓存键 (例: 见 src/model/book.go 中的 CKBook)
- gw/routes.go定义路由,使用中间件认证 (例: 见 src/gw/routes.go)
- 环境变量管理配置,不硬编码敏感信息 (例: os.Getenv("DATABASE_URL"))
- 构造函数或Init函数依赖注入 (例: 见 src/core/init.go)
- 测试文件xxx_test.go,使用表驱动测试 (例: 见 pkg/tags/tags_test.go)
- 语义化版本控制 (例: v1.2.3)
- Swagger注解生成API文档 (例: 见 src/gw/routes.go 中的路由定义)

# 特殊说明
- pkg/tags: 使用redismq实现异步标签更新,提高系统响应速度和可靠性

FAIS UNE SEULE ETAPE A LA FOIS ET DEMANDE MOI AVANT DE PASSER A LA SUIVANTE



Il reste à corriger quelques erreurs de linter :
Dans ReadingService :
Types manquants de l'API Obsidian (TFile, WorkspaceLeaf)
Propriétés manquantes sur App (workspace, vault.getFiles)
Dans OpmlService :
Dépendance manquante fast-xml-parser
Type implicite dans les tests
Je suggère d'ajouter aussi deux nouveaux services pour compléter l'architecture :
1. LogService pour la gestion centralisée des logs :
Niveaux de log (debug, info, warn, error)
Formatage des messages
Rotation des logs
Intégration avec la console Obsidian
SettingsService pour la gestion de l'interface de configuration :
Interface de configuration du plugin
Validation des paramètres
Sauvegarde/chargement des préférences
Gestion des thèmes

J'ai créé un système complet de gestion des erreurs et de journalisation avec :
Types d'erreurs spécifiques :
RSSError pour les erreurs de flux RSS
SyncError pour les erreurs de synchronisation
StorageError pour les erreurs de stockage
OpmlError pour les erreurs OPML
Codes d'erreur détaillés pour chaque type
Type Guards pour identifier les types d'erreurs
Service de journalisation (LogService) avec :
Différents niveaux de log (DEBUG, INFO, WARN, ERROR)
Notifications Obsidian intégrées
Gestion de la rotation des logs
Formatage détaillé des erreurs
Export des logs
Tests complets pour :
Les types d'erreurs et leurs propriétés
Les Type Guards
Les méthodes de journalisation
La gestion des logs
Le formatage des erreurs


 différence principale entre les tests d'erreurs et les logs est :
Tests d'erreurs (errors.test.ts) :
Teste la structure et le comportement des types d'erreurs
Vérifie que les Type Guards fonctionnent correctement
S'assure que les erreurs ont les bonnes propriétés
Valide les codes d'erreur
Teste la création des erreurs
Tests de logs (LogService.test.ts) :
Teste le système de journalisation
Vérifie les différents niveaux de log (DEBUG, INFO, WARN, ERROR)
Teste l'intégration avec les notifications Obsidian
Vérifie la gestion de la rotation des logs
Teste le formatage et l'export des logs

## Service de Traduction (i18n)
   Détecte automatiquement la langue de l'utilisateur
   Gère les traductions avec une méthode t()
   Supporte les paramètres dans les traductions
   Utilise l'anglais comme fallback
   Des fichiers de traduction séparés :
   fr.ts pour le français
   en.ts pour l'anglais
   Structure identique pour faciliter la maintenance
   Intégration dans le plugin principal :
   Initialisation du service au démarrage
   Méthode utilitaire t() pour un accès facile aux traductions
   Utilisation dans les commandes et messages
-
## Gestion des traductions FR/EN
   Méthode de traduction t()
-
## Service de Gestion des Feeds
   Récupération des flux
   Méthode fetchFeed() pour récupérer et parser un flux
   Gestion des en-têtes HTTP appropriés
   Détection automatique du type de flux (RSS ou Atom)
   Parsing des flux Atom
   Méthode parseAtomFeed() pour le flux principal
   Méthode parseAtomEntry() pour les articles
   Gestion des liens alternatifs
   Support du contenu et du résumé
   Parsing des flux RSS
   Méthode parseRssFeed() pour le flux principal
   Méthode parseRSSItem() pour les articles
   Gestion des GUIDs et des liens
   Gestion des erreurs
   Vérification des erreurs de parsing XML
   Logging des erreurs
   Messages d'erreur détaillés
Types TypeScript
   Interface RSSFeed pour la structure du flux
   Interface RSSItem pour les articles
   Interface FeedSettings pour la configuration
   Interface FeedData pour les métadonnées
   réé une suite de tests complète pour le RSSService qui couvre les cas suivants :
Tests de base
   Parsing d'un flux RSS standard
   Parsing d'un flux Atom standard
   Vérification des champs obligatoires
   Tests d'erreurs
   Gestion des erreurs de parsing XML
   Gestion des erreurs HTTP
   Gestion des réponses invalides
   Tests de cas particuliers
   Flux sans articles
   Articles avec champs manquants
   Valeurs par défaut
   Mocking
   Mock de la fonction requestUrl d'Obsidian
   Simulation de différentes réponses HTTP
   Simulation d'erreurs réseau
-
## Service de Gestion des Fichiers
   ensureFolder()
   removeFolder()
   cleanOldArticles()

### Gestion des dossiers
   ensureFolder() : Crée un dossier s'il n'existe pas
   removeFolder() : Supprime un dossier et son contenu récursivement
   fileExists() : Vérifie l'existence d'un fichier

### Gestion des articles
   saveArticle() : Sauvegarde un article en Markdown avec template
   cleanOldArticles() : Nettoie les articles selon la période de rétention
   sanitizeFileName() : Nettoie les noms de fichiers

### Gestion des erreurs
   Logging détaillé des erreurs
   Propagation des erreurs avec messages explicites
   Vérifications de sécurité

### Tests pour FileService
   Tests de ensureFolder
   Création d'un nouveau dossier
   Gestion des dossiers existants
   Propagation des erreurs
   Tests de removeFolder
   Suppression récursive des dossiers et fichiers
   Gestion des dossiers inexistants
   Vérification des appels aux méthodes de l'API
   Tests de cleanOldArticles
   Suppression des articles selon la période de rétention
   Filtrage des fichiers par dossier
   Gestion des dates
   Tests de saveArticle
   Création de nouveaux fichiers
   Mise à jour des fichiers existants
   Remplacement des variables dans le template
   Tests de sanitizeFileName
   Remplacement des caractères invalides
   Gestion des espaces et tirets
   Nettoyage des noms de fichiers

-
## ReadingService
### Navigation dans les articles
   navigateArticles() : Navigation suivant/précédent
   navigateToArticle() : Navigation directe
   markCurrentArticleAsRead() : Marque comme lu
### Gestion de l'état
   Interface ReadingState pour le suivi
   Méthode getState() pour l'état actuel
   Persistance du dernier article lu
   Interface utilisateur
   Styles CSS personnalisés
   Mode plein écran
   Boutons de navigation
   Mise en page optimisée pour la lecture
   Utilitaires
###Gestion des onglets Obsidian
   Filtrage des fichiers d'articles
   Manipulation du DOM
Tests de enterReadingMode
Activation du mode lecture
Gestion de la double activation
Chargement du dernier article lu
### Tests de navigateArticles
   Navigation vers l'article suivant
   Navigation vers l'article précédent
   Gestion des limites (début/fin)
   Tests de markCurrentArticleAsRead
   Marquage d'un article comme lu
   Gestion des cas sans article actif
   Vérification du contenu modifié
   Tests de navigateToArticle
   Navigation directe vers un article
   Gestion des articles inexistants
   Mise à jour de l'état
   Les tests utilisent :
   Mocks complets de l'API Obsidian
   Mocks du DOM pour les styles
   Assertions détaillées
   Cas d'erreur et cas limites

-
## StorageService
   Une interface StorageData bien définie
   Des méthodes pour charger et sauvegarder les données
   Une initialisation des valeurs par défaut
### Tests complets couvrant :
   L'initialisation avec des valeurs par défaut
   La fusion avec des données existantes
   La sauvegarde des données

-
## Service d'Import/Export
   Import de fichiers OPML avec gestion des catégories
   Export des flux au format OPML
   Gestion des flux en double lors de l'import
   Support des structures OPML imbriquées
### Tests :
   Import de fichiers OPML valides
   Gestion des flux existants
   Gestion des erreurs de parsing XML
   Export au format OPML
   Vérification du contenu exporté
   Gestion des erreurs d'export

## SchedulerService :
   Gestion des intervalles de temps
   Tests de démarrage/arrêt des planificateurs
   Tests de remplacement des planificateurs existants
### SyncService :
   Gestion des flux RSS
   Filtrage des articles en double
   Respect des limites d'articles
   Gestion des erreurs
   Tests de création de fichiers




En fait, Vite et esbuild ont des rôles différents dans notre projet :
Vite (via Vitest) est utilisé pour les tests :
esbuild est utilisé pour le build de production car :
Il est recommandé par Obsidian pour les plugins
Il est plus léger et plus rapide pour bundler un seul fichier
Il gère bien les spécificités d'Obsidian (externals, format cjs)
Il est configuré pour exclure les dépendances d'Obsidian qui sont déjà présentes dans l'app
On pourrait techniquement utiliser Vite pour le build aussi, mais il faudrait :
1. Configurer Vite pour qu'il produise un bundle compatible avec Obsidian
Gérer les externals d'Obsidian
S'assurer que le format de sortie est correct
Potentiellement gérer des problèmes de compatibilité
La configuration actuelle avec esbuild est plus simple et suit les recommandations d'Obsidian pour le développement de plugins. C'est un peu comme utiliser webpack pour un plugin VSCode - c'est la solution recommandée qui fonctionne bien pour ce cas d'usage spécifique.
Veux-tu quand même qu'on essaie de configurer Vite pour le build ? Ou on garde esbuild qui est plus simple et éprouvé pour les plugins Obsidian ?