استضافة open-kritt ذاتياً على VPS لفحص أمني آمن

لماذا تستضيف open-kritt ذاتياً على VPS بدلاً من حاسوبك المحمول

استضف open-kritt ذاتياً على خادم يمكنك تدميره وإعادة بنائه. تشغّل الأداة وكلاء التحليل بصلاحيات root داخل حاويات مهام مؤقتة، وتمنح كل وكيل نسخة قابلة للكتابة من التعليمات البرمجية ووصولاً مباشراً إلى الإنترنت، كما تربط Docker socket الخاص بالمضيف بخدمة المحرك. هذا تنازل مقبول على خادم مخصص للمهمة. لكنه خيار سيئ على الجهاز الذي يحتفظ بمفاتيح SSH الخاصة بك.

هناك 4 خصائص في الإعداد الافتراضي تدعم هذه التوصية. وكلها واردة في README وملف compose الخاص بالمشروع.

صُمّم الوكلاء ليتمتعوا بصلاحيات واسعة. يذكر README أن الوكلاء المزوّدين بالأدوات يعملون بصلاحيات root داخل حاويات مهام مؤقتة، مع نسخ مستودعات قابلة للكتابة ووصول مباشر إلى الإنترنت، حتى يتمكنوا من تثبيت الأدوات، وتجميع الأهداف، وتشغيل الاختبارات، وبناء نماذج إثبات المفهوم. الفحص ليس أداة linter تقرأ الملفات. بل هو تنفيذ عشوائي للتعليمات البرمجية طلبته أنت. وهذا الوصول إلى الإنترنت ينطوي على مخاطر في الاتجاهين: فأي شيء يجلبه الوكيل أثناء البحث في هدف ما هو نص غير موثوق يصل إلى prompt الخاص به، وهو نفس نوع التعرض الذي تقبله عندما تمنح الوكيل بحثه الخاص على الويب.

يحتوي المحرك على Docker socket. يربط docker-compose.yml Docker socket الخاص بالمضيف بخدمة المحرك، لأن المحرك ينشئ حاوية فحص واحدة ويشغّلها لكل مهمة. يمكن لأي عملية تصل إلى ذلك socket بدء تشغيل حاوية تربط نظام ملفات المضيف. لذلك يمتلك المحرك عملياً صلاحيات root على أي مضيف يعمل عليه.

لا توجد شاشة تسجيل دخول. يأتي backend من دون مصادقة على مستوى التطبيق. الوصول إلى المنفذ يعني الوصول إلى نتائجك وإلى رصيد مزود الخدمة الخاص بك.

التعليمات البرمجية التي تفحصها ليست ملكك غالباً. توجيه الوكلاء إلى مستودع تابع لطرف ثالث يعني تشغيل عملية build الخاصة بذلك المستودع على جهازك، بصلاحيات root ومع وصول إلى الشبكة.

إذا قرأت لماذا يجب أن تعمل وكلاء البرمجة داخل VM مؤقتة، فهذا هو نموذج التهديد نفسه، لكنه أقوى. امنح open-kritt خادماً VPS لا يشغّل أي شيء آخر، وشغّل ذلك VPS من حساب مستخدم منفصل بأقل صلاحيات ممكنة بدلاً من root.

ما الذي يفعله open-kritt فعلياً

يقسّم open-kritt (المستودع هو Kritt-ai/open-kritt، ومرخّص بموجب AGPL-3.0) أبحاث الثغرات إلى مهام صغيرة، ثم يشغّل هذه المهام بالتوازي عبر وكلاء الذكاء الاصطناعي، ويزيل التكرارات ويرتّب النتائج الواردة. تعرّف سير العمل كسلسلة من المطالبات المركّزة، وتتلقى كل خطوة سياقاً منظماً من الخطوات السابقة لها. يمكن أن يكون هدف الفحص مستودع git بعيداً أو محلياً. ومحرك التحليل هو Codex أو Claude Code. بعد ظهور نتيجة محتملة، يمكن للبرامج اللاحقة الاختيارية محاولة التحقق منها أو إنشاء إثبات مفهوم لها. إن تصميم هذه السلسلة هو عمل عادي يتعلق بالوكلاء، وليس عملاً أمنياً. لذلك، إذا كانت المطالبات والأدوات وتمرير السياق لا تزال غير مألوفة لك، فستفيدك معرفة كيفية تركيب الوكلاء في نتائجك أكثر من أي إعداد في هذا الدليل.

