Refactor WebAppAdapter::start() and ConsoleAppAdapter::start() into structured runtime pipelines

[armanist]

Summary

Refactor WebAppAdapter::start() and ConsoleAppAdapter::start() so runtime execution is no longer handled as flat sequences of loosely connected method calls.

Introduce structured runtime pipelines for web and console flows, similar in spirit to boot stages, so execution becomes explicit, extensible, and ready for future lifecycle hooks.

Why

The constructor already has a clear staged boot flow through BootPipeline, but runtime execution is still handled ad hoc.

In WebAppAdapter::start(), current responsibilities are mixed together in one method:

• preflight handling
• route resolution
• not found handling
• language loading
• debug info logging
• view cache setup
• cached response lookup
• route dispatch
• middleware execution
• response sending
• request cleanup

In ConsoleAppAdapter::start(), runtime execution is also flat:

• core command registration
• app command registration
• command validation
• command execution

This makes both runtime flows harder to reason about and leaves no clean structural boundaries for future lifecycle hooks.

Goal

Create proper runtime execution structures for both web and console adapters before introducing broader lifecycle hooks.

Runtime flow should become stage-based rather than remaining collections of ad hoc method calls.

Proposed Direction

Introduce dedicated runtime pipelines instead of reusing BootPipeline directly.

Suggested runtime structures:

• RequestPipeline
• RequestContext
• ConsolePipeline
• ConsoleContext

These should carry evolving runtime state rather than relying on loose locals and inline control flow.

Suggested Web Runtime Stages

A reasonable first breakdown of the current web flow is:

• HandlePreflightStage
• ResolveRouteStage
• HandleRouteNotFoundStage
• PrepareRequestStage
• DispatchRequestStage
• SendResponseStage
• CleanupRequestStage

Notes:

• PrepareRequestStage should cover:
  • language loading
  • debug info logging
  • view cache setup
• DispatchRequestStage should cover:
  • cached response lookup
  • route dispatch
  • middleware execution

Suggested Console Runtime Stages

A reasonable first breakdown of the current console flow is:

• RegisterCoreCommandsStage
• RegisterAppCommandsStage
• ValidateCommandStage
• RunCommandStage

If needed, command registration can later be collapsed into a single preparation stage, but the first refactor should prioritize clarity.

Scope

This ticket is about refactoring runtime structure for both adapters.

It should not yet define the full lifecycle hook contract. That should come after runtime flow has proper structural boundaries.

Acceptance Criteria

• WebAppAdapter::start() is refactored into a structured runtime pipeline
• ConsoleAppAdapter::start() is refactored into a structured runtime pipeline
• runtime state is carried through dedicated runtime context objects rather than loose local variables
• web runtime responsibilities such as language loading and view cache handling are preserved in the new structure
• console runtime responsibilities such as command registration, validation, and execution are preserved in the new structure
• the new runtime structures are suitable for later lifecycle hook integration
• tests are updated as needed

Notes

Relevant code:

• src/App/Adapters/WebAppAdapter.php
• src/App/Adapters/ConsoleAppAdapter.php
• src/App/Traits/WebAppTrait.php
• src/App/Traits/ConsoleAppTrait.php
• src/Router/RouteDispatcher.php
• src/Middleware/MiddlewareManager.php
• src/App/BootPipeline.php

This ticket should be completed before introducing broader runtime lifecycle hooks.