Sparky Laravel Package

Technical Evaluation

There is a blocking ambiguity: the metadata does not describe the artifact. The registry description presents a Filament sparkline plugin (inline SVG trend lines, table column, dashboard widget, no JS build step). The repository, the v0.1.0 release, and the bundled agents/skills tree describe a Filament starter kit (Filament + Blueprint + Boost + Flux + Pest 4). These are different products with different risk profiles and different evaluation costs. At 13 stars, 0 dependents, and a single release, there is no ecosystem signal to triangulate. No spend or sprint allocation should be approved until the pinned commit is inspected for composer.json, a panel provider, and agents/skills/. Record the resolution in writing — the description will otherwise be fed to coding agents, which will confidently generate sparkline code against a starter kit.

Architecture fit depends entirely on that resolution.

• If sparkline plugin (H1): fit is high and cheap. A Blade-rendered inline SVG column plus a widget is low-coupling, sits inside any Filament panel, and carries no runtime service. Risk is concentrated in the "no extra JS build step" claim — verify it is genuinely inline SVG and not a headless Chart.js wrapper, because the latter reintroduces an asset pipeline and a dependency we would have to own.
• If starter kit (H2): it is not a package in the dependency sense. It is a tree you consume once, at project creation. Fit is greenfield-only, and only if the admin layer is already committed to Filament + Livewire. If admin surfaces are Inertia/Vue/React, the kit's opinions actively fight the codebase. Retrofitting its conventions onto a mid-flight project is the single most expensive mistake available here.

Integration feasibility. H1: one composer require, one afternoon, reversible. H2: no composer require at all — no upgrade channel, no stated support policy, one release, one maintainer. Consumption path is composer create-project into a sandbox, or fork-and-pin into an org template repo. Feasibility is high; supportability is the constraint, not installability.

Technical risk, ranked.

1. Artifact identity unresolved (blocks everything).
2. Single maintainer, single release, zero dependents — upstream is inspiration, not a dependency feed.
3. Free-edition Flux is a hard boundary in the shipped skills; any Pro component in shipped views means broken templates and a violated house guideline simultaneously.
4. Livewire 4 behavior changes (wire:model child-event semantics, wire:scroll, $wire.$js) can break silently and are exactly the class of bug that eats a week.
5. Opinionation liability compounds — every accepted opinion is a decision we no longer own.

Key questions for the author or the commit. Which artifact is this, and which one is intended going forward? What is the upgrade policy against Filament and Livewire majors? Is the test suite green on a clean checkout? Is Flux usage strictly free-edition? Is the skills tree maintained, or a one-time snapshot? What is the intended consumption model — create-project, fork, or package?

Integration Approach

Stack fit (H2, the material case): Laravel + Filament 4 + Livewire 4 + Tailwind 4 (CSS-first) + Pest 4 (feature/browser/architecture) + Flux free edition + Filament Blueprint + Boost guidelines + agent skills. This is a coherent current-generation bet. Adopting it is a platform decision — it implicitly standardizes Filament for internal tooling, which drives hiring, component vocabulary, and how much custom Blade we write. That belongs in a platform review, not a per-project backlog item. (H1 fits any Filament panel with no stack implication at all.)

Migration path: there isn't one, and that is the point. Treat the repo as a snapshot, not a feed. Vendor it into the org template repo at a pinned commit and own the migration treadmill explicitly. The realistic extraction play for existing apps is diff-and-copy:

composer create-project awcodes/sparky /tmp/sparky-sandbox
laravel new /tmp/baseline
diff -rq /tmp/sparky-sandbox /tmp/baseline

The dev-only layer — Pest config, architecture tests, Boost guidelines, Tailwind v4 config, agents/skills/ — is the cheapest and most transferable cut, and it stands alone even if every application-code opinion is rejected.