في النهاية، تحصل على قائمة مرتبة بالنتائج المحتملة. تعامل معها كقائمة انتظار للفرز، لا كتقرير.

ما تحتاج إليه قبل البدء

• VPS يعمل بنظام Ubuntu 24.04 أو Debian 12 أو Rocky Linux 9. تسرد وثائق التثبيت هذه التوزيعات باعتبارها التوزيعات التي خضعت للاختبار، على x86_64 وARM64.
• Docker Engine مع إضافة Compose.
• Node.js 20 أو إصدار أحدث على المضيف، لأن واجهة سطر الأوامر ./kritt تعمل على المضيف بدلاً من العمل داخل حاوية.
• موفّر نموذج واحد: تسجيل دخول إلى Codex، أو OPENAI_API_KEY أو CODEX_API_KEY أو ANTHROPIC_API_KEY أو OPENROUTER_API_KEY.
• GITHUB_TOKEN فقط إذا كنت تخطط لفحص المستودعات الخاصة. يوضح .env.example الذي يأتي مع البرنامج ذلك صراحةً: لا يمكن تشغيل عمليات الفحص باستخدام رمز GitHub وحده.

ثبّت Docker وNode 20 أولاً

curl -fsSL https://get.docker.com | sudo sh
sudo usermod -aG docker $USER

سجّل الخروج ثم سجّل الدخول مجدداً لتطبيق عضوية المجموعة الجديدة، ثم تأكد من توفر إضافة Compose.

docker compose version

تعني سلسلة الإصدار أن Compose مثبّت كإضافة. تعني docker: 'compose' is not a docker command أن لديك الملف التنفيذي المستقل القديم docker-compose بدلاً من ذلك، ويستدعي open-kritt الأمر docker compose. تعادل عضوية مجموعة docker صلاحيات root على المضيف، لذلك أضف إليها الحساب الذي يشغّل open-kritt فقط. للاطلاع على شرح أطول لهذا الإعداد، راجع تشغيل Docker على VPS.

يوفّر Ubuntu 24.04 الإصدار Node 18 في مستودعه الخاص، وتخرج واجهة CLI عند استخدام أي إصدار أقدم من 20. استخدم NodeSource.

curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash -
sudo apt install -y nodejs
node -v

يجب أن يطبع node -v القيمة v20. أو إصداراً أحدث. في Rocky Linux 9، يكون البديل هو sudo dnf module enable nodejs:20 -y متبوعاً بـ sudo dnf install -y nodejs.

استنسخ open-kritt وثبّت إصداراً موسوماً

git clone https://github.com/Kritt-ai/open-kritt
cd open-kritt
git fetch --tags
git tag --list
git checkout v1.3.0

يتغير main مع مرور الوقت، أما الوسم فلا يتغير. اعتباراً من August 2026، أحدث وسم هو v1.3.0، وقد نُشر في 4 August 2026، بينما يوضح git tag --list ما هو موجود في يوم الاستنساخ. يؤدي تسجيل الخروج إلى وسم إلى وضع المستودع في حالة HEAD منفصل، وهذا صحيح هنا: فأنت تتعامل مع هذه النسخة المستنسخة باعتبارها نشرًا مثبتاً، وليست فرعاً تُجري عليه عمليات commit. للترقية لاحقاً، اقرأ ملاحظات الإصدار، ثم شغّل git fetch --tags، وسجّل الخروج إلى الوسم الجديد، ثم شغّل ./kritt start مرة أخرى، لأن start يعيد بناء الصور.

لا تشغّل ./kritt مع sudo. توضح الوثائق ذلك صراحةً. يدير CLI أدلة بيانات الاعتماد الخاصة بالمشروع ضمن .data/، لذلك يؤدي تشغيله بحساب root إلى جعل ملكية هذه الأدلة لـ root، ولا يستطيع التشغيل العادي التالي الكتابة فيها.

ضبط الوصول إلى النماذج باستخدام ./kritt setup

./kritt setup

ينشئ الأمر .env من .env.example إذا لم يكن موجوداً، ويعرض حالة كل بيانات اعتماد، ويتيح لك ضبطها أو إلغاء ضبطها. ولا يعرض القيم مرة أخرى في الطرفية. يُكتب كل من .env وملف بيانات اعتماد المحرك بالوضع 0600.

إذا كنت تفضّل تنفيذ ذلك يدوياً:

