Edit task

## Task
6.5 Implement AI extraction into Dynamic Modules

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

Current phase: Phase 6: Advanced Multimodal Intelligence & Custom Workflows

Project context: Vessel & network monitor by AI — Maritime Intelligence & Vessel Operations

## Project requirements (authoritative)
The full project description below is the authoritative requirement source. Concrete values it specifies (site URLs, names, labels, texts) are part of the deliverable — never substitute placeholder or example values (e.g. example.com) for them.
اسم المشروع المقترح

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 قائم بالفعل.
* Doc

## Reference attachments requirement
The project requirements reference attached material, but NO attachment is uploaded to this project. Do not invent a reference: if the deliverable needs one, state the missing reference explicitly instead of guessing.

## Deliverable quality baseline (applies to user-facing output)
If this task produces or changes anything the user sees in a browser, the result must look deliberately crafted — never scaffold-like or raw default markup:
- Clear visual hierarchy: a real page structure with headings, grouping and whitespace — not a bare dump of unstyled elements.
- Deliberate typography and spacing: readable font sizes and line-height, consistent padding/margins; interactive controls (buttons, inputs, links) must be visibly styled, never browser-default only.
- A coherent, restrained color palette (background, text, accent) with accessible contrast.
- Responsive layout: the page must stay usable on a narrow (mobile) viewport.
- Interactions must genuinely work: every control the description asks for performs the requested behavior, and purely local behavior (e.g. a confirmation/status message on click) is implemented client-side — no external service is needed for simple local feedback.
- Accessibility basics: semantic HTML, labels for inputs, alt text for images.
- Status/progress/success/error banners must set BOTH an explicit opaque background and an explicit foreground color that keep high contrast against each other in every state — never a translucent background, never inherited or white text over a light surface, and the text must stay readable when the browser applies its own dark/forced rendering.
- Arabic/RTL correctness: the document must set lang="ar" and dir="rtl", declare UTF-8 charset, and use natural Arabic wording and typography (no machine-stiff phrasing, no reversed or Latin-mixed layout artifacts).
This is a minimum quality floor, not a template: keep full creative freedom in design, layout and copy.

## Native automation (use this instead of building your own backend)
Native automation available for this project (Project OS platform capability).
A managed backend automation of kind 'site.check' is already provisioned for this project.
Use it from the browser via these SAME-ORIGIN endpoints (fetch, JSON):
- POST /api/app/automations/<automationId>/run  body: {"sites":[{"url":"https://…","label":"…"}]}
  → 200 {runId} | 400 {error} | 404 {error} | 429 {error}. Sites: 1..20, https public hostnames only.
- GET /api/app/automations/runs/<runId>  → {status, error?, result?}
  status: PENDING | RUNNING | SUCCEEDED | FAILED; result = {kind:'site.check', summary, results:[{url,label?,ok,statusCode?,latencyMs?,error?}]}.
Poll the run endpoint every ~2s while status is PENDING/RUNNING (timeout ~120s), then render per-site results.
STRICT RULES:
- Check EXACTLY the target sites the project's requirements define. Never substitute invented placeholder or example domains (e.g. example.com) for the project's real targets.
- NEVER render or build fields for webhook URLs, callback URLs, tokens, credentials, run ids of the platform, or any n8n concept. The end user must never see infrastructure.
- NEVER POST to any other host from the app; the automation is invoked exclusively through the run endpoint above.
- While a run is RUNNING show a friendly 'checking…' state; on FAILED show the run's error string and per-site results if present. Never fake results.
- The <automationId> above is a stable id for this project's automation; store it as a constant, not as user input.

Acceptance criteria:
- Implement the task: 6.5 Implement AI extraction into Dynamic Modules
- Cover the task description above.
- Keep the change scoped to what this task needs.
- Do not introduce secrets or credentials in code.
- Leave the repository in a consistent state (no stray debug output).
- User-facing output must satisfy the deliverable quality baseline above (deliberate styling, responsive layout, working interactions).
- The deliverable must be a correct Arabic RTL document (lang="ar", dir="rtl", UTF-8) with polished Arabic content.