Blatui Admin Laravel Package

Technical Evaluation

Architecture fit The v0.6.0 release does not change the core runtime bet — blatui-admin remains an opinionated Blade + Livewire admin scaffold — but it introduces a second integration surface that the prior assessment did not account for: developer-tooling context. The package now ships AI guidance assets (resources/boost/guidelines/core.blade.php and resources/boost/skills/blatui-admin-development/SKILL.md) and detects laravel/boost in the host app during blatui:admin install. In practical terms the package is now both a runtime dependency and a coding-agent instruction source for our repository.

Fit assessment splits accordingly:

• Runtime fit: unchanged. Good for Livewire-first Laravel monoliths; poor for Inertia/SPA or teams standardized on Filament/Nova.
• Tooling fit: attractive only if the team has adopted Laravel Boost (or an equivalent agent-guideline pipeline). Teams without Boost get a prompt they will decline and dead weight in the vendor tree. Teams with Boost inherit third-party instructions that shape how agents generate code in our codebase — a governance question, not just a convenience feature.

The presence of docs/decisions/ADR-010-... is the most significant architectural signal in this release: the project now maintains architecture decision records. That is a materially different maturity posture from the v0.0.1 baseline.

Integration feasibility Still composer require plus an Artisan installer, and the blast radius is now larger:

• The installer executes detection logic against the host app (laravel/boost presence) and prompts interactively to run php artisan boost:update --discover. Interactive prompts inside install commands are a known automation hazard — confirm a --no-interaction/--force path exists, or CI and scripted provisioning will hang.
• The same prompt can invoke a second package's Artisan command in our app, mutating Boost's discovered-context state. That is transitive write behavior we did not previously have to vet.
• The .gitattributes change (removing /resources/boost export-ignore) reveals that earlier dist packages omitted these assets. Good that it is fixed; the concerning part is that dist-vs-source drift existed at all. Assume other export-ignore rules may cause similar divergence and verify the installed vendor tree matches the repo tree.

Feasibility: high for a spike, medium for greenfield internal admin, still low for retrofit. The new AI-context feature does not change that curve — it adds a review step rather than removing one.

Technical risk

• Maturity (improved): we are now at 0.6.0 with 0.5.5 immediately prior, i.e. meaningful release cadence since the 0.0.1 baseline. Version progression plus ADRs plus a documented distribution strategy is a credible early-stage signal, not a hobby-project signal.
• Bus factor (unchanged): still a single author (@x-multibyte). No second maintainer or reviewer is evidenced in the release notes.
• Process (mixed): ADR discipline is a genuine positive. Release-on-merge automation from v0.0.1 remains in place, so regressions can still ship without a human gate. No test coverage, license, or security policy signal appears in this release body.
• Supply chain (elevated): the package now ships instructions intended to influence AI code generation in consuming repos. Treat SKILL.md and core.blade.php as executable-adjacent content: a compromised or careless upstream edit could steer an agent toward unsafe patterns in our codebase without any runtime change. This is a new, low-visibility risk class.
• Prompt/automation risk: interactive Boost detection during install is a new failure mode for scripted environments.
• Version coupling (new): the Boost integration assumes a compatible laravel/boost API surface; Boost is itself evolving, so this adds a second version-matrix axis.
• Coupling (unchanged): the installer still forces Livewire into the dependency graph.

Key questions

1. (carried) What Laravel/PHP/Livewire/Tailwind ranges are declared, and do they install cleanly against our current pins?
2. (carried) Exactly which files does the installer create or modify, and is there a documented --dry-run or uninstall path?
3. (new) Is the Boost integration strictly opt-in? Does a --no-boost / --no-interaction flag exist, and does a declined prompt leave the host app untouched?
4. (new) Does the installer call boost:update --discover itself or only print the command? If it calls it, we need to know what Boost mutates.
5. (new) What exactly do SKILL.md and core.blade.php instruct an agent to do, and does any of it conflict with our house standards (testing framework, migration conventions, auth patterns)?
6. (new) Can the Boost assets be excluded from the install entirely (env toggle, config), and are they versioned in lockstep with the scaffold API they describe?
7. (new) Are there other export-ignore entries causing dist/source divergence, and is there CI that diffs the built dist against the repo?
8. (carried) Is there a test suite or static analysis, and is there any published coverage signal?
9. (carried) What is the package's scope, license, security policy, and support channel?
10. (carried) What is the roadmap to 1.0, and is a second maintainer planned?

Integration Approach

Stack fit Target remains: supported Laravel/PHP, Blade-based or Livewire-willing, no competing admin framework (Filament remains the incumbent comparator and must be re-benchmarked against 0.6.0). Add a second qualifier for the new surface: adopt the Boost integration only for teams already running Laravel Boost with a defined agent-guideline review process. Everyone else should install with Boost detection suppressed.

