---
read_when:
    - OpenClaw के अपडेट, doctor, पैकेज स्वीकृति या Plugin इंस्टॉल व्यवहार में बदलाव करना
    - रिलीज़ कैंडिडेट तैयार करना या स्वीकृत करना
    - पैकेज अपडेट, Plugin डिपेंडेंसी क्लीनअप या Plugin इंस्टॉलेशन रिग्रेशन की डीबगिंग
sidebarTitle: Update and plugin tests
summary: OpenClaw अपडेट पथों, पैकेज माइग्रेशन और Plugin इंस्टॉल/अपडेट व्यवहार को कैसे सत्यापित करता है
title: 'परीक्षण: अपडेट और plugins'
x-i18n:
    generated_at: "2026-07-27T19:25:23Z"
    model: gpt-5.6
    postprocess_version: locale-links-v1
    prompt_version: 32
    provider: openai
    source_hash: 96a11fe42472f758d4fd1cc568486e301f7460982fdb547cab8b39de04a8dabe
    source_path: help/testing-updates-plugins.md
    workflow: 16
---

अपडेट और Plugin सत्यापन के लिए जाँच-सूची: साबित करें कि इंस्टॉल योग्य पैकेज
वास्तविक उपयोगकर्ता स्थिति को अपडेट कर सकता है, `doctor` के माध्यम से पुरानी लेगेसी स्थिति की मरम्मत कर सकता है, और फिर भी
हर समर्थित स्रोत से Plugin इंस्टॉल, लोड, अपडेट और अनइंस्टॉल कर सकता है।

व्यापक टेस्ट रनर मानचित्र के लिए, [परीक्षण](/hi/help/testing) देखें। लाइव प्रोवाइडर
कुंजियों और नेटवर्क का उपयोग करने वाले सुइट के लिए, [लाइव परीक्षण](/hi/help/testing-live) देखें।

## हम क्या सुरक्षित रखते हैं

- पैकेज टारबॉल पूर्ण है, उसमें मान्य `dist/postinstall-inventory.json` है,
  और वह अनपैक की गई रिपॉज़िटरी फ़ाइलों पर निर्भर नहीं है।
- उपयोगकर्ता कॉन्फ़िगरेशन, एजेंट, सत्र, वर्कस्पेस, Plugin अनुमत-सूचियाँ या
  चैनल कॉन्फ़िगरेशन खोए बिना किसी पुराने प्रकाशित पैकेज से उम्मीदवार पैकेज पर जा सकता है।
- `openclaw doctor --fix --non-interactive` लेगेसी सफ़ाई और मरम्मत
  पथों का स्वामी है। स्टार्टअप को पुराने Plugin स्थिति के लिए छिपे हुए संगतता माइग्रेशन नहीं बढ़ाने चाहिए।
- Plugin इंस्टॉल स्थानीय डायरेक्टरी, git रिपॉज़िटरी, npm पैकेज और
  ClawHub रजिस्ट्री पथ से काम करते हैं।
- Plugin की npm निर्भरताएँ प्रति Plugin एक प्रबंधित npm प्रोजेक्ट में इंस्टॉल होती हैं,
  भरोसा करने से पहले स्कैन की जाती हैं, और Plugin अनइंस्टॉल के दौरान
  `npm uninstall` के माध्यम से हटाई जाती हैं, ताकि होइस्ट की गई निर्भरताएँ शेष न रहें।
- कुछ भी न बदलने पर Plugin अपडेट कोई कार्रवाई नहीं करता: इंस्टॉल रिकॉर्ड, समाधान किया गया
  स्रोत, इंस्टॉल की गई निर्भरता संरचना और सक्षम स्थिति अक्षुण्ण रहते हैं।

## विकास के दौरान स्थानीय प्रमाण

सीमित दायरे से शुरू करें:

```bash
pnpm changed:lanes --json
pnpm check:changed
pnpm test:changed
```

Plugin इंस्टॉल, अनइंस्टॉल, निर्भरता या पैकेज-इन्वेंटरी परिवर्तनों के लिए,
संपादित सीमांत को कवर करने वाले केंद्रित परीक्षण भी चलाएँ:

