🎉 First commit

.cursor/mcp.json

@@ -0,0 +1,11 @@
+{
+    "mcpServers": {
+        "laravel-boost": {
+            "command": "php",
+            "args": [
+                "artisan",
+                "boost:mcp"
+            ]
+        }
+    }
+}

.cursor/rules/laravel-boost.mdc

@@ -0,0 +1,264 @@
+---
+alwaysApply: true
+---
+<laravel-boost-guidelines>
+=== foundation rules ===
+
+# Laravel Boost Guidelines
+
+The Laravel Boost guidelines are specifically curated by Laravel maintainers for this application. These guidelines should be followed closely to ensure the best experience when building Laravel applications.
+
+## Foundational Context
+
+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
+- laravel/fortify (FORTIFY) - v1
+- laravel/framework (LARAVEL) - v12
+- laravel/prompts (PROMPTS) - v0
+- livewire/flux (FLUXUI_FREE) - v2
+- livewire/livewire (LIVEWIRE) - v4
+- laravel/mcp (MCP) - v0
+- laravel/pint (PINT) - v1
+- laravel/sail (SAIL) - v1
+- pestphp/pest (PEST) - v4
+- phpunit/phpunit (PHPUNIT) - v12
+
+## Skills Activation
+
+This project has domain-specific skills available. You MUST activate the relevant skill whenever you work in that domain—don't wait until you're stuck.
+
+- `fluxui-development` — Develops UIs with Flux UI Free components. Activates when creating buttons, forms, modals, inputs, dropdowns, checkboxes, or UI components; replacing HTML form elements with Flux; working with flux: components; or when the user mentions Flux, component library, UI components, form fields, or asks about available Flux components.
+- `livewire-development` — Develops reactive Livewire 4 components. Activates when creating, updating, or modifying Livewire components; working with wire:model, wire:click, wire:loading, or any wire: directives; adding real-time updates, loading states, or reactivity; debugging component behavior; writing Livewire tests; or when the user mentions Livewire, component, counter, or reactive UI.
+- `pest-testing` — Tests applications using the Pest 4 PHP framework. Activates when writing tests, creating unit or feature tests, adding assertions, testing Livewire components, browser testing, debugging test failures, working with datasets or mocking; or when the user mentions test, spec, TDD, expects, assertion, coverage, or needs to verify functionality works.
+
+## Conventions
+
+- 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.
+
+## Verification Scripts
+
+- Do not create verification scripts or tinker when tests cover that functionality and prove they work. Unit and feature tests are more important.
+
+## Application Structure & Architecture
+
+- Stick to existing directory structure; don't create new base folders without approval.
+- Do not change the application's dependencies without approval.
+
+## Frontend Bundling
+
+- 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.
+
+## Documentation Files
+
+- You must only create documentation files if explicitly requested by the user.
+
+## Replies
+
+- Be concise in your explanations - focus on what's important rather than explaining obvious details.
+
+=== boost rules ===
+
+# Laravel Boost
+
+- Laravel Boost is an MCP server that comes with powerful tools designed specifically for this application. Use them.
+
+## Artisan
+
+- Use the `list-artisan-commands` tool when you need to call an Artisan command to double-check the available parameters.
+
+## URLs
+
+- 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.
+
+## Tinker / Debugging
+
+- 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.
+
+## Reading Browser Logs With the `browser-logs` Tool
+
+- 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.
+
+## Searching Documentation (Critically Important)
+
+- Boost comes with a powerful `search-docs` tool you should use before trying other approaches when working 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.
+- Search the documentation before making code changes to ensure we are taking the correct approach.
+- Use multiple, broad, simple, topic-based queries at once. For example: `['rate limiting', 'routing rate limiting', 'routing']`. The most relevant results will be returned first.
+- Do not add package names to queries; package information is already shared. For example, use `test resource table`, not `filament 4 test resource table`.
+
+### Available Search Syntax
+
+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 ===
+
+# PHP
+
+- Always use curly braces for control structures, even for single-line bodies.
+
+## Constructors
+
+- Use PHP 8 constructor property promotion in `__construct()`.
+    - <code-snippet>public function __construct(public GitHub $github) { }</code-snippet>
+- Do not allow empty `__construct()` methods with zero parameters unless the constructor is private.
+
+## Type Declarations
+
+- Always use explicit return type declarations for methods and functions.
+- Use appropriate PHP type hints for method parameters.
+
+<code-snippet name="Explicit Return Types and Method Params" lang="php">
+protected function isAccessible(User $user, ?string $path = null): bool
+{
+    ...
+}
+</code-snippet>
+
+## Enums
+
+- Typically, keys in an Enum should be TitleCase. For example: `FavoritePerson`, `BestLake`, `Monthly`.
+
+## Comments
+
+- Prefer PHPDoc blocks over inline comments. Never use comments within the code itself unless the logic is exceptionally complex.
+
+## PHPDoc Blocks
+
+- Add useful array shape type definitions when appropriate.
+
+=== herd rules ===
+
+# Laravel Herd
+
+- The application is served by Laravel Herd and will be available at: `https?://[kebab-case-project-dir].test`. Use the `get-absolute-url` tool to generate valid URLs for the user.
+- You must not run any commands to make the site available via HTTP(S). It is always available through Laravel Herd.
+
+=== tests rules ===
+
+# Test Enforcement
+
+- 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 ===
+
+# Do Things the Laravel Way
+
+- 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.
+
+## Database
+
+- 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.
+
+### Model Creation
+
+- 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`.
+
+### APIs & Eloquent Resources
+
+- For APIs, default to using Eloquent API Resources and API versioning unless existing API routes do not, then you should follow existing application convention.
+
+## Controllers & Validation
+
+- 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.
+
+## Authentication & Authorization
+
+- Use Laravel's built-in authentication and authorization features (gates, policies, Sanctum, etc.).
+
+## URL Generation
+
+- When generating links to other pages, prefer named routes and the `route()` function.
+
+## Queues
+
+- Use queued jobs for time-consuming operations with the `ShouldQueue` interface.
+
+## Configuration
+
+- 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')`.
+
+## Testing
+
+- 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.
+
+## Vite Error
+
+- 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 ===
+
+# Laravel 12
+
+- CRITICAL: ALWAYS use `search-docs` tool for version-specific Laravel documentation and updated code examples.
+- Since Laravel 11, Laravel has a new streamlined file structure which this project uses.
+
+## Laravel 12 Structure
+
+- 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.
+
+## Database
+
+- 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);`.
+
+### Models
+
+- 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.
+
+=== fluxui-free/core rules ===
+
+# Flux UI Free
+
+- Flux UI is the official Livewire component library. This project uses the free edition, which includes all free components and variants but not Pro components.
+- Use `<flux:*>` components when available; they are the recommended way to build Livewire interfaces.
+- IMPORTANT: Activate `fluxui-development` when working with Flux UI components.
+
+=== livewire/core rules ===
+
+# Livewire
+
+- Livewire allows you to build dynamic, reactive interfaces using only PHP — no JavaScript required.
+- Instead of writing frontend code in JavaScript frameworks, you use Alpine.js to build the UI when client-side interactions are required.
+- State lives on the server; the UI reflects it. Validate and authorize in actions (they're like HTTP requests).
+- IMPORTANT: Activate `livewire-development` every time you're working with Livewire-related tasks.
+
+=== pint/core rules ===
+
+# Laravel Pint Code Formatter
+
+- 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 ===
+
+## Pest
+
+- This project uses Pest for testing. Create tests: `php artisan make:test --pest {name}`.
+- Run tests: `php artisan test --compact` or filter: `php artisan test --compact --filter=testName`.
+- Do NOT delete tests without approval.
+- CRITICAL: ALWAYS use `search-docs` tool for version-specific Pest documentation and updated code examples.
+- IMPORTANT: Activate `pest-testing` every time you're working with a Pest or testing-related task.
+</laravel-boost-guidelines>

.cursor/rules/memory-bank.mdc

@@ -0,0 +1,38 @@
+---
+description: Regle de gestion du Memory Bank. Definit la structure, le contenu attendu et le declenchement de la mise a jour des fichiers du dossier memory-bank/.
+globs:
+alwaysApply: true
+---
+
+# Memory Bank
+
+Le Memory Bank est un ensemble de fichiers markdown dans le dossier `memory-bank/` a la racine du projet. Il sert de source de verite pour le contexte, l'architecture, les decisions et l'avancement du projet.
+
+## Declenchement de la mise a jour
+
+Quand l'utilisateur dit **"update memory bank"**, tu DOIS :
+
+1. Relire le code source du projet (modeles, services, controllers, pages Filament, migrations, routes, config, .env, composer.json, tests).
+2. Identifier ce qui a change depuis la derniere mise a jour.
+3. Mettre a jour CHAQUE fichier du dossier `memory-bank/` en consequence, en preservant la structure decrite ci-dessous.
+4. Ne jamais supprimer d'information pertinente ; ajouter les nouvelles informations et deplacer les anciennes dans une section "Historique" si necessaire.
+
+## Structure des fichiers
+
+| Fichier | Contenu attendu |
+|---------|-----------------|
+| `projectbrief.md` | Vision du projet, objectifs principaux, perimetre fonctionnel, contraintes |
+| `productContext.md` | Pourquoi le projet existe, quels problemes il resout, comment il fonctionne du point de vue utilisateur |
+| `techContext.md` | Stack technique complete, dependances, configuration de l'API Logistics (endpoints, authentification, structure de reponse, tables) |
+| `systemPatterns.md` | Architecture applicative, patterns utilises (Service, Pages Filament, config), structure des repertoires, conventions de code |
+| `activeContext.md` | Travail en cours, decisions recentes, changements importants, prochaines etapes immediates |
+| `progress.md` | Ce qui fonctionne, ce qui reste a faire, problemes connus, metriques (nombre de tests, couverture) |
+| `README.md` | Explication du dossier memory-bank, comment l'utiliser, quand le mettre a jour |
+
+## Regles de mise a jour
+
+- Chaque fichier doit etre autonome et lisible independamment.
+- Utiliser un ton factuel et concis, sans emojis.
+- Inclure des chemins de fichiers exacts quand c'est pertinent.
+- Les dates de derniere mise a jour doivent figurer en haut de chaque fichier.
+- Le fichier `progress.md` doit toujours refleter l'etat reel du projet au moment de la mise a jour.

.cursor/skills/fluxui-development/SKILL.md

@@ -0,0 +1,72 @@
+---
+name: fluxui-development
+description: >-
+  Develops UIs with Flux UI Free components. Activates when creating buttons, forms, modals,
+  inputs, dropdowns, checkboxes, or UI components; replacing HTML form elements with Flux;
+  working with flux: components; or when the user mentions Flux, component library, UI components,
+  form fields, or asks about available Flux components.
+---
+
+# Flux UI Development
+
+## When to Apply
+
+Activate this skill when:
+
+- Creating UI components or pages
+- Working with forms, modals, or interactive elements
+- Checking available Flux components
+
+## Documentation
+
+Use `search-docs` for detailed Flux UI patterns and documentation.
+
+## Basic Usage
+
+This project uses the free edition of Flux UI, which includes all free components and variants but not Pro components.
+
+Flux UI is a component library for Livewire built with Tailwind CSS. It provides components that are easy to use and customize.
+
+Use Flux UI components when available. Fall back to standard Blade components when no Flux component exists for your needs.
+
+<code-snippet name="Basic Button" lang="blade">
+<flux:button variant="primary">Click me</flux:button>
+</code-snippet>
+
+## Available Components (Free Edition)
+
+Available: avatar, badge, brand, breadcrumbs, button, callout, checkbox, dropdown, field, heading, icon, input, modal, navbar, otp-input, profile, radio, select, separator, skeleton, switch, text, textarea, tooltip
+
+## Common Patterns
+
+### Form Fields
+
+<code-snippet name="Form Field" lang="blade">
+<flux:field>
+    <flux:label>Email</flux:label>
+    <flux:input type="email" wire:model="email" />
+    <flux:error name="email" />
+</flux:field>
+</code-snippet>
+
+### Modals
+
+<code-snippet name="Modal" lang="blade">
+<flux:modal wire:model="showModal">
+    <flux:heading>Title</flux:heading>
+    <p>Content</p>
+</flux:modal>
+</code-snippet>
+
+## Verification
+
+1. Check component renders correctly
+2. Test interactive states
+3. Verify mobile responsiveness
+
+## Common Pitfalls
+
+- Trying to use Pro-only components in the free edition
+- Not checking if a Flux component exists before creating custom implementations
+- Forgetting to use the `search-docs` tool for component-specific documentation
+- Not following existing project patterns for Flux usage

.cursor/skills/livewire-development/SKILL.md

@@ -0,0 +1,163 @@
+---
+name: livewire-development
+description: >-
+  Develops reactive Livewire 4 components. Activates when creating, updating, or modifying
+  Livewire components; working with wire:model, wire:click, wire:loading, or any wire: directives;
+  adding real-time updates, loading states, or reactivity; debugging component behavior;
+  writing Livewire tests; or when the user mentions Livewire, component, counter, or reactive UI.
+---
+
+# Livewire Development
+
+## When to Apply
+
+Activate this skill when:
+
+- Creating or modifying Livewire components
+- Using wire: directives (model, click, loading, sort, intersect)
+- Implementing islands or async actions
+- Writing Livewire component tests
+
+## Documentation
+
+Use `search-docs` for detailed Livewire 4 patterns and documentation.
+
+## Basic Usage
+
+### Creating Components
+
+<code-snippet name="Component Creation Commands" lang="bash">
+
+# Single-file component (default in v4)
+
+{{ $assist->artisanCommand('make:livewire create-post') }}
+
+# Multi-file component
+
+{{ $assist->artisanCommand('make:livewire create-post --mfc') }}
+
+# Class-based component (v3 style)
+
+{{ $assist->artisanCommand('make:livewire create-post --class') }}
+
+# With namespace
+
+{{ $assist->artisanCommand('make:livewire Posts/CreatePost') }}
+
+</code-snippet>
+
+### Converting Between Formats
+
+Use `php artisan livewire:convert create-post` to convert between single-file, multi-file, and class-based formats.
+
+### Component Format Reference
+
+| Format | Flag | Structure |
+|--------|------|-----------|
+| Single-file (SFC) | default | PHP + Blade in one file |
+| Multi-file (MFC) | `--mfc` | Separate PHP class, Blade, JS, tests |
+| Class-based | `--class` | Traditional v3 style class |
+| View-based | ⚡ prefix | Blade-only with functional state |
+
+### Single-File Component Example
+
+<code-snippet name="Single-File Component Example" lang="php">
+
+<?php
+use Livewire\Component;
+
+new class extends Component {
+    public int $count = 0;
+
+    public function increment(): void
+    {
+        $this->count++;
+    }
+}
+?>
+
+<div>
+    <button wire:click="increment">Count: @{{ $count }}</button>
+</div>
+
+</code-snippet>
+
+## Livewire 4 Specifics
+
+### Key Changes From Livewire 3
+
+These things changed in Livewire 4, but may not have been updated in this application. Verify this application's setup to ensure you follow existing conventions.
+
+- Use `Route::livewire()` for full-page components; config keys renamed: `layout` → `component_layout`, `lazy_placeholder` → `component_placeholder`.
+- `wire:model` now ignores child events by default (use `wire:model.deep` for old behavior); `wire:scroll` renamed to `wire:navigate:scroll`.
+- Component tags must be properly closed; `wire:transition` now uses View Transitions API (modifiers removed).
+- JavaScript: `$wire.$js('name', fn)` → `$wire.$js.name = fn`; `commit`/`request` hooks → `interceptMessage()`/`interceptRequest()`.
+
+### New Features
+
+- Component formats: single-file (SFC), multi-file (MFC), view-based components.
+- Islands (`@island`) for isolated updates; async actions (`wire:click.async`, `#[Async]`) for parallel execution.
+- Deferred/bundled loading: `defer`, `lazy.bundle` for optimized component loading.
+
+| Feature | Usage | Purpose |
+|---------|-------|---------|
+| Islands | `@island(name: 'stats')` | Isolated update regions |
+| Async | `wire:click.async` or `#[Async]` | Non-blocking actions |
+| Deferred | `defer` attribute | Load after page render |
+| Bundled | `lazy.bundle` | Load multiple together |
+
+### New Directives
+
+- `wire:sort`, `wire:intersect`, `wire:ref`, `.renderless`, `.preserve-scroll` are available for use.
+- `data-loading` attribute automatically added to elements triggering network requests.
+
+| Directive | Purpose |
+|-----------|---------|
+| `wire:sort` | Drag-and-drop sorting |
+| `wire:intersect` | Viewport intersection detection |
+| `wire:ref` | Element references for JS |
+| `.renderless` | Component without rendering |
+| `.preserve-scroll` | Preserve scroll position |
+
+## Best Practices
+
+- Always use `wire:key` in loops
+- Use `wire:loading` for loading states
+- Use `wire:model.live` for instant updates (default is debounced)
+- Validate and authorize in actions (treat like HTTP requests)
+
+## Configuration
+
+- `smart_wire_keys` defaults to `true`; new configs: `component_locations`, `component_namespaces`, `make_command`, `csp_safe`.
+
+## Alpine & JavaScript
+
+- `wire:transition` uses browser View Transitions API; `$errors` and `$intercept` magic properties available.
+- Non-blocking `wire:poll` and parallel `wire:model.live` updates improve performance.
+
+For interceptors and hooks, see [reference/javascript-hooks.md](reference/javascript-hooks.md).
+
+## Testing
+
+<code-snippet name="Testing Example" lang="php">
+
+Livewire::test(Counter::class)
+    ->assertSet('count', 0)
+    ->call('increment')
+    ->assertSet('count', 1);
+
+</code-snippet>
+
+## Verification
+
+1. Browser console: Check for JS errors
+2. Network tab: Verify Livewire requests return 200
+3. Ensure `wire:key` on all `@foreach` loops
+
+## Common Pitfalls
+
+- Missing `wire:key` in loops → unexpected re-rendering
+- Expecting `wire:model` real-time → use `wire:model.live`
+- Unclosed component tags → syntax errors in v4
+- Using deprecated config keys or JS hooks
+- Including Alpine.js separately (already bundled in Livewire 4)

