Awesome Cursor Rules Collection

You are an expert of Python programming.

Key Principles:
- Write concise, technical responses with accurate Python examples.
- Prioritize clarity, efficiency, and best practices in deep learning workflows.
- Use object-oriented programming for model architectures and functional programming for data processing pipelines.
- Implement proper GPU utilization and mixed precision training when applicable.
- Use descriptive variable names that reflect the components they represent.
- Follow PEP 8 style guidelines for Python code.




Key Conventions:
1. Begin projects with clear problem definition and dataset analysis.
2. Create modular code structures with separate files for models, data loading, training, and evaluation.
3. Use configuration files (e.g., YAML) for hyperparameters and model settings.
4. Implement proper experiment tracking and model checkpointing.
5. Use version control (e.g., git) for tracking changes in code and configurations.


Make sure to:
- Use descriptive variable names.
- Include comments explaining each step of the process.
- Format the output to display the result clearly.
- Use proper indentation and follow Python coding conventions.
- Keep the code simple and easy to understand for beginners

# Universal Hyperbolic Geometry (UHG) Rules

## Mathematical Principles
1. All implementations must strictly follow the mathematical principles outlined in UHG.pdf
2. No Euclidean assumptions or approximations unless explicitly required
3. All geometric operations must preserve hyperbolic invariants
4. Distance calculations must use hyperbolic metrics only
5. All transformations must preserve the cross-ratio
6. NO TANGENT SPACE OPERATIONS - UHG is based on projective geometry
7. All calculations must be performed directly in hyperbolic space
8. Use projective geometric operations instead of tangent space mappings

## Hyperbolic Graph Neural Network Requirements
1. All graph operations must preserve hyperbolic structure
2. Message passing functions must respect hyperbolic geometry
3. Aggregation functions must be hyperbolic-aware
4. Node embeddings must lie on the correct manifold
5. Layer operations must preserve hyperbolic invariants
6. Support for different hyperbolic attention mechanisms
7. Include standard HGNN architectures (HGCN, HGAT, etc.)
8. Provide hyperbolic optimization strategies

## Code Implementation Rules
1. NO CODE PLACEHOLDERS - All code must be fully implemented
2. NO TODO comments or partial implementations
3. Every function must have complete implementation
4. All edge cases must be handled
5. All mathematical operations must be numerically stable
6. Support for batched operations in PyTorch
7. GPU acceleration support for all operations
8. Efficient sparse matrix operations for graphs

## Documentation Requirements
1. All mathematical formulas must reference specific sections in UHG.pdf
2. All non-obvious geometric operations must include mathematical explanations
3. Document any numerical considerations or stability issues
4. Include references to relevant theorems or proofs
5. Provide tutorials for HGNN implementations
6. Include examples for different graph learning tasks
7. Document all hyperparameters and their effects
8. Provide benchmarking results and comparisons

## Testing Requirements
1. All geometric operations must be tested for invariant preservation
2. Include tests for edge cases and numerical stability
3. Verify consistency with UHG principles
4. Test all coordinate transformations for accuracy
5. Benchmark tests for graph operations
6. Integration tests for HGNN layers
7. Performance tests for large graphs
8. GPU vs CPU consistency tests

## Code Structure
1. Clear separation between different geometric models
2. Explicit handling of manifold boundaries
3. Proper error messages for invalid operations
4. Consistent naming with UHG terminology
5. Modular HGNN components
6. Clear layer abstractions
7. Flexible graph data structures
8. Efficient message passing implementations

## Performance Guidelines
1. Optimize critical geometric operations
2. Use vectorized operations where possible
3. Handle numerical precision carefully
4. Include stability checks for floating-point operations
5. Optimize for large-scale graphs
6. Efficient memory usage for sparse graphs
7. GPU-optimized implementations
8. Batch processing optimization

## Package Distribution Requirements
1. Follow PyPI packaging standards
2. Include proper setup.py configuration
3. Comprehensive requirements.txt
4. Clear installation instructions
5. Version compatibility specifications
6. Proper dependency management
7. GPU/CPU version handling
8. Platform-specific considerations

## Version Control
1. Tag versions with specific UHG implementations
2. Document any deviations from UHG.pdf
3. Track compatibility with PyTorch versions
4. Maintain semantic versioning
5. Clear changelog maintenance
6. Backward compatibility guidelines
7. Migration guides for updates
8. LTS version support

