output:
Chunk ID: 7d1c92
Wall time: 0.0000 seconds
Process exited with code 0
Original token count: 2537
Output:
diff --git a/specs/progress.md b/specs/progress.md
index 8d03d3dd..93d1473d 100644
--- a/specs/progress.md
+++ b/specs/progress.md
@@ -7,7 +7,7 @@ ## Objective
 ## Current Status

 - Status: in progress
-- Active slice: Phase 4 - Storefront cart/checkout API surface and remaining cart estimates, after UI connection
+- Active slice: Phase 4 - remaining cart estimates, then Phase 5 orders/payments
 - Started from: Laravel Livewire/Fortify starter kit with no shop domain tables or models present
 - Last updated: 2026-05-03

@@ -27,14 +27,14 @@ ## Acceptance Checklist
 | Area | Criteria Source | Status | Evidence |
 | --- | --- | --- | --- |
 | Database schema | `specs/01-DATABASE-SCHEMA.md` | partial | Phase 1 tenancy/auth tables, Phase 2 catalog tables, Phase 3 theme/content/navigation tables, and Phase 4 cart/checkout/pricing tables are implemented: carts, cart_lines, checkouts, shipping_zones, shipping_rates, tax_settings, discounts. Order/payment/search/analytics/app tables are still missing. |
-| Routes/API | `specs/02-API-ROUTES.md` | partial | Phase 1 auth routes plus catalog/cart UI routes exist: `/`, `/collections`, `/collections/{handle}`, `/products/{handle}`, `/cart`, `/checkout`, `/search`, `/pages/{handle}`, `/admin/products`, `/admin/products/create`, `/admin/products/{product}/edit`, `/admin/collections`, `/admin/collections/create`, `/admin/collections/{collection}/edit`, `/admin/inventory`. Storefront/admin API routes are still missing. |
+| Routes/API | `specs/02-API-ROUTES.md` | partial | Phase 1 auth routes plus catalog/cart UI routes exist: `/`, `/collections`, `/collections/{handle}`, `/products/{handle}`, `/cart`, `/checkout`, `/search`, `/pages/{handle}`, `/admin/products`, `/admin/products/create`, `/admin/products/{product}/edit`, `/admin/collections`, `/admin/collections/create`, `/admin/collections/{collection}/edit`, `/admin/inventory`. Storefront REST API now includes cart line CRUD and checkout address/shipping/discount/payment-method selection under `/api/storefront/v1`. Storefront search/suggest, analytics, order lookup/payment processing, and admin REST APIs are still missing. |
 | Admin UI | `specs/03-ADMIN-UI.md` | partial | Flux/Livewire admin catalog shell now includes product index/form, collection index/form, and inventory list with auth protection, filtering, pagination, status changes, SKU uniqueness checks, and collection assignment. Order/customer/content/settings admin pages are still missing. |
 | Storefront UI | `specs/04-STOREFRONT-UI.md` | partial | Storefront layout, home, collections index/detail, product detail, search, breadcrumbs, price display, product cards, DB-backed pages, seeded navigation menus, cached theme settings, product add-to-cart persistence, cart drawer, cart page, and checkout address/shipping/discount/payment-selection UI render seeded data. Cart page shipping estimate and discount entry are still pending. |
 | Business logic | `specs/05-BUSINESS-LOGIC.md` | partial | `ResolveStore`, `BelongsToStore`, `StoreScope`, role checks, customer guard provider, catalog product lifecycle transitions, SKU uniqueness, variant matrix rebuilding, inventory reserve/release/commit/restock, automatic variant inventory, variant option mapping, media resize/cleanup job, `CartService`, `DiscountService`, `ShippingCalculator`, `TaxCalculator`, `PricingEngine`, checkout transitions through payment selection, checkout expiration, abandoned cart cleanup, session cart lookup, customer login cart merge, and product add-to-cart mutations are implemented. Order/payment services are still missing. |
 | Auth/security | `specs/06-AUTH-AND-SECURITY.md` | partial | Admin Livewire login/logout, customer guard/provider, customer login/register, login rate limiting, session hardening, and resource policies implemented. Customer password reset and Sanctum token auth still missing. |
 | Seed/test data | `specs/07-SEEDERS-AND-TEST-DATA.md` | partial | Seeders create Acme Fashion and Acme Electronics stores/domains/settings/admin access, 6 collections, 25 products, 127 variants, 127 inventory rows, 206 variant option pivots, 2 themes, 6 theme files, 2 theme settings rows, 6 pages, 4 navigation menus, 17 navigation items, 2 tax settings rows, 2 shipping zones, 6 shipping rates, 6 discounts, and no product media/runtime carts. Order/payment seed data is still missing. |
 | Browser E2E plan | `specs/08-PLAYWRIGHT-E2E-PLAN.md` | partial | Manual Playwright MCP smoke coverage has verified storefront catalog browsing, product detail, add-to-cart, cart drawer/page, checkout through payment selection, search, DB-backed content pages, seeded navigation, admin product/collection/inventory pages, and auth flows without console warnings/errors on successful pages. Automated browser tests are still missing. |
-| Roadmap phases | `specs/09-IMPLEMENTATION-ROADMAP.md` | in progress | Phase 1 foundation, Phase 2 catalog data/UI, Phase 3 theme/content/navigation data with storefront consumption, Phase 4 cart/checkout/pricing backend foundation, and Phase 4 storefront cart/checkout UI through `payment_selected` are implemented. Phase 4 API/remaining cart estimates and Phase 5 orders/payments are next. |
+| Roadmap phases | `specs/09-IMPLEMENTATION-ROADMAP.md` | in progress | Phase 1 foundation, Phase 2 catalog data/UI, Phase 3 theme/content/navigation data with storefront consumption, Phase 4 cart/checkout/pricing backend foundation, Phase 4 storefront cart/checkout UI through `payment_selected`, and the Phase 4 cart/checkout REST API surface are implemented. Remaining cart estimates and Phase 5 orders/payments are next. |

 ## Verification Evidence

@@ -90,6 +90,12 @@ ## Verification Evidence
 - 2026-05-03: `php artisan migrate:fresh --seed --no-interaction` passed after the Phase 4 UI changes.
 - 2026-05-03: `npm run build` passed after the cart/checkout Blade changes.
 - 2026-05-03: Playwright MCP verified `http://shop.test/products/classic-cotton-t-shirt` add-to-cart, `http://shop.test/cart`, and `http://shop.test/checkout` render and progress through shipping, discount, and reserve-items payment selection with Livewire update requests returning 200 and no new console warnings/errors. Missing favicon links were fixed with `public/favicon.svg`.
+- 2026-05-03: `mcp__laravel_boost__.search_docs` consulted Laravel 12 JSON API tests/resources/form requests/route model binding docs and Pest 4 JSON expectation docs before the Phase 4 API changes.
+- 2026-05-03: `php artisan route:list --path=api/storefront/v1` confirmed 12 storefront API routes for carts, cart lines, checkouts, checkout address, shipping method, discount apply/remove, and payment method selection.
+- 2026-05-03: `php artisan test --compact tests/Feature/Api/StorefrontCartApiTest.php tests/Feature/Api/StorefrontCheckoutApiTest.php` passed: 6 tests, 73 assertions.
+- 2026-05-03: `php artisan test --compact tests/Feature/Api tests/Feature/Cart tests/Feature/Checkout tests/Feature/Storefront` passed: 27 tests, 178 assertions.
+- 2026-05-03: `php artisan test --compact` passed after the cart/checkout API changes: 95 tests, 414 assertions.
+- 2026-05-03: `php artisan migrate:fresh --seed --no-interaction` passed after the cart/checkout API changes.

 ## Decisions

@@ -108,6 +114,7 @@ ## Decisions
 - Checkout completion intentionally stops before order creation in this slice. `CheckoutService::completeCheckout()` is a Phase 5 boundary until order, payment, and fulfillment tables/services exist.
 - The cart drawer reads the current session/customer cart without creating an empty cart on every storefront render; carts are created on first add-to-cart or checkout/cart service mutation.
 - The checkout UI currently reserves inventory by selecting a payment method and leaves payment capture/order creation for Phase 5.
+- The cart REST API exposes `cart_version` as the public optimistic concurrency field while the service layer keeps its `expectedVersion` argument; `expected_version` remains accepted as a compatibility alias in API requests.

 ## Open Issues

@@ -120,7 +127,7 @@ ## Open Issues
 - Product options can be displayed and edited as text in the admin form, but full option matrix generation and option-value reassignment UI are not complete.
 - Theme/page/navigation admin management UI is still missing even though the Phase 3 data layer, seeders, services, and storefront consumption exist.
 - Storefront cart page shipping estimate and cart-level discount entry are still missing; discounts can be applied during checkout.
-- Storefront cart and checkout API endpoints are still missing.
+- Storefront search/suggest, analytics event, order lookup, checkout payment processing, and admin REST API endpoints are still missing.
 - Checkout order creation, payment capture, discount usage-count increment on successful order completion, and fulfillment are still pending Phase 5.
 - Automated browser tests from Spec 08 are still missing; current browser coverage is manual Playwright MCP smoke verification.
 - SQLite enum/check constraints from the schema spec are not yet explicitly enforced as database `CHECK` constraints; enum validation is currently enforced through casts/services/model invariants.
@@ -128,4 +135,4 @@ ## Open Issues

 ## Completion Summary

-Not complete. Phase 1 foundation, Phase 2 catalog data/UI surfaces, Phase 3 storefront theme/content/navigation data, the Phase 4 cart/checkout/pricing backend foundation, and cart/checkout storefront UI through payment selection are implemented, with known auth/token, media UI, theme admin UI, cart/checkout API, cart estimates, order/payment, browser-test, and database CHECK constraint gaps tracked above.
+Not complete. Phase 1 foundation, Phase 2 catalog data/UI surfaces, Phase 3 storefront theme/content/navigation data, the Phase 4 cart/checkout/pricing backend foundation, cart/checkout storefront UI through payment selection, and cart/checkout REST APIs are implemented, with known auth/token, media UI, theme admin UI, cart estimates, order/payment, remaining API, browser-test, and database CHECK constraint gaps tracked above.


output:
Chunk ID: db50d7
Wall time: 0.0000 seconds
Process exited with code 0
Original token count: 0
Output:


message: Full Pest and fresh migrate/seed passed. I’ve also removed the two new untracked Playwright console logs, so the remaining worktree changes are the API slice and progress update only.

phase: commentary


type: message

role: assistant

text: Full Pest and fresh migrate/seed passed. I’ve also removed the two new untracked Playwright console logs, so the remaining worktree changes are the API slice and progress update only.


cmd: git add app/Providers/AppServiceProvider.php bootstrap/app.php app/Http/Controllers/Api app/Http/Requests/Api app/Http/Resources/Storefront routes/api.php tests/Feature/Api specs/progress.md && git diff --cached --check && git diff --cached --stat


