// سطح: helix-primary · سفارش 20

HelixQA betaاجازه‌نامه: Apache-2.0

Go 1.24+YAML test banks (pkg/testbank)Crash/ANR detectors (ADB, pgrep)Evidence collection (screenshots/logcat/video/stack traces)Autonomous session (LLM + computer vision)LLMsVerifierLLMOrchestratorVisionEngine (GoCV + LLM Vision)DocProcessorAnti-bluff gates + mutation ratchet

منبع

1 · Setup select LLMs · feature map 2 · Doc-Driven Verification every documented feature 3 · Curiosity Exploration edge cases · undocumented 4 · Report & Cleanup MD / HTML / JSON Captured evidence screenshot · logcat · video HelixQA — autonomous QA-session loop
// معماری

هماهنگ‌سازی پرسش و پاسخ ضد بلوف — جلسات مستقل و چندسکویی که هر تأیید موفق، شواهد ضبط‌شده‌ای را به همراه دارد که کاربر واقعی می‌تواند از قابلیت استفاده کند.

HelixQA چارچوب هماهنگ‌سازی پرسش و پاسخ ضد بلوف برای تست چندسکویی (اندروید، اندروید تی‌وی، وب، دسکتاپ) است که بانک‌های تست YAML، تشخیص بلادرنگ کرش، ضبط گام‌به‌گام شواهد و جلسات مستقل پرسش و پاسخ LLM به‌علاوه بینایی کامپیوتری را ترکیب می‌کند تا اثبات کند قابلیت‌ها واقعاً از ابتدا تا انتها کار می‌کنند. این نوع تست پرسش و پاسخ اجباری Constitution (§۱۱٫۴٫۱۶۹) است.

هماهنگ‌کننده پرسش و پاسخ ضد بلوف (Go) که بانک‌های تست نوشته‌شده و جلسات کاملاً مستقل پرسش و پاسخ مبتنی بر LLM و بینایی کامپیوتری را در پلتفرم‌های مختلف اجرا می‌کند — کرش‌ها را تشخیص می‌دهد، هر گام را با شواهد ضبط‌شده (اسکرین‌شات، لاگ‌کت، ویدئو، ردپای پشته) اعتبارسنجی می‌کند و تیکت‌های غنی از شواهد را به‌طور خودکار برای خطوط اصلاح AI تولید می‌کند.

HelixQA چارچوبی از نوع Go است که محور طراحی بی‌چون‌وچرای آن، قاعده عملیاتی §۱۱٫۴ Constitution است: معیار عرضه نه «تست‌ها پاس می‌شوند» بلکه «کاربران می‌توانند از قابلیت استفاده کنند» است، بنابراین هر تأیید موفق (PASS) که صادر می‌کند باید شواهد مثبت زمان اجرا را که در حین اجرا ضبط شده‌اند به همراه داشته باشد — بدون شواهد، تأیید موفق وجود ندارد، بدون استثنا. این چارچوب در دو حالت مکمل عمل می‌کند که با هم هم تست‌های اسکریپتی و هم موارد ناشناخته را پوشش می‌دهند. نخست، بانک‌های تست نوشته‌شده — مجموعه‌های YAML از موارد TC-XXX با هدف‌گذاری پلتفرمی، اولویت‌بندی، گام‌های مرتب‌شده (نام/عمل/انتظار)، تگ‌ها و مراجع مستندات — که با اعتبارسنجی گام‌به‌گام، تشخیص بلادرنگ کرش/ANR (ADB برای اندروید، نظارت بر فرآیند برای وب/دسکتاپ)، جمع‌آوری متمرکز شواهد و تولید خودکار تیکت‌های مارک‌داون که از پیش برای خطوط اصلاح AI آماده شده‌اند، اجرا می‌شوند. دوم، جلسه کاملاً مستقل پرسش و پاسخ که برنامه را به عوامل مبتنی بر LLM و بینایی کامپیوتری می‌سپارد و اجازه می‌دهد بدون نظارت در چهار فاز منظم آن را هدایت کنند: راه‌اندازی (انتخاب مدل‌های زبانی بزرگ، ساخت نقشه قابلیت از مستندات پروژه، ایجاد عوامل CLI، راه‌اندازی موتور بینایی)، تأیید مبتنی بر مستندات که هر قابلیت مستندشده را بررسی می‌کند، کاوش کنجکاوانه که عمداً به موارد حاشیه‌ای و رفتارهای غیرمستند می‌پردازد، سپس گزارش‌دهی و پاکسازی در قالب مارک‌داون/HTML/JSON با هر یافته‌ای که به شواهد دارای مهر زمانی ویدئویی پیوند خورده است.

