Conductor Cloud बंद हो रहा है: 20 नवंबर से पहले डेटा निर्यात करें

सावधानी के तौर पर Conductor Cloud वर्कस्पेस का स्थानांतरण और Cloud टर्मिनल पर निर्भर बैकअप चरण 13 नवंबर 2026 से पहले पूरे करके जाँचें। खाते का अलग संग्रह 20 नवंबर 2026 से पहले डाउनलोड करके जाँचें। वर्कस्पेस के लिए Transfer to local और खाते के संग्रह के लिए Settings → Account → Export data इस्तेमाल करें।

Conductor के Meta में शामिल होने की घोषणा के अनुसार, केवल पढ़ने वाले मोड में पुराने चैट और डेटा निर्यात उपलब्ध रहेंगे। घोषणा यह पुष्टि नहीं करती कि उस दौरान वर्कस्पेस स्थानांतरण या Cloud टर्मिनल भी उपलब्ध रहेंगे। Cloud 20 नवंबर को बंद होगा और उसी दिन Cloud उपयोगकर्ता डेटा मिटाना शुरू होगा।

मौजूदा उपयोगकर्ताओं को स्थानीय Conductor में चल रहा काम पूरा करने का समय मिल सकता है। इसे अस्थायी व्यवस्था मानें, अपना एकमात्र बैकअप या स्थायी विकल्प नहीं।

Conductor Cloud बंद होने की कौन-सी तारीखें महत्वपूर्ण हैं?

केवल पढ़ने वाला मोड शुरू होने से पहले वर्कस्पेस स्थानांतरण और टर्मिनल पर निर्भर बैकअप चरण पूरे करें। इस सावधानी को खाते के निर्यात के लिए घोषित समय-सीमा से अलग रखें। 2026-11-10 तक Conductor का आधिकारिक कार्यक्रम यह है:

तारीख	क्या बदलेगा	क्या करें
4 नवंबर 2026	नए उपयोगकर्ता Conductor पर पंजीकरण या ऐप डाउनलोड नहीं कर सकते। मौजूदा Pro उपयोगकर्ता Pro सुविधाएँ मुफ़्त इस्तेमाल कर सकते हैं।	अपनी मौजूदा स्थापना और खाते के आधार पर योजना बनाएँ।
13 नवंबर 2026	Cloud वर्कस्पेस केवल पढ़ने वाले मोड में चले जाएँगे। पुराने चैट और डेटा निर्यात उपलब्ध रहेंगे, लेकिन नए संदेश भेजना बंद होगा।	एजेंट से बातचीत वाला काम पहले पूरा करें। सावधानी के तौर पर इस तारीख से पहले वर्कस्पेस स्थानांतरण और टर्मिनल पर निर्भर बैकअप चरण भी पूरे करके जाँचें।
20 नवंबर 2026	Cloud बंद होगा और Cloud उपयोगकर्ता डेटा मिटाना शुरू होगा।	इस तारीख से पहले खाते का अलग निर्यात पूरा करके जाँचें।
2027 की शुरुआत	स्थानीय Conductor को नए मॉडल और गंभीर बग के सुधार मिलने की घोषित अवधि समाप्त होगी। उसका संचालन समेटना शुरू होगा।	उससे पहले ऐप पर अपनी बाकी निर्भरता समाप्त करें।

घोषणा में सक्रिय सदस्यता वाले उपयोगकर्ताओं को पैसे लौटाने का वादा भी है। अपना बिलिंग रिकॉर्ड अलग से जाँचें। पैसे लौटाने के वादे का अर्थ यह नहीं कि रकम आपके खाते में पहुँच गई है।

टीम के स्थानांतरण के लिए 12 नवंबर को अपना आंतरिक लक्ष्य रखें। यह सुझाया गया अतिरिक्त समय है, स्थानांतरण बंद होने की आधिकारिक तारीख नहीं। यह मानकर योजना न बनाएँ कि खाते का निर्यात 20 नवंबर के अंत तक चलता रहेगा।

