Edit project

Update the project definition, status, priority, and metadata.

Name *

Short description

Full description

اسم المشروع المقترح

Maritime Intelligence & Vessel Operations

نظام ذكي لمراقبة مجموعات WhatsApp البحرية، تنظيم المعلومات المهمة منها، وبناء سجل تشغيلي كامل للسفن بدءًا من VIKINGBANK 12-82، مع Dashboard عربية، أرشيف قابل للبحث، تحليل متعدد الوسائط، وإمكانية العمل Offline للضباط مستقبلًا.

⸻

1. الرؤية العامة للمشروع

أريد بناء منصة بحرية ذكية تعمل باستمرار على البنية التحتية الموجودة لدي على VPS.

المشروع ليس مجرد WhatsApp Bot، وليس مجرد Dashboard، وليس مجرد برنامج لتلخيص الرسائل.

إنه نظام متكامل يتكون من قسمين رئيسيين:

1. Maritime Intelligence
    لمراقبة وتحليل مجموعات WhatsApp البحرية العامة واستخراج المعلومات المهمة منها.
2. Vessel Operations
    لإدارة وتوثيق العمليات التشغيلية الخاصة بالسفن، بدءًا من السفينة VIKINGBANK 12-82.

القسمان يجب أن يكونا منفصلين منطقيًا من ناحية البيانات والوظائف، لكن يمكنهما مشاركة البنية التقنية العامة مثل:

* WhatsApp ingestion.
* Database.
* Media storage.
* AI services.
* Authentication.
* Search.
* Notifications.
* Dashboard infrastructure.

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

⸻

2. أهم مبدأ في المشروع

يجب أن يحتفظ النظام دائمًا بالبيانات الأصلية قبل أي معالجة بالذكاء الاصطناعي.

أي رسالة تصل من WhatsApp يجب ألا تتحول فقط إلى نتيجة AI ثم تضيع الرسالة الأصلية.

نريد الاحتفاظ، حسب ما هو متوفر، بـ:

* Original message.
* WhatsApp Message ID.
* Source group ID.
* Source group name.
* Sender ID / phone / name where available.
* Original WhatsApp timestamp.
* Date received by our system.
* Message type.
* Reply/reference information.
* Attached media information.
* Original media or a durable reference to it.
* Entry method.
* AI analysis.
* AI confidence.
* Final accepted structured data.
* Manual corrections.
* Audit/change history.

هذا مهم جدًا لأنه يسمح مستقبلًا بإعادة تحليل الرسائل القديمة باستخدام AI أفضل بدون فقدان المصدر.

⸻

3. البنية التحتية الموجودة حاليًا

المشروع سيتم تطويره وإدارته من خلال Project OS الموجود بالفعل على Hostinger VPS يعمل بنظام Ubuntu.

Project OS هو أداة التطوير وإدارة تنفيذ المشروع، وليس جزءًا إلزاميًا من المنتج النهائي للمستخدمين.

Project OS يحتوي على:

* AI Planner لإنشاء Roadmap مكونة من Stages وTasks.
* إمكانية تعديل Roadmap بالـAI قبل الموافقة عليها.
* Approve workflow.
* Execute Project.
* Coding Agents مثل OpenCode / Claude Code أو الأدوات المدعومة داخل البيئة.
* VPS قائم بالفعل.
* Docker وخدمات أخرى موجودة في البيئة.
* n8n موجود بالفعل ويمكن إعادة استخدامه.

قبل تثبيت أو إنشاء أي خدمة جديدة يجب فحص البيئة الحالية:

* Docker containers.
* Networks.
* Ports.
* Databases.
* Volumes.
* Reverse proxy.
* Existing services.
* Existing storage.
* Existing n8n instance.
* Existing PostgreSQL or other reusable infrastructure.

يجب تجنب إنشاء خدمات مكررة بدون حاجة.

إذا كانت هناك خدمة موجودة ومناسبة وآمنة، يجب تفضيل إعادة استخدامها.

لكن لا يجب إجبار Architecture على استعمال أداة معينة لمجرد أنها موجودة إذا كان هناك سبب تقني قوي لاختيار حل آخر.

⸻

4. Project OS ليس المنتج النهائي

يجب الفصل بين:

Development platform
Project OS.

و:

Final product
Maritime Intelligence & Vessel Operations.

الضباط وأفراد الطاقم لن يحصلوا على حسابات داخل Project OS.

يجب أن يكون النظام النهائي قادرًا على العمل حتى إذا تم إيقاف Project OS مستقبلًا.

Project OS يُستخدم لإنشاء، تطوير، إصلاح وتحديث المشروع فقط.

⸻

5. القسم الأول: WhatsApp Maritime Intelligence

