टीम पर OpenSpec

अन्य गाइड में दी गई सभी बातें चाहे आप अकेले हों या बीस लोगों की टीम में हों, वही काम करती हैं। टीम में बदलाव केवल किनारे के कुछ प्रश्न होते हैं: specs कहां संग्रहीत होते हैं, साथी किस तरह से किसी योजना की समीक्षा करते हैं, और यह सब कैसे हमारे मौजूदा pull-request flow में फिट होता है?

संक्षिप्त उत्तर: कोई भी बदलाव केवल फाइलों का समूह है, और OpenSpec कभी भी git को छूता नहीं है। इसलिए यह आपके मौजूदा कार्यप्रवाह को बदलने के बजाय उसमें फिट हो जाता है। यह पेज उन परंपराओं को स्पष्ट करता है जो अच्छी तरह से काम करती हैं।

एक नियम: OpenSpec git को छूता नहीं है

OpenSpec openspec/ फोल्डर के अंदर सादा Markdown पढ़ता और लिखता है। यह आपकी परियोजना में कभी भी कमिट, ब्रांच, पुश या पुल नहीं करता है — और यह स्वयं कभी किसी store को क्लोन या सिंक नहीं करता है। इसका अर्थ है:

• आप openspec/ को किसी भी अन्य सोर्स की तरह कमिट करते हैं। specs, सक्रिय बदलाव और आर्काइव आपकी परियोजना के इतिहास का हिस्सा हैं। (हां, पूरे फोल्डर को कमिट करें — FAQ देखें।)
• बदलाव एक ऐसा फोल्डर है जिसे कोड की तरह वर्शन किया जाता है। openspec/changes/add-dark-mode/ केवल ब्रांच पर मौजूद फाइलों का समूह है।
• नीचे दी गई सभी बातें परंपरा हैं, अनिवार्य नहीं। OpenSpec आपको इस तरह करने के लिए मजबूर नहीं करता; यह बस साफ-सुथरे तरीके से फिट होता है।

दैनिक कार्य प्रवाह

वह कार्यप्रवाह जो अच्छी तरह से काम करता है, उसमें एक बदलाव को एक ब्रांच और पुल-रिक्वेस्ट पर मैप किया जाता है:

git switch -c add-dark-mode        जैसे आम तौर पर ब्रांच शुरू करें
   │
/opsx:propose add-dark-mode        योजना का मसौदा तैयार करें (प्रस्ताव + specs + कार्य)
   │
योजना की समीक्षा करें              कोड पढ़ने से पहले आप इसे पढ़ें — बदलाव की समीक्षा देखें
   │
/opsx:apply                        इसे बिल्ड करें; आर्टिफैक्ट्स + कोड बदलाव एक साथ
   │
git commit && open a PR            PR में spec delta और कोड दोनों होंगे
   │
साथी समीक्षा करता है, मर्ज करता है
   │
/opsx:archive                      delta को specs/ में सम्मिलित करें, बदलाव को archive/ में स्थानांतरित करें

योजना और कोड एक ही ब्रांच में एक दूसरे के पास मौजूद होते हैं, इसलिए आपके साथी दोनों को एक साथ समीक्षा करते हैं, और छह महीने बाद भी आर्काइव किया गया spec बताता है कि कोड क्यों उस तरह दिखता है।

पुल-रिक्वेस्ट में specs की समीक्षा

यहीं टीम को फायदा महसूस होता है। जब किसी PR में बदलाव का delta spec शामिल होता है, तो समीक्षक को कुछ ऐसा मिलता है जो किसी कच्चे diff कभी नहीं देता: कोड की एक भी लाइन पढ़ने से पहले, इस बदलाव के क्या करने के उद्देश्य हैं, उसका सादा भाषा में विवरण।

समीक्षक के लिए एक अच्छा समीक्षा क्रम:

1. proposal.md पढ़ें — क्या यह सही समस्या और स्कोप है?
2. specs/ के अंदर delta पढ़ें — क्या "पूर्ण" सही परिभाषित है? (यह बदलाव की समीक्षा का दो मिनट का पास है, अब यह PR में हो रहा है।)
3. फिर कोड diff पढ़ें — क्या यह बिल्कुल उन्हीं आवश्यकताओं को पूरा करता है?

जो समीक्षक तरीके से अलग राय रखता है, वह 300 लाइनों के कोड में इसे फिर से बहस करने के बजाय, प्रस्ताव के खिलाफ सस्ते में अपनी राय व्यक्त कर सकता है। delta spec को PR विवरण के शीर्ष पर रखें, या समीक्षकों को बदलाव फोल्डर की ओर इशारा करें, ताकि वे वहीं से शुरुआत करें।

