The Rust follower stack,
taken by the hand

Step 1-2 · Leader → orchestrator mirror → action.{id}

The SpaceMouse leader's admittance thread builds a RobotState at 100 Hz and stamps leader_timestamp = now (spacemouse_leader.py:316-329). The orchestrator, only in TELEOPERATION mode, mirrors it to the follower: joints copied 1:1, velocities/efforts zeroed (orchestrator_node.py:342 → 383 → 414), published as RobotState.to_dict() JSON on action.{id}. Nothing here changed in the port — that is the zero-orchestrator-changes property.

Step 3 · Bridge ingress: _on_action → _put_action

The bridge subscribes action.{id}, converts the bus dict into the wire protobuf Action (typed hot fields + everything else squeezed into rest_json), and routes it. Two things to notice: actions are only forwarded while the stream is engaged (PREPARE_STREAM engages, ENTER_IDLE disengages), and an e-stop action short-circuits into the dual-path sender before any of that (remote_follower_bridge.py:734-746).

Step 4 · The S7A1 datagram

One datagram = one action. Big-endian 11-byte header, then the robot id, then the protobuf. The sender owns one process-wide wrap-aware u32 sequence counter that survives engage cycles (remote_follower_bridge.py:467-478; frame codec mirrored in rust frame.rs:30/43).

Telemetry uses the same layout under magic "S7N1" with a JSON payload — the differing magic is what makes cross-flow parsing impossible.

Step 5 · Listener thread: decode, hostile-datagram policy, SeqGate

A dedicated OS thread (not tokio — a datagram burst must never starve the control plane) blocks on the socket with a 200 ms timeout. Garbage, wrong magic/version, or undecodable protobuf → counted as malformed and ignored, never a fault. A foreign robot_id is dropped silently and uncounted (it is another flow's traffic). Then the seq gate (actions.rs:341, 185):

Step 6 · NodeCore::apply_action — hop stamps and the latency number

Transport-neutral from here down — the gRPC StreamActions fallback feeds the exact same function. The action is rebuilt into a RobotState (rest_json first, typed fields overlaid), then stamped through the follower.{id}.* hop chain the profiler renders. command_latency_ms is wall-clock now − leader_timestamp — which is why it assumes chrony across hosts. Any failure in this function (reconstruction, panic, driver error) is answered with an e-stop, not a log line (node.rs:519, 552).

Step 7 · set_state_by_ref — producer entry, never a sender

Ingress does not validate or send. It type-checks, records the commanded pose, short-circuits an e-stop straight into emergency_stop_impl (so it can never wait behind the send cadence), stamps servoj_enqueue, and overwrites the mailbox (robot.rs:1453-1468).

Step 8 · The mailbox: depth-1, latest-wins, read-without-take

Python got this for free — "reference assignment is atomic under the GIL" — so Rust makes it a Mutex<Option<CommandSlot>> with very particular semantics (stream.rs:181, 200-209, 245-251):

• The producer overwrites; the consumer clones and leaves the slot in place. It is cleared only by StreamHealth::reset() — never by the tick.
• Staleness comes from t_mono: a slot re-read inside the stale window is a fresh re-send of the same setpoint, not a hold. A take-semantics port would silently flip starvation accounting and the flight-recorder record kind (pinned by test re_read_within_window_is_fresh_not_hold, stream.rs:483).
• No queue may ever sit in front of this mailbox — buffering stale setpoints recreates the exact failure it exists to prevent. (The post-merge playout-queue project deliberately bounds + age-caps for this reason.)

Step 9 · The sender thread: an Instant grid at cmdT

cmdT = 1 / publish_rate_hz (10 ms at 100 Hz) and is never configured independently — the controller computes joint speed as delta/cmdT, so a mismatch inflates implied speed (stream.rs:44-54, robot.rs:727). The loop gates on ProbeState::Ready exactly (not != Off) so the readiness probe owns the channel alone during SETTLING. A tick error kills the thread — mirroring an uncaught exception in Python's daemon loop (robot.rs:1231-1244).

Step 10 · One tick: tick_paced

The M6 core (send_frame) decides fresh-vs-hold and injects the guarded send as a closure. servoj_dequeue stamps and profiler chain exports fire only on fresh frames; holds export nothing (robot.rs:1259-1289).

Step 11 · The guard suite — every frame that reaches hardware

Sacred §8.8: fresh, hold, or synchronous — every frame passes validate_command. Hold frames are not exempt. Command-path order, first failure short-circuits (envelope.rs:239-270):

joint_speed and eef_speed are state-side observers (observe_state, envelope.rs:284) — they watch the measured stream, not commands. Trip-lock: N consecutive violations latch tripped and fire the robot's e-stop callback once (guard.rs:213-228); only reset_after_estop_release clears the latch. Trip counts differ by config block: 3 for command_guard/joint_speed, 1 for command_speed/eef_speed/workarea (config.rs:479-484). On a trip inside guarded_send the driver e-stops and refuses the write (robot.rs:1474-1485).

Step 12 · set_state_impl: cap_delta, the sdk lock, and the wire

The last gates before hardware (robot.rs:1555-1597): e-stop bypass → latch gate → joint-count gate → streaming-ready gate → cap_delta → hop stamps around the sdk lock (command_pre_lock / command_lock_acquired) → record_hardware_tick → send_servoj (UDP passthrough, fire-and-forget). A transient RPC error drops the setpoint with a warning — never a crash.

cap_delta (sacred §8.10) (robot.rs:429-488): closes the loop against the measured pose, returns the target unchanged when within the per-joint step, and is a no-op when unconfigured or before the first observation. Its rate-limit warning is edge-triggered — once per ramp episode, via an AtomicBool.

Step 1 · CNDE reader: the snapshot and the first-frame latch

The reader blocks in next_state(), writes each frame into the RwLock snapshot, and latches first_frame_seen (robot.rs:1127-1147). Sacred §8.11: every state read fails with BadResponse until that latch — a pre-sync seeded from an all-zero packet would jump the arm. (Python checked frame_cnt == 0 && joints all zero; the FR firmware rejects frame_cnt at CNDE config time, so the mechanism changed, the observable behavior did not.)

Step 2 · Reading a state: classify, demux, and two famous lies

read_state_from_pkg maps the packet to RobotState (joint arrays truncate with take — slice semantics, sim packets are really shorter) (state.rs:92-131). The classifier is most-severe-wins — and ports the quirk that only EmergencyStop == 1 counts as e-stop; any other non-zero value falls through (state.rs:151-169). Vacuum state is a bit demux over both DO bytes (state.rs:181-188). And yes: units ships as "radians" while the numbers are degrees — the dataclass default was never set in Python, so it is never set in Rust either.

Step 3 · The paced publisher: S7N1 frames + the deadline theater

publish_worker_{id} ticks at publish_rate_hz on a never-resetting grid; each tick is wrapped in catch_unwind so a ported-guard panic logs and the loop continues (Python's per-iteration except) (telemetry.rs:274-331). Payload = the exact RobotState::to_dict() JSON whose parity M1 proved — protobuf telemetry is a flagged later optimization, one variable at a time.

Step 4 · Bridge receive: wrap-aware latest-wins, epoch reset

The bridge drops out-of-order frames by seq (same half-window test as the node's action gate), ages the epoch out after 2 s of silence, resets it on link loss, and republishes the JSON payload unchanged on state.{id} — the frontend cannot tell the follower moved cities (remote_follower_bridge.py:1197-1225).

Step 5 · Events: two lanes, priority always drains first

Robot events (EMERGENCY_STOP, toggles) ride an unbounded priority channel; trace_batch diagnostics ride a capped (8) bulk channel that drops-newest on overflow. The stream implementation polls priority first, always — a trace batch can never delay or reorder an e-stop notification (grpc.rs:104-146, 202).

Step 6 · The trace backfeed: the profiler works cross-host

On every fresh guarded send the driver exports the action's hop chain into a bounded queue (try_send, drop-newest + counter — zero new locks on the sender tick) (trace.rs:375-387). The telemetry thread drains chains (≤160) and hardware-send wall stamps (≤200) every ~1 s into a trace_batch bulk event. Operator-side, TraceBackfeed shifts node-monotonic hop times by −offset (the estimator from Walkthrough B), drops and counts chains that go backwards in time (a wrong offset surfaces instead of rendering), and injects them into the operator TraceLogger — zero frontend changes (trace_backfeed.py:112-150).

One deliberate exception: hw_tick wall stamps are injected UNtranslated — the consumer-rhythm panel diffs consecutive sends per robot, so a constant cross-host offset cancels; routing them through the offset estimator would add error. Dedup is a strictly-increasing wall filter (trace_backfeed.py:86-102).