HelixQA बीटालाइसेंस: Apache-2.0

पारंपरिक क्वालिटी एश्योरेंस (QA) तब "पुष्टि सफल" का हरा संकेत दे देता है, जबकि Constitution जिसे *धोखेबाज़ी* कहता है—वह गड़बड़ी इसी तरह फिसल जाती है। यानी एक फीचर को काम करता हुआ रिपोर्ट किया जाता है, जबकि असल उपयोगकर्ता के लिए वह टूटा होता है। HelixQA को खास तौर पर QA के लिए इसी समस्या को असंभव बनाने के लिए बनाया गया है: यह बिना वास्तविक सबूत (स्क्रीनशॉट, लॉगकैट, वीडियो, स्टैक ट्रेस, रिपोर्ट) के PASS स्कोर नहीं देता, जो वास्तविक परीक्षण के दौरान कैप्चर किया गया हो। साथ ही, बिना सबूत के हरे रंग की सारांश लाइन को भी एक गंभीर दोष मानता है, जो किसी गायब फीचर के बराबर होता है। यह श्रम की समस्या का भी समाधान करता है—कई प्लेटफार्मों पर व्यापक मैनुअल QA को बढ़ाना संभव नहीं होता—क्योंकि यह सत्रों को पूरी तरह स्वायत्त बना देता है।

यह दो ऐसी चीज़ों को जोड़ता है जो लगभग कभी एक ही टूल में नहीं होतीं: कठोर, सबूत-आधारित QA गेटिंग और स्वायत्त, स्वचालित अन्वेषण। एक LLM-प्लस-विज़न एजेंट *वास्तविक* ऐप खोलता है, हर दस्तावेज़ीकृत फीचर की पुष्टि करता है, उन अनदस्तावेज़ बग्स की तलाश करता है जिनके लिए किसी ने टेस्ट नहीं लिखा होता, *और* इसके साथ-साथ अदालती गुणवत्ता का सबूत भी तैयार करता है—ताकि "हमने इसका परीक्षण किया" की जगह "यह रहा वीडियो, यह रहा लॉगकैट, यह रहा टिकट" आ जाए। और चूँकि यह Constitution-नामित QA सबमॉड्यूल है, इसलिए इसे अपनाने से एक टीम के QA की ईमानदारी नहीं बढ़ती—बल्कि एक ही कदम में पूरे उत्पाद परिवार के लिए न्यूनतम मानक ऊँचा हो जाता है।

• धोखेबाज़ी-रोधी सबूत अनुबंध — हर जाँच का PASS कैप्चर किए गए रनटाइम सबूत से बँधा होता है; हरी CI लाइन को ज़रूरी तो माना जाता है, लेकिन कभी पर्याप्त नहीं, और बिना सबूत के हरे सारांश को गंभीर दोष के रूप में स्कोर किया जाता है।
• स्वायत्त दस्तावेज़-चालित + जिज्ञासा-चालित अन्वेषण — यह हर दस्तावेज़ीकृत फीचर की पुष्टि करता है *और* फिर स्क्रिप्ट से हटकर उन किनारे के मामलों की जाँच करता है जिनसे असली उपयोगकर्ता टकराते हैं (खाली इनपुट, तेज़ इंटरैक्शन, अनदस्तावेज़ रास्ते) जिन्हें कोई हस्तलिखित टेस्ट सुइट नहीं पकड़ पाता।
• विज़न ओरेकल — GoCV मैकेनिकल विज़न और LLM विज़न API सचमुच *स्क्रीन पर चल रहे UI को देखता है*, उन विज़ुअली टूटे हुए स्टेट्स को पकड़ता है जिन्हें टोकन- और प्रॉपर्टी-स्तर की पुष्टियाँ सीधे नज़रअंदाज़ कर देती हैं।
• संरचना-आधारित टेस्ट बैंक — बैंक स्ट्रिंग्स संरचना का वर्णन करती हैं और रनटाइम पर LLM-जनित प्रश्न प्रॉम्प्ट्स को संचालित करती हैं (CONST-046), ताकि एक ही बैंक सभी लोकेशनों पर काम करे, बजाय इसके कि UI टेक्स्ट के अनुवाद होते ही वह बिखर जाए।
• AI फिक्स पाइपलाइनों के लिए तैयार टिकट — स्वतः जनित मार्कडाउन इश्यूज़ पूरे सबूत बंडल के साथ आते हैं, जिन्हें सीधे डाउनस्ट्रीम रिपेयर एजेंट को सौंपा जा सकता है, न कि किसी मानव ट्राइजर को।

एक अनिवार्य गुणवत्ता स्तंभ के रूप में (Constitution §11.4.169 में helix_qa सबमॉड्यूल को आवश्यक टेस्ट प्रकारों में से एक नामित किया गया है), HelixQA परिवार के हर उत्पाद को समान शक्तियाँ प्रदान करता है:

• स्वायत्त QA सत्र: एकल कमांड helixqa autonomous --project … --platforms android,desktop,web LLM-प्लस-विज़न एजेंट को छोड़ देता है, जो बिना किसी मानवीय हस्तक्षेप के वास्तविक ऐप्स को कवरेज लक्ष्य की ओर संचालित करता है, रिपोर्ट, टिकट और वीडियो जनरेट करता है।
• टेस्ट बैंक / सुइट्स: YAML बैंक (राउंड-219 का न्यूनतम मानक ≥30), प्लेटफार्म-लक्षित, प्राथमिकता-आधारित, और लाइन-दर-लाइन उन दस्तावेज़ों से जुड़े हुए जिन्हें वे सत्यापित करते हैं।
• कैप्चर किए गए सबूत: स्क्रीनशॉट, लॉगकैट, वीडियो, स्टैक ट्रेस और पूरा टाइमलाइन—केंद्रीकृत और हर रिपोर्ट से जुड़े हुए, ताकि किसी भी निर्णय को बाद में दोबारा देखा और ऑडिट किया जा सके।
• स्वतंत्र निर्णय (§11.4.141 स्वतंत्रता सिद्धांत): इसका LLM-संचालित issuedetector और विज़न ओरेकल चल रहे ऐप के व्यवहार का मूल्यांकन उस एजेंट से स्वतंत्र रूप से करते हैं जिसने इसे नेविगेट किया, जिससे उस क्लासिक गड़बड़ी से बचा जाता है जहाँ कोई सिस्टम अपने ही काम को सही ठहरा देता है।
• गेट + म्यूटेशन रैचेट: make qa-all / make anti-bluff और challenges/scripts/helixqa_orchestrator_challenge.sh (8 चरण, अंतर्निहित §1.1 म्यूटेशन) HelixQA की ईमानदारी को लगातार साबित करते रहते हैं—और जानबूझकर कोई --skip-helixqa शॉर्टकट नहीं रखा गया है ताकि समय सीमा के दबाव में अनुशासन को बंद न किया जा सके।

सामग्री

• गुणवत्ता जाँच में ही झूठी सकारात्मकता को रोकना — वह उपकरण जो धोखे पकड़ता है, खुद धोखा न बन जाए → हर कदम पकड़े गए साक्ष्य के आधार पर सत्यापित किया जाता है, साक्ष्य के बिना पास को पास के बजाय दोष के रूप में दर्ज किया जाता है, और एक व्यवहार-एंकर मेनिफ़ेस्ट हर घोषित क्षमता को एक निष्पादन योग्य परीक्षण (CONST-035) से जोड़ता है ताकि बिना परीक्षण के कोई क्षमता दावा न की जा सके।

• एक ही मस्तिष्क से विविध प्लेटफ़ॉर्म चलाना — एंड्रॉयड, एंड्रॉयड टीवी, वेब और डेस्कटॉप का इनपुट मॉडल एक जैसा नहीं होता → एकल navigator पैकेज प्लेटफ़ॉर्म-विशिष्ट ActionExecutors (ADB, Playwright, X11) और प्रति-प्लेटफ़ॉर्म क्रैश डिटेक्टरों (एंड्रॉयड/वेब/डेस्कटॉप) को अमूर्त करता है, ताकि ऑर्केस्ट्रेशन लॉजिक एक बार लिखा जाए और प्लेटफ़ॉर्म के अंतर किनारों पर ही रहें।

• स्वायत्त एजेंटों को उपयोगी बनाना, अराजक नहीं — एक अनियंत्रित LLM ऐप में हमेशा भटक सकता है → LLMsVerifier मॉडलों का मूल्यांकन और चयन करता है, LLMOrchestrator हेडलेस CLI एजेंटों (opencode, claude-code, gemini, junie, qwen-code) का प्रबंधन करता है, DocProcessor फीचर मैप बनाता है जो अन्वेषण को एक लक्ष्य देता है, और VisionEngine हर निर्णय को मॉडल की कल्पना के बजाय स्क्रीन पर वास्तविक पिक्सल के आधार पर रखता है।

• स्थानीयकरण-सुरक्षित बैंक — एक ऐसा सूट जो अंग्रेजी UI टेक्स्ट को हार्डकोड करता है, पंद्रह भाषाओं में टूट जाता है → बैंक केवल संरचना का वर्णन करते हैं, और उपयोगकर्ता-सामने आने वाला प्रॉम्प्ट टेक्स्ट LLM/रिसोर्स-लोडेड रनटाइम पर होता है (CONST-046), ताकि एक ही बैंक किसी भी स्थान पर समान व्यवहार की जाँच करे।

• साबित करना कि गेट धोखा नहीं हैं — एक ऐसा एंटी-ब्लफ़ गेट जो खुद विफल न हो सके, वह अंतिम धोखा है → युग्मित §1.1 म्यूटेशन एक प्रकार के साक्ष्य-संग्रहण या एंटी-ब्लफ़ दावे को हटाते हैं और गेट को विफल होने के लिए बाध्य करते हैं, और एक म्यूटेशन रैचेट इस गारंटी को समय के साथ चुपचाप कमजोर होने से रोकता है।

