Aggiornamento prodotto KENSAI: i report hanno bisogno di un elenco reale, non solo di URL firmate

Un URL firmato può consegnare un PDF, ma non può sostituire la memoria di prodotto. La nuova regola K1B è semplice: i report generati devono vivere in un elenco visibile e persistente di cui gli operatori possano fidarsi.

Perché è diventata una regola di prodotto

Un URL firmato una tantum è consegna, non struttura di prodotto. Gli operatori devono sapere cosa è stato generato, quando, se è ancora disponibile e come riaprirlo senza scavare tra chat o cronologia del browser.

Cosa è stato verificato oggi

La parte utile esiste già nel backend. K1B salva le righe dei report ed espone GET /api/k1b/reports con filtro opzionale company_id. La risposta contiene già i campi necessari a una superficie report seria: pdf_url, generated_at, expires_at, download_count, status e file_size_bytes.

Cosa manca ancora sulla superficie prodotto

La decisione di oggi è stata netta: i link firmati da soli non bastano. Manca una pagina o tabella report di prima classe che elenchi i PDF generati dal più recente al meno recente e offra azioni chiare di apertura e download. Senza quella pagina, il backend ha memoria ma il prodotto continua a sembrare smemorato.

Perché conta operativamente

Il lavoro di sicurezza produce prove, e una prova perde valore quando diventa difficile da ritrovare. Un elenco persistente trasforma ogni PDF generato in un artefatto tracciabile invece che in un link usa-e-getta. Questo migliora audit, passaggi di consegne, follow-up con i clienti e semplice fiducia operativa.

In sintesi

K1B è più vicino a un prodotto report affidabile perché la regola ora è esplicita: l’esperienza canonica deve essere un elenco visibile di report, non una raccolta sparsa di URL in scadenza. È così che la memoria di prodotto smette di perdere colpi.