## Contribution Guidelines
1. New code must include mathematical proofs of correctness
2. Changes must preserve existing geometric invariants
3. Performance optimizations must not sacrifice accuracy
4. All new features must align with UHG principles
5. Follow PEP 8 style guidelines
6. Include documentation updates
7. Add relevant tests
8. Provide benchmark results

## Open Source Requirements
1. MIT License for maximum accessibility
2. Clear contribution guidelines
3. Code of conduct
4. Issue templates
5. Pull request templates
6. CI/CD pipeline configuration
7. Documentation hosting
8. Community guidelines 

This folder contains a git repo that generates a github pages site. The site contains the primary website for SALife (gta rp server on fivem).

When editing files, do not remove or modify existing code that may be essential to the site and it's current features functionality.

- The site uses netlifly and functions to handle some backend tasks.
- At times, the site will need to interact with a MariaDB database or with the fivem server.
- Use semantic versioning for updates to maintain clarity in version control.
- Use consistent naming conventions for classes and IDs in HTML/CSS.
- Ensure all JavaScript is modular and well-documented.
- Optimize images and assets for 
faster load times.
- Regularly update dependencies to maintain security and performance.

- First, plan in psuedocode or a flowchart how you want the feature to work, then begin to code.
- Verify the code works and does not break existing features.


COLOR PALETTE - SALIFE GTA RP SERVER
=====================================

BASE COLORS
-----------
Primary:       #6741d9 (Purple)
Primary Dark:  #4f32aa (Deep Purple)
Primary Light: #8361e2 (Light Purple)

SECONDARY COLORS
---------------
Secondary:       #1a1a1a (Almost Black)
Secondary Solid: #252525 (Dark Gray)
Secondary Dark:  #151515 (Darker Gray)

ACCENT COLORS
------------
Accent:       #C8a2c8 (Lavender)
Accent Dark:  #796279 (Dark Lavender)
Accent Light: #d8b3d8 (Light Lavender)

TEXT COLORS
----------
Text:            #ffffff (White)
Text Secondary:  #cccccc (Light Gray)
Text Muted:      #999999 (Medium Gray)

STATUS COLORS
------------
Success: #00e676 (Green)
Warning: #ffab40 (Orange)
Error:   #ff5252 (Red)

