Skip to content

OrchestratorOptionsBase

Defined in: packages/client/src/lib/orchestrator/orchestrator.types.ts:16

Options that apply under every layout mode.

OrchestratorOptions pairs these with the mode-specific layoutMode / initialLayout fields.

Extended by

Section titled “Extended by”

Properties

Section titled “Properties”

connection?

Section titled “connection?”

optional connection?: Partial<ConnectionOptions>

Defined in: packages/client/src/lib/orchestrator/orchestrator.types.ts:28

Connection options for the ConnectionManager

debounceDelayMs?

Section titled “debounceDelayMs?”

optional debounceDelayMs?: number

Defined in: packages/client/src/lib/orchestrator/orchestrator.types.ts:22

Debounce delay for update batching in ms (default: 300)

debug?

Section titled “debug?”

optional debug?: boolean

Defined in: packages/client/src/lib/orchestrator/orchestrator.types.ts:20

Enable debug logging (default: false)

maxWaitMs?

Section titled “maxWaitMs?”

optional maxWaitMs?: number

Defined in: packages/client/src/lib/orchestrator/orchestrator.types.ts:24

Maximum wait time before forcing an update flush in ms (default: 1000)

readyTimeoutMs?

Section titled “readyTimeoutMs?”

optional readyTimeoutMs?: number

Defined in: packages/client/src/lib/orchestrator/orchestrator.types.ts:26

Max wait time for instance readiness before skipping actions in ms (default: 500)

sessionId?

Section titled “sessionId?”

optional sessionId?: SessionId

Defined in: packages/client/src/lib/orchestrator/orchestrator.types.ts:18

Session ID for conversation continuity. Auto-generated if omitted.

vessels?

Section titled “vessels?”

optional vessels?: readonly VesselDefinition[]

Defined in: packages/client/src/lib/orchestrator/orchestrator.types.ts:44

Vessel definitions to register before TilingOrchestratorOptions.initialLayout is validated and applied. Equivalent to calling vesselManager.registerVessel() for each immediately after construction — including its report-don’t-throw behavior: a definition that fails schema validation is skipped and logged rather than aborting construction, so one bad vessel cannot take down every other vessel. Registering here (rather than after construction) exists so an initialLayout seed can reference these vessels — the registry starts out empty otherwise. The one place this still throws is indirect: if initialLayout names an instance whose vessel failed validation (or was never listed here), construction throws naming that instance and vessel — a seed genuinely cannot be honored without the vessel it names.