Auditoria de 21 modais Bootstrap, bugs pontuais e suspeita no billing Opus

O dia foi dominado por uma coisa só: encerrar a auditoria de modais que tinha começado na véspera. A pergunta que destravou o trabalho veio de uma inconsistência visual específica — dois modais na mesma tela de agendamento com padrões diferentes nos botões do rodapé. Dali em diante foi trabalho em bloco.

Maratona de modais Bootstrap 5

A inconsistência era simples de enxergar no mobile: o modal “confirmar agendamento” colocava os botões um em cada linha, enquanto o “gerar prompt” colocava os dois na mesma linha. Sem padrão definido, cada modal tinha sido construído na base do bom senso de quem estava na sprint naquele momento — e o resultado era cinco ou seis sprints de inconsistência acumulada visível para qualquer usuário em celular.

O trabalho virou três etapas encadeadas no Codex.

Etapa 1 — Padronizar o rodapé de todos os modais (2c7cd24c)
Definiu o padrão base: botões com layout unificado, sem variação arbitrária entre modais.

Etapa 2 — Aplicar flex-column/flex-sm-row em 21 modais de uma vez (e1e7424c)
O padrão escolhido foi d-flex flex-column flex-sm-row no rodapé: coluna empilhada em mobile, linha horizontal a partir do breakpoint sm. A varredura foi ampla — 21 modais Bootstrap cobertos num único commit.

Etapa 3 — Documentar os 21 itens como concluídos (bdca730a)
Checkmarks na documentação antes de partir pra revisão manual.

À tarde, a revisão manual cobriu o que tinha ficado fora da varredura inicial: modais do UIKit e os modais custom que não eram Bootstrap puro (0ae53726). Saíram ainda dois commits de ajustes na tela de agendamento — otimização de CSS (a7a13e2c) e dois ajustes responsivos de layout (881a39cd e checkpoint 2839092e).

A leitura honesta: isso era dívida de cinco ou seis sprints onde cada modal foi construído da forma disponível naquele momento. Sentar pra fazer a varredura de uma vez com um agente que aceita escopo amplo foi muito mais barato do que continuar consertando modal por modal quando o bug aparecia na tela de um usuário.

Bug do player de vídeo: diagnóstico antes de correção

Um bug no player de vídeo foi registrado mas não corrigido hoje. A decisão foi instrumentar o diagnóstico primeiro (df45fd56) — adicionar logging pra enxergar exatamente onde o comportamento quebra antes de tentar qualquer correção. O diagnóstico ficou instrumentado para a noite. A correção entra na próxima sessão com os dados coletados.

Bug do dropdown de participantes

Na tela de revisão, o dropdown de participantes estava se comportando errado. O Codex corrigiu o componente (29f991ba) em conjunto com dois outros ajustes relacionados: mapeamento de gênero incorreto e agrupamento de categorias no modal de participante (876ae47d). Os três tinham origem no mesmo relato e foram tratados juntos.

Investigação de consumo de tokens Opus

Uma sessão separada no Claude Code foi aberta pra investigar algo que estava incomodando há dias: o billing mostrava consumo de tokens Opus mesmo quando os prompts estavam configurados pro Haiku. A pergunta que entrei na sessão foi deliberadamente sem margem pra probabilidade: “tem algo consumindo tokens Opus mesmo quando o prompt é no Haiku?”

A investigação ficou aberta como hipótese viva. Duas candidatas:

1. Hook de sub-agente que sobe pro Opus por padrão, independente do modelo configurado na conversa principal
2. Skill auto-ativada que solicita o modelo mais caro sem considerar o contexto da conversa

Sem conclusão fechada hoje — fica como item ativo pra próxima sessão dedicada a billing.

Plano de testes Playwright

Outra sessão no Claude Code, desta vez no kmaroteApp, foi dedicada a planejar uma rotina de testes E2E. Pedi cinco opções com comparativo de ferramentas. Antes de qualquer proposta, orientei o agente a olhar o que já existe no repositório — pra não propor stack novo onde já tem estrutura.

A direção que ficou foi Playwright cobrindo todas as páginas documentadas, com comparativo visual pra capturar telas com documentação desatualizada ou faltante. Não virou commit hoje — é trabalho de planejamento que mora em docs/planejamento/ e vai aparecer na próxima janela quando o plano sair do rascunho.

Larissa offline

A máquina Larissa ficou inacessível por SSH durante a coleta do devlog — hostname não resolveu. Não é possível afirmar a causa: rede local, máquina desligada ou problema de DNS. Todos os dados de Larissa (commits e sessões Claude Code) chegaram como ERROR. Fica como item de checagem pro próximo dia.

---

Estatísticas do dia (geradas automaticamente):

Atividade no PC:

• Tempo ativo: 4h07min

Por categoria (do que ficou ativo):

• Larissa Project: 1h54min
• Coding: 1h05min
• Uncategorized: 48min
• Communication: 20min

Top apps: Chrome (1h33min) · Codex (1h07min) · Antigravity IDE (1h05min) · WhatsApp (7min) · Notepad (6min)

Trabalho com IA:

• Conversas claude.ai: 0 (0 mensagens)
• Sessões Claude Code: 11 (Windows, kmaroteApp + elquercarlos) · Sessões Codex: 6 (Windows, kmaroteApp)

Código produzido:

• Commits: 11 (kmaroteApp) · 1 (elquercarlos, devlog anterior)

Devlog do dia:

• 1 draft consolidado (2026-06-02-2330.md)