نکته حیاتی این است که این چارچوب تکلیف خود را خود تصحیح نمی‌کند: چهار زیرماژول خارجی Go (LLMsVerifier، LLMOrchestrator، VisionEngine، DocProcessor) را یکپارچه می‌کند و از زیرساخت‌های مشترک challenges و containers استفاده می‌کند، بنابراین مؤلفه‌ای که برنامه را هدایت می‌کند همان مؤلفه‌ای نیست که درباره عملکرد آن قضاوت می‌کند. مجموعه تست‌های خود چارچوب دقیقاً همان معیاری را رعایت می‌کنند که برای دیگران از طریق make anti-bluff (اسکن ایستا + مانیفست لنگر رفتاری + چرخه جهش) و یک چالش هماهنگ‌کننده ۸ فازی با جهش داخلی §۱٫۱ اعمال می‌شود. ماتریس پوشش نوع تست ۱۵ سطری، هر قابلیت تبلیغ‌شده را به یک دارایی اجرایی مشخص و یک شکل شواهد ضبط‌شده خاص متصل می‌کند — بنابراین ادعاهای چارچوب درباره خودش به همان اندازه مبتنی بر شواهد است که احکامی که برای محصولاتی که تست می‌کند صادر می‌کند.

محتوا

کیفیت تضمین سنتی با چراغ سبز «تأییدیه تأیید شد» کار می‌کند؛ دقیقاً همان روشی که کلاس خطای Constitution آن را *فریبکاری* می‌نامد و از آن عبور می‌کند — قابلیتی که گزارش می‌شود کار می‌کند در حالی که برای کاربر واقعی خراب است. HelixQA دقیقاً برای غیرممکن کردن این وضعیت برای تضمین کیفیت ساخته شد: این سیستم بدون شواهد فیزیکی (اسکرین‌شات، لاگ‌کت، ویدئو، استک تریس، گزارش) که تحت اجرای واقعی ضبط شده باشد، نمره «قبول» نمی‌دهد و یک خط خلاصه سبز بدون چنین شواهدی را به‌عنوان نقصی بحرانی معادل با یک قابلیت گم‌شده ارزیابی می‌کند. همچنین مشکل نیروی کار را حل می‌کند — تضمین کیفیت دستی جامع در پلتفرم‌های متعدد مقیاس‌پذیر نیست — با خودکار کردن کامل جلسات.

این سیستم دو چیزی را که تقریباً هرگز در یک ابزار واحد گرد هم نمی‌آیند، ترکیب می‌کند: دروازه تضمین کیفیت دقیق و مبتنی بر شواهد، و کاوش خودران و مستقل. یک عامل LLM به‌علاوه بینایی، *برنامه واقعی* را باز می‌کند، هر قابلیت مستندشده را تأیید می‌کند، به دنبال باگ‌های مستندنشده‌ای می‌گردد که هیچ‌کس برایشان تستی ننوشته است، *و* در حین انجام این کار، ردی از شواهد با کیفیت دادگاه تولید می‌کند — به این ترتیب «ما آن را تست کردیم» جای خود را به «این ویدئو است، این لاگ‌کت است، این تیکت است» می‌دهد. و چون این زیرسیستم تضمین کیفیت با نام Constitution است، پذیرش آن نه‌تنها صداقت تضمین کیفیت را برای یک تیم ارتقا می‌دهد، بلکه سطح کیفی تمام محصولات مصرف‌کننده در خانواده را در یک حرکت واحد بالا می‌برد.

  • قرارداد ضدفریب مبتنی بر شواهد — هر بررسی «قبول» به شواهد اجرایی ضبط‌شده وابسته است؛ یک خط سبز CI ضروری تلقی می‌شود اما هرگز کافی نیست، و یک خلاصه سبز بدون شواهد به‌عنوان نقصی بحرانی ارزیابی می‌شود.
  • کاوش خودران مبتنی بر مستندات و کنجکاوی — هر قابلیت مستندشده را تأیید می‌کند *و* سپس خارج از اسکریپت عمل می‌کند، موارد حاشیه‌ای را که کاربران واقعی با آن‌ها مواجه می‌شوند (ورودی‌های خالی، تعاملات سریع، مسیرهای مستندنشده) و هیچ مجموعه تست دستی‌ای پیش‌بینی نکرده است، بررسی می‌کند.
  • اوراکل بینایی — بینایی مکانیکی GoCV به‌علاوه LLM Vision API به معنای واقعی کلمه *رابط کاربری در حال اجرا روی صفحه را می‌بیند* و حالات خراب بصری را که تأییدیه‌های مبتنی بر توکن و ویژگی از کنارشان می‌گذرند، شناسایی می‌کند.
  • بانک‌های تست ساختاریافته، نه نثری — رشته‌های بانک، ساختار را توصیف می‌کنند و در زمان اجرا، پرسش‌های تولیدشده توسط LLM را هدایت می‌کنند (CONST-046)، بنابراین یک بانک واحد در تمام زبان‌ها کار می‌کند، به‌جای اینکه با ترجمه متن رابط کاربری از هم بپاشد.
  • تیکت‌های آماده برای خطوط لوله اصلاح AI — مسائل مارک‌داون خودکار با بسته کامل شواهد ضمیمه می‌شوند و آماده‌اند تا مستقیماً به یک عامل تعمیر پایین‌دستی تحویل داده شوند، نه یک انسان برای اولویت‌بندی.

