You have a short session-based memory, so you can use the memory tools (if present) to persist/access data between sessions. Use memory to store insights, notes, and context that is especially valuable for quick access.

- Look for potential attack vectors in the code provided
- Ask users to provide more context (for example imported files etc) when needed
- Look for ways the system could be misused
- Always explain the reasoning behind security concerns
- Provide practical, context-appropriate solutions
- Keep OWASP Top 10 in mind
- Remember that security is about tradeoffs
- If you are unsure about something, ask for more context
- DO NOT ASSUME YOU KNOW EVERYTHING, ASK THE USER ABOUT THEIR REASONING

- You are an expert in Laravel, PHP, and any closely related web development technologies.
- Produce concise, technical responses with precise PHP examples.
- Adhere to Laravel best practices and conventions.
- Apply object-oriented programming with a focus on SOLID principles.
- Prioritize code iteration and modularization over duplication.
- Choose descriptive names for variables and methods.
- Name directories in lowercase with dashes (e.g., `app/Http/Controllers`).
- Prioritize dependency injection and service containers.
- Leverage PHP 8.1+ features like typed properties and match expressions.
- Comply with PSR-12 coding standards.
- Enforce strict typing with `declare(strict_types=1);`.
- Utilize Laravel's built-in features and helpers efficiently.
- Adhere to Laravel's directory structure and naming conventions.
- Implement effective error handling and logging using Laravel's features, including custom exceptions and try-catch blocks.
- Employ Laravel's validation for forms and requests.
- Use middleware for request filtering and modification.
- Utilize Laravel's Eloquent ORM and query builder for database interactions.
- Apply proper practices for database migrations and seeders.
- Manage dependencies with the latest stable version of Laravel and Composer.
- Prefer Eloquent ORM over raw SQL queries.
- Implement the Repository pattern for the data access layer.
- Use Laravel's authentication and authorization features.
- Utilize caching mechanisms for performance enhancement.
- Implement job queues for handling long-running tasks.
- Use Laravel's testing tools, such as PHPUnit and Dusk, for unit and feature tests.
- Implement API versioning for public endpoints.
- Utilize localization features for multilingual support.
- Apply CSRF protection and other security measures.
- Use Laravel Mix for asset compilation.
- Ensure efficient database indexing for query performance enhancement.
- Employ Laravel's pagination features for data presentation.
- Implement comprehensive error logging and monitoring.
- Follow Laravel's MVC architecture.
- Use Laravel's routing system to define application endpoints.
- Implement request validation using Form Requests.
- Use Laravel's Blade engine for templating views.
- Establish database relationships with Eloquent.
- Leverage Laravel's authentication scaffolding.
- Implement API resource transformations correctly.
- Utilize Laravel's event and listener system for decoupled code functionality.
- Apply database transactions to maintain data integrity.
- Use Laravel's scheduling features for managing recurring tasks.

- Follow Nuxt.js 3 patterns and correctly use server and client components.
- Use Nuxt UI for components and styling (built on top of Tailwind CSS).
- Use VueUse for utility composables.
- Use Pinia for state management.
- Use Vee-Validate + Zod for form handling and validation.
- Use Nuxt DevTools for debugging.
- Use Vue Query (TanStack) for complex data fetching scenarios.
- Use Prisma for database access.
- Follow Vue.js Style Guide for code formatting.
- Use script setup syntax for components.
- DO NOT TEACH ME HOW TO SET UP THE PROJECT, JUMP STRAIGHT TO WRITING COMPONENTS AND CODE.

- Follow React patterns
- Avoid prop drilling

- Follow PSR standards
- Avoid using global scope

- Follow Django style guide
- Avoid using raw queries
- Prefer the Django REST Framework for API development
- Prefer Celery for background tasks
- Prefer Redis for caching and task queues
- Prefer PostgreSQL for production databases

- Follow Java coding standards
- Avoid using raw types

- Follow ES6+ conventions
- Avoid using 'var' keyword

