Kernel and front-controller lifecycle

Bounded candidate reference — 2026-10-20: 0.2.0-rc.1 is committed locally through 84f415b3098af5653577b2c65eea31fca21df79c, unpublished and not production-approved; stable PHP >=8.5.11 <8.6.0 is required. This is documentation, not adoption: this knowledge base retains its installed 0.1.0-rc.1 dependency and PHP 8.2.11 local profile. Dated PHP 8.2 evidence is historical; earlier dirty-source reports retain their original test provenance, not retroactive clean-commit proof. Candidate examples are illustrative: API signatures were reviewed, but candidate code was not executed by this editorial update. See current checkpoint, open criteria and adoption boundary.

Kernel implements KernelInterface while retaining the concrete class name used by the extracted framework. It owns the dynamic request lifecycle; the front controller remains the only intended public PHP entry point.

Request sequence

• public/app.php starts a protective output buffer, loads Composer and the selected validated configuration, and invokes the application composition root.
• It creates one immutable Request and calls Kernel::handle().
• The kernel begins one http-request container scope, runs ordered middleware and routing, and converts failures through ExceptionHandler.
• Every buffer opened during dispatch is closed. Any accidental output is discarded and becomes a safe internal response; its contents are never retained in logs or error pages.
• The container scope is reset in finally, including after errors.
• The front controller closes its bootstrap buffer, sends exactly one Response, then calls Kernel::terminate().

The kernel does not start sessions, connect to a database/provider, render a view, or perform product logic merely by booting. Those side effects occur only when selected application middleware or handlers resolve the relevant lazy dependencies.

Termination hooks

terminateWith() registers ordered TerminationHook objects or callables. Each hook runs after response sending inside an isolated output buffer. Output is discarded, failures are safely logged, and later hooks still run.

Termination is best effort. Critical state changes, messages, payments, notifications, inventory effects, and other durable work must be committed to an outbox/queue before returning the response. A termination hook is never a delivery guarantee.

Runtime and correlation context

RuntimeContext accepts bounded non-secret environment, version, and release identifiers. ContextLogger attaches those trusted values to every event so a caller cannot spoof them. Per-request context also accepts a validated correlation ID from the request attribute or response X-Request-ID header.

Unexpected request failures receive a cryptographically random reference in their safe response and structured log event. DEV/TEST may include the exception class when application debug is explicitly enabled; raw exception messages, output contents, SQL, provider bodies, and secrets remain excluded.

Editorial provenance

Source: docs/KERNEL_LIFECYCLE.md. Source SHA-256: f80412c177be9c702dda44c6e8fcf976890f5af7a9498caf9a1bf1d9a3984bf0.

Framework candidate reference; editorial checkpoint 2026-10-20. See candidate status and adoption boundary.