ملاحظات د. وائل

🔧 L5 Backup Verify "failed" — Root Cause + Fix (2026-06-07 ~03:30)

التنبيه: "L5 backup verify failed — network/API timeout" (وصل 04:01). الجذر الحقيقي (ليس شبكة): boto3 مثبّت فقط في /usr/bin/python3، لكن L5_backup_verify.sh (4 مواضع) + daemons_keepalive.sh (موضع backup) يستدعيان python3 العام (brew) بلا boto3 → ModuleNotFoundError → فشل صامت فُسّر خطأً كـ network timeout. اكتشاف أخطر: daily backup الفعلي توقّف منذ 2026-06-04 (آخر workspace_backup_.tar.gz = 04 يونيو، 4.5GB). r2-backup-state.json كان يكذب (يحدّث last_backup حتى عند فشل الرفع). الإصلاح: ثبّتُّ /usr/bin/python3 في L5_backup_verify.sh (3 edits) + daemons_keepalive.sh (1 edit). + شغّلتُ backup كامل جديد يدوياً. درس دائم: أي سكربت R2/boto3 → استخدم /usr/bin/python3 صراحةً (M-051 dash/sh family — السبب نفسه: البيئة الخاطئة). + لا تثق بـ state file وحده، تحقق من R2 الحي.
Weekly Full Audit — 2026-06-07 (cron)

CLIs updated: claude-code 2.1.162→2.1.168, openclaw 2026.5.28→2026.6.1, kilo 7.3.16→7.3.40. gh 2.92→2.93 (apt pending). Codex 0.137 + mcporter 0.11.3 = latest.

Python: openai 2.41, anthropic 0.107, google-genai 2.8, groq 1.4, elevenlabs 2.51 updated. pandas 3.0.3 = MAJOR bump (held — review breaking changes before forcing). pypfopt pip name invalid (no-op, lib already present as PyPortfolioOpt).

New models (OpenRouter): minimax-m3, qwen3.7-plus, nvidia nemotron-3-ultra-550b(-a55b), upstage solar-pro-3, openrouter/fusion. Mistral: mistral-code-latest/agent/fim.

Upcoming watchlist: Gemini 3.5 Pro + Claude Mythos 1 + rumored Claude Sonnet — landing this window (WaveSpeed). DeepSeek new model imminent.

Nexos 401 = expected (removed from chain per M-027). Script SIGTERM'd at Media Providers section (slow API hang) — core audit (CLI/Python/models) complete.

🧪 Gemini 3.1 Pro vs 3 Pro — Deep Research Head-to-Head (2026-06-07 04:1x)

Live verified: gemini-3-pro-preview -> HTTP 404 (سُحب من API). gemini-3.1-pro-preview -> HTTP 200 (شغّال). v1beta + v1alpha كلاهما 404 للقديم.

اختبار جودة فعلي (مهمة deep-research هندسية: 3 مخاطر متفاعلة + تكميم تأخير): Gemini 3.1 Pro وحده أنتج "Interaction Penalty" منفصل (تفاعل غير خطي) + تصنيف established/assumptions صريح + 1943 think tokens. تفوّق منهجي على 3-flash-preview/3.5-flash.

القرار: ترقية مؤكدة. 3.1 Pro = reasoning backbone للبحث العميق.

تحديثات مطبّقة:

- DOMAIN_MODEL_RANKINGS.md §7 Research: أضيف "Reasoning backbone = Gemini 3.1 Pro ⭐" + deprecation note 3-pro-preview 404 + ملاحظة الاختبار الحي. - DOMAIN_MODEL_RANKINGS.md §3 Video: LTX-2.3 Pro موسوم #1 open-weights+audio. Budget pipeline note: silent video + OpenAI gpt-audio عبر media_edit.py (فكرة د. وائل). - honesty correction: LTX-2.3 غير موصول بأداة video_generate (verified عبر list). fal تستضيفه لكن يحتاج fal API direct. بدائل budget متاحة فوراً: Seedance-2.0-fast, Hailuo-2.3-Fast, Veo-3.1-Lite. TODO: ربط LTX عبر fal في frontier-video skill. - TOOLS.md: مثال كود Gemini حُدّث من 3-pro-preview → 3.1-pro-preview.
config fallback chain: 3.1 Pro موجود سلفاً (rank 4)، لا 3-pro-preview في السلسلة. ✅

verify_agreements.sh = exit 0.