अधूरा काम खोए बिना Conductor Cloud का डेटा कैसे निर्यात करें?

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

पहले हर वर्कस्पेस की स्थिति दर्ज करें और फ़ाइलें सहेजें

कुछ भी स्थानांतरित करने से पहले एक छोटी सूची बनाएँ। उसमें वर्कस्पेस का नाम, रिपॉज़िटरी, ब्रांच, नवीनतम कमिट, खुला pull request और परिणाम जाँचने वाले व्यक्ति का नाम लिखें।

स्थिति दर्ज करते समय एजेंट के संपादन और कमिट रोक दें। Cloud टर्मिनल उपलब्ध रहते हुए हर वर्कस्पेस की रिपॉज़िटरी के मूल फ़ोल्डर से ये जाँचें चलाएँ। यह काम 13 नवंबर से पहले पूरा करें। यहाँ इस्तेमाल की गई शेल Bash है:

git rev-parse --verify HEAD
git status --short --branch --untracked-files=all
git diff HEAD --stat

पहला कमांड वर्तमान कमिट का पहचानकर्ता दिखाता है। दूसरा ब्रांच की जानकारी और बदली हुई या अनट्रैक्ड फ़ाइलें दिखाता है। तीसरा उस कमिट से ट्रैक की गई फ़ाइलों के अंतर का सार दिखाता है। Git के रिविज़न, स्थिति और अंतर संबंधी दस्तावेज़ इन व्यवहारों को समझाते हैं।

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

ये कमांड स्थिति जाँचते हैं; फ़ाइलों का वास्तविक डेटा नहीं सहेजते। समीक्षा किए हुए कमिट स्वीकृत रिमोट रिपॉज़िटरी में भेजें और वहाँ ब्रांच तथा कमिट की पुष्टि करें। उस रिमोट का URL बिना किसी अंतर्निहित सीक्रेट के सूची में लिखें। जिन कमिट को भेज नहीं सकते, उनके लिए वर्कस्पेस स्थानांतरण से पहले नीचे दी गई bundle और बहाली की जाँच पूरी करें। केवल साफ़ स्थिति दिखाने के लिए सीक्रेट या निजी कॉन्फ़िगरेशन को एक साथ Git में न जोड़ें।

जहाँ मौजूद हों, .conductor/settings.toml, .conductor/settings.local.toml और .context जाँचें। Conductor इन स्थानों पर प्रोजेक्ट स्क्रिप्ट, स्थानीय प्रोजेक्ट कॉन्फ़िगरेशन और बिना कमिट किए काम सौंपने के नोट्स रखने का विवरण देता है।

सेटअप कमांड, आवश्यक रनटाइम संस्करण, बाहरी सेवाएँ और पर्यावरण चर के नाम दर्ज करें। सीक्रेट के मान अपने स्वीकृत क्रेडेंशियल भंडार से बहाल करें, स्थानांतरण टिकट या एजेंट को दिए गए प्रॉम्प्ट से नहीं।

वर्कस्पेस स्थानांतरण से पहले ज़रूरी अधूरी फ़ाइलों की स्वतंत्र कॉपी बनाएँ। एक दस्तावेज़ित तरीका Sync to a local directory है। यह Cloud वर्कस्पेस की फ़ाइलों की कॉपी स्थानीय फ़ोल्डर में रखता है। ज़रूरी फ़ाइलें दिखने के बाद उन्हें उस फ़ोल्डर से अलग, स्वीकृत बैकअप स्थान में कॉपी करें।

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

कॉपी की गई फ़ाइलें खोलें और उनकी सामग्री की तुलना उपलब्ध मूल फ़ाइलों से करें। फ़ाइल सूची का मिलान अपनी दर्ज सूची और फ़ाइलें हटाने व नाम बदलने के रिकॉर्ड से करें। सिंक किए गए फ़ोल्डर को संपादित न करें और उसे एकमात्र बैकअप न मानें।

