साझा प्रोफ़ाइल स्कीमा

Apothem साझा प्रोफ़ाइल YAML के लिए स्कीमा।

Apothem साझा प्रोफ़ाइल ~/.config/apothem/profile.yaml पर, या --profile PATH के साथ दिए गए पथ पर, एक YAML फ़ाइल है। यह पहचान, वरीयताओं, साझा नियमों, प्रति-हार्नेस ओवरराइड्स, और हार्नेस बहिष्करणों के लिए सत्य का अर्थगत स्रोत है। एडॉप्टर इस प्रोफ़ाइल और पैकेज की गई Apothem पेलोड cohort से हार्नेस-मूल फ़ाइलें व्युत्पन्न करते हैं।

रनटाइम मॉडल src/apothem/lib/profile.py है; JSON स्कीमा src/apothem/schemas/profile.schema.json है।

न्यूनतम मान्य प्रोफ़ाइल

एकमात्र आवश्यक फ़ील्ड identity.name है:

identity:
  name: "Example User"

`profile init` द्वारा लिखा गया स्कैफ़ोल्ड

apothem profile init एक थोड़ा अधिक भरा-पूरा स्कैफ़ोल्ड लिखता है — प्लेसहोल्डर पहचान फ़ील्ड्स जिन्हें संचालक से व्यक्तिगत बनाने की अपेक्षा की जाती है — और सफलता की सूचना देने से पहले उसे सत्यापित करता है:

identity:
  name: "Example User"
  email: "[email protected]"
  github: "example-user"

कमांड इन फ़ील्ड्स को नाम देते हुए एक व्यक्तिगतकरण संकेत प्रिंट करता है। यदि कोई अभी भी प्लेसहोल्डर पहचान बाद में install या update तक पहुँचती है, तो वे कमांड एक परामर्शी टिप्पणी प्रिंट करते हैं और आगे बढ़ जाते हैं — Apothem कभी भी एक प्लेसहोल्डर पहचान को न तो गढ़ता है और न ही उस पर रुकता है।

विहित फ़ील्ड्स

फ़ील्ड	आवश्यक	डिफ़ॉल्ट	टिप्पणियाँ
`identity.name`	हाँ	कोई नहीं	संचालक का गैर-रिक्त प्रदर्शन नाम।
`identity.role`	नहीं	`senior software engineer`	साझा भूमिका पाठ।
`identity.email`	नहीं	छोड़ा गया	उपस्थित होने पर ईमेल-स्वरूपित होना चाहिए।
`identity.website`	नहीं	छोड़ा गया	उपस्थित होने पर URI-स्वरूपित होना चाहिए।
`identity.github`	नहीं	छोड़ा गया	`@` के बिना GitHub उपयोगकर्ता नाम।
`preferences.language`	नहीं	`python`	छोटे अक्षरों में सामान्यीकृत।
`preferences.style`	नहीं	`concise`	`concise`, `verbose`, `balanced` में से एक।
`preferences.formatter`	नहीं	छोड़ा गया	उपस्थित होने पर गैर-रिक्त स्ट्रिंग।
`preferences.test_framework`	नहीं	छोड़ा गया	उपस्थित होने पर गैर-रिक्त स्ट्रिंग।
`rules`	नहीं	`[]`	अद्वितीय गैर-रिक्त स्ट्रिंग्स; न्यूलाइन LF में सामान्यीकृत होती हैं।
`seriousness`	नहीं	`PERSONAL_USE`	`EXPLORING`, `PERSONAL_USE`, `SHARED`, `PUBLIC_LAUNCH` में से एक।
`harnesses`	नहीं	`{}`	समर्थित हार्नेस ID द्वारा कुंजीबद्ध प्रति-हार्नेस ओवरराइड्स।
`exclude_harnesses`	नहीं	`[]`	`--harness all` से बहिष्कृत समर्थित हार्नेस ID।

हार्नेस कुंजियाँ

स्कीमा ठीक इन सत्रह हार्नेस ID को स्वीकार करता है:

antigravity
claude-code
codebuddy
codex
cursor
gemini-cli
github-copilot
glm
hermes
kimi-code
kiro
open-claw
opencode
qwen-code
trae
windsurf
zed

