OpenClawDocs
View as MarkdownView this page as plain textOpen in ChatGPTAsk questions about this pageOpen in ClaudeAsk questions about this page

Release and CI

سياسة الإصدار

يعرض OpenClaw حاليًا ثلاث قنوات تحديث موجّهة للمستخدمين:

  • stable: قناة الإصدار المُرقّى الحالية، التي لا تزال تُحلّ عبر npm latest حتى اكتمال المرحلة المنفصلة الخاصة بـ CLI/القناة
  • beta: وسوم الإصدارات التمهيدية التي تُنشر إلى npm beta
  • dev: الرأس المتحرك لـ main

وبشكل منفصل، يمكن لمشغّلي الإصدار نشر حزمة النواة للشهر المكتمل السابق إلى npm extended-stable، بدءًا من التصحيح 33. ويستمر مسار الإصدار النهائي العادي للشهر الحالي على npm latest؛ ولا يؤدي هذا الفصل في النشر من جانب المشغّل بحد ذاته إلى تغيير آلية حل قناة التحديث في CLI.

تُعد إصدارات Tideclaw alpha مسارًا داخليًا منفصلًا للإصدارات التمهيدية (وسم توزيع npm ‏alpha)، وتُغطى ضمن مدخلات سير عمل NPM وصناديق اختبار الإصدار.

تسمية الإصدارات

  • إصدار npm الشهري الممتد الاستقرار: YYYY.M.PATCH، مع PATCH >= 33، ووسم git ‏vYYYY.M.PATCH
  • إصدار نهائي يومي/عادي: YYYY.M.PATCH، مع PATCH < 33، ووسم git ‏vYYYY.M.PATCH
  • إصدار تصحيح احتياطي عادي: YYYY.M.PATCH-N، وسم git ‏vYYYY.M.PATCH-N
  • إصدار Beta تمهيدي: YYYY.M.PATCH-beta.N، وسم git ‏vYYYY.M.PATCH-beta.N
  • إصدار Alpha تمهيدي: YYYY.M.PATCH-alpha.N، وسم git ‏vYYYY.M.PATCH-alpha.N
  • لا تُضف أصفارًا بادئة إلى الشهر أو التصحيح مطلقًا
  • PATCH هو رقم تسلسلي لمسار الإصدار الشهري، وليس يومًا تقويميًا. تُقدّم الإصدارات النهائية العادية وإصدارات Beta المسار الحالي؛ ولا تستهلك وسوم Alpha وحدها رقم تصحيح Beta/الإصدار العادي ولا تقدّمه، لذا تجاهل وسوم Alpha القديمة المنفردة ذات أرقام التصحيح الأعلى عند اختيار مسار Beta أو مسار عادي.
  • تستخدم إصدارات Alpha/الليلية مسار التصحيح التالي غير المُصدر، وتزيد alpha.N فقط للإصدارات المتكررة. وبمجرد أن يصبح لذلك التصحيح إصدار Beta، تنتقل إصدارات Alpha الجديدة إلى التصحيح التالي.
  • إصدارات npm غير قابلة للتغيير: لا تحذف وسمًا منشورًا أو تعِد نشره أو استخدامه مطلقًا. أنشئ بدلًا من ذلك رقم الإصدار التمهيدي التالي أو التصحيح الشهري التالي.
  • يستمر latest في اتباع مسار npm العادي/اليومي الحالي؛ ويمثل beta هدف تثبيت Beta الحالي
  • يعني extended-stable حزمة npm المدعومة للشهر السابق، بدءًا من التصحيح 33؛ والتصحيح 34 وما بعده إصدارات صيانة على ذلك المسار الشهري
  • تُنشر الإصدارات النهائية العادية وإصدارات التصحيح العادية إلى npm beta افتراضيًا؛ ويمكن لمشغّلي الإصدار استهداف latest صراحةً، أو ترقية إصدار Beta خضع للتدقيق لاحقًا
  • ينشر المسار الشهري المخصص الممتد الاستقرار حزمة النواة على npm وكل Plugin رسمي قابل للنشر على npm بالإصدار نفسه تمامًا. ولا ينشر Plugins إلى ClawHub، ولا ينشر عناصر macOS أو Windows، أو إصدار GitHub، أو وسوم توزيع المستودعات الخاصة، أو صور Docker، أو عناصر الأجهزة المحمولة، أو تنزيلات الموقع الإلكتروني.
  • يشحن كل إصدار نهائي عادي حزمة npm وتطبيق macOS وملف APK مستقلًا وموقّعًا لنظام Android ومثبّتات Windows Hub الموقّعة معًا. تتحقق إصدارات Beta عادةً من مسار npm/الحزمة وتنشره أولًا، بينما تُحجز عمليات بناء التطبيق الأصلي وتوقيعه وتوثيقه وترقيته للإصدار النهائي العادي ما لم يُطلب ذلك صراحةً.

وتيرة الإصدار

  • تنتقل الإصدارات بدءًا من Beta؛ ولا يتبعها stable إلا بعد التحقق من أحدث إصدار Beta
  • ينشئ المشرفون الإصدارات عادةً من فرع release/YYYY.M.PATCH مُنشأ من main الحالي، كي لا تعيق عمليات التحقق من الإصدار وإصلاحاته التطوير الجديد على main
  • إذا دُفع وسم Beta أو نُشر وكان يحتاج إلى إصلاح، ينشئ المشرفون وسم -beta.N التالي بدلًا من حذف الوسم القديم أو إعادة إنشائه
  • تقتصر إجراءات الإصدار التفصيلية والموافقات وبيانات الاعتماد وملاحظات الاسترداد على المشرفين

نشر npm الشهري الممتد الاستقرار فقط

هذا استثناء مخصص من إجراء الإصدار العادي أدناه. بالنسبة إلى شهر مكتمل YYYY.M، أنشئ extended-stable/YYYY.M.33؛ وانشر vYYYY.M.33 وتصحيحات الصيانة اللاحقة من الفرع نفسه. يجب أن يحدد وسم الإصدار وطرف الفرع ونسخة العمل وإصدار الحزمة والفحص المسبق لـ npm وتشغيل التحقق الكامل من الإصدار الالتزام نفسه. ويجب أن يحتوي main المحمي بالفعل على إصدار نهائي لشهر تقويمي لاحق حصرًا، أقل من التصحيح 33؛ وتظل تصحيحات الصيانة مؤهلة بعد تقدم main بأكثر من شهر واحد.

على فرع extended-stable المحدد تمامًا، ارفع إصدار الحزمة الجذرية إلى YYYY.M.P، وشغّل pnpm release:prep، وتحقق من أن كل حزمة امتداد قابلة للنشر لها الإصدار نفسه. ثبّت جميع التغييرات المُنشأة وادفعها، وأنشئ وادفع الوسم غير القابل للتغيير vYYYY.M.P عند ذلك الالتزام، وسجّل SHA الكامل الناتج. تستهلك مسارات العمل هذه الشجرة المُعدّة؛ ولا ترفع الإصدارات أو تزامنها نيابةً عنك.

شغّل الفحص المسبق لـ npm والتحقق الكامل من الإصدار من طرف ذلك الفرع المُعدّ نفسه تمامًا، ثم احفظ معرّفي التشغيل ومحاولة تشغيل التحقق الكامل من الإصدار الناجحة:

bash
gh workflow run openclaw-npm-release.yml \  --ref extended-stable/YYYY.M.33 \  -f tag=vYYYY.M.P \  -f preflight_only=true \  -f npm_dist_tag=extended-stable gh workflow run full-release-validation.yml \  --ref extended-stable/YYYY.M.33 \  -f ref=extended-stable/YYYY.M.33 \  -f release_profile=stable

release_profile=stable هو ملف تعريف عمق التحقق الحالي؛ وهو منفصل عن وسم توزيع npm ‏extended-stable ولم يتغير عن قصد.

بعد نجاح كلا التشغيلين، انشر كل Plugin رسمي قابل للنشر على npm من طرف الفرع نفسه تمامًا. يجب أن يكون التصحيح P مساويًا لـ 33 أو أكبر. مرّر SHA الكامل للإصدار بصفته ref، وانتظر اكتمال المصفوفة والقراءة الراجعة من السجل، ثم احفظ معرّف تشغيل Plugin NPM Release الناجح:

bash
RELEASE_SHA="$(git rev-parse HEAD)"gh workflow run plugin-npm-release.yml \  --ref extended-stable/YYYY.M.33 \  -f publish_scope=all-publishable \  -f ref="$RELEASE_SHA" \  -f npm_dist_tag=extended-stable

يستخدم سير العمل قائمة حزم all-publishable المُعدّة العادية، بما فيها الحزم التي لم يتغير مصدرها. ويتحقق من كل حزمة محددة ومن كل وسم Plugin ‏extended-stable قبل النجاح. إذا فشل تشغيل جزئي، فأعد تشغيل الأمر نفسه: يُعاد استخدام الحزم المنشورة بالفعل، وتُسوّى وسوم Plugin المفقودة أو القديمة ضمن بيئة إصدار npm، وتظل القراءة الراجعة النهائية تغطي مجموعة الحزم الكاملة.

بعد نجاح سير عمل Plugin واستعداد بيئة إصدار npm، انشر حزمة tarball الخاصة بالفحص المسبق للنواة نفسها تمامًا. يتحقق نشر النواة من أن تشغيل Plugin المشار إليه هو completed/success على الفرع القياسي نفسه وبـ SHA المصدر نفسه تمامًا:

bash
gh workflow run openclaw-npm-release.yml \  --ref extended-stable/YYYY.M.33 \  -f tag=vYYYY.M.P \  -f preflight_only=false \  -f npm_dist_tag=extended-stable \  -f preflight_run_id=<npm-preflight-run-id> \  -f full_release_validation_run_id=<full-validation-run-id> \  -f full_release_validation_run_attempt=<full-validation-run-attempt> \  -f plugin_npm_run_id=<plugin-npm-run-id>

بالنسبة إلى تفرع أو تجربة غير إنتاجية لا يمكنها عمدًا استيفاء سياسة الشهر الخاصة بـ .33 الشهرية أو main المحمي، أضف -f bypass_extended_stable_guard=true إلى كل من إرسالَي الفحص المسبق لـ npm والنشر. القيمة الافتراضية هي false. لا يُقبل التجاوز إلا مع npm_dist_tag=extended-stable ويُسجّل في ملخص سير العمل. وهو لا يتجاوز مرجع سير العمل القياسي extended-stable/YYYY.M.33، ولا تطابق طرف الفرع/الوسم/نسخة العمل، ولا صيغة الوسم النهائي، ولا تطابق إصدار الحزمة/الوسم، ولا هوية التشغيل والبيان المشار إليهما، ولا أصل حزمة tarball، ولا موافقة البيئة، ولا القراءة الراجعة من السجل، ولا دليل إصلاح المحدد.

يتحقق سير عمل النشر من هويات الفحص المسبق والتحقق وتشغيل Plugin المشار إليها، ومن ملخص حزمة tarball المُعدّة، ومن محددات سجل النواة. أكد النتيجة بصورة مستقلة بعد نجاح سير العمل:

bash
npm view [email protected] version --userconfig "$(mktemp)"npm view openclaw@extended-stable version --userconfig "$(mktemp)"

يجب أن يُرجع كلا الأمرين YYYY.M.P. إذا نجح النشر لكن فشلت القراءة الراجعة للمحدد، فلا تعِد نشر إصدار الحزمة غير القابل للتغيير. استخدم أمر الإصلاح الوحيد npm dist-tag add [email protected] extended-stable المطبوع في ملخص التشغيل الدائم لسير العمل الفاشل، ثم كرر القراءتين الراجعتين المستقلتين. ويُعد الرجوع إلى المحدد السابق قرارًا منفصلًا للمشغّل، وليس مسار إصلاح القراءة الراجعة.

تحدد وثائق الدعم العامة في البداية Slack وDiscord وCodex بوصفها أسطح Plugin مشمولة ضمن extended-stable. وتمثل تلك القائمة بيان دعم، لا قائمة سماح في شفرة الإصدار: يتبع كل Plugin رسمي قابل للنشر على npm مسار النشر نفسه بالإصدار المطابق تمامًا.

