Kernel Laravel Package

Product Decisions This Supports

• Build vs. buy for the admin/back-office layer. orchestra/kernel is the bootstrapping core of Orchestra Platform, a batteries-included Laravel admin and extension system. Evaluating it forces the roadmap-level question: adopt a platform-style admin layer, or compose best-of-breed packages (Filament, Nova, Backpack, Laravel starter kits, custom) on plain Laravel. That is an architecture and headcount call, made once and deliberately, not drifted into via a single bootstrap commit.
• Whether modularity is a real product requirement or an internal preference. The package is a working reference for extension discovery, lifecycle hooks, and extension-aware provider/route registration. Useful input when deciding whether a plugin system is customer-facing (marketplace, partner extensions, per-tenant feature packs) or just code organization that first-party service providers already give you for free.
• Kernel/entrypoint abstraction as a design pattern — with or without adoption. It cleanly separates HTTP/console bootstrapping and exception handling from domain code. Directly applicable to modular monoliths and multi-tenant architectures at the cost of a source read and zero dependencies.
• Legacy keep-vs-migrate scoping. Zero stars and zero dependents is a clear negative signal for any inherited Orchestra codebase. This supports deprecation timelines, migration sizing, and a "no new features on this stack" policy — not feature prioritization.
• Upgrade-coupling budgeting. Every Laravel minor becomes a coordinated two-party upgrade against an external maintainer's schedule. That is a recurring, unbudgeted line item and a direct input to release-cadence commitments. The only release artifact surfaced here is v6.0.0, targeting Laravel 8 — treat the resulting lag as a fixed tax, not a contingency.
• Explicitly not supported: customer-facing feature prioritization, pricing, packaging, or growth experiments. This is infrastructure plumbing. It should not consume roadmap capacity on its own merits, and a PM should push back on any framing of it as a customer-visible capability.

When to Consider This Package

Consider it when:

• You already run Orchestra Platform and need to understand, pin, or patch the kernel/entrypoint layer. In that context this is the correct layer, and replacing it is the larger effort.
• You are scoping a greenfield Orchestra-based application where the platform commitment is already banked and the plugin system is a stated product requirement.
• You want a reference implementation of a custom Laravel kernel with bootstrappers and extension-aware providers before designing your own. Cheap to read, genuinely clarifying, zero dependency cost.
• You are maintaining a legacy Orchestra/Laravel admin app and need to size a migration off it.

Look elsewhere (the default) when:

• Starting anything new. Laravel's own Illuminate\Foundation HTTP and Console kernels already do this, with active maintenance, security support, and a hiring pool that has read the code.
• You need modern PHP/Laravel support. The release history on offer stops at Laravel 8 — a schedule and security-patch risk you inherit, not one you can fix internally.
• You need an admin panel. Filament, Nova, Backpack, or the Laravel starter kits are materially better-supported bets with vendors behind them and real ecosystems.
• You require a vendor SLA, long-term support, or documented patch latency in lockstep with Laravel security releases. Assume none of these exist.
• Dependency-graph exposure matters: zero dependents means no ecosystem safety net, no peer pressure keeping it working, and effectively a single-maintainer bus factor until proven otherwise.
• Vanilla Laravel plus first-party service providers meets the requirement. The kernel then buys you nothing while costing you a substitution of the bootstrap sequence, HTTP pipeline, and console registration — high blast radius for a problem most applications do not have.

How to Pitch It (Stakeholders)

For executives: Do not budget around this package. It is the plumbing layer of a niche, very-low-adoption Laravel admin platform — architecturally interesting, commercially inert. Recommendation: no new spend, no adoption. Where it already exists in our estate, treat it as tech debt with a named owner, a documented migration path, and a dated exit. The strategic value is the decision it forces — platform-style admin versus composing best-of-breed packages — and that decision should rest on support, hiring, and security grounds, not on this codebase's merits. The real cost of adoption is recurring: every Laravel minor becomes a coordinated two-party upgrade with no SLA and thin community support, and incident debugging moves into code paths most Laravel engineers have never read. Ramp-up is roughly a sprint for a mid-level engineer to become productive, more for credible on-call coverage.

For engineering: It is a thin, Orchestra-specific wrapper over Laravel's HTTP and console kernels, adding custom bootstrappers, exception handling, and extension registration. Reading it is inexpensive and clarifying for entrypoint and modularity design — do that. Do not add it as a new dependency. If we inherit it, isolate it behind our own kernel/entrypoint abstraction so a one-PR swap back to Illuminate\Foundation stays available and we remain on a supported Laravel upgrade path. Two non-negotiables if it stays: exact version pins with no caret ranges, and a bootstrapping parity harness that diffs container bindings, registered providers, middleware stack order, and artisan list output against vanilla — because the dangerous failure mode is silent divergence, where the app boots and mostly works while behaving subtly differently in production. Record the Laravel-minor-to-Orchestra-version coupling in the dependency register, and validate the bootstrappers explicitly under Octane, since they run once and request-scoped state leakage is miserable to diagnose.