ऐसी meetings जो सच में दोबारा मिल जाएँ: Timeline रिलीज़

जनवरी 2026 आते-आते GeekBye users के पास एक history की समस्या थी। app उनकी meetings record और analyze तो बढ़िया कर रहा था — और फिर उन्हें एक dropdown में दर्ज कर देता था। तीन items के लिए dropdown ठीक है। पंद्रहवीं meeting तक पहुँचते-पहुँचते, "पिछले मंगलवार वाला वह interview" ढूँढना एक-जैसी दिखती rows के ढेर में परत-दर-परत खुदाई करने जैसा काम बन चुका था। v1.7.3 — दिसंबर के मध्य से 16 जनवरी के बीच 64 commits — वह रिलीज़ है जिसमें meetings ऐसी चीज़ बनीं जो सच में दोबारा मिल जाएँ।

(एक हिसाब-किताब की बात, क्योंकि git history ईमानदार है भले version numbers न हों: v1.7.2 का कोई release tag है ही नहीं। version bump तो हुआ, पर ship होने वाला अगला tag v1.7.3 था, इसलिए v1.7.2-दौर के Windows फ़िक्स इसी रिलीज़ में सवार होकर आए।)

dropdown से timeline तक

सबसे बड़ी सुर्खी वाला बदलाव एक ही pull request है: 12 files, +640 lines, जिनमें से ज़्यादातर एक नया 381-line MeetingsTimeline component है। dropdown अब meeting cards की एक scrollable timeline बन गया, चार buckets में बँटी — Today, Yesterday, This Week, Older (आज, कल, इस हफ़्ते, पुरानी) — और तारीख़ें वैसे लिखी जाने लगीं जैसे कोई इंसान बोलता है: Today, 2:30 PM, Yesterday, 2:30 PM, इस हफ़्ते के लिए Mon, 2:30 PM, और उससे पहले की चीज़ों के लिए Jan 5, 2:30 PM। Cmd/Ctrl+K एक search box पर focus करता है जो title से filter करता है। meeting detail view एक असली navigation page बन गया, इसलिए navbar के back और forward buttons का आख़िरकार कोई मतलब निकलने लगा, और breadcrumb ने "Meetings / Meeting" पढ़ना छोड़कर "Meetings / Interview with John" (यानी "Meetings / John के साथ interview") पढ़ना शुरू कर दिया (ellipsis से truncate होकर, क्योंकि कोई-न-कोई meeting का नाम हमेशा उपन्यास जितना लंबा रखेगा ही)।

इसके साथ quality-of-life के दो छोटे टुकड़े भी shipped हुए: meeting view के अंदर एक delete button (जो delete करने के बाद आपको timeline पर वापस ले जाता है, किसी मरे हुए page पर लावारिस छोड़ने के बजाय), और auto-navigation — जब कोई listening session असल transcript content के साथ ख़त्म होती है, तो dashboard सीधे उसी meeting के detail page पर खुलता है। call ख़त्म करो, meeting सामने। जो sessions ख़ाली ख़त्म होती हैं वे timeline में कचरा फैलाने के बजाय चुपचाप delete कर दी जाती हैं।

वह race जो navigation सुधारने से ख़ुद पैदा होती है

अब वह हिस्सा जो changelog आपको नहीं बताता। पुरानी meeting list की एक आदत थी: हर load पर वह सबसे नई session को auto-select कर लेती थी। जब तक list एक dropdown थी जिसे आप कभी-कभार ही छूते थे, बेज़रर। जिस पल meetings एक ऐसा page बन गईं जिस पर आप navigate करते हैं, जानलेवा: meeting #5 पर click करो, background में कोई refetch पूरा हो, और list "मदद" के इरादे से सबसे नई meeting select कर देती — आपका दो सेकंड पहले किया हुआ चुनाव मिटाकर। फ़िक्स कोई और चालाक guard नहीं था; auto-select को पूरी तरह delete करना था। जो भी list user की तरफ़ से चीज़ें select करती है, वह देर-सबेर user से ही लड़ने लगेगी।

इसे हटाने पर दूसरी race सामने आई। auto-navigation किसी meeting पर session ख़त्म होते ही उसी पल कूदती है — जो उस पल से पहले भी हो सकता है जब session ने local SQLite database में लिखना पूरा किया हो। बहुत तेज़ navigate करो और आप ऐसी meeting पर पहुँचते हो जो अभी exist ही नहीं करती। shipped फ़िक्स है detail view में पहुँचने पर sessions load करने से पहले एक 500-millisecond delay, और navigation handler अपने साथ अपने ही एहतियात रखता है — अगर dashboard अभी-अभी बना हो तो window के did-finish-load का इंतज़ार plus 100ms, और अगर वह पहले से खुला हो तो 50ms। हमारा पढ़ना यह है: session-end navigation तीन timing domains को पार करती है — database write, window load, और React mount — और हर एक को अपना छोटा delay मिला। यह काम करता है, और हम साफ़ कहेंगे कि magic numbers का यह ढेर ईमानदारी से क़बूला हुआ क़र्ज़ है, कोई जीत नहीं।

वह screenshot जो अपनी ही meeting से पहले का है

