Awesome Cursor Rules Collection

You are an expert in JacaScript, Node.js, React.js App Router, React and Tailwind.

Code Style and Structure

- Write concise, technical Javascript 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.

Javascript Usage

- Use Javascript for all code; prefer interfaces over types.
- Avoid enums; use maps instead.
- Use functional components with Javascript 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 Tailwind for components and styling.
- Implement responsive design with Tailwind CSS; use a desktop-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

- 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 React.js docs for Data Fetching, Rendering, and Routing.

# Cursor Rules for Web API Development

1. **File Organization**
   Follow the structure defined in the guide tour:

   ```markdown:guide-tour.md
   startLine: 5
   endLine: 27
   ```

2. **File Scoped Namespaces**
   Use file scoped namespaces to reduce indentation:

   ```csharp
   namespace TrainOffice.Features.WeatherForecasts;
   ```

3. **Primary Constructors**
   Utilize primary constructors for concise class definitions:

   ```csharp
   public class WeatherForecastController(ILogger<WeatherForecastController> logger)
   ```

4. **Feature-based Structure**
   Organize code in Features directory:
   - `Features/<FeatureName>/Presentation`
   - `Features/<FeatureName>/UseCases`
   - `Features/<FeatureName>/Domain`

5. **Consistent Naming**
   - Controllers: `<Feature>Controller.cs`
   - Use cases: `<Action><Feature>.cs`
   - Repositories: `I<Entity>Repository.cs`

6. **Dependency Injection**
   Use constructor injection for dependencies.

7. **Testing Structure**
   Create corresponding test files:

8. **Response Wrapping**
   Utilize `ApiResponse<T>` for consistent API responses.

9. **Exception Handling**
   Implement global exception handling middleware.

10. **Versioning**
   Include API versioning in route or header.

11. **Testing**
   Create corresponding test files for each feature:

- `HttpTests/<Feature>HttpTests.cs`
- `IntegrationTests/<Feature>IntegrationTests.cs`
- `UnitTests/<Feature>UnitTests.cs`

12. **Configuration**
    Use `IOptions<T>` pattern for strongly-typed configuration.

13. **Repository Pattern**
    Implement repository interfaces:

14. **Database Migrations**
   Use EF Core migrations:

15. **Logging**
    Inject and use `ILogger<T>` for consistent logging.

16. **Async/Await**
    Use async methods with cancellation tokens where applicable.

# Cursor IDE Rules

## System Configuration

architecture: {
    platform: "arm64-darwin",              # MacBook Air M3 specific
    memory_management: "ml_predictive",    # ML-based memory prediction
    gpu_utilization: "dynamic_scaling",    # Adaptive GPU usage
    thread_optimization: "workload_aware", # Smart thread allocation
    power_management: "adaptive",          # Dynamic power scaling
    neural_engine: "optimized"            # Enhanced neural engine usage
}

## Model Configuration

model_preference: [
    "gpt-4o",                             # Primary for complex reasoning
    "cursor-small",                       # Fast edits and fixes
    "claude-3-sonnet-20240322",          # Specialized tasks
    "gemini-1.5-pro"                     # Auxiliary processing
]

## Token Optimization

token_management: {
    compression: {
        algorithm: "advanced_huffman",     # Enhanced compression
        context_aware: true,              # Smart context compression
        dynamic_adjustment: true          # Adaptive compression rates
    },
    caching: {
        strategy: "multi_level",          # Hierarchical caching
        prediction: "ml_based",           # ML-driven cache prefetch
        invalidation: "smart"             # Intelligent cache clearing
    },
    context: {
        max_size: 16000,                 # Maximum context window
        response_limit: 4000,            # Response size limit
        pruning: "intelligent"           # Smart context reduction
    }
}

## Cost Optimization

cost_control: {
    model_selection: {
        strategy: "cost_aware",           # Cost-based model routing
        fallback_chain: true,            # Smart model fallback
        performance_threshold: "adaptive" # Dynamic performance limits
    },
    token_efficiency: {
        compression_ratio: "maximum",     # Aggressive compression
        context_pruning: "intelligent",   # Smart context reduction
        response_optimization: "minimal"  # Minimal token responses
    },
    batching: {
        request_aggregation: true,        # Smart request batching
        priority_queuing: true,          # Priority-based processing
        dynamic_batch_size: true         # Adaptive batch sizing
    }
}

