Streaming Boundary And Wrappers
===============================

Overview
--------

OpenHCS now treats streaming as a thin-wrapper integration surface, not as the
owner of generic streaming infrastructure.

Ownership
---------

- ``zmqruntime`` owns transport and execution lifecycle primitives:
  ZMQ sockets, control/data channels, ping/pong, execution status contracts.
- ``polystore`` owns streaming payload semantics and receiver-side projection:
  streaming data types, component-mode grouping, batching/debounce engines, and
  viewer receiver helpers.
- ``openhcs`` owns application wiring:
  configuration defaults, orchestrator integration, and OpenHCS-specific viewer
  process launch/lifecycle policy.

Current OpenHCS Responsibility
------------------------------

In OpenHCS runtime modules (for example ``openhcs/runtime/fiji_viewer_server.py``
and ``openhcs/runtime/napari_*``), the server classes should remain thin
wrappers that bind OpenHCS configuration/context into external abstractions.

They should not re-implement generic projection or batching logic that is
already provided by ``polystore`` receiver-core modules.

Why This Split
--------------

- keeps OpenHCS focused on domain orchestration and UX integration
- improves reuse for other applications that need the same streaming stack
- reduces duplicated logic and inconsistent behavior across viewers
- gives one canonical path per semantic concept