Migration path Still effectively greenfield-only. There is no upgrade guide evidenced between 0.0.x and 0.6.0, and the version gap is now large enough that any earlier spike output should be discarded and re-run, not upgraded. Do not attempt to layer this over an existing admin surface.

Compatibility Must confirm before commitment:

• Laravel 10/11/12 and PHP floor; Livewire major (v3 expected).
• laravel/boost supported version range, and behavior when Boost is present but older than expected.
• Frontend build assumptions (Vite vs Mix, Tailwind config ownership, asset publish collisions).
• Coexistence with Breeze/Jetstream/Fortify and existing route prefixes/migrations.
• Behavior under --no-interaction in CI.

Sequencing

1. Pin exactly: 0.6.0, no caret range. Release-on-merge automation is still in effect.
2. Re-baseline the spike: discard prior spike artifacts; fresh Laravel app, snapshot composer.json/composer.lock/git status, install, diff.
3. Test both install modes: once with Boost absent, once with Boost present, and once non-interactively. Confirm the declined-prompt path is clean.
4. Content review: read resources/boost/guidelines/core.blade.php and SKILL.md in full before enabling them anywhere an agent operates. If we keep them, vendor them under our review process and treat upstream changes as reviewable diffs.
5. Dependency audit: composer show --tree, license check, and a dist-vs-source file comparison against the GitHub tree.
6. Isolation: admin-only route group plus feature flag in a non-customer-facing internal tool.
7. Vendor contingency: still plan for a fork; upstream responsiveness remains unproven at the maintainer level.
8. Re-evaluate at 0.7.x/1.0, or on any signal of a second maintainer, published tests, or a security policy.

Operational Impact

Maintenance Unchanged in kind, slightly improved in evidence. ADR discipline means design rationale is now capturable and reviewable upstream — a real reduction in black-box risk. Counterweights: single maintainer, automated release-on-merge, and a version cadence fast enough (0.5.5 → 0.6.0 within the observed window) that pinning and periodic review are mandatory rather than optional. New maintenance line item: AI guidance drift — the shipped SKILL.md describes a scaffold API that will change, and stale agent instructions silently degrade code quality in a way that produces no error. Budget for periodic upstream diff review of the Boost assets, and be prepared to fork.

Support Still no documented support channel, contribution guide, or security disclosure process in the release body. ADRs partially compensate by making design intent self-documenting, which reduces the volume of questions we would need to ask. Escalation remains "open a GitHub issue and wait." Internal ramp-up material is still ours to write, now including a policy on whether agents may consume third-party Boost skills.

Scaling No package-level scaling change. Livewire's server-round-trip model remains appropriate for internal admin panels at tens of concurrent operators and inappropriate for high-concurrency public surfaces. Continue to watch scaffolded list views for N+1s, unbounded pagination, and oversized serialized component payloads. The Boost integration is a build-time/dev-time concern with no runtime scaling impact — though bundling the context assets adds a small amount to dist size and vendor tree noise.

Failure modes

• Interactive installer prompt: hangs CI, container builds, or scripted provisioning when Boost is present and no non-interactive flag is honored.
• Transitive Boost mutation: installer-triggered boost:update --discover alters another package's state in our app without an obvious audit trail.
• Agent instruction conflict: upstream SKILL.md guidance contradicts our conventions and is applied silently by coding agents, producing plausible-but-wrong code across many PRs.
• Dist/source divergence: export-ignore mistakes ship an incomplete package — already observed once and now fixed; assume the class of bug recurs.
• Installer mutation: partial or failed install leaves composer.json/composer.lock inconsistent; still no documented rollback.
• Asset publish collisions: overwriting host tailwind.config.js, app.css, or Vite entry points; silent until build time.
• Livewire version conflict: installer pulls a Livewire version that breaks existing host components.
• Silent breaking change: 0.x patch published automatically on merge with no migration note.
• Abandonment: package goes stale against a new Laravel major; no fork plan blocks the framework upgrade.
• Supply-chain compromise: write access to dependency manifests plus influence over AI-generated code — a wider blast radius than at v0.0.1.

Ramp-up Runtime ramp-up unchanged: low for Livewire/Blade-fluent teams, one to two weeks plus spike cost for teams without Livewire exposure. New onboarding work: reviewing and ratifying the shipped Boost guidelines, deciding whether agents may use them, and documenting that decision. Assume roughly one additional engineer-day for the first team and near-zero marginal cost thereafter. Do not count on external tutorials given the package's age.

Recommendation: upgrade the classification from unvetted trial to qualified trial. The ADR practice and version cadence are meaningful positive signals, and the release is worth re-spiking — but the package is still 0.x, single-maintainer, release-on-merge, and now carries AI-instruction supply-chain risk. Approve for a disposable spike in an internal, non-customer-facing tool only; do not adopt in production until version constraints, installer blast radius (including non-interactive behavior), test coverage, and a support commitment are established.