अगर कोई छोटी टेक्स्ट फ़ाइल नहीं आई है, तो उसका पूरा मूल डेटा उसी सापेक्ष पथ पर स्थानीय फ़ाइल में सहेजें। कॉपी दोबारा खोलकर तुलना करें। अगर किसी भी ज़रूरी फ़ाइल की जाँची हुई स्थानीय कॉपी नहीं है, तो वर्कस्पेस स्थानांतरण रोक दें। इसमें सिंक से छूटी बाइनरी फ़ाइल, जैसे repository.bundle, भी शामिल है। Cloud वर्कस्पेस उपलब्ध रहते हुए घोषणा में दिए संपर्क से Conductor से बात करें।

बैकअप की जाँच पूरी होने तक संपादन रोके रखें। अन्यथा अंतिम बदलाव के बाद स्थिति का रिकॉर्ड और कॉपियाँ अपडेट करें। टर्मिनल पर निर्भर सभी बैकअप चरण 13 नवंबर से पहले पूरे करके जाँचें।

जो कमिट रिमोट पर नहीं भेज सकते, उनका बैकअप लें

जिन ब्रांच के कमिट रिमोट पर नहीं भेज सकते, उनके स्थानांतरण से पहले Git इतिहास का स्थानीय बैकअप सहेजें। Git का bundle कमांड रिपॉज़िटरी के रेफ़रेंस और उनसे जुड़े कमिट इतिहास को एक फ़ाइल में पैक कर सकता है। इस सहेजे हुए bundle से आप नेटवर्क से जुड़े बिना Git इतिहास बहाल कर सकते हैं। ऊपर बताई गई अधूरी फ़ाइलों की अलग कॉपियाँ भी रखें।

यह स्थिति सहेजते समय नए कमिट और ब्रांच अपडेट रोक दें। Cloud रिपॉज़िटरी के मूल फ़ोल्डर से Bash में यह उदाहरण चलाएँ। conductor-history-backup नाम का फ़ोल्डर पहले से मौजूद नहीं होना चाहिए:

mkdir conductor-history-backup &&
git for-each-ref --format='%(objectname) %(refname)' refs/heads > conductor-history-backup/branches.txt &&
git bundle create conductor-history-backup/repository.bundle --all

जाँचें कि branches.txt में हर ज़रूरी ब्रांच और आपकी सूची के अनुसार उसका पूरा कमिट पहचानकर्ता मौजूद है। ऊपर दिए फ़ाइल-कॉपी तरीके से पूरा फ़ोल्डर स्वीकृत स्थानीय स्थान में कॉपी करें। यह कॉपी सिंक फ़ोल्डर के बाहर रखें और पुष्टि करें कि repository.bundle भी आपके Mac तक पहुँचा है। pre-transfer-status.txt, सूची और सहेजी हुई फ़ाइलें इस बैकअप के साथ रखें।

वर्कस्पेस स्थानांतरित करने से पहले इस स्थानीय कॉपी से बहाली जाँचें। कॉपी किए गए conductor-history-backup फ़ोल्डर में Bash खोलें। restored.git नाम का गंतव्य पहले से मौजूद नहीं होना चाहिए:

git clone --mirror repository.bundle restored.git &&
git --git-dir=restored.git for-each-ref --format='%(objectname) %(refname)' refs/heads > restored-branches.txt &&
git diff --no-index --exit-code -- branches.txt restored-branches.txt &&
git --git-dir=restored.git fsck

मिरर क्लोन रेफ़रेंस को अलग bare रिपॉज़िटरी में बहाल करता है, जिसमें वर्किंग ट्री की फ़ाइल कॉपी नहीं होती। दोनों ब्रांच सूचियों की तुलना में कोई अंतर नहीं आना चाहिए। git fsck को किसी गायब या खराब Git ऑब्जेक्ट की सूचना नहीं देनी चाहिए।

