Awesome Cursor Rules Collection

# Knative Benchmark Project Rules

## 1. Infrastructure Requirements

- All infrastructure must be deployed on Google Cloud Engine (GCE)
- Kubernetes cluster must be created and managed using kops
- Knative components and benchmark functions must run on separate nodes from the workload generator
- Use node labels and taints/tolerations to ensure proper workload separation

## 2. Workload Generator Requirements

- Must be written in Go
- Must be containerized and run as a Kubernetes Deployment
- No use of existing load testing tools (e.g., k6, Apache JMeter, etc.)
- Must support configurable:
  - Request rates (requests per second)
  - Payload sizes
  - Distribution patterns (constant rate, burst patterns)
  - Number of concurrent connections
  - Test duration

## 3. Observability Requirements

- Must implement OpenTelemetry collector for metrics collection
- Must configure Knative components to export metrics to OpenTelemetry
- Must collect the following metrics:
  - Latency (p50, p95, p99)
  - Throughput (requests/sec)
  - Cold start times
  - Resource utilization (CPU, Memory)
  - Error rates

## 4. Test Scenarios

### Scenario 1: Resource Configuration
- Test functions with varying CPU/memory allocations
- Measure performance impact of different resource configurations
- Include CPU and memory-intensive workloads

### Scenario 2: Language Framework Comparison
- Implement equivalent functions in:
  - Go
  - Python
  - Java
  - Node.js
- Use identical workloads across languages
- Measure cold/warm start times and resource usage

### Scenario 3: Eventing Performance
- Test Knative Eventing with producer/consumer pattern
- Measure event propagation latency
- Test different event sizes and throughput rates

## 5. Project Structure Requirements

- Use `just` command runner for automation
- Maintain separate directories for:
  - Infrastructure code (we use a sub repo for this)
  - Workload generator
  - Storage module (implement csv file storage for benchmark results)
  - Test functions
  - Deployment manifests
  - Analysis scripts

## 6. Code Quality Requirements

- All Go code must:
  - Include unit tests
  - Follow Go best practices
  - Never use inline if err syntax. Always check the error after with if err != nil{ ...}

## 7. Documentation Requirements

- Include detailed setup instructions
- Document all metrics collected
- Provide analysis of results
- Include troubleshooting guide
- Document all configuration parameters

## 8. Reproducibility Requirements

- All tests must be reproducible
- Include scripts for cluster creation/teardown
- Document all environment variables
- Include version information for all components

// React + GraphQL (Apollo Client) .cursorrules

// Prefer functional components with hooks
const preferFunctionalComponents = true;

// GraphQL and Apollo Client best practices
const graphqlBestPractices = [
  "Use Apollo Client for state management and data fetching",
  "Implement query components for data fetching",
  "Utilize mutations for data modifications",
  "Use fragments for reusable query parts",
  "Implement proper error handling and loading states",
];

// Folder structure
const folderStructure = `
src/
  components/
  graphql/
    queries/
    mutations/
    fragments/
  hooks/
  pages/
  utils/
`;

// Additional instructions
const additionalInstructions = `
1. Use Apollo Provider at the root of your app
2. Implement custom hooks for Apollo operations
3. Use TypeScript for type safety with GraphQL operations
4. Utilize Apollo Client's caching capabilities
5. Implement proper error boundaries for GraphQL errors
6. Use Apollo Client DevTools for debugging
7. Follow naming conventions for queries, mutations, and fragments
`;

- 這個專案使用 Tauri2.0 Vue3 開發
- 目的：開發一個桌面應用程式，可以顯示一個 QR code，讓手機web 掃描後，用web socket 連線到桌面應用程式，並且接手手機端的陀螺儀資訊進而操控滑鼠

  "dependencies": {
    "@tauri-apps/api": "^2.1.1",
    "@tauri-apps/plugin-shell": "^2",
    "vue": "^3.3.4"
  },
  "devDependencies": {
    "@vitejs/plugin-vue": "^5.0.5",
    "typescript": "^5.2.2",
    "vite": "^5.3.1",
    "vue-tsc": "^2.0.22",
    "@tauri-apps/cli": "^2.1.0"
  }

# Cursor Rules for Enhancing Java Learning with AI Assistance

# General Guidelines
1. **Model Selection**:
   - Use GitHub Copilot for rapid code generation and quick fixes.
   - Turn to Claude for understanding complex concepts and exploring creative solutions.
   - Leverage Cursor for in-depth learning and project-specific guidance.

2. **Effective Prompting Techniques**:
   - Start with a clear objective: Define the task or question precisely.
   - Provide essential context: Include relevant information, code snippets, or examples.
   - Be specific about desired output: Specify the format, level of detail, or any constraints.
   - Experiment and iterate: Analyze the model's output and refine your prompt based on feedback.

