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

## Build & Development Commands - Ensure `.gitignore` is present and up to date based on project language/toolchain.
## Testing Guidelines - Recommend committing test cases alongside features or fixes.
## Code Style & Guidelines  - Use consistent formatting tools (e.g., Prettier, Black) pre-commit if available.
## Documentation Guidelines  - Include changelogs or commit logs for release notes.
## Git Rules - Use clear commit messages: `<type>: <what>` (e.g., `fix: resolve header overlap`). - Squash trivial commits when possible before merging. - Warn users when suggesting force pushes or rebase.

# 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

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.

Generate a structured, reusable Terraform module for deploying AWS infrastructure components. The module must include:

Module Structure:
- Clearly defined input variables with descriptions and defaults
- Outputs with meaningful resource information
- Secure handling of sensitive inputs (like IAM credentials or secrets)
- Compliance with Terraform best practices for scalability and readability
- Proper file organization (main.tf, variables.tf, outputs.tf)

AWS Infrastructure Components:
- Example using common AWS services (EKS, EC2, S3, IAM roles/policies, security groups, and VPCs)
- Include resource tagging and standard naming conventions

Documentation:
- README with module usage examples
- Inline code comments to clarify configurations and decisions
- Suggestions for module testing and validation

The user has provided the following requirements:

<!-- Sequential Thinking Workflow -->
<assistant>
    <toolbox>
        <mcp_server name="sequential-thinking"
                        role="workflow_controller"
                        execution="sequential-thinking"
                        description="Initiate the sequential-thinking MCP server">
            <tool name="STEP" value="1">
                <description>Gather context by reading the relevant file(s).</description>
                <arguments>
                    <argument name="instructions" value="Seek proper context in the codebase to understand what is required. If you are unsure, ask the user." type="string" required="true"/>
                    <argument name="should_read_entire_file" type="boolean" default="true" required="false"/>
                </arguments>
                <result type="string" description="Context gathered from the file(s). Output can be passed to subsequent steps."/>
            </tool>
            <tool name="STEP" value="2">
                <description>Generate code changes based on the gathered context (from STEP 1).</description>
                <arguments>
                    <argument name="instructions" value="Generate the proper changes/corrections based on context from STEP 1." type="string" required="true"/>
                    <argument name="code_edit" type="object" required="true" description="Output: The proposed code modifications."/>
                </arguments>
                <result type="object" description="The generated code changes (code_edit object). Output can be passed to subsequent steps."/>
            </tool>
            <tool name="STEP" value="3">
                <description>Review the generated changes (from STEP 2) and suggest improvements.</description>
                <arguments>
                    <argument name="instructions" type="string" value="Review the changes applied in STEP 2 for gaps, correctness, and adherence to guidelines. Suggest improvements or identify any additional steps needed." required="true"/>
                </arguments>
                <result type="string" description="Review feedback, suggested improvements, or confirmation of completion. Final output of the workflow."/>
            </tool>
        </mcp_server>
    </toolbox>
</assistant>

Analyze the attached Laravel code and provide a detailed explanation of its structure, functionality, and any potential improvements or optimizations that could be made.
Provide a comprehensive overview of the code's purpose, including any specific requirements or constraints it addresses.
Identify any potential areas of improvement, such as code refactoring, performance enhancements, or architectural improvements.

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

Please write an e2e test using Playwright, following these guidelines:
- Tests live in the app/tests directory
- Tests are split into 3 parts: selectors, actions, and tests
- Selectors live in app/tests/_selectors and are responsible only for getting elements on a give page. Here is an example:
```BlockForm.selectors.ts
import { Page } from "@playwright/test";

export class BlockFormSelectors {
  static readonly getOwnerPersonalRadio = (page: Page) =>
    page.getByLabel("Personal");

  static readonly getSlugInput = (page: Page) =>
    page.getByRole("textbox", { name: "Slug" });

  static readonly getDescriptionInput = (page: Page) =>
    page.getByRole("textbox", { name: "Description" });
}
```

- Actions live in app/tests/_actions and are responsible for taking basic actions in a given part of the application. Here is an example:
```Organization.actions.ts
import { Page } from "@playwright/test";
import { OrganizationFormSelectors } from "../_selectors/OrganizationForm.selectors";
import { NavBarSelectors } from "../_selectors/NavBar.selectors";

export class OrganizationActions {
  public static createOrganization = async ({
    page,
    name,
    slug,
    biography,
  }: {
    page: Page;
    name: string;
    slug: string;
    biography: string;
  }) => {
    await NavBarSelectors.getCreateButton(page).click();
    await NavBarSelectors.getCreateOrganizationButton(page).click();

    await OrganizationFormSelectors.getNameInput(page).fill(name);
    await OrganizationFormSelectors.getSlugInput(page).fill(slug);
    await OrganizationFormSelectors.getBiographyInput(page).fill(biography);

    await OrganizationFormSelectors.getCreateOrganizationButton(page).click();
  };
}
```