इस रिलीज़ में एक और assumption की मौत हुई: "screenshots किसी session के तभी और सिर्फ़ तभी हैं जब वे उसके दौरान लिए गए हों।" बिल्कुल logical। ग़लत। असली users job posting पर, agenda पर, जिस code पर बात होने वाली है उस पर Cmd+H दबाते हैं — Start दबाने से पहले। Report tab screenshots को session की time range से सख़्ती से match करता था, इसलिए तैयारी के वे screenshots उसी report से ग़ायब हो जाते थे जिसके लिए वे लिए गए थे। फ़िक्स ने matching window को session शुरू होने से 60 seconds पहले तक चौड़ा कर दिया। (time-range की मशीनरी ख़ुद पुरानी है — वह v1.6.15 में चुपचाप ship हुई थी; v1.7.3 का योगदान उसे यह सिखाना है कि meetings शुरू होने से थोड़ा पहले ही शुरू हो जाती हैं।)

28 minutes में five fixes

इस रिलीज़ की युद्ध-कथा timeline में है ही नहीं — वह Windows के onboarding overlay में है, और यह "फ़िक्स को फ़िक्स करो" वाली chain की textbook मिसाल है: एक ही सुबह 10:50–11:18 के बीच five commits।

GeekBye की main window mouse passthrough इस्तेमाल करती है — एक hook जो हर mouse move पर Electron का setIgnoreMouseEvents toggle करता है ताकि clicks transparent हिस्सों के आर-पार निकल जाएँ। Windows पर onboarding के दौरान वह hook tutorial overlay से भिड़ गया, और जिस step पर dashboard window प्रकट होती है, वहाँ app freeze हो गया। फ़िक्स नंबर एक: onboarding चालू रहते hook को कुछ भी करने ही मत दो। शांति तो मिली — पर अपने ही सिपाही के हथियार रखवाकर।

सिवाय इसके कि अब onboarding के buttons जवाब नहीं दे रहे थे, क्योंकि event forwarding clicks को overlay के नीचे बैठी dashboard window तक पहुँचा रहा था। फ़िक्स दो और तीन हर wizard में forward: false से छेड़छाड़ करते रहे। फिर आया वह commit जिसने असली root cause पकड़ा: dashboard window खुलते ही उसका drag handler main window को वापस click-through mode पर reset कर देता है — और पहले फ़िक्स ने passthrough hook को passive बना दिया था, यानी उस दख़लंदाज़ी को ठीक करने वाला कोई बचा ही नहीं था। असली फ़िक्स ने रणनीति उलट दी: hook अब onboarding के दौरान हर mouse move पर setIgnoreMouseEvents(false) को सक्रिय रूप से दोबारा लागू करता है, ठीक इसीलिए कि बाहरी code उसे कभी भी reset कर सकता है। साथ ही उसने पहले वाले per-wizard जुगाड़ों की 75 lines delete कर दीं।

और उसके बाद भी एक पाँचवाँ commit आया, क्योंकि input की जंग जीत लेना z-order की जंग जीत लेना नहीं है: overlay और dashboard दोनों एक ही always-on-top level पर बैठे थे, और Windows उसी window को ऊपर उठा देता है जिसे focus मिले। overlay एक ऊँचे window level पर चला गया और dashboard के प्रकट होने के बाद एक delay पर ख़ुद को दोबारा ऊपर उठाता है। यह पूरा सिलसिला याद रखने लायक़ है: ऐसा passive फ़िक्स जो आपके इकलौते रखवाले को ही निहत्था कर दे, मूल लड़ाई से भी बदतर है।

तीन बातें जो इस रिलीज़ ने हमें सिखाईं

1. navigation के upgrade state के bugs उजागर करते हैं। auto-select वाली race v1.7.3 से पहले भी मौजूद थी; dropdown ने बस कभी उसे महसूस नहीं होने दिया। जिस पल meetings एक ऐसा page बनीं जिस पर आप जान-बूझकर navigate करते हैं, code का हर वह टुकड़ा जो आपके बदले चीज़ें select करता था, एक bug बन गया।
2. user के इरादे के इर्द-गिर्द की time boundaries को ढील चाहिए। sessions, recordings, reports — users मशीन की आधिकारिक window से थोड़ा पहले और थोड़ा बाद act करते हैं। 60 seconds वाला screenshot buffer वह एक line है जो दिखाती है कि लोग असल में कैसे बर्ताव करते हैं।
3. अपने सुधारने वाले code को कभी passive मत बनाओ। Windows वाले freeze में five fixes इसलिए लगे क्योंकि पहले फ़िक्स ने उस इकलौते mechanism को बंद कर दिया जो बाहरी दख़लंदाज़ी की काट कर सकता था। अगर कोई और code आपका invariant कभी भी तोड़ सकता है, तो आपका काम है उसे लगातार दोबारा लागू करते रहना, हथियार डाल देना नहीं।

v1 कहानी के पिछले अध्याय के लिए — इसी एक codebase से दो branded app बनाना — देखें एक codebase, दो app: बिना fork किए white-label कैसे करें (v1.7.1); और पूरे चाप के लिए, सॉफ़्टवेयर को परिपूर्णता तक पहुँचाकर भेजने की शारीर-रचना।