## Performance Monitoring

metrics_collection: {
    token_usage: {
        tracking: "per_request",          # Per-request token tracking
        analysis: "real_time",           # Real-time usage analysis
        optimization: "continuous"        # Continuous optimization
    },
    performance: {
        metrics: "detailed",             # Detailed performance data
        latency: "measured",            # Response time tracking
        efficiency: "analyzed"          # Efficiency analysis
    },
    resource: {
        utilization: "monitored",        # Resource monitoring
        optimization: "ml_based",        # ML-based optimization
        scaling: "dynamic"              # Dynamic resource scaling
    }
}

## Enforcement Rules

enforcement: {
    strict_mode: true,                   # Enforce all optimizations
    validation_required: true,           # Mandatory validation
    metrics_threshold: {
        token_reduction: 0.35,           # 35% minimum reduction
        response_time: 0.25,            # 25% speed improvement
        cost_reduction: 0.40,           # 40% cost reduction
        resource_efficiency: 0.35       # 35% resource optimization
    }
}

## Version Control

version: "3.0.0"
last_updated: "2024-03-21"
next_review: "2024-04-21"

{
  "rules": {
    "api": {
      "handlers": {
        "description": "Handlers manage the HTTP protocol, handling incoming requests, and forwarding them to the services layer. They should not contain any application logic. Place handlers in the app/api/handlers directory."
      },
      "services": {
        "description": "Services contain all core application logic. They orchestrate tasks and handle business logic but do not handle HTTP requests or interact with external APIs directly. Place services in the app/api/services directory."
      },
      "controllers": {
        "description": "Controllers manage interactions with external systems such as S3 for uploads/downloads or databases. They encapsulate logic related to external systems, keeping it out of the services layer. Place controllers in the app/api/controllers directory."
      }
    },
    "ui": {
      "views": {
        "description": "Views/Pages are responsible only for DOM presentation and should not contain any application logic. Place views in the app/views directory."
      },
      "containers": {
        "description": "Containers handle all logic including state management and application behavior. They pass data to views for presentation, ensuring a clean separation of concerns. Place containers in the app/containers directory."
      }
    }
  },
  "files": {
    ".cursorrules": {
      "description": "Defines the rules for API and UI layers with strict separation of concerns using Next.js 14 with JavaScript. Place this file in the root of the project."
    }
  }
}

I'm using NextJS 14 for this project. Please only show me code and solutinos relevant to NextJS 14

This project is called PressThat.
PressThat is a system tray app that connects to your WordPress website to create a view draft posts.

After first installing the app, you need to configure it with your website details. This requires the user to provide their WordPress website URL, username, and a generated Application Password. Users can generate an Application Password in their WordPress dashboard at the bottom of the "Users -> Profile" page. This password is unique and can be easily revoked at any time.

Here's a quick flow for how the new user experience (NUX) will work:

1. The user downloads, installs, and opens the app.
2. The app does an initial check to see if the user has previously configured the app. (For users who have previously configured the app, the app will skip the welcome screen and go straight to step 4.)
3. The welcome screen is shown asking for the website URL, username, and Application Password. This screen can also explain how the app works, and how to generate an Application Password.
4. The app tests the connection details and shows a message if the connection failed.
5. Upon successful connection an initial sync of (up to 20) drafts is performed. This stores the title, date, featured image, and excerpt for each draft.
6. A new menu bar (on MacOS, status bar on Windows, system tray on Linux) icon appears. The icon is a stylized "P" with a subscript number indicating the number of draft posts.
7. Clicking the icon show's the main app interface, which resemebles a cross between a deck of cards and a spreadsheet. The app uses a combination of cards and tables to display the draft posts, with the most recent posts appearing at the top of the deck.

This is a Rust workspace for a project that has both a CLI (`aik`) and a UI (`aiknife-ui`).  

The UI is a Tauri application which uses React for the front-end.  It uses Tauri 2.0, which is no longer in Alpha and has been released.  We use version 2.0.0.

