Uranus Laravel Package

Product Decisions This Supports

• Establishing a dependency governance policy (the highest-value output). Uranus is less useful as a package than as the concrete, cheap worked example that justifies a written rule: archived, single-maintainer, zero-adoption OSS does not enter a production dependency tree. Rejecting it explicitly costs almost nothing; codifying the criteria that reject the next twenty packages like it is the real deliverable.
• Framing the build vs. buy decision correctly on admin/back-office modernization. The stated purpose — "convert any admin panel to filamentphp" — maps to a genuine roadmap item if we have legacy admin surfaces to move onto Filament. But with an archived, MIT-licensed package, the honest framing is buy-then-own becomes own-only: any use means forking and maintaining it ourselves. That is a build decision in disguise and should be priced as one — engineering days and a named owner, not a licence cost of zero.
• Protecting the roadmap critical path. This should never sit on a release critical path or gate a delivery date. It supports a decision to run a small, capped spike to harvest an approach — not to schedule a migration on top of it.
• Calibrating our stance on the Lara Zeus ecosystem. Uranus is retired while its siblings are active. That asymmetry is useful data for deciding how much surface area we expose to that ecosystem, and for enforcing version-pinning discipline generally.
• Calibrating documentation trust. The package's headline description ("convert any admin panel to filamentphp") and its boilerplate summary (a generic config-publishing Laravel package) describe two different products, and neither is corroborated by the v1.0.0 release notes, which are an auto-generated commit link. Concrete evidence for the internal argument that README claims are hypotheses, not requirements.

When to Consider This Package

Consider it only when:

• You want a 1–2 day read-only spike on the specific problem of lifting an existing admin panel onto Filament, and you treat the source as a reference implementation, not a dependency.
• You have an internal, low-stakes tool where a future Laravel/Filament major breaking the package is an annoyance rather than an incident — and you are prepared to fork under MIT with a named internal owner.
• You are auditing the Lara Zeus ecosystem and need to separate its maintained packages from its retired ones before standardizing on any of them.
• You are already standardized on the TALL/Filament stack and want prior art on plugin registration, panel scoping, and config-publishing conventions.

Look elsewhere when:

• The target is production, customer-facing, revenue-critical, or regulated. Archived status means no security fixes, no disclosure process, no CVE response, and no compatibility work for future Laravel or Filament majors. Composer constraints will silently rot; composer update will eventually fail, or worse, succeed against an untested combination.
• You expect community support. 15 stars and 0 dependents means essentially no issue corpus, no Stack Overflow answers, no third-party guides. Every debugging hour is ours and unbudgeted.
• You need verified capability. The release notes contain no features, breaking changes, or migrations, and the two available descriptions disagree about what the package even is. Treat every capability claim as unverified until read from source.
• A maintained alternative covers the job — stock Filament panel scaffolding plus a bespoke conversion layer is the obvious baseline to price against.
• The team is Inertia/React/Vue-first or non-Laravel, where the integration cost exceeds any notional saving and adopting this would be a platform decision disguised as a package decision.

Due diligence before any code is written: check composer.json for the php, laravel/framework, and filament/filament constraints and confirm they still resolve against our Filament major; read the commit history to see where development stopped and whether it stopped mid-refactor; scan issues for the failure that preceded archiving; confirm no transitive dependency is itself abandoned; and confirm MIT is compatible with our distribution model.

How to Pitch It (Stakeholders)

For executives — one paragraph: Uranus is a small, MIT-licensed Laravel/Filament package aimed at converting existing admin panels onto Filament. It is archived, has 15 GitHub stars, zero dependent projects, and has not shipped since April 2024, and its release notes contain no feature or breaking-change detail. "Free" is the wrong lens — the real cost is ownership, because an archived package receives no security patches and no compatibility updates, so any use means we fork it and maintain it indefinitely. My recommendation is not to adopt it as a dependency, but to approve a short, capped spike to extract whatever approach is worth copying, and to use it as the worked example when we formalize a "no archived packages in production" rule. Cost of the spike: a couple of engineering days, fully reversible. Cost of skipping the rule: a future incident nobody owns.

For engineering — the ask: Do not composer require this into the main application. Clone it into a sandbox branch and answer four questions: (1) does it install and boot at all against our current PHP/Laravel/Filament versions — yes or no, with the actual error if no; (2) what does it actually do, given that one description says "convert any admin panel to filamentphp" and the other describes a generic config-publishing Laravel package — resolve that contradiction by reading src/ and composer.json; (3) what proportion of its value is a reusable pattern we could reimplement cleanly in a few days versus package-specific plumbing we would carry forever; (4) a build estimate for the reimplementation. Deliver a written recommendation — reimplement, fork, or drop — with the version constraints and the reason development stopped.

The decision I need: approval for a time-boxed spike and for the accompanying dependency policy. Not approval to adopt. The spike is cheap, reversible, and produces the information the release notes never provided.