> This is a page from the ElevenLabs documentation. For a complete page index, fetch https://elevenlabs.io/docs/llms.txt. For the full documentation in a single file, fetch https://elevenlabs.io/docs/llms-full.txt.

# प्रस्ताव और वैलिडेशन

## अवलोकन

जब ElevenAgents Architect कोई बदलाव पूरा करता है, तो वह उसे आपको एक **प्रस्ताव** के रूप में देता है: एक ब्रांच जिसमें बदलाव होता है, ऐसे टेस्ट जो दिखाते हैं कि यह काम करता है, और एक [मर्ज प्रस्ताव](/docs/hi/eleven-agents/operate/merge-proposals) जिसमें उस ब्रांच को `main` में मर्ज करने का अनुरोध होता है। यह पेज बताता है कि हर हिस्सा कैसे काम करता है, उसे कहाँ ढूंढें, और कोई प्रस्ताव बातचीत से लाइव ट्रैफ़िक तक कैसे पहुँचता है।

## प्रस्ताव क्या है

एक प्रस्ताव मौजूदा [वर्शनिंग](/docs/hi/eleven-agents/operate/versioning) मॉडल पर बनाया जाता है:

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

मर्ज प्रस्ताव एक मानक ElevenAgents मर्ज प्रस्ताव होता है, ठीक उसी तरह का जिसे कोई टीममेट मैन्युअली खोलता है। यह अलग ऑब्जेक्ट टाइप नहीं है।

एक मर्ज प्रस्ताव में ठीक एक सोर्स ब्रांच और एक टारगेट ब्रांच होती है, इसलिए एक प्रस्ताव में एक संभावित समाधान होता है। विकल्पों की तुलना करने के लिए Architect से कहें कि हर विकल्प को अपनी अलग ब्रांच पर रखे। फिर हर ब्रांच का अपना प्रस्ताव होगा, और आप उनके बीच ट्रैफ़िक को एक [एक्सपेरिमेंट](/docs/hi/eleven-agents/operate/experiments) के रूप में बाँट सकते हैं।

> **Note**
>
> Architect आपकी ओर से काम करता है, इसलिए उसके द्वारा खोला गया मर्ज प्रस्ताव लेखक के रूप में आपके नाम से दर्ज होता है।
> यह रिकॉर्ड करने के लिए कोई फ़ील्ड नहीं है कि इसे Architect ने बनाया था। अगर आपकी टीम को
> जानना हो, तो इसका उल्लेख प्रस्ताव के विवरण में करें।

## प्रस्ताव कैसे बनाया जाता है

