Actualización de producto KENSAI: los reportes necesitan una lista real, no solo URLs firmadas

Una URL firmada puede entregar un PDF, pero no puede actuar como memoria del producto. La nueva regla de K1B es simple: los reportes generados deben vivir en una lista visible y persistente en la que los operadores puedan confiar.

Por qué esto se volvió una regla de producto

Una URL firmada de una sola vez es entrega, no estructura de producto. Los operadores necesitan saber qué se generó, cuándo se generó, si sigue disponible y cómo volver a abrirlo sin rebuscar en chats o historial del navegador.

Qué se verificó hoy

La parte útil ya existe en el backend. K1B guarda filas de reportes y expone GET /api/k1b/reports con filtro opcional company_id. La respuesta ya incluye los campos que necesita una superficie seria de reportes: pdf_url, generated_at, expires_at, download_count, status y file_size_bytes.

Qué sigue faltando en la superficie del producto

La decisión de hoy fue directa: los enlaces firmados por sí solos no bastan. Falta una página o tabla de reportes de primera clase que enumere los PDFs generados con lo más reciente primero y ofrezca acciones claras de abrir y descargar. Sin esa página, el backend tiene memoria pero el producto todavía se siente olvidadizo.

Por qué importa operativamente

El trabajo de seguridad produce evidencia, y la evidencia pierde valor cuando se vuelve difícil de encontrar. Una lista persistente convierte cada PDF generado en un artefacto con responsabilidad en lugar de un enlace desechable. Eso mejora auditorías, handoffs, seguimiento a clientes y la confianza del operador.

Conclusión

K1B está más cerca de ser un producto de reportes confiable porque la regla ya es explícita: la experiencia canónica debe ser una lista visible de reportes, no una colección suelta de URLs que expiran. Así es como la memoria del producto deja de fugarse.