> ## Documentation Index
> Fetch the complete documentation index at: https://docs.befailproof.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# किसी नीति का परीक्षण करें
> ऐसे ट्रैफ़िक के विरुद्ध बैकटेस्ट करें जो आपके पास पहले से है, और सिद्ध करें कि यह वह सब कुछ रोकता है जो इसे रोकना चाहिए और वह सब कुछ अनुमति देता है जो इसे देनी चाहिए, इससे पहले कि कोई मशीन इसे लागू करे।
हर नीति का परीक्षण दो तरीकों से करें: आपके एजेंटों द्वारा पहले से तैयार किए गए ट्रैफ़िक के विरुद्ध, और एक वैध कार्रवाई के विरुद्ध जिसे इसे अनुमति देनी चाहिए। एक नीति जिसने केवल असुरक्षित मामले को देखा है, उसका परीक्षण नहीं किया गया है।
## ड्राफ्ट का बैकटेस्ट करें
नीति संपादक एक ड्राफ्ट को उन कॉल के विरुद्ध फिर से चलाता है जो आपके फ्लीट ने पहले ही बना दिए हैं, इससे पहले कि आप इसे प्रकाशित करें।
1. **Admin → policy editor** में ड्राफ्ट खोलें। संपादक पुष्टि करता है कि यह JavaScript के रूप में पार्स होता है।
2. **backtest** में, उन एजेंटों और समय विंडो को चुनें जिन्हें आप फिर से चलाना चाहते हैं — डिफ़ॉल्ट रूप से **every agent** और **30d** — और जब तक आप इसे सीमित नहीं करना चाहते, तब तक अंतिम फ़िल्टर को **everything** पर रखें।
3. **run backtest** चुनें।
परिणाम वह है जो ड्राफ्ट उन कॉल के साथ करता — जिसमें वह कितनी **working** कॉल को बाधित करता, यह भी शामिल है। ये गलत सकारात्मक हैं जो किसी भी एजेंट से मिलने से पहले पाए जाते हैं: ड्राफ्ट को कसें और जब तक वह संख्या आपके लिए स्वीकार्य न हो, तब तक इसे फिर से चलाएं।
बैकटेस्टिंग एक डैशबोर्ड सुविधा है। टर्मिनल से, इसके बजाय नीति को उन घटनाओं के विरुद्ध चलाएं जिन्हें आप नीचे वर्णित करते हैं।
## इसे किसी ऐसी घटना के विरुद्ध चलाएं जिसे आप वर्णित करते हैं
`fp policies test` नीति फ़ाइल को आपकी मशीन पर एक कृत्रिम घटना के विरुद्ध चलाता है और निर्णय की जांच करता है। कुछ भी प्रकाशित नहीं होता और कुछ भी Cloud तक नहीं पहुंचता:
```bash theme={null}
fp policies test ./checkout.policy.mjs --command "git push --force" --expect deny
fp policies test ./checkout.policy.mjs --command "git push" --expect allow
```
`--event`, `--tool`, `--command` और `--file` के साथ घटना को आकार दें। नीति का अपना `match` फ़िल्टर अभी भी लागू होता है, इसलिए एक नीति जो आपके द्वारा वर्णित घटना को कवर नहीं करती है, एक निर्णय के बजाय `skipped` की रिपोर्ट करती है — आमतौर पर एक संकेत कि इसका `match` आपके इरादे से कम है।
## इसे एक मशीन पर चलाएं
अगला, इसे अपनी मशीन पर वास्तविक रूप से लागू करें, अपने स्वयं के एजेंट के विरुद्ध:
```bash theme={null}
failproofai policies --install --custom ./checkout.policy.mjs --scope project
failproofai policies
```
पहली कमांड फ़ाइल को मान्य करती है और स्थापित करती है; दूसरी पुष्टि करती है कि यह लोड हो गई है, बाकी सब कुछ के साथ जो यहां लागू हो रहा है। एजेंट को वह करने के लिए कहें जो नीति रोकती है और देखें कि यह अस्वीकार कर दिया जाता है, फिर वैध संस्करण करें और देखें कि यह आगे बढ़ता है। कोई और प्रभावित नहीं है।
Cloud से जुड़ी मशीन पर, **Observe → policy** के अंतर्गत दोनों निर्णयों की जांच करें: नीति के नाम से फ़िल्टर करें, फिर प्रत्येक लिंक किए गए सत्र को खोलें ताकि टूल इनपुट की पुष्टि कर सकें जो इसके साथ मेल खाता है और यह कारण कि इसने क्या लौटाया।
## जो विफल हो उसका परीक्षण करें
स्थापना एक लापता फ़ाइल, एक सिंटैक्स त्रुटि, एक अनसुलझा आयात, एक शीर्ष-स्तरीय अपवाद, या एक मॉड्यूल जो लोडिंग के दौरान समय समाप्त हो जाता है, को अस्वीकार करता है — इसलिए फ़ाइल या इसमें शामिल किसी भी चीज में परिवर्तन के बाद इसे फिर से चलाएं। लागू समय पर वही टूटी हुई फ़ाइल लॉग की जाती है और **skipped** की जाती है ताकि हर दूसरी नीति चलती रहे: उत्पादन लॉग में एक लोड चेतावनी को खोई हुई लागू के रूप में मानें। कन्वेंशन फ़ाइलें स्थापना कमांड के बिना लोड होती हैं, इसलिए CI में एक स्पष्ट `failproofai policies --install --custom ` चरण रखें — यह वह है जो टूटी हुई नीति पर बिल्ड को विफल करता है।
फिर इसे जो एजेंट वास्तव में भेजते हैं उससे खिलाएं, केवल वह इनपुट नहीं जिसकी आप अपेक्षा करते हैं: लापता फ़ील्ड, वैकल्पिक टूल नाम जैसे `Write` और `Edit`, Windows पथ, विकृत इनपुट। हर पथ पर एक इरादामय `allow`, `instruct` या `deny` लौटाएं, फ़ंक्शन को निर्धारक रखें, और किसी भी बाहरी कॉल को एक छोटे समय सीमा से बांधें।
## फिर इसे प्रकाशित करें और इसे देखें
एक बैकटेस्ट दिखाता है कि नीति उस ट्रैफ़िक के साथ क्या करती: यह नहीं दिखा सकता कि आपने जो ट्रैफ़िक नहीं देखा है वह क्या करेगा। संपादक में **publish version** चुनें (या `fp policies publish` चलाएं), फिर इसे [deploy it](/hi/policies/deploy) में **observe** मोड में पहले — इसके फैसले रिकॉर्ड किए जाते हैं और कुछ भी अवरुद्ध नहीं होता — और एक बार लागू करें जब इसके मेल असुरक्षित कार्यों को वैध कार्यों से अलग करते हैं।