Console Kernel and Command Execution

Purpose and Scope

This document describes the Console Kernel's architecture and its role in managing the lifecycle of command-line interface (CLI) commands. The kernel is responsible for bootstrapping the application, discovering and registering commands from multiple sources, and executing them through the Artisan console application.

For information about command discovery mechanisms and registration, see Command Discovery and Registration. For task scheduling configuration, see Task Scheduling. For testing console commands, see Console Command Testing.

Overview

The Console Kernel (Hypervel\Foundation\Console\Kernel) serves as the central orchestrator for all CLI operations. It bridges the application container with the Symfony Console-based Artisan application, manages command lifecycle, and coordinates the bootstrap process specific to console operations.

Sources: src/Console/Kernel.php1-438 src/Console/Contracts/Kernel.php1-97

Kernel Architecture

Class Structure

The kernel implements the KernelContract interface and uses the HasPendingCommand trait to support pending command functionality during testing.

Sources: src/Console/Kernel.php32-90 src/Console/Contracts/Kernel.php13-97

Core Dependencies

Dependency	Type	Purpose
ContainerContract $app	Application Container	Provides dependency injection and service resolution
EventDispatcherInterface $events	Event Dispatcher	Dispatches application lifecycle events
ApplicationContract $artisan	Console Application	Underlying Symfony Console application wrapper

Sources: src/Console/Kernel.php77-80

Configuration Properties

Property	Type	Description
$commands	array	Explicitly registered command class names
$closureCommands	array	Closure-based commands registered via command()
$commandPaths	array	Directories to scan for command discovery
$commandRoutePaths	array	Paths to files containing closure command definitions
$loadedPaths	array	Directories that have been loaded via load()
$commandsLoaded	bool	Flag indicating if commands have been collected
$bootstrappers	array	Bootstrap classes to execute during initialization

Sources: src/Console/Kernel.php41-75

Bootstrap and Initialization Process

Bootstrap Sequence

The kernel constructor immediately dispatches the BootApplication event and registers a callback to define the console schedule after the application has fully booted.

Sources: src/Console/Kernel.php77-90 src/Console/Kernel.php95-120

Bootstrappers

The kernel uses a predefined set of bootstrappers that execute in sequence when the application has not been bootstrapped:

1. RegisterFacades (Hypervel\Foundation\Bootstrap\RegisterFacades) - Registers class aliases for facade pattern
2. RegisterProviders (Hypervel\Foundation\Bootstrap\RegisterProviders) - Registers service providers
3. BootProviders (Hypervel\Foundation\Bootstrap\BootProviders) - Boots all registered service providers

Sources: src/Console/Kernel.php71-75 src/Console/Kernel.php103-107

Lazy Initialization

The Artisan console application is lazily initialized on first access via getArtisan(). This ensures the application is fully bootstrapped before command execution begins.

Sources: src/Console/Kernel.php402-417

Command Collection and Registration

Command Collection Flow

The collectCommands() method aggregates commands from multiple sources:

1. Loaded Paths: Commands discovered from directories added via load() or addCommandPaths()
2. Hyperf Config: Commands listed in config/commands.php (for Hyperf compatibility)
3. Annotations: Commands decorated with @Command annotation
4. Closure Commands: Commands registered via command() method
5. Explicit Commands: Commands in the $commands property

Sources: src/Console/Kernel.php149-192

Command Loading and Priority

The loadCommands() method ensures Hyperf framework commands are registered before application commands. This allows application commands to override framework commands if they share the same name.

Sources: src/Console/Kernel.php194-214

Command Registration

Individual commands are registered through the registerCommand() method:

The pendingCommand() method (from HasPendingCommand trait) wraps the command for testing purposes, returning null if the command should be skipped.

Sources: src/Console/Kernel.php219-226

Command Discovery

Automatic Discovery

The kernel supports automatic command discovery when using the base kernel class without extension:

Discovery is automatically disabled when the kernel is extended, allowing application developers to override the commands() method for explicit registration.

Sources: src/Console/Kernel.php109-144

Directory Loading

The load() method adds directories to loadedPaths for command discovery:

Method	Purpose
load(paths)	Add directories to be scanned immediately
addCommandPaths(paths)	Add directories for automatic discovery during bootstrap
addCommandRoutePaths(paths)	Add files to be required for closure command definitions

Sources: src/Console/Kernel.php332-389

Command Execution

Execution Entry Points

The kernel provides multiple entry points for command execution:

• handle(InputInterface, OutputInterface): Primary entry point called by the framework
• run(?InputInterface, ?OutputInterface): Alternative entry point for standalone execution
• call(string, array, ?OutputInterface): Programmatic execution by command name

Sources: src/Console/Kernel.php95-98 src/Console/Kernel.php233-236 src/Console/Kernel.php434-437

Command Execution Lifecycle

The console application uses a container-based command loader, resolving command instances from the DI container on demand.

Sources: src/Console/Kernel.php233-236 src/Console/Kernel.php408-410

Closure Commands

Registration

Closure commands provide a lightweight way to define simple commands without creating command classes:

If commands have already been loaded when command() is called, the closure command is registered immediately. Otherwise, it's stored and registered during the next loadCommands() call.

Sources: src/Console/Kernel.php311-327

Schedule Integration

Schedule Resolution

The kernel integrates with the task scheduling system through the Schedule class:

The kernel binds a Schedule factory to the container after the application boots, configuring it with:

• Timezone: From app.schedule_timezone config (fallback to app.timezone)
• Cache Store: From cache.schedule_store config or SCHEDULE_CACHE_DRIVER environment variable

The schedule() method is a hook that application developers override to define scheduled tasks.

Sources: src/Console/Kernel.php87-89 src/Console/Kernel.php256-299

Programmatic Command Execution

Command Invocation Methods

Method	Signature	Purpose	Returns
call()	call(string $command, array $parameters, ?OutputInterface $output)	Execute command by name with parameters	Exit code
all()	all()	Get all registered commands	Command array
output()	output()	Get output from last command execution	String output

Sources: src/Console/Kernel.php233-252

Usage Pattern

The kernel's call() method enables programmatic command execution from within the application:

This pattern is commonly used in:

• Testing (see Console Command Testing)
• Application code that needs to trigger commands
• Background job processors
• HTTP endpoints that trigger maintenance commands

Sources: src/Console/Kernel.php233-236

Artisan Application Management

Application Instance Access

The kernel manages a singleton instance of the ConsoleApplication:

The getArtisan() method ensures:

1. Console application is instantiated with framework dependencies
2. Initial commands are resolved
3. Container-based command loader is configured
4. Application is bootstrapped
5. All commands are loaded and registered

Sources: src/Console/Kernel.php402-417

Setter Method

The setArtisan() method allows direct injection of a console application instance, primarily used for testing purposes:

Sources: src/Console/Kernel.php422-425