स्थानांतरण से पहले restored-branches.txt में अपेक्षित ब्रांच नाम और कमिट पहचानकर्ता जाँचें। कोई कमांड विफल हो या ज़रूरी ब्रांच गायब हो, तो रुक जाएँ। Cloud रिपॉज़िटरी उपलब्ध रहते हुए बैकअप की समस्या हल करें।

bundle, ब्रांच सूचियों और अधूरी फ़ाइलों की कॉपियों को निजी रिपॉज़िटरी डेटा की तरह सुरक्षित रखें। रिमोट पर न भेजे गए काम वाली हर रिपॉज़िटरी के लिए यह प्रक्रिया दोहराएँ। नए कमिट के बाद बैकअप अपडेट करें।

एक वर्कस्पेस स्थानांतरित करें, जाँचें, फिर अगला लें

सावधानी के तौर पर हर वर्कस्पेस का स्थानांतरण 13 नवंबर से पहले पूरा करके जाँचें। अपने Mac पर Cloud वर्कस्पेस पर राइट-क्लिक करें और Transfer to local चुनें। Conductor के 0.93.0 रिलीज़ नोट्स वर्कस्पेस और उसके चैट Mac पर ले जाने का तरीका बताते हैं।

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

अनट्रैक्ड फ़ाइलें और प्रोजेक्ट कॉन्फ़िगरेशन अलग से जाँचें। केवल रिपॉज़िटरी दिखने से यह साबित नहीं होता कि हर फ़ाइल और वातावरण की हर निर्भरता सुरक्षित है।

प्रोजेक्ट की दस्तावेज़ित सेटअप प्रक्रिया से निर्भरताएँ बहाल करें। फिर उसका सबसे छोटा उपयोगी टेस्ट या बिल्ड जाँच चलाएँ। अंतर मिलने पर जाँचे हुए रिमोट या bundle के Git इतिहास और स्वतंत्र फ़ाइल कॉपियों से तुलना करें। मूल Cloud वर्कस्पेस से तुलना केवल तभी करें जब वह अभी भी उपलब्ध हो।

हर ज़रूरी वर्कस्पेस के लिए यह प्रक्रिया दोहराएँ। अधूरे प्रयोग और उपयोगी निर्णयों वाला पुराना काम भी शामिल करें। हर जाँच के लिए किसी व्यक्ति को ज़िम्मेदारी दें। यह न मानें कि साझा काम किसी और सदस्य ने पहले ही निर्यात कर लिया है।

खाते का संग्रह डाउनलोड करके जाँचें

वर्कस्पेस स्थानीय रूप से दिखने लगें, तब भी खाते का संग्रह बनाएँ। Settings → Account → Export data खोलें और डाउनलोड को Conductor के वर्कस्पेस फ़ोल्डरों के बाहर सहेजें। 20 नवंबर से पहले यह निर्यात पूरा करके जाँचें।

टीम के स्वीकृत बैकअप स्थान में एक और कॉपी रखें। उपयुक्त स्थानीय प्रोग्राम में निर्यात खोलें और कुछ प्रतिनिधि प्रोजेक्ट रिकॉर्ड तथा बातचीत जाँचें। निर्यात की तारीख और गायब सामग्री लिखें।

इस संग्रह को जाँचने योग्य बैकअप मानें, किसी दूसरे कोडिंग टूल का तैयार आयात प्रारूप नहीं। जाँचे हुए कोड, अलग सहेजी गई फ़ाइलों, कॉन्फ़िगरेशन, निर्भरताओं और क्रेडेंशियल से कामकाजी वातावरण फिर बनाएँ।

अगर Transfer to local नहीं दिखता या विफल होता है, तो नीचे उपयुक्त बहाली तरीका चुनें। भेजे हुए कमिट स्वीकृत रिमोट से और bundle में सहेजे कमिट जाँचे हुए मिरर से बहाल करें। गायब सामग्री Cloud से केवल तभी लें जब वह अभी भी उपलब्ध हो। खाते का संग्रह अलग से निर्यात करें, लेकिन उसे अधूरे कोड की बहाली का प्रमाण न मानें।