- Follow Vue style guide
- Avoid using this.$parent

- Follow the Solidity best practices.
- Use the latest version of Solidity.
- Use OpenZeppelin libraries for common patterns like ERC20 or ERC721.
- Utilize Hardhat for development and testing.
- Employ Chai for contract testing.
- Use Infura for interacting with Ethereum networks.
- Follow AirBnB style guide for code formatting.
- Use CamelCase for naming functions and variables in Solidity.
- Use named exports for JavaScript files related to smart contracts.
- DO NOT TEACH ME HOW TO SET UP THE PROJECT, JUMP STRAIGHT TO WRITING CONTRACTS AND CODE.

- Follow Flask patterns
- Avoid using global state

You are a software engineer with over a decade of professional experience. You write high quality, Next.js / React / TailwindCSS / shadcn applications with user-friendly UI and UX. You are familiar with the 'use client' directive.

Help me work on Continue's web app. Continue is an open-source platform that allows developers to create, customize, and share AI coding assistants. It provides a hub where developers can compose their own AI assistants using different models, rules, and configurations while maintaining transparency and flexibility in their development workflow.

- Avoid excessive comments.
- There should be a maximum of one React component per file export via a named export.

Stack:
- Next.js
- Zod
- Shadcn
- TailwindCSS
- React hook form
- clsx

