The Laravel Boost guidelines are specifically curated by Laravel maintainers for this application. These guidelines should be followed closely to enhance the user's satisfaction building Laravel applications.

This application is a Laravel application and its main Laravel ecosystems package & versions are below. You are an expert with them all. Ensure you abide by these specific packages & versions.

• php - 8.4.16
• filament/filament (FILAMENT) - v4
• laravel/framework (LARAVEL) - v12
• laravel/prompts (PROMPTS) - v0
• livewire/livewire (LIVEWIRE) - v3
• laravel/mcp (MCP) - v0
• laravel/pint (PINT) - v1
• laravel/sail (SAIL) - v1
• pestphp/pest (PEST) - v4
• phpunit/phpunit (PHPUNIT) - v12
• tailwindcss (TAILWINDCSS) - v4

• You must follow all existing code conventions used in this application. When creating or editing a file, check sibling files for the correct structure, approach, and naming.
• Use descriptive names for variables and methods. For example, isRegisteredForDiscounts, not discount().
• Check for existing components to reuse before writing a new one.

• Do not create verification scripts or tinker when tests cover that functionality and prove it works. Unit and feature tests are more important.

• Stick to existing directory structure; don't create new base folders without approval.
• Do not change the application's dependencies without approval.

• If the user doesn't see a frontend change reflected in the UI, it could mean they need to run npm run build, npm run dev, or composer run dev. Ask them.

• Be concise in your explanations - focus on what's important rather than explaining obvious details.

• You must only create documentation files if explicitly requested by the user.

=== boost rules ===

• Laravel Boost is an MCP server that comes with powerful tools designed specifically for this application. Use them.

• Use the list-artisan-commands tool when you need to call an Artisan command to double-check the available parameters.

• Whenever you share a project URL with the user, you should use the get-absolute-url tool to ensure you're using the correct scheme, domain/IP, and port.

• You should use the tinker tool when you need to execute PHP to debug code or query Eloquent models directly.
• Use the database-query tool when you only need to read from the database.

• You can read browser logs, errors, and exceptions using the browser-logs tool from Boost.
• Only recent browser logs will be useful - ignore old logs.

• Boost comes with a powerful search-docs tool you should use before any other approaches when dealing with Laravel or Laravel ecosystem packages. This tool automatically passes a list of installed packages and their versions to the remote Boost API, so it returns only version-specific documentation for the user's circumstance. You should pass an array of packages to filter on if you know you need docs for particular packages.
• The search-docs tool is perfect for all Laravel-related packages, including Laravel, Inertia, Livewire, Filament, Tailwind, Pest, Nova, Nightwatch, etc.
• You must use this tool to search for Laravel ecosystem documentation before falling back to other approaches.
• Search the documentation before making code changes to ensure we are taking the correct approach.
• Use multiple, broad, simple, topic-based queries to start. For example: ['rate limiting', 'routing rate limiting', 'routing'].
• Do not add package names to queries; package information is already shared. For example, use test resource table, not filament 4 test resource table.

• You can and should pass multiple queries at once. The most relevant results will be returned first.

1. Simple Word Searches with auto-stemming - query=authentication - finds 'authenticate' and 'auth'.
2. Multiple Words (AND Logic) - query=rate limit - finds knowledge containing both "rate" AND "limit".
3. Quoted Phrases (Exact Position) - query="infinite scroll" - words must be adjacent and in that order.
4. Mixed Queries - query=middleware "rate limit" - "middleware" AND exact phrase "rate limit".
5. Multiple Queries - queries=["authentication", "middleware"] - ANY of these terms.

=== php rules ===

• Always use curly braces for control structures, even if it has one line.

• Use PHP 8 constructor property promotion in __construct().
  • public function __construct(public GitHub $github) { }
• Do not allow empty __construct() methods with zero parameters unless the constructor is private.

• Always use explicit return type declarations for methods and functions.
• Use appropriate PHP type hints for method parameters.

• Prefer PHPDoc blocks over inline comments. Never use comments within the code itself unless there is something very complex going on.

• Add useful array shape type definitions for arrays when appropriate.

• Typically, keys in an Enum should be TitleCase. For example: FavoritePerson, BestLake, Monthly.

=== tests rules ===

• Every change must be programmatically tested. Write a new test or update an existing test, then run the affected tests to make sure they pass.
• Run the minimum number of tests needed to ensure code quality and speed. Use php artisan test --compact with a specific filename or filter.

=== laravel/core rules ===

• Use php artisan make: commands to create new files (i.e. migrations, controllers, models, etc.). You can list available Artisan commands using the list-artisan-commands tool.
• If you're creating a generic PHP class, use php artisan make:class.
• Pass --no-interaction to all Artisan commands to ensure they work without user input. You should also pass the correct --options to ensure correct behavior.

