Admin settings shell + Peering pilot (epic #250, phase 1) #251

New issue

Closed

opened 2026-08-16 17:11:31 +00:00 by Cordy · 0 comments

Cordy commented

2026-08-16 17:11:31 +00:00

Owner

Phase 1 of #250 (chosen layout: Option A — grouped rail + tabs). Blocks phases 2–5.

Build the consolidated admin settings shell and prove it by porting one topic.

Scope

Single Administration entry (account menu), admin-gated as today (auth.admins / auth.adminGroups).
Grouped left rail (sections: Instance · Access · Sharing & spaces · Federation · Billing) + per-topic header + tab strip + setting rows.
Deep-linkable routing: #/admin/<topic> and #/admin/<topic>/<tab>.
Cairn's skin (glacier-teal active states, amber for keys/warnings, mono for fingerprints), reusing the existing peering-card component styles — not a new visual language.
Pilot topic: Peering ported in as the first real topic (tabs: Relationships / Inbound keys / Settings), reusing existing peering endpoints. Old peering entry redirects into the shell.

Non-goals: no settings-API changes; per-user settings untouched.

Acceptance: shell renders with rail + tabs; deep links resolve to the right tab; admin gate enforced; Peering fully functional inside the shell (register/edit/disable/keys); legacy peering entry redirects; CI-green, deployed, dogfood-verified.

Depends on: none.

Phase 1 of #250 (chosen layout: Option A — grouped rail + tabs). **Blocks phases 2–5.** Build the consolidated admin settings shell and prove it by porting one topic. **Scope** - Single **Administration** entry (account menu), admin-gated as today (`auth.admins` / `auth.adminGroups`). - Grouped left rail (sections: Instance · Access · Sharing & spaces · Federation · Billing) + per-topic header + tab strip + setting rows. - Deep-linkable routing: `#/admin/<topic>` and `#/admin/<topic>/<tab>`. - Cairn's skin (glacier-teal active states, amber for keys/warnings, mono for fingerprints), reusing the existing peering-card component styles — not a new visual language. - **Pilot topic: Peering** ported in as the first real topic (tabs: Relationships / Inbound keys / Settings), reusing existing peering endpoints. Old peering entry redirects into the shell. **Non-goals:** no settings-API changes; per-user settings untouched. **Acceptance:** shell renders with rail + tabs; deep links resolve to the right tab; admin gate enforced; Peering fully functional inside the shell (register/edit/disable/keys); legacy peering entry redirects; CI-green, deployed, dogfood-verified. Depends on: none.