Relatórios offline mais seguros, CSM como referência e site mais público

Dia de aparar improvisos em um produto real e deixar meu próprio site mais legível para humanos, buscadores e agentes.

Projeto cliente (NDA)

O grosso do dia foi no fluxo de relatórios. Revisei o comportamento offline, online e em conexão instável, com foco em uma regra simples: rascunho precisa ser uma ação explícita, não um efeito colateral que aparece no meio do caminho. Também entrou ajuste de mobile para evitar salto de scroll e deixar a criação do relatório mais previsível.

Em paralelo, a modelagem de dados recebeu uma revisão mais crítica. O ponto não era normalizar por reflexo, mas separar o que é entidade real, o que é snapshot operacional e o que precisa continuar texto por causa do uso offline e do histórico do relatório. Essa conversa também abriu uma frente sobre isolamento do banco local por ambiente e usuário, para evitar mistura de dados quando alguém troca de conta no mesmo dispositivo. No fim do dia, isso virou implementação mais concreta: IndexedDB e Background Sync passaram a considerar o usuário logado, dados legados receberam migração e as validações do fluxo de piloto ficaram mais explícitas.

Também houve trabalho de qualidade: testes de integração contra PostgreSQL real, correções em suites existentes, revisão de conflitos com main, análise de PRs e uma issue de QA manual cobrindo os principais casos de uso. A cobertura automatizada ainda não substitui a passada manual, mas já começou a transformar um checklist pesado em um plano de teste mais repetível. Também preparei uma checklist específica para testar o novo relatório offline em PWA no dispositivo real, incluindo criação, rascunho, retomada, sincronização e falhas de conectividade.

Fechei a frente com guardrails para implementação por agentes. O design system ganhou regras mais explícitas para escala, espaçamento e composição, além de um endurecimento do Biome para reduzir any e decisões soltas de frontend. Também entraram skills de projeto para planejamento e testes com navegador, para que agentes trabalhem com mais contexto antes de editar código.

tgmarinho-ai-website

No meu site, usei o CSM como referência prática de landing page, rota de links, SEO, AEO e leitura por agentes. O trabalho começou pela comparação entre os dois sites: o que o CSM já fazia bem em metadados, páginas de conversão, robots, manifest, dados estruturados e arquivos de apoio virou uma lista objetiva do que aplicar aqui.

A partir disso, entrou a leva de superfície pública: /lp, /links, humans.txt, security.txt, manifest, robots, sitemap, structured data e atualização dos arquivos llms.txt. É o tipo de mudança pequena por arquivo, mas grande no conjunto: mais caminhos de entrada, mais contexto para agentes e uma presença mais fácil de interpretar fora da home.

Também comecei a trabalhar um post sobre modelagem de dados em sistemas existentes. A ideia é cruzar cardinalidade, flexibilidade de schema, CRUD, relatórios e dashboards sem cair na resposta automática de "normaliza tudo" ou "deixa tudo flexível". O texto ainda precisa de corte fino, mas o eixo está claro: modelagem boa é aquela que respeita o caso de uso, o histórico dos dados e o custo de mudar depois.

O dia terminou com a mesma pergunta nos dois lados: onde a flexibilidade ajuda o produto, e onde ela só esconde falta de decisão?