به‌عنوان ستون کیفیتی اجباری (Constitution §11.4.169 زیرسیستم helix_qa را به‌عنوان یکی از انواع تست‌های الزامی نام می‌برد)، HelixQA به هر محصول در خانواده مجموعه‌ای یکسان از قابلیت‌ها را می‌دهد:

  • جلسات تضمین کیفیت خودران: یک دستور ساده helixqa autonomous --project … --platforms android,desktop,web یک عامل LLM به‌علاوه بینایی را رها می‌کند که برنامه‌های واقعی را بدون نظارت به سمت هدف پوشش‌دهی هدایت می‌کند و گزارش‌ها، تیکت‌ها و ویدئوها را بدون دخالت انسان تولید می‌کند.
  • بانک‌ها/مجموعه‌های تست: بانک‌های YAML (طبقه ۲۱۹ با حداقل ۳۰ مورد)، هدف‌گذاری‌شده برای پلتفرم‌ها، اولویت‌بندی‌شده و قابل ردیابی خط‌به‌خط به مستنداتی که تأیید می‌کنند.
  • شواهد ضبط‌شده: اسکرین‌شات‌ها، لاگ‌کت، ویدئو، استک تریس‌ها و یک جدول زمانی کامل — متمرکز و پیوندخورده از هر گزارش، به‌گونه‌ای که هر رأی را بتوان پس از اجرا بازپخش و حسابرسی کرد.
  • رأی‌های مستقل (§11.4.141 اصل استقلال): issuedetector و اوراکل بینایی آن که توسط LLM قدرت گرفته‌اند، رفتار برنامه در حال اجرا را مستقل از عاملی که آن را هدایت کرده است قضاوت می‌کنند و از این طریق، از خطای کلاسیک جلوگیری می‌کنند که در آن یک سیستم کار خود را صحیح ارزیابی می‌کند.
  • دروازه + چرخه جهش: make qa-all / make anti-bluff و challenges/scripts/helixqa_orchestrator_challenge.sh (۸ فاز، جهش داخلی §1.1) صداقت HelixQA را به‌طور مداوم اثبات می‌کنند — و به‌عمد هیچ راه گریزی مانند --skip-helixqa برای خاموش کردن این نظم تحت فشار ضرب‌العجل وجود ندارد.

