OpenSpec

शब्दकोश ​

हर OpenSpec शब्द एक ही जगह, साधारण भाषा में परिभाषित। इसे एक बार पढ़ लीजिए और बाकी दस्तावेज़ तेज़ी से पढ़ने लगेंगे।

शब्द विषय के अनुसार समूहबद्ध हैं, फिर प्रत्येक समूह में वर्णानुक्रम में।

मुख्य संज्ञाएँ ​

Spec. एक दस्तावेज़ जो आपके सिस्टम के किसी हिस्से के व्यवहार का वर्णन करता है। Specs openspec/specs/ में रहते हैं, डोमेन के अनुसार व्यवस्थित होते हैं, और requirements और scenarios से बने होते हैं。Spec इस सवाल का सहमति से स्वीकृत उत्तर है: "यह सॉफ्टवेयर क्या करता है?" Concepts देखें।

Source of truth. openspec/specs/ डायरेक्टरी पूरे रूप में। इसमें आपके सिस्टम का वर्तमान, सहमति से स्वीकृत व्यवहार रहता है। Changes इसमें संशोधन प्रस्तावित करते हैं; archiving उन्हें लागू करता है।

Change. कार्य का एक एकाइ, जिसे openspec/changes/<name>/ के अंतर्गत एक फोल्डर के रूप में पैकेज किया जाता है। एक change उस कार्य के बारे में सब कुछ रखता है: उसका proposal, design, tasks, और spec edits जो यह प्रस्तुत करता है। एक change, एक feature या fix।

Artifact. एक change के अंदर का दस्तावेज़। मानक artifacts हैं: proposal, delta specs, design, और tasks। इन्हें निर्भरता क्रम में बनाया जाता है और वे एक-दूसरे में फीड करते हैं।

Delta spec. एक change के अंदर की spec जो केवल बदलाव का वर्णन करती है, ADDED, MODIFIED, और REMOVED सेक्शन का उपयोग करके, बजाय पूरे spec को दोहराने के। यही चीज़ है जो OpenSpec को मौजूदा सिस्टम को साफ़ तौर पर एडिट करने देती है। Concepts देखें।

Domain. Specs के लिए एक तार्किक समूहन, जैसे auth/, payments/, या ui/। आप ऐसे डोमेन चुनते हैं जो आपके सिस्टम के बारे में आपकी सोच से मेल खाते हैं।

Spec के अंदर ​

Requirement. सिस्टम का एक अकेला व्यवहार जो होना चाहिए, आमतौर पर RFC 2119 keyword के साथ लिखा जाता है: "The system SHALL expire sessions after 30 minutes." Requirements what बताते हैं, how नहीं।

Scenario. एक requirement के क्रिया में एक विशिष्ट, परीक्षण योग्य उदाहरण, आमतौर पर Given/When/Then रूप में। Scenarios requirement को सत्यापनीय बनाते हैं: आप इससे एक automated test लिख सकते हैं।

RFC 2119 keywords. MUST, SHALL, SHOULD, और MAY शब्द, जिनमें requirement कितना कठोर है, इसकी मानकीकृत अर्थवत्ता होती है। MUST और SHALL निरपेक्ष हैं। SHOULD अपवादों के साथ अनुशंसित है। MAY वैकल्पिक है। नाम उस इंटरनेट मानक दस्तावेज़ से आया है जिसने इन्हें परिभाषित किया था।

Artifacts ​

Proposal (proposal.md). एक change का why और what: उसका इरादा, दायरा, और उच्च-स्तरीय दृष्टिकोण। पहला artifact जो आप बनाते हैं।

Design (design.md). how: तकनीकी दृष्टिकोण, आर्किटेक्चर निर्णय, और वे फाइलें जिन पर आप प्रभाव डालने की उम्मीद करते हैं। सरल changes के लिए वैकल्पिक।

Tasks (tasks.md). implementation checklist, checkboxes के साथ। AI /opsx:apply के दौरान इसमें से काम करता है और जैसे-जैसे आगे बढ़ता है वैसे-वैसे items पर टिक लगाता है।

Lifecycle ​

Archive. एक change को पूरा करने का कार्य। इसकी delta specs मुख्य specs में मर्ज हो जाती हैं, और change फोल्डर openspec/changes/archive/YYYY-MM-DD-<name>/ में चला जाता है। Archiving के बाद, आपके specs नई वास्तविकता का वर्णन करते हैं। Concepts देखें。

Sync. एक change की delta specs को मुख्य specs में मर्ज करना बिना change को archive किए। आमतौर पर स्वचालित (archive यह करने का प्रस्ताव देता है), लेकिन लंबे चलने वाले changes के लिए /opsx:sync के रूप में अलग से उपलब्ध। Commands देखें।

Workflow और commands ​

OPSX. वर्तमान मानक OpenSpec workflow, जो कठोर phases के बजाय प्रवाहमान actions के चारों ओर बना है। इसके slash commands सभी /opsx: से शुरू होते हैं। OPSX Workflow देखें।

Slash command. एक command जो आप अपने AI assistant के chat में टाइप करते हैं, जैसे /opsx:propose। Slash commands workflow को चलाने वाले हैं। ये terminal commands नहीं हैं। How Commands Work देखें।