Compatibility. Verify composer.json and package.json constraints against our supported PHP/Laravel baseline before anything else. The bundled skills assume the Filament 4 / Livewire 4 / Tailwind 4 / Pest 4 generation; if constraints disagree, the skills are actively misleading and will poison agent output. Pin PHP, Laravel, Filament, Livewire, and Tailwind versions in the template repo and treat upgrades as scheduled, owned work.

Sequencing (one engineer, one week, hard gate):

1. Resolve artifact identity at the pinned commit. Document it.
2. Read version constraints; confirm generation alignment.
3. php artisan test on a clean checkout — a red suite on day one is a conversation-ending finding, not a backlog item.
4. Click through auth: login, profile, password reset. This is the surface most likely to be stubbed or Flux-Pro-dependent.
5. Read agents/skills/* and the panel provider before writing feature code.
6. Build one real vertical slice end to end — model, migration, factory, Blueprint resource, filters, a relationship form, a Pest feature test. Time it.
7. Decide against pre-written criteria: hours to first feature vs. baseline, percentage of kit kept vs. deleted, defect and review-churn rate on agent-authored PRs.

H1 sequencing is trivial by comparison: install into a sandbox panel, wire one column and one widget against real data, verify dark mode and theming, ship or discard.

Operational Impact

Maintenance — we own it. No upstream diff, no merge path, no stated upgrade policy. A copied tree means every Filament and Livewire major is a manual coordinated migration against a codebase we forked. Budget it as a recurring platform line item, not a one-time scaffold cost. Track deletion volume during evaluation — the percentage of the kit kept versus removed is the best single proxy for opinionation fit. Above roughly 40% deleted, the kit is fighting us and we should have installed Filament directly.

Support. One maintainer, 13 stars, zero dependents, one release (v0.1.0, 2026-01-28). No SLA, no security advisory channel, no triage process. The CVE path is us. This is acceptable for a dev-only scaffold we fork and pin; it is not acceptable for anything on a runtime request path — which is another argument for confirming H1 vs. H2 before adoption.

Scaling. Team-level upside is real: one golden path removes the 3–10 days each squad re-derives on every greenfield Filament build, and the bundled skills encode house conventions as machine-readable guidance so coding agents generate in-pattern code rather than inventing it. The scaling risk is convention fragmentation — the Filament vs. Flux boundary must be written down on day one (Filament components inside resources and widgets; Flux free-edition for standalone Livewire pages; plain Blade for anything neither covers) and enforced as a Pest architecture test, because a rule in a test fires on agent PRs and a rule in a README does not. The metric that tells us whether this worked is review-churn rate on agent-authored PRs; if reviewers keep rewriting agent output to match house style, the skills aren't binding and the differentiator is gone.

Failure modes to pre-register.

• Metadata/artifact mismatch propagating into agent prompts and onboarding docs.
• Red test suite on first checkout, discovered after a sprint is already committed.
• Pro-edition Flux components shipped in views — broken templates plus a violated guideline.
• Blueprint regeneration clobbering hand-tuned form/table code; mitigate by keeping generated code recognizable and pushing customization into actions, separate schemas, and table configurators.
• Silent Livewire 4 behavior breaks presenting as "should work but doesn't."
• Upgrade cliff at the next Filament major with no upstream to diff against.
• Scope surprise: no billing, teams, invitations, or subscription gating. If the brief implies SaaS scaffolding, budget it separately — it is not in the box.

Ramp-up. The agents/skills/ tree is the onboarding asset: point CLAUDE.md or the agent system prompt at agents/skills/<area>/SKILL.md explicitly and make it the reference standard, not background reading. Human ramp-up is roughly a day for a Filament-fluent engineer to read the panel provider, skills, and architecture tests, plus the vertical-slice exercise. Recommendation: gate at one engineer-week with written success criteria either way; approve the cheap H1 evaluation immediately if the artifact is confirmed as the sparkline plugin, and route H2 to a platform build-vs-adopt review rather than a package-procurement decision.