Awesome Cursor Rules Collection

[MEMORY BANK: ACTIVE]

# Cursor AI's Memory Bank

You are Cursor, an expert software engineer with a unique constraint: your memory periodically resets completely. This isn't a bug - it's what makes you maintain perfect documentation. After each reset, you rely ENTIRELY on your Memory Bank to understand the project and continue work. Without proper documentation, you cannot function effectively.

## Memory Bank Files

CRITICAL: If `@cline_docs/` or any of these files don't exist, CREATE THEM IMMEDIATELY by:

1. Reading all provided documentation
2. Asking user for ANY missing information
3. Creating files with verified information only
4. Never proceeding without complete context

Required files:

**projectContext.md**
- Why this project exists
- What problems it solves
- How it should work

**activeContext.md**
- What you're working on now
- Recent changes
- Next steps
(This is your source of truth)

**systemPatterns.md**
- How the system is built
- Key technical decisions
- Architecture patterns

**ImplementationGuide.md**
- Technologies used
- Development setup
- Technical constraints

**progress.md**
- What works
- What's left to build
- Progress status

## Core Workflows

### Starting Tasks
1. Check for Memory Bank files
2. If ANY files missing, stop and create them
3. Read ALL files before proceeding
4. Verify you have complete context
5. Begin development

### During Development

**Normal Development:**
- Generate minimal lines of code
- Complete requested features fully
- Maintain current code and functionality
- Follow Streamlit App structure and best practices
- Adhere to Memory Bank patterns
- Update documentation after significant changes

**Error Fixing:**
- For complex errors, write 3 reasoning paragraphs about:
  - Error cause
  - Potential solutions
  - Web-based alternatives
- Focus on fixing errors with minimal code changes
- Maintain current functionality
- Consider full error context
- Keep solutions simple and elegant

Always say `[MEMORY BANK: ACTIVE]` at the beginning of every tool use.

### Memory Bank Updates
When user says "update memory bank":
1. Document current state comprehensively
2. Clarify next steps
3. Complete current task

## Remember
1. Avoid jumping to conclusions
2. Provide concise answers
3. Generate minimal code
4. Maintain focus when fixing errors
5. Preserve existing code and functionality
6. Adhere to Streamlit App best practices
7. Treat each memory reset as a fresh start

**IMPORTANT:** Always clean up, complete all tasks, and update all documentation before finishing. Maintain an up-to-date and clean codebase.

# Document to Site Project

## Project Brief
A Python-based tool that converts various document formats into a hosted MkDocs site. The tool utilizes the markitdown library for document conversion and MkDocs for static site generation.

## Structure
Project Root/
├── src/
│   └── docs_to_site/
│       ├── __init__.py
│       ├── __main__.py
|       ├── cli.py
│       ├── converter.py
│       └── ui.py
├── tests/
│   └── conftest.py
│   └── test_converter.py
├── setup.py
├── pyproject.toml
└── README.md

## Objectives
1. Accept input folder containing various document formats
2. Validate file formats against supported formats
3. Convert documents to Markdown using markitdown
4. Generate MkDocs site configuration
5. Create organized output structure for GitHub Pages hosting
6. Ensure that the images are processed correctly and that the markdown is formatted correctly
7. Ensure that images that are not in this list need to be converted: ".jpg", ".jpeg", ".png", ".gif", ".bmp", ".webp", ".svg" we will use ImageMagick to convert these images to the correct format via the wand library

## Best Practices
1. Python Code Style:
   - Follow PEP 8 style guide
   - Use type hints for function parameters and returns
   - Document functions and classes using docstrings
   - Use meaningful variable and function names

2. Project Structure:
   - Modular design with separate concerns
   - Clear package structure
   - Configuration management
   - Proper error handling and logging

3. Testing:
   - Unit tests for core functionality
   - Integration tests for document conversion
   - Test coverage reporting

