--- read_when: - البحث عن تعريفات قنوات الإصدار العامة - تشغيل التحقق من الإصدار أو قبول الحزمة - البحث عن تسمية الإصدارات ووتيرة إصدارها summary: مسارات الإصدار، وقائمة تحقق المشغّل، وبيئات التحقق، وتسمية الإصدارات، والوتيرة الزمنية title: سياسة الإصدار x-i18n: generated_at: "2026-07-12T06:30:50Z" model: gpt-5.6 postprocess_version: locale-links-v1 provider: openai source_hash: 4270a96560ee908c09d26782ffa75dbc695f4ab83c5a80dfb7abe5befd8ca686 source_path: reference/RELEASING.md workflow: 16 --- يعرض OpenClaw حاليًا ثلاث قنوات تحديث موجّهة للمستخدمين: - المستقرة: قناة الإصدار المُروَّج الحالية، التي لا تزال تُحلّ عبر `latest` في npm إلى أن يكتمل الإنجاز المرحلي المنفصل الخاص بـ CLI/القناة - التجريبية: وسوم الإصدارات التمهيدية التي تُنشر إلى `beta` في npm - التطويرية: الرأس المتحرك للفرع `main` وبشكل منفصل، يمكن لمشغّلي الإصدار نشر حزمة النواة للشهر المكتمل السابق إلى `extended-stable` في npm، بدءًا من التصحيح `33`. يستمر مسار الإصدار النهائي الاعتيادي للشهر الحالي على `latest` في npm؛ ولا يغيّر فصل النشر هذا من جانب المشغّل، بحد ذاته، آلية تحديد قناة التحديث في CLI. إصدارات Tideclaw ألفا هي مسار تمهيدي داخلي منفصل (وسم توزيع npm‏ `alpha`)، وتغطيها فقرتا [مدخلات سير عمل NPM](#npm-workflow-inputs) و[صناديق اختبار الإصدار](#release-test-boxes). ## تسمية الإصدارات - إصدار 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` - إصدار تمهيدي تجريبي: `YYYY.M.PATCH-beta.N`، ووسم git هو `vYYYY.M.PATCH-beta.N` - إصدار تمهيدي ألفا: `YYYY.M.PATCH-alpha.N`، ووسم git هو `vYYYY.M.PATCH-alpha.N` - لا تُضِف أصفارًا بادئة إلى الشهر أو التصحيح مطلقًا - يمثّل `PATCH` رقمًا تسلسليًا لمسار إصدارات شهري، وليس يومًا تقويميًا. تُقدِّم الإصدارات النهائية الاعتيادية والتجريبية المسار الحالي؛ أما وسوم ألفا فقط فلا تستهلك رقم التصحيح التجريبي/الاعتيادي ولا تُقدِّمه، لذا تجاهل وسوم ألفا القديمة فقط ذات أرقام التصحيح الأعلى عند اختيار مسار تجريبي أو اعتيادي. - تستخدم إصدارات ألفا/الليلية مسار التصحيح التالي الذي لم يُصدر بعد، ولا تزيد سوى `alpha.N` للإصدارات المتكررة. وبمجرد أن يحصل ذلك التصحيح على إصدار تجريبي، تنتقل إصدارات ألفا الجديدة إلى التصحيح التالي. - إصدارات npm غير قابلة للتغيير: لا تحذف وسمًا منشورًا أو تعِد نشره أو استخدامه مطلقًا. أنشئ بدلًا منه رقم الإصدار التمهيدي التالي أو التصحيح الشهري التالي. - يستمر `latest` في اتباع مسار npm الاعتيادي/اليومي الحالي؛ ويمثّل `beta` هدف التثبيت التجريبي الحالي - يعني `extended-stable` حزمة npm المدعومة للشهر السابق، بدءًا من التصحيح `33`؛ وتكون التصحيحات `34` وما بعدها إصدارات صيانة على ذلك المسار الشهري - تُنشر الإصدارات النهائية الاعتيادية والإصدارات التصحيحية الاعتيادية إلى `beta` في npm افتراضيًا؛ ويمكن لمشغّلي الإصدار استهداف `latest` صراحةً، أو ترقية إصدار تجريبي خضع للتدقيق لاحقًا - ينشر المسار الشهري المخصص الممتد الاستقرار حزمة نواة npm وكل Plugin رسمي قابل للنشر إلى npm بالإصدار المطابق نفسه تمامًا. ولا ينشر Plugins إلى ClawHub، ولا عناصر macOS أو Windows، ولا إصدار GitHub، ولا وسوم توزيع المستودعات الخاصة، ولا صور Docker، ولا عناصر الأجهزة المحمولة، ولا تنزيلات الموقع الإلكتروني. - يشحن كل إصدار نهائي اعتيادي حزمة npm وتطبيق macOS وحزمة APK مستقلة موقّعة لنظام Android ومثبّتات Windows Hub الموقّعة معًا. تتحقق الإصدارات التجريبية عادةً من مسار npm/الحزمة وتنشره أولًا، بينما يقتصر بناء التطبيقات الأصلية وتوقيعها وتوثيقها وترقيتها على الإصدار النهائي الاعتيادي ما لم يُطلب ذلك صراحةً. ## وتيرة الإصدار - تنتقل الإصدارات عبر المسار التجريبي أولًا؛ ولا يتبعه المسار المستقر إلا بعد التحقق من أحدث إصدار تجريبي - ينشئ المشرفون الإصدارات عادةً من فرع `release/YYYY.M.PATCH` مُنشأ من `main` الحالي، كي لا يؤدي التحقق من الإصدار وإصلاحاته إلى حظر التطوير الجديد على `main` - إذا دُفع وسم إصدار تجريبي أو نُشر ثم احتاج إلى إصلاح، ينشئ المشرفون وسم `-beta.N` التالي بدلًا من حذف الوسم القديم أو إعادة إنشائه - تظل إجراءات الإصدار التفصيلية والموافقات وبيانات الاعتماد وملاحظات الاسترداد مقتصرة على المشرفين ## نشر npm الشهري الممتد الاستقرار فقط هذا استثناء مخصص من إجراء الإصدار الاعتيادي أدناه. بالنسبة إلى شهر مكتمل `YYYY.M`، أنشئ `extended-stable/YYYY.M.33`؛ وانشر `vYYYY.M.33` وتصحيحات الصيانة اللاحقة من الفرع نفسه. يجب أن يحدد كل من وسم الإصدار ورأس الفرع ونسخة العمل وإصدار الحزمة وفحص npm التمهيدي وتشغيل التحقق الكامل من الإصدار الالتزام نفسه. يجب أن يحتوي `main` المحمي مسبقًا على إصدار نهائي لشهر تقويمي لاحق بشكل صارم وبتصحيح أقل من `33`؛ وتظل تصحيحات الصيانة مؤهلة بعد تقدّم `main` بأكثر من شهر واحد. على فرع الممتد الاستقرار المحدد، ارفع إصدار الحزمة الجذرية إلى `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`، وانتظر اكتمال المصفوفة وقراءة السجل اللاحقة، ثم احفظ معرّف تشغيل إصدار NPM للـ Plugin الناجح: ```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` قبل النجاح. إذا فشل تشغيل جزئي، فأعد تشغيل الأمر نفسه: يُعاد استخدام الحزم المنشورة مسبقًا، وتُسوّى وسوم Plugins المفقودة أو القديمة ضمن بيئة إصدار npm، وتظل القراءة اللاحقة النهائية تغطي مجموعة الحزم الكاملة. بعد نجاح سير عمل Plugins وجاهزية بيئة إصدار npm، انشر ملف tarball الأساسي المطابق من الفحص التمهيدي. يتحقق نشر النواة من أن تشغيل Plugins المُشار إليه في حالة `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= \ -f full_release_validation_run_id= \ -f full_release_validation_run_attempt= \ -f 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، أو موافقة البيئة، أو القراءة اللاحقة للسجل، أو دليل إصلاح أداة التحديد. يتحقق سير عمل النشر من هويات الفحص التمهيدي والتحقق وتشغيل Plugins المُشار إليها، ومن بصمة ملف tarball المُعدّ، ومن أدوات تحديد سجل النواة. أكّد النتيجة بصورة مستقلة بعد نجاح سير العمل: ```bash npm view openclaw@YYYY.M.P version --userconfig "$(mktemp)" npm view openclaw@extended-stable version --userconfig "$(mktemp)" ``` يجب أن يُرجع كلا الأمرين `YYYY.M.P`. إذا نجح النشر لكن فشلت القراءة اللاحقة لأداة التحديد، فلا تعِد نشر إصدار الحزمة غير القابل للتغيير. استخدم أمر الإصلاح الوحيد `npm dist-tag add openclaw@YYYY.M.P extended-stable` المطبوع في الملخص دائم التشغيل لسير العمل الفاشل، ثم كرر القراءتين اللاحقتين المستقلتين. تُعد العودة إلى أداة التحديد السابقة قرارًا منفصلًا للمشغّل، وليست مسار إصلاح القراءة اللاحقة. تحدد وثائق الدعم العامة مبدئيًا Slack وDiscord وCodex بوصفها أسطح Plugins التي يغطيها الممتد الاستقرار. هذه القائمة بيان دعم وليست قائمة سماح في شيفرة الإصدار: يتبع كل Plugin رسمي قابل للنشر إلى npm مسار النشر نفسه ذي الإصدار المطابق تمامًا. تظل قائمة التحقق الاعتيادية أدناه مسؤولة عن الإصدارات التجريبية و`latest` وإصدار GitHub وPlugins وmacOS وWindows ومنشورات المنصات الأخرى. لا تنفّذ تلك الخطوات لهذا المسار الممتد الاستقرار الخاص بـ npm فقط. ## قائمة تحقق مشغّل الإصدار الاعتيادي تمثّل قائمة التحقق هذه الشكل العام لتدفق الإصدار. وتظل تفاصيل بيانات الاعتماد الخاصة والتوقيع والتوثيق واسترداد وسوم التوزيع والتراجع الطارئ ضمن دليل تشغيل الإصدار المقتصر على المشرفين. 1. ابدأ من `main` الحالي: اسحب أحدث التغييرات، وتأكد من دفع الالتزام المستهدف، وتأكد من أن حالة CI لفرع `main` سليمة بما يكفي لإنشاء فرع منه. 2. أنشئ القسم العلوي من `CHANGELOG.md` من طلبات السحب المدمجة وجميع الالتزامات المباشرة منذ آخر وسم إصدار يمكن الوصول إليه. اجعل الإدخالات موجهة للمستخدم، وأزل التكرار بين إدخالات طلبات السحب والالتزامات المباشرة المتداخلة، ثم نفّذ الالتزام والدفع، وأعد تنفيذ إعادة التأسيس/السحب مرة أخرى قبل إنشاء الفرع. عندما يعيد وسم إصدار متشعب أو نقل لاحق إلى الأمام ربط طلبات سحب سبق إصدارها، مرّر ذلك الوسم صراحةً باستخدام `--shipped-ref`؛ يستخدم المتحقق صفوف طلبات السحب الصريحة من سجلات المساهمات الكاملة في الأقسام المرقمة من لقطة الوسم، ويتجاهل `Unreleased`، ويسجل قائمة طلبات السحب المستبعدة وعددها بدقة. 3. راجع سجلات توافق الإصدار في `src/plugins/compat/registry.ts` و`src/commands/doctor/shared/deprecation-compat.ts`. أزل التوافق المنتهي فقط عندما يظل مسار الترقية مشمولًا، أو سجّل سبب الاحتفاظ به عمدًا. 4. أنشئ `release/YYYY.M.PATCH` من `main` الحالي. لا تنفّذ أعمال الإصدار المعتادة مباشرةً على `main`. 5. حدّث كل موضع إصدار مطلوب للوسم، ثم شغّل `pnpm release:prep`. يحدّث هذا، بالترتيب، إصدارات plugins، وملفات تقليص npm، وقائمة plugins، ومخطط الإعداد الأساسي، وبيانات إعداد القنوات المضمّنة، وخط أساس وثائق الإعداد، وصادرات حزمة تطوير Plugin، وخط أساس واجهة برمجة تطبيقات حزمة تطوير Plugin. نفّذ التزامًا لأي انحراف مولّد قبل وضع الوسم، ثم شغّل الفحص التمهيدي المحلي الحتمي: `pnpm check:test-types`، و`pnpm check:architecture`، و`pnpm build && pnpm ui:build`، و`pnpm release:check`. 6. شغّل `OpenClaw NPM Release` مع `preflight_only=true`. قبل وجود الوسم، يُسمح باستخدام SHA كامل بطول 40 محرفًا لفرع الإصدار لإجراء الفحص التمهيدي المخصص للتحقق فقط. يولّد الفحص التمهيدي أدلة إصدار التبعيات للرسم البياني الدقيق للتبعيات المسحوب حاليًا ويخزنها في أثر الفحص التمهيدي لـ npm. احفظ قيمة `preflight_run_id` الناجحة. 7. ابدأ جميع اختبارات ما قبل الإصدار باستخدام `Full Release Validation` لفرع الإصدار أو الوسم أو SHA الكامل للالتزام. هذه هي نقطة الدخول اليدوية الوحيدة لمجموعات اختبارات الإصدار الأربع الكبرى: Vitest وDocker وQA Lab والحزمة. احفظ `full_release_validation_run_id` والقيمة الدقيقة لـ `full_release_validation_run_attempt`؛ فكلاهما مدخل مطلوب لـ `OpenClaw NPM Release` و`OpenClaw Release Publish`. 8. إذا فشل التحقق، أصلح المشكلة في فرع الإصدار وأعد تشغيل أصغر ملف أو مسار أو مهمة سير عمل أو ملف تعريف حزمة أو مزود أو قائمة سماح للنماذج يثبت الإصلاح. لا تعد تشغيل المظلة الكاملة إلا عندما يجعل السطح المتغير الأدلة السابقة قديمة. 9. لمرشح بيتا موسوم، شغّل `pnpm release:candidate -- --tag vYYYY.M.PATCH-beta.N` من فرع `release/YYYY.M.PATCH` المطابق. وللإصدار المستقر، مرّر أيضًا إصدار مصدر Windows المطلوب: `pnpm release:candidate -- --tag vYYYY.M.PATCH --windows-node-tag vX.Y.Z`. تستخدم الأداة المساعدة `main` الموثوق به مصدرًا لسير العمل، بينما يستهدف كل سير عمل الوسم الدقيق. تسجل هوية المرشح/الأدوات غير القابلة للتغيير ومعرّفات التشغيلات المُرسلة في `.artifacts/release-candidate//release-candidate-state.json`؛ وتؤدي إعادة تشغيل الأمر نفسه إلى استئناف تلك التشغيلات نفسها بدقة، بينما يؤدي أي انحراف في المرشح أو الأدوات أو ملف التعريف أو الخيارات إلى الفشل المغلق. قبل إرسال مصفوفة التحقق الكاملة، تعرض الأداة المساعدة بصورة حتمية نص إصدار GitHub الخاص بالوسم الدقيق، وترفض غياب عنوان الإصدار، أو نصًا يتجاوز الحد ولا يمكنه استخدام الصيغة الموجزة القياسية، أو مصدرًا لقاعدة/هدف سجل المساهمات لا يمكن الوصول إليه من الوسم. كما تتحقق من أي بيانات وصفية صريحة لاستبعاد خط أساس الإصدارات المشحونة بمقارنتها بسجلات الوسوم التراكمية المشار إليها. ثم تشغّل فحوص الإصدار المولّدة محليًا، وترسل أو تتحقق من أدلة التحقق الكامل من الإصدار والفحص التمهيدي لـ npm، وتشغّل دليل التثبيت الجديد/التحديث في Parallels مقابل حزمة tar الدقيقة المُعدّة بالإضافة إلى دليل حزمة Telegram، وتسجل خطط npm وClawHub الخاصة بالـ plugins، ولا تطبع أمر `OpenClaw Release Publish` الدقيق إلا بعد أن تصبح حزمة الأدلة سليمة. يرسل `OpenClaw Release Publish` حزم plugins المحددة أو جميع الحزم القابلة للنشر إلى npm والمجموعة نفسها إلى ClawHub بالتوازي، ثم يروّج أثر الفحص التمهيدي المُعدّ لـ npm الخاص بـ OpenClaw باستخدام وسم التوزيع المطابق بعد نجاح نشر plugins إلى npm. يظل سحب الإصدار جذر المنتج/البيانات، بينما يُنفّذ التخطيط والتحقق النهائي من سحب مصدر سير العمل الموثوق به بدقة، حتى لا يتمكن التزام إصدار أقدم من استخدام أدوات إصدار قديمة بصمت. قبل بدء أي عملية نشر فرعية، يعرض نص إصدار GitHub الدقيق ويخزنه مؤقتًا. عندما يلائم القسم المطابق الكامل من `CHANGELOG.md` حد GitHub البالغ 125,000 محرف وسقف الأمان المطابق للعارض البالغ 125,000 بايت، تحتوي الصفحة على قسم `## YYYY.M.PATCH` نفسه تمامًا، بما في ذلك عنوانه. عندما لا يلائم قسم المصدر، تحتفظ الصفحة بالملاحظات التحريرية المجمعة نفسها تمامًا وتستبدل سجل المساهمات المتضخم برابط ثابت إلى السجل الكامل في `CHANGELOG.md` المثبّت عند الوسم؛ ولا تُنشر أبدًا سجلات جزئية أو نقاط مقتطعة. يختار سير العمل النص الكامل أو الموجز قبل إضافة `### التحقق من الإصدار`؛ وإذا كان ذيل الإثبات سيتجاوز الحد، فإنه يحتفظ بالنص القياسي ويعتمد بدلًا من ذلك على الدليل المرفق غير القابل للتغيير. تصبح الإصدارات المستقرة المنشورة إلى وسم npm ‏`latest` أحدث إصدار على GitHub، بينما تُنشأ إصدارات الصيانة المستقرة المحتفظ بها على وسم npm ‏`beta` مع `latest=false` في GitHub. يرفع سير العمل أيضًا أدلة تبعيات الفحص التمهيدي، وبيان التحقق الكامل، وأدلة التحقق من السجل بعد النشر إلى إصدار GitHub للاستجابة للحوادث بعد الإصدار. يطبع معرّفات التشغيلات الفرعية فورًا، ويوافق تلقائيًا على بوابات بيئة الإصدار التي يُسمح لرمز سير العمل بالموافقة عليها، ويلخّص المهام الفرعية الفاشلة مع أواخر السجلات، وينشئ صفحة مسودة إصدار GitHub مقدمًا ويروّج أصول Windows وAndroid بالتزامن مع نشر OpenClaw إلى npm، ويُنهي صفحة الإصدار وأدلة التبعيات بعد نجاح تلك المراحل، وينتظر ClawHub كلما كان OpenClaw يُنشر إلى npm، ثم يشغّل متحقق بيتا من `main` الموثوق به ويرفع أدلة ما بعد النشر لإصدار GitHub، وحزمة npm، وحزم plugins المحددة على npm، وحزم ClawHub المحددة، ومعرّفات تشغيلات سير العمل الفرعية، ومعرّف تشغيل NPM الاختياري الخاص بـ Telegram. يتطلب متحقق تمهيد ClawHub مسار سير العمل وSHA الدقيقين لـ `main` الموثوق به، ومحاولات تشغيل المنتج والتشغيل النهائي، وSHA الإصدار، ومجموعة الحزم المطلوبة، ورباعية أثر الحزمة غير القابلة للتغيير، وأثر القراءة الراجعة النهائية من السجل؛ ولا يُقبل تشغيل ناجح قديم يستند إلى مرجع إصدار. بعد ذلك، شغّل اختبار قبول الحزمة بعد النشر على الحزمة المنشورة `openclaw@YYYY.M.PATCH-beta.N` أو `openclaw@beta`. إذا احتاج إصدار تمهيدي مدفوع أو منشور إلى إصلاح، فأنشئ رقم الإصدار التمهيدي المطابق التالي؛ ولا تحذف الإصدار القديم أو تعيد كتابته أبدًا. 10. بالنسبة إلى الإصدار المستقر، لا تتابع إلا بعد أن يمتلك إصدار بيتا المدقق أو مرشح الإصدار أدلة التحقق المطلوبة. يمر نشر npm المستقر أيضًا عبر `OpenClaw Release Publish`، مع إعادة استخدام أثر الفحص التمهيدي الناجح بواسطة `preflight_run_id`. يتطلب استعداد إصدار macOS المستقر أيضًا ملفات `.zip` و`.dmg` و`.dSYM.zip` المعبأة، وملف `appcast.xml` المحدّث على `main`؛ وينشر سير عمل نشر macOS ملف appcast الموقّع تلقائيًا إلى `main` العام بعد التحقق من أصول الإصدار، أو يفتح/يحدّث طلب سحب لملف appcast إذا منعت حماية الفرع الدفع المباشر. يتطلب استعداد 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`، ويتحقق من الأصول الثلاثة كلها قبل النشر. 11. بعد النشر، شغّل متحقق ما بعد النشر لـ npm، واختبار Telegram الشامل الاختياري المستقل لحزمة npm المنشورة عندما تحتاج إلى إثبات القناة بعد النشر، وروّج وسم التوزيع عند الحاجة، وتحقق من صفحة إصدار GitHub المولّدة، ونفّذ خطوات إعلان الإصدار، ثم أكمل [إغلاق `main` المستقر](#stable-main-closeout) قبل اعتبار الإصدار المستقر مكتملًا. ## إغلاق `main` المستقر لا يكتمل النشر المستقر حتى يحمل `main` حالة الإصدار المشحون الفعلية. 1. ابدأ من أحدث نسخة جديدة من `main`. دقّق `release/YYYY.M.PATCH` بالمقارنة معها، وانقل إلى الأمام الإصلاحات الحقيقية غير الموجودة في `main`. لا تدمج بصورة عمياء محولات التوافق أو الاختبار أو التحقق الخاصة بالإصدار فقط في `main` الأحدث. 2. اضبط `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` التي تحمل الإصدار المشحون وسجل التغييرات وملف appcast بعد النشر المستقر. يقرأ أدلة ما بعد النشر غير القابلة للتغيير لربط الوسم المشحون بتشغيلات التحقق الكامل من الإصدار والنشر الخاصة به، ثم يتحقق من حالة `main` المستقرة، والإصدار، وفترة الاستقرار الإلزامية للإصدار المستقر، وأدلة الأداء المانعة. ويرفق بيان إغلاق غير قابل للتغيير وملخص تحقق بإصدار GitHub. يتخطى مشغّل الدفع التلقائي الإصدارات القديمة التي تسبق أدلة ما بعد النشر غير القابلة للتغيير، ولا يعامل هذا التخطي أبدًا على أنه إغلاق مكتمل. يتطلب الإغلاق الكامل كلا الأصلين وملخص تحقق مطابقًا. يعيد البيان الجزئي تشغيل SHA المسجّل لـ `main` وتدريب التراجع لتوليد بايتات متطابقة، ثم يرفق ملخص التحقق المفقود؛ ويظل الزوج غير الصالح، أو ملخص التحقق دون بيان، مانعًا. يتخطى التشغيل المُفعّل بالدفع الذي لا يحتوي على متغيرات مستودع تدريب التراجع دون إكمال الإغلاق؛ ويظل سجل التدريب المفقود أو الأقدم من 90 يومًا مانعًا للإغلاق اليدوي المدعوم بالأدلة. تبقى أوامر الاسترداد الخاصة في دليل التشغيل المخصص للمشرفين فقط. استخدم الإرسال اليدوي فقط لإصلاح إغلاق مستقر مدعوم بالأدلة أو إعادة تشغيله. يمكن لوسم تصحيح احتياطي قديم إعادة استخدام أدلة الحزمة الأساسية فقط عندما يُحل وسم التصحيح إلى التزام المصدر نفسه الذي يُحل إليه الوسم المستقر الأساسي. يعيد إصدار Android الخاص به استخدام ملف APK المتحقق منه للوسم الأساسي، ويضيف معلومات المصدر الخاصة بوسم التصحيح. يجب أن ينشر التصحيح ذو المصدر المختلف أدلة الحزمة الخاصة به ويتحقق منها، وأن يستخدم قيمة `versionCode` أعلى لنظام Android. ## الفحص التمهيدي للإصدار - شغّل `pnpm check:test-types` قبل الفحص التمهيدي للإصدار لضمان استمرار تغطية TypeScript الخاص بالاختبارات خارج بوابة `pnpm check` المحلية الأسرع. - شغّل `pnpm check:architecture` قبل الفحص التمهيدي للإصدار لضمان نجاح فحوصات دورات الاستيراد الأوسع وحدود البنية خارج البوابة المحلية الأسرع. - شغّل `pnpm build && pnpm ui:build` قبل `pnpm release:check` لكي تكون عناصر إصدار `dist/*` المتوقعة وحزمة واجهة التحكم موجودة لخطوة التحقق من الحزمة. - شغّل `pnpm release:prep` بعد رفع إصدار الجذر وقبل إنشاء الوسم. يشغّل هذا الأمر جميع مولّدات الإصدار الحتمية التي يشيع انحرافها بعد تغيير الإصدار أو الإعدادات أو API: إصدارات المكوّنات الإضافية، وملفات تقليص npm، وقائمة المكوّنات الإضافية، ومخطط الإعدادات الأساسي، وبيانات تعريف إعدادات القنوات المضمّنة، وخط أساس وثائق الإعدادات، وتصديرات SDK للمكوّنات الإضافية، وخط أساس API الخاص بـ SDK للمكوّنات الإضافية. يعيد `pnpm release:check` تشغيل وسائل الحماية هذه في وضع الفحص (بالإضافة إلى فحص ميزانية سطح SDK للمكوّنات الإضافية)، ويبلّغ عن كل حالات فشل انحراف المحتوى المولّد في مرور واحد قبل تشغيل فحوصات إصدار الحزم. - تحدّث مزامنة إصدارات المكوّنات الإضافية افتراضيًا حزمة وقت التشغيل `@openclaw/ai` القابلة للنشر، وإصدارات حزم المكوّنات الإضافية الرسمية، والحدود الدنيا الحالية لـ `openclaw.compat.pluginApi` إلى إصدار OpenClaw. تعامل مع هذا الحقل بوصفه الحد الأدنى لـ API الخاص بـ SDK/وقت تشغيل المكوّنات الإضافية، وليس مجرد نسخة من إصدار الحزمة: بالنسبة إلى إصدارات المكوّنات الإضافية فقط التي يُراد لها عمدًا أن تظل متوافقة مع مضيفات OpenClaw الأقدم، أبقِ الحد الأدنى عند أقدم API مضيف مدعوم ووثّق هذا الاختيار في إثبات إصدار المكوّن الإضافي. - شغّل سير العمل اليدوي `Full Release Validation` قبل الموافقة على الإصدار لبدء جميع بيئات اختبار ما قبل الإصدار من نقطة دخول واحدة. يقبل فرعًا أو وسمًا أو معرّف SHA كاملًا لالتزام، ويطلق `CI` يدويًا، كما يطلق `OpenClaw Release Checks` لفحص التثبيت السريع، وقبول الحزمة، وفحوصات الحزمة عبر أنظمة التشغيل، وتكافؤ QA Lab، ومسارات Matrix وTelegram. تتضمن عمليات التشغيل المستقرة والكاملة دائمًا اختبارات live/E2E شاملة واختبار تحمّل لمسار إصدار Docker؛ ويُحتفظ بـ `run_release_soak=true` لإجراء اختبار تحمّل صريح لإصدار بيتا. يوفّر قبول الحزمة اختبار Telegram E2E القياسي للحزمة أثناء التحقق من الإصدار المرشح، ما يتجنب تشغيل مستطلع مباشر ثانٍ بالتزامن. قدّم `release_package_spec` بعد نشر إصدار بيتا لإعادة استخدام حزمة npm المنشورة عبر فحوصات الإصدار وقبول الحزمة واختبار Telegram E2E للحزمة، من دون إعادة بناء ملف tarball الخاص بالإصدار. قدّم `npm_telegram_package_spec` فقط عندما ينبغي أن يستخدم Telegram حزمة منشورة مختلفة عن بقية عملية التحقق من الإصدار. قدّم `package_acceptance_package_spec` عندما ينبغي أن يستخدم قبول الحزمة حزمة منشورة مختلفة عن مواصفات حزمة الإصدار. قدّم `evidence_package_spec` عندما ينبغي أن يثبت تقرير أدلة الإصدار أن التحقق يطابق حزمة npm منشورة من دون فرض تشغيل Telegram E2E. ```bash gh workflow run full-release-validation.yml --ref main -f 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 published_upgrade_survivor_baseline=openclaw@2026.4.26 -f telegram_mode=mock-openai ``` ملفات التعريف الشائعة: - `smoke`: مسارات التثبيت والقناة والوكيل، وشبكة Gateway، وإعادة تحميل الإعدادات - `package`: مسارات الحزمة والتحديث وإعادة التشغيل والمكوّنات الإضافية المعتمدة على عناصر الحزمة، من دون OpenWebUI أو ClawHub المباشر - `product`: ملف تعريف الحزمة بالإضافة إلى قنوات MCP، وتنظيف Cron والوكلاء الفرعيين، وبحث الويب عبر OpenAI، وOpenWebUI - `full`: أجزاء مسار إصدار Docker مع OpenWebUI - `custom`: تحديد دقيق لـ `docker_lanes` لإعادة تشغيل مركّزة - شغّل سير العمل اليدوي `CI` مباشرةً عندما لا تحتاج إلا إلى تغطية CI عادية وحتمية للإصدار المرشح. تتجاوز عمليات الإطلاق اليدوية لـ CI تحديد النطاق وفق التغييرات، وتفرض تشغيل تقسيمات Linux Node، وتقسيمات المكوّنات الإضافية المضمّنة، وتقسيمات عقود المكوّنات الإضافية والقنوات، وتوافق Node 22، و`check-*`، و`check-additional-*`، وفحوصات العناصر المبنية السريعة، وفحوصات الوثائق، وSkills الخاصة بـ Python، وWindows، وmacOS، ومسارات التدويل لواجهة التحكم. تشغّل عمليات 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` عند التحقق من بيانات القياس عن بُعد للإصدار. يختبر QA Lab عبر مستقبِل OTLP/HTTP محلي، ويتحقق من تصدير الآثار والمقاييس والسجلات، ومن تقييد سمات الآثار وتنقيح المحتوى والمعرّفات، من دون الحاجة إلى Opik أو Langfuse أو أي مجمّع خارجي آخر. - شغّل `pnpm qa:otel:collector-smoke` عند التحقق من التوافق مع المجمّع. يوجّه تصدير OTLP نفسه من QA Lab عبر حاوية Docker حقيقية لـ OpenTelemetry Collector قبل تنفيذ تحققات المستقبِل المحلي. - شغّل `pnpm qa:prometheus:smoke` عند التحقق من جمع بيانات Prometheus المحمي. يختبر QA Lab، ويرفض عمليات الجمع غير المصادق عليها، ويتحقق من أن مجموعات المقاييس الحرجة للإصدار تظل خالية من محتوى المطالبات والمعرّفات الخام ورموز المصادقة والمسارات المحلية. - شغّل `pnpm qa:observability:smoke` لتشغيل مساري الفحص السريع لـ OpenTelemetry وPrometheus في نسخة الشيفرة المصدرية تباعًا. - شغّل `pnpm release:check` قبل كل إصدار ذي وسم. - يولّد الفحص التمهيدي لـ `OpenClaw NPM Release` أدلة إصدار التبعيات قبل أن يحزم ملف tarball الخاص بـ npm. تُعد بوابة الثغرات الأمنية في تنبيهات npm حاجبة للإصدار. أما تقارير مخاطر بيان التبعيات المتعدية، وملكية التبعيات وسطح تثبيتها، وتغييرات التبعيات، فهي أدلة للإصدار فقط. يقارن تقرير تغييرات التبعيات الإصدار المرشح بآخر وسم إصدار يمكن الوصول إليه. يرفع الفحص التمهيدي أدلة التبعيات باسم `openclaw-release-dependency-evidence-`، كما يضمّنها ضمن `dependency-evidence/` داخل عنصر الفحص التمهيدي المُعدّ لـ npm. يعيد مسار النشر الفعلي استخدام عنصر الفحص التمهيدي هذا، ثم يرفق الأدلة نفسها بإصدار GitHub باسم `openclaw--dependency-evidence.zip`. - شغّل `OpenClaw Release Publish` لتنفيذ تسلسل النشر الذي يُجري تغييرات بعد وجود الوسم. أطلق عمليات نشر بيتا والإصدارات المستقرة العادية من `main` الموثوق به؛ إذ يظل وسم الإصدار يحدد الالتزام المستهدف بدقة، ويمكن أن يشير إلى `release/YYYY.M.PATCH`. تظل عمليات نشر Tideclaw alpha على فرع alpha المطابق لها. مرّر `preflight_run_id` الناجح الخاص بـ npm لـ OpenClaw، و`full_release_validation_run_id` الناجح، والقيمة الدقيقة لـ `full_release_validation_run_attempt`، وأبقِ نطاق نشر المكوّنات الإضافية الافتراضي `all-publishable` ما لم تكن تُجري عمدًا إصلاحًا مركّزًا. ينفّذ سير العمل نشر المكوّنات الإضافية إلى npm، ثم نشرها إلى ClawHub، ثم نشر OpenClaw إلى npm بشكل تسلسلي، كي لا تُنشر الحزمة الأساسية قبل مكوّناتها الإضافية المفصولة عنها؛ ويجري ترويج Windows وAndroid بالتزامن مع نشر الحزمة الأساسية إلى npm وبالاستناد إلى صفحة مسودة الإصدار. يمكن استئناف عمليات إعادة النشر: فإذا كان إصدار الحزمة الأساسية منشورًا بالفعل على npm، يتجاوز سير العمل إطلاق نشر الحزمة الأساسية بعد إثبات أن ملف tarball في السجل يطابق عنصر الفحص التمهيدي الخاص بالوسم، كما يُتجاوز ترويج Windows وAndroid عندما يحتوي الإصدار بالفعل على عقد عناصر الحزمة المتحقق منه، بحيث تعيد المحاولة تنفيذ المراحل الفاشلة فقط. تتطلب إصلاحات المكوّنات الإضافية المركّزة فقط تعيين `plugin_publish_scope=selected` وقائمة غير فارغة من المكوّنات الإضافية. وتتطلب عمليات `all-publishable` الخاصة بالمكوّنات الإضافية فقط أدلة كاملة وغير قابلة للتغيير من الفحص التمهيدي وFull Release Validation؛ وتُرفض الأدلة الجزئية. - يتطلب `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 للتكامل المستمر. شغّل سير العمل اليدوي `QA-Lab - All Lanes` مع `matrix_profile=all` و`matrix_shards=true` عندما تريد جردًا كاملًا ومتوازيًا للنقل والوسائط والتشفير من طرف إلى طرف في Matrix. - يُعد التحقق من تثبيت بيئة التشغيل وترقيتها عبر أنظمة التشغيل جزءًا من `OpenClaw Release Checks` و`Full Release Validation` العامَّين، اللذين يستدعيان سير العمل القابل لإعادة الاستخدام `.github/workflows/openclaw-cross-os-release-checks-reusable.yml` مباشرةً. هذا الفصل مقصود: إبقاء مسار إصدار npm الفعلي قصيرًا وحتميًا ومركّزًا على المصنوعات، بينما تبقى الفحوصات الحية الأبطأ في مسارها الخاص كي لا تؤخر النشر أو تمنعه. - يجب تشغيل فحوصات الإصدار التي تتضمن أسرارًا عبر `Full Release Validation` أو من مرجع سير العمل `main`/الإصدار، لكي يظل منطق سير العمل والأسرار خاضعين للتحكم. - يقبل `OpenClaw Release Checks` فرعًا أو وسمًا أو SHA كاملًا للالتزام، ما دام الالتزام المحسوم قابلًا للوصول من فرع OpenClaw أو وسم إصدار. - يقبل الفحص التمهيدي المخصص للتحقق فقط في `OpenClaw NPM Release` أيضًا SHA الكامل الحالي، المؤلف من 40 محرفًا، لالتزام فرع سير العمل دون اشتراط وسم مدفوع. يقتصر مسار SHA هذا على التحقق، ولا يمكن ترقيته إلى نشر فعلي. في وضع SHA، ينشئ سير العمل `v` فقط لفحص بيانات الحزمة الوصفية؛ أما النشر الفعلي فما يزال يتطلب وسم إصدار حقيقيًا. - يحافظ كلا سيري العمل على مسار النشر والترقية الفعلي على مشغّلات تستضيفها 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، والبناء، وبناء واجهة المستخدم، و`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` (أو إصدار بيتا/التصحيح المطابق) للتحقق من مسار تثبيت السجل المنشور ضمن بادئة مؤقتة جديدة. - بعد نشر إصدار بيتا، شغّل `OPENCLAW_NPM_TELEGRAM_PACKAGE_SPEC=openclaw@YYYY.M.PATCH-beta.N 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_*` مباشرةً. - لتشغيل اختبار بيتا الكامل بعد النشر من جهاز مشرف، استخدم `pnpm release:beta-smoke -- --beta betaN`. يشغّل المساعد التحقق من تحديث npm والهدف الجديد في Parallels، ويطلق `NPM Telegram Beta E2E`، ويستطلع تشغيل سير العمل المحدد، وينزّل المصنوعة، ويطبع تقرير Telegram. - يمكن للمشرفين تشغيل الفحص نفسه بعد النشر من GitHub Actions عبر سير العمل اليدوي `NPM Telegram Beta E2E`. وهو يدوي فقط عن قصد ولا يُشغَّل مع كل دمج. - تستخدم أتمتة الإصدار الخاصة بالمشرفين نهج الفحص التمهيدي ثم الترقية: - يجب أن يجتاز النشر الفعلي إلى npm معرّف تشغيل فحص تمهيدي ناجح لـ npm في `preflight_run_id`. - تستخدم أتمتة نشر إصدارات بيتا العادية والمستقرة وفحصها التمهيدي `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 معرّف تشغيل فحص تمهيدي ناجحًا لنظام macOS في `preflight_run_id` ومعرّف تشغيل تحقق ناجحًا في `validate_run_id`. - تعمل مسارات النشر الفعلي على ترقية المصنوعات المحضّرة بدلًا من إعادة بنائها. - بالنسبة إلى إصدارات التصحيح المستقرة مثل `YYYY.M.PATCH-N`، يفحص مدقق ما بعد النشر أيضًا مسار الترقية نفسه ذي البادئة المؤقتة من `YYYY.M.PATCH` إلى `YYYY.M.PATCH-N`، بحيث لا تتمكن تصحيحات الإصدار من إبقاء عمليات التثبيت العامة الأقدم بصمت على حمولة الإصدار المستقر الأساسي. - يفشل الفحص التمهيدي لإصدار npm بوضع الإغلاق الآمن ما لم تتضمن الحزمة المضغوطة كلًا من `dist/control-ui/index.html` وحمولة غير فارغة في `dist/control-ui/assets/`، كي لا نشحن لوحة معلومات فارغة للمتصفح مرة أخرى. - يتحقق فحص ما بعد النشر أيضًا من وجود نقاط دخول إضافات Plugin وبيانات الحزمة الوصفية في تخطيط السجل المثبت. يفشل مدقق ما بعد النشر لأي إصدار يشحن حمولات مفقودة لبيئة تشغيل Plugin، ولا يمكن ترقيته إلى `latest`. - يفرض `pnpm test:install:smoke` أيضًا ميزانية `unpackedSize` لحزمة npm على حزمة التحديث المرشحة، بحيث يكتشف الاختبار الشامل للمثبّت تضخم الحزمة غير المقصود قبل مسار نشر الإصدار. - إذا طال عمل الإصدار تخطيط التكامل المستمر أو بيانات توقيت الإضافات أو مصفوفات اختبار الإضافات، فأعِد إنشاء مخرجات مصفوفة `plugin-prerelease-extension-shard` المملوكة للمخطط من `.github/workflows/plugin-prerelease.yml` وراجعها قبل الموافقة، كي لا تصف ملاحظات الإصدار تخطيطًا قديمًا للتكامل المستمر. - يشمل الاستعداد لإصدار 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 ``` يجلب المساعد `origin/main` الحالي، ويدفع `release-ci/-...` عند التزام سير العمل الموثوق ذاك، ويشغّل `Full Release Validation` من الفرع المؤقت مع `ref=`، ويعيد استخدام دليل صارم للهدف المحدد عند توفره، ويتحقق من أن كل `headSha` لسير عمل فرعي يطابق SHA سير العمل الأب المثبّت، ثم يحذف الفرع المؤقت. مرّر `-f reuse_evidence=false` لفرض تشغيل جديد أو `--workflow-sha ` لتثبيت التزام أقدم ما يزال قابلًا للوصول من `origin/main` الحالي. لا يكتب سير العمل نفسه مراجع المستودع مطلقًا. يتيح ذلك بقاء أدوات الإصدار الخاصة بـ`main` متاحة دون إضافة التزامات أدوات إلى المرشح، ويتجنب إثبات تشغيل فرعي أحدث لـ`main` عن طريق الخطأ. للتحقق من فرع إصدار أو وسم، شغّله من مرجع سير العمل الموثوق `main` ومرّر فرع الإصدار أو الوسم بصفته `ref`: ```bash 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 \ -f evidence_package_spec=openclaw@YYYY.M.PATCH-beta.N ``` يحلّ سير العمل مرجع الهدف، ويشغّل `CI` اليدوي مع `target_ref=`، ثم يشغّل `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 ظل متجاوزًا. راجع [التحقق الكامل من الإصدار](/ar/reference/full-release-validation) للاطلاع على مصفوفة المراحل الكاملة، والأسماء الدقيقة لوظائف سير العمل، والفروق بين ملفي التعريف المستقر والكامل، والمصنوعات، ومقابض إعادة التشغيل المركّزة. تُشغَّل مسارات العمل الفرعية من المرجع الموثوق الذي يشغّل `Full Release Validation`، وهو عادةً `--ref main`، حتى عندما يشير `ref` الهدف إلى فرع إصدار أو وسم أقدم. يجب أن يستخدم كل تشغيل فرعي SHA المحدد نفسه لسير العمل الأب؛ وإذا تقدم `main` قبل اكتمال تشغيل سير عمل فرعي، يفشل سير العمل الجامع بوضع الإغلاق الآمن. لا يوجد مُدخل منفصل لمرجع سير عمل Full Release Validation؛ اختر حاضنة التشغيل الموثوقة باختيار مرجع تشغيل سير العمل. لا تستخدم `--ref main -f ref=` لإثبات التزام محدد على `main` متحرك؛ إذ لا يمكن استخدام قيم SHA الخام للالتزامات كمراجع لتشغيل سير العمل، لذا استخدم `pnpm ci:full-release --sha ` لإنشاء فرع مؤقت عند `origin/main` الموثوق مع إبقاء SHA الهدف مُدخلًا للمرشح. استخدم `release_profile` لتحديد اتساع التغطية الحية/تغطية المزوّد: - `minimum`: أسرع مسار حي ومسار Docker حرجين للإصدار في OpenAI/النواة - `stable`: الحد الأدنى بالإضافة إلى تغطية مستقرة للمزوّد/الواجهة الخلفية من أجل الموافقة على الإصدار - `full`: الملف المستقر بالإضافة إلى تغطية استشارية واسعة للمزوّدين/الوسائط يشغّل التحقق المستقر والكامل دائمًا الفحص الشامل الحي/من طرف إلى طرف، ومسار إصدار Docker، والمسح المحدود المنشور للترقيات الباقية قبل الترقية. استخدم `run_release_soak=true` لطلب المسح نفسه لإصدار بيتا. يغطي ذلك المسح أحدث أربع حزم مستقرة، بالإضافة إلى خطي الأساس المثبّتين `2026.4.23` و`2026.5.2`، وكذلك تغطية `2026.4.15` الأقدم، مع إزالة خطوط الأساس المكررة وتوزيع كل خط أساس على وظيفة مشغّل Docker مستقلة. يستخدم `OpenClaw Release Checks` مرجع سير العمل الموثوق لحل مرجع الهدف مرة واحدة بوصفه `release-package-under-test`، ثم يعيد استخدام تلك المصنوعة في فحوصات الأنظمة المتعددة، وقبول الحزمة، وفحوصات Docker لمسار الإصدار عند تشغيل اختبار التحمل. يحافظ ذلك على استخدام جميع صناديق الحزم للبايتات نفسها ويتجنب تكرار بناء الحزمة. بعد توفر إصدار بيتا على npm، اضبط `release_package_spec=openclaw@YYYY.M.PATCH-beta.N` لكي تنزّل فحوصات الإصدار الحزمة المشحونة مرة واحدة، وتستخرج SHA مصدر بنائها من `dist/build-info.json`، وتعيد استخدام تلك المصنوعة لمسارات الأنظمة المتعددة، وقبول الحزمة، وDocker لمسار الإصدار، وحزمة Telegram. يستخدم اختبار تثبيت OpenAI السريع عبر أنظمة التشغيل `OPENCLAW_CROSS_OS_OPENAI_MODEL` عند ضبط متغير المستودع/المؤسسة، وإلا فيستخدم `openai/gpt-5.6-luna`، لأن هذا المسار يثبت تثبيت الحزمة، والإعداد الأولي، وتشغيل Gateway، ودورة واحدة حية للوكيل، بدلًا من قياس أداء النموذج الأعلى قدرة. وتظل مصفوفة المزوّدين الحية الأوسع هي موضع التغطية الخاصة بالنماذج. استخدم هذه المتغيرات بحسب مرحلة الإصدار: ```bash # التحقق من فرع مرشح إصدار غير منشور. 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 # التحقق من التزام مدفوع محدد بدقة. gh workflow run full-release-validation.yml \ --ref main \ -f ref=<40-char-sha> \ -f provider=openai \ -f mode=both # بعد نشر إصدار تجريبي، أضف اختبار Telegram الشامل من البداية إلى النهاية للحزمة المنشورة. gh workflow run full-release-validation.yml \ --ref main \ -f ref=release/YYYY.M.PATCH \ -f provider=openai \ -f mode=both \ -f release_profile=full \ -f release_package_spec=openclaw@YYYY.M.PATCH-beta.N \ -f evidence_package_spec=openclaw@YYYY.M.PATCH-beta.N \ -f npm_telegram_provider_mode=mock-openai ``` لا تستخدم المظلة الكاملة كأول إعادة تشغيل بعد إصلاح محدد النطاق. إذا فشلت بيئة واحدة، فاستخدم سير عمل العنصر الفرعي الفاشل أو المهمة أو مسار Docker أو ملف تعريف الحزمة أو موفر النموذج أو مسار ضمان الجودة لإجراء الإثبات التالي. شغّل المظلة الكاملة مجددًا فقط عندما يغيّر الإصلاح تنسيق الإصدار المشترك أو يجعل أدلة جميع البيئات السابقة قديمة. يعيد المتحقق النهائي للمظلة فحص معرّفات تشغيل سُير عمل العناصر الفرعية المسجلة، لذلك بعد نجاح إعادة تشغيل سير عمل فرعي، أعد تشغيل مهمة الأصل الفاشلة `Verify full validation` فقط. يمكن لـ `rerun_group=all` إعادة استخدام تشغيل مظلة أخضر سابق فقط عندما يكون قد تحقق من SHA الهدف نفسه تمامًا، وملف تعريف الإصدار نفسه، وإعداد الاختبار المطوّل الفعلي نفسه، ومدخلات التحقق نفسها. هذا استرداد محدود لإعادة تشغيل المرشح نفسه، وليس إعادة استخدام للأدلة عبر قيم SHA مختلفة. بالنسبة إلى مرشح متغير، بما في ذلك التزام يقتصر على سجل التغييرات أو الإصدار، أعد تشغيل كل بوابة حزمة أو عنصر أو تثبيت أو Docker أو موفر تأثرت بالمسارات المتغيرة أو تجزئات العناصر. تحل تشغيلات المظلة الأحدث للمرجع `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 الشامل من البداية إلى النهاية الأساسي للحزمة داخل قبول الحزمة. يمكن لعمليات إعادة التشغيل المحددة النطاق عبر أنظمة التشغيل إضافة `cross_os_suite_filter=windows/packaged-upgrade` أو مرشح آخر لنظام التشغيل/مجموعة الاختبارات. تمنع إخفاقات فحوص إصدار ضمان الجودة التحقق العادي من الإصدار، بما في ذلك انحراف الأدوات الديناميكية المطلوب في OpenClaw ضمن المستوى القياسي. ومع ذلك، قد تظل تشغيلات Tideclaw alpha تتعامل مع مسارات فحوص الإصدار غير المتعلقة بسلامة الحزمة على أنها استشارية. مع `release_profile=beta`، تكون مجموعات موفر الإنتاج في `Run repo/live E2E validation` استشارية (تحذيرات وليست عوائق)؛ وتبقيها ملفات التعريف المستقرة والكاملة مانعة. عندما يطلب `live_suite_filter` صراحةً مسار ضمان جودة مباشرًا خاضعًا للبوابة مثل 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، وتدويل واجهة التحكم. يُضمَّن 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 أو مختبر ضمان الجودة أو الإنتاج أو الأنظمة المتعددة أو الحزم. استخدم الأمر الأول لـ CI المباشر من دون Android. أضف `include_android=true` عندما يجب أن يغطي CI المباشر لمرشح الإصدار Android: ```bash gh workflow run ci.yml --ref main -f target_ref=release/YYYY.M.PATCH gh 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 كأجزاء مستقلة من `install-smoke` - مسارات شاملة من البداية إلى النهاية للمستودع - أجزاء 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` - مجموعات موفري الإنتاج/الاختبارات الشاملة من البداية إلى النهاية وتغطية نماذج Docker المباشرة عندما تتضمن فحوص الإصدار مجموعات مباشرة استخدم عناصر Docker قبل إعادة التشغيل. يرفع مجدول مسار الإصدار `.artifacts/docker-tests/` متضمنًا سجلات المسارات و`summary.json` و`failures.json` وتوقيتات المراحل وJSON لخطة المجدول وأوامر إعادة التشغيل. للاسترداد المحدد النطاق، استخدم `docker_lanes=` في سير عمل الإنتاج/الاختبارات الشاملة من البداية إلى النهاية القابل لإعادة الاستخدام بدلًا من إعادة تشغيل جميع أجزاء الإصدار. تتضمن أوامر إعادة التشغيل المولّدة `package_artifact_run_id` السابق ومدخلات صور Docker المُعدّة عند توفرها، بحيث يمكن لمسار فاشل إعادة استخدام ملف tarball وصور GHCR نفسيهما. ### مختبر ضمان الجودة بيئة مختبر ضمان الجودة جزء أيضًا من `OpenClaw Release Checks`. وهي بوابة الإصدار للسلوك الوكيلي وعلى مستوى القنوات، ومنفصلة عن Vitest وآليات حزمة Docker. تشمل تغطية مختبر ضمان الجودة للإصدار: - مسار تكافؤ وهمي يقارن مسار مرشح OpenAI بخط الأساس `anthropic/claude-opus-4-8` باستخدام حزمة التكافؤ الوكيلية - ملف تعريف سريع لضمان جودة Matrix المباشر باستخدام بيئة `qa-live-shared` - مسار ضمان جودة Telegram المباشر باستخدام عقود إيجار بيانات اعتماد Convex CI - `pnpm qa:otel:smoke` أو `pnpm qa:otel:collector-smoke` أو `pnpm qa:prometheus:smoke` أو `pnpm qa:observability:smoke` عندما يحتاج قياس الإصدار عن بُعد إلى إثبات محلي صريح استخدم هذه البيئة للإجابة عن السؤال: «هل يتصرف الإصدار بصورة صحيحة في سيناريوهات ضمان الجودة وتدفقات القنوات المباشرة؟». احتفظ بعناوين URL للعناصر الخاصة بمسارات التكافؤ وMatrix وTelegram عند اعتماد الإصدار. تظل تغطية Matrix الكاملة متاحة كتشغيل يدوي مجزأ لمختبر ضمان الجودة بدلًا من المسار الافتراضي الحرج للإصدار. ### الحزمة بيئة الحزمة هي بوابة المنتج القابل للتثبيت. يدعمها `Package Acceptance` والمحلل `scripts/resolve-openclaw-package-candidate.mjs`. يطبّع المحلل المرشح إلى ملف tarball باسم `package-under-test` تستهلكه اختبارات Docker الشاملة من البداية إلى النهاية، ويتحقق من مخزون الحزمة، ويسجل إصدار الحزمة و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 المُدار بصلاحيات الجذر وإعادة تشغيل التحديث مع المصادقة المُهيأة وتثبيت Skills المباشر من ClawHub وتنظيف تبعيات Plugin القديمة وتركيبات Plugin غير المتصلة وتحديث Plugin وتقوية الحماية من تجاوز ربط أوامر Plugin وضمان جودة حزمة 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](/ar/help/testing-updates-plugins). استخدمها عند تحديد مسار التحقق المحلي أو Docker أو قبول الحزمة أو فحص الإصدار الذي يثبت تغييرًا في تثبيت/تحديث Plugin أو تنظيف doctor أو ترحيل الحزمة المنشورة. الترحيل الشامل لتحديث الحزم المنشورة من كل حزمة مستقرة `2026.4.23+` هو سير عمل يدوي منفصل باسم `Update Migration`، وليس جزءًا من CI الكامل للإصدار. تُحدَّد فترة التساهل القديم في قبول الحزم زمنيًا عن قصد. قد تستخدم الحزم حتى `2026.4.25` مسار التوافق لفجوات البيانات الوصفية المنشورة بالفعل إلى npm: إدخالات مخزون ضمان الجودة الخاصة المفقودة من ملف 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 published_upgrade_survivor_baseline=openclaw@2026.4.26 ``` ملفات تعريف الحزمة الشائعة: - `smoke`: مسارات سريعة لتثبيت الحزمة/القناة/الوكيل، وشبكة Gateway، وإعادة تحميل الإعدادات - `package`: عقود تثبيت/تحديث/إعادة تشغيل/حزم Plugin، بالإضافة إلى إثبات مباشر لتثبيت Skills من ClawHub؛ وهذا هو الإعداد الافتراضي لفحص الإصدار - `product`: ‏`package` بالإضافة إلى قنوات MCP، وتنظيف Cron/الوكيل الفرعي، وبحث الويب من OpenAI، وOpenWebUI - `full`: أجزاء مسار إصدار Docker مع OpenWebUI - `custom`: قائمة `docker_lanes` الدقيقة لإعادات التشغيل المركزة لإثبات Telegram لمرشح الحزمة، فعّل `telegram_mode=mock-openai` أو `telegram_mode=live-frontier` في قبول الحزمة. يمرر سير العمل أرشيف `package-under-test` المحلول إلى مسار Telegram؛ ولا يزال سير عمل Telegram المستقل يقبل محدد npm منشورًا لفحوص ما بعد النشر. ## أتمتة نشر الإصدار الاعتيادي بالنسبة إلى نشر الإصدار التجريبي، و`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=`. 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 الموقّع الخاص بالوسم الدقيق، مع مجموع التحقق وإثبات المصدر. تحقق من عقدَي الأصول الأصليين قبل نشر المسودة. مثال على نشر إصدار تجريبي: ```bash gh workflow run openclaw-release-publish.yml \ --ref main \ -f tag=vYYYY.M.PATCH-beta.N \ -f preflight_run_id= \ -f full_release_validation_run_id= \ -f full_release_validation_run_attempt= \ -f npm_dist_tag=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:","OpenClawCompanion-Setup-arm64.exe":"sha256:"}' \ -f preflight_run_id= \ -f full_release_validation_run_id= \ -f 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:","OpenClawCompanion-Setup-arm64.exe":"sha256:"}' \ -f preflight_run_id= \ -f full_release_validation_run_id= \ -f 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= \ -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/الحجم لأرشيف كل حزمة إلى مهمات التحقق والمهمات المحمية. تستخرج المهمة المحمية أدوات `main` الموثوقة فقط، وتتحقق من مجموعة خصائص الأثر عبر GitHub API، وتُنزّل باستخدام معرّف الأثر الدقيق، وتعيد تجزئة كل أرشيف، وتتحقق من مسارات 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`: معرّف تشغيل تمهيدي ناجح موجود، وهو مطلوب في مسار النشر الفعلي كي يعيد سير العمل استخدام الأرشيف المُعد بدلًا من إعادة بنائه - `full_release_validation_run_id`: معرّف تشغيل `Full Release Validation` ناجح لهذا الوسم/SHA، وهو مطلوب للنشر الفعلي. يجوز أن تستمر عمليات نشر الإصدار التجريبي اعتمادًا على الفحص التمهيدي وحده مع تحذير، لكن ترقية الإصدار المستقر/`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` نفسها المستخدمة أثناء الفحص المسبق؛ ويتحقق سير العمل من بيانات التعريف هذه قبل متابعة النشر ## تسلسل الإصدار المستقر العادي beta/latest هذا التسلسل القديم مخصص للإصدار المنسَّق العادي الذي يشمل أيضًا Plugins وإصدار GitHub وWindows وأعمال المنصات الأخرى. وهو ليس مسار `extended-stable` الشهري المخصص لـ npm فقط بإصدارات `.33+` والموثَّق في أعلى هذه الصفحة. عند إصدار نسخة مستقرة عادية ومنسَّقة: 1. شغّل `OpenClaw NPM Release` مع `preflight_only=true`. قبل وجود وسم، يمكنك استخدام SHA الكامل للالتزام الحالي في فرع سير العمل لإجراء تشغيل تجريبي للفحص المسبق مخصص للتحقق فقط. 2. اختر `npm_dist_tag=beta` للمسار العادي الذي يبدأ بـ 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` المحفوظة. ينشر Plugins المفصولة خارجيًا إلى npm وClawHub قبل ترقية حزمة OpenClaw على npm. 7. إذا وصل الإصدار إلى `beta`، فاستخدم سير العمل `openclaw/releases/.github/workflows/openclaw-npm-dist-tags.yml` لترقية ذلك الإصدار المستقر من `beta` إلى `latest`. 8. إذا نُشر الإصدار عمدًا مباشرةً إلى `latest` وكان ينبغي أن يتبع `beta` البنية المستقرة نفسها فورًا، فاستخدم سير عمل الإصدار نفسه لتوجيه وسمَي التوزيع إلى الإصدار المستقر، أو دع مزامنة الإصلاح الذاتي المجدولة تنقل `beta` لاحقًا. يُدار تعديل وسم التوزيع في مستودع سجل الإصدارات لأنه لا يزال يتطلب `NPM_TOKEN`، بينما يحتفظ مستودع المصدر بالنشر المعتمد على OIDC فقط. وبذلك يظل كل من مسار النشر المباشر ومسار الترقية الذي يبدأ بـ beta موثَّقًا ومرئيًا للمشغّلين. إذا اضطر أحد المشرفين إلى الرجوع إلى مصادقة npm المحلية، فيجب تشغيل أي أوامر لواجهة 1Password CLI (`op`) داخل جلسة tmux مخصصة فقط. لا تستدعِ `op` مباشرةً من صدفة الوكيل الرئيسية؛ فإبقاؤه داخل tmux يجعل المطالبات والتنبيهات ومعالجة OTP قابلة للملاحظة ويمنع تكرار تنبيهات المضيف. ## المراجع العامة - [`.github/workflows/full-release-validation.yml`](https://github.com/openclaw/openclaw/blob/main/.github/workflows/full-release-validation.yml) - [`.github/workflows/package-acceptance.yml`](https://github.com/openclaw/openclaw/blob/main/.github/workflows/package-acceptance.yml) - [`.github/workflows/openclaw-npm-release.yml`](https://github.com/openclaw/openclaw/blob/main/.github/workflows/openclaw-npm-release.yml) - [`.github/workflows/openclaw-release-checks.yml`](https://github.com/openclaw/openclaw/blob/main/.github/workflows/openclaw-release-checks.yml) - [`.github/workflows/openclaw-cross-os-release-checks-reusable.yml`](https://github.com/openclaw/openclaw/blob/main/.github/workflows/openclaw-cross-os-release-checks-reusable.yml) - [`scripts/resolve-openclaw-package-candidate.mjs`](https://github.com/openclaw/openclaw/blob/main/scripts/resolve-openclaw-package-candidate.mjs) - [`scripts/openclaw-npm-release-check.ts`](https://github.com/openclaw/openclaw/blob/main/scripts/openclaw-npm-release-check.ts) - [`scripts/package-mac-dist.sh`](https://github.com/openclaw/openclaw/blob/main/scripts/package-mac-dist.sh) - [`scripts/make_appcast.sh`](https://github.com/openclaw/openclaw/blob/main/scripts/make_appcast.sh) يستخدم المشرفون وثائق الإصدار الخاصة في [`openclaw/maintainers/release/README.md`](https://github.com/openclaw/maintainers/blob/main/release/README.md) بوصفها دليل التشغيل الفعلي. ## ذو صلة - [قنوات الإصدار](/ar/install/development-channels)