Runtime Laravel Package

Product Decisions This Supports

• One execution seam for the whole product surface. Runtime::execute() becomes the single entry point for actions, data queries, form submissions and package-defined operations. That means one place to reason about authorization, validation and error responses instead of N controllers, Livewire methods and ad-hoc service calls — which is a product decision about consistency of behaviour across surfaces, not just an engineering nicety.
• Security posture as a shipped guarantee, not a code-review convention. Contexts are built from the guard plus TenantResolver/PanelResolver and explicitly never from request input; authorization is fail-closed via a single ExecutionAuthorizer (GateExecutionAuthorizer, ability gcego-runtime.execute). This supports committing to multi-tenant isolation and "deny by default" in customer-facing security questionnaires and enterprise procurement.
• Roadmap: modular upgrade tracks. Rendering has been extracted to gcego/rendering; runtime is now execution-only. This is a packaging decision worth endorsing — you can ship execution-kernel changes without dragging Blade/Livewire/styling along, and the dependency surface shrinks (gcego/components, livewire/livewire, illuminate/view dropped). It also means two artefacts to version and a coordinated upgrade when either moves.
• Build vs buy on the dispatch layer. If you are currently maintaining an in-house action/dispatcher layer with per-feature authorization checks, this replaces it with a typed, inspectable kernel (HandlerRegistry categories, ExecutionMiddleware, ObservesLifecycle). Buy is defensible when you have more than one entry surface and more than one team writing operations.
• Error and API contract decisions. ExecutionException + ErrorCategory (HTTP status and a public message) lets you standardize customer-facing errors and telemetry without leaking internals — directly supports SLAs, support tooling and localized/public error copy.
• Operability and incident response. ExecutionTrace, the OperationExecuting/OperationExecuted/OperationFailed events and RuntimeInspector/RuntimeDiagnostic give support and on-call a real answer to "what happened to this request?" — an argument for buying rather than hand-rolling logging around ad-hoc call sites.
• Scoping and safety rails as product constraints. ExecutionScope enforces nesting depth (execution.max_depth) and keeps the subject across nested operations, and the package refuses to execute before Core has booted. These are guardrails you can advertise as reliability features rather than debug in production.
• Testability supports release cadence. The facade is mockable (shouldReceive()), so QA can cover the kernel without standing up full feature flows — relevant if you gate releases on automated coverage.
• Trade-off to accept: identifier-only targets and data-only input make operations serializable and auditable, but they will not accept arbitrary objects. Any feature that needs rich in-memory payloads needs an adapter — budget for that in design, not in the estimate's "unknowns".

When to Consider This Package

Adopt when most of the following hold:

• You are on, or have a funded, scheduled plan for PHP 8.3+ and Laravel 13. This is the hard gate — the requirement is stated explicitly and is the single biggest adoption blocker for teams on Laravel 10/11/12 today. Confirm the upgrade date before committing.
• You are already in, or deliberately entering, the GCEGO ecosystem (gcego/core ^1.0, gcego/registry ^1.1, gcego/blueprints ^1.0). Runtime depends on all three; the value proposition is ecosystem-shaped, not standalone.
• You have multiple entry surfaces (HTTP actions, queries, form submissions, package-defined operations) and want one authorized, validated, observable path.
• You need fail-closed authorization and multi-tenant context you can evidence to customers, auditors or security reviewers.
• You want diagnostics and traces as a product capability (support tooling, incident review) rather than building it per feature.

Look elsewhere or defer when:

• You are on Laravel 12 or earlier / PHP 8.2 with no near-term upgrade — this cannot be adopted at all, so treat it as a roadmap input, not a current option.
• You want a rendering/component story. That now lives in gcego/rendering; runtime alone will not render anything, and Livewire blueprint hosting has been removed (Livewire\BlueprintHost, hosts.blueprint, gcego-runtime.livewire.* are gone).
• You are upgrading from a pre-1.0 runtime. This is a breaking release: Runtime::render(), renderAuthorized(), identityOf(), canRender(), hostedBlueprint() moved to Gcego\Rendering\RenderEngine (hostedBlueprint() → authorizedBlueprint()); view component renamed to <x-gcego-rendering::render>; config keys gcego-runtime.rendering.* / gcego-runtime.authorization.* → gcego-rendering.*; ability now gcego-rendering.render; RuntimeInspector::inspect() no longer takes a target; RuntimeReport lost renderers/missingRenderers; RenderDiagnostic → RuntimeDiagnostic; capability runtime.livewire removed. Migration is a real project, not a composer bump.
• Your scope is a handful of simple CRUD controllers. The abstraction cost (Operation objects, handler registration, context plumbing) will outweigh the governance benefit.
• You need a stable, vendor-neutral execution kernel with published LTS guarantees — this is a young 1.0 with a fast-moving dependency set.

Diligence items before signing off:

• The global alias \Runtime can collide with existing code or confuse IDE/static analysis; check your codebase for Runtime usage.
• Pipeline order is documented as resolve → authorize → handler → handler authorization → validation → middleware → handler; get written confirmation of exactly where middleware and validation sit relative to handler resolution, since this determines what a middleware can and cannot intercept.
• Confirm the support/security-patch policy for the four-package set and whether rendering and runtime are expected to version in lockstep.

How to Pitch It (Stakeholders)

For executives (one paragraph): This release delivers the GCEGO execution kernel — a single, governed entry point through which every action, query and form submission flows. It gives us a consistent, auditable authorization checkpoint that is deny-by-default and builds tenant/user context from the authenticated session rather than from request input, plus standardized error categories and execution traces. Commercially that means stronger answers in enterprise security reviews, fewer silent authorization bugs, and faster incident diagnosis. Two caveats to price in: it requires PHP 8.3 and Laravel 13, so it is tied to our framework upgrade; and it is a breaking release that splits rendering into a separate package, so adoption includes a migration task and a second dependency to track. Recommendation: approve as part of the Laravel 13 upgrade plan, not as a standalone lift-and-shift.

For engineering (summary): Replace ad-hoc dispatch with Runtime::execute() / attempt() / contexts(). Define immutable, identifier-only Operations (make, action, query, submit, on, with) and register typed handlers in HandlerRegistry (action, query, form, plus package-defined categories) implementing OperationHandler/ActionHandler/QueryHandler/FormSubmissionHandler, with optional ValidatesOperation, AuthorizesOperation, ObservesLifecycle and ExecutionMiddleware. Context is a trusted, immutable ExecutionContext from ExecutionContextFactory (guard + TenantResolver/PanelResolver) — never from request input. Authorization is fail-closed through ExecutionAuthorizer/GateExecutionAuthorizer (ability gcego-runtime.execute), configurable via gcego-runtime.execution.ability, .middleware, .max_depth. Results and failures come back as ExecutionResult/ExecutionTrace or the ExecutionException hierarchy with ErrorCategory for HTTP status and public messaging. Use RuntimeInspector (RuntimeDiagnostic, RuntimeReport::$handlers) to verify handler/category/override registration in CI, and hook OperationExecuting/OperationExecuted/OperationFailed for logging and metrics. Nested operations are isolated by ExecutionScope and depth-limited; execution is refused before Core has booted. Rendering is no longer in this package — pull gcego/rendering and use Gcego\Rendering\RenderEngine (authorizedBlueprint() replaces hostedBlueprint()) and <x-gcego-rendering::render>.

Ask: sequence adoption behind the Laravel 13 / PHP 8.3 upgrade; scope a dedicated migration ticket for the rendering extraction and config/ability renames; add CI coverage that asserts RuntimeInspector output matches the expected handler registry before each release.