refactor not done

.cursor/rules/comments.mdc

@@ -0,0 +1,35 @@
+---
+alwaysApply: true
+---
+
+# Comment Guidelines
+
+## Good Comments (Human-style)
+- Explain WHY, not WHAT
+- Document non-obvious behavior or edge cases
+- Warn about performance implications or side effects
+- Explain business logic that isn't clear from code
+
+Examples:
+```javascript
+// transfer, not copy; sender buffer detaches
+// satisfies: check shape; keep literals  
+// keep multibyte across chunks
+// timingSafeEqual throws on length mismatch
+```
+
+## Bad Comments (AI-style)
+- Don't explain what the code literally does
+- Don't add changelog-style comments in code
+- Don't comment every line or obvious operations
+
+Avoid:
+```javascript
+// Prevent duplicate initialization
+// Check if project is already loaded  
+// Mark as initializing to prevent race conditions
+// (changed from blah to blah)
+```
+
+## Rule
+Only add comments when there's genuinely non-obvious behavior, performance considerations, or business logic that needs context. Code should be self-documenting through naming and structure.

.cursor/rules/handling-uncertainty.mdc

@@ -0,0 +1,21 @@
+---
+alwaysApply: true
+---
+
+# Handling Uncertainty
+
+## Principle
+If you can't confidently respond due to missing context, data access, or ambiguity (multiple interpretations), report it instead of guessing. Seek clarification to avoid errors.
+
+Apply when: query lacks details, no access to info/tools, or unclear intent.
+
+## How to Report
+1. **Description**: Why uncertain and what you need.
+2. **Questions**: 1-3 targeted ones.
+3. **Assumptions** (opt.): State if proceeding; omit otherwise.
+
+Direct and concise.
+
+**Assumptions**: None.
+
+Builds transparency.

.cursor/rules/separation-of-concerns.mdc

@@ -0,0 +1,52 @@
+---
+alwaysApply: true
+---
+
+# Separation of Concerns
+
+## Core Principle
+
+Each file should have one single purpose/responsibility. Related functionality should be grouped together, unrelated functionality should be separated.
+
+## Good Separation
+
+- One file per major concern (auth, validation, data transformation)
+- Group related utilities together
+- Extract shared logic into dedicated files
+- Keep API routes focused on their specific endpoint logic
+
+Examples:
+
+```javascript
+// ✅ Good: Each file has clear responsibility
+/lib/rate-limit.ts          // Rate limiting utilities
+/lib/validation.ts          // Input validation schemas
+/lib/freesound-api.ts       // External API integration
+/api/sounds/search/route.ts // Route handler only
+```
+
+## Bad Mixing of Concerns
+
+Avoid cramming multiple responsibilities into one file:
+
+```javascript
+// ❌ Bad: Route file doing everything
+/api/sounds/search/route.ts
+- Rate limiting logic
+- Validation schemas
+- API transformation
+- External API calls
+- Response formatting
+- Error handling utilities
+```
+
+## When to Separate
+
+- File is getting long (>500 lines)
+- Multiple distinct responsibilities in one file
+- Logic could be reused elsewhere
+- Complex utilities that distract from main purpose
+
+## Rule
+
+One file, one responsibility. Extract shared concerns into focused utility files

.cursor/rules/ultracite.mdc