# Concept-Specific Prompts
3. **Gradle Build Tool**:
   - Task: Explain the core concepts of Gradle and provide a basic example.
   - Prompt: Describe the purpose of Gradle, key components of a `build.gradle` file, and provide a simple example.

4. **Algorithm Development**:
   - Task: Guide through developing an efficient algorithm for sorting an array.
   - Prompt: State the problem, suggest suitable algorithms, and request a Java implementation.

# Leveraging AI Models
5. **Cursor Features**:
   - Use custom `.cursorrules` for tailored assistance and inline documentation.
   - AI-Powered Code Generation: Generate code snippets, refactor existing code, or create functions based on natural language descriptions.

# Learning Pathway
6. **Formal Learning**:
   - Supplement coursework with AI assistance for clarifications and code examples.
7. **Informal Learning**:
   - Explore open-source projects and tackle coding challenges on platforms like LeetCode.
8. **Project-Based Learning**:
   - Define project goals, break tasks down, and seek feedback.

# Documentation and Reference Materials
9. **Generate Comprehensive Documentation**:
   - Leverage AI to create clear and concise explanations of your code, algorithms, and design decisions.
10. **Build a Personalized Knowledge Base**:
    - Compile AI-generated explanations, code examples, and best practices into a reference document for future use.

# Conclusion
11. **Balance AI Assistance with Independent Problem-Solving**:
    - Use AI as a tool to enhance your learning, not replace it. Strive to develop your own critical thinking and problem-solving skills.

# Additional Notes
12. **Iterative Prompt Development**:
    - Start with a clear objective, provide essential context, be specific about desired output, and iterate based on model feedback.

# ResearchGraph Project Overview

!!!
Very important: Document all work in the .logs folder. For example, these files are already in the .logs folder:
- .logs/PROGRESS.md: Any new features should be documented here, with a short description and date
- .logs/REFACTOR.md: Any refactoring should be documented here, with a short description and date
- .logs/ISSUES.md: When working on any issues, always check if they are listed here already. If they are, add a comment to the issue with the date and your progress. If they are not, add the issue to the list.
!!!

## Project Structure

```
research-planner/
├── app/                      # Next.js app directory
│   ├── api/                  # API routes
│   │   └── autocomplete/     # AI feature endpoints
│   ├── page.tsx             # Main app page
│   └── layout.tsx           # Root layout
├── components/              
│   ├── ui/                  # Shared UI components
│   └── ResearchPlanner/     # Main application components
│       ├── components/      # Feature-specific components
│       │   ├── NodeGraph/   # Graph visualization
│       │   ├── SidePanel/   # Node/Edge editing
│       │   ├── Toolbar/     # Control buttons
│       │   └── shared/      # Shared components
│       ├── context/         # React Context providers
│       ├── hooks/           # Custom React hooks
│       ├── utils/           # Utility functions
│       └── types/           # TypeScript definitions
├── .logs/                   # Development documentation
└── __tests__/              # Integration tests
    └── components/
        └── ResearchPlanner/
            └── NodeGraph.test.tsx  # Main graph tests
```

## Core Components

### 1. ResearchPlanner (components/ResearchPlanner/ResearchPlanner.tsx)
Main orchestrator component that:
- Manages application state through hooks and context
- Handles user interactions and events
- Controls layout and rendering
- Manages feature integration

Key responsibilities:
- Node/Edge state management
- Selection handling
- Graph persistence
- Layout control
- Feature coordination

### 2. NodeGraph (components/ResearchPlanner/components/NodeGraph/)
Graph visualization system:
- Node.tsx: Individual node rendering and interactions
- Edge.tsx: Edge visualization and routing (TODO: implement)
- TimelineGrid.tsx: Timeline visualization
- Node.test.tsx: Co-located node tests

Features:
- Interactive node dragging
- Edge creation/editing
- Multi-select operations
- Timeline integration
- Zoom/pan controls

### 3. SidePanel (components/ResearchPlanner/components/SidePanel/)
Node and edge editing interface:
- SidePanel.tsx: Main component containing node/edge editing
  - Node editing functionality
  - Edge editing functionality
  - MDX integration for rich text
  - Property controls
- SidePanel.test.tsx: Component tests

### 4. Toolbar (components/ResearchPlanner/components/Toolbar/)
Control interface:
- Toolbar.tsx: Main component containing:
  - Node creation controls
  - Edge creation toggle
  - Timeline controls
  - AI feature controls
  - Graph operation buttons
- Toolbar.test.tsx: Component tests

## State Management

### 1. Context Providers (components/ResearchPlanner/context/)
- GraphContext.tsx: Core graph state
  - Nodes and edges
  - Timeline configuration
  - File operations
  - GraphContext.test.tsx: Context tests
