Claude Code को टीम में लाने से पहले बनाएं यह 'रिस्क रजिस्टर'

शुक्रवार की शाम थी, और मेरे एक साथी ने कहा — “Claude Code तो कमाल का है, अगले हफ्ते से हम सब इसे इस्तेमाल करते हैं।”

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

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

तभी मैंने वह चीज़ बनाई जिसे इस लेख में मैं रिस्क रजिस्टर (जोखिम रजिस्टर) कह रहा हूँ। रजिस्टर कहने भर से डरने की ज़रूरत नहीं — यह बस एक तालिका है। पर यह एक तालिका होने या न होने से ही तय होता है कि Claude Code की टीम-तैनाती “काम आसान हो गया” पर खत्म होगी या “हादसे संभालते-संभालते थक गए” पर।

मुख्य बातें

• टीम-तैनाती के हादसे मॉडल के “कम होशियार” होने से नहीं, बल्कि “कौन, कहाँ तक, किसकी जाँच पर” तय न होने से होते हैं।
• रिस्क रजिस्टर यानी हर खतरनाक इलाके के लिए “ज़िम्मेदार, जाँच का तरीका, आगे बढ़ने की शर्त” एक लाइन में लिखी हुई तालिका। शुरुआत के लिए तीन लाइनें काफी हैं।
• सबसे पहले तीन चीज़ें पक्की करें — परमिशन (कौन-सी फ़ाइल छूने दें), CI (बदलाव टूटा नहीं इसका सबूत), और पब्लिश (प्रोडक्शन पर असली जाँच)।
• Claude Code को सिर्फ “ड्राफ्ट बनाना और जाँच चलाना” तक सौंपें। डिलीट, प्रोडक्शन DB, बिलिंग और force push — ये हमेशा इंसान अप्रूव करे।
• कॉपी-पेस्ट करके चलने वाला रजिस्टर टेम्प्लेट और खतरनाक काम रोकने वाला सेटिंग उदाहरण नीचे दिया है। पहले सिर्फ एक फ़ाइल पर आज़माना ही असली तरकीब है।

रिस्क रजिस्टर आखिर है क्या?

रिस्क रजिस्टर वह तालिका है जिसमें टीम के साथ Claude Code को काम सौंपते वक्त “जहाँ हादसा होने की सबसे ज़्यादा आशंका है” उन जगहों की सूची होती है।

हर लाइन में बस तीन कॉलम काफी हैं। खतरा कहाँ है, यह सुरक्षित है इसका सबूत क्या है, और उस जाँच को कौन करेगा। बस इतना ही। किसी भारी-भरकम मैनेजमेंट टूल की ज़रूरत नहीं। शुरुआत में एक स्प्रेडशीट, या कोड के भीतर एक array तक काफी है।

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

सबसे पहले पक्के करने वाले तीन खतरनाक बिंदु

टीम-तैनाती में जहाँ चीज़ें गिरती हैं, वे ज़्यादातर इन्हीं तीन में सिमट जाती हैं। उल्टा कहें तो, यही तीन रजिस्टर में लिख लें, तो पहले दिन का बड़ा हादसा लगभग टल जाता है।

1. परमिशन (कौन-सी फ़ाइल छूने दें)

सबसे आम हादसा है “ज़रूरत से ज़्यादा छूने देना”। “रिपॉज़िटरी को साफ कर दो” कहते ही Claude Code कॉन्फ़िग फ़ाइल और CI की परिभाषा तक बेझिझक बदल देता है। इसलिए, कहाँ एडिट करना ठीक है और कहाँ बिलकुल नहीं — यह पहले तय करके शब्दों में लिख छोड़ें।

मेरा पैमाना सीधा है। लेख, ड्राफ्ट, टेस्ट कोड — छूना ठीक है। .github/, प्रोडक्शन के एनवायरनमेंट वेरिएबल, डिप्लॉय सेटिंग, डेटाबेस माइग्रेशन — “जब तक इंसान जाँच न ले, रुको”। यह लकीर हर एक की पसंद पर छोड़ देंगे तो आदमी-दर-आदमी नियम अलग हो जाएँगे, और आख़िर में सबसे ढीली सेटिंग वाला हादसा कर बैठेगा। टीम में एक ही नियम पर सबको लाना यहाँ असली बात है।

2. CI (टूटा नहीं, इसका सबूत निकलवाएँ)