command: git add app/Providers/AppServiceProvider.php bootstrap/app.php app/Http/Controllers/Api app/Http/Requests/Api app/Http/Resources/Storefront routes/api.php tests/Feature/Api specs/progress.md && git diff --cached --check && git diff --cached --stat

type: unknown

aggregated_output:
 .../Api/Storefront/V1/CartController.php           |  45 +++++
 .../Api/Storefront/V1/CartLineController.php       |  92 ++++++++++
 .../Api/Storefront/V1/CheckoutController.php       | 148 ++++++++++++++++
 .../Storefront/V1/ApplyCheckoutDiscountRequest.php |  28 +++
 .../Api/Storefront/V1/DestroyCartLineRequest.php   |  34 ++++
 .../Storefront/V1/SelectCheckoutPaymentRequest.php |  28 +++
 .../Storefront/V1/SetCheckoutAddressRequest.php    |  39 +++++
 .../Storefront/V1/SetCheckoutShippingRequest.php   |  28 +++
 .../Api/Storefront/V1/StoreCartLineRequest.php     |  38 ++++
 .../Api/Storefront/V1/StoreCartRequest.php         |  37 ++++
 .../Api/Storefront/V1/StoreCheckoutRequest.php     |  29 +++
 .../Api/Storefront/V1/UpdateCartLineRequest.php    |  35 ++++
 .../Resources/Storefront/V1/CartLineResource.php   |  43 +++++
 app/Http/Resources/Storefront/V1/CartResource.php  |  38 ++++
 .../Resources/Storefront/V1/CheckoutResource.php   |  38 ++++
 .../Storefront/V1/ShippingRateResource.php         |  26 +++
 app/Providers/AppServiceProvider.php               |   4 +-
 bootstrap/app.php                                  |   1 +
 routes/api.php                                     |  29 +++
 specs/progress.md                                  |  17 +-
 tests/Feature/Api/StorefrontCartApiTest.php        | 156 +++++++++++++++++
 tests/Feature/Api/StorefrontCheckoutApiTest.php    | 194 +++++++++++++++++++++
 22 files changed, 1121 insertions(+), 6 deletions(-)

status: completed


output:
Chunk ID: 101a30
Wall time: 0.0000 seconds
Process exited with code 0
Original token count: 370
Output:
 .../Api/Storefront/V1/CartController.php           |  45 +++++
 .../Api/Storefront/V1/CartLineController.php       |  92 ++++++++++
 .../Api/Storefront/V1/CheckoutController.php       | 148 ++++++++++++++++
 .../Storefront/V1/ApplyCheckoutDiscountRequest.php |  28 +++
 .../Api/Storefront/V1/DestroyCartLineRequest.php   |  34 ++++
 .../Storefront/V1/SelectCheckoutPaymentRequest.php |  28 +++
 .../Storefront/V1/SetCheckoutAddressRequest.php    |  39 +++++
 .../Storefront/V1/SetCheckoutShippingRequest.php   |  28 +++
 .../Api/Storefront/V1/StoreCartLineRequest.php     |  38 ++++
 .../Api/Storefront/V1/StoreCartRequest.php         |  37 ++++
 .../Api/Storefront/V1/StoreCheckoutRequest.php     |  29 +++
 .../Api/Storefront/V1/UpdateCartLineRequest.php    |  35 ++++
 .../Resources/Storefront/V1/CartLineResource.php   |  43 +++++
 app/Http/Resources/Storefront/V1/CartResource.php  |  38 ++++
 .../Resources/Storefront/V1/CheckoutResource.php   |  38 ++++
 .../Storefront/V1/ShippingRateResource.php         |  26 +++
 app/Providers/AppServiceProvider.php               |   4 +-
 bootstrap/app.php                                  |   1 +
 routes/api.php                                     |  29 +++
 specs/progress.md                                  |  17 +-
 tests/Feature/Api/StorefrontCartApiTest.php        | 156 +++++++++++++++++
 tests/Feature/Api/StorefrontCheckoutApiTest.php    | 194 +++++++++++++++++++++
 22 files changed, 1121 insertions(+), 6 deletions(-)


cmd: git status --short && git commit -m "Add storefront cart checkout API"


command: git status --short && git commit -m "Add storefront cart checkout API"

aggregated_output:
A  app/Http/Controllers/Api/Storefront/V1/CartController.php
A  app/Http/Controllers/Api/Storefront/V1/CartLineController.php
A  app/Http/Controllers/Api/Storefront/V1/CheckoutController.php
A  app/Http/Requests/Api/Storefront/V1/ApplyCheckoutDiscountRequest.php
A  app/Http/Requests/Api/Storefront/V1/DestroyCartLineRequest.php
A  app/Http/Requests/Api/Storefront/V1/SelectCheckoutPaymentRequest.php
A  app/Http/Requests/Api/Storefront/V1/SetCheckoutAddressRequest.php
A  app/Http/Requests/Api/Storefront/V1/SetCheckoutShippingRequest.php
A  app/Http/Requests/Api/Storefront/V1/StoreCartLineRequest.php
A  app/Http/Requests/Api/Storefront/V1/StoreCartRequest.php
A  app/Http/Requests/Api/Storefront/V1/StoreCheckoutRequest.php
A  app/Http/Requests/Api/Storefront/V1/UpdateCartLineRequest.php
A  app/Http/Resources/Storefront/V1/CartLineResource.php
A  app/Http/Resources/Storefront/V1/CartResource.php
A  app/Http/Resources/Storefront/V1/CheckoutResource.php
A  app/Http/Resources/Storefront/V1/ShippingRateResource.php
M  app/Providers/AppServiceProvider.php
M  bootstrap/app.php
A  routes/api.php
M  specs/progress.md
A  tests/Feature/Api/StorefrontCartApiTest.php
A  tests/Feature/Api/StorefrontCheckoutApiTest.php
[2026-05-04-codex-5-5-goal 51c9077b] Add storefront cart checkout API
 22 files changed, 1121 insertions(+), 6 deletions(-)
 create mode 100644 app/Http/Controllers/Api/Storefront/V1/CartController.php
 create mode 100644 app/Http/Controllers/Api/Storefront/V1/CartLineController.php
 create mode 100644 app/Http/Controllers/Api/Storefront/V1/CheckoutController.php
 create mode 100644 app/Http/Requests/Api/Storefront/V1/ApplyCheckoutDiscountRequest.php
 create mode 100644 app/Http/Requests/Api/Storefront/V1/DestroyCartLineRequest.php
 create mode 100644 app/Http/Requests/Api/Storefront/V1/SelectCheckoutPaymentRequest.php
 create mode 100644 app/Http/Requests/Api/Storefront/V1/SetCheckoutAddressRequest.php
 create mode 100644 app/Http/Requests/Api/Storefront/V1/SetCheckoutShippingRequest.php
 create mode 100644 app/Http/Requests/Api/Storefront/V1/StoreCartLineRequest.php
 create mode 100644 app/Http/Requests/Api/Storefront/V1/StoreCartRequest.php
 create mode 100644 app/Http/Requests/Api/Storefront/V1/StoreCheckoutRequest.php
 create mode 100644 app/Http/Requests/Api/Storefront/V1/UpdateCartLineRequest.php
 create mode 100644 app/Http/Resources/Storefront/V1/CartLineResource.php
 create mode 100644 app/Http/Resources/Storefront/V1/CartResource.php
 create mode 100644 app/Http/Resources/Storefront/V1/CheckoutResource.php
 create mode 100644 app/Http/Resources/Storefront/V1/ShippingRateResource.php
 create mode 100644 routes/api.php
 create mode 100644 tests/Feature/Api/StorefrontCartApiTest.php
 create mode 100644 tests/Feature/Api/StorefrontCheckoutApiTest.php


output:
Chunk ID: 42dc2d
Wall time: 0.0000 seconds
Process exited with code 0
Original token count: 701
Output:
A  app/Http/Controllers/Api/Storefront/V1/CartController.php
A  app/Http/Controllers/Api/Storefront/V1/CartLineController.php
A  app/Http/Controllers/Api/Storefront/V1/CheckoutController.php
A  app/Http/Requests/Api/Storefront/V1/ApplyCheckoutDiscountRequest.php
A  app/Http/Requests/Api/Storefront/V1/DestroyCartLineRequest.php
A  app/Http/Requests/Api/Storefront/V1/SelectCheckoutPaymentRequest.php
A  app/Http/Requests/Api/Storefront/V1/SetCheckoutAddressRequest.php
A  app/Http/Requests/Api/Storefront/V1/SetCheckoutShippingRequest.php
A  app/Http/Requests/Api/Storefront/V1/StoreCartLineRequest.php
A  app/Http/Requests/Api/Storefront/V1/StoreCartRequest.php
A  app/Http/Requests/Api/Storefront/V1/StoreCheckoutRequest.php
A  app/Http/Requests/Api/Storefront/V1/UpdateCartLineRequest.php
A  app/Http/Resources/Storefront/V1/CartLineResource.php
A  app/Http/Resources/Storefront/V1/CartResource.php
A  app/Http/Resources/Storefront/V1/CheckoutResource.php
A  app/Http/Resources/Storefront/V1/ShippingRateResource.php
M  app/Providers/AppServiceProvider.php
M  bootstrap/app.php
A  routes/api.php
M  specs/progress.md
A  tests/Feature/Api/StorefrontCartApiTest.php
A  tests/Feature/Api/StorefrontCheckoutApiTest.php
[2026-05-04-codex-5-5-goal 51c9077b] Add storefront cart checkout API
 22 files changed, 1121 insertions(+), 6 deletions(-)
 create mode 100644 app/Http/Controllers/Api/Storefront/V1/CartController.php
 create mode 100644 app/Http/Controllers/Api/Storefront/V1/CartLineController.php
 create mode 100644 app/Http/Controllers/Api/Storefront/V1/CheckoutController.php
 create mode 100644 app/Http/Requests/Api/Storefront/V1/ApplyCheckoutDiscountRequest.php
 create mode 100644 app/Http/Requests/Api/Storefront/V1/DestroyCartLineRequest.php
 create mode 100644 app/Http/Requests/Api/Storefront/V1/SelectCheckoutPaymentRequest.php
 create mode 100644 app/Http/Requests/Api/Storefront/V1/SetCheckoutAddressRequest.php
 create mode 100644 app/Http/Requests/Api/Storefront/V1/SetCheckoutShippingRequest.php
 create mode 100644 app/Http/Requests/Api/Storefront/V1/StoreCartLineRequest.php
 create mode 100644 app/Http/Requests/Api/Storefront/V1/StoreCartRequest.php
 create mode 100644 app/Http/Requests/Api/Storefront/V1/StoreCheckoutRequest.php
 create mode 100644 app/Http/Requests/Api/Storefront/V1/UpdateCartLineRequest.php
 create mode 100644 app/Http/Resources/Storefront/V1/CartLineResource.php
 create mode 100644 app/Http/Resources/Storefront/V1/CartResource.php
 create mode 100644 app/Http/Resources/Storefront/V1/CheckoutResource.php
 create mode 100644 app/Http/Resources/Storefront/V1/ShippingRateResource.php
 create mode 100644 routes/api.php
 create mode 100644 tests/Feature/Api/StorefrontCartApiTest.php
 create mode 100644 tests/Feature/Api/StorefrontCheckoutApiTest.php


