chore(deps): bump googleapis/release-please-action from 4 to 5

.claude/skills/hyva-alpine-component

@@ -0,0 +1 @@
+/Users/willem/hyva-ai-tools/skills/hyva-alpine-component

.claude/skills/hyva-internal-coding-standard

@@ -0,0 +1 @@
+/Users/willem/hyva-internal-skills/skills/hyva-internal-coding-standard

.claude/skills/hyva-internal-skill-security-review

@@ -0,0 +1 @@
+/Users/willem/hyva-internal-skills/skills/hyva-internal-skill-security-review

.claude/skills/hyva-playwright-test

@@ -0,0 +1 @@
+/Users/willem/hyva-ai-tools/skills/hyva-playwright-test

.claude/skills/magewire-backwards-compatibility/SKILL.md

@@ -0,0 +1,183 @@
+---
+name: magewire-backwards-compatibility
+description: "Reference for Magewire's framework-level backwards compatibility system. Use when migrating Magewire v1 (Livewire v2) code to v3, enabling BC on components, understanding wire:model / entangle / hook behavioral changes between v2 and v3, or working with the BC memo flag, deprecated v1 component APIs, and the #[HandleBackwardsCompatibility] attribute. Theme-agnostic — BC applies to any Magewire component in any Magento theme. For theme-specific BC JS implementations (e.g. Hyvä Checkout), see the matching theme's BC skill."
+license: MIT
+metadata:
+  author: Willem Poortman
+---
+
+# Magewire Backwards Compatibility
+
+Magewire v3 is built on Livewire v3, which introduced breaking changes from v2. The BC system lets existing v1 components keep working without code changes while providing a migration path to v3 conventions.
+
+Magewire is **not tied to any specific theme**. The BC system is a framework concern — any component, in any theme, can opt into BC. Individual themes may ship their own JS-layer BC implementations on top of this core (see the theme's BC skill for details).
+
+---
+
+## The Two BC Layers
+
+### 1. Core BC (`lib/MagewireBc/`) — theme-agnostic
+
+Framework-level compatibility that applies to all Magewire components regardless of theme.
+
+**PHP trait** — `HandlesComponentBackwardsCompatibility` is mixed into the base `Component` class. It provides deprecated v1 APIs: `$this->id` (public), `getPublicProperties()`, and concerns for Emit, Error, BrowserEvent, and Request. The `Component\Form` base class uses this trait via `HandlesFormComponentBackwardsCompatibility` (a deprecated pass-through that exists for potential form-specific BC, currently empty).
+
+**Feature** — `SupportMagewireBackwardsCompatibility` (sort order 99100):
+- Pushes BC effects into the snapshot during `dehydrate()`: property path mappings (`data` → `$wire`, `__livewire` → `queuedUpdates`) and preferences
+- These effects are read by JS to proxy old property access patterns
+
+### 2. Theme-specific BC layers
+
+Some themes need additional BC on top of core — wire directive rewriting, entangle live-by-default, deprecated JS hook/event re-triggering. Those live in the theme's own module under `themes/{Theme}/` and are documented in that theme's BC skill. The pattern is always the same:
+
+- A theme-scoped Feature manages a `memo.bc.enabled` flag on the snapshot
+- JS templates read the flag and apply migrations to components that have it set
+- The flag is resolvable per-component via the `#[HandleBackwardsCompatibility]` attribute, data store, or theme-defined layout rules
+
+---
+
+## The `memo.bc.enabled` Flag
+
+The BC flag is the single signal a theme's BC JS uses to decide whether to apply v2→v3 shims to a component. Resolution priority:
+
+1. `#[HandleBackwardsCompatibility]` attribute on the component class
+2. Previously hydrated value from the component's data store
+3. Theme-specific defaults (e.g. "all components under layout container X")
+
+On `hydrate()`, the flag is restored from memo into the component's data store. On `dehydrate()`, it is pushed back into the snapshot memo.
+
+---
+
+## Wire Directive Changes (v2 → v3)
+
+| Livewire v2 | Livewire v3 | Behavior |
+|---|---|---|
+| `wire:model` | `wire:model.live` | Syncs on every input change (instant) |
+| `wire:model.defer` | `wire:model` | Syncs on form submit / next request (now the default) |
+| `wire:model.lazy` | `wire:model.blur` | Syncs when the field loses focus |
+
+### Migrating your own code
+
+Remove the old modifiers and use v3 syntax:
+
+```html
+<!-- Before (v1/v2) -->
+<input wire:model="name">              <!-- instant sync -->
+<input wire:model.defer="email">       <!-- deferred -->
+<input wire:model.lazy="phone">        <!-- on blur -->
+
+<!-- After (v3) -->
+<input wire:model.live="name">         <!-- instant sync (opt-in) -->
+<input wire:model="email">             <!-- deferred (now default) -->
+<input wire:model.blur="phone">        <!-- on blur -->
+```
+
+A theme's BC JS may rewrite these directives automatically for components with `memo.bc.enabled` — see that theme's BC skill.
+
+---
+
+## Entangle Changes (v2 → v3)
+
+| Livewire v2 | Livewire v3 |
+|---|---|
+| `$wire.entangle('prop')` — **live** by default | `$wire.entangle('prop')` — **deferred** by default |
+| N/A | `$wire.entangle('prop').live` — opt-in to live |
+
+### Migrating your own code
+
+If you want instant sync (v2 default), add `.live` explicitly:
+
+```javascript
+// Before (v1/v2) — live by default
+couponCode: this.$wire.entangle('couponCode'),
+
+// After (v3) — must opt in to live
+couponCode: this.$wire.entangle('couponCode').live,
+
+// Or keep deferred (v3 default) — no .live needed
+couponCode: this.$wire.entangle('couponCode'),
+```
+
+A theme's BC JS may restore the v2 live-by-default semantic for BC-enabled components via a `$wire` proxy — see that theme's BC skill.
+
+---
+
+## Hook / Event Changes (v2 → v3)
+
+| Deprecated (v2) | Replacement (v3) |
+|---|---|
+| `component.initialized` | `component.init` |
+| `element.initialized` | `element.init` |
+| `element.updating` | `morph.updating` |
+| `element.removed` | `morph.removed` |
+| `message.sent` | `commit` |
+| `message.failed` | `commit` → `fail()` |
+| `message.received` | `commit` → `succeed()` |
+| `message.processed` | `commit` → `succeed()` → `queueMicrotask` |
+
+### Component property aliases
+
+Old property names aliased on the component object by BC JS layers:
+
+```javascript
+// component.deferredActions → component.queuedUpdates
+// component.data → component.$wire
+```
+
+---
+
+## Enabling BC for a Component
+
+### Explicit via PHP attribute
+
+```php
+use Magewirephp\Magewire\Features\SupportMagewireBackwardsCompatibility\HandleBackwardsCompatibility;
+
+#[HandleBackwardsCompatibility]
+class MyLegacyComponent extends Component
+{
+    // This component gets BC behavior
+}
+
+#[HandleBackwardsCompatibility(enabled: false)]
+class MyModernComponent extends Component
+{
+    // Explicitly opt out, even if a theme would normally enable it
+}
+```
+
+### Via data store (programmatic)
+
+```php
+use function Magewirephp\Magewire\store;
+
+// In a Feature or hook:
+store($component)->set('bc.enabled', true);
+```
+
+### Via theme defaults
+
+A theme can decide to BC-enable components automatically based on its own rules (e.g. layout container membership). See the target theme's BC skill.
+
+---
+
+## Key Files
+
+| File | Purpose |
+|------|---------|
+| `lib/MagewireBc/Features/SupportMagewireBackwardsCompatibility/SupportMagewireBackwardsCompatibility.php` | Core BC feature — pushes path mappings into effects |
+| `lib/MagewireBc/Features/SupportMagewireBackwardsCompatibility/HandleBackwardsCompatibility.php` | PHP attribute for explicit BC opt-in/out |
+| `lib/MagewireBc/Features/SupportMagewireBackwardsCompatibility/HandlesComponentBackwardsCompatibility.php` | Trait with deprecated v1 component APIs |
+
+---
+
+## Migration Checklist
+
+When upgrading a v1 component to v3:
+
+1. **wire:model** — replace `wire:model` with `wire:model.live` if you need instant sync, remove `.defer` (it's now the default), replace `.lazy` with `.blur`
+2. **entangle** — add `.live` if you need instant sync, otherwise leave as-is (deferred is now default)
+3. **JS hooks** — replace deprecated event names (see table above)
+4. **Component properties** — replace `component.data` with `component.$wire`, `component.deferredActions` with `component.queuedUpdates`
+5. **PHP APIs** — replace `$this->getPublicProperties()` with `$this->all()`, avoid public `$this->id` (use `$this->id()` or `$this->getId()`)
+6. **Remove BC attribute** — once migrated, remove `#[HandleBackwardsCompatibility]` if present

.claude/skills/magewire-best-practices/SKILL.md

@@ -0,0 +1,140 @@
+---
+name: magewire-best-practices
+description: "Use when writing, reviewing, or refactoring Magewire code for Magento 2 — components, PHTML templates, layout XML, DI configuration, Features, Mechanisms, synthesizers, lifecycle hooks, event handling, and JavaScript integration. Trigger phrases include: component design, property handling, security patterns, template rendering, DI registration, snapshot serialization, state management, architectural decisions. Also use for Magewire code reviews and refactoring. Covers any task involving Magewire PHP or JS patterns within Magento 2."
+requires: magewire, magewire-architecture, magewire-javascript
+license: MIT
+metadata:
+  author: Willem Poortman
+---
+
+# Magewire Best Practices
+
+Best practices for Magewire development in Magento 2, prioritized by impact. Each rule teaches what to do and why. For deeper API reference, load the `magewire`, `magewire-architecture`, or `magewire-javascript` skills.
+
+## Consistency First
+
+Before applying any rule, check what the codebase already does. Magewire bridges two ecosystems — Magento and Livewire — and both offer multiple valid approaches. The best choice is the one the codebase already uses, even if another pattern would be theoretically better. Inconsistency is worse than a suboptimal pattern.
+
+Check sibling components, related Features, existing DI config, and neighboring templates for established patterns. If one exists, follow it — don't introduce a second way. These rules are defaults for when no pattern exists yet, not overrides.
+
+## Quick Reference
+
+### 1. Component Design → `references/components.md`
+
+- Extend `Magewirephp\Magewire\Component`, not Magento block classes
+- Keep public properties serializable — scalars, arrays, or types with a registered synthesizer
+- Use typed properties with defaults — uninitialized properties break snapshot serialization
+- Small, focused components — split large components into parent-child
+- Never query the database in the constructor — use `mount()` for initialization
+- Use `$this->skipRender()` when a method only changes state without needing a re-render
+
+### 2. Properties & State → `references/properties.md`
+
+- Scalar types and arrays for public properties — complex objects need synthesizers
+- `wire:model` for form binding, `wire:model.live` only when instant feedback is required
+- `fill()` accepts arrays and DataObjects — use it for bulk property assignment
+- `reset()` and `resetExcept()` to restore initial state cleanly
+- Dot notation (`address.city`) for nested array/object properties
+- Never store sensitive data (passwords, tokens) in public properties — they travel to the client
+
+### 3. Lifecycle Hooks → `references/lifecycle.md`
+
+- `mount()` for initial setup — runs once, receives layout XML arguments
+- `boot()` / `booted()` for every-request setup — use for authorization checks
+- `hydrate()` / `dehydrate()` for request boundary logic, not business logic
+- `updating()` / `updated()` for validation and side effects on property changes
+- Property-specific hooks (`updatingName`, `updatedName`) over generic hooks when targeting one property
+- Never call `$this->render()` manually — the framework handles the render cycle
+
+### 4. Templates & Views → `references/templates.md`
+
+- Single root element required in every component template
+- `$magewire` is the component instance — access properties and methods directly
+- `$escaper->escapeHtml()`, `$escaper->escapeUrl()`, `$escaper->escapeJs()` for all dynamic output
+- `$block->getChildHtml()` for nested Magento blocks inside a Magewire template
+- Never echo raw user input — use Magento's escaper, not PHP's `htmlspecialchars()`
+- Keep templates thin — logic belongs in the component class, not in PHTML
+
+### 5. Layout XML & Block Registration → `references/layout.md`
+
+- Component class goes in `<argument name="magewire">` — Magewire can be bound to any block class
+- Use `name` attribute for unique block identification — Magento merges by name
+- Template path uses module notation: `Vendor_Module::template.phtml`
+- Register blocks within the page layout handle where they're needed, not globally
+
+### 6. Dependency Injection → `references/di.md`
+
+- Features and Mechanisms in area-scoped DI only (`etc/frontend/di.xml`, `etc/adminhtml/di.xml`) — never global `etc/di.xml`
+- Sort order determines boot sequence — check existing registrations before choosing a number
+- Use `boot_mode` to control when a service boots: `10` (lazy), `20` (persistent), `30` (always, default)
+- Constructor injection via Magento DI for component dependencies — not `ObjectManager::getInstance()`
+- Virtual types for DI-only variations — don't create empty subclasses
+
+### 7. Security → `references/security.md`
+
+- CSRF is automatic — Magewire uses Magento's FormKey, no manual token handling needed
+- Snapshot checksums prevent state tampering — never bypass checksum validation
+- Escape all output in templates — `$escaper->escapeHtml()` is the default, use specific escapers for URLs, JS, attributes
+- Public methods are callable from the frontend — never expose admin actions or destructive operations without authorization
+- Public properties are visible to the client — never store secrets, API keys, or session data
+- Rate limiting is handled by the `SupportMagewireRateLimiting` feature via configuration, not attributes
+
+### 8. Events & Communication → `references/events.md`
+
+- `$this->dispatch('event-name')` for cross-component communication
+- `#[On('event-name')]` attribute for declarative listeners — preferred over `$listeners` array
+- `->self()` to scope events to the dispatching component only
+- `->up()` to dispatch to the parent component
+- Kebab-case event names (`cart-updated`, not `cartUpdated`)
+- Don't use events for parent-to-child — pass data via layout XML arguments or properties
+
+### 9. JavaScript Integration → `references/javascript.md`
+
+- CSP-compatible scripts only — use `$magewireFragment->make()->script()->start()/end()`, never raw `<script>` tags
+- `magewire:init` for Magewire hooks, `alpine:init` for Alpine registrations, `magewire:initialized` for directives
+- Always `{ once: true }` on registration event listeners to prevent double registration
+- Access addons via `window.MagewireAddons`, utilities via `window.MagewireUtilities`
+- Guard addon access with `addons.has('name')` — addons are optional
+- Never depend on `window.Magewire` at registration time — it may not exist yet
+
+### 10. Features & Extensions → `references/features.md`
+
+- Extend `ComponentHook` for lifecycle-based extensions — implement only the hooks you need
+- `SupportMagewire*` prefix for Magewire-specific features, `SupportMagento*` for Magento bridge features
+- Feature-owned JS/templates live in the feature's folder, not in global `addons/` or `components/`
+- Use `storeSet()` / `storeGet()` for component-scoped feature state — not class properties
+- Push side effects via `$context->pushEffect()` during `dehydrate()` — never echo output from features
+- Facades for public APIs — register with `facade` key in DI config
+
+### 11. Performance → `references/performance.md`
+
+- `$this->skipRender()` when a method call doesn't need to update the DOM
+- Avoid `wire:model.live` on high-frequency inputs — use `wire:model.blur` or debounce
+- Minimize public properties — every property is serialized on every request
+- Lazy-load heavy dependencies — use `boot_mode: 10` for features not always needed
+- `wire:loading` for user feedback instead of polling or repeated requests
+
+### 12. Serialization & Synthesizers → `references/synthesizers.md`
+
+- Built-in synthesizers handle: arrays, stdClass, enums, floats, ints, DataObjects
+- Custom synthesizers for unsupported types — implement `match()`, `dehydrate()`, `hydrate()`
+- Register synthesizers in area-scoped DI with a sort order — first match wins
+- `dehydrate()` must return JSON-safe data — no objects, no resources
+- Test round-trip serialization: `hydrate(dehydrate($value))` must produce the original value
+- Avoid storing Magento models directly — extract needed data into scalar properties
+
+### 13. Conventions & Style → `references/style.md`
+
+- Component classes in `Vendor\Module\Magewire\` namespace — not in `Block\`, `Model\`, or `Controller\`
+- One component class per file, named after the component
+- `snake_case` for layout XML block names: `checkout.shipping.address`
+- `kebab-case` for event names and wire directives: `cart-updated`, `wire:click`
+- `PascalCase` for component class names, `camelCase` for methods and properties
+- Template files match the component purpose, not the class name: `shipping-address.phtml`, not `ShippingAddress.phtml`
+- Feature classes always prefixed with `Support`: `SupportMyFeature`
+
+## How to Apply
+
+1. Identify the file type and select relevant sections (e.g., component → 1, 2, 3; template → 4, 7; DI config → 6; JS → 9)
+2. Check sibling files for existing patterns — follow those first per Consistency First
+3. For API syntax, load the `magewire` skill for component API or `magewire-architecture` for internals