Claude Code “ठीक कर दिया” कहे, तो वह उसकी राय है। सबूत नहीं। इसलिए, बदलाव टूटा नहीं इसका सबूत देने वाली कमांड रजिस्टर में लिख रखें। बिल्ड पास हो, टेस्ट हरे हों, टाइप एरर न हो — इनमें से कोई एक “सफलता की रिपोर्ट देने से पहले ज़रूर चलाना है” तय करें।

यहाँ अहम बात — जाँच कमांड को तेज़ रखें। फुल टेस्ट में दस मिनट लगें तो कोई नहीं चलाएगा। बदली हुई फ़ाइल से जुड़े टेस्ट ही तीस सेकंड में चल जाएँ, इतना बना लें तो जाँच आदत बन जाती है।

3. पब्लिश (प्रोडक्शन पर जाने वाले बदलाव को ज़रूर देखें)

ब्लॉग का रेवेन्यू पेज हो या API — बाहर जाने वाले हर बदलाव के लिए “असली URL पर देखा या नहीं” यह दर्ज करें। बिल्ड पास होना, और यूज़र को दिखने वाला पेज सही होना — ये दो अलग बातें हैं। प्रोडक्शन का URL खोलकर एक स्क्रीनशॉट रखें। इसे ही “पूरा हुआ” की शर्त बनाएँ।

पब्लिश किया URL 200 लौटाए, पर भीतर कोई और पेज हो, तो वह अनपब्लिश्ड के बराबर है। हिन्दी पेज होते हुए भी अंग्रेज़ी का मूल पाठ मिला हो, तो वह भी अधूरा है। यह सामान्य-सी बात लगती है, पर जिस दिन जल्दी हो उसी दिन इसे छोड़ दिया जाता है।

AI को क्या सौंपें, और इंसान क्या तय करे

लकीर खींचने में उलझ जाएँ तो इस तालिका को सीधे इस्तेमाल करें। फैसले की कसौटी एक ही है — “वापस लाया जा सकता है या नहीं”।

काम	Claude Code को सौंपें	इंसान के अप्रूवल के बाद ही
ड्राफ्ट बनाना / सुधारना	◯
टेस्ट / बिल्ड चलाना	◯
बदलाव की व्याख्या (diff का सारांश)	◯
फ़ाइल डिलीट करना		◯
प्रोडक्शन डेटाबेस में लिखना		◯
जिससे बिलिंग हो ऐसा काम		◯
force push / इतिहास बदलना		◯
डिप्लॉय / प्रोडक्शन पब्लिश		◯

नियम एक ही — जिसे वापस लाना मुश्किल हो, वह काम शुरू में सब “इंसान से पूछो” में डालें। जो काम सुरक्षित साबित हो जाए, उसी को बाद में ऑटोमैटिक में बढ़ाएँ। शुरू से ढीला रखकर हादसा करने से बेहतर है कि कसकर रखें और धीरे-धीरे ढीला करें — नतीजे में यही ज़्यादा तेज़ पड़ता है।

कॉपी-पेस्ट करके इस्तेमाल करने वाला रिस्क रजिस्टर टेम्प्लेट

सबसे पहले, काम सौंपने से पहले Claude Code को दिया जाने वाला निर्देश टेम्प्लेट बना लें। यह हर बार चिपकाने भर से मनमाने विस्तार को रोका जा सकता है।

काम शुरू करने से पहले ये नियम मानें।
- एडिट सिर्फ src/content/ और tests/ के भीतर ही कर सकते हैं।
- .github/, प्रोडक्शन एनवायरनमेंट वेरिएबल, डिप्लॉय सेटिंग, DB माइग्रेशन — इन्हें मत छूएँ। छूने की ज़रूरत हो तो एडिट किए बिना वजह बताकर रिपोर्ट करें।
- बदलाव के बाद हर बार `npm run check` चलाएँ और नतीजा रिपोर्ट करें।
- डिलीट, प्रोडक्शन DB, बिलिंग या force push की ज़रूरत पड़े, तो चलाएँ नहीं — पहले पुष्टि माँगें।
एडिट शुरू करने से पहले, ऊपर की पाबंदियाँ अपने शब्दों में दोहराकर फिर काम शुरू करें।

और अब रजिस्टर खुद। शुरुआत के लिए तीन लाइनें काफी हैं। अपनी टीम के खतरनाक बिंदुओं से इन्हें बदल लें।

