Laravel Nova Blueprint Permission Laravel Package

Product Decisions This Supports

• Build vs. buy for admin-plane CRUD. The package is a build-time code generator, not a runtime dependency: it extends laravel-shift/blueprint so one YAML draft emits Nova resources plus policies wired to spatie/laravel-permission. This is the decision it informs best — do we write Nova resources and permission scaffolding by hand, generate them, or adopt a generator like this one? Because it sits in require-dev, trials are cheap and fully reversible, which lowers the bar for a spike.
• Roadmap: how much authorization surface to expose in Nova. Adopting it signals a commitment to Nova as the admin plane and to Spatie as the permission backend. The real roadmap question it forces is "do we want role/permission administration to live in Nova, or in our product's own settings UX?" — with the follow-on question of whether permissions are authored at build time (generated policies) or at runtime (seeded, DB-driven).
• Feature scoping for back-office work. Use cases: greenfield Laravel + Nova back offices, multi-role internal tools, and any product where a permission matrix would otherwise be hand-built once per model. The blueprint:build + git diff --exit-code CI pattern is a governance decision worth making regardless of vendor: it makes drafts the only place Nova resources are authored.
• Engineering-process standardization. Publishing stubs to enforce one permission-naming convention (viewAny <model> vs index <model>) across every resource is a durable decision this package supports — and one you can keep even if you drop the package.
• What it should not drive: it is not a security control, not a policy engine, and not a runtime authorization layer. Don't let it appear on a roadmap slide as "permissions" — it is scaffolding for permissions.

When to Consider This Package

Consider it only when all of these hold:

• You are already on Laravel Nova with a paid license and intend to stay.
• You already use spatie/laravel-permission with default-ish config (default guard, standard table names).
• You already use — or are willing to adopt — Blueprint drafts as the source of truth for models, migrations, and policies.
• The admin surface is greenfield or small enough that generated-then-customized resources are acceptable, and you can keep hand edits in traits/custom classes.
• Someone owns the stub directory and the Composer pin. At 3 stars with a 3.0.0 release whose only notes are a compare link, bus factor is the dominant risk.

Look elsewhere when:

• You expect vendor support, an SLA, a maintained changelog, or a security review — none are evidenced here, and permission code is security-sensitive (stale caches and wrong-guard wiring cause privilege escalation or admin lockout).
• Your Nova resources are heavily hand-edited; Blueprint output is not merge-aware and will overwrite them.
• You want permissions editable at runtime by admins rather than generated at build time.
• You are not on Nova or not on Blueprint. This package only adds generators on top of Blueprint's models: / migrations: / policies: sections; without that substrate it delivers nothing.
• Upgrading from 2.x under time pressure — the major bump is undocumented; pin ^2.0 and defer.

How to Pitch It (Stakeholders)

To executives: This is not a platform bet. It's a small, dev-only code generator that removes repetitive work when standing up admin screens in our Laravel/Nova back office — roles, permissions, and policies scaffolded from a single version-controlled spec instead of hand-written per model. Cost of trying it is a short, time-boxed spike; cost of walking away is zero because it never ships to production. The honest caveat: it is a 3-star, single-maintainer package with no published changelog for its latest major version. I recommend we treat it as a reference implementation and pattern source — adopt the draft-as-source-of-truth and CI drift-check workflow outright, and decide on the dependency itself only after a one-sprint spike. Recommendation: explore, don't standardize.

To engineering: composer require --dev. Confirm a Nova resource and its policy land in app/Nova/ with the expected permission gates from one existing draft. Two things to verify before we go further: (1) the guard referenced in generated policies matches auth.guards, and (2) every generated file's path, because "it didn't generate" is usually drafts in the wrong directory — Blueprint reads drafts/ at the project root. Pin ^3.0 only after reading the 2.0→3.0 compare link; otherwise pin ^2.0. Keep customizations in published stubs and traits, never in vendor or generated files. If the generator proves brittle, we fall back to an in-house stub set — the output shape is the valuable part, not the package.