Awesome Cursor Rules Collection

# 프로젝트 개발 가이드라인

## 1. 컴포넌트 가이드라인

### ShadCN Components
- 모든 UI 컴포넌트는 ShadCN을 사용해야 합니다.
- 컴포넌트 사용 전 설치 여부를 확인해야 합니다: '/components/ui' 디렉토리 체크
- 컴포넌트 설치 명령어를 사용해야 합니다: 'npx shadcn@latest add [component—name]'
    - 주의: 'npx shadcn—ui@latest add' 명령어는 deprecated. 반드시 'npx shadcn@latest add'를 사용해야 합니다.

### lcons

- 모든 아이콘은 Lucide React를 사용해야 합니다
- 아이콘 임포트 방법: 'import { IconName } from "lucide—react"'
- 예시: 'import { Search, Menu } from "lucide—react"'

### Component Structure

- 컴포넌트는 '/components' 디렉토리 내에 위치해야 합니다
- UI 컴포넌트는 '/components/ui' 디렉토리에 위치해야 합니다
- 페이지별 컴포넌트는 '/app' 디렉토리 내 해당 라우트에 위치해야 합니다

### Core Practices

- TypeScript types must be strictly defined.
- Follow the user requirements carefully and precisely.
- First, think step-by-step—describe your plan for what to build in pseudocode, written out in great detail.
- Confirm the plan with the user, then write the code!
- Always write correct, up-to-date, bug-free, fully functional, secure, performant, and efficient code.
- Focus on readability over performance.
- Fully implement all requested functionality.
- Leave NO to-dos, placeholders, or missing pieces in the code.
- Ensure the code is complete! Thoroughly verify the final version.
- Include all required imports, and ensure proper naming of key components.
- Be concise. Minimize unnecessary explanations and redundancy.
- If you believe there might not be a correct answer, say so. If you do not know the answer, admit it instead of guessing.
- Always provide concise, precise answers.
- Ensure reusability and modularity in your code to facilitate scalability and future development.
- Components must be designed to be reusable.
- Include comprehensive test cases to validate the functionality, edge cases, and performance of the code.
- Provide concise and clear documentation for the purpose, functionality, and usage of the code, such as comments or README files.
- Implement proper error handling and exception management to make the code robust and user-friendly.
- Maintain collaboration-friendly code by using clear naming conventions, consistent formatting, and a logical structure that a team can easily understand.
- Please answer in Korean.

# UI Text Rules
- All UI text should be lowercase, except for proper nouns (names, brands, etc.)
- Text should be concise and direct
- Remove unnecessary words and verbosity
- Use consistent terminology across components
- Remove explanatory text when the UI is self-explanatory
- Keep error messages short and clear (e.g., "invalid credentials")

# Examples
✅ "sign in" instead of "Sign In" or "Login"
✅ "username" instead of "Enter your username"
✅ "invalid credentials" instead of "The username or password you entered is incorrect"
✅ "need an account?" instead of "Don't have an account? Sign up"

# Component Naming
- Keep React component names in PascalCase (e.g., Login, Button)
- Keep file names in kebab-case (e.g., sign-up.tsx)
- Keep CSS class names in kebab-case

# Spacing
- Use minimal spacing between elements (e.g., space-y-2)
- Keep forms compact (max-width: 320px)
- Use consistent padding (e.g., pt-4 for card content)
- Reduce vertical whitespace in forms
- Keep header height compact (h-12)
- Use small text (text-sm) for secondary information

# Button Rules
- Use small buttons where possible (size="sm")
- Keep button text concise
- Use ghost variant for secondary actions
- Use consistent height for header buttons (h-7) 

# Code Modification Rules
- Only make explicitly requested changes
- No unintended side effects when making changes
- Keep all working functionality intact
- Never modify code that isn't part of the requested change
- Never remove working functionality or code
- Preserve existing code behavior
- Keep working error handling
- Maintain existing security measures
- Preserve working CORS configurations

# File Structure Rules
- Keep existing file organization
- Keep existing file paths and structures
- Maintain working import/export structure
- Preserve working file relationships
- Keep existing file naming conventions
- Maintain directory hierarchy
- Keep existing file names and locations

# Configuration Rules
- Keep working environment setups
- Preserve working build processes
- Maintain deployment configurations
- Keep working cache settings
- Preserve CORS settings
- Keep working auth configurations
- Maintain database connections
- Preserve existing environment variables
- Keep working database schemas and tables
- Preserve working RLS policies
- Keep working edge function configs
- Maintain working realtime subscriptions
- Keep working edge function CORS headers
- Preserve working rate limits
- Maintain working webhook configurations
- Keep working storage bucket settings

# API & Database Rules
- Keep working API endpoints
- Preserve working database triggers
- Maintain working stored procedures
- Keep working database indexes
- Preserve working database constraints
- Keep working database roles

# Authentication Rules
- Keep working auth providers
- Preserve working auth callbacks
- Maintain working auth redirects
- Keep working auth policies
- Preserve working JWT settings

# Version Control Rules
- Keep working lock file entries
- Preserve dependency versions
- Maintain peer dependencies
- Keep working node version settings
- Preserve typescript configurations
- Keep existing gitignore patterns

# Example: What Not To Change
❌ Modifying code beyond requested changes
❌ Changing working configurations
❌ Altering existing security measures
❌ Modifying working error handling
❌ Changing working CORS settings
❌ Altering working auth flows
❌ Modifying working database connections
❌ Removing working build commands
❌ Changing working file paths
❌ Modifying working database schemas
❌ Changing working RLS policies
❌ Altering working stored procedures
❌ Modifying working auth flows
❌ Changing working realtime subscriptions
❌ Modifying working build scripts
❌ Changing working build paths
❌ Altering working CORS headers
❌ Modifying working rate limits
❌ Changing working storage settings

# Example: Acceptable Changes
✅ Making only requested modifications
✅ Adding new functionality without breaking existing code
✅ Extending configurations without breaking working ones
✅ Adding new security measures alongside existing ones
✅ Creating new files without modifying existing ones
✅ Adding new environment variables
✅ Adding new dependencies
✅ Adding new database tables
✅ Creating new stored procedures
✅ Adding new RLS policies
✅ Extending existing schemas
✅ Adding new build scripts
✅ Creating new storage buckets
✅ Adding new rate limits 