```bash
pnpm test src/plugins/uninstall.test.ts src/infra/package-dist-inventory.test.ts test/scripts/package-acceptance-workflow.test.ts
```

किसी पैकेज Docker लेन द्वारा टारबॉल का उपयोग करने से पहले, पैकेज आर्टिफ़ैक्ट को प्रमाणित करें:

```bash
pnpm release:check
```

`release:check` कॉन्फ़िगरेशन/दस्तावेज़/API अंतर जाँच चलाता है (कॉन्फ़िगरेशन स्कीमा, कॉन्फ़िगरेशन दस्तावेज़
बेसलाइन, Plugin SDK API अनुबंध मैनिफ़ेस्ट और एक्सपोर्ट, Plugin संस्करण/इन्वेंटरी),
पैकेज वितरण इन्वेंटरी लिखता है, `npm pack --dry-run` चलाता है, प्रतिबंधित
पैक की गई फ़ाइलों को अस्वीकार करता है, टारबॉल को अस्थायी प्रीफ़िक्स में इंस्टॉल करता है, पोस्टइंस्टॉल चलाता है और
बंडल किए गए चैनल एंट्रीपॉइंट का स्मोक परीक्षण करता है।

## Docker लेन

Docker लेन उत्पाद-स्तरीय प्रमाण हैं। वे Linux कंटेनरों के भीतर एक वास्तविक
पैकेज इंस्टॉल या अपडेट करते हैं और CLI कमांड,
Gateway स्टार्टअप, HTTP प्रोब, RPC स्थिति और फ़ाइल-सिस्टम स्थिति के माध्यम से व्यवहार की पुष्टि करते हैं।

पुनरावृत्ति करते समय केंद्रित लेन का उपयोग करें:

```bash
pnpm test:docker:plugins
pnpm test:docker:plugin-lifecycle-matrix
pnpm test:docker:plugin-update
pnpm test:docker:upgrade-survivor
pnpm test:docker:published-upgrade-survivor
pnpm test:docker:update-restart-auth
pnpm test:docker:update-migration
```

महत्वपूर्ण लेन:

- `test:docker:plugins` Plugin इंस्टॉल स्मोक, स्थानीय फ़ोल्डर इंस्टॉल,
  स्थानीय फ़ोल्डर अपडेट छोड़ने का व्यवहार, पहले से इंस्टॉल
  निर्भरताओं वाले स्थानीय फ़ोल्डर, `file:` पैकेज इंस्टॉल, CLI निष्पादन के साथ git इंस्टॉल, git
  मूविंग-रेफ़ अपडेट, होइस्ट की गई ट्रांज़िटिव निर्भरताओं के साथ npm रजिस्ट्री इंस्टॉल,
  बिना बदलाव वाले npm अपडेट, विकृत npm पैकेज मेटाडेटा की अस्वीकृति,
  स्थानीय ClawHub फ़िक्स्चर इंस्टॉल और बिना बदलाव वाले अपडेट, मार्केटप्लेस अपडेट व्यवहार
  और Claude-बंडल सक्षम करना/निरीक्षण कवर करता है। ClawHub ब्लॉक को
  स्व-निहित/ऑफ़लाइन रखने के लिए `OPENCLAW_PLUGINS_E2E_CLAWHUB=0` सेट करें।
- `test:docker:plugin-lifecycle-matrix` उम्मीदवार पैकेज को एक खाली
  कंटेनर में इंस्टॉल करता है, किसी npm Plugin को इंस्टॉल, निरीक्षण, अक्षम करना, सक्षम करना,
  स्पष्ट अपग्रेड, स्पष्ट डाउनग्रेड और Plugin
  कोड हटाने के बाद अनइंस्टॉल तक चलाता है। यह प्रत्येक चरण के RSS और CPU मेट्रिक्स लॉग करता है।
- `test:docker:plugin-update` सत्यापित करता है कि अपरिवर्तित इंस्टॉल किया गया Plugin
  `openclaw plugins update` के दौरान दोबारा इंस्टॉल नहीं होता या इंस्टॉल मेटाडेटा नहीं खोता।