Architect तब प्रस्ताव बनाता है जब आप उससे किसी चीज़ को ठीक करने या बेहतर करने के लिए कहते हैं, या जब आप उसे कोई विफल टेस्ट, Spotlight की खोज या ट्रायेज टिकट देते हैं। हर चरण में Architect द्वारा कॉल किए गए टूल्स के साथ पूरी प्रक्रिया [उदाहरण](/docs/hi/eleven-agents/operate/architect/how-it-works#worked-example-improving-refund-resolutions) में दी गई है। संक्षेप में:

1. Architect जाँच करता है, ब्रांच बनाता है और उस ब्रांच पर आपके ड्राफ़्ट में बदलाव स्टेज करता है।
2. Architect बदलाव के लिए टेस्ट और सिमुलेशन लिखता है और आपको नतीजा दिखाने से पहले उन्हें बातचीत में चलाता है।
3. Architect पब्लिश डायलॉग खोलता है। आप डिफ़ देखते हैं और **Publish** चुनते हैं, जिससे बदलाव ब्रांच पर नए वर्शन के रूप में कमिट हो जाता है।
4. Architect `main` में मर्ज प्रस्ताव खोलता है और उसका विवरण ब्रांच के वास्तविक कमिट्स और टेस्ट रन से लिखता है।
5. प्रस्ताव की समीक्षा के दौरान Architect ब्रांच पर लाइव ट्रैफ़िक का छोटा हिस्सा भेजने की पेशकश करता है। इसके लिए आपकी मंज़ूरी चाहिए।

आप किसी भी चरण पर रुक सकते हैं। प्रकाशित वर्शन वाली लेकिन बिना मर्ज प्रस्ताव वाली ब्रांच भी उपयोगी है: आप उसे खुद टेस्ट कर सकते हैं या बाद में प्रस्ताव खोल सकते हैं।

### बातचीत के भीतर वैलिडेशन

Architect बदलाव बनाते समय ही टेस्ट लिखता और चलाता है, न कि बाद में आपके द्वारा शुरू किए जाने वाले अलग चरण के रूप में। किसी फ़िक्स के लिए, एक उपयोगी तरीका यह दिखाना है कि नए टेस्ट बदलाव के बिना विफल होते हैं और उसके साथ पास होते हैं। Architect वही टेस्ट मूल ब्रांच और बदलाव वाले ड्राफ़्ट, दोनों पर चला सकता है।

Architect हर बदलाव के लिए अपने-आप यह पहले-और-बाद की जाँच नहीं चलाता। जब यह महत्वपूर्ण हो, तो कहें, जैसे: "मुझे नया सिमुलेशन main पर विफल और ब्रांच पर पास होता दिखाएँ, फिर प्रस्ताव खोलें।"

जब हर सफलता शर्त पूरी होती है, तो टेस्ट **पास** होता है। LLM टेस्ट में, एजेंट का जवाब सफलता मानदंडों को पूरा करता है। टूल-कॉल टेस्ट में, अपेक्षित टूल को अपेक्षित पैरामीटर्स के साथ कॉल किया जाता है। सिमुलेशन में, सिमुलेट की गई बातचीत अपनी सफलता शर्तों को पूरा करती है। अस्थिर नतीजों की जाँच के लिए Architect से टेस्ट कई बार चलाने को कहें। यह हर टेस्ट को अधिकतम 50 बार दोहरा सकता है और पास रेट बता सकता है।

हर टेस्ट टाइप की परिभाषा के लिए [टेस्टिंग](/docs/hi/eleven-agents/customization/agent-testing) देखें।

## प्रस्ताव कहाँ ढूंढें

एजेंट खोलें, फिर **Version Control** > **Proposals** पर जाएँ। सूची को स्टेटस, लेखक (**Created by**) और समीक्षक (**Awaiting review from**, **Reviewed by**) के आधार पर फ़िल्टर किया जा सकता है। आपकी बातचीत में Architect द्वारा खोला गया प्रस्ताव आपको लेखक के रूप में दिखाता है।

Architect भी प्रस्ताव बनाते ही बातचीत में उसका लिंक देता है।

![ब्रांचेज़ पेज पर प्रस्तावों की सूची](/docs/_fern-img/bfdb23ad1edb31c89c2ff2a137fa3028bf3f9fbcf31e236de142e207b5d54cd0.webp)

## प्रस्ताव की संरचना

प्रस्ताव का पेज सोर्स और टारगेट ब्रांच, उसका स्टेटस, क्या उसे मर्ज किया जा सकता है, और सोर्स ब्रांच टारगेट से कितना पीछे या आगे है, दिखाता है। इसमें ये टैब होते हैं:

#### अवलोकन

विवरण, सोर्स ब्रांच पर कमिट्स, समीक्षाओं और टिप्पणियों की गतिविधि टाइमलाइन, और एक कमेंट बॉक्स। साइडबार में समीक्षक, सुझाए गए समीक्षक और लिंक किया गया कोई भी ट्रायेज टिकट दिखता है।

Architect द्वारा लिखे गए विवरण में हमेशा तीन सेक्शन होते हैं: **सारांश** (हर महत्वपूर्ण बदलाव और उसका कारण), **टेस्टिंग** (कौन-से टेस्ट चलाए गए और उनके नतीजे, या यह कथन कि कोई टेस्ट नहीं चलाया गया), और **समीक्षा कैसे करें** (किस पर ध्यान दें, और चलाने के लिए कोई टेस्ट या आज़माने के लिए बातचीत)।

![मर्ज प्रस्ताव का Overview टैब](/docs/_fern-img/569eccd1750f90cd5ec8121411e8effd3a38e924e0f03f06f6216a9fcc160e08.webp)

#### बदलाव

कॉन्फ़िगरेशन डिफ़: मर्ज के बाद टारगेट ब्रांच कैसी दिखेगी, उसकी वर्तमान स्थिति की तुलना में। अगर दोनों ब्रांच में एक ही फ़ील्ड बदली गई है, तो **Conflicts** व्यू हर कॉन्फ़्लिक्ट और किसका बदलाव लागू होगा, दिखाता है।

प्रस्ताव मर्ज होने के बाद, यह टैब मर्ज से पहले और बाद की टारगेट ब्रांच दिखाता है।

![मर्ज प्रस्ताव का Changes टैब](/docs/_fern-img/cd06c0f93240d7c973101b896599542290437a6dcbfa6d288a25db0c1bfcd566.webp)

#### टेस्ट रन

सोर्स ब्रांच के लिए पास रेट और टेस्ट रन इतिहास, जिसमें बातचीत में Architect द्वारा शुरू किए गए रन भी शामिल हैं। उसका पास रेट तुलना करने के लिए टारगेट ब्रांच पर स्विच करें। दोनों में से किसी भी ब्रांच पर सभी अटैच किए गए टेस्ट फिर से चलाने के लिए **Run tests** चुनें, और चाहें तो हर टेस्ट को कई बार चलाएँ।

टेस्ट रन प्रस्ताव से नहीं, ब्रांच से जुड़े होते हैं। मर्ज करने के लिए टेस्ट का पास होना ज़रूरी नहीं है। समीक्षक टैब में दिखाए गए आधार पर फैसला करते हैं।

![मर्ज प्रस्ताव का Test runs टैब](/docs/_fern-img/58e28b31cb3408fe5bf8e9193f4a4edb5e716e6023c56f29d5a4f924c70a0f7a.webp)

#### बातचीत

सोर्स ब्रांच पर चली हर बातचीत, जिसमें ट्रैफ़िक स्प्लिट के ज़रिए वहाँ भेजा गया लाइव ट्रैफ़िक भी शामिल है। उसकी ट्रांसक्रिप्ट खोलने के लिए कोई बातचीत चुनें। जब ब्रांच धीरे-धीरे रोलआउट पर हो, तो यहीं आप देख सकते हैं कि वास्तविक कॉलर बदलाव का कैसे उपयोग करते हैं।

![मर्ज प्रस्ताव का Conversations टैब](/docs/_fern-img/f6345ff5beaee9a22732c7322995a7e889245cda7901682ab390790ef3849690.webp)

## समीक्षा और मर्ज करना

### स्टेटस

मर्ज प्रस्ताव में इनमें से एक स्टेटस होता है:

| स्टेटस        | मतलब                                                                                                                              |
| ------------- | --------------------------------------------------------------------------------------------------------------------------------- |
| खुला          | समीक्षा या मर्ज का इंतज़ार है।                                                                                                    |
| मर्ज किया गया | ब्रांच को टारगेट में मर्ज कर दिया गया।                                                                                            |
| बंद           | लेखक ने वापस ले लिया, किसी और ने अस्वीकार कर दिया, या ब्रांच आर्काइव होने के कारण बंद हुआ। बंद प्रस्ताव फिर से नहीं खोले जा सकते। |

जब प्रस्ताव खुला होता है, तो हर समीक्षक की नवीनतम समीक्षा **Approved** या **Changes requested** होती है। अलग से "tested" या "ready for review" स्टेटस नहीं होते। टेस्ट नतीजे इसके बजाय **Test runs** टैब पर दिखते हैं।

समीक्षाएँ और टिप्पणियाँ **Overview** टैब की गतिविधि टाइमलाइन में, सोर्स ब्रांच पर कमिट किए गए हर नए वर्शन के साथ दिखती हैं।

![मर्ज प्रस्ताव की गतिविधि टाइमलाइन](/docs/_fern-img/522012341d0089ff418032a34bae6653d2b883934b64a0b6a12de887646b2f5f.webp)

### कौन मंज़ूरी दे और मर्ज कर सकता है

* लेखक को छोड़कर, एजेंट का एडिटर ऐक्सेस रखने वाला कोई भी व्यक्ति प्रस्ताव की समीक्षा कर सकता है। Architect आपकी ओर से काम करता है, इसलिए आप अपनी बातचीत में Architect द्वारा खोले गए प्रस्ताव को मंज़ूरी नहीं दे सकते। किसी टीममेट को देनी होगी।
* प्रस्ताव को तब मर्ज किया जा सकता है जब लेखक के अलावा किसी अन्य व्यक्ति से कम-से-कम एक मंज़ूरी हो और किसी भी समीक्षक की नवीनतम समीक्षा **Changes requested** न हो। वर्कस्पेस एडमिन मंज़ूरी के बिना मर्ज कर सकते हैं।
* किसी [सुरक्षित ब्रांच](/docs/hi/eleven-agents/operate/versioning) में मर्ज करने के लिए एडमिन अनुमतियाँ या एडमिन की मंज़ूरी चाहिए।

Architect मर्ज प्रस्ताव को मंज़ूरी नहीं दे सकता, उस पर टिप्पणी नहीं कर सकता, उसे मर्ज या बंद नहीं कर सकता। ये चरण हमेशा लोग करते हैं। समीक्षा के पूरे नियमों के लिए [मर्ज प्रस्ताव](/docs/hi/eleven-agents/operate/merge-proposals) देखें।

> **Warning**
>
> जब आप Architect से ऐसा करने को कहते हैं और आपकी भूमिका मर्ज की अनुमति देती है, तो वह प्रस्ताव के बिना सीधे ब्रांच मर्ज कर सकता है।
> **Approval required** मोड में वह पहले पूछता है। **Auto-approve** मोड में नहीं। अगर हर बदलाव को समीक्षा किए गए प्रस्ताव से गुजरना चाहिए, तो
> `main` पर ब्रांच प्रोटेक्शन इस्तेमाल करें।

### मर्ज होने पर क्या होता है

मर्ज के बाद अलग से पब्लिश करने का चरण नहीं है। मर्ज करने से टारगेट ब्रांच पर नया वर्शन लिखा जाता है, और वह वर्शन टारगेट को मिलने वाले ट्रैफ़िक के हिस्से के लिए तुरंत लाइव ट्रैफ़िक संभालता है। जब टारगेट `main` हो और कोई ट्रैफ़िक स्प्लिट सेट न हो, तो इसका मतलब सभी कॉलर होते हैं।

मर्ज करने पर यह भी होता है:

* सोर्स ब्रांच के लाइव ट्रैफ़िक का कोई भी हिस्सा टारगेट पर चला जाता है।
* डिफ़ॉल्ट रूप से सोर्स ब्रांच आर्काइव हो जाती है।
* उसी ब्रांच के अन्य सभी खुले प्रस्ताव बंद हो जाते हैं।
* अगर कोई लिंक किया हुआ ट्रायेज टिकट है, तो उसका समाधान हो जाता है।

## क्रमिक रोलआउट

प्रस्ताव मर्ज होने से पहले, आप लाइव ट्रैफ़िक का एक हिस्सा उसकी ब्रांच पर भेज सकते हैं, ताकि वास्तविक कॉलर बदलाव का उपयोग करें।

#### स्प्लिट शुरू करें

Architect से कहें, उदाहरण के लिए "इस ब्रांच पर 5% ट्रैफ़िक भेजें।" Architect आपको `main` के हिस्से सहित
पूरा परिणामी स्प्लिट बताता है और उसे लागू करने से पहले मंज़ूरी माँगता है। आप इसे खुद भी सेट कर सकते हैं: **Version Control** > **Branches** में,
ब्रांच पर **Deploy** चुनें।

#### नतीजे देखें

ब्रांच की बातचीत पढ़ने के लिए प्रस्ताव का **Conversations** टैब खोलें या Architect से
ब्रांच के नतीजों की `main` के नतीजों से तुलना करने को कहें।

#### प्रमोट करें या रोल बैक करें

प्रमोट करने के लिए प्रस्ताव मर्ज करें। ब्रांच का ट्रैफ़िक हिस्सा उसके साथ `main` पर चला जाता है। रोल
बैक करने के लिए Architect से ब्रांच का हिस्सा 0% सेट करने को कहें या डिप्लॉयमेंट खुद संपादित करें। लाइव
ट्रैफ़िक तुरंत `main` पर लौट आता है।

ट्रैफ़िक हिस्सों का कुल हमेशा 100% होना चाहिए और रूटिंग हर बातचीत के लिए निर्धारित होती है। सुरक्षित `main` से ट्रैफ़िक लेना समेत, किसी सुरक्षित ब्रांच का हिस्सा बदलने के लिए एडमिन चाहिए। [ट्रैफ़िक डिप्लॉयमेंट](/docs/hi/eleven-agents/operate/versioning#traffic-deployment) देखें।

## सक्रिय प्रस्ताव

> **Note**
>
> Architect आपके कहने पर, या जब आप उसे कोई विफल टेस्ट, Spotlight की खोज, अलर्ट या ट्रायेज टिकट देते हैं, तब प्रस्ताव बनाता है।
> वह अभी आपके एजेंट्स को किसी तय शेड्यूल पर स्कैन नहीं करता और न ही खुद प्रस्ताव खोलता है।

आज सक्रिय प्रक्रिया [Spotlight](/docs/hi/eleven-agents/dashboard/spotlight) से शुरू होकर हैंड-ऑफ़ तक जाती है। Spotlight आपके एजेंट की बातचीत को लगातार मॉनिटर करता है। यह सुझाई गई जाँचों के साथ साप्ताहिक सारांश बनाता है, रियल-टाइम अलर्ट देता है और कॉन्फ़िगरेशन बदलाव सुझाता है। Spotlight की खोज को प्रस्ताव में बदलने के लिए:

#### Spotlight खोलें

एजेंट खोलें। उसका ओवरव्यू पेज Spotlight है।

#### कोई खोज चुनें

साप्ताहिक सारांश खोलें और **Suggested next steps** देखें, या कोई रियल-टाइम अलर्ट खोलें।

#### इसे ElevenAgents Architect को सौंपें

किसी सुझाव पर **Open in Architect**, सारांश पर **Analyze with Architect**, या
किसी अलर्ट पर **Investigate with Architect** चुनें। Architect को खोज मिलती है और उसे बदलाव सुझाने से पहले
वास्तविक बातचीत के विरुद्ध उसे सत्यापित करने और प्रभावित ब्रांच की पहचान करने का निर्देश दिया जाता है।

#### प्रस्ताव माँगें

Architect की खोजों की समीक्षा करें। अगर आप मूल कारण से सहमत हैं, तो उससे समस्या को किसी
ब्रांच पर ठीक करने, फ़िक्स टेस्ट करने और प्रस्ताव खोलने को कहें।

ट्रायेज टिकट भी इसी तरह काम करते हैं। आपका लाइव एजेंट बातचीत के दौरान [समीक्षा के लिए समस्याएँ फ़्लैग कर सकता है](/docs/hi/eleven-agents/customization/tools/system-tools/flag-issue-for-review), और टिकट पर **Discuss with Architect** उसे जाँचने की प्रक्रिया शुरू करता है।

Architect इनबॉक्स में भेजी जाने वाली रिपोर्ट के साथ शेड्यूल्ड ऑटोमेशन विकासाधीन हैं। Architect पेज पर **Inbox** टैब उनके लिए प्लेसहोल्डर है।