Live Jibo Capture

Recommendation

For the first real .NET cloud -> physical Jibo runs, use the existing controlled network and routing setup that already works with the Node server.

Recommended order:

Keep the robot on the known-good Ubuntu laptop based environment.
Swap the .NET cloud into that same controlled path.
Leave the Node oracle available as a fallback on separate ports or on a second machine.
Capture real .NET websocket traffic and turn it into sanitized fixtures.
Only after that, decide what belongs in permanent Azure hosting and IaC.

This is the lowest-risk path because it changes only one major variable at a time: the cloud implementation. It avoids mixing protocol-parity questions with new infrastructure variables.

Why Not Azure First

Azure remains the target hosting direction, but it is not the best first environment for live robot discovery.

Reasons:

the main unknowns are still protocol and turn-behavior details, not Azure primitives
keeping Node and .NET both available locally makes fallback and side-by-side comparison much easier
live robot capture is more valuable right now than early CI/CD polish
region injection and device routing work are easier to debug in a tightly controlled local network

When To Move Beyond The Ubuntu Setup

Move to a second local/staging server or Azure after:

startup flows are stable against the physical robot
websocket turn telemetry is being captured reliably
several real captured sessions have been sanitized into replay fixtures
the fallback path to Node is no longer needed for normal testing

Telemetry Before Live Runs

The .NET cloud now supports structured live capture intended for first robot runs:

HTTP request/response event streams written as NDJSON
websocket event streams written as NDJSON
per-session websocket fixture export for replay
turn metadata including transID, buffered audio counts, finalize attempts, and reply types

Default capture location:

repo-root captures/http/
repo-root captures/websocket/

Artifacts:

http/*.events.ndjson
websocket/*.events.ndjson
*.events.ndjson
websocket/fixtures/*.flow.json

Suggested First Hookup Plan

Start the .NET API on the Ubuntu-backed controlled network using the same robot routing settings currently used for Node.
Confirm HTTP bootstrap and websocket acceptance with the existing smoke/routing helpers.
Run one or two controlled listen turns with Jibo.
Inspect the captured HTTP and websocket events plus exported websocket fixtures.
Convert the best captures into sanitized checked-in fixtures and tests.
Keep Node available to compare any surprising turn behavior before changing infrastructure.

Useful helper scripts:

3.5 KiB Raw Blame History