Reports
The reports behind the design decisions, newest first. They were written for Zach while the app was being built, so they say “you”. Each public copy has been read for private data first: machine paths, device serials, the machine's name and private notes are taken out, and the line at the top of each page says what was.
Runs and Identify: captures from the app
A real action runs on a live terminal you can type into, and Identify shows which physical device a row is. Screenshots of both from the running app, with a still of the run flow.
Activity log: one stream, two channels
Research and a recommendation for the Activity view, modelled on rqt_console: one log with an Activity and a Raw channel, scored against three alternatives and 19 reference products.
Diagnostics rollups: five proposals
How a black box's own report and the checks you write for a whole rig fit together. Five proposals scored; the expected setup as the rig's acceptance spec wins, after one contract fix.
RobotDx logos, round 4: ten variants of the Big Sticker
Ten one-axis variants of the round-3 pick (heart placement, scale, rotation, sticker material, head shape, outline, colour inversion, crop, pixel heart, depth). None was adopted; the Big Sticker stayed.
Backs D23.
RobotDiagnostics logos, round 3: iterating 01, 03 and 05 in rose
Ten iterations on the three round-2 picks, plus a hybrid, with top-bar icons, health states and the real GTK render. The Big Sticker (01) was picked.
Backs D23.
RobotDiagnostics logos, round 2: the heart
Ten variants around one picture: a calm robot wearing a heart sticker that works like a video-game life meter. Rose recommended for the heart.
Backs D23.
RobotDiagnostics logos, round 1: 20 proposals
Twenty original marks around a calm two-eyed face, each with a top-bar icon and four health states. Calm Line, Pretty Cushion and Kind Heart were picked to iterate on.
Backs D23.
Round 2: the panel on the real rack
Plug the rack in and the panel says what is connected, what is not and what to check. Printer-style utilities that dry-run first, five structures, eleven skins, and every button with the exact command it would run.
IO diagnostics v1: the first end-to-end build
The one-process host, the plugin contract, five tree drawings, discovery beyond USB, the stock-viewer interop proof, and the safety incident that led to a guard in front of every live-passive test.
IO diagnostics: the converged design
Zach's 14 picks from round 1 set against about 50 existing tools, turned into one design: a chip, an entity tree with detail, a table, an activity log, and two planes (read-only status, driver-owned actions).
Babble and prune, round 1: five top-bar directions
Five genuinely different ways to put plugged-in hardware in the top bar, scored against weighted criteria that were frozen first. The Plug Journal tray led at 82 of 100; it was later superseded.
Contract docs
The specs the decisions cite, from the app's repository (private), redacted the same way.
- Runs v1: a live terminal for every utility2026-10-24 · The seam for runs: a real action on a pseudo-terminal, where records go, the output ring and recordings, Stop and the plugin's own stop. Cited by D07, D08, D24.
- On-connect probe2026-10-23 · The driver says what to check when a device is plugged in: the verb, when the host runs it, the three standard events, and the query-only rule. Cited by D14.
- The expected setup (a rig manifest)2026-10-23 · A small file that says what this PC should see, so the page can say 6 of 7 boards and name the missing one. Cited by D15, D16, D17, D22.
- Stable and Preview channels2026-10-23 · Why each setting in stable-preview.json is what it is, and how the login service brings Stable up. Cited by D20, D23.
- One action vocabulary across drivers (record v0.1)2026-10-22 · The standard action names, their one label each, the four danger classes, the dry run and the model_id identity key. Cited by D06, D07, D22.
- Diagnostics record v02026-10-22 · ROS DiagnosticStatus kept whole, plus Entity, Event, Fault and Action. Eight lessons from the field, the rules, and the evidence re-checked. Cited by D04, D05, D06, D16, D17, D18.
- IO diagnostics: converged design2026-10-22 · Scope, layout, the two planes, port ownership, the contract and the open question about reusing Lichtblick. Cited by D01, D02, D03, D04, D08.
- IO diagnostics v1: build plan2026-10-22 · The decisions, the plugin boundary (a subprocess speaking JSON lines), the lanes, and the interfaces frozen between them. Cited by D01, D03, D04, D08, D09, D13, D14, D19, D24.
- Server API v12026-10-22 · What the page may rely on: state, activity, plugins, actions and their single-use tokens, history, settings. Cited by D07, D18, D19.
- Round 2 brief2026-10-22 · Zach's round-2 feedback as five structure proposals and eleven skins. Cited by D10, D11.
- Round 2 seams: tokens, skins and structures2026-10-22 · The contract for skins, structures, the row object and page state, with the decisions taken in rounds 3 and 3.5. Cited by D10, D11.
- Round 3 brief2026-10-23 · What was settled in round 3 (resizable panes, warning colours reserved, quieter utilities) and the three sets of proposals. Cited by D09, D10, D11, D13, D18.
- Bring your own tokens: writing a skin2026-10-22 · A skin is one file of token declarations; the 39 base tokens, the gates a skin must pass, and a 20-line example. Cited by D09, D11.
- Name research: 20 alternatives to RobotDiagnostics2026-10-22 · The scored list behind the naming decisions. Cited by D12, D21.