The workshop: one Pi, several stations (the arm and the grow box), each with cameras and controls; works with the arm unplugged #614

serve now starts without the arm. A missing or unopenable port means "arm: not connected", and the port is retried every 5 s, so a hot-plugged arm connects without a restart. The full suite passes (1297 pass, 0 fail, 3 skip) and tsc reports nothing for the files I changed. Under Node (as on the Pi) I could only check by reading the code. This sandbox's Node 20 can't load the .ts files, so the Bun test is the evidence. The branch is pushed.

• Merge: main already carries the workshop from #592, which overlaps this branch's older workshop work in eight files. I took main's tree whole and dropped this branch's own d5e988f commit (camera reason, button contrast, reconnect grace). Its cherry-pick conflicted in workshop-page.ts and I didn't redo it. Say if you want those three tweaks back on top of main's version.
• Arm-less serving: arm-port.ts stands in for the bus while no arm is plugged in. /status answers 200 with arm: "not connected", and a connected arm now reports arm: "connected". The camera routes (/camera-profile, /camera-still), /version, /limits and the grow routes keep answering. Bus routes that need the arm return 503 "arm not connected".
• cli.ts serve: it no longer blocks waiting for an adapter or exits when SO101_PORT is missing. The torque release on stop only runs if the arm was connected.
• Test: serve-no-arm.test.ts starts serve with SO101_PORT at a missing path. It checks /status (200, arm: "not connected"), /version, /limits and /camera-profile/1. It also checks that retryPlug plugs the bus in once the port opens.
• /cameras in the issue: the arm server has no /cameras route. Its camera routes are /camera-profile and /camera-still, so the test uses /camera-profile/1. If the app builds its camera list from somewhere else, that part isn't covered by this change.
• Unplug mid-run: if the arm is unplugged while the server runs, the existing serial error path applies. Only a missing port at start is retried.
• Not done: I didn't deploy to the Pi or confirm that so101.service stays up on real hardware. Your step 3 (the app's sync deploying it) is still to do after this lands.

Continues #614

so101 serve now starts with no arm, and a missing or unopenable port means "arm: not connected" instead of an exit. I have not tried it on the Pi, and nothing here proves the Pi's own steps (the service restart, then the app's sync deploying it). My new tests and the existing server, stations, fake-serve and pi-deploy tests pass. tsc reports no new errors; it still reports the existing erasableSyntaxOnly and src/ui/ ones.

• Serving with no arm: /status answers 200 with arm: "not connected", and /version and the camera routes still answer. Routes that need the arm return 503 "arm not connected". When the arm is present, /status now also carries arm: "connected".
• Hot-plug: the port is retried every 5 s, and the servo limits are read on the first /status after the arm appears. The new code is src/arm-port.ts, wired into serve in src/cli.ts and src/server.ts.
• Unplugging while running: the retry only covers an arm that was absent at start. If it is unplugged mid-run, calls fail with serial errors and the server does not reconnect.
• Camera routes: the arm server has no /cameras route, so the test checks /camera-profile/1 instead.
• Test runner: the test runs main under Bun, not through bin/so101 under Node 24, because the Node here can't load .ts. The Pi's Node 24 path is untested here.
• Merge: the earlier workshop work on this branch overlapped with what #592 already put on main (stations.ts, workshop-page.ts and others). I merged main and took main's version as is, so the branch now differs from main only by this fix.
• Dead code: src/arm-wait.ts is no longer used by serve; it is still imported by stations.test.ts.

serve now starts without the arm. A missing or unopenable port means "arm: not connected", and the port is retried every 5 s, so a hot-plugged arm connects without a restart. The full suite passes (1297 pass, 0 fail, 3 skip) and tsc reports nothing for the files I changed. Under Node (as on the Pi) I could only check by reading the code. This sandbox's Node 20 can't load the .ts files, so the Bun test is the evidence. The branch is pushed.

• Merge: main already carries the workshop from #592, which overlaps this branch's older workshop work in eight files. I took main's tree whole and dropped this branch's own d5e988f commit (camera reason, button contrast, reconnect grace). Its cherry-pick conflicted in workshop-page.ts and I didn't redo it. Say if you want those three tweaks back on top of main's version.
• Arm-less serving: arm-port.ts stands in for the bus while no arm is plugged in. /status answers 200 with arm: "not connected", and a connected arm now reports arm: "connected". The camera routes (/camera-profile, /camera-still), /version, /limits and the grow routes keep answering. Bus routes that need the arm return 503 "arm not connected".
• cli.ts serve: it no longer blocks waiting for an adapter or exits when SO101_PORT is missing. The torque release on stop only runs if the arm was connected.
• Test: serve-no-arm.test.ts starts serve with SO101_PORT at a missing path. It checks /status (200, arm: "not connected"), /version, /limits and /camera-profile/1. It also checks that retryPlug plugs the bus in once the port opens.
• /cameras in the issue: the arm server has no /cameras route. Its camera routes are /camera-profile and /camera-still, so the test uses /camera-profile/1. If the app builds its camera list from somewhere else, that part isn't covered by this change.
• Unplug mid-run: if the arm is unplugged while the server runs, the existing serial error path applies. Only a missing port at start is retried.
• Not done: I didn't deploy to the Pi or confirm that so101.service stays up on real hardware. Your step 3 (the app's sync deploying it) is still to do after this lands.

Declined: already done on this branch, nothing new to add. The arm-less serve fix is pushed and up to date with main, in commits dac0b3a and 49d9d46. The issue has no new comments since my last run, so there is nothing further to change. Run log: https://forge.open-platform.sh/trevato/arm/runs/01m5xg8bw6avv3tp295vp53v5r