प्रोजेक्ट कॉन्फ़िगरेशन (config.yaml)

openspec/config.yaml का हर फ़ील्ड: वह schema, context और rules जिनके साथ यह प्रोजेक्ट योजना बनाता है।

स्थान

प्रत्येक OpenSpec प्रोजेक्ट अपनी कॉन्फ़िग फ़ाइल प्रोजेक्ट रूट में openspec/config.yaml पर रखता है।

फ़ील्ड

कुंजी	प्रकार	आवश्यक	प्रभाव
schema	string	हाँ	वह वर्कफ़्लो schema जिसका इस प्रोजेक्ट के परिवर्तन पालन करते हैं
context	string	नहीं	हर आर्टिफ़ैक्ट, apply और archive में इंजेक्ट किया जाता है
rules	map: artifact ID → list of strings	नहीं	किसी एक आर्टिफ़ैक्ट के अंतर्निहित मार्गदर्शन में जोड़े गए अतिरिक्त rules
operations	map: operation → guidance list	नहीं	apply और archive कार्य के लिए सलाहकारी मार्गदर्शन
store	string	नहीं	जब यह openspec/ केवल कॉन्फ़िग हो तो फ़ॉलबैक OpenSpec रूट
references	list	नहीं	वे स्टोर जिनके specs निर्देशों में इंडेक्स किए जाते हैं

अमान्य फ़ील्ड कभी भी किसी कमांड को विफल नहीं करते। प्रत्येक फ़ील्ड को अलग से मान्य किया जाता है, और खराब मान को चेतावनी के साथ छोड़ दिया जाता है। जो फ़ाइल पढ़ी नहीं जा सकती या मान्य YAML नहीं है, उसे चेतावनी के साथ अनदेखा किया जाता है; अपवाद openspec validate है, जो 1 के साथ बाहर निकलता है ताकि CI इसे पकड़ सके।

इन फ़ील्ड में क्या लिखना है, यह प्रोजेक्ट कॉन्फ़िगरेशन में बताया गया है।

schema

वह वर्कफ़्लो schema जिसका इस प्रोजेक्ट का हर परिवर्तन पालन करता है। मान्य मान spec-driven या प्रोजेक्ट द्वारा परिभाषित schema नाम हैं। उपलब्ध schema नामों की सूची देखने के लिए openspec schemas चलाएँ।

context

मुक्त टेक्स्ट जो हर आर्टिफ़ैक्ट के निर्देशों में इंजेक्ट किया जाता है और apply तथा archive को दिया जाता है। सीमा 50KB है, और इससे बड़ा मान चेतावनी के साथ अनदेखा कर दिया जाता है।

rules

एक आर्टिफ़ैक्ट के लिए अतिरिक्त rules, जो schema के अंतर्निहित मार्गदर्शन में जोड़े जाते हैं:

rules:
  proposal:
    - Keep proposals under 500 words

आर्टिफ़ैक्ट ID अंतर्निहित नामों तक सीमित नहीं हैं, इसलिए कस्टम schema के आर्टिफ़ैक्ट कुंजियों के रूप में काम करते हैं।

operations

apply और archive कार्य कैसे संचालित हो, इसके लिए सलाहकारी मार्गदर्शन, जो आर्टिफ़ैक्ट rules से अलग है:

operations:
  apply:
    guidance:
      - Keep test summaries concise

केवल apply और archive पढ़े जाते हैं।

store

एक store ID जिसे OpenSpec रूट के रूप में उपयोग किया जाता है, केवल तब देखा जाता है जब यह openspec/ डायरेक्टरी केवल कॉन्फ़िग हो (कोई specs/ या changes/ न हो)। यह फ़ॉलबैक है, कभी ओवरराइड नहीं। पूरा क्रम रूट रिज़ॉल्यूशन में है।

references

वे store ID जिनके specs पर इस प्रोजेक्ट का कार्य आधारित है। प्रत्येक store के specs का एक इंडेक्स (id, summary, fetch command) निर्देशों के आउटपुट में जोड़ा जाता है। Spec सामग्री कभी इनलाइन नहीं की जाती, और रूट रिज़ॉल्यूशन कभी प्रभावित नहीं होता। प्रत्येक प्रविष्टि या तो store ID होती है या id और वैकल्पिक remote क्लोन स्रोत वाला map:

references:
  - platform-specs
  - id: billing-specs
    remote: git@github.com:acme/billing-specs.git

उदाहरण

भरा हुआ config.yaml:

schema: spec-driven

context: |
  Designs and tasks must cover Windows, macOS, and Linux
  Write all artifacts in Spanish

rules:
  proposal:
    - Keep proposals under 500 words
    - Always state what is out of scope
  tasks:
    - Break tasks into chunks of max 2 hours

operations:
  apply:
    guidance:
      - Keep test summaries concise
  archive:
    guidance:
      - Summarize the archive outcome before finishing

पुराने नाम

openspec/config.yml को एलियस के रूप में पढ़ा जाता है जब config.yaml मौजूद न हो। जब दोनों फ़ाइलें मौजूद हों, तो config.yaml प्राथमिकता लेता है और config.yml अनदेखा किया जाता है। openspec init config.yaml बनाता है।