# Assistant Behavior Rules
- Only make changes explicitly requested by the user
- Never suggest "improvements" to working code
- Never try to "clean up" or "optimize" working code
- Never remove code just because it seems unused
- Never change formatting of working code
- Never modify indentation unless requested
- Never rewrite working code in a "better" way
- Never add "missing" error handling to working code
- Never add "helpful" comments to working code
- Never change variable/function names to be "clearer"

# Code Block Rules
- Always include file path when suggesting edits
- Use "// ... existing code ..." to mark unchanged sections
- Show enough context around changes for clear location
- Never rewrite entire files unless specifically requested
- Keep all working code markers and comments intact
- Use correct file paths matching project structure
- Use format: ````language:path/to/file
- Include full path from project root
- Match existing directory structure
- Keep consistent path separators

# Example: What Not To Do
❌ "This code could be improved by..."
❌ "I've cleaned up the formatting..."
❌ "I've added better error handling..."
❌ "I've made the variable names clearer..."
❌ "I've optimized this section..."
❌ Using incorrect/incomplete paths
❌ Missing file paths in codeblocks
❌ Using wrong path separators

# Example: Correct Behavior
✅ Only showing requested changes
✅ Keeping existing code markers
✅ Maintaining current formatting
✅ Preserving working code structure
✅ Including clear file paths
✅ Using full paths from root
✅ Matching project structure

# Suggestion Rules
- Suggestions should be clearly marked as optional
- Explain why each suggestion might be helpful
- Show suggestions separately from requested changes
- Never mix suggestions with direct changes
- Always preserve working code in suggestions
- Make suggestions additive, not replacements
- Provide context for each suggestion
- Let user choose which suggestions to implement

# Example: Good Suggestions
✅ "Optional improvement: Could add input validation here..."
✅ "Consider adding error logging to help with debugging..."
✅ "Might want to add a loading state for better UX..."
✅ "Could add type safety by extending the Profile interface..."

# Example: Bad Suggestions
❌ "I've improved the code by..."
❌ "This code should be changed to..."
❌ "The better way to do this is..."
❌ "I fixed the code by..." 

# Edge Function Rules
- Always check existing functions first (e.g., sign-in-with-username)
- Match existing query patterns exactly
- Use parameterized queries always
- Never interpolate values into SQL
- Keep working CORS configurations
- Maintain consistent error handling
- Follow existing security patterns
- Keep function naming consistent
- Verify data exists before use
- Check array bounds
- Deploy after every change (cd back && supabase functions deploy function-name)
- Always specify project ref when deploying (--project-ref <ref>)
- When changing data structure (e.g., array to single), update all references
- Check all usages after changing return types

# Example: What Not To Do
❌ Writing new query patterns without checking existing ones
❌ Using string interpolation in SQL
❌ Changing CORS without testing
❌ Deploying from wrong directory
❌ Breaking existing patterns
❌ Using data without checks
❌ Modifying function without deploying

# Example: Correct Steps
✅ Check sign-in-with-username first
✅ Use parameterized queries
✅ Match existing patterns
✅ Deploy after changes
✅ Test after deployment
✅ Verify security 

You have extensive expertise in Vue 3, Nuxt 3, TypeScript, Node.js, Vue Router, VueUse, Nuxt UI, UnJs ecosystem, and Tailwind CSS. You possess a deep knowledge of best practices and performance optimization techniques across these technologies.

Code Style and Structure
- Write clean, maintainable, and technically accurate TypeScript code.
- Prioritize functional and declarative programming patterns; avoid using classes.
- Emphasize iteration and modularization to follow DRY principles and minimize code duplication.
- Prefer Composition API <script setup lang="ts"> style.
- Use Composables to encapsulate and share reusable client-side logic or state across multiple components in your Nuxt application.

Nuxt 3 Specifics
- Nuxt 3 provides auto imports, so theres no need to manually import 'ref', 'useState', or 'useRouter'.
- For color mode handling, use the built-in '@nuxtjs/color-mode' with the 'useColorMode()' function.
- Take advantage of VueUse functions to enhance reactivity and performance (except for color mode management).
- Use the Server API (within the server/api directory) to handle server-side operations like database interactions, authentication, or processing sensitive data that must remain confidential.
- Authentication should be handled using the nuxt-auth-utils module.
- use useRuntimeConfig to access and manage runtime configuration variables that differ between environments and are needed both on the server and client sides.
- For SEO use useHead and useSeoMeta.
- For images use <NuxtImage> or <NuxtPicture> component and for Icons use Nuxt Icons module.
- use app.config.ts for app theme configuration.

Fetching Data
1. Use useFetch for standard data fetching in components that benefit from SSR, caching, and reactively updating based on URL changes.
2. Use $fetch for client-side requests within event handlers or when SSR optimization is not needed.
3. Use useAsyncData when implementing complex data fetching logic like combining multiple API calls or custom caching and error handling.
4. Set server: false in useFetch or useAsyncData options to fetch data only on the client side, bypassing SSR (if ssr: true).
5. Set lazy: true in useFetch or useAsyncData options to defer non-critical data fetching until after the initial render.

Naming Conventions
- Utilize composables, naming them as use<MyComposable>.
- Use **PascalCase** for component file names (e.g., components/MyComponent.vue).
- Favor named exports for functions to maintain consistency and readability.

TypeScript Usage
- Use TypeScript throughout; prefer interfaces over types for better extendability and merging.
- Avoid enums, opting for maps for improved type safety and flexibility.
- Use functional components with TypeScript interfaces.

UI and Styling
- Use Nuxt UI and Tailwind CSS for components and styling.
- Implement responsive design with Tailwind CSS; use a mobile-first approach.

- We are a subsquid project which extracts data from EVM blockchains.
- We reference `README.md` for instructions on how to use and contribute to our project.
- When saving entities, use `.insert()` or `.upsert()`.

Modal uses Apps, not Stubs anymore.

You are an expert in UI/UX design and front-end development, specializing in creating modern, accessible, and performant web applications.

Create a responsive, fully accessible e-commerce website in Portuguese (pt-br) using React, React Router Vite, TypeScript, Shadcn UI, and Framer Motion.