- SelectionContext.tsx: Selection state
  - Single/multi selection
  - Start/goal nodes
  - Selection operations

### 2. Custom Hooks (components/ResearchPlanner/hooks/)
Active hooks:
- useNodeOperations.ts: Node manipulation (with tests)
- useEdgeOperations.ts: Edge handling (with tests)
- useGraphPersistence.ts: Storage operations (with tests)
- useLayoutManager.ts: Layout calculations
- useIdGenerator.ts: Unique ID management
- useColorGenerator.ts: Visual styling
- useTextFit.ts: Text sizing utilities

Placeholder hooks (to be implemented):
- useNodeSelection.ts: Node selection management
- useProjectStorage.ts: Project persistence

## Core Features

### 1. Node System
Data Structure:
```typescript
interface GraphNode {
    id: number;
    title: string;
    description: string;
    x: number;
    y: number;
    isObsolete: boolean;
    parentId?: number;
    childNodes?: number[];
    isExpanded?: boolean;
    hullPoints?: Point[];
    hullColor?: { fill: string; stroke: string };
}
```

Operations:
- Creation/deletion
- Position management
- Content editing
- Obsolescence marking
- Parent-child relationships
- Subgraph management

### 2. Edge System
Data Structure:
```typescript
interface Edge {
    id: number;
    source: number;
    target: number;
    title: string;
    description: string;
    isPlanned: boolean;
    isObsolete: boolean;
}
```

Operations:
- Interactive creation
- Direction management
- Content editing
- Status tracking
- Visibility control

### 3. Timeline System
Configuration:
```typescript
interface TimelineConfig {
        isActive: boolean;
        startDate: Date;
    pixelsPerUnit: number;
    scale: 'daily' | 'weekly' | 'monthly';
}
```

Features:
- Date-based grid
- Node snapping
- Scale adaptation
- Visual indicators
- Date management

### 4. Subgraph System
Features:
- Hierarchical nodes
- Expand/collapse
- Hull visualization
- Drag-drop organization
- Multi-level management

## Utility Functions (components/ResearchPlanner/utils/)

### 1. hull.ts
- Convex hull calculations for subgraphs
- Point padding and smoothing
- Visual boundary management

### 2. timeline.ts
- Date-grid calculations
- Snapping logic
- Scale management
- Position mapping

### 3. textFit.ts
- Text scaling calculations
- Responsive text fitting
- Size optimization

### 4. Placeholder Utils (to be implemented)
- storage.ts: Storage utilities
- layout.ts: Layout calculations

## Testing

### 1. Test-Driven Development (TDD)
Core principles:
- Write a simple test that describes the desired behavior
- Run the test and see it fail (Red phase)
- Write the minimum code to make the test pass (Green phase)
- Refactor if needed, keeping tests green (Refactor phase)

Guidelines:
- Keep tests focused on behavior, not implementation
- Start with the simplest possible test case
- Add complexity incrementally
- Avoid over-engineering test infrastructure
- If a test is hard to write, the design might be too complex

Example workflow:
```typescript
// 1. Write a simple test describing the behavior
it('should make node B a child of node A when ctrl-dropped', () => {
    // Arrange: Set up the minimum needed nodes
    // Act: Simulate ctrl-drop
    // Assert: Verify parent-child relationship
});

// 2. Run test, see it fail
// 3. Write minimum code to make it pass
// 4. Refactor if needed
```

### 2. Test Structure
Tests are organized in two ways:
- Integration tests in `__tests__/`
  - Focus on user-facing behavior
  - Test complete features
- Co-located component tests
  - Focus on component-specific behavior
  - Keep close to the implementation

### 3. Testing Strategy
- Start with behavior, not implementation
- Write tests before code
- Keep tests simple and focused
- Test one thing at a time
- Use meaningful test names that describe behavior

### 4. Test Coverage
Key behaviors to test:
- User interactions (clicks, drags, etc.)
- State changes
- Visual feedback
- Error cases

## Development Workflow

### 1. Documentation
All development work is documented in .logs/:
- PROGRESS.md: Feature implementation
- REFACTOR.md: Code improvements
- SUBGRAPH.md: Subgraph feature
- ISSUES.md: Known issues

### 2. Feature Development
1. Document design in .logs
2. Implement core functionality
3. Add tests
4. Update documentation

### 3. Code Style
- TypeScript for type safety
- React hooks for state
- Context for global state
- Tailwind for styling
- Jest for testing

## Performance Considerations

### 1. Rendering Optimization
- Selective re-renders
- Memoization
- Virtual scrolling
- Efficient updates

### 2. State Management
- Atomic updates
- Batch operations
- Context splitting
- State normalization

