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

وصلتني نتائج البحث كاملة، والصورة الآن واضحة تماماً. إليك التقرير المفصل الثاني — نسخة العمليات والمعمارية:

---

# التقرير الثاني: منصة «مواصلاتي» — نموذج التشغيل، المعمارية الكاملة، ودليل العلاقات العامة

## القسم الأول: نتيجة البحث — كيف يعمل سويفل وسالك فعلياً؟

هذا جواب سؤالك المباشر، وهو أهم معلومة في التقرير كله:

**سويفل لا تملك أي باص ولا توظف أي سائق.** شروط خدمتها تنص حرفياً على أنها ليست ناقلاً، لا تملك ولا تشغّل مركبات، ولا توظف سائقين — هي منصة تقنية وسوق حجز. مصدر الباصات عندهم نوعان: «كباتن» مستقلون يملكون باصاتهم أو فانات (ووصل بهم الأمر لعقد شراكات مع بنوك مصرية مثل بنك ناصر الاجتماعي لتمويل شراء الكباتن باصات فورد ترانزيت)، وشركات نقل متعاقدة. وفوق هذا يبيعون منتجين مؤسسيين: النقل كخدمة (هم يدبّرون الباصات للشركة/المدرسة)، وبرمجيات إدارة النقل كخدمة مستقلة تعمل على أسطول العميل نفسه.

**سالك بنفس المنطق تقريباً:** منصة اشتراكات للطلاب — الطالب يشترك عند سالك مباشرة (باقات، أكثر من ١٥٠ نقطة تجميع)، والرحلات على باصات متعاقدة تديرها سالك، وليست باصات الجامعات. أي أن سالك يبيع المقعد للطالب، والجامعة ليست طرفاً في العقد أصلاً — هي فقط الوجهة.

**ماذا يعني هذا لنا؟ ثلاث خلاصات حاسمة:**

- الفراغ السوقي الحقيقي هو بالضبط ما تنوون فعله: **لا أحد يقدّم للجامعة برمجيات مجانية على أسطولها هي**. سويفل تبيع البرمجيات كمنتج مدفوع للشركات الكبيرة، وسالك يتجاهل أسطول الجامعة كلياً. عرضكم (مجاني + أسطولهم + تطبيقكم) لا منافس مباشراً له.
- نموذجهم يؤكد صحة قرار عدم امتلاك باصات: أكبر شركة في المجال، مدرجة في ناسداك، رفضت امتلاك الأصول من اليوم الأول.
- فكرة «شركة باصات نتعاقد معها» التي طرحتَها هي حرفياً نموذج كباتن سويفل — وهي سليمة، لكن مكانها الصحيح في نموذجنا هو **حل حالة الجامعة التي لا تملك أسطولاً** (وأغلبها الحكومية)، وليست أساس النموذج.

---

## القسم الثاني: نموذج التشغيل — ثلاثة أنماط عرض في منصة واحدة

المعمارية يجب أن تدعم من اليوم الأول ثلاثة أنماط، لأن كل عميل سيقع في واحد منها:

**النمط الأول — أسطول المؤسسة (النمط الرئيسي):** الجامعة/المدرسة/الفندق/الشركة تملك باصاتها وسائقيها. نحن نقدّم البرمجيات فقط: تتبع، إشعارات، لوحة تحكم، تسجيل طلاب. مجاني. هذا نمط الجامعات الخاصة في الدول الثلاث، وهو الأسرع إغلاقاً لأنه لا يكلف الجامعة قرشاً ولا يهدد موظفيها.

**النمط الثاني — الناقل المتعاقد (طبقة التنظيم):** المؤسسة لا تملك أسطولاً — الحالة الغالبة في الجامعات الحكومية بالأردن وسوريا. نحن نُدخل طرفاً ثالثاً: شركة باصات أو مكتب نقل محلي يسجَّل عندنا ككيان «ناقل»، ونربطه بالجامعة. الجامعة تعطي المباركة الرسمية ونقاط الانطلاق داخل الحرم، الناقل يشغّل، ونحن ننظّم ونتتبع. هنا لاحقاً يوجد إيراد حقيقي (عمولة من الناقل أو رسم تنظيم)، لكن في البداية نفس المنطق: مجاني لبناء الشبكة.