تظل قائمة التحقق العادية أدناه مسؤولة عن Beta وlatest وإصدار GitHub وPlugins وmacOS وWindows ومنشورات المنصات الأخرى. لا تشغّل تلك الخطوات لمسار extended-stable المخصص لـ npm فقط.

قائمة تحقق مشغّل الإصدار العادي

تمثل قائمة التحقق هذه الشكل العام لسير الإصدار. وتظل بيانات الاعتماد الخاصة والتوقيع والتوثيق واسترداد وسم التوزيع وتفاصيل الرجوع الطارئ محصورة في دليل تشغيل الإصدار الخاص بالمشرفين.

  1. ابدأ من main الحالي: اسحب أحدث التغييرات، وتأكد من دفع الالتزام المستهدف، وتأكد من أن CI الخاص بـ main أخضر بما يكفي لإنشاء فرع منه.

  2. أنشئ release/YYYY.M.PATCH من ذلك الالتزام. عمليات النقل العكسي اختيارية؛ طبّق فقط المجموعة التي حددها المشغّل. ارفع كل موضع إصدار مطلوب، وشغّل pnpm release:prep، وأكمل إصلاحات الإصدار وعمليات النقل الأمامي المطلوبة، وراجع src/plugins/compat/registry.ts إلى جانب src/commands/doctor/shared/deprecation-compat.ts.

  3. ثبّت الالتزام المكتمل للمنتج والسابق لسجل التغييرات بصفته Code SHA. شغّل الفحص المسبق الحتمي للمصدر، ثم استخدم node scripts/full-release-validation-at-sha.mjs --sha <code-sha> --target-ref release/YYYY.M.PATCH. يؤدي ذلك إلى تثبيت أدوات سير العمل الموثوقة بينما تستهدف مصفوفة Vitest وDocker وQA والحزم والأداء الكاملة Code SHA نفسه تمامًا.

  4. صنّف الإخفاقات قبل التحرير. ينشئ إخفاق المنتج/الشفرة Code SHA جديدًا ويتطلب تحققًا كاملًا أخضر لذلك الـ SHA. أما إخفاق سير العمل أو أداة الاختبار أو بيانات الاعتماد أو الموافقة أو البنية التحتية، فيُصلح ضمن السطح المالك له ويُعاد تشغيله مقابل Code SHA نفسه.

  5. بعد أن يصبح Code SHA أخضر فقط، أنشئ قسم CHANGELOG.md العلوي من طلبات السحب المدمجة والالتزامات المباشرة منذ آخر وسم إصدار مشحون يمكن الوصول إليه. اجعل الإدخالات موجّهة للمستخدم وأزل تكرارها. عندما يعيد وسم مشحون متشعب أو نقل أمامي لاحق ربط طلبات سحب سبق إصدارها، مرّره صراحةً بصفته --shipped-ref.

  6. ثبّت CHANGELOG.md فقط. هذا الالتزام هو Release SHA. يجب أن يكون الفرق الكامل من Code SHA إلى Release SHA هو CHANGELOG.md تمامًا؛ وأي مسار آخر متغير يعيد الإصدار إلى الخطوة 2.

  7. شغّل التحقق الكامل من الإصدار المثبّت بـ SHA لصالح Release SHA مع تمكين إعادة استخدام الأدلة. يجب أن يسجّل الأصل الخفيف changelog-only-release-v1، وأن يشير إلى Code SHA الأخضر، وألا يرسل أي مسارات فرعية للمنتج. يعيد ذلك استخدام دليل المنتج؛ ولا يعيد استخدام بايتات الحزمة.

  8. شغّل OpenClaw NPM Release مع preflight_only=true مقابل Release SHA/الوسم. احفظ preflight_run_id الناجح. يؤدي ذلك إلى بناء بايتات الحزمة نفسها التي تتضمن سجل التغييرات النهائي والتحقق منها.

  9. ضع وسمًا على Release SHA، ثم شغّل مساعد الإصدار المرشح باستخدام أصل التحقق الناجح الخاص بـ Release-SHA والفحص المسبق لـ npm بدلًا من إرسال أي منهما مجددًا:

    bash
    pnpm release:candidate -- \  --tag vYYYY.M.PATCH-beta.N \  --full-release-run <release-sha-validation-run-id> \  --npm-preflight-run <preflight-run-id> \  --skip-dispatch

    للإصدار المستقر، مرّر أيضًا --windows-node-tag vX.Y.Z. تتحقق الأداة المساعدة من مصدر ملاحظات الإصدار، وبايتات الفحص المسبق لـ npm، وإثبات التثبيت/التحديث عبر Parallels، وإثبات حزمة Telegram، وخطط نشر الإضافات، ثم تطبع أمر النشر.

    يرسل OpenClaw Release Publish حزم الإضافات المحددة أو جميع الحزم القابلة للنشر إلى npm، ويرسل المجموعة نفسها إلى ClawHub بالتوازي، ثم يرقّي عنصر الفحص المسبق المُعَدّ لـ OpenClaw على npm باستخدام وسم التوزيع المطابق بمجرد نجاح نشر الإضافات على npm. تظل نسخة الإصدار العاملة جذر المنتج/البيانات، بينما يُنفَّذ التخطيط والتحقق النهائي من نسخة سير العمل الموثوقة المطابقة تمامًا للمصدر، بحيث لا يمكن لالتزام إصدار أقدم استخدام أدوات إصدار متقادمة دون تنبيه. قبل بدء أي عملية نشر فرعية، يُصيّر نص إصدار GitHub الدقيق ويخزّنه مؤقتًا. عندما يتسع قسم CHANGELOG.md المطابق الكامل ضمن حد GitHub البالغ 125,000 حرف وسقف الأمان المطابق للمُصيّر البالغ 125,000 بايت، تتضمن الصفحة قسم ## YYYY.M.PATCH نفسه تمامًا، بما في ذلك عنوانه. عندما لا يتسع القسم المصدر، تحتفظ الصفحة بالملاحظات التحريرية المجمعة نفسها تمامًا وتستبدل سجل المساهمات المتجاوز للحجم برابط ثابت إلى السجل الكامل في CHANGELOG.md المثبّت بالوسم؛ ولا تُنشر أبدًا سجلات جزئية أو نقاط تعداد مبتورة. يختار سير العمل النص الكامل أو المختصر قبل إضافة ### Release verification؛ وإذا كان ذيل الإثبات سيتجاوز الحد، فإنه يحتفظ بالنص الأساسي ويعتمد بدلًا من ذلك على الأدلة المرفقة غير القابلة للتغيير. تصبح الإصدارات المستقرة المنشورة إلى npm latest أحدث إصدار على GitHub، بينما تُنشأ إصدارات الصيانة المستقرة المحتفَظ بها على npm beta باستخدام GitHub latest=false. يرفع سير العمل أيضًا أدلة تبعيات الفحص المسبق، وبيان التحقق الكامل، وأدلة التحقق من السجل بعد النشر إلى إصدار GitHub للاستجابة لحوادث ما بعد الإصدار. يطبع معرّفات عمليات التشغيل الفرعية فورًا، ويوافق تلقائيًا على بوابات بيئة الإصدار التي يُسمح لرمز سير العمل بالموافقة عليها، ويلخّص المهام الفرعية الفاشلة مع نهايات السجلات، وينشئ صفحة إصدار GitHub المسودة مقدمًا ويرقّي أصول Windows وAndroid بالتزامن مع نشر OpenClaw على npm، ويُتمّ صفحة الإصدار وأدلة التبعيات بمجرد نجاح تلك المراحل، وينتظر ClawHub كلما كان OpenClaw يُنشر على npm، ثم يشغّل أداة التحقق التجريبي من الفرع الرئيسي الموثوق ويرفع أدلة ما بعد النشر لإصدار GitHub، وحزمة npm، وحزم الإضافات المحددة على npm، وحزم ClawHub المحددة، ومعرّفات عمليات تشغيل سير العمل الفرعية، ومعرّف تشغيل NPM Telegram الاختياري. تتطلب أداة التحقق التمهيدية لـ ClawHub مسار سير العمل وSHA المطابقين تمامًا للفرع الرئيسي الموثوق، ومحاولات تشغيل المُنتِج والطرفية، وSHA الإصدار، ومجموعة الحزم المطلوبة، ومجموعة خصائص عنصر الحزمة غير القابلة للتغيير، وعنصر القراءة الراجعة الطرفية من السجل؛ ولا تُقبل عملية تشغيل ناجحة قديمة من مرجع الإصدار.

    ثم شغّل اختبار قبول الحزمة بعد النشر على حزمة [email protected] أو openclaw@beta المنشورة. إذا احتاج إصدار أولي مدفوع أو منشور إلى إصلاح، فأصدر رقم الإصدار الأولي المطابق التالي؛ ولا تحذف الإصدار القديم أو تعِد كتابته أبدًا.

  10. عند فشل محاولة نشر، أبقِ SHA الإصدار دون تغيير ما لم يثبت الفشل وجود عيب في المنتج أو سجل التغييرات. استأنف العمليات الفرعية والعناصر غير القابلة للتغيير التي نجحت؛ ولا تعِد أبدًا بناء أو نشر إصدار حزمة سبق أن نجح.

  11. بالنسبة إلى الإصدار المستقر، لا تتابع إلا بعد أن تتوافر للإصدار التجريبي أو الإصدار المرشح المدقَّق أدلة التحقق المطلوبة. يمر نشر npm المستقر أيضًا عبر OpenClaw Release Publish، مع إعادة استخدام عنصر الفحص المسبق الناجح عبر preflight_run_id. يتطلب استعداد إصدار macOS المستقر أيضًا حزم .zip و.dmg و.dSYM.zip، وتحديث appcast.xml على main؛ وينشر سير عمل macOS موجز تحديث التطبيق الموقّع إلى main العام تلقائيًا بعد التحقق من أصول الإصدار، أو يفتح/يحدّث طلب سحب لموجز تحديث التطبيق إذا منعت حماية الفرع الدفع المباشر. يتطلب استعداد Windows Hub المستقر الأصول الموقّعة OpenClawCompanion-Setup-x64.exe وOpenClawCompanion-Setup-arm64.exe وOpenClawCompanion-SHA256SUMS.txt في إصدار OpenClaw على GitHub. مرّر وسم إصدار openclaw/openclaw-windows-node الموقّع الدقيق بوصفه windows_node_tag، وخريطة ملخصات المثبّت التي وافق عليها المرشح بوصفها windows_node_installer_digests؛ يحتفظ OpenClaw Release Publish بمسودة الإصدار، ويرسل Windows Node Release، ويتحقق من الأصول الثلاثة كلها قبل النشر.

  12. بعد النشر، شغّل أداة التحقق بعد النشر لـ npm، واختبار Telegram الشامل الاختياري المستقل لحزمة npm المنشورة عندما تحتاج إلى إثبات القناة بعد النشر، وترقية وسم التوزيع عند الحاجة، وتحقق من صفحة إصدار GitHub المُنشأة، ونفّذ خطوات إعلان الإصدار، ثم أكمل إغلاق الفرع الرئيسي للإصدار المستقر قبل اعتبار الإصدار المستقر مكتملًا.

إغلاق الفرع الرئيسي للإصدار المستقر