cp .env.example .env
chmod 600 .env
mkdir -p .data/codex
chmod 700 .data/codex

بعد ذلك، حرّر مفتاح الموفر داخل .env واترك الملف بالوضع 0600. في كلتا الحالتين، تصبح بيانات اعتماد موفر صالحة موجودة على ذلك الخادم، وهذا سبب إضافي لعدم وضع أي شيء آخر على الخادم. أنشئ مفتاحاً مخصصاً لهذا المشروع وحده، حتى لا يؤدي إبطاله لاحقاً إلى تعطيل أي شيء يهمك. يتناول إبعاد الأسرار عن متناول وكلاء الذكاء الاصطناعي هذه الممارسة على نطاق أوسع.

ضَع حدّاً للإنفاق لدى مزوّد الخدمة قبل الفحص الأول

صُمّم open-kritt لتوزيع المهام على عدة عمليات، وهذا التوزيع هو ما تدفع مقابله. الإعدادات الافتراضية في .env.example ضمن الإصدار v1.3.0 محافظة: ENGINE_WORKER_COUNT=2، الموصوف في الملف بأنه إعداد افتراضي محافظ لجهاز صغير يضم 2 vCPU، وENGINE_MAX_CONCURRENT_SCANS=1. وفوق هذين الإعدادين يوجد ENGINE_WORKERS_PER_ACCOUNT=15، وهو الحد الأقصى لاستدعاءات النموذج الجذرية المتزامنة المسموح بها على حساب مزوّد واحد، وENGINE_CODEX_MAX_SUBAGENTS_PER_SESSION=5، لأن جلسة Codex قد تشغّل ما يصل إلى خمسة وكلاء فرعيين. إذا رفعت عدد workers على VPS أكبر، فسيرتفع معه عدد استدعاءات النموذج الجارية.

لا يفرض المستودع أي حد أقصى للإنفاق. لا يوجد إعداد للميزانية في .env.example. وتتمثل شروط الإيقاف الخاصة بالمحرّك في حدود workers هذه، بالإضافة إلى ENGINE_HARNESS_TIMEOUT_SECONDS، الذي تكون قيمته الافتراضية 7200 ثانية لكل تشغيل harness. الـharness هنا هو الحلقة التي تواصل استدعاء النموذج باستخدام الأدوات والسياق إلى أن ينهي شيء ما التشغيل، ولذلك فإن مهلة الانتظار هذه تقيس زمن الساعة الفعلي للبرنامج الموجود حول النموذج في البرنامج الذي يغلّف النموذج، ولا تحدّ ما ينفقه النموذج داخله. لذلك يجب أن يكون الحد الأعلى لدى مزوّد الخدمة. افتح لوحة تحكم مزوّد الخدمة واضبط حداً شهرياً صارماً قبل الفحص الأول، وليس بعده. يشرح التحكم في تكلفة وكيل ذكاء اصطناعي على VPS إعدادات كل مزوّد.

يوجد أيضاً إجراء إيقاف محلي. يؤدي ضبط ENGINE_WORKER_COUNT=0 إلى إيقاف التقاط المهام الجديدة مؤقتاً، ويمكن تغيير قيم workers نفسها من شاشة Settings بعد تشغيل المكدس.

لا يذكر هذا الدليل سعراً لكل فحص، لأن التكلفة تعتمد على حجم المستودع، وسير العمل الذي تنشئه، والنموذج المستخدم. شغّل فحصاً واحداً على مستودع صغير واحد، ثم راجع صفحة الاستخدام لدى مزوّد الخدمة قبل توجيهه إلى أي مستودع كبير.

شغّل المكدس وتحقق من سلامته

./kritt start

يتحقق ذلك من .env ومن بيانات اعتماد واحدة على الأقل، ثم يشغّل docker compose up --build. يستغرق البناء الأول وقتاً طويلاً، لأنه يبني صور الواجهة الأمامية والواجهة الخلفية والمحرك وواجهة executor وقاعدة البيانات. ويعمل أيضاً في الواجهة الأمامية، لذلك يؤدي إغلاق جلسة SSH إلى إيقاف المكدس. شغّله داخل tmux، أو شغّله في وضع detached بعد نجاح البناء الأول. لا يستمر أي من الخيارين بعد إعادة التشغيل تلقائياً. لذلك، إذا أردت إعادة تشغيل المكدس بعد إعادة تشغيل الخادم، فإن نمط وحدة systemd الوارد في إبقاء agent مستضاف ذاتياً قيد التشغيل عبر عمليات إعادة التشغيل ينتقل مباشرة إلى هذه الحالة.

