Evolutionkitv5 Laravel Package

Product Decisions This Supports

• Build vs. buy for back-office tooling — this package ships a Filament-based admin surface (models, resources, login) on top of an Evolution API integration. The decision it informs is whether to buy/borrow an admin console skeleton or spend sprint capacity building auth, resource scaffolding, and CRUD screens from scratch.
• Multi-role / multi-tenant access model — release 5.9.0 extracts user and admin concerns into separate packages and wires login through them. That is a product-architecture signal: role separation is now a first-class, reusable concern rather than something bolted onto a single app. Use it to decide whether to standardize on this pattern or keep roles app-local.
• Platform currency on the roadmap — the bump to Filament v5.9.0 plus PHPStan running on PHP 8.4 tells you the maintainer is tracking the current Laravel/Filament major line. That supports a "stay on current major, budget annual upgrade work" roadmap assumption rather than a frozen-legacy assumption.
• Candidate use cases — internal ops consoles, WhatsApp/Evolution API dashboards for support or sales teams, and MVP back offices where time-to-first-screen matters more than long-term framework independence.
• What this release does not support — 5.9.0 is almost entirely CI hygiene, dependency automation, and an internal auth/resource refactor. Do not read it as evidence of a product roadmap (no new user-facing capability) or of API stability guarantees (no documented breaking-change policy).

When to Consider This Package

Adopt when:

• You are already on Laravel with Filament v5 and want an admin kit rather than a framework-agnostic one.
• You need an Evolution API–style integration surface plus auth and role separation quickly — the 5.9.0 refactor means you inherit a user/admin split you would otherwise design yourself.
• You are comfortable owning a fork or reading source as documentation; small single-maintainer packages are best treated as accelerators, not platforms.
• Your team runs PHP 8.4 and wants CI/PHPStan coverage from upstream rather than adding it yourself.

Look elsewhere when:

• You need a vendor SLA, security disclosure process, or formal deprecation policy — none is evidenced here.
• You are pinned to Filament v4 or earlier, or to a legacy PHP version; the package now tracks v5.9.0 and validates against 8.4.
• You require documented migration guides. This release changes models, resources, and login flow with no stated breaking-change notes — for a codebase you don't own, that is the highest-risk item here, not the dependency bumps.
• You want a long-lived, low-churn dependency. Five of nine merged PRs are CI/dependabot work; the maintenance signal is real but the surface area is thin.

Immediate action if you adopt: pin the version, then regression-test authentication, authorization, and Filament resource access before and after upgrading from 5.8.2 — the user/admin package extraction touches exactly those paths.

How to Pitch It (Stakeholders)

For executives: This is a low-cost accelerator, not a strategic platform bet. It gives us a working admin console with login and role separation on day one, on the current Filament v5 line, which saves early build time. The trade-offs are concentration risk — a single maintainer — and coupling to Filament's major version, which means a recurring annual upgrade cost. Recommend a time-boxed pilot with a defined exit path to a fork we control, not a multi-year commitment.

For engineering: Treat 5.9.0 as a maintenance release with one non-trivial change. Dependency and CI updates are safe; the extraction of models, resources, and login into user/admin packages is a structural refactor with no published migration notes. Upgrade in a branch, diff the auth and resource layers, and run the full authorization test suite before merging. Assume you will own the fork for anything business-critical, and budget for Filament v5→v6 when it lands.