- Tests live in app/tests and are the full tests, written with the Jest framework. Here is an example:
```block.spec.ts
_test("Can create a new block", async ({ page }) => {
  const blockName = "Test Block";
  const blockDescription = "Test block description";
  const blockSlug = "test-block";
  const blockRule = "This is a test block rule";

  await BlockActions.createBlock({
    page,
    name: blockName,
    description: blockDescription,
    slug: blockSlug,
    rule: blockRule,
  });

  await GlobalActions.expectPath({
    page,
    path: ROUTES.PACKAGE({
      ownerSlug: TEST_USER_EXPECTED_SLUG,
      packageSlug: blockSlug,
    }),
  });

  await expect(page.getByText(blockName).first()).toBeVisible();
  await expect(page.getByText(blockDescription)).toBeVisible();
  await expect(page.getByText(blockRule)).toBeVisible();
})
```

Please write tests that cover the basic functionality described below, making sure to correctly create the corresponding selectors, actions, and tests in their respective files:

Code refactoring and improvement analysis: identifying bugs, performance issues, and clean code practices

Objective:
Analyze the provided Vue 3 component or service that uses Composition API and Pinia , and perform a complete review based on the following guidelines:

Identify inefficient sections such as slow algorithms or unnecessary resource usage.
Highlight parts that are prone to errors , such as poorly written conditions or lack of exception handling.
Suggest performance optimizations , including more efficient data structures or methods.
Warn about possible security vulnerabilities and how to fix them.
Ensure all variables follow snake_case and functions use camelCase .
Remove unnecessary comments and semicolons .
Apply clean code principles : small functions, single responsibility, low coupling, etc.
Include suggestions for Git commit messages that are clear and descriptive.
Write a Pull Request (PR) summary highlighting the main changes and improvements made.
📋 Structure of the Analysis
Organize your response using the following structure:

🔍 1. Overview of the Component or Service
Brief description of how the component or function works.
What are its main responsibilities?
How does it interact with the Pinia store and other components?
⚙️ 2. Inefficiencies Identified
Where are there repeated or complex logics?
Functions or computed properties doing more than one task?
Improper use of reactivity (e.g., excessive use of watch or unnecessary ref)?
Example: loading data multiple times instead of caching.
🐞 3. Error-Prone Sections
Complex or ambiguous conditions.
Missing validations or error handling (e.g., when data may be null).
Possible lack of user feedback during async operations.
Type-related issues (if using TypeScript).
🚀 4. Performance Optimization Suggestions
Replacement with more efficient data structures (e.g., Map, Set).
Memoization of results using computed or helper functions.
Better use of Vue 3’s reactivity system (avoid redundant computations).
Lazy loading of heavy components or data.
🔐 5. Security Considerations
Check for content injection risks (XSS, v-html, etc.).
Secure handling of sensitive data (tokens, passwords, etc.).
Validation of user input before submission or display.
📦 6. Code Standardization
Rename variables to follow snake_case .
Rename functions to follow camelCase .
Remove outdated comments and unnecessary semicolons.
Apply clean code best practices (clear naming, small functions, etc.).
📁 7. Change Log
For each change made, include:
What was changed
Why the change was needed
What benefit it brought (readability, performance, maintainability)
Save these logs inside the .readme folder.
💾 8. Git Commit Message Suggestions
List clear and concise git commit messages for each relevant change.
Examples:
refactor: remove unused variables and semicolons from date utils
fix: validate null values in image comparison data
perf: memoize computed dates to improve calendar performance
style: rename functions to camelCase for consistency
📝 9. Pull Request Summary
Write a PR summary in either Portuguese or English (depending on your team's convention), including:

The problem being solved
Main changes made
Benefits brought (performance, readability, security)
How to test or verify the changes
Example PR Summary:

This PR refactors the ImageComparison component to improve performance and code readability. Unused variables and functions were removed, naming conventions were standardized, error handling was added for date formatting, and conditional rendering of calendar days was optimized. These changes ensure cleaner code, faster rendering, and fewer errors when handling missing data. 

Additional Instructions:

Use simple and accessible language, explaining each step as if you're teaching someone new.
Whenever possible, include code examples before and after refactoring .
Keep the code clean, well-formatted, and lightly documented if necessary.
Would you like me to apply this template to a real code snippet from your project? Just paste it here and I’ll walk you through the analysis!