आर्काइव कब करें

आर्काइविंग से बदलाव के सभी deltas आपके मुख्य openspec/specs/ में सम्मिलित हो जाते हैं और बदलाव फोल्डर को openspec/changes/archive/YYYY-MM-DD-<name>/ में स्थानांतरित कर दिया जाता है। चूंकि specs/ सभी के लिए सामान्य सत्य का स्रोत है, इसलिए टीम में इसका समय पर करना जरूरी है। दो कार्यक्षम परंपराएं हैं:

• PR के मर्ज होने के बाद आर्काइव करें (अनुशंसित)। ब्रांच में सक्रिय बदलाव होता है; जब यह आपकी मुख्य ब्रांच में मर्ज हो जाता है, तो वहीं आर्काइव कर लें (अक्सर एक छोटा फॉलो-अप कमिट या निर्धारित सफाई होती है)। यह सुनिश्चित करता है कि सामान्य specs/ में केवल वही काम आगे बढ़ता है जो वास्तव में शिप हुआ है।
• PR के अंदर ही आर्काइव करें। छोटी टीमों के लिए यह आसान है: कोड जोड़ने वाला ही वही PR सिंक और आर्काइव भी करता है। इसका ट्रेडऑफ यह है कि आपका specs/ diff और कोड diff एक साथ आ जाते हैं, जिससे PR अधिक शोरिला हो सकता है।

इनमें से किसी एक को चुनें और उस पर लगातार पालन करें। जिस तरह भी हो, /opsx:archive चेक करता है कि सभी कार्य पूर्ण हैं और पहले सिंक करने का ऑफर करता है, ताकि गलती से कोई आधा पूर्ण काम मर्ज न हो जाए।

दो लोग, समांतर बदलाव

चूंकि बदलाव अलग-अलग फोल्डर में होते हैं, इसलिए उनमें टकराव नहीं होता:

• अलग-अलग बदलाव, अलग-अलग लोग — कोई समस्या नहीं। add-dark-mode और rate-limit-login अलग-अलग ब्रांच पर अलग-अलग फोल्डर हैं; जब तक दोनों आर्काइव नहीं हो जाते, वे एक दूसरे को कभी नहीं छूते।
• एक बदलाव, एक मालिक। एक ही बदलाव फोल्डर को संपादित करने वाले दो लोगों में ठीक उसी तरह टकराव होता है जैसे दो लोग एक ही फाइल को संपादित कर रहे हों। किसी बदलाव को केवल एक लेखक के लिए रखें, या इसे दो बदलावों में बांट दें (इसके एक और कारण right-size करना है।
• टकराव का एकमात्र स्थान specs/ है। यदि दोनों बदलाव एक ही आवश्यकता को संशोधित करते हैं, तो दूसरे बदलाव को आर्काइव करते समय openspec/specs/…/spec.md में टकराव होगा — इसे किसी भी मर्ग टकराव की तरह हल करें, और उस आवश्यकता को बनाए रखें जो वास्तविकता को दर्शाती है। यह बहुत दुर्लभ है, और यह एक फीचर है: यह git आपको बताता है कि दो बदलाव सिस्टम के किस तरह काम करने के बारे में अलग-अलग राय रखते हैं।

जब योजना एक रिपोजिटरी से बढ़ जाए

ऊपर दी गई सभी बातें यह मानते हुए हैं कि योजना कोड रिपोजिटरी की अपनी openspec/ फोल्डर में होती है, जो सही डिफॉल्ट है। जब आपकी योजना वास्तव में कई रिपोजिटरी या टीमों में फैली हो — जैसे कोई एक फीचर तीन सर्विसेस को प्रभावित करता हो, या कोई आवश्यकता एक टीम की हो और दूसरी टीम उसका उपयोग करती हो — तो बीटा stores फीचर ठीक उसी के लिए है: योजना को अपनी अलग रिपोजिटरी मिल जाती है जिस पर कोई भी कोड रिपोजिटरी इशारा कर सकती है। Stores User Guide से शुरुआत करें।

आगे कहां जाएं

• बदलाव की समीक्षा — अब आपके PR के अंदर समीक्षा पास।
• अच्छे specs लिखना — सही आकार के बदलाव को कैसे तैयार करें ताकि वह एक ही ब्रांच में फिट हो जाए, इसमें यह भी शामिल है।
• Stores User Guide — रिपोजिटरी और टीमों में फैली योजना बनाना।