[Feature]: Refactor stack type handling from plugins via extensible stack-type implementations

[nacidai]

Description

This refactoring eliminates if/elif anti-patterns by using a direct handler dispatch model where handlers directly process operations without complex double dispatch callbacks.

The purpose is to eliminate the if/elif anti-pattern in stack type handling across the Muto Composer system. The refactoring introduces a double dispatch pattern where stack type handlers delegate to plugins, inverting control and simplifying both stack handlers and plugin implementations.

Initially support archive and json style stack in addition to legacy models.

Suggested Solution

Design Principles

The architecture has been streamlined from a complex double-dispatch pattern to a direct handler invocation model:1. Stack Type Categories:

• Properly Defined Solutions: Stacks with metadata + launch structure where metadata.content_type defines the type (e.g., stack/json, stack/archive)

• Before (Complex): Plugin → Handler → Plugin.accept_stack() → Handler.process_operation() - Legacy Format: Fallback validation for unrecognized formats to check if they match legacy launch/json format (raw nodes/composables)

• After (Simple): Plugin → Handler.apply_to_plugin() → Direct operation processing

2. Double Dispatch Pattern: Stack handlers delegate plugin-specific logic to plugins themselves using a visitor-like pattern, avoiding hardcoded logic in handlers

This eliminates unnecessary indirection while maintaining clean separation of concerns.

3. Plugin Extensibility: Pipeline plugins (Compose, Launch, Provision, etc.) define their own operations that stack handlers can delegate to

Core Architecture

Architecture Diagrams

1. Stack Type Handlers

Stack Handler Class Design with Double Dispatch

Handlers encapsulate all logic for a specific stack type. Each handler:

• Detects if it can handle a payload (can_handle())```mermaid

• Directly processes all operations for that stack type (apply_to_plugin())classDiagram

• Contains operation-specific logic (_start_*(), _kill_*(), _apply_*(), _provision_*()) class StackTypeHandler

**Base Handler Interface

class StackTypeHandler(ABC):    }

    """Abstract base class for stack type handlers."""    

        class StackContext {

    @abstractmethod        +stack_data: Dict~str,Any~

    def can_handle(self, payload: Dict[str, Any]) -> bool:        +metadata: Dict~str,Any~

        """Determine if this handler can process the given payload."""        +operation: str

        pass        +logger: Optional~Any~

        }

    @abstractmethod    

    def apply_to_plugin(self, plugin: BasePlugin, context: StackContext, 

                       request, response) -> any:    

        """    class Plugin {

        Process the stack operation directly.        <<interface>>

        Handler contains all operation logic for its stack type.        +accept_stack(handler: StackTypeHandler, context: StackContext) bool

        """    }

        pass    

```    class LaunchPlugin {

        +accept_stack(handler: StackTypeHandler, context: StackContext) bool

### 2. Stack Context        +handle_start(request, response) None

        +handle_kill(request, response) None

A simple dataclass that carries operation context:        +handle_apply(request, response) None

    }

### Alternatives

_No response_

### Additional Context

_No response_

[ibrahimsel]

Essentially this issue breaks down to tasks below:

TODO

• Remove unnecessary comments, logs and deprecated stuff laying around in codebase. They remained for test compatibility.

• Refactor composer/plugins so that MutoDefaultComposePlugin, MutoDefaultLaunchPlugin, and provision_plugin act purely as dispatchers that discover a StackTypeHandler via StackTypeRegistry (composer/plugins/base_plugin.py) and invoke handler.apply_to_plugin(...) for each StackOperation. All stack-specific logic currently embedded in the plugins should move into the concrete handlers under composer/stack_handlers.

• Validate stack manifests before any plugin or handler processes them by wiring StackParser.validate_stack(...) (composer/composer/utils/stack_parser.py) or equivalent schema checks into BasePlugin.find_stack_handler(...) and/or StackManager so malformed stacks never reach handler logic in composer/model.

• Convert the example solution JSON payloads in docs/samples/talker-listener/ (both the JSON manifest and the archive manifest) into regression tests under src/composer/test/. The tests should deserialize each sample, feed it through StackParser.parse_payload(...), and assert that the resulting StackManifest objects match the expected talker/listener topology.

• Restore the legacy stack execution path that instantiates composer.model.stack.Stack inside DittoStackHandler (composer/stack_handlers/ditto_handler.py). Add unit/integration coverage that calls .launch, .apply, and .kill on the Stack model with representative legacy manifests and fix any regressions found.

• Guarantee that all launch/start/kill/apply actions issued by Composer go through Ros2LaunchParent (composer/workflow/launcher.py). MutoDefaultLaunchPlugin should delegate lifecycle management to Ros2LaunchParent rather than spawning subprocesses directly, ensuring a single code path handles node tracking and teardown.

• Update the Symphony provider (src/agent/agent/symphony/symphony_provider.py) so _component_registry is mutated only when apply(...) actually publishes a stack action and when get(...) successfully retrieves component state. Failed apply/get attempts must not overwrite or persist stale state snapshots.

• Add a watchdog facility (likely within MutoSymphonyProvider or a dedicated ROS2 node) that periodically pings Composer subsystems (stack handlers, plugins, Symphony broker) and reports which services are up/down so operators can diagnose deployment health.

• Run an end-to-end test with ros-racer blueprint