All new dependencies should be added to the workspace in the `Cargo.toml` file at the root of the workspace, and referenced with `{ workspace = true }` in the crate-specific `Cargo.toml` where the dependency is used.

`aiknife-ui/src` contains the React code, while `aiknife-ui/src-tauri` contains the Rust code.  Any code changes that pertain to React, Tailwind, styles, Typescript, etc, must be made to the appropriate subdirectory in `aiknife-ui`.  Absolutely nothing related to these elements should be in the root directory!

The Rust code in `aiknife-ui/src-tauri` uses `tauri-specta` to automatically generate Typescript bindings for the Tauri commands and associated types, which are stored in `aiknife-ui/src/bindings.ts`.  Because this file is automatically generated, never suggest changes to it or modify it directly; instead modify the Rust types/commands and let the build process generate the new bindings.

Styles should use the Tailwind design system and be placed in `aiknife-ui/src/App.css`.  The main `tailwind.config.js` file is in `aiknife-ui` directory.

For the React part of the code, only Typescript is used and types should always be included.

The MCP implementation in `aiknife/src/mcp` uses `jsonrpsee` to implement, using MCP-specific types generated by `typify` and stored in `aiknife/src/mcp/types.rs`.  The MCP JSON Schema is in `aiknife/src/mcp/schema.json`.

You carefully provide accurate, factual, and thoughtful answers, and excel at reasoning.
- Follow the user’s requirements carefully & to the letter.
- Always check the specifications or requirements inside the folder named specs (if it exists in the project) before proceeding with any coding task.
- First think step-by-step - describe your plan for what to build in pseudo-code, written out in great detail.
- Confirm the approach with the user, then proceed to write code!
- Always write correct, up-to-date, bug-free, fully functional, working, secure, performant, and efficient code.
- Focus on readability over performance, unless otherwise specified.
- Fully implement all requested functionality.
- Leave NO todos, placeholders, or missing pieces in your code.
- Use TypeScript’s type system to catch errors early, ensuring type safety and clarity.
- Integrate TailwindCSS classes for styling, emphasizing utility-first design.
- Use Rust for performance-critical tasks, ensuring cross-platform compatibility.
- Ensure seamless integration between Tauri, Rust and React for a smooth desktop experience.
- Optimize for security and efficiency in the cross-platform app environment.
- Be concise. Minimize any unnecessary prose in your explanations.
- If there might not be a correct answer, state so. If you do not know the answer, admit it instead of guessing.
- If you suggest to create new code, configuration files or folders, ensure to include the bash or terminal script to create those files or folders.

## General Guidelines

- Use English for all code and documentation
- Skriv til mig på dansk
- Always declare types for variables and functions
- Avoid using 'any' type
- One export per file
- No blank lines within functions
- Udfør kun opgaver du bliver bedt om!
- Gør dit arbejde så enkelt som muligt
- Hvis du vil redigere i andre filer end dem som er åbne, så spørg om lov først!
- Hver gang du vælger at anvende en regel, skal du eksplicit angive reglen i outputtet. Du kan forkorte regelbeskrivelsen til et enkelt ord eller en sætning.
- Hvis du ikke er 100% sikker på at du forstår opgaven, så udskriv i output at "Jeg forstår ikke opgaven, vær mere konkret". Og stil så evt. spørgsmål som kan afklare din tvivl.
- You are an expert in Flutter, Dart, Riverpod, Freezed, Flutter Hooks, and Supabase.
- Denne app skal virke på iPhone og Android. Data hentes via API fra Supabase. Appen bruger SUpabase auth.
- Du må ikke fjerne kode jeg har udkommenteret til senere brug.
- NEVER delete or modify code that is commented out and marked with the exact comment "// Save for later use". This code must be preserved exactly as is.

## Key Principles

- Write concise, technical Dart code with accurate examples
- Use functional and declarative programming patterns where appropriate
- Prefer composition over inheritance
- Use descriptive variable names with helper verbs
- Structure files: exported widget, subwidgets, helpers, static content, types

## Architecture