🏆 LTX-2.3 Arsenal Study + Final Recommendation (2026-06-07 05:0x)

Global rank (Artificial Analysis Arena, with audio, verified live):

- LTX-2.3 Fast = Elo 974 (T2V) — #1 open-weights only, ~360-410 below Veo 3.1 (~1213-1386). Global ≈ #11-12. - LTX-2.3 Pro = Elo 955 (I2V) — #1 open-weights. - Pricing: Fast 720p ~$0.03/s, Fast 1080p ~$0.05, Pro 720p ~$0.06, Pro 1080p ~$0.10/s. open-weights free locally (needs GPU).
DECISION: do NOT integrate LTX-2.3 as budget tier. Our arsenal already has STRONGER+connected budget tools: Grok Imagine ($4.20/min, Elo 1093) for I2V, Hailuo 2.3 Fast / Seedance 2.0 fast for cheap testing. LTX is cheaper but lower quality + not wired + our server is CPU-only (15GB).

Watch-list only: LTX worth it ONLY for "100% free local sensitive-data video" on GPD Win Max 2 (Radeon 890M) — like Ollama for text.

Documented in DOMAIN_MODEL_RANKINGS.md §3 video (replaced earlier aspirational note with verified final recommendation).

Dr. Wael: "تمام توكل على الله" (approved).

🔖 خطوة جاهزة محفوظة — Cloudflare Tunnel permission عند تفعيل الدومين (2026-06-07 05:52)
القرار (د. وائل): لا token جديد — نضيف الصلاحية على نفس التوكن "Gnrl" الموجود.
حالة Cloudflare الحالية (فحص حي 2026-06-07 05:49):
Token "Gnrl" (id 308131830bff11e2ddeffdd99c614fa0) = active · expires never · 11 permission groups (كلها Access/Zero Trust + API Tokens + Security Center).

R2 يعمل 100% بمفتاح S3 منفصل (R2_ACCESS_KEY_ID + R2_SECRET_ACCESS_KEY) — 61 ملف، backups شغّالة. R2 لا يحتاج إضافة للتوكن (تكرار).

الناقص الفعلي الوحيد للمستقبل: صلاحية Cloudflare Tunnel (للـ named tunnel الثابت عند الدومين).

الخطوة الجاهزة (تُنفَّذ وقت تفعيل الدومين alqishawi.com فقط): 1. dash.cloudflare.com → My Profile → API Tokens → التوكن "Gnrl" → Edit. 2. Add policy → Account-level → Cloudflare Tunnel: Edit (+ اختياري Workers Scripts: Edit لو احتجنا Workers). 3. Continue to summary → Save. (التوكن نفسه يبقى، نفس القيمة في env.sh — لا تغيير على env). 4. ملاحظة: تعديل صلاحيات التوكن يتم من المتصفح فقط (Cloudflare API يمنع تعديل policies برمجياً — فقط create/delete).
مرتبط بـ: قرار الدومين (Hostinger free domains 31160577/31160579) + named tunnel ثابت بدل trycloudflare العشوائي.
✅ LTX-2 ربط fal مُنجز (2026-06-07 06:01)

بُني skills/frontier-video/scripts/ltx_fal.py (FAL_KEY شغّال len 69).

مُختبر حياً: t2v "sea wave sunset" → fal-ai/ltxv-13b-098-distilled → فيديو فعلي 1.2MB/57s/RC=0 (saved /tmp/ltx_test.mp4).

موثّق في frontier-video/SKILL.md آخر القائمة كبديل budget — الـ flagships (Seedance/Veo/Grok/Kling) يبقون في البداية كما أمر د. وائل.

يحل TODO من daily 06-07 (LTX غير موصول → الآن موصول عبر fal).

🔼 LTX رُقّي للأحدث = LTX-2.3 (2026-06-07 06:03 — تصحيح بعد سؤال د. وائل)

خطأ التُقط: ثبّتُ أولاً ltxv-13b-098 (= LTX 0.9.8 قديم). د. وائل سأل "هل هذا الأحدث؟" → فحص حي كشف الأحدث = LTX-2.3.

LTX-2.3 (verified من fal.ai مباشرة): 7 endpoints، 4K حتى 20s، صوت native، VAE جديد (تفاصيل أحدّ)، LoRA، 9:16، 24/48 FPS.