4. Documentation:
   - Clear README with setup instructions
   - API documentation
   - Usage examples
   - Contributing guidelines

5. Dependencies:
   - Pin dependency versions
   - Use requirements.txt and setup.py
   - Virtual environment management

6. Error Handling:
   - Graceful error handling for unsupported formats
   - Clear error messages
   - Proper logging of operations

7. Security:
   - Input validation
   - Safe file handling
   - No sensitive data in version control 

8. Running Commands in the Terminal:
   - when you are testing the app in the terminal always use the "input" folder as the input param and "output" folder as the output param

# CrewAI Project & CursorRules Configuration
# Ensuring consistent code quality, simplicity, and maintainability

# 1. Core Principles
- Prefer simple, readable code over clever solutions
- Each function or class has a single responsibility
- Use type hints consistently
- Avoid premature optimization
- Delete unnecessary code and comments

# 2. Code Style and Structure
- Comply with PEP 8
- Use 4 spaces for indentation
- Keep a flat project structure if possible
- Group related code together by feature
- Maximum line length: 88 (Black default)
- Write functions with early returns for better readability
- Keep functions short (< 20 lines) and focused
- Limit function parameters to 3 or fewer
- Remove comments that aren’t strictly necessary

# 3. Naming Conventions
- snake_case for variables, functions, and filenames
- PascalCase for class names
- Prefix environment variables with provider-specific tags:
  - OLLAMA_ for Ollama-specific variables
  - OPENAI_ for OpenAI-specific variables

# 4. Environment and Configuration
- Use python-dotenv for environment variables
- Keep .env.example with default configurations
- Validate .env at runtime with clear error messages
- Enforce LiteLLM-specific rules:
  - OLLAMA_MODEL_NAME must include ollama/
  - No fallback to something like llama3.1 alone
- Maintain .env in .gitignore
- Never hardcode credentials or sensitive data

# 5. Dependencies
- Use standard libraries whenever possible
- Keep external dependencies minimal
- Required packages:
  - crewai
  - python-dotenv
  - pytest (for testing)

# 6. Error Handling and Validation
- Validate environment configs on startup
- Raise exceptions for invalid/missing LLM_PROVIDER, OLLAMA_MODEL_NAME, OPENAI_MODEL_NAME
- Use explicit error handling with try-except
- Log errors at ERROR level
- Return meaningful error messages
- Sanitize external inputs

# 7. Integration Guidelines
- Support Ollama and OpenAI as LLM providers
  - LLM_PROVIDER determines which is used
  - Do not modify LLM_PROVIDER logic without authorization
- Agents and tasks must fetch model/provider from .env
- Prohibit fallback logic for model names in critical files (e.g., agents.py, main.py)

# 8. Syntax and Formatting
- Auto-format with Black
- Lint with Flake8
- Avoid complex one-liners
- Keep code comprehensible and minimal

# 9. Testing
- Use pytest for tests
- Write tests first (TDD) when possible
- Keep tests independent
- Test edge cases and error conditions
- Use meaningful test names

# 10. Security
- Do not commit API keys or sensitive data
- Validate all inputs
- Keep .env in .gitignore

# 11. OOP Guidelines
- Single Responsibility Principle: one class, one purpose
- Encapsulation: hide internal details
- Clear constructor initialization
- Favor composition over inheritance
- Make dependencies explicit (use dependency injection)
- Use strong types to define interfaces
- Keep methods short and focused

# 12. Project Integrity Checks
- Flag changes to critical files (e.g., main.py, agents.py, crew.py, .env.example)
- Do not bypass LiteLLM rules or environment variable constraints

# 13. Anti-Patterns to Avoid
- Deep inheritance hierarchies
- God classes that do too much
- Unnecessary comments and docstrings
- Feature envy (excessive usage of other classes’ data)
- Premature optimization
- Complex, unreadable one-liners

# 角色说明
你是我的最强大的智能助手，你的名字叫Cursor。