Explore (/opsx:explore). सोच-साथी command। यह आपका codebase पढ़ता है, विकल्पों की तुलना करता है, और एक धुंधला विचार को एक विशिष्ट योजना में स्पष्ट करता है, बिना किसी artifact बनाने के और बिना किसी code लिखने के। जब आपके पास समस्या है लेकिन अभी योजना नहीं, तब अनुशंसित प्रारंभिक बिंदु। Explore First देखें।

CLI. openspec program जो आप अपने terminal में चलाते हैं। यह projects सेटअप करता है, changes सूचीबद्ध और validate करता है, dashboard खोलता है, और archive करता है। OpenSpec का terminal आधा हिस्सा। CLI देखें।

Skill. निर्देशों का फोल्डर (.../skills/openspec-*/SKILL.md) जो आपका AI assistant स्वतः पहचानता और अनुसरण करता है। Skills OpenSpec workflow को आपके assistant तक पहुँचाने के लिए उभरता क्रॉस-टूल मानक हैं।

Command file. प्रति-टूल slash command फाइल (.../commands/opsx-*)। पुराना वितरण तंत्र, जो skills के साथ-साथ अभी भी समर्थित है। आप इनसे सीधे कम ही छूते हैं।

Profile. आपके project में इंस्टॉल किए गए slash commands का सेट। Core (डिफ़ॉल्ट) है: propose, explore, apply, update, sync, archive। Expanded सेट में new, continue, ff, verify, bulk-archive, onboard जुड़ते हैं। इसे openspec config profile से बदलें।

Delivery. कि OpenSpec आपके tools के लिए skills, command files, या दोनों इंस्टॉल करता है। वैश्विक रूप से कॉन्फ़िगर किया जाता है और openspec update से लागू होता है।

Customization ​

Schema. यह परिभाषा कि workflow में कौन से artifacts हैं और वे एक-दूसरे पर कैसे निर्भर करते हैं। बिल्ट-इन डिफ़ॉल्ट है spec-driven (proposal → specs → design → tasks)। आप इसे fork कर सकते हैं या अपना खुद का लिख सकते हैं। Customization देखें।

Template. एक Markdown फाइल जो schema के अंदर होती है और किसी दिए गए artifact के लिए AI द्वारा जनरेट किए जाने वाले आउटपुट का आकार तय करती है। Template में संपादन करने से AI का आउटपुट तुरंत बदल जाता है, बिना rebuild के।

Project config (openspec/config.yaml). प्रति-project सेटिंग्स: डिफ़ॉल्ट schema, हर planning request में इंजेक्ट किया जाने वाला context:, और प्रति-artifact rules:। OpenSpec को आपके stack और conventions के बारे में सिखाने का सबसे आसान तरीका。Customization देखें।

Context injection. project background को config.yaml के context: फ़ील्ड में रखना ताकि यह स्वतः हर artifact में जुड़ जाए जिसे AI जनरेट करता है। अलग फाइल पढ़ने की उम्मीद करने से अधिक विश्वसनीय।

Dependency graph. Artifact requires: संबंधों द्वारा बनाया गया directed graph। यह एक DAG है (directed acyclic graph: तीर केवल आगे की ओर इशारा करते हैं, कभी लूप में नहीं), और OpenSpec इसका उपयोग यह जानने के लिए करता है कि आप अगला क्या बना सकते हैं।

Enablers, not gates. यह सिद्धांत कि artifact dependencies दिखाते हैं कि अगला क्या संभव बनता है, न कि क्या आवश्यक है। आप किसी भी समय किसी भी artifact को फिर से देख और संपादित कर सकते हैं। Core Concepts at a Glance देखें।

Repos के बीच समन्वय (beta) ​

ये शब्द केवल तभी लागू होते हैं जब आपका planning एक से अधिक repo पर फैला हो। ये beta में हैं। अधिकांश उपयोगकर्ता इन्हें नज़रअंदाज़ कर सकते हैं। Stores User Guide देखें।

Store. एक स्वतंत्र repo जिसका पूरा काम planning है। इसमें वही openspec/ आकार है जो आप पहले से जानते हैं (specs और changes) साथ में एक छोटा identity फाइल। आप इसे अपनी मशीन पर एक बार नाम से रजिस्टर करते हैं, और फिर कोई भी OpenSpec command कहीं से भी इसमें काम कर सकता है।

Reference. एक code repo के openspec/config.yaml में एक store का घोषणा, जिस पर वह repo निर्भर करता है। References read-only हैं: repo अपना अपना root रखता है, और openspec instructions में referenced store की specs का एक index जुड़ जाता है, प्रत्येक के साथ उसे fetch करने का सटीक command।

Working context. वह चीज़ जो openspec context वर्तमान repo के लिए एकत्रित करता है: उसका OpenSpec root साथ में हर store जिस पर यह निर्भर करता है, प्रत्येक के साथ उसे fetch करने का तरीका। "मैं किसके साथ काम कर रहा हूँ?" का उत्तर।

Workset. एक व्यक्तिगत, मशीन-स्थानीय फोल्डरों का सेट जो आप साथ में खोलते हैं (एक store आपके काम करने वाले code repos के साथ-साथ)। openspec workset create से स्पष्ट रूप से बनाया जाता है; उन स्थानीय paths के बारे में कुछ भी shared planning repo में commit नहीं होता।

और देखें ​