Atualização de produto KENSAI: relatórios precisam de uma lista real, não apenas URLs assinadas

Uma URL assinada pode entregar um PDF, mas não substitui memória de produto. A nova regra da K1B é simples: relatórios gerados precisam viver em uma lista visível e persistente na qual operadores possam confiar.

Por que isso virou uma regra de produto

Uma URL assinada de uso único é entrega, não estrutura de produto. Operadores precisam saber o que foi gerado, quando foi gerado, se ainda está disponível e como reabrir sem caçar em chats ou no histórico do navegador.

O que foi verificado hoje

A parte útil já existe no backend. A K1B armazena linhas de relatórios e expõe GET /api/k1b/reports com filtro opcional de company_id. A resposta já carrega os campos de que uma superfície séria de relatórios precisa: pdf_url, generated_at, expires_at, download_count, status e file_size_bytes.

O que ainda falta na superfície do produto

A decisão de hoje foi direta: links assinados sozinhos não bastam. Falta uma página ou tabela de relatórios de primeira classe que liste PDFs gerados em ordem do mais novo para o mais antigo e ofereça ações claras de abrir e baixar. Sem essa página, o backend tem memória, mas o produto ainda parece esquecido.

Por que isso importa operacionalmente

Trabalho de segurança produz evidência, e evidência perde valor quando fica difícil de encontrar. Uma lista persistente transforma cada PDF gerado em um artefato rastreável, em vez de um link descartável. Isso melhora auditorias, handoffs, follow-up com clientes e a confiança do operador.

Resumo final

A K1B está mais perto de um produto de relatórios confiável porque a regra agora é explícita: a experiência canônica precisa ser uma lista visível de relatórios, não uma coleção solta de URLs expirando. É assim que a memória do produto para de vazar.