محاضرة اليوم · مشروع حي

نبني CRM حقيقي ونوصله من اللاب إلى Production

Q: ما الذي سنسلّمه؟

للمزيد من التفاصيل يرجى قراءة محتوى الصفحة أو الدورة.

Q: ماذا يدخل؟ وماذا نؤجل عمدًا؟

للمزيد من التفاصيل يرجى قراءة محتوى الصفحة أو الدورة.

Q: من يستخدم النظام؟

للمزيد من التفاصيل يرجى قراءة محتوى الصفحة أو الدورة.

Q: ماذا يجب أن يفعل النظام؟

للمزيد من التفاصيل يرجى قراءة محتوى الصفحة أو الدورة.

Q: كيف يجب أن يعمل النظام؟

للمزيد من التفاصيل يرجى قراءة محتوى الصفحة أو الدورة.

مش هنطلب من الذكاء الاصطناعي يعمل لنا شاشة شكلها حلو وخلاص. هنبدأ من متطلبات المنتج، ونبني قاعدة البيانات والـ API والحماية، ثم نجهّز المشروع للنشر على الاستضافة ونختبره كمستخدم حقيقي.

الاستاك الأساسي HTML / CSS / JS + PHP 8.2 + MySQL

النشر Hostinger + Domain + HTTPS

الناتج Web App + PWA قابلة للتثبيت

أدوات الـ AI Cursor / Antigravity

لماذا هذا المشروع؟

الـ CRM يعلّمك كيف تبني منتجًا حقيقيًا

مستخدمون وصلاحيات

مدير وموظفون، وكل مستخدم يجب أن يرى فقط البيانات التي تسمح له بها الصلاحيات المطبقة على السيرفر.

بيانات حقيقية

عملاء وصفقات وملاحظات ومهام. لذلك الخطأ هنا ليس مجرد Bug بصري؛ قد يؤدي إلى كشف بيانات أو فقدانها.

بيئة Production

المشروع يجب أن ينتقل من Local إلى استضافة حقيقية مع إعدادات مختلفة وقاعدة بيانات وHTTPS ونسخ احتياطية.

تعريف المنتج

ما الذي سنسلّمه؟

تطبيق Web CRM

واجهة عربية RTL تعمل من المتصفح على الكمبيوتر والموبايل، وتشمل تسجيل الدخول، العملاء، الصفقات، المهام، الأنشطة، التقارير المبسطة وقاعدة المعرفة.

PWA قابلة للتثبيت

نفس تطبيق الويب يمكن تثبيته على الشاشة الرئيسية عندما تتوفر متطلبات PWA. التثبيت لا يعني تلقائيًا أن التطبيق يعمل Offline أو يرسل Push Notifications.

MVP قابل للتسليم MySQL HTTPS PWA لا App Store في هذه المرحلة

نطاق النسخة الأولى

ماذا يدخل؟ وماذا نؤجل عمدًا؟

داخل الـ MVP

تسجيل دخول وإدارة مستخدمين
صلاحيات مدير / موظف
إدارة العملاء
الصفقات ومراحلها
المهام والمتابعة
سجل الأنشطة
قاعدة معرفة داخلية
بحث عربي
لوحة مؤشرات أساسية
PWA قابلة للتثبيت

خارج الـ MVP

محاسبة وفواتير ضريبية كاملة
حملات WhatsApp جماعية
تطبيق Native مستقل للمتاجر
بوابات دفع
تكاملات بنكية
Multi-Tenant معقد
AI يولّد ردودًا تلقائيًا داخل CRM

الأدوار

من يستخدم النظام؟

المدير

يرى جميع العملاء والصفقات والتقارير، ويدير المستخدمين، وينشر ويعدّل مقالات قاعدة المعرفة.

الموظف

يصل إلى السجلات التي يملك صلاحية الوصول إليها، ويضيف المتابعات والأنشطة، ويقرأ قاعدة المعرفة.

العميل النهائي