message: Committed the API slice as `51c9077b Add storefront cart checkout API`. I’m moving to the remaining Phase 4 cart-page items now: shipping estimate and cart-level discount entry.


text: Committed the API slice as `51c9077b Add storefront cart checkout API`. I’m moving to the remaining Phase 4 cart-page items now: shipping estimate and cart-level discount entry.


packages: livewire/livewire livewire/flux laravel/framework pestphp/pest

queries: livewire forms validation computed properties

queries: livewire query string session component tests


cmd: sed -n '1,220p' /Users/fabianwesner/Herd/shop/.agents/skills/livewire-development/SKILL.md


cmd: sed -n '1,220p' /Users/fabianwesner/Herd/shop/.agents/skills/fluxui-development/SKILL.md


cmd: sed -n '1,220p' /Users/fabianwesner/Herd/shop/.agents/skills/tailwindcss-development/SKILL.md


server: laravel-boost

tool: search-docs

type: text

text:
# Search Results

## Components Select > The button slot
Components Select | livewire/flux@2.x | Source: https://fluxui.dev/components/select#livewire/flux

            The button slot

If you need full control over the button used to trigger the custom select, you can use the button slot to render it yourself.

<flux:select variant="listbox">    <x-slot name="button">        <flux:select.button class="rounded-full!" placeholder="Choose industry..." :invalid="$errors->has('...')" />    </x-slot>    <flux:select.option>Photography</flux:select.option>    ...</flux:select>

---

## Properties See also
Properties | livewire/livewire@4.x | Source: https://livewire.laravel.com/docs/4.x/properties

## See also

- **[Forms](/docs/4.x/forms)** — Bind properties to form inputs with wire:model
- **[Computed Properties](/docs/4.x/computed-properties)** — Create derived values with automatic memoization
- **[Validation](/docs/4.x/validation)** — Validate property values before persisting
- **[Locked Attribute](/docs/4.x/attribute-locked)** — Prevent properties from being manipulated client-side
- **[Alpine](/docs/4.x/alpine)** — Access and manipulate properties from JavaScript

---

## Validation Validation Quickstart Displaying the Validation Errors XHR Requests and Validation
Validation | laravel/framework@12.x | Source: https://github.com/laravel/docs/blob/12.x/validation.md

#### XHR Requests and Validation