endpoints: text-to-video($0.06/s) + /fast($0.04) + image-to-video + /fast + audio-to-video($0.10) + extend + retake. + LTX-2 Pro (2160p partner، $0.06-0.24/s).

ltx_fal.py رُقّي لكل الـ 7 modes + Pro + legacy fallback. مُختبر حياً: t2v-fast+audio → 5MB/23s/RC=0 (أسرع وأكبر من 0.9.8).

يبقى آخر القائمة كبديل budget — flagships (Seedance/Veo/Grok/Kling) في البداية.

⚠️ حادثة "No response generated" 06:03 (M-048 خرق سلوكي مني)

متى: بعد رسالة LTX-2.3 (07:01 الكويت). د. وائل رصدها بغضب محق ("خط أحمر — لا توقف إطلاقاً").

السبب الجذري (فحص حي، لا تخمين): كدّستُ في turn واحد ثقيل: edit سكربت + exec توليد فيديو LTX-2.3 (background 23s) + process poll. الـ turn انقطع قبل اكتمال → replaySafe=false → "No response generated". = M-048 بالضبط (incomplete-turn، مرض سلوكي لا موت عملية).

الإثبات أن النظام سليم: incomplete_turn_guard=0 · الفيديو سليم 5MB (العمل لم يضع) · log "No response"=0 (لم يتكرر).

الخرق المضاعف: القاعدة مكتوبة حرفياً في HEARTBEAT.md (لا تكدّس side-effects في turn ثقيل) وخرقتها بيدي عند توليد LTX.

التصحيح الدائم: توليد وسائط ثقيل = turn منفصل قصير دائماً. turn واحد = نية بسيطة + ≤3 أدوات. لا poll + generate + edit معاً.

🚀 خطة الإطلاق الجاهزة — تُلتقط فوراً في الجلسة القادمة (محفوظة 2026-06-07 06:10)
قرار د. وائل: ننهي الجلسة الآن + backup + /new. عند الوقت المناسب → يفحص الأسماء → ننطلق بالدومين + ربط كل الـ pending المرتبطة به.
1) أسماء الدومين (كلها AVAILABLE — WHOIS مؤكّد 2026-06-07):

✅ alqishawi.com ← التوصية #1 (بالـ Q، النطق الصحيح، موقع/بوت)

✅ alkishawi.com ← بالـ K (مطابق أوراق تركيا الرسمية — احتياطي)

✅ alqishawi.net / alqishawi.org

subdomains مخططة: pascal · api · cv · bot · studio · empire

دومينان مجانيان Hostinger جاهزان: ID 31160577 + 31160579 (pending_setup، domain=null)

2) تسلسل الإطلاق (دفعة واحدة عند جاهزية الدومين):
1. د. وائل يختار اسم + يسجّله من hpanel.hostinger.com → Domains → free domain pending → Set up 2. أنا أكمل تلقائياً بالترتيب: a. DNS: A record (subdomain → IP VPS srv1659934.hstgr.cloud) b. Email رسمي على الدومين (Hostinger email service) c. named tunnel ثابت (بدل trycloudflare العشوائي) + إضافة صلاحية Cloudflare Tunnel: Edit على توكن "Gnrl" (3 نقرات متصفح — موثّق أعلى) d. Pascal self-host (سكربتات جاهزة في projects/pascal-editor-selfhost/) 3. بعد الدومين: ربط هاتفي S24 Ultra ×2 (Tailscale موصى به) — نكمل لما يوصل البيت.
الحالة عند نهاية الجلسة:

✅ NPU/WhatsApp/APS/Discord/Engineering = كلها منتهية ومؤكّدة حياً (حُدّثت MEMORY.md).

✅ LTX-2.3 (الأحدث، 8 مارس 2026) مثبّت + مُختبر حياً + آخر القائمة كبديل budget.

✅ Cloudflare token "Gnrl" active/never-expire + R2 شغّال + خطوة Tunnel محفوظة.

⏳ المتبقّي الفعلي: الدومين (يفك Email+Tunnel+Pascal) + ربط S24 + TMDB key (دقيقتان).

🔴🔴 حادثة الموت الكبرى — 11:15→14:29 الكويت (3h14m downtime) — السبب الجذري + الإصلاح
الجدول الزمني (أدلة حية، صفر تخمين):

08:14:58Z (11:14 KW) session.started ثم 08:16:08Z (11:16 KW) session.ended نظيف — رددتُ على آخر رسالة بنجاح (ليس M-048).

