Sem backend permanente
A coleta roda no GitHub Actions e produz um snapshot JSON incluído no artifact do Pages.
Estudo de caso arquitetural · engineering intelligence
O Repo Control Center nasceu de um problema operacional simples: conforme o número de repositórios cresce, CI, delivery, releases, segurança, pacotes e atividade ficam espalhados demais para formar uma visão confiável do conjunto. A solução coleta essas evidências fora do navegador, explicita quando a informação está incompleta e publica um snapshot estático para consulta.
O dashboard é somente leitura. Tokens usados na coleta permanecem no GitHub Actions e nunca são enviados para a SPA publicada.
Problema
Build, deployment, release, atividade, alertas, pacotes e itens abertos existem em superfícies e APIs diferentes. Abrir repositório por repositório funciona enquanto o conjunto é pequeno; depois disso, a própria busca por contexto vira custo operacional.
O desafio não era criar mais um dashboard visual. Era construir uma linguagem comum para interpretar o estado dos projetos sem transformar ausência de dados em falha, nem exigir infraestrutura permanente apenas para agregar sinais que mudam em baixa frequência.
Restrições e atributos de qualidade
A coleta roda no GitHub Actions e produz um snapshot JSON incluído no artifact do Pages.
A SPA consome apenas dados estáticos. Tokens e permissões ficam restritos ao ambiente de automação.
Cada repositório informa coleta completa, parcial ou indisponível e uma confiança derivada da cobertura das fontes.
Consultas opcionais podem falhar sem impedir a publicação do restante do portfólio; a degradação permanece explícita.
Decisões arquiteturais
O collector Node.js consulta as APIs durante o workflow, pagina resultados, limita concorrência e normaliza as evidências antes da publicação.
Trade-off: a atualização é periódica, não em tempo real.
O JSON publicado desacopla a SPA das APIs autenticadas e transforma a coleta em um contrato de leitura reproduzível.
Trade-off: o estado exibido representa o último workflow bem-sucedido.
A interface oferece filtros, busca, detalhe por repositório e leitura agregada sem exigir serviço de aplicação em execução.
Trade-off: rotas detalhadas usam hash e o conteúdo depende do snapshot publicado.
complete, partial e unavailable descrevem a observabilidade da coleta; a saúde do repositório permanece uma classificação distinta.
Trade-off: a UI precisa comunicar incerteza em vez de resumir tudo em uma única cor.
CI, quality, security, mutation, delivery, release, Pages e maintenance têm papéis diferentes; apenas o sinal correto deve influenciar build e delivery.
Trade-off: heurísticas precisam de override quando nomes não expressam intenção.
Dependabot, code scanning, workflow de segurança e OpenSSF Scorecard são apresentados separadamente. Falta de acesso reduz confiança, não vira alegação de segurança.
Trade-off: a leitura é mais honesta, porém menos simplificada.
Fluxo
Trade-offs e limites
O cron atualiza aproximadamente a cada hora. Isso é suficiente para manutenção de portfólio, mas não substitui monitoramento operacional de produção.
Deploys externos ao GitHub podem não aparecer; versão fica vazia quando não existe associação confiável com a entrega.
Actions, Deployments e alertas de segurança podem exigir permissões adicionais. A ausência é reportada como perda de confiança.
As métricas de 30 dias são recalculadas no estado atual. Tendência temporal exige persistência de snapshots anteriores.
Nomes de workflows fora das convenções podem ficar desconhecidos. Configuração por repositório funciona como override explícito.
Alguns headers e comportamentos de hospedagem não são controlados pela aplicação e precisam ser tratados como responsabilidade da plataforma.
Evidências públicas
Leitura arquitetural
O principal aprendizado do projeto não é “como montar um dashboard”. É que consolidar sinais de engenharia exige preservar a diferença entre ausência, falha de coleta, evidência negativa e evidência positiva. Sem isso, uma interface simples pode produzir uma interpretação incorreta do portfólio.
Ao tornar cobertura e confiança explícitas, o Repo Control Center trata a qualidade da própria observação como parte do domínio — uma decisão que reduz falsos diagnósticos e mantém a solução útil mesmo quando nem todas as fontes estão disponíveis.