**النمط الثالث — مقاعد بالاشتراك (مؤجل عمداً):** أن نبيع المقعد للطالب مباشرة كما تفعل سالك. لا ندخله الآن إطلاقاً — هو الوحيد الذي يتطلب عمليات ثقيلة وضمان إشغال، وهو ساحة سويفل وسالك المحصّنة. يبقى خياراً مستقبلياً تفتحه البيانات التي سنجمعها (سنعرف بالضبط أي المسارات مكتظة وأيها مهمَل).

**مصفوفة الاستخدام:** جامعة خاصة ← النمط الأول. جامعة حكومية ← النمط الثاني. مدرسة خاصة ← الأول (عندها باصات غالباً). فندق ← الأول (فاناته) + حساب مشاوير مؤسسي. شركة/مصنع ← الأول أو الثاني حسب ملكية الأسطول.

---

## القسم الثالث: الاستراتيجية متعددة الدول — لا مصر وحدها

تصحيح زاوية التقرير الأول: المنصة تُبنى محايدة للدولة تماماً، وكل كيان مؤسسي يحمل حقلَي دولة ومدينة، والبوليغونات موجودة عندكم أصلاً في `country_polygons.dart` للأردن وسوريا ومصر (وقلتَ إن بوليغونات الجامعات الخاصة في مصر شبه جاهزة — تُخزَّن كبوليغون للحرم مرتبط بكيان الجامعة، وتفيد في الاقتراح التلقائي للجامعة عند التسجيل وفي جيوفينس الوصول للحرم).

**الأردن:** الجامعات الخاصة (البترا، الشرق الأوسط، الزيتونة، الإسراء، العلوم التطبيقية...) تشغّل خطوط باصات فعلية من المدن — عملاء نمط أول مثاليون. الجامعات الحكومية (الأردنية، اليرموك، مؤتة، آل البيت...) طلابها على باصات النقل العام والمكاتب الخاصة — نمط ثانٍ: نتعاقد مع مكاتب الباصات العاملة أصلاً على خطوط الجامعات ونعطي الجامعة نظام التتبع مجاناً مقابل التبني الرسمي. قناة إضافية مهمة بالأردن: اتحادات الطلبة وعمادات شؤون الطلبة.

**سوريا:** الفرصة الأعمق والمنافسة صفر تقريباً. الجامعات حكومية ضخمة (دمشق، حلب، تشرين، البعث) والنقل الطلابي فوضوي (سرافيس وميكروباصات خاصة). النمط الثاني هو الطريق: التعاقد مع متعهدي نقل قائمين على خطوط الجامعات + مذكرة تفاهم مع الجامعة أو حتى وزارة التعليم العالي (في سوريا القرار مركزي — علاقة واحدة جيدة بالوزارة تفتح كل الجامعات دفعة واحدة). وميزة سوريا: وجودكم التشغيلي القائم وعقدكم الاستثماري هناك يعطيكم أرضية علاقات جاهزة.

**مصر:** كما في التقرير الأول — الجامعات الخاصة أولاً (والطلب وارد فعلاً من جامعة)، مع وعي كامل بوجود سالك وسويفل، وتمايزنا أننا لا نبيع مقاعد بل نرقمن أسطول الجامعة مجاناً.

**التوظيف:** مسؤول شراكات ميداني واحد لكل دولة (وصفه الوظيفي الكامل في القسم الحادي عشر)، يتبع لمدير تطوير أعمال مركزي. لا حاجة لأكثر في السنة الأولى.

---

## القسم الرابع: المعمارية التقنية الكاملة

### ١. مبدأ العزل من اليوم الأول — جواب فكرة «السيرفر الصغير المنفصل»

فكرتك عن سيرفر مستقل صغير بقاعدة بيانات وردس خاصين **صحيحة معمارياً مئة بالمئة**، وتحليل الحمل يثبتها: الضغط هنا معكوس عن النقل العادي. في المشاوير عندك آلاف السيارات وكل سيارة يتابعها راكب واحد؛ في الباصات عندك عشرات الباصات وكل باص يتابعه **مئات الطلاب في نفس اللحظة** (الثامنة صباحاً). خمسمئة باص ترسل إحداثية كل ٤ ثوانٍ = ١٢٥ رسالة/ثانية فقط (تافهة)، لكن توزيعها الساذج على ٥٠ ألف طالب = ملايين الرسائل. الحل ليس قوة سيرفر بل **نمط النشر**: غرفة سوكيت لكل خط، الطالب يشترك بغرفة خطه فقط، وكل نبضة GPS تُبث مرة واحدة للغرفة. بهذا النمط سيرفر صغير جداً (٢ كور / ٤ غيغا) يخدم مئات الجامعات.

