M-038 — Dead model alias in cron jobs (google/gemini-3.5-flash) — 2026-06-01 06:0X
- Symptom: Cron "Weekly API Health & Quota Audit" (f1d1e89e) reported failed at 06:00 Kuwait. د. وائل flagged via screenshot.
- Root cause: job payload.model =
google/gemini-3.5-flash— alias REMOVED from current OpenClaw build (only gemini-3-flash / 3.1-flash exist). Runtime threwFailoverError: Unknown model: google/gemini-3.5-flash. Fallback chain rescued the model call (→ gpt-5.5-pro) but the cron still recorded error. - 3-layer verify: (1) log = FailoverError model_not_found; (2) build grep = no gemini-3.5-flash in dist/.js; (3) script itself runs clean (exit 0).
- Fix: updated job model →
google/gemini-3-flash-preview(valid). Manual re-run cleared error backoff (lastError=None). Scanned all 33 crons → 0 remaining dead-alias references. - Lesson: weekly_full_audit / arsenal audit should also scan cron payload.model fields against live valid-alias list after any OpenClaw update. MEMORY golden chain references "Gemini 3.5 Flash" but the build alias is gemini-3-flash-preview (3.5 alias is gone in this build).
🛡️ Full Server Recovery Point (2026-06-01 06:17 GMT+2)
- طلب د. وائل (صوتي): snapshot/recovery point كامل للسيرفر بكل محتوياته + إيميل بطريقة التخزين والاسترجاع.
- Built:
scripts/full_server_snapshot.sh— يضغط /data/.openclaw + /hostinger، يستثني node_modules/.venv/caches، يرفع R2، sha256، manifest. - Archive: openclaw-full-20260601-061739-recovery-point.tar.gz (3.6GB) — SHA256: 9b7aec39...756edb ✅ verified
- Locations: local (memory/snapshots/full-server/) + R2 (kiloclaw/restore-points/) — نسختان
- Guide: RESTORE_GUIDE.md (محلي + R2) — أوامر استرجاع كاملة لسيرفر جديد
- Email: أُرسل لـ wayrk76@gmail.com (msg 19e816ea83e94570) + مرفقات (guide + manifest)
- Fix: r2_manager upload يأخذ prefix (مجلد) لا key كامل — أصلحت السكربت + نظّفت المسارات المكررة.
- Pending: اقتراح cron أسبوعي للـ full snapshot (بانتظار موافقة د. وائل).
🔁 Weekly Snapshot Cron — Sunday 05:00 Kuwait (2026-06-01)
- طلب د. وائل: نقطة استرجاع أسبوعية + إيميل، الأحد صباحاً نفس وقت الـ audit (05:00).
- فحصت الكرونات: اكتشفت كرون snapshot قديم (b37d2662) مجدول السبت 10:00، يستدعي weekly_snapshot_and_email.sh.
- مشكلة وُجدت: السكربت القديم incompatible مع full_server_snapshot الجديد (يمرر $TAG بدل --upload --label، يقرأ .zst/RESTORE.md غير موجودة).
- 🐛 عيب خطير اكتُشف بالاختبار الحي: full_server_snapshot كان يبتلع الأرشيفات السابقة → tar runaway (وصل 7.6GB ويتضخم). أوقفته فوراً + نظّفت.
- الإصلاح: أضفت
--exclude '/memory/snapshots/.../.tar.gz'+ prune تلقائي (KEEP_LOCAL=1، التاريخ على R2). - أعدت كتابة weekly_snapshot_and_email.sh ليتوافق (.tar.gz + manifest + RESTORE_GUIDE + 3 emails + R2 creds في HTML).
- نقلت الكرون b37d2662 → الأحد 05:00 الكويت (0 5 0) — nextRun: 2026-06-07 05:00.
- ✅ اختبار حي كامل نجح: archive 3.4GB (لا تضخّم) · SHA256 OK · رُفع R2 · 3 إيميلات أُرسلت (gmail 19e818326e0ba763 · hotmail 19e81832dedaeb01 · kcpc 19e818331273f002).
- محلي: أرشيف واحد فقط · R2: نسختان (recovery-point + weekly).
💰 Cost-Optimization Wave (2026-06-01) — EXECUTED & VERIFIED
السبب الجذري المؤكد: cacheWrite (54-60% من فاتورة Anthropic ~$700-900/يوم) بسبب crons حارسة تضرب main session آلاف المرات/يوم + تكرار ثلاثي للحماية + dbus leak.
المنفّذ (6 موجات، كل واحدة مفحوصة):
- W0: Snapshot + R2 backup (
restore-points/2026-06-01-0858-pre-cost-optim-wave.tar.gz, SHA 02fa8dbd) - W1:
watchdog_unified.shيدمج v1+v2+l3_loop (singleton صارم، validate-first, adaptive interval 45s/150s, لا يطلق openclaw — يترك server.mjs المُشرف). عطّلت L3 LLM cron (73a10569) + Watchdog Supervisor cron (896bf167). keepalive يحرس الموحّدة (bash, 5min). - W2: dbus orphan reaper في
stale_lock_cleanup.sh— نظّف 44 يتيمة (96MB→3MB). - W3:
cron_session_cleanup.py— حذف 1344 cron trajectory (255MB، 1.1GB→831MB). main/telegram محمية 100%. مدمج في keepalive (hourly). - W4: process-leak monitor في
resource_pressure_check.sh(dbus≥20, watchdog dup≥3, procs≥600). - ملاحظة: ضغط MEMORY.md أُجّل — أسطر Nexos = توثيق قرار M-027 حيّ (ليست ميّتة) → خط أحمر، لا تُحذف.
النتائج المؤحققة:
- procs: ~500 → 42 | RAM free: 424MB → 11Gi | sessions: 1.1GB → 831MB
- verify_agreements: exit=0, 113 PASS, 0 FAIL
- شبكة الأمان: SIGKILL test → keepalive أعاد الموحّدة (3s)
- 3 أسباب انهيار أُزيلت: race v1/v2، l3 مكرر، dbus leak
- التوفير المتوقع: ~60% LLM (تعطيل L3 720×/يوم + Supervisor 144×/يوم على main session)
الملفات الجديدة/المعدّلة:
- جديد: scripts/watchdog_unified.sh, scripts/maintenance/cron_session_cleanup.py
- معدّل: daemons_keepalive.sh (+unified guard +cron cleanup), stale_lock_cleanup.sh (+dbus reaper), resource_pressure_check.sh (+leak monitor), verify_agreements.sh §29 (v1→unified)
- معطّل (لا محذوف): crons 73a10569, 896bf167 + scripts v1/v2/l3_loop (backup)
🔧 Post-Wave Final Check (2026-06-01) — اكتشاف + إصلاح إضافي
اكتشاف خارج الصندوق أثناء الفحص الشامل: inotify_nexos_guard + inotify_wrapper_guard كانا بلا singleton صارم (نفس عائلة race الـ watchdog) → نسخ مكررة محتملة عند flap.
الإصلاح: أضفت strict singleton guard + trap cleanup للاثنين (نفس نمط watchdog_unified). مُختبر:
- محاولة إطلاق نسخة ثانية → رُفضت ("already running PID X — exit") ✅
- keepalive لا يكرر ✅
- nexos protection فعّالة (صفر nexos في auth) ✅
ثغرات الـ duplicate-daemon race أُغلقت في كامل المنظومة (watchdog + كلا الـ inotify guards).
🔧 Cost-Optim Wave 2 (2026-06-01) — توحيد بقية الـ crons (فكرة #4)
النقد العميق للأفكار الخمس:
- #4 (توحيد crons) → ✅ نُفّذ: L4/L6/Ollama كانت systemEvent على main تستهلك LLM turn فقط لتشغيل bash. L6 يستخدم Gemini Flash مباشرة (لا main LLM).
- #1 (Capability Router) → 🔶 كـ checklist استشاري لا محرّك إجباري (لئلا يتعارض مع الحكم المرن للسؤال).
- #2 (Fallback Health) → ✅ test_fallback_chain موجود؛ أصلحت ترتيبه ليطابق M-037 (كان قديماً).
- #3 (Self-Audit) → ⚠️ رُفض بشكله (LLM call/رد = نزيف)؛ أُعيد تصميمه كـ bash دوري أسبوعي.
- #5 (Cache Warmer) → 🔶 مؤجل (يحتاج قياس فعلي).
- L4 Integrity + L6 Canary نُقلا لـ daemons_keepalive.sh (bash, hourly marker). Ollama Guard معطّل (مغطّى أصلاً بـ P2.3).
- عطّلت 3 crons: L4 (b2c85782), L6 (8e95246e), Ollama (fded8392). إجمالي معطّل = 5 crons.
- inotify_nexos_guard + inotify_wrapper_guard: أضيف strict singleton + trap (أُغلقت ثغرة duplicate-daemon race).
- L4 baseline أُعيد بناؤه (عكس تعطيل الـ crons الشرعي).
- test_fallback_chain.sh: حُدّث ترتيب top-3 لـ M-037 chain (إصلاح الفحص، لا السلسلة).
fallback chain سليمة 100% — لم تُمَس (خط أحمر).
🚀 Cost-Optim Wave 3 — أفكار التطوير (2026-06-01)
سؤال Ollama (مؤكد): ثانوي بحت — صفر في config/fallback. كل الإجابات من السلسلة الذهبية. Ollama للبيانات الحساسة فقط بطلب صريح.
نُفّذ:
- #1 Capability Router (scripts/capability_router.sh) — lookup استشاري فوري للأفضل+بدائل من DOMAIN_MODEL_RANKINGS، صفر LLM، لا يقيّد الحكم المرن.
- #2 Accuracy Gate — كان موجوداً كاملاً في GOLDEN_RULES_CORE (منهجية 10 خطوات + Genius 8). ربطته بالـ router (لا تكرار — M-025).
- #3 Fallback Health (scripts/maintenance/fallback_health_check.sh) — probe خفيف (1-token) لمفاتيح Anthropic/OpenAI/Google/xAI كل 6h، alert فقط عند degradation. مربوط keepalive P3.3.
- #4 عطّلت Watchdog Daemons Supervisor (ab11df59) — كان systemEvent على main 288×/يوم لحراسة L1 pinger. نقلت L1 pinger لـ keepalive P3.4 (bash). إجمالي 6 crons معطّلة.
keepalive الآن يحرس كل شي bash: unified watchdog + nexos guard + wrapper guard + L1 pinger + L4 + L6 + ollama + stale-lock/dbus-reaper + cron-session-cleanup + fallback-health + resource-monitor. صفر LLM للحراسة.
6 crons معطّلة إجمالاً: L3 Auto-Rollback, Watchdog Supervisor, L4 Integrity, L6 Canary, Ollama Guard, Watchdog Daemons Supervisor.
⚠️ السلبيات المكتشفة + إصلاحها (2026-06-01 — صدق تام)
سؤال د. وائل: "ما السلبيات التي أصبحت ولم تكن قبل التطبيق؟"
سلبية #1 (أُصلحت): نقل L4/L6 من LLM cron → bash فقد قدرة تنبيه Telegram (كانت تعتمد على الـ cron announce). الإصلاح: أضفت إرسال Telegram مباشر (bash curl) داخل L4 + L6 عند detect breach/drift. التنبيه مُستعاد + التوفير محفوظ.
سلبية #2 (عولجت بدفاع متعدد الطبقات): keepalive cron صار SPoF لكل الحُرّاس bash. حاولت نقل keepalive داخل watchdog لكن ذلك خلق دائرة إحياء (دجاجة/بيضة). القرار الصادق: أبقيت keepalive cron (isolated، LLM رخيص جداً) كضامن مستقل + أضفت في watchdog شبكة أمان ثانوية تعمل لو سكت keepalive >15min. defense-in-depth بلا SPoF. (الاستقرار > التوفير الضئيل — قاعدة د. وائل).
سلبية #3 (مقبولة): L4/L6 توقيتهما الآن ضمن 5min tick بدل cron دقيق (انحراف ≤5min) — أثر عملي صفر.
سلبية #4 (معلومة): D∞ keepalive cron نفسه ما زال isolated agentTurn (~288 turn رخيص/يوم) — لم نُزِله لأنه الضامن المستقل لكسر دائرة الإحياء. توفيره الضئيل لا يستحق SPoF.
الحالة النهائية: watchdog/nexos/wrapper/L1 = 1 each PPID=1 | gateway ALIVE | procs 43 | dbus 0 | verify 113/0.
⚠️ سلبيات خفية إضافية اكتُشفت + أُصلحت (2026-06-01 wave3)
د. وائل: "سلبيات أخرى لم تنتبه لها؟" — فحص نقدي أعمق:
خفية #5 (أُصلحت): R2 backup cron (acc17a3f) = systemEvent على main كل ساعتين (12 LLM turn/يوم لمهمة bash). والأخطر: state أظهر آخر backup ناجح قبل يومين (متعثّر!). الإصلاح: نقلته لـ keepalive P2.6 (bash موثوق) + شغّلت backup فوري نجح (4.3GB) + state محدّث. عطّلت الـ cron. إجمالي 7 crons معطّلة.
خفية #6 (أُصلحت): L1 pinger بلا singleton → قابل للتكرار عند flap. أضفت singleton داخل L1_pinger_daemon.py.
خفية #7 (معلومة، مقبولة): markers في /tmp تُمسح عند container restart → الفحوصات (L4/L6/fallback/R2) تعمل فوراً بعد restart بدل انتظار الـ interval. أثر إيجابي فعلياً (فحص مبكر).
الحالة النهائية: 7 crons LLM معطّلة | كل حارس نسخة واحدة + singleton | R2 backup يعمل (كان متعثّر يومين) | verify 113/0.
🔍 نظرة 360° نهائية (2026-06-01) — ثغرات ترابط اكتُشفت + أُصلحت
د. وائل: نظرة شاملة قبل /new. الفحص النقدي كشف 3 ثغرات ترابط (لا تمسّ الدقة، لكن تهدد استمرارية المعرفة):
ثغرة ترابط #1 (أُصلحت): الأدوات الجديدة (capability_router/fallback_health/watchdog_unified/cron_session_cleanup) غير موثّقة → الجلسة القادمة لن تعرفها. الإصلاح: قسم كامل في MEMORY.md (يُقرأ كل جلسة).
ثغرة ترابط #2 (أُصلحت): عمل اليوم غير مسجّل بمكان يحرسه verify → قد تُعاد crons بالخطأ. الإصلاح: توثيق الـ 7 crons المعطّلة + سبب كل واحد في MEMORY.md.
ثغرة ترابط #3 (ملاحظة): verify_agreements لا يحرس "الـ 7 crons يجب أن تبقى معطّلة" — توصية: إضافة §32 لاحقاً (لم يُنفّذ الآن لتجنّب تعقيد إضافي قبل /new).
استغلال الترسانة: 78 skill + 50 script + capability_router يغطي 17 مجال. الهاردوير (4 cores, 11GB حر, load 0.3) غير مستغل = فرصة (Ollama/batch محلي).
✅ التشيك النهائي المطلق قبل /new (2026-06-01 13:24)
نقد نهائي كشف سلبيتين صغيرتين أُصلحتا:
- cron_session_cleanup.py لم يكن executable → chmod +x (كان يعمل عبر python3 لكن للنظافة).
- keepalive بلا flock → إضافة flock يمنع تشغيلين متزامنين (cron + يدوي) من إطلاق daemon مرتين. مُختبر: تشغيلان متزامنان → واحد skip، watchdog بقي 1. آخر edge-case للـ duplicate أُغلق.
- gateway ALIVE | openclaw PPID=10 (server.mjs supervisor) | watchdog/nexos/wrapper/L1 = 1 each PPID=1
- procs ~43 | dbus 0 يتيم | RAM 26% | free 11GB | zombies 0 | load 0.08
- chain: Opus 4.8 primary + 20 fallbacks | R2 backup 2026-06-01 يعمل
- verify_agreements: 113 PASS / 0 FAIL
- 7 crons LLM معطّلة + موثّقة في MEMORY.md (لن تُنسى/تُعكس)
🔬 نقد نهائي — حصر نقاط الضعف الفعلية (2026-06-01 13:25)
فحص حي حصر نقاط الضعف الحقيقية المتبقية:
- ض1 L5 backup verify: كان error، الآن ✅ يعمل (مع R2 backups الجديدة).
- ض2 opus watchers (2 cron): كانا يفشلان عبثاً (opus-4-8 مفعّل+مدعوم أصلاً، مهمتهما انتهت). عُطّلا. إجمالي 9 crons معطّلة.
- ض5 WhatsApp reconnect loop: غير مرتبط (plugin install مؤجل) → 4 أخطاء/يوم عبثية. قرار د. وائل (مرتبط بمهمة install المؤجلة).
- opus-4-8 يعمل فعلاً كـ primary (مؤكد من runtime identity + dist).
✅ M-038 — Codex Harness Deadlock Fix (2026-06-01 14:20 GMT+2)
د. وائل رصد الشلل من screenshot: Opus 4.8 timeout → fallback لـ openai-codex/gpt-5.5-pro (harness) بدل المباشر → (agent) failed.
الجذر (4 طبقات): openai-codex:default auth profile (=TASK-001) + discovery يحقن openai-codex/ + appServer auto-spawn + 290 binding leak.
الحل المنفّذ: discovery=false + إزالة auth profile (profiles+state) + codeModeOnly=true + تنظيف 290 binding. Backup: memory/snapshots/codex-fix-20260601-135648/.
التحقق ثلاثي: config ✅ runtime(hot reload) ✅ live(gpt-5.5 GPT55_DIRECT_OK + codex app-servers=0) ✅.
الحراسة: keepalive P2.7 + verify_agreements §40 (negative+positive tested).
bug إضافي أُصلح: verify_agreements كان exit 0 مبكر (843) + exit 1 يتيم (1188) → §25-40 (+M-037) لا تُفحص عند النجاح! أُصلح بـ aggregate exit نهائي.
النتيجة: Codex للأكواد فقط (/codex). الشاتينج openai مباشر. صفر شلل ممكن.
✅ dbus-daemon orphan leak fix (2026-06-01 14:31 GMT+2)
د. وائل رصد تنبيه: DBUS_LEAK 20+ orphan procs (وصلت 22).
الجذر: reaper P2.4 (stale_lock_cleanup.sh) موجود ويُستدعى، لكن set -Eeuo pipefail كان يقتل السكريبت قبل كتلة dbus — السبب: cat|grep -oE [0-9]+|head على lock بلا أرقام (keepalive.lock) → grep يُرجع 1 → pipefail+set -e → exit. آخر نجاح 13:15، ثم توقف.
الإصلاح: أضفت || true على الـ pid pipe + كل أوامر reaper (pgrep/ps/grep) لتحصينها ضد set -e.
التحقق: بعد الإصلاح، reaper قتل 21 orphan → 0 متبقية. exit=0. DBUS-REAP logged. keepalive (كل 5min) سيمنع التراكم.
ملاحظة: الـ leak rate ~1/3-4min يطابق نشاط codex harness/exec — مع codeModeOnly=true (M-038) قد يقل المصدر نفسه. مراقبة.
🔍 360° Critique Post-M-038 (2026-06-01 14:35 GMT+2)
د. وائل طلب نقد شامل + حصر ثغرات + تطوير بعد إصلاح Codex.
ثغرات اكتُشفت + عولجت: 1. L5 R2 Backup Verify cron يفشل (consecutiveErrors:1) — كان يبحث في snapshots/ prefix (آخر ملف 26 مايو) بدل backups/. أُصلح ليبحث في backups/ + يختار الأحدث بالـ sort. الآن exit=0 ثابت. 2. dbus reaper معطّل بـ set -e (سبق إصلاحه) — أُكّد. 3. zombie=1 عابر — من exec child، يُحصد تلقائياً (غير مقلق).
ثغرة عميقة مُسجّلة للإصلاح اللاحق (غير حرجة):
- r2_manager
list backups/لا يعرضworkspace_backup_*المباشرة (4.3GB daily) — يعرض فقط backups/snapshots/. الـ daily backup يعمل (مؤكد في full list) لكن L5 يتحقق من snapshot أقدم صالح بدل الـ daily الضخم. الإصلاح يحتاج تعديل r2_manager list delimiter. TASK جديد: PENDING.
✅ Priority #1 + #2 Done (2026-06-01 15:11 GMT+2)
#1 — r2_manager + L5 backup verify (3 جذور أُصلحت):
- L5 كان يبحث في snapshots/ (ملف 26 مايو) بدل backups/ → أُصلح للـ prefix الكامل kiloclaw/backups/.
- r2_manager cmd_download كان يفشل 404 على daily backup (مفاتيح R2 مختلطة: بعضها kiloclaw/ بعضها بدون) → أضفت _resolve_existing_key يجرّب الاثنين.
- أضفت cmd_head (تحقق خفيف بلا تنزيل). L5 الآن: HEAD يومياً (ثوانٍ) + download+tar أسبوعياً (الأحد/--full).
- تحقق: daily 4.5GB download+tar = valid (1532+ files). regression: old keys تعمل. L5 exit=0.
- fallback_health_check.sh يفحص Anthropic/OpenAI/Google/xAI بـ 1-token كل 6h + alert. شغّلته: OK (4/4 HTTP 200).
2026-06-01 16:30 — Top-of-Top Upgrade Session (محاور د. وائل)
المنجز (كله مفحوص حيّاً + verify exit=0):
1. Suno تأكيد: SUNO_API_KEY=NO. Suno شركة مستقلة (ليست MiniMax) = SOTA حقيقي للأغاني. MiniMax music-2.6 + Lyria 3 Pro + fal configured=yes (بدائل أضعف). → Suno فعلاً ناقص، يحتاج مفتاح من د. وائل. 2. TestSprite: لم تكن ثغرة — "Unsupported" في عمود Auth طبيعي لكل MCP يستخدم API_KEY. handshake نجح live. LRN-20260601-001. 3. Graph Memory (Zep): بُني skill جديدskills/graph-memory/ (SKILL.md + zep_memory.py). ADDITIVE فوق vector memory، on-demand فقط، صفر hot-path. Zep healthz=200، user.add/graph.add/search نجحت، entity "Wael" استُخرج. zep-cloud SDK نُصّب.
4. Realtime Voice: GA fix — حذف header OpenAI-Beta: realtime=v1 (مرفوض الآن beta_api_shape_disabled). default → gpt-realtime. اختبار حي: رد عربي "أهلاً!". LRN-20260601-002.
5. xAI Realtime: غير موجود إطلاقاً — xAI models = grok-4.x نص + grok-imagine صور/فيديو فقط. لا realtime audio. PRIMARY=OpenAI GA، fallback=Gemini Live. LRN-20260601-003.
6. WSA: لا جديد. آخر release Jan 2026. issue#593 آخر تعليق جوهري Aug 2025. MustardChef: "next build auto-workaround installer". نبقى على backup الحالي.
7. بنود 5.28 الثانوية: كلها auto-active (encrypted PDF, MiniMax streaming music, Fal Krea, NVIDIA catalog, perf, security hardening). لا config مطلوب.الناقص الوحيد (يحتاج د. وائل):
- SUNO_API_KEY — الوحيد بلا بديل مكافئ (للأغاني الكاملة الاحترافية).
2026-06-01 16:50 — Suno ACTIVATED ✅
- SUNO_API_KEY received from Dr. Wael + saved to env.sh (sunoapi.org, base https://api.sunoapi.org). 1050 credits (now ~1038).
- Built skills/suno-music/ (SKILL.md + suno.py). Verified live: full song generate+poll+download works (instrumental arabic oud test, 256kbps stereo, 4.9MB).
- Fixes needed: UA header (Cloudflare 1010) + curl for CDN download (403 on urllib). LRN-20260601-004.
- NOW: the last missing arsenal piece is filled. Suno = SOTA vocal songs; MiniMax/Lyria = instrumental/cheap fallback.
💰 Cost-Optim Group-1 منفّذة (2026-06-02 00:40 GMT+2)
التشخيص المُثبت: صرف Anthropic = $678/يوم. 68% cacheWrite ($461) + 28% cacheRead. output مفيد 4% فقط. 85.7% من جلسات main التفاعلية. السبب: 24 جلسة منتفخة (199MB) + cacheWrite ~66K token/رسالة.
المنفّذ (verify_agreements exit 0 بعد كله):
- ب1:
truncateAfterCompaction:true+maxActiveTranscriptBytes:"4mb"→ يوقف نمو cacheWrite (يؤرشف الأصل، يحفظ recentTurns=8 + keepRecent=40K، صفر فقد دقة). ~$150-200/يوم. - ب2:
heartbeat.modelopus-4-8 → haiku-4-5 (heartbeat=bash checks، haiku كافٍ، أثبته L5). ~$20-40/يوم. - ج1: drift detector §41 في verify_agreements (يكشف hardcoded model-string vs primary الحي — يمنع M-042/M-043).
- ج2: spend_monitor مطوّر (by_model + unknown_models + spike thresholds 50/900).
- ج3: ground-truth principle موثّق في M-042.
التوفير المتوقع الآمن: ~$170-240/يوم (دون لمس الدقة/السلسلة/الذاكرة المرجعية).
معلّق لموافقة د. وائل: ب3 (تقليص MEMORY.md) + ب4 (عادة /new). WhatsApp (bot منفصل، لا self-send) مؤجّل بطلبه.
backup: openclaw.json.bak-group1-20260602_003311
✅ ت1 + ت3 منفّذة (2026-06-02 00:52 GMT+2)
- ت1: cron_session_cleanup --max-age-days 3 → حذف cron trajectories فقط (يحمي main/telegram). الجلسات القديمة 203MB معظمها main/subagent منتهية — تركتها (السلامة > المساحة، لم أخمّن حذف main).
- ت3: Anthropic Spend Monitor cron محدّث (haiku-4-5 + gemini fallback + thresholds 50/900 + by_model + unknown detection). test run: $551.64 (2026-05-31) by_model breakdown، delivered. أثبت إصلاح M-042: المونيتور القديم قال $174 لنفس اليوم (أخفى $377).
- كل الفحوصات بعد التنفيذ: verify_agreements exit 0، السلسلة 20 موديل LIVE PASSED، RAM 12GB حر، load 0.18، كل الحماية حية.