Decidir: aba "Sistema" no admin — diagnóstico read-only da config do servidor (sem edição)

[milkway]

Status: a decidir no futuro — NÃO implementar agora. Registrado após a auditoria 2026-06 (#730–#746) para não perder o racional da discussão.

Contexto

Surgiu a pergunta: vale uma aba de configuração do server: no admin, para não depender do terminal? A conclusão da discussão foi não editar infra pela web, mas que uma aba read-only de diagnóstico resolveria a maior parte da necessidade real (conferir é muito mais frequente que mudar).

Por que NÃO editar server: pela web (racional registrado)

1. Boot-time, não runtime — port, bind-address, context-path, hosts são consumidos na subida; state.config é um Arc<Config> imutável. Edição ao vivo exigiria hot-reload (ArcSwap) ou um "salvar e reiniciar" pior que o terminal.
2. Risco de lockout — errar base-path/bind/useForwardHeaders de dentro do admin derruba o próprio admin. O padrão "apply + rollback se não confirmar" é complexidade demais para o ganho.
3. Superfície de segurança — o modelo é deliberado: secrets só via ${ENV}, volumes Admin-only, DB nunca vê infra. Um editor web do YAML inverteria isso (admin comprometido → controla bind/hosts/volumes). ShinyProxy também não faz.
4. Frequência ≈ zero — server: muda no deploy inicial (que já exige terminal) e raramente depois; o que muda toda semana (catálogo/aparência/usuários) já está no admin.

Escopo proposto (se aprovado): aba "Sistema", Admin-only, read-only

• Config efetiva: bind, porta, base-path, useForwardHeaders, heartbeat global, max-body-size, modo do DB (sqlite/pg), backend Docker, e os hosts multi-host com estado de conexão de cada um (o fan-out do MultiHostDockerBackend silently inherits no-op trait defaults — liveness reconcile, disk panel and stop_spec reap are all dead on multi-host #734 degrada silenciosamente — merece superfície).
• Warnings de validação do boot (config/CLI P3 batch: validation gaps, silently-ignored ShinyProxy fields, env-ref edge cases, dead core Router #743) — hoje só no log; aqui ficariam visíveis (IgnoredCompatField, ReplicaCeilingZero, etc.).
• Env vars de operação como setada/não-setada (RUSCKER_ADMIN_TOKEN, RUSCKER_MASTER_KEY, RUSCKER_COOKIE_KEY) — nunca valores.
• Detector de proxy reverso: requests chegando com X-Forwarded-Proto + useForwardHeaders off → aviso "cookies sairão sem Secure" (follow-up natural do fix(proxy,sessions): XFF/XFP trust, at_capacity, hot-path write, sweep race, latent footguns (#744) #762).
• Versão, uptime.

Boa parte já existe espalhada (startup banner na aba Logs, banner de backend no dashboard) — seria consolidação, custo baixo.

Fora do escopo (decidido contra, manter assim salvo nova discussão)

• Edição de qualquer campo de server:/proxy: de infra pela web.
• Editor do YAML pelo admin.
• Caso apareça dor real com um knob específico (ex.: heartbeat-timeout global, metrics-interval), promover esse knob individualmente a setting runtime no DB — caso a caso, como foi feito com a aparência — em vez de abrir o server: inteiro.