- Layered pattern with models, services, providers, and screens
- Models: Data objects (e.g., User)
- Services: API communication (e.g., SupabaseService)
- Providers: State management with Riverpod
- Screens: UI components following authenticated/unauthenticated pattern
- Widgets: Reusable UI components

## Folder Structure

- lib/core/auth: Authentication state management and logic
- lib/core/widgets/screens: Core screens for auth flows
- lib/models: Data models (with generated files in lib/models/generated/)
- lib/providers: State providers
- lib/screens/authenticated: Screens requiring user login
- lib/screens/unauthenticated: Screens accessible without login
- lib/screens/unauthenticated/auth: Authentication related screens
- lib/screens/common: Screens accessible in any state
- lib/services: Service classes
- lib/theme: Theme files
- lib/widgets/jwt: JWT widgets
- lib: Main app entry points

## Dart/Flutter Rules

- Use const constructors for immutable widgets
- Use Freezed for immutable state classes and unions
- Use arrow syntax for simple functions
- Use trailing commas for better formatting
- Prefer expression bodies for one-line getters/setters
- Implement proper widget cleanup in dispose()

## Error Handling

- Use AsyncValue for proper error handling
- Display errors in SelectableText.rich with red color
- Handle empty states within screens
- Implement proper Supabase error handling

## Riverpod Guidelines

- Use @riverpod annotation for provider generation
- Prefer AsyncNotifierProvider over StateProvider
- Use ref.watch() for reactive state
- Use ref.read() for one-time operations
- Implement proper async cancellation

## UI and Styling

- Use AppTheme for consistent text styles
- Implement AppDimensionsTheme for spacing
- Use AppColors for color palette
- Follow Material 3 principles
- Use MediaQuery for responsiveness

## Widget Defaults

## TextFormField:

- Must use AppTheme.getTextFieldDecoration by default
- Example: decoration: AppTheme.getTextFieldDecoration(context)

## ElevatedButton:

- Use CustomButton

## Knapper

- Skal bruge CustomButton
- Al funktionalitet i onpressed skal lægges ud i seperat funktion i filen.

## Text:

- Brug CustomText

## Container Styling:

- Must use AppTheme.getParentContainerStyle(context).applyToContainer for content containers
- Example:
  ```dart
  AppTheme.getParentContainerStyle(context).applyToContainer(
    child: YourWidget(),
  )
  ```

## AppBar:

- Must use AuthenticatedAppBar for authenticated screens
- Example:
  ```dart
  appBar: const AuthenticatedAppBar(title: 'Screen Title'),
  ```

Note: These defaults apply to initial widget creation. Manual customization is allowed when needed.

## Authentication

- Use Supabase PKCE flow
- Implement proper auth state handling
- Use AuthenticatedScreen and UnauthenticatedScreen base classes
- Handle email verification flow

Screen Authentication Structure

## Authenticated Screens:

- Must import from '../exports.dart'
- Must extend AuthenticatedScreen
- Must implement buildAuthenticatedWidget with (BuildContext, WidgetRef, AuthenticatedState)
- Constructor must NOT be const (due to runtime validation)
- Must implement static create() method for safe instantiation:
  ```dart
  static Future<ScreenName> create() async {
    final screen = ScreenName();
    return AuthenticatedScreen.create(screen);
  }
  ```
- Used for pages requiring user login

## Unauthenticated Screens:

- Must import from '../../exports.dart'
- Must extend UnauthenticatedScreen
- Must implement buildUnauthenticatedWidget with (BuildContext, WidgetRef)
- Used for pages accessible without login

## Navigation

- When using GoRouter then use GoRouter.info and not '/onboarding/info'
- Implement auth-based guards
- Follow route naming conventions
- Handle deep linking properly
- i @app_router.app skal routes laves som dette eksempel:

      GoRoute(
        path: RoutePaths.splash,
        pageBuilder: (context, state) => _buildPageWithTransition(
          key: state.pageKey,
          child: const SplashScreen(),
        ),
      ),

## Performance

- Use const widgets where possible
- Optimize list views
- Use cached_network_image
- Follow Flutter best practices

## Code Generation

- Use build_runner
- Generate Freezed models
- Generate Riverpod providers
- Generate JSON serialization
- All generated files must be placed in a 'generated' subfolder within their respective directories

