JiboExperiments/OpenJibo/docs/device-bootstrap.md

Device Bootstrap Path

Supported First Path

The first supported OpenJibo recovery path is:

QR Wi-Fi -> controlled router/DNS -> redirect Jibo hosts ->
RCM/device patch -> Azure-hosted OpenJibo cloud

This is the path we can document, repeat, and improve.

Why This Path Comes First

• it matches what the current Node prototype already requires
• it keeps the hosted cloud work grounded in real device traffic
• it avoids blocking the entire revival on OTA before cloud compatibility exists

Bootstrap Checklist

1. Connect the robot to a controlled Wi-Fi network.
2. Redirect legacy cloud hostnames to the OpenJibo environment.
3. Prevent fallback DNS from bypassing the controlled resolver.
4. Gain RCM/device access for targeted TLS or host validation changes.
5. Verify robot startup, token flow, socket flow, and first-turn behavior.

Required Host Routing

At minimum, watch and validate:

• api.jibo.com
• api-socket.jibo.com
• neo-hub.jibo.com
• neohub.jibo.com

Scripted Helpers

Bootstrap helper scripts live in scripts/bootstrap:

• Discover-JiboHosts.ps1
• Generate-JiboDnsOverrides.ps1
• Test-OpenJiboRouting.ps1

These are intentionally conservative helpers for discovery and verification, not destructive patch tools.

TLS And Runtime Patching

Patching requirements will vary by device version and by where certificate validation is enforced.

Near-term guidance:

• record each patch location by software version
• prefer small, repeatable changes over ad hoc edits
• keep a versioned host inventory and patch checklist
• do not describe OTA as the primary bootstrap method until the hosted cloud is stable

Smoke Test Goals

The first real-device smoke test should confirm:

• robot startup reaches the hosted cloud
• token issuance succeeds
• required sockets connect
• the robot can complete one simple turn
• update metadata calls do not break startup