Filament Clusters Laravel Package

Product Decisions This Supports

• Framework upgrade sequencing (the live one). Release 1.5.0 is a compatibility-only change: Laravel 12 support. Its only product value right now is removing this package as a blocker for the platform upgrade. The decision it supports is "keep the dependency, proceed on schedule" — not "find a replacement." Book it as a checkbox on the upgrade plan, not a roadmap item.
• Build vs buy on the admin surface. Grouping Filament resources and pages under a shared URL prefix, nav section, and breadcrumb is repetitive but trivial to hand-roll. Buying it turns per-module wiring into configuration, and that pays back on every new admin module. The strategic question is whether admin scaffolding is something the team should own at all — for internal tooling, usually not.
• Admin information architecture as a cheap, reversible bet. Clusters map naturally to product domains (Billing, Catalog, Support, Settings), which makes IA a choice you can revisit by re-namespacing rather than an architecture commitment. That's a low-cost way to test whether the back office mirrors how the business actually thinks.
• Feature scoping and predictability. Multi-screen admin features stop being "blocked on an admin refactor first" and become estimable feature work. That's the throughput gain internal-tooling roadmaps actually feel, and it's the benefit stakeholders notice.
• Dependency portfolio — convenience, not foundation. Zero stars traction to speak of, zero dependents, a single maintainer, community-only support, and Filament is absorbing cluster-style grouping into core. Register it as a convenience dependency with a scheduled exit review, not an architecture choice. The decision to record: "adopt with a re-evaluation trigger at the next Filament major."
• A diligence flag worth writing down now. Package metadata says clusters "cluster multiple fields into one visually," while the documentation describes cluster navigation. With zero dependents, that contradiction means nobody outside the maintainer has validated the use case. A one-day spike must confirm which feature actually ships before it shapes any commitment or estimate.

When to Consider This Package

Adopt when:

• You're on Laravel 11/12 + Filament v3 and the admin panel has outgrown a flat resource list into several distinct functional domains.
• You want domain-grouped navigation and prefixed URLs without owning resource subclasses, route prefixes, and breadcrumb wiring yourself.
• The admin surface is expected to keep growing, so manual per-module setup cost compounds with each screen.
• The panel is internal-facing, the team is small, and "configure rather than own" is the right trade.
• A named internal owner exists to track bumps and force the re-evaluation at each Filament major.

Look elsewhere when:

• Filament-native clustering already covers the need — two competing conventions in one panel is a permanent tax for near-zero upside.
• The panel has a handful of resources with no realistic growth; the abstraction earns nothing and the URL churn costs something.
• You need scope the package doesn't cover — per-cluster permissions, custom routing semantics, multi-panel isolation — because you'll write the glue anyway, which is worse than owning the small amount of routing directly.
• The panel is customer-facing, SLA-bearing, or revenue-critical. Single-maintainer, community-supported dependencies don't belong on that path.
• Re-clustering would ripple into hardcoded route() calls, seeded permissions/ACLs, bookmarks, or external deep links and nobody will own the migration PR.

Verification gate before committing: confirm 1.5.0 actually widened the laravel/framework and filament/filament constraints in composer.json (not just the CI matrix), confirm cluster routing survives route:cache and Filament's component cache, and diff the admin route list in a spike branch to size the blast radius. Any of those failing is a stop, not a workaround.

How to Pitch It (Stakeholders)

To executives: A small, single-purpose add-on that lets us organise the admin back office into logical sections with far less custom code. The 1.5.0 release adds Laravel 12 support, so it won't hold up the framework upgrade — and the maintainer shipped that support within about a day of the Laravel release, which is a positive maintenance signal. Cost is one Composer dependency; blast radius is limited to routing and navigation, not data or business logic. Honest caveats: it's a single-maintainer package with no known dependents, its own documentation and metadata disagree about what it does, and Filament is moving similar grouping into core. So we frame it as a convenience dependency we'd be comfortable removing, not a foundation. Recommendation: adopt now to keep admin changes cheap, gate it behind a one-day verification spike, and set a calendar trigger to re-evaluate at the next Filament major.

To engineering: Patch-level, non-breaking release — one feature, Laravel 12 compatibility. Safe to bump on a branch, but verify the constraint widening at the source rather than trusting the changelog. It gives us declarative grouping of Filament resources and custom pages under shared URL prefixes and nav sections, replacing boilerplate. Three things to hold onto: (1) it overlaps with Filament-native clustering, so settle the native-vs-package question in a spike before we standardise — "native wins" is a successful spike outcome, not a wasted week; (2) the real cost is reorganisation, since moving resources into clusters changes URLs and route names and ripples into tests, permissions, and deep links — land it as its own PR with a documented URL-break note, never bundled with the framework upgrade; (3) it leans on Filament internals, so pin ^1.5, keep cluster definitions behind a thin internal convention (labels, icons, sort, URL prefix only — nothing domain-specific), and smoke-test at every Laravel and Filament major so the exit back to native is a contained change rather than an admin rewrite. Also confirm at the top of the spike whether this package groups form fields or navigation — the description and the docs disagree, and that answer changes the whole plan.