docker compose up -d --build
docker compose ps

يجب أن يعرض docker compose ps كلاً من open-kritt-frontend وopen-kritt-backend وopen-kritt-engine وopen-kritt-executor-view وopen-kritt-db. ثم تحقق من أن الواجهة الخلفية تستجيب على الخادم نفسه.

curl -s http://127.0.0.1:3002/api/health

تعني استجابة JSON أن الواجهة الخلفية تعمل. ويعني Failed to connect to 127.0.0.1 port 3002: Connection refused أنها لا تعمل، بينما يوضح docker compose logs backend السبب. أوقف كل شيء باستخدام docker compose down من دليل المستودع.

إضافة اختيارية: يحمّل docker compose exec backend npm run seed بيانات تجريبية. وهذه طريقة منخفضة التكلفة لإلقاء نظرة على الواجهة قبل أن تنفق أي شيء على فحص حقيقي.

الوصول إلى واجهة المستخدم على المنفذ 5173 عبر نفق SSH

ترتبط كل خدمة في ملف compose بالعنوان 127.0.0.1 افتراضياً: الواجهة الأمامية على 5173، والواجهة الخلفية على 3002، وعرض المنفّذ على 8090، وPostgres على 5432. اترك عمليات الارتباط هذه كما هي، وأعد توجيه المنفذ عبر SSH من جهازك.

ssh -N -L 5173:127.0.0.1:5173 you@your-server-ip

افتح http://localhost:5173 في المتصفح المحلي لديك أثناء تشغيل ذلك الأمر. يعني -N أن الاتصال ينقل إعادة التوجيه من دون فتح shell. أضف -L 8090:127.0.0.1:8090 ثانية إلى الأمر نفسه عندما تريد عرض المنفّذ أيضاً.

قد تميل إلى ضبط FRONTEND_BIND_ADDRESS=0.0.0.0 وتجاوز النفق. لا تفعل ذلك. لا تحتوي الواجهة الخلفية على شاشة تسجيل دخول، لذلك يمكن لأي شخص يصل إلى تلك الصفحة بدء عمليات الفحص واستهلاك الرصيد الذي تدفعه لمزوّد الخدمة. للمقارنة، صُمّم Vaultwarden ليكون متاحاً عبر الإنترنت، بينما يعتمد تأمينه في النهاية على رمز المسؤول وملف النسخ الاحتياطي، وهما وسيلتان لا يوفرهما open-kritt. توجد مشكلة أخرى خفية: تتم معالجة منفذ الحاوية المنشور قبل تطبيق السياسة الافتراضية في ufw، لذلك تبدو قاعدة ufw deny 5173 صحيحة لكنها لا تحظر شيئاً. يوضّح منافذ Docker التي تتجاوز ufw سلسلة القواعد التي تسبب ذلك.

تحديد حجم VPS

تكون القيمة الافتراضية لـ ENGINE_MIN_FREE_STORAGE_GB هي 20، ويرفض المحرك بدء حاوية فحص جديدة لكل مهمة عندما تنخفض مساحة التخزين الحرة عن هذه القيمة. توجد الصور المبنية، وذاكرة التخزين المؤقت لعمليات checkout، وبيانات Postgres، ومساحات عمل المهام على القرص نفسه. لذلك لا يبدأ VPS بسعة 20 GB أي فحص على الإطلاق. اعتبر 40 GB الحد الأدنى، وزد السعة إذا كنت تفحص مستودعات كبيرة. لا تحاول استغلال الخادم بإضافة خدمة تستهلك مساحة تخزين كبيرة بجانبه، لأن الحدين المقاسين للذاكرة والقرص في هذه المقارنة بين PhotoPrism وImmich يوضحان مدى سرعة استهلاك مكتبة وسائط للمساحة التي يحتاج إليها الفحص. وينطبق الأمر نفسه على الإضافات التجميلية التي تبدو خفيفة بجانب أداة الفحص: واجهة متصفح تعيد تنسيق مكتبة Jellyfin على شكل متجر تأجير من التسعينيات تظل تشغّل خادم وسائط كاملاً وعمليات تحويل الترميز الخاصة به على القرص، لذلك ضعها على خادم آخر.