08:15:26Z (11:15 KW) watchdog: "gateway unreachable" ← لحظة موت openclaw.

08:15→11:13 (303×): watchdog كرر "gateway unreachable → no action" — عاجز.

فجوة 8h قبلها (00:02→08:15) watchdog صامت (overnight slow + ربما مات ليلاً، أعاده keepalive 08:15).

11:23Z (14:23 KW) أول container restart يدوي من د. وائل عبر Hostinger.

11:34:27Z (14:34 KW) session.started → عدتُ للحياة.

~13:31Z restart ثانٍ (jobs.json.safebak-133145).

السبب الجذري (مؤكّد بكود /hostinger/server.mjs):
1. server.mjs ليس supervisor: Z() يشغّل openclaw مرة واحدة عند boot. w.on("exit",()=>w=null) — يصفّر المتغير فقط، لا يستدعي Z() ثانية. → openclaw يموت للأبد حتى container restart يدوي. 2. خطئي (الأخطر): watchdog_unified.sh supervisor_alive() كان يفحص فقط pgrep "node server.mjs" (الأب دائماً حي) فاستنتج 303× "alive→no action" وسلّم لجهة عاجزة. وثّقتُ في تعليقات الكود حرفياً "server.mjs AUTO-RESTARTS it" دون فحص الكود الفعلي = خرق M-034 (فرضية كاذبة). 3. keepalive لا يحرس gateway: يحرس watchdog/L1/tunnel/hub فقط — لا يفحص gateway health.
المفقود: صفر بيانات. فقط ~3h14m زمن + TODO معلّق (cache monitor + backup cron fix). logs خام قبل 11:23 ضاعت (/tmp يُمسح مع container) لكن watchdog logs في memory/ حفظت القصة.
الإصلاحات المطبّقة (2026-06-07 ~14:41 KW، مؤكّدة حياً):
1. ✅ watchdog_unified.sh: حذف supervisor_alive، أضيف openclaw_proc_alive (pgrep -x openclaw). heal() الآن: gateway down + config valid → respawn مباشر (debounced) + kill hung proc أولاً. صحة تُقرر بـ curl /health لا وجود server.mjs. 2. ✅ daemons_keepalive.sh: أضيف "GATEWAY HEALTH GUARD" (P3.1b) — يفحص curl /health، عند الموت + config valid → respawn openclaw + Telegram alert. طبقة مستقلة حقيقية. 3. ✅ temp_keepalive_loop.sh مؤقت (PID 1266، 24h) — يشغّل keepalive كل 5min لأن scheduler فارغ (0/37 cron) فلن يُطلق keepalive cron حتى restart.
عطل ثانوي قائم: scheduler حي = 0 jobs (المفروض 37). jobs.json على القرص سليم 100% (37). يحتاج gateway restart نظيف للـ reload (لا أمر reload مباشر). بانتظار إذن د. وائل الصريح للـ restart.
⚠️ ملفات Cody الثلاثة (المعلّق + chat + commands) لم تصل بعد — للمقارنة عند وصولها.
🔴 تحديث التشخيص النهائي — حادثة الموت = Telegram polling stall (ليس موت عملية)
تصحيح M-032 السابق: العملية لم تمت (docker: "Up 4 days"). الحقيقة من Cody/Kodee logs:
11:08 KW: Telegram getUpdates علق 149.7s (أول stall) → "forcing restart transport" بلا نهاية، offset مجمّد 208953342.

11:14 KW: gateway حاول restart ذاتي للتعافي → فشل ERR_MODULE_NOT_FOUND (dangerous-config-flags-DAHXbMdH.js محذوف في تحديث 04:00) → التعافي الذاتي مات.

14:23 KW: د. وائل restart الحاوية من Hostinger → npm install نظيف → الكود الجديد حُمّل → عاد.