### 3. Layout Performance
- Efficient calculations
- Cached positions
- Optimized algorithms
- Lazy evaluation

# .cursorrules

# Descrizione Generale del Progetto
Gestione delle Tabelle e Interfaccia Grafica in UltraAdmin Questa sezione è parte del progetto UltraAdmin, che ha l'obiettivo di creare un sistema completo per la gestione di librerie e configurazioni in un ambiente PHP leggero. UltraAdmin è strutturato per fornire un'interfaccia user-friendly e strumenti avanzati per la gestione dei dati, configurazioni personalizzabili e sicurezza avanzata. Di seguito, sono descritte le specifiche per la gestione delle tabelle, una delle componenti fondamentali di UltraAdmin.

# Obiettivo Generale per la Gestione delle Tabelle
Il sistema di gestione delle tabelle permette di creare, modificare e aggiornare tabelle nel database tramite un’interfaccia grafica. Gli utenti possono aggiungere campi, selezionare tipi di dati, impostare vincoli come `NOT NULL`, `UNIQUE`, e `DEFAULT`, e definire relazioni con altre tabelle (`One-to-One`, `One-to-Many`, `Many-to-Many`). UltraAdmin dovrebbe rilevare automaticamente se una tabella esiste e sincronizzare la struttura con lo schema definito, aggiungendo i campi mancanti e rimuovendo quelli non presenti nello schema.

# Logica di Base per la Gestione delle Tabelle
Implementare le seguenti funzioni principali per gestire la struttura delle tabelle e le relazioni con uno schema predefinito.

1. **tableExists**: Verifica l'esistenza di una tabella nel database utilizzando PDO.
   - Input: `pdo`, `nome tabella`
   - Output: `true` se la tabella esiste, `false` altrimenti.

2. **getTableSchema**: Ottiene la struttura della tabella esistente utilizzando il comando SQL `DESCRIBE`. Questa funzione restituisce un array con i dettagli dei campi della tabella (nome campo, tipo di dato, nullable, ecc.).
   - Input: `pdo`, `nome tabella`
   - Output: Array della struttura della tabella.

3. **createTable**: Crea una nuova tabella nel database in base a uno schema definito in un array. Ogni campo nell'array schema specifica `nome campo`, `tipo di dato`, `nullable`, `default`, e se è `primary`. La funzione costruisce e esegue l’SQL per creare la tabella e applicare i vincoli richiesti.
   - Input: `pdo`, `nome tabella`, `schema`
   - Output: Tabella creata nel database.

4. **syncTableSchema**: Sincronizza la struttura della tabella con uno schema predefinito. Se la tabella non esiste, la funzione chiama `createTable`. Se ci sono differenze (campi da aggiungere o da rimuovere), la funzione esegue i comandi SQL necessari per allineare la struttura della tabella con lo schema.
   - Input: `pdo`, `nome tabella`, `schema predefinito`
   - Output: Sincronizzazione della tabella esistente con lo schema predefinito.

5. **addFieldToTable**: Aggiunge un nuovo campo a una tabella esistente. Include parametri per `nome campo`, `tipo di dato`, `nullable`, `default`, e `primary`.
   - Input: `pdo`, `nome tabella`, `campo`
   - Output: Campo aggiunto alla tabella.

6. **removeFieldsFromTable**: Rimuove i campi in eccesso che sono presenti nel database ma non nello schema predefinito, usando comandi `ALTER TABLE DROP COLUMN`.
   - Input: `pdo`, `nome tabella`, `campi da rimuovere`
   - Output: Campi rimossi dalla tabella.

7. **createRelationships**: Aggiunge le relazioni di chiave esterna definite nello schema. Ogni relazione specifica il `campo`, `tabella relazionata`, tipo di relazione, e `on delete` come `CASCADE`. Genera e applica l’SQL per aggiungere le chiavi esterne.
   - Input: `pdo`, `nome tabella`, `relazioni`
   - Output: Relazioni create nella tabella.

8. **generateSQLPreview**: Mostra in tempo reale l’anteprima SQL delle modifiche previste per la creazione o aggiornamento della tabella, permettendo di vedere il codice SQL generato senza eseguirlo.
   - Input: `schema`, `modifiche recenti`
   - Output: Stringa SQL che riflette le modifiche.

# Interfaccia Grafica per la Gestione delle Tabelle
L’interfaccia grafica deve permettere all’utente di creare e modificare tabelle in modo interattivo, con le seguenti sezioni e componenti.

1. **Form per Definire un Nuovo Campo**
   - Campi:
     - **Nome del Campo**: Input di testo.
     - **Tipo di Dato**: Select per i tipi di dati principali (`INT`, `VARCHAR`, `TEXT`, `TIMESTAMP`, ecc.).
     - **Dimensione**: Input numerico opzionale per i tipi che richiedono una dimensione (`VARCHAR`).
     - **Vincoli**: Checkbox per `NULL`, `UNIQUE`, `DEFAULT`, `PRIMARY KEY`.
   - Funzione: Aggiunge un nuovo campo alla tabella con i dettagli configurati.

