Trov Faqs Laravel Package

Technical Evaluation

Architecture fit. Trov FAQs is not a standalone utility — it is an add-on to Trov, itself a Filament-based content platform. Adopting it is a three-level commitment: Laravel → Trov → Trov FAQs. The package's entire value proposition is "FAQs are managed inside Trov's admin panel alongside your other content," which means it is worthless unless Trov is already (or is about to become) the content backbone. If Trov is not in the estate, this package is not a candidate at all and the evaluation ends here. If Trov is in the estate, then the package is a thin resource plugin whose functional surface is small and well understood: FAQ CRUD, drag-to-reorder, draft/live toggle, a Blade render component. That smallness matters for the decision — it is cheap to replace, which lowers the cost of walking away and should raise the bar for adopting anything abandoned.

Integration feasibility. Mechanically trivial, practically blocked. A 2022-05 era Laravel package will almost certainly target Laravel 8/9 and PHP 8.0/8.1, and a Filament plugin of that vintage targets Filament 2.x (Filament 3 shipped January 2023). Inference, not confirmed from the sources — but the direction of risk is what matters: the package predates every current Laravel and Filament major in active use. The usual caveats about reading the composer.json diff still apply, but they are now moot in a specific way: the repository is archived. There is no one to answer the diff questions, no one to accept a compatibility PR, and no future release that could widen the support matrix. The feasibility question is not "does it install today" but "will it still install at our next framework upgrade," and the answer to that is structurally no.

Technical risk.

• Abandonment is realized, not prospective. Archiving is a terminal state. Every other risk in this document is a downstream consequence of it.
• Security patching gap. Archived packages receive no security fixes. This is a supply-chain risk in production code paths and, for many organizations, a policy violation regardless of how benign the code is.
• Upgrade pinning — the dominant risk. A single unmaintained package can hold the entire estate back from a Laravel or PHP major, because the upgrade is blocked until someone forks and fixes the constraints. A ~200-line FAQ plugin blocking a multi-service platform upgrade is a disproportionate failure.
• No adoption signal. Zero stars is not a vanity metric here; it means no other team is exercising this code, so the first defect we hit is ours alone, with no issue trail to search.
• Pre-1.0 API churn is listed in the prior assessment but is now largely irrelevant — the package is frozen, so there will be no churn, only silence.
• License unverified. Before any fork or vendoring, confirm the license terms permit it.

Key questions — reframed for a TPM, because the maintainer questions are unanswerable:

1. Is Trov in our estate today, or is this purely exploratory? If exploratory, close the evaluation.
2. What is the actual product requirement behind FAQ content — is it a CMS-managed FAQ page, structured support content, or something with search/i18n/versioning needs the package does not cover?
3. What is our in-house estimate to build equivalent FAQ CRUD on whatever admin stack we already run? (Working assumption: 3–5 developer days.)
4. Does our dependency policy already prohibit archived packages? If not, why not — that is a separate governance finding.
5. If we forked it, who owns the fork, and what is the trigger for retiring the fork in favour of an in-house build?
6. What is the license on this repository and on Trov itself?

Integration Approach

Stack fit. Narrow. It fits an application on the 2022-era Trov/Filament-2/Laravel-9 line. It does not fit a current Laravel or Filament major without source changes we would have to own. Treat any claim of compatibility with our stack as unverified until proven in a sandbox.

Migration path. There is nothing to migrate; the genuine decision is among three options, and the TPM's job is to frame the choice rather than default to the package:

• Option A — Build in-house (recommended). Implement FAQs as a resource type on the admin framework we already run. The feature set is CRUD + ordering + publish state + a render partial. Cost is bounded and small; the output is code we own, upgrade-safe, and testable. This is the correct default for a feature this small.
• Option B — Fork and vendor. Viable only if Trov is already in production and an FAQ module is needed quickly. Cost is not the initial copy — it is ownership: naming a maintainer, adding CI, tracking upstream, and accepting the fork as a permanent internal package. The code is small enough that this is affordable, but it must be an explicit, resourced decision rather than a silent adoption.
• Option C — Adopt as-is with an exact pin. Rejected. Pinning an archived package does not control the risk; it defers it to the next platform upgrade, at which point it is more expensive.

Compatibility. No compatibility statement can be extracted from an archived repo. Verify empirically in a throwaway branch against our real constraints, and record the result in the decision record — not because we intend to ship it, but because the finding ("incompatible with our current Laravel major") closes the question for future reviewers.

Sequencing.

1. Days 0–1: Confirm whether Trov is a real platform commitment internally. If not, close.
2. Days 1–3: Sandbox install against current constraints; capture the actual failure/success and the pinned dependency set. Cheap, and it converts inference into fact.
3. Days 3–5: In-house build estimate against the same requirement scope.
4. Day 5: Decision record with the build-vs-fork-vs-adopt comparison, plus a risk-register entry if any outcome other than "build" is chosen.
5. Post-decision: If fork — license check, owner named, CI wired, package published to an internal registry with the fork's provenance documented.

Operational Impact

Maintenance. Adopting as-is means paying maintenance cost for a package nobody maintains: every Laravel, PHP, or Filament upgrade becomes our problem, and the work lands as an unplanned interruption at the worst possible moment — mid-upgrade, with the whole estate waiting. Forking converts that into a deliberate, budgeted obligation: an owner, a CI job, a compatibility matrix we define. For a feature this small, the in-house build almost always has the lower total cost of ownership over a two-to-three-year horizon.

Support. None. No upstream triage, no issue response, no security advisories, no release cadence. Escalation paths must be internal or nonexistent, and the TPM should state that plainly to stakeholders rather than leaving it implicit. Note that the Trov platform dependency carries the same question and should be evaluated with the same lens — if Trov is unmaintained, this package's status is a symptom rather than the disease.

Scaling. Functional scaling is a non-issue; FAQ content volumes are trivial and the Blade render is a simple query plus loop. The scaling that matters is organizational: every archived dependency in the portfolio raises the cost and lowers the safety margin of every future platform upgrade. The right lever is a blanket policy — archived packages require an explicit exception with a named owner and a retirement date — so individual teams stop relitigating the same question package by package.

Failure modes.

• Upgrade blockade. A framework upgrade fails to resolve; the plugin must be forked under time pressure. This is the most likely and most expensive outcome.
• Unpatched vulnerability. A CVE lands in a transitive dependency with no upstream fix path; we discover it via scanner, not via advisory.
• Silent fork divergence. Fork is created, patched once, and then drifts until nobody knows what it derives from.
• Orphaned ownership. Package adopted by one team, that team reorgs, no one can say who is responsible for the pinned version.
• Scope overrun. Stakeholders assume "FAQ management" includes search, categorization, i18n, or public API access; the package provides none of that, and the gap surfaces after adoption.

Ramp-up. Engineering ramp-up is near zero — standard Laravel package conventions, and the feature is small. The real ramp-up is governance: getting a decision record written, getting the "archived dependency" policy agreed, and getting an owner assigned if a fork proceeds. That is TPM work, not developer work, and it should be budgeted as such. Assign one named owner before any code is copied.

Recommendation. Do not adopt. The package is archived, unmaintained since May 2022, pre-1.0, and has no adoption signal — for a feature that is a few days to rebuild on a stack we already control. The decision is build in-house; fork and vendor is an acceptable fallback only if Trov is already in production and delivery pressure is real, and in that case it must come with a named owner, an internal registry entry, and a planned retirement. Record the finding either way so the next reviewer does not re-open an archived dependency on the strength of a README.