@@ -0,0 +1,105 @@
+---
+description: Ultracite Rules - AI-Ready Formatter and Linter
+globs: "**/*.{ts,tsx,js,jsx}"
+alwaysApply: true
+---
+
+# Project Context
+
+Ultracite enforces strict type safety, accessibility standards, and consistent code quality for JavaScript/TypeScript projects using Biome's lightning-fast formatter and linter.
+
+## Key Principles
+
+- Zero configuration required
+- Subsecond performance
+- Maximum type safety
+- AI-friendly code generation
+
+## Before Writing Code
+
+1. Analyze existing patterns in the codebase
+2. Consider edge cases and error scenarios
+3. Follow the rules below strictly
+4. Validate accessibility requirements
+5. Avoid code duplication
+
+## Rules
+
+### Accessibility (a11y)
+
+- Always include a `title` element for icons unless there's text beside the icon.
+- Always include a `type` attribute for button elements.
+- Accompany `onClick` with at least one of: `onKeyUp`, `onKeyDown`, or `onKeyPress`.
+- Accompany `onMouseOver`/`onMouseOut` with `onFocus`/`onBlur`.
+
+### Code Complexity and Quality
+
+- Don't use primitive type aliases or misleading types.
+- Don't use the comma operator.
+- Use for...of statements instead of Array.forEach.
+- Don't initialize variables to undefined.
+- Use .flatMap() instead of map().flat() when possible.
+
+### React and JSX Best Practices
+
+- Don't import `React` itself.
+- Don't use both `children` and `dangerouslySetInnerHTML` props on the same element.
+- Don't insert comments as text nodes.
+- Use `<>...</>` instead of `<Fragment>...</Fragment>`.
+
+### Function Parameters and Props
+
+- Always use destructured props objects instead of individual parameters in functions.
+- Example: `function helloWorld({ prop }: { prop: string })` instead of `function helloWorld(param: string)`.
+- This applies to all functions, not just React components.
+
+### Correctness and Safety
+
+- Don't assign a value to itself.
+- Avoid unused imports and variables.
+- Don't use await inside loops.
+- Don't hardcode sensitive data like API keys and tokens.
+- Don't use the TypeScript directive @ts-ignore.
+- Make sure the `preconnect` attribute is used when using Google Fonts.
+- Don't use the `delete` operator.
+- Don't use `require()` in TypeScript/ES modules - use proper `import` statements.
+
+### TypeScript Best Practices
+
+- Don't use TypeScript enums.
+- Use either `T[]` or `Array<T>` consistently.
+- Don't use the `any` type.
+
+### Style and Consistency
+
+- Don't use global `eval()`.
+- Use `String.slice()` instead of `String.substr()` and `String.substring()`.
+- Don't use `else` blocks when the `if` block breaks early.
+- Put default function parameters and optional function parameters last.
+- Use `new` when throwing an error.
+- Use `String.trimStart()` and `String.trimEnd()` over `String.trimLeft()` and `String.trimRight()`.
+
+### Next.js Specific Rules
+
+- Don't use `<img>` elements in Next.js projects.
+- Don't use `<head>` elements in Next.js projects.
+
+## Example: Error Handling
+
+```typescript
+// ✅ Good: Comprehensive error handling
+try {
+  const result = await fetchData();
+  return { success: true, data: result };
+} catch (error) {
+  console.error("API call failed:", error);
+  return { success: false, error: error.message };
+}
+
+// ❌ Bad: Swallowing errors
+try {
+  return await fetchData();
+} catch (e) {
+  console.log(e);
+}
+```

.cursor/rules/writing-scannable-code.mdc

@@ -0,0 +1,53 @@
+---
+alwaysApply: true
+---
+
+# Scannable Code Guidelines/Separating Concerns.
+
+## Core Principle
+
+Code should be scannable through proper abstraction, not comments. Use variables and helper functions to make intent clear at a glance.
+
+## Good Scannable Code
+
+- Extract complex logic into well-named variables
+- Create helper functions for multi-step operations
+- Use descriptive names that explain intent
+
+Examples:
+
+```javascript
+// ✅ Scannable: Intent is clear from variable names
+const isValidUser = user.isActive && user.hasPermissions;
+const shouldProcessPayment = amount > 0 && !order.isPaid;
+
+// ✅ Scannable: Complex logic extracted to helper
+const searchParams = buildFreesoundSearchParams({ query, filters, pagination });
+const transformedResults = transformFreesoundResults({ rawResults });
+```
+
+## Bad Unscannable Code
+
+Avoid:
+
+```javascript
+// ❌ Hard to scan: What does this condition mean?
+if (type === "effects" || !type) {
+  params.append("filter", "duration:[* TO 30.0]");
+  params.append("filter", `avg_rating:[${min_rating} TO *]`);
+  if (commercial_only) {
+    params.append("filter", 'license:("Attribution" OR "Creative Commons 0")');
+  }
+}
+
+// ❌ Hard to scan: Complex ternary
+const sortParam = query
+  ? sort === "score"
+    ? "score"
+    : `${sort}_desc`
+  : `${sort}_desc`;
+```
+
+## Rule
+
+Make code scannable by extracting intent into variables and helper functions. If you need to think about what code does, extract it. The reader should understand the flow without diving into implementation details.