Documentation Index
Fetch the complete documentation index at: https://docs.openclaw.ai/llms.txt
Use this file to discover all available pages before exploring further.
خطة تحديث التطبيق
الهدف
دفع التطبيق نحو منتج أنظف وأسرع وأسهل صيانة من دون كسر تدفقات العمل الحالية أو إخفاء المخاطر داخل إعادة هيكلة واسعة. يجب أن ينزل العمل على شكل شرائح صغيرة قابلة للمراجعة مع إثبات لكل سطح تم لمسه.المبادئ
- حافظ على البنية الحالية ما لم يكن هناك حدّ فاصل يسبب بوضوح اضطرابًا، أو تكلفة أداء، أو أخطاء مرئية للمستخدم.
- فضّل أصغر تصحيح صحيح لكل مشكلة، ثم كرر ذلك.
- افصل الإصلاحات المطلوبة عن التحسينات الاختيارية حتى يتمكن المشرفون من إنزال العمل عالي القيمة من دون انتظار قرارات ذاتية.
- أبقِ السلوك المواجه لـ Plugin موثقًا ومتوافقًا مع الإصدارات السابقة.
- تحقّق من السلوك المشحون، وعقود التبعيات، والاختبارات قبل الادعاء بأن الانحدار قد تم إصلاحه.
- حسّن أولًا المسار الرئيسي للمستخدم: الإعداد الأولي، والمصادقة، والدردشة، وإعداد الموفّر، وإدارة Plugin، والتشخيصات.
المرحلة 1: تدقيق خط الأساس
اجرد حالة التطبيق الحالية قبل التغيير.- حدّد أهم تدفقات المستخدم والأسطح البرمجية التي تملكها.
- اسرد العناصر غير المستخدمة، والإعدادات المكررة، وحالات الخطأ غير الواضحة، ومسارات التصيير المكلفة.
- التقط أوامر التحقق الحالية لكل سطح.
- صنّف المشكلات إلى: مطلوبة، أو موصى بها، أو اختيارية.
- وثّق العوائق المعروفة التي تحتاج إلى مراجعة المالك، وخصوصًا تغييرات API والأمان والإصدار وعقد Plugin.
- قائمة مشكلات واحدة مع مراجع ملفات من جذر المستودع.
- تحتوي كل مشكلة على الشدة، والسطح المالك، والأثر المتوقع على المستخدم، ومسار تحقق مقترح.
- لا تُخلط عناصر التنظيف التخيلية ضمن الإصلاحات المطلوبة.
المرحلة 2: تنظيف المنتج وتجربة المستخدم
أعطِ الأولوية للتدفقات المرئية وأزل الالتباس.- شدّد نصوص الإعداد الأولي والحالات الفارغة المتعلقة بمصادقة النموذج، وحالة Gateway، وإعداد Plugin.
- أزل العناصر غير المستخدمة أو عطّلها عندما لا يكون هناك إجراء ممكن.
- أبقِ الإجراءات المهمة مرئية عبر العروض المتجاوبة بدلًا من إخفائها خلف افتراضات تخطيط هشة.
- وحّد لغة الحالة المتكررة بحيث يكون للأخطاء مصدر حقيقة واحد.
- أضف كشفًا تدريجيًا للإعدادات المتقدمة مع إبقاء الإعداد الأساسي سريعًا.
- مسار يدوي سعيد لإعداد أول تشغيل وتشغيل المستخدم الحالي.
- اختبارات مركزة لأي منطق متعلق بالتوجيه، أو حفظ الإعدادات، أو اشتقاق الحالة.
- لقطات شاشة للمتصفح للأسطح المتجاوبة التي تغيرت.
المرحلة 3: تشديد بنية الواجهة الأمامية
حسّن قابلية الصيانة من دون إعادة كتابة واسعة.- انقل تحويلات حالة UI المتكررة إلى مساعدات ضيقة ومكتوبة الأنواع.
- أبقِ مسؤوليات جلب البيانات، والحفظ، والعرض منفصلة.
- فضّل الخطافات والمخازن وأنماط المكونات الموجودة على التجريدات الجديدة.
- قسّم المكونات الضخمة فقط عندما يقلل ذلك الاقتران أو يوضح الاختبارات.
- تجنب إدخال حالة عامة واسعة لتفاعلات اللوحات المحلية.
- لا تغيّر السلوك العام كأثر جانبي لتقسيم الملفات.
- حافظ على سلوك إمكانية الوصول للقوائم، ومربعات الحوار، وعلامات التبويب، والتنقل بلوحة المفاتيح.
- تحقّق من أن حالات التحميل، والفراغ، والخطأ، والحالة المتفائلة ما تزال تُعرض.
المرحلة 4: الأداء والموثوقية
استهدف الألم المقاس بدلًا من التحسين النظري الواسع.- قِس تكاليف بدء التشغيل، وانتقال المسارات، والقوائم الكبيرة، وسجل الدردشة.
- استبدل البيانات المشتقة المكلفة المتكررة بمحددات محفوظة أو مساعدات مخزنة عندما يثبت التحليل الجدوى.
- قلّل عمليات المسح الشبكي أو نظام الملفات التي يمكن تجنبها على المسارات الساخنة.
- حافظ على ترتيب حتمي لمدخلات الموجّه، والسجل، والملفات، وPlugin، والشبكة قبل بناء حمولة النموذج.
- أضف اختبارات انحدار خفيفة للمساعدات الساخنة وحدود العقود.
- يسجل كل تغيير أداء خط الأساس، والأثر المتوقع، والأثر الفعلي، و الفجوة المتبقية.
- لا يهبط أي تصحيح أداء اعتمادًا على الحدس فقط عندما يكون القياس الرخيص متاحًا.
المرحلة 5: تشديد الأنواع والعقود والاختبارات
ارفع مستوى الصحة عند نقاط الحدود التي يعتمد عليها المستخدمون ومؤلفو Plugins.- استبدل سلاسل وقت التشغيل الفضفاضة باتحادات مميزة أو قوائم أكواد مغلقة.
- تحقّق من المدخلات الخارجية باستخدام مساعدات المخططات الموجودة أو zod.
- أضف اختبارات عقود حول بيانات Plugins، وفهارس الموفّرين، ورسائل بروتوكول Gateway، وسلوك ترحيل الإعدادات.
- أبقِ مسارات التوافق داخل doctor أو تدفقات الإصلاح بدلًا من ترحيلات خفية وقت بدء التشغيل.
- تجنّب اقتران الاختبارات فقط بباطن Plugin؛ استخدم واجهات SDK والأشرطة الموثقة.
pnpm check:changed- اختبارات مستهدفة لكل حدّ تم تغييره.
pnpm buildعندما تتغير الحدود الكسولة أو التغليف أو الأسطح المنشورة.
المرحلة 6: الجاهزية للتوثيق والإصدار
أبقِ الوثائق المواجهة للمستخدم متوافقة مع السلوك.- حدّث الوثائق مع تغييرات السلوك أو API أو التهيئة أو الإعداد الأولي أو Plugin.
- أضف إدخالات سجل التغييرات فقط للتغييرات المرئية للمستخدم.
- أبقِ مصطلحات Plugin موجهة للمستخدم؛ واستخدم أسماء الحزم الداخلية فقط عند الحاجة للمساهمين.
- أكّد أن تعليمات الإصدار والتثبيت ما تزال تطابق سطح الأوامر الحالي.
- يتم تحديث الوثائق ذات الصلة في الفرع نفسه مع تغييرات السلوك.
- تنجح فحوصات انحراف الوثائق أو API المولدة عند لمسها.
- يذكر التسليم أي تحقق تم تخطيه وسبب تخطيه.
الشريحة الأولى الموصى بها
ابدأ بتمرير محدود على Control UI والإعداد الأولي:- دقّق أسطح إعداد أول تشغيل، وجهوزية مصادقة الموفّر، وحالة Gateway، و إعداد Plugin.
- أزل الإجراءات غير المستخدمة ووضّح حالات الفشل.
- أضف أو حدّث اختبارات مركزة لاشتقاق الحالة وحفظ الإعدادات.
- شغّل
pnpm check:changed.
تحديث مهارة الواجهة الأمامية
استخدم هذا القسم لتحديثSKILL.md المركّز على الواجهة الأمامية والمرفق مع
مهمة التحديث. إذا كنت ستتبنى هذا الإرشاد كمهارة OpenClaw محلية للمستودع،
فأنشئ .agents/skills/openclaw-frontend/SKILL.md أولًا، واحتفظ بالـ frontmatter
الذي ينتمي إلى تلك المهارة الهدف، ثم أضف أو استبدل إرشادات الجسم بالمحتوى
التالي.