Orchestrator-TS Architecture: Class Diagrams
Overview
The orchestrator-ts system is structured around Clean Architecture with four layers: domain (pure business rules), application (ports + services), infra (concrete implementations), and adapters (CLI delivery). All inter-layer communication goes through abstract port interfaces defined in application/ports/. Services in application/services/ hold the business logic and depend only on ports; infrastructure classes in infra/ implement those ports with concrete technology choices.
The five diagrams below partition the architecture by concern. Each interface carries <<interface>> and each domain value object carries <<type>>. Dependency arrows are labeled to distinguish implements relationships from runtime uses (composition) relationships.
Reading note: Diagram 1 contains all port interfaces with full method signatures. Diagrams 2–5 show ports already documented in Diagram 1 as thin stubs (name +
<<interface>>only) to reduce width — refer to Diagram 1 for full signatures.
Diagram 1: Core Ports and Their Infrastructure Implementations
This diagram shows every abstract port in application/ports/ together with its concrete infra implementation(s). The left column holds the port interfaces; arrows point right to the classes that satisfy them.
Diagram 2: Agent and Workflow Subsystem
This diagram shows how the WorkflowEngine drives phase execution through PhaseRunner, how AgentLoopService implements the PLAN→ACT→OBSERVE→REFLECT loop, and which domain types and optional ports flow through each class.
Diagram 3: Implementation Loop Subsystem
This diagram covers the ImplementationLoopService and all of its dependencies: the agent loop it drives, the review engine, the quality gate, the plan store, the self-healing loop, the git controller, and the optional observability ports. Domain record types that flow through the loop are also shown.
Diagram 4: Context Engine Subsystem
This diagram shows the ContextEngineService and its five sub-interfaces — token budget manager, accumulator, planner, compressor, and cache — together with the domain value types that flow through the 7-layer assembly pipeline.
Diagram 5: Planning and Tools Subsystem
This diagram shows the TaskPlanningService, its sub-ports for plan persistence, context building, human review, and event emission, together with the ToolExecutor and the infra tool implementations it dispatches to.