لا يكتمل النشر المستقر حتى يحمل main حالة الإصدار المنشور الفعلية.

  1. ابدأ من أحدث main جديد. راجع release/YYYY.M.PATCH مقارنةً به وانقل إلى الأمام الإصلاحات الفعلية غير الموجودة في main. لا تدمج دون تمحيص محولات التوافق أو الاختبار أو التحقق الخاصة بالإصدار فقط في main الأحدث.
  2. للمسار المعتاد، اضبط main على الإصدار المستقر المنشور. قد يستخدم الإغلاق المتأخر main بعد تقدمه إلى إصدار OpenClaw CalVer مستقر لاحق؛ لا تخفّض إصدار دورة إصدار بدأت بالفعل لمجرد إغلاق الإصدار السابق. تظل أداة التحقق تتطلب قسم سجل التغييرات وإدخال موجز تحديث التطبيق المطابقين تمامًا للإصدار المنشور، وتسجّل إصدار وSHA main الفعليين. شغّل pnpm release:prep بعد أي تغيير في إصدار الجذر، ثم pnpm deps:shrinkwrap:generate.
  3. اجعل قسم ## YYYY.M.PATCH في CHANGELOG.md على main مطابقًا تمامًا لفرع الإصدار الموسوم. أدرج تحديث appcast.xml المستقر عندما ينشر إصدار Mac واحدًا.
  4. لا تضف YYYY.M.PATCH+1 أو إصدارًا تجريبيًا أو قسم سجل تغييرات مستقبليًا فارغًا إلى main حتى يبدأ المشغّل دورة الإصدار تلك صراحةً.
  5. شغّل pnpm release:generated:check وpnpm deps:shrinkwrap:check وOPENCLAW_TESTBOX=1 pnpm check:changed. ادفع التغييرات، ثم تحقق من أن origin/main يتضمن الإصدار المنشور وسجل التغييرات قبل اعتبار الإصدار المستقر مكتملًا.
  6. حافظ على تحديث متغيرَي المستودع RELEASE_ROLLBACK_DRILL_ID وRELEASE_ROLLBACK_DRILL_DATE بعد كل تمرين تراجع خاص.

يبدأ OpenClaw Stable Main Closeout من دفعة main التي تحمل الإصدار المنشور وسجل التغييرات وموجز تحديث التطبيق بعد النشر المستقر. يقرأ أدلة ما بعد النشر غير القابلة للتغيير لربط الوسم المنشور بعمليتَي التحقق الكامل من الإصدار والنشر، ثم يتحقق من حالة الفرع الرئيسي المستقر والإصدار وفترة الاستقرار الإلزامية للإصدار المستقر وأدلة الأداء المانعة. ويرفق بيان إغلاق غير قابل للتغيير ومجموعه الاختباري بإصدار GitHub. يتخطى مشغّل الدفع التلقائي الإصدارات القديمة التي تسبق أدلة ما بعد النشر غير القابلة للتغيير، ولا يعتبر هذا التخطي أبدًا إغلاقًا مكتملًا.

يتطلب الإغلاق الكامل كِلا العنصرين ومجموعًا اختباريًا مطابقًا. يعيد البيان الجزئي تشغيل SHA main المسجّل وتمرين التراجع لإعادة إنشاء بايتات متطابقة، ثم يرفق المجموع الاختباري المفقود؛ وتظل المجموعة غير الصالحة، أو المجموع الاختباري من دون بيان، مانعة. تُتخطى عملية تشغيل مُشغَّلة بالدفع من دون متغيرات مستودع تمرين التراجع من دون إكمال الإغلاق؛ ويظل سجل التمرين المفقود أو الذي يزيد عمره على 90 يومًا مانعًا للإغلاق اليدوي المدعوم بالأدلة. تظل أوامر الاسترداد الخاصة في دليل التشغيل المخصص للمشرفين فقط. استخدم الإرسال اليدوي فقط لإصلاح أو إعادة تشغيل إغلاق مستقر مدعوم بالأدلة.

إذا فشلت العملية الأصلية لنشر الإصدار فقط بعد إرفاق أدلة npm/الإضافات غير القابلة للتغيير، فأصلح كل أصل مستقر للمنصات وانشره أولًا. بعد ذلك، يمكن لمشرف إرسال الإغلاق يدويًا باستخدام allow_failed_publish_recovery=true؛ ولا يقبل هذا الوضع إلا عملية أصلية فاشلة مكتملة، ويتطلب بالإضافة إلى ذلك عقود أصول Android وWindows الدقيقة، وملخصات GitHub من نوع SHA-256، والتحقق من المجموع الاختباري، ومصدر Android، وترقية Windows ناجحة أرسلتها العملية الأصلية وتطابق فيها فحوص Authenticode والملخصات التي وافق عليها المرشح المثبّتات المنشورة، إلى جانب فحوص macOS/موجز تحديث التطبيق المعتادة. لا يفعّل الإغلاق التلقائي عند الدفع وضع الاسترداد هذا أبدًا.

يمكن لوسم تصحيح احتياطي قديم إعادة استخدام أدلة الحزمة الأساسية فقط عندما يُحل وسم التصحيح إلى الالتزام المصدري نفسه لوسم الإصدار المستقر الأساسي. يعيد إصدار Android الخاص به استخدام APK المتحقق منه لوسم الأساس ويضيف مصدرًا لوسم التصحيح. يجب أن ينشر التصحيح ذو المصدر المختلف أدلة حزمته الخاصة ويتحقق منها، وأن يستخدم versionCode أعلى لـ Android.