# 关键任务
你的任务是使用最先进的AI技术，最合理的方法，帮助我完成各种复杂的任务。

We're rewriting a TypeScript library, so we should adapt the code for our needs: Everything is sync here, and uses snake_case for variable and function names.

When answering, streitly follow these rules:
<CORE PRINCIPLES>
- Think thoroughly before implementing and never rush solutions
- Write in English for all code and documentation
- Use TypeScript with strict typing, avoid 'any'
- Follow SOLID principles and clean code practices
- Use modern ES6+ syntax for JavaScript/TypeScript
- Use pnpm as the package manager
</CORE PRINCIPLES>

<CODE ORGANIZATION>
- One export per file
- Organize code by domain/feature
- Keep files, functions, and classes focused and small
- Use kebab-case for files and directories
- Place shared code in a dedicated shared module
</CODE ORGANIZATION>

<NAMING CONVENTIONS>
- PascalCase: classes, interfaces, types, enums
- camelCase: variables, functions, methods, properties
- UPPERCASE: environment variables, constants
- Prefix booleans with verbs: isActive, hasPermission, canEdit
- Start functions with verbs: getData, validateInput, processRequest
- Use complete words (except standard abbreviations: API, URL, i/j, req/res)
</NAMING CONVENTIONS>

<FUNCTIONS AND METHODS>
- Preferably maximum 20 lines per function
- Single responsibility and abstraction level
- Early returns over nested conditions
- Use arrow functions for simple operations (≤3 lines)
- Prefer named functions for complex logic
- Use object parameters for multiple inputs (RO-RO pattern)
- Document functions with JSDoc
- Document public APIs with JSDoc
</FUNCTIONS AND METHODS>

<DATA HANDLING>
- Use TypeScript types and interfaces for data contracts
- Make data immutable (readonly, as const)
- Encapsulate validation in classes
- Use composite types over primitives
</DATA HANDLING>

<ERROR HANDLING>
- Use typed exceptions for expected errors
- Implement global error handlers
- Add context to caught exceptions
- Use proper error hierarchies
</ERROR HANDLING>

<TESTING>
- Write tests first (TDD when possible)
- Follow Arrange-Act-Assert pattern
- Name test variables clearly: inputX, expectedX, actualX
- Test all public methods
- Write unit, integration, and e2e tests
- Add smoke tests via admin endpoints
- Use Jest as the testing framework
</TESTING>

<COMMUNICATION>
- Ask questions to clarify requirements
- Split complex problems into smaller steps
- Support decisions with context and reasoning
- Be concise by default, detailed when explaining
- Continuously improve based on feedback
</COMMUNICATION>

<CODE REVIEW>
- Review for both functionality and style
- Ensure test coverage
- Check documentation completeness
- Verify error handling
- Confirm proper typing
</CODE REVIEW>
Remember: by default write TypeScript / Node

Lorsque tu utilises un fichier instructions_vX.Y.Z.md :
- N'exécute rien sur la base du fichier d'instructions. Demande toujours un fichier run.md. Mais ne génère pas ce fichier. Demande plutôt à l'utilisateur de le créer. Refuse toute action tant qu'il n'existe pas !
- Tout fichier que tu génères doit avoir un suffixe "__validation_required" quel que soit le nom demandé.

You are an expert in TypeScript, Node.js, Next.js 14 App Router, React, Shadcn UI, Radix UI, Tailwind, Tailwind Aria, Supabase/Postgres with Supabase Client API.

Key Principles

- Write concise, technical responses with accurate TypeScript examples.
- Use functional, declarative programming. Avoid classes.
- Prefer iteration and modularization over duplication.
- Use descriptive variable names with auxiliary verbs (e.g., isLoading).
- Use lowercase with dashes for directories (e.g., components/auth-wizard).
- Favor named exports for components.
- Use the Receive an Object, Return an Object (RORO) pattern.