التنفيذ على مرحلتين حتى لا نؤخر الإطلاق:

- **المرحلة الأولى (الإطلاق):** الكود في مجلد مستقل `backend/transit/` على السيرفر الرئيسي الحالي، لكن بقاعدة بيانات MySQL مستقلة تماماً اسمها `siro_transit` تُضاف كاتصال ثالث في نمط `Database::get('transit')` الموجود عندكم (نفس آلية main وride)، وردس بمساحة أسماء خاصة `transit:*`. **قاعدة ذهبية: ممنوع أي JOIN بين قاعدة transit وقواعد النقل الرئيسية** — الربط بالمعرّفات فقط (passenger_id، driver_id) وعبر استدعاءات HTTP داخلية بنمط `sendToLocationServer` الموجود. هذه القاعدة وحدها هي ما يجعل الفصل لاحقاً عملية نقل ملفات وتغيير سطر في `.env`، لا إعادة كتابة.
- **المرحلة الثانية (عند تجاوز ~٥ جامعات فعّالة):** نقل قاعدة `siro_transit` وعملية سوكيت مستقلة `transit_socket.php` (استنساخ نمط `passenger_socket.php` بوركرمان الذي يعمل عندكم) إلى VPS صغير مستقل بردسه الخاص. تتبع الباصات يبقى في البداية على سوكيت السائقين الحالي في خادم المواقع بوسم `vehicle_kind=bus`، وينتقل مع الفصل.

### ٢. مخطط قاعدة البيانات (قاعدة `siro_transit`)