• Always use proper Eloquent relationship methods with return type hints. Prefer relationship methods over raw queries or manual joins.
• Use Eloquent models and relationships before suggesting raw database queries.
• Avoid DB::; prefer Model::query(). Generate code that leverages Laravel's ORM capabilities rather than bypassing them.
• Generate code that prevents N+1 query problems by using eager loading.
• Use Laravel's query builder for very complex database operations.

• When creating new models, create useful factories and seeders for them too. Ask the user if they need any other things, using list-artisan-commands to check the available options to php artisan make:model.

• For APIs, default to using Eloquent API Resources and API versioning unless existing API routes do not, then you should follow existing application convention.

• Always create Form Request classes for validation rather than inline validation in controllers. Include both validation rules and custom error messages.
• Check sibling Form Requests to see if the application uses array or string based validation rules.

• Use queued jobs for time-consuming operations with the ShouldQueue interface.

• Use Laravel's built-in authentication and authorization features (gates, policies, Sanctum, etc.).

• When generating links to other pages, prefer named routes and the route() function.

• Use environment variables only in configuration files - never use the env() function directly outside of config files. Always use config('app.name'), not env('APP_NAME').

• When creating models for tests, use the factories for the models. Check if the factory has custom states that can be used before manually setting up the model.
• Faker: Use methods such as $this->faker->word() or fake()->randomDigit(). Follow existing conventions whether to use $this->faker or fake().
• When creating tests, make use of php artisan make:test [options] {name} to create a feature test, and pass --unit to create a unit test. Most tests should be feature tests.

• If you receive an "Illuminate\Foundation\ViteException: Unable to locate file in Vite manifest" error, you can run npm run build or ask the user to run npm run dev or composer run dev.

=== laravel/v12 rules ===

• Use the search-docs tool to get version-specific documentation.
• Since Laravel 11, Laravel has a new streamlined file structure which this project uses.

• In Laravel 12, middleware are no longer registered in app/Http/Kernel.php.
• Middleware are configured declaratively in bootstrap/app.php using Application::configure()->withMiddleware().
• bootstrap/app.php is the file to register middleware, exceptions, and routing files.
• bootstrap/providers.php contains application specific service providers.
• The app\Console\Kernel.php file no longer exists; use bootstrap/app.php or routes/console.php for console configuration.
• Console commands in app/Console/Commands/ are automatically available and do not require manual registration.

• When modifying a column, the migration must include all of the attributes that were previously defined on the column. Otherwise, they will be dropped and lost.
• Laravel 12 allows limiting eagerly loaded records natively, without external packages: $query->latest()->limit(10);.

• Casts can and likely should be set in a casts() method on a model rather than the $casts property. Follow existing conventions from other models.

=== livewire/core rules ===

• Use the search-docs tool to find exact version-specific documentation for how to write Livewire and Livewire tests.
• Use the php artisan make:livewire [Posts\CreatePost] Artisan command to create new components.
• State should live on the server, with the UI reflecting it.
• All Livewire requests hit the Laravel backend; they're like regular HTTP requests. Always validate form data and run authorization checks in Livewire actions.

• Livewire components require a single root element.

• Use wire:loading and wire:dirty for delightful loading states.

• Add wire:key in loops:

  @foreach ($items as $item)
      <div wire:key="item-{{ $item->id }}">
          {{ $item->name }}
      </div>
  @endforeach

• Prefer lifecycle hooks like mount(), updatedFoo() for initialization and reactive side effects:

=== livewire/v3 rules ===

• These things changed in Livewire 3, but may not have been updated in this application. Verify this application's setup to ensure you conform with application conventions.
  • Use wire:model.live for real-time updates, wire:model is now deferred by default.
  • Components now use the App\Livewire namespace (not App\Http\Livewire).
  • Use $this->dispatch() to dispatch events (not emit or dispatchBrowserEvent).
  • Use the components.layouts.app view as the typical layout path (not layouts.app).

• wire:show, wire:transition, wire:cloak, wire:offline, wire:target are available for use. Use the documentation to find usage examples.

• Alpine is now included with Livewire; don't manually include Alpine.js.
• Plugins included with Alpine: persist, intersect, collapse, and focus.

• You can listen for livewire:init to hook into Livewire initialization, and fail.status === 419 for the page expiring:

Livewire.hook('message.failed', (message, component) => {
    console.error(message);
});

});

=== pint/core rules ===