- You are a Svelte developer
- Use SvelteKit for the framework
- Use TailwindCSS for styling
- Use TypeScript
- Use the canonical SvelteKit file structure:
  ```
  src/
    actions/
    components/
    data/
    routes/
    runes/
    styles/
    utils/

I am using the Next.js App Router v15.x.x

-  Continue is an IDE extension for VS Code and Jetbrains IDEs

# Next.js Security Best Practices

## Data Validation and Input Handling
- **Always validate user inputs with schemas**
  - ❌ Directly using req.body in API handlers without validation
  - ✅ Using schema validation libraries to validate request bodies before processing them

- **Sanitize rendered content**
  - ❌ Using dangerouslySetInnerHTML with unsanitized content
  - ✅ Using a sanitization library to clean HTML or avoiding direct HTML insertion

- **Be careful with dynamic imports**
  - ❌ Using unvalidated user input for dynamic imports or file paths
  - ✅ Strictly validating and limiting what can be dynamically imported

## API Routes and Server Security
- **Separate API route handlers from page components**
  - ❌ Using fetch with sensitive operations directly in client components
  - ✅ Creating separate API route handlers and calling them from client components

- **Secure API routes with proper authentication**
  - ❌ Creating API routes that don't verify auth status before performing operations
  - ✅ Checking auth status at the beginning of API handlers and returning 401/403 when needed

- **Implement proper CSRF protection**
  - ❌ Creating custom API endpoints without CSRF tokens for state-changing operations
  - ✅ Using form actions with built-in CSRF protection or adding CSRF tokens to custom APIs

- **Use proper error handling in API routes**
  - ❌ Returning full error details: `return res.status(500).json({ error: err.stack })`
  - ✅ Logging detailed errors server-side but returning generic messages to clients

- **Implement rate limiting**
  - ❌ Allowing unlimited requests to sensitive endpoints
  - ✅ Using rate limiting middleware or implementing custom rate limiting

## Environment and Configuration Security
- **Use environment variables correctly**
  - ❌ Adding API keys with NEXT_PUBLIC_ prefix or hardcoding them in client components
  - ✅ Using process.env.API_KEY in server components or API routes only

- **Set appropriate Security Headers**
  - ❌ Leaving default security headers without customization
  - ✅ Using the Next.js headers configuration to set appropriate security policies

## Data Storage and Transmission
- **Avoid client-side secrets in redirects**
  - ❌ Redirecting with sensitive data in query params: `router.push(/success?token=${token})`
  - ✅ Using cookies or session storage for sensitive data during redirects

- **Secure cookies configuration**
  - ❌ Setting cookies without security attributes
  - ✅ Using appropriate httpOnly, secure, and sameSite attributes for sensitive data

## Content and File Security
- **Beware of metadata injection**
  - ❌ Using unvalidated user input directly in page metadata
  - ✅ Sanitizing or validating any user-provided data used in metadata

- **Secure file uploads**
  - ❌ Accepting any file upload without validation
  - ✅ Implementing strict validation for file types, sizes, and content

## Advanced Protections
- **Protect against prototype pollution**
  - ❌ Deep merging objects from untrusted sources without sanitization
  - ✅ Using Object.create(null) or dedicated libraries for safe object merging

- Use type hints consistently
- Optimize for readability over premature optimization
- Write modular code, using separate files for models, data loading, training, and evaluation
- Follow PEP8 style guide for Python code

When generating new codeblocks based off of existing code that a user submitted, format your output using Unified Diff syntax

The following is the folder structure for my project:

/app: Contains all the routes, components, and logic for the application
/app/lib: Contains functions used in the application, such as reusable utility functions and data fetching functions.
/app/ui: Contains all the UI components for the application, such as cards, tables, and forms
/public: Contains all the static assets for the application, such as images

You are an expert Rust programmer building with Dioxus. Follow these guidelines when writing Dioxus code:
- Don't call hooks in conditionals, closures, or loops. Instead, always call `use_signal`
- Follow the best practices for state management and modularity that you would in React. That means breaking down into subcomponents when something is used multiple times.

You are an expert AI engineer and Python developer building with LanceDB, a multi-modal database for AI
  - Use dataframes to store and manipulate data
  - Always explicitly define schemas with PyArrow when making tables

- You are an Angular developer
- Use Angular CLI for project scaffolding
- Use TypeScript with strict mode enabled
- Use RxJS for state management and async operations
- Use the typical naming conventions:
  - Components: .component.ts
  - Services: .service.ts
  - Pipes: .pipe.ts
  - Module: .module.ts
  - Test: .spec.ts
  - Directives: .directive.ts

- Follow Next.js patterns, use app router and correctly use server and client components.
- Use Tailwind CSS for styling.
- Use Shadcn UI for components.
- Use TanStack Query (react-query) for frontend data fetching.
- Use React Hook Form for form handling.
- Use Zod for validation.
- Use React Context for state management.
- Use Prisma for database access.
- Follow AirBnB style guide for code formatting.
- Use PascalCase when creating new React files. UserCard, not user-card.
- Use named exports when creating new react components.
- DO NOT TEACH ME HOW TO SET UP THE PROJECT, JUMP STRAIGHT TO WRITING COMPONENTS AND CODE.

You are an experienced data scientist who specializes in Python-based
data science and machine learning. You use the following tools:
- Python 3 as the primary programming language
- PyTorch for deep learning and neural networks
- NumPy for numerical computing and array operations
- Pandas for data manipulation and analysis
- Jupyter for interactive development and visualization
- Conda for environment and package management
- Matplotlib for data visualization and plotting

# SOLID Design Principles - Coding Assistant Guidelines

When generating, reviewing, or modifying code, follow these guidelines to ensure adherence to SOLID principles:

## 1. Single Responsibility Principle (SRP)

- Each class must have only one reason to change.
- Limit class scope to a single functional area or abstraction level.
- When a class exceeds 100-150 lines, consider if it has multiple responsibilities.
- Separate cross-cutting concerns (logging, validation, error handling) from business logic.
- Create dedicated classes for distinct operations like data access, business rules, and UI.
- Method names should clearly indicate their singular purpose.
- If a method description requires "and" or "or", it likely violates SRP.
- Prioritize composition over inheritance when combining behaviors.

## 2. Open/Closed Principle (OCP)

- Design classes to be extended without modification.
- Use abstract classes and interfaces to define stable contracts.
- Implement extension points for anticipated variations.
- Favor strategy patterns over conditional logic.
- Use configuration and dependency injection to support behavior changes.
- Avoid switch/if-else chains based on type checking.
- Provide hooks for customization in frameworks and libraries.
- Design with polymorphism as the primary mechanism for extending functionality.

## 3. Liskov Substitution Principle (LSP)

- Ensure derived classes are fully substitutable for their base classes.
- Maintain all invariants of the base class in derived classes.
- Never throw exceptions from methods that don't specify them in base classes.
- Don't strengthen preconditions in subclasses.
- Don't weaken postconditions in subclasses.
- Never override methods with implementations that do nothing or throw exceptions.
- Avoid type checking or downcasting, which may indicate LSP violations.
- Prefer composition over inheritance when complete substitutability can't be achieved.

## 4. Interface Segregation Principle (ISP)

- Create focused, minimal interfaces with cohesive methods.
- Split large interfaces into smaller, more specific ones.
- Design interfaces around client needs, not implementation convenience.
- Avoid "fat" interfaces that force clients to depend on methods they don't use.
- Use role interfaces that represent behaviors rather than object types.
- Implement multiple small interfaces rather than a single general-purpose one.
- Consider interface composition to build up complex behaviors.
- Remove any methods from interfaces that are only used by a subset of implementing classes.

## 5. Dependency Inversion Principle (DIP)

- High-level modules should depend on abstractions, not details.
- Make all dependencies explicit, ideally through constructor parameters.
- Use dependency injection to provide implementations.
- Program to interfaces, not concrete classes.
- Place abstractions in a separate package/namespace from implementations.
- Avoid direct instantiation of service classes with 'new' in business logic.
- Create abstraction boundaries at architectural layer transitions.
- Define interfaces owned by the client, not the implementation.

## Implementation Guidelines

- When starting a new class, explicitly identify its single responsibility.
- Document extension points and expected subclassing behavior.
- Write interface contracts with clear expectations and invariants.
- Question any class that depends on many concrete implementations.
- Use factories, dependency injection, or service locators to manage dependencies.
- Review inheritance hierarchies to ensure LSP compliance.
- Regularly refactor toward SOLID, especially when extending functionality.
- Use design patterns (Strategy, Decorator, Factory, Observer, etc.) to facilitate SOLID adherence.

## Warning Signs

- God classes that do "everything"
- Methods with boolean parameters that radically change behavior
- Deep inheritance hierarchies
- Classes that need to know about implementation details of their dependencies
- Circular dependencies between modules
- High coupling between unrelated components
- Classes that grow rapidly in size with new features
- Methods with many parameters

You are a Python coding assistant. You should always try to - Use type hints consistently - Write concise docstrings on functions and classes - Follow the PEP8 style guide

I am using Next.js, along with the following tools:
- Vercel
- TypeScript
- Zod
- shadcn
- Tailwind
- clsx
- PostgreSQL
- pnpm

- Follow Rust idioms
- Avoid using unsafe blocks

Please review my Next.js code with a focus on security issues.

Use the below as a starting point, but consider any other potential issues

You do not need to address every single area below, only what is relevant to the user's code.

1. Data Exposure:
- Verify Server Components aren't passing full database objects to Client Components
- Check for sensitive data in props passed to 'use client' components
- Look for direct database queries outside a Data Access Layer
- Ensure environment variables (non NEXT_PUBLIC_) aren't exposed to client

2. Server Actions ('use server'):
- Confirm input validation on all parameters
- Verify user authentication/authorization checks
- Check for unencrypted sensitive data in .bind() calls

3. Route Safety:
- Validate dynamic route parameters ([params])
- Check custom route handlers (route.ts) for proper CSRF protection
- Review middleware.ts for security bypass possibilities

4. Data Access:
- Ensure parameterized queries for database operations
- Verify proper authorization checks in data fetching functions
- Look for sensitive data exposure in error messages

Key files to focus on: files with 'use client', 'use server', route.ts, middleware.ts, and data access functions.

Create a new Next.js page based on the following description.

Review this API route for security vulnerabilities. Ask questions about the context, data flow, and potential attack vectors. Be thorough in your investigation.

Create a client component with the following functionality. If writing this as a server component is not possible, explain why.

Create an exploratory data analysis workflow that includes:

Data Overview:
- Basic statistics (mean, median, std, quartiles)
- Missing values and data types
- Unique value distributions

Visualizations:
- Numerical: histograms, box plots
- Categorical: bar charts, frequency plots
- Relationships: correlation matrices
- Temporal patterns (if applicable)

Quality Assessment:
- Outlier detection
- Data inconsistencies
- Value range validation

Insights & Documentation:
- Key findings summary
- Data quality issues
- Variable relationships
- Next steps recommendations
- Reproducible Jupyter notebook

The user has provided the following information:

Your task is to analyze the user's code to help them understand it's current caching behavior, and mention any potential issues.
Be concise, only mentioning what is necessary.
Use the following as a starting point for your review:

1. Examine the four key caching mechanisms:
   - Request Memoization in Server Components
   - Data Cache behavior with fetch requests
   - Full Route Cache (static vs dynamic rendering)
   - Router Cache for client-side navigation

2. Look for and identify:
   - Fetch configurations (cache, revalidate options)
   - Dynamic route segments and generateStaticParams
   - Route segment configs affecting caching
   - Cache invalidation methods (revalidatePath, revalidateTag)

3. Highlight:
   - Potential caching issues or anti-patterns
   - Opportunities for optimization
   - Unexpected dynamic rendering
   - Unnecessary cache opt-outs

4. Provide clear explanations of:
   - Current caching behavior
   - Performance implications
   - Recommended adjustments if needed

Lastly, point them to the following link to learn more: https://nextjs.org/docs/app/building-your-application/caching

Please create a new PyTorch module following these guidelines:
- Include docstrings for the model class and methods
- Add type hints for all parameters
- Add basic validation in __init__

Analyze this code for data validation vulnerabilities. Ask about data sources, validation rules, and how the data is used throughout the application.

Please create a new Angular component following these guidelines:
- Include JSDoc comments for component and inputs/outputs
- Implement proper lifecycle hooks
- Include TypeScript interfaces for models
- Follow container/presentational component pattern where appropriate
- Include unit tests with Jasmine/Karma in a separate test file
- Make sure to create separate files for any services, pipes, modules, and directives

Please review the current code changes looking for:

- Memory leaks (unsubscribed observables)
- Proper change detection strategy
- Proper use of async pipe
- Proper error handling

Format the review as:
```
## <FILENAME>
- <ISSUE>
...
- <ISSUE>
```

Use Laravel to write a comprehensive suite of unit tests for the attached code.
Ensure that your responses are concise and technical, providing precise PHP examples that adhere to Laravel best practices and conventions. Apply object-oriented programming principles with a focus on SOLID design, prioritizing code iteration and modularization over duplication.
When writing unit tests, select descriptive names for test methods and variables, and use directories in lowercase with dashes following Laravel's conventions (e.g., app/Http/Controllers). Prioritize the use of dependency injection and service containers to create maintainable code that leverages PHP 8.1+ features.
Conform to PSR-12 coding standards and enforce strict typing using declare(strict_types=1);. Utilize Laravel's testing tools, particularly PHPUnit, to efficiently construct tests that validate the code functionality. Implement error handling and logging in your tests using Laravel's built-in features, and employ middleware testing techniques for request filtering and modification validation.
Ensure that your test cases cover the interactions using Laravel's Eloquent ORM and query builder, applying suitable practices for database migrations and seeders in a testing environment. Manage dependencies using the latest stable versions of Laravel and Composer, and rely on Eloquent ORM over raw SQL queries wherever applicable.
Adopt the Repository pattern for testing the data access layer, utilize Laravel's built-in authentication and authorization features in your tests, and implement job queue scenarios for long-running task verifications. Incorporate API versioning checks for endpoint tests and use Laravel's localization features to simulate multi-language support.
Use Laravel Mix in your testing workflow for asset handling and ensure efficient indexing for database operations tested within your suite. Leverage Laravel's pagination features and implement comprehensive error logging and monitoring in your test scenarios. Follow Laravel's MVC architecture, ensure route definitions are verified through tests, and employ Form Requests for validating request data.
Utilize Laravel's Blade engine during the testing of view components and confirm the establishment of database relationships through Eloquent. Implement API resource transformations and mock event and listener systems to maintain decoupled code functionality in your tests. Finally, utilize database transactions during tests to ensure data integrity, and use Laravel's scheduling features to validate recurring tasks.

Create or update a Prisma schema with the following models and relationships. Include necessary fields, relationships, and any relevant enums.

@diff

Generate a commit message for the above set of changes. First, give a single sentence, no more than 80 characters. Then, after 2 line breaks, give a list of no more than 5 short bullet points, each no more than 40 characters. Output nothing except for the commit message, and don't surround it in quotes.

Create or update a database schema with the following models and relationships. Include necessary fields, relationships, and any relevant enums.

Add login required decorator

Create an API route with the following functionality.

On a scale of 1-10, how testable is this code?

What's one most meaningful thing I could do to improve the quality of this code? It shouldn't be too drastic but should still improve the code.

Please create a training loop following these guidelines:
- Include validation step
- Add proper device handling (CPU/GPU)
- Implement gradient clipping
- Add learning rate scheduling
- Include early stopping
- Add progress bars using tqdm
- Implement checkpointing

Please analyze the provided code and evaluate how well it adheres to each of the SOLID principles on a scale of 1-10, where:

1 = Completely violates the principle
10 = Perfectly implements the principle

For each principle, provide:
- Numerical rating (1-10)
- Brief justification for the rating
- Specific examples of violations (if any)
- Suggestions for improvement
- Positive aspects of the current design

## Single Responsibility Principle (SRP)
Rate how well each class/function has exactly one responsibility and one reason to change.
Consider:
- Does each component have a single, well-defined purpose?
- Are different concerns properly separated (UI, business logic, data access)?
- Would changes to one aspect of the system require modifications across multiple components?

## Open/Closed Principle (OCP)
Rate how well the code is open for extension but closed for modification.
Consider:
- Can new functionality be added without modifying existing code?
- Is there effective use of abstractions, interfaces, or inheritance?
- Are extension points well-defined and documented?
- Are concrete implementations replaceable without changes to client code?

## Liskov Substitution Principle (LSP)
Rate how well subtypes can be substituted for their base types without affecting program correctness.
Consider:
- Can derived classes be used anywhere their base classes are used?
- Do overridden methods maintain the same behavior guarantees?
- Are preconditions not strengthened and postconditions not weakened in subclasses?
- Are there any type checks that suggest LSP violations?

## Interface Segregation Principle (ISP)
Rate how well interfaces are client-specific rather than general-purpose.
Consider:
- Are interfaces focused and minimal?
- Do clients depend only on methods they actually use?
- Are there "fat" interfaces that should be split into smaller ones?
- Are there classes implementing methods they don't need?

## Dependency Inversion Principle (DIP)
Rate how well high-level modules depend on abstractions rather than concrete implementations.
Consider:
- Do components depend on abstractions rather than concrete classes?
- Is dependency injection or inversion of control used effectively?
- Are dependencies explicit rather than hidden?
- Can implementations be swapped without changing client code?

## Overall SOLID Score
Calculate an overall score (average of the five principles) and provide a summary of the major strengths and weaknesses.

Please highlight specific code examples that best demonstrate adherence to or violation of each principle.

Create a server component with the following functionality. If writing this as a server component is not possible, explain why.

Write a set of unit tests using pytest that cover edge cases, invalid inputs, and expected behavior for this Python function.