Liveupdate Laravel Package

Technical Evaluation

Architecture fit. Narrow, additive, and confined to the internal admin surface — which is exactly the scope a TPM can defend. Under the Nova-field reading, this is a presentation-layer plugin that registers a Vue component against Nova's field API and attaches to one resource. Under the Blade live-refresh reading, it is a view-layer helper that broadcasts Eloquent model events over the broadcasting driver already configured in the app. Either way: no domain logic, no persistence layer, no request-path ownership, opt-in per screen. The blast radius is a broken internal form, never a customer-facing outage. The corollary is equally binding — the upside is capped at internal operator productivity. If we are not a Laravel shop, or (under the Nova reading) not a Nova shop, fit is zero and this closes in one meeting.

The first risk is evidence integrity, not engineering. The intake record describes three different products. The composer name wehaa/liveupdate and description.md describe a general Blade live-refresh/broadcasting helper. The repository URL (wehaa/inline-field-update) and top-line description say "a Laravel Nova field." The prior assessments on file evaluate a validation-rules introspection utility, which matches only the v0.3.2 release note. A TPM cannot scope, staff, or gate a dependency whose feature set is undetermined. The first deliverable is a half-day identity spike: clone the tagged v0.3.2 artifact, read composer.json and the source tree, and write one page confirming what it does. Until that exists, everything below is conditional and nothing should be committed to a roadmap.

Integration feasibility. High mechanically, unknown in compatibility. Composer install, package discovery, register the field or directive on one screen — hours, not weeks. The unknowns are two: which Nova major the field targets (Nova 4 and Nova 5 each reworked the field contract; last release 2021-12-02), and which PHP/Laravel band it was built against. Neither is inferable from a README that is demonstrably inconsistent with the release notes. An untested Nova/Laravel combination should be treated as broken until it renders and persists on a branch.

Technical risk, ranked.

1. Abandonment. Four years stale, 29 stars, zero dependents, overall score ~1.66. No downstream has ever hardened this against a Nova upgrade; we would be the first.
2. Version drift on a proprietary surface. Nova is paid, versioned, and closed. A field plugin inherits Nova's breaking changes with no upstream absorber, and Nova majors track Laravel majors — effectively non-discretionary.
3. Authorization and audit surface. Any inline-edit control that writes model attributes raises two data-integrity questions wearing a UI costume: does it honour Nova policies and field-level canSee/readonly, and does it fire model observers so our audit log and downstream syncs keep recording admin changes? A silent bypass surfaces weeks later as divergence between admin and reporting.
4. Validation failure behaviour. Inline error, silent no-op, or partial write? The v0.3.2 note ("return an empty array if validation rules do not exist") suggests edge cases were lightly covered.

The one strong mitigant is MIT plus likely small size. If the source is a few hundred lines, forking and owning it is cheaper and safer than depending on an abandoned tag. The identity spike should answer line count and test presence directly.

Key questions the spike must answer.

1. What does v0.3.2 actually contain — Nova field, Blade refresh helper, or validation-rules utility?
2. Which Nova and Laravel/PHP versions are supported, and does it load against ours?
3. Does the write path respect Nova authorization policies, or persist directly through the model?
4. Do inline saves fire model events — and therefore our audit logging and downstream syncs?
5. What happens on validation failure: inline error, silent no-op, or partial save?
6. LOC and test coverage? Small and tested means fork-and-own; large and untested means walk away.

Integration Approach

Stack fit. Laravel, and probably Nova, only. Under the Nova reading this is a dev-time dependency of the admin panel and never touches the customer product path — downside capped at internal tooling, upside capped at internal tooling. It cannot be positioned as a customer-experience investment. If the roadmap already implies richer interactivity, the framework decision (Livewire, Inertia + Vue/React, htmx) supersedes this package entirely: adopt-a-stack beats adopt-a-package the moment the requirement is more than one field.