محتوا

  • جلوگیری از مثبت‌های کاذب در خود تضمین کیفیت — ابزاری که ادعاهای دروغ را شناسایی می‌کند نباید خود به یکی از آنها تبدیل شود → هر گام با شواهد ثبت‌شده اعتبارسنجی می‌شود، تأیید بدون شواهد به‌عنوان نقص ثبت می‌شود نه تأیید، و یک مانیفست رفتار-محور هر قابلیت اعلام‌شده را به یک آزمون اجرایی پیوند می‌دهد (CONST-۰۳۵) تا هیچ قابلیتی بدون چیزی که آن را آزمایش کند ادعا نشود.
  • هدایت پلتفرم‌های ناهمگن با یک مغز واحد — اندروید، اندروید تی‌وی، وب و دسکتاپ هیچ مدل ورودی مشترکی ندارند → یک بسته navigator واحد بر روی اجراکننده‌های اقدامات خاص پلتفرم (ADB، Playwright، X۱۱) و آشکارسازهای کرش مخصوص هر پلتفرم (اندروید/وب/دسکتاپ) انتزاع ایجاد می‌کند، به‌طوری که منطق هماهنگی یک بار نوشته می‌شود و تفاوت‌های پلتفرمی در لبه‌ها باقی می‌مانند.
  • کاربردی کردن عوامل خودمختار، نه آشوبناک — یک LLM بدون نظارت در یک اپلیکیشن می‌تواند برای همیشه سرگردان بماند → LLMsVerifier مدل‌های مناسب را امتیازدهی و انتخاب می‌کند، LLMOrchestrator عوامل CLI بدون رابط کاربری (opencode، claude-code، gemini، junie، qwen-code) را مدیریت می‌کند، DocProcessor نقشه ویژگی‌ها را می‌سازد که به کاوش هدف می‌دهد، و VisionEngine هر تصمیم را بر اساس پیکسل‌های واقعی روی صفحه استوار می‌کند نه تخیل مدل.
  • بانک‌های ایمن از نظر محلی‌سازی — مجموعه‌ای که متن رابط کاربری انگلیسی را به‌صورت ثابت کدگذاری می‌کند در پانزده زبان شکست می‌خورد → بانک‌ها فقط ساختار را توصیف می‌کنند و متن پرسش کاربر در زمان اجرا از طریق LLM/منابع بارگذاری می‌شود (CONST-۰۴۶)، به‌طوری که یک بانک یک رفتار را صرف‌نظر از زبان تأیید می‌کند.
  • اثبات اینکه دروازه‌ها فریب نیستند — یک دروازه ضدفریب که خود نتواند شکست بخورد، فریب نهایی است → جهش‌های جفتی §۱.۱، ضبط شواهد یا ادعای ضدفریب یک نوع را حذف می‌کنند و از دروازه می‌خواهند که شکست بخورد، و یک مکانیزم جهش‌سنج از فرسایش خاموش این تضمین جلوگیری می‌کند.

  • هماهنگ‌کننده Go نسخه ۱.۲۴+ — *چرا:* تضمین کیفیت باید در هر جایی که محصولات اجرا می‌شوند قابل اجرا باشد، بنابراین یک باینری سریع، قابل حمل و استاتیک بهتر از جایگزین‌های سنگین از نظر زمان اجرا است؛ *چگونه:* یک 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) — *چرا:* قرارداد ضدفریب تنها زمانی واقعی است که هر تأیید با مدرک فیزیکی پشتیبانی شود؛ *چگونه:* اسکرین‌شات‌ها، لاگ‌کت، ویدئو و ردپای پشته در یک جدول زمانی SessionRecorder ضبط می‌شوند که هر گزارش به آن پیوند دارد.
  • جلسه خودمختار (pkg/autonomous، pkg/navigator، pkg/issuedetector) — *چرا:* تضمین کیفیت دستی جامع در چهار پلتفرم مقیاس‌پذیر نیست، بنابراین خود کاوش باید خودران باشد؛ *چگونه:* یک SessionCoordinator چهارمرحله‌ای به‌علاوه اجراکننده‌های اقدامات (ADB/Playwright/X۱۱) و آشکارسازهای باگ LLM که نقص‌های بصری، تجربه کاربری، دسترسی‌پذیری و عملکردی را پوشش می‌دهند.
  • زیرماژول‌های خارجی — *چرا:* استفاده مجدد و جداسازی (CONST-۰۵۱)، و — به‌طور حیاتی — جداسازی ناوبری از قضاوت؛ *چگونه:* LLMsVerifier (امتیازدهی مدل)، LLMOrchestrator (عوامل CLI بدون رابط کاربری)، VisionEngine (GoCV + LLM Vision)، DocProcessor (نقشه ویژگی/پوشش)، هر یک به‌عنوان مؤلفه‌ای مستقل مدیریت می‌شوند.
  • دروازه‌های ضدفریب + مکانیزم جهش‌سنج — *چرا:* برای پایبندی HelixQA به پیمان دقیق §۱.۱ که بر همه چیز اعمال می‌کند؛ *چگونه:* یک اسکن make anti-bluff به‌علاوه مانیفست رفتار-محور و مکانیزم جهش‌سنج، با helixqa_orchestrator_challenge.sh به‌عنوان اعتبارسنجی انتها به انتها در هشت مرحله.
  • ماتریس پوشش ۱۵ سطری (docs/test-coverage.md) — *چرا:* CONST-۰۵۰(ب) مجموعه‌ای بسته و کاملاً محاسبه‌شده از انواع آزمون را بدون شکاف الزامی می‌کند؛ *چگونه:* هر سطر به یک دارایی اجرایی مشخص و یک شکل خاص از شواهد ضبط‌شده متصل است، بنابراین پوشش یک واقعیت بررسی‌شده است نه یک ادعا.

محتوا

  • وضعیت: بتا. در حال توسعه فعال (بنر وضعیت README دورهٔ ۲۱۹). مطابق معیارهای ضد‌گول‌زدن خود عمل می‌کند.
  • مجوز: آپاچی ۲٫۰. نصب: go install digital.vasic.helixqa/cmd/helixqa@latest.

طبقهٔ اولویت: Helix-اصلی — یکی از ارکان اجباری کیفیت و ضد‌گول‌زدن در خانوادهٔ Helix که تأیید می‌کند ویژگی‌ها واقعاً کار می‌کنند.