Nova Perspectives Laravel Package

Technical Evaluation

Architecture fit. Unchanged. nova-perspectives is a Laravel Nova add-on, not a general Laravel package; it only has a place in the stack if we are already a Nova shop and paying for Nova licenses. The value proposition remains narrow and real: present one Nova resource through multiple configurable viewpoints without duplicating resource classes. That is a presentation/config-layer concern and should sit at the edge of the architecture carrying no domain logic. The v1.3.0 "redirect to resource" feature is the first thing to challenge that assumption — a redirect is behavior, not presentation. It introduces a control-flow and possibly a routing concern into what we previously modelled as pure config. Confirm whether the redirect is a declarative config key consumed by Nova's own response handling (acceptable, still edge-layer) or a package-owned redirect that constructs URLs and targets itself (a real architectural step up in responsibility).

Integration feasibility. Still a standard Composer install with auto-discovery and a publishable config; effort remains hours. Two changes matter. First, v1.3.0 adds Nova 5 support, which widens the eligible stack rather than narrowing it — but the release notes make no statement about Nova 4 remaining supported, so the supported matrix is now ambiguous in both directions and must be read from composer.json, not from the changelog. Second, the release body is visibly malformed: it concatenates two different compare ranges (1.1.2...v1.3.0 and v1.2.0...v1.3.0) and omits v1.2.0 from the notes entirely. That is a small but genuine supply-chain signal — we cannot reconstruct what v1.2.0 changed from the published notes, so the audit must diff the tags directly rather than trust the release text. The gating question is unchanged in kind: declarative config (low risk, portable, trivially reimplementable) versus custom Vue/Blade and menu hooks (higher rebuild cost, tied to Nova front-end internals).

Technical risk. The dominant section, and it has improved but not flipped:

• Upstream is not dead — verify the archive flag. The prior assessment's central premise was "archived upstream, zero maintenance." A new tagged release with a Nova 5 compatibility PR directly contradicts that. This is the single most important correction: downgrade "archived" to "must be re-verified at spike time." If the repository is still flagged archived, the Nova 5 commit is a one-off courtesy patch and the original conclusion stands untouched. Do not adopt on the strength of one release.
• Compatibility currency is now a genuine positive. Nova 5 support means the package is not stranded on a Nova major we may be leaving. That materially reduces the "we inherit an unscheduled upgrade obligation with no upstream" risk — for exactly one major version, once.
• Bus factor marginally improved, not solved. A first-time external contributor (@mateusz-peczkowski, PR #12) is a positive community signal but is a drive-by contribution, not a co-maintainer. Still single-maintainer, still single-point knowledge. Norman Huth's breadth across many Nova packages remains a productivity signal, not a longevity guarantee.
• Adoption signal still effectively nil. 5 stars, 0 dependents — unchanged by this release. No downstream bug-fixing, no de facto test corpus; we would still be among the only production users.
• New behavioral surface: the redirect. Redirect logic is a classic IDOR/enumeration vector — if the redirect target is derived from user-controllable input or from a resource ID without an authorization check, a "convenience" feature becomes a record-enumeration path. This is new risk introduced by this release, and it must be reviewed in the same pass as the existing authorization concern.
• Permission-surface risk (pre-existing, still the top item). A perspective that hides a column in the UI does not necessarily constrain the underlying query or API payload. Field-level leakage across roles remains the failure mode that turns a cosmetic package into an incident.
• Opportunity score caveat. The 7.22 score still sits in contrast to 5 stars and 0 dependents. Read it as unclaimed whitespace in a niche, not as demand. Do not let a release event upgrade it into a quality signal — one PR is not a trend.
• Evidence quality. The prior assessment was produced with no structured data behind it. This release is the first hard evidence point we have, and it points both ways: maintenance is real, but release hygiene is loose.

Key questions for the spike owner (revised):

1. Is the repository still archived? If yes, why was v1.3.0 shipped, and is any further maintenance committed?
2. What is the exact supported matrix from composer.json — does Nova 4 remain supported alongside Nova 5, or was it dropped?
3. What changed in v1.2.0? The release notes omit it; diff the tags.
4. What does "redirect to resource" actually do — what constructs the target, from what input, and does it pass through Nova's authorization before redirecting?
5. Does it use documented Nova 5 extension points or internals, and how much front-end (Vue/Blade) does it ship?
6. Does a perspective constrain data at the query/authorization layer, or only at the presentation layer?
7. Does Nova 5 ship a native equivalent, making this package redundant?
8. LOC-adjusted cost to reimplement in-house versus fork-and-maintain at v1.3.0.

Integration Approach

Stack fit. Laravel + Nova, now plausibly Nova 4 or 5 (confirm from the manifest, not the changelog). If we are on Nova, the fit is clean and additive: install, publish config, declare perspectives per resource, no schema changes expected. If we are not on Nova, this package is still not a reason to adopt Nova — per-application licensing and closed-source nature are a far larger commitment than this package's value justifies. Nova itself is the real vendor decision.

Migration path. Adopt-by-fork remains the default, pinned at v1.3.0 rather than an older tag — the fork baseline should be the release that carries Nova 5 support, since forking an older tag re-imports the compatibility problem the release just solved. Concretely:

• Vendor into our namespace, or use a composer.json VCS/path repository at a pinned commit. Never track a floating constraint against a repository whose maintenance posture is unresolved.
• Preserve MIT license and attribution; legally uncomplicated, still the most favorable data point here.
• Re-run the fork-vs-reimplement calculus. The calculus has shifted toward consuming the package: Nova 5 support is exactly the work we would have had to do ourselves in a fork, and it arrived free. If the audit shows the surface is still small and config-shaped, forking v1.3.0 is now cheaper than reimplementing. If the redirect feature turns out to be custom routing/controller code, the surface has grown and reimplementation gets comparatively more attractive.
• If Nova 5 has since shipped a native equivalent, migrate to it and skip this entirely.

Compatibility. Build the explicit matrix at adoption time (Nova major × Laravel major × PHP minor) and record it as the frozen baseline — with Nova 5 included. Treat every Nova major as requiring a manual verification pass. Add the package to the dependency register consulted before any Nova upgrade, and additionally to the register consulted before any package upgrade, since the redirect feature means an upgrade can now change runtime behavior, not just column layout.

Sequencing.

1. Re-verify the archive flag and read composer.json for the actual Nova 4/5 support declaration — zero-cost kill criteria either way.
2. Diff v1.1.2 → v1.3.0 to recover the missing v1.2.0 changes.
3. Review the redirect PR (#12) specifically for target construction and authorization.
4. Authorization spike: prove a perspective cannot expose fields or records a role is not entitled to, and that the redirect cannot be used to reach an unauthorized resource.
5. Decide fork vs. reimplement at v1.3.0 and record the rationale, including the maintenance-posture evidence.
6. Pilot on one low-stakes internal resource; measure the config ergonomics the team actually experiences.
7. Only then generalize to customer-facing resources, with a named fork owner assigned before the second resource ships.

Operational Impact

Maintenance. This is the section that changed most. The realistic model is no longer "internal ownership of a frozen fork with zero upstream"; it is internal ownership of a fork with sporadic upstream, which is subtly harder to plan for than either a live dependency or a dead one. Budget the same ~1 day per Nova major upgrade, plus time to evaluate each new upstream release on its merits rather than assuming it is safe or assuming it will never come. Still assign a named engineer and a documented upgrade checklist, and add a scheduled review that asks both "is this still worth carrying?" and "is upstream actually alive this quarter?"

Support. Still no vendor and no SLA. Defects are our defects. Thin team-facing documentation remains the norm — the fork owner should write a short internal README covering the perspective config contract, the redirect behavior, and the certified Nova/Laravel/PHP matrix. That document is the support artifact, and it now needs to cover a feature that did not exist at the time of the original assessment.

Scaling. Runtime cost remains negligible; this is a presentation/config layer and does not add meaningful query or rendering load beyond what Nova already does. The redirect adds one extra request cycle on the paths that use it — immaterial. The scaling risk is unchanged and organizational: config sprawl, with perspectives multiplying per resource, drifting across teams, and becoming undocumented behavior nobody dares delete. Cap it with a convention (who may add a perspective, naming, review).

Failure modes, ordered by severity:

1. Authorization leakage via perspectives. Restricts visible columns but not the underlying data, exposing fields across roles. Highest business impact; test explicitly.
2. Redirect-based record enumeration. New in v1.3.0. If the redirect target is built from user-influenced input or a raw resource ID without a Nova authorization check, it becomes an IDOR path. Review before pilot.
3. Silent Nova-upgrade breakage. Front-end overrides fail quietly after a Nova release, degrading UX without throwing errors. Mitigate with a post-upgrade smoke test. This risk is lower than previously assessed, since Nova 5 is now explicitly supported.
4. Dependency-scan noise. An archived or sporadically maintained package still trips security and policy tooling; the exception paperwork recurs, though it is now easier to argue because the package is current against Nova 5.
5. Orphaning. The one engineer who understood the config leaves; the fork becomes unmaintainable archaeology.
6. Fork rot / drift. We fork at v1.3.0, upstream later ships fixes we never track, and we face a large jump across Nova majors with no leverage.

Ramp-up. Low technically — a Laravel developer familiar with Nova is productive in under a day; this is configuration, not architecture. Organizational ramp-up remains the real cost: the team must internalize that this dependency has a thin, intermittent upstream with no safety net, and reviewers must know the fork policy. Revised recommendation: still spike it, still verify the authorization model, but the prior "default to reimplement" posture is no longer clearly correct. Nova 5 support arriving from upstream is real value and lowers the fork burden. Default to fork at v1.3.0 behind one pilot resource, contingent on (a) the archive flag being cleared or explicitly accepted as a known risk, and (b) the redirect feature surviving authorization review. Fall back to Nova's native capability or a small in-house implementation if either check fails.