• You must run vendor/bin/pint --dirty before finalizing changes to ensure your code matches the project's expected style.
• Do not run vendor/bin/pint --test, simply run vendor/bin/pint to fix any formatting issues.

=== pest/core rules ===

• If you need to verify a feature is working, write or update a Unit / Feature test.

• All tests must be written using Pest. Use php artisan make:test --pest {name}.
• You must not remove any tests or test files from the tests directory without approval. These are not temporary or helper files - these are core to the application.
• Tests should test all of the happy paths, failure paths, and weird paths.
• Tests live in the tests/Feature and tests/Unit directories.
• Pest tests look and behave like this:

• Run the minimal number of tests using an appropriate filter before finalizing code edits.
• To run all tests: php artisan test --compact.
• To run all tests in a file: php artisan test --compact tests/Feature/ExampleTest.php.
• To filter on a particular test name: php artisan test --compact --filter=testName (recommended after making a change to a related file).
• When the tests relating to your changes are passing, ask the user if they would like to run the entire test suite to ensure everything is still passing.

• When asserting status codes on a response, use the specific method like assertForbidden and assertNotFound instead of using assertStatus(403) or similar, e.g.:

$response->assertSuccessful();

});

• Mocking can be very helpful when appropriate.
• When mocking, you can use the Pest\Laravel\mock Pest function, but always import it via use function Pest\Laravel\mock; before using it. Alternatively, you can use $this->mock() if existing tests do.
• You can also create partial mocks using the same import or self method.

• Use datasets in Pest to simplify tests that have a lot of duplicated data. This is often the case when testing validation rules, so consider this solution when writing tests for validation rules.

=== pest/v4 rules ===

• Pest 4 is a huge upgrade to Pest and offers: browser testing, smoke testing, visual regression testing, test sharding, and faster type coverage.
• Browser testing is incredibly powerful and useful for this project.
• Browser tests should live in tests/Browser/.
• Use the search-docs tool for detailed guidance on utilizing these features.

• You can use Laravel features like Event::fake(), assertAuthenticated(), and model factories within Pest 4 browser tests, as well as RefreshDatabase (when needed) to ensure a clean state for each test.
• Interact with the page (click, type, scroll, select, submit, drag-and-drop, touch gestures, etc.) when appropriate to complete the test.
• If requested, test on multiple browsers (Chrome, Firefox, Safari).
• If requested, test on different devices and viewports (like iPhone 14 Pro, tablets, or custom breakpoints).
• Switch color schemes (light/dark mode) when appropriate.
• Take screenshots or pause tests for debugging when appropriate.

$this->actingAs(User::factory()->create());

$page = visit('/sign-in'); // Visit on a real browser...

$page->assertSee('Sign In')
    ->assertNoJavascriptErrors() // or ->assertNoConsoleLogs()
    ->click('Forgot Password?')
    ->fill('email', '[email protected]')
    ->click('Send Reset Link')
    ->assertSee('We have emailed your password reset link!')

Notification::assertSent(ResetPassword::class);

});

$pages->assertNoJavascriptErrors()->assertNoConsoleLogs();

=== tailwindcss/core rules ===

• Use Tailwind CSS classes to style HTML; check and use existing Tailwind conventions within the project before writing your own.
• Offer to extract repeated patterns into components that match the project's conventions (i.e. Blade, JSX, Vue, etc.).
• Think through class placement, order, priority, and defaults. Remove redundant classes, add classes to parent or child carefully to limit repetition, and group elements logically.
• You can use the search-docs tool to get exact examples from the official documentation when needed.

• When listing items, use gap utilities for spacing; don't use margins.

• If existing pages and components support dark mode, new pages and components must support dark mode in a similar way, typically using dark:.

=== tailwindcss/v4 rules ===

• Always use Tailwind CSS v4; do not use the deprecated utilities.
• corePlugins is not supported in Tailwind v4.
• In Tailwind v4, configuration is CSS-first using the @theme directive — no separate tailwind.config.js file is needed.

• In Tailwind v4, you import Tailwind using a regular CSS @import statement, not using the @tailwind directives used in v3:

• Tailwind v4 removed deprecated utilities. Do not use the deprecated option; use the replacement.
• Opacity values are still numeric.

| Deprecated | Replacement | |------------+--------------| | bg-opacity-* | bg-black/* | | text-opacity-* | text-black/* | | border-opacity-* | border-black/* | | divide-opacity-* | divide-black/* | | ring-opacity-* | ring-black/* | | placeholder-opacity-* | placeholder-black/* | | flex-shrink-* | shrink-* | | flex-grow-* | grow-* | | overflow-ellipsis | text-ellipsis | | decoration-slice | box-decoration-slice | | decoration-clone | box-decoration-clone |