# 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:

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

Optional environment overrides:

```bash
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:

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

4. Verify controlled routing from the Ubuntu environment:

```bash
./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:

```bash
./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:

```bash
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.