تعتمد الذاكرة على حساب بسيط. يحتفظ ENGINE_MEMORY_RESERVE_GB=2 بجزء من الذاكرة للمحرك وقاعدة البيانات وواجهة API والنفقات المؤقتة، ويحمل كل مشغّل فحص حجزاً وحداً أقصى صارماً مقداره ENGINE_SCAN_RUNNER_MEMORY_MB=1536. لذلك يحتاج عاملان إلى نحو 5 GB قبل تشغيل أي شيء آخر. لا يسمح المحرك إلا بالمشغّلات التي تتسع لها الميزانية المتبقية. لذلك تنتظر عمليات الفحص في قائمة الانتظار بدلاً من فشلها على خادم صغير. وهذا أفضل بكثير من أن ينهيها قاتل نفاد الذاكرة. يحدد الحساب نفسه الحد الأدنى لأي أداة تمنح كل وحدة عمل حاويتها الخاصة. ولهذا تصطدم حاوية OpenBot ومتصفح واحد لكل زميل AI بحد الذاكرة قبل وقت طويل من اصطدامها بحد المعالج.

تكون قيمتا الإزالة التلقائية ENGINE_AUTO_PRUNE_DOCKER_BUILD_CACHE وENGINE_AUTO_PRUNE_UNUSED_DOCKER_IMAGES مضبوطة افتراضياً على true. بعد اكتمال المهمة، يزيل المحرك ذاكرة التخزين المؤقت غير المستخدمة للبناء، والصور غير المستخدمة، وحاويات الفحص المتوقفة. ويحافظ على الصور التي تشير إليها حاوية قيد التشغيل، وعمليات bind mount، وبيانات قاعدة البيانات، وبيانات الاعتماد، وvolumes. وهذا سبب إضافي لعدم مشاركة الخادم: إذ يعمل برنامج إزالة لم تضبطه أنت على Docker daemon نفسه.

فحص مستودع محلي من دون تسريبه

تكون القيمة الافتراضية لـ LOCAL_REPOS_PATH هي ./local_repos، ويُربط هذا المسار كـ bind mount داخل حاويتي backend وengine في /local_repos. لذلك يظهر أي مستودع تضعه في هذا المجلد على المضيف داخل الحاويات فوراً. استخدم نسخة clone جديدة، وليس شجرة العمل التي تعمل عليها. تحصل حاوية المهمة على نسخة قابلة للكتابة، ويكون حساب root داخلها، كما تملك وصولاً إلى الإنترنت الصادر. وهذا يعني إمكانية تغيير أي محتوى موجود في تلك النسخة أو إرساله خارج الخادم. أزل ملفات .env والمفاتيح الخاصة قبل نسخ المشروع إليها.

ما تحصل عليه وما لا تحصل عليه

تحصل على نتائج مرشحة مرتبة. ولا تحصل على ثغرات تم التحقق منها. يحدد الترتيب وإزالة التكرارات ترتيب قائمة انتظار الفرز لديك. ولا يثبتان أن النتيجة حقيقية. يمكن للبرامج اللاحقة محاولة التحقق وإنشاء إثبات مفهوم، وهذه أقوى إشارة توفرها الأداة، لكن فشل البرنامج اللاحق لا يثبت أن النتيجة خاطئة. لا يزال يتعين على شخص قراءة كل نتيجة مرشحة. هذه الفجوة بين النتيجة المرشحة والإثبات هي سبب أهمية طلب دليل من agent يمكنك إعادة تشغيله بنفسك هنا أيضاً: فالنتيجة التي يمكنك إعادة إنتاجها عند الطلب أهم من نتيجة مرتبة عليك قبولها دون تحقق.

لا يدّعي هذا الدليل عدد الأخطاء الحقيقية التي يكتشفها open-kritt، لأننا لم نقس ذلك. ومن يذكر معدل اكتشاف لقاعدة التعليمات البرمجية لديك لم يشغّل الأداة على قاعدة التعليمات البرمجية لديك. افحص أولاً مستودعاً تعرفه جيداً: فالنتائج التي يمكنك تقييمها بنفسك هي أرخص وسيلة متاحة لمعايرة الأداة.

يُعد التفويض مهماً هنا أكثر من معظم الأدوات ذاتية الاستضافة. يترجم agents التعليمات البرمجية وينفذونها ويتصلون بالشبكة، لذلك يمكن لخطوة إثبات المفهوم أن تلمس أنظمة حية. وجّه الأداة إلى تعليمات برمجية تملكها أو تعاقدت على اختبارها، واكتب نطاق الهدف قبل تشغيل أي شيء. إذا ضبطت ANTHROPIC_API_KEY واستخدمت محرك Claude Code، فإن ممارسات العزل الواردة في تشغيل Claude Code بأمان على VPS تنطبق على هؤلاء agents أيضاً.