- `test:docker:upgrade-survivor` एक अव्यवस्थित
  पुराने-उपयोगकर्ता फ़िक्स्चर पर उम्मीदवार टारबॉल इंस्टॉल करता है, पैकेज अपडेट और गैर-इंटरैक्टिव डॉक्टर चलाता है, फिर
  लूपबैक Gateway शुरू करता है और स्थिति संरक्षण की जाँच करता है।
- `test:docker:published-upgrade-survivor` पहले प्रकाशित बेसलाइन इंस्टॉल करता है,
  उसे अंतर्निर्मित `openclaw config set` रेसिपी के माध्यम से कॉन्फ़िगर करता है, उसे
  उम्मीदवार टारबॉल पर अपडेट करता है, डॉक्टर चलाता है, लेगेसी सफ़ाई जाँचता है, Gateway शुरू करता है और
  `/healthz`, `/readyz` तथा RPC स्थिति को प्रोब करता है।
- `test:docker:update-restart-auth` उम्मीदवार पैकेज इंस्टॉल करता है,
  प्रबंधित टोकन-प्रमाणीकरण Gateway शुरू करता है, `openclaw update --yes --json` के लिए
  कॉलर Gateway प्रमाणीकरण एनवायरनमेंट को अनसेट करता है और सामान्य प्रोब से पहले
  उम्मीदवार अपडेट कमांड द्वारा Gateway पुनः आरंभ किए जाने की अपेक्षा करता है।
- `test:docker:update-migration` अधिक सफ़ाई वाला प्रकाशित-अपडेट लेन है। यह
  कॉन्फ़िगर की गई Discord/Telegram-शैली की उपयोगकर्ता स्थिति से शुरू होता है, बेसलाइन
  डॉक्टर चलाता है ताकि कॉन्फ़िगर की गई Plugin निर्भरताओं को अस्तित्व में आने का अवसर मिले,
  कॉन्फ़िगर किए गए पैकेज्ड Plugin के लिए लेगेसी Plugin निर्भरता अवशेष जोड़ता है, उम्मीदवार
  टारबॉल पर अपडेट करता है और अपडेट के बाद डॉक्टर से लेगेसी निर्भरता रूट हटाने की अपेक्षा करता है।

उपयोगी प्रकाशित-अपग्रेड सर्वाइवर प्रकार:

```bash
OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPEC=openclaw@2026.4.23 \
OPENCLAW_UPGRADE_SURVIVOR_SCENARIO=versioned-runtime-deps \
pnpm test:docker:published-upgrade-survivor

OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPEC=openclaw@latest \
OPENCLAW_UPGRADE_SURVIVOR_SCENARIO=bootstrap-persona \
pnpm test:docker:published-upgrade-survivor
```

उपलब्ध परिदृश्य: `base`, `acpx-openclaw-tools-bridge`, `feishu-channel`,
`bootstrap-persona`, `channel-post-core-restore`, `plugin-deps-cleanup`,
`configured-plugin-installs`, `stale-source-plugin-shadow`, `tilde-log-path`
और `versioned-runtime-deps`। समेकित रन में, `OPENCLAW_UPGRADE_SURVIVOR_SCENARIOS=reported-issues`
(उपनाम `far-reaching`) कॉन्फ़िगर किए गए Plugin इंस्टॉल माइग्रेशन सहित
सभी परिदृश्यों में विस्तृत होता है।

पूर्ण अपडेट माइग्रेशन को जानबूझकर पूर्ण रिलीज़ CI से अलग रखा गया है। जब रिलीज़ संबंधी प्रश्न यह हो कि “क्या
2026.4.23 से अब तक की हर प्रकाशित स्थिर रिलीज़ इस उम्मीदवार पर अपडेट होकर
Plugin निर्भरता अवशेष साफ़ कर सकती है?”, तब मैन्युअल `Update Migration` वर्कफ़्लो का उपयोग करें:

```bash
gh workflow run update-migration.yml \
  --ref main \
  -f workflow_ref=main \
  -f package_ref=main \
  -f baselines=all-since-2026.4.23 \
  -f scenarios=plugin-deps-cleanup
```