.cursor/skills/livewire-development/reference/javascript-hooks.md

@@ -0,0 +1,39 @@
+# Livewire 4 JavaScript Integration
+
+## Interceptor System (v4)
+
+### Intercept Messages
+
+```js
+Livewire.interceptMessage(({ component, message, onFinish, onSuccess, onError }) => {
+    onFinish(() => { /* After response, before processing */ });
+    onSuccess(({ payload }) => { /* payload.snapshot, payload.effects */ });
+    onError(() => { /* Server errors */ });
+});
+```
+
+### Intercept Requests
+
+```js
+Livewire.interceptRequest(({ request, onResponse, onSuccess, onError, onFailure }) => {
+    onResponse(({ response }) => { /* When received */ });
+    onSuccess(({ response, responseJson }) => { /* Success */ });
+    onError(({ response, responseBody, preventDefault }) => { /* 4xx/5xx */ });
+    onFailure(({ error }) => { /* Network failures */ });
+});
+```
+
+### Component-Scoped Interceptors
+
+```blade
+<script>
+    this.$intercept('save', ({ component, onSuccess }) => {
+        onSuccess(() => console.log('Saved!'));
+    });
+</script>
+```
+
+## Magic Properties
+
+- `$errors` - Access validation errors from JavaScript
+- `$intercept` - Component-scoped interceptors

