🔴 LLM "provider rejected the request schema or tool payload" — تشخيص (10:12 الكويت)
- شكوى د. وائل: فشل متكرر، لا يعمل إلا بعد /new، يهز الثقة بـ 4.8.
- الكونفيج سليم 100%: primary=opus-4-8، fallback[0]=opus-4-7، gpt-5.5-pro في #7 (fallback[6]). verify_agreements §3 = pass.
- تناقض حي: session_status يعرض gpt-5.5-pro في المركز الأول للسلسلة الحية (display/effective order) رغم أن الكونفيج يضعه #7 — يستحق مراقبة.
- تصنيف الخطأ (من كود OpenClaw errors-BLA2Tyyy.js): providerRuntimeFailureKind="schema" = classifyFailoverReason="format" → المزوّد رفض شكل الطلب (tool payload/حزمة الرسائل). هذا سبب failover.
- الآلية (ثقة عالية): خطأ format يرفضه كل موديلات السلسلة بنفس الحمولة الفاسدة → تنفد السلسلة → يظهر الخطأ → يستمر كل turn → /new يفرّغ التاريخ فيعمل. = بصمة تاريخ-جلسة فاسد (turn ثقيل/منقطع — M-048/M-063).
- فجوة رصد: أحداث failover لا تظهر في السجل المقروء (INFO level؛ التفاصيل DEBUG) → لم أستطع تحديد العنصر المشوّه بالضبط. صرّحت بذلك لد. وائل.
- سبب سلوكي ضمن تحكّمي: turns ثقيلة (جلسة "المحور 1/2/3" الأكاديمية الطويلة) + تكديس أدوات side-effect. الوقاية = turns أصغر (M-048).
- الإصلاح المقترح: (1) لا تغيير config بلا إذن (gpt-5.5-pro #7 أكّده د. وائل اليوم) (2) turns أصغر (3) سؤال د. وائل عن خيار guard لإعادة-تعيين تلقائية عند format-error.
🔴 عطل الشلل الكامل (Something went wrong loop) — تشخيص 2026-06-26 10:00
حدثان منفصلان (ليس واحداً):
الحدث A — تجمّد العملية أمس ~23:02 الكويت
- لوج 2026-06-25 يتوقف فجأة عند
23:02:49 +03:00بلا أي shutdown نظيف. - صفر أخطاء gemini-3.5-flash أمس → الجلسة كانت تعمل على موديل صالح (Gemini Pro).
- load average مرتفع (~4.0). تجمّد/هنغ كامل للعملية → الحارس داخل الحاوية لم يستطع الإنعاش → د. وائل اضطر يعمل VPS restart من Hostinger.
الحدث B — لغم الموديل الميت بعد الـ restart
- بعد إعادة التشغيل هذا الصباح: أول خطأ 09:55:16.
FailoverError: Unknown model: google/gemini-3.5-flash— الموديل مُسجّل تحت مزوّد EvoLink فقط (evolink/gemini-3.5-flash)، لكنه مُدرَج في السلسلة + قائمة /model ببادئةgoogle/→ غير قابل للحل في بناء 2026.6.9.- اللوج:
isPrimary:true+fallbackConfigured:false= توقيع M-011 (model override يدوي يُعطّل السلسلة الذهبية كاملة). - لذلك: كل رسالة → موت فوري بلا fallback → "Something went wrong". و /new لم ينفع (الـ override لاصق + اللغم في الكونفيج). و VPS restart لم ينفع (المشكلة config لا process).
- تعافى فقط لمّا اختار د. وائل Opus من /models → override لموديل صالح.
الإصلاح المطبّق (verified):
1. حذفgoogle/gemini-3.5-flash من fallbacks (كان position 10) + من خريطة models → استبدل بـ google/gemini-3-flash-preview (معروف في البناء، نفس مزوّد Google، + thinkingLevel:high).
2. أُزيل "Gemini 3.5 Thinking" من منتقي /model → لا يمكن اختياره وكسر الجلسة مجدداً.
3. JSON valid ✓ · restart ✓ · صفر أخطاء بعد 10:04 ✓ · backup: openclaw.json.bak-20260626-100312.
4. السبق التاريخي: M-038 رصد نفس الـ dead alias في cron لكن الإصلاح لم يصل سلسلة الـ main agent — بقي لغماً في position 10.درس: أي موديل في السلسلة/المنتقي يجب أن يكون مُسجّلاً تحت نفس المزوّد المُشار إليه ببادئته. موديل ببادئة مزوّد لا يملكه = موت فوري، وإذا كان manual override = بلا fallback (M-011). يجب فحص دوري أن كل عنصر سلسلة قابل للحل فعلياً.
✅ قرار M-021 / إصلاح اللغم — الخيار (ب) منفّذ 2026-06-26 ~10:15
- د. وائل اختار (ب): إعادة الموديل بالاسم الصحيح بدل حذفه.
- التغيير: position 10 في fallbacks =
evolink/gemini-3.5-flash(بدلgoogle/gemini-3.5-flashالميت). - خريطة الموديلات:
evolink/gemini-3.5-flashalias «Gemini 3.5 Thinking» + thinkingLevel:high (يعمل في /model picker الآن). google/gemini-3-flash-previewرُجّع لـ alias-only (لم يعد في السلسلة).- مُختبر حيّاً قبل التطبيق: EvoLink /chat/completions → content "OK", finish_reason stop, 112 reasoning tokens (موديل thinking). ERROR None.
- verify §22.5 حُدّث ليطلب
evolink/gemini-3.5-flash(M-071) ويرفض البادئة google/ الميتة. - سابقة عاملة:
evolink/glm-5.2موجود أصلاً في السلسلة → بادئة evolink/ مثبتة. - backup: openclaw.json.bak-20260626-100312.
M-071 (الدرس الجديد): بادئة المزوّد الكاذبة = موت فوري
أي موديل في السلسلة/المنتقي ببادئة مزوّد لا يملكه فعلاً = "Unknown model" = موت، وإذا manual override = بلا fallback (M-011). EvoLink aggregator يملك gemini-3.5-flash لا Google. القاعدة: بادئة الموديل يجب أن تطابق المزوّد المُسجَّل تحته فعلاً، ويُختبر حيّاً قبل الإدراج.✅ إصلاح إعادة حقن Nexos (الأمر الثاني من screenshot د. وائل) — M-072 · 2026-06-26 ~11:30
السبب الجذري (مؤكّد من كود/hostinger/server.mjs المصدري):
- منصّة Hostinger تحقن
NEXOS_API_KEYفي بيئة الحاوية (PID 1 → wrapper PID 15 → openclaw PID 234). مؤكّد:/proc/234/environفيه NEXOS_API_KEY رغم تعليقه في env.sh. - الـ wrapper (دالة X) يكتب
nexos:default+nexos-anthropic:defaultفي auth-profiles.json بلا شرط عند كل إقلاع (writeFileSync = close_write)، مفتاحها = NEXOS_API_KEY. ودالة H/Ee تضيف مزوّد nexos للموديلات إن وُجد المفتاح. - ثم حارسي ينظّف + يُرسل Telegram → ضجيج في كل restart.
scripts/daemons/inotify_nexos_guard.sh:
- يُنظّف الآن البروفايلين (nexos:default + nexos-anthropic:default — الثاني كان يفوته).
- صامت للـ re-seed الروتيني عند الإقلاع (نافذة STARTUP_GRACE=150s، log فقط بلا Telegram).
- ينبّه Telegram فقط للحقن أثناء التشغيل الحي (الشاذ فعلاً).
- مُختبر حيّاً: حقنتُ nexos:default in-place → نُظّف خلال ثوانٍ → سُجّل «routine startup re-seed purged silently» بلا Telegram ✓.
- backup الحارس القديم محفوظ.
pkill -f <اسم نسبي> يطابق جلسة exec نفسها فيقتلها (SIGTERM للأمر). ❌ scan /proc بأمر يحتوي اسم العملية = مطابقة ذاتية + عدّ خاطئ. ✅ استخدم bracket-trick [i]notify... + kill بـ PID صريح. (تدخّلي المتكرر خلق يتامى نافست keepalive قبل الاستقرار على نسخة واحدة.)