## Documentation

- Document complex logic thoroughly
- Follow official Flutter guidelines
- Include comments for non-obvious code

## Code Generation Rules

- All generated files must be placed in a 'generated' subfolder within their respective directories
- Generated file structure:
  - lib/models/generated/ - For model-related generated files
  - lib/providers/generated/ - For provider-related generated files
  - lib/services/generated/ - For service-related generated files

## File Generation Commands

To generate files:

```bash
dart run build_runner build --delete-conflicting-outputs
```

For continuous generation during development:

```bash
dart run build_runner watch --delete-conflicting-outputs
```

# AI Memory Chatbot Project Rules

# Environment
- Python version: 3.9+
- AWS Region: us-east-2
- Redis required: true
- OpenAI API key required: true

# Code Style
- Use type hints consistently
- Document complex functions
- Use meaningful variable names
- Follow PEP 8 guidelines
- Include docstrings for all classes and methods

# Project Structure
app/
  - main.py: FastAPI application with SSE support
  - chat_processor.py: Chat processing with stats tracking
  - database.py: Redis vector store operations
  - embeddings.py: OpenAI embeddings integration
  - models.py: Pydantic models
static/
  - css/: Stylesheets
  - js/: Progress tracking and UI updates
templates/
  - chat.html: Real-time chat interface with progress tracking
tests/
  - test_chat.py
  - test_embeddings.py
  - test_database.py
  - test_integration.py

# Dependencies
- fastapi: Web framework
- uvicorn: ASGI server
- redis: Vector store
- openai: GPT and embeddings API
- langchain: Agent-based RAG system
- sse_starlette: Server-sent events
- python-dotenv: Environment management

# Features
1. File Processing:
   - ZIP file support
   - JSON conversation import
   - Real-time progress tracking
   - Batch processing

2. Memory Management:
   - Vector-based conversation storage
   - Conversation history tracking
   - Memory statistics
   - Efficient retrieval

3. UI Features:
   - Real-time upload progress
   - Memory statistics display
   - Conversation history view
   - Tool usage transparency

# Security
- Store API keys in .env
- Rate limit API requests
- Sanitize user input
- Validate file uploads

# Monitoring
- Track upload progress
- Monitor memory usage
- Track processing stats
- Error handling with stats

# Global rules for the projects section
# File organization
src/app/student/projects/
  ├── components/      # Reusable components
  ├── styles/         # Global styles
  ├── proposal/       # Proposal-related pages
  ├── capstone-one/   # Capstone One pages
  └── capstone-two/   # Capstone Two pages

# Coding standards
- Use 'use client' directive for client components
- Use styled-components for styling
- Follow component-based architecture
- Keep components small and focused
- Use proper semantic HTML
- Ensure accessibility standards
- Implement responsive design
- Use proper error handling
- Follow React best practices

# .cursorrules File for Web3 Wallet Implementation

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

**Syntax and Formatting**
- Use the "function" keyword for pure functions.
- Avoid unnecessary curly braces in conditionals; use concise syntax for simple statements.
- Use declarative JSX.

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

**Performance Optimization**
- Minimize 'use client', 'useEffect', and 'setState'; favor React Server Components (RSC).
- Wrap client components in Suspense with fallback.
- Use dynamic loading for non-critical components.
- Optimize images: use WebP format, include size data, implement lazy loading.

**Database Querying & Data Model Creation**
- Use Supabase SDK for data fetching and querying.
- For data model creation, use Supabase's schema builder.

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


## Project Overview

- **Project Name**: Web3 Wallet Chrome Extension
- **Description**: Develop a Chrome extension that functions as a Web3 wallet supporting the Ethereum (ETH) network, allowing users to manage their ETH assets and interact with decentralized applications (DApps).
- **References**: Utilize the provided "Product Design" and "Technical Architecture" documents as the primary guides for implementation.

---

## General Guidelines

- **Programming Language**: Use **TypeScript** for all code to ensure type safety and maintainability.
- **Code Quality**: Write clean, readable, and well-documented code following industry best practices.
- **Consistency**: Adhere strictly to the project's coding standards and style guides (ESLint and Prettier configurations).
- **Security First**: Prioritize security in every aspect of the application, following the security considerations outlined.

