bridge-shiplisted

# Shipping a change to the running bridge **Committed is not live.** The bridge process holds the code it was launched with. Python edits need a restart; web edits need a rebuild *and* a restart to be served. A user testing "your fix" against the old process is the single most expensive failure mode in this repo — it looks like the fix didn't work. ## Before you touch anything: who is supervising? ```sh mystical status ``` `supervised systemd` in the output means the user unit (`mystical-assistant.service`) owns the process. That changes how you restart. ## The trap: you are inside the thing you are restarting A Claude session hosted by the bridge is a child of the bridge process **and shares its cgroup**: ```sh cat /proc/self/cgroup # .../app.slice/mystical-assistant.service ``` The unit is `KillMode=control-group`, so `systemctl --user stop` kills every process in that cgroup. That includes your session — and it includes any `setsid` child you spawn to do the restart, because `setsid` escapes the process group, not the cgroup. Restart naively and you get: bridge stopped, restarter dead, nothing comes back up. **Escape the cgroup with a transient unit:** ```sh systemd-run --user --quiet --collect --unit=bridge-restart-$$ \ bash -c 'sleep 2; systemctl --user restart mystical-assistant.service' ``` If `mystical status` showed no systemd line (hand-launched bridge), `setsid` is enough: ```sh setsid bash -c 'sleep 2; mystical restart' >/dev/null 2>&1 & ``` Eit