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

id, title, theme, status, created, date_source, order

id	title	theme	status	created	date_source	order
settings/the-same-for-system-settings-owned-by-the	The same for system settings, owned by the Super Admin	settings	open	2026-08-22	stated	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.