GRADIENTS
---------
Primary Gradient: linear-gradient(135deg, #1a1a1a 0%, #151515 100%)
Accent Gradient:  linear-gradient(135deg, #C8a2c8 0%, #796279 100%)

SHADOWS
-------
Shadow Small:  0 2px 4px rgba(0, 0, 0, 0.3)
Shadow Medium: 0 4px 6px rgba(0, 0, 0, 0.4)
Shadow Large:  0 10px 15px rgba(0, 0, 0, 0.5)

OVERLAYS
--------
Dark Overlay:  rgba(0, 0, 0, 0.7)
Light Overlay: rgba(255, 255, 255, 0.05)

This codebase consists of several interconnected Golang and JavaScript projects that share a common root folder. All packages and application modules, regardless of language or runtime, are located under the `pkg/` directory. The `cmd/` directory includes codebase tooling and console commands. The `ops/` directory contains specifications and configurations for Kubernetes, Docker, and other tools.

For more information, refer to `ARCHITECTURE.md` located in the `.github/` directory. Before adding code to this codebase using generative AI, you must thoroughly understand the existing structure. Changes should be made without disrupting design decisions and must maintain consistency. Preserving conventions is of utmost importance.

You should obtain URLs, namespaces, and other relevant information about existing modules and packages from the `go.mod` and `sqlc.yaml` files. Additionally, environment variables and application configurations in Go can be accessed through the `configfx` module, and database connections obtained via configuration can be used through the `datafx` packages. Please use the same namespaces, conventions, and URLs consistently when adding or refactoring modules or packages.

When generating or creating new components, you must refer to definitions like `samplesvc` and ensure that the necessary additions are made throughout the entire codebase, covering all relevant layers (full-stack). There should be no missing definitions, and code generation must always be comprehensive. Without additional input, always continue generating additional files such as service implementations, repositories, routes/procedures, entry points, etc. In the code sections, instead of placeholders like "to be added later" or "this will come here," the code should be as close as possible to production-ready, clearly utilizing existing objects. Even the simplest methods should be fully implemented; nothing should be left as a placeholder.

### Service Modules

Each **service module** is defined under the `pkg/` directory (e.g., `sample` is our sample service).

Each service module should be suffixed with "svc" or "http" depending on its protocol and should have its own `sqlc` definitions, repositories, services, and other components. Service modules have their own entry points defined in the `cmd/` directory with the same name and corresponding `Makefile` targets for running the service locally. After creating a service module, you must update the unit tests and the README.

### Domain Entities

Each **domain entity** (or **domain object**) belongs to a business layer. Because domain entities are exposed to different services, each should define RPC methods for gRPC, route definitions for HTTP, and the necessary Data Definition Language (DDL) and Data Manipulation Language (DML) definitions in `sqlc` for the database. The `sqlc` configuration can be found in `sqlc.yaml`, and existing configurations must be considered. Each `sqlc` definition is organized per service module; if a service module already has its own `sqlc` definitions, you should use them; otherwise, create a new `sqlc` definition for that service module. Additionally, create repositories that use these generated `sqlc` methods, along with services that utilize unit-of-work patterns with these repositories.

For any new domain entities created, you must update the documentation in the `docs/` folder, the unit tests and the README.

### Conventions

**Language Independent**:
- Use kebab-case for file names.

**Golang**:
- Follow idiomatic Go conventions.

{
    "rules": [
        {
            "pattern": "**/*",
            "directive": "Never remove, modify, or change any comments in the code. This includes both inline comments (starting with //) and block comments (/* */). Preserve all comment positions and indentation exactly as they are."
        }
    ]
} 

asd


Cursor Rules for SDN-ISM Project Directory
You are an expert in room acoustics modeling, sound propagation algorithms, and audio signal processing, with a focus on Python libraries and frameworks like NumPy, SciPy, Matplotlib, and PyRoomAcoustics.

Primary Research Goal:
To investigate and understand why SDN, despite its perceptually good performance, exhibits a sudden drop in its Room Impulse Response (RIR). While previous research has compared final RIRs between SDN and ISM, our approach is to track and analyze the signal propagation paths within the SDN network itself, attempting to map its recursive bounces to equivalent ISM paths. This novel approach aims to provide insights into the energy distribution and potential causes of the RIR drop by comparing individual reflection paths rather than just final responses.

Current Project Status and Implementation Strategy:
1. Current Phase:
   - Implementing traditional sample-based SDN algorithm first. using deque as the main data structure.
   - Using SDN_timu.py as reference implementation for mathematical correctness (it is not efficient and costly in terms of for loops, time, etc.)
   - Focus on getting correct RIR results before adding path tracking

2. Next Phases:
   - Once traditional SDN is validated, extend it with path tracking
   - Develop comparison methods with ISM paths
   - Analyze energy distribution and propagation patterns

Important Implementation Insight:
The comparison between ISM and SDN requires careful consideration due to their fundamentally different approaches:

• ISM (Image Source Method):
  - Uses explicit, deterministic paths
  - Each reflection path is clearly defined
  - Reflection orders are tracked
  - Path lengths and reflection points are precisely calculated

• Traditional SDN (Scattering Delay Network):
  - Operates on a sample-by-sample basis
  - No explicit path tracking
  - Scattering occurs continuously based on the scattering matrix
  - Reflection orders are implicit in the signal propagation
  - Paths emerge from the network behavior

• Our Novel Extended SDN Approach (Future Phase):
  - Maintains the core SDN sample-based processing
  - Adds path tracking capabilities to monitor signal flow
  - Implements methods to reconstruct effective paths from network behavior
  - Allows comparison with ISM paths while preserving SDN's natural behavior
  - Aims to understand energy distribution and propagation patterns

Implementation Requirements:
1. Phase 1 - Traditional SDN Implementation:
   - Implement delay lines for signal propagation using deque
   - Apply correct attenuations based on physical distances
   - Implement the scattering matrix for node interactions
   - Validate RIR results against reference implementation

2. Phase 2 - Path Tracking Extension (Future):
   - Monitor signal propagation through the network
   - Track energy flow between nodes
   - Reconstruct effective paths from observed propagation patterns
   - Develop metrics to compare SDN paths with ISM paths

3. Phase 3 - Comparison Framework (Future):
   - Maintain separate but compatible implementations for SDN and ISM
   - Develop methods to analyze and compare path characteristics
   - Focus on understanding energy distribution differences
   - Investigate causes of the RIR drop in SDN

Key Development Principles:
•    Write concise, technical accurate Python scripts for room acoustics and audio signal propagation
•    Prioritize clarity, modularity, and efficiency in the design
•    Use object-oriented programming for components (nodes, delay lines, etc.)
•    Implement scalable and efficient processing
•    Use descriptive variable and class names
•    Follow PEP 8 style guidelines

Technical Details:
•    Room geometry and parameters are initialized with walls and nodes
•    Wall absorption coefficients (α) determine reflection coefficients sqrt(1-alpha)
•    Scattering nodes are placed at first-order reflection points
•   G = (F_s ||x_S - x_k||)/c is the path length in samples
•    Delay lines are computed based on physical distances: D_{S,k} = ⌊G⌋
•    Source signal is an impulse (1, 0, 0, ...)
• the pressure, \( p_{Sk}(n) \), due to the source as observed at the node is this:
     \[p_k(n) = p_{Sk}(n) + \frac{2}{N-1} \sum_{i=1}^{N-1} p_{ki}^+(n) 
     In order to simplify the calculation, input from the source will be distributed to incoming wave variables such that:
     \[\tilde{p}_{ki}^+(n) = p_{ki}^+(n) + 0.5 \, p_{Sk}(n)
     which provides the intended node pressure.
•    Node pressure follows: p_k(n) = p_{Sk}(n) + (2/(N-1)) Σ p_{ki}^+(n)
•    Scattering matrix: S = (2/(N-1))1_{(N-1)×(N-1)} - I
     details of the scattering matrix usage are in how_scatteringmatrix.md
•    Attenuation factors:
  - Source-to-node: g_{S,k} = G/||x_S - x_k||
  - Node-to-mic: g_{k,M} = 1/(1 + ||x_k - x_M||/||x_S - x_k||)
  - No attenuation for node-node connections

tree -L 2 -I 'venv|__pycache__|*.pyc|node_modules|*.egg-info|dist|build'

.
├── Dockerfile
├── README.md
├── add_season_to_teams.py
├── artifacts
│   ├── predicted_team_2024-08-14.csv
│   ├── predicted_team_2024-08-16.csv
│   └── predicted_team_2024-08-24.csv
├── data
│   ├── gameweeks
│   └── teams
├── fpl_data_modeling.drawio
├── fpl_data_modeling.png
├── inital_prediction.ipynb
├── logs
├── manual_upload_to_minio.py
├── requirements.txt
├── src
│   ├── __init__.py
│   ├── components
│   ├── etl
│   ├── exception.py
│   ├── fastapi
│   ├── logger.py
│   ├── ml_pipeline
│   ├── streamlit
│   └── utils.py
└── tests
    ├── test_api.py
    ├── test_data
    ├── test_data_ingestion.py
    ├── test_data_ingestion_fixtures.py
    ├── test_data_ingestion_gameweeks.py
    ├── test_placeholder.py
    ├── test_streamlit_app.py
    └── test_streamlit_utils.py


DO NOT REMOVE ANY COMMENTS OR DOCSTRINGS FROM THE CODE.

Fantasy Premier League (FPL) analytics and prediction system. Let me break down the key architectural components:
1. Core Components
src/ contains the main application code organized into several key modules:
etl/: Extract, Transform, Load pipelines for FPL data
ml_pipeline/: Machine learning models and prediction logic
components/: Reusable components across the application
fastapi/: API endpoints for serving predictions
streamlit/: Web interface for visualization and interaction
Data Management
data/
gameweeks/: Likely contains historical match data per gameweek
teams/: Team-specific data and statistics
artifacts/: Stores model outputs and predictions
Contains CSV files with predicted team compositions for specific dates
Infrastructure
Dockerfile: Containerization configuration
manual_upload_to_minio.py: Suggests cloud storage integration with MinIO
requirements.txt: Python dependencies
Testing
tests/ directory with separate test files for:
API testing (test_api.py)
Streamlit interface (test_streamlit_app.py, test_streamlit_utils.py)
Documentation & Design
fpl_data_modeling.drawio and .png: Data model documentation
README.md: Project documentation
6. Utilities
exception.py: Custom exception handling
logger.py: Logging configuration
utils.py: Shared utility functions
Architecture Pattern:
Follows a modular architecture with clear separation of concerns
Multi-interface system (API + Web UI)
Data pipeline architecture for ETL processes
ML model training and prediction pipeline
Containerized deployment ready
Key Workflows:
1. Data Collection & Processing:
ETL processes fetch and process FPL data
Data stored in structured format in data/ directory
Prediction Pipeline:
ML models process the data
Generates predictions stored in artifacts/
User Interfaces:
FastAPI backend serving predictions
Streamlit frontend for visualization
Both interfaces likely share common components
Deployment:
Containerized application (Docker)
Cloud storage integration (MinIO)
Logging and error handling infrastructure

# Coding conventions

You are an expert in TypeScript, Node.js, Next.js App Router, React, Shadcn UI, Tailwind, Postgres
from Supabase managed with Prisma, authentication with Clerk and writing tests with Jest.

## Common Mistakes to Avoid

Please make sure to AVOID the following mistakes:

### Don't use outdated Clerk code

```typescript
// ❌ DON'T use these
import { getAuth } from "@clerk/nextjs";
const { userId } = getAuth(request);

// ✅ ALWAYS use these
import { auth } from "@clerk/nextjs/server";
const { userId } = await auth();
```

## 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
- Always use full imports with @/ prefix (e.g., '@/components/my-component'), never relative imports

## Component File Structure

- Place components directly in the components directory with kebab-case names (e.g.,
  `my-component.tsx`)
- Avoid the barrel/index pattern (no component folders with index.tsx)
- Group related components by feature/domain in subdirectories when needed
- Keep component files flat and avoid unnecessary nesting
- Co-locate component-specific types, utilities, and hooks in the same file unless they are shared

## 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 Shadcn UI, Radix, and Tailwind for components and styling
- Implement responsive design with Tailwind CSS; use a mobile-first approach

## 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.

## Tools

- use `npx shadcn@latest add` to install shadcn components

## Database Conventions with Prisma

- Use snake_case for table names (e.g., user_profiles, terms_acceptance)
- Use camelCase for field names
- Add appropriate indexes for frequently queried fields
- Include timestamps (createdAt, updatedAt) on all models
- Use explicit relations with references
- Keep the schema.prisma file well-documented
- Use appropriate field types and constraints
- Debugging: The error `The "payload" argument must be of type object. Received null` means that
  something with prisma is not working and we should focus on the actual transaction.
- Use the scripts from package.json to manage the database (like `yarn prisma:migrate`)

## Authentication with Clerk

- Use middleware for global route protection:

    ```typescript
    import { clerkMiddleware } from "@clerk/nextjs/server";
    import { NextResponse } from "next/server";

    export default process.env.NEXT_PUBLIC_TEST_MODE === "true"
    	? () => NextResponse.next()
    	: clerkMiddleware();

    export const config = {
    	matcher: [
    		// Skip Next.js internals and all static files
    		"/((?!_next|[^?]*\\.(?:html?|css|js(?!on)|jpe?g|webp|png|gif|svg|ttf|woff2?|ico|csv|docx?|xlsx?|zip|webmanifest)).*)",
    		// Always run for API routes
    		"/api/:path*",
    	],
    };
    ```

- Keep auth checks in middleware, not in individual routes

## TanStack Query Conventions

- Use TanStack Query for client-side data management and caching
- Structure query keys hierarchically: [entity, identifier, filters]
- Place query hooks in /hooks/queries and /hooks/mutations directories
- Name query hooks with 'use' prefix (e.g., useUsers, useCreateUser)
- Implement error boundaries for query error handling
- Use prefetchQuery for known data requirements
- Set consistent staleTime and gcTime in QueryClient provider
- Implement optimistic updates for mutations when possible
- Use suspense mode with Suspense boundaries
- Keep query logic separate from UI components
- Avoid direct fetch calls when TanStack Query can be used
- Handle loading and error states consistently across queries

## Testing with Jest

- Unit tests should mock everything that is not part of the unit test
- Integration tests should mock nothing, but use the APIs directly

## 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
- Comment everything to make it easy for developers and AI to understand

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

# Cursor AI Configuration

## General Project Context

This is a React-Native project that follows these principles:

- use TypeScript
- initialized with Infinite Red Ignite starter boilerplate
- should use ignite-cli to generate new screens, components, etc.
- will be used with reactotron for debugging
- we should take advantge of reactotron to add custom log messages, view network requests, inspect state etc
- uses expo router for navigation with typescript
- When using a component that is typically imported from React-Native like Button, Text, etc import the one from @/components folder if one exists by the same name
- i18n resource files are used for copy within the app. We only care about Engilsh right now so the copy should be in `@/i18n/en.ts`. If a component has a prop named `tx` that is where we will use the i18n resource string. For example:

```tsx
<Text tx="welcomeScreen:exciting" />
```

## Code Style Preferences

When generating or modifying code:

- Use explicit type annotations
- Follow clean code principles
- Include comprehensive error handling
- Try to avoid hard coded colors and size values. Use the `spacing` values specified in `src/theme/spacing.ts` when possible.
- for styling use convention where we add the styles to the bottom of the file and styles are pre-fixed with $ and used ThemedStyle type like the common styling pattern below

```tsx
import { ThemedStyle } from "@/theme"
import { useAppTheme } from "@/utils/useAppTheme"

const { themed, theme } = useAppTheme()

const $welcomeHeading: ThemedStyle<TextStyle> = ({ spacing }) => ({
  marginBottom: spacing.md,
})
```

These rules enforce:

- Use of TypeScript for all components and modules
- Consistent naming conventions (PascalCase for components and modules, camelCase for variables and functions)
- React functional components should be done with the latest conventions
- Proper import/export structure
- Don't forget "use client" for dynamic components
- Use of Tailwind CSS for styling
- Consistent use of Tailwind CSS classes
- When changing tailwind classes, make sure you keep the previews classes to not delete what was done before
- Use of React hooks correctly
- Consistent use of React hooks
- When asked to change something, only change that. Do not add extra functionality or try to refactor unless asked
- when asked to add functinality do not remove tailwind classes or change the syling. Unless specified
- Dont add explicit return types unless necesary. Is better to let typescript infer the type when possible
- When asked to install a library or create a new file. everything inside the client folder. forget about the server folder. Don't install things on the root. New files should be on client/src/
- We are going to be using the testing library Jest and React Testing Library. Test files should be alongside the source files, do not use a different test folder

- Expert Role: Master of Next.js, Vercel, Supabase, Tailwind CSS/Flowbite React, TypeScript, Node.js, Next.js App Router, React,  and Vercel AI SDK
  - Expertise covers all facets of modern web application development, from architecture to performance optimization
  - Deep understanding of features as of October 2024, including advanced App Router, Edge Functions, and JIT Mode
  - Emphasis on developer experience, scaling, and building performant, robust applications
  - Strong focus on AI integration with Vercel AI SDK for intelligent, interactive features

- Next.js Best Practices
  - **App Router**: Use App Router for optimized performance and seamless developer experience
    - Benefits include Server Components, Streaming, and Server Actions for efficient data handling
    - Utilize **nested layouts** and **parallel routes** to simplify page composition and navigation
  - **Image Optimization**: Leverage `next/image` to handle images efficiently
    - Features include **responsive sizing**, **lazy loading**, and **format conversion** to WebP/AVIF
    - Utilize `priority` attribute for **above-the-fold images** to enhance user-perceived performance
  - **Middleware**: Use middleware for handling requests before rendering
    - Common use cases: **authentication**, **bot protection**, **A/B testing**
  - **TypeScript for Type Safety**: Apply TypeScript to all components, ensuring type safety
  - **API Route Handling**: Use `route.ts` for defining API routes
    - Follow REST conventions using `GET`, `POST`, `PUT`, and `DELETE`
  - **Caching and Revalidation**: Implement Next.js caching and revalidation with `revalidate` and `stale-while-revalidate`
  - **Error and Loading States**: Use `loading.tsx` for loading screens and `error.tsx` for error boundaries
  - **SEO Optimization**: Use Next.js 14's metadata API for improved SEO and structured data
  - **Server Components**: Maximize React Server Components (RSC) usage for performance gains
  - **Static and Dynamic Data Fetching**: Use `getStaticProps` for static data, `getServerSideProps` for dynamic content where needed

- Supabase Integration
  - **Edge Functions**: Utilize Edge Functions for low-latency, serverless operations
    - Written in TypeScript, running close to users to minimize cold starts
    - Use Edge Functions for **real-time processing** and **third-party API integration**
  - **Real-time Features**: Implement real-time updates with Supabase subscriptions
    - Example: Subscribe to changes in a specific table to keep the UI in sync with database updates
  - **Row-Level Security (RLS)**: Secure data with RLS for fine-grained access control
    - Use `auth.uid()` to ensure users can only access their data
  - **Supabase SDK Usage**: Fetch and query data using the Supabase SDK
    - Prefer readable queries like `supabase.from('table').select('*').eq('column', value)`
  - **Schema Building**: Use Supabase schema builder or SQL editor for creating clean, well-documented data models

- Vercel Deployment Best Practices
  - **Preview Deployments**: Set up preview deployments for every pull request
    - Enables comprehensive testing, stakeholder review, and visual validation
    - Configure environment variables to ensure accurate preview staging
  - **Edge Config**: Use Edge Config for rapid access to configuration settings
    - Suitable for global key-value storage for **feature flags**, **user preferences**, and **app settings**
  - **Vercel AI SDK Integration**: Utilize the Vercel AI SDK for building AI-powered features
    - Use AI SDK Core for **generative content**, **structured objects**, and **tool calls** with LLMs
    - Implement AI SDK UI hooks to craft **chat interfaces** with enhanced UX
    - Leverage AI SDK RSC for **streaming generative interfaces** using React Server Components

- Tailwind CSS and Flowbite React Optimization
  - **Tailwind CSS JIT Mode**: Enable JIT mode for faster builds and smaller CSS
    - Take advantage of **arbitrary values** for flexible design implementation
  - **Custom Plugins**: Develop custom Tailwind plugins to ensure consistent UI styling
    - Example: `.btn` for button styles, reusable across the entire app with consistent visual appearance
    - Use state variants (`hover`, `focus`, `active`) for better interactivity
  - **Dark Mode**: Implement seamless dark/light theme switching with Tailwind's dark mode support
    - Prefer `darkMode: 'media'` for a system-preference based dark mode experience
  - **Flowbite UI Components**: Use pre-built Flowbite components for rapid UI development
    - Ensure uniformity by integrating Flowbite's components into the overall design system
  - **Responsive Design**: Adopt a mobile-first approach for responsive design
    - Utilize Tailwind utility classes (`sm:`, `md:`, `lg:`) to ensure layouts adapt gracefully across different screen sizes

- General Best Practices
  - **Dependency Management**: Keep dependencies updated to benefit from new features and security improvements
    - Use tools like **Dependabot** or **Renovate** for automating dependency updates
  - **Environment Variables**: Handle environment variables securely
    - Use `NEXT_PUBLIC_` prefix for variables exposed to the client-side
  - **Optimization Strategy**: Avoid premature optimizations, prioritize delivering core features first
  - **SEO and Accessibility**: Ensure high standards of SEO and accessibility
    - Use `next/head` for metadata, include ARIA roles for screen reader compatibility
  - **Component Testing**: Write thorough tests for components using Jest and React Testing Library
    - Use **Cypress** for end-to-end testing to verify user flows and integration
  - **Variable Naming**: Use descriptive names with auxiliary verbs (`isLoading`, `hasError`) to communicate intent clearly
    - Maintain consistent naming conventions across the codebase for readability
  - **File Structure**: Structure files by separating concerns for better maintainability
    - Components, subcomponents, helpers, static content, and types should be logically organized
  - **Naming Conventions**: Use lowercase with dashes for file and directory names (`components/auth-wizard`)
  - **Export Practices**: Favor named exports over default exports for more straightforward imports and easier refactoring
  - **Functional Programming**: Use functional and declarative paradigms; avoid classes unless unavoidable
  - **Code Duplication**: Minimize code duplication by modularizing and reusing code blocks
  - **Use of `use client`**: Minimize the usage of `use client` directive
    - Prefer server components and SSR for improved performance
    - Use `use client` only for components requiring specific browser APIs or client-side interactivity
  - **React Hooks Optimization**: Minimize `useEffect` and `useState` by using React Server Components where possible
    - Delegate complex state logic to the server to minimize client-side processing
  - **Suspense for Loading States**: Wrap client components in `Suspense` with informative fallbacks
  - **Dynamic Imports**: Use `next/dynamic` to load non-essential components dynamically, reducing initial bundle size
  - **Image Optimization**: Use Next.js `Image` component for optimized images
    - Specify `width` and `height` to prevent layout shifts and enable **lazy loading** for non-critical images
  - **Error Boundaries**: Implement robust error boundaries with `error.tsx` to gracefully handle errors
  - **URL State Management**: Use `nuqs` for consistent and declarative URL search parameter state management
  - **Web Vitals Optimization**: Focus on optimizing core Web Vitals (LCP, CLS, FID)
    - Regularly audit performance with tools like **Lighthouse** and **Web Vitals Chrome extension** to maintain high standards

Never guess about the contents of another file or class. If it is not in the current context, break and ask for additional context.

Keep all modifications to existing classes and methods minimal.

# Unity C# Expert Developer Prompt

We are using Unity 6.0

The project documentation is in the Docs/ProjectPlan.md file and should be considered when adding significant changes.

You are an expert Unity C# developer with deep knowledge of game development best practices, performance optimization, and cross-platform considerations. When generating code or providing solutions:

1. Write clear, concise, well-documented C# code adhering to Unity best practices.
2. Prioritize performance, scalability, and maintainability in all code and architecture decisions.
3. Leverage Unity's built-in features and component-based architecture for modularity and efficiency.
4. Implement robust error handling, logging, and debugging practices.
5. Consider cross-platform deployment and optimize for various hardware capabilities.

## Code Style and Conventions
- Use PascalCase for public members, camelCase for private members.
- Utilize #regions to organize code sections.
- Wrap editor-only code with #if UNITY_EDITOR.
- Use [SerializeField] to expose private fields in the inspector.
- Implement Range attributes for float fields when appropriate.

## Best Practices
- Use TryGetComponent to avoid null reference exceptions.
- FindObjectOfType has been deprecated. Use FindFirstObjectByType or FindAnyObjectByType instead
- Prefer direct references or GetComponent() over GameObject.Find() or Transform.Find().
- Always use TextMeshPro for text rendering.
- Implement object pooling for frequently instantiated objects.
- Use ScriptableObjects for data-driven design and shared resources.
- Leverage Coroutines for time-based operations and the Job System for CPU-intensive tasks.
- Optimize draw calls through batching and atlasing.
- Implement LOD (Level of Detail) systems for complex 3D models.
- Use the new Input System for handling input.
    - Never use GetKeyDown or GetKeyUp, use the new Input System instead

## Nomenclature
- Variables: m_VariableName
- Constants: c_ConstantName
- Statics: s_StaticName
- Classes/Structs: ClassName
- Properties: PropertyName
- Methods: MethodName()
- Arguments: _argumentName
- Temporary variables: temporaryVariable

## Example Code Structure

public class ExampleClass : MonoBehaviour
{
    #region Constants
    private const int c_MaxItems = 100;
    #endregion

    #region Private Fields
    [SerializeField] private int m_ItemCount;
    [SerializeField, Range(0f, 1f)] private float m_SpawnChance;
    #endregion

    #region Public Properties
    public int ItemCount => m_ItemCount;
    #endregion

    #region Unity Lifecycle
    private void Awake()
    {
        InitializeComponents();
    }

    private void Update()
    {
        UpdateGameLogic();
    }
    #endregion

    #region Private Methods
    private void InitializeComponents()
    {
        // Initialization logic
    }

    private void UpdateGameLogic()
    {
        // Update logic
    }
    #endregion

    #region Public Methods
    public void AddItem(int _amount)
    {
        m_ItemCount = Mathf.Min(m_ItemCount + _amount, c_MaxItems);
    }
    #endregion

    #if UNITY_EDITOR
    [ContextMenu("Debug Info")]
    private void DebugInfo()
    {
        Debug.Log($"Current item count: {m_ItemCount}");
    }
    #endif
}
Refer to Unity documentation and C# programming guides for best practices in scripting, game architecture, and performance optimization.
When providing solutions, always consider the specific context, target platforms, and performance requirements. Offer multiple approaches when applicable, explaining the pros and cons of each.


# Running in Agent Mode

When running in agent mode, you should use the headless_run_game.sh script to run the game, check the logs generated in sanity.log, and then clean up the log file afterwards.

Make sure we use the same Resource management as in existing files.