todo: settings as portable files, per user and per server

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

todo/settings/the-same-for-system-settings-owned-by-the.md

@@ -0,0 +1,32 @@
+---
+id: settings/the-same-for-system-settings-owned-by-the
+title: "The same for system settings, owned by the Super Admin"
+theme: settings
+status: open
+created: 2026-08-22
+date_source: stated
+order: 2
+---
+
+**The same for system settings, owned by the Super Admin.** Wanted 2026-08-22, in the same breath as the
+per-user export — the server's own configuration should be a file too, so a new instance can be brought
+up matching an existing one instead of being clicked into shape.
+
+This is the half with the larger payoff, because it is the half that is currently repeated per machine.
+`docs/servers.md` lists **seven platforms running**, each configured by hand, and nothing anywhere
+records what a given server's settings actually are. A file makes that answerable, diffable between two
+hosts, and reviewable in git.
+
+`server_config` is already key/value jsonb, so the export is close to free. Two things make it a
+different problem from the user one rather than the same problem twice:
+
+- **Some system settings are legitimately per machine** — anything naming a host, a port, a path or a
+  device. An import that overwrites those turns a working server into a copy of another one. The export
+  needs to distinguish portable configuration from machine identity, and that split does not exist
+  anywhere today.
+- **Ownership is the Super Admin, and only the Super Admin.** `execution` and `admin` permissions are
+  stripped for every other role even when granted, so the route carrying this is owner-only by the same
+  rule — worth stating so nobody makes it a role grant later.
+
+Do this alongside `settings/a-user-s-settings-should-export-and-import-as` — one format, two scopes.
+The credential rule from that item applies unchanged: carry the shape, never the secret.