.cursor/skills/pest-testing/SKILL.md

@@ -0,0 +1,174 @@
+---
+name: pest-testing
+description: >-
+  Tests applications using the Pest 4 PHP framework. Activates when writing tests, creating unit or feature
+  tests, adding assertions, testing Livewire components, browser testing, debugging test failures,
+  working with datasets or mocking; or when the user mentions test, spec, TDD, expects, assertion,
+  coverage, or needs to verify functionality works.
+---
+
+# Pest Testing 4
+
+## When to Apply
+
+Activate this skill when:
+
+- Creating new tests (unit, feature, or browser)
+- Modifying existing tests
+- Debugging test failures
+- Working with browser testing or smoke testing
+- Writing architecture tests or visual regression tests
+
+## Documentation
+
+Use `search-docs` for detailed Pest 4 patterns and documentation.
+
+## Basic Usage
+
+### Creating Tests
+
+All tests must be written using Pest. Use `php artisan make:test --pest {name}`.
+
+### Test Organization
+
+- Unit/Feature tests: `tests/Feature` and `tests/Unit` directories.
+- Browser tests: `tests/Browser/` directory.
+- Do NOT remove tests without approval - these are core application code.
+
+### Basic Test Structure
+
+<code-snippet name="Basic Pest Test Example" lang="php">
+
+it('is true', function () {
+    expect(true)->toBeTrue();
+});
+
+</code-snippet>
+
+### Running Tests
+
+- Run minimal tests with filter before finalizing: `php artisan test --compact --filter=testName`.
+- Run all tests: `php artisan test --compact`.
+- Run file: `php artisan test --compact tests/Feature/ExampleTest.php`.
+
+## Assertions
+
+Use specific assertions (`assertSuccessful()`, `assertNotFound()`) instead of `assertStatus()`:
+
+<code-snippet name="Pest Response Assertion" lang="php">
+
+it('returns all', function () {
+    $this->postJson('/api/docs', [])->assertSuccessful();
+});
+
+</code-snippet>
+
+| Use | Instead of |
+|-----|------------|
+| `assertSuccessful()` | `assertStatus(200)` |
+| `assertNotFound()` | `assertStatus(404)` |
+| `assertForbidden()` | `assertStatus(403)` |
+
+## Mocking
+
+Import mock function before use: `use function Pest\Laravel\mock;`
+
+## Datasets
+
+Use datasets for repetitive tests (validation rules, etc.):
+
+<code-snippet name="Pest Dataset Example" lang="php">
+
+it('has emails', function (string $email) {
+    expect($email)->not->toBeEmpty();
+})->with([
+    'james' => 'james@laravel.com',
+    'taylor' => 'taylor@laravel.com',
+]);
+
+</code-snippet>
+
+## Pest 4 Features
+
+| Feature | Purpose |
+|---------|---------|
+| Browser Testing | Full integration tests in real browsers |
+| Smoke Testing | Validate multiple pages quickly |
+| Visual Regression | Compare screenshots for visual changes |
+| Test Sharding | Parallel CI runs |
+| Architecture Testing | Enforce code conventions |
+
+### Browser Test Example
+
+Browser tests run in real browsers for full integration testing:
+
+- Browser tests live in `tests/Browser/`.
+- Use Laravel features like `Event::fake()`, `assertAuthenticated()`, and model factories.
+- Use `RefreshDatabase` for clean state per test.
+- Interact with page: click, type, scroll, select, submit, drag-and-drop, touch gestures.
+- Test on multiple browsers (Chrome, Firefox, Safari) if requested.
+- Test on different devices/viewports (iPhone 14 Pro, tablets) if requested.
+- Switch color schemes (light/dark mode) when appropriate.
+- Take screenshots or pause tests for debugging.
+
+<code-snippet name="Pest Browser Test Example" lang="php">
+
+it('may reset the password', function () {
+    Notification::fake();
+
+    $this->actingAs(User::factory()->create());
+
+    $page = visit('/sign-in');
+
+    $page->assertSee('Sign In')
+        ->assertNoJavascriptErrors()
+        ->click('Forgot Password?')
+        ->fill('email', 'nuno@laravel.com')
+        ->click('Send Reset Link')
+        ->assertSee('We have emailed your password reset link!');
+
+    Notification::assertSent(ResetPassword::class);
+});
+
+</code-snippet>
+
+### Smoke Testing
+
+Quickly validate multiple pages have no JavaScript errors:
+
+<code-snippet name="Pest Smoke Testing Example" lang="php">
+
+$pages = visit(['/', '/about', '/contact']);
+
+$pages->assertNoJavascriptErrors()->assertNoConsoleLogs();
+
+</code-snippet>
+
+### Visual Regression Testing
+
+Capture and compare screenshots to detect visual changes.
+
+### Test Sharding
+
+Split tests across parallel processes for faster CI runs.
+
+### Architecture Testing
+
+Pest 4 includes architecture testing (from Pest 3):
+
+<code-snippet name="Architecture Test Example" lang="php">
+
+arch('controllers')
+    ->expect('App\Http\Controllers')
+    ->toExtendNothing()
+    ->toHaveSuffix('Controller');
+
+</code-snippet>
+
+## Common Pitfalls
+
+- Not importing `use function Pest\Laravel\mock;` before using mock
+- Using `assertStatus(200)` instead of `assertSuccessful()`
+- Forgetting datasets for repetitive validation tests
+- Deleting tests without approval
+- Forgetting `assertNoJavascriptErrors()` in browser tests