لا يمتلك حسابًا في النسخة الأولى. النظام داخلي لفريق الشركة وليس بوابة عملاء.

قاعدة مهمة: إخفاء زر في الواجهة ليس Authorization. الصلاحية الحقيقية يجب أن تُفحص في السيرفر.

المتطلبات الوظيفية

ماذا يجب أن يفعل النظام؟

Authentication

إنشاء مدير أول مرة
دعوة الموظفين
تسجيل دخول وخروج
Session آمنة
كلمات المرور تُخزّن كـ Hash وليس كنص صريح
إمكانية إبطال الجلسات حسب التصميم

العملاء

إضافة وتعديل وأرشفة
اسم، هاتف، مصدر، حالة
تطبيع رقم الهاتف قبل المقارنة
Unique Constraint مناسب للبيانات
بحث بالاسم أو الرقم
خط زمني للأنشطة

الصفقات والمهام

جديد → تفاوض → ربح / خسارة
قيمة + عملة
تاريخ إغلاق متوقع
مهمة مرتبطة بعميل أو صفقة
تاريخ استحقاق
حالة مكتملة مع تاريخ الإتمام

التقارير

عملاء جدد
الصفقات المفتوحة وقيمتها
المهام المتأخرة
تحويل العملاء حسب المصدر

قاعدة المعرفة

من جدول عملاء إلى ذاكرة للمؤسسة

المحتوى

سياسات، إجراءات، أسئلة متكررة، نماذج رسائل، تعليمات داخلية ونصوص معتمدة.

التنظيم

أقسام، وسوم، مؤلف، حالة Draft / Published، وتاريخ إنشاء وتحديث.

الصلاحيات

المدير ينشر ويعدل، والموظف يقرأ المحتوى المنشور فقط. المسودات لا تظهر للموظفين.

قاعدة المعرفة ليست ChatGPT. هي النسخة الداخلية المعتمدة من معرفة المؤسسة، ويمكن لاحقًا استخدامها كمصدر لـ RAG إذا احتجنا ذلك.

المتطلبات غير الوظيفية

كيف يجب أن يعمل النظام؟

سرعة

نضع هدفًا واقعيًا لزمن التحميل ونقيسه في البيئة الفعلية، بدل اعتبار "أقل من 3 ثوانٍ" ضمانًا ثابتًا لكل الأجهزة والشبكات.

وضوح

RTL صحيح، رسائل خطأ مفهومة، أزرار مناسبة للموبايل وتجربة لا تعتمد على اللغة الإنجليزية.

أمان

HTTPS، Authorization على السيرفر، Password Hashing، CSRF، Validation، Prepared Statements وعدم كشف الأسرار.

قابلية الاستعادة

نسخ احتياطية منفصلة، مع اختبار استعادة النسخة بدل افتراض أن وجود ملف Backup يعني إمكانية استعادته.

Architecture

المتصفح لا يتصل بـ MySQL مباشرة

Browser / PWA

↓

UI + JavaScript

↓

API

↓

Authentication + Authorization

↓

Business Logic + Validation

↓

MySQL

قاعدة ذهبية

لا نضع بيانات MySQL أو كلمة مرور قاعدة البيانات داخل JavaScript الذي يصل إلى المتصفح.

والـ API لا يفترض أن المستخدم مخوّل لمجرد أنه وصل إلى endpoint؛ كل عملية حساسة يجب أن تمر عبر Authentication وAuthorization وValidation.

Security Architecture

كيف نمنع الـ AI من بناء نظام غير آمن؟

Identity

Authentication
Secure Sessions
Password Hashing
Session Revocation عند الحاجة

Input / Output

Server-side Validation
Prepared Statements
Output Escaping
CSRF Protection

Infrastructure

HTTPS
Secrets خارج Git
Error Handling آمن
Backups
Logging مناسب

الأمن ليس Feature نضيفها في النهاية؛ هو جزء من Architecture منذ أول Prompt.

نموذج البيانات

الجداول الأساسية في MySQL

