ceu.gg

# o chat de ajuda

Um motor só responde nos dois lugares. O widget do painel e o bot do Discord rodam o mesmo serviço, e a rota do Next na frente do widget é um proxy que repassa a resposta conforme ela chega.

• As respostas chegam em stream por Server-Sent Events, e o mesmo canal carrega a linha de status que o widget mostra enquanto uma ferramenta roda.
• As respostas saem de um conjunto curado de arquivos markdown sobre a plataforma, buscados por palavra-chave com peso maior para o que casa no título da seção. Não há embeddings nem banco vetorial; o corpus é pequeno o bastante para carregar inteiro, então a pergunta comum nem chega a uma busca.
• Cada canal do Discord tem um modo - responder tudo, responder só quando mencionada, ou ficar de fora. Canais de ticket ganham uma saudação, e a Sky se cala quando quem está falando é a equipe.
• O bot roda em exatamente uma réplica por vez, eleita por um advisory lock do Postgres. Perder o lock desconecta o gateway e outra réplica assume.
• Quando não consegue resolver, o escalate_to_human chama a equipe naquele canal em vez de deixar o modelo improvisar uma resposta.

# chamada de ferramentas

O modelo pode chamar 18 ferramentas. Nenhuma delas encosta no banco: cada uma é uma chamada HTTP para a API da própria plataforma levando o JWT de quem está na conversa, então uma chamada de ferramenta é autorizada do mesmo jeito que um clique no painel.

• As permissões vêm do ABAC, a mesma matriz que o painel lê. A Sky nunca tem credencial própria.
• Leitura é liberada para qualquer um logado: comunidades, servidores, status ao vivo, console, arquivos, backups, plano e saldo.
• Escrita - editar um arquivo de configuração, ligar ou desligar um servidor, rodar um comando no console, criar backup - exige plano pago ativo, e essa checagem falha fechada.
• Nada destrutivo roda na primeira chamada. A ferramenta devolve needsConfirmation, a Sky precisa perguntar, e só uma segunda chamada com confirmed: true passa.
• Cada resposta tem no máximo seis rodadas de ferramenta, e a última rodada vai sem ferramenta nenhuma, para obrigar a parar de investigar e responder.

# diagnóstico

Quando um servidor não sobe, o console é uma parede de stack trace em inglês. O diagnóstico é um loop separado que lê o servidor e escreve um laudo: o que está errado, a evidência disso, e as correções como botões.

• O modelo recebe ferramentas de leitura e oito rodadas. O prompt empurra ele a pedir vários arquivos na mesma rodada, porque rodada é o que falta.
• Ele termina chamando submit_diagnosis: um resumo em português, achados marcados como INFO, WARNING ou CRITICAL, e ações propostas. Se ele não chamar, a execução devolve texto e nenhuma ação.
• Todo achado precisa citar algo que ele leu de fato - uma linha de log, um valor de config, um nome de arquivo. Sem isso é chute, e chute faz o dono do servidor mexer no lugar errado.
• A cota é do servidor, não da conta que clicou. Ela sai do plano de hospedagem daquele servidor, e uma comunidade com vários administradores teria limites diferentes dependendo de quem pedisse.
• Limite zero também quer dizer indisponível, e é assim que a feature liga e desliga para o gratuito pelo admin sem precisar de deploy.
• Uma execução que passa do teto de custo para e devolve o que tem. Um laudo parcial vale mais que uma fatura aberta.
• Os nomes das ferramentas viram linguagem de gente antes de o laudo ser salvo. Um laudo real chegou ao cliente dizendo get_server retornou: "Não encontrei esse recurso".

# observabilidade

Prometheus e Grafana no cluster, OpenTelemetry dentro dos serviços: traces, métricas e logs em oito instrumentações no servidor. O tracing está com sampling desligado em produção, porque neste tamanho custava mais CPU do que os traces entregavam.

# segurança num plano gratuito

Um plano gratuito é um convite aberto. Criação em massa de servidores, execução de código arbitrário e upload de arquivos hostis precisam ser barrados.

• Nada de upload de executável. Plugins, mods e datapacks chegam pelo catálogo integrado do CurseForge e do Modrinth.
• Tudo passa pelo painel e pela API. Não há shell, e não há caminho de um servidor de jogo até o filesystem do host.
• Os containers rodam como não-root, com limites de CPU e memória por pod.
• As permissões são ABAC de ponta a ponta: uma matriz que o frontend lê da API, nunca uma checagem de cargo no código.

# ainda em aberto

• O scheduling aloca servidores por disponibilidade. Ainda não há estratégia regional - tudo bem neste tamanho, e não vai continuar tudo bem.
• O monitoramento diz que rede e memória vão ser os primeiros limitadores conforme a plataforma cresce, antes da CPU.