Core Laravel Package

Technical Evaluation

Architecture fit. lara-zeus/core is a kernel, not a capability. It ships service-provider scaffolding, base classes, traits, a config namespace, helpers, and publishable assets that sibling packages (Sky, Bolt, Rain, settings and translation tooling) resolve against. Architecturally this is a convention layer: it earns its place only when we adopt at least one Zeus capability package, at which point core arrives transitively whether or not it ever appears in our composer.json. Installed alone it produces an installed package and effectively nothing observable — there is no standalone ROI to evaluate. The fit is strong for Laravel + Filament + Livewire back-office CRUD where the pain is repetitive scaffolding, and weak anywhere unique domain logic or a customer-facing path is involved. It also imports a diffuse global surface: convention-registered config keys, helper functions, and Blade directives, plus CSS/JS that assumes our Tailwind content globs reach into vendor/lara-zeus/*.

Integration feasibility. Mechanically trivial, epistemically expensive. composer require works; understanding what entered the container does not. Documentation is effectively absent — the 5.1.1 release notes are literally "Docs" and "update css" — so the real specification is the service provider, the published config, and the sibling package that consumes them. That is feasible for a small team and a contained module, but it is a discovery cost we must budget explicitly rather than assume away.

Technical risk. Five stars and zero recorded dependents means no peer evidence: we will be the discoverer of edge cases. Bus factor is approximately one; there is no support contract, SLA, or security disclosure process. The realistic failure modes are not crashes but pollution and drift: global helper/directive naming collisions in an app we also control; stale config cache masking changes; Tailwind globs that work in npm run dev but break in npm run build; and lockstep versioning across the Zeus family where a core bump forces a sibling bump that forces a Laravel/Livewire bump. Narrow version constraints are the most common reason a security patch becomes untakeable. The opportunity score (49.41) signals an unserved niche, not production hardening — stakeholders should not read it as a quality score. One metadata item also needs reconciliation before we build policy on it: the stated 2026-04-24 release date should be verified against Packagist.

Key questions. (1) Which named sibling capability justifies this, and what metric moves? If no sibling is funded, there is no decision to make. (2) Is exposure strictly internal — dashboards, back-office, content management — where a break is an inconvenience rather than an outage? (3) Who is the named quarterly dependency-review owner? (4) What is our containment boundary — one module behind a thin adapter — and what event triggers the exit path? (5) What is our written response when an unpatched defect blocks us: patch-and-wait, or fork? (6) Which Laravel/Livewire/PHP and Tailwind/Vite matrix have we actually verified in a build, not assumed?

Integration Approach

Stack fit. Non-negotiable prerequisite: Laravel with Filament, Livewire, and a Tailwind/Vite pipeline. If we are not already on that stack, or if the admin pain is domain logic rather than CRUD scaffolding, this is the wrong tool and the evaluation should stop.

Migration path. Core should arrive transitively via a sibling, not be declared directly. Adding a direct requirement converts an inherited dependency into a declared one — a decision worth recording — and is justified only when we subclass core base classes, implement its contracts, or override its views. The migration sequence we should run: adopt one sibling capability in one module; confine every LaraZeus\* import behind a single adapter (one bridge file) so domain code never touches Zeus types; publish config selectively with --tag-scoped publishing and commit the diff as a review event; then wire assets.

Compatibility. Pin exact versions for the entire lara-zeus/* family and commit the lockfile. Gate every bump on a branch: composer update "lara-zeus/*" --with-dependencies --dry-run, inspect the lockfile diff for the Laravel and Livewire bumps it drags in, and run full CI. Use composer why-not to name the exact blocking constraint when a resolution fails. Configure Renovate/Dependabot to surface transitive changes, not just declared ones. Timebox a compatibility spike up front to confirm the framework matrix and the asset pipeline; do not carry this as an assumption.

Sequencing. (1) Confirm the transitive need with composer why and verify the Packagist release metadata. (2) Read the service provider and config — this is the highest-value ten minutes in the whole engagement. (3) Build the adapter seam before writing any feature code. (4) Publish config narrowly and commit the diff. (5) Add vendor Blade paths to the Tailwind content globs and validate in a real production build, not just dev. (6) Put the first capability behind a feature flag or route group so go/no-go is cheap. (7) Add an upgrade-canary test suite around every core surface we touch. (8) Stand up the review cadence before scaling past one team.

Operational Impact

Maintenance. Budget a named quarterly review owner, not a one-time evaluation. The operating artifact is a one-page internal note listing the core surface we actually depend on — classes subclassed, traits used, config keys read, views overridden, helpers called. That note is what makes the pinning policy reflect real usage and is the first thing we will want if the maintainer goes quiet. Keep Zeus migrations and models out of the domain schema: read through the adapter, never join from domain services.

Support. None in the contractual sense. Community-only maintenance with a bus factor near one means we own triage. Decide now, in writing, between patch-and-wait and fork; MIT makes forking trivially legal and operationally expensive, so document the fork path and do not take it until a first production use proves durable. Move down the extension ladder — config, then narrowly scoped view overrides, then subclassing, then implementing contracts, then fork — only when the level above genuinely cannot express the need.

Scaling. The package itself scales as far as internal dashboards need. The risk scales with adoption: exit cost grows with each team and each surface that touches Zeus directly, which is why the adapter seam and the containment boundary are the load-bearing controls, not the version pins. Quantify the exit path before three teams build on it, not after.

Failure modes to watch. Global helper and Blade directive collisions in the host app; stale config cache producing "my change did nothing"; Tailwind glob divergence between dev and build; a sibling bump dragging framework upgrades past our constraints; subclassed protected internals changing silently between core minors; and upstream abandonment with no disclosure channel. Each of these is detectable with cheap instrumentation — a key dump after config:clear, a production build in CI, a lockfile diff gate, and per-surface tests.

Ramp-up. The onboarding cost is reading vendor source, and it is real. A small team absorbs it faster than a large one because the surface stays bounded. Treat the sibling package as the de facto spec, keep the internal surface note current, and revalidate the "we can track Laravel/Filament majors" assumption at every quarterly review rather than holding it on faith.