الجدول	الغرض	حقول مهمة
users	المستخدمون	id, name, email, password_hash, role, active, created_at
clients	العملاء	id, owner_id, name, phone_normalized, source, status, created_at
deals	الصفقات	id, client_id, title, stage, value, currency, close_date
tasks	المهام	id, client_id, deal_id, assigned_to, title, due_at, completed_at
activities	سجل الأنشطة	id, client_id, user_id, type, body, occurred_at, created_at
kb_categories	أقسام المعرفة	id, title, sort_order
kb_articles	مقالات المعرفة	id, category_id, title, body, status, author_id, updated_at

البيئة المحلية

نبني محليًا قبل أن نلمس Production

PHP / MySQL

PHP 8.2 أو إصدار مدعوم ومناسب للمشروع
MySQL محلية عبر Laragon أو XAMPP
Composer عند الحاجة
Git
متصفح حديث

لو اخترنا Node

Node.js محليًا
Package manager
Git
اختبار متطلبات التشغيل على Hostinger قبل اعتماد المسار

أداة الـ AI تساعدنا في التنفيذ، لكنها لا تختار وحدها بيئة Production. نحن نتحقق أولًا من متطلبات الاستضافة الفعلية.

Vibe Coding Workflow

لا تقل للوكيل: "ابنِ المشروع كله"

Product Brief

المستخدمون، المشكلة، النطاق، الـ MVP ومعايير النجاح.

Architecture

تحديد Frontend وAPI وAuthentication وDatabase قبل الكود.

Schema + API Contract

الجداول والعلاقات والـ endpoints المطلوبة قبل بناء الواجهات.

Implementation Modules

Auth → Clients → Deals → Tasks → Knowledge Base → PWA.

Test → Commit → Continue

كل وحدة تعمل قبل الانتقال إلى الوحدة التالية.

قاعدة المشروع

اجعل الوكيل يعرف حدود المشروع

AGENTS.md

Architecture المعتمدة
قواعد تسمية الملفات
Security Rules
قواعد Database Access
لا تغييرات واسعة دون موافقة
لا مكتبات جديدة دون سبب

قواعد ثابتة

كل Authorization على السيرفر
لا Secrets داخل Git
لا Production credentials في Prompt
كل Feature لها طريقة اختبار
لا Refactor شامل أثناء Feature صغيرة

الهدف ليس أن تجعل الـ AI يكتب أكثر كود ممكن؛ الهدف أن تجعله يكتب أقل كود صحيح يمكن اختباره والمحافظة عليه.

قاعدة المعرفة + PWA

نضيف الـ Knowledge Base ثم نجهّز PWA

Knowledge Base

Categories
Articles
Draft / Published
بحث عربي
صلاحيات النشر
تاريخ التحديث والمؤلف

PWA

Web App Manifest
أيقونات مناسبة
RTL وتجربة Mobile
Service Worker عند الحاجة
Cache للمحتوى غير الحساس فقط
Offline لا يُفترض تلقائيًا

Web Push Notifications ليست جزءًا تلقائيًا من PWA؛ إذا أردناها نضيف Permission + Push Subscription + Service Worker + Backend للإرسال كمرحلة مستقلة.

Hostinger · Database

تجهيز MySQL على الاستضافة

إنشاء قاعدة البيانات

استخدم أدوات قواعد البيانات المتاحة في حساب Hostinger الحالي لإنشاء قاعدة MySQL.

إنشاء مستخدم قاعدة البيانات

استخدم بيانات اتصال قوية واربط المستخدم بالقاعدة المطلوبة وفق الصلاحيات المناسبة.

استيراد Schema

استورد schema.sql عبر أداة الإدارة المتاحة مثل phpMyAdmin عندما تكون متاحة.

Seed منفصل

استخدم seed-dev.sql للبيانات التجريبية محليًا، ولا ترفع حسابات تجريبية معروفة إلى Production.

