Ecommerce Admin Livewire Laravel Package

Technical Evaluation

Architecture fit. This package is an admin presentation layer, not commerce core: it sits on top of ArtisanPack UI's ecommerce engine, renders through Livewire, and borrows layout, menu, and RBAC from cms-framework. That separation is the right shape for a TPM — commerce rules, pricing, stock, and refunds stay in the engine (single source of truth), while the admin UI is replaceable and extensible. The registry/filter extension points (navigation, dashboard widgets, palette providers, order and product panels, customer tabs, settings tabs, table columns/filters/bulk actions) are the main product lever: they let us add merchant-specific screens without forking, which materially lowers long-term ownership cost. The command palette, order edit/rollback with totals diff, and refund model (per-line or by amount, pending refunds reserving capacity, "Refunded" gated on actual payment refund) are the features that will drive merchant adoption and reduce support load.

Integration feasibility. Feasible for a team already on Laravel 12/13 with Livewire and the engine. The ecommerce-admin:install command covers config publishing, front-end steps, access checks, and notification templates, which shortens the first-week path. RBAC is delegated to the engine's ability catalog via ecommerce:sync-permissions, with shop-manager provided — good, because it avoids a parallel permission model. The ecommerce-admin:sync-permissions deprecated alias gives a bridge for any existing scripts. Hard prerequisites: engine 1.0, cms-framework, and a Livewire version; rebing/graphql-laravel is only suggested and gates real-time Echo updates.

Technical risk. Moderate. The package is stable-labeled but the surrounding matrix (engine 1.0, Laravel 12/13, Livewire 3.6+ or 4) is young, so version drift is the main risk, not code quality. Deep coupling to engine internals — DescribesConfig schemas, ability catalog, default warehouse, table prefix, currency and refund-limit sources — means any engine patch can ripple into admin behavior. Real-time is optional and silently degrades to polling when GraphQL/Echo is absent; that is a support-desk surprise waiting to happen if it is not communicated. Positives: MIT license, CSP nonce on inline scripts, admin middleware enforced on every Livewire update, mutation-only rate limiting, webhook secret removed from public component state, capped picker caches/selections/import reports, and an axe check plus Pest/Playwright suite per screen.

Key questions.

1. Is engine 1.0 GA with a published support window, and what is the engine's own BC policy across 1.x?
2. Do we need real-time? If yes, who owns the GraphQL + Echo infrastructure (it is a separate dependency, not bundled)?
3. What is the support arrangement — community MIT or a commercial agreement with ArtisanPack for the engine/cms-framework?
4. Is Livewire 4 supported at parity with 3.6, or should we pin to 3.x for the first deployment?
5. What are the tested ceilings — SKU count, order volume, CSV import size, concurrent admin sessions?
6. Is the axe/browser suite representative enough for a WCAG 2.2 AA procurement claim, or is an external audit still required?
7. How stable are the extension-point contracts across minor releases (registries, filters, DescribesConfig)?

Integration Approach

Stack fit. Strong if the platform is Laravel + Livewire + the ArtisanPack engine and cms-framework is already present for layout, menu, and permissions. Weak if the organization is SPA-first (React/Vue) or runs a different commerce core; the package is not a headless admin API and should not be treated as one. For a modular monolith, this is close to ideal: it inherits the host app's auth, middleware, rate limiter, and CSP rather than inventing its own.

Migration path. Treat it as a greenfield admin surface rather than a data migration. Install into a staging app on engine 1.0, run ecommerce-admin:install, then run ecommerce:sync-permissions against the engine's ability catalog and assign shop-manager to pilot users. Configure the admin middleware group (2fa, verified) before exposing anything. If real-time dashboard/order updates are in scope, provision GraphQL and Echo in the same wave; otherwise document polling behavior for merchants. There are no visible destructive changes in v1.0.0, and the deprecated permission-sync alias means existing bootstrap scripts do not break on day one.

Compatibility. Pin the matrix explicitly: engine 1.0.x, Laravel 12 (or 13 once proven), Livewire 3.6.x initially, cms-framework at the version the engine requires. Confirm the engine's ecommerce_ table prefix is in use so the qualified-column work is actually exercised. Verify the default warehouse is configured, since stock reads/writes and inventory adjustments depend on it. Add ecommerce-admin:prune-imports to the scheduler at install time rather than later.

Sequencing.

1. Engine 1.0 upgrade/validation and cms-framework alignment.
2. Staging install of the admin package; config publish and front-end build steps.
3. Permission sync, shop-manager role assignment, and admin middleware hardening.
4. Rate limiter tuning for ecommerce.admin.mutate against expected bulk-edit volume.
5. Notification templates (Twig, locales, test sends), webhooks, and delivery-log replay validation.
6. Catalog CSV import dry run on a production-sized sample; export parity check.
7. Accessibility pass: automated axe plus manual keyboard sweep (sortable reordering, focus return, error summaries).
8. Pilot with two to three store managers; measure task time on orders, refunds, and promotions before broad rollout.

Operational Impact

Maintenance. MIT keeps licensing simple, but we inherit a fast-moving dependency chain (Laravel annual majors, Livewire 3→4, engine 1.x, cms-framework). Budget a recurring upgrade slot each Laravel/Livewire cycle and treat the admin package as version-locked to the engine. Custom work should go through registries and filters, not overrides, or upgrade cost will compound.

Support. Determine early whether support is community-only or contracted. The high-touch areas will be refunds (line vs amount, pending-refund accounting), order edits with rollback, and CSV import failures — all of which have merchant-visible money implications. Document the "real-time is off without GraphQL" behavior in the merchant-facing runbook.

Scaling. Imports are queued and resumable, caches and row selections are capped, and mutations are rate-limited — sensible defaults. Watch three seams: dashboard polling load with many concurrent admins, Echo fan-out if real-time is enabled for large order volumes, and bulk actions, which now check per-record permission and skip silently, so operators may need clearer feedback on partial success.

Failure modes. (a) Permission drift after an engine upgrade renames abilities → screens 403 silently; mitigate by running ecommerce:sync-permissions in the deploy pipeline. (b) Engine patch changes a DescribesConfig schema → config forms fail validation; smoke-test settings screens post-upgrade. (c) GraphQL/Echo outage → dashboard and orders fall back to polling or appear stale. (d) Import jobs piling up unconsumed → prune command not scheduled. (e) Webhook delivery failures → rely on the delivery log and replay, and confirm the new secret-handling behavior in the component state. (f) Rate limiter rejecting legitimate bulk edits during peak ops.

Ramp-up. Favorable: command palette (Cmd+K) cuts navigation time, the rule builder with plain-language summaries lowers promotions training, and four locales (EN/ES/FR/DE) cover most first-wave markets. Accessibility work (keyboard reordering with announcements, error summaries, table captions and sort state, live regions, unsaved-changes warnings) reduces accommodation requests and is a credible procurement talking point, though automated axe coverage should be paired with a manual audit before any formal AA claim. Plan a short merchant enablement session focused on refunds, order edits/rollback, and import dry runs — those are where mistakes cost money.