Investigate Doric stdout/stderr handling and vendor-side status API needs

Context

The Doric DLL currently emits native console output during connect/start/stop operations. In practice this means the operator sees vendor messages interleaved with the Rich UI, and the application has very little control over how those messages are displayed, suppressed, or captured.

This is not just cosmetic. Even a minimal machine-readable view of what the driver accepted would help the UI and troubleshooting flow substantially.

Why this matters

If we could reliably capture the driver-side output or, better, query equivalent structured state from the API, we would gain:

• cleaner live/preflight UI without vendor console spam breaking the operator flow
• better diagnostics when hardware commands appear to succeed but behavior is uncertain
• minimal write verification that the driver accepted a requested port/channel/state transition
• clearer operator messaging around what the software attempted to do

Important scope note:

• Console text would not prove actual optical output.
• It would still be a meaningful improvement because it could confirm that the DLL accepted a write and attempted a state transition.
• We should not rely on parsing vendor console text for exact write-parameter verification unless forced to; that is brittle.

Current problem

The DLL appears to write directly to native stdout/stderr or Qt/native logging, so the Python/Rich layer does not cleanly intercept it.

Observed result:

• vendor messages print directly into the terminal during bench test / launch / shutdown
• the UI cannot present those messages in a controlled status panel
• the app cannot reliably use those messages for verification or diagnostics

Options to investigate

Option 1: best-effort local capture of stdout/stderr

Investigate whether we can temporarily redirect OS-level stdout/stderr around Doric calls.

Potential gain:

• reduce terminal spam
• possibly capture coarse driver messages for logs

Limitations:

• may not catch all native logging paths
• may be fragile on Windows
• still leaves us parsing brittle human-readable strings

Option 2: isolate Doric calls in a subprocess

Run Doric interactions in a dedicated subprocess and capture its stdout/stderr explicitly.

Potential gain:

• cleaner containment of vendor output
• easier log capture without corrupting the main UI

Limitations:

• more complexity
• IPC/state handling overhead
• still based on brittle console strings unless vendor gives structured signals

Option 3: vendor-facing best case

Ask Doric/vendor for API support to:

• disable or redirect native console logging
• expose structured status/error callbacks or query methods
• expose current applied settings/state through the API
• return explicit success/failure/state information for config/start/stop calls

This is the preferred long-term outcome.

Recommended position

Short term:

• do not build critical verification logic around parsing console text
• consider best-effort output capture only if terminal spam becomes merge-blocking

Long term:

• push vendor for structured state/error visibility and log suppression control

What we stand to gain

• improved operator UI
• cleaner logs
• minimal write verification that software commands were accepted by the driver
• better troubleshooting when laser state is uncertain

Non-goal

This does not replace true output verification on hardware. Even perfect driver-side acknowledgement is still different from confirming actual delivered optical output.

Start by tracing the Doric connect/start/stop call sites in the Python/Rich layer and reproduce the vendor output seen during bench test, launch, and shutdown. Compare OS-level capture, subprocess isolation, and vendor API support, then document the preferred path, its limitations, and what structured status or logging controls would be needed.