// टीम-तैनाती रिस्क रजिस्टर: हर खतरनाक बिंदु के लिए "ज़िम्मेदार, सबूत, आगे बढ़ने की शर्त" एक लाइन में लिखें
type RolloutRisk = {
  area: string;       // खतरनाक इलाका
  risk: string;       // क्या हो सकता है
  owner: string;      // जाँच करने वाला ज़िम्मेदार
  proof: string;      // सुरक्षित है इसका सबूत
  nextGate: string;   // आगे बढ़ने की शर्त
};

const rolloutRisks: RolloutRisk[] = [
  {
    area: "परमिशन",
    risk: "Claude Code साझा कॉन्फ़िग तक बदल देता है",
    owner: "लीड",
    proof: "एडिट-योग्य और मनाही वाली फ़ाइलों की सूची दर्ज है",
    nextGate: "पहले सिर्फ एक फ़ाइल पर आज़माएँ",
  },
  {
    area: "CI",
    risk: "जाँच कमांड धीमी है, या मौजूद ही नहीं",
    owner: "डेवलपर",
    proof: "बिल्ड हरा, या सिर्फ़ संबंधित टेस्ट हरे",
    nextGate: "PR टेम्प्लेट में जाँच के स्टेप जोड़ें",
  },
  {
    area: "पब्लिश",
    risk: "प्रोडक्शन पर जाने वाला बदलाव असल में जाँचा नहीं",
    owner: "ऑपरेशन ज़िम्मेदार",
    proof: "पब्लिश किए URL का स्क्रीनशॉट",
    nextGate: "रोलबैक के स्टेप नोट में रखें",
  },
];

console.table(rolloutRisks);

node में चले इस तरह सेव करके चलाएँ, तो तालिका आउटपुट हो जाएगी। दिखने में भले मामूली हो, इसकी असली कीमत यह है कि “काम शुरू करने से पहले खतरनाक बिंदुओं को शब्दों में रख देते हैं”। “हर लाइन भरने तक मर्ज नहीं” यह नियम बना लें, तो रजिस्टर हादसे का दरबान बन जाता है।

ऐसी टीमों में काम आता है (तीन असली उदाहरण)

मिलती-जुलती स्थिति हो, तो रजिस्टर दोबारा बनाने के बजाय बस नाम बदलकर इस्तेमाल करें।

1. दो लोगों की छोटी टीम साझा कोड छूने से पहले — कहाँ एडिट करना ठीक है, कहाँ छूना मना है, और किस काम पर इंसान का अप्रूवल चाहिए — इन तीनों को साथ पढ़कर एक पन्ने में उतार लें। इतने भर से “एक को बिना पता चले दूसरा सेटिंग तोड़ दे” वाला हादसा मिट जाता है। छोटी टीम में ही “कहे बिना समझ जाएगा” मानकर हादसा होता है, इसलिए पहले ही शब्दों में रखने की कीमत बड़ी है।

2. रिव्यू से गुज़ारने वाली टीम लीड यह तय करे कि Claude Code का बनाया बदलाव रिव्यू में जाने से पहले “जाँच कमांड चलाने का नतीजा” और “बदलाव का सारांश” अनिवार्य हो। जिस PR में ये नहीं, उसे देखेंगे ही नहीं — यह तय करें। रिव्यू करने वाला diff पढ़े, जाँच दोबारा चलाए, और रोलबैक का तरीका समझा सके — टीम को इसी हालत तक लाना लक्ष्य है।

3. रेवेन्यू पेज वाली टीम ब्लॉग या प्रोडक्ट पेज जैसे पैसे से सीधे जुड़े पेज के बदलाव को “पूरा” मानने से पहले पब्लिश किए URL का स्क्रीनशॉट रखें। “बिल्ड पास हुआ” पर मत रुकें — यूज़र को असल में दिखने वाली स्क्रीन देखें। टाइटल, पाठ, इमेज और लिंक — सब अनुमान के मुताबिक हैं या नहीं, यह आँखों से जाँचें।

आम गलतियाँ और उन्हें सुधारने का तरीका

ईमानदारी से कहूँ तो यह रजिस्टर भी शुरू में ठीक से नहीं चला। तीन गड़बड़ियाँ साझा करता हूँ।

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