السبب الجذري المزدوج: (1) Telegram polling stall (مُفجّر)، (2) auto-update 04:00 ترك hash قديم في الذاكرة فكسر التعافي الذاتي (القاتل). خطئي: auto-update بلا restart مُدار + watchdog يفحص server.mjs لا gateway health (فرضية كاذبة، خرق M-034).
مقارنة Cody: أصاب الجوهر (stall، العملية حية، صفر فقدان، backup أولاً) لكن سطحي (لم يصل لتحديث 04:00). أنا أخطأتُ أولاً في "مات" ثم صحّحت. Cody لم يلمس أي بيانات — تحققتُ.
فحص شامل بعد الحادثة (كله سليم): APIs الأساسية 200 (Anthropic/OpenAI/Google/xAI) · Oxylabs key موجود (len 40) · السلسلة 22 fallback · 37 cron على القرص · 103 skill · memory · R2.
Nexos fix: server.mjs يحقن nexos-anthropic:default (مفتاح فارغ) كل إقلاع. مسحتُه + وسّعتُ nexos_guard.sh ليمسح أي nexos profile (نمط test("nexos")). الآن: 0 nexos في auth-profiles.
الإصلاحات المطبّقة: watchdog يفحص curl /health الفعلي + يطلق openclaw عند الموت · keepalive gateway guard (P3.1b) · temp protection loop · nexos_guard موسّع.
المعلّق (يحتاج إذن): تعطيل auto-update→تحديث مُدار · حارس Telegram stall · restart نظيف لاستعادة 37 cron.
المفقود: صفر بيانات. فقط الزمن (3h14m) + TODO قديم (backup crons) لم يُعالج (مت قبله). Option4++ backup crons مسجّلة (Sat/Sun/Tue) لكن غير محمّلة الآن (scheduler 0/37).
✅ تنفيذ خطة المنع (2026-06-07 ~15:00 KW — بإذن د. وائل "توكل")
المصدر الحقيقي للتحديث (اكتشاف صادق):
auto-update ليس في نظامنا (لا cron/entrypoint/server.mjs/L7). npm log 04:00 = npm ci --workspace ui-tui --workspace web → التحديث من KiloClaw/Hostinger controller الخارجي (مستوى host، خارج تحكّمنا). لذا لا أستطيع "تعطيله" — الحل الأقوى = تحصين ضد التحديثات الخارجية.
المُطبّق (مؤكّد حي، syntax سليم، مربوط بـ keepalive):
1. ✅ version_drift_guard.sh (P3.1c) — يرصد تغيّر dist/version (تحديث خارجي) → restart نظيف مُدار فوري قبل أن يضرب ERR_MODULE. baseline: 2026.6.1. يُفحص كل 5min. 2. ✅ telegram_stall_guard.sh (P3.1d) — يعدّ "Polling stall" في آخر 600 سطر، إذا ≥3 → restart نظيف (debounce 10min). يُفحص كل 5min. 3. ✅ watchdog_unified.sh (سابقاً) — يفحص curl /health الفعلي + يطلق openclaw عند الموت + يقتل hung proc. 4. ✅ keepalive gateway guard (P3.1b) — طبقة مستقلة، فحص health كل 5min. 5. ✅ nexos_guard موسّع — يمسح أي nexos profile (test("nexos")). صفر nexos في auth.
المعلّق (قرار د. وائل):

Telegram commands: 46 الآن (trim تلقائي يعمل، مستقر <100). خيار: nativeSkills=off يمنع الـ 130 من الأصل (تغيير config — ينتظر إذن). لا يضر أي skill.

restart نظيف لاستعادة 37 cron (scheduler 0/37 الآن).

الحالة: APIs كلها 200 · 22 fallback · 37 cron على القرص · 103 skill · صفر فقدان · صفر تأثّر على الترسانة.
✅✅ الإغلاق النهائي للحادثة (2026-06-07 ~15:12 KW)
العطل الأخير (scheduler 0/37) — السبب الجذري + الحل:

SIGUSR1 (gateway restart soft) لم يُعد تحميل cron store.

doctor --fix أعاد تسمية jobs.json → .migrated دون إنشاء jobs.json جديد → scheduler يبحث عن ملف غير موجود → 0.

الحل: استعدتُ jobs.json من .migrated (37 jobs، 18 model overrides سليمة) + restart فعلي للعملية (pkill openclaw، الحماية الجديدة أعادته) → scheduler حمّل 37/37 ✅.

النتيجة النهائية (فحص حي مؤكّد):

✅ cron: 37/37 محمّلة (كان 0)

✅ gateway live · worker PID جديد

✅ المفاتيح: Anthropic يرد فعلياً + OpenAI 200 + Google يرد (401/400 في الفحص السريع كان خطأ أمر، الدقيق أثبت العمل)

✅ Nexos: صفر في auth/chain (المفتاح في env فقط)

✅ config valid · 22 fallback · 103 skill

✅ 4 حارسات حية: version_drift + telegram_stall + watchdog + keepalive