Migration path. None — this is net-new adoption, so the sequencing that matters is containment: pin the exact version, vendor or fork the source rather than depending on the upstream tag, and register it on a single low-risk resource before considering a second. Wrapping it behind a thin internal adapter — one file that names the field or directive — makes a future swap a one-file change and is the cheapest available insurance against abandonment.

Compatibility. Two axes, in priority order. First, Nova major version: this is the gating check, and an untested combination is broken rather than assumed. Second, the PHP/Laravel band from 2021. Verify both by running them, not by reading the README.

Sequencing, with explicit gates.

1. Identity spike (half day). Clone, read composer.json and source, confirm the product. Hard stop if the confirmed product does not map to a use case we actually have. Non-negotiable given the contradictory record.
2. Compatibility spike (one day). Install pinned against our Nova/Laravel versions on a throwaway resource; exercise one inline edit end-to-end including one validation failure and one authorization denial. The denial test is the one most likely to fail and the most expensive to discover later.
3. Fork decision. If it works and is small, fork under our org, add CI and a minimal regression test, drop the upstream dependency. This converts abandonment risk into a routine maintenance line item and removes the bus factor.
4. Pilot. One internal admin resource, one team, timeboxed, measured against the status quo — specifically, full-page navigations per single-field change. Pick the metric before the pilot starts.
5. Broaden only on measurable operator time saved. The default outcome should be "not worth it"; the burden of proof sits with the package.

Fallback, and it is a real one. Nova's custom-field API is documented and a narrow click-to-edit control is a known small build — roughly one to three days. For a single-field UX win, building it ourselves is credible and is the only option that survives a Nova upgrade without archaeology. A TPM should cost the fallback before approving the spike: if the build is genuinely one to three days, the spike's expected value drops sharply, since we would be spending two days evaluating a dependency we would then fork anyway.

Operational Impact

Maintenance. Assume zero upstream effort from day one. Every Nova upgrade — and Nova upgrades are not discretionary, since they track Laravel majors — becomes our problem. Budget roughly an hour per Nova major to re-verify the field, plus the recurring cost of the fork if we take that route. That recurring line, not the install, decides the business case, and against a small internal-admin convenience it often does not clear the bar. Put the number in the decision memo explicitly rather than leaving it implied.

Support. None. No maintainer activity since December 2021, no issue triage we can rely on, no security-update channel. We are the support tier from hour one. This is acceptable only because the surface is internal and the code is likely forkable; it is disqualifying for anything customer-facing or revenue-critical.

Scaling. The package does not scale in any product sense — it is a per-screen UX affordance with no capacity model of its own. What scales is the number of screens we adopt it on, and that is the variable to control. Under the broadcasting reading, load lands on the existing broadcasting driver and queue, so scaling risk is inherited from infrastructure we already run rather than introduced. Under the Nova-field reading, there is no scaling dimension at all. Either way, keep adoption at one or two screens until the fork is stable; breadth multiplies the upgrade-verification cost linearly with no corresponding benefit.

Failure modes. Ranked by what a TPM would actually have to explain: (1) a silent authorization bypass allowing an edit the policy should have denied; (2) a write that skips model observers, so audit and reporting diverge; (3) a validation edge case that no-ops or partially writes and leaves the operator believing the save succeeded; (4) a Nova upgrade breaking the field mid-sprint with no upstream fix, forcing an unscheduled fork; (5) quiet abandonment — the package is still installed, still "works," and nobody has re-verified it in three Nova majors. Modes 1 and 2 are the ones that convert a UI convenience into a data-integrity incident, and they are precisely what the compatibility spike's authorization-denial test is designed to surface.

Ramp-up. Effectively zero for engineers who know Nova — install, register, attach to a resource. The real ramp-up is the investigation cost: because documentation is unreliable relative to the source, the team learns the feature set by reading code, not docs. Budget that explicitly in the spike rather than treating it as friction. For the wider team, communicate the posture up front: this is a timeboxed spike on internal tooling, not an adopted dependency, and the expected outcome is "not worth it" unless a pilot shows measurable operator time saved.