CI की नाकामी को टाल दिया “बाद में एक साथ ठीक कर लेंगे” तकिया-कलाम बन जाए, तो पहली टीम-तैनाती “Claude Code डाला तो सब टूटा” वाली बुरी छवि पर खत्म होती है। जाँच कमांड गिरे, तो वहीं रोककर हरा होने तक उसे ड्राफ्ट ही मानने का नियम बनाया।

ज़िम्मेदारी धुँधली रखकर मुश्किल फैसला टालते रहे “कौन अप्रूव करेगा” तय न रखें, तो सबसे मुश्किल प्रोडक्शन-रिलीज़ का फैसला हवा में लटक जाता है। रजिस्टर का owner कॉलम ज़रूर भरें। खाली छोड़कर आगे न बढ़ें। इतने भर से फैसले अटकना बंद हो गए।

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

अक्सर पूछे जाने वाले सवाल

सवाल. छोटी टीम में भी रजिस्टर ज़रूरी है? दो लोगों में भी ज़रूरी है। बल्कि कम लोगों में ही “कहे बिना समझ जाएँगे” मानकर हादसा होता है। शुरुआत में तीन लाइन का टेम्प्लेट काफी है, इसलिए पाँच मिनट में बनाकर साझा कर दें।

सवाल. क्या सिर्फ़ Claude Code की परमिशन सेटिंग से काम नहीं चलता? परमिशन सेटिंग “छूने न देने का तंत्र” है, और रजिस्टर “कौन किससे जाँच करे” का संचालन-नियम। दोनों चाहिए। सेटिंग से तकनीकी तौर पर रोकें, और रजिस्टर से इंसान की जाँच चलाएँ। विस्तार से परमिशन सेटिंग गाइड देखें।

सवाल. जाँच कमांड क्या चुनूँ? वही सबसे छोटी कमांड, जिससे उस टीम में “टूटा नहीं” कहा जा सके। टाइप-चेक, सिर्फ़ संबंधित टेस्ट चलाना, या बिल्ड — इनमें से कोई एक। फुल टेस्ट में दस मिनट लगें तो कोई नहीं चलाएगा, इसलिए पहले तीस सेकंड में खत्म होने वाली एक कमांड तय करें।

सवाल. टीम में नॉन-इंजीनियर सदस्य हों तो भी चलेगा? चलेगा। रजिस्टर बस तालिका पढ़कर भरना है, इसलिए कोड न पढ़ पाने वाला भी इसे संचालित कर सकता है। नॉन-इंजीनियर के लिए शुरुआत नॉन-इंजीनियर के लिए इस्तेमाल में समझाई गई है।

सवाल. प्रोजेक्ट-विशिष्ट नियम कहाँ लिखूँ? रिपॉज़िटरी की CLAUDE.md में लिखें, तो Claude Code हर बार उसे पढ़ लेता है। मनाही वाले इलाके और जाँच कमांड को यहीं समेट दें, तो रजिस्टर से मेल बैठाना आसान रहता है। लिखने का तरीका CLAUDE.md लिखने का तरीका में समेटा है। Anthropic की आधिकारिक Claude Code documentation को भी प्राथमिक स्रोत के रूप में देखें।

मैंने असल में आज़माकर क्या पाया

शुरू में बताए डिप्लॉय हादसे के बाद, मैंने “Claude Code पर भरोसा करूँ या नहीं” इस उलझन में पड़ना ही छोड़ दिया। अब मैं जो देखता हूँ वह है — रजिस्टर की कौन-सी लाइन अभी खाली है।

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

मैंने बस इन्हीं तीन बातों की पुष्टि की। ज़्यादा होशियार एजेंट ढूँढने के बजाय, गिरने पर वापस उठा सकें ऐसा संचालन पहले बना लें। घुमावदार रास्ता लगता है, पर टीम-तैनाती में यही सबसे तेज़ है — यही अभी मेरा अनुभव है।

अगर कंपनी में Claude Code की तैनाती गंभीरता से आगे बढ़ानी हो, या संचालन-नियम साथ मिलकर डिज़ाइन करने हों, तो ट्रेनिंग और सलाह में हम ठोस स्टेप्स तक साथ मिलकर तैयार कर सकते हैं। शुरुआत बस इतने से करें — अपनी टीम के तीन खतरनाक बिंदु, तीन लाइन में लिख डालें।