Filament Single Record Resource Laravel Package

Product Decisions This Supports

• Build vs. buy on "self-service" surfaces. Profile, wallet, settings, current subscription, and similar pages are near-universal in B2B/B2C SaaS. This package converts each of those from a bespoke Filament Resource + custom page into two traits and a page registration — a direct reduction in engineering scope for a standard roadmap item.
• Roadmap sequencing for account/member portals. If "My Wallet," "My Profile," and "My Settings" are backlog items, this package makes them a small, low-risk increment rather than a mini-project. It supports shipping them earlier and batching several into one release.
• Information architecture decisions. Choosing the single-record pattern (no index list, resource resolves to view) is a UX decision, not just a technical one. Adoption locks in a "one destination per concept" navigation model — cleaner sidebar, fewer dead-end list screens for the 1:1 case.
• Authorization model design. The package's viewAny()-denied-but-view()-allowed fallback forces a deliberate policy decision: "can this user list all records?" is now separable from "can this user see their own record?" This is the correct security posture for per-user data and is worth adopting as a house convention.
• Nested/tenant portal features. Deep chains (Wallet → Companies → Products) are supported with normalized breadcrumbs and root slug handling. This underwrites roadmap items like "customer workspace" or "tenant-scoped catalog" where URLs drop parent IDs and rely on strict query scoping.
• Feature feasibility triage. Low opportunity score (25) and only 12 stars mean it is not a strategic bet — it is a tactical convenience. Treat it as an implementation accelerator for features already on the roadmap, never as a reason to add a feature.

When to Consider This Package

Strong fit:

• A Filament 4 or 5 panel where a resource maps exactly one record per authenticated user via a belongsTo(User) relation (User hasOne Wallet, hasOne Profile).
• You want side navigation to keep working with no index page — the trait handles the redirect and nav registration.
• You have nested single-record chains and want breadcrumb consistency and root URL/slug resolution without hand-rolling it in every page.
• Your policies intentionally deny listing (viewAny) but should allow opening the user's own record (view) — the authorization fallback is the main non-obvious value here.
• You need per-resource custom resolution (firstOrCreate, where('active', true), tenant scoping) while keeping authorization and page loading aligned.

Look elsewhere or build in-house:

• The relationship is not 1:1 per user — shared records, one-per-team, one-per-role, or admin/operator views that browse other users' records. The package's default resolution assumes the authenticated user owns the record.
• You need collection UX anywhere: search, bulk actions, exports, counts, or "all my invoices" style lists. That is a normal Resource, not this.
• You are still on Filament 3 or an unsupported Laravel version — compatibility is pinned to ^4.0 || ^5.0.
• Your organization requires a vendor with support SLAs, security review artifacts, or an active maintainer team. This is a single-maintainer, pre-2.0 package with zero dependents.
• Removing parent IDs from nested URLs without enforcing strict model/page query scoping — the README explicitly warns this is on you. If the team cannot commit to that discipline, do not adopt the nested pattern.

Adoption guardrails if you proceed: pin the version, write a policy test for the viewAny/view fallback, and add a scoping test for every nested route. The code surface is two traits and one interface, so a fork-and-own contingency is cheap and should be the stated fallback.

How to Pitch It (Stakeholders)

To executives (30 seconds). This is a small open-source component that lets us build standard account pages — My Profile, My Wallet, My Settings, Current Subscription — with a fraction of the custom code we would otherwise write. It is MIT-licensed, free, and about two files' worth of logic, so it carries almost no lock-in: if it ever stops working for us, we can absorb it internally in days. It accelerates features already on the roadmap; it does not add scope.

To engineering. Filament 4/5 plugin, two traits (HasSingleRecordResource on the Resource, HasSingleRecord on ViewRecord/EditRecord) plus an explicit SingleRecordResolvableResource contract for static-analysis-friendly typing. It solves the real friction in the single-record pattern: index redirect, nav registration without an index, root record resolution, the viewAny-denied-but-view-allowed authorization fallback, and breadcrumb/slug normalization in nested chains. Resolution is overridable at the Resource level (builder or full resolver) so tenant logic and firstOrCreate stay in one place, keeping authorization and page loading aligned. It ships with Pest, PHPStan, and Pint in CI across Filament 4 and 5.

To product/design. One predictable destination per concept instead of a list view of one item. Users lands directly on their record, edit in place, with correct breadcrumbs through nested pages. Sidebar entries are stable and don't dead-end.

The honest caveats to state up front. Twelve stars, zero dependents, a single maintainer, and pre-2.0 versioning — this is not a mature dependency. Mitigate with a pinned version, tests around authorization and nested scoping, and a one-sprint fork contingency. It is a convenience we can afford to lose, which is exactly why the risk is acceptable.