## पैकेज स्वीकृति

पैकेज स्वीकृति GitHub-मूल पैकेज गेट है। यह एक उम्मीदवार
पैकेज को `package-under-test` टारबॉल में समाधान करता है, संस्करण और SHA-256 रिकॉर्ड करता है, फिर
ठीक उसी टारबॉल के विरुद्ध पुनः उपयोग योग्य Docker E2E लेन चलाता है। वर्कफ़्लो हार्नेस
रेफ़ पैकेज स्रोत रेफ़ से अलग होता है, ताकि वर्तमान परीक्षण तर्क पुरानी विश्वसनीय रिलीज़ का सत्यापन कर सके।

उम्मीदवार स्रोत:

- `source=npm`: `openclaw@extended-stable`, `openclaw@beta`,
  `openclaw@latest` या किसी सटीक प्रकाशित संस्करण को सत्यापित करें।
- `source=ref`: चयनित वर्तमान
  हार्नेस से किसी विश्वसनीय ब्रांच, टैग या कमिट को पैक करें।
- `source=url`: आवश्यक `package_sha256` के साथ सार्वजनिक HTTPS टारबॉल सत्यापित करें।
  यह पथ URL क्रेडेंशियल, गैर-डिफ़ॉल्ट HTTPS पोर्ट, निजी/आंतरिक
  होस्टनाम या DNS/IP परिणाम, विशेष-उपयोग IP स्पेस और असुरक्षित रीडायरेक्ट को अस्वीकार करता है।
- `source=trusted-url`: अनुरक्षक-स्वामित्व वाली
  `.github/package-trusted-sources.json` नीति के विरुद्ध आवश्यक `package_sha256` और `trusted_source_id` वाले HTTPS टारबॉल को सत्यापित करें।
  इनपुट-स्तरीय निजी-अनुमति
  स्विच से `source=url` को कमज़ोर करने के बजाय एंटरप्राइज़/निजी मिरर के लिए इसका उपयोग करें।
  नीति द्वारा कॉन्फ़िगर किए जाने पर बियरर प्रमाणीकरण नियत
  `OPENCLAW_TRUSTED_PACKAGE_TOKEN` सीक्रेट का उपयोग करता है।
- `source=artifact`: किसी अन्य Actions रन द्वारा अपलोड किए गए टारबॉल का पुनः उपयोग करें।

पूर्ण रिलीज़ सत्यापन डिफ़ॉल्ट रूप से समाधान किए गए रिलीज़ SHA से निर्मित
`source=artifact` का उपयोग करता है। प्रकाशन के बाद के प्रमाण के लिए,
`package_acceptance_package_spec=openclaw@YYYY.M.PATCH` पास करें ताकि वही अपग्रेड मैट्रिक्स
भेजे गए npm पैकेज को लक्ष्य बनाए।

रिलीज़ जाँच पैकेज स्वीकृति को पैकेज/अपडेट/पुनः आरंभ/Plugin सेट के साथ कॉल करती हैं:

```text
doctor-switch update-channel-switch skill-install update-corrupt-plugin upgrade-survivor published-upgrade-survivor root-managed-vps-upgrade update-restart-auth plugins-offline plugin-update plugin-binding-command-escape
```

जब रिलीज़ सोक सक्षम हो (`release_profile=stable` और
`full` के लिए बलपूर्वक सक्षम), तो वे यह भी पास करती हैं:

```text
published_upgrade_survivor_baselines=last-stable-4 2026.4.23 2026.5.2 2026.4.15
published_upgrade_survivor_scenarios=reported-issues
telegram_mode=mock-openai
```

इससे पैकेज माइग्रेशन, अपडेट चैनल स्विचिंग, दूषित प्रबंधित-Plugin
सहनशीलता, पुरानी Plugin निर्भरता सफ़ाई, ऑफ़लाइन Plugin कवरेज, Plugin
अपडेट व्यवहार और Telegram पैकेज QA एक ही समाधान किए गए आर्टिफ़ैक्ट पर बने रहते हैं,
और डिफ़ॉल्ट रिलीज़ पैकेज गेट को प्रत्येक प्रकाशित रिलीज़ पर चलने की आवश्यकता नहीं पड़ती।