In this example, we used a traditional form to send data to the application. However, many applications receive XHR requests from a JavaScript powered frontend. When using the `validate` method during an XHR request, Laravel will not generate a redirect response. Instead, Laravel generates a [JSON response containing all of the validation errors](#validation-error-response-format). This JSON response will be sent with a 422 HTTP status code.

---

## Search Full-Text Search Running Full-Text Queries
Search | laravel/framework@12.x | Source: https://github.com/laravel/docs/blob/12.x/search.md

### Running Full-Text Queries

Once the index is in place, use the `whereFullText` query builder method to search against it. Laravel will generate the appropriate SQL for your database driver — for example, `MATCH(...) AGAINST(...)` on MariaDB and MySQL, and `to_tsvector(...) @@ plainto_tsquery(...)` on PostgreSQL:

```php
$articles = Article::whereFullText('body', 'web developer')->get();
```

When using MariaDB and MySQL, results are automatically ordered by relevance score. On PostgreSQL, `whereFullText` filters matching records but does not order them by relevance — if you need automatic relevance ordering on PostgreSQL, consider using [Scout's database engine](#database-engine), which handles this for you.

If you created a composite full-text index across multiple columns, you may search against all of them by passing the same array of columns to `whereFullText`:

```php
$articles = Article::whereFullText(
    ['title', 'body'], 'web developer'
)->get();
```

The `orWhereFullText` method may be used to add a full-text search clause as an "or" condition. For complete details, consult the [query builder documentation](/docs/{{version}}/queries#full-text-where-clauses).

---

## Attribute Computed Learn more
Attribute Computed | livewire/livewire@4.x | Source: https://livewire.laravel.com/docs/4.x/attribute-computed

## Learn more

For detailed information about computed properties, caching strategies, and advanced use cases, see the [Computed Properties documentation](/docs/4.x/computed-properties).

---

## Validation Available Validation Rules json
Validation | laravel/framework@12.x | Source: https://github.com/laravel/docs/blob/12.x/validation.md

#### json

The field under validation must be a valid JSON string.

---

## Properties Security concerns
Properties | livewire/livewire@4.x | Source: https://livewire.laravel.com/docs/4.x/properties

## Security concerns

While Livewire properties are a powerful feature, there are a few security considerations that you should be aware of before using them.

In short, always treat public properties as user input — as if they were request input from a traditional endpoint. In light of this, it's essential to validate and authorize properties before persisting them to a database — just like you would do when working with request input in a controller.

### Don't trust property values

To demonstrate how neglecting to authorize and validate properties can introduce security holes in your application, the following `post.edit` component is vulnerable to attack:

```php
<?php // resources/views/components/post/⚡edit.blade.php

use Livewire\Component;
use App\Models\Post;

new class extends Component {
    public $id;
    public $title;
    public $content;

    public function mount(Post $post)
    {
        $this->id = $post->id;
        $this->title = $post->title;
        $this->content = $post->content;
    }

    public function update()
    {
        $post = Post::findOrFail($this->id);

        $post->update([
            'title' => $this->title,
            'content' => $this->content,
        ]);

        session()->flash('message', 'Post updated successfully!');
    }
};
```

```blade
<form wire:submit="update">
    <input type="text" wire:model="title">
    <input type="text" wire:model="content">

    <button type="submit">Update</button>
</form>
```

At first glance, this component may look completely fine. But, let's walk through how an attacker could use the component to do unauthorized things in your application.

Because we are storing the `id` of the post as a public property on the component, it can be manipulated on the client just the same as the `title` and `content` properties.

It doesn't matter that we didn't write an input with `wire:model="id"`. A malicious user can easily change the view to the following using their browser DevTools:

```blade
<form wire:submit="update">
    <input type="text" wire:model="id"> <!-- [tl! highlight] -->
    <input type="text" wire:model="title">
    <input type="text" wire:model="content">

    <button type="submit">Update</button>
</form>
```

Now the malicious user can update the `id` input to the ID of a different post model. When the form is submitted and `update()` is called, `Post::findOrFail()` will return and update a post the user is not the owner of.

To prevent this kind of attack, we can use one or both of the following strategies:

* Authorize the input
* Lock the property from updates

#### Authorizing the input

Because `$id` can be manipulated client-side with something like `wire:model`, just like in a controller, we can use [Laravel's authorization](https://laravel.com/docs/authorization) to make sure the current user can update the post:

```php
public function update()
{
    $post = Post::findOrFail($this->id);

    $this->authorize('update', $post); // [tl! highlight]

    $post->update(...);
}
```

If a malicious user mutates the `$id` property, the added authorization will catch it and throw an error.

#### Locking the property

Livewire also allows you to "lock" properties in order to prevent properties from being modified on the client-side. You can "lock" a property from client-side manipulation using the `#[Locked]` attribute:

```php
use Livewire\Attributes\Locked;
use Livewire\Component;

new class extends Component {
    #[Locked] // [tl! highlight]
    public $id;

    // ...
};
```

Now, if a user tries to modify `$id` on the front end, an error will be thrown.

By using `#[Locked]`, you can assume this property has not been manipulated anywhere outside your component's class.

For more information on locking properties, [consult the Locked attribute documentation](/docs/4.x/attribute-locked).

#### Eloquent models and locking

When an Eloquent model is assigned to a Livewire component property, Livewire will automatically lock the property and ensure the ID isn't changed, so that you are safe from these kinds of attacks:

```php
<?php // resources/views/components/post/⚡edit.blade.php

use Livewire\Component;
use App\Models\Post;

new class extends Component {
    public Post $post; // [tl! highlight]
    public $title;
    public $content;

    public function mount(Post $post)
    {
        $this->post = $post;
        $this->title = $post->title;
        $this->content = $post->content;
    }

    public function update()
    {
        $this->post->update([
            'title' => $this->title,
            'content' => $this->content,
        ]);

        session()->flash('message', 'Post updated successfully!');
    }
};
```

### Properties expose system information to the browser

Another essential thing to remember is that Livewire properties are serialized or "dehydrated" before they are sent to the browser. This means that their values are converted to a format that can be sent over the wire and understood by JavaScript. This format can expose information about your application to the browser, including the names and class names of your properties.

For example, suppose you have a Livewire component that defines a public property named `$post`. This property contains an instance of a `Post` model from your database. In this case, the dehydrated value of this property sent over the wire might look something like this:

```json
{
    "type": "model",
    "class": "App\Models\Post",
    "key": 1,
    "relationships": []
}
```

As you can see, the dehydrated value of the `$post` property includes the class name of the model (`App\Models\Post`) as well as the ID and any relationships that have been eager-loaded.

If you don't want to expose the class name of the model, you can use Laravel's "morphMap" functionality from a service provider to assign an alias to a model class name:

```php
<?php

namespace App\Providers;

use Illuminate\Support\ServiceProvider;
use Illuminate\Database\Eloquent\Relations\Relation;

class AppServiceProvider extends ServiceProvider
{
    public function boot()
    {
        Relation::morphMap([
            'post' => 'App\Models\Post',
        ]);
    }
}
```

Now, when the Eloquent model is "dehydrated" (serialized), the original class name won't be exposed, only the "post" alias:

```json
{
    "type": "model",
    "class": "App\Models\Post", // [tl! remove]
    "class": "post", // [tl! add]
    "key": 1,
    "relationships": []
}
```

### Eloquent constraints aren't preserved between requests

Typically, Livewire is able to preserve and recreate server-side properties between requests; however, there are certain scenarios where preserving values are impossible between requests.

For example, when storing Eloquent collections as Livewire properties, additional query constraints like `select(...)` will not be re-applied on subsequent requests.

To demonstrate, consider the following `show-todos` component with a `select()` constraint applied to the `Todos` Eloquent collection:

```php
<?php // resources/views/components/⚡show-todos.blade.php

use Illuminate\Support\Facades\Auth;
use Livewire\Component;

new class extends Component {
    public $todos;

    public function mount()
    {
        $this->todos = Auth::user()
            ->todos()
            ->select(['title', 'content']) // [tl! highlight]
            ->get();
    }
};
```

When this component is initially loaded, the `$todos` property will be set to an Eloquent collection of the user's todos; however, only the `title` and `content` fields of each row in the database will have been queried and loaded into each of the models.

When Livewire _hydrates_ the JSON of this property back into PHP on a subsequent request, the select constraint will have been lost.

To ensure the integrity of Eloquent queries, we recommend that you use [computed properties](/docs/4.x/computed-properties) instead of properties.

Computed properties are methods in your component marked with the `#[Computed]` attribute. They can be accessed as a dynamic property that isn't stored as part of the component's state but is instead evaluated on-the-fly.

Here's the above example re-written using a computed property:

```php
<?php // resources/views/components/⚡show-todos.blade.php

use Illuminate\Support\Facades\Auth;
use Livewire\Attributes\Computed;
use Livewire\Component;

new class extends Component {
    #[Computed] // [tl! highlight]
    public function todos()
    {
        return Auth::user()
            ->todos()
            ->select(['title', 'content'])
            ->get();
    }
};
```

Here's how you would access these _todos_ from the Blade view:

```blade
<ul>
    @foreach ($this->todos as $todo)
        <li wire:key="{{ $loop->index }}">{{ $todo }}</li>
    @endforeach
</ul>
```

Notice, inside your views, you can only access computed properties on the `$this` object like so: `$this->todos`.

You can also access `$todos` from inside your class. For example, if you had a `markAllAsComplete()` action:

```php
<?php // resources/views/components/⚡show-todos.blade.php

use Illuminate\Support\Facades\Auth;
use Livewire\Attributes\Computed;
use Livewire\Component;

new class extends Component {
    #[Computed]
    public function todos()
    {
        return Auth::user()
            ->todos()
            ->select(['title', 'content'])
            ->get();
    }

    public function markAllComplete() // [tl! highlight:3]
    {
        $this->todos->each->complete();
    }
};
```

You might wonder why not just call `$this->todos()` as a method directly where you need to? Why use `#[Computed]` in the first place?

The reason is that computed properties have a performance advantage, since they are automatically memoized after their first usage during a single request. This means you can freely access `$this->todos` within your component and be assured that the actual method will only be called once, so that you don't run an expensive query multiple times in the same request.

For more information, [visit the computed properties documentation](/docs/4.x/computed-properties).

---

## Queries Debugging
Queries | laravel/framework@12.x | Source: https://github.com/laravel/docs/blob/12.x/queries.md

## Debugging

You may use the `dd` and `dump` methods while building a query to dump the current query bindings and SQL. The `dd` method will display the debug information and then stop executing the request. The `dump` method will display the debug information but allow the request to continue executing:

```php
DB::table('users')->where('votes', '>', 100)->dd();

DB::table('users')->where('votes', '>', 100)->dump();
```

The `dumpRawSql` and `ddRawSql` methods may be invoked on a query to dump the query's SQL with all parameter bindings properly substituted:

```php
DB::table('users')->where('votes', '>', 100)->dumpRawSql();

DB::table('users')->where('votes', '>', 100)->ddRawSql();
```

---

## Computed Properties
Computed Properties | livewire/livewire@4.x | Source: https://livewire.laravel.com/docs/4.x/computed-properties

Computed properties are a way to create "derived" properties in Livewire. Like accessors on an Eloquent model, computed properties allow you to access values and memoize them for future access during the request.

Computed properties are particularly useful in combination with component's public properties.

---

## Queries Reusable Query Components
Queries | laravel/framework@12.x | Source: https://github.com/laravel/docs/blob/12.x/queries.md

## Reusable Query Components

If you have repeated query logic throughout your application, you may extract the logic into reusable objects using the query builder's `tap` and `pipe` methods. Imagine you have these two different queries in your application:

```php
use Illuminate\Database\Query\Builder;
use Illuminate\Support\Facades\DB;

$destination = $request->query('destination');

DB::table('flights')
    ->when($destination, function (Builder $query, string $destination) {
        $query->where('destination', $destination);
    })
    ->orderByDesc('price')
    ->get();

// ...

$destination = $request->query('destination');

DB::table('flights')
    ->when($destination, function (Builder $query, string $destination) {
        $query->where('destination', $destination);
    })
    ->where('user', $request->user()->id)
    ->orderBy('destination')
    ->get();
```

You may like to extract the destination filtering that is common between the queries into a reusable object:

```php
<?php

namespace App\Scopes;

use Illuminate\Database\Query\Builder;

class DestinationFilter
{
    public function __construct(
        private ?string $destination,
    ) {
        //
    }

    public function __invoke(Builder $query): void
    {
        $query->when($this->destination, function (Builder $query) {
            $query->where('destination', $this->destination);
        });
    }
}
```

Then, you can use the query builder's `tap` method to apply the object's logic to the query:

```php
use App\Scopes\DestinationFilter;
use Illuminate\Database\Query\Builder;
use Illuminate\Support\Facades\DB;

DB::table('flights')
    ->when($destination, function (Builder $query, string $destination) { // [tl! remove]
        $query->where('destination', $destination); // [tl! remove]
    }) // [tl! remove]
    ->tap(new DestinationFilter($destination)) // [tl! add]
    ->orderByDesc('price')
    ->get();

// ...

DB::table('flights')
    ->when($destination, function (Builder $query, string $destination) { // [tl! remove]
        $query->where('destination', $destination); // [tl! remove]
    }) // [tl! remove]
    ->tap(new DestinationFilter($destination)) // [tl! add]
    ->where('user', $request->user()->id)
    ->orderBy('destination')
    ->get();
```

---

## Validation Form Request Validation
Validation | laravel/framework@12.x | Source: https://github.com/laravel/docs/blob/12.x/validation.md

## Form Request Validation

---

## Queries
Queries | laravel/framework@12.x | Source: https://github.com/laravel/docs/blob/12.x/queries.md

# Database: Query Builder

- [Introduction](#introduction)
- [Running Database Queries](#running-database-queries)
    - [Chunking Results](#chunking-results)
    - [Streaming Results Lazily](#streaming-results-lazily)
    - [Aggregates](#aggregates)
- [Select Statements](#select-statements)
- [Raw Expressions](#raw-expressions)
- [Joins](#joins)
- [Unions](#unions)
- [Basic Where Clauses](#basic-where-clauses)
    - [Where Clauses](#where-clauses)
    - [Or Where Clauses](#or-where-clauses)
    - [Where Not Clauses](#where-not-clauses)
    - [Where Any / All / None Clauses](#where-any-all-none-clauses)
    - [JSON Where Clauses](#json-where-clauses)
    - [Additional Where Clauses](#additional-where-clauses)
    - [Logical Grouping](#logical-grouping)
- [Advanced Where Clauses](#advanced-where-clauses)
    - [Where Exists Clauses](#where-exists-clauses)
    - [Subquery Where Clauses](#subquery-where-clauses)
    - [Full Text Where Clauses](#full-text-where-clauses)
    - [Vector Similarity Clauses](#vector-similarity-clauses)
- [Ordering, Grouping, Limit and Offset](#ordering-grouping-limit-and-offset)
    - [Ordering](#ordering)
    - [Grouping](#grouping)
    - [Limit and Offset](#limit-and-offset)
- [Conditional Clauses](#conditional-clauses)
- [Insert Statements](#insert-statements)
    - [Upserts](#upserts)
- [Update Statements](#update-statements)
    - [Updating JSON Columns](#updating-json-columns)
    - [Increment and Decrement](#increment-and-decrement)
- [Delete Statements](#delete-statements)
- [Pessimistic Locking](#pessimistic-locking)
- [Reusable Query Components](#reusable-query-components)
- [Debugging](#debugging)

---

## Queries Reusable Query Components Query Pipes
Queries | laravel/framework@12.x | Source: https://github.com/laravel/docs/blob/12.x/queries.md

#### Query Pipes

The `tap` method will always return the query builder. If you would like to extract an object that executes the query and returns another value, you may use the `pipe` method instead.

Consider the following query object that contains shared [pagination](/docs/{{version}}/pagination) logic used throughout an application. Unlike the `DestinationFilter`, which applies query conditions to the query, the `Paginate` object executes the query and returns a paginator instance:

```php
<?php

namespace App\Scopes;

use Illuminate\Contracts\Pagination\LengthAwarePaginator;
use Illuminate\Database\Query\Builder;

class Paginate
{
    public function __construct(
        private string $sortBy = 'timestamp',
        private string $sortDirection = 'desc',
        private int $perPage = 25,
    ) {
        //
    }

    public function __invoke(Builder $query): LengthAwarePaginator
    {
        return $query->orderBy($this->sortBy, $this->sortDirection)
            ->paginate($this->perPage, pageName: 'p');
    }
}
```

Using the query builder's `pipe` method, we can leverage this object to apply our shared pagination logic:

```php
$flights = DB::table('flights')
    ->tap(new DestinationFilter($destination))
    ->pipe(new Paginate);
```

---

## Validation Form objects
Validation | livewire/livewire@4.x | Source: https://livewire.laravel.com/docs/4.x/validation

## Form objects

As more properties and validation rules are added to a Livewire component, it can begin to feel too crowded. To alleviate this pain and also provide a helpful abstraction for code reuse, you can use Livewire's *Form Objects* to store your properties and validation rules.

Below is the same `CreatePost` example, but now the properties and rules have been extracted to a dedicated form object named `PostForm`:

```php
<?php

namespace App\Livewire\Forms;

use Livewire\Attributes\Validate;
use Livewire\Form;

class PostForm extends Form
{
    #[Validate('required|min:3')]
	public $title = '';

    #[Validate('required|min:3')]
    public $content = '';
}
```

The `PostForm` above can now be defined as a property on the `CreatePost` component:

```php
<?php

namespace App\Livewire;

use App\Livewire\Forms\PostForm;
use Livewire\Component;
use App\Models\Post;

class CreatePost extends Component
{
    public PostForm $form;

    public function save()
    {
		Post::create(
    		$this->form->all()
    	);

		return redirect()->to('/posts');
    }

    // ...
}
```

As you can see, instead of listing out each property individually, we can retrieve all the property values using the `->all()` method on the form object.

Also, when referencing the property names in the template, you must prepend `form.` to each instance:

```blade
<form wire:submit="save">
	<input type="text" wire:model="form.title">
    <div>@error('form.title') {{ $message }} @enderror</div>

	<textarea wire:model="form.content"></textarea>
    <div>@error('form.content') {{ $message }} @enderror</div>

	<button type="submit">Save</button>
</form>
```

When using form objects, `#[Validate]` attribute validation will be run every time a property is updated. However, if you disable this behavior by specifying `onUpdate: false` on the attribute, you can manually run a form object's validation using `$this->form->validate()`:

```php
public function save()
{
    Post::create(
        $this->form->validate()
    );

    return redirect()->to('/posts');
}
```

Form objects are a useful abstraction for most larger datasets and a variety of additional features that make them even more powerful. For more information, check out the comprehensive [form object documentation](/docs/4.x/forms#extracting-a-form-object).

_[Truncated]_


output:
Wall time: 4.0647 seconds
Output:
[{"type":"text","text":"# Search Results\n\n## Components Select > The button slot\nComponents Select | livewire/flux@2.x | Source: https://fluxui.dev/components/select#livewire/flux\n\n
\n            The button slot\n

If you need full control over the button used to trigger the custom select, you can use the button slot to render it yourself.

<flux:select variant=\"listbox\">    <x-slot name=\"button\">        <flux:select.button class=\"rounded-full!\" placeholder=\"Choose industry...\" :invalid=\"$errors->has('...')\" />    </x-slot>    <flux:select.option>Photography</flux:select.option>    ...</flux:select>

\n\n---\n\n## Properties See also\nProperties | livewire/livewire@4.x | Source: https://livewire.laravel.com/docs/4.x/properties\n\n## See also\n\n- **[Forms](/docs/4.x/forms)** — Bind properties to form inputs with wire:model\n- **[Computed Properties](/docs/4.x/computed-properties)** — Create derived values with automatic memoization\n- **[Validation](/docs/4.x/validation)** — Validate property values before persisting\n- **[Locked Attribute](/docs/4.x/attribute-locked)** — Prevent properties from being manipulated client-side\n- **[Alpine](/docs/4.x/alpine)** — Access and manipulate properties from JavaScript\n\n---\n\n## Validation Validation Quickstart Displaying the Validation Errors XHR Requests and Validation\nValidation | laravel/framework@12.x | Source: https://github.com/laravel/docs/blob/12.x/validation.md\n\n\n#### XHR Requests and Validation\n\nIn this example, we used a traditional form to send data to the application. However, many applications receive XHR requests from a JavaScript powered frontend. When using the `validate` method during an XHR request, Laravel will not generate a redirect response. Instead, Laravel generates a [JSON response containing all of the validation errors](#validation-error-response-format). This JSON response will be sent with a 422 HTTP status code.\n\n---\n\n## Search Full-Text Search Running Full-Text Queries\nSearch | laravel/framework@12.x | Source: https://github.com/laravel/docs/blob/12.x/search.md\n\n\n### Running Full-Text Queries\n\nOnce the index is in place, use the `whereFullText` query builder method to search against it. Laravel will generate the appropriate SQL for your database driver — for example, `MATCH(...) AGAINST(...)` on MariaDB and MySQL, and `to_tsvector(...) @@ plainto_tsquery(...)` on PostgreSQL:\n\n```php\n$articles = Article::whereFullText('body', 'web developer')->get();\n```\n\nWhen using MariaDB and MySQL, results are automatically ordered by relevance score. On PostgreSQL, `whereFullText` filters matching records but does not order them by relevance — if you need automatic relevance ordering on PostgreSQL, consider using [Scout's database engine](#database-engine), which handles this for you.\n\nIf you created a composite full-text index across multiple columns, you may search against all of them by passing the same array of columns to `whereFullText`:\n\n```php\n$articles = Article::whereFullText(\n    ['title', 'body'], 'web developer'\n)->get();\n```\n\nThe `orWhereFullText` method may be used to add a full-text search clause as an \"or\" condition. For complete details, consult the [query builder documentation](/docs/{{version}}/queries#full-text-where-clauses).\n\n---\n\n## Attribute Computed Learn more\nAttribute Computed | livewire/livewire@4.x | Source: https://livewire.laravel.com/docs/4.x/attribute-computed\n\n## Learn more\n\nFor detailed information about computed properties, caching strategies, and advanced use cases, see the [Computed Properties documentation](/docs/4.x/computed-properties).\n\n---\n\n## Validation Available Validation Rules json\nValidation | laravel/framework@12.x | Source: https://github.com/laravel/docs/blob/12.x/validation.md\n\n\n#### json\n\nThe field under validation must be a valid JSON string.\n\n---\n\n## Properties Security concerns\nProperties | livewire/livewire@4.x | Source: https://livewire.laravel.com/docs/4.x/properties\n\n## Security concerns\n\nWhile Livewire properties are a powerful feature, there are a few security considerations that you should be aware of before using them.\n\nIn short, always treat public properties as user input — as if they were request input from a traditional endpoint. In light of this, it's essential to validate and authorize properties before persisting them to a database — just like you would do when working with request input in a controller.\n\n### Don't trust property values\n\nTo demonstrate how neglecting to authorize and validate properties can introduce security holes in your application, the following `post.edit` component is vulnerable to attack:\n\n```php\n<?php // resources/views/components/post/⚡edit.blade.php\n\nuse Livewire\\Component;\nuse App\\Models\\Post;\n\nnew class extends Component {\n    public $id;\n    public $title;\n    public $content;\n\n    public function mount(Post $post)\n    {\n        $this->id = $post->id;\n        $this->title = $post->title;\n        $this->content = $post->content;\n    }\n\n    public function update()\n    {\n        $post = Post::findOrFail($this->id);\n\n        $post->update([\n            'title' => $this->title,\n            'content' => $this->content,\n        ]);\n\n        session()->flash('message', 'Post updated successfully!');\n    }\n};\n```\n\n```blade\n<form wire:submit=\"update\">\n    <input type=\"text\" wire:model=\"title\">\n    <input type=\"text\" wire:model=\"content\">\n\n    <button type=\"submit\">Update</button>\n</form>\n```\n\nAt first glance, this component may look completely fine. But, let's walk through how an attacker could use the component to do unauthorized things in your application.\n\nBecause we are storing the `id` of the post as a public property on the component, it can be manipulated on the client just the same as the `title` and `content` properties.\n\nIt doesn't matter that we didn't write an input with `wire:model=\"id\"`. A malicious user can easily change the view to the following using their browser DevTools:\n\n```blade\n<form wire:submit=\"update\">\n    <input type=\"text\" wire:model=\"id\"> <!-- [tl! highlight] -->\n    <input type=\"text\" wire:model=\"title\">\n    <input type=\"text\" wire:model=\"content\">\n\n    <button type=\"submit\">Update</button>\n</form>\n```\n\nNow the malicious user can update the `id` input to the ID of a different post model. When the form is submitted and `update()` is called, `Post::findOrFail()` will return and update a post the user is not the owner of.\n\nTo prevent this kind of attack, we can use one or both of the following strategies:\n\n* Authorize the input\n* Lock the property from updates\n\n#### Authorizing the input\n\nBecause `$id` can be manipulated client-side with something like `wire:model`, just like in a controller, we can use [Laravel's authorization](https://laravel.com/docs/authorization) to make sure the current user can update the post:\n\n```php\npublic function update()\n{\n    $post = Post::findOrFail($this->id);\n\n    $this->authorize('update', $post); // [tl! highlight]\n\n    $post->update(...);\n}\n```\n\nIf a malicious user mutates the `$id` property, the added authorization will catch it and throw an error.\n\n#### Locking the property\n\nLivewire also allows you to \"lock\" properties in order to prevent properties from being modified on the client-side. You can \"lock\" a property from client-side manipulation using the `#[Locked]` attribute:\n\n```php\nuse Livewire\\Attributes\\Locked;\nuse Livewire\\Component;\n\nnew class extends Component {\n    #[Locked] // [tl! highlight]\n    public $id;\n\n    // ...\n};\n```\n\nNow, if a user tries to modify `$id` on the front end, an error will be thrown.\n\nBy using `#[Locked]`, you can assume this property has not been manipulated anywhere outside your component's class.\n\nFor more information on locking properties, [consult the Locked attribute documentation](/docs/4.x/attribute-locked).\n\n#### Eloquent models and locking\n\nWhen an Eloquent model is assigned to a Livewire component property, Livewire will automatically lock the property and ensure the ID isn't changed, so that you are safe from these kinds of attacks:\n\n```php\n<?php // resources/views/components/post/⚡edit.blade.php\n\nuse Livewire\\Component;\nuse App\\Models\\Post;\n\nnew class extends Component {\n    public Post $post; // [tl! highlight]\n    public $title;\n    public $content;\n\n    public function mount(Post $post)\n    {\n        $this->post = $post;\n        $this->title = $post->title;\n        $this->content = $post->content;\n    }\n\n    public function update()\n    {\n        $this->post->update([\n            'title' => $this->title,\n            'content' => $this->content,\n        ]);\n\n        session()->flash('message', 'Post updated successfully!');\n    }\n};\n```\n\n### Properties expose system information to the browser\n\nAnother essential thing to remember is that Livewire properties are serialized or \"dehydrated\" before they are sent to the browser. This means that their values are converted to a format that can be sent over the wire and understood by JavaScript. This format can expose information about your application to the browser, including the names and class names of your properties.\n\nFor example, suppose you have a Livewire component that defines a public property named `$post`. This property contains an instance of a `Post` model from your database. In this case, the dehydrated value of this property sent over the wire might look something like this:\n\n```json\n{\n    \"type\": \"model\",\n    \"class\": \"App\\Models\\Post\",\n    \"key\": 1,\n    \"relationships\": []\n}\n```\n\nAs you can see, the dehydrated value of the `$post` property includes the class name of the model (`App\\Models\\Post`) as well as the ID and any relationships that have been eager-loaded.\n\nIf you don't want to expose the class name of the model, you can use Laravel's \"morphMap\" functionality from a service provider to assign an alias to a model class name:\n\n```php\n<?php\n\nnamespace App\\Providers;\n\nuse Illuminate\\Support\\ServiceProvider;\nuse Illuminate\\Database\\Eloquent\\Relations\\Relation;\n\nclass AppServiceProvider extends ServiceProvider\n{\n    public function boot()\n    {\n        Relation::morphMap([\n            'post' => 'App\\Models\\Post',\n        ]);\n    }\n}\n```\n\nNow, when the Eloquent model is \"dehydrated\" (serialized), the original class name won't be exposed, only the \"post\" alias:\n\n```json\n{\n    \"type\": \"model\",\n    \"class\": \"App\\Models\\Post\", // [tl! remove]\n    \"class\": \"post\", // [tl! add]\n    \"key\": 1,\n    \"relationships\": []\n}\n```\n\n### Eloquent constraints aren't preserved between requests\n\nTypically, Livewire is able to preserve and recreate server-side properties between requests; however, there are certain scenarios where preserving values are impossible between requests.\n\nFor example, when storing Eloquent collections as Livewire properties, additional query constraints like `select(...)` will not be re-applied on subsequent requests.\n\nTo demonstrate, consider the following `show-todos` component with a `select()` constraint applied to the `Todos` Eloquent collection:\n\n```php\n<?php // resources/views/components/⚡show-todos.blade.php\n\nuse Illuminate\\Support\\Facades\\Auth;\nuse Livewire\\Component;\n\nnew class extends Component {\n    public $todos;\n\n    public function mount()\n    {\n        $this->todos = Auth::user()\n            ->todos()\n            ->select(['title', 'content']) // [tl! highlight]\n            ->get();\n    }\n};\n```\n\nWhen this component is initially loaded, the `$todos` property will be set to an Eloquent collection of the user's todos; however, only the `title` and `content` fields of each row in the database will have been queried and loaded into each of the models.\n\nWhen Livewire _hydrates_ the JSON of this property back into PHP on a subsequent request, the select constraint will have been lost.\n\nTo ensure the integrity of Eloquent queries, we recommend that you use [computed properties](/docs/4.x/computed-properties) instead of properties.\n\nComputed properties are methods in your component marked with the `#[Computed]` attribute. They can be accessed as a dynamic property that isn't stored as part of the component's state but is instead evaluated on-the-fly.\n\nHere's the above example re-written using a computed property:\n\n```php\n<?php // resources/views/components/⚡show-todos.blade.php\n\nuse Illuminate\\Support\\Facades\\Auth;\nuse Livewire\\Attributes\\Computed;\nuse Livewire\\Component;\n\nnew class extends Component {\n    #[Computed] // [tl! highlight]\n    public function todos()\n    {\n        return Auth::user()\n            ->todos()\n            ->select(['title', 'content'])\n            ->get();\n    }\n};\n```\n\nHere's how you would access these _todos_ from the Blade view:\n\n```blade\n<ul>\n    @foreach ($this->todos as $todo)\n        <li wire:key=\"{{ $loop->index }}\">{{ $todo }}</li>\n    @endforeach\n</ul>\n```\n\nNotice, inside your views, you can only access computed properties on the `$this` object like so: `$this->todos`.\n\nYou can also access `$todos` from inside your class. For example, if you had a `markAllAsComplete()` action:\n\n```php\n<?php // resources/views/components/⚡show-todos.blade.php\n\nuse Illuminate\\Support\\Facades\\Auth;\nuse Livewire\\Attributes\\Computed;\nuse Livewire\\Component;\n\nnew class extends Component {\n    #[Computed]\n    public function todos()\n    {\n        return Auth::user()\n            ->todos()\n            ->select(['title', 'content'])\n            ->get();\n    }\n\n    public function markAllComplete() // [tl! highlight:3]\n    {\n        $this->todos->each->complete();\n    }\n};\n```\n\nYou might wonder why not just call `$this->todos()` as a method directly where you need to? Why use `#[Computed]` in the first place?\n\nThe reason is that computed properties have a performance advantage, since they are automatically memoized after their first usage during a single request. This means you can freely access `$this->todos` within your component and be assured that the actual method will only be called once, so that you don't run an expensive query multiple times in the same request.\n\nFor more information, [visit the computed properties documentation](/docs/4.x/computed-properties).\n\n---\n\n## Queries Debugging\nQueries | laravel/framework@12.x | Source: https://github.com/laravel/docs/blob/12.x/queries.md\n\n\n## Debugging\n\nYou may use the `dd` and `dump` methods while building a query to dump the current query bindings and SQL. The `dd` method will display the debug information and then stop executing the request. The `dump` method will display the debug information but allow the request to continue executing:\n\n```php\nDB::table('users')->where('votes', '>', 100)->dd();\n\nDB::table('users')->where('votes', '>', 100)->dump();\n```\n\nThe `dumpRawSql` and `ddRawSql` methods may be invoked on a query to dump the query's SQL with all parameter bindings properly substituted:\n\n```php\nDB::table('users')->where('votes', '>', 100)->dumpRawSql();\n\nDB::table('users')->where('votes', '>', 100)->ddRawSql();\n```\n\n---\n\n## Computed Properties\nComputed Properties | livewire/livewire@4.x | Source: https://livewire.laravel.com/docs/4.x/computed-properties\n\nComputed properties are a way to create \"derived\" properties in Livewire. Like accessors on an Eloquent model, computed properties allow you to access values and memoize them for future access during the request.\n\nComputed properties are particularly useful in combination with component's public properties.\n\n---\n\n## Queries Reusable Query Components\nQueries | laravel/framework@12.x | Source: https://github.com/laravel/docs/blob/12.x/queries.md\n\n\n## Reusable Query Components\n\nIf you have repeated query logic throughout your application, you may extract the logic into reusable objects using the query builder's `tap` and `pipe` methods. Imagine you have these two different queries in your application:\n\n```php\nuse Illuminate\\Database\\Query\\Builder;\nuse Illuminate\\Support\\Facades\\DB;\n\n$destination = $request->query('destination');\n\nDB::table('flights')\n    ->when($destination, function (Builder $query, string $destination) {\n        $query->where('destination', $destination);\n    })\n    ->orderByDesc('price')\n    ->get();\n\n// ...\n\n$destination = $request->query('destination');\n\nDB::table('flights')\n    ->when($destination, function (Builder $query, string $destination) {\n        $query->where('destination', $destination);\n    })\n    ->where('user', $request->user()->id)\n    ->orderBy('destination')\n    ->get();\n```\n\nYou may like to extract the destination filtering that is common between the queries into a reusable object:\n\n```php\n<?php\n\nnamespace App\\Scopes;\n\nuse Illuminate\\Database\\Query\\Builder;\n\nclass DestinationFilter\n{\n    public function __construct(\n        private ?string $destination,\n    ) {\n        //\n    }\n\n    public function __invoke(Builder $query): void\n    {\n        $query->when($this->destination, function (Builder $query) {\n            $query->where('destination', $this->destination);\n        });\n    }\n}\n```\n\nThen, you can use the query builder's `tap` method to apply the object's logic to the query:\n\n```php\nuse App\\Scopes\\DestinationFilter;\nuse Illuminate\\Database\\Query\\Builder;\nuse Illuminate\\Support\\Facades\\DB;\n\nDB::table('flights')\n    ->when($destination, function (Builder $query, string $destination) { // [tl! remove]\n        $query->where('destination', $destination); // [tl! remove]\n    }) // [tl! remove]\n    ->tap(new DestinationFilter($destination)) // [tl! add]\n    ->orderByDesc('price')\n    ->get();\n\n// ...\n\nDB::table('flights')\n    ->when($destination, function (Builder $query, string $destination) { // [tl! remove]\n        $query->where('destination', $destination); // [tl! remove]\n    }) // [tl! remove]\n    ->tap(new DestinationFilter($destination)) // [tl! add]\n    ->where('user', $request->user()->id)\n    ->orderBy('destination')\n    ->get();\n```\n\n---\n\n## Validation Form Request Validation\nValidation | laravel/framework@12.x | Source: https://github.com/laravel/docs/blob/12.x/validation.md\n\n\n## Form Request Validation\n\n---\n\n## Queries\nQueries | laravel/framework@12.x | Source: https://github.com/laravel/docs/blob/12.x/queries.md\n\n# Database: Query Builder\n\n- [Introduction](#introduction)\n- [Running Database Queries](#running-database-queries)\n    - [Chunking Results](#chunking-results)\n    - [Streaming Results Lazily](#streaming-results-lazily)\n    - [Aggregates](#aggregates)\n- [Select Statements](#select-statements)\n- [Raw Expressions](#raw-expressions)\n- [Joins](#joins)\n- [Unions](#unions)\n- [Basic Where Clauses](#basic-where-clauses)\n    - [Where Clauses](#where-clauses)\n    - [Or Where Clauses](#or-where-clauses)\n    - [Where Not Clauses](#where-not-clauses)\n    - [Where Any / All / None Clauses](#where-any-all-none-clauses)\n    - [JSON Where Clauses](#json-where-clauses)\n    - [Additional Where Clauses](#additional-where-clauses)\n    - [Logical Grouping](#logical-grouping)\n- [Advanced Where Clauses](#advanced-where-clauses)\n    - [Where Exists Clauses](#where-exists-clauses)\n    - [Subquery Where Clauses](#subquery-where-clauses)\n    - [Full Text Where Clauses](#full-text-where-clauses)\n    - [Vector Similarity Clauses](#vector-similarity-clauses)\n- [Ordering, Grouping, Limit and Offset](#ordering-grouping-limit-and-offset)\n    - [Ordering](#ordering)\n    - [Grouping](#grouping)\n    - [Limit and Offset](#limit-and-offset)\n- [Conditional Clauses](#conditional-clauses)\n- [Insert Statements](#insert-statements)\n    - [Upserts](#upserts)\n- [Update Statements](#update-statements)\n    - [Updating JSON Columns](#updating-json-columns)\n    - [Increment and Decrement](#increment-and-decrement)\n- [Delete Statements](#delete-statements)\n- [Pessimistic Locking](#pessimistic-locking)\n- [Reusable Query Components](#reusable-query-components)\n- [Debugging](#debugging)\n\n---\n\n## Queries Reusable Query Components Query Pipes\nQueries | laravel/framework@12.x | Source: https://github.com/laravel/docs/blob/12.x/queries.md\n\n\n#### Query Pipes\n\nThe `tap` method will always return the query builder. If you would like to extract an object that executes the query and returns another value, you may use the `pipe` method instead.\n\nConsider the following query object that contains shared [pagination](/docs/{{version}}/pagination) logic used throughout an application. Unlike the `DestinationFilter`, which applies query conditions to the query, the `Paginate` object executes the query and returns a paginator instance:\n\n```php\n<?php\n\nnamespace App\\Scopes;\n\nuse Illuminate\\Contracts\\Pagination\\LengthAwarePaginator;\nuse Illuminate\\Database\\Query\\Builder;\n\nclass Paginate\n{\n    public function __construct(\n        private string $sortBy = 'timestamp',\n        private string $sortDirection = 'desc',\n        private int $perPage = 25,\n    ) {\n        //\n    }\n\n    public function __invoke(Builder $query): LengthAwarePaginator\n    {\n        return $query->orderBy($this->sortBy, $this->sortDirection)\n            ->paginate($this->perPage, pageName: 'p');\n    }\n}\n```\n\nUsing the query builder's `pipe` method, we can leverage this object to apply our shared pagination logic:\n\n```php\n$flights = DB::table('flights')\n    ->tap(new DestinationFilter($destination))\n    ->pipe(new Paginate);\n```\n\n---\n\n## Validation Form objects\nValidation | livewire/livewire@4.x | Source: https://livewire.laravel.com/docs/4.x/validation\n\n## Form objects\n\nAs more properties and validation rules are added to a Livewire component, it can begin to feel too crowded. To alleviate this pain and also provide a helpful abstraction for code reuse, you can use Livewire's *Form Objects* to store your properties and validation rules.\n\nBelow is the same `CreatePost` example, but now the properties and rules have been extracted to a dedicated form object named `PostForm`:\n\n```php\n<?php\n\nnamespace App\\Livewire\\Forms;\n\nuse Livewire\\Attributes\\Validate;\nuse Livewire\\Form;\n\nclass PostForm extends Form\n{\n    #[Validate('required|min:3')]\n\tpublic $title = '';\n\n    #[Validate('required|min:3')]\n    public $content = '';\n}\n```\n\nThe `PostForm` above can now be defined as a property on the `CreatePost` component:\n\n```php\n<?php\n\nnamespace App\\Livewire;\n\nuse App\\Livewire\\Forms\\PostForm;\nuse Livewire\\Component;\nuse App\\Models\\Post;\n\nclass CreatePost extends Component\n{\n    public PostForm $form;\n\n    public function save()\n    {\n\t\tPost::create(\n    \t\t$this->form->all()\n    \t);\n\n\t\treturn redirect()->to('/posts');\n    }\n\n    // ...\n}\n```\n\nAs you can see, instead of listing out each property individually, we can retrieve all the property values using the `->all()` method on the form object.\n\nAlso, when referencing the property names in the template, you must prepend `form.` to each instance:\n\n```blade\n<form wire:submit=\"save\">\n\t<input type=\"text\" wire:model=\"form.title\">\n    <div>@error('form.title') {{ $message }} @enderror</div>\n\n\t<textarea wire:model=\"form.content\"></textarea>\n    <div>@error('form.content') {{ $message }} @enderror</div>\n\n\t<button type=\"submit\">Save</button>\n</form>\n```\n\nWhen using form objects, `#[Validate]` attribute validation will be run every time a property is updated. However, if you disable this behavior by specifying `onUpdate: false` on the attribute, you can manually run a form object's validation using `$this->form->validate()`:\n\n```php\npublic function save()\n{\n    Post::create(\n        $this->form->validate()\n    );\n\n    return redirect()->to('/posts');\n}\n```\n\nForm objects are a useful abstraction for most larger datasets and a variety of additional features that make them even more powerful. For more information, check out the comprehensive [form object documentation](/docs/4.x/forms#extracting-a-form-object).\n\n_[Truncated]_"}]


command: sed -n '1,220p' /Users/fabianwesner/Herd/shop/.agents/skills/fluxui-development/SKILL.md

SKILL.md

type: read

aggregated_output:
---
name: fluxui-development
description: "Use this skill for Flux UI development in Livewire applications only. Trigger when working with <flux:*> components, building or customizing Livewire component UIs, creating forms, modals, tables, or other interactive elements. Covers: flux: components (buttons, inputs, modals, forms, tables, date-pickers, kanban, badges, tooltips, etc.), component composition, Tailwind CSS styling, Heroicons/Lucide icon integration, validation patterns, responsive design, and theming. Do not use for non-Livewire frameworks or non-component styling."
license: MIT
metadata:
  author: laravel
---

# Flux UI Development

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

<!-- Basic Button -->
```blade
<flux:button variant="primary">Click me</flux:button>
```

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

## Icons

Flux includes [Heroicons](https://heroicons.com/) as its default icon set. Search for exact icon names on the Heroicons site - do not guess or invent icon names.

<!-- Icon Button -->
```blade
<flux:button icon="arrow-down-tray">Export</flux:button>
```

For icons not available in Heroicons, use [Lucide](https://lucide.dev/). Import the icons you need with the Artisan command:

```bash
php artisan flux:icon crown grip-vertical github
```

## Common Patterns

### Form Fields

<!-- Form Field -->
```blade
<flux:field>
    <flux:label>Email</flux:label>
    <flux:input type="email" wire:model="email" />
    <flux:error name="email" />
</flux:field>
```

### Modals

<!-- Modal -->
```blade
<flux:modal wire:model="showModal">
    <flux:heading>Title</flux:heading>
    <p>Content</p>
</flux:modal>
```

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


command: sed -n '1,220p' /Users/fabianwesner/Herd/shop/.agents/skills/tailwindcss-development/SKILL.md

aggregated_output:
---
name: tailwindcss-development
description: "Always invoke when the user's message includes 'tailwind' in any form. Also invoke for: building responsive grid layouts (multi-column card grids, product grids), flex/grid page structures (dashboards with sidebars, fixed topbars, mobile-toggle navs), styling UI components (cards, tables, navbars, pricing sections, forms, inputs, badges), adding dark mode variants, fixing spacing or typography, and Tailwind v3/v4 work. The core use case: writing or fixing Tailwind utility classes in HTML templates (Blade, JSX, Vue). Skip for backend PHP logic, database queries, API routes, JavaScript with no HTML/CSS component, CSS file audits, build tool configuration, and vanilla CSS."
license: MIT
metadata:
  author: laravel
---

# Tailwind CSS Development

## Documentation

Use `search-docs` for detailed Tailwind CSS v4 patterns and documentation.

## Basic Usage

- Use Tailwind CSS classes to style HTML. Check and follow existing Tailwind conventions in the project before introducing new patterns.
- Offer to extract repeated patterns into components that match the project's conventions (e.g., Blade, JSX, Vue).
- Consider class placement, order, priority, and defaults. Remove redundant classes, add classes to parent or child elements carefully to reduce repetition, and group elements logically.

## Tailwind CSS v4 Specifics

- Always use Tailwind CSS v4 and avoid deprecated utilities.
- `corePlugins` is not supported in Tailwind v4.

### CSS-First Configuration

In Tailwind v4, configuration is CSS-first using the `@theme` directive — no separate `tailwind.config.js` file is needed:

<!-- CSS-First Config -->
```css
@theme {
  --color-brand: oklch(0.72 0.11 178);
}
```

### Import Syntax

In Tailwind v4, import Tailwind with a regular CSS `@import` statement instead of the `@tailwind` directives used in v3:

<!-- v4 Import Syntax -->
```diff
- @tailwind base;
- @tailwind components;
- @tailwind utilities;
+ @import "tailwindcss";
```

### Replaced Utilities

Tailwind v4 removed deprecated utilities. Use the replacements shown below. Opacity values remain 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 |

## Spacing

Use `gap` utilities instead of margins for spacing between siblings:

<!-- Gap Utilities -->
```html
<div class="flex gap-8">
    <div>Item 1</div>
    <div>Item 2</div>
</div>
```

## Dark Mode

If existing pages and components support dark mode, new pages and components must support it the same way, typically using the `dark:` variant:

<!-- Dark Mode -->
```html
<div class="bg-white dark:bg-gray-900 text-gray-900 dark:text-white">
    Content adapts to color scheme
</div>
```

## Common Patterns

### Flexbox Layout

<!-- Flexbox Layout -->
```html
<div class="flex items-center justify-between gap-4">
    <div>Left content</div>
    <div>Right content</div>
</div>
```

### Grid Layout

<!-- Grid Layout -->
```html
<div class="grid grid-cols-1 md:grid-cols-2 lg:grid-cols-3 gap-6">
    <div>Card 1</div>
    <div>Card 2</div>
    <div>Card 3</div>
</div>
```

## Common Pitfalls

- Using deprecated v3 utilities (bg-opacity-*, flex-shrink-*, etc.)
- Using `@tailwind` directives instead of `@import "tailwindcss"`
- Trying to use `tailwind.config.js` instead of CSS `@theme` directive
- Using margins for spacing between siblings instead of gap utilities
- Forgetting to add dark mode variants when the project uses dark mode


command: sed -n '1,220p' /Users/fabianwesner/Herd/shop/.agents/skills/livewire-development/SKILL.md

aggregated_output:
---
name: livewire-development
description: "Use for any task or question involving Livewire. Activate if user mentions Livewire, wire: directives, or Livewire-specific concepts like wire:model, wire:click, wire:sort, or islands, invoke this skill. Covers building new components, debugging reactivity issues, real-time form validation, drag-and-drop, loading states, migrating from Livewire 3 to 4, converting component formats (SFC/MFC/class-based), and performance optimization. Do not use for non-Livewire reactive UI (React, Vue, Alpine-only, Inertia.js) or standard Laravel forms without Livewire."
license: MIT
metadata:
  author: laravel
---

# Livewire Development

## Documentation

Use `search-docs` for detailed Livewire 4 patterns and documentation.

## Basic Usage

### Creating Components

```bash

# Single-file component (SFC - default in v4)

# Creates: resources/views/components/⚡create-post.blade.php

php artisan make:livewire create-post

# Page component (SFC - Full Page in v4)

# Creates: resources/views/pages/⚡create-post.blade.php

php artisan make:livewire pages::create-post

# Multi-file component (MFC)

# Creates: resources/views/components/⚡create-post/create-post.php

#          resources/views/components/⚡create-post/create-post.blade.php

php artisan make:livewire create-post --mfc

# Class-based component (v3 style)

# Creates: app/Livewire/CreatePost.php AND resources/views/livewire/create-post.blade.php

php artisan make:livewire create-post --class

# With namespace

php artisan make:livewire Posts/CreatePost
```

### Converting Between Formats

Use `php artisan livewire:convert create-post` to convert between single-file, multi-file, and class-based formats.

### Choosing a Component Format

> **Always follow the project's existing conventions first.** Before creating any component, inspect the project's existing Livewire components to determine the established format (SFC, MFC, or class-based) and directory structure. Check `app/Livewire/`, `resources/views/components/`, and `resources/views/livewire/` for existing components. If the project already uses a consistent format, **use that same format** — even if it differs from the Livewire v4 defaults below. Only fall back to the v4 defaults (SFC in `resources/views/components/`) when no existing convention is established.

Also check `config/livewire.php` for `make_command.type`, `make_command.emoji`, `component_locations`, and `component_namespaces` overrides, which change the default format and where files are stored.

### Component Format Reference

| Format | Flag | Class Path | View Path |
|--------|------|------------|-----------|
| Single-file (SFC) | default | — | `resources/views/components/⚡create-post.blade.php` (PHP + Blade in one file) |
| Full Page SFC | `pages::name` | — | `resources/views/pages/⚡create-post.blade.php` |
| Multi-file (MFC) | `--mfc` | `resources/views/components/⚡create-post/create-post.php` | `resources/views/components/⚡create-post/create-post.blade.php` |
| Class-based | `--class` | `app/Livewire/CreatePost.php` | `resources/views/livewire/create-post.blade.php` |
| View-based | default (Blade-only) | — | `resources/views/components/⚡create-post.blade.php` (Blade-only with functional state) |

> **Important:** The ⚡ prefix shown above is the **default** behavior in Livewire v4 — it is **configurable**. Check `config/livewire.php` for the `make_command.emoji` setting. When `true` (default), always include the ⚡ prefix in filenames you create. When `false`, omit the ⚡ prefix from all paths above.

Namespaced components map to subdirectories: `make:livewire Posts/CreatePost` creates `resources/views/components/posts/⚡create-post.blade.php` (single-file by default). Use `make:livewire Posts/CreatePost --mfc` for multi-file output at `resources/views/components/posts/⚡create-post/create-post.php` and `resources/views/components/posts/⚡create-post/create-post.blade.php`.

### Single-File Component Example

<!-- Single-File Component Example -->
```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>
```

## 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 (e.g., `Route::livewire('/posts/create', CreatePost::class)`); 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

<!-- Testing Example -->
```php
Livewire::test(Counter::class)
    ->assertSet('count', 0)
    ->call('increment')
    ->assertSet('count', 1);
```

## 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)


output:
Chunk ID: df54b2
Wall time: 0.0000 seconds
Process exited with code 0
Original token count: 1888
Output:
---
name: livewire-development
description: "Use for any task or question involving Livewire. Activate if user mentions Livewire, wire: directives, or Livewire-specific concepts like wire:model, wire:click, wire:sort, or islands, invoke this skill. Covers building new components, debugging reactivity issues, real-time form validation, drag-and-drop, loading states, migrating from Livewire 3 to 4, converting component formats (SFC/MFC/class-based), and performance optimization. Do not use for non-Livewire reactive UI (React, Vue, Alpine-only, Inertia.js) or standard Laravel forms without Livewire."
license: MIT
metadata:
  author: laravel
---

# Livewire Development

## Documentation

Use `search-docs` for detailed Livewire 4 patterns and documentation.

## Basic Usage

### Creating Components

```bash

# Single-file component (SFC - default in v4)

# Creates: resources/views/components/⚡create-post.blade.php

php artisan make:livewire create-post

# Page component (SFC - Full Page in v4)

# Creates: resources/views/pages/⚡create-post.blade.php

php artisan make:livewire pages::create-post

# Multi-file component (MFC)

# Creates: resources/views/components/⚡create-post/create-post.php

#          resources/views/components/⚡create-post/create-post.blade.php

php artisan make:livewire create-post --mfc

# Class-based component (v3 style)

# Creates: app/Livewire/CreatePost.php AND resources/views/livewire/create-post.blade.php

php artisan make:livewire create-post --class

# With namespace

php artisan make:livewire Posts/CreatePost
```

### Converting Between Formats

Use `php artisan livewire:convert create-post` to convert between single-file, multi-file, and class-based formats.

### Choosing a Component Format

> **Always follow the project's existing conventions first.** Before creating any component, inspect the project's existing Livewire components to determine the established format (SFC, MFC, or class-based) and directory structure. Check `app/Livewire/`, `resources/views/components/`, and `resources/views/livewire/` for existing components. If the project already uses a consistent format, **use that same format** — even if it differs from the Livewire v4 defaults below. Only fall back to the v4 defaults (SFC in `resources/views/components/`) when no existing convention is established.

Also check `config/livewire.php` for `make_command.type`, `make_command.emoji`, `component_locations`, and `component_namespaces` overrides, which change the default format and where files are stored.

### Component Format Reference

| Format | Flag | Class Path | View Path |
|--------|------|------------|-----------|
| Single-file (SFC) | default | — | `resources/views/components/⚡create-post.blade.php` (PHP + Blade in one file) |
| Full Page SFC | `pages::name` | — | `resources/views/pages/⚡create-post.blade.php` |
| Multi-file (MFC) | `--mfc` | `resources/views/components/⚡create-post/create-post.php` | `resources/views/components/⚡create-post/create-post.blade.php` |
| Class-based | `--class` | `app/Livewire/CreatePost.php` | `resources/views/livewire/create-post.blade.php` |
| View-based | default (Blade-only) | — | `resources/views/components/⚡create-post.blade.php` (Blade-only with functional state) |

> **Important:** The ⚡ prefix shown above is the **default** behavior in Livewire v4 — it is **configurable**. Check `config/livewire.php` for the `make_command.emoji` setting. When `true` (default), always include the ⚡ prefix in filenames you create. When `false`, omit the ⚡ prefix from all paths above.

Namespaced components map to subdirectories: `make:livewire Posts/CreatePost` creates `resources/views/components/posts/⚡create-post.blade.php` (single-file by default). Use `make:livewire Posts/CreatePost --mfc` for multi-file output at `resources/views/components/posts/⚡create-post/create-post.php` and `resources/views/components/posts/⚡create-post/create-post.blade.php`.

### Single-File Component Example

<!-- Single-File Component Example -->
```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>
```

## 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 (e.g., `Route::livewire('/posts/create', CreatePost::class)`); 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

<!-- Testing Example -->
```php
Livewire::test(Counter::class)
    ->assertSet('count', 0)
    ->call('increment')
    ->assertSet('count', 1);
```

## 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)


output:
Chunk ID: 9a77cd
Wall time: 0.0000 seconds
Process exited with code 0
Original token count: 675
Output:
---
name: fluxui-development
description: "Use this skill for Flux UI development in Livewire applications only. Trigger when working with <flux:*> components, building or customizing Livewire component UIs, creating forms, modals, tables, or other interactive elements. Covers: flux: components (buttons, inputs, modals, forms, tables, date-pickers, kanban, badges, tooltips, etc.), component composition, Tailwind CSS styling, Heroicons/Lucide icon integration, validation patterns, responsive design, and theming. Do not use for non-Livewire frameworks or non-component styling."
license: MIT
metadata:
  author: laravel
---

# Flux UI Development

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

<!-- Basic Button -->
```blade
<flux:button variant="primary">Click me</flux:button>
```

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

## Icons

Flux includes [Heroicons](https://heroicons.com/) as its default icon set. Search for exact icon names on the Heroicons site - do not guess or invent icon names.

<!-- Icon Button -->
```blade
<flux:button icon="arrow-down-tray">Export</flux:button>
```

For icons not available in Heroicons, use [Lucide](https://lucide.dev/). Import the icons you need with the Artisan command:

```bash
php artisan flux:icon crown grip-vertical github
```

## Common Patterns

### Form Fields

<!-- Form Field -->
```blade
<flux:field>
    <flux:label>Email</flux:label>
    <flux:input type="email" wire:model="email" />
    <flux:error name="email" />
</flux:field>
```

### Modals

<!-- Modal -->
```blade
<flux:modal wire:model="showModal">
    <flux:heading>Title</flux:heading>
    <p>Content</p>
</flux:modal>
```

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


output:
Chunk ID: fbd09b
Wall time: 0.0000 seconds
Process exited with code 0
Original token count: 962
Output:
---
name: tailwindcss-development
description: "Always invoke when the user's message includes 'tailwind' in any form. Also invoke for: building responsive grid layouts (multi-column card grids, product grids), flex/grid page structures (dashboards with sidebars, fixed topbars, mobile-toggle navs), styling UI components (cards, tables, navbars, pricing sections, forms, inputs, badges), adding dark mode variants, fixing spacing or typography, and Tailwind v3/v4 work. The core use case: writing or fixing Tailwind utility classes in HTML templates (Blade, JSX, Vue). Skip for backend PHP logic, database queries, API routes, JavaScript with no HTML/CSS component, CSS file audits, build tool configuration, and vanilla CSS."
license: MIT
metadata:
  author: laravel
---

# Tailwind CSS Development

## Documentation

Use `search-docs` for detailed Tailwind CSS v4 patterns and documentation.

## Basic Usage

- Use Tailwind CSS classes to style HTML. Check and follow existing Tailwind conventions in the project before introducing new patterns.
- Offer to extract repeated patterns into components that match the project's conventions (e.g., Blade, JSX, Vue).
- Consider class placement, order, priority, and defaults. Remove redundant classes, add classes to parent or child elements carefully to reduce repetition, and group elements logically.

## Tailwind CSS v4 Specifics

- Always use Tailwind CSS v4 and avoid deprecated utilities.
- `corePlugins` is not supported in Tailwind v4.

### CSS-First Configuration

In Tailwind v4, configuration is CSS-first using the `@theme` directive — no separate `tailwind.config.js` file is needed:

<!-- CSS-First Config -->
```css
@theme {
  --color-brand: oklch(0.72 0.11 178);
}
```

### Import Syntax

In Tailwind v4, import Tailwind with a regular CSS `@import` statement instead of the `@tailwind` directives used in v3:

<!-- v4 Import Syntax -->
```diff
- @tailwind base;
- @tailwind components;
- @tailwind utilities;
+ @import "tailwindcss";
```

### Replaced Utilities

Tailwind v4 removed deprecated utilities. Use the replacements shown below. Opacity values remain 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 |

## Spacing

Use `gap` utilities instead of margins for spacing between siblings:

<!-- Gap Utilities -->
```html
<div class="flex gap-8">
    <div>Item 1</div>
    <div>Item 2</div>
</div>
```

## Dark Mode

If existing pages and components support dark mode, new pages and components must support it the same way, typically using the `dark:` variant:

<!-- Dark Mode -->
```html
<div class="bg-white dark:bg-gray-900 text-gray-900 dark:text-white">
    Content adapts to color scheme
</div>
```

## Common Patterns

### Flexbox Layout

<!-- Flexbox Layout -->
```html
<div class="flex items-center justify-between gap-4">
    <div>Left content</div>
    <div>Right content</div>
</div>
```

### Grid Layout

<!-- Grid Layout -->
```html
<div class="grid grid-cols-1 md:grid-cols-2 lg:grid-cols-3 gap-6">
    <div>Card 1</div>
    <div>Card 2</div>
    <div>Card 3</div>
</div>
```

## Common Pitfalls

- Using deprecated v3 utilities (bg-opacity-*, flex-shrink-*, etc.)
- Using `@tailwind` directives instead of `@import "tailwindcss"`
- Trying to use `tailwind.config.js` instead of CSS `@theme` directive
- Using margins for spacing between siblings instead of gap utilities
- Forgetting to add dark mode variants when the project uses dark mode


command:
/bin/zsh
-lc
git status --short

cmd: git status --short


output:
Chunk ID: f90e7a
Wall time: 0.0000 seconds
Process exited with code 0
Original token count: 0
Output:


message: Using Livewire, Flux UI, Tailwind, Laravel best-practices, and Pest skills for this UI/service test slice. I’m reading the existing cart component/view and pricing services so the estimate and discount controls reuse the current checkout logic instead of inventing a second pricing path.


text: Using Livewire, Flux UI, Tailwind, Laravel best-practices, and Pest skills for this UI/service test slice. I’m reading the existing cart component/view and pricing services so the estimate and discount controls reuse the current checkout logic instead of inventing a second pricing path.


cmd: sed -n '1,260p' app/Livewire/Storefront/Cart/Show.php


cmd: sed -n '1,320p' resources/views/livewire/storefront/cart/show.blade.php


cmd: sed -n '1,340p' app/Livewire/Storefront/Checkout/Show.php


cmd: sed -n '1,300p' resources/views/livewire/storefront/cart-drawer.blade.php


cmd: sed -n '1,240p' tests/Feature/Storefront/CartCheckoutUiTest.php