ऐप संस्करण, प्रभावित वर्कस्पेस और त्रुटि का सटीक संदेश दर्ज करें। समय-सीमा से पहले Conductor की घोषणा में दिए सहायता संपर्क का इस्तेमाल करें। क्रेडेंशियल या बातचीत की संवेदनशील सामग्री न भेजें।

घोषित केवल पढ़ने वाले समय में पुराने चैट और डेटा निर्यात उपलब्ध रहेंगे। 13 नवंबर के बाद बहाली को नए एजेंट संदेश, वर्कस्पेस स्थानांतरण या चलते हुए Cloud टर्मिनल पर निर्भर न रखें।

बैकअप से कामकाजी कॉपी बहाल करें

कमिट इतिहास भेज दिया था तो उसे स्वीकृत रिमोट से बहाल करें। bundle बनाया था तो restored.git से लें। एक तरीका चुनें। दोनों तरीकों के बाद फ़ाइलें बहाल करने के चरण समान हैं। नीचे दिए चरणों में रिकॉर्ड के अनुसार फ़ाइलें हटाने और नाम बदलने के बदलाव भी लागू करें।

भेजे हुए कमिट के लिए स्वीकृत स्थानीय बहाली फ़ोल्डर में Bash खोलें। स्वीकृत रिमोट URL दर्ज करें, जिसमें कोई सीक्रेट न हो। अपनी सूची से refs/heads/ के बिना ब्रांच नाम और पूरा कमिट पहचानकर्ता लें। अपना सामान्य Git प्रमाणीकरण इस्तेमाल करें। recovered-worktree फ़ोल्डर पहले से मौजूद नहीं होना चाहिए:

read -r -p "Approved remote URL (no embedded secrets): " RECOVERY_REMOTE &&
read -r -p "Branch from inventory: " RECOVERY_BRANCH &&
read -r -p "Full commit ID from inventory: " RECOVERY_COMMIT &&
mkdir recovered-worktree &&
(
  cd recovered-worktree &&
  git init &&
  git remote add origin "$RECOVERY_REMOTE" &&
  git fetch origin &&
  git switch --create "$RECOVERY_BRANCH" "$RECOVERY_COMMIT" &&
  test "$(git branch --show-current)" = "$RECOVERY_BRANCH" &&
  test "$(git rev-parse --verify HEAD)" = "$RECOVERY_COMMIT" &&
  git status --short --branch --untracked-files=all
)

fetch चरण रिमोट का इतिहास लाता है। git switch --create दर्ज किए गए कमिट पर इच्छित स्थानीय ब्रांच बनाता है, रिमोट के नवीनतम कमिट पर नहीं। प्रमाणीकरण विफल हो, दर्ज कमिट उपलब्ध न हो या कोई तुलना विफल हो, तो रुकें। गायब कमिट जाँचे हुए bundle या उपलब्ध Cloud वर्कस्पेस से प्राप्त करें; उसकी जगह दूसरा कमिट न चुनें।

bundle बैकअप के लिए स्थानीय conductor-history-backup फ़ोल्डर में Bash खोलें। सहेजी सूची से refs/heads/ के बिना ब्रांच नाम और पूरा कमिट पहचानकर्ता दर्ज करें। recovered-worktree फ़ोल्डर पहले से मौजूद नहीं होना चाहिए:

read -r -p "Branch from inventory: " RECOVERY_BRANCH &&
read -r -p "Full commit ID from inventory: " RECOVERY_COMMIT &&
git clone --branch "$RECOVERY_BRANCH" restored.git recovered-worktree &&
(
  cd recovered-worktree &&
  test "$(git branch --show-current)" = "$RECOVERY_BRANCH" &&
  test "$(git rev-parse --verify HEAD)" = "$RECOVERY_COMMIT" &&
  git status --short --branch --untracked-files=all
)

git clone --branch कामकाजी कॉपी की ब्रांच चुनता है। git branch --show-current उसका नाम और git rev-parse --verify HEAD उसका कमिट जाँचता है। अंतिम स्थिति रिपोर्ट दोनों तुलनाएँ सफल होने के बाद ही दिखती है। त्रुटि या अंतर मिले तो रुकें।