لدي عدد من مجموعات WhatsApp البحرية التي تحتوي على حجم كبير من الرسائل اليومية.

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

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

⸻

6. WhatsApp Connection / Ingestion

يجب توفير طريقة موثوقة لاستقبال الرسائل من مجموعات WhatsApp التي يكون الحساب المصرح به عضوًا فيها.

الحل المفضل حاليًا للـMVP هو استخدام:

Evolution API باستخدام WhatsApp Web / Baileys

مع التكامل مع n8n عند الحاجة.

لكن يجب التعامل مع WhatsApp Provider من خلال طبقة abstraction مناسبة حتى يكون من الممكن مستقبلًا تغيير Provider أو استخدام API رسمي بدون إعادة تصميم النظام بالكامل.

Evolution API هو مكوّن Infrastructure فقط وليس المشروع نفسه.

يجب ألا تتحول Roadmap بالكامل إلى مشروع Evolution API.

⸻

7. متطلبات WhatsApp Bridge

في المرحلة الأولى يجب أن يكون النظام قادرًا على:

* ربط حساب WhatsApp من خلال QR / Linked Device.
* معرفة حالة الاتصال.
* اكتشاف المجموعات المتاحة للحساب.
* السماح لي باختيار/Allowlist المجموعات المراد مراقبتها.
* استقبال الرسائل الجديدة Real Time.
* استقبال Metadata.
* معرفة اسم/معرف المجموعة.
* معرفة المرسل عندما يكون متاحًا.
* معرفة Message ID.
* الاحتفاظ بالـTimestamp الأصلي.
* معرفة نوع الرسالة.
* معرفة الرسائل التي هي Reply على رسالة أخرى.
* التعامل مع Text.
* Images.
* PDFs/documents.
* Voice notes.
* Audio.
* Video.
* GIFs.
* Stickers.
* Emojis.
* Captions.
* Media references.

يجب منع إدخال نفس الرسالة مرتين.

يجب استخدام Message ID أو Idempotency mechanism مناسب.

يجب اختبار:

* Connection loss.
* Reconnect.
* VPS restart.
* Docker restart.
* Service restart.
* Duplicate webhook deliveries.
* Retry failures.

يجب توفير monitoring واضح لحالة اتصال WhatsApp.

لا يجب الاعتماد بشكل أعمى على Docker tag مثل latest.

يجب Pin واختبار إصدار معروف يعمل جيدًا.

يجب تأمين API وWebhooks وعدم نشر Management API للعامة بدون Authentication وحماية مناسبة.

⸻

8. دور n8n

n8n موجود بالفعل في البيئة.

يمكن استخدامه في:

* استقبال Webhooks.
* Routing.
* Triggering workflows.
* Calling OCR.
* Calling transcription services.
* Calling AI services.
* Notifications.
* Basic workflow orchestration.

لكن لا أريد تحويل n8n إلى مكان يحتوي على كل Business Logic الخاص بالنظام.

Business rules الأساسية، Data model، رحلة السفينة، عمليات التفريغ، validation، audit وغيرها يجب أن تكون داخل التطبيق/Backend المناسب.

يجب أن تبقى Workflows في n8n مفهومة وقابلة للصيانة.

⸻

9. معالجة الرسائل البحرية العامة

النظام لا يجب أن يقوم فقط بتلخيص كل رسالة بشكل منفصل.

يجب أن يفهم:

* Context.
* Conversation threads.
* Replies.
* Related media.
* Messages sent before and after a media item.
* Multiple posts discussing the same event.

إذا تم نشر صورة أو فيديو ثم جاءت عدة رسائل تشرح ما حدث، يجب أن يستطيع النظام ربطها في Event واحد بدل إنشاء عشر نتائج منفصلة.

⸻

10. تصنيف الأهمية

يجب أن يستطيع النظام تصنيف المعلومات إلى مستويات مثل:

Important

معلومات تستحق التنبيه أو العرض البارز.

Useful to know

معلومة ليست عاجلة لكنها تستحق الحفظ في التقرير أو الأرشيف.

Irrelevant

محتوى لا يحتاج إلى إزعاج المستخدم به.

إذا لم يكن AI متأكدًا، يجب أن يكون هناك نظام Human Feedback.

مثال:

يسأل المستخدم:

“هل تريد اعتبار هذا النوع من الرسائل مهمًا مستقبلًا؟”

ثم يمكن حفظ هذا التصحيح Preference/Rule واستخدامه لاحقًا.

لا يجب أن يكون هذا التعلم Black Box غير قابل للمراجعة.

⸻

11. المعلومات البحرية المهمة

النظام يجب أن يدعم تدريجيًا التعرف على:

* Weather information.
* Marine weather bulletins.
* Weather maps/images.
* Weather PDFs.
* Maritime incidents.
* Accidents.
* Vessel incidents.
* Port information.
* Operational warnings.
* Navigation information.
* Administrative notices.
* Fishing-related information.
* Maritime regulatory information.
* Relevant professional discussions.
* Job offers.
* Announcements.
* Documents.

⸻

12. الطقس

الطقس من المعلومات المهمة بالنسبة للمستخدم.

قد يصل الطقس في:

* Text.
* Image.
* Screenshot.
* PDF.
* Document.
* Voice message.

يجب استخراج المعلومات المهمة منه وعرض المصدر الأصلي.

يجب ألا يتم اعتبار معلومات غير مؤكدة كأنها Forecast رسمي.

يجب عرض Source/Confidence بشكل مناسب.

⸻

13. عروض العمل البحرية

تصل أحيانًا عروض عمل كثيرة داخل المجموعات البحرية.

يجب أن يستطيع AI فهم:

* Company.
* Vessel/company type if available.
* Role.
* Rank.
* Specialty.
* Required certificates.
* Required experience.
* Location.
* Contact.
* Deadline.
* Attached document.
* Link.
* Language.
* Other requirements.

ثم يصنفها مثلًا إلى:

* مناسبة للمستخدم مباشرة.
* غير مناسبة مباشرة لكنها مفيدة مهنيًا.
* غير مهمة.

يجب أن يكون Profile المستخدم المهني قابلًا للتعديل وليس hard-coded داخل AI prompts.

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

⸻

14. اللغة

المصادر قد تكون:

* Arabic.
* Moroccan Arabic.
* French.
* Spanish.
* English.
* خليط بين اللغات.

يجب أن يحتفظ النظام بالنص الأصلي.

لكن Dashboard والتقارير الموجهة للمستخدم يجب أن تدعم العربية بشكل ممتاز مع RTL.

يمكن إظهار النص الأصلي والترجمة/الشرح حسب الحاجة.

⸻

15. Greetings / Eid / Ramadan / Condolences

المجموعات تحتوي أحيانًا على عدد كبير من:

* Eid greetings.
* Ramadan greetings.
* Congratulations.
* Condolences.
* Repetitive replies.
* Emojis.
* Stickers.
* GIFs.

لا أريد أن يظهر التقرير مثل:

“فلان قال عيد مبارك”
“فلان قال عيد مبارك”
“فلان قال عيد مبارك”

عشرين مرة.

النظام يجب أن يفهم أن هذه الرسائل جزء من Event اجتماعي واحد.

مثال:

Eid Greeting

Original sender: X

Participants/responders:

* A
* B
* C
* D

نفس الشيء بالنسبة للتعازي.

⸻

16. التعازي

بالنسبة للتعازي، الرسالة الأولى مهمة.

يجب محاولة استخراج:

* من توفي.
* علاقته بالشخص إن أمكن.
* من نشر الخبر.
* تاريخ/وقت.
* أي معلومات مهمة.

ثم الردود مثل:

* الله يرحمه.
* تعازينا.
* البقاء لله.
* Emojis/stickers.

يتم تجميعها كمشاركين في التعزية بدل إغراق التقرير بالرسائل المتكررة.

إذا لم يكن النظام متأكدًا من هوية المتوفى أو العلاقة، يجب عدم اختراعها.

⸻

17. الحوادث والفيديو

مثال:

شخص ينشر Video بدون شرح.

ثم شخص يكتب:

“هذا وقع اليوم قرب الميناء.”

ثم شخص آخر يذكر اسم السفينة.

ثم شخص آخر يصحح المكان.

يجب ألا يعالج AI هذه الأشياء كأربع معلومات مستقلة.

يجب أن يحاول بناء:

Incident record

مع:

* Related messages.
* Video.
* Images.
* Participants.
* Event description.
* Vessel if known.
* Location if known.
* Timestamp.
* Confidence.
* Conflicting claims.
* Source links/references.

ويجب الاحتفاظ بمرجع يسمح للمستخدم بالرجوع إلى المحتوى الأصلي.

⸻

18. التعامل مع الشائعات والمعلومات غير المؤكدة

مجموعات WhatsApp ليست مصدرًا رسميًا دائمًا.

النظام يجب أن يميز بين:

* Reported in group.
* Claimed.
* Confirmed by multiple sources.
* Official source.
* Uncertain.

لا يجب تحويل رسالة WhatsApp إلى حقيقة مؤكدة فقط لأن AI فهم معناها.

⸻

19. القسم الثاني: Vessel Operations

القسم الثاني هو سجل العمليات التشغيلية الخاص بالسفن.

نبدأ بالسفينة:

VIKINGBANK 12-82
IMO: 7713008

