Architecture

sequenceDiagram
    participant Client
    participant Dispatcher
    participant Executor
    participant Scheduler as Executor scheduler

    Client->>Dispatcher: create TEST payment intent
    Client->>Dispatcher: submit a measurement
    Dispatcher->>Executor: upload over reverse control path
    Executor->>Scheduler: persist and schedule
    Scheduler->>Executor: start at scheduled time
    Executor->>Dispatcher: state and output stream
    Executor->>Dispatcher: terminal result
    Client->>Dispatcher: read state and logs

Loading

The dispatcher owns the public HTTP API, accounts, result storage, scheduling decisions, and the executor registry. An executor receives work, enforces its local scheduler and resource limits, runs the debuglet, and streams output and lifecycle updates back to the dispatcher.

Executors initiate both control connections to the dispatcher, so they do not need a public inbound control port. A session is active only when both paths work and the shared session credentials match.

The repository deliberately keeps the dispatcher, executor, CLI, SDKs, protocol, and deployment tooling together today because they share a protocol and release lifecycle. A future release will publish role-specific artifacts; track issue #275.

The detailed package map, control paths, run flow, persistent-state behavior, and extension guidance are in the architecture guide.