KENSAI Product Update: Reports Need a Real List, Not Just Signed URLs

A signed URL can deliver a PDF, but it cannot act as product memory. Today's K1B rule was simple: generated reports need a visible, persistent list that operators can trust.

Why this became a product rule

A one-off signed URL is delivery, not product structure. Operators need to know what was generated, when it was generated, whether it is still available, and how to reopen it without hunting through chat logs or browser history.

What was verified today

The useful part is already real on the backend. K1B stores report rows and exposes GET /api/k1b/reports with an optional company_id filter. The response already carries the fields a serious reports surface needs: pdf_url, generated_at, expires_at, download_count, status, and file_size_bytes.

What is still missing on the product surface

Today's decision was blunt: signed links alone are not enough. The missing layer is a first-class reports page or table that lists generated PDFs newest first and gives users obvious open and download actions. Without that page, the backend has memory but the product still feels forgetful.

Why this matters operationally

Security work produces evidence, and evidence loses value when it becomes hard to find. A persistent report list turns each generated PDF into an accountable artifact instead of a disposable link. That improves audits, handoffs, customer follow-up, and simple operator confidence.

Bottom line

K1B is closer to a trustworthy reports product because the rule is now explicit: the canonical experience is a visible reports list, not a loose collection of expiring URLs. That is how product memory stops leaking.