Vendra Permission Laravel Package

Product Decisions This Supports

• Build vs. buy for authorization. Roles-and-permissions is a solved problem; the only defensible in-house build is a differentiated one. This package shifts the decision from "do we build ACL" to "do we adopt Spatie's model plus a packaged admin surface" — typically 6–10 engineer-weeks of avoided work once migrations, caching, middleware, Blade directives, and CRUD screens are counted.
• Enterprise / upmarket roadmap items. Per-tenant role customization, delegated admin (a customer admin assigning roles without filing a ticket), and "who can see what" answers are recurring gates on enterprise deals and security questionnaires. The bundled Filament UI is the decision-relevant asset: it converts permissions from engineering work into admin-configurable data.
• Feature gating and packaging. Supports plan-tier gates, seat/role entitlements, and API scope decisions without bespoke flag logic per feature.
• Platform commitment. This is a subtree split of the Vendra monorepo with 1 star — the star count is not a quality signal, it is a distribution artifact. Adopting it is a commitment to the Vendra module graph (TenantResolver, module Plugin registration, self.version alignment), not an isolated library pick. Frame it as a platform bet, and evaluate the parent repo's health, not this repo's.
• Decisions it does not settle. Multi-tenancy strategy (it derives tenancy, it does not define it), SSO/SCIM provisioning, attribute- or relationship-based authorization beyond role checks, and audit logging of permission changes.

When to Consider This Package

Consider it when:

• You are on (or seriously evaluating) the Vendra modular monolith for Laravel and are using its tenancy model; the tenant-scoped migrations and vendra-tenant:enable retrofit are only valuable inside that world.
• Non-engineers need to manage roles in an admin panel — this is the genuine differentiator over raw Spatie.
• Tenant-scoped permissions are a requirement and you want that handled by the support layer rather than reimplemented per model.
• You accept Spatie semantics: roles and permissions as data, resolved through Gate/policies.

Look elsewhere when:

• You are not on Vendra. Use spatie/laravel-permission directly. This package is a wrapper; you would inherit an entire module graph for no benefit.
• You need ABAC, ReBAC, or externally evaluated authorization (OPA, SpiceDB, managed FGA). Role tables do not stretch to relationship-based rules.
• You require a vendor SLA, a formal CVE/advisory process, or contractual support.
• Release opacity is unacceptable. Published notes are changelog pointers only — no migration guide, no advisory content. For an authorization layer, that is a legitimate blocker until the diff is reviewed.
• Governance is inaccessible. The repo is [READ ONLY]; contributions and issue triage happen upstream. If you cannot get review attention in misaf/vendra, or will not commit to a private fork as fallback, that is a no.

How to Pitch It (Stakeholders)

For executives — one slide. "Roles and permissions, including letting each customer configure their own, is table stakes for enterprise deals. This gives us that plus an admin UI out of the box, instead of six to ten weeks of in-house build. The cost is a maintained dependency, not a license — MIT." Lead with the enterprise gate it unblocks, not the architecture. Be explicit that it is part of a wider platform bet: adopting it means adopting the Vendra module ecosystem, so the pitch should be bundled with that decision rather than floated as a standalone win.

For engineering. "Spatie's permission model, wrapped with a Filament admin surface, strict types, tenant-aware migrations, and a Pest test convention. The work is not installation — it's reconciling existing bespoke Gate checks and building an authorization regression suite with explicit allow and deny cases. Plan shadow-mode comparison before cutover."

Risk framing for both. Do not hide it: authorization is a privilege-escalation surface, and the honest risks are (a) opaque release notes across a four-release jump, (b) a very small independent footprint with upstream-only governance, and (c) stale permission caches after revocation — a security incident, not a bug. Present mitigations as commitments: pin an exact version after diff review, run migrations forward and back on production-shaped data, ship a kill switch, and pre-agree a private-fork fallback before adoption rather than after. Ask engineering for one number up front: the estimate for the regression suite, because that artifact is what makes every future upgrade cheap and is the real cost of this decision.