Core Laravel Package

Product Decisions This Supports

• Build vs. buy for the platform kernel. The "boring but expensive" layer of a modular admin product — package discovery, dependency-ordered startup, extension registration, capability gating, lifecycle events, diagnostics — is now a versioned dependency instead of an internal framework team's roadmap item. If you were scoping an in-house bootstrap/kernel effort, this is a credible substitute worth pricing against 3–6 engineer-months plus indefinite maintenance.
• Modular admin/extensibility roadmap. Required vs. optional dependencies, declared version compatibility, and extension capability prerequisites give you a real contract for third-party or internal "extensions." That directly supports decisions about opening a plugin surface, tiering features by capability, and shipping add-on modules without forking core.
• Release gating and change management. gcego:plan (read-only startup preview) plus gcego:diagnose --json --strict are CI-shaped primitives. This supports deciding to enforce a "plan before deploy" and "diagnose in strict mode" gate on every release, and gives you a defensible answer to "how do we know a new extension won't break boot order?"
• Supportability and SLA commitments. Stable diagnostic codes, severity levels, remediation text, redaction, and a deliberately separate public health summary mean support tickets can carry machine-readable, shareable state. This underpins decisions on on-call runbooks, customer-facing status pages, and whether support can be tiered without engineering in the loop.
• Upgrade and platform-version planning. The hard constraints (PHP 8.3+, Laravel 13, Composer 2.2+) force an explicit decision on your Laravel upgrade window rather than letting it drift — and conversely, block adoption if you're mid-cycle on an older Laravel.
• Performance budget for boot time. Opt-in detailed profiling lets you measure startup cost only when you need it, so profiler overhead isn't a default tax. Useful for deciding whether extension count is a viable scaling axis.
• Feature-level "can we ship this?" reviews. Typed startup events and retry-safe initialization make failures legible in product terms (which extension, which capability, which phase) instead of a blank white screen — a genuine reduction in incident ambiguity.

When to Consider This Package

Adopt when:

• You are building or maintaining a modular admin/back-office product with extensions, add-ons, or per-tenant capability sets, and boot-order or initialization correctness is currently tribal knowledge.
• You are on, or committed to, Laravel 13 and PHP 8.3+ within the relevant planning horizon (note the ceiling: PHP below 9.0).
• You want operational tooling as a first-class feature — CI-readable diagnostics, strict-mode checks, redacted health summaries — rather than writing it yourself.
• You are comfortable with single-vendor risk in exchange for a coherent, opinionated contract, and are willing to pin to ^1.0 and track the changelog.
• A pilot is feasible: you can trial it on one internal, non-customer-critical admin module before committing the platform to it.

Look elsewhere or defer when:

• You are on Laravel 10/11/12 or PHP 8.0–8.2. There is no stated backwards-compatibility path here; adoption becomes an upgrade project, which is a different and much larger decision.
• You need a general-purpose module loader with a broad community, tutorials, and Stack Overflow coverage. Mainstream module/package-loader packages, or plain Laravel service providers with a small internal convention, will be less capable but far better supported.
• You need enterprise procurement artifacts — published LTS/support policy, security disclosure process, third-party audit, published benchmark numbers — that aren't yet in evidence.
• Your "admin studio" is not GCEGO-shaped. The kernel is opinionated about registration closing before resolution, capability prerequisites, and extension contracts; if your architecture disagrees, you will fight it.
• You depend on Packagist discovery for your build pipeline and can't or won't add a VCS repository entry as an interim step.

Due diligence to close before committing: confirm package indexing status on Packagist; request the actual benchmark figures (PHP 8.5/Laravel 13 is stated, but numbers are not); confirm the support/versioning policy for the 1.x line; confirm whether the "public health summary" redaction has been threat-modelled for your data classes; verify whether diagnostics leak package names or paths you consider sensitive.

How to Pitch It (Stakeholders)

For executives (one paragraph): We are evaluating a small, first-stable-release Laravel component that provides the startup, extension and diagnostics foundation our admin platform would otherwise have to build and maintain ourselves. The commercial case is avoided engineering cost and reduced upgrade risk: dependency-ordered startup with declared version compatibility turns "will this release boot?" from a hope into a checkable step, and the built-in diagnostics and health summary reduce mean-time-to-diagnose in production and in support. The trade-offs are real but bounded — it is new (v1.0.0), from a single vendor, and requires PHP 8.3+ and Laravel 13, so it is only viable alongside our platform upgrade path. Recommendation is a time-boxed pilot on one internal module, not a platform-wide commitment.

For engineering leads: The release is a coherent kernel, not a grab-bag. Registration closes before dependency resolution and initialization hooks — that ordering guarantee is the headline, because it is the thing bespoke bootstrapping code always gets subtly wrong. You get required/optional dependencies with declared compatibility, capability prerequisites, typed startup events, retry-safe initialization, and opt-in profiling, plus diagnostics with stable codes, severity, remediation and redaction, and gcego:diagnose --json --strict as a CI gate. gcego:plan gives a read-only startup preview, which is the piece that makes change review meaningful. Quality signals are reasonable for a 1.0: manifest validation, Pint, maximum-level PHPStan, 239 tests, benchmarks run on PHP 8.5/Laravel 13. Auto-discovery means low integration cost; config is publishable. Caveats to plan around: Laravel 13-only, no stated LTS or security policy, no published benchmark numbers, Packagist indexing pending so we'd pin via VCS initially.

For security and operations: Diagnostics are designed for sharing — stable codes, severity, remediation hints, explicit redaction, and a deliberately separate public health summary — which is the right shape for a status endpoint or a support handoff. Strict mode gives us a non-zero-exit operational check we can wire into deploys. Ask for the redaction threat model and confirm the public summary cannot surface internal package names, versions or filesystem paths. Also confirm the release/security disclosure channel before this touches customer-facing infrastructure.

Ask: Approve a two-to-four week pilot on one internal admin module, with success criteria being (a) gcego:plan output is accurate and reviewable in PRs, (b) strict-mode diagnose runs clean in CI, (c) measured boot-time delta is acceptable under our realistic extension count, and (d) the vendor answers the support-policy and benchmark questions.