لكن Architecture يجب ألا تكون hard-coded لسفينة واحدة.

يجب دعم Multiple Vessels مستقبلًا.

⸻

20. مصادر بيانات Vessel Operations

قد تأتي البيانات من:

* WhatsApp operational group.
* Multiple WhatsApp groups.
* Manual web entry.
* Phone entry.
* Future Windows officer application.
* Documents.
* Images.
* PDFs.
* Other approved integrations.

مثال:

Group A:
Departure / Arrival.

Group B:
Discharge / trucks.

Group C:
Management discussions.

يجب دمج المعلومات المتعلقة بنفس Voyage داخل سجل واحد.

⸻

21. Voyage lifecycle

يجب دعم نموذج Voyage واضح.

الأحداث الأساسية:

* Voyage created.
* Departure.
* Arrival.
* Actual port entry.
* Planned discharge time.
* Actual discharge start.
* Actual discharge end.
* Voyage closed.

مهم جدًا:

يجب عدم الخلط بين:

Planned discharge time

و:

Actual port entry time

و:

Actual discharge start time

هذه أحداث مختلفة ويجب أن تملك Fields/Timestamps مختلفة.

⸻

22. فهم الوقت من رسائل WhatsApp

قد تصل رسالة:

“sortie 18h30”

بدون تاريخ.

النظام لا يجب أن يخترع التاريخ.

يجب استخدام WhatsApp message timestamp لتحديد التاريخ المناسب.

مثال:

Message timestamp:
14/09/2026 17:10

Text:
“sortie 18h30”

Structured event:

Date:
14/09/2026

Departure time:
18:30

مع الاحتفاظ بالمصدر والثقة.

إذا كان هناك ambiguity حقيقي يجب وضعه للمراجعة بدل اعتماد معلومة خاطئة.

⸻

23. الربان / Captain

قد يعمل أكثر من ربان على السفينة بالتناوب.

يجب تسجيل Captain المسؤول عن Voyage عندما تكون المعلومة معروفة.

إذا لم تكن معروفة:

* Do not invent it.
* Allow manual assignment/correction.

⸻

24. عمليات التفريغ

النظام يجب أن يدعم Discharge Operations بشكل منظم.

لكل عملية تفريغ:

* Vessel.
* Voyage.
* Port.
* Planned discharge.
* Actual start.
* Actual end.
* Total quantity.
* Number of trucks/loads.
* Species.
* Quality metrics.
* Temperature metrics.
* Notes.
* Documents.
* Related WhatsApp messages.

⸻

25. الشاحنات / Loads

لكل شاحنة أو Load يجب أن يكون من الممكن تسجيل:

* Sequence number.
* Truck identifier if available.
* Quantity.
* Unit.
* Species.
* Temperature.
* Quality.
* Loading timestamp.
* Handover timestamp.
* Departure timestamp.
* Notes.
* Source message.
* Attachments.
* Manual corrections.

⸻

26. المؤشرات والحسابات

يجب أن يقوم Backend بالحسابات الدقيقة وليس AI.

مثل:

* Total discharged quantity.
* Number of trucks.
* Average temperature.
* Min/max temperature.
* Voyage duration.
* Discharge duration.
* Average load.
* Quality distribution.
* Species totals.

AI يمكنه تفسير البيانات وكتابة Summary، لكن الحسابات الرقمية الرسمية يجب أن تأتي من البيانات المهيكلة وBusiness Logic.

⸻

27. المناقشات التشغيلية

قد يكتب مسؤول:

“لماذا الجودة ضعيفة؟”

أو:

“لماذا الحرارة مرتفعة؟”

ثم يجيب الربان أو شخص آخر.

يجب أن يستطيع النظام فهم أن هذا:

Operational Question / Management Discussion

وربطه بـ:

* Voyage.
* Discharge.
* Truck/load إذا كان ذلك واضحًا.

ويحفظ:

* Question.
* Asked by.
* Timestamp.
* Answer.
* Answered by.
* Timestamp.
* Related context.
* Source messages.

⸻

28. الفصل بين Maritime Intelligence وVessel Operations

هذه قاعدة مهمة جدًا.

إذا وصلت رسالة عن سفينة أخرى أو موضوع بحري عام، يجب ألا تدخل تلقائيًا في VIKINGBANK Operations.

VIKINGBANK Operations يجب أن تستقبل فقط المعلومات المرتبطة بالسفينة والرحلات والعمليات الخاصة بها.

Maritime Intelligence له أرشيفه وتصنيفاته الخاصة.

⸻

29. قاعدة البيانات

يجب أن تكون هناك Central Source of Truth.

يفضل استخدام PostgreSQL إذا كان مناسبًا للبنية الحالية.