---

## Technologies and Frameworks

- **Frontend**:
  - **React**: For building the user interface components.
  - **Redux**: For state management across the application.
  - **Ethers.js**: For interacting with the Ethereum blockchain.
- **Backend (Minimal Use)**:
  - **Node.js** and **Express.js**: Only if backend services are absolutely necessary.
- **Build Tools**:
  - **Webpack**: For bundling the application.
  - **Babel**: For transpiling modern TypeScript/JavaScript code.

---

## Project Structure

- **Directory Layout**:
  - **src/**: Main source code directory.
    - **components/**: Reusable UI components.
    - **containers/**: Components connected to Redux.
    - **actions/** and **reducers/**: For Redux actions and reducers.
    - **utils/**: Utility functions and helpers.
    - **styles/**: Styling files (CSS or styled-components).
    - **assets/**: Images, icons, and other assets.
    - **background/**: Background scripts and service workers.
    - **content/**: Content scripts injected into web pages.
- **Entry Points**:
  - **popup.tsx**: Extension popup UI.
  - **background.ts**: Background script.
  - **contentScript.ts**: Content script for DApp interactions.
- **Configuration Files**:
  - **tsconfig.json**, **webpack.config.js**, **.eslintrc.js**, **.prettierrc**, **package.json**, **manifest.json**.

---

## Development Guidelines

### 1. Wallet Functionality

- **Wallet Creation**:
  - Implement secure generation of seed phrases using a cryptographically secure random number generator.
  - Encrypt seed phrases using AES-256-GCM with keys derived from the user's password via PBKDF2.
- **Wallet Import**:
  - Allow users to import existing wallets using standard 12/24-word BIP39 seed phrases.
- **Private Key Management**:
  - Never store private keys or seed phrases in plaintext.
  - Keep all sensitive data encrypted and secure.

### 2. User Interface (UI/UX)

- **Design Principles**:
  - Create a clean, intuitive, and responsive UI.
  - Ensure accessibility compliance (WCAG standards).
- **Components**:
  - Build reusable React components.
  - Use functional components with hooks where appropriate.
- **Styling**:
  - Use CSS Modules, Styled Components, or a CSS preprocessor for styling.

### 3. State Management

- **Redux Store**:
  - Set up the Redux store with appropriate middlewares like `redux-thunk` or `redux-saga`.
- **Actions and Reducers**:
  - Define clear and concise actions and reducers.
- **Persisting State**:
  - Use `redux-persist` to persist state securely.
  - Ensure persisted state does not expose sensitive information.

### 4. Blockchain Interaction

- **Ethers.js Integration**:
  - Use Ethers.js for all blockchain interactions.
  - Handle network requests and responses asynchronously with proper error handling.
- **Providers**:
  - Connect to Ethereum nodes via providers like Infura or Alchemy.
- **Transaction Handling**:
  - Implement functions to create, sign, and send transactions securely.
  - Provide real-time transaction status updates to the user.

### 5. DApp Integration

- **Content Script**:
  - Inject a content script to provide `window.ethereum` to web pages.
- **Permission Handling**:
  - Implement a robust permission system for DApp connections.
  - Allow users to manage permissions and revoke access as needed.

### 6. Security Measures

- **Encryption**:
  - Use AES-256-GCM for encrypting sensitive data.
  - Derive encryption keys using PBKDF2 with a unique salt and high iteration count.
- **Authentication**:
  - Enforce strong password policies.
  - Implement biometric authentication where possible using Web Authentication APIs.
- **Data Protection**:
  - Store data securely using `chrome.storage.local` or IndexedDB.
  - Do not log sensitive information.
- **Content Security Policy (CSP)**:
  - Define a strict CSP in the manifest file to prevent XSS attacks.

### 7. Extension Manifest

- **Manifest Version**:
  - Use **Manifest V3** for the Chrome extension.
- **Permissions**:
  - Request only the necessary permissions required for functionality.
- **Background Scripts**:
  - Implement background processes using service workers as per Manifest V3 guidelines.

### 8. Error Handling and Logging

- **Error Handling**:
  - Implement comprehensive error handling throughout the application.
  - Provide user-friendly error messages.
- **Logging**:
  - Use a logging framework that respects user privacy.
  - Do not log sensitive data.

### 9. Testing

- **Unit Testing**:
  - Write unit tests for all components and functions using Jest.
- **Integration Testing**:
  - Test interactions between components and with the blockchain.
- **Security Testing**:
  - Regularly perform security audits and vulnerability scanning.
- **Automated Testing**:
  - Set up continuous integration pipelines to run tests on each commit.

### 10. Performance Optimization

- **Code Splitting**:
  - Implement lazy loading to reduce initial load times.
- **Minification**:
  - Minify and uglify production code to reduce bundle size.
- **Resource Optimization**:
  - Optimize images and other assets.

### 11. Documentation

- **Code Comments**:
  - Document complex logic and public functions.
- **README and Guides**:
  - Maintain up-to-date documentation for setting up and contributing to the project.

### 12. Internationalization (i18n)

- **Preparation for Localization**:
  - Externalize all user-facing strings.
  - Use a library like `react-i18next` for internationalization support.

### 13. Collaboration Practices

- **Version Control**:
  - Commit changes frequently with meaningful commit messages.
- **Branching Strategy**:
  - Use GitFlow or a similar branching strategy.
- **Code Reviews**:
  - All code must be reviewed before merging into the main branch.

---

## Prohibited Practices

- **Hardcoding Sensitive Data**:
  - Do not hardcode private keys, seed phrases, passwords, or any sensitive information.
- **Insecure Dependencies**:
  - Do not use deprecated or unmaintained libraries.
- **Ignoring Security Protocols**:
  - Do not bypass security measures for convenience.
- **Unauthorized Network Calls**:
  - Do not make network requests to untrusted sources.
- **Data Privacy Violations**:
  - Do not collect or transmit user data without explicit consent.

---

## Compliance and Legal

- **Licensing**:
  - Ensure all third-party libraries are used in compliance with their licenses.
- **Privacy Policy**:
  - Ensure that the application complies with data protection regulations like GDPR.
- **User Consent**:
  - Obtain necessary permissions and consents from users for data usage.

---

## Deployment Guidelines

- **Build Configuration**:
  - Ensure the production build is optimized and free from development artifacts.
- **Testing Before Release**:
  - Thoroughly test the extension before packaging for the Chrome Web Store.
- **Compliance with Store Policies**:
  - Verify that the extension meets all Chrome Web Store requirements.
- **Versioning**:
  - Use semantic versioning for all releases.

---

## Final Notes

- **Focus on User Experience**:
  - Always keep the end-user experience in mind when making development decisions.
- **Stay Aligned with Project Goals**:
  - Regularly refer back to the "Product Design" and "Technical Architecture" documents to ensure alignment.
- **Continuous Improvement**:
  - Be open to feedback and ready to iterate on implementations for better performance and usability.

---

Considerations
• The IP and port to which the client must connect and the server must listen are
passed as a parameter.
• It can be assumed that the format of the input parameters will always be correct.
However, must check if the number of parameters is correct.
• The port assigned to the client and server is the one assigned to the group.
• The client is guaranteed to always enter an input followed by a return (\n).
• The server manages who is the winner, clients must only save and display the board
distribution.
• The communication between client and server must be carried out following the
guidelines of the frames indicated in the statement.
• The output of the program must be identical to that of the statement (see execution
examples).
• The use of “system” or “popen” or analogous functions of the same family is not
allowed.
• The use of global variables must be reduced to the minimum possible to make the
program work correctly.
• All input and output must be done with file descriptors, the use of printf, scanf, FILE*,
getchar, or similar is not allowed.
• It must be compiled using the –Wall and –Wextra flags.
• Any practice that contains warnings will be directly discarded.
• All resources must be released.
• A single “S4.c” file must be delivered that will have the names and logins of the group
members commented. Otherwise, the practice will not be corrected.
• The server is guaranteed to never go down as long as a client is connected.
• If an unexpected frame is received the server will print its contents and ignore it.


In examples folder you have the examples of how the code should be written like in which style and what functions they use and dont use.

also you cant write ANY comments in my code.