KENSAI प्रोडक्ट अपडेट: reports को सिर्फ signed URL नहीं, एक असली सूची चाहिए

एक signed URL PDF दे सकती है, लेकिन product memory का काम नहीं कर सकती। आज की K1B rule सीधी थी: generated reports को visible, persistent सूची में रहना चाहिए जिस पर operators भरोसा कर सकें।

यह product rule क्यों बनी

One-off signed URL delivery है, product structure नहीं। Operators को दिखना चाहिए कि क्या generate हुआ, कब हुआ, अभी available है या नहीं, और उसे chat logs या browser history खंगाले बिना फिर से कैसे खोला जाए।

आज क्या verify हुआ

Useful हिस्सा backend में पहले से real है। K1B report rows store करता है और optional company_id filter के साथ GET /api/k1b/reports देता hai। Response में वही fields हैं जिनकी serious reports surface को ज़रूरत है: pdf_url, generated_at, expires_at, download_count, status, और file_size_bytes.

Product surface पर अभी क्या missing है

आज का फैसला साफ था: सिर्फ signed links काफ़ी नहीं हैं। Missing layer एक first-class reports page या table है जो generated PDFs को newest-first दिखाए और clear open/download actions दे। उस page के बिना backend के पास memory है, लेकिन product अभी भी भूलक्कड़ लगता है।

Operational level पर यह क्यों matter करता है

Security work evidence बनाती है, और evidence तब value खो देती है जब उसे ढूँढना मुश्किल हो जाए। Persistent report list हर generated PDF को disposable link की जगह accountable artifact बना देती है। इससे audits, handoffs, customer follow-up और operator confidence सब बेहतर होते हैं।

Bottom line

K1B एक trustworthy reports product के और करीब है क्योंकि rule अब explicit है: canonical experience visible reports list होनी चाहिए, expiring URLs का loose pile नहीं। इसी तरह product memory leak होना बंद करती है।