لكن على Coding Agent/Planner أن يفحص البيئة الموجودة أولًا.

يجب تصميم Data Model قابل للتوسع.

Entities المتوقعة قد تشمل، حسب Architecture النهائية:

* Users.
* People.
* Sources.
* WhatsApp accounts.
* WhatsApp groups.
* WhatsApp messages.
* Media.
* AI analyses.
* Classification.
* Vessels.
* Voyages.
* Operational events.
* Discharges.
* Loads/trucks.
* Temperatures.
* Quality records.
* Species.
* Discussions.
* Incidents.
* Jobs.
* Weather records.
* Documents.
* Alerts.
* Corrections.
* Audit logs.

هذه القائمة ليست إلزامًا حرفيًا لعدد الجداول؛ المطلوب تصميم نظيف ومرن.

⸻

30. Provenance

أي معلومة مهمة يجب أن نعرف:

“من أين جاءت؟”

مثال:

Departure = 18:30

يجب أن نستطيع الضغط عليها أو فتح تفاصيلها ونرى:

* Original WhatsApp message.
* Sender.
* Group.
* Timestamp.
* AI extraction.
* Confidence.
* Manual correction if any.

هذا ضروري جدًا.

⸻

31. AI Processing

الذكاء الاصطناعي يجب أن يحول Unstructured content إلى Structured information.

مثال رسالة:

“Viking Bank décharge 20h première camion 28.7 tonnes température 2.1 sardine qualité A”

يمكن أن ينتج AI شيئًا مثل:

event_type:
truck_discharge

vessel:
VIKINGBANK

truck_sequence:
1

quantity:
28.7

unit:
tonnes

temperature:
2.1

species:
sardine

quality:
A

confidence:
…

لكن هذه النتيجة لا تصبح حقيقة نهائية بدون Validation مناسب.

⸻

32. AI Confidence

أي Extraction مهم يجب أن يدعم Confidence أو Validation status مناسب.

مثل:

* High confidence.
* Needs review.
* Corrected.
* Confirmed.

Low-confidence items يجب أن تظهر للمراجعة بدل أن تختفي أو تعتمد سرًا.

⸻

33. Manual correction

المستخدم يجب أن يستطيع تصحيح AI.

مثال:

AI:
Arrival 18:30.

User:
هذا Departure وليس Arrival.

يجب:

* الاحتفاظ بالنتيجة القديمة في Audit.
* اعتماد القيمة المصححة.
* إمكانية استخدام التصحيح لتحسين النظام مستقبلًا.

⸻

34. Dashboard

يجب بناء Web Dashboard عربية RTL.

يجب أن تكون Responsive وتعمل من:

* Desktop browser.
* Laptop.
* Tablet.
* Mobile browser.

لا نحتاج تطبيق Mobile native للـMVP.

⸻

35. Dashboard V1

Dashboard الأولى لا تحتاج إلى أن تحتوي كل شيء.

الأولوية:

Current Voyage

* Vessel.
* Captain.
* Departure.
* Arrival.
* Port entry.
* Planned discharge.
* Discharge status.

Operational Timeline

قائمة زمنية للأحداث.

Recent Messages

عرض الرسائل التشغيلية المرتبطة.

Sources

إظهار مصدر كل حدث.

Attachments

إظهار المرفقات المتاحة.

Previous Voyages

الوصول إلى الرحلات السابقة.

Search/filter

على الأقل حسب:

* Vessel.
* Voyage.
* Date.
* Event type.

⸻

36. Dashboard المتقدمة لاحقًا

بعد توسع النظام يمكن إضافة:

* Total discharge.
* Trucks.
* Quantity charts.
* Temperature charts.
* Quality distribution.
* Species.
* Alerts.
* Maritime intelligence feed.
* Job offers.
* Weather.
* Incident list.
* Reports.

⸻

37. الأرشيف والبحث

النظام يجب أن يصبح بمرور الوقت Historical Archive.

يجب دعم البحث مستقبلًا مثل:

* ماذا حدث في رحلة X؟
* متى دخلت السفينة؟
* كم كانت كمية التفريغ؟
* ما أعلى حرارة؟
* من سأل عن الجودة؟
* اعرض رسائل يوم معين.
* اعرض Incident معين.
* اعرض كل عروض العمل الخاصة بالربابنة.
* اعرض نشرات الطقس.
* ابحث باسم سفينة.
* ابحث باسم شخص.
* ابحث داخل الوثائق.

⸻

38. Multi-modal processing

المشروع يجب أن يتوسع تدريجيًا لمعالجة:

Images

Vision/OCR.

PDFs

Text extraction/OCR where needed.

Voice notes

Speech-to-text ثم semantic analysis.

Audio

Transcription.

Video

