Desenvolver um app web que mostra logs e métricas de contêineres ao vivo

## Escrever revisões curtas que apontem só bugs e bloqueios Use o modo ultrabreve em revisões de solicitações de alteração e respostas de mantenedores. Informe somente bugs, problemas de segurança e impedimentos. Use bullets curtos, adicione referências `arquivo:linha` quando pertinente, omita seções como Pontos fortes ou Resumo e limite toda a resposta a aproximadamente 10 a 15 linhas. Escreva como um mantenedor humano. Não use travessões longos ou médios, contrastes retóricos no formato “não X, mas Y”, elogios introdutórios, recapitulações finais, rótulos inline em negrito ou ressalvas vazias. Letras minúsculas informais e contrações são aceitáveis. Declare a decisão, dê um motivo e pare. ## Pedir a quem relatou que teste o build da mudança Quando um problema relatado for corrigido em uma solicitação de alteração aberta, peça ao relator que teste o artefato de integração contínua criado para essa solicitação. Forneça a referência exata da imagem ou do pacote pré-compilado, usando um padrão genérico como `{registry}/{image}:change-{number}`. Isso permite que o relator confirme a correção antes do próximo lançamento. Antes de recomendar esse caminho, confirme se a automação realmente publica um artefato com tag para cada solicitação de alteração. ## Entender as camadas do backend e do frontend antes de editar Trate o sistema como um backend HTTP compilado e um frontend tipado de página única. O backend cuida de roteamento, autenticação, clientes de containers ou workloads, streams ao vivo de logs e métricas, ações, notificações e comunicação com agentes remotos. O frontend cuida de views baseadas em arquivos, componentes reutilizáveis, stores reativos, composables de stream, roteamento, localização e preferências do usuário. Ofereça suporte explícito a cada modo de implantação documentado, incluindo serviço independente ou multi-host, orquestração em cluster e operação com agentes remotos. Não presuma que uma alteração que funciona com uma implementação de client funcionará com todos os backends. Mantenha clara a direção principal das dependências: `HTTP handlers -> host service -> per-host service -> domain client -> runtime implementation`. ## Compilar e testar com os alvos documentados Configure o projeto instalando as dependências e executando o alvo de geração de certificados, schemas ou código de protocolo. Use a tarefa completa de desenvolvimento para hot reload coordenado do backend e do frontend, ou execute os dois watchers separadamente ao isolar um problema. Gere os assets do frontend antes de incorporá-los a um build completo do backend. Mantenha alvos distintos para a distribuição do frontend, a aplicação inteira e a imagem implantável. Use o alvo de preview para inspecionar localmente um build semelhante ao de produção. Execute testes do backend, testes unitários do frontend, verificação de tipos e testes de integração no navegador por meio dos alvos documentados. Use `TZ=UTC` em testes do frontend sensíveis a timestamps e o modo watch somente durante o trabalho local iterativo. ## Separar as camadas do backend atrás de uma interface de cliente comum Mantenha o roteamento HTTP e os handlers de streaming acima dos serviços de host e client. Coloque operações específicas de runtime atrás de uma interface compartilhada de domain client e implemente essa interface para cada backend de container, cluster ou agente remoto aceito. Separe providers de autenticação, modelos de domínio, parsing de eventos, avaliação de notificações e entrega de notificações dos handlers de transporte. Mantenha o parsing da linha de comando e a orquestração multi-host nas camadas de suporte, em vez de duplicá-los nos handlers. Para uma nova operação de workload, atualize a interface do domain client, cada implementação de runtime aplicável, o wrapper de serviço por host e o handler HTTP com sua rota. Não ignore uma camada para fazer apenas um modo de implantação passar. ## Manter o estado e os tipos de log do frontend em seus papéis Mantenha route views, componentes importados automaticamente, stores reativos, composables de stream e plug-ins da aplicação em suas funções estabelecidas. Trate como imutável a configuração injetada pelo HTML renderizado pelo backend. Mantenha preferências persistidas atrás de uma abstração de armazenamento reativa. Represente texto de uma linha, objetos estruturados e mensagens agrupadas de várias linhas como tipos distintos de entrada de log. Use o alias compartilhado de mensagem em vez de repetir um tipo union e crie as entradas por meio de uma factory que selecione o tipo correto para cada evento. Componentes reutilizados entre mudanças de rota ou workload devem atualizar todo o estado derivado. Se um gráfico otimizar atualizações alterando apenas sua última barra, exponha um método de recálculo completo e chame-o quando toda a série de dados for substituída. ## Respeitar os limites fixos dos fluxos de logs e métricas Use server-sent events para streams de logs, eventos de ciclo de vida e métricas, e conexões WebSocket para sessões interativas de attach ou execução. Envie ações de workload que alteram estado por solicitações HTTP explícitas, não por streams somente de leitura. Armazene eventos recebidos pelo frontend por 250 milissegundos, mas faça flush depois de no máximo 1.000 milissegundos. Agrupe as atualizações reativas e, quando as mensagens exibidas ultrapassarem 400 entradas, substitua ou marque as entradas mais antigas conforme o contrato do viewer. Mantenha o histórico de métricas em uma janela móvel de no máximo 300 itens. Suavize as métricas com uma média móvel exponencial de alpha 0.2, normalize os valores de CPU pela contagem permitida de núcleos ou pela contagem de núcleos do host e mantenha separados os valores percentuais e absolutos de memória. Reduza a amostragem dos gráficos para a largura disponível da tela. A substituição de toda a série de dados, como ao trocar de workload, deve acionar um recálculo completo, mesmo quando os ticks comuns atualizam apenas a barra final. ## Tratar separadamente cada modo de login e implantação Ofereça modos separados de autenticação sem credenciais, por arquivo local e por forward proxy. Use tokens assinados com expiração para autenticação local, valide o arquivo de usuários configurado e mantenha a autorização baseada em funções independente do provider de identidade. No modo independente, combine clients locais e remotos por meio de um manager com capacidade de retry. No modo em cluster, descubra os nodes pela API de orquestração e conecte-se a um agente em cada node. No modo nativo do cluster, implemente a mesma interface de domain client pela API dessa plataforma. No modo de agente remoto, exija transporte autenticado por certificado. Mantenha a seleção do modo no ponto de entrada da aplicação. Um recurso permanece incompleto até que seu comportamento esteja definido para todo modo aplicável ou seja explicitamente rejeitado nos modos não aceitos. ## Adicionar recursos novos em todas as camadas afetadas Para uma nova rota HTTP, registre a rota, implemente seu handler, determine o alvo pelo serviço de host e retorne dados estruturados ou estabeleça o stream pretendido. Para uma nova view de logs, adicione a route view, crie um composable de stream, monte a URL filtrada da API, gerencie o buffering, retorne mensagens e controles reativos e reutilize o viewer estabelecido. Para uma nova métrica, amplie o tipo de estatística do backend, extraia e calcule o valor, atualize o schema do protocolo, regenere o código do protocolo e exponha o campo no modelo do frontend quando a interface precisar dele. Os streams de eventos existentes devem transportar a atualização sem um transporte paralelo. Para um novo canal de notificações, implemente a interface do dispatcher, registre-o na factory de dispatchers, adicione seu formulário de configuração e preserve o comportamento persistido das regras e do estado dos alertas. ## Limitar chamadas a ferramentas remotas e repetir só falhas temporárias Não conecte enquanto um dispatcher remoto não estiver configurado. Use um stream bidirecional para descoberta e chamadas de ferramentas, encaminhe as chamadas por um único registry e limite as execuções simultâneas a cinco com um semáforo ponderado. Reconecte falhas transitórias com backoff exponencial de 1 a 30 segundos, acrescido de jitter. Interrompa as novas tentativas de forma permanente em respostas de permission denied que indiquem credenciais inválidas ou um plano indisponível. Armazene uma única vez em cache as definições imutáveis de ferramentas, para que a operação remota desativada acrescente sobrecarga desprezível. Para adicionar uma ferramenta, defina seu name, description e schema de parâmetros; adicione seu tipo de resposta ao union de resultados do protocolo; regenere o código do protocolo; registre o caso de dispatch; implemente-o atrás da interface do serviço de host; e adicione testes específicos. ## Classificar cada evento de log e transmiti-lo sem acumular na memória Analise streams multiplexados do runtime lendo seus headers e payloads, depois classifique cada evento bruto como dado estruturado, evento agrupado de várias linhas ou evento de uma linha. Extraia a severity com padrões explícitos, serialize o evento de domínio e entregue-o pelo stream ao vivo. Para agentes remotos, traduza chamadas do domain client em solicitações do protocolo, delegue-as ao client do runtime local e converta as respostas de volta em modelos de domínio. Preserve o comportamento de streaming de logs, métricas e eventos de ciclo de vida, em vez de acumular resultados sem limite na memória. O filtro por level, query ou expressão regular deve preservar um limite claro de resultados. As ações de workload devem permanecer atrás de um controle explícito de habilitação. ## Fazer testes repetíveis e depurar as conexões ao vivo Execute os testes do backend com o detector de race condition. Use a biblioteca de assertions do projeto de forma consistente, execute os testes do frontend em UTC e rode os testes de integração no navegador com a configuração de serviço exigida. Regenere os certificados e artefatos de protocolo necessários antes de tratar falhas de build como defeitos no código. Durante o desenvolvimento com assets não incorporados, habilite o serviço pelo filesystem e o hot reload coordenado. Alterações no backend devem reiniciar seu watcher, enquanto alterações no frontend devem usar substituição de módulos sem forçar uma reinicialização completa. Para depurar, habilite o logging de debug no backend, inspecione o estado do frontend com as ferramentas de desenvolvimento do navegador e examine no painel de rede as conexões de server-sent events e WebSocket. Revise a diferença final para que arquivos gerados e edições automatizadas não ocultem alterações sem relação com a tarefa.