Record sandbox source revisions and runner integration decisions #100

Outcome: The requested source inventory and integration decisions are recorded. Reviewed revisions are evidence, not required release pins. The trusted adapter speaks Node's heartbeat protocol directly; implementation and compatibility validation are tracked in #92/#84/#86.

Parent: #82. The reviewed source revisions and Go runner integration points below explain the baseline considered for sandbox planning.

Reviewed revision inventory (2026-10-28)

Node declares Go 1.27.3; the runner declares Go 1.25. Node has a digest-pinned builder/base and a non-root container image, but this packages Node binaries, not a k3s application manager. Source evidence: fixture pins/export behavior, development instructions, Node Dockerfile.

Decision update (2026-10-29)

App images are ordinary HTTP containers under gVisor and contain no Livepeer SDK or bootstrap credential. The trusted k3s adapter sends Node heartbeats directly and does not require the Go SDK. The allocator-managed orchestrator is also a k3s pod. #92 owns deployment, registration, and creation/release of the new repository containing runtime and adapter code; no exact SDK pin is selected in this planning issue. Node #25 is required before launch.

Go runner integration points reviewed

• Options, New/Register, Start, Close: app/service URL, bootstrap auth, runner identity, mode, capacity/status, GPU metadata, heartbeat lifetime, HTTP client, unregister.
• OnReserve/OnRelease, SessionEvent: connect session admission/release to app work. SDK session inventory is protocol state, not a Kubernetes job queue.
• SessionToken, SessionControl, StopSession, plus CreateTrickleChannels/DeleteTrickleChannels and CreateProxy: preserve callback credentials and private/public URL behavior across the sandbox boundary.
• examples/stdin-stdout: existing host HTTP/command lifecycle to package as a first app. exec.CommandContext supplies request cancellation, not process/filesystem/network isolation.

Decisions and implementation tracking

• Sandbox registration, readiness, capacity, session reconciliation and unregister are direct adapter-to-Node heartbeat work in Deploy ordinary HTTP app images in gVisor and register them with Node #92. The current one-runner-per-capability contract can support development; Node #25 must provide multi-capability registration before launch. Node drain #23 separates new admission from service of existing sessions.
• A Go runner revision is not a required sandbox release pin. Node's existing Go/Python fixture commits remain compatibility-test inputs, not proof of sandbox acceptance. Choose compatible releases and test them when implementing.
• Select and validate CPU host OS/kernel/architecture, k3s/runsc and immutable runtime artifacts in Validate k3s and gVisor compatibility on supported CPU hosts #84/Build a repeatable k3s and gVisor sandbox installer with recovery #86; GPU compatibility is deferred to future work outside Validate k3s and gVisor compatibility on supported CPU hosts #84. Deploy ordinary HTTP app images in gVisor and register them with Node #92 owns the new runtime/adapter repository, its image release and app deployment contract. The platform owns evaluation app/profile versions in Build versioned evaluation apps, profiles and the trusted verifier #90/Define an extensible hardware and capability evaluation framework #46.
• This mapping was source inspection only; no runtime or GPU validation was performed. The requested inventory and integration decisions are recorded, so this issue is complete. CPU runtime validation remains in Validate k3s and gVisor compatibility on supported CPU hosts #84/Build a repeatable k3s and gVisor sandbox installer with recovery #86. GPU compatibility is deferred to future work and is not part of Validate k3s and gVisor compatibility on supported CPU hosts #84.