test(node): check where the systemd units are staged, not what the spec says

2026-09-03T09:26:12Z

test_each_unit_is_installed_where_it_can_run read meshbay-node.spec's %install for `install -D` lines and their destination on the following line. The packaging overhaul (2026-08-31) replaced that section with `cp -a %{_staging_root}/* %{buildroot}/`: the spec no longer places individual files, build-node.sh does, and the spec only declares them in %files. So the test failed against packaging that was correct all along — it was checking a mechanism that no longer existed while the property it defends still held. Both units do land where they can run: build-node.sh:71-76 copies meshbay-node.service to /usr/lib/systemd/system/meshbay-node@.service and meshbay-node-user.service to /usr/lib/systemd/user/meshbay-node.service. It now reads that script. Same guarantee, aimed at the thing that does the work: the template — the one carrying User=%i — into the system directory, and the user unit, which cannot carry User=, into the user one. Checked against three reintroductions of the original defect: swapped destinations, the user unit dropped from staging, and the template renamed. Not verified here: %{_unitdir} and %{_userunitdir} really expanding to those paths. There is no rpm on this machine, so that comes from the RPM convention rather than from `rpm --eval`. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01AbwJDbNTkiRUh7HTWEoyss

feat(client): the platform seam, and an Electron shell that has never been run

2026-08-18T07:42:34Z

Stage D, and the honest half of it. D1 — the seam (done, and verified) ---------------------------------- `static/platform.js`. `HUB` becomes `platform.hubBase()` and the transport is built with the same base, so one address has one source. In a browser it returns '' and every path stays relative to the origin that served the page — the acceptance criterion for this split was "the browser SPA behaves identically", and it does. `platform.js` joins `_ASSETS`, or a change to it would not move the content hash and a cached browser would never ask for it. D2 — the shell (written, never launched) ----------------------------------------- **There is no npm on this machine. Electron was never installed and `packages/meshbay-client/` has not been run once.** That is stated here rather than discovered later. What is there: a main process serving the packaged interface over a privileged `app://` scheme (`secure` and `standard` are not cosmetic — without them the service worker refuses to register and streamed downloads break silently), a preload exposing an enumerated bridge that never passes a filesystem path, a window with `sandbox`, `contextIsolation` and no node integration, navigation away from the package refused, and a CSP where the hub is reachable over connect-src and is not a script source. The hub address arrives as a process argument because `platform.hubBase()` runs before anything can await. `test_desktop_shell.py` pins each of those by reading the source — the treatment `test_downloads.py` already gives the three browser save paths. It catches a property being removed and proves nothing about the application running. Two were checked by breaking them. The interface is *copied* into the package by `build/sync-ui.js` from the hub's static directory, and `ui/` is gitignored: a silent fork is the only real way to end up maintaining the interface twice. D3 — partial ------------ The bridge, and the part worth having now: safeStorage's backend is reported rather than assumed. On Linux it falls back to a fixed key when no keyring is running, silently — someone who believes the OS is holding their keys is told when it is not. The native key lifecycle belongs with D4 and needs a running application to mean anything. D8 — partial, and a real defect found -------------------------------------- `meshbay-node.spec` installed the SYSTEM template — the one carrying `User=%i` — into `%{_userunitdir}`. A user unit already runs as its owner and cannot carry `User=`; systemd refuses the file, so the packaged unit could never have started. Nothing noticed because nobody had built and installed the RPM. Two units now: the template to `%{_unitdir}`, and a new `meshbay-node-user.service` that a person enables themselves without a password — which is what lets the desktop client install a node without asking for one. It carries ExecReload, so `meshbay-node reload` does not have to stop a service somebody is streaming from, and documents the drop-in for a drive outside the home, RequiresMountsFor included. 798 tests pass; e2e.py still passes end to end. Nothing here was built or launched: no npm, no rpmbuild. Co-Authored-By: Claude Opus 5

meshbay.git/packages/meshbay-node/tests/test_packaging_units.py, branch 0.16

test(node): check where the systemd units are staged, not what the spec says

feat(client): the platform seam, and an Electron shell that has never been run