`last-stable-4` npm पर प्रकाशित चार नवीनतम स्थिर OpenClaw
रिलीज़ में समाधान होता है। रिलीज़ पैकेज स्वीकृति `2026.4.23` को प्रथम Plugin-अपडेट
संगतता सीमा, `2026.5.2` को Plugin-आर्किटेक्चर परिवर्तन सीमा और
`2026.4.15` को पुराने 2026.4.1x प्रकाशित-अपडेट बेसलाइन के रूप में पिन करती है; समाधानकर्ता
उन पिनों को डिडुप्लिकेट करता है जो पहले से नवीनतम चार में हैं। व्यापक प्रकाशित
अपडेट माइग्रेशन कवरेज के लिए, पूर्ण रिलीज़ CI के बजाय अलग अपडेट
माइग्रेशन वर्कफ़्लो में `all-since-2026.4.23` का उपयोग करें। जब आपको लेगेसी पूर्व-तिथि
एंकर सहित व्यापक मैन्युअल नमूना चाहिए, तब `release-history` उपलब्ध रहता है।

जब अनेक प्रकाशित-अपग्रेड सर्वाइवर बेसलाइन चुनी जाती हैं, तो पुनः उपयोग योग्य
Docker वर्कफ़्लो प्रत्येक बेसलाइन को उसके अपने लक्षित रनर जॉब में शार्ड करता है। प्रत्येक
बेसलाइन शार्ड फिर भी चयनित परिदृश्य सेट चलाता है, लेकिन लॉग और आर्टिफ़ैक्ट
प्रति-बेसलाइन बने रहते हैं और कुल समय एक बड़े
क्रमिक जॉब के बजाय सबसे धीमे शार्ड से सीमित होता है।

रिलीज़ से पहले किसी उम्मीदवार को सत्यापित करते समय पैकेज प्रोफ़ाइल मैन्युअल रूप से चलाएँ:

```bash
gh workflow run package-acceptance.yml \
  --ref main \
  -f workflow_ref=main \
  -f source=npm \
  -f package_spec=openclaw@beta \
  -f suite_profile=package \
  -f published_upgrade_survivor_baselines="last-stable-4 2026.4.23 2026.5.2 2026.4.15" \
  -f published_upgrade_survivor_scenarios=reported-issues \
  -f telegram_mode=mock-openai
```

प्रकाशित विस्तारित-स्थिर कैनरी के लिए,
`package_spec=openclaw@extended-stable` सेट करें। Docker लेन चलने से पहले पैकेज स्वीकृति उस
चयनकर्ता को एक सटीक टारबॉल में समाधान करती है।

जब रिलीज़ संबंधी प्रश्न में MCP चैनल,
cron/सबएजेंट सफ़ाई, OpenAI वेब खोज या OpenWebUI शामिल हों, तब `suite_profile=product` का उपयोग करें।
`suite_profile=full` का उपयोग केवल तभी करें जब आपको पूर्ण Docker रिलीज़-पथ कवरेज चाहिए।

## रिलीज़ डिफ़ॉल्ट

रिलीज़ उम्मीदवारों के लिए, डिफ़ॉल्ट प्रमाण स्टैक है:

1. स्रोत-स्तरीय प्रतिगमन के लिए `pnpm check:changed` और `pnpm test:changed`।
2. पैकेज आर्टिफ़ैक्ट अखंडता के लिए `pnpm release:check`।
3. इंस्टॉल/अपडेट/पुनः आरंभ/Plugin अनुबंधों के लिए पैकेज स्वीकृति `package` प्रोफ़ाइल या रिलीज़-जाँच कस्टम पैकेज
   लेन।
4. OS-विशिष्ट इंस्टॉलर, ऑनबोर्डिंग और प्लेटफ़ॉर्म
   व्यवहार के लिए क्रॉस-OS रिलीज़ जाँच।
5. लाइव सुइट केवल तभी, जब परिवर्तित सतह प्रोवाइडर या होस्टेड-सेवा
   व्यवहार को प्रभावित करती हो।