Metadata + selected analysis حسب الإمكانيات والتكلفة.

Stickers/GIFs/emojis

Contextual interpretation عندما تكون مفيدة، خصوصًا للتهاني والتعازي والردود.

⸻

39. عدم البدء بكل Multimodal مرة واحدة

لا يجب أن يؤخر Video understanding أو التحليل المتقدم إطلاق الـMVP.

ابدأ بالأجزاء التي تعطينا قيمة بسرعة.

ثم أضف Multimodal تدريجيًا.

⸻

40. التقارير

النظام يجب أن يدعم تقارير عربية.

أمثلة:

Voyage Report

* Departure.
* Arrival.
* Duration.
* Discharge.
* Total quantity.
* Trucks.
* Temperature.
* Quality.
* Important discussions.
* Documents.

Daily Maritime Intelligence Report

* Important.
* Useful to know.
* Weather.
* Incidents.
* Jobs.
* Other notable information.

Periodic Report

Daily / weekly / custom range.

⸻

41. التنبيهات

التنبيهات تأتي بعد أن يعمل الأساس.

أمثلة:

* Important maritime incident.
* Dangerous weather information.
* Relevant job offer.
* Operational anomaly.
* High temperature.
* Missing critical voyage data.

يجب تجنب excessive notifications.

⸻

42. برنامج الضباط Windows — مرحلة لاحقة

لا أريد أن يؤخر هذا البرنامج الـMVP.

لكن Architecture يجب أن تسمح به.

مستقبلًا أريد تطبيق Windows خاصًا بضباط السفينة.

الضباط لن يستخدموا Project OS.

التطبيق يجب أن يسمح لهم بـ:

* View operational data.
* Search.
* Manual data entry.
* View voyages.
* View discharge information.
* Work offline.

⸻

43. Offline-first

السفينة قد تعمل لفترات بدون Internet.

لذلك Windows application يجب أن يستطيع استخدام Local Database.

يمكن استخدام SQLite إذا كان مناسبًا أو حل أفضل تقترحه Architecture.

عند عودة الإنترنت:

Local DB
↔
Central Server

يجب أن تتم المزامنة بصورة آمنة.

⸻

44. Conflict resolution

إذا تم تعديل نفس السجل:

* على السفينة Offline.
* وعلى Central server.

يجب أن يكون هناك Strategy واضحة لحل التعارضات.

لا يجب فقدان التعديلات بصمت.

⸻

45. Backup / Restore

برنامج السفينة يجب مستقبلًا دعم:

* Backup Vessel Data.
* Restore Vessel Data.
* Transfer to another PC.
* Recovery after computer failure.

⸻

46. Data portability

لا أريد أن تكون البيانات محتجزة داخل برنامج مغلق.

يجب دعم التصدير حسب الحاجة إلى:

* CSV.
* Excel.
* PDF.
* Other open/usable formats.

⸻

47. حالة ترك السفينة مستقبلًا

هذا Requirement أساسي طويل المدى.

قد يتوقف المستخدم مستقبلًا عن العمل مع VIKINGBANK.

في هذه الحالة:

1. يحتفظ المستخدم بنسخته التاريخية من البيانات حتى تاريخ ترك السفينة.
2. تحصل السفينة على نسخة كاملة من بياناتها التشغيلية.
3. يمكن إيقاف Synchronization بينها وبين Central server الخاص بالمستخدم.
4. يستطيع الطاقم مواصلة استخدام النسخة المحلية بصورة مستقلة.
5. يمكن نقل البرنامج والبيانات إلى حاسوب آخر.
6. يستطيع المستخدم بعد ذلك إضافة سفينة جديدة إلى النظام بدون إعادة بناء المشروع من الصفر.

لذلك يجب أن تكون البيانات قابلة للفصل حسب Vessel/Tenant أو أي Architecture مناسبة.

⸻

48. Security

يجب تطبيق Security مناسبة بدون overengineering.

تشمل حسب الحاجة:

* Authentication.
* Authorization.
* Secure secrets management.
* Webhook authentication.
* API authentication.
* Network restrictions.
* HTTPS.
* Secure storage.
* Audit logs.
* Least privilege.

لا يجب وضع Tokens/Passwords داخل Source code.

⸻

49. Privacy

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

يجب أن يكون هناك Group Allowlist.

لا يجب تحليل مجموعات غير محددة بدون قصد.

⸻

50. Media storage

يجب فحص التخزين الموجود على VPS أولًا.

لا تفترض تلقائيًا أننا نحتاج S3 خارجيًا.

يمكن استخدام:

* VPS storage.
* Existing volumes.
* Object storage.
* MinIO.
* S3-compatible storage.

حسب الحاجة الفعلية.