الفحص المسبق للإصدار

  • شغّل pnpm check:test-types قبل الفحص المسبق للإصدار حتى تظل اختبارات TypeScript مشمولة خارج بوابة pnpm check المحلية الأسرع.

  • شغّل pnpm check:architecture قبل الفحص المسبق للإصدار حتى تكون فحوص دورات الاستيراد الأوسع وحدود البنية ناجحة خارج البوابة المحلية الأسرع.

  • شغّل pnpm build && pnpm ui:build قبل pnpm release:check حتى تتوافر عناصر إصدار dist/* المتوقعة وحزمة واجهة Control UI لخطوة التحقق من الحزمة.

  • شغّل pnpm release:prep بعد زيادة إصدار الجذر وقبل وضع الوسم. فهو يشغّل كل مولّد إصدار حتمي يشيع انحرافه بعد تغيير في الإصدار/الإعداد/API: إصدارات الإضافات، وملفات تقليص npm، وقائمة الإضافات، ومخطط الإعداد الأساسي، وبيانات إعداد القنوات المضمّنة، وخط أساس وثائق الإعداد، وصادرات Plugin SDK، وخط أساس API لـ Plugin SDK. يعيد pnpm release:check تشغيل وسائل الحماية هذه في وضع الفحص (بالإضافة إلى فحص ميزانية سطح Plugin SDK) ويبلغ عن كل حالات فشل انحراف العناصر المُنشأة في مرور واحد قبل تشغيل فحوص إصدار الحزمة.

  • تحدّث مزامنة إصدارات الإضافات افتراضيًا حزمة تشغيل @openclaw/ai القابلة للنشر، وإصدارات حزم الإضافات الرسمية، والحدود الدنيا الموجودة في openclaw.compat.pluginApi إلى إصدار OpenClaw. تعامل مع هذا الحقل على أنه الحد الأدنى لـ API الخاص بـ Plugin SDK/بيئة التشغيل، وليس مجرد نسخة من إصدار الحزمة: بالنسبة إلى إصدارات الإضافات فقط التي يُقصد أن تظل متوافقة مع مضيفي OpenClaw الأقدم، أبقِ الحد الأدنى عند أقدم API مضيف مدعوم ووثّق هذا الاختيار في إثبات إصدار الإضافة.

  • شغّل سير العمل اليدوي Full Release Validation قبل الموافقة على الإصدار لبدء جميع صناديق اختبارات ما قبل الإصدار من نقطة دخول واحدة. يقبل فرعًا أو وسمًا أو SHA التزام كاملًا، ويرسل CI يدويًا، ويرسل OpenClaw Release Checks لمسارات اختبار التثبيت السريع، وقبول الحزمة، وفحوص الحزمة عبر أنظمة التشغيل، وتكافؤ QA Lab، وMatrix، وTelegram. تتضمن عمليات التشغيل المستقرة والكاملة دائمًا اختبارات live/E2E شاملة وفترة استقرار لمسار إصدار Docker؛ ويُحتفظ بـ run_release_soak=true لفترة استقرار تجريبية صريحة. يوفر قبول الحزمة اختبار Telegram الشامل الأساسي للحزمة أثناء التحقق من المرشح، مما يتجنب تشغيل مستطلع مباشر متزامن ثانٍ.

    قدّم release_package_spec بعد نشر إصدار تجريبي لإعادة استخدام حزمة npm المنشورة عبر فحوص الإصدار، وقبول الحزمة، واختبار Telegram الشامل للحزمة من دون إعادة بناء أرشيف الإصدار. قدّم npm_telegram_package_spec فقط عندما ينبغي أن يستخدم Telegram حزمة منشورة مختلفة عن بقية التحقق من الإصدار. قدّم package_acceptance_package_spec عندما ينبغي أن يستخدم قبول الحزمة حزمة منشورة مختلفة عن مواصفة حزمة الإصدار. قدّم evidence_package_spec عندما ينبغي لتقرير أدلة الإصدار إثبات أن التحقق يطابق حزمة npm منشورة من دون فرض اختبار Telegram الشامل.

    bash
    node scripts/full-release-validation-at-sha.mjs \  --sha <code-sha> \  --target-ref release/YYYY.M.PATCH

  • شغّل سير عمل Package Acceptance اليدوي عندما تريد إثباتًا عبر قناة جانبية لنسخة حزمة مرشحة بينما يستمر عمل الإصدار. استخدم source=npm من أجل openclaw@beta أو openclaw@latest أو إصدار دقيق؛ وsource=ref لحزم فرع/وسم/SHA موثوق من package_ref باستخدام عُدّة الاختبار الحالية workflow_ref؛ وsource=url لأرشيف tarball عام عبر HTTPS مع SHA-256 مطلوب وسياسة صارمة لعناوين URL العامة؛ وsource=trusted-url لسياسة مصدر موثوق مسمّاة تستخدم trusted_source_id وSHA-256 المطلوبين؛ أو source=artifact لأرشيف tarball رفعه تشغيل GitHub Actions آخر.

    يحوّل سير العمل النسخة المرشحة إلى package-under-test، ويعيد استخدام مجدول إصدار Docker E2E مع أرشيف tarball ذاك، ويمكنه تشغيل ضمان جودة Telegram على أرشيف tarball نفسه باستخدام telegram_mode=mock-openai أو telegram_mode=live-frontier. عندما تتضمن مسارات Docker المحددة published-upgrade-survivor، تكون أداة الحزمة هي النسخة المرشحة، ويحدد published_upgrade_survivor_baseline خط الأساس المنشور. يستخدم update-restart-auth حزمة النسخة المرشحة بوصفها كلًا من CLI المثبّت والحزمة قيد الاختبار، لكي يختبر مسار إعادة التشغيل المُدارة لأمر تحديث النسخة المرشحة.

    مثال:

    bash
    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 [email protected] -f telegram_mode=mock-openai

    الملفات التعريفية الشائعة:

    • smoke: مسارات التثبيت/القنوات/الوكيل وشبكة Gateway وإعادة تحميل الإعدادات
    • package: مسارات الحزمة/التحديث/إعادة التشغيل/Plugin الأصلية للأداة من دون OpenWebUI أو ClawHub مباشر
    • product: ملف تعريف الحزمة بالإضافة إلى قنوات MCP وتنظيف cron/الوكيل الفرعي وبحث الويب من OpenAI وOpenWebUI
    • full: أجزاء مسار إصدار Docker مع OpenWebUI
    • custom: تحديد docker_lanes الدقيق لإعادة تشغيل مركّزة

  • شغّل سير عمل CI اليدوي مباشرةً عندما تحتاج فقط إلى تغطية CI عادية وحتمية للنسخة المرشحة للإصدار. تتجاوز عمليات تشغيل CI اليدوية تحديد النطاق وفق التغييرات، وتفرض أجزاء Linux Node وأجزاء Plugin المضمّنة وأجزاء عقود Plugin والقنوات وتوافق Node 22 وcheck-* وcheck-additional-* وفحوص الدخان للأدوات المبنية وفحوص المستندات وSkills الخاصة بـPython وWindows وmacOS ومسارات التدويل لواجهة Control UI. تشغّل عمليات CI اليدوية المستقلة Android فقط عند تشغيلها مع include_android=true؛ ويمرر Full Release Validation هذا الإدخال إلى عملية CI التابعة له.

    bash
    gh workflow run ci.yml --ref release/YYYY.M.PATCH -f include_android=true

  • شغّل pnpm qa:otel:smoke عند التحقق من قياس الإصدار عن بُعد. فهو يشغّل مختبر ضمان الجودة عبر مستقبِل OTLP/HTTP محلي، ويتحقق من تصدير التتبعات والمقاييس والسجلات، ومن تقييد سمات التتبع وتنقيح المحتوى/المعرّفات، من دون الحاجة إلى Opik أو Langfuse أو جامع خارجي آخر.

  • شغّل pnpm qa:otel:collector-smoke عند التحقق من توافق الجامع. فهو يوجّه تصدير OTLP نفسه من مختبر ضمان الجودة عبر حاوية Docker حقيقية لـOpenTelemetry Collector قبل تأكيدات المستقبِل المحلي.

  • شغّل pnpm qa:prometheus:smoke عند التحقق من جمع Prometheus المحمي. فهو يشغّل مختبر ضمان الجودة، ويرفض عمليات الجمع غير المصادق عليها، ويتحقق من بقاء عائلات المقاييس المهمة للإصدار خالية من محتوى المطالبات والمعرّفات الخام ورموز المصادقة والمسارات المحلية.

  • شغّل pnpm qa:observability:smoke لتشغيل مساري فحص الدخان لـOpenTelemetry وPrometheus من نسخة الشفرة المصدرية واحدًا تلو الآخر.

  • شغّل pnpm release:check قبل كل إصدار موسوم.

  • ينشئ الفحص التمهيدي OpenClaw NPM Release أدلة إصدار التبعيات قبل أن يحزم أرشيف npm tarball. تُعد بوابة ثغرات التحذيرات الأمنية في npm حاجبة للإصدار. أما تقارير مخاطر بيان التبعيات المتعدية، وملكية التبعيات/سطح تثبيتها، وتغييرات التبعيات، فهي أدلة إصدار فقط. يقارن تقرير تغييرات التبعيات النسخة المرشحة للإصدار بوسم الإصدار السابق القابل للوصول. يرفع الفحص التمهيدي أدلة التبعيات باسم openclaw-release-dependency-evidence-<tag>، ويدمجها أيضًا ضمن dependency-evidence/ داخل أداة الفحص التمهيدي المعدّة لـnpm. يعيد مسار النشر الحقيقي استخدام أداة الفحص التمهيدي تلك، ثم يرفق الأدلة نفسها بإصدار GitHub باسم openclaw-<version>-dependency-evidence.zip.

  • شغّل OpenClaw Release Publish لتسلسل النشر المُعدِّل بعد وجود الوسم. شغّل عمليات النشر التجريبية والمستقرة العادية من main موثوق؛ ويظل وسم الإصدار محددًا للالتزام المستهدف الدقيق، وقد يشير إلى release/YYYY.M.PATCH. تبقى عمليات نشر Tideclaw الأولية على الفرع الأولي المطابق لها. مرّر preflight_run_id الناجح الخاص بـnpm لـOpenClaw، وfull_release_validation_run_id الناجح، وfull_release_validation_run_attempt الدقيق، واحتفظ بنطاق نشر Plugin الافتراضي all-publishable ما لم تكن تشغّل إصلاحًا مركّزًا عن قصد. ينفّذ سير العمل نشر Plugin إلى npm، ونشر Plugin إلى ClawHub، ونشر OpenClaw إلى npm بالتتابع، كي لا تُنشر الحزمة الأساسية قبل إضافاتها الخارجية؛ ويُشغَّل ترويج Windows وAndroid بالتزامن مع نشر الحزمة الأساسية إلى npm مقابل صفحة الإصدار المسودة. يمكن استئناف عمليات إعادة تشغيل النشر: يتخطى إصدار npm الأساسي المنشور مسبقًا تشغيل الحزمة الأساسية بعد أن يثبت سير العمل تطابق أرشيف tarball في السجل مع أداة الفحص التمهيدي الخاصة بالوسم، ويُتخطى ترويج Windows/Android عندما يحتوي الإصدار بالفعل على عقد الأدوات المتحقق منه، بحيث لا تعيد المحاولة إلا المراحل الفاشلة. تتطلب إصلاحات Plugin المركّزة فقط plugin_publish_scope=selected وقائمة Plugin غير فارغة. تتطلب عمليات all-publishable الخاصة بـPlugin فقط أدلة فحص تمهيدي كاملة وغير قابلة للتغيير وأدلة التحقق الكامل من الإصدار؛ وتُرفض الأدلة الجزئية.

  • يتطلب OpenClaw Release Publish المستقر قيمة windows_node_tag دقيقة بعد وجود إصدار openclaw/openclaw-windows-node المطابق وغير التجريبي، بالإضافة إلى خريطة windows_node_installer_digests المعتمدة للنسخة المرشحة. قبل تشغيل أي عملية نشر تابعة، يتحقق من أن إصدار المصدر منشور وغير تجريبي ويحتوي على أدوات التثبيت المطلوبة لـx64 وARM64، وما يزال يطابق الخريطة المعتمدة. ثم يشغّل Windows Node Release بينما لا يزال إصدار OpenClaw مسودة، مع تمرير خريطة بصمات أدوات التثبيت المثبتة من دون تغيير. ينزّل سير العمل التابع أدوات تثبيت Windows Hub الموقّعة من ذلك الوسم الدقيق، ويطابقها مع البصمات المثبتة، ويتحقق على مشغّل Windows من أن توقيعات Authenticode الخاصة بها تستخدم موقّع OpenClaw Foundation المتوقع، ويكتب بيان SHA-256، ويرفع أدوات التثبيت والبيان إلى إصدار OpenClaw الأساسي على GitHub، ثم يعيد تنزيل الأدوات المروّجة ويتحقق من عضويتها في البيان وبصماتها. يتحقق سير العمل الأب من العقد الحالي لأدوات x64 وARM64 وأداة المجموع الاختباري قبل النشر. يرفض الاسترداد المباشر أسماء أدوات OpenClawCompanion-* غير المتوقعة قبل استبدال أدوات العقد المتوقعة ببايتات المصدر المثبتة.

    شغّل Windows Node Release يدويًا للاسترداد فقط، ومرّر دائمًا وسمًا دقيقًا، وليس latest مطلقًا، بالإضافة إلى خريطة JSON الصريحة expected_installer_digests من إصدار المصدر المعتمد. ينبغي أن تستهدف روابط تنزيل الموقع عناوين URL الدقيقة لأدوات إصدار OpenClaw المستقر الحالي، أو releases/latest/download/... فقط بعد التحقق من أن إعادة توجيه GitHub لأحدث إصدار تشير إلى الإصدار نفسه؛ ولا تربط بصفحة إصدار المستودع المصاحب وحدها.

  • تُشغَّل فحوصات الإصدار الآن في سير عمل يدوي منفصل: OpenClaw Release Checks. كما يشغّل مسار تكافؤ المحاكاة في مختبر ضمان الجودة، بالإضافة إلى ملف تعريف إصدار Matrix ومسار ضمان جودة Telegram قبل الموافقة على الإصدار. تستخدم المسارات الحية بيئة qa-live-shared؛ ويستخدم Telegram أيضًا تأجيرات بيانات اعتماد Convex CI. شغّل سير العمل اليدوي QA-Lab - All Lanes باستخدام matrix_profile=all عندما تريد جميع سيناريوهات Matrix التي تخضع للصيانة؛ يوزّع سير العمل هذا التحديد على ملفات تعريف النقل والوسائط وE2EE لإبقاء الإثبات الكامل ضمن المهل الزمنية لكل مهمة.

  • يُعد التحقق من تثبيت بيئة التشغيل وترقيتها عبر أنظمة التشغيل جزءًا من OpenClaw Release Checks وFull Release Validation العامّين، اللذين يستدعيان سير العمل القابل لإعادة الاستخدام .github/workflows/openclaw-cross-os-release-checks-reusable.yml مباشرةً. هذا الفصل مقصود: لإبقاء مسار إصدار npm الحقيقي قصيرًا وحتميًا ومركّزًا على العناصر المنشأة، بينما تبقى الفحوصات الحية الأبطأ في مسارها الخاص كي لا تؤخر النشر أو تعرقله.

  • يجب إرسال فحوصات الإصدار التي تحتوي على أسرار عبر Full Release Validation أو من مرجع سير العمل main/release، حتى يظل منطق سير العمل والأسرار خاضعين للتحكم.

  • يقبل OpenClaw Release Checks فرعًا أو وسمًا أو SHA كاملاً للالتزام، ما دام الالتزام الذي جرى حله قابلاً للوصول من فرع OpenClaw أو وسم إصدار.

  • يقبل الاختبار التمهيدي الخاص بالتحقق فقط في OpenClaw NPM Release أيضًا SHA الكامل الحالي، المكوّن من 40 محرفًا، لالتزام فرع سير العمل دون اشتراط وسم مدفوع. مسار SHA هذا مخصص للتحقق فقط ولا يمكن ترقيته إلى نشر حقيقي. في وضع SHA، ينشئ سير العمل v<package.json version> اصطناعيًا لفحص بيانات الحزمة الوصفية فقط؛ أما النشر الحقيقي فلا يزال يتطلب وسم إصدار حقيقيًا.

  • يُبقي كلا سيري العمل مسار النشر والترقية الحقيقي على مشغّلات مستضافة في GitHub، بينما يمكن لمسار التحقق غير المعدِّل استخدام مشغّلات Blacksmith Linux الأكبر.

  • يشغّل سير العمل هذا OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_CACHE_TEST=1 pnpm test:live:cache باستخدام سرّي سير العمل OPENAI_API_KEY وANTHROPIC_API_KEY.

  • لم يعد الاختبار التمهيدي لإصدار npm ينتظر مسار فحوصات الإصدار المنفصل.

  • قبل وسم إصدار مرشح محليًا، شغّل RELEASE_TAG=vYYYY.M.PATCH-beta.N pnpm release:fast-pretag-check. يشغّل المساعد حواجز حماية الإصدار السريعة، وفحوصات إصدار npm/ClawHub الخاصة بالـ plugins، والبناء، وبناء واجهة المستخدم، وrelease:openclaw:npm:check بالترتيب الذي يكشف الأخطاء الشائعة المانعة للموافقة قبل بدء سير عمل النشر في GitHub.

  • شغّل RELEASE_TAG=vYYYY.M.PATCH node --import tsx scripts/openclaw-npm-release-check.ts (أو وسم الإصدار التمهيدي/التصحيحي المطابق) قبل الموافقة.

  • بعد النشر إلى npm، شغّل node --import tsx scripts/openclaw-npm-postpublish-verify.ts YYYY.M.PATCH (أو إصدار beta/التصحيح المطابق) للتحقق من مسار تثبيت السجل المنشور ضمن بادئة مؤقتة جديدة.

  • بعد نشر beta، شغّل [email protected] OPENCLAW_NPM_TELEGRAM_CREDENTIAL_SOURCE=convex OPENCLAW_NPM_TELEGRAM_CREDENTIAL_ROLE=ci pnpm test:docker:npm-telegram-live للتحقق من إعداد الحزمة المثبتة، وإعداد Telegram، والاختبار الشامل الحقيقي لـ Telegram مقابل حزمة npm المنشورة باستخدام مجموعة بيانات اعتماد Telegram المشتركة والمؤجّرة. يمكن للعمليات الموضعية الفردية للمشرفين حذف متغيرات Convex وتمرير بيانات اعتماد البيئة الثلاثة OPENCLAW_QA_TELEGRAM_* مباشرةً.

  • لتشغيل اختبار الدخان الكامل بعد نشر beta من جهاز مشرف، استخدم pnpm release:beta-smoke -- --beta betaN. يشغّل المساعد التحقق من تحديث npm والهدف الجديد في Parallels، ويرسل NPM Telegram Beta E2E، ويستطلع تشغيل سير العمل المحدد، وينزّل العنصر المنشأ، ويطبع تقرير Telegram.

  • يمكن للمشرفين تشغيل فحص ما بعد النشر نفسه من GitHub Actions عبر سير العمل اليدوي NPM Telegram Beta E2E. وقد صُمم عمدًا ليكون يدويًا فقط ولا يعمل عند كل دمج.

  • تستخدم أتمتة الإصدار الخاصة بالمشرفين الاختبار التمهيدي ثم الترقية:

    • يجب أن يجتاز النشر الحقيقي إلى npm بنجاح preflight_run_id الخاص بـ npm.
    • تستخدم عملية تنسيق النشر والاختبار التمهيدي لإصدارات beta والمستقرة العادية main الموثوق به مقابل وسم الهدف المحدد. أما نشر Tideclaw alpha واختباره التمهيدي فيستخدمان فرع alpha المطابق.
    • تستخدم إصدارات npm المستقرة beta افتراضيًا؛ ويمكن للنشر المستقر إلى npm استهداف latest صراحةً عبر إدخال سير العمل.
    • يوجد تعديل وسم التوزيع في npm المعتمد على الرمز المميز ضمن openclaw/releases/.github/workflows/openclaw-npm-dist-tags.yml لأن npm dist-tag add لا يزال يحتاج إلى NPM_TOKEN بينما يحتفظ مستودع المصدر بنشر يعتمد على OIDC فقط.
    • يُستخدم macOS Release العام للتحقق فقط؛ وعندما يوجد وسم على فرع إصدار فقط ولكن يُرسل سير العمل من main، عيّن public_release_branch=release/YYYY.M.PATCH.
    • يجب أن يجتاز نشر macOS الحقيقي بنجاح preflight_run_id وvalidate_run_id الخاصين بـ macOS.
    • ترقّي مسارات النشر الحقيقية العناصر المنشأة المُعدّة بدلًا من إعادة بنائها مرة أخرى.

  • بالنسبة إلى إصدارات التصحيح المستقرة مثل YYYY.M.PATCH-N، يفحص مدقق ما بعد النشر أيضًا مسار ترقية البادئة المؤقتة نفسه من YYYY.M.PATCH إلى YYYY.M.PATCH-N، حتى لا تتسبب تصحيحات الإصدار بصمت في إبقاء عمليات التثبيت العامة الأقدم على حمولة الإصدار المستقر الأساسي.

  • يفشل الاختبار التمهيدي لإصدار npm بصورة مغلقة ما لم يتضمن ملف tarball كلاً من dist/control-ui/index.html وحمولة dist/control-ui/assets/ غير فارغة، حتى لا نشحن لوحة معلومات متصفح فارغة مجددًا.

  • يتحقق فحص ما بعد النشر أيضًا من وجود نقاط دخول الـ plugins المنشورة وبيانات الحزمة الوصفية في تخطيط السجل المثبت. يفشل الإصدار الذي يشحن حمولات مفقودة لبيئة تشغيل الـ plugins في مدقق ما بعد النشر ولا يمكن ترقيته إلى latest.

  • يفرض pnpm test:install:smoke أيضًا ميزانية unpackedSize الخاصة بحزم npm على ملف tarball المرشح للتحديث، بحيث يكتشف الاختبار الشامل للمثبّت تضخم الحزمة العرضي قبل مسار نشر الإصدار.

  • إذا مسّ عمل الإصدار تخطيط CI أو بيانات توقيت الامتدادات أو مصفوفات اختبار الامتدادات، فأعد إنشاء مخرجات مصفوفة plugin-prerelease-extension-shard المملوكة للمخطط من .github/workflows/plugin-prerelease.yml وراجعها قبل الموافقة، حتى لا تصف ملاحظات الإصدار تخطيط CI قديمًا.

  • يشمل استعداد إصدار macOS المستقر أيضًا أسطح أداة التحديث: يجب أن ينتهي إصدار GitHub محتويًا على .zip و.dmg و.dSYM.zip المحزّمة؛ ويجب أن يشير appcast.xml في main إلى ملف zip المستقر الجديد بعد النشر (يلتزم به سير عمل نشر macOS تلقائيًا، أو يفتح طلب سحب لـ appcast عندما يُحظر الدفع المباشر)؛ ويجب أن يحتفظ التطبيق المحزّم بمعرّف حزمة غير مخصص للتصحيح، وعنوان URL غير فارغ لخلاصة Sparkle، وCFBundleVersion عند الحد الأدنى القياسي لبناء Sparkle لإصدار ذلك الإصدار أو أعلى منه.

صناديق اختبار الإصدار

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

bash
pnpm ci:full-release \  --sha <code-sha> \  --target-ref release/YYYY.M.PATCH

يجلب المساعد origin/main الحالي، ويدفع release-ci/<workflow-sha>-... عند التزام سير العمل الموثوق به، ويستنتج beta من إصدارات حزم alpha/beta وstable خلاف ذلك، ويرسل Full Release Validation من الفرع المؤقت باستخدام ref=<target-sha>، ويتحقق من أن كل headSha لسير عمل فرعي يطابق SHA المثبت لسير العمل الأب، ثم يحذف الفرع المؤقت. مرّر -f reuse_evidence=false لفرض تشغيل جديد، أو -f release_profile=full للمسح الاستشاري الواسع، أو --workflow-sha <trusted-main-sha> لتثبيت التزام أقدم لا يزال قابلاً للوصول من origin/main الحالي. لا يكتب سير العمل نفسه مراجع المستودع مطلقًا. يحافظ هذا على إتاحة أدوات الإصدار الخاصة بالفرع الرئيسي دون إضافة التزامات أدوات إلى المرشح، ويتجنب إثبات تشغيل فرعي أحدث لـ main عن طريق الخطأ.

بعد أن يصبح Code SHA أخضر، التزم بـ CHANGELOG.md فقط وشغّل المساعد نفسه باستخدام Release SHA:

bash
pnpm ci:full-release \  --sha <release-sha> \  --target-ref release/YYYY.M.PATCH

يعيد الأب الثاني استخدام دليل المنتج فقط عندما يثبت GitHub أن Release SHA ينحدر من Code SHA وأن مجموعة المسارات المتغيرة الكاملة هي بالضبط CHANGELOG.md. ويسجّل changelog-only-release-v1 ولا يرسل أي مهام فرعية للمنتج. يظل الاختبار التمهيدي لـ npm وقبول الحزمة/التثبيت يعملان على Release SHA لأن بايتات ملف tarball الخاص به تغيرت.

بالنسبة إلى Code SHA جديد، يحل سير العمل الهدف، ويرسل CI اليدوي، ثم يرسل OpenClaw Release Checks. يوزّع OpenClaw Release Checks اختبار دخان التثبيت، وفحوصات الإصدار عبر أنظمة التشغيل، وتغطية مسار الإصدار الحي/الشامل في Docker عند تمكين الاختبار الممتد، وقبول الحزمة مع الاختبار الشامل القياسي لحزمة Telegram، وتكافؤ مختبر ضمان الجودة، وMatrix الحي، وTelegram الحي. لا يُقبل التشغيل الكامل/الشامل إلا عندما يُظهر ملخص Full Release Validation نجاح normal_ci وplugin_prerelease وrelease_checks، إلا إذا تخطّت إعادة تشغيل مركّزة المهمة الفرعية المنفصلة Plugin Prerelease عمدًا. استخدم المهمة الفرعية المستقلة npm-telegram فقط لإعادة تشغيل مركّزة للحزمة المنشورة باستخدام release_package_spec أو npm_telegram_package_spec. يتضمن ملخص المدقق النهائي جداول أبطأ المهام لكل تشغيل فرعي، بحيث يستطيع مدير الإصدار رؤية المسار الحرج الحالي دون تنزيل السجلات.

المهمة الفرعية لأداء المنتج مخصصة للعناصر المنشأة فقط في مسار الإصدار هذا. يرسلها سير العمل الشامل باستخدام publish_reports=false، ويُرفض التحقق ما لم يثبت حاجز العناصر المنشأة فقط أن ناشر تقرير Clawgrit ظل متخطىً.

راجع التحقق الكامل من الإصدار للاطلاع على مصفوفة المراحل الكاملة، وأسماء مهام سير العمل الدقيقة، والفروق بين ملفي التعريف المستقر والكامل، والعناصر المنشأة، ومعرّفات إعادة التشغيل المركّزة.

تُرسل مهام سير العمل الفرعية من المرجع الموثوق المثبت بـ SHA الذي يشغّل Full Release Validation. يجب أن يستخدم كل تشغيل فرعي SHA سير العمل الأب نفسه تمامًا. لا تستخدم عمليات إرسال --ref main -f ref=<sha> الأولية لإثبات الإصدار؛ استخدم pnpm ci:full-release --sha <target-sha> --target-ref release/YYYY.M.PATCH.

استخدم release_profile لتحديد اتساع التغطية الحية/تغطية المزوّد:

  • beta: أسرع مسار حي ومسار Docker الحرجين للإصدار لـ OpenAI/النواة
  • stable: تغطية المزوّد/الواجهة الخلفية لإصداري beta والمستقر للموافقة على الإصدار
  • full: الإصدار المستقر بالإضافة إلى تغطية استشارية واسعة للمزوّد/الوسائط

يشغّل التحقق المستقر والكامل دائمًا المسح الشامل الحي/الشامل، ومسار إصدار Docker، والمسح المحدود لاستمرار الترقيات المنشورة قبل الترقية. استخدم run_release_soak=true لطلب المسح نفسه لإصدار beta. يغطي ذلك المسح أحدث أربع حزم مستقرة، بالإضافة إلى خطي أساس مثبتين هما 2026.4.23 و2026.5.2، وكذلك تغطية 2026.4.15 الأقدم، مع إزالة خطوط الأساس المكررة وتوزيع كل خط أساس على مهمة مشغّل Docker مستقلة.

يستخدم OpenClaw Release Checks مرجع سير العمل الموثوق به لحل المرجع المستهدف مرة واحدة بوصفه release-package-under-test، ويعيد استخدام ذلك العنصر المنشأ في الفحوصات عبر أنظمة التشغيل، وقبول الحزمة، وفحوصات Docker لمسار الإصدار عند تشغيل الاختبار الممتد. يُبقي هذا جميع الصناديق المتعاملة مع الحزم على البايتات نفسها ويتجنب تكرار بناء الحزم. بعد وجود إصدار beta بالفعل على npm، عيّن [email protected] حتى تنزّل فحوصات الإصدار الحزمة المشحونة مرة واحدة، وتستخرج SHA مصدر بنائها من dist/build-info.json، وتعيد استخدام ذلك العنصر المنشأ للمسارات عبر أنظمة التشغيل، وقبول الحزمة، ومسار إصدار Docker، ومسارات حزمة Telegram.

يستخدم اختبار دخان تثبيت OpenAI عبر أنظمة التشغيل OPENCLAW_CROSS_OS_OPENAI_MODEL عند تعيين متغير المستودع/المؤسسة، وإلا فيستخدم openai/gpt-5.6-luna، لأن هذا المسار يثبت تثبيت الحزمة، والإعداد، وبدء تشغيل Gateway، ودورة واحدة حية للوكيل، بدلًا من قياس أداء النموذج الأكثر قدرة. تظل مصفوفة المزوّدين الحية الأوسع هي المكان المخصص للتغطية الخاصة بالنماذج.

استخدم هذه المتغيرات وفقًا لمرحلة الإصدار:

bash
# تحقّق من Code SHA المكتمل للمنتج.pnpm ci:full-release \  --sha <code-sha> \  --target-ref release/YYYY.M.PATCH # تحقّق من Release SHA الخاص بسجل التغييرات فقط عبر إعادة استخدام أدلة المنتج الخاصة بـ Code SHA.pnpm ci:full-release \  --sha <release-sha> \  --target-ref release/YYYY.M.PATCH # بعد نشر إصدار تجريبي، أضف اختبار Telegram E2E للحزمة المنشورة.pnpm ci:full-release \  --sha <release-sha> \  --target-ref release/YYYY.M.PATCH \  -f [email protected] \  -f [email protected] \  -f npm_telegram_provider_mode=mock-openai

لا تستخدم المظلّة الكاملة كأول إعادة تشغيل بعد إصلاح مركّز. إذا فشل أحد الصناديق، فاستخدم سير العمل الفرعي الفاشل أو المهمة أو مسار Docker أو ملف تعريف الحزمة أو موفّر النموذج أو مسار QA للإثبات التالي. شغّل المظلّة الكاملة مجددًا فقط عندما يغيّر الإصلاح تنسيق الإصدار المشترك أو يجعل أدلة جميع الصناديق السابقة قديمة. يعيد المتحقّق النهائي للمظلّة فحص معرّفات تشغيل سير العمل الفرعي المسجّلة، لذلك بعد إعادة تشغيل سير عمل فرعي بنجاح، أعد تشغيل مهمة الأصل Verify full validation الفاشلة فقط.

قد يعيد rerun_group=all استخدام تشغيل مظلّة أخضر سابق عندما يتطابق ملف تعريف الإصدار، وإعداد الاستقرار الفعلي، ومدخلات التحقّق، ويكون SHA الهدف إما متطابقًا أو يكون الهدف الجديد تابعًا له ومجموعة المسارات المتغيّرة الكاملة فيه هي بالضبط CHANGELOG.md. تسجّل إعادة استخدام الهدف المطابق exact-target-full-validation-v1؛ ويسجّل Release SHA لما بعد التحقّق changelog-only-release-v1. يعيد الأخير استخدام التحقّق من المنتج فقط. ويجب أن يستمر تشغيل الفحص التمهيدي لـ npm، وبايتات الحزمة، ومصدر ملاحظات الإصدار، وقبول التثبيت/التحديث مقابل Release SHA. يتطلّب أي تغيير في الإصدار أو المصدر أو المحتوى المُنشأ أو التبعية أو الحزمة أو الهدف المملوك لسير العمل Code SHA جديدًا وتحقّقًا كاملًا حديثًا. تحلّ عمليات المظلّة الأحدث للمرجع release/* نفسه ومجموعة إعادة التشغيل محل العمليات الجارية تلقائيًا. مرّر reuse_evidence=false لفرض تشغيل كامل حديث.

للاسترداد المحدود، مرّر rerun_group إلى المظلّة. يمثّل all تشغيل مرشّح الإصدار الفعلي، ويشغّل ci عنصر CI الفرعي العادي فقط، ويشغّل plugin-prerelease عنصر Plugin الخاص بالإصدار فقط، ويشغّل release-checks كل صناديق الإصدار، ومجموعات الإصدار الأضيق هي install-smoke وcross-os وlive-e2e وpackage وqa وqa-parity وqa-live وnpm-telegram. تتطلّب عمليات إعادة التشغيل المركّزة لـ npm-telegram استخدام release_package_spec أو npm_telegram_package_spec؛ وتستخدم عمليات التشغيل الكاملة/الشاملة اختبار Telegram E2E القياسي للحزمة داخل قبول الحزمة. يمكن لإعادات التشغيل المركّزة عبر أنظمة التشغيل إضافة cross_os_suite_filter=windows/packaged-upgrade أو مرشّح آخر لنظام التشغيل/الحزمة الاختبارية. تمنع إخفاقات فحص إصدار QA التحقّق العادي من الإصدار، بما في ذلك الانحراف المطلوب لأداة OpenClaw الديناميكية في المستوى القياسي. قد تستمر عمليات Tideclaw alpha في اعتبار مسارات فحص الإصدار غير المتعلقة بسلامة الحزمة استشارية. مع release_profile=beta، تكون حزم موفّر الإنتاج Run repo/live E2E validation استشارية (تحذيرات وليست عوامل منع)؛ وتظل ملفات التعريف المستقرة والكاملة حاجبة. عندما يطلب live_suite_filter صراحةً مسار QA مباشرًا خاضعًا للبوابة مثل Discord أو WhatsApp أو Slack، يجب تمكين متغيّر المستودع OPENCLAW_RELEASE_QA_*_LIVE_CI_ENABLED المطابق؛ وإلا يفشل التقاط المدخلات بدلًا من تخطّي المسار بصمت.

Vitest

صندوق Vitest هو سير العمل الفرعي اليدوي CI. يتجاوز CI اليدوي عمدًا تحديد النطاق حسب التغييرات ويفرض مخطط الاختبارات العادي لمرشّح الإصدار: أجزاء Linux Node، وأجزاء Plugin المضمّنة، وأجزاء عقود Plugin والقنوات، والتوافق مع Node 22، وcheck-*، وcheck-additional-*، وفحوصات سلامة العناصر المبنية، وفحوصات المستندات، وSkills بلغة Python، وWindows، وmacOS، وتدويل واجهة Control UI. يُضمّن Android عندما يشغّل Full Release Validation الصندوق لأن المظلّة تمرّر include_android=true؛ ويتطلّب CI اليدوي المستقل include_android=true لتغطية Android.

استخدم هذا الصندوق للإجابة عن السؤال: «هل اجتازت شجرة المصدر حزمة الاختبارات العادية الكاملة؟» وهو ليس مماثلًا للتحقّق من المنتج عبر مسار الإصدار. الأدلة المطلوب الاحتفاظ بها:

  • ملخّص Full Release Validation يعرض عنوان URL لتشغيل CI الذي جرى إرساله
  • تشغيل CI أخضر على SHA الهدف المحدّد
  • أسماء الأجزاء الفاشلة أو البطيئة من مهام CI عند التحقيق في حالات التراجع
  • عناصر توقيت Vitest مثل .artifacts/vitest-shard-timings.json عندما يحتاج التشغيل إلى تحليل الأداء

شغّل CI اليدوي مباشرةً فقط عندما يحتاج الإصدار إلى CI عادي حتمي، لكن لا يحتاج إلى صناديق Docker أو QA Lab أو الإنتاج أو أنظمة التشغيل المتعددة أو الحزم. استخدم الأمر الأول لتشغيل CI مباشر دون Android. أضف include_android=true عندما يجب أن يغطي CI المباشر لمرشّح الإصدار Android:

bash
gh workflow run ci.yml --ref main -f target_ref=release/YYYY.M.PATCHgh workflow run ci.yml --ref main -f target_ref=release/YYYY.M.PATCH -f include_android=true

Docker

يوجد صندوق Docker في OpenClaw Release Checks عبر openclaw-live-and-e2e-checks-reusable.yml، بالإضافة إلى سير العمل install-smoke في وضع الإصدار. ويتحقّق من مرشّح الإصدار عبر بيئات Docker المحزّمة بدلًا من الاقتصار على اختبارات مستوى المصدر.

تشمل تغطية Docker للإصدار:

  • فحص سلامة كامل للتثبيت مع تمكين فحص سلامة التثبيت العام البطيء لـ Bun
  • إعداد/إعادة استخدام صورة فحص سلامة Dockerfile الجذري حسب SHA الهدف، مع تشغيل مهام فحص QR والجذر/Gateway والمثبّت/Bun كأجزاء منفصلة لفحص سلامة التثبيت
  • مسارات E2E الخاصة بالمستودع
  • أجزاء 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
  • تغطية OpenWebUI على مشغّل مخصّص ذي قرص كبير عند طلبها
  • مسارات تثبيت/إلغاء تثبيت Plugin المضمّنة والمقسّمة من bundled-plugin-install-uninstall-0 عبر bundled-plugin-install-uninstall-23
  • حزم موفّري الإنتاج/E2E وتغطية نماذج Docker المباشرة عندما تتضمّن فحوصات الإصدار حزمًا مباشرة

استخدم عناصر Docker قبل إعادة التشغيل. يرفع مجدول مسار الإصدار .artifacts/docker-tests/ مع سجلات المسارات، وsummary.json، وfailures.json، وتوقيتات المراحل، وJSON لخطة المجدول، وأوامر إعادة التشغيل. للاسترداد المركّز، استخدم docker_lanes=<lane[,lane]> في سير عمل الإنتاج/E2E القابل لإعادة الاستخدام بدلًا من إعادة تشغيل كل أجزاء الإصدار. تتضمّن أوامر إعادة التشغيل المُنشأة مدخلات package_artifact_run_id السابقة وصور Docker المُعدّة عند توفرها، بحيث يمكن لمسار فاشل إعادة استخدام ملف tarball نفسه وصور GHCR ذاتها.

QA Lab

يُعد صندوق QA Lab أيضًا جزءًا من OpenClaw Release Checks. وهو بوابة الإصدار الخاصة بسلوك الوكيل ومستوى القناة، ومنفصل عن آليات حزم Vitest وDocker.

تشمل تغطية QA Lab للإصدار:

  • مسار تكافؤ وهمي يقارن مسار OpenAI المرشّح بخط أساس anthropic/claude-opus-4-8 باستخدام حزمة تكافؤ الوكيل
  • ملف تعريف إصدار لمحوّل Matrix المباشر باستخدام بيئة qa-live-shared
  • مسار QA مباشر لـ Telegram باستخدام عقود إيجار بيانات اعتماد Convex CI
  • pnpm qa:otel:smoke أو pnpm qa:otel:collector-smoke أو pnpm qa:prometheus:smoke أو pnpm qa:observability:smoke عندما يحتاج قياس الإصدار عن بُعد إلى إثبات محلي صريح

استخدم هذا الصندوق للإجابة عن السؤال: «هل يعمل الإصدار بصورة صحيحة في سيناريوهات QA وتدفّقات القنوات المباشرة؟» احتفظ بعناوين URL للعناصر الخاصة بمسارات التكافؤ وMatrix وTelegram عند اعتماد الإصدار. تظل تغطية Matrix الكاملة متاحة كتشغيل QA-Lab يدوي ومجزّأ بدلًا من المسار الافتراضي الحرج للإصدار.

الحزمة

صندوق الحزمة هو بوابة المنتج القابل للتثبيت. ويدعمه Package Acceptance والمحلّل scripts/resolve-openclaw-package-candidate.mjs. يطبّع المحلّل المرشّح إلى ملف tarball ‏package-under-test الذي يستهلكه Docker E2E، ويتحقّق من مخزون الحزمة، ويسجّل إصدار الحزمة وSHA-256، ويُبقي مرجع أداة سير العمل منفصلًا عن مرجع مصدر الحزمة.

مصادر المرشّحين المدعومة:

  • source=npm: ‏openclaw@beta أو openclaw@latest أو إصدار OpenClaw دقيق
  • source=ref: حزّم فرع package_ref موثوقًا أو وسمًا أو SHA كاملًا للالتزام باستخدام أداة workflow_ref المحدّدة
  • source=url: نزّل .tgz عامًا عبر HTTPS مع package_sha256 المطلوب؛ وتُرفض بيانات الاعتماد في عنوان URL ومنافذ HTTPS غير الافتراضية وأسماء المضيفين أو العناوين المحلولة الخاصة/الداخلية/ذات الاستخدام الخاص وعمليات إعادة التوجيه غير الآمنة
  • source=trusted-url: نزّل .tgz عبر HTTPS مع package_sha256 وtrusted_source_id المطلوبين من سياسة مسمّاة في .github/package-trusted-sources.json؛ استخدم هذا للمرايا المؤسسية المملوكة للمشرفين أو مستودعات الحزم الخاصة بدلًا من إضافة تجاوز للشبكة الخاصة على مستوى المدخلات إلى source=url
  • source=artifact: أعد استخدام .tgz رفعه تشغيل آخر لـ GitHub Actions

يشغّل OpenClaw Release Checks قبول الحزمة باستخدام 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. يُبقي قبول الحزمة عمليات الترحيل والتحديث وترقية VPS المُدار من الجذر وإعادة التشغيل بعد تحديث المصادقة المُهيأة وتثبيت Skill مباشرة من ClawHub وتنظيف تبعيات Plugin القديمة وتركيبات Plugin غير المتصلة وتحديث Plugin وتقوية الهروب من ربط أوامر Plugin وQA لحزمة Telegram على ملف tarball المحلّل نفسه. تستخدم فحوصات الإصدار الحاجبة خط أساس أحدث حزمة منشورة افتراضيًا؛ ويوسّع ملف تعريف الإصدار التجريبي باستخدام run_release_soak=true أو release_profile=stable أو release_profile=full مسح الناجين من ترقية الإصدارات المنشورة إلى last-stable-4 بالإضافة إلى خطوط الأساس المثبّتة 2026.4.23 و2026.5.2 و2026.4.15 مع سيناريوهات reported-issues. استخدم قبول الحزمة مع source=npm لمرشّح سبق شحنه، أو source=ref لملف tarball محلي من npm مدعوم بـ SHA قبل النشر، أو source=trusted-url لمرآة مؤسسية/خاصة مملوكة للمشرف، أو source=artifact لملف tarball مُعدّ رفعه تشغيل آخر لـ GitHub Actions.

وهو البديل الأصلي ضمن GitHub لمعظم تغطية الحزم/التحديثات التي كانت تتطلّب Parallels سابقًا. تظل فحوصات الإصدار عبر أنظمة التشغيل مهمة لعمليات الإعداد الأولي والمثبّت وسلوك المنصة الخاصة بكل نظام تشغيل، لكن ينبغي أن يفضّل التحقّق من منتج الحزمة/التحديث قبول الحزمة.

قائمة التحقّق القياسية للتحقّق من التحديثات وPlugin هي اختبار التحديثات وPlugin. استخدمها عند تحديد أي مسار محلي أو Docker أو قبول الحزمة أو فحص الإصدار يثبت تغييرًا في تثبيت/تحديث Plugin أو تنظيف doctor أو ترحيل الحزمة المنشورة. يُعد الترحيل الشامل لتحديثات كل حزمة 2026.4.23+ مستقرة ومنشورة سير عمل يدويًا منفصلًا Update Migration، وليس جزءًا من CI الكامل للإصدار.

التساهل القديم في قبول الحزمة محدود زمنيًا عن قصد. قد تستخدم الحزم حتى 2026.4.25 مسار التوافق لفجوات البيانات الوصفية المنشورة بالفعل إلى npm: إدخالات مخزون QA الخاصة المفقودة من ملف tarball، وgateway install --wrapper المفقود، وملفات التصحيح المفقودة من تركيبة git المشتقة من ملف tarball، وupdate.channel المستمر المفقود، ومواقع سجلات تثبيت Plugin القديمة، وغياب استمرار سجل تثبيت السوق، وترحيل بيانات تعريف الإعداد أثناء plugins update. قد تحذّر حزمة 2026.4.26 المنشورة بشأن ملفات ختم بيانات تعريف البناء المحلي التي شُحنت بالفعل. يجب أن تستوفي الحزم اللاحقة عقود الحزم الحديثة؛ وتؤدي الفجوات نفسها فيها إلى فشل التحقّق من الإصدار.

استخدم ملفات تعريف أوسع لقبول الحزمة عندما يكون سؤال الإصدار متعلقًا بحزمة فعلية قابلة للتثبيت:

bash
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 [email protected]

ملفات تعريف الحزمة الشائعة:

  • smoke: مسارات التثبيت السريع للحزمة/القناة/الوكيل، وشبكة Gateway، وإعادة تحميل الإعدادات
  • package: عقود تثبيت/تحديث/إعادة تشغيل/حزم Plugin، بالإضافة إلى إثبات مباشر لتثبيت مهارة ClawHub؛ وهذا هو الإعداد الافتراضي لفحص الإصدار
  • product: package بالإضافة إلى قنوات MCP، وتنظيف cron/الوكلاء الفرعيين، وبحث الويب من OpenAI، وOpenWebUI
  • full: أجزاء مسار إصدار Docker مع OpenWebUI
  • custom: قائمة docker_lanes الدقيقة لإعادات التشغيل المركزة

لإثبات Telegram الخاص بالحزمة المرشحة، فعّل telegram_mode=mock-openai أو telegram_mode=live-frontier في قبول الحزمة. يمرر سير العمل ملف tarball المحسوم package-under-test إلى مسار Telegram؛ ويظل سير عمل Telegram المستقل يقبل مواصفة npm منشورة لفحوص ما بعد النشر.

أتمتة نشر الإصدار العادي

بالنسبة إلى beta، وlatest، وPlugin، وإصدار GitHub، والنشر على المنصات، يُعد OpenClaw Release Publish نقطة الدخول العادية التي تُجري التغييرات. ولا يستخدم مسار .33+ الشهري الخاص بالإصدار الممتد المستقر على npm فقط هذا المنسق. ينسق سير العمل العادي مسارات عمل الناشر الموثوق بالترتيب الذي يتطلبه الإصدار:

  1. اسحب وسم الإصدار وحدد SHA الخاص بالتزامه.
  2. تحقق من إمكانية الوصول إلى الوسم من main أو release/* (أو فرع Tideclaw alpha للإصدارات التمهيدية من نوع alpha).
  3. شغّل pnpm plugins:sync:check.
  4. شغّل Plugin NPM Release باستخدام publish_scope=all-publishable وref=<release-sha>.
  5. شغّل Plugin ClawHub Release بالنطاق وSHA نفسيهما.
  6. شغّل OpenClaw NPM Release باستخدام وسم الإصدار، ووسم توزيع npm، وpreflight_run_id المحفوظ بعد التحقق من full_release_validation_run_id المحفوظ ومحاولة التشغيل الدقيقة.
  7. بالنسبة إلى الإصدارات المستقرة، أنشئ إصدار GitHub أو حدّثه كمسودة، وشغّل Windows Node Release باستخدام windows_node_tag الصريح وwindows_node_installer_digests المعتمد للمرشح، وتحقق من أصول مُثبّت Windows والمجاميع الاختبارية القياسية. وشغّل أيضًا Android Release لبناء ملف APK الموقّع ذي الوسم الدقيق، مع المجموع الاختباري وإثبات المصدر. تحقق من عقدي الأصول الأصلية كليهما قبل نشر المسودة.

مثال نشر beta:

bash
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

نشر مستقر إلى وسم توزيع beta الافتراضي:

bash
gh workflow run openclaw-release-publish.yml \  --ref main \  -f tag=vYYYY.M.PATCH \  -f windows_node_tag=vX.Y.Z \  -f windows_node_installer_digests='{"OpenClawCompanion-Setup-x64.exe":"sha256:<approved-x64-sha256>","OpenClawCompanion-Setup-arm64.exe":"sha256:<approved-arm64-sha256>"}' \  -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

تكون الترقية المستقرة مباشرةً إلى latest صريحة:

bash
gh workflow run openclaw-release-publish.yml \  --ref main \  -f tag=vYYYY.M.PATCH \  -f windows_node_tag=vX.Y.Z \  -f windows_node_installer_digests='{"OpenClawCompanion-Setup-x64.exe":"sha256:<approved-x64-sha256>","OpenClawCompanion-Setup-arm64.exe":"sha256:<approved-arm64-sha256>"}' \  -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=latest

استخدم مساري العمل الأدنى مستوى Plugin NPM Release وPlugin ClawHub Release فقط لأعمال الإصلاح أو إعادة النشر المركزة. يرفض OpenClaw Release Publish القيمة plugin_publish_scope=selected عندما تكون publish_openclaw_npm=true، بحيث لا يمكن شحن الحزمة الأساسية من دون كل Plugin رسمي قابل للنشر، بما في ذلك @openclaw/diffs-language-pack. لإصلاح Plugin محدد، عيّن publish_openclaw_npm=false مع plugin_publish_scope=selected وplugins=@openclaw/name، أو شغّل سير العمل الفرعي مباشرةً.

يُعد تمهيد ClawHub عند النشر الأول استثناءً: شغّل Plugin ClawHub New من main الموثوق، ومرّر SHA الكامل للإصدار المستهدف عبر ref. لا تشغّل سير عمل التمهيد نفسه مطلقًا من وسم الإصدار أو فرعه:

bash
gh workflow run plugin-clawhub-new.yml \  --ref main \  -f plugins=@openclaw/name \  -f ref=<full-40-character-release-sha> \  -f pretag_validation=true \  -f dry_run=true

يتطلب التحقق السابق للوسم dry_run=true، ويرفض مدخلات وسم الإصدار والتشغيل الأب، ولا يقبل إلا هدفًا دقيقًا يمكن الوصول إليه من main أو release/*. ولا يحمّل بيانات اعتماد ClawHub، ولا ينشر بايتات الحزمة، ولا يغير إعدادات الناشر الموثوق. ومع ذلك، يحسم سير العمل خطة السجل المباشر، ويسحب الهدف ويحزّمه في مهمة بلا أسرار فقط، ويُنشئ سلسلة أدوات ClawHub المقفلة، ويتحقق من الأثر غير القابل للتغيير ومن الاسم المختصر/هوية الحزمة قبل وجود وسم الإصدار. لا تعتمد بيئة clawhub-plugin-bootstrap إلا بعد انتهاء مهام الحزم بلا أسرار؛ فمهمة التحقق المحمية هذه لا تحتوي على بيانات اعتماد أو أوامر تُجري تغييرات.

يجب أن يتضمن التشغيل التجريبي المعتمد أو التمهيد الفعلي بعد وضع الوسم وسم الإصدار الدقيق، بالإضافة إلى معرّف تشغيل OpenClaw Release Publish الأب ومحاولته وفرعه. يشهد التشغيل الأب على SHA الخاص بسير عمله وعلى SHA موثوق ودقيق منفصل لـmain من أجل Plugin ClawHub New؛ ويجب أن يتطابق التشغيل الفرعي وكل اعتماد لبيئة محمية مع SHA الفرعي المعتمد. ويُعاد فحص وسم الإصدار قبل كل محاولة نشر وكل تغيير في الناشر الموثوق.

ترفع مهمة الحزم أثرًا واحدًا غير قابل للتغيير، ويُنقل اسمه ومعرّف/ملخص أثر Actions، وتشغيل/محاولة المُنتج، وSHA الهدف، وSHA-256/حجم ملف tarball لكل حزمة إلى مهام التحقق والمهام المحمية. وتسحب المهمة المحمية أدوات main الموثوقة فقط، وتتحقق من مجموعة بيانات الأثر عبر GitHub API، وتُنزّل بواسطة معرّف الأثر الدقيق، وتعيد حساب تجزئة كل ملف tarball، وتتحقق من مسارات TAR المحلية وهوية الحزمة وفق قواعد التطبيع القياسية USTAR الخاصة بـCLI المثبتة. ثم يجتاز كل مرشح تشغيلًا تجريبيًا للنشر باستخدام CLI المثبتة، والذي يعود قبل البحث في السجل أو المصادقة. يحدد المرشح الأولي لمهمة بيانات الاعتماد الحد الأقصى لحزم ClawPacks المضغوطة عند 120 MiB، وإجمالي حمولة الملفات عند 50 MiB، وبيانات TAR الموسعة عند 64 MiB، وعدد إدخالات TAR عند 10,000. ويظل إصلاح الناشر الموثوق للحزمة الموجودة مقتصرًا على الإعداد، لكنه مع ذلك يحزّم الهدف ويتطلب الوسم المطلوب بالإضافة إلى التطابق الدقيق لبايتات السجل وبياناته الوصفية قبل تغيير إعدادات الناشر الموثوق. ينزّل التحقق اللاحق للنشر أثر ClawHub ويتطلب SHA-256 والحجم نفسيهما. ولا يجوز لاسترداد إعادة تشغيل المهام الفاشلة إعادة استخدام أثر حزمة من محاولة سابقة إلا عندما تكون مهمة المُنتج الدقيقة قد اكتملت بنجاح. كما يربط الدليل النهائي إصدار ClawHub المقفل، وSHA-256 للقفل، وسلامة npm. ويتطلب عدم التطابق إصدار حزمة جديدًا.

مدخلات سير عمل NPM

يقبل OpenClaw NPM Release هذه المدخلات التي يتحكم فيها المشغّل:

  • tag: وسم إصدار مطلوب مثل v2026.4.2 أو v2026.4.2-1 أو v2026.4.2-beta.1 أو v2026.4.2-alpha.1؛ وعندما تكون preflight_only=true، يمكن أن تكون أيضًا SHA الالتزام الكامل الحالي المكون من 40 محرفًا لفرع سير العمل، وذلك للفحص التمهيدي المخصص للتحقق فقط
  • preflight_only: القيمة true للتحقق/البناء/الحزم فقط، والقيمة false لمسار النشر الفعلي
  • preflight_run_id: معرّف تشغيل فحص تمهيدي ناجح حالي، مطلوب في مسار النشر الفعلي لكي يعيد سير العمل استخدام ملف tarball المُعد بدلًا من إعادة بنائه
  • full_release_validation_run_id: معرّف تشغيل Full Release Validation ناجح لهذا الوسم/SHA، مطلوب للنشر الفعلي. يمكن أن تتابع عمليات نشر beta اعتمادًا على الفحص التمهيدي وحده مع تحذير، لكن الترقية المستقرة/ترقية latest تظل تتطلبه.
  • full_release_validation_run_attempt: محاولة التشغيل الموجبة الدقيقة المقترنة بـfull_release_validation_run_id؛ مطلوبة كلما تم توفير معرّف التشغيل، بحيث لا يمكن لإعادات التشغيل تغيير دليل التفويض أثناء النشر.
  • release_publish_run_id: معرّف تشغيل OpenClaw Release Publish المعتمد؛ مطلوب عندما يشغّل سير العمل هذا التشغيل الأب المذكور (استدعاءات النشر الفعلي من ممثل آلي)
  • plugin_npm_run_id: معرّف تشغيل Plugin NPM Release ناجح ودقيق للرأس؛ مطلوب للنشر الأساسي الفعلي لـextended-stable
  • npm_dist_tag: وسم npm المستهدف لمسار النشر؛ يقبل alpha أو beta أو latest أو extended-stable، وتكون قيمته الافتراضية beta. يجب أن تستخدم الرقعة النهائية 33 وما بعدها extended-stable؛ افتراضيًا، يرفض extended-stable الرقع الأقدم، ويرفض دائمًا الوسوم غير النهائية.
  • bypass_extended_stable_guard: قيمة منطقية للاختبار فقط، وقيمتها الافتراضية false؛ ومع npm_dist_tag=extended-stable، تتجاوز أهلية الإصدار الشهري الممتد المستقر مع الحفاظ على فحوص هوية الإصدار والأثر والاعتماد وإعادة القراءة.

يقبل Plugin NPM Release القيمة npm_dist_tag=default لسلوك الإصدار الحالي أو npm_dist_tag=extended-stable للمسار الشهري المحمي. يتطلب خيار الإصدار الممتد المستقر publish_scope=all-publishable، ومدخل plugins فارغًا، ورقعة نهائية عند 33 أو أعلى، وفرع extended-stable/YYYY.M.33 القياسي عند رأسه الدقيق. ولا ينقل مطلقًا وسمَي Plugin latest أو beta. تتلقى إصدارات الحزم الجديدة extended-stable ذريًا عبر النشر الموثوق باستخدام OIDC ‏(npm publish --tag extended-stable)؛ ولا يستخدم سير العمل المصدري هذا npm dist-tag add المصادق عليه بالرمز المميز. تتخطى إعادات المحاولة الإصدارات الدقيقة الموجودة بالفعل في npm، ثم تفشل بشكل مغلق ما لم تؤكد إعادة القراءة الكاملة تقارب كل حزمة دقيقة ووسم extended-stable.

يقبل OpenClaw Release Publish هذه المدخلات التي يتحكم فيها المشغّل:

  • tag: وسم إصدار مطلوب؛ يجب أن يكون موجودًا بالفعل
  • preflight_run_id: معرّف تشغيل فحص تمهيدي OpenClaw NPM Release ناجح؛ مطلوب عندما تكون publish_openclaw_npm=true أو plugin_publish_scope=all-publishable
  • full_release_validation_run_id: معرّف تشغيل Full Release Validation ناجح؛ مطلوب عندما تكون publish_openclaw_npm=true أو plugin_publish_scope=all-publishable
  • full_release_validation_run_attempt: المحاولة الموجبة الدقيقة المقترنة بـfull_release_validation_run_id؛ مطلوبة كلما تم توفير معرّف التشغيل
  • windows_node_tag: وسم إصدار openclaw/openclaw-windows-node دقيق وغير تمهيدي؛ مطلوب لنشر OpenClaw المستقر
  • windows_node_installer_digests: خريطة JSON مضغوطة ومعتمدة للمرشح تربط أسماء مُثبّتات Windows الحالية بملخصات sha256: المثبتة الخاصة بها؛ مطلوبة لنشر OpenClaw المستقر
  • npm_telegram_run_id: معرّف تشغيل NPM Telegram Beta E2E ناجح اختياري لتضمينه في دليل الإصدار النهائي
  • npm_dist_tag: وسم npm المستهدف لحزمة OpenClaw، وأحد القيم alpha أو beta أو latest
  • plugin_publish_scope: قيمته الافتراضية all-publishable؛ استخدم selected فقط لأعمال الإصلاح المركزة الخاصة بـPlugin فقط مع publish_openclaw_npm=false
  • plugins: أسماء حزم @openclaw/* مفصولة بفواصل عندما تكون plugin_publish_scope=selected
  • publish_openclaw_npm: قيمته الافتراضية true؛ عيّن false فقط عند استخدام سير العمل كمنسق إصلاح خاص بـPlugin فقط
  • release_profile: ملف تعريف تغطية الإصدار المستخدم في ملخصات دليل الإصدار؛ قيمته الافتراضية from-validation، التي تقرؤه من بيان التحقق، أو تجاوزها باستخدام beta أو stable أو full
  • wait_for_clawhub: قيمته الافتراضية false حتى لا يحظر المكوّن الجانبي لـClawHub توفر npm؛ عيّن true فقط عندما يجب أن يتضمن اكتمال سير العمل اكتمال ClawHub

يقبل OpenClaw Release Checks هذه المدخلات التي يتحكم فيها المشغّل:

  • ref: الفرع أو الوسم أو SHA الكامل للالتزام المراد التحقق منه. تتطلب عمليات التحقق التي تتضمن أسرارًا أن يكون الالتزام الذي جرى حله قابلًا للوصول إليه من فرع OpenClaw أو وسم إصدار.
  • run_release_soak: فعّل التحقق الشامل المباشر/E2E، ومسار إصدار Docker، واختبار التحمل لجميع الناجين من الترقية منذ البداية ضمن عمليات التحقق من الإصدار التجريبي. يُفرض تفعيله بواسطة release_profile=stable وrelease_profile=full.

القواعد:

  • يجوز نشر الإصدارات النهائية والتصحيحية العادية التي يقل رقم التصحيح فيها عن 33 إلى beta أو latest. يجب نشر الإصدارات النهائية التي يساوي رقم التصحيح فيها 33 أو يزيد عليه إلى extended-stable، وتُرفض الإصدارات ذات لاحقة التصحيح عند ذلك الحد.
  • لا يجوز نشر وسوم الإصدارات التجريبية المسبقة إلا إلى beta؛ ولا يجوز نشر وسوم إصدارات ألفا المسبقة إلا إلى alpha
  • بالنسبة إلى OpenClaw NPM Release، لا يُسمح بإدخال SHA كامل للالتزام إلا عندما preflight_only=true
  • يكون OpenClaw Release Checks وFull Release Validation دائمًا مخصصين للتحقق فقط
  • يجب أن يستخدم مسار النشر الفعلي npm_dist_tag نفسه المستخدم أثناء الفحص المسبق؛ ويتحقق سير العمل من بيانات التعريف هذه قبل متابعة النشر

تسلسل الإصدار التجريبي العادي/أحدث إصدار مستقر

هذا التسلسل القديم مخصص للإصدار المنسق العادي الذي يتولى أيضًا مسؤولية الإضافات، وإصدار GitHub، وWindows، وأعمال المنصات الأخرى. وهو ليس مسار الإصدار المستقر الممتد الشهري الخاص بـ npm فقط، .33+، والموضح في أعلى هذه الصفحة.

عند إعداد إصدار مستقر منسق عادي:

  1. شغّل OpenClaw NPM Release باستخدام preflight_only=true. قبل وجود الوسم، يمكنك استخدام SHA الالتزام الحالي الكامل لفرع سير العمل لإجراء تشغيل تجريبي مخصص للتحقق فقط لسير عمل الفحص المسبق.
  2. اختر npm_dist_tag=beta للتدفق العادي الذي يبدأ بالإصدار التجريبي، أو latest فقط عندما تريد عمدًا النشر مباشرةً كإصدار مستقر.
  3. شغّل Full Release Validation على فرع الإصدار أو وسم الإصدار أو SHA الكامل للالتزام عندما تريد تغطية CI العادية إلى جانب ذاكرة التخزين المؤقت المباشرة للمطالبات، وDocker، وQA Lab، وMatrix، وTelegram من سير عمل يدوي واحد. إذا كنت تحتاج عمدًا إلى مخطط الاختبارات العادي الحتمي فقط، فشغّل بدلًا من ذلك سير العمل اليدوي CI على مرجع الإصدار.
  4. حدّد وسم إصدار openclaw/openclaw-windows-node الدقيق غير المسبق الذي يجب شحن مثبّتاته الموقّعة لبنيتي x64 وARM64. احفظه باسم windows_node_tag، واحفظ خريطة البصمات الموجزة المتحقق منها باسم windows_node_installer_digests. تسجل أداة الإصدار المرشح المساعدة كليهما وتدرجهما في أمر النشر الذي تنشئه.
  5. احفظ preflight_run_id وfull_release_validation_run_id الناجحين، وfull_release_validation_run_attempt الدقيق.
  6. شغّل OpenClaw Release Publish من main الموثوق باستخدام tag نفسه، وnpm_dist_tag نفسه، وwindows_node_tag المحدد، وwindows_node_installer_digests المحفوظ الخاص به، وpreflight_run_id المحفوظ، وfull_release_validation_run_id، وfull_release_validation_run_attempt. ينشر هذا الإضافات المفصولة خارجيًا إلى npm وClawHub قبل ترقية حزمة OpenClaw على npm.
  7. إذا وصل الإصدار إلى beta، فاستخدم سير العمل openclaw/releases/.github/workflows/openclaw-npm-dist-tags.yml لترقية ذلك الإصدار المستقر من beta إلى latest.
  8. إذا نُشر الإصدار عمدًا مباشرةً إلى latest وكان ينبغي أن يتبع beta البنية المستقرة نفسها فورًا، فاستخدم سير عمل الإصدار نفسه لتوجيه وسمي التوزيع كليهما إلى الإصدار المستقر، أو اترك مزامنة الإصلاح الذاتي المجدولة الخاصة به تنقل beta لاحقًا.

يوجد تعديل وسم التوزيع في مستودع سجل الإصدارات لأنه لا يزال يتطلب NPM_TOKEN، بينما يحتفظ مستودع المصدر بالنشر باستخدام OIDC فقط. وهذا يُبقي كلاً من مسار النشر المباشر ومسار الترقية الذي يبدأ بالإصدار التجريبي موثقًا ومرئيًا للمشغّل.

إذا اضطر أحد المشرفين إلى الرجوع إلى مصادقة npm المحلية، فلا تُشغّل أي أوامر لواجهة 1Password CLI ‏(op) إلا داخل جلسة tmux مخصصة. لا تستدعِ op مباشرةً من الصدفة الرئيسية للوكيل؛ إذ إن إبقاءه داخل tmux يجعل المطالبات والتنبيهات ومعالجة كلمات المرور لمرة واحدة قابلة للمراقبة ويمنع تكرار تنبيهات المضيف.

المراجع العامة

يستخدم المشرفون وثائق الإصدار الخاصة في openclaw/maintainers/release/README.md لدليل التشغيل الفعلي.

ذو صلة

Was this useful?
On this page

On this page