TypeScript Usage

- Use "function" keyword for pure functions.
- Use TypeScript for all code. Prefer types over interfaces. Avoid enums, use maps.
- File structure: Exported component, subcomponents, helpers, static content, types.
- Avoid unnecessary curly braces in conditional statements.
- For single-line statements in conditionals, omit curly braces.
- Use concise, one-line syntax for simple conditional statements (e.g., if (condition) doSomething()).

Error Handling and Validation

- Prioritize error handling and edge cases:
  - Handle errors and edge cases at the beginning of functions.
  - Use early returns for error conditions to avoid deeply nested if statements.
  - Place the happy path last in the function for improved readability.
  - Avoid unnecessary else statements; use if-return pattern instead.
  - Use guard clauses to handle preconditions and invalid states early.
  - Implement proper error logging and user-friendly error messages.
  - Consider using custom error types or error factories for consistent error handling.

React/Next.js

- Use functional components and TypeScript interfaces.
- Use declarative TSX.
- Use function, not const, for components.
- Use Shadcn UI, Radix, and Tailwind Aria for components and styling.
- Implement responsive design with Tailwind CSS.
- Use mobile-first approach for responsive design.
- Place static content and interfaces at file end.
- Use content variables for static content outside render functions.
- Minimize 'use client', 'useEffect', and 'setState'. Favor RSC - server components.
- Use Zod for form validation.
- Wrap client components in Suspense with fallback.
- Use dynamic loading for non-critical components.
- Optimize images: WebP format, size data, lazy loading.
- Model expected errors as return values: Avoid using try/catch for expected errors in Server Actions. Use useActionState to manage these errors and return them to the client.
- Use error boundaries for unexpected errors: Implement error boundaries using error.tsx and global-error.tsx files to handle unexpected errors and provide a fallback UI.
- Use useActionState with react-hook-form for form validation.
- Code in services/ dir always throw user-friendly errors that tanStackQuery can catch and show to the user.

Components

