Add guarded model update channel and experiment budgets

[larai-w]

Summary

• add signed model bundle packaging, compatibility and safe reload guardrails
• add local recording and export budgets for experiments
• add updater checks for model entrypoints and artifact size

Verification

• cargo test --workspace
• cargo test -p updater --lib a_model_reload_delivers_sighup_without_restarting_robotd
• cargo test -p updater --lib a_model_bundle_missing_its_onnx_file_is_refused_before_swap
• cargo test -p updater --lib a_model_artifact_must_declare_and_fit_its_budget
• bash scripts/record-lerobot-preflight.sh

[pierre-rouanet]

Thanks for this — there's a lot of good judgement in here and I want to say where before I ask for changes.

Keeping a 1.8 MiB frame off the WebRTC control channel, and framing media.frame as a JSON header naming a byte count followed by the bytes, is the right call and the right shape. policy_enabled as an Option<bool> where absence is a refusal rather than "probably safe" is exactly right, and the reasoning you wrote for it — held can't distinguish an armed policy holding on a zero command from a disabled one — is the argument I'd want made. Recording the pre-scale action rather than targets, so a dataset doesn't label voltage sag and the low-pass as policy, is a subtle thing to get right. And in the reload you landed on "a failed load must keep the running controller", which is the single most important property in that whole area.

Could you split this into separate PRs?

There are four independent features here — the model-* update channel, the SIGHUP reload, the local observation/recording path, and robotctl support — and they need different answers. Bundled together, the pieces I'd merge tomorrow are blocked behind the pieces that need a conversation.

Some of it has already been implemented on main

This is the awkward part, and it isn't your fault: this branch's base is 84 commits old, and the policy channel was designed and shipped in the meantime. At your merge base, docs/design/policy-channel-design.md didn't exist and updater-design.md §5.5 had no amendment on it. You read §5.5 and built what it said — including the [component.model-walk] / [component.model-jump] TOML, which is literally in that section, and the SIGHUP, which §5.5 literally specifies. The doc moved underneath you.

What's on main now:

• robot.reloadPolicies, plus policy.* on updaterd and robotctl policy check / update / load / reset / search — landed at API_VERSION 19 (we're at 23 now). Same milestone, and it handles two cases the SIGHUP approach can't: it swaps under a moving robot by comparing the change against the network that stepped last tick, and being a call rather than a signal it answers accepted or refused-with-a-reason. There's a field report in §4 that shaped it — load a walk, walk, sit, policy reset walk, and the robot ramped to home and stood up, because sitstand was driving and the reset didn't touch it.
• One policies component, not one per slot. policy-channel-design.md §9 argues this out and §13 records it as decided. The reasons are that the files are produced as a family by one training run, and the slot→file mapping is mode-dependent (walk is alpha_walking.onnx on legs and roller.onnx on wheels — which postdates §5.5). A per-slot model-walk component can't express that at all. §5.5 now opens with a paragraph saying the control policies went the other way.
• model_api is consulted end to end already (updater/src/policy.rs, manifest.rs), so that half of the roadmap bullet you were working from is stale too.

So features 1 and 2 don't have a path forward as written — not because the work was wrong, but because main answered the same question differently and in more depth. Sorry you spent the time on it.

The genuinely new parts should merge fairly easily

Three pieces here aren't duplicated by anything and I don't think any of them is controversial:

1. media.frame. docs/project/npu-bringup.md names this method, with your justification, and it's still open: "a call that answers with one frame. Useful for far more than perception (a snapshot in the console, a still for a bug report), and it makes capture stop fighting the daemon." This is the project's own option A. Four things and I'd merge it:
   • mediad/src/frame.rs:192 says proto::Id::String; the variant is Id::Text. The module is #[cfg(target_os = "linux")], so macOS never builds it — which is why cargo test --workspace looked green. CI would catch it, but no CI run has happened on this branch yet.
   • the socket needs handing to the robot group. tof/src/main.rs:382 and padd/src/tap.rs:136 both chown theirs after binding (warning rather than failing when the group is absent); mode 0660 alone leaves it mediad:mediad, and the operator is only ever added to robot. robotctl media frame can't currently work outside root.
   • read_line has no cap, so MAX_REQUEST_BYTES is checked after the whole line is already buffered — reader.take(MAX_REQUEST_BYTES as u64) is the bound.
   • docs/design/architecture.md's service table still says mediad has "no unix socket of its own". Giving it one is a deliberate change to the service split and that's where it gets recorded.
2. required_files and max_artifact_bytes as component config keys, independent of models. Both are good on their own merits. One fix: require_artifact_budget is only called from Engine::check, so apply — the path that installs — never consults it. It wants to sit next to the pin check in apply_inner.
3. policy_enabled on RobotState, with the absent-is-unknown semantics exactly as you have them.

Those three are small, self-contained, and I'd expect them to go in with barely any back-and-forth. Please rebase on main first — robotd/src/main.rs, robotd/src/control.rs and mediad/src/pipeline.rs all conflict, and robotd/src/main.rs in particular has been substantially rewritten.

The two that need a conversation rather than a review

The LeRobot recording path. I can't find a stated need for it anywhere — git grep for lerobot, imitation or teleoperat across docs/ and scripts/ on main gives one unrelated hit. That's not a no; behaviour cloning is an obvious thing to want, and the roadmap's "Not doing, on purpose" list exists so new directions get argued for rather than added quietly. Could you open an issue or a short design note with the premise? One thing I'd want to work through there: policy_action is the output of a 61-dimensional network whose dominant input is the commanded twist, and the exporter's features are image + 15 joints. The command isn't in there, so the same image and joint angles map to different actions depending on what the operator's stick was doing — the residual is the human. samples.jsonl has it (movement.requested, and safety.gravity too), so it's the exporter's feature list rather than the recording, but it's the kind of thing the conversation would have surfaced first.

robotctl support. This one is asked for almost word for word — roadmap M7: "One command, after a fault, producing a file someone can send. Nothing collects health, versions, the journal, the update history and the unit states together." Your section list is that list. But M7 also says it has "no shape for this yet", and specifically that it should be decided alongside #52's durable crash record, because "the journal does not survive a power cut by design, so anything that matters here needs the update history's durability rather than the journal's" — a journal snapshot is the half M7 calls insufficient for the intermittent faults it's aimed at. There's no design doc for #52 yet, so I'd rather write that down and decide the durable-record question once. Your support.rs is a good sketch to bring to it, and the credential filter and the "failure is evidence, not a reason to abandon the bundle" choice both survive that conversation.

Happy to go through any of this in more detail — and if it's easier, open the media.frame PR first and we can get that one landed while the rest is being sorted out.

[larai-w]

Thank you — this is a more careful read than I expected, and the parts you flagged as superseded are ones I'd much rather know about now than after more work on them.

I'll split it. Taking your suggestion: I'll open media.frame on its own first, with the four fixes you listed — Id::Text, the robot-group chown after binding, bounding the read with reader.take(MAX_REQUEST_BYTES), and the architecture.md service table entry. The Id::String one is a fair hit: the module is #[cfg(target_os = "linux")], so my cargo test --workspace was green without ever building it.

No objection on the policy channel. policy-channel-design.md §9 answers the question better than what I built, and the one-policies-component argument is right — a per-slot component can't express a mode-dependent slot→file mapping at all. I'll drop features 1 and 2 rather than try to rework them.

On the recording path and robotctl support: agreed that both need a written premise before code. I'd rather open an issue and a short design note than argue them inside a PR. On the recording one, the point about the commanded twist being absent from the exporter's features is the part I'd want to work through first — if the residual is the operator, the feature list is wrong before the format is.

One honest note on timing: I'm a solo maintainer here and I can't give you a date. I'd rather say that than promise one and go quiet. media.frame is the piece I'll get to first.

[larai-w]

Opened #241 with just media.frame, rebuilt on current main rather than rebased — Frames had become a rendezvous rather than a cache in the meantime, so frames.latest() was gone and the endpoint's contract had to change with it. That change is written up in the PR; it is the one thing there I would not decide on my own.

All four of your fixes are in. I also ran it on Linux CI before opening, and checked that the five tests actually executed rather than reading the green — the Id::Text one was a fair enough hit that I did not want to repeat the shape of it.

Leaving this PR open for the rest, as you suggested.