❓ الأسئلة الشائعة

حالياً نعم للاستخدام الشخصي. لا حاجة بطاقة ائتمان. خطط مدفوعة للفرق ستظهر مستقبلاً مع ميزات إضافية (multi-tenant، SLA، دعم premium).

الكود closed source حالياً. لكن المعمارية موثّقة بالكامل في الهيكل التقني و رسومات هندسية. الـ API مفتوح للتكامل عبر REST + Webhooks.

Next.js 14 + NestJS 11 + PostgreSQL + Redis + BullMQ + Prisma 6 + Ollama. القائمة الكاملة + المعمارية في دليل الهيكل.

كل البيانات في قاعدة محلية (Postgres) — لا تخرج لخدمات خارجية. JWT auth، signature verification على webhooks، tools whitelist، Sentry للأخطاء، SSL/TLS كامل. تفاصيل في صفحة الهيكل.

نطبّق مبدأي data minimization و user control: البيانات مخزّنة محلياً، تقدر تحذف حسابك متى ما تشاء، الـ logs محدودة بـ retention 30 يوم افتراضياً. لـ GDPR-full compliance راسلنا.

52 وكيل في 12 قسم: محتوى، سيو، إعلانات، CRM، مبيعات، تطوير، e-commerce، تصميم، مالية، استراتيجية، جودة، HR. القائمة الكاملة في صفحة الوكلاء.

الافتراضي: Ollama مع qwen2.5:32b محلياً. النظام يدعم تبديل النموذج (qwen2.5:14b، llama3.2، إلخ). كما يدعم Anthropic + OpenAI كـ fallback للحالات الخاصة.

نعم — من /settings → إدارة الوكلاء. حدّد الاسم، النموذج، system prompt، والأدوات المسموحة. الوكيل يصبح متاحاً فوراً للاستخدام في الـ chat والـ automation.

نعم. من /settings → اختر الوكيل → عدّل الـ system prompt. التغيير يطبّق على المحادثات الجديدة فوراً. المحادثات النشطة تكمل بالـ prompt القديم.

لا، الـ models لا تتدرّب على بياناتك (Ollama محلي، لا data leakage). لكن النظام يحفظ تاريخ المحادثات في “Brain” للسياق المستقبلي — تستطيع تعطيله من الإعدادات.

حسب حدود Meta لحسابك. الـ Cloud API الافتراضية 1000 رسالة/يوم بعد التحقّق التجاري. القوالب الـ utility/marketing لا تُحسَب ضمن هذا الحد. للترقية: راجع Meta Business.

نعم. كل رقم له WaAccount مستقل في الـ DB. الواجهة الحالية تعرض رقماً واحداً افتراضياً؛ لتبديل الرقم المعروض: localStorage.setItem('operix_account_id', '...').

لو Ollama محلي: مجاناً — يستهلك GPU/CPU فقط. لو OpenAI/Anthropic: حسب أسعار الـ tokens (~$0.001 لكل رسالة قصيرة).

الرسالة الأصلية تبقى ظاهرة في الواجهة مع badge أحمر “فشل”. لو الرد كان من AI auto-reply في HYBRID mode، يرجع للقائمة المعلّقة لمراجعتك. الـ error يُسجَّل في /automation/queues.

الـ workflow-runs queue concurrency = 5. يعني 5 runs بنفس اللحظة كحد أقصى. الباقي ينتظر في الـ queue ويُعالَج بالترتيب. لا حد على عدد الـ workflows نفسها.

نعم — عقدة condition مع true/false handles. تفرّع كامل حسب أي قيمة. تفاصيل في صفحة الإجراءات.

نعم — http_request action مع timeout + deep variable interpolation في body/headers. مفيد للتكامل مع Slack، Zapier، أنظمتك الخاصة.

call_agent action يستدعي أي وكيل من الـ 52. النتيجة تصبح متغيّر متاح للعقد التالية عبر {{nodeId.response}}.

الـ job يبقى في BullMQ queue (Redis). عند إعادة تشغيل backend، الـ worker يلتقطه ويكمل من حيث توقّف. الـ idempotency guard يمنع تكرار العقد المنفّذة سابقاً.

حالياً 1-5 مستخدمين في نفس المنظمة (Single account). الـ multi-tenant يأتي في v2.0. كل مستخدم له JWT منفصل وأذونات على الـ tools.

نعم. كل البيانات في Postgres قياسية — استخدم pg_dump للنسخ الكاملة. للـ JSON exports انتقائية، الـ API يدعم GET على كل الـ resources.

الـ Frontend يبنى بـ npm run build وينشر عبر rsync إلى أي VPS مع nginx + PM2. الـ Backend يتطلّب Postgres + Redis + Ollama (إن أردت LLM محلي). الـ DEPLOYMENT.md في الـ repo فيها التفاصيل.

لـ Postgres: pg_dump operix_db > backups/$(date +%F).sql في cron. لـ Redis: BullMQ persists automatically، لكن BGSAVE يومي محبّذ. الـ workflows والوكلاء كلها في Postgres — استرجاعها يستعيد كل النظام.

ثلاث طبقات: (1) /automation/queues للـ live BullMQ stats، (2) Sentry للأخطاء، (3) tail -f /tmp/operix-backend.log | jq . للـ structured logs. تفاصيل في دليل المراقبة.