fixes for testing Jibo

OpenJibo/docs/live-jibo-capture.md

@@ -36,27 +36,31 @@ Move to a second local/staging server or Azure after:
 
 ## Telemetry Before Live Runs
 
-The `.NET` cloud now supports structured websocket capture intended for first live runs:
+The `.NET` cloud now supports structured live capture intended for first robot runs:
 
-- event stream written as NDJSON
-- per-session fixture export for replay
+- 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`
-- `fixtures/*.flow.json`
+- `websocket/fixtures/*.flow.json`
 
 ## Suggested First Hookup Plan
 
 1. Start the `.NET` API on the Ubuntu-backed controlled network using the same robot routing settings currently used for Node.
 2. Confirm HTTP bootstrap and websocket acceptance with the existing smoke/routing helpers.
 3. Run one or two controlled listen turns with Jibo.
-4. Inspect the captured websocket events and exported fixtures.
+4. Inspect the captured HTTP and websocket events plus exported websocket fixtures.
 5. Convert the best captures into sanitized checked-in fixtures and tests.
 6. Keep Node available to compare any surprising turn behavior before changing infrastructure.
 

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

@@ -109,6 +109,11 @@ BASEURL=http://localhost:24605 ./scripts/cloud/invoke-live-jibo-prep.sh
 
 - `captures/websocket/fixtures/`
 
+Telemetry from the same run should also now be present under:
+
+- `captures/http/`
+- `captures/websocket/`
+
 9. Import the best fixture into the checked-in websocket fixture set:
 
 ```bash
@@ -133,7 +138,8 @@ If the robot does not connect or the first turn fails:
 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
+5. compare the `.NET` HTTP capture output with prior Node logs
+6. temporarily switch back to Node to confirm the environment still works
 
 ## Not In Scope For This First Test
 

OpenJibo/docs/protocol-inventory.md

@@ -45,11 +45,11 @@ Observed from `open-jibo-link.js`:
 | `Loop_*` | `List`, `ListLoops` | medium | initial dispatch implemented |
 | `Robot_*` | `GetRobot`, `UpdateRobot` | medium | initial dispatch implemented |
 | `Update_*` | `ListUpdates`, `ListUpdatesFrom`, `GetUpdateFrom`, `CreateUpdate`, `RemoveUpdate` | medium | list/get scaffolding implemented |
-| `Media_20160725` | `List`, `Get`, `Create`, `Remove` | medium | not yet ported |
-| `Log_*` | `PutEvents`, `PutEventsAsync`, `PutBinaryAsync`, `PutAsrBinary` | medium | upload endpoints reserved; detailed handling pending |
-| `Key_*` | `ShouldCreate`, `CreateSymmetricKey`, `GetRequest` | medium | pending |
-| `Person_*` | `ListHolidays` | low | pending |
-| `Backup_*` | `List` | low | pending |
+| `Media_20160725` | `List`, `Get`, `Create`, `Remove` | medium | implemented in current parity scaffold |
+| `Log_*` | `PutEvents`, `PutEventsAsync`, `PutBinaryAsync`, `PutAsrBinary` | medium | async upload metadata and placeholder upload endpoints implemented |
+| `Key_*` | `ShouldCreate`, `CreateSymmetricKey`, `GetRequest` | medium | implemented in current parity scaffold |
+| `Person_*` | `ListHolidays` | low | implemented in current parity scaffold |
+| `Backup_*` | `List` | low | implemented in current parity scaffold |
 
 ## WebSocket Flows
 
@@ -101,6 +101,16 @@ That separation is intentional. The synthetic STT path currently exists only to
 | `/upload/log-events` | async log upload target | medium | placeholder endpoint accepted |
 | `/upload/log-binary` | async binary upload target | medium | placeholder endpoint accepted |
 
+## First Live .NET Capture Findings
+
+The first real `.NET` robot run has confirmed only an early startup slice so far:
+
+- `api.jibo.com` startup HTTP requests are reaching the `.NET` cloud
+- `Notification.NewRobotToken` is active in the robot startup sequence
+- `api-socket.jibo.com/{token}` is being accepted live
+
+The first live run has not yet shown full startup parity with the working Node server. In particular, the successful Node run continues into additional health/log cadence after token issuance and socket acceptance, while the current `.NET` run has not yet reproduced that full progression consistently.
+
 ## First Core Revive Slice
 
 The first .NET hosted milestone should fully support: