Integration Scenarios:

Recommended Loopback + SSH Tunnel Pathway

• Risk Level: Starting/stopping the bridge is High Risk; establishing the tunnel is Controlled Risk.
• Prerequisites: Customer approval for bridge deployment obtained, token generated via key management workflows, and only a single bridge instance active on the robot. ROBOT_USER is the robot login username.

cd /home/realman/realbot-secondary-development
source /opt/ros/humble/setup.bash
source /home/realman/workspace/rm_robot_ws/install/setup.bash
export REALBOT_BRIDGE_TOKEN='<injected_by_secrets_system>'
python3 -m examples.platform_bridge.secure_record_bridge

Startup logs MUST display 127.0.0.1:8090 and MUST NOT print the token.

Establish the tunnel on the local dev machine:

export ROBOT_IP=192.168.127.10
ssh -N -L 18090:127.0.0.1:8090 "${ROBOT_USER}@${ROBOT_IP}"

In a separate local terminal, execute:

export REALBOT_BRIDGE_TOKEN='<token_matching_bridge>'
python3 -m examples.platform_bridge.record_client \
  --base-url http://127.0.0.1:18090 \
  start --scene kitchen --task pick_001 --operator op01 --device 110

After business operations complete, invoke stop using identical metadata, then invoke list. The sample client reads the token from environment variables and does not provide a --token command-line argument to prevent credentials from appearing in process lists.

• Success Criteria: Requests to all three endpoints without a token or with an invalid token return HTTP 401; valid token requests return strict integer status: 0; bridge logs contain no credentials or request bodies; list reflects only completed directories after stop.

• Failure Handling: On HTTP 401, verify token injection and rotation policies without printing tokens; on Connection Refused, check the SSH tunnel status and the robot loopback listener separately; on HTTP 502 or timeouts, query the recorder's actual status without automatically retrying start.