Roadmap: the first one reached its target, so this is the next one

[pierre-rouanet]

M1 to M4 were a sequence with one destination — a robot that walks, updates itself over the air, and cannot be bricked doing it. That arrived. The work left is independent tracks with different risks and no ordering between them, so the milestone numbers stop being a sequence and the order of work becomes its own section.

Three new milestones

M7 — knowing what a board is doing. A duck in someone else's hands will develop a fault, and today the answer to which part is a developer reading a journal over ssh. No design, on purpose — it is framed as the four questions it owns: a support bundle (nothing collects health, versions, journal, update history and unit states together), a hardware pass/fail a non-developer can run, history for the intermittent faults a snapshot cannot show, and the overlap with #52 — whose crash record, flushed to /var/lib outside release dirs, is exactly the durability a hardware fault report needs. The two should be decided together rather than growing two answers. M4's two unmeasured numbers land here.

M8 — the model channel. Every policy ships inside the daemon artifact today, so a new gait needs a daemon release and a policy trained on a laptop reaches a duck only through CI. The engine was designed for the other arrangement and most of it is already built: the hf_hub source verifying our own minisign (HF signs nothing for us), a model as an ordinary component with its own version line, install dir, rollback target, pin and known-bad history, action = "reload" implemented, and xtask sign signing any directory.

What is missing is at the two ends: robotd has no SIGHUP handler and no way to swap an ort session under a running 50 Hz loop; nothing publishes a bundle (xtask package --channel model-walk checks --version against a crate version a model does not have); model_api is designed and unimplemented; and publishing a policy is a third signing key, not a reuse of release-1 or team.dev. One decision comes first — whether the release keeps its copies as a floor that a Hub component overrides, or the network becomes a hard dependency for a robot that walks.

M9 — the autonomous brain. The biggest untracked gap, with the shape argument that matters: presence, mood and the shared beat are inputs to one brain, not modes beside it. The chorale and the theremin grew as modes because there was nothing to hang them on, and the chorale is now 55 KB of robotd.

What changed in the existing ones

M4 closes, with its log criterion rewritten. It required logs to survive a power cut; /var/log is a zram device and the durable record is the update history under /var/lib, so the criterion asked for a property this project decided not to have (deploy/README.md records the decision). What is left is one journalctl --list-boots on a board.

M5 gains the Python client question — whether one client covers both transports, or the WebSocket surface alone is what a script wants — and splits privacy in two: consent is a mediad session-layer change and is unblocked, the indicator needs an LED under software control that does not exist and should be asked of the hardware rather than parked here.

M6 is reordered by lead time rather than difficulty, and promotes what was an M2 footnote: a private repo's release assets are reachable with a token and a customer robot has none, so as things stand robots in the field cannot download anything (updater-design.md §6.1). With preorders open, that is the longest-lead decision on the page — it changes where release.yml publishes and what updater.toml on every shipped robot points at.

Also

• The "where we are" table gains the recovery net (built, shipped, never exercised against a release that cannot start) and an in-flight row for Maploc: mapping & localization as a robotd-hosted subcrate — and why it never worked #127, Chorale: one room, one conductor — three ways the election could split #151, the NPU detector, docs: the phone app, before the first line of it #107 and docs: a design for seeing what the services say to each other #52.
• M1–M3 keep their evidence lines and the decisions that still bind; the blow-by-blow is in the design docs and the history.
• Every relative link and anchor in the file resolves; the three inbound milestone references (remote-webrtc.md M6, architecture.md M2, robotd-design.md M3) still point at the right sections.