- جدول `transit_orgs`: المؤسسات — المعرّف، النوع (جامعة/مدرسة/شركة/فندق/**ناقل**)، الاسم بالعربية والإنجليزية، الدولة، المدينة، بوليغون الحرم، الشعار، حالة العقد، تاريخ التفعيل. نوع «ناقل» هو ما يفعّل النمط الثاني.
- جدول `transit_org_links`: ربط ناقل ↔ مؤسسة (جامعة حكومية تخدمها شركة باصات).
- جدول `transit_org_admins`: مشرفو المؤسسة — الهاتف، الاسم، الدور (مالك/مشرف نقل/مُرسِل)، صلاحيات، دخول بهاتف + OTP على لوحة الويب.
- جدول `transit_vehicles`: الباصات — المؤسسة المالكة، اللوحة، السعة، الموديل، الحالة. (منفصل عن `captains_car` عمداً — باص الجامعة ليس سيارة كابتن).
- جدول `transit_drivers`: سائقو الباصات — الهاتف، الاسم، المؤسسة، رقم الرخصة وصورتها، حالة التفعيل، وحقل `main_driver_id` اختياري يربطه بجدول `driver` الرئيسي إن كان كابتن مشاوير أيضاً (سائق فندق مثلاً).
- جدول `transit_routes`: الخطوط — المؤسسة، الاسم («خط الزرقاء صباحي»)، الاتجاه (ذهاب/عودة)، البوليلاين المشفّر، المسافة، الزمن التقديري، الحالة (مسودة/معتمد/موقوف).
- جدول `transit_stops`: المحطات — الخط، الترتيب، الاسم، الإحداثيات، نصف قطر الجيوفينس بالمتر (افتراضي ١٥٠م)، الإزاحة الزمنية التقديرية عن الانطلاق.
- جدول `transit_schedules`: الجداول — الخط، أيام الأسبوع (قناع بتات)، وقت الانطلاق، فترة السريان (بداية/نهاية الفصل الدراسي).
- جدول `transit_trips`: الرحلة الفعلية اليومية — الجدول، التاريخ، السائق، الباص، الحالة (مجدولة/انطلقت/انتهت/ملغاة)، أوقات البدء والانتهاء الفعلية. هذا الجدول هو مصدر تقارير الالتزام.
- جدول `transit_enrollments`: العضويات — معرّف الراكب (من النظام الرئيسي)، المؤسسة، **الرقم الجامعي/الوظيفي**، الدور (طالب/موظف/نزيل)، الحالة (نشط/موقوف/منتهي)، تاريخ انتهاء الصلاحية (نهاية الفصل — التجديد الفصلي يحصل بإعادة استيراد الكشف وتحديث التواريخ تلقائياً).
- جدول `transit_rosters`: سجل عمليات استيراد كشوف الطلاب — من رفعها، متى، كم سجلاً، وفروقات النسخة السابقة (من تخرّج يُعطَّل تلقائياً).
- جدول `transit_guardians`: أولياء الأمور (للمدارس) — راكب وليّ الأمر مربوط بعضوية الطالب/الطفل، صلة القرابة، أنواع الإشعارات المفعّلة.
- جدول `transit_boardings` (مرحلة ثانية): إثبات الصعود — الرحلة، العضوية، وقت الصعود/النزول، الطريقة (QR/تأشير السائق/جيوفينس).
- جدول `transit_broadcasts`: إعلانات المشرف («غداً عطلة — لا باصات») مع سجل التسليم.

### ٣. تدفق التتبع والإشعارات

- **الإرسال:** تطبيق السائق في وضع الباص يبث الموقع لسوكيت المواقع الحالي بوسم الرحلة. المعالج يكتب في ردس `transit:trip:{id}:pos` وينشر في قناة `transit:route:{id}`.
- **الاستقبال الحي:** الطالب الفاتح للخريطة مشترك بغرفة خطه فقط — بث واحد لكل نبضة.
- **الإشعارات الخاملة (الأهم):** الطالب غير الفاتح للتطبيق يصله إشعار FCM عبر **اشتراك Topic لكل خط** (`transit_route_123`) — وهذا قرار مهم للتكلفة: مواضيع FCM مجانية وتوزّع للآلاف بلا أي حمل على سيرفرنا، ولا نحتاج إدارة توكنات فردية للبث العام.
- **إشعار الاقتراب الشخصي:** الطالب يحدد «محطتي» مرة واحدة؛ عند دخول الباص جيوفينس المحطة السابقة لمحطته، يُرسل إشعار موجّه «الباص يبعد محطة واحدة عنك». الحساب يتم سيرفرياً بمقارنة موقع الباص بمحطات الخط (وجدول `geofence_zones` وخبرة خدمة الجيوفينس الموجودة في تطبيق الراكب تُعاد هنا).
- **حزمة إشعارات لكل شخصية:** للطالب (انطلق الباص، اقترب من محطتك، تأخر، آخر نداء، إعلانات المشرف)؛ لولي الأمر في المدارس (صعد ابنك ✓ نزل ابنك ✓ الباص اقترب من البيت)؛ للفندق (السائق وصل البوابة لنزيل الغرفة كذا، تقرير شهري)؛ للمشرف (باص لم ينطلق بموعده، باص خرج عن المسار، سائق أغلق التطبيق أثناء رحلة، ملخص التزام يومي). مع قواعد ضبط: ساعات هدوء، ومنع التكرار خلال نافذة زمنية.

---

## القسم الخامس: جهة السائق — كيف نميّز سائق الباص ونديره

هذا جواب سؤالك التشغيلي، والمبدأ الحاكم: **سائق الباص ليس كابتن مشاوير، فلا يمر بمسار الكباتن إطلاقاً.**

- **التمييز في البيانات:** يوجد عندكم حقل `employmentType` في جدول السائق أصلاً — سائق الباص يُسجَّل في `transit_drivers` بربط اختياري فقط مع الجدول الرئيسي. لا يستقبل عروض مشاوير أبداً، لا يظهر في بحث السيارات القريبة، ولا يدخل منظومة الأرباح والمحفظة (راتبه من الجامعة).
- **التسجيل مقلوب:** الكابتن العادي يسجّل نفسه ثم توافقون؛ سائق الباص **يُنشئه مشرف الجامعة** من لوحة التحكم (اسم + هاتف + رخصة)، فتصله رسالة دعوة، يحمّل تطبيق السائق نفسه، يدخل بهاتفه + OTP، فيتعرف النظام عليه كسائق باص ويفتح له «وضع الباص» مباشرة. لا وثائق جنائية ولا فحص منا — الجامعة موظِّفه وهي المسؤولة، ونوثّق ذلك في العقد.
- **واجهة وضع الباص (بساطة متطرفة عمداً):** شاشة واحدة: رحلة اليوم القادمة (الخط، الوقت، الباص) وزر كبير «ابدأ الرحلة». أثناء الرحلة: شريط المحطات يتقدم تلقائياً بالجيوفينس (بلا أي إدخال يدوي)، زر «تأخير» يبث إشعاراً جاهزاً للمشتركين، زر طوارئ، ودردشة مع المشرف (نفس بنية دردشة `backend/ride/chat` الجاهزة). زر «أنهِ الرحلة» يظهر عند آخر محطة. لا عدّاد، لا أسعار، لا خريطة طلبات.
- **السائق المزدوج:** سائق فان الفندق قد يكون كابتن مشاوير مساءً — الربط عبر `main_driver_id` يسمح له بالتبديل بين الوضعين من زر واحد، ولا يمكن أن يكون في الوضعين معاً.
- **حل مشكلة الالتزام (لأن السائق ليس شريكنا اقتصادياً):** أداتنا هي الجامعة نفسها — تقرير الالتزام اليومي للمشرف (انطلق بالموعد؟ أغلق التطبيق؟ أنهى الخط؟) يجعل تشغيل التطبيق جزءاً من تقييم السائق الوظيفي عند مديره. ونضيف تحفيزاً ناعماً: شارة «سائق ممتاز» وتقييم الطلاب للرحلة.

---

## القسم السادس: جهة الطالب — التسجيل والتحقق بالتفصيل

- **المبدأ الذي حددتَه صحيح:** الطالب راكب عادي أولاً — نفس تسجيل الراكب (هاتف + OTP الموجود). تبويب «مواصلاتي» مقفل حتى يفعّل عضويته.
- **تدفق التفعيل:** يفتح مواصلاتي ← يظهر له اختيار الجامعة (مرشّحة تلقائياً حسب موقعه وبوليغون الدولة) ← يدخل رقمه الجامعي ← التحقق بإحدى ثلاث طرق حسب جاهزية الجامعة: **أ)** استعلام API مباشر من نظام الجامعة إن وُجد (الأفضل، ونجهّز له عقد ربط موحّداً بسيطاً: endpoint واحد يستقبل الرقم ويرجع الحالة والاسم)؛ **ب)** الكشف المستورد — المشرف رفع ملف إكسل/CSV بأرقام الطلاب (وهواتفهم إن توفرت) ونطابق محلياً؛ **ج)** الموافقة اليدوية — الطلب يذهب لطابور المشرف يوافق عليه من اللوحة (للجامعات الأقل تنظيماً).
- **نقطة ذكية في موضوع OTP توفّر مالاً حقيقياً:** الطالب هاتفه موثّق أصلاً بـOTP عند تسجيله كراكب. فإن كان كشف الجامعة يحتوي أرقام الهواتف وطابق هاتف الحساب = هذا أقوى توثيق ممكن **بصفر رسائل SMS إضافية**. نرسل OTP ثانياً فقط عند عدم التطابق أو غياب الهاتف من الكشف. ومع آلاف الطلاب، كل OTP موفَّر يعني خفضاً مباشراً لفاتورة SMS — ولديكم أصلاً قناة واتساب عبر نابح كبديل أرخص عند الحاجة.
- **دورة الحياة:** العضوية تنتهي بنهاية الفصل تلقائياً (حقل الصلاحية)، وإعادة استيراد كشف الفصل الجديد تجدد النشطين وتعطّل المتخرجين. طالب انتقل جامعة؟ عضويات متعددة مسموحة نظرياً، والمشرف يرى قائمته فقط.
- **داخل التبويب:** خطوط جامعته وجداولها، خريطة الباص الحي، «محطتي» المفضلة، إشعاراته، وإعلانات الجامعة. **وأهم زر في المشروع كله:** عندما يفوت الطالب الباص أو يكون الانطلاق القادم بعيداً، يظهر «فاتك الباص؟ اطلب سيارة الآن» بمسار معبأ مسبقاً نحو الجامعة — هذه نقطة تحويل الدعاية إلى إيراد، وقياس نقراتها هو مؤشر نجاح المشروع الأول.

---

## القسم السابع: تعريف الخطوط — من يرسمها؟

جواب مباشر لسؤالك: **الاثنان معاً، لكن بترتيب زمني وبحوكمة.**

- **في الإطلاق: فريقنا يرسم.** جودة أول انطباع أهم من التفويض. نبني محرر خطوط في لوحة الإدارة: المشرف عندنا ينقر المحطات على الخريطة بالترتيب، والنظام يولّد البوليلاين تلقائياً عبر محرك التوجيه بين المحطات، مع إمكانية سحب المسار لتعديله (وخرائطكم الخاصة intaleq_maps تعني صفر تكلفة API هنا). جلسة تجهيز جامعة كاملة (١٠–١٥ خطاً) = يوم عمل واحد مع مشرف نقل الجامعة على الهاتف.
- **من الفصل الثاني: نفس المحرر يُفتح لمشرف الجامعة** في لوحته، لكن بسير عمل «مسودة ← اعتماد»: أي خط يرسمه أو يعدّله يبقى مسودة حتى يعتمده فريقنا (فحص جودة: محطات منطقية، جيوفينس لا يتداخل، المسار سالك). بهذا نفوّض الجهد ونحتفظ بالجودة.
- **المحطات جيوفينس من اليوم الأول** كما اقترحت: كل محطة دائرة بنصف قطر قابل للضبط، وهي أساس ثلاث وظائف دفعة واحدة: تقدّم شريط المحطات عند السائق، إشعار الاقتراب للطالب، وكشف الخروج عن المسار للمشرف.

---

## القسم الثامن: لوحة مشرف المؤسسة (ويب)

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

---

## القسم التاسع: تفريعات المدارس والفنادق والشركات

- **المدارس:** نفس البنية مع طبقة ولي الأمر: الأهل يسجلون كركاب عاديين ويربطون أبناءهم برمز من إدارة المدرسة، وإشعارات «صعد/نزل» تتطلب إثبات صعود (مرحلة ثانية: تأشير السائق على قائمة الطلاب أو QR). حساسية بيانات القاصرين أعلى — عقد معالجة بيانات إلزامي، ولا يظهر اسم الطفل الكامل في أي إشعار.
- **الفنادق:** الوجه المجدول (مكوك مطار بمواعيد) يستخدم نفس بنية الخطوط، والوجه الأهم (سيارة للنزيل من الاستقبال بفوترة شهرية) هو مشاوير عادية بحساب مؤسسي — موظف الاستقبال مشرفٌ يطلب من اللوحة، والفاتورة تتجمع على كيان الفندق. دفعكم جاهز بالدول الثلاث فالفوترة الشهرية تركيب محاسبي فوق الموجود.
- **الشركات والمصانع:** أقرب نسخة للجامعات (خطوط تجميع موظفين بورديات)، مع فارق وحيد: الجداول تتبع الورديات لا الفصول، والعضوية برقم وظيفي. هي أيضاً بلا موسمية — تملأ صيف الجامعات.

---

## القسم العاشر: النموذج المجاني — ماذا نكسب بالضبط وكيف نضبط كلفته

تثبيتاً لقرارك: الخدمة مجانية بالكامل للجميع (الجامعة، الطالب، السائق)، ونحن نكسب أربعة أشياء تُقاس رقمياً:

- **التثبيتات:** كل جامعة = آلاف تثبيتات بقرار واحد. المؤشر: تثبيتات لكل مؤسسة مفعّلة.
- **العادة اليومية:** فتحتان يومياً على الأقل لكل طالب نشط. المؤشر: نسبة النشطين يومياً من المسجلين.
- **التحويل لمشاوير مدفوعة:** زر «فاتك الباص» + الاستخدام المسائي. المؤشر الحاكم للمشروع كله: نسبة الطلاب الذين طلبوا أول مشوار مدفوع خلال ٣٠ يوماً من تفعيل العضوية.
- **السمعة والمرجعية:** شعارات الجامعات في العرض التسويقي وأمام المستثمرين.

وضبط التكلفة ممكن لأن أثقل بندين عندكم محلولان: الخرائط ملككم (صفر رسوم لكل طلب — ميزة قاتلة على أي منافس يدفع لغوغل عن كل طالب يفتح الخريطة)، وSMS نقلّصه بحيلة مطابقة هاتف الكشف أعلاه وبواتساب نابح. الباقي (سيرفر صغير + تخزين) هامشي. أي أن «الدعاية» هذه تكلفتها التشغيلية شبه ثابتة مهما كبر عدد الطلاب — وهذا ما يجعل النموذج المجاني آمناً مالياً.

مع تحفّظ واحد أسجله بأمانة: نُبقي في العقد بنداً يسمح بخدمات مدفوعة اختيارية لاحقاً (نسخة بعلامة الجامعة، باقة تقارير متقدمة، إشعارات أهل مميزة في المدارس) حتى لا نقفل باب الإيراد المباشر للأبد بوعد «مجاني إلى الأبد» مكتوب.

---

## القسم الحادي عشر: دليل مدير العلاقات العامة — كتيّب العمل الكامل

**الوصف الوظيفي:** مسؤول شراكات ميداني في كل دولة، خلفية مبيعات B2B أو علاقات جامعية، هدفه الرقمي: ٤ اجتماعات أسبوعياً، تجربتان موقّعتان كل ربع سنة، ومتابعة تفعيل ما يوقّعه (التوقيع بلا تفعيل لا يُحتسب له).

**بناء قائمة الأهداف:** يبدأ بالجامعات الخاصة التي تعلن خطوط باصات على مواقعها (القائمة تُجهّز مكتبياً قبل أي زيارة)، ثم المدارس الخاصة الكبرى، ثم الفنادق ٤–٥ نجوم، ثم مديري الحركة في الشركات الصناعية.

**من يقابل بالترتيب:** مدير الحركة/النقل أولاً (لا تتجاوزه أبداً — إن شعر أن النظام سيكشف تقصيره أو يستبدله سيقتل الصفقة من الظل؛ العرض يُصاغ له هو: «نظام يريحك من مكالمات وين الباص ويظهر انضباط دائرتك أمام الرئاسة»)، ثم نائب الرئيس للشؤون الإدارية (صاحب التوقيع)، وعمادة شؤون الطلبة (حليف داخلي لأن رضا الطلاب معيار أدائها). في الحكومية يضاف: اتحاد الطلبة كقناة ضغط إيجابي، والوزارة في سوريا.

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

**الاعتراضات المتوقعة وردودها الجاهزة:**
- «عندنا GPS على الباصات أصلاً» ← «نظام التتبع عندكم يراه موظف واحد في غرفة؛ نحن نضعه بجيب كل طالب وولي أمر، مع إشعارات — الفرق بين كاميرا مراقبة وخدمة.»
- «ليش مجاني؟ شو مصلحتكم؟» ← الصدق الكامل، فهو أقوى رد: «مصلحتنا أن ينزّل طلابكم تطبيقنا ويستخدموه بمشاويرهم الخاصة خارج الدوام. أنتم دعايتنا ونحن خدمتكم.» الشفافية هنا تبني الثقة ولا تضرّ.
- «بيانات طلابنا؟» ← «تُستخدم للتحقق فقط، عقد معالجة بيانات موقّع، لا نبيعها ولا نستخدمها إعلانياً، وتُحذف بانتهاء العقد.» (ويجب أن يكون هذا صادقاً وملزماً داخلياً).
- «ما عندنا وقت ولا فريق تقني» ← «لا نطلب أي ربط تقني: ملف إكسل واحد بأرقام الطلاب ويوم واحد مع مدير الحركة لرسم الخطوط. كل شيء علينا.»
- «خلونا نفكر» ← عرض التجربة المصغّرة فوراً: «جرّبوا على ٣ باصات فقط لشهر واحد، بلا أي التزام ولا توقيع طويل — إن لم يحبها الطلاب نسحبها بصمت.»

**العدّة التي نجهزها له:** صفحة تعريفية عربية واحدة، عرض حي على هاتفه فيه باص تجريبي يتحرك فعلاً (أقوى أداة إقناع على الإطلاق — تجهيزه على بيئة تجريبية إلزامي قبل أول زيارة)، نموذج اتفاقية تجربة من صفحتين، نموذج عقد معالجة بيانات، وبعد أول جامعة: دراسة حالة بأرقامها وفيديو شهادة من مدير نقلها.

**مراحل الصفقة التي يُدار بها (تُتابع أسبوعياً):** رصد ← اجتماع أول ← عرض حي ← اتفاقية تجربة ← استيراد الكشف ورسم الخطوط ← تفعيل ← مراجعة نهاية التجربة ← عقد سنوي مجاني موقّع + حق استخدام الشعار.

---

## القسم الثاني عشر: خطة التنفيذ المحدّثة

- **الآن — نهاية يوليو:** تجميد نطاق النسخة الأولى، وبدء `backend/transit/` وقاعدة `siro_transit`، واجتماع الجامعة المصرية (هي التجربة الأولى بحكم أنها طلبت)، وبدء توظيف مسؤول الشراكات الأول.
- **أغسطس:** بناء النسخة الأولى: الكيانات + الخطوط بالمحرر الداخلي + عضوية الطالب بالكشف المستورد + تتبع حي بغرف السوكيت + إشعارات الانطلاق والاقتراب + وضع الباص للسائق + لوحة مشرف بأساسياتها (خريطة اليوم، السائقون، الكشف، إعلان). بيئة العرض الحي للمندوبين تجهز من هذه النسخة نفسها.
- **سبتمبر:** إطلاق فعلي مع الجامعة المصرية أول أيام الفصل، والمندوبون يفتحون الأردن بالجامعات الخاصة على نفس النسخة.
- **الفصل الثاني (فبراير):** التحقق عبر API، محرر الخطوط للمشرفين، تقارير الإشغال، إثبات الصعود، أول مدرسة وأول فندق، وفتح سوريا بالنمط الثاني (ناقل متعاقد + مذكرة جامعة).
- **الصيف القادم:** الفصل الفيزيائي للسيرفر الصغير إن تحقق حده (~٥ مؤسسات فعالة)، ودخول الشركات والمصانع لملء الصيف.

---

## القسم الثالث عشر: جدول المخاطر المحدّث

| الخطر | الاحتمال | التخفيف |
|---|---|---|
| سالك أو سويفل يقلدان العرض المجاني | متوسط | سرعة توقيع عقود حصرية مع بند تجديد تلقائي؛ ميزتنا البنيوية أن خرائطنا مجانية وهم يدفعون عن كل مستخدم |
| مدير النقل يعرقل من الداخل | عالٍ إن أُهمل | العرض يُبنى حوله لا فوقه (القسم الحادي عشر) |
| كشوف طلاب متسربة أو مساء استخدامها | منخفض لكن كارثي | عزل قاعدة transit، تشفير حقل الرقم الجامعي، صلاحيات دنيا، والتزام حرفي بعقد المعالجة |
| سائقون لا يشغّلون التطبيق | متوسط | تقرير الالتزام للمشرف + واجهة الزر الواحد |
| موسمية أكاديمية | مؤكد | المصانع والفنادق تملأ الصيف (مرحلة مخططة أصلاً) |
| تضخم النطاق قبل الإطلاق | عالٍ | قائمة النسخة الأولى مجمّدة: تتبع، جداول، عضوية، إشعارات، لوحة أساسية — لا شيء غيرها |

---

**المصادر:** [شروط خدمة سويفل — ليست ناقلاً ولا تملك مركبات](https://www.swvl.com/terms-of-service)، [سويفل على ويكيبيديا](https://en.wikipedia.org/wiki/Swvl)، [منتج البرمجيات كخدمة من سويفل](https://www.swvl.com/services/software-as-a-service)، [نظرة عامة على أعمال سويفل وتمويل كباتنها](https://www.bitget.com/stock/nasdaq-swvl/what-is)، [تطبيق سالك على غوغل بلاي](https://play.google.com/store/apps/details?id=com.salek.studentapp&hl=en_US)، [موقع سالك](https://salekbus.com/).

هذا التقرير جاهز ليكون وثيقة العمل المرجعية للمشروع. الخطوة العملية التالية بيدك أنت: تجميد نطاق النسخة الأولى والبدء بمجلد `backend/transit/` وقاعدة البيانات — وأنا جاهز أبدأ ببناء المخطط التنفيذي للجداول وهيكل الملفات فور ما تقول ابدأ.