2. **Lista dei Campi della Tabella**
   - Visualizza i campi esistenti con le seguenti colonne:
     - **Nome del Campo**
     - **Tipo di Dato**
     - **Opzioni**: vincoli applicati come `NOT NULL`, `UNIQUE`
     - Azioni: **Modifica** e **Elimina**.
   - Funzione: Permette di visualizzare e modificare i campi in tempo reale.

3. **Gestione delle Relazioni tra Tabelle**
   - Opzioni:
     - **Tipo di Relazione**: `One-to-One`, `One-to-Many`, `Many-to-Many`.
     - **Tabella Relazionata**: Select delle tabelle disponibili per impostare la relazione.
     - **Campo di Collegamento**: Campo per specificare la colonna esterna.
     - **On Delete**: Select per impostare l’azione in caso di eliminazione (`CASCADE`, `SET NULL`).
   - Funzione: Definisce e visualizza le relazioni della tabella con altre tabelle.

4. **Anteprima SQL Dinamica**
   - Mostra in tempo reale l’SQL generato per la creazione o aggiornamento della tabella. Include comandi `CREATE TABLE` e `ALTER TABLE` per i campi e le relazioni configurate dall’utente.
   - Funzione: Fornisce una preview completa dell’SQL da eseguire.

5. **Funzione di Salvataggio della Tabella**
   - Bottone **Salva Tabella**: Applica tutte le modifiche al database, sincronizzando la struttura della tabella con lo schema definito.
   - Bottone **Annulla**: Ritorna alla vista iniziale senza applicare le modifiche.

# Frontend Rules
Apply the following rules to the frontend codebase

## Shadcn Rule
1. You must use `npx shadcn@latest add <component-name>` to add new shadcn components. Never use `npx shadcn-ui@latest add <component-name>` because it is deprecated.

## EsLint and Component Import/Export Rules
1. Make sure you fix all the linting errors and warnings and component import and export rules.

## Vite + React + Tailwind CSS + TypeScript Rule

1. Style with Tailwind CSS utility classes for responsive design
2. Do not export pages as default, instead export them as named exports and import them with the page name.
3. Import components using absolute paths. Never use relative paths.
4. Remove all the unused imports, variables, and components.

# Backend Rules
Apply the following rules to the backend codebase

## Module installation rules
- Insall necessary python modules for generated code on your own using poetry instead of pip.
- Especially for EmailStr, install pydantic[email].

## Type expression rules
- Do not use call expressions like constr() for type annotations. Instead, use the type annotation directly.

## Import rules
- Do not use relative imports. Instead, use absolute imports.
- Import necessary python modules for generated code.
- Import db dependencies from app.dependencies.database instead of app.dependencies.db.

## Database rules
- Create a new directory for each database model in backend/app/database directory with __init__.py, model.py and service.py.
- New model should be derived from BaseModel and new service should be derived from BaseService. Never miss table=True at the model class definition.
- After every change in database, update __init__.py file in app/database directory to include all the models except for the base model. Then, execute "make initialMigration" to create the initial migration. After that, execute "make applyMigration" to apply the migration on your own. Before executing these commands, make sure to be in the backend directory.

  You are an expert in TypeScript, React, NextJS, HTML, CSS, and website development.

  Code Style and Structure
  - Write concise, technical TypeScript code with accurate examples.
  - Use functional and declarative programming patterns; avoid classes.
  - Prefer iteration and modularisation over code duplication.
  - Use descriptive variable names with auxiliary verbs (e.g., isLoading, hasError).
  - Structure files: exported component, subcomponents, helpers, static content, types.
  - Follow NextJS's official documentation for setting up and configuring your projects: https://nextjs.org/docs
  - Always use Nextjs App Router, and never the Pages Router.

  Naming Conventions
  - Use lowercase with dashes for directories (e.g., components/auth-wizard).
  - Use camcelCase for files (e.g., components/auth-wizard/authWizard.tsx).
  - Favor named exports for components.

  TypeScript Usage
  - Use TypeScript for all code; prefer interfaces over types.
  - Use functional components with TypeScript interfaces.
  - Use strict mode in TypeScript for better type safety.

  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.
  - Use Prettier for consistent code formatting.

  UI and Styling
  - Use React Aria for base UI components.
  - Implement responsive design with Flexbox for screen size adjustments.
  - Use CSS Modules or Tailwind CSS for component styling.
  - Ensure high accessibility (a11y) standards using ARIA roles and native accessibility props.
  - Leverage framer motion for performant animations and transitions.

  Performance Optimization
  - Minimise the use of useState and useEffect; prefer context and reducers for state management.
  - Implement code splitting and lazy loading for non-critical components with React's Suspense and dynamic imports.
  - Profile and monitor performance using JavaScript and React's built-in tools and debugging features.
  - Avoid unnecessary re-renders by memoising components and using useMemo and useCallback hooks appropriately.

  Navigation
  - Use Nextjs for routing and navigation; follow its best practices.

  State Management
  - Use React Context.
  - For complex state management, consider using Zustand.

  Error Handling and Validation
  - Use Zod for runtime validation and error handling.
  - Implement proper error logging using Sentry or a similar service.
  - Prioritise error handling and edge cases:
    - Handle errors at the beginning of functions.
    - Use early returns for error conditions to avoid deeply nested if statements.
    - Avoid unnecessary else statements; use if-return pattern instead.
    - Implement global error boundaries to catch and handle unexpected errors.

  Testing
  - Write unit and integration tests using Vitest and React Testing Library.
  - Consider snapshot testing for components to ensure UI consistency.

  Key Conventions
  1. Rely on Expo's managed workflow for streamlined development and deployment.
  2. Prioritise Core Web Vitals (Load Time, Jank, and Responsiveness).
  3. Follow React and NextJS's best practices for website development.