يجب فصل Metadata عن file storage بطريقة منظمة.

⸻

51. Reliability

النظام يجب أن يتحمل المشاكل الواقعية مثل:

* WhatsApp disconnect.
* Webhook retry.
* n8n failure.
* AI timeout.
* Database temporary failure.
* Service restart.
* VPS reboot.
* Duplicate delivery.

يجب ألا تضيع الرسائل بصمت.

يفضل وجود:

* Retry.
* Error log.
* Failed item queue / dead-letter mechanism where appropriate.
* Monitoring.
* Health checks.

⸻

52. Observability

يجب أن نستطيع معرفة:

* هل WhatsApp متصل؟
* آخر رسالة استقبلناها متى؟
* كم رسالة دخلت؟
* كم رسالة فشلت؟
* هل n8n يعمل؟
* هل AI processing يعمل؟
* هل هناك queue متراكمة؟
* هل Database تعمل؟

هذه المعلومات مهمة للتشغيل.

⸻

53. Performance

لا نعرف حتى الآن الحجم الحقيقي النهائي للرسائل.

لا تبن Architecture ضخمة بناءً على رقم افتراضي.

ابدأ بتصميم عملي وقابل للتوسع، مع Metrics.

ثم نقيس الحجم الحقيقي ونوسع عند الحاجة.

⸻

54. No unnecessary microservices

لا أريد Architecture معقدة لمجرد أنها “Enterprise”.

إذا كان Modular Monolith أو عدد قليل من الخدمات يكفي، استخدمه.

يجب أن يكون:

* Maintainable.
* Understandable.
* Reliable.
* Extensible.

⸻

55. Hermes

Hermes يمكن استخدامه مستقبلًا كAssistant.

مثل:

“ما أعلى درجة حرارة في آخر 10 رحلات؟”

أو:

“اعطني ملخص الرحلة السابقة.”

لكن Hermes ليس جزءًا إلزاميًا من Core system.

إذا توقف Hermes، يجب أن يبقى النظام الأساسي يعمل.

⸻

56. الأولوية القصوى: قيمة عملية هذا الموسم

لا أريد الانتظار حتى اكتمال المشروع بالكامل لكي أبدأ استخدامه.

يجب أن تبنى Roadmap بحيث تعطينا Partial Usable Product بسرعة.

أول إنجاز عملي مهم:

رسالة حقيقية من WhatsApp group
→ تدخل النظام
→ تحفظ Raw
→ نعرف Group/Sender/Timestamp/Message ID
→ يمكن الرجوع إليها.

ثم بسرعة بعدها:

رسالة تشغيلية حقيقية مرتبطة بـVIKINGBANK
→ يفهمها النظام
→ يحولها إلى Operational Event
→ يربطها بالرسالة الأصلية
→ تظهر في Dashboard.

⸻

57. ترتيب الأولويات المطلوب من AI Planner

يجب أن يقترح AI Planner Roadmap منطقية، لكن الأولويات الأساسية يجب أن تكون كما يلي:

Priority 1

WhatsApp Foundation.

Priority 2

VIKINGBANK Operations V1.

Priority 3

Dashboard V1.

عند اكتمال هذه النقاط الثلاث يجب أن يكون لدينا First Usable MVP.

ثم:

Priority 4

Discharge Operations.

Priority 5

Maritime Intelligence.

Priority 6

Advanced Multimodal Processing.

Priority 7

Reports / Alerts / Feedback / Search enhancements.

Priority 8

Windows Offline / Sync / Backup / Vessel handover.

يمكن للـPlanner تقسيمها إلى عدد مراحل مختلف إذا كان هناك سبب تقني منطقي، لكن لا يجب أن يؤخر Vessel Operations إلى نهاية المشروع.

⸻

58. Phase 1 المتوقع — WhatsApp Foundation

هذه المرحلة يجب أن تشمل ما يلزم للوصول إلى End-to-End working ingestion.

مثل:

* Inspect VPS.
* Inspect existing n8n.
* Check Docker environment.
* Deploy/configure WhatsApp bridge.
* Secure it.
* QR connection.
* Group discovery.
* Group allowlist.
* Real-time messages.
* Raw event preservation.
* Media handling foundation.
* Message deduplication.
* Delivery into n8n/backend pipeline.
* Reconnect/restart testing.
* Basic monitoring.

Completion criterion:

إرسال رسالة حقيقية داخل مجموعة اختبار مصرح بها، ثم رؤية:

* Group.
* Sender.
* Message.
* Timestamp.
* Message ID.
* Media metadata if present.

داخل النظام بصورة صحيحة.

⸻

59. Phase 2 المتوقع — VIKINGBANK Operations V1

يجب إنشاء الأساس التشغيلي للسفينة.