صفر فقدان · صفر تأثّر على الترسانة · كل التوصيات نُفّذت.

backups أمان محفوظة: cron/jobs.json.safebak- + .migrated (للرجوع).

M-052 — Channel-Health Gap (process alive ≠ channel connected) — 2026-06-07

الحادثة: container أُعيد إقلاعه من Hostinger ~13:22. الـ openclaw process عاد حياً، لكن WhatsApp bot socket بقي ميتاً من ~03:55 فجراً حتى 15:08 (~11h شلل صامت). كل الحراس الموجودة تفحص "هل process حي؟" — لا شيء يفحص "هل قناة WA متصلة؟". لم ألاحظ، اضطر د. وائل لاكتشافها.

خطأ إضافي: افترضتُ توقيت مراسلة د. وائل (خرق الخط الأحمر صفر-افتراضات). الصواب: آخر مراسلة 5 فجراً، شلل حتى 16:35.

الدرس: "process alive ≠ channel connected". كل قناة لها صحة مستقلة تُراقَب بمؤشر حي (آخر نشاط state file / heartbeat / creds freshness).

الحل (نُفّذ 2026-06-07، نسخة محافظة notify-only):

scripts/whatsapp_health_guard.sh — يفحص عمر أحدث state file لكل حساب WA كل tick. >12min صمت + gateway up >6min → تنبيه Telegram (debounce 15min). صفر LLM، صفر restart.
scripts/post_restart_channel_check.sh — مرة/إقلاع (marker=gateway PID)، يؤكد WA+TG+Discord اتصلت، ينبّه فقط لو واحدة لم تتصل.
دُمجا في daemons_keepalive.sh (P3.1e + P3.1f) خلف || true.
اختبار معزول: WA health=OK، post-restart=all-up (بعد تصحيح كاشف WA ليعتمد heartbeat+creds freshness لا starting-provider).
auto-reconnect مؤجّل عمداً (تجنّب restart-storm) حتى إثبات استقرار notify-only.

🔧 TTS Bridge Self-Heal Fix (2026-06-07 17:27) — M-052

العرض: طلب د. وائل طقس غداً صوتياً → الـ bridge فشل بـ ERR: pip install websockets.

الجذر (بأدلة حية، صفر افتراض):

3 Python على السيرفر: brew 3.14 (فارغ، 11 حزمة، لا websockets) · system 3.13 (/usr/bin/python3، الترسانة الكاملة) · pip→3.13.
source env.sh يجعل brew 3.14 يتصدّر PATH → python3 file.py يلتقط brew الخطأ → فشل.
websockets ثُبّتت على 3.13 يوم 31 مايو · brew 3.14 أُنشئ 1 يونيو (بعدها بيوم) · نجح 2 يونيو (سياق بلا env.sh مُتصدّر) · فشل 7 يونيو (source env.sh أولاً لجلب OPENAI_API_KEY).
ليس عُطلاً جديداً — فخّ بيئة كامن منذ 1 يونيو، ظهر اليوم لاختلاف ترتيب الاستدعاء.

الحل (الأقوى — self-heal، صفر مخاطرة):

shebang → #!/usr/bin/python3 (طبقة 1).
منطق re-exec ذاتي: لو الـ interpreter الحالي بلا websockets → os.execv("/usr/bin/python3", ...) تلقائياً (طبقة 2، يعمل بأي طريقة استدعاء).
اختُبر حياً: source env.sh (brew متصدّر) + python3 المرن → نجح ✅ (heal_test.ogg).

التأثير على الترسانات: صفر سلبي. لا يلمس env.sh/brew/106 سكربت. لا cron/daemon يستدعيه. التكلفة: صفر. القاعدة العامة الموثّقة تبقى: السكربتات العلمية/الطبية/التحرير تُشغّل عبر pyrun.sh أو /usr/bin/python3 (ليس brew 3.14).

🧭 Capability Router Expansion + Behavioral Rule (2026-06-07 17:50) — M-054

التوسعة المثلى (التوسعة + القاعدة السلوكية):

