# Sentinel Diary #4: From Dashboard to Incident Response — The deterministic path to reliable SRE

Context: The "Vibe Coding" Evolution

We are currently at v0.10.20. Looking back at the last post, we were celebrating the FinOps module. Since then, the project has undergone a significant architectural shift.

My development stack evolved: I started with Claude Code, which generated the original monolith (main.go reaching ~2,200 lines). I then used Gemini 3.1 Pro to execute a massive refactoring, decomposing the monolith into a clean pkg/ structure (api, k8s, store, incidents). Finally, I integrated Minimax 2.7 (via Opencode) to push from v0.10.17 to v0.10.20, building the new "no-scroll" dashboard. I continue to use Gemini CLI as my core orchestration layer. The result? Higher velocity, better code structure, and a dashboard that finally feels like an SRE tool, not a prototype.

M3: Deterministic Incident Intelligence

The dashboard was excellent for viewing costs, but I realized it was "read-only." It showed the state, but it didn't detect issues. I needed it to assist the operator, not just display data.

1. Code Refactoring (The end of the "God Object")

The main.go file was a massive 2,282 lines of code. It was a monolith of responsibility. I guided the Gemini 3.1 Pro agent to refactor it into dedicated packages: pkg/api, pkg/k8s, pkg/store, and pkg/incidents. It now sits at a lean ~220 lines.

2. Deterministic Detection vs. LLM Hype

I wanted the system to be useful even without an LLM. I implemented /api/incidents using pure deterministic logic.

• The logic: Correlating a CrashLoopBackOff status with a spike in CPU usage.
• The severity: We now inject a severity field, allowing the dashboard to prioritize what matters.
• The UI: The dashboard is now "no-scroll" and event-driven. You can toggle between FinOps and SRE views without leaving the context.

M4: Security Hardening (WIP)

Observability is a liability if your tool is an attack vector. We are currently executing Milestone 4, focusing on hardening the system:

• DOM-based XSS: During a security audit via CodeQL, I received high-severity alerts indicating the dashboard was vulnerable to XSS due to dynamic rendering via innerHTML. I instructed the AI to integrate DOMPurify to sanitize inputs before rendering.
• Data Resilience (In progress): We are migrating from emptyDir to PersistentVolumeClaim (PVC) for PostgreSQL, ensuring pod restarts no longer result in data loss.
• CI/CD Pipeline (Completed): I implemented GitHub Actions. Every push or pull_request now triggers go test and helm lint. If the build is red, it does not merge.

Lessons Learned

"If the LLM goes down, Sentinel stays useful."

The deterministic-first approach is not just a design choice; it is a necessity for SRE tools. I observed that agents (like Minimax/Gemini) are brilliant, but they shouldn't be the central nervous system of your reliability tool. They should be the "specialist on call"—highly valuable, but not required for the system to remain upright.

Current Cluster State

Next steps: Prepare for M7, the real-world lab with Online Boutique (Chaos Engineering).

Portuguese Version

Contexto: A Evolução do "Vibe Coding"

Estamos na v0.10.20. Olhando para o post anterior, estávamos celebrando o módulo de FinOps. Desde então, o projeto passou por uma mudança arquitetural significativa.

Minha stack de desenvolvimento evoluiu: comecei com o Claude Code, que gerou o monólito original (main.go chegando a ~2.200 linhas). Em seguida, usei o Gemini 3.1 Pro para executar uma refatoração massiva, decompondo o monólito em uma estrutura limpa pkg/ (api, k8s, store, incidents). Finalmente, integrei o Minimax 2.7 (via Opencode) para subir da v0.10.17 para a v0.10.20, construindo o novo dashboard "no-scroll". Continuo usando o Gemini CLI como minha camada de orquestração central. O resultado? Maior velocidade, estrutura de código superior e um dashboard que finalmente parece uma ferramenta de SRE, não um protótipo.

M3: Inteligência Determinística de Incidentes

O dashboard era excelente para ver custos, mas percebi que ele era "somente leitura". Ele mostrava o estado, mas não detectava problemas. Eu precisava que ele auxiliasse o operador, não apenas exibisse dados.

1. Refatoração de Código (O fim do "God Object")

O arquivo main.go tinha 2.282 linhas. Era um monólito de responsabilidade. Orientei o agente do Gemini 3.1 Pro a refatorá-lo em pacotes dedicados: pkg/api, pkg/k8s, pkg/store e pkg/incidents. Agora ele tem enxutas ~220 linhas.

2. Detecção Determinística vs. Hype de LLM

Eu queria que o sistema fosse útil mesmo sem LLM. Implementei o /api/incidents usando lógica puramente determinística.

• A lógica: Correlacionar um status CrashLoopBackOff com um pico na utilização de CPU.
• A severidade: Agora injetamos um campo severity, permitindo que o dashboard priorize o que importa.
• A UI: O dashboard agora é "no-scroll" e orientado a eventos. Você pode alternar entre as visões de FinOps e SRE sem sair do contexto.

M4: Hardening de Segurança (Em andamento)

Observabilidade é um risco se a ferramenta for um vetor de ataque. Estamos no meio da execução do Milestone 4, focando em blindar o sistema:

• XSS baseado em DOM: Durante uma auditoria de segurança via CodeQL, recebi alertas de alta severidade indicando que o dashboard estava vulnerável a XSS por renderizar conteúdo via innerHTML. Instruí o agente a integrar o DOMPurify para sanitizar todo input antes da renderização no DOM.
• Resiliência de Dados (Em andamento): Iniciamos a migração de emptyDir para PersistentVolumeClaim (PVC) real para o PostgreSQL, garantindo que restarts de pod não resultem em perda de dados.
• Pipeline de CI/CD (Concluído): Implementei GitHub Actions. Todo push ou pull_request agora dispara go test e helm lint. A regra é clara: build vermelho não entra na main.

Lições Aprendidas

"Se o LLM cair, o Sentinel continua útil."

A abordagem deterministic-first não é apenas uma escolha de design; é uma necessidade para ferramentas de SRE. Observei que agentes (como Minimax/Gemini) são brilhantes, mas não devem ser o sistema nervoso central da sua ferramenta de confiabilidade. Eles devem ser o "especialista de plantão" — altamente valioso, mas não obrigatório para o sistema permanecer de pé.

Próximos passos: Preparar o M7, o laboratório real com Online Boutique (Chaos Engineering).

Repositório: https://github.com/boccato85/Sentinel