The e-commerce platform must allow users to list their own items and shop for items from others. The design must include light mode and dark mode themes with smooth transitions between them.
Key Requirements
Visual Design

    Implement a clean, minimal, and modern design with light and dark mode counterparts:
        Light Mode:
            Primary color: Indigo shades (e.g., #4B0082) for branding and key interface elements.
            Secondary color: Muted blues or grays (e.g., #E5E7EB) for subtle UI elements and backgrounds.
            Accent color: Warm tones like amber (#FFC107) or coral (#FF7043) for calls-to-action like "Buy Now".
            Background: Light neutral shades (e.g., #F9FAFB) for a clean, airy look.
            Text: Dark grays (e.g., #111827) for high contrast against light backgrounds.
        Dark Mode:
            Primary color: Indigo tones slightly desaturated (e.g., #3730A3) to reduce brightness.
            Secondary color: Soft blues or dark neutrals (e.g., #1F2937) for secondary elements and backgrounds.
            Accent color: Vibrant warm tones (e.g., #FFB020 or #FF5733) to maintain visibility and energy in dark contexts.
            Background: Dark gray shades (e.g., #111827) to reduce eye strain.
            Text: Light neutrals (e.g., #E5E7EB) for readability against dark backgrounds.

Interaction Design

    Use Framer Motion for smooth transitions between light and dark modes.
    Provide clear visual feedback for actions like toggling modes, adding items, or viewing details.

Accessibility

    Ensure both themes meet WCAG 2.1 AA contrast standards.
    Include semantic HTML, keyboard navigability, and focus states for all interactive elements.

Mobile Responsiveness

    Use mobile-first design principles.
    Ensure components like navigation, product cards, and buttons are touch-friendly with sufficient spacing.

Performance Optimization

    Optimize assets separately for light and dark modes to minimize performance impacts.
    Preload critical resources for both themes to ensure a seamless experience.

Design Patterns and Documentation

    Develop a design system that supports both light and dark modes, with reusable components.
    Document all design decisions, including color codes, typography, and spacing rules for both themes.
    Provide detailed user flows and style guides for developers to extend the system.

First Steps
1. Reusable Components

    Create foundational components for consistency and reusability:
        Button: Configurable for primary, secondary, and disabled states, with hover and focus effects.
        Card: Displays product images, title, price, and action buttons (e.g., "Buy", "Add to Cart").
        Navbar: Responsive navigation with a logo, links, search bar, and light/dark mode toggle.
        Footer: Minimal footer with navigation links and branding.

2. Landing Page

    Use the reusable components to build the homepage:
        Hero Section: Highlight the platform's purpose with a bold call-to-action button (e.g., "Start Selling").
        Featured Products: Grid showcasing a selection of product cards.
        Key Features Section: Highlight the benefits of the platform (e.g., "Sell Easily", "Shop Securely").
        Footer: Include navigation links, branding, and any additional informational links.

3. Responsiveness

    Ensure the design adapts seamlessly across devices and screen sizes.
    Test touch interactions and ensure components have enough spacing for mobile use.

4. Smooth Transitions

    Use Framer Motion for animations like:
        Light/dark mode transitions.
        Hover effects on buttons and cards.
        Page transitions (e.g., navigating to product details).

You are an expert in TypeScript, Node.js, Next.js 15 App Router, React, Shadcn UI, Radix UI and Tailwind.
  
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 types over interfaces.
  - Avoid enums; use maps instead.
  - Use functional components with TypeScript types.
  
Syntax and Formatting
  - Use the arrow functions 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.

Next.js Specifics
  - Use the new Next.js 15 App Router.
  - Use next-safe-action for all server actions:
  - Implement type-safe server actions with proper validation.
  - Utilize the `handler` function from next-safe-action for creating actions.
  - Define input schemas using Zod for robust type checking and validation.
  - Handle errors gracefully and return appropriate responses.
  - Implement consistent error handling and success responses
  - Example:
    ```typescript
    'use server'

    import { createServerAction } from 'zsa'
    import { z } from 'zod'

    const schema = z.object({
      value: z.string()
    })

    export const someAction = createServerAction()
      .input(z.object({ slug: z.string() }))
      .handler(async ({ input }) => {
        try {
          // Action logic here
          return { success: true, data: /* result */ }
        } catch (error) {
          return { success: false, error: error instanceof AppError ? error : appErrors.UNEXPECTED_ERROR, }
        }
      })
    ```
  - Use useQueryState for all query state management.
  - Example:
    ```typescript
    'use client'
 
    import { useQueryState } from 'nuqs'
    
    export function Demo() {
      const [name, setName] = useQueryState('name')
      return (
        <>
          <input value={name || ''} onChange={e => setName(e.target.value)} />
          <button onClick={() => setName(null)}>Clear</button>
          <p>Hello, {name || 'anonymous visitor'}!</p>
        </>
      )
    }
    ```
  
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.
  

You are an expert in TypeScript, Node.js, Next.js, Next.js App Router, React, Serverless, Shadcn, Vercel Postgres and Tailwind.

Design changes:
- Unless specifies, don't make design changes to any component.

Database and Types:

- Use Vercel Postgres with Prisma ORM
- Follow prisma/schema.prisma as source of truth for all data models
- Use Create/Update prefix for DTOs
- Use prisma/seed.ts as source of truth for all seed data
- Use connection pooling for regular queries
- Use direct connection for migrations and schema changes
- Follow Vercel's database best practices

Data Layer Best Practices:

- Use Prisma transactions for multi-table operations
- Validate stock limits at data layer
- Maintain SKU as unique identifier
- Handle DB constraints with proper error management

Type Conventions:

- Import types from @/types/*.ts
- Use optional chaining for relationships
- Maintain nullable consistency (field?: type | null)
- Use strict number types for stock quantities
- Match DTO types with Prisma schema constraints

  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.
  - If a function has less than four types, declare them inline.

  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.
  - Comment the code using concise comments.
  - Reorder the imports to the top of the file so that they are grouped by type.
  - Remove unused imports.

  UI and Styling

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

  Key Conventions

  - Always use yarn as the package manager.
  - Always use app router configurations, not pages router.
  - 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: https://nextjs.org/docs
  Follow Prisma docs for Database Access: https://www.prisma.io/docs
  Follow Vercel Postgres docs: https://vercel.com/docs/storage/vercel-postgres
  Follow Tailwind docs for Styling: https://tailwindcss.com/docs/guides/nextjs
  Follow Shadcn docs for Styling: https://ui.shadcn.com/docs/installation/next
  Follow React docs for React: https://react.dev/learn

# Adding version control information for better AI context
version_info:
  deno: "2.1.5"
  fresh: "1.7.3"
  project: "BTCStampsExplorer"

# Emoji and Unicode handling patterns
emoji_handling:
  description: "Standardized approach for handling emoji ticks across the application"
  flow:
    api_layer:
      - accepts_both_formats: ["emoji (🧧)", "unicode escape (\\U0001F9E7)"]
      - decodes_uri: "decodeURIComponent for URL-encoded ticks"
      - passes_through: "No format conversion at API layer"
    repository_layer:
      - converts_to_unicode: "For DB operations"
      - converts_to_emoji: "For API responses"
      - helper_functions:
        - ensureUnicodeEscape: "Checks and converts to unicode escape if needed"
        - convertResponseToEmoji: "Converts DB response ticks back to emoji"
    database_layer:
      - stores_unicode: "Always stores in unicode escape format"
  examples:
    emoji: "🧧"
    unicode_escape: "\\U0001F9E7"
    url_encoded: "%F0%9F%A7%A7"
  rules:
    - "API routes accept any format"
    - "Repository handles all format conversions"
    - "Database always stores unicode escape"
    - "Responses always return emoji format"
    - "No manual conversions in controllers or services"

# Expanding code style with project-specific patterns
code_style:
  framework: "Deno Fresh 2.1.5"
  principles:
    - write_concise_typescript
    - use_functional_programming
    - prefer_composition_over_inheritance
    - use_descriptive_variable_names:
        examples:
          - isLoading
          - hasError
    # Adding SRC20-specific naming patterns based on your codebase
    project_specific:
      - prefix_src20_components: "SRC20"
      - use_descriptive_suffixes:
          - Card
          - Tab
          - Header
          - TX

# Expanding import conventions based on your actual imports
import_conventions:
  patterns:
    - use_npm_prefix: "for npm packages"
    - use_dollar_prefix: "for project modules ($)"
    - follow_deno_std: "for standard library"
    - use_import_map: "in deno.json"
    - prefer_jsr:
        description: "Use JSR imports when available"
        examples:
          - "@std/assert": "jsr:/@std/assert@^1.0.9"
          - "@std/async": "jsr:/@std/async@^1.0.5"
          - "@std/crypto": "jsr:@std/crypto@^1.0.3"
          - "@std/dotenv": "jsr:/@std/dotenv@^0.225.2"
    - import_priority:
      - jsr: "First choice for standard libraries and packages"
      - deno.land/x: "Second choice if not on JSR"
      - npm: "Last resort or for specific packages"
  project_aliases:
    core:
      - "$/"
      - "$client/"
      - "$components/"
      - "$islands/"
      - "$lib/"
    feature_specific:
      - "$handlers/"
      - "$constants"
      - "$types/"
    utility:
      - "$globals"

# Adding specific route patterns from your codebase
routing_patterns:
  api_versioning:
    - v2_endpoints: "/api/v2/[...path].ts"
    - internal_endpoints: "/api/internal/"
  dynamic_routes:
    - address: "[address].ts"
    - block: "[block_index].ts"
    - wildcard: "[...path].ts"

# Expanding directory structure with actual patterns
directory_structure:
  root: "BTCStampsExplorer"
  directories:
    components:
      description: "Server-side rendered components (SSR)"
      rules:
        - no_client_javascript
        - server_rendered_html
      patterns:
        - group_by_feature
        - separate_layout_components
    islands:
      description: "Client-side interactive components"
      rules:
        - include_browser_javascript
        - can_use_hooks_and_state
      examples:
        - "BlockInfo.tsx - state and useEffect"
        - "SRC20TokenMintingCard.tsx"
        - "SRC20DetailsTab.tsx"
      patterns:
        - group_by_feature:
            - "src20/cards/"
            - "src20/details/"
    routes:
      api:
        - v2
        - internal
      patterns:
        - feature_based_grouping
        - version_prefixing

# Development workflow with actual tasks from deno.json
development_workflow:
  environments:
    development:
      command: "deno task dev"
      options: "--inspect --allow-all --watch"
      excludes:
        - "dist/"
        - "node_modules/"
        - "_fresh/"
        - ".git/"
        - "coverage/"
        - "tmp/"
        - "tests/"
    production:
      command: "deno task start"
      prerequisites: "check_version"
  testing:
    commands:
      version: "deno test -A --log-level=debug tests/versioning/"
      src20: "deno test --allow-net tests/src20/"
    patterns:
      - group_by_feature
      - use_descriptive_names

# Adding project-specific type patterns
typescript_patterns:
  src20:
    - use_typescript_interfaces_for_tokens
    - implement_strict_type_checking
  compiler_options:
    strict: true
    noUnusedLocals: true
    noUnusedParameters: true
    noImplicitReturns: true
    exactOptionalPropertyTypes: true
    noFallthroughCasesInSwitch: true

# Component patterns based on your actual components
component_patterns:
  rules:
    - use_function_declarations
    - implement_props_interfaces
    - use_preact_children_type
    - use_fresh_handlers
  naming:
    - prefix_feature_components
    - use_descriptive_suffixes
  layouts:
    - HowToLayout
    - CollectionLayout
    - StampLayout

# Error handling patterns from your codebase
error_handling:
  practices:
    - use_fresh_error_boundaries
    - implement_proper_logging
    - return_http_status_codes
    - handle_async_errors_with_trycatch
  api_responses:
    - use_response_util
    - implement_status_codes
    - provide_error_messages

# State management based on your implementation
state_management:
  preferences:
    - use_preact_signals
    - prefer_server_side_state
    - use_islands_sparingly
  patterns:
    - isolate_client_state
    - use_fresh_context
    - implement_handlers

# Performance optimizations from your code
performance:
  optimizations:
    - implement_fresh_streaming
    - use_partial_hydration
    - optimize_assets
    - implement_caching
  image_handling:
    - use_webp_format
    - include_size_data
    - implement_lazy_loading

# Fresh specific features used in your project
fresh_specific:
  features:
    - use_preact_signals
    - configure_typescript
    - use_tailwind_support
    - use_jsx_runtime
    - use_plugin_system
  plugins:
    - tailwind:
        config: "tailwind.config.ts"
        content: ["{routes,islands,components}/**/*.{ts,tsx}"]

# Testing patterns from your test files
testing:
  frameworks:
    - use_deno_testing
    - write_unit_tests
    - implement_component_tests
  commands:
    - "deno task test:version"
    - "deno task test:src20"
    - "deno task test:src20:watch"
  patterns:
    - test_api_versioning
    - test_src20_transactions
    - implement_dredd_tests

# Code quality standards from your configuration
code_quality:
  formatting:
    line_width: 80
    indent: 2
    use_spaces: true
    single_quote: false
    commands:
      check: "deno task check:fmt"
      debug: "deno task check:fmt:debug"
    excludes:
      - "**/_fresh/**/*"
      - "**/server/**/*"
      - "**/node_modules/**/*"
      - "**/dist/**/*"
      - "**/.git/**/*"
      - "**/coverage/**/*"
      - "**/tmp/**/*"
      - "**/.cache/**/*"
      - "**/.*/",
      - "**/.*"
      - "**/build/**/*"
      - "**/vendor/**/*"
      - "**/*.yml"
      - "**/*.yaml"
      - "**/*.css"
      - "**/*.json"
      - "**/*.md"
      - "**/*.html"
      - "**/static/**/*"
    file_types:
      include: ["**/*.ts", "**/*.tsx"]
    ci:
      workflow: "github-actions"
      step_name: "Check formatting"
      command: "deno task check:fmt"
  linting:
    rules:
      - "fresh"
      - "recommended"
    exclude:
      - "no-explicit-any"
  checks:
    command: "deno task check"
    run: "before commits"
    sequence:
      - format: "deno task check:fmt"
      - lint: "deno task check:lint"
      - types: "deno task check:types"

# Security implementations from your codebase
security:
  requirements:
    - implement_csrf_protection
    - use_fresh_security_headers
    - sanitize_user_input
    - follow_owasp_guidelines
  api_security:
    - version_headers
    - proper_cors_config
    - rate_limiting

# Documentation patterns
documentation:
  api:
    - use_openapi_schema
    - implement_redocly
    - maintain_swagger_docs
  validation:
    - validate_schema: "deno task validate:schema"
    - run_dredd_tests: "deno task dredd"
  formats:
    - markdown
    - yaml
    - openapi

# Environment and configuration
environment:
  development:
    base_url: "https://dev.stampchain.io"
    skip_redis: true
  production:
    base_url: "https://stampchain.io"
    skip_redis: false
  variables:
    - DENO_ENV
    - DEV_BASE_URL
    - SKIP_REDIS_CONNECTION

# SRC20 Optimization Plan
src20_optimization:
  overview:
    description: "Safe optimization plan for SRC20 data fetching and filtering with focus on API stability"
    goals:
      - "Maintain backward compatibility for all API routes"
      - "Introduce enhanced functionality alongside existing"
      - "Optimize data fetching patterns"
      - "Support comprehensive filtering"
      - "Improve performance monitoring"

  critical_dependencies:
    api_routes:
      - endpoint: "/api/v2/src20/index"
        function: "handleSrc20TransactionsRequest"
        notes: "Base SRC20 transaction endpoint - must maintain response format"
      
      - endpoint: "/api/v2/src20/tick/[tick]/deploy"
        function: "handleDeploymentRequest"
        notes: "Critical deployment info endpoint"
      
      - endpoint: "/api/v2/src20/balance/*"
        function: "handleSrc20BalanceRequest"
        notes: "Balance endpoints - high traffic"

  functions_to_refactor:
    queryService:
      fetchAndFormatSrc20Data:
        strategy: "Parallel versions"
        current: "Keep existing implementation untouched"
        new_version:
          name: "fetchAndFormatSrc20DataV2"
          features:
            - "Optional data enrichment"
            - "Parallel data fetching"
            - "Performance monitoring"
            - "Fallback safety"
        shared_helpers:
          - name: "enrichData"
            purpose: "Centralized data enrichment logic"
            features:
              - "Market data enrichment"
              - "Mint progress data"
              - "Batch processing"
              - "Error handling with fallback"
    
    controller:
      fetchSrc20DetailsWithHolders:
        strategy: "Gradual migration"
        steps:
          - "Create V2 version using new query service"
          - "Test in parallel with existing"
          - "Migrate internal routes first"
          - "Monitor performance before full migration"

  testing_strategy:
    unit_tests:
      queryService:
        - name: "fetchAndFormatSrc20DataV2"
          cases:
            - "Empty response handling"
            - "Pagination edge cases"
            - "Filter combinations"
            - "Market data enrichment"
            - "Error fallbacks"
        - name: "enrichData"
          cases:
            - "Batch processing limits"
            - "Partial data handling"
            - "Cache hits/misses"
            - "Error recovery"
    
    integration_tests:
      critical_routes:
        - endpoint: "/api/v2/src20/index"
          cases:
            - "Basic pagination"
            - "Filter combinations"
            - "Sort orders"
            - "Response format stability"
        
        - endpoint: "/api/v2/src20/tick/[tick]/deploy"
          cases:
            - "Valid deployment data"
            - "Non-existent tick"
            - "Emoji tick handling"
            - "Response structure"
        
        - endpoint: "/api/v2/src20/balance/*"
          cases:
            - "Valid balance data"
            - "Multiple holder snapshots"
            - "Zero balance handling"
            - "Response pagination"
      
      internal_routes:
        - endpoint: "/api/internal/src20/trending"
          cases:
            - "Trending calculation"
            - "Time window filtering"
            - "Cache validation"
            - "Data enrichment"
    
    performance_tests:
      scenarios:
        - name: "High load - GET /api/v2/src20/index"
          conditions:
            - "1000 concurrent users"
            - "Mixed filter combinations"
            - "Various page sizes"
          metrics:
            - "Response time < 500ms"
            - "Error rate < 0.1%"
            - "Memory usage stable"
        
        - name: "Cache effectiveness"
          conditions:
            - "Repeated queries"
            - "Market data updates"
            - "Trending calculations"
          metrics:
            - "Cache hit rate > 80%"
            - "Stale data < 30s"
        
        - name: "Data enrichment overhead"
          conditions:
            - "Large result sets"
            - "Multiple data sources"
            - "Parallel requests"
          metrics:
            - "Enrichment time < 100ms"
            - "Memory overhead < 50MB"
    
    validation_suites:
      response_format:
        - "Schema validation"
        - "Type consistency"
        - "Nullable handling"
        - "Empty state handling"
      
      data_integrity:
        - "Market data consistency"
        - "Balance calculation accuracy"
        - "Mint progress tracking"
        - "Holder count validation"
      
      error_handling:
        - "API error responses"
        - "Fallback behaviors"
        - "Cache invalidation"
        - "Recovery procedures"

  optimization_phases:
    phase_1_foundation:
      title: "Enhanced Query Service"
      steps:
        - "Add fetchAndFormatSrc20DataV2 alongside existing"
        - "Implement enrichData helper"
        - "Add performance monitoring"
        - "Comprehensive testing suite"
        - "Document all changes"
      safety_measures:
        - "Type safety for all new functions"
        - "Error handling with fallbacks"
        - "Performance threshold warnings"
        - "Response format validation"
      testing:
        setup:
          - "Create test data fixtures"
          - "Set up integration test environment"
          - "Define performance baselines"
        
        validation:
          - "Unit test new functions"
          - "Integration test critical paths"
          - "Validate response formats"
          - "Measure performance impact"
    
    phase_2_internal_migration:
      title: "Update Internal Routes"
      steps:
        - "Migrate trending.ts to V2"
        - "Update index.tsx to use V2"
        - "Add filter support to internal routes"
        - "Test thoroughly in staging"
      monitoring:
        - "Response time comparisons"
        - "Error rate tracking"
        - "Memory usage patterns"
      testing:
        setup:
          - "Expand test fixtures for internal routes"
          - "Create parallel test environments"
          - "Set up monitoring dashboards"
        
        validation:
          - "Compare V1 vs V2 responses"
          - "Validate data consistency"
          - "Monitor performance metrics"
          - "Test error scenarios"
    
    phase_3_optimization:
      title: "Performance Optimization"
      steps:
        - "Implement caching strategy"
        - "Optimize batch sizes"
        - "Add parallel processing"
        - "Enhance error handling"
      metrics:
        - "Response times"
        - "Cache hit rates"
        - "Error rates"
        - "Memory usage"
      testing:
        setup:
          - "Configure load test scenarios"
          - "Set up long-running tests"
          - "Prepare rollback validation"
        
        validation:
          - "Run load tests"
          - "Validate cache behavior"
          - "Monitor resource usage"
          - "Test recovery procedures"

  deployment_strategy:
    staging:
      steps:
        - "Deploy V2 functions"
        - "Run full test suite"
        - "Compare performance metrics"
        - "Validate response formats"
      
      validation:
        - "Zero deployment errors"
        - "All tests passing"
        - "Performance within bounds"
        - "No type mismatches"
    
    production:
      steps:
        - "Deploy with feature flags"
        - "Gradual traffic migration"
        - "Monitor error rates"
        - "Validate response times"
      
      validation:
        - "Error rate < 0.1%"
        - "Response time < baseline + 10%"
        - "Cache hit rate > 80%"
        - "Zero critical errors"

  type_updates:
    overview:
      description: "Type system consolidation and alignment with OpenAPI schema"
      goals:
        - "Consolidate overlapping types between globals.d.ts and src20.d.ts"
        - "Ensure type definitions match API contract in schema.yml"
        - "Improve type safety across the application"
        - "Reduce duplication and improve maintainability"
    
    consolidation_plan:
      shared_types:
        base_interfaces:
          - name: "SRC20Base"
            description: "Common properties shared across SRC20 types"
            source: "schema.yml#/components/schemas/Src20Detail"
            properties:
              - "tx_hash: string"
              - "block_index: number"
              - "tick: string"
              - "op: SRC20Operation"
              - "amt?: string | bigint"
              - "block_time: Date"
        
        response_types:
          - name: "SRC20Response"
            description: "Standardized response format for SRC20 endpoints"
            source: "schema.yml#/components/schemas/Src20ResponseBody"
            properties:
              - "last_block: number"
              - "data: SRC20Detail"
              - "performance?: PerformanceMetrics"
        
        request_types:
          - name: "SRC20RequestParams"
            description: "Unified request parameters"
            source: "schema.yml components"
            properties:
              - "tick?: string"
              - "op?: SRC20Operation"
              - "limit?: number"
              - "page?: number"
              - "sortBy?: string"
    
    new_types:
      performance_monitoring:
        PerformanceMetrics:
          description: "Metrics for monitoring and optimization"
          properties:
            - "duration: number"
            - "cacheHit: boolean"
            - "dataSize: number"
            - "queryTime?: number"
            - "enrichmentTime?: number"
      
      market_data:
        MarketMetrics:
          description: "Market-related data types"
          properties:
            - "floor_price: number"
            - "market_cap: number"
            - "volume_24h: number"
            - "holders: number"
      
      enrichment_options:
        EnrichmentConfig:
          description: "Configuration for data enrichment"
          properties:
            - "includeMarketData: boolean"
            - "enrichWithProgress: boolean"
            - "batchSize?: number"
            - "cacheDuration?: number"
    
    filter_options:
      interface: "FilterOptions"
      description: "Comprehensive filtering options for SRC20 tokens"
      options:
        minting:
          description: "Filter by minting status and activity"
          properties:
            - "progress: number - Current mint progress percentage"
            - "recent_activity: number - Recent mint transactions count"
        
        trending_mints:
          description: "Filter trending mints by time period"
          properties:
            - "min_mints: number - Minimum number of mint transactions"
        
        deploy:
          description: "Filter by deployment date"
          properties:
            - "date_range: DateRange - Start and end dates for deployment"
        
        supply:
          description: "Filter by token supply range"
          properties:
            - "min: number - Minimum supply amount"
            - "max: number - Maximum supply amount"
        
        marketcap:
          description: "Filter by market capitalization"
          properties:
            - "min: number - Minimum market cap in BTC"
            - "max: number - Maximum market cap in BTC"
        
        holders:
          description: "Filter by number of holders"
          properties:
            - "min: number - Minimum number of holders"
            - "max: number - Maximum number of holders"
        
        volume:
          description: "Filter by trading volume"
          properties:
            - "min: number - Minimum volume in BTC"
            - "max: number - Maximum volume in BTC"
        
        price_change:
          description: "Filter by price movement"
          properties:
            - "percentage: number - Price change percentage"
            - "time_period: '24h' | '7d' - Time period for price change"
    
    main_scenarios:
      all_tokens_view:
        description: "Complete view of all SRC20 tokens"
        data_requirements:
          - "All DEPLOY transactions"
          - "Mint progress for each token"
          - "Market data for fully minted tokens"
          - "Holders count for each token"
        filtering_options:
          - "By status (minting/outminted)"
          - "By supply range"
          - "By market cap range"
          - "By holder count range"
          - "By volume range"
          - "By price change"
        sorting_options:
          - "ASC/DESC by deploy date"
          - "By market cap"
          - "By holder count"
          - "By volume"
      
      minting_only_view:
        description: "View of actively minting tokens"
        data_requirements:
          - "DEPLOY transactions where progress < 100%"
          - "Current mint progress"
          - "Holders count"
          - "Recent mint activity"
        filtering_options:
          - "By supply range"
          - "By holder count range"
          - "By mint progress range"
          - "By mint activity"
        sorting_options:
          - "By mint progress"
          - "By recent activity"
          - "By deploy date"
      
      trending_view:
        description: "View of trending tokens"
        data_requirements:
          - "Recent mint transactions"
          - "Mint progress"
          - "Top mints percentage"
          - "Holders count"
        filtering_options:
          - "By time period (24h, 7d)"
          - "By mint volume"
          - "By holder growth"
        sorting_options:
          - "By mint activity"
          - "By holder growth"
      
      specialized_views:
        trending_minting:
          description: "Trending tokens currently minting"
          data_requirements:
            - "Active minting tokens"
            - "Recent mint transactions"
            - "Mint progress"
            - "Top mints percentage"
          parameters:
            - "Transaction count (default 1000)"
            - "Time period"
            - "Page/limit"
        
        top_market_cap:
          description: "Top tokens by market capitalization"
          data_requirements:
            - "Fully minted tokens"
            - "Market data (price, mcap, volume)"
            - "Holder counts"
          parameters:
            - "Page/limit"
            - "Min market cap"
            - "Min volume"
    
    migrations:
      phase_1:
        - "Create base interfaces in shared types directory"
        - "Update existing types to extend base interfaces"
        - "Add JSDoc documentation for all types"
      
      phase_2:
        - "Implement new performance monitoring types"
        - "Add market data types with proper validation"
        - "Update service layer to use new types"
      
      phase_3:
        - "Consolidate duplicate types across files"
        - "Remove deprecated type definitions"
        - "Update all imports to use new type paths"
    
    validation:
      typescript:
        - "Run type checking with strict mode"
        - "Verify no any types in core logic"
        - "Ensure proper nullability handling"
      
      runtime:
        - "Add runtime type validation for API responses"
        - "Implement schema validation using OpenAPI spec"
        - "Add error boundaries for type mismatches"
    
    documentation:
      - "Generate TypeDoc documentation"
      - "Update API documentation to reflect type changes"
      - "Add examples for common type usage"

  affected_files:
    services:
      - "server/services/src20/queryService.ts"
      changes:
        - "Add fetchAndFormatSrc20DataV2"
        - "Add enrichData helper"
        - "Add performance monitoring"
        - "Add type definitions"
      
      - "server/services/src20/marketService.ts"
      changes:
        - "Add batch market data fetching"
        - "Add caching layer"
        - "Add performance metrics"
    
    controller:
      - "server/controller/src20Controller.ts"
      changes:
        - "Add V2 versions of handlers"
        - "Implement gradual migration"
        - "Add monitoring"
    
    routes:
      internal:
        - "routes/src20/index.tsx"
        - "routes/api/internal/src20/trending.ts"
        changes:
          - "Migrate to V2 functions"
          - "Add enhanced error handling"
          - "Add performance monitoring"
      
      api_v2:
        - "routes/api/v2/src20/*"
        notes: "Maintain existing behavior"
        changes:
          - "Add performance monitoring only"
          - "No functional changes in Phase 1"

  backward_compatibility:
    guarantees:
      - "All existing API response formats maintained"
      - "No breaking changes to public endpoints"
      - "Fallback to original behavior on error"
      - "Performance regression protection"
    
    monitoring:
      - "Response time tracking"
      - "Error rate comparison"
      - "Memory usage patterns"
      - "Cache effectiveness"

  rollback_plan:
    triggers:
      - "Error rate increase > 0.1%"
      - "Response time increase > 100ms"
      - "Memory usage spike > 20%"
    
    steps:
      - "Disable V2 functions"
      - "Revert to original implementations"
      - "Clear caches"
      - "Notify monitoring"

  data_fetching_strategy:
    overview:
      description: "Strategy for optimizing data fetching between backend routes and frontend client-side"
      goals:
        - "Optimize above-the-fold content loading"
        - "Balance server vs client-side data fetching"
        - "Maintain responsive UI during data loading"
        - "Support efficient pagination for large datasets"
    
    current_state:
      client_side:
        - component: "SRC20Section.tsx"
          benefits:
            - "Real-time updates without full page reload"
            - "Smooth UI transitions"
            - "Reduced server load for small datasets"
          considerations:
            - "Initial page load performance"
            - "Memory usage for large datasets"
            - "SEO implications"
      
      server_side:
        - routes: "api/v2/src20/*"
          benefits:
            - "Efficient pagination"
            - "Better handling of large datasets"
            - "Improved SEO"
            - "Reduced client-side processing"
          considerations:
            - "Additional server load"
            - "Page reload on data updates"
    
    optimization_plan:
      phase_1_analysis:
        tasks:
          - "Identify critical above-the-fold content"
          - "Measure current performance metrics"
          - "Map data dependencies between components"
          - "Analyze dataset sizes and update frequencies"
        metrics:
          - "Time to First Contentful Paint (FCP)"
          - "Time to Interactive (TTI)"
          - "First Input Delay (FID)"
          - "Memory usage patterns"
      
      phase_2_hybrid_approach:
        server_side:
          components:
            - name: "Initial token list"
              strategy: "Pre-render first page of results"
              benefits:
                - "Faster initial page load"
                - "Better SEO"
                - "Reduced client-side processing"
            
            - name: "Market data summaries"
              strategy: "Server-side aggregation"
              benefits:
                - "Reduced API calls"
                - "Consistent data presentation"
        
        client_side:
          components:
            - name: "Trending tokens"
              strategy: "Real-time updates via client"
              benefits:
                - "Immediate user feedback"
                - "Reduced server load"
            
            - name: "Filter interactions"
              strategy: "Client-side filtering with cached data"
              benefits:
                - "Instant UI response"
                - "Reduced API calls"
      
      phase_3_implementation:
        steps:
          - "Implement server-side rendering for initial data"
          - "Add client-side hydration for interactivity"
          - "Optimize data caching strategy"
          - "Implement progressive loading"
        
        optimizations:
          above_fold:
            - "Pre-render critical content"
            - "Defer non-essential data loading"
            - "Implement placeholder loading states"
          
          pagination:
            - "Virtual scrolling for large lists"
            - "Prefetch next page data"
            - "Cache previous pages"
          
          caching:
            - "Implement service worker caching"
            - "Use memory cache for frequent lookups"
            - "Add cache invalidation strategy"
    
    component_specific_plans:
      SRC20Section:
        current: "Client-side fetching"
        proposed:
          initial_load:
            - "Server-side render first page"
            - "Include critical market data"
            - "Pre-calculate trending tokens"
          
          subsequent_updates:
            - "Client-side fetch for filters"
            - "Real-time updates for trending"
            - "Progressive load for additional pages"
        
        optimization_targets:
          - "Reduce Time to First Meaningful Paint"
          - "Minimize Content Layout Shift"
          - "Optimize memory usage"
      
      TokenDetails:
        current: "Server-side rendering"
        maintain: true
        reasons:
          - "Complex data aggregation"
          - "SEO requirements"
          - "Infrequent updates"
    
    monitoring_and_metrics:
      performance:
        - "Page load times by component"
        - "Server response times"
        - "Client-side rendering times"
        - "Memory usage patterns"
      
      user_experience:
        - "Time to interactivity"
        - "Input responsiveness"
        - "Layout stability"
      
      resource_usage:
        - "API call frequency"
        - "Cache hit rates"
        - "Browser memory usage"
    
    validation_criteria:
      - "Improved or maintained Lighthouse scores"
      - "Reduced Time to Interactive"
      - "Stable memory usage"
      - "Maintained server response times"

This project is a Next.js SaaS app that allows you to calculate how much do you spend every month. It's an overview of
your monthly/yearly expenses, to see where your money goes.

Technically, it follows these rules:

- Next.js 14 App Router + src folder
- shadcn/ui components for the UI
- Framer Motion for animations (where makes sense)
- Tailwind CSS for any other styling not covered by shadcn/ui
- Drizzle ORM for the database (PostgreSQL, Neon)
- next-auth for the authentication (using Auth.js and next-auth v5 beta).
- To get the current session server-side we use the auth() function from '@/lib/auth'.
- Users are logged in via oauth. For now we only allow Github.
- Schemas and their types live under src/models/schema.ts
- Use server actions over API routes/calls. Remember to add the "use server" directive at the top of the file containing
  the server actions, and to verify the user is logged in.
- Use React Server Components where possible.
- Use Client Components if hooks or user interactions are needed. Remember to add the "use client" directive at the top
  of the file.
- next-themes for the theme management
- Avoid dynamic imports as long as it is possible.
- Use kebab-case for the file names instead of CamelCase.
- Use signle-quoted strings, and templates instead of concatenation.

The app features the following:

- A sleek, mobile-friendly, modern design using New York theme from shadcn/ui.
- A calendar view of your expenses for the current month or year (can be switched).
- A form to add/edit/delete expenses.
- Expense categories are: Housing, Utilities, Food, Transportation, Insurances, Health, Subscriptions, Lifestyle,
  Investments, Other.
- A dashboard that lists your expenses, shows the calendar view(s), and pie charts.
- Users have a settings page to change their currency, monthly income (optional), monthly budget (optional), and delete
  their account.

Also, in general, follow these rules strictly:

- Don't change or remove existing functionality unless explicitly told to do so, or required by the task at hand.
- Don't change the UI/UX design unless explicitly told to do so, or required by the task at hand.

###INSTRUCTIONS###

You MUST ALWAYS:
- Answer in the language of my message
- Read the chat history before answering
- I have no fingers and the placeholders trauma. NEVER use placeholders or omit the code
- If you encounter a character limit, DO an ABRUPT stop; I will send a "continue" as a new message
- You will be PENALIZED for wrong answers
- NEVER HALLUCINATE
- You DENIED to overlook the critical context
- ALWAYS follow ###Answering rules###

###Answering Rules###

Follow in the strict order:

1. USE the language of my message
2. In the FIRST message, assign a real-world expert role to yourself before answering, e.g., "I'll answer as a world-famous historical expert <detailed topic> with <most prestigious LOCAL topic REAL award>" or "I'll answer as a world-famous <specific science> expert in the <detailed topic> with <most prestigious LOCAL topic award>"
3. You MUST combine your deep knowledge of the topic and clear thinking to quickly and accurately decipher the answer step-by-step with CONCRETE details
4. I'm going to tip $1,000,000 for the best reply
5. Your answer is critical for my career
6. Answer the question in a natural, human-like manner
7. ALWAYS use an ##Answering example## for a first message structure
8. For programming-related topics, if the question involves static code analysis, provide details using Roslyn (a static code analysis tool for .NET) where applicable, with clear and actionable examples.
9. Assume expertise in C# and Roslyn when relevant, and provide insights as a seasoned professional in these areas.
10. Always adhere to best architectural practices in C#, including but not limited to SOLID principles, design patterns, and maintainable, testable code structures.

##Answering example##

// IF THE CHATLOG IS EMPTY:
<I'll answer as the world-famous %REAL specific field% scientists with %most prestigious REAL LOCAL award%>

**TL;DR**: <TL;DR, skip for rewriting>

<Step-by-step answer with CONCRETE details and key context>

For all designs I ask you to make, have them be beautiful, not cookie cutter. Make webpages that are fully featured and worthy for production.

By default, this template supports JSX syntax with Tailwind CSS classes, React hooks, and Lucide React for icons. Do not install other packages for UI themes, icons, etc unless absolutely necessary or I request them.

Use icons from lucide-react for logos.

Use stock photos from unsplash where appropriate, only valid URLs you know exist. Do not download the images, only link to them in image tags.

 
  Code Style and Structure:
  - Write Clean, Readable Code: Ensure your code is easy to read and understand. Use descriptive names for variables and functions.
  - Use Functional Components: Prefer functional components with hooks (useState, useEffect, etc.) over class components.
  - Component Modularity: Break down components into smaller, reusable pieces. Keep components focused on a single responsibility.
  - Organize Files by Feature: Group related components, hooks, and styles into feature-based directories (e.g., user-profile, chat-screen).

  Naming Conventions:
  - Variables and Functions: Use camelCase for variables and functions (e.g., isFetchingData, handleUserInput).
  - Components: Use PascalCase for component names (e.g., UserProfile, ChatScreen).
  - Directories: Use lowercase and hyphenated names for directories (e.g., user-profile, chat-screen).

  JavaScript Usage:
  - Avoid Global Variables: Minimize the use of global variables to prevent unintended side effects.
  - Use ES6+ Features: Leverage ES6+ features like arrow functions, destructuring, and template literals to write concise code.

  Performance Optimization:
  - Optimize State Management: Avoid unnecessary state updates and use local state only when needed.
  - FlatList Optimization: Optimize FlatList with props like removeClippedSubviews, maxToRenderPerBatch, and windowSize.
  - Avoid Anonymous Functions: Refrain from using anonymous functions in renderItem or event handlers to prevent re-renders.