Wrote "a user systemd unit" in c9eb451 as a statement about the deployment. It came from package.json's pgh.systemd: { user: true, enable: true } — a declaration, not a materialized unit. Measured: `systemctl --user list-units` shows none. pgh's own supervisor (pgh/lib/supervisor.js, parented to init) spawns serve.js at boot, and `pgh app status` reports autostart: true with startedAt matching the machine's boot. That is the same failure the README pass existed to fix, committed inside it: reading a manifest and writing it down as an observation. Also corrected the placement section's claim that this "durably serves the keyless roster favela-web reads for the feed skeleton". Measured today, that overstates it: - favela-web holds its OWN keyless replica per configured room, on tabertron and on stortron, from the shipped package.json default (no apps.json override) - stortron answers the loser-club feed skeleton with real posts, so it resolves the roster with no favela-node installed and no serve.js running there - this process had 0 TCP and 0 UDP connections after 65 minutes of uptime What it does uniquely hold is a WRITABLE store for the room — its own log line says writable: true, against favela-web's keyless readers — so it is the store that could add or ban a member. serve.js itself never writes; it keeps that store online. The README now says that instead of implying it is load-bearing for reads. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>