JiboExperiments/OpenJibo/docs/live-jibo-test-runbook.md

Live Jibo .NET Test Runbook

Goal

Run the first real Jibo -> .NET OpenJibo cloud test on the Ubuntu machine using the same working certificate and controlled routing that currently work with the Node server.

This runbook intentionally avoids introducing Azure, new hostnames, or new robot bootstrap changes during the first live test.

Recommended Approach

Use the existing Ubuntu networking path and certificate material first.

• keep the current controlled Wi-Fi / routing arrangement
• keep the current Jibo-facing hostnames:
  • api.jibo.com
  • api-socket.jibo.com
  • neo-hub.jibo.com
• keep the Node server available as a fallback
• run the .NET API with the same cert/key material by converting it to a temporary .pfx for Kestrel

Prerequisites On Ubuntu

Install or confirm these tools:

• dotnet
• openssl
• curl
• python3

Optional but useful:

• pwsh

pwsh is not required anymore for the Ubuntu live test path if you use the bash/python helpers added here.

Certificate Plan

The Node server currently uses:

• cert.pem
• key.pem

The .NET API can reuse that same material for the test by converting it at startup into a temporary .pfx.

If your current cert file already includes the working chain, use it as-is.

If your chain is separate, pass it as CHAIN_PEM.

Step By Step

1. On Ubuntu, stop the Node server if it is currently bound to port 443.

2. From the repo root, start the .NET cloud using the same cert/key:

./scripts/cloud/start-dotnet-with-node-cert.sh

Optional environment overrides:

CERT_PEM=/path/to/cert.pem \
KEY_PEM=/path/to/key.pem \
CHAIN_PEM=/path/to/chain.pem \
ASPNETCORE_URLS="https://0.0.0.0:443;http://0.0.0.0:24605" \
./scripts/cloud/start-dotnet-with-node-cert.sh

3. In another terminal, run the prep checklist:

./scripts/cloud/invoke-live-jibo-prep.sh

By default this uses the local HTTP port exposed by the launcher:

• http://localhost:24605

That avoids certificate-name validation issues during preflight.

If you want to override it, either of these works:

BASE_URL=http://localhost:24605 ./scripts/cloud/invoke-live-jibo-prep.sh
BASEURL=http://localhost:24605 ./scripts/cloud/invoke-live-jibo-prep.sh

4. Verify controlled routing from the Ubuntu environment:

./scripts/bootstrap/test-openjibo-routing.sh

5. Power on Jibo and let it connect using the existing controlled network configuration.

6. Perform the first live checks in this order:

• startup / bootstrap reachability
• one simple chat turn
• one joke turn

7. After the run, summarize the captured websocket telemetry:

./scripts/cloud/get-websocket-capture-summary.sh

8. Inspect exported fixtures under:

• captures/websocket/fixtures/

9. Import the best fixture into the checked-in websocket fixture set:

python3 ./scripts/cloud/import-websocket-capture-fixture.py \
  /path/to/exported.flow.json \
  neo-hub-real-jibo-first-chat

10. Keep notes on:

• whether startup succeeded cleanly
• which websocket paths connected
• whether audio stayed pending or finalized
• whether EOS timing matched expectations
• whether any unexpected message families appeared

What To Do If The Test Fails

If the robot does not connect or the first turn fails:

1. confirm the .NET API is actually bound on 443
2. confirm the cert presented by the .NET API matches the currently working Node cert path
3. confirm the Ubuntu routing still points Jibo traffic at the same machine
4. compare the .NET websocket capture output with prior Node logs
5. temporarily switch back to Node to confirm the environment still works

Not In Scope For This First Test

Do not mix these into the first live run:

• Azure deployment cutover
• new permanent OpenJibo hostnames
• IaC rollout
• new device bootstrap edits beyond the already working setup

Those are valid next steps, but they should follow the first successful .NET live capture, not precede it.