Resource Navigation Tab Laravel Package

Technical Evaluation

Architecture fit

• This is a presentation-layer-only package. It registers tab grouping for Filament resource form schemas; it introduces no migrations, no schema changes, no domain logic, no API surface, and no new runtime services. That makes architectural fit a binary question — does our panel run Filament, and does its version satisfy the package constraint — rather than a design question.
• The first gate is a framework ambiguity that must be resolved in hour one. The repository blurb references "Laravel Nova resource sidebars" while the composer.json and all secondary write-ups describe a Filament plugin (2.1.x line) that groups form fields into tabs. These are different products with different APIs. A TPM should not fund a spike until someone has read composer.json and src/ and confirmed the filament/filament constraint and plugin entry point. Two minutes of verification prevents an entire misdirected evaluation.
• If the panel is Filament: the integration point is a panel plugin registration plus per-resource tab declarations. Low conceptual surface — one provider line, one declaration pattern per resource.
• If the panel is Nova: the evaluation ends. Do not attempt an adapter; that converts a free dependency into an owned one.

Integration feasibility

• Genuinely cheap. One composer require, one plugin registration, per-resource tab grouping. Realistic effort for a pilot is hours, not days, for an engineer already fluent in the panel.
• Pin >=2.1.5 and reject floating 2.x or ^2.1.0. The 2.1.5 patch fixes a HasOne field failing to render on initial page load — that is a blank relationship field on a data-entry form, i.e. a correctness hazard, not a cosmetic quirk. Any version below it is disqualified for production use.
• The fix is JS-side, which means the published asset must be confirmed to match the tag. A stale prebuilt bundle from a prior install reproduces the bug while composer.lock looks correct. This is a known, documented trap and belongs in the acceptance criteria, not in tribal knowledge.
• The decisive early gate: does the panel's native Tabs component already solve this? Filament ships tab/panel primitives. If native tabs deliver the grouping we need, this package is a dependency for zero marginal value. This comparison can and should end the evaluation in the first hour. Everything downstream is conditional on it failing.

Technical risk

• Bus factor of one, zero dependents, 78 stars. Zero dependents is the telling number: no ecosystem has validated this in production. The November 2023 release after a gap, consisting of a single community PR fixing a user-reported bug, should be read as alive, not staffed — a reprieve, not a reversal. There is no vendor to escalate to, no security review pipeline, no LTS commitment.
• Field-type coverage is unvalidated. The one known defect arrived via user report, not CI. Relationship, upload, and KeyValue field types inside tabs are unverified until we verify them. The package's test matrix is the weak link, and it fails in whichever resource we happen to use that field type in.
• The highest-value risk is validation behavior inside inactive tabs. The panel validates all fields, not only visible ones. Submit with a required field blank in a hidden tab: if the UI surfaces the error and moves the user to the offending tab, acceptable; if it produces a generic failure with no pointer, that is a shippable-blocking UX failure that may not be patchable from outside the package. This is a pilot exit criterion, not a nice-to-have check.
• Cross-tab reactive/conditional fields (visible(), reactive() with a dependent field in another tab) are an untested interaction class. Must be walked explicitly against the field patterns our resources actually use.
• Framework major bumps are the real exposure. A single-maintainer presentation plugin is the likeliest casualty of a Filament major upgrade, and it fails at render time in the admin panel — typically the morning after a dependency update, in front of ops staff.

Key questions for the technical owner

1. Does the package target Filament or Nova, and does that match our panel and version constraint?
2. Do native panel tabs already give us the grouping? If yes, the evaluation is over.
3. Can we name defensible tabs for a real resource, or are we inventing them to justify the dependency?
4. Does the panel's validation behavior point users to errors in hidden tabs on our field mix?
5. Who owns the ~1–2 hours per quarter of release review and re-test after framework upgrades — and is the MIT fork contingency pre-agreed rather than improvised during an incident?

Integration Approach

Stack fit

• Fits only if the panel is Filament and the version constraint resolves. Otherwise stop.
• Scope is strictly presentational: resource form schema declarations and a panel plugin registration. No infrastructure change, no deployment change, no data-plane change. Blast radius is one resource file.
• The package is an enhancement to the authoring experience of admin resources, so it touches every engineer who edits a resource class. That argues for a single canonical declaration snippet in internal docs, not per-engineer improvisation.

Migration path

• No data migration, no schema migration, no config changes. That is the core of the value proposition and the reason the decision is structurally reversible.
• Upgrading from an inherited 2.1.0–2.1.4 install is a straight patch; do it before evaluating anything else, or the pilot will burn an afternoon debugging a phantom blank relationship field.
• Reverting is deleting the tab declaration from one resource. No state is created, so rollback is instantaneous and complete.