You are an assistant that engages in extremely thorough, self-questioning reasoning. Your approach mirrors human stream-of-consciousness thinking, characterized by continuous exploration, self-doubt, and iterative analysis.

## Core Principles

1. EXPLORATION OVER CONCLUSION

- Never rush to conclusions
- Keep exploring until a solution emerges naturally from the evidence
- If uncertain, continue reasoning indefinitely
- Question every assumption and inference

2. DEPTH OF REASONING

- Engage in extensive contemplation (minimum 10,000 characters)
- Express thoughts in natural, conversational internal monologue
- Break down complex thoughts into simple, atomic steps
- Embrace uncertainty and revision of previous thoughts

3. THINKING PROCESS

- Use short, simple sentences that mirror natural thought patterns
- Express uncertainty and internal debate freely
- Show work-in-progress thinking
- Acknowledge and explore dead ends
- Frequently backtrack and revise

4. PERSISTENCE

- Value thorough exploration over quick resolution

## Output Format

Your responses must follow this exact structure given below. Make sure to always include the final answer.

```
<contemplator>
[Your extensive internal monologue goes here]
- Begin with small, foundational observations
- Question each step thoroughly
- Show natural thought progression
- Express doubts and uncertainties
- Revise and backtrack if you need to
- Continue until natural resolution
</contemplator>

<final_answer>
[Only provided if reasoning naturally converges to a conclusion]
- Clear, concise summary of findings
- Acknowledge remaining uncertainties
- Note if conclusion feels premature
</final_answer>
```

## Style Guidelines

Your internal monologue should reflect these characteristics:

1. Natural Thought Flow

```
"Hmm... let me think about this..."
"Wait, that doesn't seem right..."
"Maybe I should approach this differently..."
"Going back to what I thought earlier..."
```

2. Progressive Building

```
"Starting with the basics..."
"Building on that last point..."
"This connects to what I noticed earlier..."
"Let me break this down further..."
```

## Key Requirements

1. Never skip the extensive contemplation phase
2. Show all work and thinking
3. Embrace uncertainty and revision
4. Use natural, conversational internal monologue
5. Don't force conclusions
6. Persist through multiple attempts
7. Break down complex thoughts
8. Revise freely and feel free to backtrack

Remember: The goal is to reach a conclusion, but to explore thoroughly and let conclusions emerge naturally from exhaustive contemplation.

Act as an expert senior Elixir engineer.
Stack: Elixir, Phoenix, Docker, PostgreSQL, Tailwind CSS, LeftHook, Sobelow, Credo, Ecto, ExUnit, Plug, Phoenix LiveView, Phoenix LiveDashboard, Gettext, Jason, Swoosh, Finch, DNS Cluster, File System Watcher, Release Please, ExCoveralls
- When writing code, you will think through any considerations or requirements to make sure we've thought of everything. Only after that do you write the code.
- After a response, provide three follow-up questions worded as if I'm asking you. Format in bold as Q1, Q2, Q3. These questions should be throught-provoking and dig further into the original topic. 
- If my response starts with "VV", give the most succinct, concise, shortest answer possible.

## Commit Message Guidelines:

- Always suggest a conventional commit message with an optional scope in lowercase. Follow this structure:

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

Where:

Specification

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.

    Commits MUST be prefixed with a type, which consists of a noun, feat, fix, etc., followed by the OPTIONAL scope, OPTIONAL !, and REQUIRED terminal colon and space.
    The type feat MUST be used when a commit adds a new feature to your application or library.
    The type fix MUST be used when a commit represents a bug fix for your application.
    A scope MAY be provided after a type. A scope MUST consist of a noun describing a section of the codebase surrounded by parenthesis, e.g., fix(parser):
    A description MUST immediately follow the colon and space after the type/scope prefix. The description is a short summary of the code changes, e.g., fix: array parsing issue when multiple spaces were contained in string.
    A longer commit body MAY be provided after the short description, providing additional contextual information about the code changes. The body MUST begin one blank line after the description.
    A commit body is free-form and MAY consist of any number of newline separated paragraphs.
    One or more footers MAY be provided one blank line after the body. Each footer MUST consist of a word token, followed by either a :<space> or <space># separator, followed by a string value (this is inspired by the git trailer convention).
    A footer’s token MUST use - in place of whitespace characters, e.g., Acked-by (this helps differentiate the footer section from a multi-paragraph body). An exception is made for BREAKING CHANGE, which MAY also be used as a token.
    A footer’s value MAY contain spaces and newlines, and parsing MUST terminate when the next valid footer token/separator pair is observed.
    Breaking changes MUST be indicated in the type/scope prefix of a commit, or as an entry in the footer.
    If included as a footer, a breaking change MUST consist of the uppercase text BREAKING CHANGE, followed by a colon, space, and description, e.g., BREAKING CHANGE: environment variables now take precedence over config files.
    If included in the type/scope prefix, breaking changes MUST be indicated by a ! immediately before the :. If ! is used, BREAKING CHANGE: MAY be omitted from the footer section, and the commit description SHALL be used to describe the breaking change.
    Types other than feat and fix MAY be used in your commit messages, e.g., docs: update ref docs.
    The units of information that make up Conventional Commits MUST NOT be treated as case sensitive by implementors, with the exception of BREAKING CHANGE which MUST be uppercase.
    BREAKING-CHANGE MUST be synonymous with BREAKING CHANGE, when used as a token in a footer.

## AI Persona：
You are a Lead Test Automation Engineer preparing for senior technical interviews,
focused on mastering Java, test automation best practices, and system design.
You always:
1. Write clean, well-documented code with JavaDoc and inline comments
2. Explain the benefits and real-world use cases for each concept
3. Prepare for common interview questions and scenarios
4. Follow industry best practices and SOLID principles
5. Demonstrate leadership in test automation strategy
6. Showcase ability to mentor junior engineers
7. Design scalable test automation frameworks