अज्ञात शीर्ष-स्तरीय फ़ील्ड्स, अज्ञात हार्नेस कुंजियाँ, गलत मान प्रकार, दोहराए गए बहिष्करण, और विकृत पहचान फ़ील्ड्स, install या update के लिखने से पहले विफल हो जाते हैं। अपेक्षित त्रुटियों में एक फ़ील्ड, एक कारण, एक समाधान, उपयोगी होने पर एक संपादित सुरक्षित मान, और सत्यापन विफलताओं के लिए files_written: [] शामिल होते हैं।

प्रोफ़ाइल फ़ील्ड से मूल फ़ाइल तक

प्रोफ़ाइल क्या है; एडॉप्टर कैसे हैं। आरंभ-से-अंत प्रवाह को समझना यह समझाता है कि क्यों एक ही YAML फ़ाइल में एक संपादन हर इंस्टॉल किए गए हार्नेस को फिर से आकार दे सकता है।

एक प्रोफ़ाइल फ़ील्ड अर्थगत आशय वहन करती है, न कि कोई शाब्दिक कॉन्फ़िग अंश। identity.name "संचालक कौन है" है, JSON की एक पंक्ति नहीं। पैकेज की गई पेलोड cohort (commands, rules, skills, hooks, templates, statuslines, output-styles, agents) Apothem के अपने तटस्थ स्वरूप में व्यवहारगत सामग्री वहन करती है। न तो फ़ील्ड और न ही cohort जानता है कि किसी भी हार्नेस का कॉन्फ़िग कैसा दिखता है — वह ज्ञान केवल एडॉप्टरों का है।

जब आप apothem update चलाते हैं, तो प्रवाह है:

JSON स्कीमा के विरुद्ध प्रोफ़ाइल को लोड और सत्यापित करें। जब तक पूरी प्रोफ़ाइल मान्य न हो, कुछ भी नहीं लिखा जाता, ताकि कोई टाइपो कभी आधा-इंस्टॉल न करे।
केंद्रीय रजिस्ट्री के माध्यम से चयनित हार्नेस (या all, किसी भी exclude_harnesses को घटाकर) के लिए एडॉप्टरों को सुलझाएँ।
मूर्त करें — प्रत्येक एडॉप्टर वही प्रोफ़ाइल और वही cohort पढ़ता है, फिर उन्हें अपने हार्नेस की बोली में अनुवाद करता है। preferences.style जैसी फ़ील्ड एक हार्नेस में एक मूल कॉन्फ़िग मान बन जाती है और दूसरे में रेंडर किया गया निर्देश संदर्भ; rules[] में एक नियम Cursor के लिए एक .mdc फ़ाइल बन जाता है, Copilot के लिए रेपो-व्यापी निर्देशों का एक खंड, या जहाँ हार्नेस के पास कोई मूल नियम सतह नहीं है वहाँ एक समर्थन-वृक्ष प्रविष्टि।
मूल फ़ाइलें लिखें — एक रेंडर किया गया एकल कॉन्फ़िग, एक परिवर्तित cohort, या हार्नेस के मूल एंकर से संदर्भित एक समर्थन उप-वृक्ष।

वही प्रोफ़ाइल हर हार्नेस को चलाती है, इसलिए मूर्तीकरण आशय के बारे में असहमत नहीं हो सकते। ऐसी क्षमता कोशिकाएँ जिन्हें हार्नेस समर्थन नहीं करता (या जो अब भी खोज-प्रतीक्षित हैं) किसी भी लेखन से पहले संरचित चेतावनियों के रूप में उभरती हैं, बजाय इसके कि उन्हें किसी ऐसी विक्रेता सतह में गढ़ा जाए जो मौजूद नहीं है। यही वह बात है जो एक-संपादन-अनेक-हार्नेस की गारंटी को वास्तविक बनाती है: प्रोफ़ाइल एक बार संपादित होती है, और प्रत्येक एडॉप्टर उस एकल स्रोत से अपनी मूल फ़ाइलों को फिर से व्युत्पन्न करता है।