Laravel Nova Blueprint Permission Laravel Package

Technical Evaluation

Architecture fit

• The evidence points to a build-time code generator, not a runtime package: it extends laravel-shift/blueprint so a YAML draft emits Nova Resources plus policy/permission wiring (typically against spatie/laravel-permission). The marketplace description ("blueprint-style interface for defining roles, assigning permissions") describes an admin UI, which the implementation notes contradict. Treat the positioning mismatch as the first thing to resolve before any stakeholder sees a demo — the actual artifact is scaffolding, not an end-user RBAC screen.
• If the classification holds, this is a developer-productivity tool on the admin plane, not core authorization logic. Architectural fit is therefore narrow: it fits only if the team is already Nova-based and already Blueprint-first. It does not add authorization capability — Spatie and Nova's Gate integration do that. The package's contribution is generation velocity.
• Fits best in greenfield or early-stage Nova back-offices where Resources are still being scaffolded. Poor fit for a mature app where Nova Resources are hand-tuned and drift-sensitive.

Integration feasibility

• Feasible but prerequisite-heavy. The real dependency chain is Nova (paid license) → Blueprint → this plugin → Spatie. Any link missing makes the plugin valueless. The dominant cost is not this package; it is adopting Blueprint's draft-as-source-of-truth discipline across the app.
• Installation is trivial (--dev), publish stubs/config, run blueprint:build. A one-day spike can establish whether generated output is usable — that is cheap and worth doing before any deeper commitment.

Technical risk

• Documentation/positioning risk (highest): description and behavior diverge. Scope is unclear until a spike proves what is actually emitted.
• Upgrade risk: 3.0.0 is a major bump whose release note is only a compare link. No changelog body, no migration notes, no support matrix.
• Bus factor / ecosystem risk: 3 stars, single maintainer, opportunity score 0.38. No community, no third-party tutorials, no Stack Overflow corpus. Every defect is an internal ticket.
• Authorization risk: permission packages are security-sensitive. Generated policies can silently mismatch if config/permission.php uses non-default tables or a non-web guard — misalignment yields either privilege escalation or admin lockout.
• Regeneration risk: Blueprint output is not merge-aware; hand-edits to generated Resources are destroyed on rebuild. This is a process risk that must be encoded in team conventions, not solved by the tool.

Key questions

1. Is this a code generator or an admin UI? Get a definitive answer from the spike, and correct internal documentation accordingly.
2. What changed 2.0.0 → 3.0.0, and what is the supported matrix (Laravel / PHP / Nova / Spatie)?
3. Are we already on Blueprint? If not, is the combined adoption justified versus hand-writing Nova Resources and policies?
4. Who owns the generated code — is it treated as committed source, or as disposable output?
5. What is the license, and is there any maintenance commitment or SLA from the author?
6. Does the generated policy naming convention satisfy our access-review and audit requirements?

Integration Approach

Stack fit

• Requires Laravel + Nova + Blueprint + a Spatie-style permission backend. Confirm Nova version alignment first — Nova majors are the most common break point and are licensed, so upgrade timing is a commercial decision as much as a technical one.
• Define early whether the package touches only generation or influences runtime authorization. If generation only, production blast radius is limited to the code it emits — a favourable risk profile.

Migration path

• Greenfield / no prior use: pilot 3.0.0 directly. Build one representative model end-to-end (draft → Nova Resource → Policy → seeder → negative authorization test) with blueprint:build --only=<Model>.
• Existing 2.x users: do not upgrade opportunistically. Diff the compare link, review stub and config changes, and re-run generation into a branch to inspect the delta before merging. Pin ^2.0 if the upgrade cannot be scheduled.
• No Blueprint today: treat this as a separate decision. Adopting Blueprint is an app-wide workflow change; the plugin should not be the reason to adopt it. Recommend deciding Blueprint on its own merits first.

Compatibility

• Pin exact Composer constraints for Laravel, PHP, Nova, and the permission backend; run CI against the production matrix only.
• Verify generated policy guards against auth.guards, and confirm permission table names match config/permission.php.
• Add a CI drift check (blueprint:build then git diff --exit-code) so drafts stay the sole authoring surface.

Sequencing

1. Spike (≤1 week, throwaway branch): install --dev, publish stubs/config, generate one model, evaluate output quality and the generator-vs-UI question. Exit criteria: a Nova Resource + Policy that passes both positive and negative authorization tests.
2. Decision record: document what the tool actually does, what it does not, and the supported matrix. Include the positioning correction.
3. Convention design: publish stubs, define the permission naming convention and the "never hand-edit generated files" rule.
4. CI guardrails: drift check, dependency pin, and a lint step on generated policies.
5. Pilot: two to three models in a staging Nova app with representative roles and a seeded Spatie config.
6. UAT: admin workflows plus access-review sign-off from security.
7. Adopt or retire: full rollout with a documented rollback, or record a no-go and keep the spike as reference.

Operational Impact

Maintenance

• Put the package in require-dev — a production require ships a code generator to prod for no benefit.
• Assign an explicit owner for: Composer constraints, Nova upgrade timing, generated-code conventions, and stub customisation. Unowned codegen drifts.
• Treat 3.0.0 as a planned work item, not a routine bump. Budget review time for each major; assume unknowns until the changelog is read.
• Realistic ongoing cost is low but non-zero: the tool is small, but every Nova or Spatie major forces a regeneration review.

Support

• Expect no external support. No community, no issue corpus, no documented troubleshooting. Build an internal runbook covering: regeneration conflicts, permission cache clears, failed migrations, and guard/table mismatches.
• Ramp-up is short for Laravel/Nova developers (hours), longer for security and ops who need the permission semantics and the regeneration constraints explained.
• Keep a single internal "how we generate Nova resources" doc; otherwise each developer rediscovers the overwrite behaviour after losing edits.

Scaling

• Admin-plane traffic is low; the generated Resources themselves are ordinary Nova code and scale as Nova does.
• The scaling consideration is authorization throughput: if generated policies drive per-request Gate checks, validate Spatie's permission cache, indexes, and query patterns under expected load. This is a property of Spatie, not the plugin, but the plugin sets the defaults — get them right at generation time, because retrofitting means editing many files.

Failure modes

• Silent guard mismatch → privilege escalation or admin lockout. Mitigate with negative authorization tests in CI and a break-glass super-admin path.
• Overwritten hand-edits → lost functionality discovered late. Mitigate with the trait/custom-class convention and code review that flags changes inside generated paths.
• Dependency conflict on Nova major → blocked framework upgrade. Mitigate by pinning and by keeping generated Resources close enough to vanilla that you can drop the plugin.
• Single-maintainer abandonment → no upstream fixes. Mitigate by vendoring stubs and treating the plugin as replaceable; the exit cost should be "delete the dev dependency and keep the generated code."
• Changelog opacity on 3.0.0 → unexpected regeneration differences. Mitigate with a regenerate-and-diff branch before upgrade.

Ramp-up

• One developer-week covers the spike, conventions, and CI guardrails; that is the honest adoption budget.
• Gate the decision on the spike, not on the description. Given 3 stars and a 0.38 opportunity score, the default posture should be adopt as a disposable accelerator with a pre-planned exit, not as a foundational dependency. It should never be on the critical path of your authorization model — Spatie is, and should remain, the named dependency of record.