Core Laravel Package

Product Decisions This Supports

• Build vs. buy for back-office tooling — decided at the suite level, never at this package. lara-zeus/core has zero standalone product value. It is the shared kernel (base classes, traits, config namespace, helpers, service-provider scaffolding, publishable assets) beneath the Zeus family — Sky panels, Bolt forms, Rain tables, settings and translation tooling. The decision on the table is "do we standardize internal admin CRUD on Laravel + Filament + Zeus rather than hand-rolling screens?" Core arrives transitively as a consequence of that answer. Fund the capability, inherit the kernel.
• Roadmap sequencing when admin work is the critical-path blocker. The value proposition of the suite is compressing weeks of CRUD, settings pages, and form scaffolding into days. That is worth funding specifically when internal-tool work is gating a customer-facing deliverable. Frame the approval as buying back engineering weeks against a named, dated milestone — not as "adding a dependency."
• Scope discipline for the pilot — one named capability or nothing. Any business case must be written against a concrete sibling capability ("dynamic admin forms in 3 weeks instead of 8") with a metric that moves. Core's cost of ownership is a line item inside that brief. If no sibling package is funded, there is no decision to make and the evaluation should be closed.
• Dependency-risk register entry, sized by blast radius. Five stars, zero recorded dependents, and a bus factor near one is a low-maturity signal. The PM artifact here is a risk-register line scoped by exposure — "internal dashboards only" versus "backs something a customer touches" — not a feature-backlog line. The opportunity score (~49) reflects an unserved niche, not production hardening; make sure stakeholders do not read it as a quality score.
• Lock-in and exit-cost estimation, done before scale. Because core is abstracted beneath higher-level Zeus packages, our integration surface stays small if we confine the suite to one module behind a thin adapter. Quantify the exit path before three teams build on it, not after. A trivially legal MIT fork is not the same thing as a cheap operational exit.
• Upgrade-cadence and maintenance budgeting. A recent release date implies active upkeep, but reconcile it against Packagist before writing a pinning policy on top of it. Budget a named quarterly-review owner for the lara-zeus/* family — the recurring cost is dependency stewardship, not the initial install. The assumption "we can track Laravel/Filament majors" requires revalidation each cycle, not faith.
• Procurement simplification. MIT licensing means no commercial negotiation, no legal review queue, no per-seat cost. This removes the usual friction from a pilot approval and lowers the internal cost of saying yes to a timeboxed spike.

When to Consider This Package

Consider it — via the Zeus suite, never as a direct install — when:

• You are already on Laravel + Filament + Livewire, and the pain is repetitive admin/CRUD scaffolding rather than unique domain logic. If your differentiator is the admin screen itself, buy nothing.
• The team is small and internal-tool velocity is worth more than long-term dependency independence.
• You can pin exact versions, commit the lockfile, and name a person who owns periodic dependency review. Without that owner, do not adopt.
• Exposure is non-critical-path: internal dashboards, back-office, content management — where a breaking change is an inconvenience, not an outage.
• MIT licensing matters (it does here — no procurement cycle, no commercial negotiation).
• You have a timeboxed compatibility spike available to confirm the current Laravel/Livewire/PHP matrix and the Vite/Tailwind asset pipeline before committing. Core ships CSS that expects Tailwind content globs pointed at vendor/lara-zeus/*; that is the most common silent breakage.
• You are prepared to write tests around every core surface you touch, because with zero dependents you are the first to hit the edge cases.

Look elsewhere when:

• The package would sit on a customer-facing or revenue-critical path. Low adoption means we discover the edge cases ourselves, in production.
• You need a support contract, SLA, or security disclosure process. Community-only maintenance with a bus factor near one does not provide these — and "core" being infrastructure does not change that. It is a naming coincidence, not a support tier.
• You would composer require lara-zeus/core directly without extending its base classes, implementing its contracts, or overriding its views. That converts an inherited dependency into a declared one — a decision worth writing down, and usually the wrong one.
• Your team is not on Filament or is deliberately avoiding it. The kernel's conventions only pay off if you adopt the siblings that resolve against it.
• You cannot absorb a lockstep upgrade: a core bump can force a sibling bump, which can force a Laravel/Livewire bump. Narrow constraints are the most common reason a team "can't take the security patch."
• The work is one screen, once. Scaffolding overhead exceeds the savings; hand-roll it.
• Your organization requires vendor accountability — a named party who answers when something breaks. Decide in writing, in advance, what the response is when an unpatched defect blocks you: patch-and-wait, or fork.

How to Pitch It (Stakeholders)

One line for executives: "This is not a product we buy — it is the shared foundation underneath a set of admin-tooling packages. The decision is whether we standardize our back-office screens on that suite to reclaim engineering weeks on [named deliverable]; the foundation comes along for free, and we keep it off anything customers touch."

The honest framing, stated up front: lara-zeus/core has no standalone ROI and never will. If anyone finds themselves justifying it on its own merits, the evaluation has gone wrong. The business case is always written against a named sibling capability — "dynamic admin forms in three weeks instead of eight" — with core carried as a cost-of-ownership line inside it. Say this out loud in the room; it buys credibility for everything that follows.

What we are actually asking for: a timeboxed spike on one sibling capability, behind a feature flag or route group, confined to a single module and wrapped in a thin adapter so the exit is a refactor rather than a rewrite. Success criteria and a kill date defined before the first line of code. The go/no-go gate stays cheap because the blast radius was capped by design.

For engineering, the operative constraints:

• Treat core as a transitive dependency, not a declared one. Verify with composer why lara-zeus/core before assuming anything about it.
• The sibling packages are the specification — documentation is effectively absent, so read vendor/lara-zeus/core/src and read how a sibling consumes it.
• Extend, don't fork. The extension ladder, safest first: config → narrowly published view overrides → subclassing base classes → implementing contracts directly → forking as last resort. Move down a rung only when the one above genuinely cannot express the need.
• Pin the whole lara-zeus/* family to a mutually compatible set, commit the lockfile, and gate every bump behind a branch with a full CI run.
• Keep Zeus migrations and models out of the domain schema — read through the adapter, never join from domain code.
• Maintain a one-page internal note of the core surface we 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 it is the first thing we will want when the maintainer goes quiet.

What we are explicitly accepting: no SLA, no security disclosure process, bus factor near one, and no peer evidence to lean on. We mitigate with exact pinning, a named quarterly dependency-review owner, fast tests that run on every lockfile diff, and non-critical-path exposure only. We document the fork path but do not take it until a first production use proves durable.

What we will report back: days saved against the named deliverable, the size of our actual dependency surface, and a recommendation on whether to extend the suite to a second capability — or unwind it while unwinding is still cheap.