अनुरक्षक मशीनों पर, व्यापक गेट और Docker/पैकेज उत्पाद प्रमाण
स्थानीय प्रमाण स्पष्ट रूप से न किए जाने पर Testbox में चलने चाहिए।

## लेगेसी संगतता

संगतता में ढील सीमित और समयबद्ध है:

- `2026.4.25-beta.*` सहित `2026.4.25` तक के पैकेज,
  पैकेज स्वीकृति में पहले से भेजे गए पैकेज मेटाडेटा अंतर सहन कर सकते हैं।
- प्रकाशित `2026.4.26` पैकेज पहले से भेजी गई स्थानीय बिल्ड मेटाडेटा स्टैम्प
  फ़ाइलों के लिए चेतावनी दे सकता है।
- बाद के पैकेज को आधुनिक अनुबंधों को पूरा करना आवश्यक है। वही अंतर
  चेतावनी देने या छोड़ने के बजाय विफल होते हैं।

इन पुराने आकारों के लिए नए स्टार्टअप माइग्रेशन न जोड़ें। डॉक्टर
मरम्मत जोड़ें या विस्तृत करें, फिर उसे `upgrade-survivor`, `published-upgrade-survivor` या
अपडेट कमांड द्वारा पुनः आरंभ का स्वामित्व होने पर `update-restart-auth` से प्रमाणित करें।

## कवरेज जोड़ना

अपडेट या Plugin व्यवहार बदलते समय, सबसे निचली उस परत पर कवरेज जोड़ें जो
सही कारण से विफल हो सकती है:

- शुद्ध पाथ या मेटाडेटा लॉजिक: स्रोत के पास यूनिट टेस्ट।
- पैकेज इन्वेंटरी या पैक की गई फ़ाइल का व्यवहार: `package-dist-inventory` या टारबॉल
  चेकर टेस्ट।
- CLI इंस्टॉल/अपडेट व्यवहार: Docker लेन अभिकथन या फ़िक्स्चर।
- प्रकाशित-रिलीज़ माइग्रेशन व्यवहार: `published-upgrade-survivor` परिदृश्य।
- अपडेट के स्वामित्व वाला रीस्टार्ट व्यवहार: `update-restart-auth`।
- रजिस्ट्री/पैकेज स्रोत व्यवहार: `test:docker:plugins` फ़िक्स्चर या ClawHub
  फ़िक्स्चर सर्वर।
- डिपेंडेंसी लेआउट या क्लीनअप व्यवहार: रनटाइम निष्पादन और
  फ़ाइलसिस्टम सीमा, दोनों की पुष्टि करें। npm डिपेंडेंसियाँ Plugin के
  प्रबंधित npm प्रोजेक्ट के भीतर होइस्ट की जा सकती हैं, इसलिए टेस्ट से यह सिद्ध होना चाहिए कि उस प्रोजेक्ट को स्कैन/साफ़ किया जाता है,
  न कि यह मान लिया जाए कि केवल Plugin पैकेज-स्थानीय `node_modules` ट्री ही मौजूद है।

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

## विफलता ट्रायेज

आर्टिफ़ैक्ट की पहचान से शुरू करें:

- पैकेज स्वीकृति `resolve_package` सारांश: स्रोत, संस्करण, SHA-256 और
  आर्टिफ़ैक्ट का नाम।
- Docker आर्टिफ़ैक्ट: `.artifacts/docker-tests/**/summary.json`,
  `failures.json`, लेन लॉग और दोबारा चलाने के कमांड।
- अपग्रेड सर्वाइवर सारांश: `.artifacts/upgrade-survivor/summary.json`,
  जिसमें बेसलाइन संस्करण, कैंडिडेट संस्करण, परिदृश्य, चरण की अवधियाँ और
  कॉन्फ़िगरेशन रेसिपी कवरेज शामिल हैं।

पूरे रिलीज़ अंब्रेला को दोबारा चलाने के बजाय, उसी पैकेज आर्टिफ़ैक्ट के साथ
ठीक उसी विफल लेन को दोबारा चलाना बेहतर है।