# تنفيذ ربط الصيانة بالتقويم

تاريخ التحديث: 25 أكتوبر 2026.

## النتيجة

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

افتح [دليل الآلية مباشرة](https://martechhub.net/screen/calendar-web/?calendarGuide=1)، أو [التقويم](https://martechhub.net/screen/calendar-web/) واضغط «كيف يعمل التقويم؟». طلب الصيانة متاح من [صفحة الصيانة](https://martechhub.net/screen/maintenance-request/). شرح الشاشة موجود أيضًا في [دليل الإدارة](index.html#screen-S2.3).

## دليل واضح ومثال قابل للمراجعة

يوجد بانر أعلى لوحة التشغيل وزر «كيف يعمل التقويم؟». الدليل ست مراحل: قراءة التقويم، فحص الحجز، تسجيل أثر الصيانة، القرار لكل حجز، التنبيهات، واعتماد الجاهزية. كل مرحلة توضح ما حدث، والقرار المطلوب، وأثره على التقويم. الانتقال بين المراحل لا ينفذ إجراءً.

«جرّب المثال خطوة بخطوة» يفتح مثالًا من سبع حالات فعلية تبدأ قبل العطل وتنتهي باعتماد الجاهزية. يستخدم المثال نفس منطق الحجب والقرار والنقل، لكن بياناته في الذاكرة فقط. لا يغير الحجوزات أو البلاغات المحفوظة في الجلسة. يمكن إعادة المثال من البداية دون المساس بسجل التشغيل.

زر «افتح القسم للتطبيق» ينقل المستخدم إلى قسم التشغيل الفعلي داخل جلسته. زرا «نسخ ملخص الآلية» و«تنزيل ملخص TXT» يجهزان النص للمشاركة. عند رفض إذن الحافظة يظهر النص للنسخ اليدوي. [الملخص النصي المباشر](calendar-mechanism.txt) متاح أيضًا.

## مسار تجربة سريع

1. افتح «الصيانة والقرارات»، ثم اكتب وصف العطل وسبب التقييم. الوحدة الافتراضية مراسي 204.
2. اترك بداية التأثير في 25 أكتوبر 2026 الساعة 10:00 والنهاية في 29 أكتوبر الساعة 12:00. اختار «الإقامة ممكنة مع ملاحظة» واحفظ.
3. تظهر ثلاثة حجوزات: كريم مقيم، هدى لديها حجز متداخل، ومنى لديها حجز لاحق ينتظر اعتماد الجاهزية.
4. في إقامة كريم اكتب السبب وموعد مراجعة لاحقًا لساعة التجربة، ووثق التواصل، ثم اعتمد الاستمرار.
5. في حجز هدى اختار مراسي 301، ووثق موافقة الضيف ومراجعة فرق السعر، واكتب السبب، ثم أكد النقل.
6. افتح التقويم ثم التنبيهات. الحجب مستمر، وحجز هدى يظهر على البديل، والاطلاع لا يغلق التنبيه.
7. اكتب دليل الإصلاح وسجل انتهاء العمل. بعده اكتب نتيجة المعاينة وأكد الاختبار والتنظيف، ثم اعتمد الجاهزية.

## السياسات المنفذة

- الأثر «لا يؤثر على الإقامة» لا يحجب البيع ولا يطلب قرارات ضيوف. بقية التصنيفات تحجب البيع.
- الحجب يبدأ عند وقت التأثير ويستمر حتى اعتماد الجاهزية. النهاية المسجلة تقدير، وليست تاريخ فتح تلقائي. هذا اختيار تحفظي ظاهر داخل الواجهة.
- الحجوزات بعد النهاية المتوقعة تظهر باعتبارها تنتظر الجاهزية. يميز العرض بينها وبين التداخل المباشر.
- قرار الاستمرار متاح فقط عند قابلية الإقامة. يحتاج اسم المسؤول والسبب وتوثيق التواصل وموعد مراجعة مستقبلي.
- النقل يعيد فحص البديل وقت التأكيد، بما يشمل السعة والجاهزية والحجوزات والصيانة. النقل للمقيم يحفظ الفترة السابقة ويغير المتبقي من ساعة التجربة.
- تحديث البلاغ يعيد القرارات للمراجعة. غلق بلاغ لا يزيل أي حجب ناتج عن بلاغ آخر.
- التصعيد بعد مهلة من 1 إلى 72 ساعة، أو فور تجاوز موعد الإصلاح. الساعة تبدأ في 25 أكتوبر الساعة 10:00 ويمكن تقديمها يدويًا فقط.
- الحجز من التقويم يفحص كامل الفترة، ويمنع التعارض ولو بدأت الفترة قبل الصيانة.
- الحجز السريع وإتمام الحجز المباشر يفحصان حجب الصيانة قبل المتابعة. أمثلتهما تظل مستقلة عن سجل الحجوزات الجديد ولا تضيف إليه حجوزات.

## حدود التنفيذ

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

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

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

لا ينقل هذا المسار حجزًا على عدة بدائل، ولا يلغي حجزًا أو يغير قناة خارجية. أمثلة حالات التجربة الجاهزة تظل قفزات للعرض وليست اعتماد إجراءات.

## التحقق

- `node scripts/test-operations.js`: نجح 19 اختبارًا للحجب والتعارض والنقل والتصعيد والمعاينة، بما يشمل الفترات المتلامسة، التواريخ غير الصحيحة، والبديل الذي أصبح مشغولًا قبل التأكيد، وعزل المثال التعليمي عن بيانات الجلسة.
- `node scripts/test-operations-browser.js`: نجح مسار Chrome فعلي من تسجيل البلاغ إلى القرار والنقل والتنبيه، ثم التحقق من حفظ التغييرات بين الشاشات ورفض حجز متعارض وإعادة الفتح بعد المعاينة. اختبر أيضًا منع المتابعة من زري الحجز السريع ودفع الحجز المباشر، ونافذة حالات التجربة في شريط العرض.
- فحص الموبايل بعرض 390 بكسل تحقق من اتجاه RTL وعدم وجود تمرير أفقي للصفحة. جدول التقويم نفسه قابل للتمرير أفقيًا.
- `node scripts/test-calendar-guide-browser.js`: نجح شرح المراحل الست والمثال ذو الحالات السبع، واشتراط الموافقة ومراجعة السعر والجاهزية، وإعادة المثال دون تعديل الجلسة، والنسخ الفعلي للحافظة وتنزيل TXT، والرابط المباشر داخل شريط العرض. راجعت صورة الدليل على الموبايل. صور التحقق في `.cache/calendar-guide-review/`.
- راجعت صورة الموبايل الناتجة من الاختبار. صور التحقق المحلية موجودة في `.cache/operations-review/`.
- تحقق المتصفح من اتجاه التقرير العربي RTL ومحاذاته وروابطه المحلية. نجح فحص دليل الشاشات وعددها 49 وسلامة مسارات النموذج وأصوله بعد إعادة التوليد.

مصدر Markdown نظيف بدون أغلفة HTML. النسخة المقروءة تولد في `operations-review.html`. معاينة Markdown الأصلية داخل Codex لم تتغير.

## الملفات الأساسية

- سجل التشغيل: `design/prototype/interactive/operations-store.js`.
- واجهة التشغيل: `design/prototype/interactive/operations-ui.js`.
- دليل الآلية والمثال: `design/prototype/interactive/operations-walkthrough.js`.
- تنسيق الواجهة: `design/prototype/interactive/operations.css`.
- ربط الأزرار والحجب: `design/prototype/interactive/runtime.js`.
- مولد الشاشات: `scripts/build-prototype.js`.
- اختبارات المنطق: `scripts/test-operations.js`.
- اختبارات المتصفح: `scripts/test-operations-browser.js`.
- اختبارات دليل الآلية: `scripts/test-calendar-guide-browser.js`.
- مصدر شرح التشغيل: `docs/management-guide/operations-guide.js`.
- [فهرس ملفات الدليل](FILES.html). فهرس المشروع الشامل موجود في `FILES.html` بجذر المشروع.