किसी भी तरीके के सफल होने पर उसकी नई recovered-worktree कॉपी में काम करें। सहेजी हुई बदली, जोड़ी और अनट्रैक्ड फ़ाइलों को उनके मूल सापेक्ष पथों पर कॉपी करें। ज़रूरी इग्नोर की गई फ़ाइलें अलग से बहाल करें। मूल बैकअप कॉपियाँ न बदलें।

फ़ाइलें हटाने और नाम बदलने के बदलाव दोबारा लागू करें, ताकि बहाली वाली कॉपी के पथ अंतिम सहेजी स्थिति से मेल खाएँ। इसके लिए pre-transfer-status.txt और फ़ाइलों की मौजूदगी के नोट्स देखें। कोई दर्ज हटाया गया पथ केवल बहाली वाली कॉपी से हटाएँ, और पहले पुष्टि करें कि अंतिम स्थिति में वह मौजूद नहीं था। नाम बदलने के मामले में सहेजी फ़ाइल नए पथ पर बहाल करें। पुराना पथ तभी हटाएँ जब अंतिम स्थिति में वह नहीं था।

बहाल कॉपी के मूल फ़ोल्डर से स्थिति जाँचने वाले कमांड फिर चलाएँ। हर बदले पथ को सहेजी स्थिति से और फ़ाइल की सामग्री को स्वतंत्र कॉपी से मिलाएँ। यह वर्किंग ट्री की सामग्री बहाल करता है, पुरानी स्टेजिंग स्थिति नहीं। बदलाव स्टेज करने या एजेंट का काम फिर शुरू करने से पहले अंतर जाँचें। बैकअप मिरर में कमिट push न करें।

स्थानीय Conductor को अस्थायी व्यवस्था की तरह इस्तेमाल करें

वर्कस्पेस इंटरफ़ेस पर निर्भरता हटाते समय काम जारी रखने के लिए स्थानीय Conductor रखें। घोषणा के अनुसार, स्थानीय Conductor को 2027 की शुरुआत तक नए मॉडल और गंभीर बग के सुधार मिलेंगे। उसके बाद संचालन समेटना शुरू होगा। इससे Cloud की 20 नवंबर की समय-सीमा नहीं बढ़ती।

वर्कस्पेस स्थानांतरित करने के बाद निष्पादन वातावरण जाँचें। Conductor के Cloud वर्कस्पेस दस्तावेज़ Mac से जुड़े Linux सैंडबॉक्स का वर्णन करते हैं। Cloud में सफल बिल्ड यह साबित नहीं करता कि वही निर्भरताएँ और कमांड स्थानीय रूप से भी चलेंगे।

स्थानीय निष्पादन का अर्थ यह भी नहीं कि मॉडल बिना नेटवर्क चलेगा। Conductor के गोपनीयता दस्तावेज़ कहते हैं कि स्थानीय वर्कस्पेस का मॉडल ट्रैफ़िक कॉन्फ़िगर किए गए मॉडल प्रदाता को जाता है।

प्रक्रियाओं के चलने की अवधि का अंतर ध्यान में रखें। Cloud FAQ के अनुसार, Conductor बंद करने या Mac बंद करने पर स्थानीय वर्कस्पेस सत्र समाप्त हो जाते हैं। इसलिए स्थानांतरित वर्कस्पेस को Cloud में लगातार चलने वाली प्रक्रिया का विकल्प न मानें।

इस बीच रिपॉज़िटरी को Conductor के बिना इस्तेमाल करने योग्य बनाएँ। सेटअप निर्देश, टेस्ट कमांड और काम सौंपने के नोट्स समीक्षा की हुई प्रोजेक्ट फ़ाइलों में रखें। मॉडल प्रदाता की उपयोग सीमा या API बिल को Conductor की मुफ़्त Pro सुविधाओं से अलग जाँचें।

