Summary

The current BaseCoordinator interface is tightly coupled to subprocess-based execution and socket communication (TCP or Unix Domain). As the coordinator pattern expands to support additional SDK implementations, the base interface should be abstract enough to accommodate alternative transport mechanisms without requiring subclasses to override low-level internals.

Problem

• BaseCoordinator exposes implementation details specific to subprocess + socket IPC
• Coordinators that could benefit from other communication channels (e.g. shared memory, in-process execution) have no clean abstraction to build against
• The current design makes it harder to reason about what is a required contract vs. what is a Java-specific detail

Proposed Changes

• Raise the abstraction level of BaseCoordinator's public interface so that communication channel and process launching are not assumed
• The interface should be defined in terms of high-level operations (e.g. accepting a DagFileParsingRequest and returning a DagFileParsingResponse) rather than prescribing how those operations are carried out underneath
• Concrete implementations such as JavaCoordinator remain free to use subprocesses and sockets internally

Acceptance Criteria

• BaseCoordinator public interface makes no assumptions about transport (sockets, shared memory, etc.) or process model (subprocess vs. in-process)
• Existing JavaCoordinator and Go SDK coordinator behavior is preserved
• A new coordinator implementation using a non-socket channel could be built against BaseCoordinator without workarounds

Drafted-by: Claude Code (Opus 4.7); reviewed by @jason810496 before posting