Skip to content

शब्दावली

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

शब्दों को विषय के अनुसार समूहीकृत किया गया है, फिर प्रत्येक समूह के भीतर वर्णानुक्रमित (alphabetized) किया गया है।

मुख्य संज्ञाएँ (The core nouns)

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

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

Change. कार्य की एक इकाई, जिसे openspec/changes/<name>/ के तहत एक फ़ोल्डर के रूप में पैक किया गया है। एक Change उस कार्य के बारे में सब कुछ रखता है: इसका प्रस्ताव (proposal), डिज़ाइन, कार्य (tasks), और वह Spec संपादन जो यह पेश करता है। एक परिवर्तन, एक सुविधा या सुधार।

Artifact. एक Change के अंदर का दस्तावेज़। मानक Artifacts प्रस्ताव (proposal), delta specs, डिज़ाइन और कार्य (tasks) हैं। इन्हें निर्भरता क्रम में बनाया जाता है और ये एक-दूसरे को फीड करते हैं।

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

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

Spec के अंदर (Inside a spec)

Requirement. एक एकल व्यवहार जो सिस्टम के पास होना चाहिए, जिसे आमतौर पर एक RFC 2119 कीवर्ड से लिखा जाता है: "सिस्टम को 30 मिनट के बाद सत्र समाप्त कर देना चाहिए।" Requirement वह क्या बताता है, न कि कैसे

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

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

Artifacts (The artifacts)

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

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

Tasks (tasks.md). कार्यान्वयन (implementation) चेकलिस्ट, जिसमें चेकबॉक्स हैं। AI इसे /opsx:apply के दौरान काम करता है और जैसे-जैसे वह आगे बढ़ता है वैसे-वैसे आइटमों को चिह्नित (check) करता है।

जीवनचक्र (The lifecycle)

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

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

कार्यप्रवाह और कमांड (Workflow and commands)

OPSX. वर्तमान मानक OpenSpec कार्यप्रवाह, जो कठोर चरणों के बजाय तरल क्रियाओं (fluid actions) के आसपास बनाया गया है। इसके सभी स्लैश कमांड /opsx: से शुरू होते हैं। देखें OPSX Workflow

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

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

CLI. वह openspec प्रोग्राम जिसे आप अपने टर्मिनल में चलाते हैं। यह प्रोजेक्ट सेट करता है, परिवर्तनों को सूचीबद्ध और मान्य करता है, डैशबोर्ड खोलता है, और Archive करता है। OpenSpec का टर्मिनल वाला भाग। देखें CLI

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

Command file. एक प्रति-उपकरण स्लैश कमांड फ़ाइल (.../commands/opsx-*)। यह पुरानी वितरण तंत्र (delivery mechanism) है, जिसे अभी भी Skills के साथ समर्थित किया जाता है। आप शायद ही इन्हें सीधे छूते हैं।

Profile. आपके प्रोजेक्ट में स्थापित स्लैश कमांडों का सेट। Core (डिफ़ॉल्ट) में propose, explore, apply, sync, archive शामिल हैं। विस्तारित (expanded) सेट में new, continue, ff, verify, bulk-archive, onboard जोड़े जाते हैं। इसे openspec config profile से बदलें।

Delivery. यह कि OpenSpec आपके उपकरणों के लिए Skills, कमांड फ़ाइलें, या दोनों स्थापित करता है। इसे वैश्विक स्तर पर कॉन्फ़िगर किया जाता है और openspec update के साथ लागू किया जाता है।

अनुकूलन (Customization)

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

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

Project config (openspec/config.yaml). प्रति-परियोजना सेटिंग्स: डिफ़ॉल्ट Schema, प्रत्येक योजना अनुरोध में इंजेक्ट किया गया context:, और प्रति-Artifact rules:। अपने स्टैक और परंपराओं के बारे में OpenSpec को सिखाने का सबसे आसान तरीका। देखें Customization

Context injection. config.yaml के context: फ़ील्ड में परियोजना की पृष्ठभूमि डालना ताकि यह स्वचालित रूप से AI द्वारा उत्पन्न किए गए प्रत्येक Artifact में जोड़ा जा सके। यह उम्मीद करने से अधिक विश्वसनीय है कि AI एक अलग फ़ाइल पढ़ेगा।

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

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

रिपॉजिटरी में समन्वय (Coordination across repos) (बीटा)

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

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

Reference. एक घोषणा, कोड रिपॉजिटरी के openspec/config.yaml में, एक ऐसे Store की जो वह उपयोग करता है। Reference केवल पढ़ने योग्य (read-only) होते हैं: रिपॉजिटरी अपनी मूल जड़ (root) को बनाए रखती है, और openspec instructions को संदर्भित Store के specs का एक इंडेक्स मिलता है, प्रत्येक में उसे प्राप्त करने की सटीक कमांड होती है।

Working context. वह जो openspec context वर्तमान रिपॉजिटरी के लिए इकट्ठा करता है: इसकी OpenSpec root और हर वह Store जिसे यह संदर्भित करता है, प्रत्येक में उसे प्राप्त करने का तरीका। 'मैं किस चीज़ पर काम कर रहा हूँ?' इसका उत्तर।

Workset. फ़ोल्डरों का एक व्यक्तिगत, मशीन-स्थानीय सेट जिसे आप एक साथ खोलते हैं (आपके काम करने वाले कोड रिपॉजिटरी के साथ एक Store)। इसे openspec workset create के साथ स्पष्ट रूप से बनाया गया है; उन स्थानीय रास्तों में से कुछ भी साझा योजना रिपॉजिटरी में प्रतिबद्ध (committed) नहीं किया जाता है।

संदर्भ देखें (See also)