Panel Bundle Laravel Package

Technical Evaluation

Architecture fit. This is a Symfony bundle, not a Laravel package — the single most important fact for the evaluation. novosga/panel-bundle is the administrative/attendant panel layer of the NovoSGA queue-management system: the surface where services, priority rules, units, attendants and roles are configured, and where tickets and attendance are monitored. It assumes the NovoSGA core schema, its Doctrine entities, its authentication model, and Symfony's service container, routing and Twig pipeline. Nothing in it maps onto Eloquent, service providers, facades, Blade or config/*.php. For a Laravel codebase the only realistic architecture is a sidecar service: run NovoSGA + the panel as its own Composer root or container, and integrate over HTTP and a shared session boundary. That is a service-integration decision, and it belongs in the design record before anyone writes code.

Integration feasibility. Feasible but non-trivial, and the cost sits in seams rather than in the bundle itself. Three seams matter: (1) Auth — the panel has its own attendant records (usuario); syncing from Laravel on user create/update, or fronting both apps with a shared cookie domain and reverse proxy, is the work. (2) Ticket issuance — Laravel should call a thin client (NovosgaClient behind an interface, configured base URI, timeout, retry, fakeable in tests) rather than reaching into the panel's database. (3) Read models — poll queue state into local tables on a schedule instead of joining across to the NovoSGA schema, so your migrations stay independent of the bundle's. Each is a known pattern; none is a drop-in.

Technical risk. Elevated, and mostly evidence risk rather than code risk. Zero stars and zero dependents means no observable production adoption to learn from; there is no commercial support, no published security policy, no LTS or deprecation commitment. v2.3.0 shipped with release notes that are nothing but a link to the commit history — no itemised features, fixes, breaking changes or migration notes — so the release must be treated as unverified until someone reads the diff. The highest-likelihood silent break is the Twig/theme override layer, which is precisely where panel bundles get customised. Composer constraint collisions between the bundle's symfony/* pins and Laravel's are real; separate Composer roots dissolve them permanently.

Key questions to close before committing:

• Do our queue semantics (multi-unit, multi-service, priority weighting, counter assignment) actually match the NovoSGA domain model closely enough that configuration beats custom modelling?
• Who owns the ticket record of truth — our Laravel app or the panel? Answer this before the schema is touched.
• Will the panel run as a separate service in our infrastructure, and who on-call owns it when it pages?
• Has anyone read the v2.2.x → v2.3.0 diff for constructor signatures, container aliases, config keys, template changes and new Doctrine migrations?
• What is our exit plan if the project stalls — is the data portable, or are we locked into its schema?

Integration Approach

Stack fit. Poor as a library, acceptable as a service. There is no service provider, no vendor:publish, no Blade, no facades. If the requirement is "admin UI sharing our Eloquent models, guards and policies," a Filament/Livewire panel over the existing schema is cheaper to own and far easier to hire for. Adopt this only if the NovoSGA domain model is a genuine fit and we are willing to operate a second runtime.

Migration path. Greenfield, effectively — there is no incremental path from a Laravel admin panel into this one, and no path back out other than reimplementation. Sequence it as: standalone spike (official Docker image or its own Composer root) → prove the one seam that matters → decide. The proof point is concrete: log in as an attendant, pull a ticket from the queue, and confirm a ticket created by our Laravel app appears in the panel. If that round-trip works, the rest is configuration and plumbing.

Compatibility. Verify before touching composer.json: the php constraint, the symfony/* pins, and the novosga/core-bundle pin on the v2.3.0 tag. The panel expects the NovoSGA core schema to exist and be migrated; running it against a half-initialised database produces template and repository errors that look like panel bugs and are not. Pin the exact tag (2.3.0, not ^2.3) until the diff has been read. Do not attempt to install it into the Laravel composer.json — that is where most of an afternoon disappears.

Sequencing.

1. Time-boxed spike of the standalone panel; validate domain-model fit against real service-desk scenarios.
2. Read the v2.3.0 diff; classify the release as verified or unverified and record it.
3. Decide ticket ownership and write it down.
4. Build the NovosgaClient boundary (interface, timeout, retry, test fake) — no direct calls from controllers.
5. Implement user sync (scheduled job or listener on user create/update); do not duplicate user tables.
6. Stand up the auth/session seam: shared cookie domain and reverse proxy, or an authenticated forwarded session. Confirm framework.session, cookie SameSite, and X-Forwarded-* handling.
7. Add scheduled read-model polling for any queue data Laravel needs for dashboards or notifications.
8. Keep Twig overrides in a small, version-pinned overlay directory with a documented list of what is overridden.

Operational Impact

Maintenance. We own this dependency outright: no SLA, no security policy, no deprecation commitments, no visible maintainer bench. Budget a review per release — diff the changelog, re-check the symfony/* and core-bundle pins, run the panel's own login and ticket flow, then bump the pinned tag on a branch. The override surface is the recurring cost: every Twig template we customise is a place a minor bump can break silently, so keep overrides few, listed and version-pinned.

Support. Community-only. Debugging happens in the Symfony profiler and var/log/dev.log inside the panel root — not storage/logs/laravel.log. A blank panel page is almost always a Twig render exception logged there. This is a real ramp-up cost for a Laravel-shaped team and should be reflected in on-call expectations, not discovered during the first incident.

Scaling. The panel is a UI layer over the NovoSGA core; scaling characteristics are those of that stack and its database, not of this bundle. It is stateless enough to run behind a load balancer with a shared database and shared session store. Our side scales independently as long as the HTTP calls to it have timeouts, retries and circuit-breaking — an unbounded synchronous call from a Laravel request path into the panel is the anti-pattern to design out early.

Failure modes to plan for.

• Silent template break on upgrade — mitigated by pinned tags, a small override surface, and a smoke test in the panel's own test flow before promotion.
• Composer constraint collision — avoided structurally by separate Composer roots.
• Cross-app auth failure — presents as login loops or anonymous sessions; check session domain, cookie SameSite, and proxy X-Forwarded-* before debugging auth code.
• Inconsistent or partially migrated schema — confusing repository/template errors; enforce a migration gate in deployment.
• Unverified release — a minor bump that is only "probably" non-breaking is not an upgrade plan; treat it as a branch-and-verify task each time.
• Bus factor — no dependents and no visible commercial backing means the project could go quiet; keep the integration boundary narrow enough to replace.

Ramp-up. Two distinct curves. Laravel engineers need Symfony fluency — bundles, the container, Twig, Doctrine migrations, the profiler — before they can debug this confidently; estimate weeks, not days, and plan for it explicitly. The NovoSGA domain itself (units, services, priorities, attendance, counters) is the easier half, since it is business logic rather than framework idiom. Cheapest de-risking move: keep the sidecar boundary so narrow and so well-tested that a replacement panel, or a Filament rebuild, is a client swap rather than a rewrite. Verdict: worth a time-boxed spike if the NovoSGA domain model fits — not a decision to take on the strength of the release notes alone.