FAQ

لماذا يحتاج open-kritt إلى VPS خاص به؟

لأن وكلاء التحليل يعملون بصلاحيات root داخل حاويات مهام مؤقتة تحتوي على نسخ قابلة للكتابة من شفرتك، ولديها وصول مباشر إلى الإنترنت. كما أن خدمة المحرك تربط Docker socket الخاص بالمضيف حتى تتمكن من تشغيل حاوية لكل مهمة. ويمكن لأي عملية تصل إلى ذلك المقبس تشغيل حاوية تربط نظام ملفات المضيف. لذلك يجب التعامل مع الحزمة بأكملها على أنها تملك صلاحيات root على مضيفها. يكون هذا التنازل مقبولاً على VPS مخصص، كما أن إعادة بناء الخادم لا تكلّفك شيئاً. أما على محطة عملك اليومية، فسيضع مفاتيح SSH وملفات تعريف المتصفح ضمن حد الثقة نفسه الذي توجد فيه الشفرة التي تفحصها.

هل يمكنني إتاحة المنفذ 5173 بدلاً من استخدام نفق SSH؟

لا ينبغي لك ذلك. تُصدر الواجهة الخلفية من دون مصادقة على مستوى التطبيق، لذلك يكون المنفذ هو الحاجز الوحيد بين الإنترنت ونتائج الفحص ورصيد المزوّد. يربط ملف compose كل خدمة بالعنوان 127.0.0.1 لهذا السبب. شغّل ssh -N -L 5173:127.0.0.1:5173 you@your-server-ip وافتح http://localhost:5173 محلياً بدلاً من ذلك. لا تُعد قاعدة ufw بديلاً مناسباً، لأن منفذ Docker المنشور يُعالج قبل تطبيق السياسة الافتراضية لـ ufw.

كيف أمنع open-kritt من إنفاق أكثر مما خططت له؟

عيّن حداً أقصى صارماً في وحدة تحكم مزوّد النموذج قبل أول فحص، لأن open-kritt لا يوفّر إعداداً للميزانية خاصاً به. أبقِ إعدادات التزامن الافتراضية المضمّنة في الإصدار لأول عمليات تشغيل، ENGINE_WORKER_COUNT=2 وENGINE_MAX_CONCURRENT_SCANS=1، وتذكّر أن حساب المزوّد الواحد يسمح افتراضياً بما يصل إلى 15 استدعاءً متزامناً لنموذج root، بينما قد تشغّل جلسة Codex ما يصل إلى خمسة وكلاء فرعيين. يوقف ENGINE_WORKER_COUNT=0 التقاط المهام الجديدة، وهو أسرع إجراء إيقاف محلي.

ما الإصدار الذي ينبغي أن أتحقق منه؟

استخدم tag، وليس main. يعرض git fetch --tags المتاح بعد تشغيل git tag --list، أما v1.3.0، المنشور في 4 August 2026، فهو الأحدث وقت كتابة هذا النص. يضمن التثبيت أن تؤدي إعادة البناء بعد أشهر إلى إنتاج الحزمة نفسها. كما يجعل الترقية قراراً تتخذه بعد قراءة ملاحظات الإصدار، بدلاً من أن تكون أثراً جانبياً لاستنساخ المستودع في يوم مختلف.

لم يبدأ الفحص مطلقاً. ما الذي ينبغي أن أتحقق منه؟

تحقق أولاً من مساحة القرص الحرة، لأن المحرك لن يشغّل حاوية فحص مستقلة لكل مهمة عندما تنخفض المساحة الحرة عن ENGINE_MIN_FREE_STORAGE_GB، التي تكون قيمتها الافتراضية 20 GB. ثم تحقق من أن قيمة ENGINE_WORKER_COUNT ليست 0، لأن هذه القيمة توقف التقاط المهام الجديدة. بعد ذلك، تأكد من إعداد بيانات اعتماد نموذج فعلياً عبر تشغيل ./kritt setup، لأن وجود GITHUB_TOKEN وحده لا يكفي لتشغيل عمليات الفحص. يوضّح docker compose logs engine سبب تخطي المهمة.