Claude Code, Codex या OpenCode में समानांतर काम फिर शुरू करें

पहले वही कोडिंग एजेंट इस्तेमाल करें जिसे आप जानते हैं। फिर अलग Git worktree के माध्यम से समानांतर काम बहाल करें। वर्कट्री उसी रिपॉज़िटरी की दूसरी कामकाजी कॉपी है, जो आम तौर पर अलग ब्रांच पर होती है।

यह तरीका उन डेवलपर के लिए उपयुक्त है जो प्रोजेक्ट स्थानीय रूप से चला सकते हैं और Git में बदलावों की समीक्षा करते हैं। इससे अलग कामकाजी फ़ोल्डर मिलते हैं। यह Conductor की साझा Cloud सेवा या उसके पूरे इंटरफ़ेस को दोबारा नहीं बनाता।

एजेंट चुनें और प्रमाणीकरण जाँचें

काम स्थानांतरित करने से पहले अपना चुना CLI, यानी कमांड-लाइन टूल, Conductor के बाहर इंस्टॉल करें और उसका प्रमाणीकरण पूरा करें। नीचे दिए मिश्रित एजेंट उदाहरण के लिए Claude Code और Codex दोनों इंस्टॉल और प्रमाणित होने चाहिए। केवल एक एजेंट इस्तेमाल करना हो तो दोनों वर्कट्री में वही CLI चलाएँ।

अपनी Claude Code प्रक्रिया बनाए रखने के लिए Claude Code चुनें। प्रोजेक्ट फ़ोल्डर में claude चलाएँ और पहले इस्तेमाल के प्रमाणीकरण निर्देश पूरे करें।

अपनी Codex प्रक्रिया बनाए रखने के लिए Codex CLI चुनें। प्रोजेक्ट फ़ोल्डर में codex चलाएँ। पहले रन में ChatGPT से साइन इन या कोई अन्य उपलब्ध प्रमाणीकरण तरीका मिलता है।

अगर आप पहले से OpenCode में मॉडल प्रदाता सेट करते हैं या कई प्रदाताओं में से चुनना चाहते हैं, तो OpenCode इस्तेमाल करें। opencode चलाएँ। फिर प्रदाता जोड़ने के निर्देशों के अनुसार /connect और /models इस्तेमाल करें।

यह न मानें कि केवल Conductor के भीतर सेट किए गए क्रेडेंशियल अलग CLI में उपलब्ध हैं। असली काम का एक्सेस देने से पहले सक्रिय खाता, प्रदाता और मॉडल जाँचें।

उपयोग के अनुसार भुगतान वाले अलग API रास्ते के लिए BetterToken के पास Claude Code और Codex के विशिष्ट सेटअप निर्देश हैं। मॉडल एक्सेस की कॉन्फ़िगरेशन को वर्कस्पेस बहाली से अलग रखें। प्रोडक्शन काम स्थानांतरित करने से पहले Claude Code और Codex API की शुरुआती जाँच सूची अपनाएँ।

दो वर्कट्री बनाएँ और पूरी प्रक्रिया जाँचें

अपनी जाँची हुई स्थानीय रिपॉज़िटरी के मूल फ़ोल्डर से शुरू करें और ज्ञात कमिट को आधार बनाएँ। यह Bash उदाहरण वर्तमान HEAD से दो ब्रांच बनाता है:

git worktree add -b migration/docs ../migration-docs HEAD &&
git worktree add -b migration/tests ../migration-tests HEAD &&
git worktree list

Git का वर्कट्री संदर्भ -b से ब्रांच बनाने और list से जाँचने का तरीका बताता है। पुष्टि करें कि आउटपुट में दोनों नए फ़ोल्डर और उनकी संबंधित ब्रांच दिखती हैं।

ये कमिट की गई स्थिति की नई कामकाजी कॉपियाँ हैं। इनमें बिना कमिट की गई फ़ाइलें या Conductor चैट की स्थिति कॉपी नहीं होती। उदाहरण चलाने से पहले बहाल किए जाने वाले अधूरे काम को सुरक्षित रखें।