Router كان يغطي 18 مجالاً → الآن 26 (أُضيف 8: geospatial·science·graphical·audio·ocr·media·economic·entertainment).
كل مجال جديد يوجّه لمصدره الصحيح (DOMAIN_MODEL_RANKINGS للاقتصادي؛ MATRIX/skill للباقي).
القاعدة السلوكية في GOLDEN_RULES_CORE step 3: "قبل أي مهمة متخصصة، استشر الـ Router أولاً" — يحوّلها من أداة تُنسى لعادة تلقائية. (الاستشارة إلزامية؛ النتيجة تبقى بحكمي المرن).
الحارس §49 (M-054) في verify_agreements: يفحص 8 مجالات موسّعة + المجالات الأصلية + القاعدة مربوطة. يمنع drift.

التحقق: syntax سليم · 18 قديم + 8 جديد يعملون · مجال خاطئ يُرفض · verify EXIT=0. التأثير: صفر على الترسانات/الاستقرار/التكلفة (bash استشاري، لا cron، لا LLM). تماسك أعلى للترسانة. نسخ احتياطية محفوظة (capability_router.sh.bak + GOLDEN_RULES_CORE.md.bak).

🧹 Stale Cleanup + Arsenal Drift Guard + MCP Review (2026-06-07 17:58)

1) Stale entry cleanup (M-? — config hygiene)

skill-workshop كان في plugins.allow + entries لكنه صار core في OpenClaw 2026.6.1 (9 ملفات dist) → طبع تحذير "stale" كل restart.
أُزيل من allow (32→31) + entries (30→29). اختُبر حياً: أداة skill_workshop ما زالت تعمل (core، list ردّت سليم). التحذير اختفى. JSON صالح. القنوات سليمة.

2) Arsenal Drift Guard (M-055)

scripts/arsenal_drift_check.sh جديد: يفحص وجود 9 routers + 6 MATRIX + syntax الـ Python routers. EXIT 0/2.
صفر تأثير على الدقة (existence/syntax فقط، لا يعدّل محتوى) · صفر تكلفة (test -e + py_compile) · استقرار أعلى (يكشف تلف مبكراً).
مربوط في verify_agreements §50 (M-055). اختُبر: EXIT=0.

3) MCP Servers review (8، ليس 6)

6 صحيّة قيّمة: google-drive(8) · github(26) · playwright(23) · testsprite(8) · filesystem(14) · context7(2).
2 خاملة: linear (auth ناقص) · streamlinear-linear (offline + مكرّر، معرّف في ~/.codex/config.toml:30).
مهم: كل MCP تخص Codex/Claude CLI، ليست محمّلة في OpenClaw gateway (mcp غير موجود في openclaw.json) → لا تؤثر على نظامنا الأساسي ولا موارده.
لم ألمس الـ MCP الخاملة (تخص Codex config) — تنتظر قرار د. وائل (قد يريد Linear لاحقاً).

نسخ احتياطية: openclaw.json.bak.stale- · كل verify EXIT=0.
🔧 Linear MCP Fix + skill_workshop توضيح (2026-06-07 18:08)
Linear — أُصلح فعلياً (لا حذف، عاد للعمل) ✅
السبب الجذري: ~/.codex/config.toml سطر streamlinear-linear كان فيه LINEAR_API_TOKEN = placeholder وهمي (مُقنّع) بدل الحقيقي. الـ token الحقيقي في env.sh (lin_api_...، 48 حرف) صالح 100% (Linear API ردّ: WAEL ALKISHAWI / wayrk76@gmail.com). الإصلاح: استبدلت الـ placeholder بالـ token الحقيقي (string replace نظيف، TOML صالح). نسخة احتياطية: config.toml.bak. النتيجة: streamlinear-linear صار online (1 tool كامل) → mcporter الآن 7 healthy (كان 6). الأداة: linear(search/get/update/comment/create/graphql) متصلة بفريق WAE. ملاحظة: نسخة linear الأخرى ما زالت auth-required (Linear غيّرت endpoint /sse→/mcp). لم أحذفها (طلب د. وائل: لا إلغاء) — streamlinear يغطّي Linear بالكامل الآن.

skill_workshop — لم تُعطب ولم نخسر شيئاً (توضيح) ✅

التصحيح المهم: كلمة "stale" كانت عن سطر تعريف قديم في config، لا عن الأداة. الأداة skill_workshop مدمجة في core OpenClaw (9 ملفات dist)، بياناتها كاملة (proposals + reviews حتى اليوم 10:14)، وتعمل 100% (list ردّت سليم). إزالة السطر القديم = نظافة فقط، صفر خسارة. لا شيء كان "مربوطاً" بالسطر سوى تحذير مزعج.