Universal Panel Laravel Package

Technical Evaluation

Architecture fit manggala/universal-panel is not a utility library — it is an opinionated application shell that takes ownership of routing, authentication, authorization UI, navigation, and resource scaffolding. That is a strong fit for greenfield internal tools and back-office CRUD on Laravel 10–12, and a poor fit for products with an established admin surface, custom design system, or non-standard auth flow.

The highest-risk architectural decision is the multi-stack renderer abstraction (Blade, Livewire v2/v3, Inertia React, Inertia Vue v2/v3, REST API). An abstraction layered over three different rendering paradigms will tend toward lowest-common-denominator component behavior and will couple your upgrade cadence to every upstream major (Livewire 2→3 and Inertia Vue 2→3 are materially different). Treat blade (the stated default) as the only path we would commit to without a spike.

Integration feasibility Feasible — this is a Composer package with Artisan generators, no infrastructure prerequisites beyond PHP/Laravel and a Vite build. The realistic difficulty is not installation but coexistence: existing auth guards, existing role/permission tables (Spatie or custom), existing layouts and Tailwind config, existing route prefixes. The package's role-based dynamic routing (/superadmin vs /admin) implies it owns guard/redirect logic, which is exactly where conflicts surface.

Technical risk

• Authentication suite is the largest risk. Shipping register / forgot-password / reset-password views is table stakes for a framework and a liability if not hardened. We must independently verify: rate limiting on login and reset, token TTL and single-use semantics, session regeneration on login, email enumeration resistance, CSRF coverage, password policy hooks, and email verification. No MFA is mentioned.
• Permission matrix may be presentation-only. "Visual role-based access control matrix with checkboxes" describes a GUI; it does not evidence server-side enforcement. Until we confirm every resource path runs a policy/gate check, assume the matrix is cosmetic and the authorization boundary is unproven. This is a release blocker for production use.
• Spotlight quick search authorization leakage. Auto-discovering registered CRUD resources and searching them is a classic cross-tenant/cross-role data leak vector. Needs per-resource scoping and authz filtering verified. The "zero third-party dependency" claim is a genuine supply-chain positive.
• Release hygiene signals are inconsistent. universal-panel:doctor is documented as checking "PHP 8.4+", but the compatibility matrix states ^8.2 || ^8.3 || ^8.4. Laravel ^13.0 is also claimed, which is not a verifiable stable target at time of review. Both undermine confidence in the release checklist.
• Surface area. 27 generator commands, exporters, importers, background tasks, themes, and plugins at v1.0.0 implies breadth ahead of maturity. Test coverage, changelog discipline, and backward-compatibility policy are unknown.
• No prior assessment and no supporting data — this evaluation is derived solely from release notes and must be treated as unvalidated vendor claims.

Key questions

1. Does the permission matrix enforce authorization server-side on every generated resource, and where is that code?
2. What is the test suite size/coverage, and is there a published BC policy for 1.x?
3. Who maintains the package — single maintainer or team? Any commercial support or SLA?
4. How are generated migrations and models versioned, and can --generate be run safely against an existing schema?
5. Which Tailwind/Vite version does the published asset pipeline assume, and can it coexist with our build?
6. Is there a documented migration path from an existing role/permission implementation?
7. What is the supported upgrade path for the Livewire/Inertia adapters, and which one is actually maintained?

Integration Approach

Stack fit PHP 8.2–8.4 and Laravel 10–12 align with our current runtime. A Vite build is a hard prerequisite (the doctor command checks compilation health), so any app not already on Vite needs that work sequenced first. Front-end adapter choice should be locked at kickoff — switching adapters later is a rewrite of the panel's views, not a config toggle.

Migration path Install additively and never in-place:

1. Install into a feature branch; run universal-panel:doctor and record the baseline.
2. Mount the panel under an isolated prefix (/admin or a non-guessable path) behind the existing app; do not replace existing login.
3. Stand up one resource end-to-end with make:panel-resource --generate in a scratch environment, then hand-review the generated model and migration before it touches any shared schema. Generated migrations against existing tables is the single most likely way to cause an incident.
4. Map existing roles/permissions into the panel's model explicitly; do not dual-run two RBAC systems longer than one release cycle.
5. Gate the whole panel behind a feature flag and ship to internal users first.

Compatibility Version-matrix risk is concentrated in the optional adapters, not the core. Livewire 2 and Inertia Vue 2 are legacy branches; supporting them costs us upgrade headroom and is where breakage will appear. Assume the theme/sidebar CSS (fixed 160px / 52px collapsed, .no-scrollbar) ships its own stylesheet and may collide with existing Tailwind config — budget time for style isolation.

Sequencing Doctor/baseline → single panel on blade → auth suite security review → one resource with policy enforcement → permission matrix validated against server-side checks → importers/exporters → background tasks (queue + failure handling) → multi-panel role routing → adapter evaluation only if a concrete requirement demands React/Vue.

Operational Impact

Maintenance This becomes a standing dependency with a UI surface we do not control. Expect to vendor or fork specific views once we customize them; upgrades of a young 1.x package will occasionally break customized views under minor version bumps. Assign a named owner and require an upgrade runbook before go-live.

Support No evidence of commercial support, SLA, or a security disclosure process in the release notes. Budget an internal subject-matter owner rather than assuming vendor escalation. Absent a security contact, treat vulnerability response as our responsibility.

Scaling Admin panels are low-concurrency by nature, so request throughput is not the concern. The scaling risks are query-shaped:

• Spotlight search fanning out across every registered resource — needs result caps and per-resource scoping.
• Permission matrix loading all roles × modules on each render — needs caching with explicit invalidation.
• Exporters/importers on large tables — memory ceilings; require chunking or queued jobs.
• Background tasks require a supervised queue worker with retry/dead-letter handling; without it, failures are silent.

Failure modes

• Auth guard collision — panel login breaks session for the main app (or vice versa). Highest-severity, most likely.
• Stale permission cache — either privilege escalation or lockout after a role change.
• Vite build failure takes the entire admin down, not just styling. Doctor must run in CI, not only at runtime.
• Generated migration applied to a shared database — data loss risk; enforce a review gate.
• Multi-panel role routing misconfiguration — redirect loops or users landing in the wrong panel.
• Adapter drift after upgrade — a Livewire/Inertia major bump silently breaks panel views.
• Silent authorization gap — if the permission matrix is UI-only, unauthorized users see permitted-looking controls; server-side checks are the only real control.

Ramp-up A Laravel-fluent engineer should reach a first working resource in roughly one to two days; a full RBAC migration plus auth hardening is a multi-week effort with security review. Investment required: an ADR recording the panel decision, onboarding docs for the fluent Panel::make() API and generator conventions, and a documented "do not run --generate against shared schemas" rule. Recommend a two-week time-boxed spike covering auth hardening, authorization enforcement, and style isolation before any production commitment.