يتضمن على الأقل:

* Vessel record.
* Voyage model.
* Departure.
* Arrival.
* Planned discharge.
* Actual port entry.
* Actual discharge start.
* Captain where known.
* Operational event extraction.
* Manual correction.
* Provenance.

Completion criterion:

رسالة حقيقية مثل:

“sortie 18h30”

تتحول بصورة صحيحة إلى:

Vessel:
VIKINGBANK 12-82

Event:
Departure

Date:
derived from original message timestamp

Time:
18:30

Source:
original WhatsApp message.

⸻

60. Phase 3 المتوقع — Dashboard V1

Arabic RTL Responsive Web Dashboard.

يعرض على الأقل:

* Current Voyage.
* Operational timeline.
* Voyage events.
* Source messages.
* Attachments.
* Previous voyages.
* Basic search/filter.
* Data review/correction where appropriate.

عند نهاية هذه المرحلة يجب اعتبار النظام:

FIRST USABLE MVP

ولا يجب انتظار Maritime Intelligence المتقدم أو Windows application لكي نبدأ الاستخدام الحقيقي.

⸻

61. Phase 4 المتوقع — Discharge Operations

بعد عمل MVP:

* Trucks/loads.
* Quantities.
* Temperature.
* Species.
* Quality.
* Times.
* Totals.
* Calculations.
* Operational discussions.
* Related media/documents.

⸻

62. Phase 5 المتوقع — Maritime Intelligence

بعد تثبيت الأساس التشغيلي:

* Important / Useful / Irrelevant.
* Weather.
* Incidents.
* Jobs.
* Notices.
* Greetings.
* Condolences.
* Grouped replies.
* General maritime archive.

⸻

63. Phase 6 المتوقع — Multimodal

* OCR.
* PDF parsing.
* Voice transcription.
* Audio.
* Video.
* Stickers/GIF context.
* Multi-message correlation.
* Incident/event clustering.

⸻

64. Phase 7 المتوقع — Intelligence & Reporting

* Advanced search.
* Reports.
* Alerts.
* Human feedback.
* Correction workflows.
* Confidence.
* Long-term archive.
* Better classification.

⸻

65. Phase 8 المتوقع — Officer Offline Application

* Windows application.
* Local database.
* Offline data entry.
* Sync.
* Conflicts.
* Backup.
* Restore.
* Export.
* Transfer to another PC.
* Vessel handover.

⸻

66. ما لا يجب فعله في Roadmap

لا تجعل:

* Evolution API هو المشروع كله.
* WhatsApp integration يستحوذ على خمس مراحل ويؤجل المنتج.
* Job offers شرطًا لإطلاق الـMVP.
* Windows Offline شرطًا لإطلاق الـMVP.
* Advanced video AI شرطًا للإطلاق.
* AIS شرطًا للمشروع.
* Microservices شرطًا بدون حاجة.
* S3 شرطًا بدون فحص التخزين الحالي.
* Hermes Core dependency.
* Project OS جزءًا من تطبيق الضباط.

⸻

67. AIS

AIS ليس Requirement للـMVP.

يمكن اعتباره Future optional enhancement فقط إذا أصبح هناك Use Case واضح.

لا تجعل AIS Dependency لأي مرحلة أساسية.

⸻

68. Outbound WhatsApp messages

الـMVP في البداية Read-oriented.

الأولوية هي:

Receive → Store → Understand → Organize → Display.

لا نحتاج Automatic outbound WhatsApp messaging كشرط للنسخة الأولى.

إذا أضفناه مستقبلًا يجب تصميمه بحذر.

⸻

69. اختبار كل مرحلة

كل Stage يجب أن تحتوي Acceptance/Validation Tasks.

لا تعتبر المهمة منتهية فقط لأن الكود كُتب.

أمثلة:

WhatsApp:
اختبار رسالة حقيقية.

Restart:
إعادة تشغيل Container واختبار reconnect.

Deduplication:
إرسال/إعادة webhook والتأكد من عدم تكرار الرسالة.

Voyage:
اختبار رسائل Departure/Arrival حقيقية.

Dashboard:
التأكد أن البيانات المعروضة مطابقة للمصدر.

⸻

70. Seed/Test Data

يمكن استخدام Test data أثناء التطوير، لكن يجب ألا تختلط مع Production data.

يفضل وجود آلية واضحة للتمييز أو بيئة Test مناسبة.

⸻

71. الهدف النهائي

النتيجة النهائية التي أريد الوصول إليها هي أن أستطيع فتح النظام وأرى:

Operations

كل ما يتعلق بالسفينة والرحلات والتفريغ والجودة والحرارة.

Maritime Intelligence

المعلومات المهمة المستخرجة من مجموعات WhatsApp.