Basev3 Laravel Package

Technical Evaluation

Architecture fit. filakitphp/basev3 is a Filament v3 starter kit / base scaffold, not a distributable library with a stable public API. Integration means generating a project from it and owning the resulting code, or vendoring a fork. That distinction drives everything below: there is no composer update upgrade path, so upstream releases are reference material and diff candidates, not dependency bumps we consume automatically. Fit is good for a greenfield internal back-office/admin panel; poor if we need a versioned, supportable dependency.

Integration feasibility. Bootstrapping is low-friction (days to a working panel). Tracking upstream is the expensive part — every release becomes a manual classification exercise. 3.3.56 is nominally a routine bump, but it is not purely cosmetic; two items touch things we would have to reconcile:

• PR #92 — "Use filament-user for the user model, resource and login." This changes the identity layer: the User model, the Filament resource, and the login flow. Highest blast-radius category in any Laravel app (guards, password broker, policies, factories/seeders, panel authGuard).
• PR #93 — pnpm → bun. Dev/CI toolchain only, but it invalidates pnpm-lock.yaml, existing Dockerfiles, and any internal pipeline that shells out to pnpm.
• Filament pin 3.3.55 → 3.3.56 plus ~13 dependabot dependency PRs (composer + actions groups).
• PR #91 — PHPStan on PHP 8.4. Signals 8.4 validation, but static analysis passing ≠ declared runtime support. Verify composer.json require before assuming 8.4 is supported.

Technical risk. Medium overall, with one high-severity element (auth) and several low-severity ones. Filament patch bumps occasionally require re-publishing assets/views, so "patch" is not automatically "safe." The volume of autos-merged dependabot PRs is a supply-chain review burden we inherit rather than a feature.

Key questions.

1. Is basev3 intended as fork-and-own, or is a distributable package on the roadmap?
2. Is the filament-user swap mandatory, and is there a documented migration for apps already built on 3.3.55?
3. What is the declared PHP matrix — is 8.4 supported or merely linted?
4. Is the patch number tracking Filament's version, or does it imply a semver contract of its own?
5. Maintainer concentration / bus factor, and is there a release cadence we can plan around?

Integration Approach

Stack fit. Laravel 11/12 + Filament v3 + Tailwind/Vite, now with bun for asset tooling. Aligns with our existing PHP platform. The mismatch is governance, not technology: we want pinned, auditable dependencies; this artifact wants to be a template.

Migration path. Two viable models — pick one explicitly, don't drift into the second by accident.

• Scaffold-once, own-the-code (recommended). Generate from 3.3.56, commit the upstream SHA, treat the result as our codebase. Upstream becomes a source of ideas and security-relevant diffs only.
• Vendored fork with a diff cadence. Justified only if we intend to contribute back or need upstream's CI hygiene. Requires a standing quarterly merge slot or it silently diverges.

For anyone already on 3.3.55, the only structural change is PR #92. Land it as its own PR, isolated from the dependency churn.

Compatibility. Verify Filament 3.3.56 ↔ filament-user constraint alignment before anything else. Confirm the PHP version matrix against our platform baseline. Confirm bun availability (or an accepted workaround) in build images and CI runners; keep pnpm locally if that's the faster path and decouple that decision.

Sequencing.

1. Read the actual 3.3.55...3.3.56 diff and label every PR: runtime / dev-only / CI-only. Don't work from the notes alone.
2. Spike the filament-user swap on a branch; inventory every touch point — User model, panel provider authGuard, login page, policies, factories, seeders, feature tests.
3. Validate in staging: filament:assets, filament:optimize, config/view republish check, php artisan about.
4. Treat bun adoption as a separate, independently revertible change.
5. Commit composer.lock and record the upstream reference SHA in the repo README.

Operational Impact

Maintenance. Because we own the code, "maintenance" means maintaining a Filament application — including absorbing Filament major version migrations (v4 readiness should be a tracked line item, not a surprise). The dependency-upkeep burden shifts to us entirely; upstream's 13 dependabot merges are hygiene we can imitate but not inherit.

Support. Small-maintainer OSS project, dependabot-dominated release cadence, a first-time contributor appearing in this very release. No commercial SLA. Escalation is GitHub issues only. Plan for self-sufficiency and name an internal owner for the Filament layer.

Scaling. Runtime scaling is unaffected by this release — that's Laravel/Filament territory (queue workers, asset caching, DB). The scaling risk is on the team axis: a forked codebase plus a pnpm/bun split raises onboarding cost and slows the second and third engineer.

Failure modes.

• Silent auth drift post-filament-user (wrong guard, stale password broker, broken remember-me, policies referencing the old model namespace). Highest severity, lowest detectability — surfaces only when login breaks in production.
• Asset staleness after the Filament patch bump (missing filament:assets, stale published views) — visible UI breakage, quickly diagnosed.
• CI breakage from pnpm→bun — blocks delivery, trivial to fix, easy to overlook.
• Upstream divergence if we fork without a merge cadence — accumulates invisibly until we can't reconcile.
• Supply-chain exposure from high-volume autos — pin, review lockfile diffs, don't blanket-accept.

Ramp-up. A Laravel/Filament-competent engineer is productive on the scaffold within days. The non-obvious cost is teaching the team our fork/upstream policy and the post-swap auth topology. Budget roughly one sprint for a safe adoption including auth reconciliation, CI updates, and staging validation; two to three days for a greenfield scaffold with no existing auth to reconcile.