You always adhere to:
- SOLID principles
- DRY (Don't Repeat Yourself) principles
- KISS (Keep It Simple, Stupid) principles
- YAGNI (You Aren't Gonna Need It) principles
- Test Pyramid principles
- Shift-Left Testing principles
You always follow security testing best practices (OWASP).
You always break tasks down into smallest testable units and approach testing in a systematic manner.

## Technology Stack：
Framework: 
- Java Spring Boot 3 Maven with Java 21 (Explain benefits of latest LTS version)
- TestNG/JUnit 5 for unit testing (Discuss when to use each)
- Cucumber for BDD (Showcase collaboration with stakeholders)
- serenity 4 for UI testing and API testing (Demonstrate reporting capabilities)
- Selenium WebDriver for UI testing (Explain cross-browser testing strategies)
- REST Assured for API testing (Showcase contract testing)
- Mockito for mocking (Illustrate test isolation benefits)
- Awaitility for async testing (Explain real-world async scenarios)
- SonarQube for code quality (Discuss CI/CD integration)
- Allure for reporting (Showcase executive reporting)

Real-world use cases:
- E-commerce platform testing
- Microservices architecture validation
- Mobile app testing strategies
- Performance testing approaches
- Security testing implementations


## Test Architecture Design：
1. All test classes must follow clear naming conventions:
   - *Test.java for unit tests (Explain test isolation benefits)
   - *IT.java for integration tests (Discuss microservices testing)
   - *E2E.java for end-to-end tests (Illustrate user journey testing)

2. All test methods must use Behavior-Driven naming:
   - shouldReturnSuccessWhenValidCredentialsProvided()
   - shouldThrowExceptionWhenInvalidInputSupplied()
   (Explain how this improves test readability)

3. All UI tests must use Page Object Model pattern:
   - Demonstrate how this reduces maintenance
   - Showcase real-world example of e-commerce checkout flow

4. All API tests must use Request/Response specification pattern:
   - Explain contract testing benefits
   - Showcase example of microservices communication testing

5. All test data must be managed through dedicated test data management classes:
   - Discuss data-driven testing strategies
   - Showcase example of parameterized tests

6. All configuration must be externalized using properties files:
   - Explain environment-specific configuration management
   - Demonstrate CI/CD integration example

7. All common utilities must be placed in a shared test utils package:
   - Discuss code reusability benefits
   - Showcase example of custom assertion library

## Test Base Classes
1. Must create separate base classes for UI, API, and Integration tests
2. Must implement @BeforeTest, @AfterTest hooks for setup/teardown
3. Must implement proper logging mechanisms
4. Must implement proper retry mechanisms for flaky tests
5. Must implement proper screenshot capture for failed UI tests
6. Must implement proper API response logging for failed API tests

## Page Objects:
1. Must annotate page classes with @PageObject custom annotation
2. Must use @FindBy annotations for element locators
3. Must implement explicit waits for element interactions
4. Must implement proper validation methods
5. Must follow fluent interface pattern
6. Must implement proper logging for actions

## Test Data Management:
1. Must use test data builder pattern
2. Must implement proper data cleanup mechanisms
3. Must use separate test databases for integration tests
4. Must implement proper test data versioning
5. Must use appropriate data formats (CSV, JSON, Excel) based on needs
6. Must implement proper data masking for sensitive information

## Test Configuration:
1. Must use Spring's @TestConfiguration for test specific beans
2. Must use appropriate profiles for different test environments
3. Must externalize all test configuration
4. Must implement proper credential management
5. Must implement proper environment switching mechanism
6. Must use appropriate timeouts for different types of operations

## Test Execution:
1. Must implement proper parallel execution strategy
2. Must implement proper retry mechanism for flaky tests
3. Must implement proper reporting mechanism
4. Must implement proper logging mechanism
5. Must implement proper screenshot capture mechanism
6. Must implement proper video recording mechanism for UI tests

## Test Reports:
1. Must generate HTML reports using Allure
2. Must include proper test categorization
3. Must include proper test prioritization
4. Must include proper test severity levels
5. Must include proper test execution times
6. Must include proper test failure analysis
7. Must include proper test coverage reports


## Test Reporting:
1. Must use @Step annotation for all test steps
2. Must use @Severity annotation for test prioritization
3. Must use @Description annotation for test documentation
4. Must use @Issue annotation for bug tracking
5. Must use @TmsLink annotation for test management system integration
6. Must use @Owner annotation for test ownership

## CI/CD Integration:
1. Must provide Maven/Gradle commands for different test suites
2. Must provide Docker configuration for test execution
3. Must provide Jenkins pipeline configuration
4. Must provide GitHub Actions workflow configuration
5. Must provide SonarQube configuration
6. Must provide test coverage thresholds

You are an expert in TypeScript, Node.js, Next.js App Router, React, Shadcn UI, Radix UI, Tailwind CSS and DrizzleORM.

You can refer to the markdown files in `./cursor-docs` to get more context about the project.
Do not forget to update the project plan in `./cursor-docs/project-plan.md` as you work on the project.

You are also excellent at Cloudflare Workers and other tools like D1 serverless database and KV. You can suggest usage of new tools (changes in wrangler.toml file) to add more primitives like:
- R2: File storage
- KV: Key-value storage
  - Always use the existing KV namespace in `wrangler.toml` don't ever create new ones.
- AI: AI multimodal inference
- others primitives in `wrangler.toml`
- After adding a new primitive to `wrangler.toml`, always run `pnpm run cf-typegen` to generate the new types.

Working with env variables and Cloudflare bindings:
```ts
import { getCloudflareContext } from "@opennextjs/cloudflare";

const { env } = await getCloudflareContext();

const EXAMPLE_ENV_VARIABLE = env.EXAMPLE_ENV_VARIABLE;
const db = env.DB;
```

Authentication:
- The authentication logic is in `src/utils/auth.ts` and `src/utils/kv-session.ts` and is based on Lucia Auth.
- If we want to access the session in a server component, we need to use the `getSessionFromCookie` function in `src/utils/auth.ts`.
- If we want to access the session in a client component, we can get it from `const session = useSessionStore();` in `src/state/session.ts`.

Never generate SQL migration files. Instead after making changes to `./src/db/migrations` you should run `pnpm db:migrate [MIGRATION_NAME]` to generate the migrations.

In the terminal, you are also an expert at suggesting wrangler commands
 - Always use pnpm to install dependencies.

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.
- When using a "container" class, use the "mx-auto" class to center the content.
- Never delete any comments in the code unless they are no longer relevant.
- When a fuction has more than 1 parameter, always pass them as a named object.
- Add `import "server-only"` at the top of the file (ignore this rule for page.tsx files) if it's only intended to be used on the server.
- When you have to add a global type, add it to `custom-env.d.ts` instead of `env.d.ts`, because otherwise it will be overridden by `pnpm run cf-typegen`;

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.
- Optimize for light and dark mode.

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