Filanitics Laravel Package

Technical Evaluation

Architecture fit: Not assessable, and the TPM's job is to say so out loud rather than let a capability description stand in for an artifact. The advertised surface — Filament-native widgets for stats, charts, and trends, configurable metrics and data sources, date-range filtering, publishable config, custom models and queries — maps cleanly onto a real product need (self-serve analytics inside an admin panel without building reporting screens). But the v1.0.0 release note states the package is "just a husk from the original, no need to install from here." That means there is no service provider, plugin registration, config schema, widget contract, migration set, or view layer we can inspect against our Laravel topology, our Filament panel structure, our tenancy model, or our data sources. Architecture fit is not applicable, not "unknown," and should be recorded that way.

Integration feasibility: Blocked at the gate, not at the technical layer. The first feasibility question a TPM asks about any dependency is not "does the API work" but "is there an installable artifact published by someone who stands behind it?" Here the publisher has pre-emptively answered no in the release channel. Building a roadmap commitment on a package whose own maintainer disclaims it is the single cheapest way to acquire schedule risk.

Technical risk: High and blocking.

• Provenance. "Husk from the original" tells us the code here is not canonical and that something was removed or replaced. We cannot determine what, and no maintainer will tell us.
• Supply chain. A published package name that the legitimate project says not to install is a namespace-squatting and future-takeover hazard. Composer will resolve it without complaint; a later re-registration of the name flows straight into a routine composer update.
• Signals of abandonment. 0 stars, a maturity score of 0.3, a single release dated 2025-04-11 whose content is a do-not-use notice. MIT licensing is permissive but irrelevant when there is no maintained code to license.
• No visible quality gates. No tests, CI, static analysis, support matrix, or changelog history in evidence — and the release note makes spending effort to find them a poor use of engineering time.
• Audit exposure. If this name sits anywhere in our graph, the release note is effectively a disclosure that we depend on an artifact its own publisher does not endorse.

Key questions:

1. Who surfaced this package, and what job were they trying to do — which specific dashboard, metric, or stakeholder request motivated it?
2. What is the canonical upstream package, and is it actively maintained with a supported Laravel/Filament matrix?
3. Is this name a legitimate fork, a mirror, or a collision/typosquat of the original?
4. Does any direct or transitive dependency in our services require this name today?
5. Is there a successor package or documented deprecation path we should target instead?
6. What is the Packagist ownership and release history — was v1.0.0 the first release, or did it replace substantive prior versions?
7. If we adopted the upstream original, what would governance require for the data it reads (PII, tenant isolation, retention) given its "custom models and queries" extensibility?
8. What alternatives already exist in the estate — another Filament plugin, an internal metrics endpoint, or a BI tool — that satisfy the same job to be done?

Integration Approach

Stack fit: Claimed, not demonstrated. Filament's plugin and widget APIs have changed materially across major versions, and without a composer.json we cannot infer the Laravel version floor, PHP constraint, panel registration mechanism, or asset pipeline expectations. Do not reason from the package name, from the marketing description, or from assumed parity with earlier versions of the original.

Migration path: The direction of travel is away from this name, not toward it.

1. Not yet installed — add a denylist entry, close the evaluation, and move the underlying capability request to a different owner or option.
2. Installed anywhere — audit composer.json and composer.lock across all services, identify who requires it (direct or transitive), and file a routine remediation ticket.
3. Direct dependency — check whether the canonical upstream is still resolvable and maintained. If yes, repoint to it with a pinned constraint; if no, plan a functional replacement rather than a version bump.
4. Transitive dependency — raise it with the intermediate maintainer. Do not vendor, fork, or patch around a husk.

Compatibility: Unassessable by construction. There is no constraint set, support matrix, or changelog to triangulate from, and the release note implies deliberate structural divergence from whatever the original was. Treat compatibility as a policy-based "no" rather than a technical "maybe."

Sequencing:

• Now: Denylist the name, notify platform and security owners, confirm no production lockfile references it, and capture the decision in the dependency register with the release-note quote attached.
• This sprint: Complete the transitive audit and identify the canonical upstream and two credible alternatives that address the original dashboard request.
• Next: Choose between repointing to upstream and solving the capability differently; scope as routine maintenance, escalating only if the audit finds it in a production path.
• Ongoing: Reconsider only if the upstream project publishes a clear successor and this name is formally marked abandoned on Packagist.

Operational Impact

Maintenance: Zero expected, which is the risk rather than the relief. An admin-panel plugin lives directly on the Filament and Laravel upgrade treadmill; with no maintainer, every major framework release becomes an unplanned blocker on a feature the business already believes is delivered.

Support: None. There is no vendor, no SLA, no issue triage, and no internal escalation path that does not dead-end at a release note telling us not to install it. Any executive asking "who fixes this if it breaks" gets an honest "nobody."

Scaling: Moot at runtime; material organizationally. The longer this name sits on an approved or "to evaluate" list, the more engineers independently rediscover it, assume it is the real package, and burn a half-day each confirming it is a placeholder. The compounding cost is duplicated evaluation and shadow adoption, not load.

Failure modes:

• Install-time: upstream dist deletion or tag removal breaks composer install for a locked consumer — a cold-cache build failure with no fix available from the publisher.
• Namespace takeover: the name is re-registered and a routine update pulls unreviewed code into the build. Highest severity, and the strongest argument for denylisting today.
• Silent divergence: a developer assumes parity with the original, integrates against APIs the husk stripped out, and the gap surfaces during a demo or a release.
• Delivery credibility: a stakeholder-facing dashboard is promised from a package that contains no dashboards, converting a dependency problem into a roadmap commitment problem.
• Audit finding: security or compliance flags the dependency after deployment, forcing unplanned remediation on someone else's timeline.

Ramp-up: Effectively zero, which is a trap. There is no README, no usage example, no tests, and no config to read — so the real onboarding cost is unlearning the assumption that this is usable. Mitigate by recording the decision, the rationale, and the release-note quote in the dependency register so the next TPM or engineer inherits the conclusion instead of repeating the investigation.