पहले से इस्तेमाल न हुए ब्रांच और फ़ोल्डर नाम चुनें। बनाने में त्रुटि आए तो दोबारा कोशिश का निर्णय लेने से पहले मौजूदा स्थिति जाँचें। केवल त्रुटि पार करने के लिए --force न जोड़ें।

अगले दो कमांड मानते हैं कि Claude Code और Codex दोनों इंस्टॉल हैं और उनका प्रमाणीकरण पूरा है। दो टर्मिनल टैब खोलें; शुरुआत में दोनों मूल रिपॉज़िटरी के मूल फ़ोल्डर में हों। पहले टैब में Claude Code शुरू करें:

(cd ../migration-docs && claude)

दूसरे टैब में Codex शुरू करें:

(cd ../migration-tests && codex)

एक एजेंट वाले सेटअप में दोनों फ़ोल्डरों में वही इंस्टॉल किया हुआ CLI कमांड इस्तेमाल करें: claude, codex या opencode। एक ही कामकाजी फ़ोल्डर में दो संपादन करने वाले एजेंट न चलाएँ।

हर सत्र की शुरुआत इस जाँच प्रॉम्प्ट से करें:

Use read-only tools to inspect this repository.
Report the current directory and Git branch.
Identify the documented setup command and one existing test command.
Cite the repository files that define those commands.
If a command is not documented, say so.
Do not edit files, install packages, commit, or push.

अपेक्षित परिणाम अलग फ़ोल्डरों और ब्रांच से जुड़ी दो रिपोर्ट हैं। हर रिपोर्ट असली रिपॉज़िटरी फ़ाइलों का संदर्भ दे, कोई मनगढ़ंत सामान्य टेस्ट कमांड नहीं। सामान्य अनुमति जाँच चालू रखें। प्रॉम्प्ट सुरक्षा सीमा नहीं है।

इन जाँचों के सफल होने के बाद आवश्यक सेटअप की अनुमति दें और हर वर्कट्री में एक छोटा मौजूदा टेस्ट चलाएँ। फिर स्वतंत्र काम सौंपें, जैसे दस्तावेज़ सुधारना और अलग टेस्ट सुधारना। कमिट या मर्ज से पहले हर प्राप्त diff की समीक्षा करें।

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

नए CLI सत्र को बहाल बातचीत का इतिहास न समझें। OpenAI के आयात दस्तावेज़ Codex CLI के लिए Claude Code और Cursor को आयात स्रोत बताते हैं। इससे यह साबित नहीं होता कि Conductor खाते का संग्रह सीधे आयात हो सकता है।

अलग वर्कट्री से अलग डेटाबेस, सेवा खाते या डेवलपमेंट पोर्ट भी नहीं मिलते। समानांतर बिल्ड चलाने से पहले इन संसाधनों को तय करके बाँटें। Conductor भी वर्कस्पेस अलगाव और सुरक्षा सीमा में अंतर करता है।

हर सक्रिय सत्र के लिए प्रदाता की उपयोग सीमा या API खर्च पर नज़र रखें। उदाहरण के लिए, OpenAI के प्रमाणीकरण दस्तावेज़ API कुंजी वाली बिलिंग और ChatGPT योजना में शामिल क्रेडिट को अलग बताते हैं। अतिरिक्त टर्मिनल टैब खोलने से सदस्यता की अतिरिक्त सीमा नहीं मिलती।

स्थानांतरण तभी पूरा मानें जब संग्रह खुलता हो, सभी ज़रूरी फ़ाइलें और कमिट मिल गए हों और स्थानीय काम की जाँच सफल हो। जिन वर्कस्पेस की बहाली अधूरी है, उन्हें सूची में रखें। उन्हें तभी हटाएँ जब ज़िम्मेदार व्यक्ति जाँच ले या स्पष्ट रूप से लिख दे कि क्या बहाल नहीं हो सका।