لا نفترض أن DB_HOST دائمًا localhost. نستخدم قيمة الاتصال التي توفرها بيئة الاستضافة الحالية.

Hostinger · Deployment

من Local إلى Production

PHP Web App

Document Root حسب إعداد الموقع
رفع الملفات بالطريقة المناسبة
Composer dependencies حسب الـ workflow
إعداد Production منفصل
عدم رفع الأسرار إلى Git
PHP version حسب المتطلبات المدعومة

Node.js Web App

يُستخدم فقط إذا كانت الخدمة الحالية تدعمه
تحقق من الخطة والمنتج الفعلي قبل الاعتماد عليه
حدد Node version المناسبة
Build / Start commands
Environment Variables
لا ترفع node_modules من جهاز Windows كقاعدة

تفاصيل hPanel والخطط قد تتغير؛ لذلك نتعامل مع إعدادات Hostinger الحالية باعتبارها مصدر الحقيقة وقت التنفيذ.

Domain · HTTPS · Launch

آخر ميل قبل الـ Live

ربط الدومين

استخدم الطريقة المناسبة حسب مكان إدارة DNS: Nameservers أو السجلات المطلوبة مثل A / CNAME.

DNS

انتظر انتشار التغييرات ولا تعتبر عدم الوصول الفوري دليلًا على فشل المشروع.

TLS / HTTPS

فعّل شهادة TLS/SSL المتاحة، ثم اختبر HTTPS وإعادة التوجيه وتوحيد النطاق المستخدم.

Smoke Test

مدير + موظف + عميل + صفقة + مهمة + مقال + اختبار صلاحيات.

Backup ثم Launch

نسخة من الملفات والقاعدة، ثم اختبار استعادة النسخة وفق الإمكانية المتاحة، وبعدها إطلاق الرابط.

Prompt البناء النهائي

لا تبدأ بالكود قبل أن تعطي الـ AI خريطة العمل

أنت تعمل كمهندس برمجيات مسؤول عن بناء CRM عربي RTL قابل للنشر. قبل كتابة أي كود: حلّل المتطلبات، اقترح Architecture واضحة، صمّم Schema لقاعدة MySQL، وحدد API Contract وقواعد Authentication وAuthorization وSecurity. بعد ذلك أنشئ خطة تنفيذ Modules ولا تنفذ المشروع كله دفعة واحدة.

الاستاك الأساسي: HTML/CSS/JavaScript + PHP 8.2 + MySQL. الوحدات: Users, Clients, Deals, Tasks, Activities, Knowledge Base, PWA.

الموظف لا يصل إلا إلى السجلات المسموح بها له، وجميع الصلاحيات يجب أن تُفحص على السيرفر. استخدم Prepared Statements وServer-side Validation وCSRF Protection وPassword Hashing وSecure Session Handling.

أنشئ: schema.sql، seed-dev.sql، .env.example، وAGENTS.md. لا تضع أي Production password أو API key داخل الكود أو Git أو Prompt.

بعد كل Module: اشرح ما تم بناؤه، طريقة اختباره، الحالات الحدّية، والمخاطر الأمنية المحتملة قبل الانتقال إلى الوحدة التالية.

التقييم النهائي

المشروع لا يُعتبر مكتملًا لأنه يبدو جميلًا

Live

رابط حقيقي يعمل عبر HTTPS ويمكن الوصول إليه من جهاز وشبكة مختلفة.

Secure

المدير والموظف لا يتجاوزان صلاحياتهما، ولا توجد أسرار مكشوفة أو بيانات يمكن الوصول إليها دون Authorization.

Useful

يمكن إضافة عميل، تحريك صفقة، إنشاء مهمة، ونشر والبحث عن مقال في قاعدة المعرفة.

Web App MySQL API Security PWA Production

الهدف من Vibe Coding ليس أن يكتب الذكاء الاصطناعي المشروع بدلًا منك؛ الهدف أن تتعلم كيف تقود AI لبناء نظام يمكن اختباره وتشغيله وصيانته.