उत्तरप्रकाशित11 स्रोत
BMAD V4.2: परीक्षण का दायरा तय करें, अलगाव नहीं
मौजूदा साक्ष्य यह साबित नहीं करते कि हर परीक्षण में 198.1 MiB डाउनलोड होता है या हर बदलाव पर पूरी कंटेनर मैट्रिक्स चलती है। एक लॉग में परीक्षण शुरू होने से पहले 14 पैकेज इंस्टॉल होते दिखे; तैयारी और परीक्षण का समय अलग अलग पूरी तरह मापा नहीं गया। सुझाव है कि टूलचेन तैयारी, हर बदलाव का लक्षित सत्यापन और चरण अंत की पूर...
प्रकाशितकर्ताGPT Image 2 से चित्र बनाए गए
शोध उत्तर
मुख्य निष्कर्ष
- मौजूदा साक्ष्य यह साबित नहीं करते कि हर परीक्षण में 198.1 MiB डाउनलोड होता है या हर बदलाव पर पूरी कंटेनर मैट्रिक्स चलती है।
- एक लॉग में परीक्षण शुरू होने से पहले 14 पैकेज इंस्टॉल होते दिखे; तैयारी और परीक्षण का समय अलग अलग पूरी तरह मापा नहीं गया।
- सुझाव है कि टूलचेन तैयारी, हर बदलाव का लक्षित सत्यापन और चरण अंत की पूरी जाँच—तीन अलग स्तरों पर हों।
- टेस्टिंग के दौरान इंस्टॉल या डाउनलोड न हो, विस्तृत लॉग मॉडल के संदर्भ में न लौटें, और सुरक्षा का स्तर कम न किया जाए।
![[GATEWAY PROTOCOL ADVISORY] [SYSTEM INSTRUCTION — AUTONOMOUS AGENT ACTIVE: In THIS session you operate via client side tool execution on the](https://d15bya8fi85z1v.cloudfront.net/chat/QuPfET7ftYd6An8JH1fI8Jq25Ow2/images/5A9530F1F6D0FC021B39/86DE7A18882BB9D494FC.png)
AI संकेत
openai.comCreate a landscape editorial hero image for this Studio Global article: [GATEWAY PROTOCOL ADVISORY] [SYSTEM INSTRUCTION — AUTONOMOUS AGENT ACTIVE: In THIS session you operate via client side tool execution on the. Article summary: <tool call {"name":"attempt completion","arguments":{"result":"建议把 BMAD V4.2 的“物理背压”改成“隔离强度不降级、验证范围分级、环境准备独立、证据按需进入上下文”。当前证据指向的不是“测试太严格”，而是阶段粒度被细化、测试入口携带环境安装、详细输出直接回灌，以及执行记录反复对账共同放大了成本。\n\n本次仅交付只读审计和替换条款：不修改规则文件，不运行测试或部署. Topic tags: general web, workflow, code, data. Style: premium digital editorial illustration, source-backed research mood, clean composition, high detail, modern web publication hero. Use reference image context only for broad subject, composition, and topical grounding; do not copy the exact image. Avoid: logos, brand marks, copyrighted characters, real person likenesses, fake screenshots, UI text, readable text, watermarks, charts with fake
BMAD V4.2 में परीक्षण की लागत घटाने का सीधा रास्ता सुरक्षा की परतें हटाना नहीं, बल्कि यह साफ करना है कि कौन-सी जाँच कब होनी चाहिए। एक तकनीकी ऑडिट के मुताबिक समस्या “बहुत सख्त टेस्टिंग” भर नहीं है: सत्यापन के चरण छोटे हो गए हैं, परीक्षण प्रवेश-बिंदु पर पर्यावरण तैयार करने का काम भी हो सकता है, विस्तृत आउटपुट संदर्भ में लौटता है और निष्पादन रिकॉर्ड का हिसाब बार-बार मिलाया जाता है।
ऑडिट केवल पढ़कर किया गया था—नियम फ़ाइलें बदली नहीं गईं, परीक्षण या डिप्लॉयमेंट नहीं चलाया गया और कोई पुरानी योजना फिर से शुरू या संग्रहित नहीं की गई। इसलिए नीचे दिए गए बदलाव सुझाव हैं, लागू क्षमताओं का दावा नहीं।
साक्ष्य क्या बताते हैं—और क्या नहीं
BMAD के वैश्विक नियम हर छोटे पैच पर पूरी कंटेनर मैट्रिक्स चलाने की साफ माँग नहीं करते। 02-bmad-core.md हर चरण के लिए संबंधित सत्यापन की बात करता है (नियम, खंड 3)। इंजीनियरिंग नियम भी बदलाव के दायरे के अनुसार परीक्षण चुनने और होस्ट या स्वीकृत कंटेनर का उपयोग करने की गुंजाइश देता है (इंजीनियरिंग नियम)। अधिक कठोर निर्देश एक पुराने परियोजना-प्लान में था: “हर कदम के बाद भौतिक सत्यापन” (योजना का निर्देश)।
इसलिए बढ़ी लागत को सीधे वैश्विक नियम पर डालना सही नहीं होगा। अधिक सटीक तस्वीर यह है: नियम चरण का आकार और तैयारी की लागत अलग नहीं करते; फिर परियोजना-प्लान हर कदम के बाद सत्यापन जोड़ता है; और वही परीक्षण प्रवेश-बिंदु पर्यावरण तैयार करने और टेस्ट चलाने, दोनों का काम कर सकता है।
एक लॉग में टेस्ट इवेंट शुरू होने से पहले 14 पैकेज इंस्टॉल होते दिखते हैं। इंस्टॉलेशन के अंत में 31 पैकेजों का कुल आकार 198.1 MiB बताया गया है—यह संख्या अपने-आप में इस बात का प्रमाण नहीं कि उसी रन में 198.1 MiB डाउनलोड या नए सिरे से अनपैक हुआ। लॉग के समय के अनुसार ऑपरेशन शुरू होने और टेस्ट इवेंट के बीच करीब 5.3 सेकंड थे; पैकेज-स्तर का टेस्ट करीब 2.72 सेकंड चला और पूरा ऑपरेशन लगभग 8 सेकंड का था (समय विवरण, इंस्टॉलेशन लॉग, समापन रिकॉर्ड)। उपलब्ध समय-माप यह नहीं बताते कि तैयारी के हिस्से में इंस्टॉल, कंटेनर शुरू होने, कम्पाइल या कैश-जाँच में से किसने कितना समय लिया।
लॉग की समस्या केवल पैकेज इंस्टॉलेशन नहीं है। टेस्ट इवेंट में शुरुआत और पास होने की जानकारी कई रूपों में दोहराई गई है (दोहराए गए इवेंट का नमूना)। उपलब्ध लॉग में लगभग 76,000 अक्षरों का कटे हुए आउटपुट का संकेत भी है (कटाव का स्थान)। लेकिन चैट निर्यात या स्क्रीन पर दिखे पाठ से यह निष्कर्ष नहीं निकाला जा सकता कि पूरा लॉग मॉडल के अनुरोध में गया था या उससे कितने बिल किए गए टोकन बने।
इतिहास में कम्पाइल और टेस्ट के अलग-अलग कॉल तथा अलग कंटेनर पहचान दर्ज हैं (फिक्स्ड-स्टेट सत्यापन रिकॉर्ड)। फिर भी लॉग में टेस्ट के लिए ऐसा Go कमांड दिखता है जो बिल्ड की तैयारी में प्रवेश कर सकता है (कंटेनर के भीतर कमांड)। आइसोलेशन स्क्रिप्ट का पूरा पाठ उपलब्ध नहीं था, इसलिए यह तय नहीं किया जा सकता कि इंस्टॉलेशन स्क्रिप्ट, इमेज एंट्री-पॉइंट या किसी दूसरे रैपर में हुआ। निष्कर्ष सीमित रहना चाहिए: एक रन में इंस्टॉलेशन देखा गया; कई कंटेनर कॉल का इतिहास है; हर कॉल में दोबारा इंस्टॉलेशन हुआ—यह अभी साबित नहीं।
चार अलग जीवनचक्र, जिन्हें अलग रखना ज़रूरी है
- आइसोलेशन: एक टेस्ट स्रोत कोड, होस्ट या अगले टेस्ट को दूषित न करे।
- टूलचेन: कम्पाइलर, सिस्टम लाइब्रेरी और स्वीकृत निर्भरताएँ पर्यावरण के साथ बदलें, हर व्यावसायिक व्यवहार-सुधार के साथ नहीं।
- सत्यापन: बदलाव के कारण कौन-सा पुराना प्रमाण अमान्य हुआ है, यह तय किया जाए।
- रिकॉर्ड: नतीजे और स्थिति सहेजना अपने-आप में उसी कार्यात्मक परीक्षण को दोबारा चलाने का कारण न बने।
पुरानी योजना में बदले हुए दस्तावेज़-बाइंडिंग को फिर जाँचने और निष्पादन रिकॉर्ड में ऐतिहासिक सारांश रखने की शर्तें हैं (बाइंडिंग इतिहास, रिकॉर्ड के बाद पुनः जाँच)। इससे बदलाव पकड़ने में मदद मिलती है, लेकिन यदि अनुबंध के इनपुट और परीक्षण-नतीजों को अलग न रखा जाए तो “नतीजा दर्ज करो → दस्तावेज़ बदला → फिर टेस्ट करो → फिर नतीजा दर्ज करो” जैसा दोहराव पैदा हो सकता है। यह संरचनात्मक जोखिम है; उपलब्ध साक्ष्य अनंत चक्र साबित नहीं करते।
मुख्य फर्क यह है: स्थिर टूलचेन दोबारा इस्तेमाल करना और पुराना, दूषित टेस्ट-परिवेश दोबारा इस्तेमाल करना एक बात नहीं। अस्थायी टेस्ट-परिवेश को फिर से बनाना भी टूलचेन दोबारा इंस्टॉल करने के बराबर नहीं। सुरक्षा को “पूरी तरह सुरक्षित” जैसे अस्पष्ट दावे की जगह जाँचने योग्य सीमाओं में लिखना चाहिए—जैसे बाहरी नेटवर्क और अनधिकृत स्थायी लेखन पर रोक, लेकिन सीमित अस्थायी जगह और तयशुदा प्रमाण-फ़ाइलों की अनुमति। Go का रेस डिटेक्टर केवल चलाए गए रास्तों में कुछ डेटा रेस पकड़ सकता है; इससे यह साबित नहीं होता कि कार्यक्रम में कहीं भी रेस नहीं है 9।
तीन स्तरों में सत्यापन का प्रस्ताव
यह सुझाया गया अनुबंध है, पहले से लागू व्यवस्था नहीं।
| स्तर | काम | कब चलाएँ |
|---|---|---|
| L0: स्थिर निष्पादन पर्यावरण | पहले से तैयार टूलचेन, सिस्टम लाइब्रेरी और स्वीकृत निर्भरताएँ; इमेज और टूलचेन की पहचान दर्ज हो | पर्यावरण का इनपुट बदले तो नया संस्करण तैयार करें; केवल स्रोत कोड बदलने पर सिस्टम पैकेज दोबारा इंस्टॉल न हों |
| L1: कोडिंग के दौरान लक्षित जाँच | एक अर्थपूर्ण बदलाव के लिए संबंधित यूनिट, मॉड्यूल और ज़रूरत पड़ने पर रेस परीक्षण | हर सत्यापन-योग्य बदलाव के बाद, उसी स्वीकृत आइसोलेशन में; परीक्षण का दायरा बदले, सुरक्षा का स्तर नहीं |
| L2: चरण-अंत की जाँच | स्थिर किए गए उम्मीदवार पर चरण के लिए ज़रूरी परीक्षणों की पूरी सूची, अलग से चलाया गया RSS मापन और प्रमाण का मिलान | चरण पूरा होने या अधिकृत डिलीवरी से पहले; सामान्य प्रगति-रिकॉर्ड बदलने पर नहीं |
L0: पर्यावरण दोबारा इस्तेमाल करें, पुराना टेस्ट-फील्ड नहीं
इमेज की पहचान स्थिर रखें और परीक्षण प्रवेश-बिंदु पर सिस्टम पैकेज इंस्टॉल करना, इमेज डाउनलोड करना या नेटवर्क से निर्भरताएँ हल करना बंद करें। यदि स्वीकृत इमेज या निर्भरता मौजूद न हो तो रन रुकना चाहिए और साफ बताना चाहिए कि पर्यावरण तैयार नहीं है—नेटवर्क से अपने-आप पूर्ति नहीं करनी चाहिए। पर्यावरण तैयार करने की अलग अनुमति और अलग समय-बजट हो; उसे परीक्षण कमांड के भीतर छिपाया न जाए।
टेस्ट में स्रोत केवल-पढ़ने योग्य रहे, बाहरी नेटवर्क बंद हो और अस्थायी जगह सीमित हो। प्रमाण के लिए आवश्यक सामग्री के अलावा क्रेडेंशियल, होस्ट-कंट्रोल सॉकेट या असंबंधित फ़ोल्डर माउंट न हों। कैश परियोजना, टूलचेन, प्लेटफ़ॉर्म और भरोसे की सीमा के अनुसार अलग रखें। कैश हिट का अर्थ केवल यह है कि कोई गणना फिर इस्तेमाल हुई—यह अपने-आप में टेस्ट पास होने का प्रमाण नहीं।
L1: हल्की जाँच का मतलब सैंडबॉक्स से बाहर जाना नहीं
उपलब्ध पुराने प्राधिकरण में ऑफ़लाइन आइसोलेशन कंटेनर में सत्यापन की सीमा तय है (स्वीकृति का दायरा)। इसलिए होस्ट मशीन पर तेज़ टेस्ट को डिफ़ॉल्ट विकल्प मानना उचित नहीं। सामान्य रास्ता वही सुरक्षा सीमाएँ बनाए रखने वाला हल्का आइसोलेटेड रन होना चाहिए। होस्ट पर टेस्ट चलाना हो तो उसके लिए अलग, स्पष्ट अनुमति और लागू होने की शर्तें चाहिए—समय बचाने के नाम पर चुपचाप वातावरण बदलना नहीं।
L2: उम्मीदवार स्थिर करें, टूलचेन बार-बार तैयार न करें
चरण-अंत का परिणाम स्रोत और टेस्ट स्नैपशॉट, निर्भरताओं, निष्पादन पर्यावरण, रन-कॉन्फ़िगरेशन और सत्यापन सूची से बँधा हो। RSS का मापन बिना इंस्ट्रूमेंटेशन वाले अलग प्रोसेस में हो; रेस और संसाधन-जाँच के नतीजे अलग दर्ज हों। पुरानी योजना में स्वतंत्र संसाधन-सत्यापन की शर्त पहले से है, उसे बनाए रखना चाहिए (संसाधन सत्यापन निर्देश)।
अंतिम गेट के बाद इनपुट बदलें तो पुराने नतीजे नए उम्मीदवार पर सीधे लागू न मानें। सिर्फ़ प्रभावित हिस्से दोबारा चलाए जा सकते हैं, बशर्ते यह दिखाया जाए कि बाकी प्रमाण अब भी लागू हैं। यह साबित न हो सके तो जाँच का दायरा बढ़ाएँ।
किन बदलावों पर कौन-सी जाँच हो
| बदलाव या घटना | ज़रूरी कदम | अपने-आप यह न करें |
|---|---|---|
| एक ही व्यवहार के कोड और टेस्ट में बदलाव पूरा हुआ | एक बार संबंधित L1 जाँच | L0 फिर से बनाना या पूरी L2 मैट्रिक्स चलाना |
| लॉक, समवर्ती पहुँच, रद्दीकरण या संसाधन-मुक्ति बदली | मौजूदा बैच में लक्षित रेस और जीवनचक्र जाँच जोड़ना | रेस जाँच को केवल अंतिम डिलीवरी तक टालना |
| साझा निर्भरता या मॉड्यूल-इंटरफ़ेस बदला | प्रभावित कॉल-चेन तक जाँच बढ़ाना | बिना आधार केवल बदली हुई फ़ाइल टेस्ट करना |
| टूलचेन, सिस्टम निर्भरता या आइसोलेशन कॉन्फ़िगरेशन बदला | L0 की फिर पुष्टि और संबंधित प्रमाणों की समीक्षा | टेस्ट कमांड के भीतर इंस्टॉल करना |
| चरण की डिलीवरी के लिए उम्मीदवार स्थिर हुआ | चरण के लिए ज़रूरी L2 मैट्रिक्स | हर बीच के पैच पर पूरी मैट्रिक्स दोहराना |
| केवल निष्पादन रिकॉर्ड या प्रगति-पाठ बदला | रिकॉर्ड की पूर्णता और दस्तावेज़ अनुबंध की जाँच | व्यावसायिक टेस्ट और RSS फिर चलाना |
“अर्थपूर्ण बदलाव-बैच” का मतलब है ऐसा व्यवहार-सुधार और उसका टेस्ट, जिसे अलग से जाँचा जा सके। उसमें कई सटीक संपादन हो सकते हैं। उससे जुड़े अगले बदलाव पर जाने से पहले L1 पास होना चाहिए। न तो बदलावों को अनिश्चित समय तक जमा करें, न ही टूल-कॉल की संख्या को बैच तय करने का आधार बनाएँ।
नियमों में प्रस्तावित बदलाव
वैश्विक नियम में: “भौतिक सत्यापन” का अर्थ स्वीकृत पर्यावरण में वास्तविक रन और जाँचा जा सकने वाला नतीजा हो—हर संपादन के बाद आधारभूत पर्यावरण फिर बनाना नहीं। काम शुरू करने से पहले बदलाव-बैच, चरण-सीमा, संबंधित जाँच और दायरा बढ़ाने की शर्तें तय हों। पर्यावरण तैयारी, कम्पाइल, टेस्ट और सफ़ाई के इनपुट, बजट और नतीजे अलग हों; टेस्ट प्रवेश-बिंदु पर पैकेज इंस्टॉल, इमेज डाउनलोड या निर्भरता डाउनलोड न हो।
पर्यावरण तैयार न होना, कम्पाइल विफल होना, टेस्ट असफल होना, समय-सीमा पार होना, कोई टेस्ट न चलना, प्रमाण क्षतिग्रस्त होना और सफ़ाई विफल होना—इनकी अलग-अलग श्रेणियाँ हों। ज़रूरी जाँच में कोई भी विफल हो तो चरण आगे न बढ़े। विफल नतीजा चरण को रोकता है, लेकिन उसी दायरे में कारण ढूँढ़ने और सुधारने से नहीं रोकता। एक ही असफल कमांड बार-बार चलाकर, assertion हटाकर या सुरक्षा ढीली करके हरी स्थिति न ली जाए। सत्यापन का नतीजा उसके वास्तविक इनपुट और कवरेज से जुड़ा हो; उसे तभी दोबारा मानें जब यह साबित हो कि इनपुट और लागू होने की शर्तें नहीं बदलीं।
इंजीनियरिंग नियम में: हर जाँच के साथ बदलाव का दायरा, चुना हुआ सत्यापन और दायरा बढ़ाने का कारण दर्ज हो; जोखिम केवल बदली हुई फ़ाइलों की संख्या से तय न हो। यदि कम्पाइल और टेस्ट का बजट सख़्ती से अलग रखना है, तो टेस्ट चरण पहले से बने, पहचाने जा सकने वाले बिल्ड आर्टिफ़ैक्ट का उपयोग करे—छिपे हुए बिल्ड-चक्र में दोबारा न जाए। कम्पाइल, टेस्ट और सफ़ाई के समय-बजट अलग और सीमित हों; कुल बजट में शामिल चरणों और बंद होने के लिए दी गई अतिरिक्त मोहलत का हिसाब हो। पर्यावरण बदलना, तैयारी करना और व्यावसायिक डिप्लॉयमेंट अलग-अलग अनुमति माँगें; सत्यापन कंटेनर बनाना व्यावसायिक डिप्लॉयमेंट नहीं कहलाए।
आउटपुट नियम में: कच्चे डायग्नोस्टिक लॉग और मॉडल को दिखाए जाने वाले सारांश अलग रहें। विस्तृत लॉग सीमित अवधि वाले स्वीकृत आर्टिफ़ैक्ट चैनल में रखें; पूरा लॉग डिफ़ॉल्ट रूप से बातचीत में न लौटाएँ। एक शुरुआती सुझाव है कि सफल रन का सारांश 2 KiB और विफलता का सारांश 8 KiB तक सीमित हो। सारांश में पहला मूल कारण, ज़रूरी स्टैक, निकास स्थिति, छूटी जाँच और मूल लॉग का स्थान रहे। ये शुरुआती बजट सुझाए गए हैं—न तो उद्योग-मानक, न ही इस ऑडिट में मापे गए सर्वोत्तम आँकड़े।
संरचित टेस्ट इवेंट को पढ़कर गिनती और दोहराव का सार दें; केवल “error” लिखी पंक्तियाँ हटाना पर्याप्त नहीं। अंतिम इवेंट न मिले, पार्सिंग विफल हो, शून्य टेस्ट चलें, कुछ टेस्ट बिना कारण छोड़े जाएँ या आर्टिफ़ैक्ट उपलब्ध न हो तो केवल शून्य निकास-कोड देखकर पास न मानें। सारांश काट-छाँट उपकरण के परिणाम के मॉडल इतिहास में जाने से पहले होनी चाहिए। मॉडल से “लॉग अनदेखा करने” या स्क्रीन पर लॉग मोड़कर दिखाने का निर्देश इसका विकल्प नहीं।
योजना के टेम्पलेट में: हर सत्यापन के लिए स्तर, उसे शुरू करने वाली घटना, अपेक्षित कवरेज और स्पष्ट रूप से बाहर रखी चीज़ें लिखें। साथ में निष्पादन पर्यावरण और अनुमति, तैयारी की उपलब्ध सामग्री, तैयारी/कम्पाइल/टेस्ट/सफ़ाई का अलग बजट, इनपुट पहचान, प्रमाण अमान्य होने की शर्तें, सारांश सीमा, कच्चे आर्टिफ़ैक्ट का स्थान और उसे रखने की अवधि तथा पर्यावरण, assertion या प्रमाण-विफलता पर अगला कदम भी दर्ज हो (सत्यापन मैट्रिक्स टेम्पलेट)। अनुबंध के इनपुट और रन के नतीजे अलग रखे जाएँ; नतीजा दर्ज करने से वही कार्यात्मक जाँच अपने-आप फिर न चले। बाहरी बदलाव पकड़ने के लिए पूर्ण फ़ाइल-फिंगरप्रिंट वाली सुरक्षा फिर भी बनी रहे।
लागू करने का व्यावहारिक क्रम
- पहले नियम और योजना-टेम्पलेट में L0/L1/L2, बदलाव-बैच, आउटपुट सीमा और प्रमाण अमान्य होने की शर्तें साफ करें। Roo और मूल कौशल-पथ दोनों की जाँच करें, ताकि अलग रास्तों में अलग अर्थ न निकलें (कौशल प्रवेश-बिंदु, मूल कोर नियम)।
- फिर निष्पादन व्यवस्था सुधारें: टूलचेन पहले से उपलब्ध हो, पर्यावरण तैयारी और टेस्ट अलग हों और मशीन-पठनीय सारांश तैयार हो। केवल इंस्टॉलेशन लॉग छिपाकर इसे पूरा सुधार न मानें।
- अंत में छोटे पैमाने पर तुलना करें: कई बदलाव-बैच एक ही पर्यावरण में चलाएँ और जाँचें कि टेस्ट चरण में सिस्टम पैकेज इंस्टॉल शून्य बार हुआ, सामान्य रिकॉर्ड अपडेट से L2 नहीं चला, सारांश तय सीमा में रहा और जान-बूझकर डाले गए assertion failure, शून्य टेस्ट, timeout तथा सफ़ाई की विफलता ने रन को रोका।
सुझावों का क्रम अहम है: पहले दोहराई जाने वाली तैयारी और अनावश्यक पूरा लॉग हटाएँ, उसके बाद सत्यापन की आवृत्ति पर निर्णय लें। आइसोलेशन कम करना या अहम रेस कवरेज घटाना निष्पादन और नियमों की अस्पष्टता की भरपाई नहीं है।
Studio Global AI
अपना शोध जारी रखें
इस पृष्ठ में एक स्रोत-समर्थित उत्तर शामिल है जिसे आप Studio Global के अंदर जारी रख सकते हैं।
लोग पूछते भी हैं
"BMAD V4.2: परीक्षण का दायरा तय करें, अलगाव नहीं" का संक्षिप्त उत्तर क्या है?
मौजूदा साक्ष्य यह साबित नहीं करते कि हर परीक्षण में 198.1 MiB डाउनलोड होता है या हर बदलाव पर पूरी कंटेनर मैट्रिक्स चलती है।
सबसे पहले सत्यापित करने योग्य मुख्य बिंदु क्या हैं?
मौजूदा साक्ष्य यह साबित नहीं करते कि हर परीक्षण में 198.1 MiB डाउनलोड होता है या हर बदलाव पर पूरी कंटेनर मैट्रिक्स चलती है। एक लॉग में परीक्षण शुरू होने से पहले 14 पैकेज इंस्टॉल होते दिखे; तैयारी और परीक्षण का समय अलग अलग पूरी तरह मापा नहीं गया।
मुझे अभ्यास में आगे क्या करना चाहिए?
सुझाव है कि टूलचेन तैयारी, हर बदलाव का लक्षित सत्यापन और चरण अंत की पूरी जाँच—तीन अलग स्तरों पर हों।