CI पाइपलाइन

OpenClaw CI, main पर पुश होने पर (ट्रिगर पर Markdown और docs/** पाथ अनदेखे किए जाते हैं), प्रत्येक गैर-ड्राफ़्ट पुल रिक्वेस्ट पर और मैन्युअल डिस्पैच पर चलता है। कैनोनिकल main पुश एकल-प्रवाह वाले हैं: CI समवर्ती समूह एक पूर्ण इंटीग्रेशन चक्र को चलने देता है, जबकि GitHub केवल नवीनतम लंबित पुश रखता है। पहले से Blacksmith मैट्रिक्स पंजीकृत कर चुके कार्य को रद्द करने के बजाय, नए मर्ज उस लंबित रन को बदल देते हैं। पुल रिक्वेस्ट अब भी अप्रचलित हेड रद्द करती हैं, और मैन्युअल डिस्पैच पृथक समूहों का उपयोग करते हैं। preflight डिफ़ को वर्गीकृत करता है और केवल असंबंधित क्षेत्रों में बदलाव होने पर महँगी लेन बंद कर देता है। मैन्युअल workflow_dispatch रन जानबूझकर स्मार्ट स्कोपिंग को बायपास करते हैं और रिलीज़ कैंडिडेट तथा व्यापक सत्यापन के लिए पूरे ग्राफ़ में विस्तार करते हैं। Android लेन include_android (या release_gate इनपुट) के माध्यम से ऑप्ट-इन रहती हैं। केवल रिलीज़ वाली plugin कवरेज अलग Plugin Prerelease वर्कफ़्लो में रहती है और केवल Full Release Validation या स्पष्ट मैन्युअल डिस्पैच से चलती है।

पाइपलाइन का अवलोकन

स्वतंत्र Periphery वर्कफ़्लो iOS और macOS ऐप के लिए शून्य डेड-कोड निष्कर्ष लागू करते हैं। साझा OpenClawKit वर्कफ़्लो दोनों उपभोक्ताओं को समानांतर स्कैन करता है और किसी घोषणा की रिपोर्ट केवल तभी करता है, जब Periphery दोनों बिल्ड से समान Swift USR उत्सर्जित करता है। इसके जनरेट किए गए OpenClawProtocol/GatewayModels.swift स्कीमा अनुबंध को ऐप-स्थानीय डेड कोड मानने के बजाय जनरेटर-स्वामित्व वाले कोड के रूप में रखा जाता है।

तेज़ी से विफल होने का क्रम

1. preflight तय करता है कि कौन-सी लेन मौजूद होंगी। docs-scope और changed-scope लॉजिक इस जॉब के भीतर के चरण हैं, स्वतंत्र जॉब नहीं। कैनोनिकल main तुरंत शुरू होता है, लेकिन उसका समवर्ती समूह केवल एक पूर्ण रन को प्रवेश देता है और बाद के पुश को एक नवीनतम लंबित रन में समेकित करता है। Node-संबंधित मुख्य पुश यहाँ एकमात्र निर्भरता-डिस्क राइटर और उसके आकार के अनुरक्षण को भी क्रमबद्ध करते हैं, इससे पहले कि डाउनस्ट्रीम जॉब कुंजी माउंट कर सकें; Blacksmith किसी नए कमिट को केवल बाद के वर्कफ़्लो रन के लिए उपलब्ध करा सकता है, इसलिए उसी रन के उपभोक्ता मार्कर-जाँच वाला स्थानीय फ़ॉलबैक बनाए रखते हैं।
2. security-fast, check-*, check-additional-*, check-docs, और skills-python अधिक भारी आर्टिफ़ैक्ट और प्लेटफ़ॉर्म मैट्रिक्स जॉब की प्रतीक्षा किए बिना जल्दी विफल होते हैं।
3. build-artifacts और लोकेल जाँच तेज़ Linux लेन के साथ ओवरलैप होती हैं। Control UI और नेटिव ऐप स्रोत PR जनरेट किए गए लोकेल स्नैपशॉट/संसाधनों को बाहर रखते हैं; उनके क्रमबद्ध रीफ़्रेश वर्कफ़्लो पृष्ठभूमि में पृथक जनरेट किए गए PR की मरम्मत और स्वचालित मर्ज करते हैं। स्रोत CI अब भी पुराने स्रोत इन्वेंटरी और असुरक्षित स्थानीयकरण कॉल को अवरुद्ध करता है। जनरेट किए गए PR, मैन्युअल CI और रिलीज़ तैयारी पूर्ण अनूदित/प्लेटफ़ॉर्म-जनरेटेड समानता लागू करते हैं। कैनोनिकल release/YYYY.M.PATCH शाखाओं में अन्य जनरेट किए गए रिलीज़ आउटपुट के साथ रिलीज़-तैयारी लोकेल मरम्मत शामिल हो सकती है।
4. इसके बाद अधिक भारी प्लेटफ़ॉर्म और रनटाइम लेन विस्तृत होती हैं: checks-fast-core, checks-fast-contracts-plugins-*, checks-fast-contracts-channels-*, checks-node-*, checks-windows, macos-node, macos-swift, ios-build, और android।
5. openclaw/ci-gate प्रत्येक चयनित लेन की प्रतीक्षा करता है। प्रीफ़्लाइट और सुरक्षा को सफल होना आवश्यक है; डाउनस्ट्रीम जॉब केवल तभी स्किप हो सकते हैं, जब मैनिफ़ेस्ट ने उन्हें नहीं चुना हो। कोई विफल या रद्द की गई चयनित लेन समुच्चय को विफल कर देती है।

मर्ज समन्वयक समान पुल-रिक्वेस्ट हेड के लिए प्रमाणीकृत सफल openclaw/ci-gate का 24 घंटे तक पुनः उपयोग कर सकता है। इससे असंबंधित main बदलावों के बाद योगदानकर्ता शाखा को फिर से लिखने से बचा जाता है। पुनः उपयोग योग्य परिणाम वर्तमान main के विरुद्ध अलग कठोर, ऐप-स्वामित्व वाली परीक्षण-मर्ज जाँच का स्थान नहीं लेता। बाद का लंबित या विफल पुनः रन, ताज़गी अवधि के दौरान उस अपरिवर्तित हेड के पहले के सफल परिणाम को नहीं मिटाता।

डिफ़ॉल्ट-ब्रांच नियम-समूह के लिए GitHub Actions के स्वामित्व वाली openclaw/ci-gate जाँच आवश्यक है। रिपॉज़िटरी अनुरक्षकों और प्रशासकों के पास ऑडिट किया हुआ ब्रेक-ग्लास बायपास है, जो केवल हस्ताक्षरित सीधे फ़ास्ट-फ़ॉरवर्ड लैंडिंग के लिए अभिप्रेत है; संगठन का नियम-समूह अब भी हटाने और नॉन-फ़ास्ट-फ़ॉरवर्ड अपडेट को अवरुद्ध करता है। सामान्य पुल रिक्वेस्ट मर्ज में विफल CI को बायपास करने के बजाय गेट का उपयोग जारी रखना चाहिए। अलग सख्त App-स्वामित्व वाली टेस्ट-मर्ज जाँच अब भी हेड को वर्तमान main से बाँधती है।

कोई नया हेड लैंड होने पर GitHub प्रतिस्थापित पुल रिक्वेस्ट जॉब को cancelled के रूप में चिह्नित कर सकता है। जब तक उसी PR का नवीनतम रन भी विफल न हो, इसे CI का शोर मानें। प्रवेश के बाद कैनोनिकल main रन रद्द नहीं किए जाते; मर्ज ट्रैफ़िक आने पर GitHub केवल पुराने लंबित रन को नवीनतम टिप से बदलता है। मैट्रिक्स जॉब fail-fast: false का उपयोग करते हैं, और build-artifacts छोटे सत्यापनकर्ता जॉब कतार में लगाने के बजाय एम्बेडेड चैनल, कोर-सपोर्ट-बाउंड्री और gateway-watch की विफलताओं की सीधे रिपोर्ट करता है। स्वचालित CI समवर्तीता कुंजी संस्करणबद्ध है (CI-v7-*), ताकि किसी पुराने कतार समूह में GitHub-पक्ष का ज़ॉम्बी नए main रन को अनिश्चित काल तक अवरुद्ध न कर सके। मैन्युअल पूर्ण-सुइट रन CI-manual-v1-* का उपयोग करते हैं और प्रगति में चल रहे रन रद्द नहीं करते। प्लगइन-सूची स्टार्टअप-मेमोरी गार्ड स्व-होस्टेड Blacksmith Linux पर 350 MiB की अधिकतम सीमा रखता है और GitHub-होस्टेड Linux पर 425 MiB की अनुमति देता है, जहाँ उसी बिल्ट CLI के लिए RSS बेसलाइन अधिक है।

GitHub Actions से कुल समय, कतार समय, सबसे धीमे जॉब, विफलताओं और pnpm-store-warmup फ़ैनआउट बैरियर का सारांश देने के लिए pnpm ci:timings, pnpm ci:timings:recent, या node scripts/ci-run-timings.mjs <run-id> का उपयोग करें। वर्कफ़्लो के भीतर ci-timings-summary जॉब ci.yml में मौजूद है, लेकिन अभी अक्षम है (if: false); इसके बजाय टाइमिंग सहायक को स्थानीय रूप से चलाएँ। बिल्ड टाइमिंग के लिए, build-artifacts जॉब का Build dist चरण देखें: pnpm build:ci-artifacts, [build-all] phase timings: प्रिंट करता है और इसमें ui:build शामिल होता है; जॉब startup-memory आर्टिफ़ैक्ट भी अपलोड करता है।

PR संदर्भ और साक्ष्य

बाहरी योगदानकर्ताओं के PR, PR संदर्भ और साक्ष्य गेट को .github/workflows/real-behavior-proof.yml से चलाते हैं। वर्कफ़्लो विश्वसनीय वर्कफ़्लो संशोधन (github.workflow_sha) को चेक आउट करता है और केवल PR बॉडी का मूल्यांकन करता है; यह योगदानकर्ता ब्रांच का कोड निष्पादित नहीं करता।

यह गेट उन PR लेखकों पर लागू होता है जो रिपॉज़िटरी के स्वामी, सदस्य, सहयोगी या बॉट नहीं हैं। PR बॉडी में लेखक द्वारा लिखे गए What Problem This Solves और Evidence अनुभाग होने पर यह पास हो जाता है। साक्ष्य कोई केंद्रित टेस्ट, CI परिणाम, स्क्रीनशॉट, रिकॉर्डिंग, टर्मिनल आउटपुट, लाइव अवलोकन, संपादित लॉग या आर्टिफ़ैक्ट लिंक हो सकता है। बॉडी आशय और उपयोगी सत्यापन प्रदान करती है; समीक्षक शुद्धता का आकलन करने के लिए कोड, टेस्ट और CI का निरीक्षण करते हैं।

जाँच विफल होने पर कोई अन्य कोड कमिट पुश करने के बजाय PR बॉडी अपडेट करें।

दायरा और रूटिंग

दायरा लॉजिक scripts/ci-changed-scope.mjs में है और src/scripts/ci-changed-scope.test.ts में यूनिट टेस्ट द्वारा कवर किया गया है। मैन्युअल डिस्पैच बदले हुए दायरे की पहचान छोड़ देता है और प्रीफ़्लाइट मैनिफ़ेस्ट को ऐसे कार्य कराता है मानो प्रत्येक दायरा-बद्ध क्षेत्र बदल गया हो।

अलग-अलग iOS और macOS Periphery वर्कफ़्लो शून्य-निष्कर्ष वाली डेड-कोड नीति लागू करते हैं। प्रत्येक केवल तभी चलता है जब कोई गैर-ड्राफ़्ट पुल रिक्वेस्ट उसके नेटिव स्कैन दायरे को छूती है, या जब उसे मैन्युअल रूप से डिस्पैच किया जाता है।

• CI वर्कफ़्लो संपादन Node CI ग्राफ़, वर्कफ़्लो लिंटिंग और Windows लेन को सत्यापित करते हैं (ci.yml इसे निष्पादित करता है), लेकिन स्वयं iOS, Android या macOS नेटिव बिल्ड को बाध्य नहीं करते; वे प्लेटफ़ॉर्म लेन प्लेटफ़ॉर्म स्रोत परिवर्तनों तक दायरा-बद्ध रहते हैं।
• वर्कफ़्लो सैनिटी सभी वर्कफ़्लो YAML फ़ाइलों पर actionlint, zizmor, कंपोज़िट-ऐक्शन इंटरपोलेशन गार्ड और कॉन्फ़्लिक्ट-मार्कर गार्ड चलाता है। PR-दायरा-बद्ध security-fast जॉब बदली हुई वर्कफ़्लो फ़ाइलों पर zizmor भी चलाता है, ताकि वर्कफ़्लो सुरक्षा निष्कर्ष मुख्य CI ग्राफ़ में जल्दी विफल हों।
• main पुश पर दस्तावेज़ों की जाँच स्टैंडअलोन Docs वर्कफ़्लो द्वारा CI में उपयोग किए जाने वाले उसी ClawHub दस्तावेज़ मिरर के साथ की जाती है, ताकि मिश्रित कोड+दस्तावेज़ पुश CI check-docs शार्ड को भी कतार में न लगाएँ। दस्तावेज़ बदलने पर पुल रिक्वेस्ट और मैन्युअल CI अब भी CI से check-docs चलाते हैं।
• TUI PTY TUI परिवर्तनों के लिए checks-node-core-runtime-tui-pty Linux Node शार्ड में चलता है। शार्ड OPENCLAW_TUI_PTY_INCLUDE_LOCAL=1 के साथ test/vitest/vitest.tui-pty.config.ts चलाता है, इसलिए यह नियतात्मक TuiBackend फ़िक्स्चर लेन और केवल बाहरी मॉडल एंडपॉइंट को मॉक करने वाले धीमे tui --local स्मोक, दोनों को कवर करता है।
• केवल CI रूटिंग वाले संपादन, कोर-टेस्ट फ़िक्स्चर का छोटा समूह जिसे तेज़ टास्क सीधे चलाता है, और सीमित प्लगइन अनुबंध सहायक संपादन तेज़, केवल-Node मैनिफ़ेस्ट पथ का उपयोग करते हैं: preflight, security-fast, और केवल वे तेज़ लेन जिन्हें परिवर्तन छूता है — एकल checks-fast-core CI-रूटिंग टास्क, दो प्लगइन अनुबंध शार्ड या दोनों। यह पथ बिल्ड आर्टिफ़ैक्ट, Node 22 संगतता, चैनल अनुबंध, पूर्ण कोर शार्ड, बंडल किए गए प्लगइन शार्ड और अतिरिक्त गार्ड मैट्रिक्स छोड़ देता है।
• Windows Node जाँचें Windows-विशिष्ट प्रोसेस/पथ रैपर, npm/pnpm/UI रनर सहायक, पैकेज मैनेजर कॉन्फ़िगरेशन और उस लेन को निष्पादित करने वाली CI वर्कफ़्लो सतहों तक दायरा-बद्ध हैं; असंबंधित स्रोत, प्लगइन, इंस्टॉल-स्मोक और केवल-टेस्ट परिवर्तन Linux Node लेन पर रहते हैं।

सबसे धीमे Node टेस्ट परिवारों को विभाजित या संतुलित किया गया है, ताकि प्रत्येक जॉब रनर को आवश्यकता से अधिक आरक्षित किए बिना छोटा रहे:

• Plugin अनुबंध और चैनल अनुबंध, दोनों मानक GitHub रनर फ़ॉलबैक के साथ दो भारित Blacksmith-समर्थित शार्ड के रूप में चलते हैं।
• कोर यूनिट की तेज़/समर्थन लेन अलग-अलग चलती हैं; कोर रनटाइम इन्फ़्रा प्रक्रिया, साझा, हुक, सीक्रेट और तीन Cron डोमेन शार्ड में विभाजित होता है।
• ऑटो-रिप्लाई संतुलित वर्कर के रूप में चलता है, जिसमें रिप्लाई सबट्री एजेंट-रनर, कमांड, डिस्पैच, सेशन और स्टेट-रूटिंग शार्ड में विभाजित होती है।
• एजेंटिक Gateway/सर्वर (कंट्रोल-प्लेन) कॉन्फ़िगरेशन, निर्मित आर्टिफ़ैक्ट की प्रतीक्षा करने के बजाय चैट, प्रमाणीकरण, मॉडल, HTTP/Plugin, रनटाइम और स्टार्टअप लेन में विभाजित होते हैं।
• सामान्य CI केवल पृथक इन्फ़्रा इन्क्लूड-पैटर्न शार्ड को अधिकतम 64 टेस्ट फ़ाइलों वाले नियतात्मक बंडलों में पैक करता है, जिससे गैर-पृथक कमांड/Cron, स्टेटफ़ुल एजेंट्स-कोर या Gateway/सर्वर सुइट को मर्ज किए बिना Node मैट्रिक्स छोटा होता है। भारी निश्चित सुइट 8 vCPU पर बने रहते हैं, जबकि बंडल की गई और कम भार वाली लेन 4 vCPU का उपयोग करती हैं।
• कैनोनिकल रिपॉज़िटरी पर पुल रिक्वेस्ट, सिंथेटिक मर्ज्ड-ट्री डिफ़ के विरुद्ध बदले हुए टेस्ट रिज़ॉल्वर का पुनः उपयोग करती हैं। सटीक बदलाव एक लक्षित Node जॉब चलाते हैं; हर चयनित टेस्ट फ़ाइल को अपनी प्रक्रिया मिलती है, ताकि स्टेटफ़ुल सुइट का पृथक्करण अक्षुण्ण रहे। प्लानर सिबलिंग टेस्ट को इम्पोर्ट-ग्राफ़ आश्रितों के साथ संयोजित करता है और वर्कस्पेस पैकेज, पैकेज/लॉकफ़ाइल, साझा हार्नेस, स्प्लिट-कॉन्फ़िग, नाम बदले या हटाए गए बदलावों, सार्वजनिक एक्सटेंशन-अनुबंध बदलावों, विशेष शार्ड सेटअप वाले टेस्ट, आंशिक रूप से रिज़ॉल्व किए गए या खाली लक्ष्यों, अत्यधिक बड़े पाथ या लक्ष्य प्लान और प्लानर त्रुटियों के लिए मौजूदा 14-जॉब कॉम्पैक्ट पूर्ण-सुइट प्लान पर फ़ॉलबैक करता है। लक्षित प्लान हमेशा पूर्ण निर्मित-आर्टिफ़ैक्ट सीमा गेट बनाए रखते हैं, क्योंकि उसके रिपॉज़िटरी स्कैनर इम्पोर्ट से व्युत्पन्न नहीं किए जा सकते। main पुश वही पूर्ण कॉम्पैक्ट सुइट चलाते हैं: लंबित मध्यवर्ती पुश इवेंट को एकीकृत किया जा सकता है, इसलिए सबसे नए शेष रन को केवल उसके अंतिम एकल-पुश डिफ़ के बजाय संपूर्ण एकीकरण ट्री को सत्यापित करना आवश्यक है। मैन्युअल डिस्पैच और रिलीज़ गेट पूर्ण नामित प्रति-शार्ड मैट्रिक्स बनाए रखते हैं।
• पूर्ण Node मैट्रिक्स लगातार धीमे सीरियल टूलिंग, ऑटो-रिप्लाई कमांड शार्ड और व्यापक कोर-फ़ास्ट कैश राइटर को पहले प्रवेश देता है। इससे 28-जॉब सीमा बनी रहती है और साथ ही क्रिटिकल-पाथ कार्य तथा अगले रन के ट्रांसफ़ॉर्म सीड को बाद की वेव में खिसकने से रोका जाता है।
• व्यापक ब्राउज़र, QA, मीडिया और विविध Plugin टेस्ट साझा Plugin कैच-ऑल के बजाय अपने समर्पित Vitest कॉन्फ़िगरेशन का उपयोग करते हैं। इन्क्लूड-पैटर्न शार्ड CI शार्ड नाम का उपयोग करके टाइमिंग प्रविष्टियाँ रिकॉर्ड करते हैं, ताकि .artifacts/vitest-shard-timings.json पूरे कॉन्फ़िगरेशन को फ़िल्टर किए गए शार्ड से अलग पहचान सके।
• Linux Node शार्ड जॉब Vitest के प्रायोगिक फ़ाइलसिस्टम मॉड्यूल कैश को अपस्ट्रीम Actions कैश API के माध्यम से बनाए रखते हैं, जिसे Blacksmith अपने रनर पर पारदर्शी रूप से तेज़ करता है। प्रत्येक CI शार्ड केवल-रीस्टोर होता है और संरक्षित सीड को अपने रनर-स्थानीय रूट में अनपैक करता है; फिर शार्ड रैपर समवर्ती Vitest प्रक्रियाओं को अलग-अलग लाइव उपनिर्देशिकाएँ देता है। केवल रद्द न होने वाला दैनिक या स्पष्ट रूप से डिस्पैच किया गया वार्मर नया अपरिवर्तनीय आर्काइव सहेजता है, इसलिए पुल रिक्वेस्ट ट्रांसफ़ॉर्म प्रकाशित नहीं कर सकतीं या प्रति-PR कैश फ़ैमिली नहीं बना सकतीं। ट्रांसफ़ॉर्म-इनपुट फ़िंगरप्रिंट असंगत लॉकफ़ाइल, पैकेज, tsconfig और Vitest-कॉन्फ़िग पीढ़ियों को साफ़ करता है। संरक्षित राइटर अपने रीस्टोर किए गए कैश को 2 GiB से अधिक होने पर स्कैन करके 75% तक प्रून करता है। Vitest मॉड्यूल आईडी, स्रोत सामग्री, एनवायरनमेंट और रिज़ॉल्व किए गए ट्रांसफ़ॉर्म कॉन्फ़िगरेशन का हैश बनाता है, इसलिए सामान्य आंशिक स्रोत बदलाव अपरिवर्तित प्रविष्टियों को वार्म रखते हैं, जबकि बदले हुए मॉड्यूल सुरक्षित रूप से मिस होते हैं। मोटे रीस्टोर प्रीफ़िक्स वर्कफ़्लो रन के बीच सेतु बनाते हैं; सामान्य Actions कैश LRU और निष्क्रियता निष्कासन पुराने अपरिवर्तनीय आर्काइव को सीमित करते हैं।
• विश्वसनीय Linux Node जॉब, प्रत्येक समर्थित Node लाइन के लिए एक संरक्षित डिपेंडेंसी डिस्क से pnpm स्टोर और node_modules को भी बाइंड करते हैं। पैकेज मैनिफ़ेस्ट, इंस्टॉल सेटिंग, रनर प्लेटफ़ॉर्म और सटीक Node पैच डिस्क कुंजी से बाहर रहते हैं; सटीक रनटाइम और इंस्टॉल-इनपुट फ़िंगरप्रिंट तय करता है कि जॉब ट्री का पुनः उपयोग करेगा या पुनः इंस्टॉल करके उसी डिस्क को रीफ़्रेश करेगा। हैशिंग से पहले मैनिफ़ेस्ट को कैनोनिकल बनाया जाता है। ऑडिट किए गए प्रत्यक्ष रूट हुक केवल pnpm की इंस्टॉल लाइफ़साइकल स्क्रिप्ट बनाए रखते हैं, इसलिए फ़ॉर्मैटिंग और सामान्य टेस्ट/बिल्ड स्क्रिप्ट संपादन डिपेंडेंसी ट्री को वार्म रखते हैं; बिना ऑडिट वाली लाइफ़साइकल-हुक ड्रिफ़्ट तब तक फ़ेल-क्लोज़ होती है, जब तक उसके स्रोत इनपुट फ़िंगरप्रिंट अनुबंध में शामिल नहीं हो जाते। डिपेंडेंसी, पैकेज-मैनेजर, हुक-स्रोत और लॉकफ़ाइल बदलाव हमेशा स्नैपशॉट को अमान्य करते हैं। मिलता हुआ फ़िंगरप्रिंट आवश्यक है, लेकिन पर्याप्त नहीं: सेटअप इम्पोर्टर आर्काइव और मैनिफ़ेस्ट चेकसम भी जाँचता है, फिर postinstall द्वारा बनाए रखी गई रजिस्ट्री-समर्थित लॉकफ़ाइल डिपेंडेंसी को उन पैकेज मैनिफ़ेस्ट के विरुद्ध सत्यापित करता है जिन्हें Node उनके इम्पोर्टर से रिज़ॉल्व करता है। अनुपस्थित या पुरानी इम्पोर्टर सामग्री रूट होइस्ट प्रदान करने के बजाय नए इंस्टॉल पर फ़ॉलबैक करती है। ऐसी पुल रिक्वेस्ट जिसका केवल-पढ़ने योग्य स्नैपशॉट अनुपयोगी है, वर्कस्पेस बाइंड को अलग करके रनर-स्थानीय स्टोरेज में इंस्टॉल करती है, जिससे ऐसे क्लोन पर धीमी राइट से बचा जाता है जिसे वह प्रकाशित नहीं कर सकती। स्टिकी कोल्ड इंस्टॉल pnpm के आंतरिक फ़ेच पुनःप्रयास अक्षम करते हैं और क्रमशः वार्म होते स्टोर से अधिकतम तीन सीमित पूर्ण-इंस्टॉल प्रयास करते हैं; टाइमआउट फिर भी विफलता रहता है। सामग्री-सत्यापित रीस्टोर या फ़्रोज़न-लॉकफ़ाइल इंस्टॉल के बाद, सेटअप pnpm की अनावश्यक प्री-रन डिपेंडेंसी जाँच अक्षम करता है: रिपॉज़िटरी जानबूझकर Plugin-स्थानीय node_modules को प्रून करती है, जिसे pnpm अन्यथा पुराना मानकर शार्ड फ़ैनआउट के दौरान असुरक्षित समवर्ती निहित इंस्टॉल के माध्यम से सुधारता है। कैनोनिकल main प्रीफ़्लाइट एकमात्र राइटर है और प्रत्येक रीफ़्रेश पर स्टोर को मापता है तथा सेवानिवृत्त पैकेज संस्करणों द्वारा इसे 8 GiB से ऊपर धकेलने के बाद ही pnpm store prune चलाता है। राइटर जॉब पूरा होने के बाद भी Blacksmith स्नैपशॉट प्रकाशन असिंक्रोनस होता है, इसलिए नई कुंजी या फ़िंगरप्रिंट के बाद पहला रन कोल्ड रह सकता है; बाद के सामग्री-सत्यापित सटीक-मार्कर रीस्टोर रोलआउट का प्रमाण हैं। आवश्यक CI जॉब और पुल रिक्वेस्ट को डिस्पोज़ेबल क्लोन मिलते हैं, इसलिए डिपेंडेंसी बदलाव नई डिस्क, प्रतिस्पर्धी स्नैपशॉट या बिल्ड रद्द कर सकने वाला कैश लॉक नहीं बनाते।
• Node शार्ड और बिल्ड-आर्टिफ़ैक्ट जॉब अपरिवर्तनीय Actions कैश के माध्यम से Node के पोर्टेबल ऑन-डिस्क कम्पाइल कैश को भी रीस्टोर करते हैं। स्वतंत्र test और build नेमस्पेस उनके राइटर को एक-दूसरे के आर्काइव बदलने से रोकते हैं: शेड्यूल किया गया टेस्ट वार्मर संरक्षित टेस्ट सीड का स्वामी है, जबकि build-artifacts विश्वसनीय main पुश से प्रति UTC दिन अधिकतम एक संरक्षित बिल्ड आर्काइव प्रकाशित कर सकता है। PR और सामान्य टेस्ट जॉब केवल संरक्षित स्नैपशॉट पढ़ते हैं, इसलिए फ़ीचर-ब्रांच बाइटकोड कभी साझा सीड में प्रवेश नहीं करता और PR ट्रैफ़िक कोई कैश आर्काइव नहीं बनाता। यह अलग-अलग चेकआउट पाथ में Node द्वारा लोड किए गए ऑर्केस्ट्रेशन, बिल्ड टूलिंग और बाहरी डिपेंडेंसी के लिए V8 बाइटकोड का पुनः उपयोग करता है, जिसमें स्रोत ग्राफ़ का केवल कुछ भाग बदलने की स्थिति भी शामिल है। Vitest चाइल्ड प्रक्रियाएँ विरासत में मिले कम्पाइल कैश को अक्षम करती हैं, क्योंकि डायनेमिक कॉन्फ़िगरेशन के भीतर कवरेज सक्षम किया जा सकता है और बाइटकोड से स्क्रिप्ट डीसीरियलाइज़ होने पर V8 कवरेज स्रोत-स्थिति की सटीकता खो सकती है।
• बिल्ड-आर्टिफ़ैक्ट जॉब सामग्री-फ़िंगरप्रिंट किए गए build-all चरण आउटपुट को भी बनाए रखता है। CI की स्वयं निर्मित Plugin SDK घोषणाएँ रिपॉज़िटरी-स्वामित्व वाले संपूर्ण TypeScript/JSON स्रोत ग्राफ़ का हैश बनाती हैं, इंस्टॉल की गई और जनरेट की गई निर्देशिकाओं को बाहर रखती हैं और tsdown द्वारा dist साफ़ करने के बाद फ़्लैट घोषणाओं तथा पैकेज ब्रिज, दोनों को रीस्टोर करती हैं। उस ग्राफ़ के बाहर के दस्तावेज़, वर्कफ़्लो, Plugin और अन्य बदलाव घोषणा स्नैपशॉट का पुनः उपयोग कर सकते हैं; स्रोत बदलाव एक्सपोर्ट गेट चलने से पहले इसका पुनर्निर्माण करते हैं।
• पूर्ण घोषणा बिल्ड tsdown को AI, वर्कस्पेस-पैकेज और एकीकृत समूहों में विभाजित करते हैं। प्रत्येक समूह केवल घोषणाओं को कैश करता है, फिर भी उन घोषणाओं को रीस्टोर करने से पहले रनटाइम JavaScript का पुनर्निर्माण करता है। इसलिए कोर या Plugin बदलाव केवल बड़े एकीकृत ग्राफ़ को अमान्य करते हैं, जबकि वर्कस्पेस-पैकेज बदलाव सावधानीपूर्वक प्रत्येक आश्रित घोषणा समूह को अमान्य करते हैं। सार्वजनिक पूर्ण बिल्ड सामान्यतः अपरिवर्तनीय Actions कैश का उपयोग करते हैं; मोटी रीस्टोर कुंजियाँ आंशिक बदलावों को सीड करती हैं, प्रति-समूह सामग्री फ़िंगरप्रिंट पुराने डेटा को अस्वीकार करते हैं और GitHub का कैश कोटा पुरानी पीढ़ियों को निष्कासित करता है। इसके बजाय साप्ताहिक Node 22 लेन सफल main रन के बाद 14-दिन का आर्टिफ़ैक्ट प्रकाशित करती है और केवल उन्हीं आर्टिफ़ैक्ट को रीस्टोर करती है जिनकी अपरिवर्तनीय निर्माता पहचान main पर उस वर्कफ़्लो में रिज़ॉल्व होती है, जिससे PR कोड को साझा कैश में लिखने की अनुमति दिए बिना कोटा चर्न से बचा जाता है। निजी-QA घोषणाएँ Actions कैश में कभी बनाए नहीं रखी जातीं, क्योंकि कैश नेमस्पेस गोपनीयता सीमाएँ नहीं हैं।
• check-additional-* पूरक सीमा गार्ड सूची (scripts/run-additional-boundary-checks.mjs) को एक प्रॉम्प्ट-भारी शार्ड (check-additional-boundaries-a, जिसमें Codex प्रॉम्प्ट स्नैपशॉट ड्रिफ़्ट जाँच शामिल है) और शेष स्ट्राइप के लिए एक संयुक्त शार्ड (check-additional-boundaries-bcd) में बाँटता है; प्रत्येक स्वतंत्र गार्ड को समवर्ती रूप से चलाता है और प्रति-जाँच टाइमिंग प्रिंट करता है। पैकेज-सीमा कम्पाइल/कैनरी कार्य साथ रहता है और रनटाइम टोपोलॉजी आर्किटेक्चर, build-artifacts में अंतर्निहित Gateway वॉच कवरेज से अलग चलता है।
• 32-vCPU स्व-होस्टेड बिल्ड रनर पर, dist/ और dist-runtime/ के पहले ही बन जाने के बाद Gateway वॉच, चैनल टेस्ट और कोर समर्थन-सीमा शार्ड build-artifacts के भीतर एक साथ शुरू होते हैं। GitHub-होस्टेड फ़ॉलबैक रन Gateway वॉच को सीरियल रखते हैं, ताकि कम-कोर प्रतिस्पर्धा उसकी तत्परता समय-सीमा का उपभोग न कर सके।

प्रवेश मिलने के बाद, कैनोनिकल Linux CI अधिकतम 28 समवर्ती Node टेस्ट जॉब और छोटी तेज़/जाँच लेन के लिए 12 जॉब की अनुमति देता है; Windows और Android दो पर बने रहते हैं क्योंकि वे रनर पूल अधिक सीमित हैं। कॉम्पैक्ट संपूर्ण-कॉन्फ़िगरेशन बैच 120-मिनट के बैच टाइमआउट के साथ चलते हैं, जबकि इन्क्लूड-पैटर्न समूह समान सीमित जॉब बजट साझा करते हैं।

Android CI testPlayDebugUnitTest और testThirdPartyDebugUnitTest, दोनों चलाता है और फिर Play डीबग APK बनाता है। तृतीय-पक्ष फ़्लेवर का कोई अलग स्रोत सेट या मैनिफ़ेस्ट नहीं है; उसकी यूनिट-टेस्ट लेन फिर भी SMS/कॉल-लॉग BuildConfig फ़्लैग के साथ फ़्लेवर को कम्पाइल करती है, जबकि प्रत्येक Android-संबंधित पुश पर डुप्लिकेट डीबग APK पैकेजिंग जॉब से बचती है। प्रत्येक वर्तमान Gradle टास्क की एक संरक्षित स्टिकी डिस्क होती है; PR जॉब डिस्पोज़ेबल क्लोन का उपयोग करते हैं, जबकि संरक्षित रन सामग्री-एड्रेस्ड Gradle प्रविष्टियों को यथास्थान रीफ़्रेश करते हैं।

Blacksmith स्टिकी-डिस्क कुंजियाँ जानबूझकर समर्थित रनटाइम या टास्क आयामों तक सीमित होती हैं, PR संख्या, कमिट, रन, ब्रांच या डिपेंडेंसी हैश तक कभी नहीं। रनटाइम ट्रांसफ़ॉर्म और कम्पाइल कैश स्टिकी डिस्क के बजाय Actions कैश का उपयोग करते हैं, क्योंकि अपरिवर्तनीय आर्काइव सत्यापनीय रीस्टोर/सेव परिणाम दिखाते हैं और परिवर्तनशील स्नैपशॉट-प्रमोशन विफलताओं से बचते हैं। स्टिकी कुंजी-संस्करण माइग्रेशन के बाद, .github/retired-sticky-disks.json में केवल सटीक अप्रचलित कुंजी, आर्किटेक्चर और क्षेत्र पहचान जोड़ें, समान आयामों और पुष्टि के साथ main से Sticky Disk Cleanup डिस्पैच करें, हटाना सत्यापित करें, फिर उन प्रविष्टियों को हटा दें। वर्कफ़्लो ARM पहचानों को ARM रनर पर रूट करता है, रनर-क्षेत्र बेमेल को अस्वीकार करता है, Blacksmith की सटीक-कुंजी हटाने वाली कार्रवाई का उपयोग करता है और Docker बिल्डर कैश या वाइल्डकार्ड प्रीफ़िक्स कभी नहीं हटाता। Actions कैश आर्काइव सामान्य LRU और निष्क्रियता निष्कासन का उपयोग करते हैं।

check-dependencies शार्ड प्रोडक्शन Knip डिपेंडेंसी, अप्रयुक्त-फ़ाइल और अप्रयुक्त-एक्सपोर्ट जाँच चलाता है। अप्रयुक्त-फ़ाइल गार्ड तब विफल होता है जब कोई PR नई असमीक्षित अप्रयुक्त फ़ाइल जोड़ता है या पुरानी अलाउलिस्ट प्रविष्टि छोड़ देता है, जबकि जानबूझकर रखे गए डायनेमिक Plugin, जनरेट किए गए, बिल्ड, लाइव-टेस्ट और पैकेज ब्रिज सतहों को संरक्षित रखता है जिन्हें Knip स्थिर रूप से रिज़ॉल्व नहीं कर सकता। अप्रयुक्त-एक्सपोर्ट गार्ड टेस्ट-समर्थन फ़ाइलों को बाहर रखता है और प्रत्येक अप्रयुक्त प्रोडक्शन एक्सपोर्ट पर विफल होता है; जानबूझकर रखे गए डायनेमिक उपभोक्ताओं को config/knip.config.ts में मॉडल किया जाना आवश्यक है। ऐतिहासिक लक्ष्य उपलब्ध होने पर एक्सपोर्ट गार्ड चलाते हैं और अन्यथा अपना पुराना डेड-कोड फ़ॉलबैक बनाए रखते हैं।

ClawSweeper गतिविधि अग्रेषण

.github/workflows/clawsweeper-dispatch.yml OpenClaw रिपॉज़िटरी गतिविधि से ClawSweeper तक लक्ष्य-पक्षीय सेतु है। यह अविश्वसनीय पुल रिक्वेस्ट कोड को चेक आउट या निष्पादित नहीं करता। वर्कफ़्लो CLAWSWEEPER_APP_PRIVATE_KEY से GitHub App टोकन बनाता है, फिर संक्षिप्त repository_dispatch पेलोड को openclaw/clawsweeper पर डिस्पैच करता है।

वर्कफ़्लो में चार लेन हैं:

• clawsweeper_item सटीक इश्यू और पुल रिक्वेस्ट समीक्षा अनुरोधों के लिए;
• clawsweeper_comment इश्यू टिप्पणियों में स्पष्ट ClawSweeper कमांड के लिए;
• clawsweeper_commit_review main पुश पर कमिट-स्तरीय समीक्षा अनुरोधों के लिए;
• github_activity सामान्य GitHub गतिविधि के लिए, जिसका ClawSweeper एजेंट निरीक्षण कर सकता है।

github_activity लेन केवल सामान्यीकृत मेटाडेटा अग्रेषित करती है: इवेंट प्रकार, कार्रवाई, कर्ता, रिपॉज़िटरी, आइटम संख्या, URL, शीर्षक, स्थिति और, उपलब्ध होने पर, टिप्पणियों या समीक्षाओं के छोटे अंश। यह जानबूझकर पूरा Webhook बॉडी अग्रेषित नहीं करती। openclaw/clawsweeper में प्राप्तकर्ता वर्कफ़्लो .github/workflows/github-activity.yml है, जो सामान्यीकृत इवेंट को ClawSweeper एजेंट के लिए OpenClaw Gateway हुक पर पोस्ट करता है।

सामान्य गतिविधि अवलोकन है, डिफ़ॉल्ट रूप से डिलीवरी नहीं। ClawSweeper एजेंट को उसके प्रॉम्प्ट में Discord लक्ष्य मिलता है और उसे #clawsweeper पर केवल तभी पोस्ट करना चाहिए, जब इवेंट अप्रत्याशित, कार्रवाई योग्य, जोखिमपूर्ण या संचालन की दृष्टि से उपयोगी हो। नियमित रूप से खोले या संपादित किए गए आइटम, बॉट गतिविधि, डुप्लिकेट Webhook शोर और सामान्य समीक्षा ट्रैफ़िक का परिणाम NO_REPLY होना चाहिए।

इस पूरे पथ में GitHub शीर्षकों, टिप्पणियों, बॉडी, समीक्षा टेक्स्ट, ब्रांच नामों और कमिट संदेशों को अविश्वसनीय डेटा मानें। वे संक्षेपण और ट्राइएज के लिए इनपुट हैं, वर्कफ़्लो या एजेंट रनटाइम के लिए निर्देश नहीं।

मैन्युअल डिस्पैच

मैन्युअल CI डिस्पैच सामान्य CI के समान जॉब ग्राफ़ चलाते हैं, लेकिन Android के दायरे से बाहर की प्रत्येक लेन को बलपूर्वक चालू करते हैं: Linux Node शार्ड, बंडल किए गए Plugin शार्ड, Plugin और चैनल अनुबंध शार्ड, Node 22 संगतता, check-*, check-additional-*, निर्मित आर्टिफ़ैक्ट स्मोक जाँच, दस्तावेज़ जाँच, Python Skills, Windows, macOS, iOS बिल्ड और Control UI/नेटिव ऐप i18n। स्वचालित स्रोत PR, उसी PR में अनुवादित या प्लेटफ़ॉर्म-जनित आउटपुट की आवश्यकता के बिना, नेटिव निष्कर्षण इन्वेंटरी और Android/Apple स्थानीयकरण सुरक्षा सत्यापित करते हैं। क्रमबद्ध Native App Locale Refresh वर्कफ़्लो उन आर्टिफ़ैक्ट को एक पृथक PR में फिर से बनाता है और आवश्यक जाँच पास होने के बाद सटीक हेड के स्वतः मर्ज को सक्षम करता है। जनित-आर्टिफ़ैक्ट PR, मैन्युअल CI, Full Release Validation और रिलीज़ तैयारी के लिए पूर्ण नेटिव समानता अवरोधक बनी रहती है। स्वचालित PR और main रन पर Control UI लोकेल समानता परामर्शात्मक और मैन्युअल/रिलीज़ CI पर अवरोधक बनी रहती है। स्टैंडअलोन मैन्युअल CI डिस्पैच Android को केवल include_android=true के साथ चलाते हैं (release_gate इनपुट भी Android को बलपूर्वक चालू करता है); पूर्ण रिलीज़ अम्ब्रेला include_android=true पास करके Android को सक्षम करता है। Plugin प्रीरिलीज़ स्थैतिक जाँच, केवल रिलीज़ वाला agentic-plugins शार्ड, पूर्ण एक्सटेंशन बैच स्वीप और Plugin प्रीरिलीज़ Docker लेन CI से बाहर रखे गए हैं। Docker प्रीरिलीज़ सूट केवल तभी चलता है, जब Full Release Validation रिलीज़-सत्यापन गेट सक्षम करके अलग Plugin Prerelease वर्कफ़्लो डिस्पैच करता है।

PR अधिकतम-पंक्ति जाँच चेक आउट किए गए सिंथेटिक मर्ज ट्री से बेसलाइन प्राप्त करती है और इवेंट हेड के विरुद्ध उसके हेड पैरेंट को सत्यापित करती है। मैन्युअल रन एक अद्वितीय समवर्ती समूह का उपयोग करते हैं, ताकि रिलीज़-कैंडिडेट का पूर्ण सूट उसी रेफ़ पर किसी अन्य पुश या PR रन द्वारा रद्द न हो। वैकल्पिक target_ref इनपुट विश्वसनीय कॉलर को चयनित डिस्पैच रेफ़ की वर्कफ़्लो फ़ाइल का उपयोग करते हुए किसी ब्रांच, टैग या पूर्ण कमिट SHA के विरुद्ध वह ग्राफ़ चलाने देता है; अधिकतम-पंक्ति बेसलाइन की तुलना उस रन के लिए निर्धारित डिफ़ॉल्ट-ब्रांच हेड के विरुद्ध लक्ष्य के मर्ज बेस से की जाती है। release_gate इनपुट क्षमता के कारण रुके PR CI के लिए सटीक-SHA मेंटेनर फ़ॉलबैक है: इसके लिए आवश्यक है कि target_ref एक पूर्ण कमिट SHA हो, जो डिस्पैच की गई ब्रांच के हेड से मेल खाता हो, और pull_request_number उस खुले PR की पहचान करे जिसके मर्ज ट्री को सत्यापित किया जाता है।

gh workflow run ci.yml --ref release/YYYY.M.PATCHgh workflow run ci.yml --ref main -f target_ref=<branch-or-sha> -f include_android=truegh workflow run full-release-validation.yml --ref main -f ref=<branch-or-sha>

Gateway extended-stable, extended-stable/YYYY.M.33 से npm प्रीफ़्लाइट, Full Release Validation और Plugin npm रिलीज़ चलाता है; कोर प्रकाशन उन तीन रन ID और सत्यापन प्रयास का उपयोग करता है। release-ci/* प्रमाण अमान्य है क्योंकि प्रकाशन प्रत्येक रन को कैनोनिकल ब्रांच और रिलीज़ SHA से बाँधता है। टैग Gateway इमेज और केवल extended-stable* उपनाम प्रकाशित करता है; यह पथ नियमित ऑर्केस्ट्रेटर और उसकी ClawHub, नेटिव ऐप, GitHub Release, वेबसाइट और निजी dist-tag सतहों को छोड़ देता है। कमांड और पुनर्प्राप्ति के लिए मासिक Gateway extended-stable प्रकाशन देखें।

रनर

रनर पंजीकरण बजट

OpenClaw की वर्तमान GitHub रनर-पंजीकरण बकेट ghx api rate_limit में प्रति 5 मिनट 10,000 स्व-होस्टेड रनर पंजीकरण रिपोर्ट करती है। प्रत्येक ट्यूनिंग चरण से पहले actions_runner_registration की फिर से जाँच करें, क्योंकि GitHub इस बकेट को बदल सकता है। सीमा openclaw संगठन के सभी Blacksmith रनर पंजीकरणों द्वारा साझा की जाती है, इसलिए एक और Blacksmith इंस्टॉलेशन जोड़ने से नई बकेट नहीं जुड़ती।

बर्स्ट नियंत्रण के लिए Blacksmith लेबल को दुर्लभ संसाधन मानें। जो जॉब केवल रूटिंग, सूचना, संक्षेपण, शार्ड चयन या छोटे CodeQL स्कैन चलाते हैं, उन्हें GitHub-होस्टेड रनर पर रहना चाहिए, जब तक कि उनके लिए मापी गई Blacksmith-विशिष्ट आवश्यकताएँ न हों। किसी भी नए Blacksmith मैट्रिक्स, बड़े max-parallel या उच्च-आवृत्ति वाले वर्कफ़्लो को अपनी सबसे खराब स्थिति की पंजीकरण संख्या दिखानी होगी और संगठन-स्तरीय लक्ष्य को सक्रिय बकेट के लगभग 60% से नीचे रखना होगा। वर्तमान 10,000-पंजीकरण बकेट के साथ, इसका अर्थ 6,000-पंजीकरण संचालन लक्ष्य है, जो समवर्ती रिपॉज़िटरी, पुनः प्रयास और बर्स्ट ओवरलैप के लिए अतिरिक्त क्षमता छोड़ता है।

परिवर्तित-लक्ष्य PR योजना सामान्य Node परीक्षण बर्स्ट को 14 Blacksmith पंजीकरणों से घटाकर एक कर देती है। व्यापक-जोखिम वाले PR 14-पंजीकरण वाला संक्षिप्त फ़ॉलबैक बनाए रखते हैं, इसलिए सबसे खराब स्थिति नहीं बढ़ती।

कैनोनिकल-रिपॉज़िटरी CI सामान्य पुश और पुल रिक्वेस्ट रन के लिए Blacksmith को डिफ़ॉल्ट रनर पथ बनाए रखती है। workflow_dispatch और गैर-कैनोनिकल रिपॉज़िटरी रन GitHub-होस्टेड रनर का उपयोग करते हैं, लेकिन सामान्य कैनोनिकल रन वर्तमान में Blacksmith कतार की स्थिति की जाँच नहीं करते या Blacksmith अनुपलब्ध होने पर स्वचालित रूप से GitHub-होस्टेड लेबल पर फ़ॉलबैक नहीं करते।

सतह रैचेट

दो केवल-संकुचन बजट कॉन्फ़िगरेशन सतह की रक्षा करते हैं। दोनों वृद्धि होने पर CI को विफल करते हैं, जब तक उसी PR में बजट फ़ाइल को सोच-समझकर अपडेट न किया जाए, और जब सफ़ाई वास्तविक संख्या घटाती है तो दोनों रैचेट-डाउन की माँग करते हैं।

• config/env-var-count-budget.txt, src/, packages/ और extensions/ के अंतर्गत उत्पादन स्रोत में अलग-अलग OPENCLAW_* नामों की संख्या सीमित करता है (परीक्षण और QA Lab शामिल नहीं)। इसकी जाँच node scripts/check-env-var-count.mjs करता है। एनवायरनमेंट वेरिएबल हटाते समय: उसी PR में संख्या घटाएँ। एक जोड़ना कॉन्फ़िगरेशन-सतह संबंधी निर्णय है — PR बॉडी में इसका औचित्य दें।
• docs/.generated/config-baseline.counts.json, प्रत्येक प्रकार (कोर/चैनल/Plugin) के openclaw.json स्कीमा प्रविष्टि की संख्या सीमित करता है। इसकी जाँच pnpm config:docs:check करता है; किसी भी स्कीमा परिवर्तन के बाद pnpm config:docs:gen के साथ फिर से जनरेट करें।

स्थानीय समकक्ष

pnpm changed:lanes                            # origin/main...HEAD के लिए स्थानीय changed-lane classifier का निरीक्षण करेंpnpm check:changed                            # स्मार्ट स्थानीय जाँच गेट: सीमा लेन के अनुसार बदली हुई फ़ॉर्मैटिंग/typecheck/lint/guardspnpm check                                    # तेज़ स्थानीय गेट: prod tsgo + sharded lint + समानांतर तेज़ guardspnpm check:test-typespnpm check:timed                              # प्रत्येक चरण के समय सहित वही गेटpnpm build:strict-smokepnpm check:architecturepnpm test:gateway:watch-regressionOPENCLAW_TUI_PTY_INCLUDE_LOCAL=1 node scripts/run-vitest.mjs run --config test/vitest/vitest.tui-pty.config.tspnpm test                                     # vitest परीक्षणpnpm test:changed                             # कम लागत वाले स्मार्ट बदले हुए Vitest लक्ष्यpnpm test:ui                                  # Control UI यूनिट/ब्राउज़र सुइटpnpm ui:i18n:check                            # जनरेट की गई Control UI लोकेल समानता (रिलीज़ गेट)pnpm native:i18n:baseline                     # स्रोत-स्वामित्व वाली नेटिव निष्कर्षण इन्वेंट्री अपडेट करेंpnpm native:i18n:verify                       # स्रोत इन्वेंट्री + Android/Apple स्थानीयकरण सुरक्षाpnpm native:i18n:check                        # सख्त अनुवादित/प्लेटफ़ॉर्म-जनरेटेड समानता (रिलीज़ गेट)pnpm test:channelspnpm test:contracts:channelspnpm check:docs                               # दस्तावेज़ फ़ॉर्मैट + lint + टूटे हुए लिंकpnpm build                                    # जब CI आर्टिफ़ैक्ट/स्मोक जाँच महत्वपूर्ण हों, तब dist बिल्ड करेंpnpm ios:build                                # iOS ऐप प्रोजेक्ट जनरेट और बिल्ड करेंpnpm ci:timings                               # नवीनतम origin/main push CI रन का सारांश देंpnpm ci:timings:recent                        # हाल के सफल main CI रन की तुलना करेंnode scripts/ci-run-timings.mjs <run-id>      # कुल समय, कतार समय और सबसे धीमे जॉब का सारांश देंnode scripts/ci-run-timings.mjs --latest-main # issue/comment शोर को अनदेखा करें और origin/main push CI चुनेंnode scripts/ci-run-timings.mjs --recent 10   # हाल के सफल main CI रन की तुलना करेंpnpm test:perf:groups --full-suite --allow-failures --output .artifacts/test-perf/baseline-before.jsonpnpm test:perf:groups:compare .artifacts/test-perf/baseline-before.json .artifacts/test-perf/after-agent.jsonpnpm test:startup:memorypnpm test:extensions:memory -- --json .artifacts/openclaw-performance/source/mock-provider/extension-memory.jsonpnpm perf:kova:summary --report .artifacts/kova/reports/mock-provider/report.json --output .artifacts/kova/summary.md

OpenClaw प्रदर्शन

OpenClaw Performance उत्पाद/रनटाइम प्रदर्शन कार्यप्रवाह है। यह main पर प्रतिदिन चलता है और इसे मैन्युअल रूप से डिस्पैच किया जा सकता है:

gh workflow run openclaw-performance.yml --ref main -f profile=diagnostic -f repeat=3gh workflow run openclaw-performance.yml --ref main -f profile=smoke -f repeat=1 -f deep_profile=true -f live_openai_candidate=truegh workflow run openclaw-performance.yml --ref main -f target_ref=v2026.5.2 -f profile=diagnostic -f repeat=3

मैन्युअल डिस्पैच सामान्यतः कार्यप्रवाह ref का बेंचमार्क करता है। वर्तमान कार्यप्रवाह कार्यान्वयन के साथ किसी रिलीज़ टैग या दूसरी ब्रांच का बेंचमार्क करने के लिए target_ref सेट करें। प्रकाशित रिपोर्ट पथ और नवीनतम पॉइंटर परीक्षण किए गए ref के आधार पर कुंजीबद्ध होते हैं, और प्रत्येक index.md परीक्षण किए गए ref/SHA, कार्यप्रवाह ref/SHA, Kova ref, प्रोफ़ाइल, लेन प्रमाणीकरण मोड, मॉडल, पुनरावृत्ति संख्या और परिदृश्य फ़िल्टर रिकॉर्ड करता है।

कार्यप्रवाह पिन की गई रिलीज़ से OCM और पिन किए गए kova_ref इनपुट पर openclaw/Kova से Kova इंस्टॉल करता है, फिर तीन लेन चलाता है:

• mock-provider: नियतात्मक नकली OpenAI-संगत प्रमाणीकरण वाले स्थानीय-बिल्ड रनटाइम पर Kova निदान परिदृश्य।
• mock-deep-profile: स्टार्टअप, Gateway और एजेंट-टर्न हॉटस्पॉट के लिए CPU/हीप/ट्रेस प्रोफ़ाइलिंग। शेड्यूल पर या deep_profile=true के साथ डिस्पैच करने पर चलता है।
• live-openai-candidate: एक वास्तविक OpenAI openai/gpt-5.6-luna एजेंट टर्न, जिसे OPENAI_API_KEY अनुपलब्ध होने पर छोड़ दिया जाता है। शेड्यूल पर या live_openai_candidate=true के साथ डिस्पैच करने पर चलता है।

mock-provider लेन Kova पास के बाद OpenClaw-नेटिव स्रोत प्रोब भी चलाती है: डिफ़ॉल्ट, छोड़े गए चैनल, आंतरिक हुक और पचास-Plugin स्टार्टअप मामलों में Gateway बूट समय और मेमोरी; बंडल किए गए Plugin आयात RSS, दोहराए गए नकली-OpenAI channel-chat-baseline hello लूप, बूट किए गए Gateway पर CLI स्टार्टअप कमांड और SQLite स्थिति स्मोक प्रदर्शन प्रोब। जब परीक्षण किए गए ref के लिए पिछली प्रकाशित mock-provider स्रोत रिपोर्ट उपलब्ध होती है, तो स्रोत सारांश वर्तमान RSS और हीप मानों की उस बेसलाइन से तुलना करता है और RSS में बड़ी वृद्धि को watch के रूप में चिह्नित करता है। स्रोत प्रोब Markdown सारांश रिपोर्ट बंडल में source/index.md पर होता है और उसके पास रॉ JSON रहता है।

प्रत्येक लेन अपना पूरा GitHub आर्टिफ़ैक्ट अपलोड करती है, जिसमें CPU, हीप, ट्रेस और संपीड़ित निदान बंडल शामिल होते हैं। एक अलग प्रकाशक जॉब उन आर्टिफ़ैक्ट को डाउनलोड और सत्यापित करता है, फिर केवल openclaw/clawgrit-reports सामग्री तक सीमित अल्पकालिक ClawSweeper GitHub App टोकन बनाता है और उसे केवल Git push चरण को देता है। यह report.json, report.md, index.md, स्रोत-प्रोब आर्टिफ़ैक्ट और बंडल मेटाडेटा/चेकसम को openclaw-performance/<tested-ref>/<run-id>-<attempt>/<lane>/ के अंतर्गत कमिट करता है; पूरा निदान संग्रह लिंक किए गए Actions आर्टिफ़ैक्ट में रहता है। प्रकाशक push का प्रयास करने से पहले 50 MB से बड़ी किसी भी रिपोर्ट फ़ाइल को अस्वीकार करता है। वर्तमान परीक्षण-ref पॉइंटर openclaw-performance/<tested-ref>/latest-<lane>.json है। यदि ऐप-टोकन निर्माण या रिपोर्ट प्रकाशन विफल होता है, तो शेड्यूल किए गए रन और profile=release डिस्पैच विफल हो जाते हैं। मैन्युअल गैर-रिलीज़ डिस्पैच प्रकाशन को परामर्शात्मक रखते हैं और प्रमाणीकरण या प्रकाशन विफल होने पर GitHub आर्टिफ़ैक्ट बनाए रखते हैं। पिछली स्रोत बेसलाइन सार्वजनिक रिपोर्ट रिपॉज़िटरी से अनाम रूप से प्राप्त की जाती है, इसलिए बेसलाइन का सफल प्राप्त होना प्रकाशक प्रमाणीकरण सिद्ध नहीं करता।

पूर्ण रिलीज़ सत्यापन

Full Release Validation "रिलीज़ से पहले सब कुछ चलाएँ" के लिए मैन्युअल व्यापक कार्यप्रवाह है। यह किसी ब्रांच, टैग या पूर्ण कमिट SHA को स्वीकार करता है, उस लक्ष्य के साथ मैन्युअल CI कार्यप्रवाह (Android सहित) डिस्पैच करता है, केवल-रिलीज़ Plugin/पैकेज/स्थैतिक/Docker प्रमाण के लिए Plugin Prerelease डिस्पैच करता है, लक्ष्य SHA पर OpenClaw Performance डिस्पैच करता है और इंस्टॉल स्मोक, पैकेज स्वीकृति, क्रॉस-OS पैकेज जाँच, QA Lab समानता, Matrix, Telegram तथा गेट की गई Discord, WhatsApp और Slack लेन के लिए OpenClaw Release Checks डिस्पैच करता है (परामर्शात्मक परिपक्वता स्कोरकार्ड रेंडरिंग को run_maturity_scorecard के माध्यम से वैकल्पिक रूप से चुना जाता है)। स्थिर और पूर्ण प्रोफ़ाइल में हमेशा विस्तृत लाइव/E2E और Docker रिलीज़-पथ सोक कवरेज शामिल होता है; बीटा प्रोफ़ाइल इसे run_release_soak=true के साथ वैकल्पिक रूप से चुन सकती है। प्रामाणिक पैकेज Telegram E2E, Package Acceptance के अंदर चलता है, इसलिए पूर्ण उम्मीदवार कोई डुप्लिकेट लाइव पोलर शुरू नहीं करता। प्रकाशन के बाद, रिलीज़ जाँच, Package Acceptance, Docker, क्रॉस-OS और Telegram में भेजे गए npm पैकेज को दोबारा बिल्ड किए बिना पुनः उपयोग करने के लिए release_package_spec दें। केवल केंद्रित प्रकाशित-पैकेज Telegram पुनः-रन के लिए npm_telegram_package_spec का उपयोग करें। Codex Plugin लाइव पैकेज लेन डिफ़ॉल्ट रूप से उसी चयनित स्थिति का उपयोग करती है: प्रकाशित release_package_spec=openclaw@<tag>, codex_plugin_spec=npm:@openclaw/codex@<tag> व्युत्पन्न करता है, जबकि SHA/आर्टिफ़ैक्ट रन चयनित ref से extensions/codex पैक करते हैं। npm:, npm-pack: या git: विनिर्देशों जैसे कस्टम Plugin स्रोतों के लिए codex_plugin_spec स्पष्ट रूप से सेट करें। इसका लाइव एजेंट प्रमाण दृश्यमान प्रगति भेजता है, यादृच्छिक वर्कस्पेस रीड और सटीक आर्टिफ़ैक्ट लेखन के दौरान जारी रहता है, फिर पूर्णता भेजता है।

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

OpenClaw Release Publish मैन्युअल परिवर्तनकारी रिलीज़ कार्यप्रवाह है। रिलीज़ टैग मौजूद होने और OpenClaw npm प्रीफ़्लाइट सफल होने के बाद विश्वसनीय main से नियमित बीटा और स्थिर प्रकाशन डिस्पैच करें (प्रीफ़्लाइट अपनी जाँचों में pnpm plugins:sync:check चलाता है)। टैग अब भी सटीक रिलीज़ कमिट चुनता है, जिसमें release/YYYY.M.PATCH पर स्थित कमिट भी शामिल है; Tideclaw अल्फ़ा प्रकाशन अपनी संगत अल्फ़ा ब्रांच का उपयोग जारी रखते हैं। इसके लिए सहेजा गया preflight_run_id और सफल full_release_validation_run_id तथा उसका सटीक full_release_validation_run_attempt आवश्यक है, यह सभी प्रकाशन योग्य Plugin पैकेजों के लिए Plugin NPM Release डिस्पैच करता है, उसी रिलीज़ SHA के लिए Plugin ClawHub Release डिस्पैच करता है और केवल उसके बाद OpenClaw NPM Release डिस्पैच करता है। स्थिर प्रकाशन के लिए सटीक windows_node_tag भी आवश्यक है; कार्यप्रवाह किसी भी प्रकाशन चाइल्ड से पहले Windows स्रोत रिलीज़ को सत्यापित करता है और उसके x64/ARM64 इंस्टॉलर की उम्मीदवार-अनुमोदित windows_node_installer_digests इनपुट से तुलना करता है, फिर GitHub रिलीज़ ड्राफ़्ट प्रकाशित करने से पहले उन्हीं पिन किए गए इंस्टॉलर डाइजेस्ट तथा सटीक सहायक आस्ति और चेकसम अनुबंध को प्रोमोट और सत्यापित करता है। केंद्रित केवल-Plugin सुधार गैर-रिक्त पैकेज सूची के साथ plugin_publish_scope=selected का उपयोग करते हैं। केवल-Plugin all-publishable रन के लिए मुख्य प्रकाशन के समान अपरिवर्तनीय npm प्रीफ़्लाइट और पूर्ण रिलीज़ सत्यापन प्रमाण आवश्यक हैं।

gh workflow run openclaw-release-publish.yml \  --ref main \  -f tag=vYYYY.M.PATCH-beta.N \  -f preflight_run_id=<successful-openclaw-npm-preflight-run-id> \  -f full_release_validation_run_id=<successful-full-release-validation-run-id> \  -f full_release_validation_run_attempt=<successful-full-release-validation-run-attempt> \  -f npm_dist_tag=beta

तेज़ी से बदलती ब्रांच पर पिन किए गए कमिट प्रमाण के लिए gh workflow run ... --ref main -f ref=<sha> के बजाय सहायक का उपयोग करें:

pnpm ci:full-release --sha <full-sha>

GitHub कार्यप्रवाह डिस्पैच ref ब्रांच या टैग होने चाहिए, रॉ कमिट SHA नहीं। सहायक विश्वसनीय main कार्यप्रवाह SHA पर एक अस्थायी release-ci/<sha>-... ब्रांच push करता है, अनुरोधित लक्ष्य SHA को कार्यप्रवाह के ref इनपुट के माध्यम से देता है, उपलब्ध होने पर सख्त सटीक-लक्ष्य प्रमाण का पुनः उपयोग करता है, सत्यापित करता है कि प्रत्येक चाइल्ड कार्यप्रवाह headSha विश्वसनीय कार्यप्रवाह SHA से मेल खाता है और रन पूर्ण होने पर अस्थायी ब्रांच हटा देता है। नया सत्यापन बाध्य करने के लिए -f reuse_evidence=false दें। यदि कोई चाइल्ड कार्यप्रवाह किसी अलग कार्यप्रवाह SHA पर चला हो, तो व्यापक सत्यापक भी विफल हो जाता है।

release_profile रिलीज़ जाँचों को दी जाने वाली लाइव/प्रदाता व्यापकता नियंत्रित करता है। मैन्युअल रिलीज़ कार्यप्रवाह डिफ़ॉल्ट रूप से stable का उपयोग करते हैं; full का उपयोग केवल तब करें जब आप जानबूझकर व्यापक परामर्शात्मक प्रदाता/मीडिया मैट्रिक्स चाहते हों। स्थिर और पूर्ण रिलीज़ जाँच हमेशा विस्तृत लाइव/E2E और Docker रिलीज़-पथ सोक चलाती हैं; बीटा प्रोफ़ाइल इसे run_release_soak=true के साथ वैकल्पिक रूप से चुन सकती है।

• beta सबसे तेज़ OpenAI/मुख्य रिलीज़-महत्वपूर्ण लेन बनाए रखता है।
• stable स्थिर प्रदाता/बैकएंड समूह जोड़ता है।
• full व्यापक परामर्शात्मक प्रदाता/मीडिया मैट्रिक्स चलाता है।

व्यापक कार्यप्रवाह डिस्पैच किए गए चाइल्ड रन आईडी रिकॉर्ड करता है और अंतिम Verify full validation जॉब वर्तमान चाइल्ड रन निष्कर्षों की फिर से जाँच करता है तथा प्रत्येक चाइल्ड रन के लिए सबसे धीमे जॉब की तालिकाएँ जोड़ता है। यदि किसी चाइल्ड कार्यप्रवाह को दोबारा चलाने पर वह सफल हो जाता है, तो व्यापक परिणाम और समय-सारांश रीफ़्रेश करने के लिए केवल पैरेंट सत्यापक जॉब दोबारा चलाएँ।

पुनर्प्राप्ति के लिए, Full Release Validation और OpenClaw Release Checks दोनों rerun_group स्वीकार करते हैं। रिलीज़ कैंडिडेट के लिए all, केवल सामान्य पूर्ण CI चाइल्ड के लिए ci, केवल Plugin प्रीरिलीज़ चाइल्ड के लिए plugin-prerelease, केवल OpenClaw प्रदर्शन चाइल्ड के लिए performance, प्रत्येक रिलीज़ चाइल्ड के लिए release-checks, या अम्ब्रेला पर अधिक सीमित समूह का उपयोग करें: install-smoke, cross-os, live-e2e, package, qa, qa-parity, qa-live, या npm-telegram। इससे केंद्रित सुधार के बाद विफल रिलीज़ बॉक्स का पुनः संचालन सीमित रहता है। किसी एक विफल क्रॉस-OS लेन के लिए, rerun_group=cross-os को cross_os_suite_filter के साथ संयोजित करें, उदाहरण के लिए windows/packaged-upgrade; लंबे क्रॉस-OS कमांड Heartbeat पंक्तियाँ उत्सर्जित करते हैं और पैकेज्ड-अपग्रेड सारांशों में प्रत्येक चरण की टाइमिंग शामिल होती है। चुनी गई Matrix और Telegram QA लेन सामान्य रिलीज़ सत्यापन को अवरुद्ध करती हैं, और कोर रनटाइम-युग्म टूल कवरेज गेट भी ऐसा ही करता है। QA समानता, रनटाइम समानता, और गेट की गई Discord, WhatsApp तथा Slack लाइव लेन परामर्शात्मक हैं।

OpenClaw Release Checks चयनित रेफ़ को एक बार release-package-under-test टारबॉल में रिज़ॉल्व करने के लिए विश्वसनीय वर्कफ़्लो रेफ़ का उपयोग करता है, फिर उस आर्टिफ़ैक्ट को क्रॉस-OS जाँचों और पैकेज स्वीकृति के साथ-साथ सोक कवरेज चलने पर लाइव/E2E रिलीज़-पथ Docker वर्कफ़्लो को पास करता है। इससे रिलीज़ बॉक्सों में पैकेज बाइट्स सुसंगत रहती हैं और एक ही कैंडिडेट को कई चाइल्ड जॉब में दोबारा पैक करने से बचा जाता है। Codex npm-Plugin लाइव लेन के लिए, रिलीज़ जाँचें या तो release_package_spec से प्राप्त मेल खाता प्रकाशित Plugin स्पेक पास करती हैं, ऑपरेटर द्वारा दिया गया codex_plugin_spec पास करती हैं, या इनपुट खाली छोड़ती हैं ताकि Docker स्क्रिप्ट चयनित चेकआउट के Codex Plugin को पैक करे।

ref=main और rerun_group=all के लिए डुप्लिकेट Full Release Validation रन पुराने अम्ब्रेला का स्थान ले लेते हैं। पैरेंट रद्द होने पर पैरेंट मॉनिटर पहले से डिस्पैच किए गए किसी भी चाइल्ड वर्कफ़्लो को रद्द कर देता है, इसलिए नया मुख्य सत्यापन किसी पुराने दो घंटे के रिलीज़-जाँच रन के पीछे प्रतीक्षा नहीं करता। रिलीज़ ब्रांच/टैग सत्यापन और केंद्रित पुनः संचालन समूह cancel-in-progress: false बनाए रखते हैं।

लाइव और E2E शार्ड

रिलीज़ लाइव/E2E चाइल्ड व्यापक नेटिव pnpm test:live कवरेज बनाए रखता है, लेकिन इसे एक सीरियल जॉब के बजाय scripts/test-live-shard.mjs के माध्यम से नामित शार्ड के रूप में चलाता है:

• native-live-src-agents और native-live-src-agents-zai-coding
• native-live-src-gateway-core
• प्रोवाइडर-फ़िल्टर किए गए native-live-src-gateway-profiles जॉब
• native-live-src-gateway-backends
• native-live-src-infra
• native-live-test
• native-live-extensions-a-k
• native-live-extensions-l-n
• native-live-extensions-moonshot
• native-live-extensions-openai
• native-live-extensions-o-z-other
• native-live-extensions-xai
• अलग मीडिया ऑडियो/वीडियो शार्ड और प्रोवाइडर-फ़िल्टर किए गए संगीत शार्ड

इससे समान फ़ाइल कवरेज बना रहता है, जबकि धीमे लाइव प्रोवाइडर की विफलताओं को दोबारा चलाना और उनका निदान करना आसान हो जाता है। समग्र native-live-src-gateway, native-live-extensions-o-z, native-live-extensions-media, और native-live-extensions-media-music शार्ड नाम मैन्युअल एकबारगी पुनः संचालन के लिए वैध बने रहते हैं।

नेटिव लाइव मीडिया शार्ड ghcr.io/openclaw/openclaw-live-media-runner:ubuntu-24.04 में चलते हैं, जिसे Live Media Runner Image वर्कफ़्लो बनाता है। यह इमेज ffmpeg और ffprobe को पहले से इंस्टॉल करती है; मीडिया जॉब सेटअप से पहले केवल बाइनरी सत्यापित करते हैं। Docker-समर्थित लाइव सुइट को सामान्य Blacksmith रनर पर रखें—कंटेनर जॉब नेस्टेड Docker परीक्षण शुरू करने के लिए गलत स्थान हैं।

Docker-समर्थित लाइव मॉडल/बैकएंड शार्ड प्रत्येक चयनित कमिट के लिए अलग साझा ghcr.io/openclaw/openclaw-live-test:<sha>-<extensions> इमेज का उपयोग करते हैं। लाइव रिलीज़ वर्कफ़्लो इस इमेज को एक बार बनाकर पुश करता है, फिर Docker लाइव मॉडल, प्रोवाइडर-शार्डेड Gateway, CLI बैकएंड, ACP बाइंड, और Codex हार्नेस शार्ड OPENCLAW_SKIP_DOCKER_BUILD=1 के साथ चलते हैं। Gateway Docker शार्ड वर्कफ़्लो जॉब टाइमआउट से नीचे स्पष्ट स्क्रिप्ट-स्तरीय timeout सीमाएँ रखते हैं, ताकि अटका हुआ कंटेनर या क्लीनअप पथ पूरे रिलीज़-जाँच बजट का उपयोग करने के बजाय शीघ्र विफल हो। यदि ये शार्ड पूर्ण स्रोत Docker टारगेट को स्वतंत्र रूप से दोबारा बनाते हैं, तो रिलीज़ रन गलत ढंग से कॉन्फ़िगर किया गया है और डुप्लिकेट इमेज बिल्ड पर वास्तविक समय व्यर्थ करेगा।

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

जब प्रश्न हो, “क्या यह इंस्टॉल किया जा सकने वाला OpenClaw पैकेज एक उत्पाद के रूप में काम करता है?”, तब Package Acceptance का उपयोग करें। यह सामान्य CI से अलग है: सामान्य CI स्रोत ट्री को सत्यापित करती है, जबकि पैकेज स्वीकृति किसी एक टारबॉल को उसी Docker E2E हार्नेस के माध्यम से सत्यापित करती है जिसका उपयोगकर्ता इंस्टॉल या अपडेट के बाद प्रयोग करते हैं।

जॉब

1. resolve_package, workflow_ref को चेक आउट करता है, एक पैकेज कैंडिडेट रिज़ॉल्व करता है, .artifacts/docker-e2e-package/openclaw-current.tgz लिखता है, .artifacts/docker-e2e-package/package-candidate.json लिखता है, दोनों को package-under-test आर्टिफ़ैक्ट के रूप में अपलोड करता है, और GitHub चरण सारांश में स्रोत, वर्कफ़्लो रेफ़, पैकेज रेफ़, संस्करण, SHA-256, और प्रोफ़ाइल प्रिंट करता है।
2. package_integrity, package-under-test आर्टिफ़ैक्ट डाउनलोड करता है और scripts/check-openclaw-package-tarball.mjs के साथ सार्वजनिक पैकेज टारबॉल अनुबंध लागू करता है।
3. docker_acceptance, रिज़ॉल्व किए गए पैकेज स्रोत SHA (workflow_ref पर फ़ॉलबैक करते हुए) और package_artifact_name=package-under-test के साथ openclaw-live-and-e2e-checks-reusable.yml को कॉल करता है। पुनः प्रयोज्य वर्कफ़्लो उस आर्टिफ़ैक्ट को डाउनलोड करता है, टारबॉल इन्वेंटरी सत्यापित करता है, आवश्यकता होने पर पैकेज-डाइजेस्ट Docker इमेज तैयार करता है, और वर्कफ़्लो चेकआउट को पैक करने के बजाय उस पैकेज के विरुद्ध चयनित Docker लेन चलाता है। जब कोई प्रोफ़ाइल कई लक्षित docker_lanes चुनती है, तो पुनः प्रयोज्य वर्कफ़्लो पैकेज और साझा इमेज एक बार तैयार करता है, फिर उन लेन को विशिष्ट आर्टिफ़ैक्ट वाले समानांतर लक्षित Docker जॉब के रूप में फैलाता है।
4. package_telegram वैकल्पिक रूप से NPM Telegram Beta E2E को कॉल करता है। यह तब चलता है जब telegram_mode, none नहीं होता और पैकेज स्वीकृति द्वारा रिज़ॉल्व किए जाने पर वही package-under-test आर्टिफ़ैक्ट इंस्टॉल करता है; स्वतंत्र Telegram डिस्पैच अब भी प्रकाशित npm स्पेक इंस्टॉल कर सकता है।
5. summary, पैकेज रिज़ॉल्यूशन, अखंडता, Docker स्वीकृति, या वैकल्पिक Telegram लेन विफल होने पर वर्कफ़्लो को विफल करता है। advisory इनपुट परामर्शात्मक कॉलर के लिए स्वीकृति विफलताओं को चेतावनियों में घटा देता है।

कैंडिडेट स्रोत

• source=npm केवल openclaw@extended-stable, openclaw@beta, openclaw@latest, या openclaw@2026.4.27-beta.2 जैसे सटीक OpenClaw रिलीज़ संस्करण को स्वीकार करता है। इसका उपयोग प्रकाशित विस्तारित-स्थिर, प्रीरिलीज़, या स्थिर स्वीकृति के लिए करें।
• source=ref किसी विश्वसनीय package_ref ब्रांच, टैग, या पूर्ण कमिट SHA को पैक करता है। रिज़ॉल्वर OpenClaw ब्रांच/टैग फ़ेच करता है, सत्यापित करता है कि चयनित कमिट रिपॉज़िटरी ब्रांच इतिहास या किसी रिलीज़ टैग से पहुँच योग्य है, डिटैच्ड वर्कट्री में निर्भरताएँ इंस्टॉल करता है, और इसे scripts/package-openclaw-for-docker.mjs के साथ पैक करता है।
• source=url कोई सार्वजनिक HTTPS .tgz डाउनलोड करता है; package_sha256 आवश्यक है। यह पथ URL क्रेडेंशियल, गैर-डिफ़ॉल्ट HTTPS पोर्ट, निजी/आंतरिक/विशेष-उपयोग होस्टनाम या रिज़ॉल्व किए गए IP, और समान सार्वजनिक सुरक्षा नीति के बाहर के रीडायरेक्ट अस्वीकार करता है।
• source=trusted-url, .github/package-trusted-sources.json में नामित विश्वसनीय-स्रोत नीति से HTTPS .tgz डाउनलोड करता है; package_sha256 और trusted_source_id आवश्यक हैं। इसका उपयोग केवल मेंटेनर-स्वामित्व वाले एंटरप्राइज़ मिरर या निजी पैकेज रिपॉज़िटरी के लिए करें, जिन्हें कॉन्फ़िगर किए गए होस्ट, पोर्ट, पथ प्रीफ़िक्स, रीडायरेक्ट होस्ट, या निजी-नेटवर्क रिज़ॉल्यूशन की आवश्यकता होती है। यदि नीति बियरर प्रमाणीकरण घोषित करती है, तो वर्कफ़्लो निश्चित OPENCLAW_TRUSTED_PACKAGE_TOKEN सीक्रेट का उपयोग करता है; URL में एम्बेड किए गए क्रेडेंशियल अब भी अस्वीकार किए जाते हैं।
• source=artifact, artifact_run_id और artifact_name से एक .tgz डाउनलोड करता है; package_sha256 वैकल्पिक है लेकिन बाहरी रूप से साझा किए गए आर्टिफ़ैक्ट के लिए इसे दिया जाना चाहिए।

workflow_ref और package_ref को अलग रखें। workflow_ref वह विश्वसनीय वर्कफ़्लो/हार्नेस कोड है जो परीक्षण चलाता है। package_ref वह स्रोत कमिट है जिसे source=ref होने पर पैक किया जाता है। इससे वर्तमान परीक्षण हार्नेस पुराना वर्कफ़्लो तर्क चलाए बिना पुराने विश्वसनीय स्रोत कमिट को सत्यापित कर सकता है।

सुइट प्रोफ़ाइल

• smoke — npm-onboard-channel-agent, gateway-network, config-reload
• package — npm-onboard-channel-agent, 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
• product — plugins-offline के बजाय लाइव plugins कवरेज वाला package सेट, साथ में mcp-channels, cron-mcp-cleanup, openai-web-search-minimal, openwebui
• full — OpenWebUI के साथ पूर्ण Docker रिलीज़-पथ खंड
• custom — सटीक docker_lanes; suite_profile=custom होने पर आवश्यक

package प्रोफ़ाइल ऑफ़लाइन Plugin कवरेज का उपयोग करती है, ताकि प्रकाशित-पैकेज सत्यापन लाइव ClawHub उपलब्धता पर निर्भर न हो। वैकल्पिक Telegram लेन NPM Telegram Beta E2E में package-under-test आर्टिफ़ैक्ट का पुनः उपयोग करती है, जबकि स्वतंत्र डिस्पैच के लिए प्रकाशित npm स्पेक पथ बनाए रखा जाता है।

स्थानीय कमांड, Docker लेन, पैकेज स्वीकृति इनपुट, रिलीज़ डिफ़ॉल्ट, और विफलता ट्रायेज सहित समर्पित अपडेट और Plugin परीक्षण नीति के लिए, अपडेट और Plugin का परीक्षण देखें।

रिलीज़ जाँचें पैकेज स्वीकृति को source=artifact, तैयार रिलीज़ पैकेज आर्टिफ़ैक्ट, suite_profile=custom, docker_lanes='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', और telegram_mode=mock-openai के साथ कॉल करती हैं। इससे पैकेज माइग्रेशन, अपडेट, लाइव ClawHub Skill इंस्टॉल, पुराने Plugin-निर्भरता क्लीनअप, कॉन्फ़िगर किए गए Plugin इंस्टॉल की मरम्मत, ऑफ़लाइन Plugin, Plugin अपडेट, और Telegram प्रमाण समान रिज़ॉल्व किए गए पैकेज टारबॉल पर बने रहते हैं। बिना दोबारा बनाए भेजे गए npm पैकेज के विरुद्ध समान मैट्रिक्स चलाने के लिए बीटा प्रकाशित करने के बाद पूर्ण रिलीज़ सत्यापन या OpenClaw रिलीज़ जाँच पर release_package_spec सेट करें; केवल तभी package_acceptance_package_spec सेट करें जब पैकेज स्वीकृति को बाकी रिलीज़ सत्यापन से अलग पैकेज चाहिए। क्रॉस-OS रिलीज़ जाँचें अब भी OS-विशिष्ट ऑनबोर्डिंग, इंस्टॉलर, और प्लेटफ़ॉर्म व्यवहार को कवर करती हैं; पैकेज/अपडेट उत्पाद सत्यापन की शुरुआत पैकेज स्वीकृति से होनी चाहिए।

published-upgrade-survivor Docker लेन अवरोधक रिलीज़ पथ में प्रति रन एक प्रकाशित पैकेज बेसलाइन सत्यापित करती है। पैकेज स्वीकृति में, रिज़ॉल्व किया गया package-under-test टारबॉल हमेशा कैंडिडेट होता है और published_upgrade_survivor_baseline फ़ॉलबैक प्रकाशित बेसलाइन चुनता है, जिसका डिफ़ॉल्ट openclaw@latest है; विफल-लेन पुनः संचालन कमांड उस बेसलाइन को बनाए रखते हैं। run_release_soak=true या release_profile=full वाला पूर्ण रिलीज़ सत्यापन published_upgrade_survivor_baselines='last-stable-4 2026.4.23 2026.5.2 2026.4.15' और published_upgrade_survivor_scenarios=reported-issues सेट करता है, ताकि चार नवीनतम स्थिर npm रिलीज़ के साथ पिन की गई Plugin-संगतता सीमा रिलीज़ और Feishu कॉन्फ़िगरेशन, संरक्षित बूटस्ट्रैप/पर्सोना फ़ाइलों, कॉन्फ़िगर किए गए OpenClaw Plugin इंस्टॉल, टिल्ड लॉग पथ, तथा पुराने लेगेसी Plugin निर्भरता रूट के लिए समस्या-आकार वाले फ़िक्स्चर तक विस्तार हो सके। बहु-बेसलाइन प्रकाशित-अपग्रेड सर्वाइवर चयन बेसलाइन के अनुसार अलग लक्षित Docker रनर जॉब में शार्ड किए जाते हैं। जब प्रश्न विस्तृत प्रकाशित अपडेट क्लीनअप का हो, न कि सामान्य पूर्ण रिलीज़ CI विस्तार का, तब अलग Update Migration वर्कफ़्लो all-since-2026.4.23 बेसलाइन और plugin-deps-cleanup परिदृश्यों के साथ update-migration Docker लेन का उपयोग करता है। स्थानीय समग्र रन OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPECS के साथ सटीक पैकेज स्पेक पास कर सकते हैं, openclaw@2026.4.15 जैसे OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPEC के साथ एकल लेन बनाए रख सकते हैं, या परिदृश्य मैट्रिक्स के लिए OPENCLAW_UPGRADE_SURVIVOR_SCENARIOS सेट कर सकते हैं। प्रकाशित लेन बेसलाइन को बेक की गई openclaw config set कमांड रेसिपी से कॉन्फ़िगर करती है, रेसिपी चरणों को summary.json में रिकॉर्ड करती है, और Gateway प्रारंभ होने के बाद /healthz, /readyz, तथा RPC स्थिति की जाँच करती है। Windows पैकेज्ड और इंस्टॉलर फ़्रेश लेन यह भी सत्यापित करती हैं कि इंस्टॉल किया गया पैकेज किसी कच्चे निरपेक्ष Windows पथ से ब्राउज़र-नियंत्रण ओवरराइड आयात कर सकता है। OpenAI क्रॉस-OS एजेंट-टर्न स्मोक सेट होने पर डिफ़ॉल्ट रूप से OPENCLAW_CROSS_OS_OPENAI_MODEL, अन्यथा openai/gpt-5.6-luna का उपयोग करता है, ताकि इंस्टॉल और Gateway प्रमाण कम लागत वाले GPT-5.6 परीक्षण स्तर का उपयोग करे।

लेगेसी संगतता अवधियाँ

Package Acceptance में पहले से प्रकाशित पैकेजों के लिए सीमित पुरानी-संगतता अवधियाँ हैं। 2026.4.25-beta.* सहित 2026.4.25 तक के पैकेज संगतता पथ का उपयोग कर सकते हैं:

• dist/postinstall-inventory.json में ज्ञात निजी QA प्रविष्टियाँ टारबॉल से छोड़ी गई फ़ाइलों की ओर संकेत कर सकती हैं;
• जब पैकेज वह फ़्लैग उजागर नहीं करता, तब doctor-switch, gateway install --wrapper स्थायित्व उप-मामले को छोड़ सकता है;
• update-channel-switch टारबॉल से प्राप्त नकली git फ़िक्स्चर से अनुपलब्ध pnpm patchedDependencies हटा सकता है और अनुपलब्ध स्थायी update.channel को लॉग कर सकता है;
• Plugin स्मोक परीक्षण पुरानी इंस्टॉल-रिकॉर्ड लोकेशन पढ़ सकते हैं या मार्केटप्लेस इंस्टॉल-रिकॉर्ड स्थायित्व की अनुपस्थिति स्वीकार कर सकते हैं;
• plugin-update कॉन्फ़िग मेटाडेटा माइग्रेशन की अनुमति दे सकता है, जबकि इंस्टॉल रिकॉर्ड और पुनः इंस्टॉल न करने वाला व्यवहार अपरिवर्तित रहना आवश्यक है।

प्रकाशित 2026.4.26 पैकेज पहले से शिप की गई स्थानीय बिल्ड मेटाडेटा स्टैम्प फ़ाइलों के लिए चेतावनी भी दे सकता है, और 2026.5.20 तक के पैकेज npm-shrinkwrap.json अनुपलब्ध होने पर विफल होने के बजाय चेतावनी दे सकते हैं। बाद के पैकेजों को आधुनिक अनुबंधों का पालन करना होगा; उन्हीं स्थितियों में चेतावनी देने या छोड़ने के बजाय विफलता होगी।

उदाहरण

# उत्पाद-स्तरीय कवरेज के साथ वर्तमान बीटा पैकेज को सत्यापित करें।gh workflow run package-acceptance.yml \  --ref main \  -f workflow_ref=main \  -f source=npm \  -f package_spec=openclaw@beta \  -f suite_profile=product \  -f telegram_mode=mock-openai # पैकेज कवरेज के साथ प्रकाशित विस्तारित-स्थिर पैकेज को सत्यापित करें।gh workflow run package-acceptance.yml \  --ref main \  -f workflow_ref=main \  -f source=npm \  -f package_spec=openclaw@extended-stable \  -f suite_profile=package \  -f telegram_mode=mock-openai # वर्तमान हार्नेस के साथ किसी रिलीज़ ब्रांच को पैक और सत्यापित करें।gh workflow run package-acceptance.yml \  --ref main \  -f workflow_ref=main \  -f source=ref \  -f package_ref=release/YYYY.M.PATCH \  -f suite_profile=package \  -f telegram_mode=mock-openai # टारबॉल URL को सत्यापित करें। source=url के लिए SHA-256 अनिवार्य है।gh workflow run package-acceptance.yml \  --ref main \  -f workflow_ref=main \  -f source=url \  -f package_url=https://example.com/openclaw-current.tgz \  -f package_sha256=<64-char-sha256> \  -f suite_profile=smoke # नामित विश्वसनीय निजी मिरर नीति से टारबॉल को सत्यापित करें।gh workflow run package-acceptance.yml \  --ref main \  -f workflow_ref=main \  -f source=trusted-url \  -f trusted_source_id=enterprise-artifactory \  -f package_url=https://packages.example.internal:8443/artifactory/openclaw/openclaw-current.tgz \  -f package_sha256=<64-char-sha256> \  -f suite_profile=smoke # किसी अन्य Actions रन द्वारा अपलोड किए गए टारबॉल का पुनः उपयोग करें।gh workflow run package-acceptance.yml \  --ref main \  -f workflow_ref=main \  -f source=artifact \  -f artifact_run_id=<run-id> \  -f artifact_name=package-under-test \  -f suite_profile=custom \  -f docker_lanes='install-e2e plugin-update'

विफल Package Acceptance रन को डीबग करते समय, पैकेज स्रोत, संस्करण और SHA-256 की पुष्टि करने के लिए resolve_package सारांश से शुरू करें। फिर docker_acceptance चाइल्ड रन और उसकी Docker कलाकृतियों का निरीक्षण करें: .artifacts/docker-tests/**/summary.json, failures.json, लेन लॉग, चरण समय और पुनः रन कमांड। पूर्ण रिलीज़ सत्यापन को दोबारा चलाने के बजाय विफल पैकेज प्रोफ़ाइल या ठीक उन्हीं Docker लेनों को दोबारा चलाना बेहतर है।

इंस्टॉल स्मोक परीक्षण

Install Smoke वर्कफ़्लो अब पुल रिक्वेस्ट या main पुश पर नहीं चलता। उसका रात्रिकालीन/मैन्युअल रैपर और रिलीज़ सत्यापन, दोनों केवल-पढ़ने योग्य install-smoke-reusable.yml कोर को कॉल करते हैं, और हर रन GitHub द्वारा होस्ट किए गए रनर पर पूर्ण इंस्टॉल-स्मोक पथ अपनाता है:

• रूट Dockerfile स्मोक इमेज प्रत्येक लक्ष्य SHA के लिए एक बार बनाई जाती है, उसे अपरिवर्तनीय कलाकृति में वर्कफ़्लो संशोधन और निर्माता प्रयास से बाँधा जाता है, फिर CLI स्मोक, साझा-वर्कस्पेस CLI स्मोक हटाने वाले एजेंट, कंटेनर Gateway-नेटवर्क E2E और बंडल किए गए matrix Plugin बिल्ड-आर्ग स्मोक द्वारा लोड किया जाता है। Plugin स्मोक रनटाइम निर्भरता इंस्टॉल मिररिंग और प्रवेश-एस्केप निदान के बिना Plugin लोड होने की पुष्टि करता है।
• QR पैकेज इंस्टॉल और इंस्टॉलर/अपडेट Docker स्मोक परीक्षण (Rocky Linux इंस्टॉलर लेन और कॉन्फ़िगर करने योग्य update_baseline_version npm बेसलाइन के विरुद्ध अपडेट लेन सहित) अलग-अलग जॉब के रूप में चलते हैं, ताकि इंस्टॉलर कार्य को रूट इमेज स्मोक परीक्षणों के पीछे प्रतीक्षा न करनी पड़े।

धीमा Bun वैश्विक इंस्टॉल इमेज-प्रोवाइडर स्मोक परीक्षण अलग से run_bun_global_install_smoke द्वारा गेट किया जाता है। यह रात्रिकालीन शेड्यूल पर चलता है, रिलीज़ जाँचों से आने वाली वर्कफ़्लो कॉल के लिए डिफ़ॉल्ट रूप से चालू रहता है, और मैन्युअल Install Smoke डिस्पैच इसे चुन सकते हैं। सामान्य PR CI अभी भी Node-संबंधित परिवर्तनों के लिए तेज़ Bun लॉन्चर रिग्रेशन लेन चलाता है। QR और इंस्टॉलर Docker परीक्षण अपने इंस्टॉल-केंद्रित Dockerfile बनाए रखते हैं।

स्थानीय Docker E2E

pnpm test:docker:all एक साझा लाइव-परीक्षण इमेज पहले से बनाता है, OpenClaw को npm टारबॉल के रूप में एक बार पैक करता है, और दो साझा scripts/e2e/Dockerfile इमेज बनाता है:

• इंस्टॉलर/अपडेट/Plugin-निर्भरता लेनों के लिए एक साधारण Node/Git रनर;
• एक कार्यात्मक इमेज, जो सामान्य कार्यक्षमता लेनों के लिए उसी टारबॉल को /app में इंस्टॉल करती है।

Docker लेन परिभाषाएँ scripts/lib/docker-e2e-scenarios.mjs में, प्लानर लॉजिक scripts/lib/docker-e2e-plan.mjs में हैं, और रनर केवल चयनित योजना निष्पादित करता है। शेड्यूलर OPENCLAW_DOCKER_E2E_BARE_IMAGE और OPENCLAW_DOCKER_E2E_FUNCTIONAL_IMAGE के साथ प्रत्येक लेन के लिए इमेज चुनता है, फिर OPENCLAW_SKIP_DOCKER_BUILD=1 के साथ लेन चलाता है।

समायोज्य मान

अपनी प्रभावी सीमा से भारी लेन फिर भी खाली पूल से शुरू हो सकती है, फिर क्षमता छोड़ने तक अकेले चलती है। स्थानीय एग्रीगेट Docker की पूर्व-जाँच करता है, पुराने OpenClaw E2E कंटेनर हटाता है, सक्रिय-लेन स्थिति उत्सर्जित करता है, सबसे लंबे को पहले रखने के क्रम के लिए लेन समय स्थायी करता है, और डिफ़ॉल्ट रूप से पहली विफलता के बाद नई पूल की गई लेनों का शेड्यूल करना रोक देता है।

पुनः उपयोग योग्य लाइव/E2E वर्कफ़्लो

पुनः उपयोग योग्य लाइव/E2E वर्कफ़्लो scripts/test-docker-all.mjs --plan-json से पूछता है कि कौन-सा पैकेज, इमेज प्रकार, लाइव इमेज, लेन और क्रेडेंशियल कवरेज आवश्यक है। इसके बाद scripts/docker-e2e.mjs उस योजना को GitHub आउटपुट और सारांशों में बदलता है। यह या तो scripts/package-openclaw-for-docker.mjs के माध्यम से OpenClaw पैक करता है, वर्तमान रन की पैकेज कलाकृति डाउनलोड करता है, या package_artifact_run_id से पैकेज कलाकृति डाउनलोड करता है, फिर टारबॉल इन्वेंटरी सत्यापित करता है। डिफ़ॉल्ट no-push-artifact पथ Blacksmith के Docker लेयर कैश के माध्यम से पैकेज-डाइजेस्ट-टैग वाली साधारण/कार्यात्मक इमेज बनाता है, इमेज के सटीक बाइट्स को अपरिवर्तनीय वर्कफ़्लो कलाकृति में पैक करता है, और प्रत्येक उपभोक्ता से उस कलाकृति को सत्यापित तथा लोड करवाता है। इसके बजाय existing-only को स्पष्ट docker_e2e_bare_image/docker_e2e_functional_image GHCR संदर्भों की आवश्यकता होती है और यह कभी बिल्ड या पुश नहीं करता। वे रजिस्ट्री पुल प्रति प्रयास सीमित 180-सेकंड टाइमआउट उपयोग करते हैं, ताकि अटकी हुई स्ट्रीम CI के अधिकांश क्रिटिकल पथ का समय लेने के बजाय शीघ्र पुनः प्रयास करे। सफल निर्धारित सत्यापन के बाद, openclaw-scheduled-live-checks.yml अपरिवर्तनीय परीक्षित-इमेज मैनिफ़ेस्ट को अलग पैकेज-लेखन प्रकाशक को देता है; केवल-पढ़ने योग्य रिलीज़ और प्रीरिलीज़ कॉलर कभी उस राइटर से होकर नहीं गुजरते।

रिलीज़-पथ खंड

रिलीज़ Docker कवरेज OPENCLAW_SKIP_DOCKER_BUILD=1 के साथ छोटे खंडित जॉब चलाता है, ताकि प्रत्येक खंड केवल अपनी आवश्यक कलाकृति-समर्थित इमेज के प्रकार को सत्यापित और लोड करे (या स्पष्ट existing-only पुनः उपयोग के अंतर्गत उसे पुल करे) और उसी भारित शेड्यूलर के माध्यम से कई लेन निष्पादित करे:

• OPENCLAW_DOCKER_ALL_PROFILE=release-path
• OPENCLAW_DOCKER_ALL_CHUNK=core | package-update-openai | package-update-anthropic | package-update-core | plugins-runtime-plugins | plugins-runtime-services | plugins-runtime-install-a..h | openwebui

वर्तमान रिलीज़ Docker खंड core, package-update-openai, package-update-anthropic, package-update-core, plugins-runtime-plugins, plugins-runtime-services, plugins-runtime-install-a से plugins-runtime-install-h, और openwebui हैं। package-update-openai में लाइव Codex Plugin पैकेज लेन शामिल है, जो उम्मीदवार OpenClaw पैकेज इंस्टॉल करती है, स्पष्ट Codex CLI इंस्टॉल स्वीकृति के साथ codex_plugin_spec या समान-संदर्भ टारबॉल से Codex Plugin इंस्टॉल करती है, Codex CLI पूर्व-जाँच और उसी सत्र के एजेंट टर्न चलाती है, फिर शून्य-पुनः प्रयास वाला मध्यम-चिंतन टर्न चलाती है जो प्रगति भेजता है, यादृच्छिक वर्कस्पेस इनपुट पढ़ता है, उनकी सटीक कलाकृति लिखता है और पूर्णता भेजता है। plugins-runtime-core, plugins-runtime, और plugins-integrations एग्रीगेट Plugin/रनटाइम उपनाम बने रहते हैं। install-e2e लेन उपनाम दोनों प्रोवाइडर इंस्टॉलर लेनों के लिए एग्रीगेट मैन्युअल पुनः रन उपनाम बना रहता है।

जब भी स्थिर या पूर्ण रिलीज़-पथ कवरेज इसका अनुरोध करता है, OpenWebUI एक समर्पित बड़ी-डिस्क वाले Blacksmith रनर पर स्वतंत्र openwebui खंड के रूप में चलता है, भले ही पुनः उपयोग योग्य वर्कफ़्लो समर्थित जॉब को GitHub द्वारा होस्ट किए गए रनर पर भेजता हो। बाहरी इमेज पुल को अलग रखने से बड़ी इमेज plugins-runtime-services में साझा पैकेज और Plugin इमेजों से प्रतिस्पर्धा नहीं करती; पुराने एग्रीगेट Plugin/रनटाइम खंड संगत मैन्युअल पुनः रन के लिए अभी भी OpenWebUI शामिल करते हैं। बंडल किए गए चैनल अपडेट लेन अस्थायी npm नेटवर्क विफलताओं के लिए एक बार पुनः प्रयास करते हैं।

प्रत्येक खंड लेन लॉग, समय, summary.json, failures.json, चरण समय, शेड्यूलर योजना JSON, धीमी-लेन तालिकाओं और प्रति-लेन पुनः रन कमांड के साथ .artifacts/docker-tests/ अपलोड करता है। वर्कफ़्लो का docker_lanes इनपुट खंड जॉब के बजाय उस रन के लिए तैयार इमेजों के विरुद्ध चयनित लेन चलाता है, जिससे विफल-लेन डीबगिंग एक लक्षित Docker जॉब तक सीमित रहती है; यदि चयनित लेन एक लाइव Docker लेन है, तो लक्षित जॉब उस पुनः रन के लिए स्थानीय रूप से लाइव-परीक्षण इमेज बनाता है। पुनः रन सहायक विफलता कलाकृति के ठीक चयनित लक्ष्य SHA को सत्यापित करता है और मैन्युअल डिस्पैच उस संदर्भ को दोबारा पैक करता है, क्योंकि आंतरिक पुनः उपयोग योग्य वर्कफ़्लो पैकेज ट्यूपल workflow_dispatch स्कीमा का हिस्सा नहीं है। जनरेट किए गए कमांड में तैयार इमेज इनपुट और shared_image_policy=existing-only केवल तब शामिल होते हैं, जब वे इनपुट GHCR-समर्थित हों; रनर-स्थानीय कलाकृति टैग छोड़ दिए जाते हैं, ताकि नया रनर उन्हें दोबारा बनाए। स्पष्ट लक्ष्य ओवरराइड पुनर्प्राप्त GHCR इमेज संदर्भों को हटा देता है, जब तक कलाकृति यह सिद्ध न करे कि वे ओवरराइड से मेल खाते हैं। कलाकृति से जनरेट किए गए वर्कफ़्लो-परिभाषा संदर्भ भी छोड़ दिए जाते हैं, क्योंकि पूर्ण-रिलीज़ की अस्थायी ब्रांच हटा दी जाती हैं; जब तक ऑपरेटर स्पष्ट रूप से इसे ओवरराइड न करे, डिस्पैच रिपॉज़िटरी की डिफ़ॉल्ट ब्रांच उपयोग करता है।

pnpm test:docker:rerun <run-id>      # Docker कलाकृतियाँ डाउनलोड करें और संयुक्त/प्रति-लेन लक्षित पुनः रन कमांड प्रिंट करेंpnpm test:docker:timings <summary>   # धीमी-लेन और चरण क्रिटिकल-पथ सारांश

निर्धारित लाइव/E2E वर्कफ़्लो प्रतिदिन पूर्ण रिलीज़-पथ Docker सुइट चलाता है और सफल होने के बाद ठीक उन्हीं परीक्षित इमेज कलाकृतियों के लिए स्पष्ट प्रकाशक को आमंत्रित करता है।

Plugin प्रीरिलीज़

Plugin Prerelease अधिक महँगा उत्पाद/पैकेज कवरेज है, इसलिए यह Full Release Validation या किसी स्पष्ट ऑपरेटर द्वारा डिस्पैच किया जाने वाला एक अलग वर्कफ़्लो है। सामान्य पुल रिक्वेस्ट, main पुश और स्वतंत्र मैन्युअल CI डिस्पैच उस सुइट को बंद रखते हैं। यह बंडल किए गए Plugin परीक्षणों को आठ एक्सटेंशन वर्कर में संतुलित करता है; वे एक्सटेंशन शार्ड जॉब एक समय में अधिकतम दो Plugin कॉन्फ़िग समूह चलाते हैं, जिनमें प्रत्येक समूह के लिए एक Vitest वर्कर और बड़ा Node हीप होता है, ताकि अधिक इंपोर्ट वाले Plugin बैच अतिरिक्त CI जॉब न बनाएँ। केवल रिलीज़ वाला Docker प्रीरिलीज़ पथ (full_release_validation इनपुट द्वारा सक्षम) लक्षित Docker लेन को चार-चार के समूहों में बैच करता है, ताकि एक से तीन मिनट वाले जॉब के लिए दर्जनों रनर आरक्षित न हों। वर्कफ़्लो @openclaw/plugin-inspector से एक सूचनात्मक plugin-inspector-advisory आर्टिफ़ैक्ट भी अपलोड करता है; इंस्पेक्टर के निष्कर्ष ट्रायेज इनपुट हैं और ब्लॉकिंग Plugin Prerelease गेट को नहीं बदलते।

QA Lab

QA Lab में मुख्य स्मार्ट-स्कोप्ड वर्कफ़्लो के बाहर समर्पित CI लेन हैं। एजेंटिक समानता व्यापक QA और रिलीज़ हार्नेस के अंतर्गत नेस्टेड है, यह कोई स्वतंत्र PR वर्कफ़्लो नहीं है। जब समानता को व्यापक सत्यापन रन के साथ चलना चाहिए, तब rerun_group=qa-parity के साथ Full Release Validation का उपयोग करें।

• QA-Lab - All Lanes वर्कफ़्लो main पर हर रात और मैन्युअल डिस्पैच पर चलता है; यह मॉक समानता के साथ लाइव Matrix, Telegram, Discord, WhatsApp और Slack जॉब में फैलता है। लाइव जॉब qa-live-shared एनवायरनमेंट का उपयोग करते हैं; Telegram, Discord, WhatsApp और Slack Convex लीज़ का उपयोग करते हैं, जबकि Matrix अस्थायी स्थानीय क्रेडेंशियल उपलब्ध कराता है।

रिलीज़ जाँच नियतात्मक मॉक प्रोवाइडर और मॉक-योग्य मॉडल (mock-openai/gpt-5.6-luna और mock-openai/gpt-5.6-luna-alt) के साथ Matrix और Telegram की लाइव ट्रांसपोर्ट लेन चलाती है, ताकि चैनल अनुबंध को लाइव मॉडल की विलंबता और सामान्य प्रोवाइडर-Plugin स्टार्टअप से अलग रखा जा सके। लाइव ट्रांसपोर्ट Gateway मेमोरी खोज को अक्षम करता है, क्योंकि QA समानता मेमोरी व्यवहार को अलग से कवर करती है; प्रोवाइडर कनेक्टिविटी अलग लाइव मॉडल, नेटिव प्रोवाइडर और Docker प्रोवाइडर सुइट द्वारा कवर की जाती है।

शेड्यूल किए गए और रिलीज़ Matrix गेट, रिलीज़ परिदृश्यों के साथ साझा QA Lab सुइट होस्ट और लाइव अडैप्टर का उपयोग करते हैं। CLI डिफ़ॉल्ट और मैन्युअल वर्कफ़्लो इनपुट all ही रहते हैं; मैन्युअल all डिस्पैच transport, media, e2ee-smoke, e2ee-deep और e2ee-cli प्रोफ़ाइल में फैलते हैं, ताकि 93-परिदृश्य वाला प्रमाण प्रत्येक जॉब की समय-सीमा के भीतर रहे। केंद्रित मैन्युअल डिस्पैच एक जॉब में fast, release या transport चुनते हैं।

OpenClaw Release Checks रिलीज़ अनुमोदन से पहले रिलीज़-महत्वपूर्ण QA Lab लेन भी चलाता है; इसका QA समानता गेट उम्मीदवार और बेसलाइन पैक को समानांतर लेन जॉब के रूप में चलाता है, फिर अंतिम समानता तुलना के लिए दोनों आर्टिफ़ैक्ट को एक छोटे रिपोर्ट जॉब में डाउनलोड करता है।

सामान्य PR के लिए, समानता को आवश्यक स्थिति मानने के बजाय स्कोप्ड CI/जाँच प्रमाण का पालन करें।

CodeQL

CodeQL वर्कफ़्लो जानबूझकर एक संकीर्ण प्रथम-चरण सुरक्षा स्कैनर है, पूर्ण रिपॉज़िटरी स्वीप नहीं। दैनिक, मैन्युअल, main पुश और गैर-ड्राफ़्ट पुल रिक्वेस्ट गार्ड रन, Actions वर्कफ़्लो कोड के साथ सर्वाधिक जोखिम वाली JavaScript/TypeScript सतहों को उच्च-विश्वसनीयता सुरक्षा क्वेरी से स्कैन करते हैं, जिन्हें उच्च/गंभीर security-severity तक फ़िल्टर किया गया है।

पुल रिक्वेस्ट गार्ड हल्का रहता है: यह केवल .github/actions, .github/codeql, .github/workflows, packages, scripts, src या प्रक्रिया का स्वामित्व रखने वाले बंडल Plugin रनटाइम पथों के अंतर्गत बदलावों के लिए शुरू होता है, और शेड्यूल किए गए वर्कफ़्लो वाला वही उच्च-विश्वसनीयता सुरक्षा मैट्रिक्स चलाता है। Android और macOS CodeQL को PR डिफ़ॉल्ट से बाहर रखा जाता है।

सुरक्षा श्रेणियाँ

प्लेटफ़ॉर्म-विशिष्ट सुरक्षा शार्ड

• CodeQL Android Critical Security — शेड्यूल किया गया Android सुरक्षा शार्ड। वर्कफ़्लो सैनिटी द्वारा स्वीकार किए गए सबसे छोटे Blacksmith Linux रनर पर CodeQL के लिए Android ऐप को मैन्युअल रूप से बिल्ड करता है। /codeql-critical-security/android के अंतर्गत अपलोड करता है।
• CodeQL macOS Critical Security — साप्ताहिक/मैन्युअल macOS सुरक्षा शार्ड। Blacksmith macOS पर CodeQL के लिए macOS ऐप को मैन्युअल रूप से बिल्ड करता है, अपलोड किए गए SARIF से निर्भरता बिल्ड परिणाम फ़िल्टर करता है और /codeql-critical-security/macos के अंतर्गत अपलोड करता है। इसे दैनिक डिफ़ॉल्ट से बाहर रखा गया है, क्योंकि साफ़ स्थिति में भी macOS बिल्ड अधिकांश रनटाइम लेता है।

गंभीर गुणवत्ता श्रेणियाँ

CodeQL Critical Quality इससे मेल खाने वाला गैर-सुरक्षा शार्ड है। यह GitHub-होस्टेड Linux रनर पर संकीर्ण, उच्च-मूल्य सतहों के लिए केवल त्रुटि-गंभीरता वाली गैर-सुरक्षा JavaScript/TypeScript गुणवत्ता क्वेरी चलाता है, ताकि गुणवत्ता स्कैन Blacksmith रनर-पंजीकरण बजट खर्च न करें। इसका पुल रिक्वेस्ट गार्ड जानबूझकर शेड्यूल की गई प्रोफ़ाइल से छोटा है: गैर-ड्राफ़्ट PR केवल उन सतहों से मेल खाने वाले शार्ड चलाते हैं जिन्हें वे छूते हैं, तेरह PR-रूट योग्य शार्ड में से — agent-runtime-boundary, channel-runtime-boundary, config-boundary, core-auth-secrets, gateway-runtime-boundary, mcp-process-runtime-boundary, memory-runtime-boundary, network-runtime-boundary, plugin-boundary, plugin-sdk-package-contract, plugin-sdk-reply-runtime, provider-runtime-boundary और session-diagnostics-boundary। ui-control-plane और web-media-runtime-boundary PR रन से बाहर रहते हैं। CodeQL कॉन्फ़िग और गुणवत्ता वर्कफ़्लो में बदलाव पूर्ण PR शार्ड सेट चलाते हैं (नेटवर्क रनटाइम शार्ड अपनी स्वयं की CodeQL कॉन्फ़िग फ़ाइलों और नेटवर्क का स्वामित्व रखने वाले स्रोत पथों से सक्रिय होता है)।

मैन्युअल डिस्पैच यह स्वीकार करता है:

profile=all|agent-runtime-boundary|config-boundary|core-auth-secrets|channel-runtime-boundary|gateway-runtime-boundary|memory-runtime-boundary|mcp-process-runtime-boundary|network-runtime-boundary|plugin-boundary|plugin-sdk-package-contract|plugin-sdk-reply-runtime|provider-runtime-boundary|session-diagnostics-boundary

संकीर्ण प्रोफ़ाइल किसी एक गुणवत्ता शार्ड को अलगाव में चलाने के लिए शिक्षण/पुनरावृत्ति हुक हैं।

गुणवत्ता को सुरक्षा से अलग रखा जाता है, ताकि सुरक्षा संकेत को अस्पष्ट किए बिना गुणवत्ता निष्कर्षों को शेड्यूल, मापा, अक्षम या विस्तारित किया जा सके। Swift, Python और बंडल-Plugin CodeQL विस्तार को केवल तभी स्कोप्ड या शार्ड किए गए अनुवर्ती कार्य के रूप में वापस जोड़ा जाना चाहिए, जब संकीर्ण प्रोफ़ाइल का रनटाइम और संकेत स्थिर हो जाए।

रखरखाव वर्कफ़्लो

Docs Agent

Docs Agent वर्कफ़्लो हाल ही में लैंड हुए बदलावों के साथ मौजूदा दस्तावेज़ों को संरेखित रखने के लिए एक इवेंट-संचालित Codex रखरखाव लेन है। इसका कोई शुद्ध शेड्यूल नहीं है: main पर सफल गैर-बॉट पुश CI रन इसे ट्रिगर कर सकता है, और मैन्युअल डिस्पैच इसे सीधे चला सकता है। जब main आगे बढ़ चुका हो या पिछले एक घंटे में कोई अन्य न छोड़ा गया Docs Agent रन बनाया गया हो, तब वर्कफ़्लो-रन आह्वान छोड़ दिए जाते हैं। जब यह चलता है, तो पिछले न छोड़े गए Docs Agent स्रोत SHA से वर्तमान main तक की कमिट सीमा की समीक्षा करता है, ताकि एक प्रति-घंटा रन पिछले दस्तावेज़ पास के बाद संचित सभी मुख्य बदलावों को कवर कर सके।

Test Performance Agent

Test Performance Agent वर्कफ़्लो धीमे परीक्षणों के लिए एक इवेंट-संचालित Codex रखरखाव लेन है। इसका कोई शुद्ध शेड्यूल नहीं है: main पर बॉट से इतर कोई सफल पुश CI रन इसे ट्रिगर कर सकता है, लेकिन यदि उस UTC दिन कोई अन्य workflow-run आह्वान पहले ही चल चुका है या चल रहा है, तो यह स्किप हो जाता है। मैन्युअल डिस्पैच उस दैनिक गतिविधि गेट को बायपास करता है। यह लेन पूर्ण-सुइट समूहीकृत Vitest प्रदर्शन रिपोर्ट बनाती है, Codex को व्यापक रीफ़ैक्टर के बजाय केवल छोटे, कवरेज-संरक्षित परीक्षण प्रदर्शन सुधार करने देती है, फिर पूर्ण-सुइट रिपोर्ट दोबारा चलाती है और पास होने वाले आधारभूत परीक्षणों की संख्या घटाने वाले बदलावों को अस्वीकार करती है। समूहीकृत रिपोर्ट Linux और macOS पर प्रति-कॉन्फ़िग वॉल टाइम और अधिकतम RSS दर्ज करती है, ताकि पहले/बाद की तुलना अवधि के अंतरों के साथ परीक्षण मेमोरी के अंतर भी दिखाए। यदि आधाररेखा में विफल परीक्षण हैं, तो Codex केवल स्पष्ट विफलताओं को ठीक कर सकता है और कुछ भी कमिट होने से पहले एजेंट-पश्चात पूर्ण-सुइट रिपोर्ट का पास होना आवश्यक है। जब बॉट पुश लैंड होने से पहले main आगे बढ़ जाता है, तो लेन सत्यापित पैच को रीबेस करती है, pnpm check:changed दोबारा चलाती है और पुश का पुनः प्रयास करती है; टकराव वाले पुराने पैच स्किप कर दिए जाते हैं। यह GitHub-होस्टेड Ubuntu का उपयोग करती है, ताकि Codex ऐक्शन डॉक्स एजेंट जैसी ही drop-sudo सुरक्षा व्यवस्था बनाए रख सके।

मर्ज के बाद डुप्लिकेट PR

Duplicate PRs After Merge वर्कफ़्लो लैंड होने के बाद डुप्लिकेट सफ़ाई के लिए एक मैन्युअल मेंटेनर वर्कफ़्लो है। यह डिफ़ॉल्ट रूप से ड्राई-रन करता है और apply=true होने पर केवल स्पष्ट रूप से सूचीबद्ध PR बंद करता है। GitHub में बदलाव करने से पहले, यह सत्यापित करता है कि लैंड किया गया PR मर्ज हो चुका है और प्रत्येक डुप्लिकेट में या तो साझा संदर्भित इश्यू है या बदले गए हंक ओवरलैप करते हैं।

gh workflow run duplicate-after-merge.yml \  -f landed_pr=70532 \  -f duplicate_prs='70530,70592' \  -f apply=true

स्थानीय जाँच गेट और बदली हुई रूटिंग

कॉन्फ़िग आधारभूत गणना रैचेट

pnpm config:docs:check बिना दस्तावेज़ वाले कॉन्फ़िग-सतह विस्तार तथा दूषित या पुराने गणना स्नैपशॉट को अस्वीकार करता है। जब कोई समीक्षित उत्पाद बदलाव जानबूझकर स्कीमा पथ जोड़ता है, तो pnpm config:docs:gen चलाएँ, कोर/चैनल/Plugin गणना अंतर और जनरेट की गई SHA-256 फ़ाइलों का निरीक्षण करें, और स्कीमा, सहायता, लेबल, माइग्रेशन तथा परीक्षणों के साथ विचारपूर्वक आधाररेखा वृद्धि कमिट करें। रैचेट को बायपास करने के लिए गणना फ़ाइल को हाथ से संपादित न करें।

कॉन्फ़िग लेखकों को Settings के लिए नई लीफ़ को टियर भी देना आवश्यक है। लीफ़ पर advanced: false या advanced: true जोड़ें, या कुंजी को ऐसे पूर्वज के नीचे रखें जिसका टियर सभी वंशजों को इनहेरिट करना चाहिए। अवर्गीकृत रूट कॉपी-पेस्ट स्टब के साथ स्कीमा गुणवत्ता परीक्षण में विफल होते हैं; बिना पूर्वज वाले पथ डिफ़ॉल्ट रूप से उन्नत होते हैं। क्यूरेट किया गया सामान्य-लीफ़ स्नैपशॉट जानबूझकर किए गए टियर बदलावों को समीक्षा में दृश्यमान बनाता है।

स्थानीय बदली-लेन लॉजिक scripts/changed-lanes.mjs में रहता है और scripts/check-changed.mjs द्वारा निष्पादित होता है। वह स्थानीय जाँच गेट व्यापक CI प्लेटफ़ॉर्म दायरे की तुलना में आर्किटेक्चर सीमाओं के बारे में अधिक सख्त है:

• कोर उत्पादन बदलाव कोर प्रोड और कोर परीक्षण टाइपचेक के साथ कोर लिंट/गार्ड चलाते हैं;
• केवल कोर परीक्षण बदलाव सिर्फ़ कोर परीक्षण टाइपचेक के साथ कोर लिंट चलाते हैं;
• एक्सटेंशन उत्पादन बदलाव एक्सटेंशन प्रोड और एक्सटेंशन परीक्षण टाइपचेक के साथ एक्सटेंशन लिंट चलाते हैं;
• केवल एक्सटेंशन परीक्षण बदलाव एक्सटेंशन परीक्षण टाइपचेक के साथ एक्सटेंशन लिंट चलाते हैं;
• सार्वजनिक Plugin SDK या Plugin-अनुबंध बदलाव एक्सटेंशन टाइपचेक तक विस्तृत होते हैं, क्योंकि एक्सटेंशन इन कोर अनुबंधों पर निर्भर हैं (Vitest एक्सटेंशन स्वीप स्पष्ट परीक्षण कार्य बने रहते हैं);
• केवल रिलीज़ मेटाडेटा संस्करण वृद्धि लक्षित संस्करण/कॉन्फ़िग/रूट-निर्भरता जाँच चलाती है;
• अज्ञात रूट/कॉन्फ़िग बदलाव सुरक्षित रूप से सभी जाँच लेन पर विफल होते हैं।

स्थानीय बदले-परीक्षण की रूटिंग scripts/test-projects.test-support.mjs में रहती है और जानबूझकर check:changed से कम खर्चीली है: प्रत्यक्ष परीक्षण संपादन स्वयं को चलाते हैं, स्रोत संपादन पहले स्पष्ट मैपिंग को प्राथमिकता देते हैं, फिर सिब्लिंग परीक्षणों और इंपोर्ट-ग्राफ़ आश्रितों को। साझा समूह-कक्ष डिलीवरी कॉन्फ़िग स्पष्ट मैपिंग में से एक है: समूह के दृश्यमान-उत्तर कॉन्फ़िग, स्रोत उत्तर डिलीवरी मोड या संदेश-टूल सिस्टम प्रॉम्प्ट में बदलाव कोर उत्तर परीक्षणों के साथ Discord और Slack डिलीवरी रिग्रेशन से होकर जाते हैं, ताकि साझा डिफ़ॉल्ट बदलाव पहले PR पुश से पहले विफल हो। OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed का उपयोग केवल तभी करें जब बदलाव इतना व्यापक हार्नेस-स्तरीय हो कि सस्ता मैप किया गया सेट विश्वसनीय प्रतिनिधि न हो।

Testbox सत्यापन

Crabbox मेंटेनर Linux प्रमाण के लिए रेपो-स्वामित्व वाला रिमोट-बॉक्स रैपर है। एजेंट सत्र केवल विश्वसनीय स्रोत के लिए, मौजूदा निर्भरता इंस्टॉलेशन तैयार होने पर, एक/कुछ केंद्रित परीक्षण और सस्ती स्थैतिक जाँच स्थानीय रखते हैं। वे बड़े सुइट और कम्प्यूटेशन की दृष्टि से गहन कार्य के लिए Crabbox का उपयोग करते हैं, जिसमें बिल्ड, टाइपचेक, लिंट फ़ैन-आउट, Docker, पैकेज लेन, E2E, लाइव प्रमाण और CI समानता शामिल हैं। विश्वसनीय मेंटेनर का भारी प्रमाण डिफ़ॉल्ट रूप से blacksmith-testbox का उपयोग करता है, और .crabbox.yaml अब डिफ़ॉल्ट रूप से इसका उपयोग करता है। इसका कॉन्फ़िगर किया गया वर्कफ़्लो प्रदाता और एजेंट क्रेडेंशियल हाइड्रेट करता है, इसलिए अविश्वसनीय योगदानकर्ता या फ़ोर्क कोड को इसके बजाय सीक्रेट-रहित फ़ोर्क CI या सैनिटाइज़ किया हुआ प्रत्यक्ष AWS Crabbox उपयोग करना आवश्यक है। सैनिटाइज़ किए गए AWS रन CRABBOX_ENV_ALLOW=CI सेट करते हैं, --no-hydrate पास करते हैं और नया अस्थायी रिमोट HOME उपयोग करते हैं; यह रेपो की OPENCLAW_* अनुमति-सूची और मौजूदा प्रमाणीकरण प्रोफ़ाइलों को अविश्वसनीय कोड तक पहुँचने से रोकता है। वे उस अविश्वसनीय स्रोत को समर्पित नई वार्म की गई लीज़ का उपयोग करते हैं, कभी भी विश्वसनीय या पहले हाइड्रेट की गई लीज़ का नहीं। स्वच्छ विश्वसनीय main चेकआउट से इंस्टॉल किया हुआ विश्वसनीय Crabbox बाइनरी लॉन्च करें और --fresh-pr से केवल रिमोट PR फ़ेच करें; अविश्वसनीय चेकआउट का रैपर या कॉन्फ़िग कभी भी स्थानीय रूप से निष्पादित न करें। CRABBOX_AWS_INSTANCE_PROFILE को अनसेट करें और तब तक सुरक्षित रूप से विफल हों जब तक रिज़ॉल्व किया गया aws.instanceProfile खाली न हो। किसी भी इंस्टॉल/परीक्षण से पहले, IMDSv2 टोकन आवश्यक करने, IAM क्रेडेंशियल एंडपॉइंट द्वारा 404 लौटाया जाना प्रमाणित करने और रिमोट git rev-parse HEAD की पूर्ण समीक्षित PR हेड SHA से तुलना करने के लिए विश्वसनीय एब्सोल्यूट-पाथ टूल उपयोग करें। लीज़ को उस SHA से बाँधें और हेड बदलने पर उसे रोककर दोबारा वार्म करें। स्वच्छ main से विश्वसनीय scripts/crabbox-untrusted-bootstrap.sh को --fresh-pr के साथ अपलोड करें; यह पिन किए गए Node/pnpm इंस्टॉल करता है, SHA और पैकेज-मैनेजर पिन सत्यापित करता है, HOME को आइसोलेट करता है, निर्भरताएँ इंस्टॉल करता है और फिर अनुरोधित परीक्षण निष्पादित करता है। सभी CRABBOX_TAILSCALE* ओवरराइड अनसेट करें, --network public --tailscale=false लागू करें, एग्ज़िट-नोड/LAN फ़्लैग साफ़ करें और कोई भी स्क्रिप्ट अपलोड करने से पहले crabbox inspect से बिना Tailscale स्थिति वाली सार्वजनिक नेटवर्किंग रिपोर्ट करना आवश्यक करें। स्वामित्व वाली AWS/Hetzner क्षमता Blacksmith आउटेज, कोटा समस्याओं या स्पष्ट स्वामित्व-क्षमता परीक्षण के लिए फ़ॉलबैक भी बनी रहती है।

एजेंट अनुमानित कार्य के लिए पहले से वार्म नहीं करते। पहला भारी कमांड तैयार होने पर Testbox को आवश्यकतानुसार प्राप्त करें, बाद के भारी कमांड के लिए लौटाई गई tbx_... id का पुनः उपयोग करें, हर रन पर वर्तमान चेकआउट सिंक करें और हैंडऑफ़ से पहले उसे रोकें।

Crabbox-समर्थित Blacksmith रन एकबारगी Testbox को वार्म, क्लेम, सिंक, रन, रिपोर्ट और साफ़ करते हैं। अंतर्निहित सिंक सैनिटी जाँच तब तेज़ी से विफल होती है जब सिंक किए गए बॉक्स पर git status --short कम-से-कम 200 ट्रैक की गई विलोपन दिखाता है, जिससे pnpm-lock.yaml जैसी गायब होती रूट फ़ाइलें पकड़ में आती हैं। जानबूझकर बड़े-विलोपन वाले PR के लिए रिमोट कमांड हेतु CRABBOX_ALLOW_MASS_DELETIONS=1 सेट करें।

Crabbox ऐसे स्थानीय Blacksmith CLI आह्वान को भी समाप्त कर देता है जो सिंक-पश्चात आउटपुट के बिना पाँच मिनट से अधिक सिंक चरण में रहता है। उस गार्ड को अक्षम करने के लिए CRABBOX_BLACKSMITH_SYNC_TIMEOUT_MS=0 सेट करें, या असामान्य रूप से बड़े स्थानीय डिफ़ के लिए अधिक बड़ा मिलीसेकंड मान उपयोग करें।

पहले रन से पूर्व, रेपो रूट से रैपर जाँचें:

pnpm crabbox:run -- --help | sed -n '1,120p'

रेपो रैपर ऐसे पुराने Crabbox बाइनरी को अस्वीकार करता है जो चयनित प्रदाता का विज्ञापन नहीं करता, और Blacksmith-समर्थित रन के लिए Crabbox 0.22.0 या नया आवश्यक है, ताकि रैपर को वर्तमान Testbox सिंक, कतार और सफ़ाई व्यवहार मिले। Codex वर्कट्री या लिंक्ड/स्पार्स चेकआउट में स्थानीय pnpm crabbox:run स्क्रिप्ट से बचें, क्योंकि Crabbox शुरू होने से पहले pnpm निर्भरताओं का मिलान कर सकता है; इसके बजाय node रैपर को सीधे आह्वान करें:

node scripts/crabbox-wrapper.mjs run --provider blacksmith-testbox --timing-json --shell -- "pnpm test <path-or-filter>"

सिब्लिंग चेकआउट उपयोग करते समय, टाइमिंग या प्रमाण कार्य से पहले उपेक्षित स्थानीय बाइनरी दोबारा बिल्ड करें:

version="$(git -C ../crabbox describe --tags --always --dirty | sed 's/^v//')" \  && go build -C ../crabbox -trimpath -ldflags "-s -w -X github.com/openclaw/crabbox/internal/cli.version=${version}" -o bin/crabbox ./cmd/crabbox

.crabbox.yaml का blacksmith: ब्लॉक पहले ही संगठन, वर्कफ़्लो, जॉब और रेफ़ डिफ़ॉल्ट को पिन करता है, इसलिए नीचे दिए गए स्पष्ट फ़्लैग वैकल्पिक हैं। बदला हुआ गेट:

pnpm crabbox:run -- --provider blacksmith-testbox \  --blacksmith-org openclaw \  --blacksmith-workflow .github/workflows/ci-check-testbox.yml \  --blacksmith-job check \  --blacksmith-ref main \  --idle-timeout 90m \  --ttl 240m \  --timing-json \  --shell -- \  "corepack pnpm check:changed"

स्थानीय निर्भरताएँ अनुपलब्ध होने या लक्ष्य के फ़ैन-आउट होने पर Testbox पर केंद्रित परीक्षण पुनः चलाना:

pnpm crabbox:run -- --provider blacksmith-testbox \  --idle-timeout 90m \  --ttl 240m \  --timing-json \  --shell -- \  "corepack pnpm test <path-or-filter>"

पूर्ण सुइट:

pnpm crabbox:run -- --provider blacksmith-testbox \  --idle-timeout 90m \  --ttl 240m \  --timing-json \  --shell -- \  "corepack pnpm test"

अंतिम JSON सारांश पढ़ें। उपयोगी फ़ील्ड provider, leaseId, syncDelegated, exitCode, commandMs और totalMs हैं। प्रत्यायोजित Blacksmith Testbox रन के लिए Crabbox रैपर निकास कोड और JSON सारांश ही कमांड परिणाम हैं। लिंक किया गया GitHub Actions रन हाइड्रेशन और कीपअलाइव का स्वामी है; SSH कमांड पहले ही लौटने के बाद Testbox को बाहरी रूप से रोकने पर यह cancelled के रूप में समाप्त हो सकता है। जब तक रैपर exitCode शून्येतर न हो या कमांड आउटपुट विफल परीक्षण न दिखाए, इसे सफ़ाई/स्थिति आर्टिफ़ैक्ट मानें। एकबारगी Blacksmith-समर्थित Crabbox रन को Testbox स्वचालित रूप से रोक देना चाहिए; यदि कोई रन बाधित हो या सफ़ाई अस्पष्ट हो, तो लाइव बॉक्स का निरीक्षण करें और केवल अपने बनाए हुए बॉक्स रोकें:

blacksmith testbox list --allblacksmith testbox status --id <tbx_id>blacksmith testbox stop --id <tbx_id>

पुनः उपयोग केवल तभी करें जब आपको जानबूझकर उसी हाइड्रेट किए गए बॉक्स पर कई कमांड चलाने हों:

node scripts/crabbox-wrapper.mjs run --provider blacksmith-testbox --id <tbx_id> --timing-json --shell -- "corepack pnpm test <path-or-filter>"pnpm crabbox:stop -- <tbx_id>

लीज़ का पुनः उपयोग करें, पुराने स्रोत का नहीं। --no-sync छोड़ दें, ताकि प्रत्येक रन वर्तमान चेकआउट अपलोड करे; इसका उपयोग केवल अपरिवर्तित, पहले से सिंक किए गए ट्री को जानबूझकर दोबारा चलाने के लिए करें। अविश्वसनीय योगदानकर्ता/फ़ोर्क कोड को हर कमांड के लिए CRABBOX_ENV_ALLOW=CI, --provider aws --no-hydrate और नया अस्थायी रिमोट HOME उपयोग करना आवश्यक है; परीक्षण से पहले उस सैनिटाइज़ किए गए कमांड में निर्भरताएँ इंस्टॉल करें। केवल उसी अविश्वसनीय स्रोत को समर्पित नई वार्म की गई लीज़ का पुनः उपयोग करें; विश्वसनीय या पहले हाइड्रेट की गई लीज़ का कभी नहीं। अविश्वसनीय चेकआउट का रैपर या कॉन्फ़िग कभी भी स्थानीय रूप से निष्पादित न करें: स्वच्छ विश्वसनीय main से इंस्टॉल किया हुआ विश्वसनीय Crabbox बाइनरी लॉन्च करें और प्रत्येक रन पर --fresh-pr पास करें। CRABBOX_AWS_INSTANCE_PROFILE को अनसेट रखें, गैर-खाली रिज़ॉल्व किए गए इंस्टेंस प्रोफ़ाइल को अस्वीकार करें, विश्वसनीय रिमोट IMDS नो-रोल प्रमाण आवश्यक करें और इंस्टॉल/परीक्षण से पहले समीक्षित हेड SHA सत्यापित करें। लीज़ को उस SHA से बाँधें; किसी भी हेड बदलाव के बाद रोकें और दोबारा वार्म करें। यदि कोई रिमोट PR मौजूद नहीं है, तो सीक्रेट-रहित फ़ोर्क CI उपयोग करें। अविश्वसनीय स्रोत के लिए कभी भी hydrate-github या क्रेडेंशियल-हाइड्रेटेड Blacksmith वर्कफ़्लो न चुनें।

यदि Crabbox टूटी हुई परत है लेकिन Blacksmith स्वयं काम करता है, तो प्रत्यक्ष Blacksmith का उपयोग केवल list, status और सफ़ाई जैसे निदान के लिए करें। प्रत्यक्ष Blacksmith रन को मेंटेनर प्रमाण मानने से पहले Crabbox पथ ठीक करें।

यदि blacksmith testbox list --all और blacksmith testbox status काम करते हैं, लेकिन नए वार्मअप कुछ मिनटों के बाद भी बिना IP या Actions रन URL के queued स्थिति में रहते हैं, तो इसे Blacksmith प्रदाता, कतार, बिलिंग या संगठन-सीमा के दबाव के रूप में मानें। आपके बनाए हुए कतारबद्ध ids को रोकें, अधिक Testboxes शुरू करने से बचें, और प्रमाण को नीचे दिए गए स्वामित्व वाले Crabbox क्षमता पथ पर ले जाएँ, जबकि कोई व्यक्ति Blacksmith डैशबोर्ड, बिलिंग और संगठन सीमाओं की जाँच करे।

स्वामित्व वाली Crabbox क्षमता पर केवल तभी एस्केलेट करें, जब Blacksmith अनुपलब्ध हो, कोटा-सीमित हो, आवश्यक परिवेश मौजूद न हो, या स्वामित्व वाली क्षमता स्पष्ट रूप से लक्ष्य हो:

CRABBOX_CAPACITY_REGIONS=eu-west-1,eu-west-2,eu-central-1,us-east-1,us-west-2 \  pnpm crabbox:warmup -- --provider aws --class standard --market on-demand --idle-timeout 90mpnpm crabbox:hydrate -- --provider aws --id <cbx_id-or-slug>pnpm crabbox:run -- --provider aws --id <cbx_id-or-slug> --timing-json --shell -- "pnpm check:changed"pnpm crabbox:stop -- --provider aws <cbx_id-or-slug>

AWS दबाव के दौरान, जब तक कार्य को वास्तव में 48xlarge-श्रेणी के CPU की आवश्यकता न हो, class=beast से बचें। beast अनुरोध 192 vCPUs से शुरू होता है और यह क्षेत्रीय EC2 Spot या On-Demand Standard कोटा सीमा पार करने का सबसे आसान तरीका है। रिपॉज़िटरी-स्वामित्व वाला .crabbox.yaml डिफ़ॉल्ट रूप से class: standard, ऑन-डिमांड बाज़ार और capacity.hints: true का उपयोग करता है, ताकि ब्रोकर किए गए AWS लीज़ चयनित क्षेत्र/बाज़ार, कोटा दबाव, Spot फ़ॉलबैक और उच्च-दबाव श्रेणी चेतावनियाँ प्रिंट करें। अधिक भारी व्यापक जाँचों के लिए fast, केवल standard/fast के पर्याप्त न होने के बाद large, और केवल असाधारण CPU-बाउंड लेन—जैसे पूर्ण-सूट या सभी-Plugin Docker मैट्रिक्स, स्पष्ट रिलीज़/ब्लॉकर सत्यापन या उच्च-कोर प्रदर्शन प्रोफ़ाइलिंग—के लिए beast का उपयोग करें। pnpm check:changed, केंद्रित परीक्षणों, केवल-दस्तावेज़ कार्य, सामान्य lint/typecheck, छोटे E2E पुनरुत्पादनों या Blacksmith आउटेज ट्रायेज के लिए beast का उपयोग न करें। क्षमता निदान के लिए --market on-demand का उपयोग करें, ताकि Spot बाज़ार की अस्थिरता संकेत में न मिले।

.crabbox.yaml प्रदाता, सिंक और GitHub Actions हाइड्रेशन डिफ़ॉल्ट का स्वामी है। Crabbox सिंक कभी भी .git स्थानांतरित नहीं करता, इसलिए हाइड्रेट किया गया Actions चेकआउट अनुरक्षक-स्थानीय रिमोट और ऑब्जेक्ट स्टोर को सिंक करने के बजाय अपना रिमोट Git मेटाडेटा बनाए रखता है, और रिपॉज़िटरी कॉन्फ़िगरेशन स्थानीय रनटाइम/बिल्ड आर्टिफ़ैक्ट (जैसे .artifacts और परीक्षण रिपोर्ट) भी बाहर रखता है, जिन्हें कभी स्थानांतरित नहीं किया जाना चाहिए। .github/workflows/crabbox-hydrate.yml चेकआउट, Node/pnpm सेटअप, origin/main फ़ेच और स्वामित्व-क्लाउड crabbox run --id <cbx_id> कमांड के लिए गैर-गोपनीय परिवेश हस्तांतरण का स्वामी है।

संबंधित

• इंस्टॉलेशन का अवलोकन
• विकास चैनल