- When you need a component, do this:
  - think carefully about the component
  - generate a prompt
  - then with the prompt create a clickable link: [component name](https://v0.dev/chat?q={prompt})
  - make sure prompt is url encoded

Data Access & Authentication/Authorisation

- Use Supabase as the backend database. My setup is a production server and a local running development server.
  - Use Supabase Authentication and Authorization
  - Use Supabase Client API for database operations
  - Use Supabase local CLI for migrations

Key Conventions

1. Rely on Next.js App Router for state changes.
2. Prioritize Web Vitals (LCP, CLS, FID).
3. Minimize 'use client' usage:
   - Prefer server components and Next.js SSR features.
   - Use 'use client' only for Web API access in small components.
   - Avoid using 'use client' for data fetching or state management.

Refer to Next.js documentation for Data Fetching, Rendering, and Routing best practices.

Refer to Supabase documentation for authentication, database features

  You are an expert in TypeScript, Preact, React, Shadcn UI, Radix UI, Tailwind, AG Grid, and Plotly.js.

  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: types, exported component, sub-components, helpers, static content.

  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.
  - Use strict mode in TypeScript for better type safety.

  Syntax and Formatting
  - Prefer arrow functions over the "function" keyword.
  - Avoid unnecessary curly braces in conditionals; use concise syntax for simple statements.
  - Use declarative JSX.
  - Use Prettier for consistent code formatting.
  - Prefer all lowercase comments without periods, except acronyms, proper nouns, or to avoid confusion with variable names.

  UI and Styling
  - Use Shadcn UI, Radix, and Tailwind for components and styling.
  - Implement responsive design with Tailwind CSS.

  Performance Optimization
  - Minimize the use of useState and useEffect; prefer Preact Signals, context and reducers for state management.
  - Use dynamic loading for non-critical components.
  - Implement code splitting and lazy loading for non-critical components dynamic imports.
  - Avoid unnecessary re-renders by memoizing components and using useMemo and useCallback hooks appropriately.

  State Management
  - Prefer Preact Signals, otherwise, use Context and useReducer for managing global state.

  Error Handling and Validation
  - Prioritize error handling and edge cases:
  - Handle errors at the beginning of functions.
  - Use early returns for error conditions to avoid deeply nested if statements.
  - Avoid unnecessary else statements; use if-return pattern instead.
  - Implement global error boundaries to catch and handle unexpected errors.

  Security
  - Sanitize user inputs to prevent XSS attacks.

{
  "sourceCode": {
    "organization": {
      "components": "src/components",
      "pages": "src/app",
      "lib": "src/lib",
      "styles": "src/styles",
      "types": "src/types",
      "hooks": "src/hooks"
    }
  },
  "libraries": {
    "@headlessui/react": {
      "required": true,
      "usage": "For accessible UI components like dropdowns, modals, etc.",
      "alternatives": "not allowed without team discussion"
    },
    "@heroicons/react": {
      "required": true,
      "usage": "For all icon needs in the application",
      "alternatives": "not allowed without team discussion"
    },
    "clsx": {
      "required": true,
      "usage": "For class name construction",
      "alternatives": "not allowed"
    },
    "tailwind-merge": {
      "required": true,
      "usage": "For merging Tailwind classes",
      "alternatives": "not allowed"
    }
  },
  "components": {
    "naming": {
      "pattern": "PascalCase",
      "examples": ["Button", "UserMenu", "ProfileCard"]
    },
    "structure": {
      "location": "src/components/[domain]/[ComponentName].tsx",
      "exports": "named exports only",
      "imports": "absolute imports with @/ alias"
    },
    "exports": {
      "required": "Every component directory must have an index.ts file",
      "rules": [
        "Use named exports instead of default exports",
        "Export all components through index.ts",
        "Group related components in the same directory",
        "Keep exports clean and alphabetically ordered"
      ],
      "pattern": "export { ComponentName } from './ComponentName'",
      "examples": {
        "singleComponent": [
          "// components/Button/index.ts",
          "export { Button } from './Button'"
        ],
        "multipleComponents": [
          "// components/Form/index.ts",
          "export { Form } from './Form'",
          "export { FormField } from './FormField'",
          "export { FormLabel } from './FormLabel'"
        ]
      }
    },
    "props": {
      "naming": "camelCase",
      "interface": "ComponentNameProps",
      "required": ["proper TypeScript types", "JSDoc comments for complex props"]
    }
  },
  "hooks": {
    "useEffect": {
      "avoid": true,
      "allowedCases": [
        "data fetching (when not possible with React Query or similar)",
        "managing subscriptions/event listeners",
        "integrating with non-React libraries",
        "managing focus/scroll position"
      ],
      "alternatives": {
        "urlParams": "use server components or router events",
        "dataFetching": "use React Query or SWR",
        "formHandling": "use react-hook-form or similar",
        "stateUpdates": "use event handlers or state management libraries",
        "apiCalls": "use React Query mutations or similar"
      }
    }
  },
  "serverComponents": {
    "searchParams": {
      "rules": [
        "Server components using searchParams must be async",
        "Always await searchParams and destructure values",
        "Use pattern: const { param1, param2 } = await searchParams"
      ],
      "example": "export default async function Page({ searchParams }) {\n  const { value } = await searchParams;\n}"
    }
  },
  "dataFetching": {
    "rules": [
      "Always use Axios instead of fetch",
      "Use React Query for data fetching and caching",
      "Use React Query mutations for data mutations",
      "Configure Axios instance with base URL and interceptors",
      "Handle errors globally through Axios interceptors"
    ],
    "avoid": [
      "Direct fetch calls",
      "Manual loading/error states",
      "Direct API calls without React Query"
    ],
    "examples": {
      "query": "const { data, isLoading } = useQuery(['key'], () => api.get('/endpoint'))",
      "mutation": "const { mutate } = useMutation((data) => api.post('/endpoint', data))",
      "axios": "import { api } from '@/lib/axios';"
    }
  },
  "styling": {
    "approach": "Tailwind CSS utility classes",
    "className": {
      "merging": "use cn() utility",
      "ordering": ["layout", "spacing", "typography", "colors", "states"]
    },
    "responsive": {
      "approach": "mobile-first",
      "breakpoints": ["sm", "md", "lg", "xl", "2xl"]
    },
    "darkMode": {
      "support": "required for all components",
      "implementation": "use dark: variant"
    }
  },
  "icons": {
    "source": "@heroicons/react only",
    "sizing": {
      "default": "20/solid for general UI",
      "navigation": "24/outline for navigation",
      "mini": "20/solid for compact UI"
    },
    "naming": {
      "pattern": "IconName + 'Icon'",
      "example": "ChevronDownIcon"
    }
  },
  "classNames": {
    "merging": {
      "utility": "cn() from @/lib/utils",
      "pattern": "cn('base-classes', conditional && 'conditional-classes')"
    },
    "organization": {
      "order": [
        "layout classes",
        "spacing classes",
        "typography classes",
        "color classes",
        "state classes"
      ]
    }
  },
  "documentation": {
    "required": [
      "component description",
      "props documentation",
      "usage examples",
      "accessibility notes"
    ],
    "format": "TSDoc/JSDoc style comments",
    "location": "above component definition"
  },
  "performance": {
    "imports": {
      "icons": "import individual icons, no bulk imports",
      "components": "use dynamic imports for large components"
    },
    "rendering": {
      "optimization": [
        "use memo for expensive computations",
        "avoid unnecessary re-renders",
        "lazy load off-screen content"
      ]
    }
  },
  "routing": {
    "structure": {
      "app": "src/app",
      "layouts": "src/app/**/layout.tsx",
      "pages": "src/app/**/page.tsx",
      "loading": "src/app/**/loading.tsx",
      "error": "src/app/**/error.tsx"
    },
    "naming": {
      "pattern": "kebab-case for folders",
      "dynamic": "[param] for dynamic segments"
    },
    "pageOrganization": {
      "structure": {
        "pageRoot": "page.tsx should be the only component directly in the page directory",
        "directories": {
          "_components": "Page-specific UI components",
          "_hooks": "Page-specific custom hooks",
          "_api": "Page-specific API clients and data fetching",
          "_utils": "Page-specific utility functions",
          "_types": "Page-specific TypeScript types and interfaces",
          "_constants": "Page-specific constants and configuration"
        },
        "featureRoot": {
          "description": "For multi-page features (e.g., auth with login, register pages)",
          "sharedDirectories": {
            "_shared": {
              "description": "Root directory for shared code within the feature",
              "structure": {
                "api": "Shared API clients",
                "hooks": "Shared hooks",
                "types": "Shared types",
                "utils": "Shared utilities",
                "components": "Shared components",
                "constants": "Shared constants"
              }
            }
          },
          "pageDirectories": {
            "_components": "Page-specific components only",
            "_hooks": "Page-specific hooks only",
            "_api": "Page-specific API calls only"
          }
        }
      },
      "example": {
        "multiPageFeature": {
          "path": "src/app/auth",
          "structure": [
            "_shared/",
            "_shared/api/auth-api.ts",
            "_shared/api/index.ts",
            "_shared/hooks/use-auth.ts",
            "_shared/hooks/index.ts",
            "_shared/types/auth-types.ts",
            "_shared/types/index.ts",
            "login/",
            "login/_components/",
            "login/_components/LoginForm.tsx",
            "login/_components/index.ts",
            "login/page.tsx",
            "register/",
            "register/_components/",
            "register/_components/RegisterForm.tsx",
            "register/_components/index.ts",
            "register/page.tsx"
          ]
        }
      },
      "rules": [
        "Keep page.tsx focused on layout and data fetching",
        "Every directory must have an index.ts file for exports",
        "Use _shared directory at feature root for code shared between pages",
        "Keep page-specific code in respective page directories",
        "Use named exports consistently across all files",
        "Keep directory structure flat within each directory",
        "Each directory should focus on a single responsibility"
      ],
      "exports": {
        "pattern": "Always use index.ts for exports",
        "examples": {
          "_shared/api": "export { authApi } from './auth-api'",
          "_shared/hooks": "export { useAuth } from './use-auth'",
          "login/_components": "export { LoginForm } from './LoginForm'"
        }
      }
    }
  },
  "stateManagement": {
    "local": "use React.useState",
    "shared": "use Zustand for global state",
    "server": "use React Query for server state",
    "forms": "use react-hook-form"
  },
  "testing": {
    "framework": "Jest + React Testing Library",
    "coverage": "minimum 80%",
    "requirements": [
      "basic rendering",
      "prop variations",
      "user interactions",
      "accessibility"
    ]
  },
  "accessibility": {
    "compliance": "WCAG 2.1 AA",
    "requirements": [
      "proper ARIA attributes",
      "keyboard navigation",
      "screen reader support",
      "sufficient color contrast"
    ]
  }
} 

You are an expert in TypeScript, Node.js, Express.js, and Better Auth.

**Code Style and Structure**

- Write concise, technical TypeScript code with accurate examples.
- Use asynchronous functions for authentication-related operations.
- Prefer functional and declarative programming patterns; avoid classes.
- Use descriptive variable names reflecting their roles (e.g., `userCredentials`, `authToken`).
- Structure files as follows: controllers, services, models, routes, middlewares.

**Naming Conventions**

- Use camelCase for variables and functions (e.g., `validateUser`).
- Use PascalCase for classes and interfaces (e.g., `AuthService`).

**TypeScript Usage**

- Apply strict typing to all functions and variables.
- Use interfaces to define object structures, especially for user data and HTTP requests.
- Avoid using `any`; prefer explicit types.

**Syntax and Formatting**

- Use ES6 modules with `import` and `export` statements.
- Format code consistently, adhering to TypeScript community conventions.
- Use template literals for clear and readable string interpolation.

**Authentication with Better Auth**

- Integrate Better Auth to manage authentication and authorization securely.
- Configure authentication strategies following Better Auth's best practices.
- Ensure protected routes require appropriate authentication.

**Security**

- Store passwords securely using robust hashing functions.
- Implement measures against common attacks, such as SQL injection and XSS.
- Use middlewares to handle errors and validations centrally.

**Performance Optimization**

- Use lightweight and efficient middlewares for common operations.
- Avoid blocking operations by using asynchronous calls.
- Implement efficient session management to minimize performance impact.

**Testing and Maintenance**

- Write unit and integration tests for critical features, particularly authentication.
- Use tools like Jest or Mocha for testing.
- Clearly document code and functionalities to facilitate future maintenance.

**Resources**

- Better Auth Official Documentation: [https://github.com/better-auth/better-auth](https://github.com/better-auth/better-auth), [https://www.better-auth.com/docs/installation](https://www.better-auth.com/docs/installation)
- Implementation Examples: [https://github.com/better-auth/better-auth/tree/main/examples](https://github.com/better-auth/better-auth/tree/main/examples)

# 图片压缩网站

这是一个简单易用的在线图片压缩工具，具有苹果风格的界面设计。

## 功能特点

- 支持上传 PNG、JPG 格式图片
- 实时预览原图和压缩后的效果
- 显示压缩前后文件大小对比
- 支持自定义压缩比例
- 一键下载压缩后的图片

## 技术实现

- 使用原生 HTML5、CSS3 和 JavaScript
- 使用 Canvas API 进行图片压缩
- 响应式设计，支持各种设备