Admin Bundle Laravel Package

Product Decisions This Supports

• Do not treat this as a Laravel dependency decision — the metadata is wrong. The package is described as a "Laravel admin panel scaffold," but the repository is rzproject/AdminBundle, a Symfony 2.x bundle that extends SonataAdminBundle. There is no service provider, no config/admin.php, no Artisan surface. A PM should record this as a catalog/data-quality finding, not a build-vs-buy finding: package descriptions and "opportunity scores" in this catalog cannot be trusted as a proxy for fit.
• Build vs. buy: this is neither — it is "reference only." Zero stars, zero dependents, archived, composite score 0.03. A 6.81 opportunity score here reflects ecosystem whitespace (Laravel/Symfony teams do want bundled admin scaffolding), not package quality or adoption. Whitespace without a maintained artifact is a roadmap signal, not a procurement option.
• Roadmap input: standardize the admin layer instead of bundling it per project. The genuine product lesson from this artifact is that admin surfaces (routing, CRUD generators, layouts, auth hooks) are a recurring, well-understood need. The right response is to pick one maintained admin framework — Filament, Laravel Nova, or Backpack for Laravel; SonataAdmin or EasyAdmin for Symfony — and keep admin code behind internal interfaces so the choice stays reversible.
• Reference use case it does support: a 1–2 day spike to read the entity/CRUD abstractions, resource registration patterns, and admin UX layout, and extract design ideas before discarding the code. That is the only defensible PM-approved use.
• Use cases it does NOT support: greenfield admin panels, multi-tenant SaaS back offices, API-first products, regulated-data back offices, or anything requiring security maintenance or PHP 8.x/framework currency.
• Do not let the catalog score drive a spike. Any "opportunity" ranking that surfaces a 0-star, archived, framework-mismatched bundle at 6.81 needs a scoring guardrail before it reaches a roadmap review.

When to Consider This Package

Consider only if all of the following hold:

• You are actively maintaining a legacy RZ Project CMS / SonataAdminBundle deployment and need to preserve its admin surface during a migration window.
• You accept the Symfony framework coupling end to end; nothing in a Laravel application can consume this without becoming a fork.
• You need a read-only reference — reading controllers, config trees, and Twig layouts to port behavior — and will not add it to a manifest.
• The work is timeboxed (≤2 days) and has a named owner who writes down what was learned.

Look elsewhere if any of the following is true:

• Your stack is Laravel. This is a framework mismatch, not a version mismatch. Shortlist Filament, Nova, Backpack, or Voyager.
• You need security patches. The repo is archived — no CVE response, no dependency updates, no maintainer. An admin bundle is the highest-privilege surface in the app: auth-adjacent routing, CRUD over arbitrary entities, file handling. Shipping it unmaintained is a standing audit finding.
• You need community support. 0 stars / 0 dependents means no issue triage, no forks to inherit maintenance from, no Stack Overflow corpus, no prior art to debug against.
• You need performance evidence. With no dependents, there is no data on list-view pagination, query generation, or media handling under load. Your team would be the first to discover each ceiling — in production.
• You are assembling a "buy" shortlist. Neither this artifact nor the RZ Project family belongs on one.

Decision rule: classify this as a deprecated artifact. Adoption requires a written exception that explicitly justifies framework mismatch, archived status, zero adoption, and a named fork owner with an engineer-week budget. Absent that, decline.

How to Pitch It (Stakeholders)

For executives: This is an archived Symfony component from a niche CMS with no users, no maintainers, and no security updates — and it is mislabeled in our catalog as a Laravel package. It is not a viable foundation for anything we ship. The "opportunity score" of 6.81 measures ecosystem whitespace, not package quality; it should be read as "teams want admin scaffolding," not "use this." The strategic takeaway is a decision we should make anyway: pick one maintained admin framework and standardize.

For engineering: Do not add rz/admin-bundle to any Laravel manifest — expect composer require to fail on framework-generation constraints before you reach a runtime error, and do not pin around it, because pinning an abandoned admin bundle drags the whole application onto an EOL runtime. If a team needs admin functionality, we standardize on Filament for Laravel (EasyAdmin/SonataAdmin for Symfony) and keep admin code behind our own interfaces so the choice stays reversible. If RZ Project migration work surfaces, scope it as a one-time port with a hard timebox — never an ongoing dependency.

The ask (three concrete decisions):

1. Confirm no team has this in a composer.json or composer.lock.
2. Add to the "do not adopt" list with a one-line rationale: archived, Symfony-not-Laravel, zero adoption, no security path.
3. Sponsor the real decision this artifact points at: approve one maintained admin framework as the house standard, plus a lightweight scoring guardrail so 0-star archived packages stop surfacing as opportunities in roadmap reviews.