# .cursorrules

# Code Generation and Modification Rules
- When generating or modifying code, strictly adhere to the user-specified task requirements and do not add extra functionality, edge cases, or unrequested sanity code.
- Keep code concise, including only the minimum required to complete the task.
- Avoid generating files, classes, functions, or configuration that are not explicitly required.
- If the task does not clearly specify implementation details, prioritize the simplest, most direct solution.
- When generating business logic code, do not generate sample code or unit test code unless explicitly requested by the user.

# CSS Style Rules
- All CSS styles must use Tailwind CSS 3.x syntax.
- Use of native CSS (e.g., style attributes or .css files) or other CSS frameworks (e.g., less) is prohibited.
- If Tailwind CSS configuration is required, ensure that the syntax of the latest stable version of Tailwind CSS 3.x is used.

# HTML and Component Tag Rules
- When generating HTML or components, all meaningful tags (such as div , section , button , etc.) must include a data-alt="xxxx" attribute describing the tag's purpose.
- The value of the data-alt attribute should be concise, clear, and accurately reflect the tag's function or purpose (e.g., "main-content" or "submit-button").
- Examples:
- <div data-alt="main-content" class="p-4 bg-gray-100">...</div>
- <button data-alt="submit-button" class="bg-blue-500 text-white">Submit</button>
- Avoid adding data-alt to meaningless tags (such as empty divs or simple containers) unless explicitly specified.

# Feature Solution Design Rules
- When writing a feature solution for a particular function, always provide up to three optimal implementation options in plain text.
- Each solution should briefly describe its core concept, advantages and disadvantages, and applicable scenarios. - Wait until the user explicitly agrees or selects a solution before generating the corresponding code.
- Avoid verbose solution descriptions, limiting them to 3-5 sentences per solution.

# Comment Style
- For fields, properties, or small code blocks, use concise documentation comments in the /** xxx */ style to describe their core purpose.
- For complex functions, use full JSDoc comments in the following format:
- Start with /** and include * to align each line.
- Include @description to describe the function's main functionality.
- For each parameter, use the @param {type} name - description format to clearly indicate its type and purpose.
- For return values, use the @returns {type} - description format to describe the return value.
- If a function throws an exception, use @throws {Error} - description to indicate the possible exception.
- If appropriate, include @example to provide a brief usage example.
- Example:
/**
* Calculates the sum of two numbers.
* @param {number} a - The first number.
* @param {number} b - The second number.
* @returns {number} - The sum of a and b.
* @throws {Error} - If inputs are not numbers.
* @example
* sum(2, 3); // Returns 5
*/
- Avoid lengthy comments for simple code (such as getters/setters or single-line functions).
- Comments should be concise and avoid lengthy descriptions.
- Ensure that comments are comprehensive.

# Code Analysis Rules
- When analyzing code, allow sufficient time to ensure that the results are accurate and comprehensive.
- Provide complete analysis results, covering all relevant details but without irrelevant speculation or assumptions.
- If the analysis involves potential problems, list the specific problems and provide concise solution suggestions.
- Analyze but don't directly modify files to generate code. Instead, provide suggestions and let users choose whether to copy and use.

# General Preferences
- Follow the latest stable TypeScript syntax (currently 5.x).
- Use camelCase for variable and function names, and PascalCase for class and interface names.
- Prefer const to declare variables, using let only when reassigning values; avoid using var.
- Follow Airbnb TypeScript standards for coding style (e.g., 4-space indentation, single quotes).
- Avoid generating console.log or debugging code unless explicitly requested by the user.
- Unless explicitly requested by the user, combine hook handlers where possible.
- Always use async over .then for asynchronous functions.