التحقق الكامل من الإصدار

Full Release Validation هو الإطار الجامع للإصدار: نقطة الدخول اليدوية الوحيدة لإثبات ما قبل الإصدار. يجري معظم العمل في مهام سير عمل فرعية، بحيث يمكن إعادة تشغيل بيئة فاشلة دون إعادة بدء الإصدار بالكامل. شغّله من مرجع موثوق لمهمة سير العمل، وعادةً ما يكون main، ومرّر فرع الإصدار أو الوسم أو SHA الكامل للالتزام بوصفه ref:

gh workflow run full-release-validation.yml \
  --ref main \
  -f ref=release/YYYY.M.PATCH \
  -f provider=openai \
  -f mode=both \
  -f release_profile=stable

يقبل provider أيضًا anthropic أو minimax للإعداد الأولي عبر أنظمة التشغيل المختلفة ودورة الوكيل المتكاملة. تحل المهام الفرعية القابلة لإعادة الاستخدام أداة مهمة سير العمل المستدعاة من job.workflow_repository وjob.workflow_sha، بينما يحدد الإدخال ref المرشح الخاضع للاختبار. يتيح ذلك استخدام منطق التحقق الموثوق الحالي عند التحقق من فرع إصدار أو وسم أقدم. يجب أن تبلغ كل مهمة فرعية مُرسلة عن SHA مهمة سير العمل نفسه الخاص بتشغيل Full Release Validation الأب. إذا تحرك main بين عمليات إرسال الأب والمهام الفرعية، يفشل الإطار الجامع بصورة مغلقة حتى إذا نجحت المهمة الفرعية نفسها. للحصول على إثبات غير قابل للتغيير لالتزام محدد بدقة، استخدم pnpm ci:full-release --sha <target-sha>. ينشئ المساعد مرجعًا مؤقتًا release-ci/* مثبتًا على origin/main الموثوق الحالي، ويمرر SHA الهدف بوصفه ref المرشح فقط، ويعيد استخدام أدلة الهدف الدقيق الصارمة عند توفرها، ويحذف المرجع بعد التحقق. مرّر -f reuse_evidence=false لفرض تشغيل جديد أو --workflow-sha <trusted-main-sha> لاختيار التزام أقدم لمهمة سير العمل لا يزال يمكن الوصول إليه من origin/main الحالي. لا تنشئ مهمة سير العمل مراجع المستودع ولا تحدّثها بنفسها أبدًا. يشغّل release_profile=stable وrelease_profile=full دائمًا اختبار التحمل الشامل المباشر/عبر Docker. مرّر run_release_soak=true لتضمين مسارات اختبار التحمل نفسها مع ملف beta. يرفض النشر المستقر بيان تحقق لا يتضمن اختبار التحمل هذا وأدلة أداء المنتج المانعة. يبني قبول الحزمة عادةً حزمة tarball المرشحة من ref المحلول، بما في ذلك عمليات SHA الكامل المُرسلة باستخدام pnpm ci:full-release. بعد نشر إصدار تجريبي، مرّر release_package_spec=openclaw@YYYY.M.PATCH-beta.N لإعادة استخدام حزمة npm المنشورة عبر فحوص الإصدار وقبول الحزمة وأنظمة التشغيل المختلفة ومسار الإصدار عبر Docker وحزمة Telegram. استخدم package_acceptance_package_spec فقط عندما ينبغي لقبول الحزمة أن يثبت حزمة مختلفة عمدًا. يتبع مسار الحزمة المباشر لـ Plugin ‏Codex الحالة نفسها: تستمد قيم release_package_spec المنشورة codex_plugin_spec=npm:@openclaw/codex@<version>؛ وتحزم عمليات SHA/الأثر extensions/codex من المرجع المحدد؛ ويمكن للمشغّلين تعيين codex_plugin_spec مباشرةً لمصادر Plugin من النوع npm: أو npm-pack: أو git:. يمنح المسار موافقة تثبيت Codex CLI الصريحة التي يتطلبها ذلك Plugin، ثم يشغّل فحص Codex CLI التمهيدي ودورات وكيل OpenAI ضمن الجلسة نفسها.

المراحل العليا

عند rerun_group=all، تُشغّل أولًا مهمة Check for reusable validation evidence: تبحث عن أحدث تحقق كامل أخضر سابق لـ SHA الهدف نفسه تمامًا وملف الإصدار نفسه وإعداد اختبار التحمل الفعلي نفسه ومدخلات التحقق نفسها. عند وجود مثل هذه الأدلة، تُتخطى جميع المسارات ويعيد مدقق الإطار الجامع فحص الأثر الأب غير القابل للتغيير وعمليات تشغيل المهام الفرعية وسجلات الإرسال. هذا مخصص فقط للاستعادة بإعادة التشغيل للمرشح نفسه؛ ولا يسمح بإعادة الاستخدام عبر قيم SHA مختلفة. بالنسبة إلى مرشح متغير، أعد تشغيل كل بوابة حزمة أو أثر أو تثبيت أو Docker أو مزود تأثرت بذلك الفرق. مرّر reuse_evidence=false لفرض تشغيل كامل جديد. تعمل إعادة استخدام الأدلة فقط من main أو من مرجع release-ci/* أساسي مثبت بـ SHA يظل التزام مهمة سير العمل الخاص به ضمن سلسلة main الموثوقة؛ أما مراجع مهام سير العمل الأخرى فتشغّل المسارات المحددة من جديد. كذلك عند rerun_group=all، تبني مهمة Verify Docker runtime image assets هدف Docker المسمى runtime-assets باستخدام OPENCLAW_EXTENSIONS=diagnostics-otel,codex. تعمل بالتوازي مع المراحل الأخرى ويفرضها مدقق الإطار الجامع؛ ولم تعد المسارات تنتظرها قبل الإرسال. يتخطى rerun_group الأضيق هذا الفحص التمهيدي.

المرحلة	التفاصيل
حل الهدف	المهمة: `Resolve target ref` مهمة سير العمل الفرعية: لا توجد ما تثبته: تحل فرع الإصدار أو الوسم أو SHA الكامل للالتزام وتسجل المدخلات المحددة. إعادة التشغيل: أعد تشغيل الإطار الجامع إذا فشلت.
الفحص التمهيدي لأصول Docker	المهمة: `Verify Docker runtime image assets` مهمة سير العمل الفرعية: لا توجد ما تثبته: استمرار نجاح هدف بناء Docker المسمى `runtime-assets` قبل إرسال أي مرحلة أخرى. تعمل فقط عند `rerun_group=all`. إعادة التشغيل: أعد تشغيل الإطار الجامع باستخدام `rerun_group=all`.
Vitest والتكامل المستمر العادي	المهمة: `Run normal full CI` مهمة سير العمل الفرعية: `CI` ما تثبته: مخطط التكامل المستمر اليدوي الكامل مقابل المرجع الهدف، بما يشمل مسارات Linux Node، وأجزاء Plugins المضمّنة، وأجزاء عقود Plugins والقنوات، والتوافق مع Node 22، و`check-`، و`check-additional-`، وفحوص الدخان للأثر المبني، وفحوص التوثيق، وSkills الخاصة بـ Python، وWindows، وmacOS، وتدويل واجهة التحكم، وAndroid عبر الإطار الجامع. إعادة التشغيل: `rerun_group=ci`.
ما قبل إصدار Plugins	المهمة: `Run plugin prerelease validation` مهمة سير العمل الفرعية: `Plugin Prerelease` ما تثبته: فحوص Plugins الساكنة الخاصة بالإصدار فقط، وتغطية Plugins الوكيلية، وأجزاء الدفعات الكاملة لـ Plugins، ومسارات Docker لما قبل إصدار Plugins، وأثر `plugin-inspector-advisory` غير مانع لفرز التوافق. إعادة التشغيل: `rerun_group=plugin-prerelease`.
فحوص الإصدار	المهمة: `Run release/live/Docker/QA validation` مهمة سير العمل الفرعية: `OpenClaw Release Checks` ما تثبته: فحص دخان التثبيت، وفحوص الحزمة عبر أنظمة التشغيل المختلفة، وقبول الحزمة، وتكافؤ مختبر ضمان الجودة، وMatrix المباشر، وTelegram المباشر. تشغّل ملفات التعريف المستقرة والكاملة أيضًا مجموعات الاختبارات المباشرة/المتكاملة الشاملة وأجزاء مسار الإصدار عبر Docker؛ ويمكن لـ beta الاشتراك باستخدام `run_release_soak=true`. إعادة التشغيل: `rerun_group=release-checks` أو مُعرّف أضيق لفحوص الإصدار.
حزمة Telegram	المهمة: `Run package Telegram E2E` مهمة سير العمل الفرعية: `NPM Telegram Beta E2E` ما تثبته: اختبار Telegram متكامل ومركّز لحزمة منشورة عند تعيين `release_package_spec` أو `npm_telegram_package_spec`. يستخدم التحقق الكامل من المرشح بدلًا من ذلك اختبار Telegram المتكامل الأساسي لقبول الحزمة. إعادة التشغيل: `rerun_group=npm-telegram` مع `release_package_spec` أو `npm_telegram_package_spec`.
أداء المنتج	المهمة: `Run product performance evidence` مهمة سير العمل الفرعية: `OpenClaw Performance` ما تثبته: تشغيل أداء وفق ملف الإصدار (`profile=release`، و`repeat=3`، و`fail_on_regression=true`، و`publish_reports=false`) مقابل SHA الهدف. يبقى ناتج Kova في آثار مهمة سير العمل، ويجب أن تثبت المهمة الفرعية تخطي ناشر تقريرها. مطلوب (مانع) فقط عند `rerun_group=all` أو `rerun_group=performance`؛ وغير مطلوب لمجموعات إعادة التشغيل الأضيق. إعادة التشغيل: `rerun_group=performance`.
مدقق الإطار الجامع	المهمة: `Verify full validation` مهمة سير العمل الفرعية: لا توجد ما تثبته: يعيد فحص النتائج المسجلة لعمليات تشغيل المهام الفرعية ويلحق جداول أبطأ المهام من مهام سير العمل الفرعية. إعادة التشغيل: أعد تشغيل هذه المهمة فقط بعد إعادة تشغيل مهمة فرعية فاشلة حتى تصبح خضراء.

يرسل الإطار الجامع أداء المنتج دائمًا في وضع الأثر فقط. تسمح OpenClaw Performance بنشر التقارير فقط لعمليات التشغيل المجدولة أو للإرسال اليدوي الذي يعيّن publish_reports=true صراحةً. يجب أن يكتمل حارس وضع الأثر فقط بنجاح، بما يثبت أن مهمة الناشر ظلت متخطاة. تسجل الأدلة الجديدة والمعاد استخدامها controls.performanceReportPublication=artifact-only؛ ويرفض المدقق ومحدد إعادة الاستخدام الأدلة التي لا تحتوي على إثبات المهمة الفرعية للأداء المطبّع والمطابق. يرفع المدقق البيان الأساسي باسم full-release-validation-<run-id>-<run-attempt>. تتحقق أدوات الأدلة من معرّف الأثر وملخصه وعملية التشغيل المنتجة ومحاولة التشغيل قبل تنزيل معرّف الأثر المحدد بدقة. وتفرض حدًا أقصى على ملف ZIP المنزّل، وتتحقق من وحدات بايته مقابل ملخص REST من النوع sha256:، وتبث مدخل البيان المحدود الوحيد المسموح به دون استخراج الأرشيف. يبقى اسم مستعار ثابت مؤقتًا لمستهلكي النشر الأقدم. يفضّل المدقق دائمًا الأثر المؤهل بمحاولة التشغيل؛ وكإجراء انتقالي، يقبل الاسم الثابت فقط لمنتج بيان v2 من المحاولة الأولى. ويرفض ذلك الاسم القديم للمحاولات اللاحقة ولبيان v3. عند ref=main مع rerun_group=all، ولمراجع release/*، ولمراجع Tideclaw alpha، يحل تشغيل أحدث للإطار الجامع محل تشغيل أقدم له المرجع ومجموعة إعادة التشغيل نفسيهما. عند إلغاء الأب، تلغي أداة مراقبته أي مهمة سير عمل فرعية سبق أن أرسلها. لا تلغي عمليات التحقق الخاصة بالوسوم وSHA المثبت بعضها بعضًا.

مراحل فحوص الإصدار

تُعد OpenClaw Release Checks أكبر مهمة سير عمل فرعية. تحل الهدف مرة واحدة وتجهّز أثرًا مشتركًا باسم release-package-under-test عندما تحتاج إليه المراحل المتعلقة بالحزمة أو Docker.

المرحلة	التفاصيل
هدف الإصدار	المهمة: `Resolve target ref` سير العمل الداعم: لا يوجد الاختبارات: المرجع المحدد، وقيمة SHA المتوقعة الاختيارية، وملف التعريف، ومجموعة إعادة التشغيل، ومرشح مجموعة الاختبارات الحية المركزة. إعادة التشغيل: `rerun_group=release-checks`.
أداة الحزمة	المهمة: `Prepare release package artifact` سير العمل الداعم: لا يوجد الاختبارات: تحزم ملف tarball مرشحًا واحدًا أو تحدده، ثم ترفع `release-package-under-test` لعمليات التحقق اللاحقة الموجهة إلى الحزمة. إعادة التشغيل: مجموعة الحزمة المتأثرة أو الأنظمة المتعددة أو الاختبارات الحية/E2E.
اختبار تثبيت أولي	المهمة: `Run install smoke` سير العمل الداعم: `Install Smoke` الاختبارات: مسار التثبيت الكامل مع إعادة استخدام صورة الاختبار الأولي لملف Dockerfile الجذري، وتثبيت حزمة QR، واختبارات Docker الأولية للجذر وGateway، واختبارات Docker للمثبّت، واختبار أولي لموفر الصور عبر التثبيت العام باستخدام Bun. إعادة التشغيل: `rerun_group=install-smoke`.
الأنظمة المتعددة	المهمة: `cross_os_release_checks` سير العمل الداعم: `OpenClaw Cross-OS Release Checks (Reusable)` الاختبارات: مسارات التثبيت الجديد والترقية على Linux وWindows وmacOS للموفر والوضع المحددين، باستخدام ملف tarball المرشح إلى جانب حزمة مرجعية. إعادة التشغيل: `rerun_group=cross-os`.
اختبارات E2E للمستودع والبيئة الحية	المهمة: `Run repo/live E2E validation` سير العمل الداعم: `OpenClaw Live And E2E Checks (Reusable)` الاختبارات: اختبارات E2E للمستودع، وذاكرة التخزين المؤقت الحية، والبث عبر WebSocket في OpenAI، وأجزاء الموفر الحي الأصلي والـPlugin، وأدوات اختبار النموذج الحي والواجهة الخلفية وGateway المدعومة بـDocker والمحددة بواسطة `release_profile`. التشغيل: `run_release_soak=true` أو `release_profile=full` أو `rerun_group=live-e2e` المركزة. إعادة التشغيل: `rerun_group=live-e2e`، مع `live_suite_filter` اختياريًا.
مسار إصدار Docker	المهمة: `Run Docker release-path validation` سير العمل الداعم: `OpenClaw Live And E2E Checks (Reusable)` الاختبارات: أجزاء Docker لمسار الإصدار مقابل أداة الحزمة المشتركة. التشغيل: `run_release_soak=true` أو `release_profile=full` أو `rerun_group=live-e2e` المركزة. إعادة التشغيل: `rerun_group=live-e2e`.
قبول الحزمة	المهمة: `Run package acceptance` سير العمل الداعم: `Package Acceptance` الاختبارات: تجهيزات حزمة الـPlugin غير المتصلة، وتحديث الـPlugin، واختبار E2E القياسي لحزمة Telegram التي تستخدم محاكاة OpenAI، وعمليات التحقق من استمرار العمل بعد ترقية الإصدارات المنشورة باستخدام ملف tarball نفسه. تستخدم عمليات تحقق الإصدار الحاجبة أحدث إصدار مرجعي منشور افتراضيًا؛ وتتوسع اختبارات التحمل (`run_release_soak=true`) لتشمل آخر 4 إصدارات npm مستقرة بالإضافة إلى 3 إصدارات تاريخية مثبتة (`2026.4.23` و`2026.5.2` و`2026.4.15`)، وتُشغّل مقابل تجهيزات ترقية لمشكلات مُبلغ عنها. إعادة التشغيل: `rerun_group=package`.
بطاقة تقييم النضج	المهمة: `Render maturity scorecard release docs` سير العمل الداعم: `maturity-scorecard.yml` الاختبارات: تعرض وثائق بطاقة تقييم النضج الاستشارية مقابل المرجع المستهدف. لا تعمل إلا عند تمرير `run_maturity_scorecard=true`. إعادة التشغيل: `rerun_group=qa` مع `run_maturity_scorecard=true`.
تكافؤ ضمان الجودة	المهمة: `Run QA Lab parity lane` و`Run QA Lab parity report` سير العمل الداعم: مهام مباشرة الاختبارات: حزم تكافؤ وكيلية للنسخة المرشحة والنسخة المرجعية، ثم تقرير التكافؤ. إعادة التشغيل: `rerun_group=qa-parity` أو `rerun_group=qa`.
تكافؤ بيئة تشغيل ضمان الجودة	المهمة: `Run QA Lab runtime parity lane` سير العمل الداعم: مهمة مباشرة الاختبارات: مسار تكافؤ وكيلي لزوج بيئتي التشغيل `openclaw`/`codex` ‏(`pnpm openclaw qa suite --runtime-pair openclaw,codex`)، يتضمن مستوى قياسيًا، ومع `run_release_soak=true` مستوى اختبار تحمل. استشاري: لا تمنع حالات الفشل الفردية مدقق عمليات تحقق الإصدار. إعادة التشغيل: `rerun_group=qa-parity` أو `rerun_group=qa`.
تغطية أدوات بيئة تشغيل ضمان الجودة	المهمة: `Enforce QA Lab runtime tool coverage` سير العمل الداعم: مهمة مباشرة الاختبارات: الانحراف الديناميكي للأدوات بين `openclaw` و`codex` في المستوى القياسي لتكافؤ بيئة التشغيل (`pnpm openclaw qa coverage --tools`)، باستخدام مخرجات مسار تكافؤ بيئة تشغيل ضمان الجودة. حاجب: لا يمكن تجاوز هذه المهمة بصفة استشارية. إعادة التشغيل: `rerun_group=qa-parity` أو `rerun_group=qa`.
Matrix الحي لضمان الجودة	المهمة: `Run QA Lab live Matrix lane` سير العمل الداعم: مهمة مباشرة الاختبارات: ملف تعريف سريع لضمان جودة Matrix الحي في بيئة `qa-live-shared`. إعادة التشغيل: `rerun_group=qa-live` أو `rerun_group=qa`.
Telegram الحي لضمان الجودة	المهمة: `Run QA Lab live Telegram lane` سير العمل الداعم: مهمة مباشرة الاختبارات: ضمان جودة Telegram الحي باستخدام عقود إيجار بيانات اعتماد Convex CI. إعادة التشغيل: `rerun_group=qa-live` أو `rerun_group=qa`.
مدقق الإصدار	المهمة: `Verify release checks` سير العمل الداعم: لا يوجد الاختبارات: مهام تحقق الإصدار المطلوبة لمجموعة إعادة التشغيل المحددة. إعادة التشغيل: أعد التشغيل بعد نجاح المهام الفرعية المركزة.

أجزاء مسار إصدار Docker

تشغّل مرحلة مسار إصدار Docker هذه الأجزاء عندما يكون live_suite_filter فارغًا:

الجزء	التغطية
`core`	مسارات الاختبار الأولي الأساسية لمسار إصدار Docker.
`package-update-openai`	سلوك تثبيت/تحديث حزمة OpenAI، وتثبيت Codex عند الطلب، والتفاعلات الحية لـCodex Plugin، واستدعاءات أدوات Chat Completions.
`package-update-anthropic`	سلوك تثبيت حزمة Anthropic وتحديثها.
`package-update-core`	سلوك الحزمة والتحديث المحايد للموفر.
`plugins-runtime-plugins`	مسارات بيئة تشغيل الـPlugin التي تختبر سلوك الـPlugin.
`plugins-runtime-services`	مسارات بيئة تشغيل الـPlugin المدعومة بالخدمات والحية.
من `plugins-runtime-install-a` إلى `plugins-runtime-install-h`	دفعات تثبيت/تشغيل الـPlugin مقسمة للتحقق المتوازي من الإصدار.
`openwebui`	اختبار توافق أولي مع OpenWebUI معزول على مشغّل مخصص ذي قرص كبير عند طلبه.

استخدم docker_lanes=<lane[,lane]> الموجّه في سير العمل الحي/E2E القابل لإعادة الاستخدام عندما يفشل مسار Docker واحد فقط. تتضمن أدوات الإصدار أوامر إعادة تشغيل خاصة بكل مسار مع مدخلات لإعادة استخدام أداة الحزمة والصورة عند توفرها.

ملفات تعريف الإصدار

يتحكم release_profile أساسًا في نطاق الاختبارات المباشرة/المزوّدين ضمن فحوصات الإصدار. ولا يلغي CI الكامل المعتاد، أو الإصدار التجريبي المسبق للـ Plugin، أو اختبار التثبيت السريع، أو قبول الحزمة، أو مختبر ضمان الجودة. تُشغّل ملفات التعريف المستقرة والكاملة دائمًا تغطية شاملة لاختبارات E2E للمستودع/الاختبارات المباشرة واختبارات التحمّل لمسار إصدار Docker. ويمكن لملف التعريف التجريبي الاشتراك عبر run_release_soak=true. يوفّر قبول الحزمة اختبار Telegram E2E القياسي للحزمة لكل إصدار كامل مرشّح، لذلك لا تكرر المظلة أداة الاستطلاع المباشر هذه.

ملف التعريف	الاستخدام المقصود	تغطية الاختبارات المباشرة/المزوّدين المضمّنة
`beta`	أسرع اختبار سريع حاسم للإصدار.	المسار المباشر لـ OpenAI/النواة، ونماذج Docker المباشرة لـ OpenAI، ونواة Gateway الأصلية، وملف تعريف Gateway الأصلي لـ OpenAI، وPlugin الأصلي لـ OpenAI، وGateway المباشر لـ OpenAI على Docker.
`stable`	ملف تعريف الموافقة الافتراضي على الإصدار.	`beta` بالإضافة إلى اختبار Anthropic السريع، وGoogle، وMiniMax، والواجهة الخلفية، وحزمة الاختبارات المباشرة الأصلية، وواجهة CLI الخلفية المباشرة على Docker، وربط ACP على Docker، وحزمة Codex على Docker، وإعلان الوكيل الفرعي على Docker، وشريحة اختبار سريع لـ OpenCode Go.
`full`	مسح استشاري واسع.	`stable` بالإضافة إلى المزوّدين الاستشاريين، وشرائح Plugins المباشرة، وشرائح الوسائط المباشرة.

إضافات الملف الكامل فقط

يتخطى stable مجموعات الاختبارات التالية، بينما يضمّنها full:

المجال	التغطية الخاصة بالملف الكامل فقط
نماذج Docker المباشرة	OpenCode Go، وOpenRouter، وxAI، وZ.ai، وFireworks.
Gateway المباشر على Docker	المزوّدون الاستشاريون مقسّمون إلى شرائح DeepSeek/Fireworks، وOpenCode Go/OpenRouter، وxAI/Z.ai.
ملفات تعريف مزوّدي Gateway الأصلية	شرائح Anthropic الكاملة لـ Opus وSonnet/Haiku، وFireworks، وDeepSeek، وشرائح نماذج OpenCode Go الكاملة، وOpenRouter، وxAI، وZ.ai.
شرائح Plugins الأصلية المباشرة	Plugins من A إلى K، ومن L إلى N، والبقية من O إلى Z، وMoonshot، وxAI.
شرائح الوسائط الأصلية المباشرة	الصوت، وموسيقى Google، وموسيقى MiniMax، ومجموعات الفيديو من A إلى D.

يتضمن stable الاختبارين native-live-src-gateway-profiles-anthropic-smoke و native-live-src-gateway-profiles-opencode-go-smoke؛ بينما يستخدم full بدلًا منهما شرائح نماذج Anthropic وOpenCode Go الأوسع. ويمكن لعمليات إعادة التشغيل المركّزة الاستمرار في استخدام المعرّفين التجميعيين native-live-src-gateway-profiles-anthropic أو native-live-src-gateway-profiles-opencode-go.

عمليات إعادة التشغيل المركّزة

استخدم rerun_group لتجنب تكرار بيئات إصدار غير مرتبطة:

المعرّف	النطاق
`all`	جميع مراحل التحقق الكامل من الإصدار.
`ci`	العملية الفرعية اليدوية لـ CI الكامل فقط.
`plugin-prerelease`	العملية الفرعية للإصدار التجريبي المسبق للـ Plugin فقط.
`release-checks`	جميع مراحل فحوصات إصدار OpenClaw.
`install-smoke`	اختبار التثبيت السريع مرورًا بفحوصات الإصدار.
`cross-os`	فحوصات الإصدار عبر أنظمة التشغيل.
`live-e2e`	اختبارات E2E للمستودع/الاختبارات المباشرة والتحقق من مسار إصدار Docker.
`package`	قبول الحزمة.
`qa`	تكافؤ ضمان الجودة بالإضافة إلى مسارات ضمان الجودة المباشرة.
`qa-parity`	مسارات تكافؤ ضمان الجودة والتقرير فقط.
`qa-live`	Matrix وTelegram المباشران لضمان الجودة، بالإضافة إلى مسارات Discord وWhatsApp وSlack المشروطة عند تمكينها.
`npm-telegram`	اختبار Telegram E2E للحزمة المنشورة؛ يتطلب `release_package_spec` أو `npm_telegram_package_spec`.
`performance`	أدلة أداء المنتج فقط.

استخدم live_suite_filter مع rerun_group=live-e2e عند فشل مجموعة اختبارات مباشرة واحدة. تُعرّف معرّفات عوامل التصفية الصالحة في سير عمل الاختبارات المباشرة/E2E القابل لإعادة الاستخدام، ومنها docker-live-models، وlive-gateway-docker، وlive-gateway-anthropic-docker، وlive-gateway-google-docker، وlive-gateway-minimax-docker، وlive-gateway-advisory-docker، وlive-cli-backend-docker، وlive-acp-bind-docker، و live-codex-harness-docker. المعرّف live-gateway-advisory-docker هو معرّف إعادة تشغيل تجميعي لشرائح المزوّدين الثلاث، لذلك يظل يوزّع التنفيذ على جميع مهام Gateway الاستشارية في Docker. استخدم cross_os_suite_filter مع rerun_group=cross-os عند فشل مسار واحد عبر أنظمة التشغيل. يقبل عامل التصفية معرّف نظام تشغيل، أو معرّف مجموعة اختبارات، أو زوج نظام تشغيل/مجموعة اختبارات، مثل windows/packaged-upgrade أو windows أو packaged-fresh. تتضمن ملخصات الاختبارات عبر أنظمة التشغيل توقيتات لكل مرحلة لمسارات ترقية الحزم، وتطبع الأوامر طويلة التشغيل أسطر Heartbeat لكي يظهر التحديث العالق قبل انتهاء مهلة المهمة. تمنع إخفاقات فحوصات إصدار ضمان الجودة التحقق المعتاد من الإصدار. كما يمنع فحص تغطية أدوات وقت تشغيل ضمان الجودة (الانحراف الديناميكي للأدوات بين openclaw وcodex في المستوى القياسي) مدقق فحوصات الإصدار، رغم أن مسار تكافؤ وقت تشغيل ضمان الجودة الأساسي استشاري. وقد تظل عمليات Tideclaw alpha تعامل مسارات فحوصات الإصدار غير المرتبطة بسلامة الحزمة على أنها استشارية. عند استخدام release_profile=beta، تكون مجموعات اختبارات المزوّدين المباشرة ضمن Run repo/live E2E validation استشارية: إذ تتغير عمليات نشر نماذج الجهات الخارجية أثناء الإصدار، ولذلك يعرض الإصدار التجريبي إخفاقاتها كتحذيرات، بينما تبقي ملفات التعريف المستقرة والكاملة عليها كعوامل مانعة. عندما يطلب live_suite_filter صراحةً مسار ضمان جودة مباشرًا مشروطًا مثل Discord أو WhatsApp أو Slack، يجب تمكين متغير المستودع المطابق OPENCLAW_RELEASE_QA_*_LIVE_CI_ENABLED؛ وإلا يفشل التقاط الإدخال بدلًا من تخطي المسار بصمت. أعد التشغيل باستخدام rerun_group=qa أو qa-parity أو qa-live عندما تحتاج إلى أدلة حديثة لضمان الجودة.

الأدلة الواجب الاحتفاظ بها

احتفظ بملخص Full Release Validation بوصفه فهرسًا على مستوى الإصدار. فهو يربط معرّفات العمليات الفرعية ويتضمن جداول بأبطأ المهام. عند حدوث إخفاقات، افحص سير العمل الفرعي أولًا، ثم أعد تشغيل أصغر معرّف مطابق أعلاه. العناصر المفيدة:

release-package-under-test من OpenClaw Release Checks
عناصر مسار إصدار Docker ضمن .artifacts/docker-tests/
package-under-test الخاص بقبول الحزمة وعناصر قبول Docker
عناصر فحوصات الإصدار عبر أنظمة التشغيل لكل نظام تشغيل ومجموعة اختبارات
عناصر تكافؤ ضمان الجودة، وتكافؤ وقت التشغيل، وMatrix، وTelegram

ملفات سير العمل

.github/workflows/full-release-validation.yml
.github/workflows/openclaw-release-checks.yml
.github/workflows/openclaw-live-and-e2e-checks-reusable.yml
.github/workflows/plugin-prerelease.yml
.github/workflows/install-smoke.yml
.github/workflows/install-smoke-reusable.yml
.github/workflows/openclaw-cross-os-release-checks-reusable.yml
.github/workflows/package-acceptance.yml
.github/workflows/openclaw-performance.yml
.github/workflows/npm-telegram-beta-e2e.yml

Release notes

Maturity

Release process

Testing and CI

التحقق الكامل من الإصدار

المراحل العليا

مراحل فحوص الإصدار

أجزاء مسار إصدار Docker

ملفات تعريف الإصدار

إضافات الملف الكامل فقط

عمليات إعادة التشغيل المركّزة

الأدلة الواجب الاحتفاظ بها

ملفات سير العمل

​المراحل العليا

​مراحل فحوص الإصدار

​أجزاء مسار إصدار Docker

​ملفات تعريف الإصدار

​إضافات الملف الكامل فقط

​عمليات إعادة التشغيل المركّزة

​الأدلة الواجب الاحتفاظ بها

​ملفات سير العمل

المراحل العليا

مراحل فحوص الإصدار

أجزاء مسار إصدار Docker

ملفات تعريف الإصدار

إضافات الملف الكامل فقط

عمليات إعادة التشغيل المركّزة

الأدلة الواجب الاحتفاظ بها

ملفات سير العمل