Compatibility

• Two axes: our panel major version vs. the package's declared constraint, and the field types our resources actually use vs. the package's (thin) verified matrix.
• Build a short checklist of field types present in our resources — relationships, uploads, KeyValue, conditional/reactive fields — and walk every one of them inside a tab. Treat any unverified type as unsupported until proven otherwise.
• Re-run that same checklist on every Filament minor upgrade, not only majors. It is cheap once written and it is the only coverage this package will get.

Sequencing

1. Hour 0 — resolve the framework ambiguity. Read composer.json and src/. Confirm Filament vs. Nova and the version constraint.
2. Hour 1 — the native-tabs gate. Prove whether the panel's built-in Tabs covers the need. If it does, close the evaluation and bank the finding.
3. Pin and verify. composer require ...:^2.1.5; confirm composer.lock and confirm the published asset matches the tag.
4. Pilot on exactly one resource. Pick one with 10+ fields, at least one HasOne and one BelongsTo. Group it Basics / Relations / Meta.
5. Cold-load smoke test. Hard refresh, fresh tab, and navigate in from the index. The 2.1.5 defect was a mount-time bug; warm navigation will not reproduce the failure class we are guarding against.
6. Validation and reactive-field tests. Blank required field in a hidden tab; cross-tab dependent fields. These are go/no-go.
7. Codify the convention, then expand one resource per PR.

Pilot design discipline

• Group by operator mental model, never by field type. Basics / Pricing / Relations / SEO / Meta is a support artifact; Strings / Numbers / Dates is a filing cabinet nobody asked for.
• Keep identity on the first tab always. Name, status, tenant — anything an operator scans to answer "which record is this." Tabs may hide fields; they must never hide which record is open.
• Isolate relationships in their own tab. HasOne/HasMany/BelongsTo is the least-tested path; a dedicated tab makes breakage obvious in review and diagnosable in production.
• Do not tab short forms. Below roughly 8–10 fields, tabs add clicks and hide context. This is an improvement for dense resources and an active regression for sparse ones — apply it selectively.

Operational Impact

Maintenance

• Real but small and unowned by default. Budget 1–2 hours per quarter for release review and re-testing after framework upgrades. That estimate must be attached to a named owner, or it becomes nobody's job and the first symptom is a broken admin panel.
• Pre-agree the MIT fork contingency now. The package is MIT and small; if maintainership lapses, forking is viable. Deciding that in advance is what prevents a stalled dependency from becoming an incident. Also pre-agree the thin-wrapper-over-native-Tabs fallback with a one-day time-box.
• Add a runbook line: "re-test all tabbed resources after framework major bumps." This is the single highest-leverage operational artifact for this dependency.

Support

• Positive expected effect on support load: dense forms drive "where do I edit X?" tickets. Tabs are a discoverability fix, and the effect on time-to-competence for new ops and support staff is measurable by comparing ticket volume before and after.
• The grouping convention doubles as support documentation — it can be pasted into macros, onboarding docs, and release notes. Arguably the convention is the real deliverable even if the package is later dropped.
• Offset risk: when a field moves into a tab, previously muscle-memory locations change. Expect a short tail of "X moved" questions after rollout. A one-line note in the internal changelog absorbs most of it.

Scaling

• Scales trivially in the technical sense — it is presentational and per-resource. But convention drift is the real scaling cost. Without a canonical snippet and a documented grouping rule, a dozen resources will grow a dozen tab schemes within six months, and the support artifact evaporates.
• Roll out one resource per PR. The change is presentational, so there is no reason to couple two resources' risk, and phased rollout lets the first resource codify the convention before the second inherits a mistake.
• Do not let tab layout become load-bearing. If a tab refactor can block a deploy, a UI nicety has become infrastructure — split it out of the release.

Failure modes

Ramp-up

• Engineer ramp-up: near zero for anyone already authoring panel resources. The canonical snippet is the whole onboarding.
• Ops/support ramp-up: positive — that is the point of the change. Expect a brief reorientation tail immediately after each resource converts.
• TPM ramp-up: modest, but non-zero. Someone must own the version pin, the quarterly review, the post-upgrade re-test, and the field-type checklist. If no one is named, the dependency is unmanaged rather than low-risk.

Recommendation Approve a contained, single-resource pilot with a defined exit gate and a pre-agreed one-day fallback — not a standard, and not a roadmap line item. Gates: framework confirmed → native tabs proven insufficient → pinned at >=2.1.5 with verified asset → cold-load, hidden-tab validation, and reactive-field tests pass. This is back-office hygiene: cheap, visible, fully reversible, and explicitly not a strategic bet. It should never appear in a roadmap narrative as differentiation; framing it as strategy invites scrutiny it cannot survive.