ORCA Lab compatibility: connect DeepSeek-TUI as an ORCA agent connector

[Hmbown]

Goal

ORCA Lab (physical-AI training platform, demoed at GDPS 2026) advertises "fast direct connect" for terminal coding agents — the same slot it offers Claude Code / OpenClaw. Make DeepSeek-TUI connectable as the coding agent that drives an ORCA robot/sim session.

Approach

Implement an agent-connector adapter on top of the existing Codex-style app-server transport (crates/app-server, JSON-RPC 2.0 over stdio + HTTP) rather than a new runtime. ORCA spawns deepseek app-server --stdio (or dials the HTTP listener) and performs a handshake.

ORCA concept → app-server mapping:

ORCA	app-server
connect / open	orca/handshake → thread/create → thread/start
send task/step	thread/message / prompt/run
resume	thread/resume
stream tokens/tools	existing event stream (response_delta, tool_call_*)
disconnect	shutdown

Design doc: docs/ORCA_CONNECTOR.md.

Status

Scaffold landed on branch claude/ds-tui-orca-compatibility-g6fV1:

• orca/handshake + orca/capabilities methods on the stdio transport, advertised in capabilities
• Design doc mapping ORCA sessions onto app-server threads

Acceptance / follow-ups

• ORCA auth/token exchange (transport vs. handshake layer — needs ORCA spec)
• HTTP /orca/handshake route mirroring the stdio method
• Robot/sim workspace path wiring (thread/start { cwd } vs. dedicated orca/* param)
• Server→client push notifications vs. request/response polling over stdio
• Telemetry/event forwarding back to the ORCA session
• Integration test against an ORCA connector mock
• End-to-end validation against a real ORCA Lab session

Open questions

1. Does ORCA authenticate the connector (bearer / mTLS), and at which layer?
2. Push notifications or strict polling over stdio?
3. How does ORCA pass the workspace/robot-session path?

These require the ORCA Lab connector spec, which isn't public yet — flagging as a blocker for the follow-up items.