• Go 1.24+ ऑर्केस्ट्रेटर — *क्यों:* गुणवत्ता जाँच को उन सभी जगहों पर चलना चाहिए जहाँ उत्पाद चलते हैं, इसलिए एकल स्टैटिकली-लिंक्ड, तेज़ और पोर्टेबल बाइनरी रनटाइम-भारी विकल्प से बेहतर है; *कैसे:* एक cmd/helixqa CLI जिसमें संयोज्य उप-कमांड run / list / report / autonomous / version शामिल हैं।

• YAML टेस्ट बैंक (pkg/testbank) — *क्यों:* सूट घोषणात्मक और पठनीय होने चाहिए, जिन्हें Go को छुए बिना इंसान संपादित कर सकें; *कैसे:* version/name/test_cases[] जिसमें id, category, priority, platforms, क्रमबद्ध steps[], और documentation_refs[] शामिल हैं ताकि फीचर दस्तावेज़ों से पता लगाया जा सके।

• क्रैश/ANR डिटेक्टर (pkg/detector) — *क्यों:* सबसे महत्वपूर्ण विफलताएँ वे होती हैं जो लाइव, इंटरैक्शन के दौरान होती हैं, न कि बाद में दावे के रूप में; *कैसे:* एंड्रॉयड के लिए ADB (pidof/logcat/screencap) और वेब/डेस्कटॉप के लिए pgrep, जो प्रक्रिया को टेस्ट चलाते समय निगरानी करते हैं।

• साक्ष्य संग्रह (pkg/evidence, pkg/session) — *क्यों:* एंटी-ब्लफ़ अनुबंध तभी वास्तविक होता है जब हर पास के पीछे भौतिक प्रमाण हो; *कैसे:* स्क्रीनशॉट, logcat, वीडियो और स्टैक ट्रेस एक SessionRecorder टाइमलाइन में कैप्चर किए जाते हैं, जिससे हर रिपोर्ट जुड़ी होती है।

• स्वायत्त सत्र (pkg/autonomous, pkg/navigator, pkg/issuedetector) — *क्यों:* चार प्लेटफ़ॉर्म पर मैनुअल गुणवत्ता जाँच का विस्तार नहीं किया जा सकता, इसलिए अन्वेषण को खुद संचालित होना चाहिए; *कैसे:* एक 4-चरणीय SessionCoordinator प्लस ActionExecutors (ADB/Playwright/X11) और LLM बग डिटेक्शन जो विज़ुअल, UX, एक्सेसिबिलिटी और कार्यात्मक दोषों को कवर करता है।

• बाहरी सबमॉड्यूल — *क्यों:* पुन: उपयोग और डिकपलिंग (CONST-051), और — महत्वपूर्ण रूप से — नेविगेटर को जज से अलग करना; *कैसे:* LLMsVerifier (मॉडल स्कोरिंग), LLMOrchestrator (हेडलेस CLI एजेंट), VisionEngine (GoCV + LLM विज़न), DocProcessor (फीचर-मैप/कवरेज), प्रत्येक स्वतंत्र रूप से स्वामित्व वाला घटक।

• एंटी-ब्लफ़ गेट + म्यूटेशन रैचेट — *क्यों:* HelixQA को उसी §1.1 अनुबंध का पालन करना चाहिए जो वह दूसरों पर लागू करता है; *कैसे:* एक make anti-bluff स्कैन प्लस व्यवहार-एंकर मेनिफ़ेस्ट और म्यूटेशन रैचेट, जिसमें helixqa_orchestrator_challenge.sh एक 8-चरणीय एंड-टू-एंड वैलिडेटर के रूप में कार्य करता है।

• 15-पंक्ति कवरेज मैट्रिक्स (docs/test-coverage.md) — *क्यों:* CONST-050(B) एक बंद, पूरी तरह से लेखांकित टेस्ट-टाइप सेट की मांग करता है जिसमें कोई अंतराल न हो; *कैसे:* हर पंक्ति एक ठोस निष्पादन योग्य संपत्ति और एक विशिष्ट साक्ष्य-स्वरूप से जुड़ी होती है, ताकि कवरेज एक जाँच योग्य तथ्य हो, न कि केवल दावा।

सामग्री

• स्थिति: बीटा। सक्रिय रूप से विकसित (README स्थिति बैनर दौर 219)। अपने स्वयं के 'ब्लफ़-विरोधी' मानक पर खरा उतरता है।
• लाइसेंस: अपाचे-2.0। इंस्टॉल करें: go install digital.vasic.helixqa/cmd/helixqa@latest।

प्राथमिकता स्तर: Helix-प्राथमिक — Helix परिवार के लिए एक अनिवार्य गुणवत्ता/ब्लफ़-विरोधी स्तंभ, जो यह सत्यापित करता है कि विशेषताएँ वास्तव में कार्य करती हैं।