Roles Permissions Api Laravel Package

Product Decisions This Supports

• API surface scoping for RBAC features. This package is a presentation adapter — it turns roles/permissions domain logic into HTTP endpoints. That makes it directly relevant to decisions like "do we ship a roles/permissions REST API in v1, or defer to an admin UI?" and "what does the contract look like for role assignment, permission listing, and effective-permission checks?"
• Build vs. buy (thin-layer edition). The real build/buy question isn't RBAC itself — that's a solved problem (e.g., spatie/laravel-permission and similar). The question is whether to hand-roll the controller/resource/transformer layer that exposes it. An adapter package is a candidate to remove ~a sprint of boilerplate, if it fits your stack.
• Architecture direction: modular monolith vs. service split. An "api presentation adapter" implies a ports-and-adapters design where transport is swappable (REST today, GraphQL/RPC later). Adopting it is a soft commitment to that separation — a meaningful architectural decision that outlives the package itself.
• Roadmap sequencing for admin/partner surfaces. If roles and permissions are exposed to internal admin tooling or external partners, this determines whether permission matrices, role CRUD, and assignment flows land in the same release or get staged.
• Ecosystem bet. With 0 stars and 0 dependents, adoption is effectively a bet on the Liberu module ecosystem maturing. That's a portfolio/roadmap decision (vendor concentration, long-term maintenance ownership), not just a code decision.
• Compliance and audit exposure. Roles/permissions APIs are frequently the surface auditors ask about. Deciding how permission state is exposed (read-only vs. mutable, who can enumerate) is a product and security decision this package shapes.

When to Consider This Package

Consider it when:

• You are already running the Liberu modular Laravel stack and want a consistent, conventions-matching presentation layer rather than bespoke controllers.
• You need a standard roles/permissions HTTP surface quickly for an internal admin console or a first partner integration, and a spike is cheap.
• Your team is comfortable owning a fork — you're treating it as reference implementation / starting scaffold, not a dependency with a support contract.
• The license question is resolved favorably for your distribution model (commercial, SaaS, or open source) — see risk note below.

Look elsewhere when:

• License is unresolved. NOASSERTION is not a license. For any commercial or enterprise distribution this is a hard blocker until legal clears it; it is the single most disqualifying signal here.
• You need production guarantees. 0 stars, 0 dependents, and a single-vendor origin mean no community validation, no third-party bug reports, no ecosystem of answers. Bus factor is effectively one.
• Your RBAC needs are simple. A single-app Laravel product with basic roles is better served by spatie/laravel-permission plus 2–3 hand-written controllers — fewer moving parts, fully licensed, massively adopted.
• You need more than CRUD. Policy evaluation at scale, ABAC/relationship-based access, permission caching strategy, multi-tenancy isolation, or audit logging are all beyond what a thin presentation adapter should be expected to solve.
• Release hygiene matters to you. The listed last release (2026-10-26) is a future date, which reads as metadata noise rather than a healthy cadence. Verify the actual commit history and tag provenance before treating any release signal as real.
• You require GraphQL or event-driven contracts rather than REST resources.

Net PM read: treat this as an evaluation candidate for a timeboxed spike, not an adoption. Score 19.8 with opportunity 42.6 says "interesting direction, unproven artifact."

How to Pitch It (Stakeholders)

To executives: This is a small, thin piece of plumbing that exposes who-can-do-what over our API, rather than a platform in itself. The strategic value is low and the switching cost is low — which cuts both ways: it saves us a short burst of engineering effort, but it also means we shouldn't build a roadmap around it. My recommendation is a short, timeboxed spike, not a commitment. The gating issues are non-technical: the license is unstated, which is a legal stop sign for commercial distribution, and the project has no visible adoption, which means we would be the maintainer in practice. Approve the spike; hold the adoption decision until legal clears the license and engineering confirms the fit.

To engineering: It's a presentation adapter for roles/permissions — transport separated from the authorization domain, which is the right shape if we're already in the Liberu module conventions. It is not an authorization engine; it assumes a domain layer exists beneath it. Two asks before we lean on it: (1) confirm the license and whether we'd be forking, and (2) confirm what it actually wraps and whether its API contract is stable enough to expose to partners. If either answer is weak, we replicate the ~few hundred lines ourselves against a licensed, well-adopted RBAC library and keep the same ports-and-adapters boundary — same architectural benefit, none of the provenance risk.

Recommendation: Spike (1–2 days), behind our own interface boundary so it is replaceable. Do not introduce it as a direct dependency in a revenue-critical path until license and maintenance ownership are settled.