Filament Tool Kit Laravel Package

Technical Evaluation

Architecture fit. Unchanged and now better evidenced. akira/filament-tool-kit remains a Laravel/Filament (TALL stack) add-on, and 2.0.0 confirms the surface area is reusable form components rather than pages or resources — the release adds "bio and social media fields to form components and JSON files." That is exactly the leaf-dependency profile we want: additive, scoped to the admin surface, no domain-model or persistence change implied. If anything, the feature set looks narrower than a "tool kit" name suggests, which is favorable for audit cost.

Integration feasibility. Mechanically unchanged (composer require, auto-discovery, class usage or ->plugin()). Two new facts materially change the diligence:

• The package is at 29 releases (1.28.0 → 2.0.0), not the "thin release history" the prior assessment assumed. That corrects a prior error in our read and suggests sustained iteration.
• The project shows real release engineering: a PR-based workflow (#70), Dependabot-managed dependency bumps, and a GitHub-Actions release-to-Discord integration. That is CI/tooling maturity well above the single-author-skeleton profile we previously inferred from the placeholder description.

The open question is no longer "does it install" but what 2.0.0 breaks. A major bump whose only listed feature is additive field additions implies either (a) undocumented breaking changes, or (b) major-version bumps used as feature markers rather than semver signals. Both matter to us; (b) is arguably worse, because it makes version numbers non-predictive.

Technical risk. Reduced on abandonment, elevated on version discipline.

• Bus factor still one. Unchanged. Mitigated only by MIT licensing and presumed small code surface.
• Semver discipline — new, elevated. 1.28.0 → 2.0.0 for what reads as additive fields. Either the changelog is incomplete or the major was triggered by something not documented (Filament v4 namespace adoption, dropped PHP/Laravel ranges, removed components, config schema change). Until we diff the tag, we cannot tell a safe additive bump from a forced migration.
• Release velocity without a support policy. 29 releases is activity, not commitment. No stated support window, no LTS line, no documented deprecation process in the notes.
• Filament major tracking — partially de-risked. A 2.0.0 released 2025-09-30 is plausibly the Filament v4 alignment. If so, the v3/v4 stranding risk we flagged drops, but we must confirm which line 2.x actually supports.
• "JSON files" — new ambiguity. Shipped JSON may be translations, config presets, or serialized form schemas. If it is the latter, it is closer to persisted state than pure presentation and inherits upgrade obligations.
• Mitigating factors unchanged: MIT, small surface, audit-in-an-afternoon.

Key questions.

1. What actually broke in 2.0.0? Full compare diff between 1.28.0 and 2.0.0 — required before any pin decision.
2. Which Filament major does 2.x target — v4 only, or v3 and v4 both? Does a 1.x maintenance line still exist for v3 panels?
3. Did PHP/Laravel/illuminate/* minimums move in 2.0.0?
4. What are the shipped JSON files — translations, config, or persisted form schema?
5. Are the bio/social fields presentation-only, or do they introduce validation, storage, or model assumptions?
6. Is a 1.x branch still receiving fixes, or is 2.x a hard cutover?
7. Any documented deprecation/migration guide for 2.0.0? Absence is itself the answer.
8. Is the major bump policy documented anywhere (e.g. "majors track Filament majors")?

Integration Approach

Stack fit. Unchanged. Near-native if our admin is Filament-based; not a bridge from Nova or hand-rolled Blade, and still not a justification for a Filament migration on its own.

Migration path. Same additive, reversible pattern, with the audit step now mandatory rather than prudent:

1. Tag diff first — compare 1.28.0..2.0.0 to enumerate actual breaking changes; read composer.json at both tags.
2. Vendor audit — clone, run the suite locally, composer why-not against our lockfile.
3. Spike in a throwaway branch against a real panel; exercise every exported component, explicitly including the new bio/social fields.
4. Wrap behind a thin internal adapter so a swap to native Filament components or a fork is a one-file change.
5. Pilot in a single low-stakes internal admin panel — not client-facing, not revenue-path.

Compatibility. The prior recommendation to pin an exact version rather than a caret range is now validated, not merely cautious — a caret range on this package would have auto-upgraded us across a major. Pin "akira/filament-tool-kit": "2.0.0" (or the last 1.x, if our panel is on Filament v3). Confirm the Filament major alignment before feature evaluation; a 2.x-only package in a v3 panel is a dead end. Verify PHP and illuminate/support ranges at the 2.0.0 tag specifically — majors are where floors move.

Sequencing. Tag diff → vendor audit → spike → adapter wrap → pilot panel → 30-day soak → revisit. Gate production-wide use on the same two signals as before, plus one new one: (a) it survives one Filament point release without patching, (b) we have a named internal owner capable of forking, and (c) the 2.0.0 breaking changes are enumerated and we can articulate why they don't affect us. If (c) cannot be satisfied from the diff, treat the package as undocumented-source-only and price the audit accordingly. Fallback remains native Filament components — a day or two of hand-rolling versus an abandoned dependency in the admin path.

Operational Impact

Maintenance. Materially better than the prior read: active iteration through 29 releases, Dependabot-driven dependency hygiene, PR review flow, automated release tooling. That is a maintained project, not a portfolio artifact. It is still a single-maintainer project with no dependents to absorb the burden, so fork-and-own remains the contingency plan, but the probability of needing it in the next 12 months is lower than previously assessed. Budget for the fork as an option, not a likelihood.

Support. Unchanged: no SLA, no commercial backing, no escalation path. GitHub triage only. Internal first-line support must be able to read and patch source. The 2.0.0 notes are the tell — a major release with no migration guidance means upstream support is "read the diff," and our support model must match that.

Scaling. Unchanged and low-risk. Presentational components cost little against Filament's Livewire render budget. Still watch any shipped widgets or table columns that issue their own queries (N+1 on large list pages, surfaced late by exports/reports), and verify asset-publishing behavior under config:cache, view:cache, and filament:cache-components. The new JSON files warrant a specific check: confirm whether they are read at runtime (and therefore cacheable) or written at install time (and therefore a republish obligation).

Failure modes.

• Semver surprise (new, top of list). Majors that don't correspond to documented breakage — or breakage that does — mean version numbers cannot drive our upgrade automation. Exact pins and a changelog read are the only defense.
• Panel-bricking. A plugin throwing in register()/boot() takes down the whole admin panel. Re-test boot order against our other plugins at 2.0.0.
• Upgrade stranding. Reduced but not eliminated: if 2.x is Filament-v4-only and we're on v3, the pin becomes a wall until we upgrade the panel.
• Silent view overrides. Published Blade views diverging from Filament internals after an upgrade — higher exposure now that the package tracks Filament majors closely.
• Asset/JSON drift. Published CSS/JS or JSON going stale after composer update without a republish — classic, hard-to-diagnose admin styling and form-schema failures.
• Maintainer abandonment. Lower probability, unchanged impact.

Ramp-up. Low for Filament-fluent engineers; the component API should feel native. Thin documentation still pushes cost onto source reading — budget roughly half a day per engineer plus the spike, and add the tag-diff review (2–3 hours) as a fixed cost. Write the internal usage note at the end of the pilot; it is the artifact that makes the adapter-wrap decision durable after the original spike author moves on.

TPM recommendation. Upgrade from "conditional, low-priority" to conditional, worth a scheduled spike. The maturity signals that drove the prior skepticism — thin release history, skeleton-grade project hygiene — did not survive contact with the release feed, and the prior assessment should be corrected on that point. The residual risk has shifted from "nobody maintains this" to "versioning is unpriced," which is a cheap risk to retire: a tag diff and a one-day spike settles it. Do not adopt on the revenue path or in client-delivered code without an explicit fork-and-own decision recorded. If 2.0.0's breaking changes turn out to be undocumented structural changes rather than the advertised additive fields, revert to the prior low-priority posture.